MIS-Prototyping: Um Processo de Prototipação

Transcrição

1 MIS-Prototyping: Um Processo de Prototipação Baseado no Modelo de Inspeção Semiótica Joelton S. Matos 1,Bruno F. Gadelha 1 1 Instituto de Informática Universidade do Estado do Amazonas (UEA) Manaus AM Brazil {joeltonmatos,bgadelha}@gmail.com Abstract. This work presents a proposal of model of development based on prototyping which incorporates the Semiotic Inspection Method(MIS), it s present in Semiotic Engineering, where the analysis of communicability of a software artifact aims to improve it each cycle. Thus, minimizing the errors of communication between the software artifact and user. Resumo. Este trabalho apresenta uma proposta de modelo de processo de desenvolvimento baseado em prototipação que incorpora o Método de Inspeção Semiótica(MIS), presente na Engenharia Semiótica, onde a análise da comunicabilidade de um artefato de software visa melhorá-lo a cada ciclo. Assim, minimizando erros de comunicação entre o engenheiro de software e usuário. 1. Introdução A interface de um sistema é entendida como uma comunicação do projetista para o usuário, que tem por objetivo comunicar ao usuário a visão do projetista sobre a quem ela se destina; que problemas ela pode resolver e como interagir com ela[de Souza 2005b, Prates and Barbosa 2007, de Souza and Leitão 2009]. Segundo de Souza[de Souza et al. 2001], artefatos de software são artefatos de meta-comunicação, onde há mensagens enviadas do engenheiro de software para o usuário sobre a gama de informações que este pode trocar com os sistemas a fim de conseguir determinados efeitos. Uma forma de avaliar a qualidade da comunicação e identificar erros desta na interface é a comunicabilidade, que é a qualidade de um artefato computacional interativo comunicar com eficiência e eficácia a intenção de design e seus princípios interativos[prates et al. 2000]. Como lembra Cardoso [Cardoso 2010], a análise da comunicabilidade de um artefato é normalmente avaliada após o produto estar pronto. Esse fato torna distante a possibilidade de alterações em sua interface, pois se torna um grande problema aplicar correções devido a inúmeros fatores, dentre eles, o financeiro. Uma proposta de solução seria um processo de desenvolvimento que incorpore questões da análise da interface nas etapas iniciais de desenvolvimento do artefato, melhorando-o a cada ciclo para que após sua finalização os usuários compreendam a mensagem do Engenheiro de Software eficazmente. Este trabalho visa propor o processo de desenvolvimento por prototipação, onde se acrescenta etapas que possibilitem a criação da interface do sistema e o estudo de sua comunicabilidade, através da aplicação de um dos métodos existentes na Engenharia Semiótica,o Método de Inspeção Semiótica (MIS). Manaus, 25 a 27 de abril de ISSN (CDR)

