Engenharia

Nesta seo voc encontra artigos voltados para testes, processo,

modelos, documentao, entre outros

Ciclos de Vida do Software

Conhecendo os Bastidores

De que se trata o artigo?

Ana Brbara Lins de Macdo

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,
mais especificamente, 2 anos na rea de integrao de esforos do times de engenharia e
6 anos trabalhando na rea responsvel pela
rede intraveicular (comunicao digital entre
mdulos eletrnicos e diagnose veicular).
6 anos adicionais de experincia prvia em
Informtica como Analista de Sistemas de
software para aplicaes em internet, finanas, comerciais e vendas. Atualmente est
cursando Ps-Graduao em Engenharia de
Software na Faculdade Ruy Barbosa.

Rodrigo Spnola
rodrigo@sqlmagazine.com.br

Doutor e Mestre em Engenharia de Software

pela COPPE/UFRJ.
Diretor de Operaes Kali Software
(www.kalisoftware.com)
Editor Chefe SQL Magazine | WebMobile |
Engenharia de Software Magazine
Professor do Curso de Ps-Graduao em
Engenharia de Software da Faculdade Ruy
Barbosa.

rocesso 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

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 deinio 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 deinir-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.

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.

Edio 36 - Engenharia de Software Magazine

21

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

Figura 1. O modelo em cascata

22

Engenharia de Software Magazine - Ciclos de Vida do Software

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

GESTO DE CONHEC IMENTO

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 Figura 2. O modelo em V
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.
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 plane- Figura 3. Ciclo de vida Incremental
jamento, afinal no aceitvel que o cliente
se depare com muitos erros de software a cada incremento,
so to bem conhecidos, ou os requisitos ainda esto sofrendo
tampouco, que a cada incremento ele precise se readaptar a
mudanas. Desta forma, a anlise feita em cima dos requigrandes mudanas. Uma ateno especial deve ser dada ao
sitos conseguidos at ento, e a primeira verso entregue ao
agrupamento dos requisitos e qualidade no desenvolvimento
cliente. O cliente usa o software no seu ambiente operacional,
das funes comuns a todo o sistema, que inevitavelmente
e como feedback, esclarece o que no foi bem entendido e d
devero ser entregues no primeiro incremento.
mais informaes sobre o que precisa e sobre o que deseja (ou
Desta forma, alm de atender as necessidades mais crticas do
seja, mais requisitos).
cliente mais cedo, as partes mais importantes sero, tambm, as
A partir deste feedback, nova anlise, projeto e desenvolvipartes mais testadas no ambiente real. Ser mais difcil gastar
mento so realizados, e uma segunda verso do software enrecursos em conceitos errados, ou que um mau entendimento
tregue ao cliente que, novamente, retorna com mais feedbacks.
dos requisitos alcance uma escala difcil de ser ajustada, visto
Assim, o software vai evoluindo, se tornando mais completo,
que durante todo o projeto haver o feedback do cliente (a
at atender todas as necessidades do cliente dentro do escopo
opinio do cliente realimenta o sistema).
estabelecido. Tem-se assim a verso final, pelo menos at novos
Esse ciclo de vida no exige uma equipe muito grande, pois
requisitos aparecerem (ver Figura 4).
a modularizao diminui o escopo de cada incremento, e no
A participao constante do cliente uma grande vantagem
h um paralelismo nas atividades. Haver, por outro lado,
desse modelo, o que diminui o risco de m interpretao de
uma dificuldade em manter a documentao de cada fase
requisitos dos modelos que s oferecem a primeira verso do
atualizada devido s melhorias no sistema e aos ajustes de
software no final do processo. Da mesma forma, o software
requisitos solicitados pelos clientes.
j atende algumas necessidades do cliente muito mais cedo
no processo.
Modelo Evolutivo
No dada muita nfase documentao, pois a gerao
Neste modelo, os requisitos so adquiridos em paralelo
de verses torna este trabalho muito rduo. Alm disso,
evoluo do sistema. O modelo evolutivo parte do princpio
como a anlise de requisitos e desenvolvimento esto sempre
que o cliente no expe todos os requisitos, ou os requisitos no

