Prototipagem
Origem: Wikipédia, a enciclopédia livre.
A prototipagem é aplicada nas mais diversas áreas de conhecimento, mas sempre com os mesmos objectivos gerais. Apresentaremos os conceitos gerais e as técnicas de prototipagem que de alguma forma estejam relacionadas com o desenvolvimento de software. Especialmente, a prototipagem que tenham alguma função no processo de engenharia de requisitos para o desenvolvimento de software.
Índice |
[editar] Introdução
Protótipo é uma versão inicial do sistema final que está disponível da fase inicial do processo de desenvolvimento. Quando o sistema final é hardware é comum o protótipo servir para testar o design do sistema. Mas se o sistema final for software a sua mais comum utilização é na elucidação e validação dos requisitos. Assim sendo, é fundamental que este seja desenvolvido rapidamente. Consequentemente, algumas funcionalidades serão sacrificadas com o objectivo de acelerar o desenvolvimento do protótipo que em seguida se destaca: facilidade de manutenção, qualidade, performance, fiabilidade (Kotonya, Sommerville 1998).
Um protótipo é um sistema de demonstração que se apresenta aos utilizadores e Stakeholders (Os Stakeholders são as pessoas ou organizações que são de alguma forma afectadas pelo sistema e/ou que tem directamente ou indirectamente influência nos requisitos do sistema) de forma a validar os requisitos conhecidos ou obtê-los quando os requisitos conhecidos são vagos ou indefinidos. Um protótipo pode ser usado como meio de comunicação entre os diversos membros da equipa de desenvolvimento ou mesmo como meio de nós mesmos testarmos a nossas ideias (Sommerville, Sawyer 1997).
A prototipagem tem influência em duas actividades do processo de engenharia de requisitos, a actividade de identificação e descoberta de requisitos e na actividade de validação de requisitos. A experiência de os utilizadores analisarem a forma como o sistema irá suportar o seu trabalho, poderá traduzir-se em novos requisitos (actividade de identificação e descoberta de requisitos). Poderá igualmente, revelar a correcção ou incorrecção dos requisitos propostos (actividade de validação de requisitos).
Um outro motivo para recorrer a prototipagem é que geralmente os Stakeholders não conseguem especificar o que pretendem, mas perante um sistema e após uma breve utilização, facilmente especificam o que não pretendem. A experiência permitiu concluir que o sistema final será tanto melhor quanto mais iterativo for o processo de desenvolvimento do protótipo (Rogers, Sharp, Preece, 2002). O protótipo permite demonstrar conceitos, opções de designe, aumentar o conhecimento sobre os problemas e sobre as possíveis soluções.
Os protótipos podem ser desenvolvidos usando tecnologias que em nada se assemelham com as do sistema final (Kotonya, Sommerville 1998).Os protótipos podem ser elaborados recorrendo a diversas técnicas, materiais e consequentemente, apresentam diversos custos (Rogers, Sharp,Preece 2002). Os protótipos podem ser um conjunto de folhas de papel com as interfaces do sistema desenhadas, as interfaces do sistema elaboradas em alguma aplicação de efectuar apresentações, maquetes a 3 dimensões, um pedaço de software, um vídeo em que se simula uma tarefa, entre muitas outras possibilidades. A prototipagem tem sempre como fim permitir aos Stakeholders interagirem com a visão do sistema final. Dependendo dos objectivos a atingir e dos Stakeholders é que se decide o tipo, as técnicas e os materiais a utilizar no desenvolvimento do protótipo.
Ynome Rogers, Helen Sharp e Jennifer Preece(2002) defendem que uma cultura de efectuar prototipagem origina uma cultura de busca pela inovação.
[editar] Benefícios
A aplicação da prototipagem pode traduzir em um conjunto alargado de benefícios no desenvolvimento do sistema, que em seguida se especificam:
- Se os Stakeholders não conseguirem especificar ou especificarem os requisitos de forma ambígua, poderão concordar com um documento de requisitos que não reflecte as suas necessidades. A prototipagem permite demonstrar aos Stakeholders o significado de requisitos (Sommerville, Sawyer 1997);
- A prototipagem permite validar os requisitos conhecidos. A análise cuidada dos requisitos em conjunção com reavaliações sistemáticas dos requisitos permitem reduzir a incerteza sobre as funcionalidades do sistema. No entanto, a forma mais fiável de validar um requisito é experimentá-lo. Permite, igualmente, verificar se existem equívocos na interpretação dos requisitos entre os programadores e os Stakeholders (Kotonya, Sommerville 1998).
- A prototipagem permite atenuar os riscos de numa fase avançada do desenvolvimento do software se verificar que existe erros, incoerências ou omissões nos requisitos os quais se traduzem nessa fase em elevados custos de reconversão; No entanto, o desenvolvimento do protótipo poderá levar na fase iniciar a um aumento dos custos que serão atenuados se forem evitados os elevados custos de reconversões em fases avançadas do desenvolvimento (Kotonya, Sommerville 1998).
- A prototipagem é a única efectiva forma de desenvolver as interfaces com o utilizador (Kotonya, Sommerville 1998). Se o protótipo for desenvolvido aquando do processo de desenvolvimento do documento de requisitos poderá mais tarde reduzir os custos de desenvolvimento do sistema (Sommerville, Sawyer 1997);
- Se o sistema for software, o sistema final poderá, em alguns casos, ser desenvolvido modificando e acrescentando novas funcionalidades ao protótipo minimizando os custos;
- O protótipo permite rapidamente demonstrar a administração e com custos de desenvolvimento reduzidos a utilidade e praticabilidade do sistema (Sommerville, Sawyer 1997) (Kotonya, Sommerville 1998).
- O protótipo pode ser utilizado para treino dos utilizadores antes que o sistema esteja completamente implementado;
- O protótipo pode ser utilizado na fase de testes do sistema com o objectivo de verificar se ambos têm o mesmo comportamento (Kotonya, Sommerville 1998);
[editar] Problemas
Na aplicação da prototipagem podem ocorrer um conjunto de problemas que em seguida se especificam:
- O tempo de desenvolvimento de protótipos está dependente da experiência das pessoas envolvidas. O tempo de desenvolvimento dos protótipos iniciais poderá ser demorada enquanto se adquire a experiência de como elaborar protótipos de forma rápida e eficiente (Sommerville, Sawyer 1997) (Kotonya, Sommerville 1998).
- Em algumas circunstâncias o desenvolvimento de protótipos atrasa o desenvolvimento e origina um aumento do custo do sistema final. O sistema obtido com base nos resultados da elaboração dos protótipos é melhor mas poderá não ser recompensador (Sommerville, Sawyer, 1997) (Kotonya, Sommerville 1998).
- Alguns requisitos, como requisitos de “em tempo real” e requisitos não funcionais podem ser difíceis ou mesmo impossíveis de implementar num protótipo (Sommerville, Sawyer 1997) (Kotonya, Sommerville 1998).
- Num desenvolvimento de um protótipo não é preocupante o facto de não ser um sistema bem estruturado, flexível e de fácil manutenção. Um sistema final que não cumpre os critérios anteriores irá certamente originar custos de manutenção elevados e reduzido tempo de vida (Sommerville, Sawyer, 1997). Podem existir situações em que o desenvolvimento do sistema seja obtido através da continuação do desenvolvimento do protótipo mas em regra, a elaboração do sistema final não deve ter por base os protótipos desenvolvidos.
- Um protótipo é um sistema de demonstração do sistema final no qual foram feitos compromissos de forma a um rápido desenvolvimento. Isto origina que o protótipo possa não ser fiável nem rápido, iludindo os utilizadores sobre as possíveis capacidades do sistema final. Isto pode originar um comportamento comedido e minimalista ao especificarem os requisitos (Sommerville, Sawyer 1997)(Kotonya, Sommerville 1998).
[editar] Implementação
Desde o inicio do desenvolvimento do protótipo que deve estar bem definido quais são os objectivos a serem atingidos com o desenvolvimento do protótipo. Os stakeholders que experimentarem o protótipo devem saber claramente com são os objectivos do protótipo de forma a não haver falsas expectativas e levar a fracasso da experiência.
Após termos definido os objectivos, temos de decidir quais os requisitos a implementar no protótipo. É necessário nesta fase estabelecer um compromisso entre os requisitos a implementar e os que não serão implementados. A natureza da prototipagem a isso obriga: produzir rapidamente um sistema para testar um aspecto do sistema final. Dependendo do tipo de prototipagem adoptada, prototipagem de baixa fidelidade ou alta fidelidade, diferentes compromissos serão necessários estabelecer. Aquando do estabelecimento de compromissos geralmente deparamos com o dilema: implementar um numero grande de requisitos mesmo que superficialmente ou poucos requisitos mas com todos os detalhes implementados. A resposta a este dilema deu origem a 2 tipos de prototipagem: a prototipagem horizontal (providenciar um vasto numero de funcionalidades mas com poucos detalhes) e a prototipagem vertical (providenciar um pequeno numero de funcionalidades mas com todos os detalhes) (Rogers, Sharp, Preece 2002). Em geral, para reduzir os custos e diminuir ao mínimo o tempo de desenvolvimento poder-se a não implementar os requisitos não funcionais e/ou requisitos que não interferem com os objectivos propostos para o protótipo.
O tempo reservado para a demonstração do protótipo aos Stakeholders deve ser o necessário a que estes se familiarizem com o protótipo e deve ser elaborado, de acordo com os objectivos propostos, um plano de avaliação do protótipo. Só com um plano correctamente elaborado e estando os utilizadores familiarizados com o protótipo é que estes normalmente descobrem os erros e omissões nos requisitos.
O tempo de desenvolvimento do protótipo é essencial que seja o mais curto possível. O rápido desenvolvimento do protótipo permitirá que os utilizadores experimentem o protótipo na fase inicial do desenvolvimento do software, minimizando os custos associados as alterações nos requisitos.
Os protótipos podem ser classificados como protótipos de baixa fidelidade ou de alta fidelidade (Rogers, Sharp, Preece, 2002).
[editar] Prototipagem de baixa fidelidade
Os protótipos de baixa fidelidade são aqueles que não se assemelham com o produto final (Rogers, Sharp, Preece 2002). Estes protótipos são úteis para a exploração e testes na fase inicial de desenvolvimento do sistema. São protótipos simples, baratos e de fácil produção e alteração facilitando deste modo a exploração e teste de ideias. Estes tipos de protótipos nunca são desenvolvidos com o objectivo de serem incorporados no produto final. Na prototipagem de baixa fidelidade alguns dos principais compromissos estabelecidos são: o sistema não funciona e o protótipo não se assemelha com o sistema final.
[editar] Aspectos positivos
- Reduzidos custos;
- Reduzido tempo de desenvolvimento;
- Eficiente para recolha de requisitos;
- Eficiente e facilita múltiplos testes de opções de design;
[editar] Aspectos negativos
- Reduzida utilidade após a definição do documento de requisitos (ex: na fase de testes do sistema final);
- Definição incompleta do esquema navigacional;
- Permitir testes limitados (ex: usabilidade);
[editar] Prototipagem de alta fidelidade
Os protótipos de alta fidelidade são aqueles que se assemelham com o produto final. Esses protótipos utilizam as mesmas técnicas e materiais que o sistema final (Rogers, Sharp, Preece 2002). São os protótipos indicados quando os objectos são a venda do sistema ou o teste de problemas técnicos. Na prototipagem de alta fidelidade também se efectuam compromissos, sendo os principais o facto do protótipo ter funcionalidades limitadas e os requisitos não funcionais, normalmente, não estarem implementados.
[editar] Aspectos positivos
- Possuir funcionalidades semelhantes às do sistema final;
- Permitir a definição completa do esquema navigacional;
- Permitir elevado grau de interactividade com os utilizadores;
- Permitir a exploração e testes diversos com um elevado grau de realismo;
- O Protótipo é um documento de requisitos;
- Facilita a venda da ideia do sistema final;
[editar] Aspectos negativos
- Elevado custos de desenvolvimento;
- Elevado tempo de desenvolvimento;
- Ineficiente para testes de opções de design de implementação;
- Ineficiente para recolha de requisitos;
Tendo em mente o referido anteriormente no âmbito da engenharia de requisitos o tipo de protótipo mais indicado é o de baixa fidelidade.
A prototipagem poderá ser implementada segundo 2 métodos: prototipagem “Throw-away” e a prototipagem evolutiva (Kotonya, Sommerville 1998).
A prototipagem “Throw-away” tem como objectivo fundamental identificar e validar os requisitos. A prototipagem evolutiva tem como objectivo fundamental minimizar o tempo de desenvolvimento do sistema.
[editar] Prototipagem “Throw-away”
A prototipagem “Throw-away” consiste no desenvolvimento de um protótipo com o objectivo de aumentar a qualidade do documento de requisitos. O desenvolvimento do protótipo tem por base os requisitos que não estão bem definidos. Os requisitos bem definidos poderão nunca ser implementados no protótipo (Kotonya, Sommerville 1998).
Os passos de desenvolvimento do protótipo são:
- Desenvolvimento deste com base num documento de requisitos provisório;
- Obter as opiniões dos stakeholders;
- Reformular o documento de requisitos;
Estes passos serão repetidos até que os stakeholders estejam satisfeitos com o protótipo, consequentemente o documento de requisitos está finalizado.
Após as experiências e após o documento de requisitos estar finalizado o protótipo deixa de ser necessário, consequentemente é abandonado.
Visto o tempo de vida do protótipo ser muito curta, no seu desenvolvimento conceitos como: fácil manutenção, boa performance, fiabilidade podem não ser considerados.
Em seguida focamos a nossa atenção na prototipagem especifica para projectos de desenvolvimento de software.
A linguagem de programação com a qual o sistema é desenvolvido é normalmente diferente da linguagem de desenvolvimento do protótipo.
Existem 3 tipos de protótipos (Sommerville, Sawyer, 1997):
- Protótipo em papel: é desenvolvido um conjunto de interfaces associadas a cenários de utilização que são apresentados aos utilizadores. Este tipo de prototipagem é barata e eficiente (Rogers, Sharp, Preece, 2002)(Kotonya, Sommerville 1998). È mais indicada quando o sistema a desenvolver é software. Não é necessário desenvolver software executável. Os analistas e utilizadores percorrem estes cenários, simulando a utilização do sistema, sendo analisado as reacções dos utilizadores, a informação requerida e a forma de interacção com o sistema. Este método é muito eficiente para sistemas interactivos. Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, 2002).
- Protótipo “wizard of Oz”: uma pessoa simula as respostas dos sistemas em resposta as acções dos utilizadores. Este tipo de prototipagem é relativamente barata visto apenas a interface do sistema ter de ser desenvolvida (Kotonya, Sommerville 1998). Os utilizadores interagem com o que parece ser o sistema em que as suas acções são analisadas por um pessoa que simula a resposta do sistema. É particularmente útil quando o sistema a desenvolver tem por base numa interface existente. Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, 2002).
- Protótipo automático: é utilizado linguagens 4GL ou outras linguagens que permitem um rápido desenvolvimento de protótipos executáveis. Este tipo de prototipagem é a mais cara (Kotonya, Sommerville 1998). Envolve o desenvolvimento de software, recorrendo a linguagens de programação de alto nível, que simule as funcionalidades do sistema. O problema principal do desenvolvimento de protótipos executáveis é de os Stakeholders não simularem a real utilização do sistema final devido ao facto de muitos dos requisitos não funcionais do sistema não estarem provavelmente implementados em conjunção com falta de treino. Um outro problema poderá surgir se o desenvolvimento do sistema estiver atrasado. Nesta situação pode ocorrer a tentação de prosseguir o desenvolvimento do protótipo com todas as nefastas consequências anteriormente referidas.
[editar] Prototipagem evolutiva
Recentemente, a separação entre o desenvolvimento do protótipo e o desenvolvimento do sistema propriamente esbateu-se dando origem a prototipagem evolutiva.
Na prototipagem evolutiva é desenvolvido rapidamente um protótipo, sendo modificado sucessivamente de acordo com comentários dos Stakeholders até se obter o sistema final. O protótipo começa por ser muito simples obedecendo aos requisitos fundamentais e que estejam completamente definidos (Kotonya, Sommerville 1998).
Em contraste com a prototipagem “Throw-away” não é elaborado um documento de requisitos detalhado, podendo mesmo não haver documento de requisitos.
Visto o protótipo dar origem ao sistema final, no seu desenvolvimento conceitos como: fácil manutenção, boa performance, fiabilidade devem ser uma preocupação. O desenvolvimento do protótipo deve se reger pelos mesmos critérios de qualidade de qualquer outro sistema. Para que a evolução do protótipo para o sistema final pelo processo de prototipagem evolutiva origine um sistema robusto é necessário um planeamento e um desenvolvimento cuidado desde o início. Basear o sistema final em protótipos desenvolvidos para responder a questões específicas não é uma boa estratégia para desenvolver um sistema final robusto (Rogers, Sharp, Preece 2002).
Apresentaremos, em seguida, as características principais:
- Minimização do tempo de desenvolvimento. Em algumas situações a rápida entrega do sistema e a usabilidade são mais importantes que a fácil manutenção e o sistema ter todas as funcionalidades necessárias.
- Envolvimento dos Stakeholders. O envolvimento destes no processo de desenvolvimento poderá traduzir-se que o sistema suprima exactamente as suas necessidades, mas também, visto estarem envolvidos, desejam que o sistema seja um sucesso.
- Os processos de especificação, designe e implementação são repetidamente intercalados.
- O sistema é desenvolvido de um forma incremental.
- São utilizadas técnicas de rápido desenvolvimento de software.
- Em sistemas de grande dimensão podem ocorrer problemas ao nível da gestão do desenvolvimento e contratuais. Se os sistemas evoluem muito rapidamente, pode originar que não seja produzida a documentação devida. Os contratos entre a entidade que desenvolverá o sistema e os clientes normalmente têm o documento de requisitos por base. Visto o documento de requisitos não existir ou não ser detalhado torna-se difícil elaborar o contrato.
- Em sistemas de longo período de funcionamento podem ocorrer problemas ao nível da manutenção e de evolução (Rogers, Sharp, Preece 2002) (Kotonya, Sommerville 1998). A rapidez, as continuas alterações, a falta de uma estrutura sólida e as tecnologias específicas envolvidas podem originar que, somente os especialistas que desenvolveram possam efectuar com relativa facilidade possíveis alterações e que o tempo de vida do sistema seja curto.
Resumindo a prototipagem evolutiva permite o desenvolvimento de pequenos e médios sistemas rapidamente, que se adaptam as necessidades dos utilizadores mas com tempo de funcionamento curtos. Esta forma de prototipagem é comum hoje em dia no desenvolvimento de aplicações web.
[editar] Questões finais
Ao longo do processo de desenvolvimento poder-se a desenvolver diferentes tipos de protótipos consoante os objectivos a atingir e o grupo de pessoas a interagir com estes. Na fase inicial do desenvolvimento é normal utilizar prototipagem de baixa fidelidade e do tipo "throw-away" e em fases mais avançadas utilizarem-se prototipagem de alta fidelidade podendo ser do tipo evolutiva ou não. Os objectivos que se pretendem atingir influenciam decididamente o tipo de protótipo a desenvolver. Se o objectivo for obter a aprovação pela administração os protótipos de baixa fidelidade dificilmente causariam uma boa impressão. Neste caso, a prototipagem de alta fidelidade horizontal de certeza que seria melhor opção (Rogers, Sharp, Preece 2002).
[editar] Referências
Requirements Engineering - A good practice guide Ian Sommerville & Pete Sawyer Wiley - 1997
Requirements Engineering - Processes Techniques Gerald Kotonga & Ian Sommmerville Wiley - 1998
Software Engineering Ian Sommmerville Addison & Wesley - 1995
Interaction Design - Beyond human-computer interaction Yvonne Rogers & Helen Sharp & Jennifer Preece Wiley - 2002
Requirements Engineering: Processes and Techniques Gerald Kotonya, Ian Somerville Wiley - 1998
