O Modelo Incremental

Ricardo Dias
Contexto Delimitado
4 min readAug 22, 2019

O Modelo Incremental surge como uma melhoria do Modelo em Cascata. Ao invés de especificar e desenvolver tudo de uma só vez, este modelo trabalha com incrementos, ou seja, pequenos pedaços de software entregues de cada vez. Este modelo combina elementos do Modelo em Cascata aplicados de maneira iterativa, ou seja, de forma que o progresso aconteça através de sucessivos refinamentos, melhorados a cada iteração. (PRESSMAN, 2006).

Cada pedaço (incremento) é desenvolvido de forma linear, como no Modelo em Cascata, e em seguida exposto aos comentários dos clientes (SOMMERVILLE, 2011). Caso seja necessário alterar algo nessa implementação, é desenvolvido um novo incremento e o resultado é novamente apresentado.

O modelo incremental

O primeiro incremento é frequentemente chamado de “núcleo do produto” (PRESSMAN, 2006) e contém a implementação dos requisitos básicos para que o sistema possa funcionar e atender minimamente as necessidades do cliente.

Cada aprimoramento é lançado como uma versão. Novas versões são criadas até que o sistema fique completo e adequado, para então, ser lançada a versão final.

Todavia, diferente do Modelo em Cascata, onde cada etapa tem sua vez para acontecer e, ao término de todas, o projeto termina, no Modelo Incremental as atividades de Especificação, Projeto, Implementação e Validação são intercaladas, acontecendo em cada nova versão, com rápido feedback entre todas as atividades (SOMMERVILLE, 2011).

Os clientes podem estabelecer as prioridades das partes do sistema a serem desenvolvidas, especificando as mais úteis primeiro. Após o cliente estabelecer as funcionalidades necessárias, são criados os estágios (incrementos) de entrega, onde cada estágio fornece um conjunto de funcionalidades do sistema.

Vantagens

  • É particularmente útil quando não há mão-de-obra disponível para uma implementação completa, dentro do prazo comercial de entrega estabelecido pelo projeto (PRESSMAN, 2006);
  • O cliente não precisa receber todo o sistema para poder usá-lo. Como a implementação é feita por pedaços ordenados por prioridades, o cliente pode ter acesso às partes mais importantes antes, podendo utilizá-las imediatamente;
  • “O custo de acomodar as mudanças nos requisitos do cliente é reduzido”. (SOMMERVILLE, 2011) A quantidade de análise e documentação a ser refeita é muito menor do que o necessário no modelo em cascata.
  • É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução por meio de documentos de projeto de software.
  • Para PRESSMAN (2006) e SOMMERVILLE (2011), é possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se todas as funcionalidades não forem incluídas. Os clientes podem usar e obter ganhos a partir do software inicial antes do que seria possível com um processo em cascata.

Desvantagens

  • Os problemas são particularmente críticos para os sistemas grandes, complexos e com vida-longa, onde várias equipes desenvolvem diferentes partes do sistema;
  • Sistemas de grande porte necessitam de um framework ou arquitetura estável, e as responsabilidades das diferentes equipes de trabalho do sistema precisam ser claramente definidas, respeitando essa arquitetura. Segundo SOMMERVILLE (2011), essa parte deve ser planejada com antecedência, e não pode ser desenvolvida de forma incremental;

SOMMERVILLE (2011) aponta dois problemas no modelo incremental.

  • O primeiro problema é que o progresso não é visível e os gerentes precisam de entregas regulares para mensurar o progresso. Se os sistemas forem desenvolvidos com rapidez, não será economicamente viável produzir documentos que reflitam cada uma das versões do sistema;
  • O segundo problema é que a estrutura do sistema tende a se degradar com a adição dos novos incrementos. Tempo e dinheiro devem ser direcionados para refatoração e melhorias do software, pois as constantes mudanças sem previsão do futuro tendem a corromper sua estrutura. A incorporação de mudanças do software torna-se cada vez mais difícil e custosa.

Nos próximos artigos serão abordados outros modelos de processo de software. Espero que o conteúdo seja útil. Um grande abraço e até a próxima!

Leia também o próximo artigo sobre o assunto:

Leia todos os artigos desta série:

Referências para aprofundamento

PRESSMAN, Roger. S. Engenharia de Software, 6ª Edição. McGrawHill, Nova York, EUA, 2006

SOMMERVILLE, Ian. Engenharia de Software, 9ª Edição. Pearson. São Paulo, Brasil, 2011.

--

--

Ricardo Dias
Contexto Delimitado

Apaixonado por padrões, programação clara, elegante e principalmente manutenível. Trabalha como desenvolvedor deste 2000, incrementando a cada ano este loop…