Edio 36 - Engenharia de Software Magazine

23

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.

Figura 4. Ciclo de vida Evolutivo

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, costumamse 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).
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
Figura 5. Ciclo de vida RAD

24

Engenharia de Software Magazine - Ciclos de Vida do Software

Prototipagem a construo de um exemplar

do que foi entendido dos requisitos capturados

GESTO DE CONHEC IMENTO

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

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

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;

Edio 36 - Engenharia de Software Magazine

25

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

Figura 7. Modelo Espiral

26

Engenharia de Software Magazine - Ciclos de Vida do Software

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 inal da Viabilidade do Projeto teremos como resultado a
Concepo das Operaes; da Deinio de Requisitos o produto sero os requisitos; no inal do Desenvolvimento e Testes
o projeto criado e os testes habilitados. Pode-se parar por a,
pode-se incluir mais fases, pode a espiral icar adormecida at
uma nova alterao do sistema se requisitada, e desta forma
estender at o im 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

GESTO DE CONHEC IMENTO

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
Figura 8. Conceitos chaves do RUP
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, arqui- Figura 9. RUP
tetura do sistema, plano de desenvolvimento para o
Concepo
Elaborao Construo
Transio
software e identificar os riscos.
Construo: constri o software e a documentao
Esforo
~5 %
20 %
65 %
10%
associada.
Programao
10 %
30 %
50 %
10 %
Transio: finaliza produto, define-se plano de entrega e
Tabela 1. Distribuio prevista de esforo e programao para um ciclo
entrega a verso operacional documentada para o cliente.
de desenvolvimento inicial tpico de um projeto de mdio tamanho

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 , identiicando 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.

Edio 36 - Engenharia de Software Magazine

27

Modelo

Foco

Requisitos

1 verso p/ cliente

Cascata

Documento e artefato

Bem conhecido/congelado

Fim do ciclo

Gerenciamento
(1=mais simples)
1

Planejamento de testes

Bem conhecido/congelado

Fim do ciclo

Sistemas
(tamanho complexidade mximos)
Simples
Simples

Incremental

Incrementos operacionais

Maior abstrao / Tratado em mdulos

Prottipos operacionais

Mdio

Evolutivo

Evoluo dos requisitos

Pouco conhecidos

Prottipos operacionais

Mdio

RAD

Rapidez

Prottipos operacionais

Mdio

Prototipagem

Dvidas nos Requisitos

Escopo restrito / Maior abstrao /

Tratado em mdulos
Abstratos

Mdio

Espiral

Anlise de risco

Complexos

RUP

Frameworks e boas
prticas

Prottipos
no
operacionais
Prottipos operacionais
ou no operacionais
Prottipos operacionais
ou no operacionais

Complexos

Maior abstrao / evoludos com o

tempo
Maior abstrao / evoludos com o
tempo

Tabela 2. Comparao entre os modelos de ciclo de vida

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

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

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:

28

Engenharia de Software Magazine - Ciclos de Vida do Software

D
s

D seu feedback sobre esta edio!

www.devmedia.com.br/esmag/feedback

Feedback
eu
sobre e
s

Consideraes Finais

edio
ta

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

informaes existente entre eles

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 Prticas de Engenharia de Software, 2011
PFLEGER, Shari, Engenharia de Software Teoria e Prtica, Prentice Hall, 2 Ed
PAULA Filho, Wilson, Engenharia de Software: fundamentos, mtodos e padres, LTC, 3 Ed
Vdeo Aula sobre Ciclo de Vida de Software, Revista digital Engenharia de Software Magazine
Artigo: Ciclo de Vida del Software, http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/
lpcu097%20-%2001.pdf
Artigo: Going Over the Waterfall with the RUP: http://www.ibm.com/developerworks/
rational/library/4626.html
IBM Webpage: Rational Unified Process: http://www-01.ibm.com/software/br/rational/
rup.shtml
RUP Tutorial Tour: http://www.wthreex.com/rup/portugues/index.htm