JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE TESTES EM SOFTWARE LONDRINA - PARANÁ 2010

1 JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE TESTES EM SOFTWARE LONDRINA - PARANÁ 2010

2 JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE TESTES EM SOFTWARE Relatório Final de Estagio Obrigatório apresentado ao Curso de Ciência da Computação, no Departamento de Computação da Universidade Estadual de Londrina, como requisito para a obtenção do título de Bacharel, sob orientação do Prof. Dr. Rodolfo Miranda de Barros. LONDRINA - PARANÁ 2010

3 JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE TESTES EM SOFTWARE Prof. Dr. Rodolfo Miranda de Barros Universidade Estadual de Londrina Prof. Dr. Mario Lemes Proença Jr. Universidade Estadual de Londrina Prof. Ms. Elieser Botelho Manhas Jr. Universidade Estadual de Londrina

4 RESUMO Este estágio propõe o desenvolvimento de uma ferramenta que facilite a documentação e o relatório dos testes executados em softwares, ou seja, uma ferramenta de Gerenciamento de Testes. Com o conceito de Web App, essa ferramenta tem por objetivo trocar os documentos preenchidos em papel quando uma atividade de teste é encerrada por uma interface visual simples, com o propósito de facilitar a descrição, documentação, consulta, recuperação e o relatório dos testes. Vale ressaltar que este projeto faz parte de um projeto maior que visa o desenvolvimento de um conjunto de ferramentas de apoio ao processo de desenvolvimento de software. Palavras-Chaves: Gerenciamento de Testes, Web App, ADS, EJB.

5 SUMÁRIO 1 INTRODUÇÃO... 10 2 PROCEDIMENTOS METODOLÓGICOS... 13 2.1 MYECLIPSE 8.0... 13 2.2 ENTERPRISE JAVABEANS 3.0... 13 2.3 JBOSS APPLICATION SERVER 5.1(JBOSS AS)... 15 2.4 JDK 1.5... 16 2.5 RICHFACES 3.3.1... 16 2.6 POSTGRESQL 8.4.0... 16 3 O PROCESSO DE DESENVOLVIMENTO... 18 4 CASOS DE USO... 22 4.1 ESPECIFICAÇÃO DE CASO DE USO: <MANTER TESTES>... 23 4.1.1 Descrição... 24 4.1.2 Fluxo Básico... 24 4.1.3 Fluxos Alternativos... 24 4.1.4 Requisitos especiais... 25 4.1.5 Precondições... 25 4.1.6 Pós-condições... 25 4.1.7 Pontos de Extensão... 25 4.1.8 Local View... 25 4.1.9 Definição dos atributos... 26 4.1.10 Protótipo da Interface... 27 4.2 ESPECIFICAÇÃO DE CASO DE USO: <MANTER CASO DE TESTES>... 27 4.2.1 Descrição... 27 4.2.2 Fluxo Básico... 27 4.2.3 Fluxos Alternativos... 28 4.2.4 Requisitos especiais... 28 4.2.5 Precondições... 28 4.2.6 Pós-condições... 29 4.2.7 Pontos de Extensão... 29 4.2.8 Local View... 29 4.2.9 Definição dos atributos... 30 4.2.10 Protótipo da Interface... 31 4.3 ESPECIFICAÇÃO DE CASO DE USO: <MANTER PROCEDIMENTOS DE TESTE>... 31 4.3.1 Descrição... 31 4.3.2 Fluxo Básico... 31 4.3.3 Fluxos Alternativos... 32 4.3.4 Requisitos especiais... 32 4.3.5 Precondições... 32 4.3.6 Pós-condições... 32 4.3.7 Pontos de Extensão... 33 4.3.8 Local View... 33 4.3.9 Definição dos atributos... 34 4.3.10 Protótipo da Interface... 34 4.4 ESPECIFICAÇÃO DE CASO DE USO: <MANTER RELATÓRIO RESUMIDO>... 35

