Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Relato de Experiência Usando SCRUM e Protótipo Marcelo da Rocha Santos Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Orientador Prof. Dr. Rodrigo Bonifácio de Almeida Brasília 2011

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Computação Licenciatura Coordenador: Prof. Dr. Homero Luiz Picolo Banca examinadora composta por: Prof. Dr. Rodrigo Bonifácio de Almeida (Orientador) CIC/UnB Prof. Dr. Genaina Nunes Rodrigues CIC/UnB Prof. Me. Hilmer Rodrigues Neri FGA/UnB CIP Catalogação Internacional na Publicação Santos, Marcelo da Rocha. Relato de Experiência Usando SCRUM e Protótipo / Marcelo da Rocha Santos. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, Scrum, 2. Metodologia Ágil, 3. Gerência de Projetos, 4. Protótipo CDU Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Relato de Experiência Usando SCRUM e Protótipo Marcelo da Rocha Santos Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Prof. Dr. Rodrigo Bonifácio de Almeida (Orientador) CIC/UnB Prof. Dr. Genaina Nunes Rodrigues CIC/UnB Prof. Me. Hilmer Rodrigues Neri FGA/UnB Prof. Dr. Homero Luiz Picolo Coordenador do Curso de Computação Licenciatura Brasília, 05 de junho de 2011

4 Dedicatória Ao meu avô Pedro da Rocha Machado (in memorian). i

5 Agradecimentos Agradeço a todos os que me ajudaram durante essa jornada. Aos meus pais, que sempre me apoiaram, mesmo quando escolhi um área de estudos que me levaria para longe deles. Ao meu bem, Taís de Sant Anna Machado por todo o apoio e incentivo ao longo do curso e especialmente durante este último semestre. Agradeço também aos amigos do Inep, local onde trabalho há 7 anos e onde elaborei o estudo de caso que deu origem a esse trabalho monográfico. E ao meu orientador, Rodrigo, pelo acompanhamento e apoio ao trabalho aqui apresentado. ii

6 Resumo Esta monografia consiste em um estudo de caso sobre a utilização de metodologias ágeis, aliado à adoção de protótipos como parte importante no levantamento de requisitos. Este estudo se deu entre os anos de 2008 a 2010, no Inep - Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira. A pesquisa bibliográfica foi feita sobre os três temas envolvidos nesse estudo de caso: a engenharia de requisitos, os protótipos e a metodologia ágil. Por fim temos a elaboração do estudo sobre a forma como se iniciou a utilização da metodologia ágil e dos protótipos dentro do órgão e quais foram os principais benefícios alcançados, bem como as customizações que foram necessárias para adaptar as metodologias à realidade do desenvolvimento de software numa instituição pública. Palavras-chave: Scrum, Metodologia Ágil, Gerência de Projetos, Protótipo iii

7 Abstract This monograph consists on a case study on the use of agile methodologies, with the adoption of prototypes as part s important in requirements gathering. This study took place between the years 2008 to 2010, at the INEP - National Institute of Educational Studies Anísio Teixeira. The theoretical research was done on the three issues involved in this case of study: requirements engineering, prototypes and agile. Finally, we have the survey about the way the institution started using the agile methodology and prototyping and what were the main bene?ts achieved, and the customizations that were necessary to adapt the methodology to the reality of the development of software in a public institution. Keywords: Scrum, Agile Methodology, Project Management, Prototype iv

8 Sumário 1 Introdução 1 2 Engenharia de requisitos Tipos de requisitos O levantamento de requisitos Prototipagem no processo de desenvolvimento de softwares Prototipação e objetivos Uso dos protótipos em testes Tipos de protótipos Quanto à reutilização e funcionalidades implementadas Quanto à fidelidade Quanto à abrangência de funcionalidades Protótipos Globais e locais Protótipo Storyboarding Protótipo em papel Mágico de Oz (Wizard of Oz) Benefícios e riscos Metodologia Ágil e Prototipagem Extreme Programming Scrum Características do Scrum Protótipos e Metodologias Ágeis Metodologia Ágil e Protótipos no Inep Situação anterior Implantação da Metodologia Ágil Resultados da implantação Referências 36 v

9 Lista de Figuras 2.1 Tipos de requisitos não funcionais (Sommerville (2007)) O processo de requisitos (Pfleeger (2004)) Curva de falhas para o software (Pressman (2006)) Caso de uso Processo de desenvolvimento de protótipos.(sommerville (2007)) Teste back-to-back (Sommerville (2007)) Exemplo de campos em um protótipo descartável Protótipo vertical x Protótipo Horizontal (Nielsen (1993)) Protótipo de cenário Protótipo em papel (Snyder (2003)) Processo de desenvolvimento iterativo Cartão CRC O processo Extreme Porgramming (Pressman (2006)) Formação Scrum no esporte Rugby Fluxo de processo do Scrum Pressman (2006) Gráfico de Burndown ( Kniberg (2007)) Protótipo não funcional Gráfido de BurnDown do Enem em Quadro do Scrum utilizado no Enem em Ocorrências em 2009, por nível de gravidade Ocorrências em 2011, por nível de gravidade vi

