A verificação e documentação dos resultados do projeto ocorrem em qual das etapas do ciclo de vida

Por que eu devo ler este 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.

O ciclo de vida � a estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, opera��o e manuten��o de um produto de software, abrangendo a vida do sistema, desde a defini��o de seus requisitos at� o t�rmino 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 vers�o operacional do sistema.

Processo de software � o conjunto de atividades que constituem o desenvolvimento de um sistema computacional. Estas atividades s�o agrupadas em fases, como: defini��o de requisitos, an�lise, projeto, desenvolvimento, teste e implanta��o.

Em cada fase s�o definidas, al�m das suas atividades, as fun��es 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 v�o 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 tend�ncia a repetirem-se os passos e as pr�ticas que deram certo. A etapa seguinte foi a formaliza��o em modelos de ciclo de vida.

Em outras palavras, os modelos de ciclo de vida s�o 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, opera��o e manuten��o de um produto de software, abrangendo a vida do sistema, desde a defini��o de seus requisitos at� o t�rmino 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 vers�o operacional do sistema.

N�o existe um modelo ideal. O perfil e complexidade do neg�cio do cliente, o tempo dispon�vel, o custo, a equipe, o ambiente operacional s�o fatores que influenciar�o diretamente na escolha do ciclo de vida de software a ser adotado.

