MODELOS DE PROCESSO MODELOS DE PROCESSO

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 Pode-se afirmar que existem duas grandes
famlias de modelos: os prescritivos e os geis.
NO EXISTE UM MODELO MELHOR QUE
TODOS OS OUTROS
Projetos diferentes tem diferentes necessidades.
O engenheiro de software deve escolher aquele
mais adequado sua equipe e ao projeto que vai
desenvolver.
Se ele escolher bem, ter um processo eficiente, Se ele escolher bem, ter um processo eficiente,
baseado em padres e lies aprendidas e com
possibilidade de capitalizar experincias.
O controle ser eficiente e os riscos, erros e
retrabalho sero minimizados.
Mas se escolher mal poder estar gerando
trabalho repetitivo e frustrante para a equipe, o
que alis, pode acontecer tambm quando no se
escolhe ciclo de vida algum.
SEGUNDO ELLIS (2010), PARA ESCOLHER UM MODELO
DE CICLO DE VIDA O ENGENHEIRO DE SOFTWARE
DEVE RESPONDER S SEGUINTES PERGUNTAS:
Quo bem os analistas e o cliente podem
conhecer os requisitos do sistema?
O entendimento sobre o sistema poder a
mudar a medida que o desenvolvimento
avanar?
Quo bem compreendida a arquitetura
do sistema?
provvel que sejam feitas grandes
mudanas de rumo ao longo do projeto?
SEGUNDO ELLIS (2010), PARA ESCOLHER UM MODELO
DE CICLO DE VIDA O ENGENHEIRO DE SOFTWARE
DEVE RESPONDER S SEGUINTES PERGUNTAS:
Qual o grau de confiabilidade necessrio em
relao ao cronograma?
Quanto planejamento efetivamente necessrio?
Qual o grau de risco que este projeto apresenta?
Existe alguma restrio de cronograma? Existe alguma restrio de cronograma?
Ser necessrio entregar partes do sistema
funcionando antes de terminar o projeto todo?
Qual o grau de treinamento e adaptao
necessrios para a equipe poder utilizar o ciclo de
vida que parece mais adequado ao projeto?
Em funo das respostas um dos ciclos seguintes
poder ser escolhido.
CODIFICAR E CONSERTAR (CODE AND FIX)
Passos:
1. Construa junto com o cliente um entendimento
preliminar sobre o sistema que deve ser
desenvolvido.
2. Implemente uma primeira verso deste sistema.
3. Interaja com o cliente de forma a corrigir a verso
preliminar at que esta satisfaa ao cliente.
4. Faa testes e corrija os inevitveis erros.
5. Entregue o produto.
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. 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, 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. 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 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 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 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 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
A existncia de fases bem definidas ajuda a detectar erros
cedo e desta forma mais barato corrigi-los.
Procura promover a estabilidade dos requisitos. S se move
quando os requisitos so aceitos.
Funciona bem com projetos onde os requisitos so bem
conhecidos e estveis, j que este tipo de projeto se conhecidos e estveis, j que este tipo de projeto se
beneficia de uma abordagem organizada e sistemtica.
Funciona bem quando a preocupao com qualidade est
acima das preocupaes com custo ou tempo de
desenvolvimento, visto que a eliminao de mudanas ao
longo do curso minimiza uma conhecida fonte de erros.
adequado para equipes tecnicamente fracas ou
inexperientes, pois d estrutura ao projeto, servindo de
guia e evitando o esforo intil.
PROBLEMAS (ELLIS, 2010)
No produz resultados tangveis at a fase de codificao,
exceto para as pessoas familiarizadas com as tcnicas de
documentao, que podero ver significado nos documentos.
difcil estabelecer requisitos completos antes de comear
a codificar.
Desenvolvedores sempre reclamam que os usurios no Desenvolvedores sempre reclamam que os usurios no
sabem expressar o que precisam. Os usurio no so
especialistas em computao ento no mencionam muitas
vezes os problemas mais bvios, que s aparecero quando
o produto estiver em operao.
No h flexibilidade com requisitos. Voltar atrs para
corrigir requisitos mal estabelecidos ou que mudaram
bastante trabalhoso.
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 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
PROPOSTAS DE ROYCE PARA MELHORAR O
MODELO
Inserir uma fase de projeto entre o levantamento
dos requisitos e sua anlise. Se projetistas que
conheam as limitaes de sistemas
computacionais puderem verificar os requisitos
antes dos analistas iniciarem seus trabalhos, eles antes dos analistas iniciarem seus trabalhos, eles
podero adicionar preciosos requisitos
suplementares referentes s limitaes fsicas do
sistema.
Produzir documentao. Nas fases iniciais a
documentao o produto esperado e deve ser
feita com a mesma qualidade com que se procura
fazer o produto.
PROPOSTAS DE ROYCE PARA MELHORAR O
MODELO
Fazer duas vezes. Sugere-se que o produto
efetivamente entregue ao cliente seja a segunda
verso produzida. Ou seja, executa-se as fases do
ciclo Cascata duas vezes, usando o conhecimento
aprendido da primeira rodada para produzir um aprendido da primeira rodada para produzir um
produto muito melhor na segunda vez.
Planejar, controlar e monitorar o teste. Testes
devem ser sistemticos e realizados por
especialistas, j que so crticos para o sucesso do
sistema.
Envolver o cliente. importante envolver o
cliente formalmente no processo e no apenas na
aceitao do produto final.
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 tipo de ciclo de vida em processos de
desenvolvimento de software.
Essas variaes so apresentadas a seguir.
CASCATA ENTRELAADO (SASHIMI)
O modelo conhecido como Sashimi (DeGrace,
1990), ou Cascata Entrelaado (Overlapped
Waterfall), uma tentativa de atenuar a
caracterstica BDUF do modelo Cascata.
Ao invs de cada fase produzir documentao Ao invs de cada fase produzir documentao
completa para a fase seguinte, o modelo Sashimi
prope que cada fase procure iniciar o tratamento
de questes da fase seguinte e continue tratando
as questes da fase anterior.
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 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 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 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 (WATERFALL
WITH SUBPROJECTS)
Permite que algumas fases do modelo Cascata
sejam executadas em paralelo.
Aps a fase de projeto da arquitetura, o projeto
pode ser subdividido de forma que vrios
subsistemas sejam desenvolvidos em paralelo por subsistemas sejam desenvolvidos em paralelo por
equipes diferentes, ou pela mesma equipe em
momentos diferentes.
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. 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. 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
(WATERFALL WITH RISK REDUCTION)
Procura resolver um dos principais problemas do
BDUF que a dificuldade em se ter uma boa
definio dos requisitos do projeto nas fases
iniciais.
Este modelo basicamente acrescenta uma fase de Este modelo basicamente acrescenta uma fase de
reduo de riscos antes do incio do processo em
cascata.
O objetivo do modelo a reduo do risco com os
requisitos.
A tnica a utilizao de tcnicas que garantam
que os requisitos sero os mais estveis possveis.
TCNICAS USADAS DURANTE A FASE
ESPIRAL
Desenvolver prottipos de interface com o
usurio.
Desenvolver storyboards com o usurio.
Conduzir vrios ciclos de entrevistas com o
usurio e cliente. usurio e cliente.
Filmar os usurios utilizando os sistemas
antigos, sejam eles informatizados ou no.
Utilizar extensamente quaisquer outras prticas
de eliciao de requisitos.
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. 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 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
Fase de requisitos: a equipe elabora o documento de requisitos.
Uma estimativa de esforo deve ser produzida nesta fase tambm.
Fase de projeto arquitetural: a equipe organiza os requisitos em
unidades funcionais coesas, define como as diferentes partes
arquiteturais do sistema vo se interconectar e colaborar.
Nesta fase deve ser produzido um documento de especificao
funcional do sistema, e as estimativas de esforo podem ser funcional do sistema, e as estimativas de esforo podem ser
revistas.
Fase de projeto detalhado: a equipe vai aprofundar a descrio das
partes do sistema e tomar decises sobre como sero
implementadas.
Esta fase produz o documento de especificao detalhado dos
componentes do software.
Na fase de implementao o software implementado de acordo
com a especificao detalhada.
FASES DE VERIFICAO
Fase de teste de unidade: tem como objetivo
verificar se todas as unidades se comportam como
especificado na fase de projeto detalhado.
O processo s segue em frente se todas s unidades
passam em todos os testes. passam em todos os testes.
Fase de teste de integrao: tem como objetivo
verificar se o sistema se comporta conforme a
especificao do projeto arquitetural.
Fase de teste de sistema: verifica se o sistema
satisfaz os requisitos especificados.
Se o sistema passar nestes testes estar pronto para
ser entregue ao cliente.
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. 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 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 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 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
A idia deste ciclo iniciar com mini projetos, abordando os
principais riscos e expandir este projeto atravs da
construo de prottipos, testes e replanejamento de forma
a abarcar os principais riscos identificados.
Aps a equipe ter adquirido um conhecimento mais
completo dos potenciais problemas com o sistema, ela passa completo dos potenciais problemas com o sistema, ela passa
a desenvolver um ciclo final semelhante ao modelo
Waterfall.
No incio do processo espera-se que a equipe explore os
riscos, construa um plano para gerenciar os riscos e planeje
e concorde com uma abordagem para o prximo ciclo.
Cada iterao faz o projeto avanar um nvel em
entendimento e mitigao de riscos.
PASSOS DAS ITERAES
Determinar inicialmente os objetivos, alternativas e
restries relacionadas fase que vai se iniciar.
Identificar e resolver riscos relacionados fase em
andamento.
Avaliar as alternativas disponveis. Tipicamente podem ser
utilizados prottipos nesta fase para verificar a viabilidade utilizados prottipos nesta fase para verificar a viabilidade
de diferentes alternativas.
Desenvolver os artefatos (possivelmente entregas)
relacionados a esta fase e certificar que esto corretos.
Planejar a prxima iterao.
Obter concordncia em relao abordagem para a
prxima iterao, caso se resolva realizar uma.
VANTAGENS
As primeiras iteraes so as mais baratas do ponto de
vista de investimento de tempo e recursos e ao mesmo
tempo so as que resolvem os maiores problemas do
projeto.
A escolha dos riscos a serem mitigados feita em funo
das necessidades de projeto. das necessidades de projeto.
Assim, a medida que os custos aumentam, o risco diminui,
o que altamente desejvel em projetos de envergadura.
Se o projeto no puder ser concludo por razes tcnicas,
isso ser descoberto cedo.
Alm disso, o modelo possui fases bem definidas, o que
permite o acompanhamento objetivo do desenvolvimento.
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. 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 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)
O modelo de Prototipao Evolucionria (Brooks,
1975) sugere que a equipe de desenvolvimento
trabalhe junto ao cliente os aspectos mais visveis
do sistema, na forma de prottipos (usualmente
de interface), at que o produto seja aceitvel. de interface), at que o produto seja aceitvel.
PROTOTIPAO EVOLUCIONRIA
VANTAGENS
Este modelo pode ser particularmente
interessante se for difcil fazer o cliente entender
os requisitos.
Neste caso, um prottipo do sistema ser uma
ferramenta mais fcil para o analista se comunicar ferramenta mais fcil para o analista se comunicar
com o cliente e chegar a um acordo sobre o que deve
ser desenvolvido.
Este modelo tambm pode ser interessante
quando tanto a equipe quanto o cliente no
conhecem bem os requisitos do sistema.
Pode ser difcil elaborar requisitos quando no se
sabe exatamente o que necessrio, sem ver o
software funcionando e testando o mesmo.
DESVANTAGENS
O modelo no muito bom em relao previso de tempo
para desenvolvimento e tambm em relao gerncia do
processo, j que difcil avaliar quando cada fase foi
efetivamente realizada.
Pode at acabar acontecendo que o modelo se torne mais
uma desculpa para usar Codificar e Consertar do que uma desculpa para usar Codificar e Consertar do que
efetivamente seguir um ciclo de vida bem definido.
Para evitar isso deve-se garantir que o processo
efetivamente obtenha uma concepo real do sistema, com
requisitos definidos da melhor forma possvel, e com um
projeto realista antes de iniciar a codificao propriamente
dita.
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 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, 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.
NECESSRIO PLANEJAR EM DOIS NVEIS
Tcnico: as dependncias tcnicas entre os
diferentes mdulos entregveis devem ser
cuidadosamente verificadas. Se um mdulo tem
dependncias com outro, o segundo deve ser
entregue antes deste. entregue antes deste.
Gerencial: deve-se procurar garantir que os
mdulos sejam efetivamente significativos para o
cliente. Ser menos til entregar funcionalidades
parciais que no possam produzir nenhum
trabalho consistente.
MODELO ORIENTADO A CRONOGRAMA
(DESIGN TO SCHEDULE)
similar ao modelo Entregas em Estgios, exceto
pelo fato de que ao contrrio deste ltimo, no se
sabe a priori quais funcionalidades sero
entregues a cada ciclo.
Prev que os ciclos terminaro em determinada Prev que os ciclos terminaro em determinada
data e as funcionalidades implementadas at ali
sero entregues.
importante priorizar, portanto, as
funcionalidades, de forma que as mais
importantes sejam abordadas e entregues
primeiro, enquanto as menos importantes ficam
para depois.
MODELO ORIENTADO A CRONOGRAMA
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 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)
um meio termo entre a Prototipao Evolucionria e a
Entrega em Estgios.
Neste modelo a equipe tambm desenvolve uma verso do
produto, mostra ao cliente, e desenvolve novas verses
baseadas no feedback do cliente.
Depende do grau em que se pretende acomodar os Depende do grau em que se pretende acomodar os
requisitos solicitados:
se a idia acomodar todos ou a grande maioria dos
novos requisitos, ento a abordagem tende mais para
Prototipao Evolucionria.
Se as entregas continuaro sendo planejadas de acordo
com o previsto e as novas funcionalidades acomodadas
aos poucos nas entregas, ento a abordagem se parece
mais com Entrega em Estgios.
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. 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.
MODELO ORIENTADO A FERRAMENTAS
(DESIGN TO TOOLS)
Consiste no uso intensivo de ferramentas de
prototipao e gerao de cdigo, que permitem a
rpida produo de sistemas executveis a partir
de especificaes em alto nvel, como por exemplo,
jCompany (Alvim, 2008). jCompany (Alvim, 2008).
uma abordagem extremamente rpida de
desenvolvimento e prototipao, mas limitada
pelas funcionalidades oferecidas pelas
ferramentas especficas.
Assim, requisitos s so atendidos se a
ferramenta de produo permite atender
funcionalidade requerida.
Se as ferramentas forem cuidadosamente
escolhidas, entretanto, pode-se conseguir
implementar uma grande parte dos requisitos
rapidamente. rapidamente.
Esta abordagem pode ser combinada com outros
modelos de processo.
A prototipao necessria no processo espiral, por
exemplo, pode ser feita utilizando-se ferramentas
de gerao de cdigo para produzir prottipos
rapidamente.
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.
Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.
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. 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.
Schell, J. (2008). The Art of Game Design. Elsevier.
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.