6 4.4.1 Descrição... 35 4.4.2 Fluxo Básico... 35 4.4.3 Fluxos Alternativos... 35 4.4.4 Requisitos especiais... 36 4.4.5 Precondições... 36 4.4.6 Pós-condições... 36 4.4.7 Pontos de Extensão... 36 4.4.8 Local View... 36 4.4.9 Definição dos atributos... 37 4.4.10 Protótipo da Interface... 38 4.5 ESPECIFICAÇÃO DE CASO DE USO: <MANTER HISTÓRICO>... 38 4.5.1 Descrição... 38 4.5.2 Fluxo Básico... 39 4.5.3 Fluxos Alternativos... 39 4.5.4 Requisitos especiais... 39 4.5.5 Precondições... 39 4.5.6 Pós-condições... 40 4.5.7 Pontos de Extensão... 40 4.5.8 Local View... 40 4.5.9 Definição dos atributos... 41 4.5.10 Protótipo da Interface... 42 5 DIAGRAMAS... 43 5.1 DIAGRAMA DE ARQUITETURA... 43 5.2 DIAGRAMA DE ATIVIDADES... 44 5.3 DIAGRAMA DE CLASSES... 44 5.4 DIAGRAMA DE ENTIDADE E RELACIONAMENTO... 44 6 RELATÓRIO DE TESTES... 46 6.1 HISTÓRICO DA REVISÃO... 46 6.2 INTRODUÇÃO... 46 6.2.1 Ambiente... 46 6.3 CRITÉRIOS DE COMPLETEZA... 47 6.4 ESPECIFICAÇÃO DOS TESTES... 47 6.4.1 Procedimentos de teste... 48 6.5 CASOS DE TESTE E INCIDENTES DOS TESTES... 52 6.5.1 Página Teste... 52 6.5.2 Página Caso de Teste... 53 6.5.3 Página Relatório Resumido... 54 6.5.4 Página Histórico... 54 6.6 RELATÓRIO RESUMIDO DOS TESTES... 55 7 CONSIDERAÇÕES FINAIS... 56 8 BIBLIOGRAFIA... 57

7 LISTA DE FIGURAS Figura 3.1: Processo de Desenvolvimento 1... 19 Figura 3.2: Interface 1... 21 Figura 3.3: Interface 2... 22 Figura 4.1: Diagrama dos Casos de Uso 1... 23 Figura 4.2: Local View 1... 25 Figura 4.3: Protótipo de Interface 1... 27 Figura 4.4: Local View 2... 29 Figura 4.5: Protótipo de Interface 2... 31 Figura 4.6: Local View 3... 33 Figura 4.7: Protótipo de Interface 3... 34 Figura 4.8: Local View 4... 36 Figura 4.9: Protótipo de Interface 4... 38 Figura 4.10: Local View 5... 40 Figura 4.11: Protótipo de Interface 5... 42 Figura 5.1: Arquitetura Web 1... 43 Figura 5.2: Diagrama de Atividades 1... Anexo Figura 5.3: Diagrama de Classes 1... Anexo Figura 5.4: Diagrama ER 1... 45

8 LISTA DE TABELAS Tabela 4.1: Definição dos Atributos 1... 26 Tabela 4.2: Definição dos Atributos 2... 30 Tabela 4.3: Definição dos Atributos 3... 34 Tabela 4.4: Definição dos Atributos 4... 37 Tabela 4.5: Definição dos Atributos 5... 41 Tabela 6.1: Histórico da Revisão 1... 46 Tabela 6.2: Ambiente 1... 47 Tabela 6.3: Critérios de Completeza 1... 47 Tabela 6.4.1: Procedimentos de teste 1... 48 Tabela 6.4.2: Procedimentos de teste 2... 48 Tabela 6.4.3: Procedimentos de teste 3... 48 Tabela 6.4.4: Procedimentos de teste 4... 49 Tabela 6.4.5: Procedimentos de teste 5... 49 Tabela 6.4.6: Procedimentos de teste 6... 50 Tabela 6.4.7: Procedimentos de teste 7... 50 Tabela 6.4.8: Procedimentos de teste 8... 50 Tabela 6.4.9: Procedimentos de teste 9... 51 Tabela 6.4.10: Procedimentos de teste 10... 51 Tabela 6.4.11: Procedimentos de teste 11... 51 Tabela 6.4.12: Procedimentos de teste 12... 52