2 A seção 2 comenta sobre trabalhos relacionados que serviram como base para o desenvolvimento deste. A seção 3 trata sobre o que é a engenharia semiótica: apresenta uma descrição geral desta abordagem, bem como seu escopo e métodos existentes.a seção 4 é reservada para explicar sobre MIS-Prototyping: introduz uma descrição do método proposto e suas respectivas etapas. A seção 5 apresenta um estudo de caso de um sistema em desenvolvimento que segue a metodologia proposta para o controle da gestão do tempo em eventos, como os do gênero cultural. A seção 6 faz uma discussão do método proposto sobre seus pontos positivos, melhorias previstas e demais questões relevantes, e a seção 7 apresenta a conclusão do trabalho proposto. 2. Trabalhos Relacionados Existem trabalhos que visam o estudo da comunicabilidade em artefatos de software, dentre os relevantes para este contexto tem-se a Reconfiguração em Ambientes Virtuais a partir de Análises da Comunicabilidade [Cardoso 2010], tendo como objetivo avaliar a comunicabilidade de ambientes virtuais desenvolvidos a partir da plataforma Moodle, verificando o comportamento dos usuários ao realizarem determinadas tarefas no artefato. Inspeção Semiótica do ColabWeb: Proposta de Adaptações para o contexto da Aprendizagem de Programação [Castro and Fuks 2009], trabalho que propôs a avaliação do nível de comunicação de um groupware utilizando o Método de Inspeção Semiótica, a fim de determinar o quanto a falta de comunicação afeta o nível de aprendizagem de programação que o artefato analisado propõe. O Método de Inspeção Semiótica Aplicado ao Requisito Usabilidade [Monsalve et al. 2011] visou na operacionalização do requisito usabilidade no contexto do jogo educacional SimulES-W usando o Método de Inspeção Semiótica. Os trabalhos descritos desempenham bons resultado no que tange a análise da comunicabilidade, porém o foco de todos está na análise de produtos finalizados, apenas medindo o nível de comunicação do Engenheiro de Software e usuário através do estudo da interface, ou seja, apesar da identificação de melhorias para os softwares estudados é muito díficil a execução destas. Propor alternativas para identificar lacunas na comunicação antes da implementação do sistema computacional a fim de obter a solução para estas lacunas é importante tanto para os Engenheiros de Software quanto para os utilizadores do sistema. 3. Engenharia Semiótica A Engenharia Semiótica propõe uma abordagem IHC centrada na comunicação, onde o designer dos sistemas computacionais são atores ativos na comunicação com o usuário[castro and Fuks 2009]. O objeto de estudo da Engenharia Semiótica como lembra de Souza[de Souza 2005a] são os processos de comunicação engenheiro de softwareusuário que serão ou estão codificados computacionalmente na interface por meio de diferentes representações ou signos. Existem dois métodos propostos pela Engenharia Semiótica para avaliar a comunicabilidade de um artefato. O primeiro é o método de Inspeção Semiótica (MIS)[de Souza et al. 2006] que permite avaliar o sistema computacional desde a perspectiva do engenheiro de software, através da sua metacomunicação com o usuário, neste Manaus, 25 a 27 de abril de ISSN (CDR)

3 método não há o envolvimento de usuários no processo. O segundo é o Método de Avalição de Comunicabilidade (MAC)[Prates et al. 2000], em que há o envolvimento de usuários e a utilização do artefato por meio do desenvolvimento de testes que possibilitam a avaliação dos aspectos da interface pelo usuário. Este trabalho é centrado no uso do MIS como parte do processo de desenvolvimento por prototipação, pois a avaliação da comunicabilidade da interface de um sistema antes dele ser totalmente implementado é mais viável do que quando ele está finalizado, pois a possibilidade de alterações importantes no artefato ficam menos distantes Método de Inspeção Semiótica Método de inspeção proposto pela Engenharia Semiótica, segundo de Souza (apud [Castro and Fuks 2009]): O MIS tem como principal propósito avaliar a comunicabilidade de artefatos computacionais interativos. Para aplicar o MIS inicialmente tem uma fase prévia de preparação que envolve um levantamento da documentação existente, posteriormente se inspeciona o sistema considerando três diferentes níveis de signos utilizados pelo projetista: metalinguísticos, estáticos e dinâmicos[de Souza et al. 2006]. O método é aplicado em cinco etapas : i - análise dos signos metalinguísticos: analisar signos na interface que representam outros signos sejam eles dinâmicos, estáticos ou metalinguísticos. Exemplo: o signo Ajuda possui a seguinte mensagem de auto explicação pressione a tecla para obter ajuda. ii- análise dos signos estáticos: analisar signos que não tem movimentos na interface e persistem mesmo que a interação do usuário com o sistema não esteja de acordo. São signos independentes de relações causais e temporais. iii- análise dos signos dinâmicos: analisar signos que representam uma transformação devido a resposta da interação com o usuário, estes signos são atualizáveis ao longo do tempo e perdem sua significância fora do seu domínio temporal. iv- comparação de mensagem de metacomunicação: é realizada uma comparação entre as mensagens geradas pelo engenheiro de software nos passos anteriores. v- avalição da comunicabilidade: avalia-se a qualidade de comunicação do sistema inspecionado. Nas três primeiras etapas são sugeridas frases que o engenheiro de software deve seguir para criar sua mensagem de análise[de Souza 2005a, de Souza and Leitão 2009]: (i)aqui está o meu entendimento de quem você é.(ii) O que eu aprendi que você quer ou precisa fazer, de qual jeito você prefere fazer e por que.(iii) Este é o sistema que eu projetei para você e (iv) este é o jeito que você pode ou deve usá-lo para satisfazer seu propósito que casam com esta visão. Na seção 4 as frases serão utilizadas e representam o esquema de metacomunicação. 4. MIS-Prototyping Segundo [Filho 2009]: A prototipação dentro do processo de desenvolvimento de software é uma técnica aplicável a atividades do fluxo de requisitos. As experiências mostraram segundo Boehm(apud [Sommerville 2011]) que a prototipação reduz o números de problemas com a especificação de requisitos. Manaus, 25 a 27 de abril de ISSN (CDR)