10 Lista de Tabelas 2.1 Métricas para especificar requisitos não funcionais (Sommerville (2007)) Princípios dos métodos ágeis vii

11 Capítulo 1 Introdução Uma falha no levantamento dos requisitos de um sistema pode ter grande impacto no software produzido. Temos à disposição várias formas distintas de levantar requisitos, desenvolver softwares e gerenciar projetos. Uma combinação adequada dessas formas pode garantir o sucesso de um projeto de desenvolvimento de software e a satisfação dos clientes e demais usuários. Nessa monografia apresentaremos o empenho do Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira - Inep - para implementar uma metodologia ágil de desenvolvimento, visando melhorias nos prazos de entrega e na qualidade dos softwares produzidos por sua Diretoria de Tecnologia e Disseminação de Informações Educacionais - DTDIE. Os softwares em questão utilizam a plataforma Web para coletar os dados de inscrições, divulgar locais de prova e resultados de exames como o ENEM (Exame Nacional do Ensino Médio), ENCCEJA (Exame Nacional para Certificação de Jovens e Adultos) e Prova Brasil. O total de usuários externos ao órgão atendidos por esses sistemas supera o número de 10 milhões de pessoas. O Inep é uma autarquia federal ligada ao Ministério da Educação, criada em 1937, que tem como missão promover pesquisas, estudos e avaliações do Sistema Educacional Brasileiro, visando dar subsídios à formulação e implantação de políticas públicas Inep (2011). O estudo de caso apresentado nessa monografia se deu entre os anos de 2008 e Durante esse período participamos da equipe que implantou o modelo de desenvolvimento aqui apresentado, de forma pioneira. No início do ano de 2008, o Inep desenvolvia seus sistemas utilizando o modelo Cascata. Esse modelo vinha atendendo até então, e, juntamente com a contratação externa de soluções de softwares, atendiam suficientemente a necessidade de sistemas de informação do órgão. No entanto, no referido ano, outras necessidades de desenvolvimento de softwares surgiram. Uma parte dessas necessidades ocorreu devido à difícil manutenção dos sistemas existentes. Esses sistemas utilizavam a estrutura cliente-servidor e precisavam se adaptar à nova realidade: a plataforma web. Outro motivo para o crescimento da quantidade de sistemas a serem desenvolvidos foi a ampliação do número de participantes dos exames administrados pelo instituto. Em 2009, as inscrições do Enem, por exemplo, passaram a ser efetuadas apenas via Internet. Dessa forma, o número de pessoas que utilizava o sistema de inscrição passou de 1,5 milhões para 4,8 milhões. Com todo esse acréscimo de necessidade de atendimento a DTDIE percebeu que precisava alterar o seu modelo de gestão de projetos e de desenvolvimento dos softwares. A metodologia ágil, então, foi escolhida como uma possível solução para 1

12 garantir que o desenvolvimento dos sistemas ocorresse dentro do prazo e com a qualidade necessária. O principal objetivo dessa monografia é apresentarmos a implantação da metodologia ágil dentro do Inep e demonstrarmos algumas alterações feitas na metodologia para melhor adaptação a características do órgão. Será apresentada a utilização dos protótipos como parte da documentação utilizada para levantamento de requisitos, sua utilização na fase de testes e na homologação dos sistemas. Desta forma demonstramos, através de um caso real, é que a utilização de protótipos no levantamento de requisitos para projetos que são administrados e desenvolvidos utilizando metodologia ágil tende a melhorar a qualidade do software produzido e reduzir a incidência de ocorrências de maior gravidade durante os testes, garantindo assim a satisfação dos envolvidos no projeto e dos usuários finais do sistema. Para tanto, o trabalho foi organizado em quatro partes: 1. No capítulo dois serão apresentados conceitos sobre a Engenharia de requisitos, apontando os tipos de requisitos e as formas de levantamento dos mesmos. 2. No terceiro capítulo apresentamos uma revisão bibliográfica sobre protótipos, suas classificações e usos, além dos objetivos de se utilizar. 3. O quarto capítulo é formado por duas partes: as metodologias ágeis de desenvolvimento de sistema e gerência de projetos e como os protótipos estão inseridos nesse contexto. 4. Por fim, apresentaremos o estudo de caso sobre a adoção da metodologia ágil no Inep e como a utilização dos protótipos foi importante para melhoria na qualidade dos softwares produzidos. 2