9 LISTA DE ABREVIATURAS Web App Web Aplication IEEE - Institute of Electrical and Electronics Engineers STE Software Testing Enviroments IDE Integrated Development Environment J2EE Java 2 Enterprise Edition JSF Java Server Faces TI Tecnologia da Informação EJB Enterprise Java Beans API Application Programming Interface ORM Object Relational Mapping POJO Plain Old Java Object JVM Java Virtual Machine JDK Java Development Kit SGBDOR Sistema Gerenciador de Banco de Dados Objeto Relacional WBS Work Breakdown Structure ADS Ambiente de Desenvolvimento de Software GPL General Public License PMBOK Project Management Body of Knowledge MPS-BR Modelo de Processo de Software Brasileiro HTML HyperText Markup Language CSS Cascading Style Sheets XML Extensible Markup Language

10 1 INTRODUÇÃO Atualmente, a busca pela melhoria do processo de software se tornou algo primordial para que empresas desenvolvam produtos com qualidade e dentro de padrões pré-definidos, facilitando modificações futuras. A área de Testes de Softwares é fundamental neste processo de desenvolvimento. Além de utilizar métodos para comprovar que os requisitos especificados previamente foram cumpridos, e os requisitos não especificados não constam no software, os testes ajudam o desenvolvedor a mensurar a qualidade de um software baseando-se no número de defeitos encontrados. Como em qualquer outra área, os testes necessitam ser criados, documentados e apresentar a possibilidade de relatar erros encontrados durante a aplicação. Existem alguns modelos para a documentação, como o IEEE Standard for Software Test Documentation [3], criado pela IEEE Computer Society, que traz uma lista de documentos básicos para testes de softwares. No desenvolvimento de software é necessário criar soluções tecnológicas utilizando como base os requisitos que o cliente apresenta. A Engenharia de Software preocupa-se em tratar todos os requisitos para que o projeto obtenha a melhor qualidade possível, dentro de prazos controlados e com custos compatíveis com o mercado [4]. São necessárias melhorias neste cenário, como por exemplo, a automatização de algumas fases do desenvolvimento acarretando ganho de desempenho e aumento da qualidade. Segundo [6], a qualidade do produto final em um desenvolvimento de software depende dos métodos, técnicas e ferramentas que o desenvolvedor usa. Uma escolha mal feita destes pode afetar não só a qualidade como também o custo do projeto. Por este motivo é de grande importância que projetos sejam feitos obedecendo a padrões e métricas. Existem estágios definidos no desenvolvimento, em [2] o primeiro estágio de um desenvolvimento de software envolve a elaboração de uma proposta para executar o projeto. A proposta descreve os objetivos do projeto e como ele será realizado. Em geral inclui também estimativas de custo e programação. Um

