Ciclos de Vida do Software

Conhecendo os Bastidores
De que se trata o artigo
Neste contexto, neste artigo apresentaremos alguns modelos de ciclo de vida,
quais sejam: Cascata, Modelo em V, Incremental, Evolutivo, RAD,
Prototipagem, Espiral, Modelo de Ciclo de Vida Associado ao RUP.
Para que serve
O ciclo de vida a estrutura contendo processos, atividades e tarefas
envolvidas no desenvolvimento, operao e manuteno de um produto de
software, abrangendo a vida do sistema, desde a definio de seus requisitos
at o trmino de seu uso.
Em que situao o tema til
O modelo de ciclo de vida a primeira escolha a ser feita no processo de
software. A partir desta escolha definir-se- desde a maneira mais adequada de
obter as necessidades do cliente, at quando e como o cliente receber sua
primeira verso operacional do sistema.

Ana Brbara Lins de Macdo

Estudante do curso de especializao em Engenharia de Software da Faculdade Ruy
Barbosa. Engenheira Eletrnica com especializao em Telecomunicaes (UFBA) e
formao anterior em Informtica (UCSal). 8 anos de experincia profissional na
indstria automotiva trabalhando para Ford Motor Company na rea de engenharia de
desenvolvimento de produtos. 6 anos adicionais de experincia prvia em Informtica
como Analista de Sistemas de software para aplicaes em internet, finanas,
comerciais e vendas.

Rodrigo Spinola
Editor Chefe - SQL Magazine | WebMobile | Engenharia de Software Magazine
Professor da Faculdade Ruy Barbosa (www.frb.edu.br), uma instituio parte do Grupo
DeVry (www.devrybrasil.com.br).

Processo de software o conjunto de atividades que constituem o

desenvolvimento de um sistema computacional. Estas atividades so
agrupadas em fases, como: definio de requisitos, anlise, projeto,
desenvolvimento, teste e implantao.
Em cada fase so definidas, alm das suas atividades, as funes e

responsabilidades de cada membro da equipe, e como produto resultante, os

artefatos.
O que diferencia um processo de software do outro a ordem em que as
fases vo ocorrer, o tempo e a nfase dados a cada fase, as atividades
presentes, e os produtos entregues.
Com o crescimento do mercado de software, houve uma tendncia a
repetirem-se os passos e as prticas que deram certo. A etapa seguinte foi a
formalizao em modelos de ciclo de vida.
Em outras palavras, os modelos de ciclo de vida so o esqueleto, ou as
estruturas pr-definidas nas quais encaixamos as fases do processo. De
acordo com a NBR ISO/IEC 12207:1998, o ciclo de vida a Estrutura
contendo processos, atividades e tarefas envolvidas no desenvolvimento,
operao e manuteno de um produto de software, abrangendo a vida do
sistema, desde a definio de seus requisitos at o trmino de seu uso.
O modelo de ciclo de vida a primeira escolha a ser feita no processo de
software.
A partir desta escolha definir-se- desde a maneira mais adequada de obter
as necessidades do cliente, at quando e como o cliente receber sua primeira
verso operacional do sistema.
No existe um modelo ideal. O perfil e complexidade do negcio do cliente, o
tempo disponvel, o custo, a equipe, o ambiente operacional so fatores que
influenciaro diretamente na escolha do ciclo de vida de software a ser
adotado.
Da mesma forma, tambm difcil uma empresa adotar um nico ciclo de
vida. Na maior parte dos casos, v-se a presena de mais de um ciclo de vida
no processo.
Os ciclos de vida se comportam de maneira sequencial (fases seguem
determinada ordem) e/ou incremental (diviso de escopo) e/ou iterativa
(retroalimentao de fases) e/ou evolutiva (software aprimorado).
Neste contexto, neste artigo apresentaremos alguns modelos de ciclo de vida,
quais sejam:
- Cascata
- Modelo em V
- Incremental
- Evolutivo
- RAD
- Prototipagem
- Espiral
- Modelo de Ciclo de Vida Associado ao RUP
Modelo em Cascata
Formalizado por Royce em 1970, o modelo mais antigo. Suas atividades
fundamentais so:
- anlise e definio de requisitos;
- projeto;
- implementao;
- teste;
- integrao.

O modelo em cascata tem o grande mrito de ser o primeiro a impor

