Trab2

Transcript

2.1 Justificando sua resposta com base no tipo de sistema a ser desenvolvido, sugira o modelo genérico de processo de software mais adequado para ser usado como base para a gerência do desenvolvimento dos sistemas a seguir: Um sistema para controlar o antibloqueio de frenagem de um carro. Por ser um sistema de segurana cr!tico que e"ige in#meras an$lises antes de sua implementa%o o sistema em cascata seria o ideal. Um sistema de realidade virtual para dar apoio & manuten%o de software. Por se tratar de um sistema rico em interfaces visuais e com c'ances de possuir in#meras mudanas de requerimento um sistema incremental pode ser usado com prototipa%o das interfaces gr$ficas, um processo de desenvolvimento $gil também pode ser usado. Um sistema de contabilidade para uma universidade, que substitua um sistema ($ e"istente. )ste é um sistema com os requisitos fracamente con'ecidos, como ($ e"istem outros sistemas que possivelmente se enquadrem neste tipo de sistema uma abordagem baseada em reuso pode ser aplicada. Um sistema interativo de plane(amento de viagens que a(ude os usu$rios a plane(ar viagens com menor impacto ambiental. Um sistema com interface de usu$rio comple"a que precisa ser est$vel e #til. Uma abordagem incremental é a mais apropriada conforme os requerimentos de sistema mudam conforme o usu$rio gan'a e"periência. 2.2 2.2 )"pl )"pliq ique ue por por que que o dese desenv nvol olvi vime ment nto o incr increm emen enta tall é o méto método do mais mais efic efica* a* para para o desenvolvimento de sistemas de software de neg+cios. Por que esse modelo é menos adequado para a engen'aria de sistemas de tempo real Porque em software de neg+cios dificilmente a equipe de desenvolvimento ir$ possuir o dominio completo do problema a ser solucionado, o que e"ige uma abordagem incremental, em sistemas de tempo real geralmente os requisitos s%o bem con'ecidos e '$ um foco maior em segurana o que e"ig e"igee maio maiorr e"at e"atid id%o %o no dese desenv nvol olvi vime ment nto, o, n%o n%o pode podend ndo o 'ave 'averr fal' fal'as as,, porta portant nto o o mode modelo lo incremental n%o seria nada ideial para este tipo de sistema. 2.- onsidere o modelo de processo baseado em re#so da /igura 2.-. )"plique por que, nesse processo, é essencial ter duas atividades distintas de engen'aria de requisitos. )m um modelo de processo baseado em reuso você precisa de duas atividades porque é essencial adaptar os requerimentos requerimentos de sistema de acordo com com as capacidades capacidades do sistema0componente sistema0componente a ser reutili*ado. )stas atividades s%o: 1. Uma atividade inicial onde você compreende a fun%o do sistema e seus requerimentos. )stes devem ser e"pressos com detal'es suficientes para que possam ser usados como base para o sistema0componente sistema0componente que satisfa*em os requerimentos e podem ser reusados. 2. uando uando os sistem sistemas0 as0com compon ponen entes tes forem forem seleci seleciona onados dos,, você você precis precisaa que os requis requisito itoss de engen' engen'ari ariaa se(am se(am mais mais detal' detal'ado adoss para para c'eca c'ecarr se estas estas carac caracter terist istica icass do softwa software re reusa reusado do satisfa*em as necessidades do neg+cio e para identificar mudanas e adies que se(am necess$rias. 2.3 4ugira por que é importante, no processo de engen'aria de requisitos, fa*er uma distin%o entre desenvolvimento dos requisitos do usu$rio e desenvolvimento de requisitos de sistema. Porque os requisitos do usu$rio s%o requisitos fracos, generalistas, que descrevem o que o sistema se propes a fa*er, enquanto os requisitos de sistema envolvem mais a parte técnica e de arquitetura 5como o sistema ir$ fa*er6 sendo portanto requisitos fortes que envolvem um n!vel de descri%o pr+prio para a equipe de desenvolvimento e longe da linguagem leiga do usu$rio. 2.7 8escreva as principais atividades do processo de pro(eto de software e as sa!das dessas atividades. Usando um diagrama, mostre as poss!veis relaes entre as sa!das dessas atividades. 2.9 )"plique por que, em sistemas comple"os, as mudanas s%o inevit$veis. )"emplifique as atividades de processo de software que a(udam a prever as mudanas e fa*er com que o software se(a desenvolvido mais tolerante a mudanas 5desconsidere prototipa%o e entrega incremental6. s sistemas devem mudar porque s%o instalados em um ambiente que se adapta e naturalmente gera novos0diferentes requerimentos de sistema, um e"emplo seria a refatora%o de c+digo que mel'ora a qualidade do c+digo e o torna mais ameno a mudanas. 2.; )"plique por que os sistemas desenvolvidos como prot+tipos normalmente n%o devem ser usados como sistemas de produ%o. s prot+tipos remetem naturalmente a e"perimenta%o, e nada que se(a e"perimental deve ser tomado como produto final (ustamente por serem incompletos e muito poss!velmente conten'am fal'as de v$rios tipos, estruturais, de concep%o e afins. 2.< )"plique por que o modelo em espiral de =oe'm é um modelo adapt$vel, que apoia tanto as atividades de preven%o de mudanas quanto as de toler>ncia a mudanas. ?a pr$tica, esse modelo n%o tem sido amplamente usado. 4ugira as poss!veis ra*es para isso.  modelo em espiral repete suas fases até que o produto final se(a aceit$vel, talve* n%o se(a amplamente usado por questes de incompreens%o da usabilidade do modelo. ada volta na espiral representa uma fase do processo de software. 8essa forma, a volta mais interna pode preocupar@se com a viabilidade do sistemaA o ciclo seguinte, com defini%o de requisitosA o seguinte, com o pro(eto do sistema, e assim por diante.  modelo em espiral combina preven%o e toler>ncia a mudanas, assume que mudanas s%o um resultado de riscos de pro(eto e inclui atividades e"pl!citas de gerenciamento de riscos para sua redu%o. 2.B uais s%o as vantagens de proporcionar vises est$ticas e din>micas do processo de software, assim como no Cational Unified Process D vantagem de proporcionar vises est$ticas e din>micas é que as fases do processo de desenvolvimento n%o est%o associadas a worEflows espec!ficos. Do menos em princ!pio, todos os worEflows do CUP podem estar ativos em todas as fases do processo. ?as fases iniciais, provavelmente, maiores esforos ser%o empen'ados em worEflows, como modelagem de neg+cios e requisitos, e, nas fases posteriores, no teste e na implanta%o.