11 gerenciamento eficaz de um projeto de software depende de um planejamento acurado do andamento do projeto. Ainda sobre o desenvolvimento, podemos citar [8] na questão que trata do modelo de qualidade de software, quando usamos um modelo podemos medir variáveis independentes mais cedo do que outras no ciclo de desenvolvimento, mas ainda precisaríamos medir as variáveis dependentes do processo. Para essas podem-se predizer seus valores baseando-se nas variáveis independentes dos módulos. Assim, com os modelos estatísticos podem-se estimar parâmetros para módulos similares baseando nas variáveis dependentes e independentes de cada um. A maioria dos projetos segue um cronograma de atividades chamado ciclo de vida. Os ciclos de vida diferem de um projeto para outro no número de iterações, fases, métodos de controle e número de protótipos criados. Ao final do ciclo de vida de um desenvolvimento de software encontra-se a fase de testes, que verifica se o sistema produzido está livre de erros de programação, lógica e se corresponde aos requisitos previamente especificados. Em [1] cita-se que, sobre vários aspectos, o teste é um processo independente e o número de tipos diferentes de testes varia tanto quanto as diferentes abordagens de desenvolvimento. Os testes em software podem ser separados em duas categorias: os que são baseados nas especificações funcionais dos sistemas (chamado de testes de black-box ou testes de caixa-preta), e os que são baseados nas estruturas internas dos sistemas (chamado de testes de white-box ou testes de caixa-branca), essas categorias são utilizadas levando em conta a área do sistema que deseja-se verificar erros[5]. A Verificação e Validação são nomes dados aos processos de verificação e análise que asseguram que o software cumpra com suas especificações e atenda às necessidades dos clientes que estão pagando por ele. A verificação e validação constituem um processo de ciclo de vida completo, começando com as revisões dos requisitos e continuando com as revisões do projeto e as inspeções de código até chegar aos testes dos produtos [2]. Alguns autores como [7], mostram que a evolução dos testes está sendo baseada em Software Testing Environments (STEs), consistindo em ambientes automatizados específicos para testes de softwares, buscando maior eficiência e aumento no número de capacidades dos testes.

12 Ainda que algumas empresas não possuam seu sistema de testes baseados em automação, é possível automatizar os documentos utilizados na aplicação dos testes e na documentação dos mesmos. Com isso conseguiríamos aumentar o desempenho, melhorar a qualidade e facilitar a execução da fase de testes de software. A ferramenta de Gerência de Testes em Software foi desenvolvida dentro da Fábrica de Software GAIA, dentro do Departamento de Computação, no Centro de Ciências Exatas (CCE) na Universidade Estadual de Londrina. Uma fábrica de software é uma organização que provê serviços de desenvolvimento de sistemas com alta qualidade, baixo custo e de forma rápida, utilizando um processo de desenvolvimento de software bem definido e tecnologia de ponta, além de algumas formas de feedback para reconhecer e lidar com oportunidades de melhoria do processo [15]. A Fábrica GAIA utiliza um processo de desenvolvimento baseado no Processo Unificado, iterativo e incremental [16], direcionado a casos de uso e centrado na arquitetura. Este trabalho está dividido da seguinte forma: no Capitulo 2 serão apresentados os conceitos utilizados no desenvolvimento da ferramenta, bem como os métodos utilizados, no Capitulo 3, será apresentado o modelo de Processo de Desenvolvimento utilizado. No Capitulo 4 serão apresentados os Casos de Uso da ferramenta desenvolvida, no Capitulo 5 serão apresentados os diagramas que compõem a documentação da ferramenta, no Capítulo 6 será apresentado o relatório dos testes executados para verificar a conformidade e a qualidade da ferramenta, e finalmente no Capítulo 7 serão apresentadas as considerações finais.

13 2 PROCEDIMENTOS METODOLÓGICOS Os procedimentos metodológicos apresentados a seguir têm como objetivo demonstrar todo o ambiente e ferramentas utilizadas desde a arquitetura até o processo final de testes e implementação. 2.1 MyEclipse 8.0 O MyEclipse 8.0[9] é uma IDE J2EE que foi construído sobre a plataforma Eclipse e integra soluções proprietárias e open source no ambiente de desenvolvimento. Ele adiciona ferramentas de banco de dados, um designer visual para web, ferramentas de persistência, Struts e JSF, e outras características básicas do Eclipse. Um dos principais motivos da escolha dessa IDE para o desenvolvimento foi sua capacidade de trabalhar com a persistência de objetos em Banco de Dados. O MyEclipse oferece outras vantagens como facilidade de adaptação para novos desenvolvedores e continuidade de desenvolvimento na mesma IDE. 2.2 Enterprise JavaBeans 3.0 Existem várias aplicações de software que executam funções empresariais e tipicamente envolvem grandes quantidades de dados que são simultaneamente acessados por muitos usuários. Estas aplicações raramente executam isoladamente. Ao invés disto, cada uma é normalmente apenas um pedaço do quebra-cabeça da paisagem do TI de uma companhia, e tem que interagir com as pessoas e com outros sistemas. Resumindo, o desenvolvimento de aplicações empresariais é um trabalho difícil. Aspectos como o desempenho, escalabilidade, concorrência e segurança devem ser contemplados em quase todas as aplicações empresariais, para que as mesmas cumpram adequadamente o seu papel na empresa. Em resposta a estes desafios, a especificação do EJB foi introduzida em março de 1998, para tornar mais fácil a confecção de sistemas empresariais distribuídos

