Tópicos

Por que Iterar?

Tradicionalmente, os projetos foram organizados para percorrer cada disciplina em seqüência apenas uma vez. Isso leva ao ciclo de vida em cascata:

Diagrama mostra uma iteração indo da Modelagem de Negócios para Implementação

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. Isso se chama ciclo de vida iterativo. Cada passagem através da seqüência de disciplinas do processo chama-se iteração.

Diagrama mostra 3 iterações sucessivas, cada uma indo da Modelagem de Negócios para Implementação.

Portanto, de uma perspectiva de desenvolvimento o ciclo de vida do software é uma sucessão de iterações, através da qual o software é desenvolvido incrementalmente. Cada iteração é concluída com o release 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 por artefatos de suporte: descrição do release, documentação do usuário, planos, e assim por diante, e os modelos atualizados do sistema.

A conseqüência principal dessa abordagem iterativa é que osconjuntos de artefatos, descritos anteriormente, crescem e amadurecem com o tempo, conforme mostrado no seguinte diagrama.

Evolução do conjunto de informações ao longo das fases de desenvolvimento.

O Que É uma Iteração? Para o início da página

Uma iteração envolve as atividades de desenvolvimento que levam ao release de um produto - uma versão estável e executável do produto, junto com qualquer outro elemento periférico necessário para utilizar esse release. Portanto, uma iteração de desenvolvimento é, de alguma forma, uma passagem completa por pelo menos todas as disciplinas: 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 variará de acordo com o tamanho e a natureza do projeto, mas é provável que várias construções sejam feitas em cada iteração, conforme especificado no Plano de Construção de Integração para a iteração. Essa é uma conseqüência da abordagem de integração contínua recomendada no RUP (Rational Unified Process): conforme os componentes testados da unidade ficam disponíveis, eles são integrados, em seguida, uma construção é produzida e sujeita 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 fazer construções diariamente, mas isso não representará as iterações como o RUP as 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.

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. Os releases agem como uma função imposta que conduz a equipe de desenvolvimento a encerrar em intervalos regulares, evitando a síndrome de "90% concluídos, 90% restantes".

As iterações e os releases permitem com o tempo um uso melhor das várias especialidades na equipe; designers, testadores, escritores e assim por diante. 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. Diz-se que isso é como um 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.

Iteração e FasesPara o início da página

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 Para o início da página

"A estratégia incremental determina as necessidades do usuário e define os requisitos do sistema e, em seguida, executa 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:

  • 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

Diagrama descrito no texto associado.

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 Evolucionário Para o início da página

"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:

  • 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

Diagrama descrito no texto associado.

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 deEntrega Incremental Para o início da página

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:

  • 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

Diagrama descrito no texto associado.

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.

Padrão de Iteração: Ciclo de Vida "Design Design" Para início da Global

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 é chamada "design global" 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

Diagrama descrito no texto associado.

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

Padrão de Iteração: Estratégias Híbridas Para início da página

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:

  • Para domínios complexos ou de problemas não familiares, nos quais há um alto grau de exploração: aumente o número de iterações na fase de elaboração e seu comprimento.
  • Para problemas de desenvolvimento mais complexos, nos quais há complexidade de tradução do design em código: aumente o número de iterações na fase de construção e seu comprimento.
  • Para entregar software em uma série de releases incrementais: aumente o número de iterações na fase de transição e seu comprimento.


Rational Unified Process   2003.06.15