APLICATIVO WEB DE AUXÍLIO À INSPEÇÃO DE SOFTWARE COM LISTAS DE VERIFICAÇÃO UNIVERSIDADE REGIONAL DE BLUMENAU CURSO DE SISTEMAS DE INFORMAÇÃO Mayara Barbieri da Silva Prof. Everaldo Artur Grahl, Orientador

ROTEIRO DA APRESENTAÇÃO 1. Introdução 2. Objetivos 3. Fundamentação teórica 4. Especificação 5. Operacionalidade 6. Resultados e Discussões 7. Conclusão 8. Extensões

INTRODUÇÃO  Investimento das empresas em qualidade de software  Custo para a correção de defeitos  Inspeção de software  Necessidade da empresa Senior Sistemas

OBJETIVO Desenvolver uma aplicação web que auxilie as atividades de inspeção de software na empresa Senior Sistemas através da utilização de listas de verificação

FUNDAMENTAÇÃO TEÓRICA PROCESSO DE TESTE  Equipes de teste e de desenvolvimento independentes  Objetivo: minimizar os riscos causados por defeitos  Ciclo de vida de teste – Conceito “V” de teste

FUNDAMENTAÇÃO TEÓRICA INSPEÇÃO DE SOFTWARE  Conceito  Tipo particular revisão que pode ser aplicado a todos os artefatos de software e tem como principal objetivo minimizar os custos com o reparo de defeitos nos projetos (FAGAN, 1976, 1986).  Etapas  Planejamento  Apresentação  Preparação  Reunião de inspeção  Retrabalho  Acompanhamento  Papéis envolvidos  Autor  Moderador  Redator  Inspetor

FUNDAMENTAÇÃO TEÓRICA Características da inspeção de software  é um método estruturado para verificar documentos do software, tais como a especificação de requisitos, os documentos do projeto e o código-fonte;  é realizado em seis etapas consecutivas (planejamento, apresentação, preparação, reunião de inspeção, retrabalho e acompanhamento);  compreende a definição de uma equipe de inspeção para verificar o documento, que é composta pelo moderador, relator, inspetor e autor;  os participantes que irão inspecionar o produto têm suas funções bem definidas durante o processo, cada qual cumprindo a sua tarefa;  o resultado final é gerar um documento do que foi obtido na inspeção individual e nas discussões das reuniões das equipes.

FUNDAMENTAÇÃO TEÓRICA Benefícios da inspeção de software  Melhora a qualidade do produto de software que está sendo construído, atendendo às necessidades do usuário;  Aumenta a produtividade durante a criação do sistema que está sendo desenvolvido, garantindo a sua qualidade e prevenindo futuros problemas, detectando os defeitos;  Verifica se o software atende a todos os seus requisitos;  Torna os projetos mais administráveis.

FUNDAMENTAÇÃO TEÓRICA Principais técnicas da inspeção de software:  Ad-Hoc  Checklist ou listas de verificação  Leitura Baseada em Perspectiva (PBR)

FUNDAMENTAÇÃO TEÓRICA SISTEMA ATUAL  Empresa: Senior Sistemas  Ramo: desenvolvedora de software para gestão empresarial, de gestão de pessoas e acesso e segurança  Ano de fundação e localização:  1988, Blumenau/SC  Certificações:  ABNT – NBR ISO 9001: 2000 e o CMMI nível 3

FUNDAMENTAÇÃO TEÓRICA PROCESSO ATUAL  Necessidade

FUNDAMENTAÇÃO TEÓRICA TRABALHOS CORRELATOS  Biondo (2007) descreve uma ferramenta para garantia da qualidade aplicada na implementação de sistemas.

FUNDAMENTAÇÃO TEÓRICA TRABALHOS CORRELATOS  Ebertz (2002) descreve um protótipo de apoio ao processo de verificação baseado na norma ISO/IEC

FUNDAMENTAÇÃO TEÓRICA TRABALHOS CORRELATOS  Bertini (2006) apresenta um estudo comparativo entre três técnicas de leitura para avaliação de documentos de requisitos de software, a leitura baseada em checklists, a leitura baseada em cenários e a leitura baseada em perspectivas.

