Prototipagem de software
Origem: Wikipédia, a enciclopédia livre.
Remova este aviso somente depois de todo o texto estar wikificado.
PROTOTIPAGEM
As técnicas e ferramentas de software existem para identificar requisitos ambíguos e em falta. Estes problemas são factores importantíssimos no desenvolvimento de qualquer sistema de software. Contudo, estas questões tornam-se ainda mais complicadas com a emergente troca de requisitos de software ao longo do seu desenvolvimento. Projectos de larga escala estão em grande expansão nos dias de hoje e qualquer alteração no percurso da criação de um sistema pode acarretar sérios problemas, que levam a um aumento significativo dos custos. [11]
A prototipagem tem vindo a ganhar uma aceitação crescente nas comunidades de Engenharia de Software, sendo encarada cada vez mais como um modelo credível de criação de sistemas. [7] A prototipagem de sistemas de software pretende ser usada, principalmente, para animar e demonstrar os requisitos de um sistema. Pretende-se, assim, ajudar os clientes e os responsáveis pelo desenvolvimento do projecto a testar e a melhorar o sistema antes mesmo de este estar finalizado. Na engenharia de requisitos, a prototipagem é empregue para gerar protótipos de interfaces com o utilizador em conjunto com cenários [2], facilitar a compreensão, por parte dos interessados, do sistema de software a ser desenvolvido, no levantamento e validação de requisitos [5], reduzir a ambiguidade, inconsistência e falta de compreensão aquando da recolha de requisitos [3, 4] e ainda modificar de um forma organizada especificações e implementações já realizadas [6].
Experiências realizadas ao longo dos tempos e da nova era tecnológica mostram que a prototipagem de sistemas de software reduz até 40% o tamanho de um sistema e o esforço dos respectivos programadores. [1] A prototipagem vem sendo usada com um sucesso, permitindo que desde muito cedo se ganhe uma melhor percepção dos requisitos do sistema e também simplificando o seu desenho.
Um protótipo pode ser considerado uma implementação concreta, embora parcial, de um programa. Os protótipos podem ser criados para explorar múltiplas questões durante o desenvolvimento do software. Por exemplo, um protótipo de uma interface com o utilizador tem como principal funcionalidade conseguir captar as necessidades efectivas e concretas do utilizador. [8]
Um protótipo requer a participação de cerca de 30% da equipa de desenvolvimento de uma aplicação de software. Assim, é pedida a este pessoal que crie uma ou duas versões que foquem vários aspectos do sistema. A ideia não é que se produza código efectivo, ou seja, que se comece a desenvolver já módulos do programa, visto que um protótipo pode ser usado para uma continuação do progresso do sistema ou pode ser completamente descartado. Apenas quando algumas especificações resultantes de experiências realizadas com o protótipo forem examinadas se deve dar início ao desenvolvimento formal do processo. “A prototype produces "running" software and the production development produces "working" software.” [1]
Há diversas opções para fazer protótipos de sistemas de software. As técnicas variam consoante os custos e o esforço investido para a realização do protótipo e também pela fidelidade e generalidade dos resultados. Abaixo estão as técnicas de prototipagem mais usuais para a prática da engenharia de usabilidade:
*Storyboard
*Protótipo em papel
*Feiticeiro de Oz
*Máquina de Cenários
*Prototipagem rápida
*Prototipagem evolutiva
Storyboarding: esta técnica utiliza a especificação através de imagens para descrever certas situações. Fortemente ligado à técnica de cenários, o storyboarding pode actuar de forma conjunta com estes. Entretanto, pela sua forma de descrição, os cenários são mais adequados à análise de tarefas, enquanto o storyboarding se encaixa melhor na validação do formato visual destes cenários e elaboração de protótipos não operacionais.
Protótipo em papel: é certamente o método mais simples a utilizar; apenas com o material existente num escritório é possível fazer um esboço de uma aplicação, isto é, com papel (ou “post-it”) lápis e caneta pode criar-se caixas de diálogo, menus, mensagens de erro, … Assim que parte do sistema esteja esquematizado, pede-se aos potenciais utilizadores que testem o protótipo, interagindo com a interface em papel. Além disso, caso algo não esteja correcto e se queira mudar, é extremamente fácil de se (re)fazer.
Feiticeiro de Oz: Uma pessoa (wizard) simula as respostas do sistema de acordo com as entradas do utilizador, pela seguinte ordem: – Interpreta os inputs de um utilizador segundo um algoritmo – Controla computador para simular o output desejado – Usa a interface real ou um “mock-up” A técnica do Feiticeiro de Oz ou “Wizard of Oz” é utilizado para simular a adição de funcionalidades complexas e também para testar ideias futuristas. Máquina de cenários: o protótipo traduz-se, apenas, por alguns ecrãs que sustentam uma quantidade considerável de informação sobre “se” e “como” é que o desenho do sistema vai de encontro com os objectivos e as expectativas do utilizador; a “máquina de cenários” inclui ainda alguma programação em lógica que permite que os utilizadores possam “navegar” através de uma sequência predefinida de cenários.
Prototipagem Rápida: é usada para reduzir os riscos dos requisitos; o protótipo é desenvolvido a partir de uma especificação inicial, é entregue/dado a conhecer aos clientes finais e aos responsáveis pelo projecto e depois é "deixado de lado". Um protótipo rápido nunca deve ser considerado como uma versão (quase) final do sistema, pois a prototipagem rápida é pouco estruturada e difícil de se manter do inicio ao final do projecto.
Prototipagem Evolutiva: o principal ponto aqui é adquirir funcionalidade para demonstrar uma parte do sistema ao utilizador final, de modo a que algum feedback seja conseguido do lado do cliente. [11] Há medida que o sistema vai sendo desenvolvido, diversas funcionalidades são adicionadas ao protótipo e traduzidas numa eficiente implementação. No final, o sistema vai estar pronto no seu todo.
Perigos da prototipagem…
A técnica de prototipagem na identificação de requisitos pode nem sempre ser benéfica. Algumas empresas e/ou organizações podem encarar os protótipos como sendo “inimigos” seus. A adaptação ao protótipo, a eficiência de utilização, a aplicabilidade e o comportamento dos potenciais utilizadores e também dos clientes que estão a “comprar” um sistema de software pode ter um impacto negativo.
Se a maqueta do sistema for construída sem cuidado especial, pode ser que esta resolva, teoricamente, o problema errado, ou seja, aparentemente o protótipo pode parecer muito bom e estar muito bem feito, mas na realidade não ir de encontro às necessidades base dos potenciais utilizadores.
Para além disso, o facto de um protótipo dar a conhecer apenas algumas “peças do puzzle”, pode levar a que se menosprezem partes fundamentais do sistema, tornando-se incompleto. Saltar passos fundamentais no desenho de um software pode conduzir à “primeira solução” (mais fácil e simples) em vez de nos levar à “melhor solução”.
A prototipagem tem ainda outro problema que deve ter sido em conta: se for demasiado perfeito e permitir que o utilizador navegue pelo sistema já com um grau de profundidade elevado, pode levar a que o cliente pense que o projecto já está praticamente pronto, desvalorizando assim a quantidade de trabalho ainda por realizar.
Concluindo, o processo de prototipagem pode ser muito eficaz, mas também ter custos de produção elevados e ocupar uma quantidade de tempo exagerada. Todos estes pontos devem ser bem medidos tanto pelos engenheiros de software que estão à frente de qualquer projecto como também pela parte dos clientes.
Conclusão:
Já muito tem sido escrito sobre as melhores práticas para o desenvolvimento de aplicações de software, mas o que é certo é que não existe “a melhor maneira”. Há diversas formas de encarar a realidade tecnológica e a criação de novos sistemas de software não é excepção. Tanto a prototipagem como os requisitos são necessários. O uso do método de “tentativa-erro” no processo de análise e síntese na Engenharia de Software é cada vez mais usado. “Bottom-up” é síntese. “Top-down” é análise. “Bottom-up” é prototipagem. “Top-down” é desenvolvimento de requisitos. A prototipagem facilita a comunicação entre o cliente e o responsável pelo desenho da aplicação. A escrita formal dos requisitos do sistema de software é necessária para estabelecer uma definição clara do projecto, permitindo controlar as alterações que vão sendo efectuadas ao longo de todo o processo e facilitando a comunicação entre o cliente e o gestor do projecto. [1]
REFERÊNCIAS
[1] Larry Bernstein, Importance of Software Prototyping http://www.dacs.dtic.mil/awareness/newsletters/technews2-1/prototyping.html, 29-12-2005, 10h11
[2] M. Elkoutbi, I. Khriss & R.K. Keller. Generating User Interface Prototypes from Scenarios, IEEE Int’l. Symp. On Requirements Eng., 1999.
[3] R.D. Acosta, C.L. Burns, W.E. Rzepka & J.L. Sidoran. A Case Study of Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. Fisrt IEEE Int’l Conf. on Requirements Engineering, 1994
[4] B. Ramesh & Luqi. Process Knowledge Based Rapid Prototyping for Requirements Engineering, 1993
[5] A. Sutcliffe, A Technique Combination Approach to Requirements Engineering, 1997
[6] M.B. Ozcan & J.I.A. Siddiqi. Validating and Evolving Software Requirements in a Systematic Framework, 1994
[7] C. Ryan, A. Annie, D. Aldo, W. Laurie. Evolving Beyond Requirements Creep: A Risk-Based Evolutionary Prototyping Model
[8] M. Rosson, J. Carroll. Usability Engineering: Scenario-Based Development of Human Computer Interaction, Morgan Kaufmann Publishers, 2002
[9] Gerald Kotonya and Ian Sommerville, John Wiley & Sons, Requirements Engineering Processes and Techniques , 1998
[10] Dean Leffingwell, Don Widrig. Managing Software Requirements: a Use Case approach. 2nd Edition. Addison-Wesley, 2003.
[11] Joseph Urban. Software Prototyping and Requirements Engineering, 1992 http://www.dacs.dtic.mil/techs/prototype/DACS-Prototype.pdf
[12] Scalon, T. Paper prototypes: still our favourite http://www.uie.com/articles/paper_prototyping, 28-12-2005, 15h53