4 A figura 1 mostra o modelo de processo de desenvolvimento por prototipação. Os objetivos do protótipo devem ser bem definidos desde o início do projeto. Há a necessidade de elaborar um plano de prototipação que visa identificar os objetivos do projeto. É inconsistente que um protótipo atenda todos os objetivos, deixando-os implícitos, clientes podem entender errado o propósito do protótipo. A definição das funcionalidades do protótipo é uma etapa importante. É criada uma definição geral sobre o que é relevante constar na versão do sistema. A próxima etapa é o desenvolvimento. Protótipos iniciais visam aprimorar os requisitos estabelecidos, testam a interação do sistema de um ponto de vista global e apresentam quando necessário, a sequência de subtarefas, enquanto que protótipos finais visam testar todos as partes importantes ou ainda não bem resolvidas no projeto. Após o desenvolvimento, é realizada a avaliação do protótipo, Ince e Hekmatpour (apud [Sommerville 2011]) sugerem que é a fase mais importante de todo o processo de prototipação. Deve-se avaliar os objetivos do protótipo, a partir da interação com os usuários, neste estágio são identificados erros, omissões ou modificações nos requisitos. Figura 1. Etapas modelo tradicional de prototipação. Fonte: Sommerville,2003, p O MIS-Prototyping sugere após estabelecer os requisitos do artefato a implementação da interface e posteriormente o estudo da sua comunicabilidade, a fim de identificar falhas na comunicação, aplicando as etapas do MIS e elaborando documento com possíveis alterações da interface do artefato. Após o estudo da qualidade de comunicação, sugere-se a correção das falhas encontradas, através das soluções propostas pelo próprio inspetor. Uma vez concluída a etapa de definição e constatada uma comunicação possivelmente eficaz, prossegue-se para a escolha das funcionalidades e posteriormente a implementação do protótipo. Ao chegar na avaliação do protótipo seguindo esta proposta, a relação com o usuário poderá focar-se melhor no entendimento, reformulação e extração dos requisitos, em vez de determinar o quanto a falta de comunicacão afeta o grau de aprendizagem do artefato pelo usuário. A figura 2 mostra o modelo de processo de desenvolvimento de protótipo proposto pelo MIS-Prototyping. 5. Estudo de Caso: Sistema para criação e controle de eventos setevents 5.1. O setevents Diariamente eventos são elaborados com intuito de promover um aumento do intelecto humano, da diversãoe do conhecimento de uma nova cultura. Em eventos como o carnaval e o festival folclórico de Parintins é preciso que suas componentes sejam controladas, pois caso contrário há perdas de pontos pelo atraso das apresentações. Normalmente em eventos como estes, o tratamento do controle é feito de forma totalmente manual. Manaus, 25 a 27 de abril de ISSN (CDR)

5 Figura 2. Etapas Mis-Prototyping Uma abordagem alternativa seria diminuir a necessidade do intenso controle realizado por pessoas projetando um sistema que identifique se as componentes do evento estão acontecendo de acordo com a previsão do organizador, através da visualização de relatórios depois de ocorridas as apresentações do evento ou da visualização de relatórios tempo após acontecerem partes de sua execução. O setevents é um sistema que visa atender esse propósito. Seus usuários podem cadastrar eventos. Eventos são constituídos de apresentações, cabe ao usuário cadastrar as apresentações existentes em cada evento. O controle de tempo de uma apresentação se dá avaliando as partes existentes dentro desta Prototipação do Artefato Os requisitos do setevents foram determinados após a observação de eventos locais que poderiam atrasar devido a falta de gestão do tempo. Decidiu-se elaborar um sistema simples que ajudasse a identificar ou guardar informações relativas ao tempo de duração das apresentações dos eventos. Após estabelecer os requisitos, identificaram-se as funcionalidades do sistema. Na figura 3 há o wireframe da página inicial do artefato. Figura 3. WireFrame tela inicial setevents Com o intuito de aprimorar os requisitos do sistema foi construída a interface do protótipo para observar a interação das funcionalidades ainda não implementadas. A mesma página apresentada em wireframe é mostrada na figura 4. Manaus, 25 a 27 de abril de ISSN (CDR)

