Engenharia de software

Modelos clssicos para

desenvolvimento de
software
Modelos clssicos para desenvolvimento
de software

Ciclo de vida do software

Antes de iniciarmos o estudo sobre ciclo de vida do software,

importante notar a diferena entre processo de software e ciclo de vida,
conforme definio de Sommerville (2003):
Processo de software refere-se a todas as atividades, tais como
artefatos, ferramentas, papis, controles etc., necessrias para construir,
entregar e manter um produto de software. J o ciclo de vida apresenta uma
representao alto nvel do processo de software executado (processo de
software real) ou como deveria ser executado, ou seja, normalmente, ciclos
de vida determinam as fases e o relacionamento entre as fases.
Um processo de software um conjunto de atividades e resultados
associados que levam produo de um produto de software. Esse processo
pode envolver o desenvolvimento de software desde o incio, embora, cada
vez mais, ocorra o caso de um software novo ser desenvolvido mediante a
expanso e a modificao de sistemas j existentes. Embora existam muitos
processos de software diferentes, h atividades fundamentais comuns a
todos eles, como especificao de software, projeto e implementao de
software, validao de software e evoluo de software (SOMMERVILLE,
2003).

Lembre-se: ciclo de vida do software

MTODOS + FERRAMENTAS + PROCEDIMENTOS =
CICLO DE VIDA DE SOFTWARE
(representao alto nvel do processo de software executado)

Os modelos de processo de software existentes possuem diferentes

graus de sofisticao e complexidade. No h um processo ideal, e
diferentes organizaes desenvolvem abordagens distintas para o

2
Engenharia de software Modelos clssicos para desenvolvimento de
Software
desenvolvimento de software. Os processos evoluram para explorar a
capacidade das pessoas em uma organizao, assim como as caractersticas
especficas dos sistemas que esto sendo desenvolvidos. At dentro da
mesma empresa podem ser utilizados processos diferentes para o
desenvolvimento de software (SOMMERVILLE, 2003).
Veja na tabela 1 os tipos de atividades do ciclo de vida do software e
suas respectivas funes.

Tabela 1. Tipos de atividades do ciclo de vida de um software e suas funes

(GUSTAFSON, 2003)
Atividades Funes
Determina se o desenvolvimento
Viabilidade
proposto vivel
Determina se existe mercado para
Anlise de mercado
esse produto
Determinam as funcionalidades que
Requisitos
o software deve ter
Elucidao dos requisitos Obtm os requisitos do usurio
Determina as tarefas e estruturas
Anlise de domnio
que so comuns ao problema
Determina como desenvolver o
Planejamento do projeto
software
Anlise de custos Determina a estimativa dos custos
Constri o cronograma para o
Cronograma
desenvolvimento
Determina atividades que iro ajudar
Garantia da qualidade de software
a garantir a qualidade do produto
Estrutura de decomposio de Determina as subtarefas necessrias
trabalho para o desenvolvimento do produto
Determina como o software dever
Projeto
prover as funcionalidades
Projeto arquitetural Projeta a estrutura do sistema
Especifica as interfaces entre as
Projeto de interface
partes do sistema
Projeta os algoritmos para cada
Projeto detalhado
parte
Implementao Construo do software
Execuo do software com dados
Teste para ajudar a garantir que o software
funciona corretamente
Prov o cliente com uma soluo
Entrega
eficiente
Torna o software disponvel no
Instalao
ambiente operacional do cliente
Treinamento Ensina o usurio a operar o software
Manuteno Atualizao e evoluo do software
3
Engenharia de software Modelos clssicos para desenvolvimento de
Software
 para garantir usabilidade constante

A seguir, sero apresentados alguns modelos de processo utilizados

no desenvolvimento de software, tais como cascata, prototipao,
incremental, espiral e modelo processo unificado (RUP).
Em 1970, proposta do modelo cascata deu incio a concordncia em
termos dos mtodos a serem usados no desenvolvimento de software. Desde
ento, ao longo dos anos muitos modelos tm sido propostos, refletindo a
grande variedade de interpretaes e caminhos que podem ser tomados no
desenvolvimento de software.
Os modelos de processo de software definem conjuntos distintos de
atividades, aes, tarefas, marcos e produtos de trabalho que so
necessrios para fazer Engenharia de Software com alta qualidade. Esses
modelos efetivamente fornecem um procedimento til para o trabalho da
Engenharia de Software.
Engenheiros de software adaptam um modelo de processo s suas
necessidades e depois o seguem. Isso importante, pois fornece
estabilidade, controle e organizao a uma atividade que, se deixada sem
controle, pode tornar-se bastante catica. Cada modelo deve ser adaptado
para que seja usado efetivamente em um projeto de software especfico.

Modelo cascata

O modelo mostrado na figura 1 chamado de modelo cascata, j que

o seu diagrama parece com uma srie de cascatas. Inicialmente descrito por
Royce em 1970, foi a primeira realizao de uma sequncia padro de
tarefas.
Anlise de
viabilidade
Anlise de
requisitos
Projeto
Codificao
Testes
Manuteno

Figura 1. Modelo cascata.

Adaptado de Gustafson (2003).
4
Engenharia de software Modelos clssicos para desenvolvimento de
Software
 Na anlise de viabilidade desse modelo:
So produzidos escopo do sistema ou avalia o sistema
atualmente em uso;
So estabelecidas metas e objetivos do sistema;
decidida a viabilidade de automatizar (estima-se tempo e
recurso).

A anlise de viabilidade envolve a anlise de alto nvel: coleta de

requisitos em nvel macro do sistema e pequena quantidade de projeto. Esta
viso essencial quando o software deve fazer interface com outros
elementos (hardware, pessoas e banco de dados). Como resultado, obtm-se
o estudo de viabilidade do desenvolvimento do software.

Na anlise e especificao de requisitos desse modelo so obtidos:

Definio dos dados e funes: documentos como lista de
eventos, descrio de propsitos, diagrama de contexto etc.
Nessa fase, faz-se uso de uma ferramenta de modelagem;
Refinamento das relaes custo-benefcio e das estimativas de
recursos.

Nessa fase, deve-se compreender o domnio da informao, a funo,

o desempenho e interfaces exigidos. Como resultado, obtm-se o documento
de especificao de requisitos de software.

O projeto do modelo cascata definido por quatro atributos: estrutura

de dados, arquitetura de software, detalhes procedimentais e caracterizao
de interfaces. Alm disso, so obtidos:
Definio da arquitetura por meio das definies dos mdulos
do sistema, relacionamentos entre mdulos e transformao do
modelo de dados em base de dados;
Modelo de interface homem-mquina;
Elaborao do plano de testes.

Como resultado dessa fase, obtm-se a especificao de projeto de

software.

Na codificao desse modelo, ocorre a transformao em linguagem

5
Engenharia de software Modelos clssicos para desenvolvimento de
Software
de programao, e geralmente utilizada a tcnica de programao
estruturada. O resultado dessa fase so listagens do programa-fonte (cdigo-
fonte).

Nos testes desse modelo, realizam-se a comparao do sistema com

sua especificao, verificam-se o funcionamento interno e externo do
programa para garantir que todas as instrues tenham sido testadas nos
aspectos funcionais do sistema. Tambm feita a instalao do software. O
resultado dessa fase o sistema testado e instalado.

Para refletir: fase de teste do modelo

cascata
Conforme pode ser observado na figura 1, algo interessante a cada uma das
fases do modelo cascata so os testes. Os testes no formam uma fase
distinta a ser realizada apenas aps o produto ter sido construdo nem devem
ser realizados apenas no final de cada fase. Em vez disso, devem ser
contnuos ao longo do processo de desenvolvimento do software.

A fase de manuteno desse modelo trata das mudanas no software

depois de entregue ao cliente. So vrias as causas de manuteno: erros,
exigncia do cliente para acrscimos funcionais e de desempenho,
mudanas na plataforma de software/hardware, evoluo do negcio etc. O
resultado dessa fase so modificaes nos programas e nos documentos.
O modelo cascata apresenta vrios pontos fortes, entre os quais o
cumprimento do enfoque rigoroso, ou seja, a estipulao de que deve ser
fornecida documentao de cada fase, e a exigncia de que todos os
produtos de cada fase (inclusive a documentao) sejam verificados
meticulosamente.
Por outro lado, entre os problemas que algumas vezes so
encontrados quando o modelo em cascata aplicado, esto (PRESSMAN,
2006):
Projetos reais raramente seguem o fluxo sequencial que o modelo
prope. Apesar de o modelo linear poder acomodar a iterao, ele
o faz indiretamente. Como resultado, as modificaes podem
causar confuso, medida que a equipe de projeto prossegue;
Em geral, difcil para o cliente estabelecer logo no incio do
projeto todos os requisitos explicitamente. O modelo em cascata
6
Engenharia de software Modelos clssicos para desenvolvimento de
Software
 exige isso e tem dificuldade de acomodar a incerteza natural que
existe no comeo de muitos projetos;
cliente precisa ter pacincia. Uma verso executvel do(s)
programa(s) no vai ficar disponvel at o perodo final do intervalo
de tempo do projeto. Um erro grosseiro pode ser desastroso se no
for detectado at que o programa executvel seja revisto.

Em uma anlise criteriosa de projetos reais, Bradac et al. (1994)

descobriram que a natureza linear do modelo cascata leva a estados de
bloqueio nos quais alguns membros da equipe de projeto precisam esperar
que outros membros completem as tarefas dependentes. Na realidade, o
tempo gasto em espera pode exceder o tempo gasto no trabalho produtivo. O
estado de bloqueio tende a ocorrer mais no incio e no fim de um processo
sequencial linear (PRESSMAN, 2006).
Finalmente, Sommerville (2007) sugere que o modelo cascata deve
ser usado apenas quando os requisitos forem bem compreendidos e houver
pouca probabilidade de mudanas radicais durante o desenvolvimento do
sistema.

Modelo prototipao

Obter
requisitos

Elaborar
projeto rpido
Refinamento do
prottipo

Construir
Avaliar prottipo
prottipo

Figura 2. Modelo de prototipao.

Adaptado de PRESSMAN (2006).
7
Engenharia de software Modelos clssicos para desenvolvimento de
Software
 Frequentemente, o cliente define um conjunto de objetivos gerais para
o software, mas no identifica detalhadamente requisitos de entrada,
processamento ou sada. Apesar de a prototipagem (Figura 2) poder ser
usada como um modelo de processo independente, ela mais comumente
usada como uma tcnica que pode ser implementada dentro do contexto de
qualquer um dos modelos de processo apresentados neste material.
Independentemente da maneira como aplicado, o modelo prototipao
auxilia o engenheiro de software e o cliente a entenderem melhor o que deve
ser construdo quando os requisitos esto confusos (PRESSMAN, 2006).
Esse modelo inicia-se com a obteno de requisitos. O engenheiro de
software e o cliente encontram-se e definem os objetivos gerais do software,
identificam as necessidades conhecidas e delineiam reas que necessitam
de mais definies. Uma iterao de prototipagem planejada rapidamente e
a modelagem (na forma de um projeto rpido) ocorre. O projeto rpido
concentra-se na representao daqueles aspectos do software que estaro
visveis para o cliente/usurio (por exemplo, layout da interface com o usurio
ou formatos de sada de tela). O projeto rpido leva construo de um
prottipo que implantado e depois avaliado pelo cliente/usurio. O feedback
usado para refinar os requisitos do software. A iterao ocorre medida
que o prottipo ajustado para satisfazer s necessidades do cliente, e, ao
mesmo tempo, permite ao desenvolvedor entender melhor o que precisa ser
feito (PRESSMAN, 2006).
Mas o que fazer com o prottipo quando ele tiver cumprido a finalidade
descrita? Brooks (1975) fornece a resposta:
Na maioria dos projetos, o primeiro
sistema construdo consegue ser apenas
utilizvel. Pode ser muito lento, muito grande,
muito complicado de usar, ou tudo isso ao
mesmo tempo. No h alternativa seno
comear de novo e construir uma verso
reprojetada, na qual esses problemas so
resolvidos... Quando um novo conceito de
sistema ou uma nova tecnologia usada deve-
se construir um sistema para ser descartado,
porque nem mesmo o melhor planejamento
to onisciente para fazer certo na primeira vez.
A questo de gerencia, entretanto, no se o
sistema piloto elaborado deve ser descartado.
Ele ser. A nica questo planejar
antecipadamente a construo de um
descartvel, ou prometer entregar o software
8
Engenharia de software Modelos clssicos para desenvolvimento de
Software
 descartvel aos clientes.

O prottipo pode servir como o primeiro sistema, aquele que Brooks

recomenda que se descarte. Mas essa pode ser uma viso idealizada.
verdade que tanto clientes quanto desenvolvedores gostam do modelo de
prototipagem. Os usurios tm o sabor de um sistema real e os
desenvolvedores conseguem construir algo imediatamente. Ainda assim, a
prototipagem pode ser problemtica pelas seguintes razes (PRESSMAN,
2006):
Incerteza de conhecer no incio do desenvolvimento quanto
tempo levar para construir um produto aceitvel;
cliente v o produto (prottipo), como a verso final
(executvel);
desenvolvedor frequentemente faz uma implementao
comprometida (utilizando o que est disponvel) com o objetivo
de produzir rapidamente um prottipo;
Dificilmente utilizado para o desenvolvimento completo do
software, geralmente utilizado somente na fase inicial.

recomendada a utilizao do modelo prototipao quando os

clientes definem um conjunto de objetivos gerais para o software, porm no
identificam os requisitos detalhados de entrada-processo-sada. E ainda,
quando o desenvolvedor pode no estar seguro da eficcia de um algoritmo,
da capacidade de usabilidade do sistema ou da funcionalidade do software.
Finalmente, ainda que possam ocorrer problemas, a prototipao um
modelo de processo de software eficiente. A chave definirem-se as regras
do jogo logo no comeo do projeto. O cliente e o desenvolvedor devem
concordar que o prottipo seja construdo para servir como um mecanismo a
fim de definir os requisitos.

Fique atento
Resista presso de aperfeioar um prottipo malfeito para torn-lo um
produto de produo. A qualidade quase sempre sofre com o resultado
(PRESSMAN, 2006).

Modelo espiral
9
Engenharia de software Modelos clssicos para desenvolvimento de
Software
 O modelo espiral (Figura 3), originalmente proposto por Boehm
(1988), um modelo de processo de software que combina a natureza
iterativa da prototipagem com os aspectos controlados e sistemticos do
modelo em cascata. Ele fornece o potencial para o desenvolvimento rpido
de verses de software cada vez mais completas (PRESSMAN, 2006).
O modelo espiral de desenvolvimento um modelo de processo
guiado por riscos. usado para guiar a engenharia de sistema de software
com vrios interessados concorrentes. Ele tem duas principais caractersticas
distintas. A primeira uma abordagem cclica, para aumentar
incrementalmente o grau de definio de um sistema enquanto diminui seu
grau de risco. A outra um conjunto de marcos de ancoragem, para garantir
o comprometimento dos interessados com solues exequveis e
mutuamente satisfatrias para o sistema (BOEHM, 1988).

Figura 3. Modelo espiral (SOMMERVILLE, 2007).

Usando esse modelo, o software desenvolvido em uma srie de

verses evolucionrias. Durante as primeiras iteraes, as verses podem
ser um modelo de papel ou prottipo. Durante as ltimas iteraes, so
produzidas verses cada vez mais completas do sistema submetido
engenharia.

10
Engenharia de software Modelos clssicos para desenvolvimento de
Software
Saiba mais
O modelo espiral pode ser adaptado para ser aplicado ao longo de todo o
ciclo de vida de uma aplicao, desde o desenvolvimento conceitual at a
manuteno (PRESSMAN, 2006).

Um modelo espiral dividido em um conjunto de atividades de

arcabouo definidas pela equipe de Engenharia de Software. medida que
esse processo comea, a equipe de software realiza atividades que so
indicadas por um circuito em volta da espiral em sentido horrio, comeando
pelo centro. O risco considerado medida que cada evoluo feita. Os
marcos de ancoragem uma combinao de produtos de trabalho e
condies que so obtidas ao longo do caminho da espiral so indicados
para cada passagem evolucionria (cada volta). O primeiro circuito em torno
da espiral poderia resultar no desenvolvimento da especificao de um
produto; passagens subsequentes em torno da espiral poderiam ser usadas
para desenvolver um prottipo e depois, progressivamente, verses mais
sofisticadas do software. Cada passagem pela regio de planejamento
resulta em ajustes do plano do projeto. O custo e o cronograma so
ajustados com base no feedback derivado do cliente aps a entrega. Alm
disso, o gerente do projeto ajusta o nmero planejado de iteraes
necessrias para completar o software (PRESSMAN, 2006).
Diferentemente de outros modelos, que terminam quando o software
entregue, o modelo espiral pode ser adaptado para aplicao ao longo da
vida do software. Assim, o primeiro circuito em volta da espiral poderia
representar um projeto de desenvolvimento de conceitos que comea no
centro da espiral e continua por vrias iteraes at o desenvolvimento do
conceito ser completado. Se o conceito for desenvolvido em um produto real,
o processo prossegue para fora na espiral e um projeto de desenvolvimento
de novo produto comea (PRESSMAN, 2006).
O modelo espiral uma abordagem realstica do
desenvolvimento de sistemas e softwares de grande porte. Como o software
evolui medida que o processo avana, o desenvolvedor e o cliente
entendem melhor e reagem aos riscos de cada nvel evolucionrio. O modelo
espiral usa a prototipagem como um mecanismo de reduo de risco, porm,
mais importante, permite ao desenvolvedor aplicar a abordagem de
prototipagem em qualquer estgio da evoluo do produto (PRESSMAN,
2006).
No entanto, como outros modelos, o modelo espiral no to
facilmente aceito. Pode ser difcil convencer os clientes (particularmente, em
11
Engenharia de software Modelos clssicos para desenvolvimento de
Software
situaes de contrato), que a abordagem evolucionria controlvel. Ela
exige competncia considervel na avaliao de riscos e depende dessa
competncia para ter sucesso. Se um risco importante no for descoberto e
gerenciado, fatalmente ocorrero problemas (PRESSMAN, 2006).

Fique atento
Se sua gerncia exige desenvolvimento com oramento fixo (geralmente uma
m ideia), o modelo espiral pode ser um problema: medida que cada
circuito completado, o custo do projeto revisado.

Modelo incremental

O modelo incremental combina elementos do modelo em cascata

aplicado de maneira iterativa. Como mostra a figura 4, o modelo incremental
aplica sequncias lineares de uma forma racional medida que o tempo
passa. Cada sequncia linear produz incrementos do software passveis de
serem entregues (MCDERMID, 1993).

Figura 4. Modelo incremental (PRESSMAN, 2006).

Para um melhor entendimento deste modelo, Pressman (2006) ilustra

um exemplo: softwares de processamento de texto desenvolvidos segundo
12
Engenharia de software Modelos clssicos para desenvolvimento de
Software
este modelo poderiam entregar a gesto bsica de arquivos, edio e
produo de documentos no primeiro incremento; capacidades de edio e
de produo de documentos mais sofisticados no segundo incremento;
verificao ortogrfica e gramatical no terceiro incremento; e capacidade
avanada de disposio de pginas no quarto incremento. Deve-se notar que
o fluxo de processo para qualquer incremento pode incorporar o conceito de
prototipagem discutido anteriormente.
Quando um modelo incremental usado, o primeiro incremento
frequentemente chamado de ncleo do produto. Isto , os requisitos
bsicos so satisfeitos, mas muitas caractersticas suplementares (algumas
conhecidas, outras desconhecidas) deixam de ser elaboradas. O ncleo do
produto usado pelo cliente (ou passa por reviso detalhada). Um plano
desenvolvido para o prximo incremento como resultado do uso e/ou
avaliao. O plano visa modificao do ncleo do produto para melhor
satisfazer s necessidades do cliente e elaborao de caractersticas e
funcionalidades adicionais. Esse processo repetido aps a realizao de
cada incremento, at que o produto completo seja produzido. O modelo
incremental iterativo por natureza. Mas, diferentemente da prototipagem, o
modelo incremental tem o objetivo de apresentar um produto operacional a
cada incremento. Os primeiros incrementos so verses simplificadas do
produto final, mas oferecem capacidades que servem ao usurio, alm de
uma plataforma para a avaliao do usurio (PRESSMAN, 2006).
O desenvolvimento incremental particularmente til quando
no h mo de obra disponvel para uma implementao completa, dentro do
prazo comercial de entrega estabelecida para o projeto. Os primeiros
incrementos podem ser implementados com menos pessoal. Se o ncleo do
produto for bem recebido, ento pessoal extra (se necessrio) pode ser
adicionado para implementar o prximo incremento. Alm disso, os
incrementos podem ser planejados para gerir os riscos tcnicos. Por
exemplo, um sistema importante pode exigir a disponibilidade de um
hardware novo, que est em desenvolvimento, e cuja data de entrega
incerta. Pode ser possvel planejar os primeiros incrementos de modo que
seja evitado o uso desse hardware, permitindo, assim, que uma parte da
funcionalidade seja entregue aos usurios finais sem demora excessiva
(PRESSMAN, 2006).

Lembre-se

13
Engenharia de software Modelos clssicos para desenvolvimento de
Software
O modelo incremental entrega uma srie de verses, chamadas de
incrementos, que fornecem progressivamente mais funcionalidade para os
clientes medida que cada incremento entregue (PRESSMAN, 2006).

Modelo processo unificado

O rational unified process (RUP) um exemplo de modelo de

processo moderno que foi derivado do trabalho sobre UML (unified modeling
language) e do processo unificado de desenvolvimento de software
associado (RUMBAUGH et al., 1999). Ele um bom exemplo de modelo
hbrido de processo, traz elementos de todos os modelos genricos de
processo (conforme alguns deles foram estudados nos tpicos anteriores),
apoia a iterao e ilustra boas prticas de especificao e projeto. Por outro
lado, o RUP geralmente descrito a partir de trs perspectivas
(SOMMERVILLE, 2007):
Uma perspectiva dinmica, que mostra as fases do modelo ao
longo do tempo;
Uma perspectiva esttica, que mostra as atividades realizadas
no processo;
Uma perspectiva prtica, que sugere as boas prticas a serem
utilizadas durante o processo.

O RUP um modelo que identifica quatro fases discretas no processo

de software. No entanto, ao contrrio do modelo cascata, no qual as fases
coincidem com as atividades do processo, as fases do RUP esto
relacionadas mais estritamente aos negcios do que a assuntos tcnicos
(SOMMERVILLE, 2007).
A figura 5 mostra as fases do RUP.

Figura 5. Ilustrao do RUP (SOMMERVILLE, 2007).

A fase de concepo tem como objetivo estabelecer um business

case para o sistema. Voc deve identificar todas as entidades externas

14
Engenharia de software Modelos clssicos para desenvolvimento de
Software
(pessoas e sistemas), que iro interagir com o sistema, definir essas
interaes. Depois voc usa essas informaes para avaliar a contribuio do
sistema com o negcio. Se a contribuio for de pouca importncia, o projeto
pode ser cancelado depois dessa fase (SOMMERVILLE, 2007).
Os objetivos da fase de elaborao so desenvolver um entendimento
do domnio do problema, estabelecer um framework de arquitetura para o
sistema, desenvolver o plano de projeto e identificar os riscos principais do
projeto. Ao concluir essa fase, voc deve ter modelo de requisitos para o
sistema (os casos de uso da UML so especificados), uma descrio de
arquitetura e um plano de desenvolvimento para o software (SOMMERVILLE,
2007).
A fase de construo est essencialmente relacionada ao projeto,
programao e teste do sistema. As partes do sistema so desenvolvidas
paralelamente e integradas durante essa fase. Ao concluir essa fase, voc
deve ter um sistema de software em funcionamento e a documentao
associada pronta para ser liberada aos usurios (SOMMERVILLE, 2007).
A fase de transio a fase final do RUP e est relacionada
transferncia do sistema da comunidade de desenvolvimento para a
comunidade dos usurios e com a entrada do sistema em funcionamento no
ambiente real. Isso algo ignorado na maioria dos modelos de processo de
software, mas , de fato, uma atividade onerosa e, s vezes, problemtica.
Ao concluir essa fase, voc dever ter um sistema de software documentado,
funcionando corretamente em seu ambiente operacional (SOMMERVILLE,
2007).
A iterao no RUP considerada em duas formas, como apresentada
na figura 5. Cada fase pode ser realizada de forma interativa, com os
resultados desenvolvidos incrementalmente. Alm disso, o conjunto total de
fases pode tambm ser realizado de forma incremental, conforme
apresentado pela seta, retornando da transio para a concepo, na figura 5
(SOMMERVILLE, 2007).
A viso esttica do RUP enfoca as atividades que ocorrem
durante o processo de desenvolvimento. Elas so chamadas de workflows na
descrio RUP. Existem seis workflows de processo principais identificados e
trs workflows de apoio principais. O RUP foi projetado em conjunto com a
UML linguagem de modelagem unificada orientada a objetos e, por isso,
a descrio dos workflows orientada em termos dos modelos UML
associados. Os principais workflows de engenharia e de apoio esto
descritos na tabela 2 (SOMMERVILLE, 2007).
A vantagem de apresentar as vises estticas e dinmicas
que as fases do processo de desenvolvimento no esto associadas aos
workflows especficos. Em princpio, todos os workflows do RUP podem ser
15
Engenharia de software Modelos clssicos para desenvolvimento de
Software
ativados em todos os estgios do processo. Naturalmente, a maior parte do
esforo ser provavelmente despendida nos workflows como modelagem de
negcios e requisitos, nas fases iniciais do processo e no teste e
implementao nas fases posteriores (SOMMERVILLE, 2007).

Tabela 2. Workflows estticos no rational unified process

(SOMMERVILLE,2007)
Workflow Descrio
Os processos de negcio so modelados
Modelagem de negcio
usando casos de uso de negcios
Os agentes que interagem com o sistema so
Requisitos identificados e os casos de uso so desenvolvidos para
modelar os requisitos de sistema
Um modelo de projeto criado e documentado
Anlise e projeto usando modelos de arquitetura, de componente, de
objeto e de sequncia
Os componentes de sistema so implementados
e estruturados em subsistemas de implementao. A
Implementao
gerao automtica de cdigo com base nos modelos
de projeto ajuda a acelerar esse processo
O teste um processo iterativo realizado em
Teste conjunto com a implementao. O teste de sistema
segue o trmino da implementao
Uma verso do produto criada, distribuda aos
Implantao
usurios e instalada no local de trabalho
Gerenciamento de Este workflow de apoio gerencia as mudanas
configurao e mudanas do sistema
Gerenciamento de Este workflow de apoio gerencia o
projetos desenvolvimento do sistema
Este workflow est relacionado
Ambiente disponibilizao de ferramentas apropriadas de software
para a equipe de desenvolvimento

BIBLIOGRAFIA BSICA

BOEHM, Barry W. A spiral model for software development and

enhancement. Computer, [S.l.], p. 61-72, mai. 1988.

BRADAC, Mark G.; PERRY, Dewayne E.; VOTTA, Lawrence G. Prototyping a

process monitoring experiment. IEEE Transactions on Software Engineering,
[S.l.], v. 20, n. 10, p.774-784, out. 1994.
16
Engenharia de software Modelos clssicos para desenvolvimento de
Software
BROOKS, Frederick. The mythical man-month. 1. ed. Massachusetts:
Addison-Wesley, 1975.

GUSTAFSON, David A. Engenharia de software. [S.l.]: Bookman, 2003.

JACOBSON, Ivar; RUMBAUGH, James; BOOCH, Grady. The unified

software development process. Massachusetts: Addison-Wesley, 1999.

McDERMID, John; ROOK, Paul. Software development process models.

Software Engineers Reference Book, CRC Press, p. 15/26-15/28, 1993.

PRESSMAN, Roger S. Engenharia de software. 6. ed. [S.l.]: McGraw Hill

Interamericana, 2006.

SOMMERVILLE, Ian. Engenharia de software. 6. ed. So Paulo: Addison-

Wesley, 2003.

________________. Engenharia de software, 8. ed. So Paulo: Addison-

Wesley, 2007.

BIBLIOGRAFIA COMPLEMENTAR

IEEE The world's largest professional association for the advancement of

technology. Disponvel em: <http://www.ieee.org/>. Acesso em: 12 fev. 2013.

KRUCHTEN, Philippe. The rational unified process: an introduction. 2. ed.

Massachusets: Addison-Wesley, 2000.

PFLEEGER, Shari Lawrence. Software engineering: theory and practice. 2.

ed. New Jersey: Prentice-Hall, 2001.

PRIESTLEY, Michael; UTT, Mary Hunter. A unified process for software and
documentation development. In: 18th annual ACM International Conference
on Computer Documentation: Technology & Teamwork, p. 231-238, 2000.

ROGGIO, Robert F. A model for the software engineering capstone sequence

17
Engenharia de software Modelos clssicos para desenvolvimento de
Software
using rational unified process. In: 44th annual Southeast regional conference,
p. 306-311, 2006.

R.S. PRESSMAN & ASSOCIATES, INC. Products that improve your software
engineering practices. Disponvel em: <http://www.rspa.com>. Acesso em: 12
fev. 2013.

18
Engenharia de software Modelos clssicos para desenvolvimento de
Software