13 Capítulo 2 Engenharia de requisitos O desenvolvimento de softwares se inicia a partir do levantamento dos requisitos. Através deles podemos entender melhor qual o problema que deve ser resolvido através de um sistema ou mesmo quais os fatores que levam à necessidade de substituição de um já existente. Os clientes, que são os principais Stakeholders, têm em mente uma ideia do que desejam do sistema, e cabe ao analista transformar essa necessidade em requisitos. De maneira detalhada, Stakeholder é o termo usado para denominar a pessoa ou grupo de pessoas que são afetadas pelo sistema (Sommerville (2007)), e entende-se por requisito as características do sistema ou descrições de suas finalidades, incluindo tudo que ele é capaz de realizar para atender os anseios daquele que o idealizou Pfleeger (2004). 2.1 Tipos de requisitos O termo requisito é utilizado de maneira muito livre pela indústria de software. Para alguns é aceitável que ele possua um nível abstrato de definição. Para outros é necessário que seja uma definição formal e detalhada de cada uma das funções do sistema. Existe ainda a possibilidade de utilizar-se de ambos os tipos de requisitos, como por exemplo para a contratação do desenvolvimento de um software. Num primeiro momento, para possibilitar uma maior concorrência pode-se estabelecer apenas as diretrizes gerais do sistema. Após a escolha da empresa que desenvolverá o sistema os requisitos podem ser melhor detalhados. Os requisitos, segundo Sommerville (2007), podem ser classificados em: Requisitos de usuário: declarações em linguagem natural das necessidades que deverão ser supridas pelo sistema. Esses requisitos devem especificar, preferencialmente, apenas o comportamento externo do sistema, desta forma evitando interferir no projeto do software. Para escrever requisitos de usuário não é indicada a utilização de termos muito técnicos. Eles devem ser escritos da forma mais simples e intuitiva possível, tomando o máximo cuidado para que o documento seja claro, os requisitos bem diferenciados e destacados. Sommerville (2007) indica que se crie e/ou adote um padrão para levantamento desses requisitos. A padronização facilita a redução na quantidade de erros. 3

14 Requisitos de sistema: definem mais detalhadamente as funções, serviços e até mesmo as restrições. Deve ser um documento preciso e definir exatamente o que deverá ser implementado. A rigor tratam-se de uma versão expandida dos requisitos de usuário, que serão usados para projetar o sistema. Possui termos mais técnicos e maiores informações sobre o fluxo do sistema. Essa especificação pode ser utilizada para contratação do desenvolvimento do sistema, o que leva geralmente a ser feita antes do início do projeto. A existência de documentos com diferentes níveis de detalhamento das funcionalidades pode ser útil para a comunicação com diferentes tipos de leitores. Por exemplo, um documento pode ser apresentado ao contratante e outro ao stakeholder que utilizará mais diretamente o sistema. Requisitos funcionais são serviços ou funcionalidades que o sistema deverá oferecer. Em alguns casos esse tipo de requisito pode também ser utilizado para explicar o que não será atendido pelo sistema. Como exemplo podemos citar um sistema que faça o trâmite de documentos dentro de um escritório, mas que não será responsável pelo processo de digitalização dos mesmos. Esse tipo de requisito depende do tipo de sistema, dos Stakeholders e principalmente da orientação geral do desenvolvimento do sistema. Os requisitos funcionais podem expressar os do usuário, no entanto de maneira mais detalhada. As entradas, saídas e os processos internos do software devem fazer parte desse tipo de requisito. Requisitos não funcionais são restrições gerais sobre o sistema. Geralmente se aplicam ao sistema como um todo e podem estar relacionadas a propriedades necessárias, como por exemplo, sua segurança, disponibilidade e tempo de resposta. Podem também expressar restrições dos sistemas que não dizem respeito à sua implementação em si. É o caso da capacidade de processamento do hardware utilizado para suporte ao sistema, ou mesmo da velocidade de rede do ambiente onde o sistema estará disponível. Esses requisitos podem ter grande influência sobre o custo final do sistema. A produção de um sistema crítico, com alta disponibilidade e velocidade de processamento extrema, que é uma necessidade crescente do mundo atual, podem tornar o desenvolvimento do sistema mais complexo e interferir na escolha da linguagem e das ferramentas que serão utilizadas durante seu desenvolvimento. Desta forma os requisitos não funcionais podem estar ligados às restrições orçamentárias, ou até mesmo às necessidades de interoperação entre sistemas. Sommerville (2007) classifica os requisitos não funcionais em tipos. Esses tipos são apresentados na figura 2.1. Mais detalhadamente os grandes grupos de requisitos não-funcionais são: 1. De produto: dizem respeito ao comportamento do produto, como por exemplo, sua velocidade e a memória que será utilizada. Além disso, devem orientar o desenvolvimento do sistema quanto às necessidades de usabilidade, eficiência, confiabilidade e portabilidade, quando necessário. 4