6 Figura 4. Tela inicial setevents Uma vez desenvolvida a interface, as próximas etapas realizadas foram o estudo da comunicabilidade do artefato através da aplicação do MIS e as modificações da mesma, segundo as observações identificadas pelo inspetor. Estas etapas estão descritas na subseção Método de Inspeção Semiótica(MIS) setevents As cinco etapas do MIS apresentadas anteriormente na subseção 3.1 serão aplicadas para o setevents. Etapa 1:Análise dos signos Metalinguísticos Nesta etapa realizam-se inspeções tanto on-line quanto off-line na documentação disponível sobre a ferramenta, porém como o artefato está em desenvolvimento esta documentação está indisponível.os signos metalinguísticos são poucos durante a navegação da interface do sistema. Dependendo da localização do usuário no sistema há a presença ou não de metalinguagem explicando o que se deve fazer para atingir seu objetivo. O MIS sugere que se construa a metamensagem do engenheiro de software para o usuário a medida que se conclui cada etapa do método. Esta metamensagem deve ser baseada em um esquema de metacomunicação, descrito na seção anterior 3.1. (Aqui está o meu entendimento de quem você é). Você é um usuário que não tem muita experiência em sistemas web, mas tem conhecimentos básicos de informática. (O que eu aprendi que você quer ou precisa fazer de que forma e por que). Você precisa saber utilizar o sistema de forma prática, através das informações de ajuda disponíveis nas telas iniciais.(este é o sistema que eu projetei para você). Uma ferramenta que ajuda a maximizar sua gerência de eventos e ao mesmo tempo não afasta todo o conhecimento que você tem sobre a organização de seu trabalho. Um sistema que forneça informações que lhe ajudem a prosseguir com a sua usabilidade e que o leve a cumprir seus objetivos e disponibilize descrições dos dados importantes que você deve fornecer.(essa é a maneira pela qual você pode ou deve utilizá-lo de forma que preencha uma variedade de propósitos que coadunam com esta visão).observando e lendo as etapas que você está concluindo e entendendo os significados dos campos que requisitem dados. Etapa 2:Análise dos signos Estáticos A figura 5 mostra o sistema inspecionado na opção Criar Apresentação, nesta Manaus, 25 a 27 de abril de ISSN (CDR)

7 funcionalidade não estão claros alguns signos como, por exemplo, o botão adicionar da Parte 1, não está claro se adiciona um novo segmento ou adiciona a Parte 1. O combobox presente para selecionar a quantidade de segmentos não se encaixa na interface e transmite ambiguidade, além do que não é possível excluir segmentos após adicioná-los. Figura 5. Adicionar segmentos da apresentação (Aqui está o meu entendimento de quem você é). Você é um usuário que sabe preencher dados para entrar na sua área de acesso e que sabe criar cada componente que desejar no sistema.(o que eu aprendi que você quer ou precisa fazer de que forma e por que). Você precisa adicionar o que necessita independente da sua localização, pode optar por uma navegação sequencial ou direta. Após criar um evento, consegue adicionar várias apresentações e a cada uma sabe completar as informações pedidas de acordo com o que os campos da página permitem responder, pois você sabe interpretar signos.(este é o sistema que eu projetei para você). Um sistema que permite que você o acesse após validá-lo e possibilite escolher opções que necessite utilizar, forneça mecanismos para refazer seus passos quando julgar necessário e gera seus eventos e apresentações conforme suas informações armazenadas.(essa é a maneira pela qual você pode ou deve utilizá-lo de forma que preencha uma variedade de propósitos que coadunam com esta visão). Utilizando informações que você previamente forneceu, navegando pelo menu fixo superior e seguindo as orientações da ferramenta passo-a-passo, podendo removê-las ou editá-las, independentemente se foram armazenadas. Etapa 3:Análise dos signos Dinâmicos A navegação do sistema setevents é simples, os passos seguidos a partir de cada opção selecionada pelo usuário têm propósitos bem específicos. (Aqui está o meu entendimento de quem você é). Você é um usuário que sabe interagir com os menus, submenus e sabe interpretar comportamentos automáticos do sistema.(o que eu aprendi que você quer ou precisa fazer de que forma e por que).precisa preencher os campos requisitados corretamente e não quer se preocupar com seus formatos.(este é o sistema que eu projetei para você). Um sistema que seja visível na interface a mudança de passos fundamentais para concluir objetivos e que previna erros de preenchimento com formatações automáticas. (Essa é a maneira pela qual você pode ou deve utilizá-lo de forma que preencha uma variedade de propósitos que coadunam com esta visão). Observando mudanças de interface, preenchendo dados e seguindo os passos para ver os resultados. Manaus, 25 a 27 de abril de ISSN (CDR)

