Sérgio,

Parabéns pelo artigo está muito bom.

Concordo que prototipar é muito importante no sucesso de qualquer projeto de software.

Um protótipo bem elaborado resolve um dos problemas apontado por Brooks que é a invisibilidade do software:

“Invisibilidade: O software não é espacialmente representável: não existe um diagrama ou esquema lógico que o descreva. São necessárias muitas representações para conseguir um entendimento visual do sistema.”(Brooks, Frederick P. ``No Silver Bullet: essence and accidents of Software Engineering.'' IEEE Computer, Abril de 1987.).

O usuário não tem a menor idéia de como será o software, principalmente se for um sistema novo, mas com o protótipo ele tem a possibilidade de participar da construção. Um protótipo é equivalente a uma maquete na arquitetura. Apresentar uma maquete para o cliente permite que ela faça alterações no projeto, “sem custos”, agora imagina depois da casa construída ter que mudar uma parede ou outro detalhe qualquer. Em seu artigo Brooks aponta a provável solução:

“Refinamento de Requisitos e Prototipagem rápida: A tarefa mais difícil é sempre decidir o que construir. Uma técnica excelente para resolver o problema é extrair e refinar iterativamente a funcionalidade do sistema; permite que os requisitos evoluam, o que é muito mais natural do que forçar os clientes a especificarem...”

Apesar dos experts afirmarem que com diagramas podemos interagir com nosso cliente, comparo com a construção civil, uma planta mostra com detalhes como a casa vai ser construída, mas com uma maquete estamos vendo a “casa” e todos os seus detalhes. Pessoalmente tenho muitas dúvidas quanto ao cliente entender um MER, um DFD ou um diagrama de caso de uso, este muito melhor, mas ainda não enxergamos o todo.

Um efeito colateral, é que ao ver o protótipo o cliente acha que o software está pronto e quando falamos que temos ainda 40% (60% análise, 35% construção e 5% testes/homologação) de trabalho, eles ficam achando que estamos enrolando.

Muitas empresas guardam seus códigos fontes a sete chaves, mas a parte mais difícil na construção de qualquer software é justamente aquela em que todos tem acesso, que é a interface, suas funcionalidades e usabilidade e estes quesitos atingimos em cheio com um bom protótipo.
[]s,
Elizeu.

Sergio, você foi muito feliz ao escrever seu artigo e Elizeu, não o conheço, mas você conseguiu completar perfeitamente a idéia original.

No entanto, uma coisa que nunca consegui entender é por que algumas empresas com funcionários na área de TI, muitas delas com metodologias próprias e diversos certificados, parecem dar menos importância para os protótipos do que as empresas que não possuem.

Um dos maiores problemas ao meu ver é que, como as fases onde analisamos e elaboramos o sistema não gera nenhum produto "tangível", os clientes pensam que não estamos fazendo nada e não conseguem ver a importância dessas fases. Enquanto na engenharia essas fases geram uma ou diversas plantas, as nossas geram pilhas de papel que para a maioria do cliente não têm sentido.

O protótipo seria o único mecanismo de demonstrar ao cliente algum resultado. No entanto, isso nos remete aos sistemas onde a maior parte do processamento não possui telas, dificultando ainda mais o trabalho de validar junto ao cliente o que será entregue.

Acredito que uma boa ferramenta a ser somada aos protótipos seja um gerador de workflow. Não sei se existe, mas imagine uma ferramenta onde o analista demonstrasse a execução do caso de uso ou o diagrama de atividades como se fosse um filme. Um PowerPoint ou um Flash melhorado. Onde o analista com poucos cliques e drag-and-drops conseguisse montar um filminho que exibisse exatamente o que o sistema executa após um clique em um botão do protótipo.

Não custa nada sonhar.

Mais uma vez, parabéns pelo artigo Sergio.