14 orientados a objeto. A especificação e os servidores de aplicação que implementam a maior parte de estas funcionalidades, tiveram sucesso em atingir estes objetivos. Porém através dos anos, as falhas do EJB, junto com o advento de alternativas mais simples, fizeram com que muitos questionassem se o EJB oferece a melhor solução para o desenvolvimento produtivo de aplicações empresariais. Falhas do EJB frequentemente citadas incluem o seguinte: Componentes que queiram tirar vantagem dos serviços empresariais fornecidos estarão ligados à API EJB; É uma proposta do tipo tudo ou nada. Mesmo que quisermos apenas um serviço do EJB, temos que aceitar tudo o que vem com ele; Componentes do EJB requerem um recipiente (container) e são difíceis de testar; Cada EJB requer vários artefatos (interfaces, classes e descritores); Arquiteturas EJB tradicionais são menos orientadas a objeto e introduzem "falsos objetos" que têm só estados e nenhum comportamento. Alternativas populares para o EJB incluem o seguinte: Programação Orientada a Aspecto (Aspect Oriented Programming); Recipientes de peso leve tais como Spring, Pico Container e Hivemind; Ferramentas de mapeamento objeto-relacional (Object Relational Mapping - ORM) tais como Hibernate JPA;.NET como componentes de serviços. Para solucionar algumas das falhas citadas anteriormente foi criado então o Enterprise JavaBeans 3.0, ou EJB 3.0[10], que têm por objetivo fornecer aos desenvolvedores um gerenciamento automático de muitos serviços essenciais aos aplicativos. A especificação do projeto público do EJB 3.0, objetiva facilitar o desenvolvimento e tornar mais simples a alavancagem dos serviços empresariais. Alguns aspectos do EJB 3.0 incluem: O modelo de programação POJO (Plain Old Java Object Antigo Objeto Java Simples);

15 O framework de persistência leve ORM; Injeção de dependência; Comentários Metadata. Outros aspectos notáveis da especificação EJB 3.0 incluem: Configuração por exceção; Eliminação de interfaces de componente; Eliminação de interfaces home; Redução do uso de exceções verificadas. 2.3 JBoss Application Server 5.1(JBoss AS) O JBoss Aplication Server[11] é um servidor de aplicação open source baseado no J2EE. É o responsável por fornecer a infraestrutura de serviços para a execução de aplicações distribuídas. Os servidores de aplicação são executados em servidores e são acessados pelos clientes através de uma conexão de rede. Existem várias versões JBoss, tais como: JBoss AS 4.0: um servidor de aplicações Java EE 1.4, possui um container Apache Tomcat 5.5 embutido como servelt. Ele suporta qualquer Java Virtual Machine entre as versões 1.4 e 1.6. JBoss AS 4.2: também funciona como um servidor de aplicações Java EE 1.4, mas implementa o Enterprise JavaBeans 3.0 por padrão. Ele requer o Java Development Kit versão 5 e junto apresenta o servidor Tomcat 5.5. JBoss AS 5.1: lançado em 2009, funciona como um servidor de aplicação Java EE 5. É uma atualização menor do grande lançamento JBoss AS 5.0, que estava em desenvolvimento a mais de 3 anos e é construído em cima de um Microcontainer JBoss, contém uma visualização de alguns elementos do Java EE 6. O servidor JBoss pode ser executado em diversos sistemas operacionais, incluindo muitas plataformas POSIX (como o Linux, FreeBSD e Mac OS X), Microsoft Windows e outros, e necessita de uma JVM adequada presente no sistema.

