Escolar Documentos
Profissional Documentos
Cultura Documentos
1.2 - Modelos de Processo Prescritivo
1.2 - Modelos de Processo Prescritivo
PRESCRITIVO
PROF. RAUL SIDNEI WAZLAWICK
UFSC-CTC-INE
2010
MODELOS DE PROCESSO
Processos so construdos de acordo com modelos
ou estilos, que quando aplicados ao
desenvolvimento de software so conhecidos como
ciclos de vida.
Pode-se afirmar que existem duas grandes
famlias de modelos: os prescritivos e os geis.
Quo
Passos:
1.
2.
3.
4.
5.
SEM PREVISIBILIDADE
Pode-se dizer que uma forma bastante ingnua
de modelo de processo.
Pode-se dizer tambm que nem sequer parece ser
um processo, pois no h previsibilidade em
relao s atividades e resultados obtidos.
O modelo usado porque simples, no porque
funciona bem.
Muitos projetos reais, mesmo dirigidos por outros
modelos de ciclo de vida, por vezes caem na
prtica de codificar e testar em funo de presso
de cronograma.
ONDE USADO
Empresas que no usam modelo de processo
algum possivelmente usam Codificar e Consertar
por default.
O modelo Codificar e Consertar , possivelmente,
bastante usado em empresas de pequeno porte,
mas deve ser entendido mais como uma maneira
de pressionar programadores (code rush) do que
como um processo organizado (McConnell, 1996).
Se o sistema no satisfaz o cliente, cobra-se do
programador uma verso funcional adequada no
menor tempo possvel.
VANTAGENS
No se perde tempo com documentao,
planejamento ou projeto: vai-se direto
codificao.
O progresso facilmente visvel medida que o
programa vai ficando pronto.
No h necessidade de conhecimentos ou
treinamento especiais. Qualquer pessoa que
programe pode desenvolver software com este
modelo de ciclo de vida.
DESVANTAGENS
Um dos problemas com esta tcnica que o
cdigo que sofreu vrias correes fica cada vez
mais difcil de modificar.
Alm disso, com bastante freqncia o que o
cliente menos precisa de cdigo ruim produzido
rapidamente, ele precisa ter certas necessidades
atendidas.
Essas necessidades so levantadas na fase de
requisitos, que se for feita s pressas, deixar de
atingir estes objetivos.
OUTRAS DESVANTAGENS
difcil avaliar o progresso at que o programa
esteja funcionando.
muito difcil avaliar a qualidade e os riscos do
projeto.
Se no meio do projeto a equipe descobrir que
decises arquiteturais estavam erradas, no h
soluo a no ser comear tudo de novo.
Codificar e consertar sem um plano de teste
sistemtico tende a produzir sistemas instveis e
com grande probabilidade de conterem erros.
CASCATA (WATERFALL)
O modelo Cascata (Waterfall ou WFM) vem dos
anos 1970 e apresenta um ciclo de
desenvolvimento bem mais detalhado e previsvel
do que o modelo Codificar e Testar.
Cascata considerado o av de todos os ciclos de
vida.
O modelo baseia-se na filosofia BDUF (Big
Design Up Front), que prope que antes de
produzir linhas de cdigo deve-se fazer um
trabalho detalhado de anlise e projeto, de forma
que quando o cdigo for efetivamente produzido
esteja o mais prximo possvel dos requisitos do
cliente.
REVISO E DOCUMENTAO
O modelo prev uma atividade de reviso ao final
de cada fase para que se avalie se o projeto pode
seguir para a fase seguinte.
Se a reviso mostrar que o projeto no est
pronto para seguir para a fase seguinte, ento ele
deve permanecer na mesma fase (Ellis, 2010).
O modelo Cascata dirigido por documentao, j
que ela que determina se as fases foram
concludas ou no.
BENEFCIOS
MODELO WATERFALL
ORIGINAL (ROYCE, 1970)
Implementao arriscada: apenas
na fase de teste vrios aspectos
do sistema seriam pela primeira
vez experimentados da prtica.
Desta forma, aps a fase de teste,
muito retrabalho necessrio
para alterar os requisitos e a
partir deles todo o projeto.
(Royce)
VARIAO CASCATA
DUPLA
Poderia ser desta forma, mas na
prtica no assim (Royce).
O QUE ACABA
ACONTECENDO NA
PRTICA
VARIAES
O modelo Cascata, na sua forma mais simples
impraticvel.
Algumas variaes foram ento propostas ao
longo do tempo para permitir a aplicao deste
tipo de ciclo de vida em processos de
desenvolvimento de software.
Essas variaes so apresentadas a seguir.
SASHIMI
SCRUM
A idia do modelo Sashimi de que cada fase se
entrelaa apenas com a anterior e a posterior,
entretanto, vai contra a observao de Royce.
Em funo disso, uma das evolues de Sashimi
mais importantes o modelo SCRUM, que
consiste em levar a idia de fases entrelaadas ao
extremo pela reduo do processo a uma nica
fase na qual todas as fases do modelo Cascata so
realizadas paralelamente por profissionais
especializados trabalhando em equipe.
VANTAGENS
O modelo Sashimi tem o mrito de indicar que,
por exemplo, a fase de anlise de requisitos s
estar completa depois que o projeto da
arquitetura tiver terminado, e assim por diante.
Este estilo de processo adequado se o
engenheiro de software avaliar que poder obter
ganhos de conhecimento sobre o sistema ao
passar de uma fase para outra.
O modelo tambm prov uma substancial
reduo na quantidade de documentao, pois as
equipes das diferentes fases trabalharo juntas
boa parte do tempo.
DESVANTAGENS
Entre os problemas do modelo est o fato de que
fica mais difcil definir marcos (millestones), pois
no fica muito claro quando exatamente uma fase
termina.
Alm disso, a realizao de atividades paralelas
com este modelo pode levar a falhas de
comunicao, aceitao de hipteses erradas e
ineficincia no trabalho.
CASCATA COM
SUBPROJETOS
VANTAGENS
Este modelo bem mais razovel de utilizar do
que o modelo Cascata puro, visto que o fato de
quebrar o sistema em subsistemas menores
permite que subprojetos mais rpidos e fceis de
gerenciar sejam realizados.
Esta tcnica explora melhor as potencialidades de
modularidade do projeto.
Com ela, o progresso mais facilmente visvel,
porque pode-se produzir vrias entregas de
partes funcionais do sistema a medida que ficam
prontas.
DESVANTAGENS
A maior dificuldade com este modelo est na
possibilidade de surgirem interdependncias
imprevistas entre os subsistemas.
O projeto arquitetnico deve ser bem feito de
forma a minimizar tais problemas.
Alm disso, este modelo exige maior capacidade
de gerncia para impedir que sejam criadas
inconsistncias entre os subsistemas.
CASCATA COM
REDUO DE RISCO
DISCUSSO
A espiral de reduo de riscos no precisa ficar
restrita aos requisitos do projeto, ela pode ser
aplicada a quaisquer outros riscos identificados.
Este tipo e modelo adequado a projetos com um
grande nmero de riscos importantes.
A espiral de reduo de riscos uma forma de a
equipe garantir alguma estabilidade ao projeto
antes de comprometer um grande nmero de
recursos na sua execuo.
MODELO V (V MODEL)
uma variao do modelo Cascata que prev
uma fase de validao e verificao para cada
fase de construo.
O Modelo V pode ser usado com projetos que
tenham requisitos estveis e dentro de um
domnio conhecido (Lenz & Moeller, 2004).
O Modelo V seqencial e, como o modelo
Cascata, dirigido por documentao.
MODELO V
FASES CONSTRUTIVAS
FASES DE VERIFICAO
VANTAGENS
A principal caracterstica do Modelo V est na
sua nfase nos testes e validaes simtricos ao
projeto.
Essas etapas, porm, podem ser incorporadas a
outros modelos de processo.
DESVANTAGENS
Os pontos negativos deste modelo so os mesmos
do modelo Cascata puro, entre eles o fato de que
mudanas nos requisitos provocam muito
retrabalho.
Alem disso, em muitos casos, os documentos
produzidos no lado esquerdo do V so ambguos e
imprecisos, impedindo ou dificultando os testes
necessrios representados no lado direito do V.
MODELO W
Spillner (2002) apresenta uma variao ao
Modelo V ainda mais voltada a rea de teste, o
Modelo W.
A principal motivao a esta variao est na
observao de que h uma diviso muito estrita
entre as atividades construtivas do lado esquerdo
do V e as atividades de teste no lado direito.
Spillner prope que o planejamento dos testes
inicie durante a fase construtiva, mesmo sendo
executado depois e que o lado direito do V no
seja considerado apenas como um conjunto de
atividades de testes, mas tambm de
reconstruo.
MODELO W
ESPIRAL (SPIRAL)
O modelo Espiral (Spiral) foi originalmente
proposto por Boehm (1986) e fortemente
orientado reduo de riscos.
A proposta de Boehm no foi a primeira a
apresentar a idia de ciclos iterativos, mas foi a
primeira a realmente explicar porque as iteraes
eram necessrias.
O projeto dividido em subprojetos, cada um dos
quais aborda um ou mais elementos de alto risco,
at que todos os riscos identificados tenham sido
tratados.
ESPIRAL
ESPIRAL
VANTAGENS
DESVANTAGENS
O modelo no prov a equipe com indicaes
claras sobre a quantidade de trabalho esperada a
cada ciclo, o que pode tornar o tempo de
desenvolvimento nas primeiras fases bastante
imprevisvel.
Alm disso, o movimento complexo entre as
diferentes fases ao longo das vrias iteraes da
espiral exige uma gerncia complexa e eficiente.
APLICAO
Esse ciclo de vida se adqua bem a projetos
complexos com alto risco e requisitos pouco
conhecidos como, por exemplo, projetos de
pesquisa e desenvolvimento (P&D).
Segundo Schell (2008), o modelo Espiral
bastante adequado a rea de jogos eletrnicos,
onde os requisitos usualmente no so conhecidos
sem que prottipos tenham sido testados, e onde
os riscos se apresentam altos tanto do ponto de
vista tecnolgico quanto do ponto de vista da
usabilidade do sistema.
PROTOTIPAO EVOLUCIONRIA
(EVOLUTIONARY PROTOTYPING)
PROTOTIPAO EVOLUCIONRIA
VANTAGENS
DESVANTAGENS
ENTREGAS EM ESTGIOS
uma variao mais bem estruturada do modelo
Prototipao Evolucionria embora tambm seja
considerado uma variao do modelo Cascata.
Ao contrrio da prototipao Evolucionria, o
modelo Entregas em Estgios prev que a cada
ciclo a equipe planeje e saiba exatamente o que
vai entregar ao cliente.
A abordagem interessante porque haver vrios
pontos de entrega e o cliente poder acompanhar
mais diretamente a evoluo do sistema.
No existe, portanto, o problema do modelo
Cascata, onde o sistema s entregue quando
est totalmente acabado.
ENTREGA EM ESTGIOS
VANTAGENS
Uma das principais vantagens deste modelo
(Ellis, 2010) o fato de colocar funcionalidades
teis nas mos do cliente antes de completar todo
o projeto.
Se os estgios forem planejados cuidadosamente,
funcionalidades importantes estaro disponveis
muito mais cedo do que com outros ciclos de vida.
Alm disso, este modelo prov entregas mais cedo
e de forma contnua, o que pode aliviar um pouco
a presso de cronograma colocada na equipe.
DISCUSSO
Este modelo uma boa estratgia para garantir
que haver algum produto disponvel em uma
determinada data, se isso for absolutamente
imprescindvel.
Porm, se a equipe altamente confiante na sua
capacidade de previso de esforo (cumpre prazos
constantemente), essa abordagem no
recomendada.
Uma das desvantagens deste modelo que, caso
nem todas as funcionalidades sejam entregues a
equipe ter perdido tempo fazendo a anlise
delas nas etapas iniciais.
ENTREGA EVOLUCIONRIA
(EVOLUTIONARY DELIVERY)
ENTREGA EVOLUCIONRIA
Este modelo permite ento ajustes que lhe do
um pouco da flexibilidade do modelo de
Prototipao Evolucionria ao mesmo tempo em
que se tem o planejamento da Entrega em
Estgios.
As diferenas entre este modelo e os anteriores
ento est mais na nfase do que nas atividades
relacionadas.
No modelo de Prototipao Evolucionria a
nfase est nos aspectos visveis do sistema.
Na Entrega Evolucionria, porm, a nfase est
nas funcionalidades mais crticas do sistema.
BIBLIOGRAFIA
Alvim, P. (2008). Tirando o Mximo do Java EE 5 Open-Source com jCompany Developer Suite.
Powerlogic Publishing: Belo Horizonte.
Boehm, B. (1986). A Spiral Model for Software Development and Enhancement. ACM SIGSOFT
Software Engineering Notes 11(4):14-24. August.
DeGrace, P., Stahl, L. H. (1990). Wicked Problems, Righteous Solutions: A catalog of modern
engineering paradigms. Prentice-Hall.
Ellis, R. (2010). Project Management: Project lifecycle planning. Lecture Notes. University of the
West Indies. Disponvel em:
http://www.eng.uwi.tt/depts/civil/pgrad/proj_mgmt/courses/prmg6009/Notes%20PDF/04_L3.pdf.
Acessado em: 06/03/2010.
Lenz, G., Moeller, T. (2004). .NET: A complete development cycle. Pearson Education Inc.
Visualizao parcial disponvel em:
http://books.google.com.br/books?id=64XC28ZMhdEC&printsec=frontcover#v=onepage&q=&f=false
. Acessado em 06/03/2010.
McConnell, S. (1996). Rapid Development. Redmond, Washington: Microsoft Press. Acessvel online
em: http://my.safaribooksonline.com/9780735634725.
Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE
WESCON 26 (August):1-9. Disponvel em
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf. Consultado em
06/03/2010.
Spillner, A. (2002). The W Model: Strengthening the bond between development and test.
STAReast Conference, May 2002, Orlando, USA. Disponvel em:
http://www.stickyminds.com/getfile.asp?ot=XML&id=3572&fn=XDD3572filelistfilename1%2Epdf.
Consultado em: 06/03/2002.