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.

Apresentação em tema: "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."— Transcrição da apresentação:

1 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

2 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

3 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

4 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

5 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

6 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

7 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.

8 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.

9 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)

10 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

11 FUNDAMENTAÇÃO TEÓRICA PROCESSO ATUAL  Necessidade

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

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

14 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.

15 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

16 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.

17 ESPECIFICAÇÃO  Diagrama de caso de uso

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

19 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.

20 OPERACIONALIDADE  Tela de login

21 OPERACIONALIDADE  Tela principal  Perfil do administrador

22 OPERACIONALIDADE  Tela principal  Perfil do operador

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

24 OPERACIONALIDADE  Tela de criação de template

25 OPERACIONALIDADE  Criação dos componentes

26 OPERACIONALIDADE  Apresentação dos templates existentes

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

28 OPERACIONALIDADE  Edição simultânea

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

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

31 OPERACIONALIDADE  Exportação da planilha para Excel

32 OPERACIONALIDADE  Help

33 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 12207.

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

35 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.

36 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.

37 DEMONSTRAÇÃO DA APLICAÇÃO…