16 2.4 JDK 1.5 O Java Development Kit (JDK) [12] é um pacote básico de ferramentas oferecidas pela empresa Sun Microsystems para o público em geral. Este conjunto de aplicações foi concebido para programação de aplicações de software, utilizando principalmente a linguagem de programação Java. O poder de aplicações Java pode ser visto no número infindável de ferramentas destinadas a trabalhar na Internet e também para funcionar em desktop. É uma das ferramentas obrigatórias para programas Java serem executados. A nova versão do JDK (1.5) apresenta novas extensões para a linguagem de programação Java. Uma destas é a introdução de "Generics" (similar aos Templates do C++). A programação genérica permite que você escreva código que pode ser reutilizado para muitos tipos de objetos diferentes. 2.5 Richfaces 3.3.1 Richfaces 3.3.1[13] são um conjunto de implementações que constituem uma biblioteca de componentes para aplicações web utilizando o framework JSF que atualmente é mantido por JBoss.org. Ele permite a fácil integração de recursos Ajax no desenvolvimento de aplicações corporativas. RichFaces é mais do que apenas uma biblioteca de componentes para JavaServer Faces, pode ser considerada uma extensão do Ajax4jsf com inúmeros componentes com Ajax embutido e com um suporte a Skins que podem deixar as interfaces da aplicação com um visual padronizado. 2.6 PostgreSQL 8.4.0 O sistema gerenciador de banco de dados objeto relacional (SGBDOR) PostgreSQL 8.4.0[14] foi desenvolvido como projeto de código aberto e é um dos SGBDs mais avançados, contando com recursos como: consultas complexas, chaves estrangeiras, integridade transacional, etc.

17 O PostgreSQL suporta funções de retorno de linha, onde a saída da função é um conjunto de valores que pode ser tratada muito como uma tabela dentro de consultas. Agrega funções personalizadas e janelas também podem ser definidas. Consultas podem ser definidas para executar com os privilégios, quer do chamador ou do usuário que definiu a função. Funções são muitas vezes referidas como os procedimentos armazenados, embora haja uma ligeira distinção técnica entre os dois. Para a administração do Banco de Dados é utilizado o pgadmin que é uma ferramenta gráfica gratuita e aberta de administração para o PostgreSQL, que é suportada em diversos sistemas. O programa está disponível em mais de uma dezena de línguas. O primeiro protótipo, chamado pgmanager, foi escrita para PostgreSQL 6.3.2 a partir de 1998, refeita e lançada como pgadmin sob a licença GPL nos meses mais tarde. A segunda geração (chamado pgadmin II) foi uma reescrita completa, lançado em 16 de Janeiro de 2002. A versão atual é pgadmin III, que foi originalmente lançado sob a Artistic License e agora está liberado sob a mesma licença do PostgreSQL. Ao contrário das versões anteriores que foram escritos em Visual Basic, pgadmin III é escrito em C ++, usando a estrutura wxwidgets permitindo que ele seja executado em sistemas operacionais mais comuns.

18 3 O PROCESSO DE DESENVOLVIMENTO Basicamente, as Fábricas de Software podem ser classificadas em Fábricas de Programas, Fábricas de Teste e Fábricas de Projetos. As Fábricas de Programas caracterizam-se por atuarem em apenas uma porção do processo produtivo do software. Seu objetivo é codificar e testar programas conforme um acordo de níveis de serviços com o cliente ou usuário. As Fábricas de teste atuam no teste do software verificando e validando se a codificação está em conformidade com a especificação de requisitos. E as Fábricas de Projetos, por sua vez, atuam com um pouco mais de abrangência no processo de produção, englobando além das atividades inerentes à Fábrica de Programas e à Fábrica de Testes, fases como modelagem de negócio, requisitos, análise e design. Tem-se também, a chamada Fábrica de Projetos de Software ou Fábrica de Projetos Ampliada que, além da abrangência da Fábrica de Projetos, atua também na arquitetura da solução. Seu objetivo é a conceituação do software, preocupando-se em projetar uma solução em que o software se caracteriza apenas como um dos componentes. O processo de desenvolvimento de software compreende um conjunto de atividades que engloba métodos, ferramentas e procedimentos, com o objetivo de produzir softwares que atendam aos requisitos especificados pelos usuários ou clientes. A partir de uma perspectiva de gerenciamento baseada no PMBOK [17], o Processo de Desenvolvimento de Software da GAIA é dividido em seis fases, cada uma concluída por um marco principal. A Figura 3.1 apresenta este Processo e a forma como a Gerência de Comunicação atua com o Processo GAIA, ou seja, em paralelo a este Processo. Cada fase do processo é composta por atividades, sendo que cada uma destas atividades são descritas por um fluxo de trabalho composto por tarefas a serem realizadas pelos atores do processo, gerando artefatos (atas, documentos, código fonte, planos de testes).