15 Figura 2.1: Tipos de requisitos não funcionais (Sommerville (2007)). 2. Organizacionais: são produtos das políticas e procedimentos das organizações. Esses procedimentos são referentes, principalmente, aos padrões de desenvolvimento, procedimentos de implantação e/ou entrega de sistemas. 3. Externos: são as restrições referentes à interoperabilidade, às questões referentes à ética ou mesmo referentes ao aspecto legal do sistema. Os requisitos não funcionais, geralmente, são de difícil verificação, pois são definidos de maneira genérica em alguns casos. Por exemplo é difícil medir a usabilidade de um sistema. Uma forma de tentar resolver esse problema é se criando metas conforme representado na tabela 2.1 (Sommerville (2007)). 2.2 O levantamento de requisitos Pfleeger (2004) divide o processo de levantamento de requisitos em quatro etapas, conforme figura 2.2. Desta maneira, no primeiro momento, tem-se a análise do problema, iniciada com o trabalho de questionar os Stakeholders quanto às suas necessidades. Quando possível é importante mostrar as soluções já existentes, sistemas que atendem a necessidades similares produzidos anteriormente. Este trabalho de compreensão das necessidades possibilita uma visão mais acurada do problema que deverá ser resolvido. Posteriormente, é necessário descrever o entendimento do analista sobre o problema exposto. Este momento é importante para evitarmos descompassos no entendimento da questão a ser solucionada. De modo análogo, vale também analisar se estamos observando 5

16 Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade Medida Transações processadas por segundo Tempo de resposta de usuário para cada evento do sistema Tempo de demora para atualização de tela Medidas de armazenagem Número de chips de RAM Tempo necessário para treinamento de novos usuários Quantidade de opções de ajuda existentes no sistema Tempo médio das falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade do sistema Tempo para voltar à disponibilidade após uma falha. Probabilidade de corrupção de dados por falha Percentual de eventos que causam falhas O quanto o software depende do sistema operacional Quantidade de sistemas operacionais em que funciona. Tabela 2.1: Métricas para especificar requisitos não funcionais (Sommerville (2007)). o problema do ponto de vista correto. Caso sejam muitos os Stakeholders envolvidos no projeto, provavelmente será necessária a realização de uma reunião conjunta para uma melhor compreensão das várias necessidades e equalização dos diversos pontos de vista. Por mais preparada que seja a equipe que desenvolverá o sistema, caso os requisitos não sejam bem levantados ou os mesmos sejam ambíguos, ou ainda existam falhas no entendimento das necessidades, o projeto de software poderá passar por sérios problemas, muitas vezes podendo inclusive ser abandonado. Pressman (2006) indica que modificações nos requisitos dos sistemas trazem consigo um grande aumento na incidência de falhas na implementação do software. Para ilustrar tal fato, elaborou o gráfico presente na figura 2.3. Na tentativa de diminuir a incidência de modificações de requisitos, tem-se a terceira etapa do processo de requisitos, a prototipação. Para Pressman (2006) a prototipação ou prototipagem é: [...] um processo que capacita o desenvolvedor a criar um modelo do software que será implementado. Este modelo pode assumir uma das seguintes formas: 1. Um protótipo em papel ou um modelo baseado em PC que retrata a interação homem-máquina de uma forma que capacita o usuário a entender quanta interação ocorrerá; 2. Um protótipo de trabalho que implementa algum subconjunto da função exigida do software desejado; ou 3. Um programa existente que executa parte ou toda a função desejada, mas que tem características que serão melhoradas num novo esforço de desenvolvimento. 6

17 Figura 2.2: O processo de requisitos (Pfleeger (2004)). Figura 2.3: Curva de falhas para o software (Pressman (2006)). Outro conceito é aquele proposto por Bahn e Nauman (Bahn e Nauman, 1997, apud Lopez (2003)), que entendem protótipo como um processo de construção e avaliação do modelo de funcionamento de um sistema. Esse processo tem como finalidade auxiliar na aprendizagem de alguns aspectos dos requisitos do sistema e/ou suas potenciais soluções. Os benefícios da prototipação foram descritos por Gordon e Bieman e citados por Sommerville, em seu livro Engenharia de Software (Gordon e Bieman, 1995, apud Sommerville (2007)): 1. Usabilidade aprimorada do sistema 2. Adequação maior do sistema às necessidades do usuário 3. Qualidade do projeto final aprimorada 4. Facilidade de manutenção aprimorada 7

