ferramenta de suporte a gestÃo de...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
FERRAMENTA DE SUPORTE A GESTÃO DE DEFEITOS
COM INTEGRAÇÃO ENTRE 0800NET E MANTIS
THIAGO FABIAN LENZI
BLUMENAU 2012
2012/1-18
THIAGO FABIAN LENZI
FERRAMENTA DE SUPORTE A GESTÃO DE DEFEITOS
COM INTEGRAÇÃO ENTRE 0800NET E MANTIS
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-18
FERRAMENTA DE SUPORTE A GESTÃO DE DEFEITOS
COM INTEGRAÇÃO ENTRE 0800NET E MANTIS
Por
THIAGO FABIAN LENZI
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. Mauro Marcelo Mattos, Doutor – FURB
______________________________________________________ Membro: Prof. Marcel Hugo, Mestre – FURB
Blumenau, 06 de julho de 2012.
RESUMO
O constante aumento no volume de projetos de software, bem como a sua complexidade fazem com que aumentem também o número de defeitos gerados, tornando assim necessária a gestão dos defeitos nos projetos. Para possibilitar aos gerentes de projetos da empresa Edusoft Tecnologia uma melhor gestão dos defeitos e eliminar a duplicação do trabalho de registrar defeitos em duas ferramentas, foi desenvolvida uma ferramenta que realiza a integração dos defeitos registrados na ferramenta 0800net com a ferramenta Mantis e fornece consultas gerenciais para a análise dos defeitos. O 0800net é uma ferramenta de gestão de serviços voltada a incidentes, problemas, mudanças, dentre outras atividades organizacionais. O Mantis por sua vez é uma ferramenta voltada à gestão de defeitos. Para o desenvolvimento da ferramenta de integração foram utilizados os bancos de dados Sql Server e MySQL, e o servidor Web Glassfish. A utilização desta ferramenta forneceu informações para avaliar a produtividade da equipe, permitindo assim um melhor planejamento dos projetos e também avaliar mudanças necessárias no projeto, bem como o impacto destas mudanças na qualidade do produto.
Palavras-chave: Ferramenta Mantis. Ferramenta 0800net. Gestão de defeitos.
ABSTRACT
The constant increase in the volume of software projects and their complexity make also increase the number of defects generated, making requiring the management of defects in the projects. To enable project managers of the company Edusoft technology a better management of defects and eliminate duplication of work to record defects in two frameworks, was developed a framework that performs the integration of the defects recorded in the framework with the framework 0800net Mantis provides consultation and management for the analysis of defects. The 0800net is a service management framework focused on incidents, problems, changes, among other organizational activities. Mantis on the other hand, is a framework used for the management of failures. To develop the integration framework was used the database Sql Server and MySQL, and Web server Glassfish. The use of this framework has provided information to evaluate staff productivity, allowing this way, a better planning of projects and also evaluate necessary changes in the project, as well as the impact of these changes on product quality. Keywords: Framework Mantis. Framework 0800net. Management of defects.
LISTA DE FIGURAS
Figura 1 – Diferença entre Erro, Defeito e Falha ..................................................................... 15
Figura 2 - Elementos chaves da gestão de defeitos .................................................................. 16
Figura 3- Áreas e processos atendidos pela ferramenta 0800net.............................................. 21
Figura 4 - Quadro de andamento dos projetos .......................................................................... 22
Figura 5 – Sistema atual da Edusoft ......................................................................................... 23
Figura 6 - Exemplo de modelo de texto de um defeito ............................................................ 26
Figura 7 – Fluxo após implementação da ferramenta............................................................... 27
Figura 8 - Diagrama de casos de uso da ferramenta. ................................................................ 29
Figura 9 – Diagrama de atividades do caso de uso integrar defeitos ....................................... 31
Figura 10 - Modelo Entidade Relacionamento da ferramenta .................................................. 33
Figura 11 – Modelo Entidade Relacionamento do 0800net ..................................................... 34
Figura 12 – Diagrama de entidade relacionamento do Mantis ................................................. 35
Figura 13 – Gatilho de integração de tarefas ............................................................................ 36
Figura 14 – Trecho do método de conversão de trâmites/tarefas em defeitos ......................... 37
Figura 15 – Classe de gerenciamento de tarefas....................................................................... 39
Figura 16 – Arquivo web.xml com a inclusão do listener........................................................ 40
Figura 17 – Tela de login da ferramenta de integração ............................................................ 41
Figura 18 – Falha de login na ferramenta ................................................................................. 41
Figura 19 – Tela inicial da ferramenta...................................................................................... 42
Figura 20 – Tela de informações da ferramenta ....................................................................... 42
Figura 21 – Tela de integração de dados da ferramenta ........................................................... 43
Figura 22 – Gravação da configuração de conexões com o 0800net e o Mantis ..................... 44
Figura 23 – Mensagem de criação dos gatilhos de integração ................................................. 44
Figura 24 – Mensagem de integração de defeitos realizada ..................................................... 45
Figura 25 – Consulta de defeitos .............................................................................................. 45
Figura 26 – Apresentação dos defeitos no Mantis .................................................................... 46
Figura 27 – Consulta de eficácia na detecção de defeitos ........................................................ 47
Figura 28 – Consulta de defeitos por criticidade x cliente x teste ............................................ 47
Figura 29 – Consulta de tempo de resposta na correção de defeitos ........................................ 48
Figura 30 – Consulta de quantidade de defeitos encontrados .................................................. 49
LISTA DE QUADROS
Quadro 1 - Comparativo entre as funcionalidades do Mantis, Trac e Bugzilla ........................ 19
Quadro 2 - Requisitos funcionais ............................................................................................. 28
Quadro 3 - Requisitos não funcionais ...................................................................................... 28
Quadro 4 – Descrição do caso de uso Configurar Conexão com o 0800net e Mantis ............. 29
Quadro 5 – Descrição do caso de uso Criar gatilhos de integração ......................................... 30
Quadro 6 – Descrição do caso de uso Consultar eficácia na detecção de defeitos................... 32
Quadro 7 – Descrição do caso de uso Consultar quantidade de defeitos encontrados ............. 32
Quadro 8 – Descrição do caso de uso Consultar tempo de resposta na correção de defeitos. . 32
Quadro 9 - Fórmula para comparar defeitos encontrados pelo cliente e pelo teste .................. 46
Quadro 10 – Comparativo do processo com a integração ........................................................ 50
Quadro 11 – Dicionário de dados da entidade tb_conexao ...................................................... 55
Quadro 12 – Dicionário de dados da entidade tb_tramite0800 ................................................ 55
Quadro 13 – Dicionário de dados da entidade tb_tramite_falha .............................................. 56
Quadro 14 - Dicionário de dados da entidade tb_defeito ......................................................... 57
Quadro 15 - Dicionário de dados da entidade usuario.............................................................. 57
Quadro 16 - Dicionário de dados da entidade TipoVersao ...................................................... 57
Quadro 17 - Dicionário de dados da entidade Tarefa ............................................................... 58
Quadro 18 - Dicionário de dados da entidade Atividade.......................................................... 58
Quadro 19 - Dicionário de dados da entidade Mantis_project_table ....................................... 58
Quadro 20 - Dicionário de dados da entidade Mantis_user_table ............................................ 58
Quadro 21 - Dicionário de dados da entidade Mantis_bug_text_table .................................... 58
Quadro 22 - Dicionário de dados da entidade Mantis_bug_table ............................................ 59
LISTA DE SIGLAS
CMMI - Capability Maturity Model Integration
EDD – Eficácia na detecção de defeitos
JSF – Java Server Faces
SLA – Service Level Agreement
TI – Tecnologia da Informação
UML - Unified Modeling Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 13
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14
2.1 GESTÃO DE DEFEITOS ................................................................................................. 14
2.2 MANTIS ............................................................................................................................ 18
2.3 0800NET ........................................................................................................................... 20
2.4 SISTEMA ATUAL ........................................................................................................... 21
2.5 TRABALHOS CORRELATOS ........................................................................................ 23
3 DESENVOLVIMENTO .................................................................................................... 25
3.1 LEVANTAMENTO DE INFORMAÇÕES ...................................................................... 25
3.2 ESPECIFICAÇÃO ............................................................................................................ 27
3.2.1 Requisitos funcionais ...................................................................................................... 27
3.2.2 Requisitos não funcionais ............................................................................................... 28
3.2.3 Diagrama de casos de uso ............................................................................................... 28
3.2.4 Modelos Entidade Relacionamento................................................................................. 32
3.3 IMPLEMENTAÇÃO ........................................................................................................ 35
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 36
3.3.1.1 Codificação do sistema ................................................................................................. 36
3.3.2 Operacionalidade da implementação .............................................................................. 40
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 49
4 CONCLUSÕES .................................................................................................................. 52
4.1 EXTENSÕES .................................................................................................................... 52
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 54
APÊNDICE A – Descrição do dicionário de dados ............................................................. 55
12
1 INTRODUÇÃO
À medida que a capacidade de produção de software das empresas de tecnologia
aumenta, também aumenta a complexidade dos softwares desenvolvidos. Pelo fato de muitas
empresas não aplicarem as técnicas de engenharia de software de maneira eficaz, estas
possuem muitos problemas (SOMMERVILLE, 2003). Segundo Bartié (2002, p. 5), “com o
aumento da complexidade no desenvolvimento do software¸ aumentam proporcionalmente os
riscos de mau funcionamento dos mesmos, tornando-se mais difícil produzir softwares com
um nível de qualidade desejado” .
A implantação de um processo de garantia de qualidade de software torna-se então,
essencial para a sobrevivência e competitividade no mercado. No entanto, garantir a qualidade
de software não é uma tarefa simples, pois envolve todos os processos do desenvolvimento de
software (BARTIÉ, 2002). A implantação de um programa de melhoria de processos de
software é uma forma eficaz das empresas implantarem processo de garantia da qualidade,
pois estes descrevem uma estrutura de trabalho que possui os elementos necessários para
tornar o desenvolvimento de software mais eficiente e controlado (BARTIÉ, 2002).
No entanto, garantir qualidade não significa produzir um software livre de defeitos. A
produção de softwares com defeitos é um problema comum enfrentado por empresas de
software. O ideal seria que não houvessem defeitos nos softwares produzidos, mas enquanto
não se chega nesta situação, a prática de gerenciar os defeitos torna-se essencial (ELIZA;
LAGARES, 2011).
Neste contexto, uma boa gestão de defeitos aplicada no processo de desenvolvimento
de software pode ser o diferencial para se conseguir alcançar níveis satisfatórios de qualidade,
bem como evitar atrasos no planejamento do projeto.
Na empresa Edusoft Tecnologia, a gestão de defeitos (bugs) é realizada com a
utilização de uma ferramenta de gestão de serviços e negócios. Tendo a necessidade de tornar
mais efetivo e seguro o gerenciamento e controle destes defeitos, tomou-se a decisão de
utilizar uma ferramenta especializada para esta finalidade. Para que se possa realizar o
processo de gestão de defeitos e permitir aos clientes da empresa a abertura/acompanhamento
dos problemas encontrados, torna-se necessária a utilização em conjunto das ferramentas de
apoio ao usuário e gestão especializada de defeitos. Entretanto, utilizar as duas ferramentas,
sem integração entre elas, pode resultar em perda de dados além de trabalho desnecessário de
registro em cada ferramenta. Além do mais, não há garantias de que as informações estejam
13
registradas adequadamente nas duas ferramentas, podendo assim resultar em perda de dados e
consequentemente, relatórios gerenciais incorretos.
Tendo a necessidade de integrar as ferramentas especializadas em gestão de serviços e
negócios e gestão de defeitos, 0800net e Mantis respectivamente, pesquisou-se na internet
uma solução de integração pronta, que atendesse às necessidades da empresa, entretanto não
houve sucesso na busca. Observou-se então, a oportunidade de desenvolver uma ferramenta
personalizada que realize a integração entre o 0800net e o Mantis e atenda plenamente as
necessidades envolvidas.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é desenvolver uma ferramenta que auxilie o processo de
gestão de defeitos da Edusoft, realizando a integração de dados entre a ferramenta 0800net e a
ferramenta Mantis e fornecendo consultas como suporte à gestão de defeitos.
1.2 ESTRUTURA DO TRABALHO
No primeiro capítulo tem-se a introdução ao tema principal deste trabalho com a
apresentação dos objetivos.
No segundo capítulo apresenta-se a fundamentação teórica pesquisada sobre processos
de software, gestão de defeitos, Mantis, 0800net e trabalhos correlatos.
O terceiro capítulo apresenta o desenvolvimento da ferramenta iniciando-se com o
levantamento de informações, tendo na sequência a especificação, a implementação e os
resultados e discussões.
No quarto capítulo têm-se as conclusões deste trabalho bem como se apresentam
sugestões para trabalhos futuros.
14
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda assuntos a serem apresentados nas seções a seguir que
fundamentam o desenvolvimento deste trabalho, tais como gestão de defeitos, ferramentas
utilizadas, sistema atual além de trabalhos correlatos.
2.1 GESTÃO DE DEFEITOS
O processo de desenvolvimento de software cria naturalmente produtos com defeitos,
sendo que na maior parte dos casos, estes defeitos são considerados um risco para a imagem
da empresa e do negócio. Portanto, descobrir os defeitos do(s) software(s) da empresa não é
suficiente, é essencial adotar o gerenciamento de defeitos no processo de teste para minimizar,
controlar, evidenciar os riscos para que os seus impactos não sejam grandes (ELIZA;
LAGARES, 2011).
Segundo Eliza e Lagares (2011, p. 68), “é importante que a gestão de defeitos seja
realizada, pois a mesma possibilita uma visão geral e conseqüentemente um melhor
acompanhamento do andamento do projeto, através da verificação dos bugs encontrados“.
Baseado neste contexto observa-se que a qualidade do sistema pode ser medida a partir
dos bugs encontrados (ELIZA; LAGARES, 2011).
Mas ainda mais primordial que a medição da qualidade, o grande objetivo é evitar
defeitos. A gestão de defeitos possui outros princípios como a utilização de ferramentas de
automação para registro e gestão dos defeitos integrando equipes de desenvolvimento e testes,
e a utilização das informações coletadas para otimização do trabalho de desenvolvedores e
testadores com o objetivo de melhorar continuamente os processos envolvidos (BASTOS,
2007).
Eliza e Lagares (2011, p.68) conceituam na Figura 1 a diferença entre erro, defeito e falha:
a) erro, ou engano é a ação humana que produz resultados incorretos, como por
exemplo a implementação incorreta de um algoritmo;
15
b) defeito ou bug é a falha em um sistema que pode ocasionar uma anomalia ao tentar
desempenhar sua devida função. Por exemplo, omissão de informações e cálculos
incorretos;
c) falha é a ação inesperada do software, no caso a apresentação de resultados
diferentes do planejado.
Fonte: Eliza e Lagares (2011, p. 68). Figura 1 – Diferença entre Erro, Defeito e Falha
Segundo Bastos (2007, p. 188) “os elementos chaves no processo de gestão de defeitos
são:”
a) prevenção de defeitos;
b) linha-de-base (baseline) a ser entregue;
c) identificação do defeito;
d) solução do defeito;
e) melhoria do processo;
f) relatórios de gestão.
A Figura 2 demonstra os elementos chaves no processo de gestão de defeitos citados por Bastos (2007).
16
Fonte: Bastos (2007, p. 188). Figura 2 - Elementos chaves da gestão de defeitos
A prevenção de defeitos consiste em identificar os riscos críticos e estimar os impactos
esperados minimizando-os. Para isso deve-se entender os riscos críticos a serem enfrentados
pelo projeto, identificando os defeitos que podem vir a colocar em risco o sucesso da
construção, entrega ou funcionamento do projeto. São exemplos, a falta ou inconsistência de
um requisito chave, a não familiarização com tipo de negócio pela equipe e problemas
existentes de integração de ambientes. Tendo a identificação dos principais riscos, deve-se
estimar os impactos. Para estimar o impacto de um defeito, deve-se avaliar com que
frequência o mesmo ocorre, o custo de sua correção e as consequências para o sistema e para
os negócios. Tendo estimado os impactos, deve-se então, adotar técnicas para a minimização
de impactos. O objetivo inicial é eliminar o risco. Quando não for possível eliminá-lo, deve-se
tentar reduzir a probabilidade do mesmo tornar-se um problema, ainda definindo por fim um
plano de contingência para o caso de uma ocorrência. Bastos (2007, p. 190), cita que a melhor
formar de realizar esta prevenção é adotando a prática de gerenciamento dos riscos. Algumas
técnicas como a garantia de qualidade, treinamentos e padronização de metodologias são
apropriadas (BASTOS, 2007).
O baseline é o elemento que define um ou mais marcos do projeto com o objetivo de
monitorar e controlar as alterações realizadas (ELIZA; LAGARES, 2011).
Segundo Bastos (2007, p. 192), “estes marcos definem a transferência de um estágio
para outro“.
A prevenção de defeitos consiste em três etapas, encontrar, relatar e reconhecer um
defeito. A descoberta de defeitos ocorre com o controle de qualidade, ou por usuários na
utilização do sistema em produção. Encontrado um defeito, o mesmo deve ser relatado com
rapidez, para evitar prejuízos às atividades da organização. É importante que o mesmo seja
relatado detalhadamente para facilitar o seu entendimento. Por fim, depois de detectado o
defeito, o desenvolvedor irá decidir se o mesmo é válido. Entretanto, um defeito deve ser
considerado como tal, se o sistema apresentar comportamento diferente ao descrito na
documentação (BASTOS, 2007).
17
A solução do defeito é um elemento que deve priorizar e programar a correção,
corrigir o defeito e relatar a solução. A priorização deverá determinar baseado em critérios
definidos a classificação do defeito. Sugere-se a classificação dos critérios:
a) crítico: tem sério impacto na operação do negócio da organização;
b) grave: produz um resultado incorreto ou pára de funcionar;
c) menor: alguma coisa está errada, mas não afeta diretamente os usuários. Erros na
documentação ou na interface gráfica são exemplos.
Definida a priorização da correção, o passo seguinte é programar a correção, alocando
recursos, de acordo com a agenda e a prioridade dos defeitos. A correção de defeitos envolve
a verificação, bem como a revisão de produtos envolvidos como listas de checagem
(checklists), dados de teste, programas e a execução da correção. Por fim, o defeito corrigido
deve ser relatado, informando quando a correção foi realizada, quando será liberada
(BASTOS, 2007).
Segundo Bastos (2007, p. 199), “a atividade de melhoria do processo deve abranger a
avaliação do processo que originou o defeito e a compreensão do que o causou e se
pertinentes, propostas de mudanças processuais capazes de minimizar ou eliminar a causa do
defeito.”
Segundo Eliza e Lagares (2011, p. 70), “Os relatórios de gestão fazem parte de todo o
processo de gerenciamento dos defeitos. O seu propósito é criar um registro completo dos
defeitos identificados durante o processo”.
Conforme Bastos (2007, p. 200), “Os defeitos são registrados para as seguintes
finalidades: corrigir o defeito, relatar a situação da aplicação, obter parâmetros para o
desenvolvimento de expectativas de defeitos nas aplicações futuras e melhorar o processo de
desenvolvimento de software.”
Para o registro dos defeitos, a utilização de uma ferramenta adequada é importante. A
ferramenta deve oferecer suporte para o registro de alguns itens (BASTOS, 2007):
a) número de identificação do defeito;
b) nome descritivo e tipo;
c) fonte do defeito;
d) severidade e prioridade;
e) situação atual;
18
f) data e hora para as mudanças de situação;
g) descrição detalhada;
h) componente ou programa no qual o defeito foi encontrado;
i) impressão de telas e registros (logs);
j) responsável.
A gestão de defeitos traz diversas vantagens ao processo de software no qual foi
implementada, pois permite a visualização de todo o escopo do projeto, o andamento do
processo de teste e a qualidade do sistema que está sendo testado. Outras vantagens também
são consideradas (ELIZA ; LAGARES, 2011):
a) maior visibilidade dos problemas;
b) evidências dos problemas encontrados;
c) controle e acompanhamento das implementações desenvolvidas;
d) organização de documentos e arquivos;
e) maior cooperação entre desenvolvedores e testadores;
f) coleta de dados para análise e melhorias;
g) compromisso com a remoção dos defeitos;
h) diminuição nos custos baseado em lições aprendidas fazendo com que não repitam
defeitos;
i) redução de impacto dos defeitos.
2.2 MANTIS
Mantis é uma ferramenta livre, de gerenciamento de defeitos de fácil customização e
utilização (ELIZA; LAGARES, 2011).
A ferramenta é desenvolvida na linguagem PHP e trabalha com os bancos de dados
MySQL, MS SQL e Postgre SQL e roda em servidor web. O Mantis pode ser instalado no
19
Windows, Linux, Mac OS, OS/2, e outros. Quase qualquer navegador web deve rodar o
Mantis (MANTISBT, 2011).
Segundo Eliza e Lagares (2011, p. 72), “as características mais relevantes do Mantis
são:”
a) um bug a ser corrigido, uma sugestão, ou até mesmo uma melhoria a ser efetuada
no software é definido como um caso (Issue);
b) notificações são customizáveis por e-mail;
c) suporta gerenciamento de múltiplos projetos;
d) permite customizações como permissões de acesso, categoria, campos
personalizados específicos por projeto;
e) página principal personalizável por usuário;
f) geração de relatórios e históricos;
g) permite o auto-cadastramento de usuários, além de facilidade na recuperação de
senhas esquecidas;
h) permite exportação de dados para planilha;
i) permite autenticação via LDAP.
Comparado a outras ferramentas para gestão de defeitos, o Mantis demonstra um
resultado satisfatório conforme é indicado no Quadro 1.
Critérios Mantis Trac Bugzilla Anexo de arquivos Atende Atende Atende Campos customizados Atende Parcia Atende Compatibilidade com vários sistemas operacionais
Atende Atende Atende
Customização do workflow Parcial Parcial Atende Definição de prioridade das solicitações Atende Atende Atende Facilidade de instalação Atende Parcial Não atende Facilidade na usabilidade Atende Parcial Parcial Facilidade na utilização Atende Atende Atende Geração de relatórios Atende Atende Atende Monitoramento de alterações Atende Atende Atende Rastreamento de mudanças Não atende Atende Parcial Segurança de acesso Atende Atende Atende
Fonte: Eliza e Lagares (2011 p. 73).
Quadro 1 - Comparativo entre as funcionalidades do Mantis, Trac e Bugzilla
20
2.3 0800NET
O 0800net é um software de Gerenciamento de Serviços para Tecnologia da
informação (TI) que pode ser configurado para atender os processos e workflow, ajudando a
gerenciar todos os serviços: incidentes, problemas, mudanças, consultoria, projetos de
desenvolvimento de software e implementações, contratos de service desk, help desk,
agendamento de manutenção preventiva, manutenção predial, relacionamento com o RH entre
inúmeras outras atividades das organizações.
O 0800net é uma solução completa de Business Service Management – Gestão de
negócios e serviços, e com alta capacidade de customização, que pode ser aplicada em
qualquer área da empresa.
Sua aplicação é construída para rodar integralmente pelo conceito de web/browser,
possibilitando, assim, o acesso às informações de sua empresa em qualquer lugar do mundo,
tendo como foco a Gestão de Atendimento e Serviços.
O 0800net gerencia e controla, de forma centralizada, todos os tipos de problemas e
pedidos de suporte de usuários. Possibilita abertura de chamados pelo cliente ou por e-mail,
controle de Service Level Agreement (SLA), Inventário, Controle de Projetos, Gestão de
Prospect, extração de dados para gerenciamento de métricas/índices de controle, além de
muitas vantagens que aumentarão a produtividade da empresa (ELLEVO, 2010).
21
A Figura 3 apresenta a interface para o registro de atividades internas da empresa.
Fonte: Ellevo (2010). Figura 3- Áreas e processos atendidos pela ferramenta 0800net
2.4 SISTEMA ATUAL
Atualmente na empresa Edusoft o controle de atividades (tarefas) é realizado na
ferramenta 0800net, inclusive a gestão dos defeitos. As tarefas são listadas a partir dos filtros
e visões, no qual os filtros retornam as tarefas de acordo com “o que se quer” e as visões
retornam as características das tarefas.
Os filtros normalmente são organizados por produto, versão de liberação, natureza da
tarefa e iterações da versão (sprint), Já as visões, normalmente estão configuradas para
retornar a natureza, estágio, prioridade, responsável, cliente, título da tarefa, data de abertura e
versão de liberação das tarefas retornadas pelo filtro. Contudo, tanto os filtros quanto as
visões podem ser configurados de acordo com a necessidade do usuário (gerente, líder de
projeto, desenvolvedor, testador e atendente).
22
O controle da evolução e também os defeitos encontrados no projeto, baseiam-se nas
tarefas vinculadas ao projeto e no estágio em que se encontram. A partir destas duas
informações, sabe-se qual a situação do projeto, inclusive dos defeitos encontrados.
Devido às mudanças naturais decorrentes da evolução dos projetos, e também pelo fato
de o 0800net permitir a visualização de apenas o estado atual dos projetos em forma de
listagem, as equipes de desenvolvimento e qualidade utilizam um quadro físico para melhor
visualização do projeto. O quadro é dividido em raias, sendo que cada raia é um estágio pelo
qual as tarefas passam, e para cada tarefa prevista no projeto, são colados dois papéis no
quadro contendo o número, título e tamanho da tarefa, sendo um para a atividade de
desenvolvimento e outro para os testes. A medida que as tarefas vão evoluindo, o responsável
muda a tarefa de raia. Uma vez por dia é realizada uma reunião para realizar o
acompanhamento do projeto e atualizar, o gráfico do projeto de acordo com o tamanho das
tarefas concluídas. O objetivo é tornar disponível a todos da equipe a situação atual, e a
evolução do projeto. Na Figura 4 é possível ver a evolução de um projeto em andamento.
Figura 4 - Quadro de andamento dos projetos
Atualmente não é possível medir os defeitos encontrados no projeto por diversas
perspectivas, pois o 0800net retorna apenas uma lista de tarefas, conforme os filtros
informados, sendo que pelo fato da empresa trabalhar com o conceito de tarefas e uma tarefa
possivelmente conter diversos defeitos, a informação extraída pelo relatório não é correta,
pois neste caso a quantificação de defeitos é realizada baseada na quantidade de tarefas e não
a quantidade real de defeitos. Com o Mantis, que começou-se a utilizar poucos meses antes do
23
início deste projeto é possível visualizar os defeitos por projeto, porém não com os filtros que
se deseja para a tomada de decisão gerencial.
Além da quantidade de defeitos encontrados, não é possível medir o tempo de resposta
da correção de defeitos por versão ou sprint ou a eficácia da equipe na detecção de defeitos.
Estas métricas serão mais bem descritas no capítulo 3.
A Figura 5 apresenta o sistema atual da Edusoft.
Figura 5 – Sistema atual da Edusoft
2.5 TRABALHOS CORRELATOS
Cita-se como trabalhos correlatos as monografias como a de Camila Labes e Douglas
de Oliveira Waltrick para conclusão de curso na Universidade Regional de Blumenau.
O trabalho de Labes (2010) consistiu no desenvolvimento de uma ferramenta de apoio
aos processos gerenciais na área de testes e planejamento e controle dos casos de testes de
uma empresa que tem o objetivo de obter o Capability Maturity Model Integration (CMMI)
nível 3. Pelo fato do nível 3 do CMMI exigir atividades obrigatórias direcionadas ao teste de
software, a verificação e a validação, o trabalho focou bastante na padronização dos processos
24
de testes. Para o desenvolvimento da ferramenta, foram utilizadas as tecnologias c#, asp.net e
SQL Server 2005.
O trabalho de Waltrick (2011) por sua vez, foi o desenvolvimento de uma integração
entre as ferramentas TestComplete e TestLink, com os objetivos de facilitar a execução dos
testes e manter histórico de execuções dos casos de testes nas duas ferramentas. A integração
consistia em configurar os ambientes de testes, executar no TestComplete os casos de testes
criados no TestLink, manter histórico dos casos de testes executados no TestComplete, gerar
automaticamente os resultados da automatização nos casos de teste mantidos no TestLink, e
utilizar para a automatização dos testes a massa de dados para mantida no TesLink, sem uma
carga explícita da mesma. As tecnologias utilizadas na construção do trabalho foram as
linguagens Pascal, DelphiScript, banco de dados MySQL 5.0, TestComplete 7.10.475.7 como
IDE de desenvolvimento e TestLink 1.9.2 como gerenciador dos casos de testes.
25
3 DESENVOLVIMENTO
Neste capítulo estão descritas as particularidades técnicas do sistema proposto tais
como a descrição do mesmo e a apresentação dos requisitos funcionais e não funcionais,
diagrama de casos de uso e suas descrições.
3.1 LEVANTAMENTO DE INFORMAÇÕES
Com base nos problemas citados na seção do sistema atual, desenvolveu-se uma
ferramenta que possibilita ao processo de gestão de defeitos da empresa, informações mais
detalhadas dos defeitos, permitindo aos gestores a tomada de decisões mais seguras. A partir
da utilização do Mantis com o 0800net, desenvolveu-se a integração de dados entre as duas
ferramentas.
A integração dos dados realizada pela ferramenta recupera os dados do 0800net e os
insere na tabela de trâmites da ferramenta de integração, na sequência converte um trâmite em
um ou mais defeitos e os insere na tabela de defeitos e, por fim, os insere na base de dados do
Mantis. Os dados recuperados do 0800net são o título da tarefa, a descrição da tarefa/ trâmite,
o projeto em que a tarefa está vinculada, a versão de liberação da tarefa, a data programada
para liberação da versão, a data de registro da tarefa/trâmite e o usuário que registrou a
tarefa/trâmite. A conversão de um trâmite em um ou mais defeitos insere na tabela de defeitos
o título do defeito, a descrição, a natureza, a criticidade, o projeto em que a tarefa do defeito
está vinculada, o usuário que registrou, a versão de liberação, a data de registro, a data
programada para liberação, o código do relatório, se existir e a identificação de defeito
encontrado internamente ou por cliente. Por fim, os defeitos são inseridos na base de dados do
Mantis. Sempre que necessário, também são criados usuários e projetos no Mantis.
Para que o processo de integração ocorra, é necessário que o 0800net esteja disponível
(on-line). A integração ocorre por ativação de gatilhos que detectam novas tarefas/trâmites
contendo defeitos, a partir da identificação do caractere especial § contido no trâmite. Estes
gatilhos inserem o trâmite na tabela de trâmites da ferramenta e a ferramenta realiza a
conversão do trâmite em um ou mais defeitos integrando-os com o Mantis conforme já
26
definido. Na ferramenta o usuário configura os endereços de banco de dados do 0800net e do
Mantis e cria os gatilhos.
A integração não necessita de operações manuais, sendo que quando a ferramenta
detecta registro de tarefas/trâmites no 0800net que possuam defeitos, o processo de integração
é disparado conforme a definição. Para que o processo seja disparado, é necessário que
existam defeitos a integrar, ou seja, a descrição da tarefa ou do trâmite registrado na tarefa
contenha defeitos registrados. A Figura 6 apresenta um modelo de texto preenchido na tarefa
ou no trâmite do 0800net contendo um defeito.
Figura 6 - Exemplo de modelo de texto de um defeito
A utilização do Mantis em si, possibilita aos gestores extrair relatórios da quantidade
de defeitos detectados e resolvidos por projeto. No entanto, como o objetivo é que os gestores
possam extrair outras informações importantes do projeto, a ferramenta disponibiliza três
consultas gerenciais personalizadas:
a) tempo de resposta correção de defeitos, ou seja, a média de tempo que os defeitos
filtrados levam para serem corrigidos, considerando sua abertura e sua conclusão;
b) quantidade de defeitos, ou seja, a soma dos defeitos encontrados conforme os
filtros selecionados;
c) eficácia na detecção de defeitos, que é uma métrica percentual que cruza a
quantidade de defeitos encontrados internamente, quantidade de defeitos
encontrados por clientes e a criticidade dos defeitos encontrados.
Para cada relatório (exceto o relatório de eficácia na detecção de defeitos) será possível
filtrar os defeitos por projeto, versão de liberação, usuário que registrou, natureza, criticidade
e somente defeitos em relatórios. No caso dos relatórios de eficácia na detecção de defeitos,
poderá se utilizar os filtros de versão de liberação, projeto e somente defeitos em relatórios.
Com a geração destas consultas, é possível verificar deficiências nos processos da
empresa e os gerentes têm em mãos informações precisas para tomada de decisões seguras.
A Figura 7 apresenta o fluxo do sistema após a implementação da ferramenta.
27
Figura 7 – Fluxo após implementação da ferramenta
3.2 ESPECIFICAÇÃO
Esta seção apresenta os requisitos funcionais, os requisitos não funcionais, os
diagramas de casos de uso e o modelo entidade relacionamento da ferramenta.
3.2.1 Requisitos funcionais
O Quadro 2 apresenta os requisitos funcionais previstos para a ferramenta e sua
rastreabilidade, ou seja, vinculação com o(s) caso(s) de uso associado(s).
Requisitos Funcionais Caso de Uso
RF01: A ferramenta deve permitir ao administrador configurar a conexão
com o 0800net e com o Mantis.
UC 001
RF02: A ferramenta deve permitir ao administrador criar os gatilhos de
integração no 0800net.
UC 002
RF03: A ferramenta deve integrar registro de tarefas e trâmites do
0800net com sua base de dados.
UC 003
28
RF04: A ferramenta deve converter registro de tarefas e trâmites em
defeitos.
UC 003
RF05: A ferramenta deve integrar defeitos de sua base de dados com a
base de dados do Mantis.
UC 003
RF05: A ferramenta deve permitir ao administrador executar o processo
de integração de defeitos.
UC003
RF07: A ferramenta deve permitir ao gerente realizar consulta de
eficácia na detecção de defeitos.
UC 004
RF08: A ferramenta deve permitir ao gerente realizar consulta de
quantidade de defeitos encontrados.
UC 005
RF09: A ferramenta deve permitir ao gerente realizar consulta de tempo
de resposta na correção de defeitos.
UC 006
Quadro 2 - Requisitos funcionais
3.2.2 Requisitos não funcionais
O Quadro 3 lista os requisitos não funcionais previstos para a ferramenta.
Requisitos Não Funcionais
RNF01: A ferramenta deve funcionar nos navegadores IE7 ou superior e Firefox 4 ou
superior.
RNF02: A ferramenta deve possuir segurança de acesso por senha.
Quadro 3 - Requisitos não funcionais
3.2.3 Diagrama de casos de uso
Esta sub-seção apresenta o diagrama de casos de uso da ferramenta.
Na Figura 8, têm-se os casos de uso de configurar conexões, criar gatilhos de
integração, integrar defeitos, consulta de eficácia na detecção de defeitos, tempo de resposta
na correção de defeitos e quantidade de defeitos encontrados. O ator “usuário” é representado
pelo responsável da infraestrutura da empresa com o papel de configurar as conexões entre as
conexões entre os bancos de dados da ferramenta proposta, 0800net e Mantis, a criação dos
29
gatilhos de integração e também é representado pelo gerente ou líder de projeto com o papel
de extrair os relatórios e analisá-los para avaliar se é necessária alguma tomada de decisão
para realinhar metas no projeto. Para o sistema não existe diferença entre administrador e
gerente, ambos utilizam o mesmo usuário de acesso e possuem acesso as mesmas opções do
sistema. O ator 0800Net é representado pela ferramenta 0800Net com o papel de enviar à
ferramenta as novas tarefas e trâmites criados. O ator Mantis é representado pela ferramenta
Mantis com o papel de receber da ferramenta de integração os novos defeitos.
Figura 8 - Diagrama de casos de uso da ferramenta.
O Quadro 4 apresenta a descrição do caso de uso Configurar conexão com o 0800net e
Mantis.
UC 01 – Configurar conexão com o 0800net e Mantis Ator: Usuário. Objetivo: Salvar/Atualizar os dados para acesso a base de dados do 0800net e Mantis. Pré-condições: Usuário logado na ferramenta. Pós-condições: Dados salvos com sucesso.
Quadro 4 – Descrição do caso de uso Configurar Conexão com o 0800net e Mantis
30
O Quadro 5 apresenta a descrição do caso de uso criar gatilhos de integração.
UC 02 – Criar gatilhos de integração Ator: Usuário, 0800Net. Objetivo: Criar os gatilhos responsáveis por integrar novas tarefas e trâmites do 0800net com a base de dados da ferramenta. Pré-condições: Usuário logado na ferramenta e base de dados do 0800net existente. Pós-condições: Criação de gatilhos com sucesso.
Quadro 5 – Descrição do caso de uso Criar gatilhos de integração
O caso de uso Integrar defeitos será detalhado no diagrama de atividades apresentado
na Figura 9. Este caso de uso possui três etapas, a integração de trâmites do 0800net com a
base de dados da ferramenta, a conversão de trâmites em defeitos e a integração de defeitos
com o Mantis. a integração, executando em tempo programado o monitoramento e integração
dos dados. O tempo programado pata executar a integração de defeitos é de sessenta
segundos. Posteriormente será apresentada a classe responsável por esta configuração.
Na Figura 9 apresenta-se o diagrama de atividades que detalha o caso de uso integrar
defeitos. O diagrama demonstra em alto nível como ocorre o processo desde a verificação de
trâmites na base de dados da ferramenta até a inclusão de defeitos no Mantis. Este processo
ocorre após os gatilhos de integração inserir trâmites de tarefas do 0800net na base de dados
da ferramenta.
31
Figura 9 – Diagrama de atividades do caso de uso integrar defeitos
32
O Quadro 6 apresenta a descrição do caso de uso Consultar eficácia na detecção de
defeitos
UC 04 – Consultar eficácia na detecção de defeitos Ator: Usuário. Objetivo: Consultar a eficácia na detecção de defeitos da equipe de testes de acordo com os filtros informados. Pré-condições: Usuário logado na ferramenta, defeitos existentes na tabela de defeitos da ferramenta. Pós-condições: Consulta da eficácia realizada com sucesso.
Quadro 6 – Descrição do caso de uso Consultar eficácia na detecção de defeitos
O Quadro 7 apresenta a descrição do caso de uso Consultar quantidade de defeitos
encontrados.
UC 05 – Consultar quantidade de defeitos encontrados Ator: Usuário. Objetivo: Consultar a eficácia na detecção de defeitos da equipe de testes de acordo com os filtros informados. Pré-condições: Usuário logado na ferramenta, defeitos existentes na tabela de defeitos da ferramenta. Pós-condições: Consulta da eficácia realizada com sucesso.
Quadro 7 – Descrição do caso de uso Consultar quantidade de defeitos encontrados
O Quadro 8 apresenta a descrição do caso de uso Consultar tempo de resposta na
correção de defeitos.
UC 06 – Consultar tempo de resposta na correção de defeitos Ator: Usuário. Objetivo: Consultar a eficácia na detecção de defeitos da equipe de testes de acordo com os filtros informados. Pré-condições: Usuário logado na ferramenta, defeitos existentes na tabela de defeitos da ferramenta. Pós-condições: Consulta da eficácia realizada com sucesso.
Quadro 8 – Descrição do caso de uso Consultar tempo de resposta na correção de defeitos.
3.2.4 Modelos Entidade Relacionamento
Optou-se por apresentar o modelo entidade relacionamento separado por ferramenta.
Será apresentado o modelo da ferramenta de integração, da ferramenta 0800net e da
ferramenta Mantis.
A Figura 10 apresenta o modelo entidade relacionamento da ferramenta de integração.
Apesar de não possuírem relacionamento, os dados da tabela de trâmites do 0800net são
convertidos e inseridos na tabela de defeitos.
33
Figura 10 - Modelo Entidade Relacionamento da ferramenta
A tabela tb_conexao possui apenas um registro, que contém dados para realizar a
conexão nas ferramentas 0800net e Mantis. A tabela tb_tramite0800 possui dados do 0800net
a partir do disparo dos gatilhos de integração. Quando os gatilhos detectam que há defeitos na
tarefa/trâmite gerado, isto é, identificam se a mesma possui o modelo de texto definido na
figura 8, estas recuperam os dados do 0800net e inserem na tabela de trâmites. A tabela
tb_tramite_falha possui os dados do 0800net recuperados da tabela de trâmites e que por
algum motivo não foram integrados, normalmente por preenchimento incorreto no 0800net.
A tabela de defeitos, tb_defeito, possui os defeitos recuperados dos trâmites existentes na
tabela de trâmites, mas com os dados organizados e divididos. Quando a integração converte
um trâmite em defeitos, este trâmite é removido. Por fim, ao integrar os defeitos com o
Mantis, os defeitos são marcados como integrados.
A Figura 11 apresenta o modelo entidade relacionamento da ferramenta 0800net. São
apresentadas somente as tabelas e os campos envolvidos neste processo.
34
Figura 11 – Modelo Entidade Relacionamento do 0800net
Os campos usunome da tabela Usuario, versaoL e verDataLib da tabela TipoVersao,
projeto e tarTitulo da tabela Tarefa sempre são inseridos na tabela de trâmites da ferramenta
de integração. Se o processo que ocorre é a criação de novas tarefas, é disparado o gatilho
existente na tabela Tarefa e os outros campos inseridos na tabela de trâmites são o
TarDescricao e o TarData da tabela Tarefa. Caso o processo que ocorre seja a criação de um
novo trâmite em uma tarefa, é disparado o gatilho existente na tabela Atividade e os outros
campos inseridos na tabela de trâmites são o ativDescricao e o ativData da tabela Atividade.
A Figura 12 apresenta o modelo entidade relacionamento da ferramenta Mantis. São
apresentadas somente as tabelas e os campos envolvidos neste processo.
35
Figura 12 – Diagrama de entidade relacionamento do Mantis
Quando o processo de integração é ativado, os defeitos existentes na tabela de defeitos
da ferramenta de integração são inseridos no Mantis. Todos os defeitos no Mantis são
registros da tabela Mantis_bug_table, que contém o título do defeito e referências para o
projeto do defeito que está contido na tabela Mantis_project_table, a descrição do defeito que
está contida na tabela Mantis_bug_text_table e o usuário que registrou o defeito que está
contido na tabela Mantis_user_table.
O dicionário de dados das entidades apresentadas anteriormente está descrito no
Apêndice A.
3.3 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
36
3.3.1 Técnicas e ferramentas utilizadas
A ferramenta foi desenvolvida em ambiente web na linguagem Java com a utilização
da tecnologia Java Server Faces (JSF) no ambiente de desenvolvimento e depuração Net
Beans versão 6.8 e o web container da ferramenta é o GlassFish. A base de dados da
ferramenta foi criada em Sql Server, embora a mesma também estabeleça conexões com bases
de dados MySQL. Para a criação dos modelos entidade relacionamento, foi utilizada a
ferramenta DBDesigner versão 4.0. A criação dos diagramas de casos de uso foi feita com a
utilização do Enterprise Architect versão 7.5 com base nos padrões da Unified Model
Language (UML).
3.3.1.1 Codificação do sistema
A Figura 13 apresenta o gatilho que integra novas tarefas do 0800net com a base de
dados da ferramenta de integração.
Figura 13 – Gatilho de integração de tarefas
Sempre que uma nova tarefa é criada no 0800net o gatilho é ativado. O gatilho
37
verifica se no campo TarDescricao (a descrição da tarefa) existem defeitos. Para identificar se
existem defeitos, o gatilho percorre o campo inteiro procurando o caractere “§”, se houver ao
menos um caractere, o gatilho realiza a integração.
Existe também um gatilho que realiza este processo sempre que um novo trâmite é
registrado em alguma tarefa no 0800net. A regra definida para este gatilho é a mesma do
gatilho apresentado anteriormente, mas com base nos dados do trâmite registrado.
A Figura 14 apresenta trecho do método que realiza a conversão de um trâmite ou uma
tarefa em um ou mais defeitos.
Figura 14 – Trecho do método de conversão de trâmites/tarefas em defeitos
38
Figura 14 - Trecho do método de conversão de trâmites/tarefas em defeitos (continuação)
O método apresentado na Figura 14 captura todos os registros (trâmites) da
tb_tramite0800 em uma estrutura de retorno da consulta (resultset) identificado como
“tramites”. Sobre este resultset então, é realizada uma iteração para recuperar e armazenar em
uma variável string temporária a descrição do trâmite, na sequência o método armazena as
posições desta descrição que contém o caractere “§”. Estes caracteres delimitam o início e o
final dos defeitos dentro da descrição do trâmite.
Neste ponto, o método já identifica os defeitos do trâmite, e então para cada defeito o
mesmo armazena as posições que contém o caractere “#”, os quais delimitam o início dos
detalhes do defeito. Detalhes do defeito são as características do defeito, como a natureza, a
criticidade e outros.
Neste ponto o método já possui a posição dos detalhes do defeito e então para cada
detalhe, é armazenado em uma estrutura de vetor (array) de duas posições o cabeçalho do
detalhe na posição 0 e a descrição do detalhe na posição 1.
O método então verifica qual é o detalhe do defeito e insere na variável
39
correspondente, até que acabem todos os detalhes. Ao final deste processo o método insere o
defeito na tabela tb_defeito e realiza o mesmo processo em todos os defeitos de todos os
trâmites.
Os processos de conversão de trâmites em defeitos e inserção de defeitos no Mantis
podem ser realizados pela ação do usuário, porém, estes já são realizados em tempo
programado pelo servidor. A Figura 15 apresenta a classe que implementa esta
funcionalidade.
Figura 15 – Classe de gerenciamento de tarefas
Nesta classe, foi criada uma tarefa que é executada a cada um minuto. O tempo
programado para execução é configurado na linha selecionada. Ao ser executada, a tarefa
exibe a mensagem Execução automatizada da integração, executa os métodos
converteDefeito() da classe defeito e integraMantis() da classe defeito e encerra a tarefa. Para
que o servidor execute esta tarefa, é necessário criar um listener no arquivo web.xml da
aplicação. A Figura 16 apresenta o trecho de código selecionado deste listener inserido no
arquivo web.xml.
40
Figura 16 – Arquivo web.xml com a inclusão do listener
Para criar este listener, é necessário somente adicionar a etiqueta (tag) selecionada na
Figura 18 no arquivo web.xml.
3.3.2 Operacionalidade da implementação
Esta subseção apresenta as telas do sistema, bem como as operações possíveis. O
sistema possui uma opção que permite ao usuário realizar as configurações de conexão com
as bases de dados necessárias, criação dos gatilhos de integração e integração manual dos
defeitos. Outras três opções permitem realizar consultas sobre os defeitos existentes.
A Figura 17 apresenta a tela de acesso ao sistema (login) da ferramenta. Pelo fato de
41
não haver a necessidade de um controle multi usuários, o sistema possui somente um usuário
de acesso. Caso o usuário ou a senha estejam incorretos o sistema apresenta uma mensagem
de falha no login. A Figura 18 apresenta a mensagem de falha de login.
Figura 17 – Tela de login da ferramenta de integração
Figura 18 – Falha de login na ferramenta
A ferramenta possui controle de sessão e uma sessão só é aberta quando o login é
validado, ou seja, o usuário não consegue acessar o sistema enquanto não realiza a validação
42
do login. Quando o usuário sai do sistema a sessão é destruída.
A Figura 19 apresenta a tela inicial da ferramenta.
Figura 19 – Tela inicial da ferramenta
A tela inicial é exibida no momento em que o sistema valida o login do usuário. Esta
não pertence a nenhuma parte dos processos da ferramenta. Outra tela que não pertence ao
processo é a tela de informações, apresentada na Figura 20.
Figura 20 – Tela de informações da ferramenta
A tela de informações apenas apresenta ao usuário informações gerais de como ocorre
43
o processo de integração, como funcionam as consultas e o local em que o projeto foi
aplicado.
A Figura 21 apresenta a tela de integração de dados. Nesta tela estão previstas três
etapas do processo, a configuração das conexões, a criação dos gatilhos de integração e a
integração de dados manualmente.
Figura 21 – Tela de integração de dados da ferramenta
Para realizar a configuração das conexões com o 0800net e Mantis, basta informar o
servidor, a base de dados, o usuário de acesso e a senha e clicar no botão gravar conexões. A
ferramenta irá salvar estas informações em banco de dados e sempre que realizar uma
conexão na base de dados do 0800net ou do Mantis, utilizará estas informações.
A Figura 22 apresenta a mensagem de gravação da configuração para conexões.
44
Figura 22 – Gravação da configuração de conexões com o 0800net e o Mantis
Para criar os gatilhos de integração na base de dados do 0800net, o usuário precisa
somente clicar no botão Criar Gatilho de Integração. A ferramenta irá verificar os dados para
conectar na base de dados do 0800net, criar os gatilhos e avisar o usuário que os gatilhos
foram criados com sucesso, como é apresentado na Figura 23.
Figura 23 – Mensagem de criação dos gatilhos de integração
A Figura 24 apresenta a mensagem de integração dos defeitos. Esta mensagem é
apresentada sempre que o usuário realiza a integração dos defeitos com o Mantis
45
manualmente. Quando o processo ocorre de forma automática, o sistema não apresenta a
mensagem.
Figura 24 – Mensagem de integração de defeitos realizada
Ao clicar no botão Integrar Defeitos, a ferramenta recupera os registros de trâmites,
converte para defeitos e os insere no Mantis. Para inserir no Mantis, a ferramenta recupera os
dados para conexão na base de dados do Mantis.
A Figura 25 apresenta uma consulta realizada na tabela de defeitos que exibe os
defeitos de um projeto.
Figura 25 – Consulta de defeitos
A consulta de dados apresentada acima retornou nove defeitos. Estes nove defeitos são
exibidos também no Mantis. A Figura 26 apresenta os defeitos deste projeto no Mantis.
46
Figura 26 – Apresentação dos defeitos no Mantis
Após realizar a integração dos defeitos, o usuário poderá visualizar por consulta
algumas informações úteis para tomada de decisão.
Na Figura 27 a ferramenta disponibiliza a consulta de eficácia na detecção de defeitos
(EDD). Esta consulta é uma métrica que exibe ao usuário a eficácia que houve da equipe em
detectar defeitos de acordo com os filtros selecionados. A consulta eficácia na detecção de
defeitos compara os defeitos encontrados pelo teste com os defeitos encontrados por clientes.
Cada defeito encontrado acrescenta pontos de acordo com sua classificação, defeitos
classificados como altos valem cinco pontos, os médios valem três pontos e os baixos um
ponto. A comparação acontece de acordo com a fórmula apresentada no Quadro 9.
Eficácia = Pontos do teste / (Pontos do teste + Pontos do cliente) * 100. O percentual ideal
varia de acordo com o projeto.
Quadro 9 - Fórmula para comparar defeitos encontrados pelo cliente e pelo teste
47
Figura 27 – Consulta de eficácia na detecção de defeitos
A consulta retornou a eficácia de 86% baseada nos defeitos encontrados por
criticidade x cliente x teste para o projeto selecionado. Cada projeto, dependendo da sua
abordagem e complexidade pode ter uma meta para o EDD maior ou menor. No exemplo
fictício, a eficácia é considerada boa sempre que alcançar um valor maior que 75%. Este valor
de 75% é considerado satisfatório na empresa Edusoft.
A Figura 28 apresenta a consulta de defeitos por criticidade x cliente x teste na base de
dados da ferramenta.
Figura 28 – Consulta de defeitos por criticidade x cliente x teste
A Figura 29 apresenta a consulta de tempo de resposta na detecção de defeitos.
48
Figura 29 – Consulta de tempo de resposta na correção de defeitos
A consulta de tempo de resposta na correção de defeitos avalia a data em que o defeito
foi registrado e a data programada para a liberação da versão do mesmo. Tendo esta diferença,
os defeitos são agrupados de acordo com sua criticidade e a consulta apresenta a média de
tempo por criticidade com um totalizador no final. No projeto pesquisado, os defeitos levaram
em média dezesseis dias desde seu registro, passando pela correção, testes e disponibilização
da correção aos clientes.
A ferramenta possui ainda a consulta de quantidade de defeitos encontrados. Esta
consulta exibe a quantidade de defeitos encontrados pela equipe e pelo cliente de acordo com
os filtros selecionados. A Figura 30 apresenta a consulta de quantidade de defeitos
encontrados.
49
Figura 30 – Consulta de quantidade de defeitos encontrados
3.4 RESULTADOS E DISCUSSÃO
Este trabalho conseguiu atender o seu objetivo principal que era fornecer suporte à
gestão de defeitos a partir da integração de dados entre as ferramentas 0800net e Mantis.
Desta forma o Mantis possui uma base de dados precisa com os defeitos encontrados, e estes
podem ser avaliados por diversas perspectivas. Pelo fato do Mantis ser uma ferramenta
altamente customizável muitas informações úteis podem ser extraídas para análise,
dependendo da forma com que o mesmo é utilizado.
Além da integração com o Mantis, a ferramenta possibilitou aos gerentes as consultas
personalizadas de quantidade de defeitos encontrados, tempo de resposta na correção de
defeitos e eficácia na detecção de defeitos e estas informações têm um grande valor aos
gerentes de projetos para a tomada de decisões.
Outros benefícios que a integração forneceu foram a eliminação da necessidade de
registrar defeitos em duas ferramentas, evitando assim o retrabalho e garantindo a integridade
dos defeitos existentes em ambas as ferramentas. Ou seja, os defeitos existem nas duas
ferramentas e com os mesmos dados.
50
O Quadro 10 apresenta um comparativo do processo com a utilização da ferramenta de
integração.
Item Sem integração Com integração
Lançamento de
defeitos no
0800net.
Todos os defeitos são
registrados no 0800net.
Todos os defeitos são registrados no
0800net.
Lançamento de
defeitos no
Mantis.
Todos os defeitos são
registrados no Mantis.
Não há necessidade de registrar
manualmente defeitos no Mantis.
Integridade dos
defeitos.
Parte dos defeitos registrados
no 0800net não são registrados
no Mantis corretamente.
100% dos defeitos registrados no
0800net são registrados no Mantis
com os dados corretos.
Informações
gerenciais
relacionadas a
defeitos.
Apenas informações bastante
claras ocasionadas pela
percepção humana.
Quantidade relevante de
informações vistas de diversas
formas.
Tomada de
decisões
relacionadas a
defeitos.
Apenas em casos de problemas
muito perceptíveis.
Decisões mais seguras, ainda em
pouca quantidade devido ao fato da
ferramenta estar em produção
pouco tempo.
Quadro 10 – Comparativo do processo com a integração
Não foi possível avaliar ainda se houve diminuição no esforço realizado, ou ainda
diminuição nos custos do projeto.
Foram realizados questionamentos dos gerentes de qualidade e projetos da empresa
sobre os benefícios que a ferramenta trouxe.
Conforme a gerente de qualidade, com a utilização da ferramenta nos projetos da
empresa, consegue-se trabalhar sobre as naturezas dos defeitos de forma pró-ativa e não
reativa, melhorando o planejamento e execução dos testes nas funcionalidades em que mais
ocorreram defeitos. A utilização da ferramenta também permite avaliar a qualidade do
produto e eficácia da equipe com relação aos erros encontrados internamente e pelo cliente e
permite por fim avaliar se as mudanças nos processos de desenvolvimento de software
refletiram em melhoria no produto. Estas situações são identificadas a partir de números.
Para o gerente de projetos da empresa, informações como quantidade de defeitos
encontrados e tempo de resposta na correção de defeitos, auxiliam a tornar mais clara a
51
questão planejar o escopo e cronograma do projeto, bem como ajudam a avaliar a
produtividade da equipe.
Como consequência dos resultados obtidos com a integração, alguns elementos do
ciclo de gestão de defeitos são melhores atendidos. Com uma melhor identificação das
características dos defeitos encontrados consegue-se melhorar a prevenção de defeitos,
consequentemente em alguns casos exigindo mudanças nos processos de desenvolvimento de
software a fim de adequá-los, caracterizando as mudanças como melhoria de processo.
Em relação ao trabalho de Waltrick (2011), as duas ferramentas realizam integração,
mas manipulam dados diferentes, porém ambas ocorrem pela base de dados. Quanto aos
objetivos, as duas conseguiram alcançá-los com sucesso, atendendo assim as necessidades
existentes.
Quanto ao trabalho desenvolvido por Labes (2010), o mesmo teve um foco diferente
deste trabalho, mas os benefícios alcançados são parecidos, pois ambos tiverem foco na
qualidade dos processos da empresa implantada.
52
4 CONCLUSÕES
Após o desenvolvimento do trabalho e a avaliação resultados obtidos, pode-se avaliar
como alcançados os objetivos deste trabalho. A ferramenta permite aos gerentes a análise da
informação gerada pela mesma, possibilitando a tomada de decisão mais segura, o que por si
só garante o sucesso do projeto. Embora só a ferramenta não resolva todos os problemas
relacionados ao processo de gestão de defeitos, o mesmo fornece suporte ao processo,
principalmente na etapa de relatórios de gestão, o que por sua vez abrange a todas as etapas
do processo.
Percebeu-se que com o aumento da complexidade dos softwares e da concorrência
entre as empresas, alcançar um nível de qualidade superior é sim uma vantagem competitiva
desejada por todas estas.
Quanto as dificuldades durante o projeto destacam-se duas, a forma de utilização do
Mantis e a forma de realizar a integração de dados. Primeiramente tentou-se utilizar o Mantis
com base de dados Sql Server, mas não obteve-se sucesso na instalação, resultando assim na
utilização do Mantis com base de dados MySQL. Após esta definição pôde-se definir a forma
de integração, não mais diretamente entre as bases de dados, mas passando pela base de dados
da ferramenta. Tentou-se programar a integração toda por gatilho, mas devido a alta
complexidade, mudou-se a leitura e conversão dos defeitos para ocorrer pelo Java, assim
resolvendo-se também esta dificuldade.
4.1 EXTENSÕES
Como sugestões para futuros trabalhos, a ferramenta poderá incluir novas
funcionalidades como a eliminação de um defeito, caso seja percebido pela equipe que o
mesmo trata-se de uma dúvida ou até mesmo que tenha sido registrado indevidamente. Outra
funcionalidade que poderá ser incluída na ferramenta é a integração de novos dados do defeito
caso seja necessário. Poderá ser desenvolvida também a opção de guardar históricos das
consultas realizadas para acompanhar a evolução nos projetos com relação aos defeitos.
Além das novas funcionalidades, novas consultas poderão ser desenvolvidas, inclusive
53
a exportação em forma de relatórios pdf.
54
REFERÊNCIAS BIBLIOGRÁFICAS
BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Campus, 2002.
BASTOS, Aderson. Base de conhecimento em teste de software. 2.ed.São Paulo: Martins, 2007
ELIZA, Renata; LAGARES, Vivian. Gestão de Defeitos no Teste de Software Java Magazine, Grajaú, n.94, p.68 – p.74 ago. 2011
ELLEVO. 0800net - Software help desk, service desk, software helpdesk, produto help desk, Blumenau, 2010. Disponível em: <http://www.ellevo.com.br/0800net/> Acessado em: 04 set. 2011.
KOSCIANSKI, André; Soares, Michel S. Qualidade de software. São Paulo: Novatec, 2006.
LABES, Camila. Teste-plan: ferramenta de apoio ao planejamento e controle das atividades do processo de testes. 2010, 107 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. Disponível em: <http://www.inf.furb.br/tcc/index.php?cd=11&tcc=1263> Acesso em: 07 set. 2011.
MANTISBT. Mantis Bug Tracker, [S.l.], 2011. Disponível em: <http://www.mantisbt.org/> Acessado em: 29 ago. 2011.
SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison Wesley, 2003
WALTRICK, Douglas O. Plugin da ferramenta TestComplete para integração com a ferramenta TestLink, 2011, 61 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. Disponível em: <http://www.inf.furb.br/tcc/index.php?cd=6&tcc=1382> Acesso em: 06 jun. 2012.
55
APÊNDICE A – Descrição do dicionário de dados
Os quadros de 11 a 14 apresentam o dicionário de dados das entidades que pertencem
a base de dados da ferramenta.
O Quadro 11 apresenta o dicionário de dados da entidade tb_conexao.
Entidade: tb_conexao
Atributo Tipo Descrição
con_id Int (PK) Código identificador do registro de conexões.
con_servidor0800 Varchar(45) Caminho do servidor + porta em que se encontra a base de
dados do 0800net.
con_base0800 Varchar(45) Nome da base de dados do 0800net.
con_servidormantis Varchar(45) Caminho do servidor + porta em que se encontra a base de
dados do Mantis.
con_basemantis Varchar(45) Nome da base de dados do Mantis.
con_usuario0800 Varchar(45) Usuário para acesso ao servidor do 0800net.
con_senha0800 Varchar(45) Senha de acesso ao servidor do 0800net.
con_usuariomantis Varchar(45) Usuário para acesso ao servidor do Mantis.
con_senhamantis Varchar(45) Senha de acesso ao servidor do Mantis.
Quadro 11 – Dicionário de dados da entidade tb_conexao
O Quadro 12 apresenta o dicionário de dados da entidade tb_tramite0800.
Entidade: tb_tramite0800
Atributo Tipo Descrição
tra_id Int (PK) Código identificador do registro.
tra_titulo Varchar(255) Título da tarefa no 0800net.
tra_descricao Text Descrição da tarefa ou do trâmite da tarefa no 0800net.
tra_projeto Varchar(255) Projeto no qual a tarefa está vinculada.
tra_versaolib Varchar(255) Versão de liberação no qual a tarefa está vinculada.
tra_dataversaolib Date Data programada para liberação da versão no qual a tarefa
está vinculada.
tra_datareg Date Data em que a tarefa ou trâmite foi registrada.
tra_usuario Varchar(255) Usuário que registrou a tarefa ou trâmite.
Quadro 12 – Dicionário de dados da entidade tb_tramite0800
56
O Quadro 13 apresenta o dicionário de dados da entidade tb_tramite0800.
Entidade: tb_tramite_falha
Atributo Tipo Descrição
tfa_id Int (PK) Código identificador do trâmite com falha.
tfa_titulotarefa Varchar(255) Título da tarefa no 0800net que possui a falha.
tfa_registro_falha Varchar(255) Descrição da tarefa ou do trâmite da tarefa com falha.
tfa_projeto Varchar(255) Projeto no qual a tarefa está vinculada.
tfa_versaolib Varchar(255) Versão de liberação no qual a tarefa está vinculada.
tfa_usuario Varchar(45) Usuário que registrou a tarefa ou trâmite com falha.
Quadro 13 – Dicionário de dados da entidade tb_tramite_falha
O Quadro 14 apresenta o dicionário de dados da entidade tb_defeito.
Entidade: tb_defeito
Atributo Tipo Descrição
def_id Int (PK) Código identificador do defeito.
def_titulo Varchar(255) Título do defeito.
def_descricao Text Descrição do defeito.
def_natureza Varchar(45) Natureza do defeito.
def_criticidade Varchar(45) Criticidade do defeito.
def_projeto Varchar(45) Projeto em que a tarefa do defeito está vinculada.
def_versaolib Varchar(45) Versão de liberação em que a tarefa do defeito está
vinculada.
def_usuario Varchar(45) Usuário que registrou o defeito na tarefa.
def_codrel Varchar(45) Código do relatório em que o defeito ocorreu, caso
tenha ocorrido em relatório.
def_datareg Date Data em que o defeito foi registrado na tarefa ou
trâmite.
def_datalib Date Data da versão de liberação em que a tarefa do defeito
está vinculada.
def_interno Varchar(45) Valor informado no defeito. Será S caso o defeito
tenha sido encontrado pelo Teste e N caso o mesmo
tenha sido encontrado pelo cliente.
57
def_integrado Int Valor 0 enquanto o defeito não estiver integrado com o
Mantis. Quando o defeito for integrado com o Mantis
o valor passa a ser 1.
Quadro 14 - Dicionário de dados da entidade tb_defeito
Os quadros de 15 a 18 apresentam o dicionário de dados das entidades que pertencem
à base de dados do 0800net e estão envolvidas no processo de integração.
O Quadro 15 apresenta o dicionário de dados da entidade usuario.
Entidade: Usuario
Atributo Tipo Descrição
UsuID Int (PK) Código identificador do usuário.
usunome Varchar Nome do usuário cadastrado no 0800net.
Quadro 15 - Dicionário de dados da entidade usuario
O Quadro 16 apresenta o dicionário de dados da entidade TipoVersao.
Entidade: TipoVersao
Atributo Tipo Descrição
VerID Int (PK) Código identificador da versão.
ProID Int (FK) Código identificador do produto.
VersaoL Varchar Descrição da versão de liberação.
VerDataRealLib Datetime Data programada para a liberação da versão.
Quadro 16 - Dicionário de dados da entidade TipoVersao
O Quadro 17 apresenta o dicionário de dados da entidade Tarefa.
Entidade: Tarefa
Atributo Tipo Descrição
TarID Int (PK) Código identificador da tarefa.
ProID Int (FK) Código identificador de vínculo do produto.
VerID Int (FK) Código identificador de vínculo da versão.
UsuID Int (FK) Código identificador de vínculo do usuário.
TarTitulo Varchar Título da tarefa.
TarDescricao Varchar Descrição da tarefa. Contém dados do defeito como o título, a
descrição, a natureza e a criticidade, se o defeito é interno e o
código do relatório.
Projeto Varchar Projeto que a tarefa está vinculada.
58
TarData Datetime Data de registro da tarefa.
Quadro 17 - Dicionário de dados da entidade Tarefa
O Quadro 18 apresenta o dicionário de dados da entidade Atividade.
Entidade: Atividade
Atributo Tipo Descrição
AtivID Int (PK) Código identificador da atividade (trâmite da tarefa).
TarID Int (FK) Código identificador de vínculo da tarefa.
ativData Datetime Data de registro da atividade (trâmite da tarefa).
ativDescricao Varchar Descrição da atividade (trâmite da tarefa).
Quadro 18 - Dicionário de dados da entidade Atividade
Os quadros de 19 a 22 apresentam o dicionário de dados das entidades que pertencem
à base de dados do Mantis e estão envolvidas no processo de integração.
O Quadro 19 apresenta o dicionário de dados da entidade Mantis_project_table.
Entidade: Mantis_project_table
Atributo Tipo Descrição
Id Int (PK) Código identificador do projeto.
Name Varchar Nome do projeto da tarefa do defeito integrado.
Quadro 19 - Dicionário de dados da entidade Mantis_project_table
O Quadro 20 apresenta o dicionário de dados da entidade Mantis_user_table.
Entidade: Mantis_user_table
Atributo Tipo Descrição
Id Int (PK) Código identificador do usuário.
username Varchar Nome do usuário que registrou a tarefa do defeito integrado.
Quadro 20 - Dicionário de dados da entidade Mantis_user_table
O Quadro 21 apresenta o dicionário de dados da entidade Mantis_bug_text_table.
Entidade: Mantis_bug_text_table
Atributo Tipo Descrição
Id Int (PK) Código identificador da descrição do defeito.
description Longtext Descrição do defeito integrado.
Quadro 21 - Dicionário de dados da entidade Mantis_bug_text_table
O Quadro 22 apresenta o dicionário de dados da entidade Mantis_bug_table.
Entidade: Mantis_bug_table
Atributo Tipo Descrição
59
Id Int (PK) Código identificador do defeito.
project_id Int (FK) Código identificador de vínculo do projeto da tarefa do defeito
integrado.
bug_text_id Int (FK) Código identificador de vínculo da descrição do defeito
integrado.
repórter_id Int (FK) Código identificador de vínculo do usuário que registrou a tarefa
do defeito integrado.
summary Varchar Título do defeito integrado.
Quadro 22 - Dicionário de dados da entidade Mantis_bug_table