ESPECIFICAÇÃO  Requisitos funcionais Requisitos FuncionaisCaso de Uso RF01 – A aplicação deve requerer autenticação de usuários para manipulação do mesmo. UC01 RF02 - A aplicação deve permitir a manipulação simultânea, por qualquer usuário, das listas de verificação criadas pelo administrador. UC02 RF03 - A aplicação deve permitir a visualização das listas de verificação já criadas. UC03 RF04 - A aplicação deve permitir a exportação do relatório com o resultado da inspeção em formato suportado pelo Microsoft Excel. UC04 RF05 - A aplicação deve permitir a vinculação de uma lista a uma atividade de inspeção de software. UC05 RF06 - A aplicação deve permitir a criação de templates de listas de verificação por usuários do tipo administrador. UC06 RF07 - A aplicação deve permitir a manutenção (cadastro, exclusão e alteração) de dois tipos de atores: administrador e operador. UC07

ESPECIFICAÇÃO  Requisitos não funcionais Requisitos Não Funcionais RNF01 - A aplicação deve ser desenvolvida utilizando a linguagem Java. RNF02 - A aplicação deve utilizar o banco de dados MySQL. RNF03 - A aplicação deve permitir acesso concorrente e simultâneo de até 10 usuários. RNF04 – A aplicação deve utilizar o AJAX. RNF05 – A aplicação deve utilizar o Framework Prototype.

ESPECIFICAÇÃO  Diagrama de caso de uso

ESPECIFICAÇÃO  Modelo Entidade-Relacionamento (MER)

ESPECIFICAÇÃO  Técnicas e ferramentas utilizadas  Java, JavaScript, HTML 5 3 CSS 3;  Eclipse Indigo IDE;  Banco de dados MySQL, versão 5.2;  JDBC;  AJAX;  AJAX Polling;  DHTML;  Framework Prototype ;  API Sax Parser;  Enterprise Architect;  MadCap Flare.

OPERACIONALIDADE  Tela de login

OPERACIONALIDADE  Tela principal  Perfil do administrador

OPERACIONALIDADE  Tela principal  Perfil do operador

OPERACIONALIDADE  Tela de controle de usuários  Inserção, exclusão, alteração e busca

OPERACIONALIDADE  Tela de criação de template

OPERACIONALIDADE  Criação dos componentes

OPERACIONALIDADE  Apresentação dos templates existentes

OPERACIONALIDADE  Tela de edição das listas de verificação

OPERACIONALIDADE  Edição simultânea

OPERACIONALIDADE  Apresentação dos templates após execução

OPERACIONALIDADE  Finalização da lista de verificação

OPERACIONALIDADE  Exportação da planilha para Excel

OPERACIONALIDADE  Help

RESULTADOS E DISCUSSÕES  Simplifica a atividade de inspeção de software.  Tornou possível a criação de templates de listas de verificação, bem como a manipulação de uma mesma lista de verificação por um grupo de pessoas. Além disso, todos os artefatos gerados pelas inspeções de software ficam armazenados no mesmo local.  Seguiu a mesma linha do protótipo desenvolvido por Biondo. O principal objetivo dos trabalhos foi o de facilitar a atividade de inspeção de software.  A dissertação de Bertini ressaltou a importância da inspeção de software.  O protótipo desenvolvido por Ebertz também tinha como objetivo facilitar a o processo de verificação, porém ele seguiu a norma ISO/IEC

RESULTADOS E DISCUSSÕES  As principais limitações do aplicativo são:  Usabilidade  Definições de permissão

CONCLUSÃO  Permite a criação de listas de verificação que auxiliam a atividade de inspeção de software.  A alteração simultânea das listas de verificação tornou o processo mais simples, pois eliminou algumas fases do processo atual da empresa Senior Sistemas.  O repositório único para as listas de verificação tornou o acesso a elas mais rápido.  Principais dificuldades:  AJAX integrado com servlets;  Simulação de orientação objetos no JavaScript com o Framework Prototype;  Tratamento dos requests;  Definição da rotina de atualização simultânea em vários clients.

EXTENSÕES  M elhoria da usabilidade da aplicação;  Implementação de um campo de busca para filtragem das listas de verificação existentes;  Implementação da edição da lista de verificação após criação pelo moderador;  Implementação de um controle de acesso às listas de verificação.

DEMONSTRAÇÃO DA APLICAÇÃO…