8 Etapa 4:Comparação das metamensagens O usuário não tendo dicas pelo artefato pode interpretar erroneamente ações que realiza. Apesar da falta de explicação de alguns termos, uma interpretação fora do esperado não iria fugir da consistência, pois a interação com o usuário é objetiva. No sistema inspecionado há problemas de padrão de nomenclatura de botões, signos estáticos com a mesma função têm nomes diferentes. Entender incorretamente uma representação do sistema causa problemas de usabilidade. Em algumas parte do artefato apresenta essa situação desnorteando o usuário da navegação e de seu objetivo. Etapa 5:Análise da Comunicabilidade O sistema proposto oferece uma interface amigável, que possibilita uma boa interação com os usuários, porém foram identificados potenciais erros na comunicação do artefato, é preciso que com esta análise de qualidade de comunicação o engenheiro de software solucione estes problemas. No setevents é preciso que acrescente dicas de como realizar as tarefas das principais funcionalidades do artefato. A correção da despadronização da ferramenta estudada é necessária. Uma solução seria deixar a mesma nomenclatura, após alterá-la de acordo com a função dos botões, ícones etc... Nas funcionalidades do sistema que passam a idéia de ambiguidade, é preciso que se descubra e mude na interface uma maneira que torne a inexistência dessa característica, neste caso a exclusão seria a melhor alternativa, além do que é preciso que o usuário possa excluir segmentos individualmente, bastando acrescentar um signo estático de exclusão do lado de cada segmento. Na figura 6 observa-se a tela correspondente a figura 5 modificada após a interface de o artefato ter sido inspecionado pelos MIS e ter voltado para a etapa de desenvolvimento da interface. Figura 6. Correções adicionar segmentos da apresentação 6. Discussão A prototipação tem pontos positivos como proporcionar maior aproximação do sistema as necessidades do usuário, melhor qualidade de projeto, melhor facilidade de manutenção e a atenuação do esforço de desenvolvimento[soares 2007]. Porém, no estágio de avaliação do protótipo, além de se observar e identificar novos requisitos preocupa-se com a usabilidade do artefato pelo usuário e muitas vezes diversos problemas de comunicação são Manaus, 25 a 27 de abril de ISSN (CDR)

9 identificados, o que torna muito dispendioso para a empresa a modificação do protótipo devido a esses fatores somados aos demais objetivos a serem cumpridos no novo ciclo de refinamento do protótipo. Para contrastar esses pontos negativos é possível a inserção da análise da qualidade de comunicação da interface. O Mis-Prototyping, figura 2, modifica a metodologia de processo por prototipação incluindo a etapa de projeto da interface, a fim de ter uma visão geral do sistema e posteriormente estudar a comunicabilidade, aplicando o Método de Inspeção Semiótica.Este foi escolhido por ser um método que não necessita da interação do usuário e obtém respostas esclarecedoras para o inspetor. A etapa de avaliação da comunicação visa corrigir falhas que prejudicariam a usabilidade do artefato, como observado no estudo de caso do artefato setevents. A repetição e alternância entre essas duas etapas é necessária até que o nível de qualidade de comunicação esteja adequado segundo a concepção do inspetor. Uma vez aceito a qualidade de comunicação,o fluxo normal da metodologia continua. Os ciclos de todo o processo prosseguem até que todas as funcionalidades estejam entendidas e o sistema praticamente próximo da conclusão. Pontos negativos do método proposto é que apesar de projetar a interface e estudar a comunicabilidade do artefato, estas etapas podem levar um certo tempo e na avaliação do protótipo o cliente pode descobrir que não era exatamente o que necessitava, frustrarse devido a interface ou eventuais mudanças nesta no software final. Isto significa que apesar de potencialmente ter boa comunicação, o sistema precisa ser remodelado segundo a mudança de requisitos, tornando as etapas propostas da metodologia apresentada frágeis em alguns aspectos.trabalhos futuros visam explorar o estudo da interação do usuário com o sistema antes do estudo da comunicabilidade. Com isso pode-se reduzir os esforços de cada ciclo, evitando que o protótipo desenvolvido seja totalmente descartado e tenha uma boa comunicabilidade. 7. Conclusão A boa comunicabilidade de um artefato de software é fundamental para a eficácia da interação com o usuário. Neste artigo mostrou-se uma forma de identificação de melhorias para sistemas que seguem a metodologia de processo de desenvolvimento por prototipação, através do estudo da qualidade de comunicação pelo Método de Inspeção Semiótica. Indubitavelmente esse método tem um grande poder de análise, minimizando possíveis falhas de comunicação. Trazer este método para dentro de um processo de desenvolvimento pode ter um grande potencial, em vez de usá-lo isoladamente e após o sistema estar finalizado. Foi feito um estudo de caso do sistema setevents seguindo esta metodologia, porém este ainda está em fase de desenvolvimento, o que compromete a análise de outro fatores importantes, porém não levado em consideração neste trabalho. Observações pertinentes a respeito da aplicação do Mis-Prototyping foram identificadas e comentadas, como no estágio de avaliação do protótipo, pois pode acontecer de requistos entendidos e implementados pelos Engenheiro de Software serem totalmente divergentes dos clientes, o que se torna um fator negativo para a análise de comunicabilidade e do processo. Pesquisas para trabalhos futuros visam reorganizar e dividir algumas etapas da metodologia proposta, bem como apresentar um estudo de caso após a aplicação de vários ciclos de Manaus, 25 a 27 de abril de ISSN (CDR)

