- criar protótipo dinâmico ou estático?
- criar um protótipo reutilizável?
- o que fazer com o protótipo na fase de construção?
Em primeiro lugar, temos que definir a necessidade do protótipo visual, e seu papel no processo de desenvolvimento. Na minha opinião, o protótipo visual servirá para obter a aprovação junto ao usuário, do que é esperado como interface com o sistema. Então uma premissa que deve ser estabelecida é: a criação do protótipo deve ser feita na frente do usuário. Isso porque se formos fazer anotações e depois montar o protótipo, apresentando-o em outro momento, podemos perder detalhes do que foi conversado, e o usuario poderá esquecer de itens que foram tratados ou até mesmo já ter criado novas espectativas. Isso nos leva a outro ponto muito importante: Para que o protótipo seja feito na frente do usuário, a ferramenta de desenho deve ser ágil e produtiva: se a sessão de prototipação demorar demais, podemos perder a atenção do usuário, e assim tornar a reunião cansativa demais. Assim, ou adotamos uma ferramenta digital, como a Balsamiq Mockups, ou desenhamos em folhas de papel, que depois podem ser digitalizadas. A vantagem da folha de papel é a liberdade em desenhar componentes e fazer anotações. Seus problemas são a leitura de letras de difícil compreensão e a dificuldade de rearranjar facilmente os componentes. A vantagem de uma ferramenta como a Balsamiq é que o desenho, embora não funcional, já fica armazenado e permite mudanças rápidas. É bem amigável e funciona bem para interfaces relativamente complexas. Podemos até arriscar a deixar um cliente mais experiente no uso do computador desenhando as telas desejadas. O problema é quando se deseja usar componentes que não existem - neste caso recomendo usar anotações mesmo.
Bom, já comecamos definindo implicitamente que o protótipo não sera funcional, ou seja, será apenas um anexo na documentação de análise. Entretanto, a menos que use uma ferramenta como o Adobe Flex Builder, ou interface de linguagem de 4a geração, podemos perder mais tempo desenhando uma interface bem elaborada, quando poderíamos deixar os detalhes para depois. Então, a menos que se tenha um ferramental ágil para desenvolver o protótipo funcional inicial, vamos optar pelo estático mesmo.
Uma vez que o protótipo tenha sido desenhado e pré-aprovado pelo cliente, então podemos partir para desenvolver a interface do usuário, mandando as imagens do rascunho inicial para que o designer possa desenvolver os componentes. Recomendo que nesta fase, que pode ser realizada enquanto se faz o projeto físico, faça-se apenas os formulários, sem atuação de um componente Action (ainda). A idéia é que no final da etapa de projeto lógico e físico, seja apresentada a interface para o usuário - dependendo do grau de experiência do cliente, do tempo disponível e da dimensão do sistema, podemos apresentar o protótipo inicial, as telas como vão ficar, os casos de uso, a lista de requisitos e o modelo de domínio simplificado.
Uma vez aprovado, podemos partir para o desenvolvimento dos actions com as respostas e apresentar logo em seguida - isso dará um senso de organização e de que o trabalho esta fluindo bem.
Já que firmamos a linha-mestra e alguns princípios, vamos discutir um pouco mais sobre como funcionarão as coisas em um caso tipico.
Considerando um sistema simples, com a maioria dos formulários sendo apenas CRUD, podemos focar apenas em um ou dois para obter o sentimento do usuário, e depois dar maior importância para os formulários mais complexos. A desenhos do protótipo inicial deverão ser arquivados junto com o modelo do sistema, ficando disponíveis para todos envolvidos no projeto. Para isso, cria-se um objeto "artifact" no modelo do EA, associando-o com arquivo do protótipo. Após sua aprovação formal pelo usuário (que preferencialmente deve ocorrer no momento da entrevista), o designer entra em ação, criando a interface em HTML e javascript propriamente dita. As alterações que forem sendo feitas não precisam necessariamente ser replicadas no desenho feito, mas recomenda-se pelo menos documentar as mudancas feitas, justificando o porque de não fazer, fazer diferente ou incluir determinado componente. Este tipo de registro deve ser feito no EA, como uma lista de questões ligadas a este artefato. Estas questões deverão ser recuperadas pelo sistema gestão de desenvolvimento e manutenção (atrelado ao Dotproject), e serão usados no relatório do projeto.
O resultado final poderá também gerar um screenshot que será anexado ao mesmo artifact (com o label de "feito").