18 5. Esboço de desenvolvimento reduzido Como o trabalho se refere ao uso de protótipos na Engenharia de Requisitos, este assunto será abordado com maior profundidade no próximo capítulo. A quarta e última etapa se ocupa da definição e especificação dos requisitos, a partir da documentação e validação. Para facilitar o entendimento dos requisitos do sistema podemos gerar a documentação de diversas formas. Algumas incluem documentos extensos que descrevem cenários de utilização para todas as etapas e possibilidades de uso do sistema. São os denominados Casos de Uso, que são característica fundamental da UML (Unified Modeling Language).(Booch et al. (2000)) Em alguns ambientes de trabalho os Casos de Uso têm também a função de estabelecer um compromisso entre o Stakeholder e a equipe responsável pelo desenvolvimento. No entanto, algumas vezes o documento pode ser de difícil leitura por pessoas que não estão familiarizadas com seu formato e suas características, caso da maioria dos Stakeholders. Um caso de uso bem estruturado tem de conter pelo menos os seguintes fluxos (Larman (2007)): 1. Fluxo de eventos principal: contém o caminho comum a todos usuários do sistema. 2. Fluxo de eventos alternativos: contém os caminhos alternativos do sistema, que podem ou não ser apresentados para os usuários. 3. Fluxo de exceção: contém, principalmente o comportamento do sistema quando ocorre alguma exceção no fluxo de utilização do sistema. É o fluxo responsável pelo tratamento dos erros. A UML prevê o Diagrama de Casos de Uso como um agrupador das funções que os atores têm dentro do sistema. A categoria ator é utilizada para representar os papéis que os usuários desempenham quando interagem com os casos de uso. (Booch et al. (2000)) Os atores e casos de uso são representados conforme figura 2.4. Figura 2.4: Caso de uso Outros documentos utilizados no desenvolvimento do sistema, como o Modelo de Dados ou a Estrutura Analítica do Projeto também geram muitas dúvidas se forem apresentados aos Stakeholders. A dificuldade força, na maioria das vezes, a explicação detalhada 8

19 do documento em si pelos Analistas de Requisitos. Isto prejudica o verdadeiro foco dos encontros: o levantamento dos requisitos para construção do sistema. Um documento de especificação de requisitos bem elaborado evita problemas na etapa da validação do sistema, uma vez que tem de ser aceito ou não pelo usuário. Nos próximos capítulos, serão descritos o processo de prototipagem e os tipos de protótipo, para entender de que modo a utilização destes modelos pode auxiliar no levantamento de requisitos e na produção de documentos na Metodologia Ágil. 9

20 Capítulo 3 Prototipagem no processo de desenvolvimento de softwares Quando se pretende construir um imóvel, ou mesmo efetuar uma reforma em algum já pronto, é certo não se iniciar sem antes se ter uma idéia de como ficará a construção. Para permitir que o cliente saiba aproximadamente como ficará a sua obra, os engenheiros e arquitetos utilizam plantas e maquetes. Com base nessas plantas e maquetes, o cliente então passa a conhecer e poder solicitar mudanças no planejamento da obra, na posição dos quartos ou no tamanho da sala, por exemplo. De maneira análoga o uso de protótipos no desenvolvimento de softwares permite aos stakeholders visualizar desde o antes do início do desenvolvimento como o sistema ficará quando completamente desenvolvido. O uso da prototipagem no desenvolvimento de softwares pode ir mais além. Engenheiros e arquitetos provavelmente não poderão, sem um gasto elevado, ou a utilização de outras tecnologias, propiciar aos seus clientes a sensação de estarem em sua sala de estar no segundo andar, antes mesmo do primeiro andar estar pronto. O uso dos protótipos no desenvolvimento de softwares permite que os stakeholders possam, por exemplo, verificar como ficarão os seus relatórios antes mesmo da interface de captação dos dados estar pronta. A prototipagem pode ser vista como uma técnica que permite a validação, avaliação e demonstração da interface de um software que será desenvolvido, dando suporte às iterações rápidas e ao esclarecimento de dúvidas restantes do levantamento de requisitos. Podemos utilizar diversas ferramentas diferentes para desenvolver os protótipos. Muitas vezes a tecnologia utilizada no seu desenvolvimento difere da utilizada no desenvolvimento do sistema em si. Exemplos de tecnologias que podem ser utilizadas na prototipagem (Frank et al. (1995)): HTML - Hyper Text Markup Language Papel e caneta JSP - Java Server Pages ASP.NET CSS - Cascading Style Sheets Editores de imagem 10