Da mesma forma, tamb�m � dif�cil uma empresa adotar um �nico ciclo de vida. Na maior parte dos casos, v�-se a presen�a 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 (divis�o de escopo) e/ou iterativa (retroalimenta��o 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 s�o:

• an�lise e defini��o de requisitos;
• projeto;
• implementa��o;
• teste;
• integra��o.

O modelo em cascata tem o grande m�rito de ser o primeiro a impor o planejamento e o gerenciamento ao processo de software, que antes era casual. O nome "cascata" foi atribu�do em raz�o da sequ�ncia das fases, onde cada fase s� come�a quando a anterior termina; e da transmiss�o 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 an�lise e projeto antes de partir para a programa��o, a fim de que o objetivo do software esteja bem definido e que sejam evitados retrabalhos, conforme podemos observar na Figura 1.

Devido � sua simplicidade, o modelo em cascata � f�cil de ser entendido pelo cliente. � um modelo que sup�e um in�cio e fim claro e determinado, assim como uma estimativa precisa de custo logo no in�cio, fatores importantes na conquista do cliente.

O problema se d� depois, quando o cliente, ap�s esperar at� o fim do processo para receber a primeira vers�o do sistema, pode n�o concordar com ela. Apesar de cada fase terminar com uma documenta��o aprovada, certamente haver� lacunas devido a requisitos mal descritos pelo cliente, mal entendido pelo analista ou por mudan�a de cen�rio na organiza��o que exija adapta��o de requisitos. O modelo em cascata n�o prev� revis�o de fases.

Assim, o risco � muito alto, principalmente para sistemas complexos, de grande porte, afinal o modelo em cascata pressup�e uma realidade est�tica e bem conhecida, comparado a uma linha de produ��o fabril. Mas a rotina do neg�cio do cliente n�o reflete isso. Manipula��o de usu�rios com diferentes habilidades, ambientes operacionais distintos, tecnologia em crescente evolu��o, necessidade de integra��o com outros sistemas (em plataformas antigas ou mais novas), mudan�as organizacionais, at� mudan�as na legisla��o do munic�pio/estado/pa�s, pedem um modelo mais flex�vel.

Por outro lado, o modelo em cascata ad�qua-se bem como um "submodelo" para outros modelos. Por exemplo, no modelo "cascata com realimenta��o" permite-se que, a cada descoberta da fase posterior, haja uma corre��o da fase anterior.

Modelo em V

Neste modelo, do Minist�rio de Defesa da Alemanha, 1992, o modelo em cascata � colocado em forma de "V". Do lado esquerdo do V ficam da an�lise de requisitos at� o projeto, a codifica��o fica no v�rtice e os testes, desenvolvimento, implanta��o e manuten��o, � direita, conforme Figura 2.

A caracter�stica principal desse modelo, que o diferencia do modelo em cascata, � a �nfase dada � verifica��o e valida��o: cada fase do lado esquerdo gera um plano de teste a ser executado no lado direito.

Mais tarde, o c�digo fonte ser� testado, do mais baixo n�vel ao n�vel sist�mico 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 aceita��o do cliente valida a an�lise de requisitos.

Da mesma forma que o modelo em cascata, o cliente s� recebe a primeira vers�o do software no final do ciclo, mas apresenta menos risco, devido ao planejamento pr�vio dos testes nas fases de an�lise e projeto.

Ciclos de Vida Incremental

Neste modelo, de Mills em 1980, os requisitos do cliente s�o obtidos, e, de acordo com a funcionalidade, s�o agrupados em m�dulos. Ap�s este agrupamento, a equipe, junto ao cliente, define a prioridade em que cada m�dulo ser� desenvolvido, escolha baseada na import�ncia daquela funcionalidade ao neg�cio do cliente.

Cada m�dulo 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.

Como o cliente j� trabalhar� no primeiro incremento ou m�dulo, � muito importante que haja uma especial aten��o na integra��o dos incrementos, o que exige muito planejamento, afinal n�o � aceit�vel que o cliente se depare com muitos erros de software a cada incremento, tampouco, que a cada incremento ele precise se readaptar a grandes mudan�as. Uma aten��o especial deve ser dada ao agrupamento dos requisitos e � qualidade no desenvolvimento das fun��es comuns a todo o sistema, que inevitavelmente dever�o ser entregues no primeiro incremento.

Desta forma, al�m de atender as necessidades mais cr�ticas do cliente mais cedo, as partes mais importantes ser�o, tamb�m, as partes mais testadas no ambiente real. Ser� mais dif�cil gastar recursos em conceitos errados, ou que um mau entendimento dos requisitos alcance uma escala dif�cil de ser ajustada, visto que durante todo o projeto haver� o feedback do cliente (a opini�o do cliente realimenta o sistema).

Esse ciclo de vida n�o exige uma equipe muito grande, pois a modulariza��o diminui o escopo de cada incremento, e n�o h� um paralelismo nas atividades. Haver�, por outro lado, uma dificuldade em manter a documenta��o de cada fase atualizada devido �s melhorias no sistema e aos ajustes de requisitos solicitados pelos clientes.

Modelo Evolutivo

Neste modelo, os requisitos s�o adquiridos em paralelo � evolu��o do sistema. O modelo evolutivo parte do princ�pio que o cliente n�o exp�e todos os requisitos, ou os requisitos n�o s�o t�o bem conhecidos, ou os requisitos ainda est�o sofrendo mudan�as. Desta forma, a an�lise � feita em cima dos requisitos conseguidos at� ent�o, e a primeira vers�o � entregue ao cliente. O cliente usa o software no seu ambiente operacional, e como feedback, esclarece o que n�o foi bem entendido e d� mais informa��es sobre o que precisa e sobre o que deseja (ou seja, mais requisitos).

A partir deste feedback, nova an�lise, projeto e desenvolvimento s�o realizados, e uma segunda vers�o 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 vers�o final, pelo menos at� novos requisitos aparecerem (ver Figura 4).

A participa��o constante do cliente � uma grande vantagem desse modelo, o que diminui o risco de m� interpreta��o de requisitos dos modelos que s� oferecem a primeira vers�o do software no final do processo. Da mesma forma, o software j� atende algumas necessidades do cliente muito mais cedo no processo.

N�o � dada muita �nfase � documenta��o, pois a gera��o de vers�es torna este trabalho muito �rduo. Al�m disso, como a an�lise de requisitos e desenvolvimento est�o sempre acontecendo, a preocupa��o 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 documenta��o adequada, o escopo de requisitos n�o determinado, o software crescendo e estando ao mesmo tempo em produ��o podem ter consequ�ncias negativas. Seguem alguns exemplos: o sistema nunca terminar, pois o cliente sempre pede uma altera��o; o sistema n�o ter uma estrutura robusta a falhas nem prop�cia a uma f�cil manuten��o, pelas constantes altera��es; o cliente mudar de ideia radicalmente entre uma vers�o e outra ou revelar um requisito que exija uma vers�o bem diferente da anterior, fazendo com que toda a base (de dados ou de programa��o) 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 n�o haja frustra��es de expectativas.

RAD � �Rapid Application Development�

Este modelo formalizado por James Martin em 1991, como uma evolu��o da �prototipagem r�pida�, destaca-se pelo desenvolvimento r�pido da aplica��o. O ciclo de vida � extremamente comprimido, de forma a encontrarem-se exemplos, na literatura, de dura��o de 60 e 90 dias. � ideal para clientes buscando lan�ar solu��es pioneiras no mercado.

� um ciclo de vida incremental, iterativo, onde � prefer�vel que os requisitos tenham escopo restrito. A diferen�a principal do ciclo anterior � o forte paralelismo das atividades, requerendo, assim, m�dulos bastante independentes. Aqui os incrementos s�o desenvolvidos ao mesmo tempo, por equipes diferentes.

Al�m do paralelismo, a conquista do baixo tempo se d� gra�as � compress�o da fase de requisitos e da fase de implanta��o. Isso significa que, na obten��o dos requisitos, costumam-se optar por metodologias mais din�micas e r�pidas, como workshops ao inv�s de entrevistas. Permite-se tamb�m um desenvolvimento inicial no n�vel mais alto de abstra��o dos requisitos visto o envolvimento maior do usu�rio e visibilidade mais cedo dos prot�tipos (ver Figura 5).

As f�bricas de software que resolvem por adotar este modelo devem ter uma estrutura pr�via diferencial de pessoas e ferramentas, tais como:

• Pessoas:
• Profissionais experientes (funcional e ger�ncia);
• Profissionais de r�pida adapta��o;
• Equipes de colabora��o m�tua;
• Maior quantidade de pessoas;
• Gerenciamento:
• Empresas pouco burocr�ticas que encorajem a elimina��o de obst�culos;
• Alto controle do tempo;
• Uso de Ferramentas:
• CASE;
• Muita diagrama��o;
• Pr�via biblioteca de componentes reutiliz�veis (APIs, wizards, templates,...);
• F�cil manuten��o (ex.: linguagens de programa��o que suportem Orienta��o a Objetos, tratamento de exce��o, ponteiros);
• Ado��o de ferramentas maduras, pois n�o h� tempo de atualizar vers�es e tratar erros inesperados;

Os sistemas desenvolvidos no ciclo RAD tendem a ter uma padroniza��o de telas muito forte, devido a bibliotecas reutiliz�veis e templates, por�m tendem a perder em desempenho do sistema e na an�lise de risco (atividades estas que demandam tempo em qualquer projeto). Assim, � prefer�vel seu uso para softwares de distribui��o pequena.

Prototipagem

Prototipagem � a constru��o 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 prot�tipo em engenharia de software pode ser o desenho de uma tela, um software contendo algumas funcionalidades do sistema. S�o considerados operacionais (quando j� podem ser utilizados pelo cliente no ambiente real, ou seja, em produ��o), ou n�o operacionais (n�o est�o aptos para serem utilizados em produ��o). Os prot�tipos podem ser descartados, ou reaproveitados para evolu�rem at� a vers�o final.

No ciclo de vida de prototipagem, n�o � exigido um conhecimento aprofundado dos requisitos num primeiro momento. Isso � bastante �til quando os requisitos n�o s�o totalmente conhecidos, s�o muitos complexos ou confusos. Desta forma, se o cliente n�o sabe expressar o que deseja (o que ocorre bastante quando n�o � um sistema legado), a melhor maneira de evitar que se perca tempo e recursos com uma m� interpreta��o � a constru��o de modelos, ou seja, de prot�tipos do que o software faria.

Assim, o cliente experimentar�, na pr�tica, como o sistema ou parte dele funcionar�. A partir desse primeiro contato, o cliente esclarece o que n�o foi bem interpretado, aprofunda alguns conceitos e at� descobre um pouco mais sobre o que realmente precisa. A partir deste feedback, novos requisitos s�o colhidos e o projeto ganha maior profundidade. Outro prot�tipo � gerado e apresentado ao cliente, que retorna com mais feedbacks. Ou seja, o cliente participa ativamente do in�cio ao fim do processo (ver Figura 6).

A gera��o de prot�tipos pode ser facilitada por ferramentas geradoras de telas, de relat�rios, poupando esfor�o de programa��o e diminuindo o tempo de entrega.

Cada prot�tipo tem uma finalidade diferente. Um prot�tipo pode servir para esclarecer d�vidas sobre uma rotina, demonstrar a apar�ncia das telas, conte�do de tabelas, formato de relat�rios. Os prot�tipos podem tamb�m ser utilizados para apresentar op��es ao cliente para que ele escolha a que mais lhe agrade, como op��es de navega��o, de fluxo de telas, entre outras.

Por isso, � muito importante explicar previamente ao cliente que prot�tipos s�o apenas modelos para melhorar a comunica��o. Caso contr�rio, pode causar uma frustra��o por n�o funcionar corretamente, ter fun��es limitadas, ter resposta lenta, ou a apar�ncia ruim. Certamente um prot�tipo constru�do para esclarecer uma rotina provavelmente ter� uma �cara feia�; para demonstrar a apar�ncia das telas, n�o ter� funcionalidade; para apresentar o formato dos relat�rios, os dados n�o ser�o coerentes.

O cliente far� compara��es entre o sistema final e o que foi �prometido� atrav�s do prot�tipo e pode ficar insatisfeito. Por exemplo, geralmente o prot�tipo n�o acessa rede ou banco de dados, pois as informa��es s�o �desenhadas� com a tela, fazendo com que tudo fique muito r�pido. J� no ambiente operacional haver� uma degrada��o de desempenho e o cliente pode se decepcionar.

Faz parte de um bom gerenciamento no modelo de prototipagem planejar se, quais e que fun��es dos prot�tipos n�o operacionais ser�o reaproveitadas na vers�o operacional, para que sua confec��o siga as boas pr�ticas de engenharia de software. Os prot�tipos n�o operacionais s�o constru�dos com pouca qualidade em prol da velocidade. Ou seja, n�o h� preocupa��o na programa��o, em refinar o c�digo, em usar coment�rios, em aproveitar eficientemente os recursos de hardware e software, na manuten��o, no reuso de componentes e na integra��o com outras fun��es ou sistemas. Com certeza ser� um problema se a equipe sucumbir � press�o do cliente, cada vez mais ansioso para ver a vers�o final daquele trabalho, e transformar � revelia, prot�tipos n�o operacionais em operacionais.

O gerente tamb�m deve se preocupar com o escopo do projeto versus a quantidade de prot�tipos, para que n�o se perca muito tempo nesse processo, tampouco se transforme num processo de �tentativa e erro�.

N�o � uma tarefa f�cil documentar o modelo de ciclo de vida baseado na prototipagem devido aos requisitos n�o serem totalmente conhecidos no primeiro momento e a consequente quantidade de mudan�as ocorridas.

Modelo Espiral

O modelo proposto por Boehm em 1988 trata de uma abordagem c�clica das fases do processo, onde a cada �volta� ou itera��o temos vers�es evolucion�rias do sistema.

Este � um modelo guiado por risco, suporta sistemas complexos e/ou de grande porte, onde falhas n�o s�o toler�veis. Para isso, a cada itera��o h� uma atividade dedicada � an�lise de riscos e apoiada atrav�s de gera��o de prot�tipos, n�o necessariamente operacionais (desenhos de tela, por exemplo) para que haja um envolvimento constante do cliente nas decis�es.

Cada itera��o ou volta � dedicada a uma fase do processo de vida de um software (viabilidade do projeto, defini��o de requisitos, desenvolvimento e teste,...). Ao mesmo tempo, cada volta � seccionada em 4 setores, da seguinte forma:

1. Itera��o: Viabilidade do projeto:
• 1.1. Defini��o de objetivos;
• 1.2. Avalia��o e redu��o de riscos;
• 1.3. Desenvolvimento e valida��o;
• 1.4. Planejamento da pr�xima fase;
2. Itera��o: Defini��o de requisitos do sistema:
• 2.1. Defini��o dos objetivos;
• 2.2. Avalia��o e redu��o de riscos;
• 2.3. Desenvolvimento e valida��o;
• 2.4. Planejamento da pr�xima fase;
3. Itera��o: Projeto do sistema:
• 3.1. ...
• 3.2. ...
• 3.3. ...
• 3.4. ...
4. Itera��o: Desenvolvimento e teste de unidade
• 4.1. ...
• 4.2. ...
• ...
5. Itera��o: Implanta��o
• ...

Ou, na representa��o gr�fica deste modelo conforme Figura 7.

Os quatro setores s�o explicados da seguinte forma:

1. Na Defini��o de Objetivos, desempenhos, funcionalidade, entre outros objetivos, s�o levantados. Visando alcan�ar esses objetivos s�o listadas alternativas e restri��es, e cria-se um plano gerencial detalhado.
2. Na An�lise de Riscos, as alternativas, restri��es e riscos anteriormente levantados s�o avaliados. Neste setor (por�m n�o apenas neste) prot�tipos s�o utilizados para ajudar na an�lise de riscos.
3. No Desenvolvimento e Valida��o um modelo apropriado para o desenvolvimento do sistema � escolhido, de acordo com o risco analisado no setor anterior (cascata, interativo,...).
4. No Planejamento da Pr�xima fase ocorre a revis�o do projeto e a decis�o de partir para a pr�xima fase.

Ou seja, cada volta ou itera��o do processo � vista por quatro �ngulos.

No final da Viabilidade do Projeto teremos como resultado a Concep��o das Opera��es; da Defini��o de Requisitos o produto ser�o os requisitos; no final do Desenvolvimento e Testes o projeto � criado e os testes habilitados. Pode-se parar por a�, pode-se incluir mais fases, pode a espiral ficar adormecida at� uma nova altera��o do sistema se requisitada, e desta forma estender at� o fim de vida do sistema.

Neste modelo, apenas o in�cio � definido. A evolu��o e amadurecimento dos requisitos demandam tempo ajust�vel (assim como custo). Isto torna o sistema dif�cil de ser vender ao cliente e exige um alto n�vel 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 utiliza��o das melhores pr�ticas de especifica��o de projeto (V�deo Aula sobre Ciclo de Vida de Software, parte 3, revista Engenharia de Software Magazine).

O objetivo do RUP � produzir software com qualidade (melhores pr�ticas de engenharia de software) que satisfa�a as necessidades dos clientes dentro de um prazo e or�amento 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 configur�vel que oferece melhores pr�ticas comprovadas e uma arquitetura configur�vel. (ver Figura 8)�

O RUP possui quatro fases de neg�cio. O nome de cada fase revela o que ser� entregue por ela (ver Figura 9):

• Concep��o: define o escopo do projeto, ou �business case�; onde � julgado se o projeto deve ir adiante ou ser cancelado.
• Elabora��o: elabora modelo de requisitos, arquitetura do sistema, plano de desenvolvimento para o software e identificar os riscos.
• Constru��o: constr�i o software e a documenta��o associada.
• Transi��o: finaliza produto, define-se plano de entrega e entrega a vers�o operacional documentada para o cliente.

A itera��o no RUP tem por objetivo minimizar os riscos. Como pode ser visto na Figura 9, a itera��o pode acontecer dentro de cada fase, gerando incrementos, ou em todo o processo. Por exemplo, dentro da concep��o, a itera��o pode ocorrer at� que todos os requisitos sejam perfeitamente entendidos. O plano de itera��es identificar� quais e quantas itera��es s�o necess�rias durante o processo.

Em geral, essas fases demandam esfor�o e programa��o diferentes. Para um projeto de m�dio porte, de acordo com o fabricante ser� seguida a distribui��o apresentada na Tabela 1.

Tabela 1. Distribui��o prevista de esfor�o e programa��o para um ciclo de desenvolvimento inicial t�pico de um projeto de m�dio tamanho

O RUP usa templates que descrevem o que � esperado no resultado de cada fase ou cada itera��o (IBM, 2004), identificando as compet�ncias e responsabilidades (arquiteto, analista, testador,...), as atividades e os artefatos.

Para descrever as atividades (codifica��o de uma classe, integra��o de sistemas,...) o RUP faz o uso de manuais (guidelines), que descrevem t�cnicas e heur�sticas; e de �Mentores de Ferramentas�, que explicam o uso da ferramenta para executar a atividade. Os artefatos de cada fase (documentos, modelos, c�digos, etc.) s�o criados, juntamente com templates e exemplos, para melhor entendimento da equipe e do cliente (ver Figura 10).

Os templates tamb�m ajudam no gerenciamento, pois definem o que precisa ser executado. Servem tamb�m como guia para que as boas pr�ticas de especifica��o de projeto n�o sejam esquecidas no processo de desenvolvimento daquele software.

Assim, toda a preocupa��o dada pelo RUP em disciplinar o processo atrav�s de frameworks, guias, templates, faz com que haja uma melhor aloca��o de pessoas na equipe, padroniza��o do sistema, vis�o concreta do andamento do projeto.

A escolha do RUP deve ser feita por empresas de software com pr�via experi�ncia, pois a defini��o de framework, templates, guias, m�todos, entre outros, demandam tempo e exigem ader�ncia �s boas pr�ticas de processo de software.

Considera��es Finais

Finalizando este artigo sobre os modelos de ciclo de vida de software, segue uma tabela comparativa das principais caracter�sticas 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, n�o existe um modelo ideal e na maioria dos softwares desenvolvidos s�o utilizados mais de um modelo de ciclo de vida.

Tabela 2. Compara��o entre os modelos de ciclo de vida

Saiu na DevMedia!

• Entre de cabe�a no REST: Voc� j� deve ter notado que o prazo para o lan�amento de uma aplica��o nem sempre corresponde a complexidade dos seus requisitos. Por esse motivo, � cada vez mais importante que o desenvolvedor saiba como criar e consumir APIs. Veja como nesta s�rie.

Bibliografia:

• SOMMERVILLE, Ian, Engenharia Software. Addison Wesley. 8� ed
• PRESSMAN, Roger, Engenharia Software, McGraw-Hill. 6� ed
• Case Maker Inc., What is Rappid Application Development?
• PISKE, Otavio. SEIDEL, Fabio, Rapid Application Development
• Norma NBR ISO/IEC 12207:1998
• SPINOLA, Rodrigo, Boas Pr�ticas de Engenharia de Software, 2011
• PFLEGER, Shari, Engenharia de Software � Teoria e Pr�tica, Prentice Hall, 2� Ed
• PAULA Filho, Wilson, Engenharia de Software: fundamentos, m�todos e padr�es, LTC, 3� Ed
• V�deo Aula sobre Ciclo de Vida de Software, Revista digital Engenharia de Software Magazine

Confira outros conte�dos: