As fases e os marcos de um projeto

Do ponto de vista do gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. À cada final de fase, uma avaliação é executada para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

Fases de Planejamento

As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio tamanho deve prever a seguinte distribuição de esforço e programação:

que pode ser descrito graficamente como

Esta distribuição pode variar. Por exemplo, ferramentas que gerem código e etapas de teste podem diminuir a fase de construção. Além disso, para um ciclo de evolução, as fases de iniciação e de elaboração seriam consideravelmente menores, já que uma visão e arquitetura básicas já estão estabelecidas.

Estratégias de Planejamento

Nesta seção, foo apresentado um número de padrões de ciclo de vida correspondentes aos perfis de projetos comuns.

Padrão de ciclo de vida: Incremental

"A estratégia incremental determina as necessidades do usuário e define os requisitos do sistema e, em seguida, desempenha o restante do desenvolvimento em uma seqüência de construções. A primeira construção incorpora partes dos recursos planejados, a próxima construção inclui mais recursos e assim por diante até o sistema estar completo".[DOD94]

As seguintes iterações são características:

Essa estratégia é apropriada quando:

Padrão de ciclo de vida: Evolutivo

"A estratégia evolucionária difere da incremental ao reconhecer que o as necessidades do usuário não são completamente entendidas e todos os requisitos não podem ser definidos imediatamente, eles são refinados em cada construção sucessiva". [DOD94]

As seguintes iterações são características:

Essa estratégia é apropriada quando:

Padrão de ciclo de vida: Entrega Incremental 

Alguns autores também fizeram em fases as entregas da funcionalidade incremental para o cliente [GIL88]. Isso pode ser necessário quando há pressões de mercado sobre o tempo restrito, onde a liberação antecipada de certos recursos importantes pode render benefícios de negócio significativos.

Em termos da abordagem da iteração de fase, a fase de transição começa cedo e tem a maioria das iterações. Essa estratégia requer uma arquitetura bastante estável, que é difícil de se conseguir em um ciclo de desenvolvimento inicial, para um sistema "sem precedentes".

As seguintes iterações são características:

Essa estratégia é apropriada quando:

Padrão de ciclo de vida: "Design Grande"

A abordagem em cascata tradicional pode ser vista como um caso degenerado em que há apenas uma iteração na fase de construção. Chamado "design grande" em [DOD94]. Na prática, é difícil evitar iterações adicionais na fase de transição.

As seguintes iterações são características:

Essa estratégia é apropriada quando:

Padrão de ciclo de vida: Estratégias Híbridas

Na prática, poucos projetos seguem estritamente uma estratégia. Você freqüentemente acaba com uma evolução híbrida, no início, uma construção incremental e várias entregas. Uma das vantagens do modelo de iteração de fase é que ele permite acomodar uma abordagem híbrida, simplesmente aumentando o tamanho e o número de iterações em determinadas fases:

Movendo de Um Ciclo para o Próximo

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases. Esses ciclos subseqüentes são chamados ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante. Normalmente, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto foram determinadas pelos ciclos de desenvolvimento anteriores.    São exceções a essa regra os ciclos de evolução, em que ocorre uma redefinição significativa do produto ou da arquitetura.