21 Como exemplo prático da utilização de diferentes tecnologias nas etapas de desenvolvimento e prototipagem podemos citar a utilização de papel e caneta para o desenvolvimento do protótipo, e de qualquer linguagem de programação para desenvolvimento do sistema. Essa liberdade torna o processo de prototipagem de fácil inserção nas diferentes metodologias de desenvolvimento, sendo possível inclusive escolher qual a tecnologia deve ser utilizada em cada fase do desenvolvimento do sistema. Na fase inicial pode ser interessante utilizar um protótipo em linguagem de programação, como forma de adiantar o andamento do projeto, possibilitando uma reutilização do protótipo. Ou, nesta mesma fase pode se optar por tecnologias que tornem a prototipação mais rápida, como a utilização de editores de imagem. 3.1 Prototipação e objetivos Um modelo de processo para o desenvolvimento de protótipos funcionais foi definido por Sommerville (2007) e é apresentado na figura 3.1. Figura 3.1: Processo de desenvolvimento de protótipos.(sommerville (2007)). Os objetivos da prototipação devem ser definidos: a validação da interface com o usuário, um estudo da viabiliade do desenvolvimento da aplicação ou a validação dos requisitos são algumas das possibilidades. É possível ainda abranger todos esses objetivos com um único protótipo. Posteriormente, é necessário definir o que será implementado e o que não será implementado no protótipo. É importante que o desenvolvimento do protótipo não adicione custos muitos altos ao processo de desenvolvimento do sistema. Da mesma maneira, o seu desenvolvimento não deve consumir muito tempo da equipe. Por último, para que a avaliação seja feita adequadamente, é necessário que o usuário tenha tempo para validar o protótipo. Uma validação feita apressadamente pode esconder falhas no levantamento dos requisitos ou na simulação da atividade a qual se destina o software. A utilização dos protótipos possibilita ao Stakeholder, desde o princípio do desenvolvimento do sistema, poder validar as entradas de dados e o posicionamento dos campos nas telas, entre outros detalhes. Estabelece-se, assim, uma relação de cumplicidade entre o stakeholder e a equipe de desenvolvimento, devido à compreensão mais real dos requisitos levantados e do sistema que será produzido a partir destes. Além disso, as reuniões de apresentação dos protótipos servem para dar a sensação de que o projeto está evoluindo, em contraposição ao sentimento de isolamento experimentado quando o projeto só é visto meses após sua especificação inicial. 11

22 Esta utilização de protótipos, aliada à adoção de entregas parciais, contribuem em muito para a redução dos gastos referentes às alterações feitas nos softwares após a sua entrega final. O risco envolvido na entrega de um sistema cuja interface só será conhecida quando o desenvolvimento já estiver concluído é alto, pois além da possibilidade da interface desenvolvida não agradar, os stakeholders podem mudar de opinião com o tempo, e neste caso já não gostarem da solução que foi planejada no começo da jornada de desenvolvimento. Esse descontentamento poderá se tornar irreversível, fazendo o software desenvolvido não ser utilizado. Atualmente, não basta ao sistema executar a função para qual foi desenvolvido. É necessário que ele tenha uma interface amigável e intuitiva. O desenvolvimento das interfaces representa 48% do código do software e 1/3 do esforço de revisão do sistema após sua entrega (Nielsen (1993)). Desta maneira, quanto mais próxima estiver a interface da necessidade do cliente, maior a chance de obtermos uma redução no esforço de revisão. 3.2 Uso dos protótipos em testes A utilização dos protótipos vai além da validação dos requisitos. Eles podem também serem utilizados nas etapas de teste e para realizar experimentos, que possibilitem o estudo da viabilidade do projeto proposto. No caso da utilização para testes, os protótipos auxiliam na resolução de um dos maiores problemas destes: validar os resultados e respostas enviadas pelo sistema. Podemos utilizar os protótipos para realização de testes back-to-back, comparando as respostas do sistema com os protótipos do mesmo e gerando-se relatórios de diferenças. Essa utilização facilita a homologação com o cliente final, visto que a própria equipe envolvida no desenvolvimento do sistema, de posse dos protótipos aprovados pelos stakeholders pode adiantar a homologação do sistema, percebendo diferenças entre os protótipos e o software desenvolvido. Nesse caso, aliada à facilitação dos testes em si, a utilização dos protótipos pode evitar desgastes desnecessários junto aos clientes. Sommerville (2007) ilustra o teste back-to-back conforme descrito na figura Tipos de protótipos Quanto à reutilização e funcionalidades implementadas Quanto à possibilidade de reutilização, Pfleeger (2004) define protótipos de requisitos da seguinte maneira: 1. Protótipos descartáveis (throw-away): tem caráter exploratório e são utilizados para se aprender mais sobre o problema que se pretende resolver ou para explorar a viabilidade das possíveis soluções para o mesmo. Podem ser apresentados em papel ou mesmo em formado digital, mas não permitem a interação do usuário. Pode ser utilizado apenas no início do desenvolvimento dos protótipos, pois é de mais rápido desenvolvimento e de baixo custo, ou como único tipo de protótipo. O protótipo descartável retratado na figura 3.3 foi desenvolvido em um editor de imagens. 12

