P ROTOTIPAGEM R ÁPIDA E O C ICLO DE V IDA C LÁSSICO DE D ESENVOLVIMENTO DE S OFTWARE

SOFTWARE

O ciclo de vida clássico, segundo PRESSMAN (1995), é o paradigma mais amplamente usado pela engenharia de software. Suas etapas se assemelham às etapas genéricas aplicáveis a todos os paradigmas de engenharia de software, a saber: definição(planejamento e análise), desenvolvimento (projeto, codificação e testes) e manutenção.

O paradigma do ciclo de vida clássico (também conhecido como modelo em cascata) é uma abordagem seqüencial de desenvolvimento em que os requisitos que caracterizam o objetivo geral e os objetivos específicos do software devem ser definidos já nas primeiras fases do ciclo de desenvolvimento  “engenharia de sistemas e análise de requisitos” (PRESSMAN, 1995). O usuário, então, só terá oportunidade de “ver e sentir” o sistema numa fase bem adiantada de sua implementação, quando, não raramente, o usuário percebe que o sistema não é o que ele esperava e/ou o usuário deseja novas funcionalidades.

“Prototipagem rápida foi formalmente introduzida no começo da década de 80, como uma alternativa à entrega forçada de sistemas de software com funcionalidade incorreta” (CONNEL & SHAFER, 1989).

“A suposição de que é possível criar uma especificação completa previamente para o desenvolvimento tem sido a maior causa de problemas devido às freqüentes mudanças das especificações durante e depois do desenvolvimento” (WOOD & KANG, 1992).

Idealmente, prototipagem rápida (e suas ferramentas) deveriam suportar todas as diferentes fases do desenvolvimento e a aquisição de suas respectivas informações necessárias (BLOM, 2000).

VLIET (1993) apud BLOM (2000) reconhece as seguintes fases de desenvolvimento:

– Análise de requisitos: “esta fase resulta em uma completa descrição do problema a ser resolvido. Isto inclui a funcionalidade requerida do sistema, os requisitos de performance e hardware requerido.

Protótipos ajudam a encontrar a descrição do problema permitindo aos desenvolvedores ver como usuários interagem com o sistema e o que eles esperam do sistema. Usuários também podem dar um feedback sobre o sistema que os desenvolvedores podem integrar com a descrição do problema. Além disso, é freqüente o caso de os usuários mudarem seus desejos uma vez que eles tenham

usado o sistema. Prototipagem permite que essas mudanças sejam incorporadas com antecedência no desenvolvimento do sistema”.

– Projeto: “nesta fase um projeto é feito. Este projeto é um modelo do sistema inteiro. Quando implementado, deveria resolver o problema descrito na fase de análise de requisitos. É importante ver que o projeto não é uma implementação. A fase de projeto descreve o que precisa ser feito, não diz como isto deve ser feito. O Projeto não apenas define a funcionalidade (as funções necessárias para resolver o problema), mas também a funcionalidade da interface (quais informações precisam ser mostradas ao usuário e quais comandos devem estar disponíveis para o usuário para que ele possa manipulara a informação).

Protótipos certamente podem ajudar a definir a funcionalidade da interface. De fato, muitos protótipos apenas exibem a funcionalidade da interface sem muita funcionalidade do sistema. Usando protótipos usuários podem deixar claro quais informações eles necessitam manipular e ajudar a definir a funcionalidade da interface. Ao mesmo tempo, fornecem boas dicas sobre a funcionalidade necessária para o sistema”.

– Implementação: “aqui o sistema é implementado. Esta fase se preocupa em como o modelo resultante da fase de projeto deve ser implementado. O resultado da fase de implementação é um sistema executável, o qual (esperançosamente) resolve o problema.

Idealmente, a implementação do protótipo poderia ser usada para implementar o sistema real. Em outras palavras o protótipo deveria resultar em reusabilidade do código. Na prática, entretanto, isto não é sempre o caso. Existem várias razões para isto:

– O protótipo não é executável e assim o protótipo não contém código que possa ser reutilizado, ele não contém código executável de nenhuma maneira.

– O protótipo é escrito em uma linguagem diferente da que será utilizada para sistema real. Freqüentemente protótipos são criados usando uma linguagem de script14 que não é poderosa o suficiente para o sistema inteiro ser criado com ele. A solução óbvia é escrever o protótipo na mesma linguagem que o sistema

real. Mas então a linguagem usada para criar o protótipo deve ser bastante poderosa e mais poder significa mais dificuldade de uso. Então o protótipo levará mais tempo para ser desenvolvido.

– O protótipo não é bem construído. Um dos requisitos dos protótipos é que eles podem ser criados rapidamente. Infelizmente em ciência da computação fazer algo rapidamente sempre interfere no “fazer algo bem feito”. E se o sistema real não é bem construído, ele terá muito mais erros e será mais difícil de manter. Também muitas ferramentas de protótipos tendem a misturar a interface do usuário com a funcionalidade do sistema o que compromete também uma boa construção. Conseqüentemente o código de um protótipo mal estruturado não deveria ser usado para implementar o sistema real”.

– Teste: “a fase de teste testa se o sistema resultante da fase de implementação

realmente resolve o problema. Se não resolve, os desenvolvedores devem retornar à fase anterior e corrigir os erros.

Prototipagem pode ser útil na fase de teste. Ou será mais precisa, prototipagem pode reduzir a necessidade da fase de teste. Idealmente a fase de teste não deveria ser necessária de maneira nenhuma. Mas com as técnicas correntes disponíveis em ciência da computação, é impossível fazer software sem erros para todos, mas principalmente para sistemas triviais. Prototipagem não pode resolver este problema completamente, mas pode deixar menos difícil. Durante a criação do protótipo erros em potencial podem já ser detectados e corrigidos mais cedo. Como regra geral, quanto mais cedo os erros são encontrados, mais barato para corrigi-los. O problema de erros no software é essencialmente transformado no problema de erros no protótipo. Mas erros no protótipo são mais fáceis de resolver porque podem ser descobertos mais cedo e porque o protótipo é menos complexo que o sistema real”.

– Manutenção: “mesmo depois do teste o sistema ainda conterá erros, os quais serão corrigidos na fase de manutenção, conforme eles são descobertos. Também os usuários podem pensar sobre novos requisitos enquanto eles estão usando o sistema. A nova funcionalidade necessária para suportar esses requisitos será incluída no

sistema na fase de manutenção e também as fases anteriores serão revisadas conforme necessário.

O propósito principal da prototipagem é coletar informações necessárias para construir o sistema com êxito. Por isso a prototipagem pode ser útil para descobrir quais novas funcionalidades são desejadas no sistema”.