o planejamento e o gerenciamento ao processo de software, que
antes era casual. O nome "cascata" foi atribudo em razo da
sequncia das fases, onde cada fase s comea quando a anterior
termina; e da transmisso do resultado da fase anterior como entrada
para a fase atual (o fim de cada fase resulta em um documento
aprovado). Nesse modelo, portanto, dada muita nfase s fases de
anlise e projeto antes de partir para a programao, a fim de que o
objetivo do software esteja bem definido e que sejam evitados
retrabalhos, conforme podemos observar na Figura 1.
[abrir imagem em janela]

Figura 1. O modelo em cascata

Devido sua simplicidade, o modelo em cascata fcil de ser entendido pelo

cliente. um modelo que supe um incio e fim claro e determinado, assim
como uma estimativa precisa de custo logo no incio, fatores importantes na
conquista do cliente.
O problema se d depois, quando o cliente, aps esperar at o fim do
processo para receber a primeira verso do sistema, pode no concordar com
ela. Apesar de cada fase terminar com uma documentao aprovada,
certamente haver lacunas devido a requisitos mal descritos pelo cliente, mal

entendido pelo analista ou por mudana de cenrio na organizao que exija

adaptao de requisitos. O modelo em cascata no prev reviso de fases.
Assim, o risco muito alto, principalmente para sistemas complexos, de
grande porte, afinal o modelo em cascata pressupe uma realidade esttica e
bem conhecida, comparado a uma linha de produo fabril. Mas a rotina do
negcio do cliente no reflete isso. Manipulao de usurios com diferentes
habilidades, ambientes operacionais distintos, tecnologia em crescente
evoluo, necessidade de integrao com outros sistemas (em plataformas
antigas ou mais novas), mudanas organizacionais, at mudanas na
legislao do municpio/estado/pas, pedem um modelo mais flexvel.
Por outro lado, o modelo em cascata adqua-se bem como um "sub-modelo"
para outros modelos. Por exemplo, no modelo "cascata com realimentao"
permite-se que, a cada descoberta da fase posterior, haja uma correo da
fase anterior.

Modelo em V
Neste modelo, do Ministrio de Defesa da Alemanha, 1992, o modelo em
cascata colocado em forma de "V". Do lado esquerdo do V ficam da anlise
de requisitos at o projeto, a codificao fica no vrtice e os testes,
desenvolvimento, implantao e manuteno, direita, conforme Figura 2.
[abrir imagem em janela]

Figura 2. O modelo em V

A caracterstica principal desse modelo, que o diferencia do modelo em

cascata, a nfase dada verificao e validao: cada fase do lado esquerdo
gera um plano de teste a ser executado no lado direito.
Mais tarde, o cdigo fonte ser testado, do mais baixo nvel ao nvel sistmico
para confirmar os resultados, seguindo os respectivos planos de teste: o teste
de unidade valida o projeto do programa, o teste de sistema valida o projeto de

sistema e o teste de aceitao do cliente valida a anlise de requisitos.

Da mesma forma que o modelo em cascata, o cliente s recebe a primeira
verso do software no final do ciclo, mas apresenta menos risco, devido ao
planejamento prvio dos testes nas fases de anlise e projeto.

Ciclos de Vida Incremental

Neste modelo, de Mills em 1980, os requisitos do cliente so obtidos, e, de
acordo com a funcionalidade, so agrupados em mdulos. Aps este
agrupamento, a equipe, junto ao cliente, define a prioridade em que cada
mdulo ser desenvolvido, escolha baseada na importncia daquela
funcionalidade ao negcio do cliente.
Cada mdulo passar por todas as fases "cascata" de projeto, conforme se
observa na Figura 3, e ser entregue ao cliente um software operacional.
Assim, o cliente receber parte do produto final em menos tempo.
[abrir imagem em janela]

Figura 3. Ciclo de vida Incremental

Como o cliente j trabalhar no primeiro incremento ou mdulo, muito