10 aplicação do método de prototipação baseado no modelo de Inspeção Semiótica, avaliando a comunicabilidade do sistema e seu efeito para o artefato em desenvolvimento. A aplicação dessa metodologia pode vir tornar cada estágio do modelo tradicional de prototipação mais leve, menos dispendioso para as empresas, além do que menos informações precisarão ser coletas pelos engenheiros de software para o projeto do protótipo no próximo ciclo da metodologia. Referências Cardoso, E. A. (2010). Reconfiguração em ambientes virtuais a partir de análises da comunicabilidade. Amazonas:Manaus, Castro, T. and Fuks, H. (2009). Inspeção semiótica do colabweb proposta de adaptações para conxtexto da aprendizagem de programação. Revista Brasileira de Informática na Educação, 17(1). de Souza, C. S. (2005a). Semiotic engineering: Bringing designers and users together at interaction time. Interacting with Computers, 17(3): de Souza, C. S. (2005b). The semiotic engineering of human-computer interaction. MIT Press,Cambridge MA, U.K., 17(3). de Souza, C. S., Barbosa, S., and R.O.Prates (2001). A semiotic engineering approach to user interface design. Knowledge Based Systems, Amsterdam, 14(8): de Souza, C. S. and Leitão, C. (2009). Semiotic engineering methods for scientifc research in hci. Princeton:NJ Morgan e Claypool. de Souza, C. S., Leitão, C., Prates, R., and da Silva, E. (2006). The semiotic inspection method. VII Simpósio sobre Fatores Humanos em Sistemas Computacionais,IHC 2006, Natal, RN, 1. Filho, W. P. (2009). Engenharia de Software Fundamentos, Métodos e Padrões. LTC, 3rd edition. Monsalve, E., Werneck, V., and J.Leite (2011). O método de inspeção semiótica aplicado ao requisito usabilidade. Anais do WER11 Workshop em Engenharia de Requisitos, Rio de janeiro Rj, Brasil, pages Prates, R. and Barbosa, S. (2007). Introdução à teoria e prática da interação humano computador fundamentada na engenharia semiótica. T. Kowaltowski; KK Breitman Org.Atualizações em Informática. XXVII Congresso da Sociedade Brasileira de Computacao. Prates, R., de Souza, C., and Barbosa, S. (2000). Communicability evaluation method for user interfaces. Interactions, New York, 07(1): Soares, B. C. (2007). Requisitos para utilização de prototipagem evolutiva nos processos de desenvolvimento de software para web. Universidade Federal de Minas Gerais(UFMG), Belo Horizonte MG. Sommerville, I. (2011). Engenharia de Software. Pearson, 9th edition. Manaus, 25 a 27 de abril de ISSN (CDR)