Conceitos: Iteração
Tópicos
Tradicionalmente, os projetos foram organizados para percorrer cada disciplina em seqüência apenas uma vez. Esse procedimento conduz ao ciclo de vida cascata:
Freqüentemente, ele resulta em um acúmulo de integração tardia na implementação, quando, pela primeira vez, o produto é criado e o teste começa. Aparecem os problemas que permaneceram ocultos por todo o processo de Análise, Design e Implementação, e o projeto é paralisado enquanto começa um longo ciclo de correção de erros.
Uma maneira mais flexível (e menos arriscada) de continuar é percorrer várias vezes as diversas disciplinas de desenvolvimento, construindo um melhor entendimento dos requisitos, planejando uma arquitetura robusta, elevando a organização do desenvolvimento e, por fim, liberando uma série de implementações que são gradualmente mais completas. Esse procedimento chama-se ciclo de vida iterativo. A cada passagem, a seqüência de disciplinas do processo chama-se iteração.
Portanto, do ponto de vista do desenvolvimento, o ciclo de vida do software é uma sucessão de iterações, por meio das quais o software se desenvolve de maneira incremental. Cada iteração termina com a liberação de um produto executável. Esse produto pode ser um subconjunto da visão completa, mas mesmo assim ser útil do ponto de vista da engenharia ou do usuário. Cada release é acompanhado de artefatos de suporte: descrição do release, documentação do usuário, planos etc., bem como modelos atualizados do sistema.
A principal conseqüência dessa abordagem iterativa é que os conjuntos de artefatos, descritos anteriormente, crescem e amadurecem o tempo todo, como mostra o diagrama a seguir.
Evolução do conjunto de informações ao longo das fases de desenvolvimento.
Uma iteração abrange as atividades de desenvolvimento que conduzem à liberaçãode um produto—uma versão do produto estável e executável, junto com qualquer outro elemento periférico necessário para usar esse release. Portanto, uma iteração de desenvolvimento é de certa forma uma passagem completa por todas as disciplinas: pelo menos Requisitos, Análise & Design, Implementação e Teste. É como um pequeno projeto cascata em si mesmo. Observe que os critérios de avaliação são estabelecidos quando cada iteração é planejada. O release terá planejado a capacidade que é demonstrável. A duração de uma iteração varia de acordo com o tamanho e a natureza do projeto, mas é provável que vários builds sejam construídos em cada iteração, da maneira especificada no Plano de Integração do Build para a iteração. Isso é uma conseqüência da abordagem de integração contínua recomendada no Rational Unified Process (RUP): quando os componentes testados da unidade ficam disponíveis, eles são integrados e, em seguida, um build é produzido e fica sujeito ao teste de integração. Dessa maneira, a capacidade do software integrado cresce quando a iteração continua, em direção às metas definidas quando a iteração foi planejada. Pode ser demonstrado que cada build representa uma mini-iteração por si mesmo; a diferença está no planejamento necessário e na formalidade da avaliação realizada. Pode ser apropriado e conveniente em alguns projetos construir builds diariamente, mas eles não representam iterações quando o RUP os define—exceto, talvez, para um projeto muito pequeno de uma única pessoa. Mesmo em projetos pequenos com várias pessoas (por exemplo, envolvendo cinco pessoas criando 10.000 linhas de código), seria muito difícil alcançar uma duração de iteração de menos de uma semana. Para obter uma explicação sobre o porquê, consulte Diretrizes: Plano de Desenvolvimento de Software.
Release
Um release pode ser interno ou externo. Um release interno é usado apenas pela organização de desenvolvimento, como parte de um marco, ou para fazer uma demonstração para usuários ou clientes. Um release externo é liberado para os usuários finais. Um release não é necessariamente um produto completo, mas pode ser apenas uma etapa ao longo do caminho, com sua utilidade avaliada apenas do ponto de vista da engenharia. Uma das funções dos releases é forçar a equipe de desenvolvimento a fazer fechamentos em intervalos regulares, evitando a síndrome do "90% pronto, 90% faltando".
Iterações e releases permitem um uso contínuo melhor das várias especialidades da equipe: designers, testadores, escritores etc.. Releases regulares permitem que você fragmente os problemas de integração e teste, e os distribua pelo ciclo de desenvolvimento. Esses problemas freqüentemente são as enxurradas de projetos grandes, porque todos os problemas foram descobertos de uma vez durante a única etapa de integração em massa, que ocorreu muito tarde no ciclo, e onde um único problema detém a equipe toda.
A cada iteração, os artefatos são atualizados. Dizem que isso se parece um pouco com software "em crescimento". Em vez de desenvolver artefatos uns após os outros, como em um pipeline, eles são desenvolvidos através do ciclo, apesar das taxas diferentes.
Marco menor
Cada iteração é concluída por um marco menor, onde o resultado da iteração é avaliado em relação aos critérios de êxito do objetivo dessa iteração específica.
Cada iteração em uma fase resulta em um release executável do sistema.
Cada fase no RUP pode ser ainda mais dividida em iterações. Uma iteração é um loop completo de desenvolvimento que resulta em um release (interno ou externo) de um produto executável, um subconjunto do produto final em desenvolvimento, que cresce por incrementos, a cada iteração, para se tornar o sistema final.
Padrão de iteração: Ciclo de Vida Incremental
"A estratégia incremental determina as necessidades do usuário e define os requisitos do sistema e, em seguida, realiza o restante do desenvolvimento em uma seqüência de builds. O primeiro build incorpora partes das capacidades planejadas, o próximo build adiciona mais capacidades e assim por diante até o sistema estar completo." [DOD94]
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- uma única iteração de Elaboração, durante a qual os requisitos são definidos e a arquitetura estabelecida
- várias iterações de Construção durante as quais os casos de uso são realizados e a arquitetura é aprimorada
- várias iterações de Transição para migrar o produto para a comunidade de usuários
Essa estratégia é apropriada quando:
- O domínio do problema é familiar.
- Os riscos são bem entendidos.
- A equipe do projeto é experiente.
Padrão de iteração: Ciclo de Vida Evolutivo
"A estratégia evolutiva é diferente da incremental, pois reconhece que as necessidades do usuário não são totalmente entendidas e que os requisitos não podem ser definidos antecipadamente, sendo refinados em cada build sucessivo." [DOD94]
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- várias iterações de Elaboração, durante as quais os requisitos são refinados em cada iteração
- uma única iteração de Construção, durante a qual os casos de uso são realizados e a arquitetura é expandida
- várias iterações de Transição para migrar o produto para a comunidade de usuários
Essa estratégia é apropriada quando:
- O domínio do problema é novo ou não é familiar.
- A equipe é inexperiente.
Padrão de iteração: Ciclo de Vida da Liberação Incremental
Alguns autores também definiram em fases as liberações de 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 exige uma arquitetura muito estável, que é difícil de alcançar em um ciclo de desenvolvimento inicial, para um sistema "sem precedentes".
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- uma única iteração de Elaboração, durante a qual é criada uma baseline de arquitetura estável
- uma única iteração de Construção, durante a qual os casos de uso são realizados e a arquitetura é aprimorada
- várias iterações de Transição para migrar o produto para a comunidade de usuários
Essa estratégia é apropriada quando:
- O domínio do problema é familiar:
- a arquitetura e os requisitos podem ser estabilizados antecipadamente no ciclo de desenvolvimento
- há um baixo grau de novidade no problema
- A equipe é experiente.
- Releases incrementais de funcionalidade têm alto valor para o cliente.
A abordagem em cascata tradicional pode ser vista como um caso degenerado em que há apenas uma iteração na fase de construção. Ela se chama "design principal" em [DOD94]. Na prática, é difícil evitar iterações adicionais na fase de transição.
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- uma única iteração muito longa de Construção, durante a qual os casos de uso são realizados e a arquitetura é aprimorada
- várias iterações de Transição para migrar o produto para a comunidade de usuários
Essa estratégia é apropriada quando:
- um pequeno incremento de funcionalidade bem definida está sendo adicionado a um produto muito estável
- a nova funcionalidade é bem definida e bem entendida
- A equipe é experiente, tanto no domínio do problema quando no produto existente
Na prática, poucos projetos seguem estritamente uma estratégia. Freqüentemente, você finaliza com um híbrido, alguma evolução no começo, alguma criação incremental e várias liberações. 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:
- Para domínios de problemas complexos ou não familiares, onde há um alto grau de exploração: aumentar o número de iterações na fase de elaboração e seu tamanho.
- Para problemas de desenvolvimento mais complexos, onde há complexidade na conversão do design em código: aumentar o número de iterações na fase de construção e seu tamanho.
- Para liberar o software em uma série de releases incrementais: aumentar o número de iterações na fase de transição e seu tamanho.
Copyright
(c) 1987 - 2001 Rational Software Corporation
| |
|
