Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
APLICATIVO WEB DE AUXÍLIO À INSPEÇÃO DE
SOFTWARE COM LISTAS DE VERIFICAÇÃO
MAYARA BARBIERI DA SILVA
BLUMENAU
2012
2012/1-14
MAYARA BARBIERI DA SILVA
APLICATIVO WEB DE AUXÍLIO À INSPEÇÃO DE
SOFTWARE COM LISTAS DE VERIFICAÇÃO
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Sistemas
de Informação— Bacharelado.
Prof. Everaldo Artur Grahl, Mestre - Orientador
BLUMENAU
2012
2012/1-14
APLICATIVO WEB DE AUXÍLIO À INSPEÇÃO DE
SOFTWARE COM LISTAS DE VERIFICAÇÃO
Por
MAYARA BARBIERI DA SILVA
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Prof. Everaldo Artur Grahl, Mestre – Orientador, FURB
______________________________________________________
Membro: Prof. Wilson Pedro Carli, Mestre – FURB
______________________________________________________
Membro: Prof. Rion Brattig Correia, Mestre – FURB
Blumenau, 04 de junho de 2012.
Dedico este trabalho aos meus pais, que
sempre me apoiaram na busca pelo
conhecimento, e a todos os meus amigos,
especialmente aqueles que me ajudaram
diretamente na realização deste.
AGRADECIMENTOS
A Deus, pelo seu imenso amor e graça.
À minha família que sempre esteve presente.
Aos meus amigos, pelos empurrões e cobranças.
Ao meu orientador, Everaldo Artur Grahl, por ter acreditado na conclusão deste
trabalho.
Aos professores do Departamento de Sistemas e Computação da Universidade
Regional de Blumenau por suas contribuições durante os semestres letivos.
Não sabendo que era impossível, foi lá e fez.
Jean Cocteau
RESUMO
A qualidade de software é uma área que está recebendo cada vez mais importância e destaque
dentro das empresas desenvolvedoras de software. Várias técnicas existem para tornar este
processo mais assertivo e com o custo mais baixo. A inspeção de software é um tipo de
revisão que tem como principal objetivo minimizar os custos com reparo de defeitos nos
projetos. Na empresa Senior Sistemas, existem casos onde as equipes precisam alterar a
mesma planilha eletrônica simultaneamente para realizar a atividade de inspeção de software.
Outra necessidade das equipes é manter todos os artefatos gerados em um mesmo repositório.
Este trabalho acadêmico propõe a criação de um aplicativo que permita a edição de listas de
verificação por um grupo de pessoas simultaneamente e que organize os artefatos gerados. O
desenvolvimento do aplicativo proposto tornou a atividade de inspeção de software mais
eficaz para as equipes dentro da empresa Senior Sistemas.
Palavras-chave: Inspeção de software. Lista de verificação. Processo de teste.
ABSTRACT
Software quality is an area that is receiving more and more importance and emphasis within
software development companies. There are various techniques to make this process more
assertive and with lower cost. The Software inspection is a type of revision that can be
applied to all software artifacts and has as a main objective to minimize repairing costs in
projects. At Senior Sistemas, there are cases where the teams need to alter the same electronic
spreadsheet simultaneously to perform the software inspection activity. Another team’s
necessity is to keep all the generated artifacts in the same repository. This work academic
proposes the creation of an application that allows editing of verification lists by a group of
people simultaneously and organizes the generated artifacts. The development of the proposed
application made the software inspection activity more effective for the teams within the
company Senior Sistemas.
Key-words: Software inspection. Checklist. Test process.
LISTA DE FIGURAS
Figura 1 - Conceito “V” de testes de software ......................................................................... 15
Figura 2 – Fluxo de atividades .................................................................................................... 19
Figura 3 - Tela de auditorias do protótipo .................................................................................... 20
Figura 4 - Tela de verificação do contrato ................................................................................ 21
Figura 5 – Relatório das perguntas da atividade do contrato ................................................... 21
Figura 6 – Diagrama de casos de uso ....................................................................................... 25
Figura 7 – Modelo entidade relacionamento ............................................................................ 26
Figura 8 – Implementação da função ClientConnector ............................................................ 28
Figura 9 – Chamada da função setInterval ............................................................................... 28
Figura 10 – Função de sincronização dos dados ...................................................................... 29
Figura 11 – Implementação do componente base .................................................................... 29
Figura 12 – Parte do index.html ................................................................................................ 30
Figura 13 – Parte do style.css ................................................................................................... 31
Figura 14 – Parse do XML ...................................................................................................... 32
Figura 15 – Parse do XML ...................................................................................................... 32
Figura 16 – Classe que renderiza e atualiza o editBox ............................................................. 33
Figura 17 – Classe que insere novo usuário na base ................................................................ 33
Figura 18 – Método update ...................................................................................................... 34
Figura 19 – Tela de login .......................................................................................................... 35
Figura 20 – Tela de login com validação de usuário ................................................................ 35
Figura 21 – Tela de login com validação de usuário ................................................................ 35
Figura 22 - Perfil do administrador .......................................................................................... 36
Figura 23 - Perfil do operador .................................................................................................. 36
Figura 24 – Tela de controle de usuários .................................................................................. 37
Figura 25 – Tela de criação de templates ................................................................................. 38
Figura 26 – Campos para criação de template .......................................................................... 38
Figura 27 – Ações disponíveis para criação do template ......................................................... 39
Figura 28 – Cadastro de itens de verificação ............................................................................ 39
Figura 29 – Inserção de um passo de verificação ..................................................................... 40
Figura 30 – Inserção vários passos de verificação ................................................................... 40
Figura 31 – Mensagem de dados não salvos ............................................................................ 41
Figura 32 – Listas de verificação existentes ............................................................................. 41
Figura 33 – Campo descrição da não-conformidade sendo editado pelo usuário 01 ............... 42
Figura 34 – Campo descrição da não-conformidade bloqueado para o usuário 02 .................. 42
Figura 35 – Planilha exportada para Excel ............................................................................... 42
Figura 36 – Tela de ajuda da aplicação .................................................................................... 42
LISTA DE QUADROS
Quadro 1 - Requisitos funcionais ............................................................................................. 24
Quadro 2 - Requisitos não funcionais ...................................................................................... 24
Quadro 3 – Descrição do caso de uso Logar no Sistema.......................................................... 48
Quadro 4 – Descrição do caso de uso Manipular lista de verificação ...................................... 48
Quadro 5 – Descrição do caso de uso Visualizar listas de verificação criadas ........................ 49
Quadro 6 – Descrição do caso de uso Exportar resultado da inspeção .................................... 49
Quadro 7 – Descrição do caso de uso Vincular lista ................................................................ 49
Quadro 8 – Descrição do caso de uso Criar template ............................................................... 50
Quadro 9 – Descrição do caso de uso Manter usuários ............................................................ 50
Quadro 10 - Dicionário de dados da entidade user ................................................................... 51
Quadro 11 - Dicionário de dados da entidade checklistdef ...................................................... 51
Quadro 12 - Dicionário de dados da entidade checklistitemdef ............................................... 52
Quadro 13 - Dicionário de dados da entidade checkliststepdef................................................ 52
Quadro 14 - Dicionário de dados da entidade checklist ........................................................... 52
Quadro 15 - Dicionário de dados da entidade checklistitem .................................................... 53
LISTA DE SIGLAS
AJAX - Asynchronous Javascript and XML
CMMI - Capability Maturity Model Integration
CSS - Cascading Style Sheets
DHTML - Dynamic HyperText Markup Language
DOM - Document Object Model
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
JDBC - Java Database Connectivity
MER - Modelo Entidade Relacionamento
PBR - Leitura Baseada em Perspectiva
RF - Requisitos Funcionais
RNF - Requisitos Não Funcionais
UML - Unified Model Language
XML - eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVO DO TRABALHO............................................................................................ 13
1.2 ESTRUTURA DO TRABALHO ....................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14
2.1 PROCESSO DE TESTE .................................................................................................... 14
2.2 INSPEÇÃO DE SOFTWARE ........................................................................................... 15
2.2.1 Características da inspeção de software ......................................................................... 16
2.2.2 Benefícios da inspeção de software ................................................................................ 17
2.2.3 Técnicas de leitura .......................................................................................................... 17
2.3 SISTEMA ATUAL ........................................................................................................... 18
2.4 TRABALHOS CORRELATOS ........................................................................................ 19
2.4.1 Ferramenta de garantia da qualidade aplicada na implementação de sistemas .............. 20
2.4.2 Protótipo de apoio ao processo de verificação baseado na norma ISO/IEC 12207 ....... 20
2.4.3 Técnicas de inspeção aplicadas à avaliação de requisitos de sistemas de software: um
estudo comparativo ......................................................................................................... 22
3 DESENVOLVIMENTO DO APLICATIVO .................................................................. 23
3.1 LEVANTAMENTO DE INFORMAÇÕES ...................................................................... 23
3.2 ESPECIFICAÇÃO ............................................................................................................ 23
3.2.1 Requisitos Funcionais ...................................................................................................... 23
3.2.2 Requisitos Não Funcionais .............................................................................................. 24
3.2.3 Diagrama de casos de uso ................................................................................................ 24
3.2.4 Modelo Entidade Relacionamento................................................................................... 25
3.3 IMPLEMENTAÇÃO ......................................................................................................... 26
3.3.1 Técnicas e ferramentas utilizadas .................................................................................... 26
3.3.2 Codificação do aplicativo ................................................................................................ 27
3.3.3 Operacionalidade da implementação ............................................................................... 34
3.4 RESULTADOS E DISCUSSÃO ....................................................................................... 44
4 CONCLUSÕES .................................................................................................................. 45
4.1 EXTENSÕES .................................................................................................................... 45
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 47
APÊNDICE A – Descrição dos Casos de Uso ...................................................................... 48
APÊNDICE B – Detalhamento do dicionário de dados ...................................................... 51
12
1 INTRODUÇÃO
Cada vez mais os softwares estão se tornando indispensáveis na vida de todos.
Atrelado a isso, está o aumento do investimento das empresas desenvolvedoras de software
em qualidade, visto que a complexidade deles vem aumentando exponencialmente. Sabe-se
que o custo da correção de um defeito aumenta na medida em que o processo de
desenvolvimento progride (BOEHM; BASILI, 2001).
A engenharia de software também considera que quanto mais precocemente os defeitos
forem descobertos, menor será o custo para a sua correção. Para chegar a tal conclusão ela
considera variáveis como esforço, produtividade, tempo e custo do desenvolvimento. Essas
variáveis são afetadas de acordo com o número de defeitos encontrados no software, assim
como a etapa em que os mesmos são descobertos.
Existem vários métodos que buscam o menor custo para a correção de um defeito. A
inspeção de software é um método de análise estruturado, eficiente e econômico, para
verificar as propriedades de qualidade do produto de software que está sendo desenvolvido,
tendo como principal objetivo minimizar os custos com o reparo de defeitos nos projetos
(FAGAN, 1986).
A inspeção de software define algumas técnicas de leitura dos documentos a serem
inspecionados. A leitura baseada em checklist, ou listas de verificação, é um método barato e
eficiente para a descoberta de defeitos durante o ciclo de desenvolvimento. Algumas equipes
da empresa Senior Sistemas de Blumenau, desenvolvedora de software que possui o nível 3
do Capability Maturity Model Integration (CMMI) e ISO9001:2008, executam várias listas de
verificação durante o desenvolvimento de um sistema. Para tal, utilizam planilhas eletrônicas
como ferramenta de apoio para a edição destas listas.
Por ser uma empresa de médio porte, com cerca de seiscentos funcionários, é natural a
existência de muitas listas de verificação, que são manipuladas diariamente por vários
colaboradores. Para que a alteração da mesma lista por vários membros da equipe seja
possível, surgiu a idéia deste trabalho.
13
11..11 OOBBJJEETTIIVVOO DDOO TTRRAABBAALLHHOO
O objetivo desde trabalho é o desenvolvimento de 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.
11..22 EESSTTRRUUTTUURRAA DDOO TTRRAABBAALLHHOO
No primeiro capítulo tem-se a introdução ao tema principal deste trabalho com a
apresentação da justificativa e dos objetivos.
No segundo capítulo apresenta-se a fundamentação teórica pesquisada sobre processo
de teste, inspeção de software, características da inspeção de software, benefícios da inspeção
de software, técnicas de leitura, sistema atual e trabalhos correlatos.
O terceiro capítulo apresenta o desenvolvimento do aplicativo iniciando-se com o
levantamento de informações, tendo na sequencia especificação, implementação, resultados e
discussão.
No quarto capítulo tem-se as conclusões deste trabalho bem como apresentam-se
sugestões para trabalhos futuros.
14
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda assuntos a serem apresentados nas seções a seguir, tais como
processo de teste, inspeção de software, sistema atual além de trabalhos correlatos.
22..11 PPRROOCCEESSSSOO DDEE TTEESSTTEE
Muitas empresas desenvolvedoras de software veem o teste de software como parte do
processo de desenvolvimento e estes, em geral, são executados pelos próprios
desenvolvedores ou pelos usuários do sistema. Para um modelo de garantia de qualidade, se
os testes de software não forem executados por uma equipe independente de testes eles não
são testes suficientes que garantem a qualidade do produto.
O principal objetivo de um processo de teste, com metodologia própria, é minimizar
os riscos causados por defeitos provenientes do processo de desenvolvimento. Para que isso
se torne possível dentro das empresas, é muito importante ter uma equipe treinada e
capacitada, além de uma metodologia de desenvolvimento adequada. Dessa forma, os testes
nos documentos podem ser realizados paralelamente ao processo de desenvolvimento, através
de revisões e inspeções (BASTOS et al., 2007).
O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o
processo de desenvolvimento. Em determinados pontos os artefatos gerados são revisados
com o objetivo de criar as condições necessárias para a correta implementação, procurando
sempre identificar os defeitos o mais cedo possível. O conceito de ciclo de vida de testes é
ilustrado na Figura 1. Esta figura mostra que os processos de desenvolvimento e teste iniciam
simultaneamente. Ambas as equipes utilizam as mesmas informações para a realização de
suas atividades. No conceito “V” de teste, os procedimentos de fazer e conferir convergem
durante todo o projeto, visando minimizar ou eliminar riscos (BASTOS et al., 2007).
15
Fonte: Bastos et al. (2007, p. 41).
Figura 1 – Conceito “V” de testes de software
Em 1976, Michal Fagan publicou um artigo sobre como as inspeções de código
poderiam reduzir os defeitos dos softwares. Nesse mesmo ano, Glenford Myers lançou um
livro onde mostrava a importância dos testes serem feitos corretamente. Porém, foi em 1979
que Myers lançou o livro ‘The Art of Software Testing’, aquele que se tornou uma das bíblias
da qualidade na época. Neste livro, Myers afirma que o custo para a correção do defeito
aumenta 10 vezes para cada estágio em que o projeto do software avança. Myers mostrou que
a correção de defeitos encontrados em requisitos, por exemplo, custam menos que os defeitos
encontrados apenas na fase de teste (MYERS, 1979).
22..22 IINNSSPPEEÇÇÃÃOO DDEE SSOOFFTTWWAARREE
A inspeção de software é um tipo particular de 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, 1986).
A inspeção visa encontrar erros lendo, entendendo o que o documento descreve e
checando através de uma lista de verificação as propriedades de qualidade requeridas. A
inspeção de software é composta por seis fases, que são o planejamento, a apresentação, a
preparação, a reunião de inspeção, o retrabalho e o acompanhamento (FAGAN, 1986).
No planejamento é definido o contexto da inspeção, são selecionados os inspetores e
os materiais a serem revisados são preparados. Na segunda fase, de apresentação, os autores
16
apresentam as características dos artefatos a serem inspecionados. Na fase de preparação, os
integrantes do time de inspeção se preparam para desempenhar o papel designado a cada um.
Na reunião de inspeção os defeitos são encontrados, discutidos e categorizados. Na fase do
retrabalho o autor do documento corrige os defeitos encontrados pelos inspetores e
confirmados pelo moderador. Finalmente, na etapa de acompanhamento, o time de inspeção é
responsável por assegurar que todos os defeitos encontrados foram corrigidos e nenhum outro
tipo de defeito foi introduzido na fase de retrabalho (FAGAN, 1986).
Os papéis envolvidos no processo de inspeção de software são o autor, o moderador, o
redator e o inspetor. O autor é o desenvolvedor do artefato a ser inspecionado, o moderador
lidera a inspeção e programa e controla as reuniões, o redator é o responsável por relatar os
defeitos e as questões levantadas durante o processo de inspeção e o inspetor é o responsável
por encontrar os defeitos no produto.
A inspeção corresponde a uma das mais importantes atividades de garantia de
qualidade de software, sendo que o principal objetivo é descoberta antecipada de defeitos.
Com a descoberta antecipada dos defeitos, eles não se propagam para as demais fases do
processo de software. A engenharia de software tem utilizado a inspeção como um dos
métodos mais eficientes e efetivos na busca por um produto de melhor qualidade
(FELIZARDO, 2004).
2.2.1 Características da inspeção de software
As principais características de um processo de inspeção de software, segundo Fagan
(1986) e Doolan (1992) são:
a) 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;
b) realizado em seis etapas consecutivas (planejamento, apresentação, preparação,
inspeção, retrabalho e revisão);
c) compreende a definição de uma equipe de inspeção para verificar o documento,
que é composta pelo moderador, relator, inspetor e autor;
d) os participantes que irão inspecionar o produto têm suas funções bem definidas
durante o processo, cada qual cumprindo a sua tarefa;
e) o resultado final é gerar um documento do que foi obtido na inspeção individual e
nas discussões das reuniões das equipes.
17
2.2.2 Benefícios da inspeção de software
A inspeção de software tem por objetivo entregar um software com qualidade para o
cliente. De acordo com Fagan (1986) e Pressman (1995) a inspeção de software:
a) melhora a qualidade do produto de software que está sendo construído, atendendo
às necessidades do usuário;
b) aumenta a produtividade durante a criação do sistema que está sendo
desenvolvido, garantindo a sua qualidade e prevenindo futuros problemas,
detectando os defeitos;
c) verifica se o software atende a todos os seus requisitos;
d) torna os projetos mais administráveis.
2.2.3 Técnicas de leitura
A inspeção de software é uma técnica de revisão baseada na leitura e no entendimento
dos artefatos, gerados durante o processo de desenvolvimento de software, com o objetivo de
encontrar o maior número possível de defeitos.
Para garantir um mínimo de qualidade e padronização nas leituras dos documentos a
serem inspecionados, fez-se necessária a criação de técnicas de leituras. As principais técnicas
de leitura empregadas nas inspeções de software são a Ad-Hoc, o checklist - ou listas de
verificação - e Leitura Baseada em Perspectiva (PBR).
A técnica de leitura Ad-Hoc prega que cada leitor leia o documento do seu jeito, sem
impor nenhuma técnica formal ou procedimento. Esta técnica não é recomendada, pois se
torna dependente da experiência do revisor e não é passível de repetição nem de melhoria,
pois não existe um procedimento a ser seguido.
A técnica de leitura baseada em checklist disponibiliza ao leitor um documento onde
estão apresentados os itens encontrados em revisões anteriores. Deste modo, o revisor
consegue seguir uma linha de raciocínio, mas não fica preso somente a ela.
A técnica de leitura baseada em perspectiva é aplicada em inspeção de documentos de
requisitos em linguagem natural. Ela prevê um conjunto de instruções específicas para os três
papéis envolvidos diretamente com o documento de requisitos, o testador, o projetista e o
18
usuário (KALINOWSKI; SPÍNOLA; TRAVASSOS, 2004).
22..33 SSIISSTTEEMMAA AATTUUAALL
A Senior Sistemas é uma das maiores empresas desenvolvedoras de software para
gestão empresarial do Brasil e oferece, além de soluções em gestão empresarial, soluções de
gestão de pessoas, acesso e segurança. Além de atuar no mercado de software brasileiro, a
Senior Sistemas também tem participação no mercado latino-americano. A empresa foi
fundada em 1988 e tem sua sede localizada em Blumenau, no estado de Santa Catarina
(SENIOR SISTEMAS, 2012).
Buscando sempre os mais elevados níveis de excelência, além da inovação na gestão
do conhecimento, a Senior Sistemas investiu na atualização de seus produtos e na certificação
de seus processos. A Senior Sistemas possui, hoje, as seguintes certificações, a ABNT – NBR
ISO 9001: 2000 e o CMMI nível 3.
Por ser uma empresa de médio porte, com cerca de 600 funcionários, e ter um
processo de garantia de qualidade bem definido, existe a necessidade da criação de
ferramentas que auxiliem o dia-a-dia dos colaboradores quanto ao cumprimento do processo.
Em várias partes do processo desenvolvido pela Senior Sistemas, está descrita a
necessidade da execução de listas de verificação. Sendo executadas em vários momentos,
como por exemplo, no encerramento de projetos, nos ciclos de testes, na integração dos
produtos, nas revisões por pares, em auditorias de processo, entre outros.
Na Figura 2 o analista de qualidade é representado pelo executor líder, que executa o
papel de moderador da inspeção de software. É o executor líder que cria o template da lista de
verificação que será executada, une as várias planilhas executadas pelos executores 1 e 2 e
posteriormente gera o resultado da inspeção.
19
Figura 2 – Fluxo de atividades
22..44 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS
Existem disponíveis ferramentas comerciais e acadêmicas que abordam a temática da
inspeção de software, baseada em listas de verificação. Desta maneira, é possível encontrar
desde trabalhos de conclusão de curso até dissertações de pós-graduação. Dentre estes
trabalhos, foi selecionada a “ferramenta para garantia da qualidade aplicada na
implementação de sistemas” de Aline Biondo, o “protótipo de apoio ao processo de
verificação baseado na norma ISO/IEC 12207” de Itaboraí Cordoni Ebertz e a dissertação de
Lilian Bertini, “Técnicas de inspeção aplicadas à avaliação de requisitos de sistemas de
software: um estudo comparativo”, os quais são descritos a seguir.
20
2.4.1 Ferramenta de garantia da qualidade aplicada na implementação de sistemas
O trabalho apresenta uma técnica para implementação da garantia da qualidade no
desenvolvimento de sistemas. A acadêmica propôs a criação de um modelo de checklist onde
é possível registrar as conformidades e as não-conformidades levantadas durante a auditoria
de algum processo. A Figura 3, que representa a tela de auditorias do protótipo desenvolvido
pela acadêmica. Este protótipo foi desenvolvido em PHP, juntamente com HTML e CSS. O
banco de dados escolhido foi o MySQL. Além da manipulação do checklist o protótipo
também apresenta um relatório consolidando as auditorias realizadas no período (BIONDO,
2007).
Fonte: Biondo (2007, p. 17).
Figura 3 - Tela de auditorias do protótipo
2.4.2 Protótipo de apoio ao processo de verificação baseado na norma ISO/IEC 12207
O trabalho apresenta um protótipo de apoio ao processo de verificação baseado na
norma ISO/IEC 12207. O acadêmico propôs a criação de um software para facilitar a adoção
do processo de verificação com a utilização de checklists. Além disso, fez um estudo
comparativo entre as atividades de verificação previstas em normas conhecidas como ISO
9000-3, ISO/IEC 15504 e modelo CMMI. A Figura 4 apresenta a execução de um dos
21
checklists cadastrados. Após a finalização das verificações, o software desenvolvido
disponibiliza a funcionalidade de emissão do relatório com os resultados do procedimento,
conforme Figura 5. O software foi desenvolvido no ambiente de programação Visual Delphi
5.0 da Borland e para o armazenamento dos dados foi utilizado o Paradox (EBERTZ, 2002).
Fonte: Ebertz (2002, p. 45).
Figura 4 - Tela de verificação do contrato
Fonte: Ebertz (2002, p. 46).
Figura 5 – Relatório das perguntas da atividade do contrato
22
2.4.3 Técnicas de inspeção aplicadas à avaliação de requisitos de sistemas de software: um
estudo comparativo
A dissertação 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. Este estudo se propôs a comparar a
eficiência das técnicas citadas em relação ao número de defeitos detectados pelos indivíduos e
o tempo médio de experiência na área. Os resultados obtidos com esta pesquisa foram úteis
para profissionais que atuam na análise e especificação de requisitos de software, uma vez que
podem subsidiar a escolha da técnica de inspeção mais apropriada. Além disso, o estudo
contribui para a melhoria contínua da qualidade dos softwares desenvolvidos, pois os
profissionais terão informações sobre os tipos de defeitos com maior índice de ocorrência em
documentos de requisitos de software (BERTINI, 2006).
23
3 DESENVOLVIMENTO DO APLICATIVO
Neste capitulo estão descritos os requisitos funcionais, os requisitos não funcionais, o
diagrama de casos de uso, o modelo de entidade relacionamento, a operacionalidade do
aplicativo, os resultados e a sua discussão.
33..11 LLEEVVAANNTTAAMMEENNTTOO DDEE IINNFFOORRMMAAÇÇÕÕEESS
Após observações in loco sobre a criação e edição de listas de verificação pelas
equipes na Senior Sistemas foi possível identificar a necessidade do desenvolvimento de um
aplicativo web que permita a edição das listas por mais de uma pessoa ao mesmo tempo e que
armazene as evidências num local único.
33..22 EESSPPEECCIIFFIICCAAÇÇÃÃOO
A seguir são apresentados os requisitos funcionais (RF), requisitos não funcionais
(RNF), diagrama de casos de uso e o modelo de entidade relacionamento (MER).
3.2.1 Requisitos Funcionais
O Quadro 1 apresenta os requisitos funcionais previstos para o sistema e sua
rastreabilidade, ou seja, vinculação com o(s) caso(s) de uso associado(s).
24
Requisitos Funcionais Caso 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
Quadro 1 - Requisitos funcionais
3.2.2 Requisitos Não Funcionais
O Quadro 2 lista os requisitos não funcionais previstos para o sistema.
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. Quadro 2 - Requisitos não funcionais
3.2.3 Diagrama de casos de uso
A Figura 6 exibe os diagramas de casos de uso do sistema. Os atores são o
administrador, que tem acesso total ao sistema, e o operador, que pode manipular as listas de
verificação criadas pelo administrador.
O detalhamento dos casos de uso está descrito no Apêndice A.
25
Figura 6 – Diagrama de casos de uso
3.2.4 Modelo Entidade Relacionamento
A Figura 7 apresenta o modelo entidade-relacionamento no qual estão as tabelas que
são persistidas no banco de dados utilizado pela aplicação.
26
Figura 7 – Modelo entidade relacionamento
Foram definidas seis tabelas no banco de dados para utilização no aplicativo para
criação e manipulação de listas de verificação de apoio à inspeção de software. No Apêndice
B consta o dicionário de dados.
33..33 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
3.3.1 Técnicas e ferramentas utilizadas
Para o desenvolvimento do aplicativo para criação e manipulação de listas de
verificação foram utilizas as linguagens Java, JavaScript, HTML 5 e CSS 3. Na compilação e
depuração a ferramenta Eclipse, versão Indigo. O banco de dados utilizado, conforme
explicitado no RNF02, foi o MySQL, versão 5.2. Para a persistência dos dados foi utilizado o
JDBC. O contêiner de aplicações web Apache Tomcat foi utilizado para a execução dos
27
servlets.
Para a restrição de acesso do aplicativo foi utilizada a autenticação básica do
HyperText Transfer Protocol (HTTP). Esta autenticação utiliza funções embutias do servidor
da web para limitar o acesso.
Para que a criação dinâmica dos componentes e a alteração simultânea das listas de
verificação fossem possíveis, foram utilizados o AJAX, o AJAX Polling, o DHTML, o
framework Prototype e a API Sax Parser.
O framework Prototype serve para construção de aplicações dinâmicas Asynchronous
Javascript and XML (AJAX).
O AJAX permite a criação de páginas web mais interativas com o usuário. Ele não é
uma tecnologia, ele é um conjunto de tecnologias trabalhando juntas. O AJAX incorpora no
seu modelo a exposição e interação dinâmica usando o Document Object Model (DOM). O
DOM é um modelo de objetos de documentos que permite a alteração e edição dinâmica da
estrutura, do conteúdo e do estilo de um documento eletrônico. Para o intercâmbio e
manipulação de dados é utilizado o XML. A recuperação assíncrona de dados se dá através do
uso dos objetos XMLHttpRequest e XMLHttpResponse. O JavaScript faz a junção entre os
elementos.
A técnica chamada de AJAX Polling fica enviando requisições para o servidor para
verificar se existe alguma alteração, e caso exista renderiza a alteração para todos os usuários.
O DHTML é formado por um conjunto de tecnologias que permite que uma página
web seja modificada dinamicamente na própria máquina cliente, sem necessidade de novos
acessos ao servidor.
Sax Parser é um conjunto de interfaces que é implementada para efetuar o parsing de
arquivos no formato XML.
A especificação deste aplicativo foi feita utilizando-se os diagramas da Unified Model
Language (UML), usando o software de modelagem Enterprise Architect, produzindo os
modelos de casos de uso e o modelo entidade relacionamento.
Para a criação da documentação da aplicação foi utilizado o MadCap Flare.
3.3.2 Codificação do aplicativo
A aplicação foi desenvolvida utilizando o modelo cliente-servidor. Para a comunicação
entre o client e o server foi utilizado o framework Prototype. Este framework serve para
28
construção de aplicações dinâmicas Asynchronous Javascript and XML (AJAX). O código
que encapsula o XMLHttpRequest do Javascript está representado pela Figura 8.
Figura 8 – Implementação da função ClientConnector
Para a atualização simultânea de vários usuários é utilizada a técnica chamada de
AJAX Polling. A função setInteval do JavaScript (Figura 9) chama uma função de
sincronização (Figura 10) de dados.
Figura 9 – Chamada da função setInterval
29
Figura 10 – Função de sincronização dos dados
A definição do componente base para a criação e atualização dinâmica de
componentes no client está demonstrada na Figura 11. O framework Prototype e o Dynamic
HyperText Markup Language (DHTML) são utilizados para a criação e atualização de
componentes.
Figura 11 – Implementação do componente base
30
As telas deste aplicativo foram criadas utilizando HTML 5 e CSS 3 para que o código
ficasse mais limpo e leve, além de possuírem mais recursos que o HTML 4 e o CSS 2. A
Figura 12 mostra parte do index.html.
Figura 12 – Parte do index.html
A definição das folhas de estilo utilizando CSS 3 está representada pela Figura 13.
31
Figura 13 – Parte do style.css
As Figuras 14 e 15 mostram código que realiza o parse do XML proveniente do client
para tratamento no server utilizando a API SaxParser.
32
Figura 14 – Parse do XML
Figura 15 – Parse do XML
A classe que renderiza e atualiza o componente EditBox no server está representada na
Figura 16.
33
Figura 16 – Classe que renderiza e atualiza o editBox
A Figura 17 representa a classe que realiza a inserção de registros na base utilizando
Java Database Connectivity (JDBC).
Figura 17 – Classe que insere novo usuário na base
34
O método update (Figura 18) da classe ExecuteListForm.java, permite a atualização
dinâmica de vários usuários simultâneos.
Figura 18 – Método update
3.3.3 Operacionalidade da implementação
O início do uso do aplicativo para criação e manipulação de listas de verificação de
apoio à inspeção de software dá-se através da autenticação do usuário (Figura 19). Existem
dois tipos de usuário, o usuário administrador e o operador.
35
Figura 19 – Tela de login
Caso o usuário não informe usuário ou senha é exibida a mensagem da Figura 20 ao
usuário. Caso ele não esteja cadastrado ou algum dos dados do login esteja incorreto o
aplicativo apresentará a mensagem exibida na Figura 21.
Figura 20 – Tela de login com validação de usuário
Figura 21 – Tela de login com validação de usuário
36
Caso a categoria do usuário seja administrador do sistema, ele terá acesso a todas as
funcionalidades do sistema (Figura 22). Caso o usuário seja o operador, ele somente terá
acesso as listas de verificação criadas pelo administrador (Figura 23).
Figura 22 - Perfil do administrador
Figura 23 - Perfil do operador
O usuário administrador tem permissão para o cadastro de novos usuários no aplicativo
através do botão Controlar usuários. Ao clicar nesse botão a tela para cadastro de novos
usuários é exibida (Figura 24).
37
Figura 24 – Tela de controle de usuários
Para inserir um novo usuário o administrador deve clicar no botão Novo. Caso o
administrador não informe o login, a senha, o nome ou o tipo do usuário será exibida uma
mensagem ao usuário informando que um campo obrigatório não foi preenchido.
Quando o administrador preencher todos os campos corretamente e pressionar o botão
Gravar, o novo usuário estará cadastrado na aplicação. Se já existir um usuário cadastrado
com o mesmo login será exibida uma mensagem informando que já existe um usuário com
este login.
A tela de controle de usuário também permite a alteração ou exclusão de algum
usuário já cadastrado. Para alterar alguma informação do usuário basta alterar o campo
desejado e clicar em Gravar. Para excluir deve-se clicar no botão Excluir.
Além de controlar os usuários, o administrador também tem permissão para a criação
de novos templates de listas de verificação. Para tal, deve clicar no botão novo template,
disponível no perfil do usuário. Ao clicar neste botão será exibida a tela representada pela
Figura 25.
38
Figura 25 – Tela de criação de templates
No campo identificador da inspeção deve ser inserido um identificador único para o
template. O campo moderador apresenta o login do criador do template. Quaisquer
informações sobre a inspeção devem ser informadas no campo descrição da inspeção de
software. O campo autor do artefato serve para descrever quem são os geradores dos artefatos
a serem revisados. No campo revisor o moderador deve selecionar os usuários responsáveis
por executar a inspeção de software (Figura 26).
Figura 26 – Campos para criação de template
A tela de criação de templates apresenta um painel com as ações disponíveis para a
criação do novo template (Figura 27).
39
Figura 27 – Ações disponíveis para criação do template
Os itens de verificação representam o que será verificado durante a inspeção do
software. Já os passos, representam o que será verificado para cada item. Para inserir itens de
verificação basta clicar no botão representado por um sinal de soma ao lado do texto Item de
Verificação e preencher os campos conforme necessidade da inspeção de software (Figura
28).
Figura 28 – Cadastro de itens de verificação
Para inserir passos de verificação basta clicar no botão representado por um sinal de
soma ao lado do texto Passo de Verificação. Ao clicar neste botão será exibida uma janela
modal conforme Figura 29.
40
Figura 29 – Inserção de um passo de verificação
Nesta janela modal deve ser inserida a descrição do passo e definido o componente que
será inserido no template da lista de verificação. O aplicativo permite a inserção de quantos
passos de verificação foram necessários para a realização da inspeção de software (Figura 30).
Figura 30 – Inserção vários passos de verificação
Caso o moderador pressione o botão voltar, representado por uma seta verde, sem ter salvado
o template criado, será exibida a mensagem ao usuário conforme Figura 31.
41
Figura 31 – Mensagem de dados não salvos
Quando o moderador finalizar a construção do novo template e clicar no botão salvar,
a nova lista será inserida no quadro de listas de verificações presente no perfil do usuário.
Tanto no perfil do usuário administrador quanto no perfil do operador é apresentado
um quadro com todas as listas de verificação existentes (Figura 32).
Figura 32 – Listas de verificação existentes
O quadro que contém as listas de verificação apresenta as seguintes informações e
ações:
a) identificador da inspeção: vínculo da lista de verificação à inspeção de software;
b) descrição: descrição da inspeção de software;
c) moderador: nome do usuário criador da lista de verificação;
d) revisor: nome dos usuários elencados para a realização da revisão;
e) finalizado: informa se a lista de verificação já foi finalizada;
f) download: efetua o download da lista de verificação para o formato xls;
42
g) entrar: apresenta a lista de verificação para que esta possa ser manipulada.
O ícone para download apenas fica habilitado quando já ocorreu pelo menos uma
execução da lista de verificação. Caso a lista ainda não tenha sido executada o ícone aparece
com estilo desabilitado. Para efetuar o download basta apenas clicar no ícone habilitado.
Ao entrar em uma lista de verificação o usuário pode alterar os dados da mesma. A
aplicação permite que até dez usuários simultâneos alterem a mesma lista de verificação.
Quando existe mais de um usuário conectado na mesma lista de verificação as alterações
efetuadas por cada um dos usuários é atualizada aos demais usuários em tempo real. Quando
um usuário está editando um campo da lista de verificação (Figura 33) o mesmo campo fica
bloqueado para edição na lista dos demais usuários (Figura 34).
Figura 33 – Campo descrição da não-conformidade sendo editado pelo usuário 01
Figura 34 – Campo descrição da não-conformidade bloqueado para o usuário 02
Os dados alterados nas listas de verificações são salvos na base automaticamente e
ficam disponíveis para edição até a finalização da lista. Quando o usuário clica no botão
43
Finalizar, a lista de verificação fica desabilitada no perfil dos usuários e a partir de então pode
apenas ser exportada para o formato xls (Figura 35). A sua edição não é mais permitida.
Figura 35 – Planilha exportada para o Excel
Quando o usuário clicar no botão de ajuda do aplicativo, a tela representada pela
Figura 36 será exibida. Esta tela contém as informações básicas para a operacionalidade da
aplicação.
Figura 36 – Tela de ajuda da aplicação
44
33..44 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO
O desenvolvimento do aplicativo atendeu ao objetivo proposto de criar um aplicativo
web que auxilia a atividade de inspeção de software através do uso de listas de verificação.
Com o uso deste aplicativo tornou-se 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, com o uso do aplicativo desenvolvido, todos os artefatos gerados pelas inspeções de
software ficam armazenados no mesmo local.
Com o uso do aplicativo, a verificação dos documentos de software ficou simplificada.
Além disso, é possível definir os participantes da atividade de inspeção e gerar um documento
com o resultado final da inspeção, características essas definidas por Fagan (1986) e Doolan
(1992).
O desenvolvimento do aplicativo deste trabalho seguiu a mesma linha do protótipo
desenvolvido por Biondo (2007). Apesar de os dois trabalhos facilitarem a atividade de
inspeção de software, o desenvolvimento do aplicativo deste trabalho é mais flexível que o
proposto por Biondo por permitir a criação de templates de listas de verificação. Além de
possibilitar a alteração da mesma lista de verificação por um grupo de usuários.
A dissertação de Bertini (2006) discorre sobre as técnicas de inspeção de software e
seus benefícios, ressaltando a importância desse tipo de revisão. Os resultados obtidos com
esta pesquisa foram úteis pois demonstraram que o resultado de uma inspeção de software é
mais eficaz quando uma técnica de leitura é empregada.
O protótipo desenvolvido por Ebertz (2002) também tinha como objetivo facilitar a o
processo de verificação. Diferente do trabalho proposto por Ebertz, o aplicativo desenvolvido
por este trabalho não se baseia em nenhuma norma. Apesar disso, ambos os trabalhos tem
como foco encontrar falhas mais cedo para que o custo da correção seja mais baixo.
Em conversa informal com membros da equipe de qualidade da empresa Senior
Sistemas ficou evidenciado que o aplicativo atingiu o objetivo de simplificar a atividade de
inspeção de software dentro da organização. Foram levantadas situações pontuais de melhoria
que estão relacionadas no tópico 4.1 deste documento.
Como principais limitações do aplicativo têm-se a usabilidade e as definições de
permissão. Não foram seguidas todas as heurísticas de usabilidade para o desenvolvimento do
aplicativo, visto que este não era o principal problema das equipes da Senior Sistemas. Na
implementação atual não existe um controle de qual usuário pode acessar determinada lista.
45
4 CONCLUSÕES
Após a conclusão da implementação do aplicativo e posterior análise dos resultados,
ficou evidenciado o cumprimento do objetivo deste trabalho de facilitar a atividade de
inspeção de software. O aplicativo desenvolvido permite a criação de listas de verificação por
usuários com permissão de administrador e a manipulação das listas criadas por qualquer tipo
de usuário. A edição das listas de forma simultânea torna o trabalho mais produtivo e evita
perda de tempo e possíveis erros cometidos ao juntar as informações contidas em diferentes
arquivos para um relatório final. Além disso, com o aplicativo desenvolvido todas as listas de
verificação ficam armazenadas no mesmo lugar, facilitando a organização e o acesso a elas.
As empresas estão investindo mais em qualidade de software pois estão percebendo
que disponibilizar para o mercado um software sem bugs é um diferencial importante e
muitas vezes decisivo.
As principais dificuldades encontradas durante o desenvolvimento do aplicativo foram
o desenvolvimento de aplicações utilizando AJAX integrado com servlets, a implementação
de simulação de orientação a objetos no JavaScript com o framework Prototype para a criação
dinâmica de componentes, a definição da rotina de tratamento dos requests, criação de
categorias e tratamento de cada uma pelos diferentes formulários e a definição da rotina de
atualização simultânea de vários clients.
Apesar das dificuldades encontradas, as linguagens, técnicas e as ferramentas
utilizadas para o desenvolvimento deste aplicativo foram adequadas. Por serem tecnologias
atuais, as documentações existentes são completas e de fácil acesso.
44..11 EEXXTTEENNSSÕÕEESS
Como sugestões para futuro trabalhos têm-se:
a) melhoria da interface seguindo as heurísticas de usabilidade;
b) implementação de um campo de busca para filtragem das listas de verificação
existentes, tornando a busca mais simples quando existe um número elevado de
listas de verificação criadas;
c) implementação da edição da lista de verificação após criação pelo moderador. Isso
46
permite uma manutenção mais simplificada das listas já criadas;
d) implementação de um controle de acesso às listas de verificação. Permitindo
acesso às listas de verificação por área ou por projeto, por exemplo;
e) permitir a parametrização do tempo de sincronização na edição simultânea das
listas de verificação.
47
REFERÊNCIAS BIBLIOGRÁFICAS
BASTOS, A. et al. Base de conhecimento em teste de software. 2. ed. São Paulo: Martins,
2007.
BERTINI, L. A. Técnicas de inspeção aplicadas à avaliação de requisitos de sistemas de
software: Um Estudo Comparativo. 2006. 152 f. Dissertação (Pós-graduação em Ciências da
Computação) – Curso de Ciências da Computação, Universidade Metodista de Piracicaba,
Piracicaba.
BIONDO, A. Uma ferramenta para garantia da qualidade aplicada na implementação
de sistemas. 2007. 21 f. Artigo (Bacharel em Sistema de Informação) – Curso de sistemas de
informação, Universidade Luterana do Brasil, Canoas.
BOEHM, B. W.; BASILI, V. R. Software defect reduction top 10 list. Computer, [S.l.], v.
34, n. 1, p. 135-137, jan. 2001.
DOOLAN, E.P. Experience with Fagan's inspection method. Software - practice and
experience, [S.l.], v. 22, n. 2, 1992. Disponível em: <http://citeseerx.ist.psu.edu/>. Acesso
em: 01 set. 2011.
EBERTZ, I. C. Protótipo de apoio ao processo de verificação baseado na norma
ISO/IEC. 2002. 101 f. Dissertação (Graduação em Ciências da Computação) – Curso de
ciências da computação, UniversidaRegional de Blumenau, Blumenau.
FAGAN, M.E. Advances in Software Inspections. IEEE Transactions on software
engineering, [S.l.], v. 12, n. 7, 1986. Disponível em:
<http://www.mfagan.com/pdfs/aisi1986.pdf>. Acesso em: 11 mar. 2012.
FELIZARDO, K. R. Apoio computacional para inspeção de software. Revista de ciência da
computação, Lavras, v. 3, n. 2, p. 14-18, nov. 2004.
KALINOWSKI, M., SPÍNOLA, R. O., TRAVASSOS, G. H. Infra-estrutura computacional
para apoio ao processo de inspeção de software. In: SIMPÓSIO BRASILEIRO DE
QUALIDADE DE SOFTWARE, 2004, Brasília.
MYERS, G. J. The art of software testing. 1. ed. New York: Wiley, 1979.
PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: Makron Books, 1995.
SENIOR SISTEMAS, Histórico da empresa. Blumenau, 2012. Disponível em: <http:
www.senior.com.br>. Acesso em: 12 maio 2012.
48
APÊNDICE A – Descrição dos Casos de Uso
Este Apêndice apresenta a descrição dos principais casos de uso descritos na seção de
especificação deste trabalho. No Quadro 3 tem-se o caso de uso "Logar no Sistema".
UC01 - Caso de uso – Logar no Sistema
Ator: Administrador ou operador
Objetivo: Entrar no sistema através de um login e de uma senha
Pré-condições: Administrador/operador cadastrado no sistema
Pós-condições: Usuário logado no sistema com o menu específico sendo exibido
Cenário Principal:
1. Administrador/operador informa login
2. Administrador/operador informa senha
3. Administrador/operador clica em Fazer login
4. Sistema abre a tela principal, exibindo o perfil de acordo com a permissão do usuário
Cenário Alternativo:
No passo 2, usuário informa senha inválida
3.1 Sistema apresenta mensagem de erro para o informando que a senha está inválida
Cenário Alternativo:
No passo 1, usuário informa login inválido
3.1 Sistema apresenta mensagem de erro para o informando que o usuário não está
cadastrado. Quadro 3 – Descrição do caso de uso Logar no Sistema
No Quadro 4 apresenta-se o caso de uso "Manipular lista de verificação".
UC02 - Caso de uso – Manipular lista de verificação
Ator: Administrador/Operador
Objetivo: Manipular uma lista de verificação
Pré-condições: Lista de verificação cadastrada no sistema
Pós-condições: Lista de verificação com as alterações realizadas
Cenário Principal:
1. Administrador/Operador entra no sistema
2. Sistema exibe as listas de verificações existentes
3. Administrador/Operador entra na lista que deseja alterar
4. Administrador/Operador altera a lista de verificação
5. Sistema atualiza a lista dos demais usuários conectados a ela
6. Sistema salva as alterações realizadas
7. Administrar/Operador clica no botão finalizar
8. Sistema não permite mais edição da lista Quadro 4 – Descrição do caso de uso Manipular lista de verificação
No Quadro 5 apresenta-se o caso de uso "Visualizar listas de verificação
49
criadas ".
UC03 - Caso de uso – Visualizar listas de verificação criadas
Ator: Administrador/Operador
Objetivo: Permitir a visualização de todas as listas de verificação criadas. Quadro 5 – Descrição do caso de uso Visualizar listas de verificação criadas
No Quadro 6 apresenta-se o caso de uso "Exportar resultado da inspeção".
UC04 - Caso de uso – Exportar resultado da inspeção
Ator: Administrador/Operador
Objetivo: Permitir a exportação das lista de verificação criadas no formato xls. Quadro 6 – Descrição do caso de uso Exportar resultado da inspeção
No Quadro 7 apresenta-se o caso de uso "Vincular lista".
UC05 - Caso de uso – Vincular lista
Ator: Administrador
Objetivo: Permitir a vinculação das listas de verificação às inspeções de software realizadas. Quadro 7 – Descrição do caso de uso Vincular lista
No Quadro 8 apresenta-se o caso de uso "Criar template".
UC06 - Caso de uso – Criar template
Ator: Administrador
Objetivo: Criar novo template de lista de verificação
Pré-condições: Usuário com permissão de administrador
Pós-condições: Template criado e visível no quadro de listas de verificações existentes
Cenário Principal:
1. Administrador entra no sistema
2. Sistema exibe o perfil do administrador
3. Administrador clica no botão Novo template
4. Sistema apresenta a tela de criação de novo template
5. Sistema preenche o campo moderador com o nome do usuário criador do template
6. Administrador informa identificador da inspeção
7. Administrador informa a descrição da inspeção
8. Administrador informa os autores dos artefatos
9. Administrador clica no botão adicionar revisores
10. Sistema apresenta janela com os usuários cadastrados no sistema
11. Administrador seleciona os revisores e clica no botão ok
12. Sistema apresenta os nomes dos revisores no campo revisor
13. Administrador clica no botão inserir novo item
14. Sistema cria dinamicamente um textarea
15. Administrador clica no botão inserir novo passo
16. Sistema apresenta janela para edição do passo
17. Administrador informa a descrição do passo e o tipo do componente
18. Sistema renderiza o componente escolhido para todos os itens já existentes
19. Administrador clica em salvar
20. Sistema salva o novo template na base de dados
21. Sistema atualiza o quadro de listas de verificações existentes
50
Cenário Alternativo:
No passo 6, caso o administrador informar um identificador da inspeção já existente
Ao salvar o sistema apresenta uma tela informando que o identificador da inspeção já existe
Cenário Alternativo:
No passo 7, caso o administrador não informar a descrição da inspeção
O Sistema apresenta uma tela informando que o campo descrição da inspeção deve ser
preenchido
Cenário Alternativo:
No passo 13, caso o administrador clicar em salvar
O Sistema salva o template apenas com os dados informados
Cenário Alternativo:
No passo 17, caso o administrador escolher o componente combobox
17.1. Sistema apresenta campo para inserção dos valores do combobox
17.2. Administrador informa os valores
Cenário Alternativo:
No passo 19, caso o administrador clicar no botão voltar
19.1. Sistema apresenta uma janela informando que existem dados não salvos e pede para
confirmar a saída.
19.2. Administrador clica no botão sim
19.3. Sistema descarta os dados preenchidos
19.4. Sistema apresenta o perfil do usuário
Cenário Alternativo:
No passo 19, administrador clica no botão voltar
19.1. Sistema apresenta uma janela informando que existem dados não salvos e pede para
confirmar a saída.
19.2. Administrador clica no botão não
19.3. Sistema volta a para a tela de criação do template Quadro 8 – Descrição do caso de uso Criar template
No Quadro 9 apresenta-se o caso de uso "Manter usuários ".
UC07 - Caso de uso – Manter usuários
Ator: Administrador
Objetivo: Permitir ao usuário com permissão de administrador cadastrar novos usuários e
alterar, buscar ou excluir usuários já cadastrados. Quadro 9 – Descrição do caso de uso Manter usuários
51
APÊNDICE B – Detalhamento do dicionário de dados
Segue documentação que contem o detalhamento do dicionário de dados, descrevendo
o MER que está na seção 3.2.6.
O quadro 10 apresenta o dicionário de dados da entidade user.
Entidade: user – Definição de usuário
Atributo Tipo Descrição
name Varchar(100) Nome do usuário.
login (PK) Varchar(32) Login do usuário.
pass Varchar(12) Senha do usuário.
type Varchar(30) Tipo do usuário (administrador ou operador).
Quadro 10 - Dicionário de dados da entidade user
O quadro 11 apresenta o dicionário de dados da entidade checklistdef.
Entidade: checklistdef – Definição do template do checklist
Atributo Tipo Descrição
id (PK) Int Código identificador checklist.
name Varchar(100) Nome identificador do checklist.
description Varchar(200) Descrição do checklist.
moderator (FK) Varchar(100) Usuário moderador do checklist.
artifactauthors Varchar(255) Autores dos artefatos.
reviser (FK) Varchar(100) Revisores dos artefatos.
Quadro 11 - Dicionário de dados da entidade checklistdef
O quadro 12 apresenta o dicionário de dados da entidade checklistitemdef.
Entidade: checklistitemdef – Definição do item do checklist
Atributo Tipo Descrição
id (PK) Int Código identificador do item do checklist.
52
description Varchar(255) Descrição do item do checklist.
checklistdef (FK) Int Código identificar do checklist o qual o item pertence.
Quadro 12 - Dicionário de dados da entidade checklistitemdef
O quadro 13 apresenta o dicionário de dados da entidade checkliststepdef.
Entidade: checkliststepdef – Definição do passo de verificação do checklist
Atributo Tipo Descrição
id (PK) Int Código identificador do passo de verificação do checklist.
description Varchar(255) Descrição do passo de verificação do checklist.
component Varchar(45) Descrição do tipo de componente.
values Varchar(100) Lista de valores caso o componente escolhido tenha sido
o combobox.
checklistdef (FK) Int Código que identifica a qual checklist o passo pertence.
Quadro 13 - Dicionário de dados da entidade checkliststepdef
O quadro 14 apresenta o dicionário de dados da entidade checklist.
Entidade: checklist – Definição do checklist em execução
Atributo Tipo Descrição
id (PK) Int Código identificador de um checklist em execução.
checklistdef (FK) Int Código identificador do checklist em execução.
Finaldate Varchar(200) Descrição do usuário finalizador do template e a data que
foi finalizado.
Quadro 14 - Dicionário de dados da entidade checklist
O quadro 15 apresenta o dicionário de dados da entidade checklistitem.
Entidade: checklistitem – Definição do valor do checklist em execução
Atributo Tipo Descrição
id (PK) Int Código identificador do campo de um checklist em
execução.
checklist (FK) Int Código identificador do checklist.
53
checklistitemdef (FK) Int Código identificador do item do checklist.
checkliststepdef (FK) Int Código identificador do passo do checklist.
value Varchar(255) Valor preenchido no campo.
Quadro 15 - Dicionário de dados da entidade checklistitem
