Date post: | 10-Nov-2018 |
Category: |
Documents |
Upload: | duongkhanh |
View: | 212 times |
Download: | 0 times |
� 1
Engenharia de Software Prof.ErwinAlexanderUhlmann
DosRequisitosaoTestedeSoftware
UHLMANN, Erwin Alexander. Engenharia de
Software: dos requisitos ao teste de software.
InstitutoSiegen.Guarulhos,2016.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 2
Agradecimentos
Agradeço à minha esposa Kátia por entender
minha ausência, meu filho por me inspirar e
alegrar, meus pais Mirtes e Günter por terem
criado meu caminho. Aos meus alunos que
viabilizaram este trabalho e a todos os autores
de livros e bibliotecas que consultei para que
pudessedevidamenteembasareste.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 3
Sumário Agradecimentos 2..............................................................................................................
Introdução 5.......................................................................................................................
EngenhariadeSoftware 6.................................................................................................
Software 6......................................................................................................................
ArquiteturasdeSoftware 7...........................................................................................
ImportânciadaEngenhariadeSoftware 8...............................................................
EngenhariadeSoftware 10............................................................................................
MétodosdeProduçãodeSoftware 10......................................................................
DesafiosdaEngenhariadeSoftware 10........................................................................
AtributosdeSoftware 12...........................................................................................
ExercíciosobreRequisitosdeUsuário 13..................................................................
Requisitos 14.......................................................................................................................
RequisitosdeUsuárioedeSistema 14..........................................................................
ExercíciosobreRequisitosdeUsuárioedeSistemas 15..........................................
RequisitosFuncionais 15............................................................................................
RequisitosNãoFuncionais 17.....................................................................................
Especificaçãodeinterface 19.........................................................................................
DocumentaçãodeSoftware 22.....................................................................................
EngenhariadeRequisitos 23..........................................................................................
EstudodeViabilidade 23............................................................................................
ElicitaçãoeAnálise 25................................................................................................
Especificação 26.........................................................................................................
Validação 27................................................................................................................
Projeto 28...........................................................................................................................
ProcessosdeSoftware 28.............................................................................................
ModeloCascata 28.....................................................................................................
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 4
DesenvolvimentoEvolucionário 30...........................................................................
Iteraçãodeprocesso 31.................................................................................................
Incremental 31............................................................................................................
Espiral 32.....................................................................................................................
RationalUnifiedProcess 32.......................................................................................
TestedeSoftware 33......................................................................................................
ModelodeQualidadedeSoftware 33.......................................................................
ModelodeQualidadedaNormaISO9126 34...........................................................
Funcionalidade 34......................................................................................................
Confiabilidade 35........................................................................................................
Usabilidade 35............................................................................................................
Eficiência 36................................................................................................................
Manutenibilidade 37...................................................................................................
Portabilidade 37..........................................................................................................
RespostadoExercíciodeRequisitosdoUsuário 38....................................................
Bibliografia 41.....................................................................................................................
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 5
Introdução EstetrabalhopretendediscutirdeformaamplaaEngenhariadeSoftwaresem
abrangertodososaspectos,maspontuandoosprincipaispontosquesefazem
necessáriosparaaelaboraçãodeprojetosdesoftwareconsistentesequepossam
sermensurados,testadoseauditados.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 6
Engenharia de Software
Software Conhecerosconceitosquefundamentamascoisasédesumaimportânciapara
saberaquesepropõemequaisseusobjetivos.Oqueéeparaqueserveum
software?
Umsoftwareéumacoleçãodescriptsqueseassociamdeformalógicapara
produzirumresultadoesperadodependendodaconfiguraçãoedosdadosde
entrada.
Deformageral,umsoftwareserveprincipalmenteparaproduzirresultadoslógicos
queaceleremasrespostasparaproblemasdocotidianoepermitamsimulaçõesde
resultados.
Umsoftwareéprincipalmentecaracterizadoporumaestruturadescripts(script1),
interfacegráfica(Figura1),dependênciadeumhardware,configuração,
documentação(Figura2)earquivosassociados.
1. <?php 2. $conecta = mysql_connect("200.166.25.124", "root", "123mudar"); 3. mysql_select_db("banco"); 4.5. if(isset($_POST['Gravar'])){ 6. $usu_nome = $_POST['usu_nome']; 7. mysql_query("INSERT INTO usuarios (usu_nome) VALUES
('$usu_nome')"); 8. } 9. ?> 10.<html> 11.<body> 12.<form method='post'> 13.<input type="text" name="usu_nome" id="usu_nome" size="20" /> 14.<input type="submit" name="Gravar" id="Gravar" value="Submit" /> 15.</form> 16.</body> 17.</html>
script1–scriptparamsoftwarewebsimples
Notequeaslinhas2e3possuemdadosdeconfiguraçãocomooendereçodo
BancodeDados,ousuárioeasenhaalémdonomedoBancodeDados.Esta
configuraçãopermiteosoftwarefuncionaradequadamente.Alógicaestánaslinhas
5,6e7,quepermitemreceberdadoseprocessá-los.AInterfaceestáapartirda
linha11.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 7
�
Figura1-InterfaceGráficadeUsuário(GUI)
�
Figura2-DiagramadeAtividades(Documentação)
Paradeterminaroidealparaumaempresaéprecisoconhecereestudaros
processosempresariaiscomBPMeGrafos,comoocaminhocríticoeaárvorede
decisão.
Arquiteturas de Software Deformageral,ossoftwarespodemserdefinidosousegmentadoscomo
monolíticos,duascamadasoucliente-servidoretrêscamadasouncamadas.
Ossoftwaresmonolíticossãoaquelesquepossuememumaúnicaplataformaa
interfacecomousuário,oprocessamentoouregrasdenegócio(programação)eo
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 8
armazenamentoquepodeserounãoemumbancodedados.Algunsexemplossão
ossistemasoperacionais,softwarescriadosemlinguagenscomoC,COBOLe
FORTRANqueestejamnecessariamenteunidosouatémesmoumpequeno
aplicativoemAccessquerodeemumamáquina.Umadascaracterísticasnegativas
destetipodesoftwareéqueoclientepossuicontatocomaprogramação,deforma
permitidaounão,qualqueratualizaçãodeveserfeitanamáquinaclienteeháa
possibilidadededescontroledeversõesinstaladas,oquepodelevara
inconsistênciasdeusoededadosentreosusuários.
Ossoftwaresdotipoduascamadasoucliente-servidor,possuememgeral,parte
delenoclienteeoutranoservidor,comoumainterfaceparaoclienteea
programaçãocomarmazenamentonoservidor,ouainterfaceeaprogramaçãono
clienteeacamadadepersistência,oBancodeDados,noservidor.Comoexemplo,
ossoftwaresquerodamemterminaisburros,redesthinclientdelojasde
departamentooualgunsaplicativosdecelulares.
OssoftwaresemtrêsouncamadassãoaquelesquepossuemaInterfacenocliente,
oprocessamentooucamadaderegradenegócios,aprogramaçãoemsi,emum
servidoreosdadosoucamadadepersistência,emumoutroservidor.Avantagem
destemodeloéocontrolesobreversões,oclientenãopossuicontatocoma
programaçãonemcomosdadoseamanutençãoécentralizada.Outrasdiversas
vantagenspodemsernumeradascomoindependênciadodispositivodesaída,
segurança,reduçãodotrafegodedados,entreoutras.
Importância da Engenharia de Software Adocumentaçãoéimportanteparaverificaçãodoprojetoearealizaçãodo
software,assimépossívelpreverosresultados.Destaforma,alémda
previsibilidadeépossívelrealizarosTestesdeSoftwareeaauditoriadaqualidade
osresultados.Amanutenabilidadeéoutraparteimportantequepodeserpermitida
peladocumentação,assiminserir,excluiroucorrigirpartesdocódigoficasimplese
rápido.Vejamosoexemplodemanutenabilidadecomesemdocumentação
utilizandoosoftwaredoscript1.
Oobjetivodosoftwareégravarosdadosdoformulárioemumbancodedados.O
problemaéqueosdadosnãoestãosendogravados.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 9
Paraencontraroproblemaéprecisopercorrerocódigoembuscadefalhase
alterarsuaprogramação,linhaalinhaparaseencontraroproblema,oubuscar
outrasalternativascomobuscarseobancodedadosestáativo,seaconfiguração
estácerta,ouaindasehácomunicaçãoentreaspartes.
Comadocumentação,bastaanalisaroprojetoediretamentenospontosque
podemapresentarfalhascomoaconfiguração,condicionaisouinterface.
Ostestesdesoftwarepodemauxiliartambémporapresentaremosdadosde
retorno,oquefacilitaaidentificaçãodafalhanopontodoerro.
AindasobreasvantagensdaadoçãodaEngenhariadeSoftwareéaviabilidade
econômica.NomodelosemasdefiniçõesdaEngenhariadeSoftware,oscustos
podemsermuitomaisaltos,conformemostraaFigura3.
�
Figura3-CustodedesenvolvimentodeSoftwaresemplanejamentoadequado(ENGELHOLMJr.,2013)
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 10
Engenharia de Software ComoépossívelobservarnaFigura3,quantomaissedemoradetectarumafalhaou
erronodesenvolvimentodosoftware,maiscaraésuacorreção.Paraqueseevitem
oumitiguemesseserroséprecisodefinirummétododeproduçãodosoftware.
Métodos de Produção de Software
Análise Estruturada
Aanáliseestruturada,comumatéosanos1970,procuraidentificaroscomponentes
funcionaisbásicosdeumsoftware,comoaconexãocomoBancodeDados,a
recepçãodedadosdeumformulárioouafunçãodeimpressão.Suagrafia,emgeral
éutilizadaanotaçãodefluxogramasoudiagramascomoIDEF0,oumesmo
diagramadecaixas.Aanáliseestruturadaésimplesefuncional,porissoatéhojeé
muitoutilizadaereconhecida.
Orientada à Objetos
Apartirdosanos1990,aUMLfoianotaçãoquemaisatendeuosquesitosde
qualidadeemprojeto.Seusnovediagramasconseguemexpressardeformamais
abrangenteaqualidadedeumsoftware.Brooks(1986),emseucélebreartigoNo
silverbullet,indicaqueaUMLpermiteumadocumentaçãomelhoreaprogramação
simplificada,porém,comoseutítulo,nãohámilagresparadesenvolverou
documentarumsoftware,diversassituaçõespodemdefinirqualomelhormétodo.
UmdosmaioresdesafioslevantadosporBrooks,paraaEngenhariadeSoftware,é
odesenvolvimentodesistemasquepossuamIndependênciaFuncional,Altacoesão
eBaixoAcoplamento,assim:
Figura4-DesafiodaEngenhariadeSoftware
Desafios da Engenharia de Software AIndependênciaFuncionalpedequeosistemafuncionesemdependerdeoutras
partesquepodemserparadas,comoemumsite.Ainterfacegráficanãopode
deixardefuncionarporqueomodeloouregradenegócio,aprogramação,parou,
nemtãopoucoservirsomenteàumadeterminadaregraoumodelodenegócioou
arquiteturadesistema,emsuma,ainterfacenãopodepararporculpada
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 11
programaçãoouporqueumdeterminadocamponãopossuicorrespondenteno
BD.
AAltaCoesãoindicaquetodosistemadeveenviarereceberdadosdeformaqueas
partesenvolvidasrecebameprocessemcorretamente,assim,seumcampodeum
formuláriotivercomoidentificadorapalavra“nome”,aprogramaçãodeveestar
preparadaparareceberdadoscomesteidentificador,mastambém,aprogramação
ouainterfacenãodevemconteresteidentificadorcomoumaconstante,ambos
devempermitirqueesteidentificadorpossaseralteradoeasmensagenspossam
sertrocadasdeformacoesa.Deoutraformatambémécomocriarobjetosque
possuammétodosouatividadesquenãodeveriampertenceràestaclasse.De
formasimples,seriacomocriarumobjetoqueéoresponsávelporreceberos
dadosegravá-losnoBancodeDados.
Porfim,oBaixoAcoplamentoexigequetodapartedesistemafuncionedeforma
maisindependentepossível.Quandosecriamobjetosquedependemdo
funcionamentodeoutro,casoumououtropareporqualquermotivo,oobjeto
requisitantedevepermitiracontinuidadedofuncionamento,aindaque
prejudicado,massemfalhas.Quandoadependênciaentreosobjetoéalta,existeo
AltoAcoplamento,algoquedevesempreserevitado,poroutrolado,seesta
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 12
dependênciaforbaixaecadaobjetopuderfuncionardeformaindependente,é
atendidaacondiçãodeBaixoAcoplamento.
AOrientaçãoaObjetos,mostra-secomoumadasformasquemelhorpermite
atenderdeformasatisfatóriaestetipodedesafiodaEngenhariadeSoftware,
porém,comodito,nemtodasituaçãopodeseratendidapelaOrientaçãoaObjetos
(OO),mesmoassim,estedesafionãodevedeixardeseratendido,aindaquepartes
menoresnãosejamelaboradaspelaOO.
Atributos de Software Todoprogramaserve,atendeaumpropósitoespecífico,comoumaplicativode
comunicaçãoporvoz,deveprocessaroáudiodeformarápidaecompactapara
enviarereceberemtempoadequadoosdados,umprogramadecontrolede
injeçãodecombustívelemummotordecarrodeveresponderimediatamenteaos
parâmetrosambientais,comoooxigênio,acelerador,octanagemerotaçõespor
minutoe,semfalhas.Aodesenvolverumsoftwarequeohardwarenãocomportaé
precisocompreenderquaissãoseusatributosoucaracterísticasessenciaisparaseu
funcionamentoadequado,aindaquesepercamcaracterísticasadicionais,não
essenciais.
Entreascaracterísticasessenciaispodemsercitadas:
Manutenabilidade:Oprogramadeveserescritodeformaqueasalteraçõessejam
rápidaefacilmentefeitas.Osclientespodemsolicitaralteraçõescomfrequências
altasoubaixase,estudarosoftwareesuasinteraçõestodavezquehouveruma
alteraçãopodetornarsuamanutençãocara,demoradaefrequentementecom
errosdetodaespécie.Éimportantesalientarqueamanutençãodeumsoftware,
nestecaso,nãosetratadetesteseverificaçõesperiódicas,masquemiráecomoirá
semanterumcontratodealteraçõesecomplementos.Umadasformasde
mensuraramanutenabilidadeéotempoqueumaalteraçãooucorreçãolevapara
serefetivada,porém,comoistodeveserelaboradoantesdasocorrências.Desta
forma,podeserfácilmensuraramanutenabilidadeporsuadocumentação.Quanto
maisdocumentadoseguindo-seospadrões,maisrápidaserásuamanutenabilidade.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 13
Confiança:Aconfiabilidadeéamétricaqueseutilizaparaanalisaronúmerode
vezesouotempodeusoatéafalhadeumsoftware,alémdesteparâmetrosão
consideradososfatoresdeproteção,segurançaedisponibilidade,que
essencialmentedescrevemcomoalgoestarinacessível,protegido,porémpodeser
apropriado,carregadoeseguro,oobjetopodeseracessado,masnãocarregado.
Deformasimplesosdadosdeumclientedevemestarprotegidos,inacessíveisea
senhadeacesso,nãopodesercarregada,grava,poissecorretamenteprogramada,
deveestarcriptografada.Adisponibilidadeétraduzidapelacapacidadedetornar
umsistemadisponível,ouseja,seumservidorcair,háoutroquepossaseracessado
imediatamente?Quantotempoosistemaatende?Comoéfeitaatransiçãoentre
servidores?
Eficiência:Osoftwaredeveserprojetadoaconsumiromenosrecursosopossível,
sejadeprocessamento,armazenamentooucarregamento,comoexemploumsite,
paracadatelaquesenavega,precisaenviaraoclientetodososarquivos,como
logotipo,arquivosdefundoououtrosqueserepitam.Estesarquivospodemser
carregadosapenasumavezearmazenadosnocomputadordocliente,evitandoo
tráfegodesnecessáriodedadosnarede.
Usabilidade:Ousodevesersimples,semesforçosdesnecessáriosedeforma
intuitiva,oquepodeincluiradocumentação.Diversosformuláriosdogoverno
possuemcamposaserempreenchidosquesomenteumcontador,advogadoou
funcionáriosaibamseussignificados.Deoutraforma,osbotõesdecontinuar,
voltar,fecharououtrosdeusocontínuo,podemestaragrupadoseemtamanho
adequadoparaouso,evitandodeslocamentodesnecessário,nemcliqueserrados.
Outroexemploimportanteéotamanhodafonte,seousuárioédeficientevisual,
auditivooumotor,oumesmo,deve-seconsiderar,hoje,odispositivo,comoum
tabletoucelular.
Vamospraticar!
Exercício sobre Requisitos de Usuário Um cliente deseja um software para controle de entrada, saída, almoço e escala de emenda de feriados em sua empresa que tem 212 funcionários e é uma fábrica de plásticos injetados para a indústria de panelas.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 14
OexercícioéparaescreverosRequisitosdeSistemadeformaadequada
considerandocomoresolveroproblemadoBaixoAcoplamento,daAltaCoesãoe
daIndependênciaFuncionaledescreverdeformaamplaaManutenabilidade,
Confiança,EficiênciaeUsabilidadeparaapresentaçãoaocliente.
Comoaempresaéfictícia,elaborecomseuscolegasosFatorescríticosdesucesso
paradeterminarquaissãoascaracterísticasessenciaisparaestesoftware.
Oobjetivodesteexercícioédesenvolverodocumentodeformapráticapara
compreensãodacomplexidadedodesenvolvimentodosRequisitosdeSistemade
formaqueseatendaosaspectosqueenvolvemodesenvolvimentodosoftware.
Requisitos
Requisitos de Usuário e de Sistema OsRequisitosdeUsuárioexpressamdeformaabstrataoqueseesperadosistema,
utilizandolinguagemnatural,diagramaseoutrasformasquesefaçamclarospara
compreenderseusanseios.AdevolutivapassaaserchamadadeRequisitosdo
Sistemacomasdefiniçõesdefunções,serviçoserestriçõesoperacionaisdo
sistema.Estesrequisitostambémsãochamadosdeespecificaçõesfuncional.
Deformaprática,apartirdosrequisitosdousuário,parasecriarosrequisitosde
sistemaouespecificaçõesfuncionais,éprecisoelaborarumdocumentoque
expliqueoquedeveserfeitoparaatenderosrequisitosdousuário.
O sistema deve ser simples e funcional, com botões que expressem de forma clara para que servem e o cliente possa, sem entender de programação, alterar os dados de todo o site, como nome, endereço, nome das páginas, conteúdo e imagens.
OEngenheirodeRequisitosdevetraduzircadapasso,assim:
1. Oqueéprecisoparasersimples?
Terumainterfacecompoucasopçõeseprogramar;
2. Oqueéprecisoparaserfuncional?
Terumainterfacequeodesigneleiauteprivilegiemasfunçõesemdetrimentodasformas;
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 15
3. Oqueéprecisoparaqueosbotõessejamclaroseexprimamsuautilidade?
Estudaraprincipalfunçãodeusodobotão,nãoembutir funçõesquetenhamaspectosdiferentesdaprincipaleutilizardesignflat;
4. Oqueéprecisoparaquealteredosdadossementenderdeprogramação?
Desenvolverformulárioscomnomeseperguntasqueexpressemoquealteram;
Exercício sobre Requisitos de Usuário e de Sistemas DesenvolvaodocumentoparaosRequisitosdeSistemaparaosseguintes
requisitosdeUsuário:
A empresa possui duas plataformas de gerenciamento de dados e processos. Uma é própria e em linguagem web e a outra é do fabricante X que é formato desktop, fica instalado nas máquinas e os dados devem ser sincronizados ao máximo possível para que os dados de vendas do sistema próprio sejam úteis para o sistema novo que é de produção.
Requisitos Funcionais
OsRequisitosFuncionaisdeumsistemadescrevemasaçõesquedevemser
realizadas,assimcomoosresultadosesperadoseasformasqueserãoobtidos.
Diferentedosrequisitosdeusuário,altamenteabstraído,osRequisitosFuncionais
sãoasespecificaçõestécnicasquepermitemacompreensãodecomoosdadosde
entradaserãoprocessadoseosdesaídaforamobtidos.
RequisitosFuncionaissãoasdeclaraçõessobreasfunções,serviços,reaçõesa
determinadascondições,interfaceeconfiguraçõesdosoftware.
Paraseelaborarumbomdocumentodelevantamentoderequisitosfuncionaisé
precisoatenderasespecificaçõesdeCompletezaeConsistência.
Completezasignificaquetodasascaracterísticasdescritaspelousuáriodevemser
definidosnonívelquepermitaacriaçãodosoftwaresemquehajamdúvidasou
sejamnecessáriasinterpretaçõesdoprogramador.
Consistênciasignificaquetodasasespecificaçõesdevemserverificadasseem
outraspartesdosistemaselasnãosãocontraditóriasouseanulem.
Exemplo:
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 16
RequisitosdeUsuário:Criarumsoftwarequepermitaocadastrodeusuários.
RequisitosdeSistema:
•Qualoobjetivodosoftware?
• Criarumpequenosistemaquepermitaqueosfuncionáriossecadastremparateracessoaosarquivosdoescritório;
•Quaissãoosdadosnecessáriosparaisto?
•Nome,email,cargoesupervisor;
•Oqueéimportantenestesoftwareparaaempresa?
•Queousuáriotenhapermissãoimediatadeacessoparaleituraeapósaprovaçãodosupervisor,acessototal;
• Todososmovimentodousuáriodevemserregistradosemumlogdosistema;
•Osistemapodepermitiracessosomentedecomputadoresinternos,comliberaçãopeloIP.
•…
…
RF01-OcadastrodeveteroscamposdotipotextoparaarmazenarosdadosNome
eemail;
RF02-Ocadastrodevetercamposdotiposelectcomosdadosjácastradosde
Cargoequeofuncionárioapontesomentesupervisoresepossaapontaroutros
funcionários;
RF03-Osistemadeverátertrêsníveisdeacesso:1-cadastrado,2-liberado,3-
supervisor;
RF04-osistemadeveestarpreparadoparadispositivosmóveis,comocelulares,
tabletsetambémcomputadoresdemesa,comamesmaqualidadedeleitura.
RF05-…
Completeza: RF01-campodotipotexto.Faltaindicarotamanhoparanome
completoounomedeusuário.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 17
RF02-oselectinformaqueosdadosjádevemestarcadastrados,mas
nãodizsesãovariáveiscomdadosdeBancodeDadosousesãofixos.
RF03-Emnenhumlugarfoidescritoondeestesníveissão
cadastrados,escolhidosoueditados.
RF04-Qualéaqualidadedeleitura?Todosusuáriospodemler
normalmente?Hápessoascomdeficiêncianaempresa?
Consistência:RF03-estáinconsistente.Elenãoédescritonesteformatonos
requisitosdesistema.
RF04-Setodoacessodeveserdecomputadoresinternosliberados
porIP,dispositivosmóveiscontradizemaregra.
Requisitos Não Funcionais RequisitosNãoFuncionaissãoasespecificaçõesrestritivasoudeinfra-estruturae
funcionamentosistema.Diferentedosrequisitosfuncionaisqueexplicamdeforma
detalhadaoqueosistemairáfazer,osnãofuncionaisdescrevemnomesmonível
dedetalheoqueéprecisoparaqueosistemaatendaasespecificaçõesdos
RequisitosFuncionais.
OsRequisitosNãoFuncionaisdescrevemdeformaobjetivaosrequisitosquenão
pertencemaoserviçodosoftware,comolinguagens,padrõesdedesenvolvimento,
decontrole,deplataforma,daarquiteturadosoftwareeseucomportamento.
EntreasprincipaiscaracterísticasdosRequisitosNãoFuncionaisestãoadefinição
dalinguagemdeuso,comoJavaouPHP,aplataformaqueiráatender,comolocal
Windows,LinuxouUnixouaindaweb,comoApacheouIIS.Tambémseespecificam
ohardwarenecessárioparatalação.DeformasimplesosrequisitosNãofuncionais
sedividememtrêsgrandesáreas:RequisitosdeProduto,Organizacionaise
externos,comomostraaFigura5.
Figura5-ÁrvoredeRequisitosNãoFuncionais
ComoosRequisitosNãoFuncionaisestabelecemaplataformadeatendimentodos
RequisitosFuncionais,partiremosdosRequisitosFuncionaisdescritos
anteriormenteparaelaboraroexemplo:
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 18
ParaatenderoRF01(RF01-Ocadastrodeveteroscamposdotipotextoparaarmazenaros
dadosNomeeemail;)
RNF01-AplataformadeveserWEB,comusodalinguagemPHP;(RNFdeProduto)
• Paraatenderacompletezaeconsistência…
• PorquêWEBePHP?
•Ondeficarãooscomputadores?
•Qualoambiente?Windows,LinuxouUnix?
•Qualotipodeservidor?
• Seasegurançaéalta,comotratardasegurança?(Consistência)
(RF02-OcadastrodevetercamposdotiposelectcomosdadosjácastradosdeCargoequeo
funcionárioapontesomentesupervisoresepossaapontaroutrosfuncionários;)
RNF02-OservidorseráconformedisponibilizadopelosetordeTI,conformeregra
XPTOdestesetor;(RNFOrganizacional)
RNF03-Osusuáriosnovosdevemteracessosomentecomliberaçãopelo
supervisor,conformedescritonosrequisitosdeusuário,assim,aliberaçãodeve
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 19
criarumadependênciaentreoliberadoeoliberador,garantidoassimasegurança
deacessoaosistemaporco-dependência.
Parasepensaremmétricasdeeficiência,cria-seumcenário:
Umservidoremrede10/100com50computadores.
Setodosestiveremconectadoscomusoespecíficoparaacessoaosoftware.Se
todossolicitaremacessoaosistemaaomesmotempo,acapacidademáximade
fornecimentodedadoséde100Mbps,ouseja,100Mbps/50máquinas.Comocada
máquinapodesolicitarparasiaté2Mbpsecadacaracterepodeconsumiraté8b,
logo250000caracteres/segundo.Seosistemativerimagensearquivos
dependentesaseremcarregados,odesempenhocai,aeficiênciapodeserobtida
pelareduçãodestesaspectos.
Especificação de interface Amaioriadossoftwaresquandosolicitadossãoimplementaçõessistemasjá
implantados,ouseja,umsistemaéimplantadoquandonãoháaindaoutro,eleé
novo,ealgoimplementadoquandojáexisteumimplantadoeganharáum
implemento.
AEngenhariadeSoftwaredevegarantirqueointerfaceamentodestessistemas
ocorradeformatransparenteparaosistemalegadoeoimplementopormeiode
umadocumentaçãoquedeterminaospontosdeentradaesaídadosistema
implantadoeconseguircombinarcomospontosdeentradaesaídadonovo
software.
AdocumentaçãodeveserdescritacomoInterfacesdeProcedimento,Estruturade
DadoseRepresentaçãodeDados.
InterfacedeProcedimentos:AsApplicationProgrammingInterfaces(APIs)sãoas
aplicaçõesoupequenossoftwaresquepermitemacomunicaçãoentresistemasde
formaativaeassíncrona,ouseja,duranteoprocedimentoemumsistemaa
comuniçãopodeocorrerantesmesmodoprocedimentoterminar.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 20
UmexemplopráticoéoXMLHTTPRequest(MozillaFirefox,SafariouOpera)ouo
ActiveXObject(MicrosoftInternetExplorer)sãoasAPIsparacomunicação
assíncronaentresistemasweb.
EstruturadeDados:Arepresentaçãográficadecomoosdadossecomunicamentre
ossistemas.NaUML,oDiagramadeMáquinadeEstadoséumaformasimplese
eficazdesedemonstrarcomoosdadossãotrocadosentreestessistemas(Figura
5).
Alémdosdiagramas,muitasvezessefaznecessárioquesedemonstreaestrutura
decomunicaçãocomoresultado,umexemploéoarquivomodelodetrocade
mensagenscomooXML.
<turmas> <tur_id>1</tur_id> <tur_descr>Turma X</tur_descr> <tur_num>201602</tur_num> <sal_id>12</sal_id> <coo_id>9</coo_id> </turmas>
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 21
Figura6-EstruturadeDados
RepresentaçõesdeDados:Demonstracomoosistemasecomportacomosdados,
astrocasdemensagens,asrespostaseasrequisições(ere-requisições)dos
sistemas.NaUMLumDiagramadeSequenciaéumaformaimportantepara
representarosdados(Figura6).
Figura7-RepresentaçãodeDados
Nestecontexto,emespecialnoswebserviceséimportanteconheceroconceitode
EnterpriseServiceBUS(ESB)queéumaarquiteturadesoftwareconcebidacomo
umacamadadeabstraçãoparacomunicaçãoentresistemascomplexosdetrocas
múltiplasdedadosassincronicoseemmulticanais.
Deformasimplesimagineumapequenaempresaquepossuiapenastrêssistemas
quenãosecomunicam,nãosãointegrados,comovendas,estoqueelogística.O
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 22
sistemadevendas,aoconcluirseusprocessosimprimeosdocumentosadequados
paraosistemadeestoquedarbaixaeoprodutoser
retiradonelepelopessoaldelogísticaparaentregano
cliente.ComoESBacomunicaçãopodesergarantidapelo
BUSdesdequeoEngenheirodeSoftwaretenha
especificadocorretamentetantoaRepresentaçãodos
Dados,aEstruturadeDadosecomoistoocorrerá,a
InterfacedeProcedimentos.
Figura8-EnterpriseServiceBUS
Documentação de Software ComodefinidopeloIEEE/ANSI830-1998noSWEBOKV3.0(http://
www.computer.org/ieeecs-swebokdelivery-portlet/swebok/SWEBOKv3.pdf?
token=TxoQmJSG0TrGEdoyV5hAcE9jTwFEPb1Y),aestruturadeveser:
1-Introdução
1.1-Propósitododocumentoderequisitos
1.2-Escopodoproduto
1.3-Definições,acrônimoseabreviaturas
1.4-Referências
1.5-Visãogeraldorestantedodocumento
2-DescriçãoGeral
2.1-Perspectivadoproduto
2.2-Funçõesdoproduto
2.3-Característicasdosusuários
2.4-Restriçõesgerais
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 23
2.5-Suposiçõesedependências
3-Requisitosespecíficos
RF,RNFeInterface
4-Apêndices
5-Índice
Figura9-FormatododocumentopadrãoestabelecidopeloIEEEparaEngenhariadeSoftware
Engenharia de Requisitos
AEngenhariadeRequisitoséumaseriedeaçõestomadaspeloEngenheirode
Softwarequevisamanteradocumentaçãodosoftwaredeacordocomospadrões
estabelecidosdasolicitaçãoàentrega.
AEngenhariadeRequisitosécaracterizadaporquatrosubprocressos:estudode
viabilidade,elicitaçãoeanálise,especificaçãoevalidação.Cadasubprocessoda
EngenhariadeRequisitosserveparaumafasedoprocessodesoftware,como
segue:
Estudo de Viabilidade OEstudodeViabilidadeéumdocumentoquedescreveosrequisitosdonegócio,o
descritivofuncionaldosistema,aindaqueprévio,ecomoosistemapoderáapoiar
osprocessosdenegócio.
Exemplo:
Descritivo das regras de negócio
ONegócioprecisaarmazenartodososclientes,funcionários,produtos,datasde
consultaeverificarsefechounegócioounão.Todosestesdadosdevemser
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 24
relacionadosparaofertarprodutosnãocompradoserelacionadosparaoclientee
disponibilizarumdescontosobanálisefutura.
Descritivo Funcional do Sistema
Osistemapossuiráumainterfacesimpleseintuitivaparacadastro,ediçãoe
exclusãodepessoas,produtos,efetivaçãodevenda,relatóriosporcliente,por
produto,pordataeporvendedoreaofertadedescontosobonúmerode
consultasevendasdoprodutopelonumerodeconsultasevendasporcliente.
Suporte do Sistema ao Negócio
Comoaempresarealizataistarefasatualmente?
Quaisproblemaspossíveisosistemaajudariaaevitarouresolver?
Comoosistemacontribuirádiretamenteparaosobjetivosdaempresa?
Cálculo do custo benefício
Paraseobterovalordeumsoftwarequesejaadequadoaouso,ouseja,calcularo
Custoemrelaçãoaobenefício,éprecisoentenderadiferençaentrecustoevalor.
Custoéaquantiafinanceirapagaemdetrimentodousodobemevaloréa
expressãodautilidade,dagarantiaedocustoparaseobterumbemcomas
mesmasespecificaçõesqueatendamdeformasatisfatória.
Destaformaépossívelcalculardaseguinteforma:
Valor,utilidadeegarantia.
Valor=custodeumsubstitutocomasmesmascaracterísticasouqueatendade
formasatisfatória.
Utilidade=quantidadedevezesquesenecessitouutilizarporumperíodo.Ex.:qual
autilidadedo3Gnocelular?
quantasvezesvocêprecisouutilizaro3Gnaúltimasemana(7dias)?
nosúltimos7diaspreciseiutilizar4vezes.
logo,autilidadedo3Gé4/7,ou42%.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 25
Garantia=Éonúmerodevezesdeusoatéafalha.Ex.:das4vezesqueutilizou,
quantasforamdefatoefetivadas?3.Logo3/4degarantia.
Elicitação e Análise Oprocessodeelicitaçãoeanálisedosrequisitosdeveserfeitocomaequipede
engenhariaeocliente.Paratalaçãoummodeloespiraldeconstruçãodo
documentopodeserfeitocomquatroáreas:ObtençãodosRequisitos,Classificação
eOrganização,PriorizaçãoenegociaçãoderequisitoseDocumentação,conforme
ilustraaFigura10.
Figura10-ProcessoespiraldeElicitaçãoeAnálisedeRequisitos
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 26
Obtenção de Requisitos
Entrevistadireta,questionáriosquantitativosequalitativos,elaboraçãode
diagramaseestudodonegócio.
Classificação e organização de requisitos
Classificarosrequisitoscomorelacionadosoucomplementareseorganizaem
conjuntoscoerentes.
Priorização e negociação de requisitos
Paraevitarrequisitosconflitanteseredundantesentreváriosstakeholders,é
importantenegociarqualéoprioritárioeexporosrequisitosparadeterminaçãode
qualatender.
Documentação de requisitos
Especificar,escrevereapresentarparaapróximavoltadaespiral.
Especificação Analisarodocumentodosrequisitoseconvertê-loemumaformapadrão,comoa
UMLparadesenvolvimento.Estepontoédegrandeimportânciaparadetecçãode
conflitosderequisitosFigura11.
Figura11-RequisitosconflitantesdemonstradosemUML
Qualadiferençaentreousuárioeoadministrador?
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 27
Osrequisitosexigiamqueambospudessemgerenciar,porém,apenasumpoderá.
Negociação!!!
Validação Avalidaçãodevecolocaremprovaosrequisitos,seucumprimentoounão,seus
conflitoseredundânciasefalhas,destaforma,deve-serever:
Validade:Todousuáriopoderárealizarosolicitado?
Completeza:Osrequisitosforamlevantadosdeformaaresolveroproblema
completamente?Nãofaltaramdetalhesfuncionais?
Consistência:Osrequisitossãoconflitantes?SomenteoAdminpodeGerenciaros
usuáriosxtodousuáriodevepodergerenciarseusdados.
Realismo:Épossívelexecutar?Oprazoéviável?Ocustoéaceitável?Aestruturae
tecnologialegadassuportam?
Quantificável,MensuráveleVerificável:Odocumento,desdeolevantamentodos
requisitosdeveserfacilmenteQuantificável,ouseja,expressaronúmerode
funções,declientes,deusuários,produtos,etc.,Mensurávelparaquepossamedir
otempodeuso,acargadosistema,emcasodepaneotempoderetorno,emcaso
deerro,asconsequênciaseVerificávelparaquedeformasimplespossaser
compreendidopeloclienteouusuárioqueosolicitadofoiatendido.
CasosdeTeste:Aindanãoéotestedesoftwarequeverificaofuncionamentodele
pronto,mascriaçãodesituaçõeschave,comodoistiposdeusuáriosexecutandoas
mesmasfunções,omesmotipodeusuárioexecutandoaçõescontráriase
desobedecendoregrasdenegócio.Éconvenienteaelaboraçãodeummapa
mental.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 28
Projeto
Processos de Software ProcessodeSoftwareéoconjuntodeatividadesquelevaàproduçãodosoftware.
Estaatividadetemestenomeporserareuniãodediversasatividadeshumanas,
técnicasefabris,como,nestaordem,acriatividade,adocumentaçãoecodificação
eadependênciaentrediversasatividadesparalelasdeprodução.Entreas
atividadesestãoaEspecificaçãodeSoftware,ProjetoeImplementação,Validação
eaEvolução,sendo:
• Especificaçãoserefereàsfuncionalidades,operaçõeserestrições;
• Projetoeimplementação:atendimentoàsEspecificações;
• Validação:verificaçãocomoclientedosolicitado;
• Evolução:atenderàsnecessidadesmutáveisdocliente.
OProcessodeSoftwareéprincipalmenteutilizadocomodocumentaçãoque
permitaacontinuidadedosoftwareporoutrosquenãoparticiparamdeseuprojeto
semprejuízodaqualidade.
Ex.:DiagramasUML,EngenhariadeRequisitos,etc.
OsmodelosdeProcessodeSoftwaresãoabstraçõesdasatividadesqueauxiliama
compreensãodasatividadesdeprodução,entreosmodelospodemsercitados:
Modelo Cascata
Umdosprimeirosmodelosdedesenvolvimento,quedatadosanos1970e
representaociclodevidadosoftware.Eleécaracterizadopeladefiniçãodas
atividadesopassoseguinteeaverificaçãonopassoanterior,ouseja,umpasso
servededesenvolvimentoerequisitoparaoseguintequedevevalidá-lo.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
DefiniçãodeRequisitos
Projetodosistema
� 29
Análiseedefiniçãoderequisitos:Documentaçãoelaboradacomoclienteeque
servedebaseparatodasasatividadedomodelodeprocesso.
Projetodosistema:Definiçãoabstratadaarquiteturadosistema,hardware,
softwareesuasrelaçõesedependências;
Implementaçãoetestedeunidade:Duranteoprocessotodaaunidadeétestada
emsuaspartes,nestafase,étestadaaunidadecompletaconformeas
especificaçõesderequisitos;
Integraçãoetestedesistema:Apósotestedeunidadeaintegraçãoérealizada
comotesteparaverificarasrelaçõesedependênciaseseasespecificaçõesestãode
acordocomosrequisitos,estafaseéaliberaçãodosoftwareparaocliente*;
Operaçãoemanutenção:Estaéafasemaislongadociclodevidadosoftware,em
geraléafaseparadetecçãodeerrosdeproduçãonãodetectados.étambémafase
deaprimoramento,ampliaçãoeimplementaçãodenovosmódulos.
*Deformasimplificadaegeneralizadaasversõesalfasãoaprimeiraversãoliberada:
Elanormalmentetemtrêsfases:Alfa1:softwareprontoemfasedetestecomos
colaboradores,ousejaéaversãointerna,commuitaspossíveisfalhas.Alfa2:após
ascorreçõesinternaséliberadoparaoclientequetestaemmodeloteste(seforum
softwarenovo,correjuntodospapéis,casosejasubstituiçãodeoutro,devecorrer
emparaleloecomserviçoduplicadoparadetecçãodafalhas).Alfa3:Correções
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
ImplementaçãoetestedeUnidade
Integraçãoetestedesistema
Operaçãoemanutenção
� 30
internaseexternasfeitaséliberadaaversãopararefinamentodeusabilidade,
acessibilidade,visualenovosrequisitosdetectadosdepoisdotestepelocliente.
Beta1:PorvezesdefendidacomoAlfa3ouvice-versa,écaracterizadapelaliberação
paraaoperação.Beta2:Correçõespósoperação,detectadaspelocliente.Beta3:
Versãofinal.Apósascorreçõespósoperaçãocomosnovosrequisitos(alfa2)e
ajustesdeusabilidadeeacessibilidadeeusoextensodosoftwareemsituaçãoreale
semparalelismo.
Deformageraltambéméinteressantedefinirprazosparaamudançadeversão.
Estesprazossãocompatíveiscomoporteecomplexidadedosoftware.Deforma
simples,cercade10%dotempodeprodução,ouseja,seosoftwarelevouumano
parachegarnoAlfa1,30a40diassãonecessáriosparaarealizaçãodostestes.
**Umsoftwareéversão1quandoéliberadoapósaversãoBeta3.Apósisto,as
primeirascorreçõesoumelhoriasdemódulossãoapresentadascomo1.1.Seneste
módulocorrigidohouvernovasalteraçõesentãoseráaversão1.1.1.Paraquese
torne2,osoftwaredevesernovo,reescrito.Paraummódulosetornar2(1.2)este
módulodeveserreescritoeparasetornar1.1.2acorreçãodomódulodevetersido
reescritaapósacorreçãoqueadenominoucomo1.1.1.Podemexistirversõesmais
complexasedemonstremmaisníveis,como1.2.3.4.5epodem,conforme
documentação,demonstraratéocampooubotãonovodosistema.
Desenvolvimento Evolucionário Esteéumprocessodeproduçãoinvisívelouquenãopermiteadefiniçãodeprazos
nemeconomicamenteviávelaproduçãodedocumentosparacadaversão.Sãoem
geraladotadosquandonecessidadesespecíficasdeclientesquenãosabemcomo
resolver,nãoconseguem(sejaoclienteouoEngenheirodeSoftware)demonstrar
ouatéquepontoosoftwaredeveráatingir.
Emgeralsãosistemasquedevemdescobrircomoresolverproblemasqueaindaa
ciênciadoclientenãoconheceexatamenteoresultadoesperado.
Comoexemplo,sistemasrobóticosdereconhecimentodefala,gestos,sons,
sistemascirúrgicos,decálculodeparâmetrosdanatureza,qualitativos,entre
outros.Sãoseparadosemdoistiposdedesenvolvimento:
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 31
Exploratório:Conformenovasfunçõessãoentregues,novascaracterísticassurgem
esãosolicitadaspelocliente.
Throwaway:Oclientenãoconseguedefinirexatamenteaspotencialidadesqueo
sistemapodeatenderedefinirosrequisitos.Umprotótipoédesenvolvidoe
apresentadoconformeépossívelcompreenderdoclienteeesteobservaos
resultadosapresentadosparapercepçãoeevoluçãooudescarte.
Iteração de processo Qualquersoftwarepodesofrermudançasaolongododesenvolvimentooumesmo
aolongodouso,comaadoçãodenovastecnologiasenovosrequisitos.Para
auxiliarnestesaspectos,oprocessodeiteraçãooudesenvolvimentoincrementalou
porfases.
Incremental
Quandoossoftwaressãocomplexosoupossuempartesaindanãodefinidasdo
projetotodo,odesenvolvimentoincrementalestudaapartequeiráser
desenvolvida,emtodassuasfasescomosoftwaresindependentes,commodelos
comoCascataouEvolucionário.
Oquediferenesteaspectoéaintegraçãodosincrementos.Aintegraçãopode
ocorrerporinterefaceamento(trocademensagens)ouintegraçãosimples,quando
aspartespertencemaomesmosoftware,combasededadosúnica.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
Descriçãodoesboço(pré-prototipação)
Desenvolvimento
Especificação
Validação
Desenvolvimento
VersãoInicial
Final
DesenvolvimentoIntermediárias
� 32
Espiral
Cadavoltanaespiralrepresenta:
• Definiçãodosobjetivos;
• Avaliaçãoereduçãoderiscos;
• Desenvolvimentoevalidação;
• Planejamento.
Rational Unified Process ORationalUnifiedProcess(RUP)éumexemplodemetodologiaderivadadaUML
(UnifiedModelingLanguage).
ORUPreconheceosoutrosmodeloscomponentesetrata-oscomopartesda
perspectivageraldodesenvolvimentodesoftwarescomplexos.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 33
Teste de Software ISO/IEC9126éumanormaISOparaqualidadedeprodutodesoftware,eladefine
umconjuntodeparâmetroscomoobjetivodepadronizaraavaliaçãodaqualidade
desoftware.FoisubstituídapelaNormaISO/IEC25010:2011.Elaseenquadrano
modelodequalidadedasnormasdafamília9000.Anormabrasileira
correspondenteéaNBR13596,quefoisubstituídapelaNBRISO/IEC9126-1.
Modelo de Qualidade de Software
Aqualidadedeumsistemadesoftwarepodeserentendidadediversasformase
utilizandodiferentesabordagens.
AnormaISO/IEC9126,ouconjuntodenormasquetratamdesteassuntonoâmbito
daISO,estabeleceummodelodequalidadecomosseguintescomponentes:
Processodedesenvolvimento,cujaqualidadeafetaaqualidadedoprodutode
softwaregeradoeéinfluenciadopelanaturezadoprodutodesenvolvido;
Produto,compreendendoosatributosdequalidadedoproduto(sistema)de
software.Estesatributosdequalidadepodemserdivididosentreatributosinternos
eexternos.Estessediferenciampelaformacomosãoaferidos(internaou
externamenteaoprodutodesoftware)eemconjuntocompõemaqualidadedo
produtodesoftwareemsi;
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 34
Qualidadeemusoqueconsistenaaferiçãodaqualidadedosoftwareemcada
contextoespecíficodeusuário.Estaé,também,aqualidadepercebidapelousuário.
Modelo de Qualidade da Norma ISO 9126 Anorma9126sefocanaqualidadedoprodutodesoftware,propondoAtributosde
Qualidade,distribuídosemseiscaracterísticasprincipais,comcadaumadelas
divididasemsub-características,conformepodemosvernafigura:
Nonívelmaisaltotemosascaracterísticasdequalidadeenosquadrosabaixoas
suassub-características.Cadacaracterística/sub-característicacompõeumAtributo
deQualidadedosoftware.
Notequeemtodasascaracterísticastemosumasub-categoriacomonomede
Conformidade.Aconformidadeéutilizadaparaavaliaroquantoosoftware
obedeceaosrequisitosdelegislaçãoetodootipodepadronizaçãoounormalização
aplicávelaocontexto.
Funcionalidade Acapacidadedeumsoftwareproverfuncionalidadesquesatisfaçamousuárioem
suasnecessidadesdeclaradaseimplícitas,dentrodeumdeterminadocontextode
uso.
Suassub-característicassão:
Adequação,quemedeoquantooconjuntodefuncionalidadeséadequadoàs
necessidadesdousuário;
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 35
Acurácia(ouprecisão)representaacapacidadedosoftwaredefornecer
resultadosprecisosoucomaprecisãodentrodoquefoiacordado/solicitado;
Interoperabilidadequetratadamaneiracomoosoftwareinteragecomoutro(s)
sistema(s)especificados;
Segurançamedeacapacidadedosistemadeprotegerasinformaçõesdousuário
efornecê-lasapenas(esempre)àspessoasautorizadassegurançatambémpode
estardirigidaem,processargerarearmazenarasinformações;
Conformidadetratadapadronização,políticasenormasdeumprojeto;
Confiabilidade Oprodutosemantémnoníveldedesempenhonascondiçõesestabelecidas.
Suassub-característicassão:
Maturidade,entendidacomosendoacapacidadedosoftwareemevitarfalhas
decorrentesdedefeitosnosoftware;
TolerânciaaFalhasrepresentandoacapacidadedosoftwareemmantero
funcionamentoadequadomesmoquandoocorremdefeitosneleounassuas
interfacesexternas;
Recuperabilidadequefocanacapacidadedeumsoftwareserecuperarapósuma
falha,restabelecendoseusníveisdedesempenhoerecuperandoosseusdados;
Usabilidade
Acapacidadedoprodutodesoftwaresercompreendido,seufuncionamento
aprendido,seroperadoeseratraenteaousuário.
Notequeesteconceitoébastanteabrangenteeseaplicamesmoaprogramasque
nãopossuemumainterfaceparaousuáriofinal.Porexemplo,umprogramabatch
executadoporumaferramentadeprogramaçãodeprocessostambémpodeser
avaliadoquantoasuausabilidade,noquedizrespeitoaserfacilmente
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 36
compreendido,aprendido,etc.Alémdisto,aoperaçãodeumsistemaéuma
interfaceHumano-Computador(verIHC)sujeitaàsavaliaçõesdeusabilidade.
Suassub-característicassão:
Inteligibilidadequerepresentaafacilidadecomqueousuáriopodecompreender
assuasfuncionalidadeseavaliarseomesmopodeserusadoparasatisfazerassuas
necessidadesespecíficas;
Apreensibilidadeidentificaafacilidadedeaprendizadodosistemaparaosseus
potenciaisusuários;
Operacionalidadeécomooprodutofacilitaasuaoperaçãoporpartedousuário,
incluindoamaneiracomoeletoleraerrosdeoperação;
Proteçãofrenteaerrosdeusuários:comoprodutoconsegueprevenirerrosdos
usuários;
Estética/Atratividade:envolvecaracterísticasquepossamatrairumpotencial
usuárioparaosistema,oquepodeincluirdesdeaadequaçãodasinformações
prestadasparaousuárioatéosrequintesvisuaisutilizadosnasuainterfacegráfica;
Acessibilidade:refere-seapráticainclusivadefazersoftwaresquepossamser
utilizadosportodasaspessoasquetenhamdeficiênciaounão.Quandoos
softwaressãocorretamenteconcebidos,desenvolvidoseeditados,todosos
usuáriospodemterigualacessoàinformaçãoefuncionalidades.
Eficiência Otempodeexecuçãoeosrecursosenvolvidossãocompatíveiscomonívelde
desempenhodosoftware.
Suassub-característicassão:
ComportamentoemRelaçãoaoTempoqueavaliaseostemposderesposta(ou
deprocessamento)estãodentrodasespecificações;
UtilizaçãodeRecursosquemedetantoosrecursosconsumidosquantoa
capacidadedosistemaemutilizarosrecursosdisponíveis;
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 37
Manutenibilidade Acapacidade(oufacilidade)doprodutodesoftwaresermodificado,incluindo
tantoasmelhoriasouextensõesdefuncionalidadequantoascorreçõesdedefeitos,
falhasouerros.
Suassub-característicassão:
Analisabilidadeidentificaafacilidadeemsediagnosticareventuaisproblemase
identificarascausasdasdeficiênciasoufalhas;
Modificabilidadecaracterizaafacilidadecomqueocomportamentodosoftware
podesermodificado;
Estabilidadeavaliaacapacidadedosoftwaredeevitarefeitoscolaterais
decorrentesdemodificaçõesintroduzidas;
Testabilidaderepresentaacapacidadedesetestarosistemamodificado,tanto
quantoasnovasfuncionalidadesquantoasnãoafetadasdiretamentepela
modificação;
Portabilidade
Acapacidadedosistemasertransferidodeumambienteparaoutro.
Como"ambiente",devemosconsiderartodoosfatoresdeadaptação,taiscomo
diferentescondiçõesdeinfra-estrutura(sistemasoperacionais,versõesdebancos
dedados,etc.),diferentestiposerecursosdehardware(talcomoaproveitarum
númeromaiordeprocessadoresoumemória).Alémdestes,fatorescomoidioma
ouafacilidadeparasecriarambientesdetestesdevemserconsideradoscomo
característicasdeportabilidade.
Suassub-característicassão:
Adaptabilidade,representandoacapacidadedosoftwareseadaptaradiferentes
ambientessemanecessidadedeaçõesadicionais(configurações);
CapacidadeparaserInstaladoidentificaafacilidadecomquepodeseinstalaro
sistemaemumnovoambiente;
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 38
Coexistênciamedeoquãofacilmenteumsoftwareconvivecomoutrosinstalados
nomesmoambiente;
CapacidadeparaSubstituirrepresentaacapacidadequeosistematemde
substituiroutrosistemaespecificado,emumcontextodeusoeambiente
específicos.Esteatributointeragetantocomadaptabilidadequantocoma
capacidadeparaserinstalado;
Resposta do Exercício de Requisitos do Usuário QuaissãoosFatoresCríticosdeSucessodaIndústria?
AnálisedaIndústriaeseusFatoresCríticosdeSucesso
Qualéoclientetipo?
Porqueocliente(indústriadeplásticos)querestesoftware?
Oqueoéimportanteparaoclientequesolicitouosoftwareeseucliente?
Umaindústriadeplásticosvivedeclientesquesãooutrasempresasquecompram
lotesdeseusprodutos.Paraseatenderoutrasempresas,oscompradoresdelas
devemterumaáreaderecepção,visitaàfábrica,eelesdesejamtergarantiase
previsibilidadeemsuastransações,logopossuircertificaçõescomoISO9000são
fundamentaisparaganharseuscontratos.
Paraqueestesoftwarepossaatenderdeformamaiseficazaindústria,elepoderá
atenderàestasnormas,bemcomoseguirasleistrabalhistas.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 39
Característicasessenciaisdosoftware
Tercomunicaçãocomoutrossoftwares,portanto,geraçãodearquivosde
comunicaçãocomoXML;
Guardarhistóricodemovimentaçãopor5anosparaatendimentodasleis;
Informarpormeiodeavisossonorosouvisuaisaofuncionáriodeerrosdeleitura,
deatrasos,prevendocompensaçõescasodeseje,fechamentoautomáticodo
horárioporturno,aindaqueofuncionárionãoofaça(casodepesquecimento)e
informa-lonopontoseguinte,gerargráficosgerenciaisporturma,turno,
funcionário,médiasemediasponderadas.
OsoftwareserádesenvolvidoemPHPcomOrientaçãoàObjetoedocumentação
porfunçãoalémdadocumentaçãogeral,istofacilitaamanutençãodosoftwareem
casodeerro,porfacilitaradetecção.Osoftwareficaráhospedadoemnossos
servidoresparaqueemcasodequeda,falhaouinconformidadededadososerviço
possaserrapidamente.Otempomédioderespostaparareestabelecerumservidor
éde1h30.
Onúmerodediasdeusosemfalhaséde33dias.ProteçãoeSegurança.
Eficiência,ousodoAJAXproporcionaráotráfegodeapenasosdadostextuais,sem
anecessidadedecarregamentocompletodapágina,diminuindootempopara
obtençãodosdados.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 40
Usabilidade,todainterfacegráficadeveráatenderaospadrõesdeusabilidadecom
itensdispostossemprenasmesmasposiçõeseevidenciandoaintuitividade,além
dousodedesignflat.
Alta-Coesão–Osobjetosnaprogramaçãoserãodesenvolvidosdeformaquetodos
osaspectosfuncionaisestejamdisponíveisnasprópriasclasses,facilitandoa
manutençãoemcasodefalhasporrestringirospontosdeanálise.
IndependênciaFuncional–Aindaquepartedosoftwarenãofuncione
adequadamente,comosobrecargadoBancodeDados,interrupçãodoserviçoPHP
ououtroimpacto,todasaspartesfuncionarãocomavisosaousuárioqueosistema
estádeficienteenãopoderácontinuaretentarágerarumerroembancodedados
eavisarodesenvolvedor.
Baixoacoplamento–todasasclassesdependentesterãogatilhosdeverificaçãodo
plenofuncionamentodosistema,comavisosaousuárioemcasodefalha.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
� 41
Bibliografia ASSOCIAÇÃOBRASILEIRADENORMASTÉCNICAS.NBRISO/IEC9126-1Engenhariade
software-Qualidadedeproduto-Parte1:Modelodequalidade.2003.
Bartie,AlexandreGarantiadaQualidadedeSoftwareRiodeJaneiro:Elsevier,2003
IEEE.SWEBoK:GuidetotheSoftwareEngineeringBodyofKnowledge3.0.Pierre
Bourque,Écoledetechnologiesupérieure(ÉTS),RichardE.(Dick)Fairley,Software
andSystemsEngineeringAssociates(S2EA).IEEEComputerSociety.
SOMMERVILLE,Ian.EngenhariadeSoftware,8ªedição.PearsonAddison-Wesley,
SãoPaulo,2007.
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br