+2

Metodologias de desenvolvimento de software - Parte II

criado por Gustavo Villa em 26/07/2004 10:06am
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 inseguro da eficiência de um algorítimo 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 frequentemente 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 algorítimo ineficiênte 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.

Comentários:

Mostrando 1 - 4 de 4 comentários
Dam disse:
Bom artigo.
20/11/2008 4:25am (~16 anos atrás)

Bozo disse:
Muitas empresas, usam um processo diferente.

1 - reunião com cliente, pós comercial, pega algumas das necessidades, conhece alguns sistemas.

2 - para para a area de sistemas que antes de uma reunião faz uma analise "geral" do sistema e passa para o prototipador (HTML)

3 - apresenta para o cliente um fluxo inicial que "pode" ser uma idéia do que o mesmo necessita.

Bom pessoal, este tipo de processo funciona, eu,por motivos de prazos com clientes, ja fiz coisas assim, e para minha sorte funcionaram e o sistema é redondinho.

abraço.
12/09/2004 7:36pm (~20 anos atrás)

O protótipo pode ser perigoso pois como dito no artigo na ancia de se faze-lo pode-se atropelar algumas regras na modelagem dos dados junto ao cliente e também a não compreensão do cliente sobre o que é um protótipo.
Mas o protótipo serve para o cliente ter noção do que o sistema irá servir.
No entanto vc utilizar desenhos de tela para demostrar ao cliente como irá se dispor os campos e qual será o fluxo de manuzeio. Com isso vc ganha tempo e qualidade na elaboração do protótipo.
Porque o que se vê é o que se obtem.
31/07/2004 12:31pm (~20 anos atrás)

Fran disse:
Oiiii....
O uso de protótipos nos ajudam quando temos um grande software para desenvolver e nossa analise é participativa , ou seja, o usuario participa da analise do projeto.
Isso nos da a garantia de chegar mais proximo ao que o usuario quer, satisfazendo-o.
(Eu tambem gosto dos livros do Pressmam...hehehe)
28/07/2004 4:12pm (~20 anos atrás)

Novo Comentário:

(Você pode usar tags como <b>, <i> ou <code>. URLs serão convertidas para links automaticamente.)