23 Figura 3.2: Teste back-to-back (Sommerville (2007)). Figura 3.3: Exemplo de campos em um protótipo descartável Uma das vantagens deste tipo de protótipo é a sua rápida criação. Além disso, já que a sua função principal não é demonstrar interface ao usuário, a atenção durante sua criação recai somente sobre as funcionalidades do sistema, deixando em segundo plano a interface do mesmo. Os protótipos não funcionais facilitam o entendimento durante um encontro de levantamento de requisito e devem ser utilizados quando lidamos com stakeholders muito ocupados ou impacientes. Esse protótipo após apresentado é descartado, não sendo utilizado como parte do software final. Pode ser utilizando, por exemplo, quando o ciclo de entregas ou o prazo de desenvolvimento do projeto são curtos. As funcionalidades, navegação e interfaces, serão apresentadas nas entregas parciais sequentes. 2. Protótipos evolutivos: permitem navegação no sistema, dando ao usuário a sensação de estar realmente utilizando um software totalmente implementado. Esse tipo de 13

24 protótipo permite acessar as páginas do sistema e simular a sua interação com o mesmo. Têm como principal vantagem a simulação mais real do que será construído. O cliente pode então opinar na sequência de páginas (quando existirem), no posicionamento dos botões e até nas cores do sistema, validando desta maneira toda a interface humano-computador. Pode ser reutilizado posteriormente no desenvolvimento do sistema. Aplica-se a partes do projeto sobre as quais o cliente apresenta dúvidas, relativas principalmente a interface e o fluxo. Por exemplo, caso o cliente tenha dúvidas sobre a utilização de uma combo-box ou um check-box, protótipos evolutivos podem ser apresentados e o aprovado incorporado no projeto Quanto à fidelidade A fidelidade de um protótipo pode ser avaliada em quatro dimensões: (Mayhew (1999) appud dos Santos (2006)) 1. Detalhamento: a quantidade de detalhes que o modelo suporta. Um protótipo feito com papel e caneta, por exemplo suporta menos detalhes que um desenvolvido em software. 2. Funcionalidades: o quanto o protótipo possui de operações implementadas. 3. Similaridade de interação: o quanto a interação do usuário com o protótipo se assemelha com a do software final. 4. Estética: o quanto a interface gráfica utilizada é parecida com a do software final. Os protótipos podem ser de baixa ou alta fidelidade. Essa separação é criada avaliandose os protótipos conforme citado acima. Protótipos de alta fidelidade São os protótipos que se assemelham em muito ao produto final. Para esse tipo de protótipo recomenda-se a utilização da mesma linguagem que será utilizada no sistema final uma vez que sua reutilização no desenvolvimento do sistema é comum. A utilização da mesma linguagem, no entanto, muitas vezes pode não ser possível, devido a critérios como tempo necessário ou mesmo priorização do desenvolvimento de outros módulos do sistema, que já possuem requisitos levantados e aprovados. Indica-se sua utilização quando o objetivo é a venda de um sistema ou o teste quanto a problemas técnicos (da Cunha (2007)). Essa recomendação se dá por ser o tipo de protótipo que mais se aproxima do sistema que será desenvolvido. Portanto ao apresentálo durante um processo de venda, o cliente terá a sua disposição uma visão próxima do produto final. Como vantagens do uso de protótipos de alta fidelidade temos: 1. Funcionalidades completas. 2. Acesso do usuário ao protótipo diretamente. 14

25 3. Navegação completa no sistema. 4. Exploração e teste do sistema. 5. Utiliazação como ferramenta de venda e marketing. 6. Especificação do sistema de forma interativa. Como desvantagens podemos citar: 1. Elevado investimento de tempo para desenvolvimento. 2. Elevado investimento financeiro para desenvolvimento. 3. Ineficiente para provas de conceito. 4. Ineficaz para aquisição de novos requisitos. 5. Aparência de software pronto, o que pode gerar falsas expectativas nos clientes. Protótipos de baixa fidelidade Sua função principal é elucidar novos requisitos do sistema. Possuem um tempo de vida muito curtos, sendo possível modificá-los muito rapidamente durante seu desenvolvimento.(medeiros et al. (2008)) Como vantagens da sua utilização podemos citar: 1. Custos mais baixos. 2. Vários conceitos de design podem ser implementados. 3. Rápido desenvolvimento. 4. Identificação de requisitos de mercado. 5. Pode ser utilizado como prova de conceito. As seguintes desvantagens podem ser listadas: 1. Especificação de código fraca. 2. Verificação de erros limitada. 3. Pouca utilidade após fase de requisitos. 4. Pouco útil para testes de usabilidade. 5. Limitações de fluxo e navegação Quanto à abrangência de funcionalidades Os protótipos podem ser também classificados de acordo com sua abrangência, conforme figura

26 Figura 3.4: Protótipo vertical x Protótipo Horizontal (Nielsen (1993)). 1. Protótipo vertical: Contém poucas das funcionalidades do sistema, implementadas com maior profundidade. Esse protótipo é, na maioria das vezes, reutilizado no desenvolvimento da solução final. Por conter toda a implementação de uma função do sistema, esse tipo de protótipo deve ser utilizado em pontos críticos, onde existe maior dificuldade no entendimento na especificação dos requisitos ou ainda para avaliar soluções de softwares possíveis. 2. Protótipo horizontal: Contém todas as funções do sistema, implementadas apenas na camada de interface. Esse protótipo é usado para simulação da interface e identificação de possíveis funcionalidades que não tiveram seus requisitos levantados. Geralmente são protótipos descartáveis, visto que podem ser desenvolvidos em outra linguagem, diferente da utilizada no sistema ou mesmo feito em papel. Existe ainda uma terceira abordagem, apontada por Dumas and Redish (1994) que propõe uma área de intersecção, denominada protótipo de cenário (Nielsen and Mack (1994)). Esse tipo de protótipo é orientado à tarefa, sendo implementado apenas em camada de apresentação, em algumas partes, e com maior profundidade, quando se busca solucionar o entendimento de determinada função do sistema ou ainda demonstrar os caminhos possíveis. Dumas e Redish propuseram uma nova representação, aqui apresentada pela figura 3.5, para ilustrar esse tipo de protótipo, modificando a anteriormente publicada por Nielsen (1993) Protótipos Globais e locais Para finalizar a classificação dos protótipos, eles podem também serem classificados em Globais e Locais. Essa classificação se assemelha com a classificação em Horizontal e Vertical. Os protótipos globais abrangem todas as funcionalidades do sistema. A diferença para entre o protótipo global e o horizontal é que no primeiro caso podem haver diferentes níveis de implantação em cada parte do sistema. O protótipo local tem como objetivo tratar de detalhes objetivos do sistema, não necessariamente sendo necessária a implementação em profundidade da solução, como no protótipo vertical. O protótipo 16

27 Figura 3.5: Protótipo de cenário local também costuma ser utilizado por pouco tempo, sendo descartado após a solução do problema Protótipo Storyboarding Trata-se de uma técnica que expressa o comportamento do sistema, projeto ou intenção de implementação baseando-se na perspectiva do usuário através da utilização de imagens. Esta técnica foi utilizada no cinema e em desenhos animados, por poder representar um esboço dos personagens e da história (Gonçalves et al. (2005)). O storyboarding é um tipo de protótipo de baixa fidelidade que pode ser classificado em (Leffingwell and Widrig (2003) appud Gonçalves et al. (2005)): Passivo: São constituídos de quadros, fotos, esboços, etc. Neste caso são apresentadas ao usuário as regras do sistema em sua sequência, com uma explanação do tipo Quando você faz isto, acontece isto ; Ativo: Corresponde a uma sequência de figuras que mostram uma descrição automatizada do modo como o sistema se comporta em um uso típico ou em um cenário operacional, por exemplo, em uma apresentação automática de slides; Interativo: Permite ao usuário interagir sobre o sistema de um modo mais realístico, exigindo sua participação. Pode ser uma simulação dos possíveis cenários (protótipo não-funcional), ou mesmo um protótipo funcional simplificado do sistema. 17

28 3.3.6 Protótipo em papel Segundo Snyder (2003), protótipos em papel é um método amplamente utilizado para desenho de interface, testes e ajustes juntamente aos usuários. No início dos anos 1990 era um método pouco conhecido pela maioria das equipes de desenvolvimento de software. É notavelmente o meio mais simples e rápido de se construir um protótipo visto que utiliza materiais simples, como papel, lápis e régua, para desenhar a interface humanocomputador. Após desenhados os protótipos pode-se demonstrá-los aos stakeholders e efetuar os ajustes e correções necessárias rapidamente. Snyder (2003) considera essa técnica de protótipação como um método de criação, um brainstorming. No entanto para tarefas de prototipagem que envolvam muitas telas esse processo pode se tornar cansativo, tornando latente a necessidade de utilização de ferramentas automatizadas. Figura 3.6: Protótipo em papel (Snyder (2003)) Mágico de Oz (Wizard of Oz ) Essa técnica de prototipagem utiliza um operador humano (o mágico de Oz) para simular o comportamento do software, processando e simulando a resposta do software. É uma prototipagem barata, pois somente a interface do sistema precisa estar desenvolvida. A pessoa que opera o sistema pode ser ou não exibida ao usuário, pois podemos utilizar ferramentas de controle a distância para controlar o computador. Essa técnica é indicada quando se pretende incluir no sistema funcionalidade complexas ou avaliar idéias mais inovadoras de design (de Souza Coutinho (2006)). 18