A abordagem de prototipagem é muito útil para o esclarecimento e formalização do projeto.

Esclarecimento, pois tudo o que será desenvolvido será baseado no que for apresentado em forma de telas para os usuários finais; e formalização, pois depois de aprovado o protótipo, você não corre o risco do cliente alegar que achava que determinada funcionalidade estaria no sistema.

Geralmente quando vamos desenvolver um sistema, o cliente define um conjunto de objetivos gerais para o software, mas não identifica detalhadamente requisitos de entrada, processamento e saída.

Nós, desenvolvedores, podemos também estar inseguros da eficiência de um algoritmo ou da forma que a interação homem/máquina deve assumir.

Como este modelo funciona então?

O modelo de prototipagem começa com a definição de requisitos. O desenvolvedor e o cliente se encontram e definem objetivos gerais do software, identificam as necessidades conhecidas e delineiam áreas que necessitam de mais definições.

Um projeto rápido é então realizado.

Esse projeto concentra-se na representação daqueles aspectos de software que vão ficar visíveis ao cliente/usuário (ex: abordagens de entrada e formatos de saída).

O projeto rápido parte de um protótipo. O protótipo é avaliado pelo cliente/usuário e usado para refinar os requisitos do software que será desenvolvido.

Interações ocorrem a medida que o protótipo é ajustado para satisfazer as necessidades do cliente e ao mesmo tempo permite ao desenvolvedor entender o que precisa ser feito.

O protótipo serve como um mecanismo para a identificação dos requisitos do software. APENAS PARA ISSO!

Você pode desenvolver protótipos executáveis se julgar mais adequado. Neste caso, o desenvolvedor tenta usar partes de programas existentes ou aplica ferramentas (geradores de relatórios, gestores de janelas) que permitem que programas executáveis sejam gerados RAPIDAMENTE.

O protótipo pode servir como o primeiro sistema (segundo Pressman cita, a questão não é se ele será descartado. Ele será pois ninguém é capaz de projetar um sistema perfeito na primeira versão).

Esse tipo de abordagem agrada desenvolvedores e clientes.

O fluxo de desenvolvimento funciona da seguinte maneira:

OUVIR O CLIENTE - > CONSTRUIR/REVISAR PROTÓTIPO -> CLIENTE TESTA -> OUVIR O CLIENTE -> ETC...

Ao final do protótipo, temos o sistema todo delineado e já especificado o que deve ser feito.

A partir daí, o protótipo deverá ser utilizado apenas como um documento base para o que deve ser desenvolvido. O desenvolvimento de um software com qualidade começa a partir deste ponto.

Os problemas da prototipagem são:

1) O cliente vê o que parece ser uma versão executável do software, ignorando que o protótipo apenas consegue funcionar precariamente, sem saber que na pressa de fazê-lo rodar, ninguém considerou a sua qualidade global ou a manutenibilidade a longo prazo. O protótipo não deve ser reutilizado, pois foi feito apenas para que os requisitos do sistema fossem compreendidos.

Quando informado que o produto deve ser refeito de modo que altos níveis de qualidade possam ser atingidos, o cliente reclama e exige "alguns consertos", para transformar o protótipo num produto executável. Erroneamente, mas em geral, os desenvolvedores concordam.

2) O desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável. Um sistema operacional ou uma linguagem de programação inapropriada pode ser usado simplesmente por estar disponível e serem conhecidos; um algoritmo ineficiente pode ser implementado simplesmente para demonstrar uma possibilidade. Com o tempo, o desenvolvedor pode ficar familiarizado com essas escolhas e esquecer todas as razões por que elas eram inadequadas. Temos que tomar muito cuidado com isso. Uma escolha muito abaixo da ideal se tornou parte integral do sistema.

O importante para a prototipagem é definir as regras do jogo no início; isto é, o cliente e o desenvolvedor devem estar de acordo que o protótipo seja construído para servir apenas como um mecanismo para definição dos requisitos e depois ele é descartado, e o software real é submetido à engenharia com o objetivo de buscar qualidade e manutenibilidade.