importante que haja uma especial ateno na integrao dos incrementos, o
que exige muito planejamento, afinal no aceitvel que o cliente se depare
com muitos erros de software a cada incremento, tampouco, que a cada
incremento ele precise se readaptar a grandes mudanas. Uma ateno
especial deve ser dada ao agrupamento dos requisitos e qualidade no
desenvolvimento das funes comuns a todo o sistema, que inevitavelmente
devero ser entregues no primeiro incremento.
Desta forma, alm de atender as necessidades mais crticas do cliente mais
cedo, as partes mais importantes sero, tambm, as partes mais testadas no
ambiente real.
Ser mais difcil gastar recursos em conceitos errados, ou que um mau
entendimento dos requisitos alcance uma escala difcil de ser ajustada, visto
que durante todo o projeto haver o feedback do cliente (a opinio do cliente
realimenta o sistema).
Esse ciclo de vida no exige uma equipe muito grande, pois a modularizao
diminui o escopo de cada incremento, e no h um paralelismo nas atividades.
Haver, por outro lado, uma dificuldade em manter a documentao de cada

fase atualizada devido s melhorias no sistema e aos ajustes de requisitos

solicitados pelos clientes.

Modelo Evolutivo
Neste modelo, os requisitos so adquiridos em paralelo evoluo do sistema.
O modelo evolutivo parte do princpio que o cliente no expe todos os
requisitos, ou os requisitos no so to bem conhecidos, ou os requisitos ainda
esto sofrendo mudanas. Desta forma, a anlise feita em cima dos
requisitos conseguidos at ento, e a primeira verso entregue ao cliente. O
cliente usa o software no seu ambiente operacional, e como feedback,
esclarece o que no foi bem entendido e d mais informaes sobre o que
precisa e sobre o que deseja (ou seja, mais requisitos).
A partir deste feedback, nova anlise, projeto e desenvolvimento so
realizados, e uma segunda verso do software entregue ao cliente que,
novamente, retorna com mais feedbacks. Assim, o software vai evoluindo, se
tornando mais completo, at atender todas as necessidades do cliente dentro
do escopo estabelecido. Tem-se assim a verso final, pelo menos at novos
requisitos aparecerem (ver Figura 4).
[abrir imagem em janela]

Figura 4. Ciclo de vida Evolutivo

A participao constante do cliente uma grande vantagem desse modelo, o

que diminui o risco de m interpretao de requisitos dos modelos que s
oferecem a primeira verso do software no final do processo. Da mesma forma,
o software j atende algumas necessidades do cliente muito mais cedo no

processo.
No dada muita nfase documentao, pois a gerao de verses torna
este trabalho muito rduo. Alm disso, como a anlise de requisitos e
desenvolvimento esto sempre acontecendo, a preocupao em documentar
todo o processo pode fazer com que haja atrasos na entrega.
H uma alta necessidade de gerenciamento nesse tipo de modelo, pois a falta
de documentao adequada, o escopo de requisitos no determinado, o
software crescendo e estando ao mesmo tempo em produo podem ter
conseqncias negativas. Seguem alguns exemplos: o sistema nunca terminar,
pois o cliente sempre pede uma alterao; o sistema no ter uma estrutura
robusta a falhas nem propcia a uma fcil manuteno, pelas constantes
alteraes; o cliente mudar de idia radicalmente entre uma verso e outra ou
revelar um requisito que exija uma verso bem diferente da anterior, fazendo
com que toda a base (de dados ou de programao) precise ser revista. Os
citados problemas podem implicar em um grande nus financeiro e de tempo.
muito importante que o cliente esteja ciente do que se trata este ciclo de vida
e que sejam esclarecidos os limites de escopo e de tempo, para que no haja
frustraes de expectativas.

RAD - Rapid Application

Development
Este modelo formalizado por James Martin em 1991, como uma evoluo da
prototipagem rpida, destaca-se pelo desenvolvimento rpido da aplicao. O
ciclo de vida extremamente comprimido, de forma a encontrarem-se
exemplos, na literatura, de durao de 60 e 90 dias. ideal para clientes
buscando lanar solues pioneiras no mercado.
um ciclo de vida incremental, iterativo, onde prefervel que os requisitos
tenham escopo restrito. A diferena principal do ciclo anterior o forte
paralelismo das atividades, requerendo, assim, mdulos bastante
independentes. Aqui os incrementos so desenvolvidos ao mesmo tempo, por
equipes diferentes.
Alm do paralelismo, a conquista do baixo tempo se d graas compresso
da fase de requisitos e da fase de implantao. Isso significa que, na obteno
dos requisitos, costumam-se optar por metodologias mais dinmicas e rpidas,
como workshops ao invs de entrevistas.
Permite-se tambm um desenvolvimento inicial no nvel mais alto de abstrao
dos requisitos visto o envolvimento maior do usurio e visibilidade mais cedo
dos prottipos (ver Figura 5).
[abrir imagem em janela]