19 Figura 3.1: Processo de Desenvolvimento 1 Análise Inicial: reunião com o cliente para entendimento do problema e definição do escopo. O número de reuniões é definido pela equipe de analistas, visto que, por política organizacional [18], a GAIA investe na qualidade deste escopo, minimizando ao máximo os problemas de falta de entendimento, insatisfações futuras do cliente pelo fato do sistema não atender suas necessidades, evitando com isso o retrabalho. O resultado deste investimento é a minimização dos riscos do projeto. Para cada reunião é gerada uma ata que deve ser assinada por todos os participantes, firmando o comprometimento de todos os envolvidos e para que os assuntos tratados sejam disponibilizados eletronicamente a todos os demais integrantes do desenvolvimento deste produto. Ao término desta etapa, tem-se uma proposta para o cliente, incluindo o escopo que é representado por uma WBS (Work Breakdown Structure), premissas, riscos, o prazo (em meses) para o desenvolvimento e o custo do projeto. Para estabelecimento dos prazos e custos utiliza-se um banco de dados histórico do desempenho da equipe em projetos similares; Análise e Planejamento: Após a aprovação da proposta, deve-se iniciar o planejamento do projeto, por meio da definição dos casos de uso e das respectivas especificações, dos riscos e prioridades de desenvolvimento, da expansão da WBS, da alocação de pessoas, da elaboração do cronograma, do estabelecimento de pontos

20 de controle, do número de iterações e de quais casos de uso serão desenvolvidos em cada iteração. É gerado um artefato intitulado Plano de Projeto. Vale ressaltar que esta fase do processo de desenvolvimento da GAIA ocorre de maneira iterativa, ou seja, após definirmos e iniciarmos a primeira iteração, no término da mesma, caso o desenvolvimento deva continuar, esta fase é disparada novamente. Nesta fase também ocorre o estabelecimento do grau de severidade para a aprovação ou não dos resultados das atividades pelo projeto. O grau de rigorosidade implica diretamente no controle da qualidade do projeto, ou seja, quanto maior a grau de rigorosidade, mais rígido é o processo de garantia de qualidade do projeto; Monitoramento e Controle: Paralelamente a Análise e Planejamento, deve-se iniciar o monitoramento e controle do projeto, buscando verificar se o que está sendo feito está de acordo com o planejado, tomando ações corretivas quando necessário. Esta verificação deverá ser feita nos pontos de controle indicados no artefato Plano de projeto; Execução: Nesta fase ocorre a especificação e a implementação dos respectivos casos de uso e os testes unitários. A especificação dos casos de uso deve ser verificada e validada. Caso ocorra uma quantidade igual ou superior de não conformidades aceitáveis para o projeto em questão, a iteração deve ser cancelada e um novo planejamento deve ser estabelecido levando-se em consideração os atrasos e as consequências dos mesmos. Após uma análise do resultado dos testes, decidese, baseado também no grau de rigorosidade, por corrigir as não conformidades encontradas e realizar novamente os testes e partirmos para a próxima fase intitulada Entrega ou cancelarmos a iteração e voltarmos para a fase de Análise e Planejamento; Entrega: Esta fase está responsável por executar os testes de integração que, caso registre um resultado positivo, iniciará a entrega e implantação da parte do produto desenvolvida até a presente iteração. Se o projeto ainda não terminou, a fase de Análise e Planejamento é iniciada novamente. Do contrário, a fase de Finalização é iniciada;

