Ciclos de Vida do SoftwareConhecendo os BastidoresDe que se trata o artigoNeste 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 serveO 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 tilO 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 MacdoEstudante 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 SpinolaEditor 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 RUPModelo 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 VNeste 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 VA 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 IncrementalNeste 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 EvolutivoNeste 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 DevelopmentEste 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 envolvimentomaior 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.PrototipagemPrototipagem 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 EspiralO 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 unidade4.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. Pode-se 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 RUPDerivado 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

ConclusoFinalizando 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.