Figura 5. Ciclo de vida RAD x cascata - alta compresso de tempo

As fbricas de software que resolvem por adotar este modelo devem ter uma
estrutura prvia diferencial de pessoas e ferramentas, tais como:
- Pessoas:
- Profissionais experientes (funcional e gerncia);
- Profissionais de rpida adaptao;
- Equipes de colaborao mtua;
- Maior quantidade de pessoas;
- Gerenciamento:
- Empresas pouco burocrticas que encorajem a eliminao de obstculos;
- Alto controle do tempo;
- Uso de Ferramentas:
- CASE;
- Muita diagramao;
- Prvia biblioteca de componentes reutilizveis (APIs, wizards, templates,...);
- Fcil manuteno (ex.: linguagens de programao que suportem Orientao
a Objetos, tratamento de exceo, ponteiros);
- Adoo de ferramentas maduras, pois no h tempo de atualizar verses e
tratar erros inesperados;
Os sistemas desenvolvidos no ciclo RAD tendem a ter uma padronizao de

telas muito forte, devido a bibliotecas reutilizveis e templates, porm tendem a

perder em desempenho do sistema e na anlise de risco (atividades estas que
demandam tempo em qualquer projeto). Assim, prefervel seu uso para
softwares de distribuio pequena.

Prototipagem
Prototipagem a construo de um exemplar do que foi entendido dos
requisitos capturados do cliente. Pode ser considerado um ciclo de vida ou
pode ser usado como ferramenta em outros ciclos de vida.
Um prottipo em engenharia de software pode ser o desenho de uma tela, um
software contendo algumas funcionalidades do sistema.
So considerados operacionais (quando j podem ser utilizados pelo cliente no
ambiente real, ou seja, em produo), ou no operacionais (no esto aptos
para serem utilizados em produo). Os prottipos podem ser descartados, ou
reaproveitados para evolurem at a verso final.
No ciclo de vida de prototipagem, no exigido um conhecimento
aprofundado dos requisitos num primeiro momento. Isso bastante til quando
os requisitos no so totalmente conhecidos, so muitos complexos ou
confusos. Desta forma, se o cliente no sabe expressar o que deseja (o que
ocorre bastante quando no um sistema legado), a melhor maneira de evitar
que se perca tempo e recursos com uma m interpretao a construo de
modelos, ou seja, de prottipos do que o software faria.
Assim, o cliente experimentar, na prtica, como o sistema ou parte dele
funcionar. A partir desse primeiro contato, o cliente esclarece o que no foi
bem interpretado, aprofunda alguns conceitos e at descobre um pouco mais
sobre o que realmente precisa. A partir deste feedback, novos requisitos so
colhidos e o projeto ganha maior profundidade. Outro prottipo gerado e
apresentado ao cliente, que retorna com mais feedbacks. Ou seja, o cliente
participa ativamente do incio ao fim do processo (ver Figura 6).
A gerao de prottipos pode ser facilitada por ferramentas
geradoras de telas, de relatrios, poupando esforo de programao e
diminuindo o tempo de entrega.
Cada prottipo tem uma finalidade diferente.
Um prottipo pode servir para esclarecer dvidas sobre uma rotina,
demonstrar a aparncia das telas, contedo de tabelas, formato de relatrios.
Os prottipos podem tambm ser utilizados para apresentar opes ao cliente
para que ele escolha a que mais lhe agrade, como opes de navegao, de
fluxo de telas, entre outras.
Por isso, muito importante explicar previamente ao cliente que prottipos
so apenas modelos para melhorar a comunicao. Caso contrrio, pode
causar uma frustrao por no funcionar corretamente, ter funes limitadas,
ter resposta lenta, ou a aparncia ruim. Certamente um prottipo construdo

para esclarecer uma rotina provavelmente ter uma cara feia; para
demonstrar a aparncia das telas, no ter funcionalidade; para apresentar o
formato dos relatrios, os dados no sero coerentes.
[abrir imagem em janela]

Figura 6. O modelo e prototipagem (Pressman, adaptado)

O cliente far comparaes entre o sistema final e o que foi prometido

atravs do prottipo e pode ficar insatisfeito. Por exemplo, geralmente o
prottipo no acessa rede ou banco de dados, pois as informaes so
desenhadas com a tela, fazendo com que tudo fique muito rpido.
J no ambiente operacional haver uma degradao de desempenho
e o cliente pode se decepcionar.
Faz parte de um bom gerenciamento no modelo de prototipagem
planejar se, quais e que funes dos prottipos no operacionais
sero reaproveitadas na verso operacional, para que sua confeco
siga as boas prticas de engenharia de software. Os prottipos no
operacionais so construdos com pouca qualidade em prol da
velocidade. Ou seja, no h preocupao na programao, em refinar
o cdigo, em usar comentrios, em aproveitar eficientemente os
recursos de hardware e software, na manuteno, no reuso de
componentes e na integrao com outras funes ou sistemas. Com
certeza ser um problema se a equipe sucumbir presso do cliente,
cada vez mais ansioso para ver a verso final daquele trabalho, e
transformar revelia, prottipos no operacionais em operacionais.
O gerente tambm deve se preocupar com o escopo do projeto
versus a quantidade de prottipos, para que no se perca muito

tempo nesse processo, tampouco se transforme num processo de

tentativa e erro.
No uma tarefa fcil documentar o modelo de ciclo de vida baseado na
prototipagem devido aos requisitos no serem totalmente conhecidos no
primeiro momento e a consequente quantidade de mudanas ocorridas.

Modelo Espiral
O modelo proposto por Boehm em 1988 trata de uma abordagem cclica das
fases do processo, onde a cada volta ou iterao temos verses
evolucionrias do sistema.
Este um modelo guiado por risco, suporta sistemas complexos e/ou de
grande porte, onde falhas no so tolerveis. Para isso, a cada iterao h
uma atividade dedicada anlise de riscos e apoiada atravs de gerao de
prottipos, no necessariamente operacionais (desenhos de tela, por exemplo)
para que haja um envolvimento constante do cliente nas decises.
Cada iterao ou volta dedicada a uma fase do processo de vida de um
software (viabilidade do projeto, definio de requisitos, desenvolvimento e
teste,...). Ao mesmo tempo, cada volta seccionada em 4 setores, da seguinte
forma:
1 Iterao: Viabilidade do projeto:
1.1. Definio de objetivos;
1.2. Avaliao e reduo de riscos;
1.3. Desenvolvimento e validao;
1.4. Planejamento da prxima fase;
2 Iterao: Definio de requisitos do sistema:
2.1. Definio dos objetivos;
2.2. Avaliao e reduo de riscos;
2.3. Desenvolvimento e validao;
2.4. Planejamento da prxima fase;
3 Iterao:
Projeto do sistema:
3.1. ...
3.2. ...
3.3. ...
3.4. ...
4 Iterao: Desenvolvimento e teste de unidade
4.1. ...
4.2. ...
...
5 Iterao: Implantao
...
Ou, na representao grfica deste modelo conforme Figura 7.

Os quatro setores so explicados da seguinte forma:

1. Na Definio de Objetivos, desempenhos, funcionalidade, entre outros
objetivos, so levantados. Visando alcanar esses objetivos so listadas
alternativas e restries, e cria-se um plano gerencial detalhado.
2. Na Anlise de Riscos, as alternativas, restries e riscos anteriormente
levantados so avaliados. Neste setor (porm no apenas neste) prottipos
so utilizados para ajudar na anlise de riscos.
3. No Desenvolvimento e Validao um modelo apropriado para o
desenvolvimento do sistema escolhido, de acordo com o risco analisado no
setor anterior (cascata, interativo,...).
4. No Planejamento da Prxima fase ocorre a reviso do projeto e a deciso de
partir para a prxima fase.
Ou seja, cada volta ou iterao do processo vista por quatro ngulos.
No final da Viabilidade do Projeto teremos como resultado a Concepo das
Operaes; da Definio de Requisitos o produto sero os requisitos; no final
do Desenvolvimento e Testes o projeto criado e os testes habilitados. Podese parar por a, pode-se incluir mais fases, pode a espiral ficar adormecida at
uma nova alterao do sistema se requisitada, e desta forma estender at o fim
de vida do sistema.
Neste modelo, apenas o incio definido.
A evoluo e amadurecimento dos requisitos demandam tempo ajustvel
(assim como custo). Isto torna o sistema difcil de ser vender ao cliente e exige
um alto nvel de gerenciamento em todo o processo.

Modelo de Ciclo de Vida Associado ao

RUP
Derivado da UML e do Processo Unificado de Desenvolvimento de Software,
o RUP, Rational Unified Process, um modelo de processo iterativo e
incremental, dividido em fases, orientado a casos de uso. Possui framework
(esqueleto) de processo e manuais que guiam na utilizao das melhores
prticas de especificao de projeto (Vdeo Aula sobre Ciclo de Vida de
Software, parte 3, revista Engenharia de Software Magazine).
O objetivo do RUP produzir software com qualidade (melhores prticas de
engenharia de software) que satisfaa as necessidades dos clientes dentro de
um prazo e oramento estabelecidos.
Este modelo foi desenvolvido pela Rational Software Corporation e adquirido
pela IBM, que o define da seguinte maneira: IBM Rational Unified Process,
ou RUP, uma plataforma de processo de desenvolvimento de software
configurvel que oferece melhores prticas comprovadas e uma arquitetura
configurvel. (ver Figura 8)
O RUP possui quatro fases de negcio. O nome de cada fase revela o que
ser entregue por ela (ver Figura 9):
- Concepo: define o escopo do projeto, ou business case; onde julgado se
o projeto deve ir adiante ou ser cancelado.
- Elaborao: elabora modelo de requisitos, arquitetura do sistema, plano de
desenvolvimento para o software e identificar os riscos.

- Construo: constri o software e a documentao associada.

- Transio: finaliza produto, define-se plano de entrega e entrega a verso
operacional documentada para o cliente.
[abrir imagem em janela]

Figura 7. Modelo Espiral

[abrir imagem em janela]

Figura 8. Conceitos chaves do RUP

A iterao no RUP tem por objetivo minimizar os riscos. Como pode ser visto
na Figura 9, a iterao pode acontecer dentro de cada fase, gerando
incrementos, ou em todo o processo. Por exemplo, dentro da concepo, a
iterao pode ocorrer at que todos os requisitos sejam perfeitamente
entendidos. O plano de iteraes identificar quais e quantas iteraes so
necessrias durante o processo.
Em geral, essas fases demandam esforo e programao diferentes. Para um
projeto de mdio porte, de acordo com o fabricante ser seguida a distribuio
apresentada na Tabela 1.
O RUP usa templates que descrevem o que esperado no resultado de cada
fase ou cada iterao (IBM, 2004), identificando as competncias e
responsabilidades (arquiteto, analista, testador,...), as atividades e os artefatos.
Para descrever as atividades (codificao de uma classe, integrao de
sistemas,...) o RUP faz o uso de manuais (guidelines), que descrevem tcnicas
e heursticas; e de Mentores de Ferramentas, que explicam o uso da
ferramenta para executar a atividade. Os artefatos de cada fase (documentos,
modelos, cdigos, etc.) so criados, juntamente com templates e exemplos,
para melhor entendimento da equipe e do cliente (ver Figura 10).

Os templates tambm ajudam no gerenciamento, pois definem o que

precisa ser executado. Servem tambm como guia para que as boas
prticas de especificao de projeto no sejam esquecidas no
processo de desenvolvimento daquele software.
Assim, toda a preocupao dada pelo RUP em disciplinar o processo atravs
de frameworks, guias, templates, faz com que haja uma melhor alocao de
pessoas na equipe, padronizao do sistema, viso concreta do andamento do
projeto.
A escolha do RUP deve ser feita por empresas de software com prvia
experincia, pois a definio de framework, templates, guias, mtodos, entre
outros, demandam tempo e exigem aderncia s boas prticas de processo de
software.
[abrir imagem em janela]

Figura 9. RUP
[abrir imagem em janela]

Figura 10. Os principais artefatos do Rational Unified Process e o fluxo de

informaes existente entre eles.
[abrir imagem em janela]

Tabela 1. Distribuio prevista de esforo e programao para um ciclo de

desenvolvimento inicial tpico de um projeto de mdio tamanho.
[abrir imagem em janela]

Tabela 2. Comparao entre os modelos de ciclo de vida

Concluso
Finalizando este artigo sobre os modelos de ciclo de vida de software,
segue uma tabela comparativa das principais caractersticas que
devem ser observadas antes de escolher o ciclo ou os ciclos de vida a
serem adotados (ver Tabela 2).
Vale ressaltar que, conforme j mencionado anteriormente, no
existe um modelo ideal e na maioria dos softwares desenvolvidos so
utilizados mais de um modelo de ciclo de vida.