21 Finalização: Nesta faze é realizada um reunião de término do projeto, na qual são levantadas as lições aprendidas, sendo as mesmas registradas em ata para futuras consultas e melhorias no processo de desenvolvimento. É gerado um documento indicando o recebimento do produto pelo cliente e o término do projeto. Todas as fases do processo foram definidas com o propósito de ser o mais simples possível, porém mantendo o formalismo para garantir a qualidade do desenvolvimento nas nuvens. O processo de desenvolvimento GAIA, onde a ferramenta de Gerência de Testes foi desenvolvida, também contou com a participação de um analista de Design que foi posteriormente incluído ao projeto. A função desse analista foi criar um padrão de interface para todo o ADS (Ambiente de Desenvolvimento de Software), baseandose no guia de estilos definido pelo GAIA. Assim a ferramenta desenvolvida apresenta uma diferenciação entre a interface final e a utilizada nos protótipos dos casos de uso que serão vistos a seguir. As figuras 3.2 e 3.3 mostram exemplos da padronização de interface utilizada no ADS dentro do ciclo de desenvolvimento GAIA. Figura 3.2: Interface 1

22 Figura 3.3: Interface 2 4 CASOS DE USO Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, ou classe apresentando mensagens trocadas entre os sistemas e um ou mais atores. Um caso de uso representa uma unidade significante e discreta da interação entre um usuário e o sistema. Cada caso de uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto. Pode-se "incluir" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento. A seguir, são apresentados os casos de uso da ferramenta desenvolvida, onde em cada caso de uso são especificados seus fluxos básicos, alternativos, requisitos especiais, pré-condições, pós-condições, pontos de extensão, local view, definição dos atributos e protótipo da interface. Dentro da descrição de cada caso de uso existem figuras que apresentam o local view representando um diagrama de caso de uso e o Protótipo de Interface que representa como a interface inicial é planejada. As tabelas de Definição de atributos apresentam quais os atributos que o caso de uso em questão necessita para armazenar as informações.

23 A figura 4.1 contém todos os diagramas de caso de uso utilizados no ADS, para que seja possível o entendimento sobre onde cada ferramenta está incluída dentro do projeto e quem foi o responsável pela sua criação. Figura 4.1: Diagrama dos Casos de Uso 1

24 4.1 Especificação de Caso de Uso: <Manter Testes> 4.1.1 Descrição Esse caso de uso destina-se a cadastrar, manter atualizado e excluir os testes realizados em projetos de software. 4.1.2 Fluxo Básico O analista de testes deve preencher todos os campos necessários para poder cadastrar um Teste, após isso o analista de testes seleciona a opção Salvar Dados, o sistema então valida os campos do formulário e volta à tela inicial. 4.1.3 Fluxos Alternativos Alterar um Teste Cadastrado: O analista de testes pode alterar um teste já cadastrado através de uma lista que será mostrada na tela, em seguida clicando no botão Alterar Teste. O sistema mostrará a tela onde as alterações podem ser feitas, após isso o analista de testes seleciona a opção Atualizar Dados e o sistema volta à tela inicial. Formulário não validado: O sistema pode não validar o formulário de dados. O analista de testes então deverá corrigir os erros mostrados e selecionar a opção Salvar Dados. O sistema valida os campos do formulário e volta à tela inicial. Excluir um Teste Cadastrado: O analista de testes pode excluir um teste já cadastrado através de uma lista que será mostrada na tela, em seguida clicando no botão Excluir Teste, será mostrado um aviso informando que essa operação não poderá ser desfeita, oferecendo a opção de confirmar e de cancelar. Selecionando a opção Confirmar o sistema exclui o teste selecionado bem como todos os itens associados a esse teste, após isso o sistema volta à tela inicial.