O Processo Unificado (PU) surgiu posteriormente às metodologias citadas acima e propõe um processo de desenvolvimento iterativo e incremental como meio para sanar fragilidades das metodologias anteriores. Baseia-se em refinamentos e incrementos de um sistema por meio de múltiplas iterações contando com o feedback do cliente e com uma adaptação cíclica como principais propulsores para um sistema que se adeque bem aos interesses do cliente. Não há, no Processo Unificado, uma corrida para implementar o software e nem um longo e demorado projeto que tenta resolver todos os problemas antes da programação. Ao fim de cada iteração tem se um sistema executável, mas que ainda não está pronto para ser colocado em produção (LARMAN, 2004).
No processo unificado valoriza-se muito o feedback vindo do cliente. Segundo Larman (2004) a frase “acolha a mudança” (BECK, 2000 apud LARMAN, 2004) mostra a atitude chave do desenvolvimento iterativo. Ao invés de combater a mudança tentando especificá-la completa e corretamente e fazer com que o cliente assine embaixo de um conjunto de requisitos congelados antes da implementação. No processo unificado aceita-se a mudança e passa a considera-la não um problema, mas sim uma realidade.
Essa realimentação contínua vale ouro, ao invés de se especular sobre requisitos ou projetos corretos, aproxima-se com maior precisão do que o cliente realmente precisa. Todavia isso não é uma justificativa para o desenvolvimento caótico e reativo em que continuamente muda-se a direção, é necessário, sempre, manter um meio termo. No Processo Unificado o desenvolvimento progride através de uma série de ciclos estruturados que envolvem construção-realimentação-adaptação. Frequentemente as primeiras iterações de um projeto tendem a ser maiores visto que os requisitos ainda não estão corretamente refinados (LARMAN, 2004).
Larman (2004) enumera uma série de benefícios tragos pelo processo iterativo:
- Mitigação precoce de erros, ao invés de tardiamente e de forma arriscada;
- Progresso visível desde o início do projeto;
- Realimentação, envolvimento do cliente e adaptação imediatos refinando o sistema.
- Administra-se melhor a complexidade evitando uma sobrecarga da equipe de desenvolvimento.
- O aprendizado de uma iteração pode ser aplicado para melhorar o processo de desenvolvimento como um todo.
O processo unificado recomenda pequenas iterações que podem variar de duas a seis semanas. As ideias centrais do processo unificado são, dar pequenos passos, obter feedback rápido e fazer adaptações. Iterações com grandes intervalos de tempo podem prejudicar a motivação da equipe além de aumentarem o risco do projeto.
De acordo com Pressman (2006) é razoável caracterizar as metodologias adotadas nas duas primeiras décadas da Engenharia de Software como a era do “pensamento linear”. A Engenharia de Software, até então, era abordada como uma atividade linear onde a execução de diferentes etapas sequenciais poderia ser utilizada para resolver problemas complexos. Embora essa abordagem seja coerente ela não pode ser empregada sem acarretar nos problemas apontados acima. Para Pressman (2006), apesar das falhas apresentadas por essas metodologias, muitos conceitos criados nesse período são válidos e continuarão sendo utilizados e/ou incorporados em metodologias futuras.
Treinamentos relacionados com essa postagem
Referências:
LARMAN, Craig. Utilizando UML e Padrões: Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Processo Unificado. 2 ed. Porto Alegre: Bookman, 2004.
PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.
