Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Alexis da Rocha Silva
Classificação de defeitos de software usando ODC: um estudo de caso para uma linha de produtos de software
São Paulo
2013
Alexis da Rocha Silva
Classificação de defeitos de software usando ODC: um estudo de caso para uma linha de produtos de software
Dissertação de Mestrado apresentada ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo – IPT, como parte dos requisitos para a obtenção do título de Mestre em Engenharia da Computação. Data de aprovação ___/___/______ __________________________________ Prof. Dr. Mário Yoshikazu Miyake (Orientador) IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Membros da Banca Examinadora: Prof. Dr. Mário Yoshikazu Miyake (Orientador) IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo Profa. Dra. Elisa Yumi Nakagawa (Membro) USP – Universidade de São Paulo - São Carlos Prof. Dr. Paulo Sérgio Muniz (Membro) IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Alexis da Rocha Silva
Classificação de defeitos de software usando ODC: um estudo de caso para uma linha de produtos de software
Dissertação de Mestrado apresentada ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo – IPT, como parte dos requisitos para a obtenção do título de Mestre em Engenharia da Computação. Área de Concentração: Engenharia de Software Orientador: Prof. Dr. Mário Miyake
São Paulo Agosto/2013
Ficha Catalográfica Elaborada pelo Departamento de Acervo e Informação Tecnológica – DAIT do Instituto de Pesquisas Tecnológicas do Estado de São Paulo - IPT
S586c Silva, Alexis da Rocha Classificação de defeitos de software usando ODC: um estudo de caso para uma linha de produtos de software. / Alexis da Rocha Silva. São Paulo, 2013.
145p. Dissertação (Mestrado em Engenharia de Computação) - Instituto de Pesquisas
Tecnológicas do Estado de São Paulo. Área de concentração: Engenharia de Software.
Orientador: Prof. Dr. Mário Yoshikazu Miyake
1. Linha de produto 2. Produto de software 3. Defeito 4. ODC (Orthogonal Defect Classification) 5. Tese I. Miyake, Mário Yoshikazu, orient. II. IPT. Coordenadoria de Ensino Tecnológico III. Título 13-57 CDU 004.052.42
AGRADECIMENTO
Agradeço, primeiramente, à Deus por me dar forças todos os dias para continuar minha caminhada.
Agradeço aos professores e funcionários do IPT pelo constante auxílio, disposição e atenção.
Agradeço aos membros da banca, a Profa. Dra. Elisa Yumi Nakagawa, o Prof. Dr. Paulo Sérgio Muniz e o Prof. Dr. Mário Miyake, pela disponibilidade e pelas preciosas dicas para melhorar este trabalho.
Agradeço ao Prof. Dr. Mário Miyake pela orientação, por compartilhar o seu conhecimento e por saber dosar a minha ansiedade em terminar o trabalho.
Agradeço à empresa onde trabalho, aos meus gerentes e colegas pelo apoio, pelo compartilhamento de conhecimento e pela ajuda em todos os momentos solicitados.
Agradeço à minha família e aos meus amigos. Mesmo distante, vocês são a base de tudo e têm uma parcela importante nessa conquista. Aqui, faço um agradecimento especial aos meus sogros pelo incentivo e pela compreensão e ao meu cunhado pela força e por ter compartilhado esse sonho comigo desde o início.
Agradeço aos meus pais, Pedro Maurício e Clarice, por serem meus grandes exemplos de honestidade, integridade e persistência. Com vocês, aprendi que o trabalho, seja ele qual for, quando é feito com amor e honestidade, sempre é recompensado. A criação que vocês dois me deram foi o maior presente que um filho poderia receber dos seus pais. Amo vocês.
Enfim, agradeço à minha esposa, Tatiana, pelo seu companheirismo, por sua inesgotável paciência e por sempre saber dizer a palavra certa nos meus momentos de frustração e desespero. Você é o maior exemplo de pessoa resiliente e que consegue superar momentos difíceis e seguir em frente sem perder a sua essência. Se eu consegui terminar esta dissertação e o mestrado é porque me inspirei em você em todas os momentos em que tive vontade de desistir. Sem você, eu nunca teria conseguido e a minha caminhada nunca seria completa. Te amo.
RESUMO
Linhas de produtos de software desenvolvidas em curtos espaços de tempo e sem se seguir um processo específico para o desenvolvimento de linhas de produtos servem de motivação para este trabalho. Nessas linhas de produtos, a realização das tarefas de manutenção é de difícil análise, implementação e implantação. As equipes de desenvolvimento não têm segurança em realizar modificações ou melhorias, pois fica muito difícil prever o seu impacto. O cenário descrito leva a correções de defeitos que podem não corrigir o problema ou gerar efeitos colaterais, ou a desenvolvimentos de novas funcionalidades que tornam o ambiente instável ou não atendem aos requisitos. O objetivo do trabalho é analisar os defeitos encontrados em uma linha de produtos de software com base nos critérios definidos pelo método ODC (Orthogonal Defect Classification) e nas variáveis e estrutura do repositório de dados no qual eles se encontram. Com essa análise, espera-se obter padrões de defeitos que possam auxiliar na identificação e análise dos problemas relacionados à manutenção em linhas de produtos de software. Esses padrões de defeitos também auxiliarão na formulação de propostas de tarefas de manutenção para se enfrentar esses problemas. Para tanto: a estrutura da base de dados de defeitos será descrita e detalhada; os critérios que serão efetivamente usados para a obtenção dos padrões de defeitos serão selecionados; as consultas usadas para se extrair as informações relativas aos defeitos cadastrados serão montadas e executadas; os resultados serão analisados para se obter padrões de defeitos que possam ajudar no entendimento dos problemas; esses padrões de defeitos serão mapeados para partes do processo que necessitem revisão; tarefas de manutenção para se enfrentar os problemas serão propostas e aplicadas e será verificado se houve ou não melhora no cenário descrito anteriormente. Palavras-chave: Linha de produto de software, ODC, classificação de defeitos, padrões de defeitos, manutenção em linha de produto de software.
ABSTRACT
Software defect classification using ODC: a case study for a software product line
Software product lines that were developed in a short time frame and without following any specific process for the development of a software product line are the motivation for this dissertation. On this kind of product lines, the accomplishment of the maintenance activities have difficult analysis and implementation. The development teams do not have the certainty in making any changes to the system, because it is too difficult to predict any side effects. The scenario just described leads to defect fixes that may not fix the actual problem or that may lead to side effects, or to the development of new functionalities that turn the environment to be unstable or that do not implement the requirements. The goal of this dissertation is to analyze the defects found in a software product line based in the criteria defined in the ODC (Orthogonal Defect Classification) method and in the variables and the structure of the defect repository where they are recorded. With this analysis, it is hoped to obtain some defect patterns that will help in identifying and analysing the software product line maintenance problems. These defect patterns will also help in the proposition of some maintenance tasks to deal with these problems. To accomplish this: the structure of the defect data base will be described and detailed; the criteria that will be used to obtain the defect patterns will be selected; the queries that will be used to extract information related to the defects will be built and executed; the results will be analyzed to obtain defect patterns that will help in understanding the maintenance problems; these patters will be mapped to the parts of the development process that need revision; maintenance tasks to deal with the problems will be proposed and it will be verified if the scenario described before got better after applying the maintenance tasks proposed. Key Words: Software product line, ODC, defect classification, defect patterns, software product lines maintenance.
Lista de Ilustrações Figura 1 - Atividades Essenciais para o desenvolvimento de linhas de produtos de
software ........................................................................................................................... 15
Lista de Tabelas
Tabela 1 - Critérios da base de dados de defeitos ........................................................... 29 Tabela 2 - Critérios ODC da base de dados de defeito ................................................... 31 Tabela 3 - Detalhamento das principais hipóteses de problemas ................................. 34 Tabela 4 - Interação entre critérios da base e hipóteses ................................................ 38 Tabela 5 - Matriz de Congruência Normalizada por Tipo de Defeito ............................ 42 Tabela 6 - Matriz de Congurência Normalizada por Tipo de Defeito - Probabilidade
por Gatilho e Tipo .......................................................................................................... 42 Tabela 7 - Consultas da hipótese 1 .................................................................................... 44 Tabela 8 - Consultas da hipótese 2 .................................................................................... 45 Tabela 9 - Consultas da hipótese 3 .................................................................................... 46 Tabela 10 - Consultas da hipótese 4 .................................................................................. 47 Tabela 11 - Consultas da hipótese 5 .................................................................................. 48 Tabela 12 - Consultas da hipótese 6 .................................................................................. 49 Tabela 13 - Consultas hipótese 7 ........................................................................................ 50 Tabela 14 - Consultas da hipótese 8 .................................................................................. 52 Tabela 15 - Consultas da hipótese 9 .................................................................................. 53 Tabela 16 - Consultas da hipótese 10 ................................................................................ 53 Tabela 17 - Consultas da hipótese 11 ................................................................................ 54 Tabela 18 - Consultas da hipótese 12 ................................................................................ 55 Tabela 19 - Matriz de Congruência - Valores absolutos da distribuição de defeitos .. 59 Tabela 20 - Matriz de Congruência – Valores relativos da distribuição de defeitos ... 60 Tabela 21 – Defeitos por Severidade ................................................................................. 61 Tabela 22 – Defeitos Descobertos em Clientes por Severidade ................................... 61 Tabela 23 – Defeitos por Produto ....................................................................................... 62 Tabela 24 – Defeitos Descobertos em Cliente por Produto ........................................... 63 Tabela 25 – Defeitos por Produto e Severidade ............................................................... 64 Tabela 26 – Defeitos Descobertos em Cliente por Produto e Severidade ................... 64 Tabela 27 – Defeitos do Produto Núcleo por Versão e Severidade .............................. 65 Tabela 28 - Resultados da consulta 1.1 ............................................................................. 67 Tabela 29 - Resultados da consulta 1.2 ............................................................................. 67 Tabela 30 - Resultados da consulta 1.3 ............................................................................. 68 Tabela 31 - Resultados da consulta 1.4 ............................................................................. 69 Tabela 32 - Resultados da consulta 1.5 ............................................................................. 69 Tabela 33 - Resultados da consulta 1.6 ............................................................................. 70 Tabela 34 - Resultados da consulta 1.7 ............................................................................. 71 Tabela 35 - Resultados da consulta 1.8 ............................................................................. 71 Tabela 36 - Resultados da consulta 2.1 ............................................................................. 73 Tabela 37 - Resultados da consulta 2.2 ............................................................................. 74 Tabela 38 - Resultados da consulta 2.3 ............................................................................. 75 Tabela 39 - Resultados da consulta 2.4 ............................................................................. 75 Tabela 40 - Resultados da consulta 3.1 ............................................................................. 77 Tabela 41 - Resultados da consulta 3.2 ............................................................................. 77 Tabela 42 - Resultados da consulta 3.3 ............................................................................. 78 Tabela 43 - Resultados da consulta 3.4 ............................................................................. 79 Tabela 44 - Resultados da consulta 3.5 ............................................................................. 80 Tabela 45 - Resultados da consulta 3.6 ............................................................................. 81
Tabela 46 - Resultados da consulta 4.1 ............................................................................. 82 Tabela 47 - Resultados da consulta 4.2 ............................................................................. 83 Tabela 48 - Resultados da consulta 4.3 ............................................................................. 83 Tabela 49 - Resultados da consulta 4.4 ............................................................................. 84 Tabela 50 - Resultados da consulta 4.5 ............................................................................. 85 Tabela 51 - Resultados da consulta 4.6 ............................................................................. 85 Tabela 52 - Resultados da consulta 5.1 ............................................................................. 87 Tabela 53 - Resultados da consulta 5.2 ............................................................................. 88 Tabela 54 - Resultados da consulta 5.3 ............................................................................. 88 Tabela 55 - Resultados da consulta 5.4 ............................................................................. 89 Tabela 56 - Resultados da consulta 6.1 ............................................................................. 91 Tabela 57 - Resultados da consulta 6.2 ............................................................................. 91 Tabela 58 - Resultados da consulta 6.3 ............................................................................. 92 Tabela 59 - Resultados da consulta 6.4 ............................................................................. 93 Tabela 60 - Resultados da consulta 6.5 ............................................................................. 93 Tabela 61 - Resultados da consulta 6.6 ............................................................................. 94 Tabela 62 - Resultados da consulta 7.1 ............................................................................. 95 Tabela 63 - Resultados da consulta 7.2 ............................................................................. 96 Tabela 64 - Resultados da consulta 7.3 ............................................................................. 97 Tabela 65 - Resultados da consulta 7.4 ............................................................................. 97 Tabela 66 - Resultados da consulta 7.5 ............................................................................. 98 Tabela 67 - Resultados da consulta 7.6 ............................................................................. 99 Tabela 68 - Resultados da consulta 7.7 ............................................................................. 99 Tabela 69 - Resultados da consulta 8.1 ........................................................................... 101 Tabela 70 - Resultados da consulta 8.2 ........................................................................... 102 Tabela 71 - Resultados da consulta 8.3 ........................................................................... 102 Tabela 72 - Resultados da consulta 8.4 ........................................................................... 103 Tabela 73 - Resultados da consulta 8.5 ........................................................................... 104 Tabela 74 - Resultados da consulta 8.6 ........................................................................... 104 Tabela 75 - Resultados da consulta 9.1 ........................................................................... 106 Tabela 76 - Resultados da consulta 9.2 ........................................................................... 107 Tabela 77 - Resultados da consulta 10.1 ........................................................................ 108 Tabela 78 - Resultados da consulta 10.2 ........................................................................ 108 Tabela 79 - Resultados da consulta 10.3 ........................................................................ 109 Tabela 80 - Resultados da consulta 10.4 ........................................................................ 110 Tabela 81 - Resultados da consulta 11.1 ........................................................................ 111 Tabela 82 - Resultados da consulta 11.2 ........................................................................ 112 Tabela 83 - Resultados da consulta 12.1 ........................................................................ 113 Tabela 84 - Resultados da consulta 12.2 ........................................................................ 114 Tabela 85 - Resultados da consulta 12.3 ........................................................................ 114 Tabela 86 - Resultados da consulta 12.4 ........................................................................ 115 Tabela 87 - Consultas da hipótese 5 ................................................................................ 138 Tabela 88 - Consultas da hipótese 7 ................................................................................ 139
Lista de Abreviaturas e Siglas
ALG ATR APAR AutoODC
Algoritmo Atribuição Authorized Program Analysis Report Automated Generation of Orthogonal Defect Classifications
BLD Build CHC COPLIMO CVT
Checagem Constructive Product Line Investment Model Component Verification Test
DOC FUN IBM
Documentação Função International Business Machine
INT Integração SER SVT UT
Serialização System Verification Test Unit Test
SUMÁRIO
1 INTRODUÇÃO ...................................................................................................... 6 1.1 Motivação ......................................................................................................... 6
1.2 Objetivo ............................................................................................................ 8
1.3 Contribuições ................................................................................................... 9
1.4 Método de Trabalho ......................................................................................... 9
1.4.1 Levantamento e análise da literatura. ..................................................... 10
1.4.2 Descrição e detalhamento da estrutura da base de dados de defeitos. . 10
1.4.3 Levantamento das informações de defeitos da base de dados. ............. 10
1.4.4 Análise dos resultados para se descobrir padrões de defeitos. .............. 11
1.4.5 Estabelecimento de um mapeamento entre os padrões de defeitos e o
processo de desenvolvimento e manutenção da linha de produtos. ................ 11
1.4.6 Proposição de tarefas de manutenção. ................................................... 12
1.5 Organização de Trabalho ............................................................................ 12
2 ESTADO DA ARTE ............................................................................................. 14 2.1 Introdução ...................................................................................................... 14
2.2 Linha de Produtos de Software ...................................................................... 14
2.3 Uso de informações de defeitos de software na manutenção e o método
Orthogonal Defect Classification (ODC) ................................................................ 20
2.4 Conclusão ...................................................................................................... 27
3 PLANEJAMENTO DAS CONSULTAS PARA VALIDAÇÃO DAS HIPÓTESES 28 3.1 Introdução ...................................................................................................... 28
3.2 Estrutura da base ........................................................................................... 28
3.3 Seleção dos Critérios da Base de Dados de Defeitos ................................... 31
3.4 Avaliação da Qualidade dos Dados ............................................................... 38
3.5 Montagem das Consultas .............................................................................. 43
3.6 Conclusão ...................................................................................................... 55
4 EXECUÇÃO DAS CONSULTAS ........................................................................ 57 4.1 Introdução ...................................................................................................... 57
4.2 Testes - Qualidade de Dados ........................................................................ 57
4.3 Consultas Gerais na Base ............................................................................. 61
4.4 Consultas por hipótese de problema ............................................................. 66
4.4.1 Hipótese 1 ................................................................................................ 66
4.4.2 Hipótese 2 ................................................................................................ 73
4.4.3 Hipótese 3 ................................................................................................ 77
4.4.4 Hipótese 4 ................................................................................................ 82
4.4.5 Hipótese 5 ................................................................................................ 87
4.4.6 Hipótese 6 ................................................................................................ 90
4.4.7 Hipótese 7 ................................................................................................ 95
4.4.8 Hipótese 8 .............................................................................................. 101
4.4.9 Hipótese 9 .............................................................................................. 106
4.4.10 Hipótese 10 .......................................................................................... 108
4.4.11 Hipótese 11 .......................................................................................... 111
4.4.12 Hipótese 12 .......................................................................................... 113
4.5 Conclusão .................................................................................................... 116
5 VALIDAÇÃO DAS ANÁLISES DOS RESULTADOS ....................................... 117 5.1 Validação das análises por especialista ...................................................... 117
5.1.1 Especialista 1 ......................................................................................... 117
5.1.2 Especialista 2 ......................................................................................... 118
5.1.3 Especialista 3 ......................................................................................... 119
5.2 Conclusão .................................................................................................... 120
6 ELABORAÇÃO DE PROPOSTAS DE TAREFAS DE MANUTENÇÃO .......... 121 6.1 Propostas relacionados aos testes ................................................................ 121
6.1.1 A revisão do processo de escrita dos casos de teste da bateria de testes
de verificação de componentes (CVT). ........................................................... 121
6.1.2 A revisão do processo de escrita dos casos de teste da bateria de testes
de verificação de sistema. ............................................................................... 122
6.1.3 A revisão do processo de escrita do código dos testes de unidade para
casos de teste simples e complexos. .............................................................. 123
6.2 Propostas relacionados ao desenvolvimento ................................................. 124
6.2.1 O aumento do detalhamento do projeto de baixo nível. ........................ 124
6.2.2 A criação de reuniões de revisão ou inspeção do projeto de baixo nível
com os desenvolvedores. ............................................................................... 124
6.2.3 O aumento da frequência de acontecimento das reuniões de revisão de
código entre os desenvolvedores e o líder técnico do time. ........................... 125
6.2.4 A inclusão de um treinamento para os líderes dos times de
desenvolvimento e de testes sobre a configuração do scripts de geração
automática de builds para que estes possam dar manutenção nestes scripts
caso necessário. ............................................................................................. 125
6.2.5 A revisão do uso, por parte dos desenvolvedores, no código, de
bibliotecas externas para se habilitar o mesmo a tratar de forma automática o
uso de mais de um idioma na aplicação e a tradução de termos e palavras
entre estes idiomas. ........................................................................................ 126
6.3 Propostas sugeridas pelos especialistas ...................................................... 127
6.3.1 Adição de uma reunião de demonstração da funcionalidade pronta, para
o gerente de produto, antes do término do ciclo de desenvolvimento, para
garantir aderência da funcionalidade à especificação de requisitos. .............. 127
6.3.2 A revisão de todos os defeitos abertos por clientes, antes que os
mesmos comecem a ser corrigidos, pelos gerentes do produto ou pelo líder
técnico de desenvolvimento, para garantir que os mesmos são defeitos. ...... 127
6.3.3 A construção de um documento de boas práticas de codificação pelos
líderes de desenvolvimento, baseado nos principais erros encontrados. ....... 128
6.4 Conclusão .................................................................................................... 128
7 CONCLUSÃO .................................................................................................... 130 7.1 Resumo ........................................................................................................ 130
7.2 Contribuições ............................................................................................... 131
7.3 Trabalhos futuros ......................................................................................... 132
REFERÊNCIAS ....................................................................................................... 133 APÊNDICES ............................................................................................................ 137 APÊNDICE A – HIPÓTESES DE PROBLEMAS ORIGINAIS RETIRADAS APÓS AVALIAÇÃO DOS ESPECIALISTAS. .................................................................... 137
6 1 INTRODUÇÃO
1.1 Motivação
A participação em uma equipe de desenvolvimento de uma linha de produtos de
software foi determinante para a escolha desse objeto de estudo. Essa linha de
produto de software é composta por um software base e vários produtos específicos,
cada um, desenvolvido para um determinado ramo empresarial. Uma linha de
produtos de software pode ser definida como um conjunto de sistemas de software
que compartilham um conjunto controlado de funcionalidades e que satisfaçam às
necessidades de um segmento de negócio específico. Geralmente, são
desenvolvidos a partir de um conjunto comum de componentes seguindo um roteiro
pré-definido (Northrop, 2002).
No início do ciclo de vida dessa linha de produtos de software, existia apenas o
software base. O aumento da base instalada e o grande número de personalizações
realizadas para atender às necessidades dos clientes levaram ao entendimento de
que clientes atuando em um mesmo ramo industrial necessitavam de
personalizações semelhantes. Isso levou à criação das chamadas soluções verticais
industriais e, para cada uma delas, a criação de software específico, com a adição
das personalizações pedidas pelos clientes daquele determinado ramo de indústria.
Esse processo levou à criação de uma linha de produto de software que foi feita
em um curto espaço de tempo para que não se perdesse mercado. Muitas
mudanças no projeto e na arquitetura, tanto no software base quanto nos
específicos, que seriam necessárias para uma adequação à criação da linha e a
consequente adição de novos produtos, não foram feitas ou não seguiram nenhum
processo de software específico para o desenvolvimento de uma linha de produtos.
Segundo Riva e Del Rosso (2003), linhas de produtos de software quase nunca
são criadas seguindo um processo de desenvolvimento específico para elas.
Geralmente, inicia-se com um ou com poucos produtos e, quando o negócio se torna
maduro e começa a gerar lucro, novos produtos são adicionados. Esses novos
produtos, tipicamente, são versões copiadas dos produtos já existentes com a
adição de novas funcionalidades.
7
A falta do uso de um processo específico para o desenvolvimento da linha de
produto, objeto de estudo deste trabalho, pode ser evidenciada pela repetição de
elementos de código em vários produtos da linha (Esses produtos foram criados
com base na cópia das funcionalidades de outros produtos já existentes,
adicionando apenas as novas funcionalidades.) e pela não existência de uma fase
para a identificação dos elementos comuns a vários produtos e que deveriam ser
migrados para o software base.
O cenário descrito no parágrafo anterior somado à falta da aplicação de um
processo de manutenção de software específico para linhas de produto de software
fazem com que as manutenções realizadas nos produtos da linha, sejam elas
corretivas ou evolutivas, sejam de difícil análise, implementação e implantação, pois
para as equipes de desenvolvimento fica muito difícil fazer algum tipo de alteração
ou melhoria com a segurança de que as mesmas não irão gerar impacto.
Com isso, o código, o projeto e as decisões arquiteturais das correções e das
novas funcionalidades são feitos sem uma análise de impacto em outras partes do
produto e em outros produtos da linha. Isso leva a correções de defeitos que podem
não corrigir o problema ou gerar efeitos colaterais, ou ainda a desenvolvimentos de
novas funcionalidades que tornam o ambiente instável, que atrapalham
funcionalidades que funcionavam ou que não atendem aos requisitos. Logo, os
produtos que compõem essa linha de produto de software sofrem uma degradação
constante e a própria realização da tarefa de manutenção torna-se uma atividade
complexa, ineficiente e custosa.
Segundo Dhungana et al (2008), tarefas de manutenção e evolução estão entre
as mais desafiadoras e custosas na engenharia de software. Com relação à linha de
produto de software, essas tarefas são ainda mais críticas devido ao tamanho, à
complexidade e a longevidade desses sistemas. Para se manter e evoluir esses
sistemas, deve-se enfrentar diferentes tipos de modificações causadas por
mudanças nas necessidades dos clientes, evolução tecnológica ou
desenvolvimentos mercadológicos.
Embora haja na literatura vários trabalhos relacionados ao processo de
desenvolvimento de linhas de produto de software como Northrop e Clements
(2011); às práticas e estratégias relacionadas a linhas de produto de software como
McGregor et. al (2010); aos modelos arquiteturais para o desenvolvimento de linhas
de produtos de software como em Chaudhary, Verma e Raheja (2010) e à
8 verificação de conformidade de produtos em uma linha de produtos como em Lutz
(2008), poucos trabalhos foram encontrados relacionados à manutenção e evolução
em linhas de produtos de software. “Despite its importance surprisingly few papers
are available on product line evolution.“ (DHUNGANA; NEUMAYER;
GRUNBACHER; RABISER; 2008, p.319).
Os trabalhos existentes relacionados à manutenção e evolução em linhas de
produtos vêm enfrentando esse problema tratando melhor a modelagem como em
Dhungana et al (2008), ou tratando com avaliação e reconstrução arquitetural como
Riva e Del Rosso (2003), ou usando simulação para facilitar decisões sobre o
desenvolvimento e a manutenção dos produtos, como em Chen et al (2004), ou
ainda, usando técnicas de mineração de dados para facilitar e descobrir padrões de
reúso e defeitos escondidos como em Jiang et al (2008).
Entretanto, trabalhos relacionados a defeitos encontrados em linhas de produtos
de software, bem como sua classificação e análise, usando um método formal e
estabelecido como o ODC (Orthogonal Defect Classification), para auxiliar na
melhoria das tarefas de manutenção desses mesmos produtos não foram
encontrados. Segundo He et al (2009), o ODC é um método que usa uma série de
atributos ortogonais, como atividade, gatilho, impacto, alvo, tipo do defeito,
qualificador do defeito, fonte e idade, para a classificação e a análise de um defeito.
Usando esses atributos e seus valores, um defeito pode ser classificado como um
ponto no espaço de coordenadas cartesianas.
1.2 Objetivo
O objetivo do trabalho a ser desenvolvido é analisar os defeitos encontrados em
uma linha de produtos de software com base nos critérios definidos pelo método
ODC e nas variáveis e estrutura do repositório de dados no qual esses defeitos se
encontram presentes. Esse repositório conta, atualmente, com aproximadamente
150 mil registros de defeitos classificados de acordo com o ODC para os produtos
da linha de produtos em questão. Com essa análise, espera-se obter padrões de
defeitos que possam auxiliar na identificação e análise dos problemas relacionados
à manutenção corretiva e evolutiva em uma linha de produtos de software, bem
9 como na formulação de propostas de tarefas de manutenção para se enfrentar
esses problemas.
1.3 Contribuições
Esse trabalho tem como contribuição uma abordagem que usa informações
sobre defeitos encontrados em uma linha de produtos de software para se propor
tarefas de manutenção para esta linha de produtos.
Essa abordagem difere de outras apresentadas para tratar dos problemas
relacionados à manutenção e evolução em linhas de produtos, como a apresentada
por Riva e Del Rosso (2003), que propõem uma mudança na arquitetura das linhas
ou como a apresentada por Jiang et al (2008), que propõe o uso de técnicas de
mineração de dados para descobrir padrões de códigos que possuam defeitos
escondidos ou, ainda, como a apresentada por Chen et al (2004) que usa de
simulação para facilitar decisões sobre a manutenção dos produtos.
A abordagem proposta difere das mencionadas anteriormente, pois baseia-se em
análises feitas sobre informações relativas aos defeitos encontrados na linha de
produtos, com base nos critérios do método ODC. Essas análises visam descobrir
padrões de defeitos que possam ser mapeados para as partes do processo que
deixaram escapar esses defeitos e que necessitam de revisão. Logo, as tarefas de
manutenção serão propostas com base em informações históricas de defeitos dos
produtos da linha, o que pode fazer com que a aplicação dessas propostas tenha
mais chance de diminuir os problemas mencionados na motivação desse trabalho.
1.4 Método de Trabalho
O estudo de caso a ser apresentado no trabalho em questão será desenvolvido
dentro do ambiente de um dos laboratórios de desenvolvimento de software de uma
empresa multinacional da área de tecnologia da informação.
Uma linha de produto de software desenvolvida por um grupo dentro dessa
10 empresa será usada como base para o estudo de caso.
A base de dados de defeitos a ser usada nesse trabalho contém todos os
defeitos cadastrados, internamente e por clientes, para todos os produtos que
compõem essa linha de produtos. Ela possui, aproximadamente, 150 mil registros de
defeitos cadastrados durante os últimos 11 anos.
1.4.1 – Levantamento e análise da literatura.
- O estado da arte será revisto para se entender com mais detalhes todos os
critérios propostos pelo método ODC para classificação de defeitos. Esses
critérios serão usados para se analisar os defeitos encontrados nos produtos
da linha
1.4.2 – Descrição e detalhamento da estrutura da base de dados de defeitos.
- A base de dados que possui os defeitos encontrados terá sua estrutura
descrita e, posteriormente, detalhada pois isso será um dos critérios usados
para se analisar os defeitos encontrados nos produtos da linha. Para se
descrever e detalhar a estrutura da base, serão identificados e descritos os
campos usados para armazenar os dados relativos aos defeitos. Os principais
campos usados são: o produto no qual o defeito foi encontrado, severidade do
defeito (que varia de 1 a 4), impacto do defeito no cliente, fase do processo de
desenvolvimento/manutenção, aplicação dentro de determinado produto,
versão do produto, build da versão do produto no qual foi encontrado o
defeito, entre outros.
1.4.3 – Levantamento das informações de defeitos da base de dados.
- Os critérios mais importantes e que serão efetivamente usados para a
obtenção dos padrões de defeitos serão selecionados. Essa seleção dar-se-a
levando-se em conta a estrutura da base de dados de defeitos e os critérios
propostos pelo ODC, levantados nos itens anteriores. Esses critérios ajudarão
na obtenção dos padrões de defeitos que possam auxiliar no entendimento
dos principais problemas ocorridos. Alguns desses critérios são: produto,
11
versão, aplicação, severidade, impacto no cliente, fase na qual foi encontrado,
atividade (a atividade que estava sendo feita quando o defeito foi descoberto),
gatilho (o ambiente ou a condição que teve que existir para o defeito
aparecer), alvo (representa a identidade do artefato que foi corrigido), tipo do
defeito (a natureza da correção que foi feita), qualificador (informação acerca
de uma implementação incorreta, irrelevante ou não existente), fonte
(identifica a origem do artefato que possuía o defeito) e idade (identifica a
idade do artefato que possuía o defeito). Esses critérios serão combinados
para se montar as consultas que serão usadas para se extrair informações
relativas aos defeitos cadastrados na base, como: número de defeitos de
severidade alta por produto e versão, número de defeitos de severidade alta
por fase, número de defeitos com alto impacto no cliente por idade do artefato
que o causou, número de defeitos de determinada versão por tipo, entre
outros. Essas consultas serão executadas na base de dados de defeito em
questão e os resultados serão armazenados em planilhas de texto para futura
análise e obtenção de padrões de defeitos que possam auxiliar no
entendimento dos principais problemas ocorridos.
1.4.4 – Análise dos resultados para se descobrir padrões de defeitos.
- Os resultados obtidos, após o levantamento de dados realizado no item
anterior, serão analisados com base nos critérios ODC selecionados no Item
1.4.3, para se descobrir padrões de defeitos que possam ajudar no
entendimento dos principais problemas ocorridos. Alguns dos resultados que
podem ser obtidos são: número de defeitos de severidade alta por produto e
versão, número de defeitos de severidade alta por fase, número de defeitos
com alto impacto no cliente por idade do artefato que o causou, número de
defeitos de determinada versão por tipo. Para auxiliar a análise, vários
gráficos serão gerados manualmente a partir dos resultados armazenados em
planilhas de texto e dos critérios selecionados no item anterior.
1.4.5 – Estabelecimento de um mapeamento entre os padrões de defeitos e o
processo de desenvolvimento e manutenção da linha de produtos.
12
- Esse mapeamento será estabelecido entre os padrões de defeitos
encontrados no item anterior e o processo de desenvolvimento e manutenção
da linha de produtos para se determinar as partes do processo que deixaram
escapar os defeitos mais graves ou a maior quantidade deles e que possam
necessitar de revisão. Os critérios do ODC, principalmente o tipo de defeito e
gatilho, serão usados para se estabelecer esse mapeamento.
1.4.6 – Proposição de tarefas de manutenção.
- Um conjunto de tarefas de manutenção, para essa linha de produtos de
software, serão propostas tendo em vista as partes do processo de
desenvolvimento e manutenção, identificadas no item anterior, que
necessitam de revisão. Práticas de manutenção de software, aplicadas a
produtos que não sejam parte de uma linha de produtos, também servirão de
base teórica para a proposição dessas tarefas, sendo que sua subsequente
aplicação tem como objetivo a diminuição das falhas do processo.
1.5 Organização de Trabalho
A Seção 2, Estado da Arte, apresenta os conceitos relevantes para o trabalho a
ser desenvolvido, como linhas de produtos de software, processo de manutenção
em linhas de produtos de software, classificação de defeitos de software, um método
para classificação de defeitos de software chamado ODC e trabalhos relacionados
A Seção 3, Planejamento dos testes, apresenta a descrição e o detalhamento da
estrutura da base de dados de defeitos, a seleção dos critérios mais importantes que
serão usados para a obtenção dos padrões de defeitos que possam auxiliar no
entendimento dos principais problemas ocorridos, a validação dessa seleção de
critérios e a montagem das consultas baseadas na combinação dos critérios
previamente selecionados.
A Seção 4, Execução das consultas, apresenta a execução das diversas
consultas, previamente definidas, sobre a base de dados de defeitos dos produtos
da linha de produtos em questão, bem como os resultados obtidos (Tais como
13 número de defeitos de severidade alta por produto e versão, número de defeitos de
severidade alta por fase, número de defeitos com alto impacto no cliente por idade
do artefato que o causou, número de defeitos de determinada versão por tipo).
Também apresenta uma análise dos resultados obtidos na execução dos testes,
com base nos critérios selecionados na Seção 3 e em alguns gráficos. Essa análise
é apresentada com a intenção de se chegar a padrões de defeitos que possam
auxiliar no entendimento dos principais problemas ocorridos. Essa seção também
apresenta mapeamentos entre esses padrões de defeitos e partes do processo de
desenvolvimento e manutenção da linha de produtos de software que deixaram
esses defeitos escaparem.
A Seção 5, Validação da análise dos resultados, apresenta a validação dos
especialistas ODC e da linha de produtos de software em questão relativas às
hipóteses de problemas, à montagem das consultas usadas para se recuperar os
dados de defeitos e às analises dos resultados obtidos com a execução destas
consultas.
A Seção 6, Elaboração de propostas de tarefas de manutenção, apresenta a
proposição de algumas tarefas de manutenção que poderão ser aplicadas visando a
diminuição das falhas das partes do processo que foram identificadas como
necessitando de revisão.
A Seção 7, Conclusão, apresenta as principais observações que podem ser
feitas após a elaboração das propostas das tarefas de manutenção, visando-se
chegar a conclusão de se pode haver ou não melhora no cenário descrito na
motivação desse trabalho.
14 2 ESTADO DA ARTE
2.1 Introdução
Neste capítulo, serão apresentados os conceitos relevantes para o trabalho a ser
desenvolvido, como linhas de produtos de software, processo de manutenção em
linhas de produtos de software, classificação de defeitos de software e um método
para classificação de defeitos de software chamado ODC.
O capítulo atual será organizado como segue. Na Seção 2.2, serão apresentados
os conceitos de linhas de produtos de software, as atividades essenciais
relacionadas ao seu desenvolvimento e manutenção, bem como os principais
estudos que estão sendo feitos relacionados a esse último assunto. Na Seção 2.3,
serão mencionadas as vantagens do uso das informações provenientes dos defeitos
de software para auxiliar na manutenção e evolução dos mesmos, do uso de
classificação dos defeitos de software para se melhorar os processos de
desenvolvimento, os conceitos do método ODC, os principais estudos e as principais
aplicações desse método de classificação, bem como as vantagens dessas
aplicações. Na Seção 2.4, faz-se uma conclusão sobre os tópicos apresentados no
capítulo.
2.2 Linha de Produto de Software
Linhas de Produtos de Software, que também são conhecidas como Famílias de
Produtos de Software, podem ser entendidas como um conjunto de sistemas de
software que compartilham um conjunto controlado de funcionalidades que
satisfaçam as necessidades de um segmento de negócio específico e que,
geralmente, são desenvolvidos a partir de componentes comuns seguindo um roteiro
pré-definido (Northrop e Clements, 2011). Em contrapartida e, para reforçar o
15 conceito, linhas de produtos de software não devem ser entendidas apenas como: o
desenvolvimento de um sistema que utiliza-se de reúso, desenvolvimento baseado
em um componente ou serviço, uma arquitetura reconfigurável, várias versões de
um produto único, um conjunto de padrões técnicos ou um reúso de baixa
granularidade (Northrop e Clements, 2011).
Essencialmente, a criação de uma linha de produtos de software envolve o
desenvolvimento do núcleo de artefatos e o desenvolvimento dos produtos usando
esse núcleo, todos eles sendo gerenciados tanto técnica quanto
organizacionalmente. O desenvolvimento do núcleo de artefatos e o
desenvolvimento dos produtos podem acontecer em qualquer ordem; produtos
podem ser gerados a partir do núcleo de artefatos ou os artefatos desse núcleo
podem ser extraídos de um ou mais novos produtos. O desenvolvimento do núcleo
de artefatos, o desenvolvimento dos produtos e o gerenciamento técnico e
organizacional são as três atividades essenciais relacionadas ao desenvolvimento
de linhas de produtos de software (Northrop e Clements, 2011), como mostrado na
Figura 1.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 13
Desenvolvimento de Linha de Produto
Engenharia de Domínio Engenharia de Aplicação
Desenvolvimento do Núcleo de Artefatos
Desenvolvimento do Produto
Gerenciamento
Figura 2.3: Atividades essenciais de uma LPS (adaptada de Software Engineering Institute (SEI)(2007)).
A iniciativa PLP estabelece três atividades essenciais para o desenvolvimento de linha de pro-dutos: o desenvolvimento do núcleo de artefatos , também conhecido como engenharia de domínio;o desenvolvimento do produto, também conhecido como engenharia de aplicação; e o gerencia-mento da LPS (Software Engineering Institute (SEI), 2007). Na Figura 2.3, são ilustradas essasatividades. Destaca-se a relação entre elas, que são iterativas e estão altamente interligadas, con-forme é indicado pelas flechas rotativas que se entrecortam. A atividade de desenvolvimento donúcleo de artefatos pode passar por revisões ou inclusões de novos artefatos, na medida em queprodutos são desenvolvidos, assim como novos produtos podem ser gerados, conforme são reali-zadas mudanças no núcleo de artefatos. Essas duas atividades são influenciadas pela atividade degerenciamento.
A abordagem PLP define um conjunto de áreas de trabalho menores e mais gerenciáveis como objetivo de realizar essas atividades essenciais.
Abordagem Plus
A abordagem Product Line UML-Based Software Engineering (PLUS) (Gomaa, 2004) estendeos métodos de modelagem de sistemas únicos baseados em Unified Modeling Language (UML)(Object Management Group (OMG), 2007) para tratar linha de produto de software (Gomaa,
Figura 1 - Atividades Essenciais para o desenvolvimento de linhas de produtos de software
Fonte: Northrop e Clements (2011)
16
Nenhuma das atividades essenciais citadas anteriormente tem o foco específico
na manutenção, seja ela dos artefatos que compõem o núcleo, seja dos produtos.
Segundo Dhungana et al. (2008), poucos trabalhos relacionados à evolução e
manutenção de linha de produtos de software estão disponíveis, mesmo tendo em
vista a importância dessas atividades que correspondem, ainda de acordo com
Dhungana et al (2008, apud Grubb e Takang 2005, p.6), a 60% dos custos de um
sistema de software. Para linhas de produtos de software, as atividades de
manutenção desempenham um papel ainda mais crucial devido ao tamanho, à
complexidade e à longevidade desses sistemas.
Em Dhungana et al. (2008), o problema relacionado à manutenção e à evolução
em linhas de produtos de software é atacado organizando-se os modelos de
variabilidade encontrados em uma linha de produtos em pequenos fragmentos
relacionados de modelos, cada um deles, definindo a variabilidade de uma parte
específica do sistema. O objeto de estudo desse artigo foi aplicado a um ambiente
parecido com o ambiente da linha de produtos de software que serve como base
para o trabalho a ser desenvolvido, no qual diversas equipes estão envolvidas em
criá-la e mantê-la e no qual diferentes partes do sistema apresentam diferentes
graus de complexidade e evoluem em velocidades distintas. O trabalho também
atesta a importância de abordagens para tratar da evolução de linhas de produtos de
software para evitar sua degradação.
Esses pontos mencionados serão úteis para fundamentar a importância do
trabalho a ser desenvolvido, bem como para servir de base para o seu
desenvolvimento. Contudo, a abordagem usada por Dhungana,et al. (2008), no
desenvolvimento do seu artigo, não será útil para o desenvolvimento da dissertação
em questão, pois em uma linha de produtos composta por um núcleo de artefatos
pequeno e coeso e produtos com grande variabilidade entre si, a fragmentação de
modelos em modelos menores, para atender variabilidades específicas, pode se
tornar inviável em termos de gestão de configuração, ainda mais em um ambiente
com várias equipes envolvidas e que estão dispersas geograficamente.
Em Riva e Del Rosso (2003), uma avaliação e uma posterior reconstrução da
arquitetura da linha de produtos de software são propostas para se resolver os
problemas relacionados à sua evolução. É destacado que, em relação às linhas de
produtos de software, o principal objetivo de uma arquitetura é o de descrever o que
17 é comum, e deve fazer parte do núcleo de artefatos, e o que é variável, para tornar
explícitos os pontos de variação de cada um dos produtos. São mencionados, ainda,
alguns problemas relacionados à evolução em linhas de produtos de software, bem
como algumas sugestões para se minimizar esses problemas, como:
- A introdução de novos requisitos que quebram a integridade do sistema, o
que poderia ser minimizado com uma análise de complexidade desses
requisitos e do impacto que eles teriam sobre a integridade do sistema;
- O risco de se projetar uma plataforma que seja muito genérica para as
necessidades dos produtos, o que pode ser resolvido com uma investigação
de qual seria a plataforma mais indicada para a linha de produtos em questão;
- A dependência que existe entre os vários componentes, sejam eles parte do
núcleo de artefatos ou dos produtos, e seus desenvolvedores
(desenvolvedores dos artefatos do núcleo) e usuários (desenvolvedores dos
produtos). Isso gera uma rede complexa de dependência que pode levar a
mudanças com efeitos indesejáveis ou a mudanças necessárias que
demoram a acontecer. Esses problemas podem ser resolvidos com uma
definição formal das atribuições de cada equipe e com a documentação das
dependências existentes entre os componentes do núcleo de artefatos e os
componentes de cada um dos produtos.
Os problemas e as sugestões mencionadas anteriormente devem ser levadas em
consideração em qualquer tentativa de auxiliar a melhoria das tarefas de
manutenção e evolução em linhas de produtos de software. Contudo, uma análise
de toda a arquitetura da linha de produtos, bem como sua reconstrução só podem
ser feitos com o aval e a participação do grupo que a define e controla, o que nem
sempre é viável, por serem esses grupos fechados e resistentes a mudanças. Além
disso, esse trabalho de avaliação arquitetural pode levar à conclusão de que essa
arquitetura precisa ser quase que totalmente reconstruída, o que também pode vir a
ser inviável dependendo do tamanho, da idade e da complexidade da linha de
produtos
O uso de simulação para facilitar decisões de processos, como as estratégias de
adoção e evolução a serem usadas, relacionadas ao desenvolvimento e à evolução
das linhas de produtos de software é mostrado em Chen et al. (2004). O simulador
criado pelos autores se baseia na teoria de simulação discreta de eventos e em um
modelo de investimento construtivo de linhas de produtos chamado COPLIMO
18 (Constructive Product Line Investment Model). Com as simulações realizadas, os
autores conseguem mostrar os efeitos que variações relacionadas aos recursos
humanos, às estratégias de adoção e às estratégias de evolução têm sobre uma
linha de produtos de software.
Os conceitos de estratégias de evolução apresentados nesse artigo serão úteis
no trabalho a ser desenvolvido, pois podem servir tanto de base para o
desenvolvimento e a proposição de melhorias nas tarefas de manutenção como para
validar a eficiência da aplicação dessas melhorias sobre diferentes estratégias
evolutivas. Entretanto, algumas das suposições feitas pelos autores sobre o
desenvolvimento e o uso do simulador fazem com que ele não seja recomendável
para linhas de produtos de software disponíveis comercialmente. Essas linhas de
produtos não possuem produtos com tamanhos iguais ou com frações idênticas de
código reaproveitado. Para essas linhas, mudanças em um produto não causarão
mudanças no mesmo percentual de código reaproveitado e adaptado nos outros
produtos da linha, como os autores assumem. Logo, uma evolução do simulador
para aceitar linhas de produtos de software com produtos de tamanhos diferentes,
taxas variáveis de mudança em código reaproveitado e adaptado permitiria que ele
pudesse ser usado em linhas de produtos disponíveis no mercado.
Já Jiang et al (2008) tentam propor uma mudança no processo de manutenção
de software com a adição de técnicas de mineração de dados. Essas técnicas são
usadas para se achar potenciais áreas do código, em outros produtos de uma linha,
nas quais defeitos semelhantes ao que acabou de ser corrigido possam também
ocorrer. Se essas áreas forem encontradas, novos defeitos são abertos, delegados
aos responsáveis e corrigidos. Esse processo ajuda na descoberta de defeitos
similares e que podem estar escondidos em outros produtos da linha. Como
justificativa para a aplicação das técnicas de mineração de dados, é mencionado
que, gradualmente, os artefatos comuns e os padrões de reúso, sejam eles módulos
idênticos de código ou módulos com modificações mínimas, em uma linha de
produtos de software, se tornam intratáveis e que a correção de defeitos falha em
não propagá-los, o que leva a uma degradação na qualidade do produto.
As linhas de produtos mencionadas no artigo experimentam um processo de
manutenção centrado em código, devido à urgência da correção de defeitos, o que
se assemelha a linha de produtos de software objeto de estudo do trabalho a ser
desenvolvido. Isso somado à aplicação do uso de defeitos como base para a
19 melhoria da qualidade dos produtos de uma linha de produtos de software e ao uso
de técnicas de mineração de dados será útil para o trabalho a ser desenvolvido, pois
este último usará a classificação e a análise dos defeitos presentes em uma base de
dados para auxiliar na melhoria das tarefas de manutenção desses produtos.
Contudo, a aplicação de técnicas de mineração de dados para se achar padrões de
código semelhantes, em outros produtos da linha, não resolve o problema da
manutenção evolutiva dos produtos que fazem parte de qualquer linha de produtos
de software. Além disso, os autores não detalharam o método proposto, o que
inviabiliza o seu uso ou sua adaptação para o uso em linhas de produtos de software
mais complexas.
Como mencionaram Jiang et al (2008), existem linhas de produtos de software
que apresentam um processo de manutenção centrado em código, pois a correção
de defeitos é um ponto crítico. Nesses casos, o uso destes defeitos, desde que
armazenados em algum tipo de repositório de defeitos encontrados, pode ser útil na
análise dos principais problemas relacionados a manutenção e a evolução destas
linhas. Entretanto, dependendo do número de defeitos presentes neste repositório,
essa análise pode ser tornar inviável sem algum tipo de semântica ou classificação
aplicados a eles.
Em Thao (2012), o problema relacionado à manutenção e à evolução em linhas
de produtos de software é atacado propondo-se um sistema de controle de versão
que dê suporte à evolução da linha, através da propagação das mudanças no núcleo
de artefatos para os produtos e vice-versa. O modelo proposto por esse artigo deve
modelar a linha de produtos de software, acompanhar os artefatos compartilhados
do núcleo, mostrar como os produtos são derivados do núcleo de artefatos, exibir a
evolução dos produtos e dos artefatos do núcleo de maneira independente e permitir
com que as mudanças propaguem entre o núcleo de artefatos e os produtos.
Um sistema de controle de versão é importante para o controle de mudanças,
principalmente no desenvolvimento de um sistema complexo como uma linha de
produtos de software e já é usado na linha de produtos de software objeto de estudo
desse trabalho. A abordagem usada por Thao (2012), no desenvolvimento do seu
artigo, difere da abordagem do sistema de controle de versão usado na linha de
produtos de software em questão. Ela, mesmo sendo mais completa que a usada
atualmente na linha de produtos em questão, não será útil para o desenvolvimento
da dissertação, pois um controle de versão bem feito não resolverá problemas como
20 o das manutenções realizadas nos produtos da linha, sejam elas corretivas ou
evolutivas, serem de difícil análise, implementação e implantação, ou ainda, os
desenvolvimentos de novas funcionalidades, em alguns casos, não atenderem aos
requisitos.
Em Souza et. al. (2012), o problema relacionado à evolução em linhas de
produtos de software é atacado propondo-se um estudo para analisar o resultado de
dados coletados em inspeções e a relação desses dados com o número de linhas de
código, número de manutenções corretivas nos produtos da linha, número de
características dos produtos da linha e número de não conformidades dessas
características. Com isso, os autores chegam a algumas conclusões relativas a
essas relações, como, existir uma correlação muito forte entre manutenção corretiva
e não conformidade de característica ou entre manutenção corretiva e número de
características dos produtos.
Essa análise da relação de dados entre ocorrências de manutenções corretivas
e outras variáveis é importante para se entender quais os fatores mais influenciam
no aparecimento dessas ocorrências. Contudo, a abordagem usada por Souza et. al.
(2012), no desenvolvimento do artigo, não será útil para o desenvolvimento da
dissertação, pois ela se baseia apenas em dados obtidos através de inspeções em
uma linha de produtos pequena voltada para o ambiente médico. Essa abordagem
difere, em termos de origem dos dados, tamanho da linha de produtos e finalidade,
da linha de produtos objeto de estudo do trabalho.
2.3 Uso de informações de defeitos de software na manutenção e o método
Orthogonal Defect Classification (ODC)
O uso de informações de defeitos de software para auxiliar na manutenção e na
evolução desses sistemas é apresentado em vários trabalhos. Alguns desses
trabalhos serão apresentados a seguir.
Em Li e Long (2011), os problemas relacionados à manutenção e evolução de
sistemas de software são atacados com o uso de informações de defeitos para se
medir a degeneração das arquiteturas desses mesmos sistemas. Essas
informações, que são a versão do sistema, o componente onde o defeito foi
21 encontrado, os arquivos alterados para se corrigir os defeitos, o número de linhas de
código da correção e o número de linhas de código do arquivo são obtidas através
de um repositório de controle de defeitos. O levantamento dessas informações ajuda
a responder algumas questões relacionadas à degradação arquitetural e a se montar
algumas relações que levam ao entendimento de quais componentes contribuem
mais para essa degradação e, consequentemente, que devem ser corrigidos com
maior prioridade.
O uso de informações de defeitos para se detectar problemas na arquitetura do
sistema também é um dos objetivos do trabalho em questão. Contudo, a abordagem
usada por Li e Long (2011), no desenvolvimento do artigo, difere da usada no
desenvolvimento da dissertação, pois ele se baseia apenas em poucas informações
de defeitos, sem nenhuma classificação e também porque ele conecta as
informações de defeitos apenas com problemas relativos à arquitetura. O método de
classificação de defeitos ODC e o uso de informações de defeitos para se achar
problemas relativos ao código, ao projeto, à arquitetura, à documentação, entre
outros, que o próprio ODC oferece fazem com que a abordagem do trabalho em
questão seja mais completa que a usada por Li e Long (2011).
Em D´Ambros (2008), os problemas relacionados à manutenção e evolução de
vários sistemas de software são atacados com o uso de informações dos defeitos
desses mesmos sistemas. Essas informações, que são obtidas através de um
repositório de controle de defeitos, ajudam no entendimento sobre a estrutura do
sistema de software e na detecção de possíveis problemas no código fonte.
Problemas, esses, que podem ajudar a identificar as áreas mais problemáticas e
futuros erros no sistema.
Esse uso de informações de defeitos para se detectar áreas problemáticas do
sistema e futuros problemas também é um dos objetivos do trabalho em questão.
Contudo, a abordagem usada por D´Ambros (2008), no desenvolvimento do artigo,
difere da usada no desenvolvimento da dissertação, pois ele baseia-se apenas em
dados obtidos através de um repositório de dados de defeitos que não usa nenhum
método para classificá-los e também porque ele conecta as informações de defeitos
apenas com problemas relativos ao código fonte. O método de classificação de
defeitos ODC e o uso de informações de defeitos para se achar problemas relativos
ao código, ao projeto, à arquitetura, à documentação, entre outros, que o próprio
ODC oferece fazem com que a abordagem do trabalho em questão seja mais
22 completa que a usada por D´Ambros (2008).
O uso do método de classificação de defeitos ODC permite aos desenvolvedores
receberem uma resposta sobre o processo de desenvolvimento por meio da
extração de informações dos defeitos. Esse método baseia-se na idéia de que o uso
de informações semânticas relativas aos defeitos possibilita a extração de
relacionamentos de causa e efeito dentro do processo de desenvolvimento. Pode-se
entender o ODC como um método de classificação de defeitos no qual cada defeito
é caracterizado em atributos e classes que, coletivamente, mapeiam a parte do
processo que necessita de revisão. Os atributos têm como objetivo descrever cada
um dos defeitos. Para cada atributo, um valor deve ser escolhido para caracterizá-lo,
esse valor também é chamado de classe (Chillarege et al, 1992).
Alguns atributos são levantados no momento da abertura do defeito enquanto
outros são levantados no momento da correção dele. Quando um defeito é aberto,
as circunstâncias que levaram ao seu aparecimento, bem como o seu impacto para
o usuário são tipicamente conhecidos. Quando um defeito é fechado, geralmente
depois de uma correção ser aplicada, tanto sua natureza quanto o escopo da
correção também são conhecidos. As categorias do método ODC capturam a
semântica do defeito dentro dessas duas perspectivas (IBM Research, 2002). Para
cada categoria, existem atributos específicos e, para cada atributo, existem classes
definidas de valores. Para a classificação do defeito, apenas um valor para cada um
dos atributos deve ser escolhido.
Durante a abertura do defeito, os atributos atividade (a atividade que estava
sendo feita quando o defeito foi descoberto), gatilho (o ambiente ou a condição que
existiu para o defeito aparecer) e impacto (o impacto que esse defeito teria ou teve
para o cliente) devem ser preenchidos. Já, durante a correção do defeito, os
atributos alvo (identidade do artefato que foi corrigido), tipo do defeito (a natureza
da correção que foi feita), qualificador (informação acerca de uma implementação
incorreta, irrelevante ou não existente), fonte (identifica a origem do artefato que
possuía o defeito) e idade (identifica a idade do artefato que possuía o defeito)
devem ser preenchidos (IBM Research, 2002)
Os atributos alvo, tipo do defeito, atividade e gatilho do defeito são essenciais
para se mostrar a parte do processo de desenvolvimento de software que necessita
de revisão. Os atributos alvo e tipo do defeito capturam o significado da correção.
Cada classe de valor, associada a esses atributos, pode ser mapeada para uma
23 parte do processo que falhou e deixou o defeito escapar. Já os atributos atividade e
gatilho do defeito, que pode ser entendido como uma condição que permitiu o seu
aparecimento, provêm informações e mapeamentos acerca do processo de
verificação, sua eficiência e completeza (Chillarege et al, 1992).
Os conceitos apresentados acima serão de fundamental importância para o
trabalho a ser desenvolvido, pois o ODC será o método usado para a classificação
dos defeitos da linha de produto de software objeto de estudo do trabalho.
Em El Emam e Wieczorek (1998), uma pequena modificação no método ODC é
apresentada em conjunto com uma técnica para se verificar a repetitividade da
classificação de defeitos usando esse método. Pode-se entender o conceito de
repetitividade, em classificação de defeitos, como sendo o baixo grau de
dependência que essa classificação tem com o seu classificador. Os autores alegam
que a repetitividade dessa classificação leva a um maior grau de confiança o que faz
com que decisões de melhorias sejam tomadas com um maior grau de certeza. Os
autores ainda mostram, no artigo, que, levando-se em conta o artefato código, o
atributo tipo do defeito e dados relacionados a defeitos encontrados em inspeções
de código e a classificação de defeitos usando-se o método ODC apresentam um
alto grau de repetitividade e, consequentemente, de confiabilidade. Uma técnica
para se verificar a repetitividade e a consequente confiabilidade da classificação de
defeitos baseada no método ODC é de vital importância no trabalho a ser
desenvolvido, pois as recomendações relativas às tarefas de manutenção da linha
de produtos de software serão baseadas nesta classificação. Porém, a técnica
apresentada no artigo pode não ser adequada para a aplicação no desenvolvimento
do trabalho, pois baseia-se em um pequeno conjunto de dados de defeitos
encontrados em inspeções de código, o que contrasta com o grande conjunto de
dados de defeitos, na ordem de 100 mil, encontrados por testadores e por clientes
da linha de produtos de software do trabalho em questão.
Tiejun, Leina e Chengbin (2008) propõem um sistema de rastreamento de
defeitos baseado no método ODC e no uso de um sistema de fluxo de trabalho.
Esse sistema baseia-se no uso de alguns atributos do ODC, como atividade, gatilho,
severidade, origem, conteúdo e tipo, para a classificação dos defeitos e em uma
ferramenta de fluxo de trabalho para informar aos responsáveis pelos defeitos, em
cada um dos seus possíveis estados, o que deve ser feito para que ele possa passar
para o estado seguinte até sua resolução. Segundo os autores, o ODC foi escolhido
24 como método de classificação de defeitos, pois resolve o problema da criação de
medidas úteis para que se possa avaliar o processo de desenvolvimento. O fato do
trabalho usar o ODC como base para a classificação dos defeitos e de expor, em
mais detalhes, conceitos relacionados aos atributos atividade, gatilho, tipo e origem,
o torna uma fonte de consulta útil para o trabalho a ser desenvolvido. O número de
papéis responsáveis por analisar cada um dos defeitos, de acordo com o artigo,
(Testador, Gerente de Testes, Desenvolvedor, Gerente do Desenvolvedor, Revisor
Chefe, Revisor, Oficial de Gerenciamento de Configuração), bem como o número de
estados pelos quais esses defeitos passam antes de poderem ser marcados como
resolvidos são pontos que podem aumentar a confiabilidade do processo de
classificação. Entretanto, eles também são pontos ineficientes do sistema de
rastreamento proposto, pois essa complexidade pode levar à demora para se
resolver defeitos devido a burocracia imposta pelo processo. Isso é especialmente
preocupante em sistemas nos quais a correção de defeitos é um ponto crítico, o que
é o caso da linha de produtos de software, objeto de estudo do trabalho a ser
desenvolvido.
Em Huang et al (2011), são apresentados uma abordagem e uma ferramenta
para se automatizar a classificação de defeitos baseada em ODC. Segundo os
autores, a classificação de defeitos, usando o ODC, da maneira convencional, é uma
tarefa árdua, propensa a erros e que requer a participação de especialistas do
domínio do problema e do método ODC em si. Para a criação do AutoODC
(Automated Generation of Orthogonal Defect Classifications), os autores
empregaram técnicas de classificação de texto sobre os relatórios de defeitos e
algoritmos de aprendizado. Nesse caso, esses algoritmos foram desenvolvidos para
o aprendizado dos conceitos relativos ao ODC. Segundo as simulações
apresentadas no trabalho, o uso do AutoODC pode reduzir o esforço humano e
aumentar a confiança dos analistas nas classificações realizadas por meio do
método ODC. Um método para classificação automática de defeitos será útil no
trabalho a ser desenvolvido, pois a base de dados de defeitos da linha de produto de
software tem mais de 100 mil registros de defeitos. Entretanto, essa base de dados
é estruturada como um banco de dados relacional. Logo, uma abordagem de
classificação baseada em texto, vindo de relatórios de defeitos só seria apropriada
para a classificação neste caso, se fosse modificada para atender a estrutura da
base de dados objeto de estudo desse trabalho.
25
Bassin e Santhanam (2001) descrevem um método para a análise de
informações que podem ser extraídas de defeitos, classificados usando o método
ODC. Esse método tem o objetivo de mostrar as fraquezas dos produtos e dos
processos usados no desenvolvimento desses. Este método pretende caracterizar
os elementos dos produtos e, então, identificar as atividades do processo que
possam mostrar suas fraquezas. Nesse trabalho, são tratados problemas de
manutenção apenas em artefatos legados, portados e feitos por terceiros. Com isso,
apenas os atributos do ODC origem e idade são levados em questão, pois o atributo
origem tem classes de valores relacionadas a artefatos portados e desenvolvidos
por terceiros e o atributo idade tem classes de valores que podem identificar se um
artefato é legado ou não. O método proposto consiste na coleta de dados de
defeitos classificados pelo ODC, no uso de técnicas de avaliação dos atributos para
se definir algumas características relativas às atividades de remoção ou prevenção
de defeitos, na identificação de pontos positivos e fraquezas do processo e na
execução das ações e medição dos resultados. Esse método poderá servir como
base para o método que será adotado no trabalho a ser desenvolvido para a análise
das informações que serão extraídas dos defeitos presentes no repositório de
defeitos da linha de produtos de software em questão, pois suas finalidades são
semelhantes. Contudo, o método apresentado no artigo só leva em consideração
dois atributos do ODC e só interessa-se na análise de informação de software
portado, legado e desenvolvidos por terceiros. Isto não atende à análise a ser feita
sobre os defeitos encontrados na linha de produtos de software objeto do estudo a
ser desenvolvido, pois a base de dados de defeitos desta é classificada usando-se
todos os atributos do método ODC, além de levar em consideração os produtos de
software desenvolvidos internamente.
Já Saraiya, Lohner e Baik (2006) propõem uma matriz de congruência para
melhorar o processo de classificação de defeitos usando o ODC. Os autores
acreditam que o uso desta matriz ajuda a monitorar a qualidade dos dados coletados
dos defeitos classificados segundo o ODC, o que levaria a uma melhora no processo
de coleta destes dados e ajudaria na institucionalização do ODC dentro das
organizações. Para se desenvolver a matriz, basicamente, tenta-se achar
relacionamentos significativos entre os atributos tipo e gatilho de um defeito,
baseado no conhecimento de especialistas do domínio. Com a definição desse
relacionamento, uma matriz de tipo de defeito por gatilho de defeito foi montada
26 representando a probabilidade (alta, média ou baixa) de se ocorrer uma combinação
dos valores das classes destes atributos em cada um dos quadrantes da matriz.
Após finalizada, a matriz pode ser usada como referência para a verificação da
classificação de cada um dos defeitos, pois pode ser verificado qual a probabilidade
dos valores escolhidos para os atributos tipo e gatilho acontecerem naquela
combinação. Revisões podem ser feitas para defeitos que apresentam classificações
com baixas probabilidades de ocorrência, segundo a matriz, e correções e
treinamento podem ser realizados se necessário. Uma técnica para se monitorar a
qualidade dos dados de classificação de defeitos deverá ser usada no trabalho a ser
desenvolvido, pois defeitos incorretamente classificados podem levar a análises
incorretas e a propostas de tarefas de manutenção que não sejam coerentes. Só
que uma técnica manual para esse monitoramento não atende ao caso do trabalho a
ser desenvolvido, pois o esforço para se revisar mais de cem mil defeitos não terá
como ser realizado. Além disso, para revisão da classificação de defeitos pelo
método ODC ser completa, devem ser usados os outros atributos apresentados pelo
método, como atividade, impacto, idade, origem, qualificador e alvo.
Em Chillarege (2011), o atributo da classificação ODC gatilho é usado para
estimar a proporção de dois tipos de erro de um software em produção. Os dois
tipos de erro a terem sua proporção estimada são: os Bohrbugs, que podem ser
entendidos como erros de comportamento determinísticos e os Mandelbugs, que
podem ser entendidos como erros de comportamento não determinísticos. O autor
menciona que o atributo gatilho pode ser entendido como o mecanismo que faz com
que o defeito apareça ou o ambiente ou a condição que deve existir para o defeito
aparecer. Ele também menciona que esse atributo torna-se uma medida dos
processos de verificação e validação. Ele, de acordo com a última versão do ODC,
5.11, pode ter as seguintes classes de valores: conformidade com o projeto de
software, lógica/fluxo, compatibilidade retroativa, documentação interna,
compatibilidade lateral, concorrência, dependência de linguagem, efeitos colaterais,
situação rara, caminho simples, caminho complexo, cobertura, variação,
sequenciamento, interação, carga de trabalho, recuperação/exceção, início/reinicio,
configuração de hardware, configuração de software e teste bloqueado. (IBM
Research, 2002). Como, segundo Chillarege (2011), a medição de gatilhos é mais
simples e direta do que a medição do ambiente no qual o erro foi encontrado, o
primeiro é usado para afirmar qual o tipo do erro ocorrido. O artigo mostra como o
27 método ODC pode ser útil para a classificação e a identificação de erros nos mais
diversos ambientes e dos mais diversos tipos. Contudo, a aplicação do método
ODC, o desenvolvimento e o estudo de caso apresentados nesse trabalho, que
levam em conta apenas ocorrências de tipos de defeitos muito específicos
(Bohrbugs e Mandelbugs), diferem do objeto de estudo do trabalho a ser
desenvolvido.
2.4 Conclusão
Neste capítulo foram apresentados conceitos relevantes para o trabalho a ser
desenvolvido, como linha de produto de software, processo de manutenção em linha
de produto de software, classificação de defeitos de software e um método para
classificação de defeitos de software chamado ODC.
Além desses conceitos, abordagens relativas ao processo de manutenção em
linha de produto de software, bem como ao uso do método ODC e adaptações
propostas para a classificação de defeitos em ambientes distintos foram mostradas.
No capítulo também foram apresentados exemplos das abordagens
mencionadas, as principais vantagens e desvantagens de suas aplicações, bem
como uma análise do possível uso dessas no trabalho a ser desenvolvido.
28 3 PLANEJAMENTO DAS CONSULTAS PARA VALIDAÇÃO DAS HIPÓTESES
3.1 Introdução
Este capítulo apresenta a descrição e o detalhamento da estrutura da base de
dados de defeitos, incluindo os campos usados para os critérios do método ODC. O
capítulo também apresenta as principais hipóteses que levam aos problemas que se
deseja resolver, a seleção dos critérios que serão usados para a obtenção dos
padrões de defeitos que possam auxiliar no entendimento dos principais problemas
ocorridos, bem como a justificativa dessa seleção, a validação dessa seleção e a
montagem das consultas baseadas na combinação dos critérios previamente
selecionados.
3.2 Estrutura da base
A base de dados de defeitos em questão possui vários campos que são usados
para caracterizar e descrever cada um dos registros de defeitos abertos para os
produtos dessa linha de produto de software. Existem campos que são de uso geral
e que não são provenientes de nenhum método, como identificador do defeito,
descrição, entre outros. O restante dos campos, como gatilho, tipo de defeito, entre
outros, são provenientes do método ODC. Os principais campos de uso geral
utilizados, na base de dados, para descrever e classificar um defeito serão
mostrados na Tabela 1:
29 Tabela 1 - Critérios da base de dados de defeitos
Critérios Descrição
Identificador do defeito Identificador único do defeito no formato AA-NNNNN, no qual AA são os
dois últimos dígitos do ano no qual o defeito foi descoberto e NNNNN é
um número sequencial.
Descrição Descrição detalhada do defeito, bem como os passos usados para
reproduzi-lo.
Produto Mostra em qual dos produtos da linha de produtos o defeito foi
descoberto. Um defeito também pode ser aberto para o produto ou
software base.
Versão Campo que mostra em qual versão de um determinado produto da linha
o erro foi encontrado.
Aplicação Cada um dos produtos da linha possui uma série de aplicações. Esse
campo mostra em qual aplicação, de um determinado produto, o defeito
foi encontrado.
Severidade Mostra a severidade do defeito descoberto. Essa severidade pode ser:
1 – Resultado errado ou falha, crítico para a execução do programa.
2 – Resultados errado, não crítico para a execução do programa.
3 – Comportamento inesperado.
4 – Problema menor.
Impacto no Cliente Campo que descreve qual o impacto que o defeito causou no cliente ou
causaria se tivesse sido descoberto no ambiente de produção do cliente.
Pode ter os valores alto, médio e baixo. Esse campo não será usado no
trabalho por ter a mesma função do campo ODC impacto.
Tipo Campo que identifica se o registro corrente é um defeito no software, um
problema de documentação ou um pedido de melhoria.
APAR APAR (Authorized Program Analysis Report) é um campo que identifica
que esse defeito foi descoberto no ambiente de produção de um cliente.
Prioridade de Teste Campo que mostra qual é a prioridade desse defeito sob o ponto de vista
da equipe de testes. O defeito pode bloquear a execução de um caso de
testes, pode ser de correção obrigatória, pode ter uma prioridade
moderada ou baixa
Defeito duplicado Campo que mostra, caso exista, o número de um outro defeito,
descoberto anteriormente, que seja semelhante ao defeito em questão.
Com isso, a correção do defeito duplicado, também corrigirá o defeito em
questão.
Estado de desenvolvimento
Campo que exibe o estado, sob o ponto de vista da equipe de
desenvolvimento, no qual o defeito se encontra. O defeito pode se
encontrar nos estados: aberto, não reproduzido, não é defeito, retrabalho
e corrigido.
30
Critérios Descrição
Atribuído a Mostra para qual membro da equipe de desenvolvimento o defeito foi
atribuído para ser corrigido.
Versão alvo Campo que mostra em qual versão de um determinado produto da linha
o erro deve ser corrigido e a correção deve ser entregue.
Build corrigido Campo que exibe o identificador do build, de uma determinada versão de
um produto da linha de produtos, que contem a correção para o defeito
em questão.
Estado de teste Campo que exibe o estado, sob o ponto de vista da equipe de testes, no
qual o defeito se encontra. O defeito pode se encontrar nos estados:
aberto, não reproduzido, não é defeito, corrigido, retrabalho e fechado.
Versão de teste Campo que mostra em qual versão de um determinado produto da linha
a correção feita para o defeito foi testada.
Build de teste Campo que exibe o identificador do build, de uma determinada versão de
um produto da linha de produtos, na qual a correção feita para o defeito
foi testada.
Testado por Mostra qual membro da equipe de testes foi o responsável por testar a
correção do defeito.
Já os campos com critérios do método ODC serão mostrados e descrito na
Tabela 2:
31 Tabela 2 - Critérios ODC da base de dados de defeito
Critérios ODC Descrição
Atividade Mostra o que estava sendo feito ou se tentando fazer quando o defeito foi
descoberto. Por exemplo, durante a fase de teste de componente,
decidiu-se fazer uma inspeção de código. Nesse caso, a fase é teste de
componente, mas a atividade é inspeção de código.
Gatilho Mostra o ambiente ou a condição que teve que existir para se descobrir o
defeito. Ou o que foi necessário para se reproduzir o defeito.
Impacto Mostra qual impacto o defeito descoberto teria (caso tenha sido
descoberto internamente) ou teve (caso tenha sido descoberto em
ambiente externo) para o cliente.
Alvo Campo que exibe a identidade de alto nível do artefato que foi realmente
corrigido. Pode ser um dos seguintes valores: build, código, projeto,
informação, suporte de idioma nacional e requisitos.
Tipo do defeito Mostra a natureza da correção que foi feita, ou o que realmente foi
corrigido.
Qualificador Campo que mostra uma indicação de se o defeito foi uma omissão, um
erro ou por uma implementação irrelevante.
Fonte Campo que mostra a identificação da origem do artefato que possui o
defeito. Especifica se o defeito foi encontrado em um artefato
desenvolvido internamente, reusado de uma biblioteca, portado de uma
plataforma para outra ou desenvolvido por terceiros.
Idade Campo que mostra a idade do artefato que possui o defeito. Especifica
se um defeito foi encontrado em um artefato novo, velho, reescrito ou
recorrigido.
3.3 Seleção dos Critérios da Base de Dados de Defeitos
A base de dados detalhada no item anterior possui 27 campos que representam
os critérios que descrevem e classificam um defeito. Como esses critérios não
possuem a mesma importância em relação ao problema mencionado na motivação
deste trabalho e para a classificação dos defeitos, os mais importantes serão
selecionados. Essa seleção tem como objetivo facilitar a obtenção de padrões de
defeitos que possam auxiliar na identificação e análise dos principais problemas
relacionados à manutenção na linha de produto de software analisada.
32
Contudo, para se definir quais são os critérios mais importantes e que deverão
ser selecionados para uma posterior combinação dos mesmos para montar cada
uma das consultas, deve-se, primeiramente, levantar as principais hipóteses que
levam aos problemas relacionados à manutenção em linhas de produto de software
que o trabalho pretende elucidar.
Essas hipóteses foram obtidas através de entrevistas com os líderes dos times
de desenvolvimento dos produtos que compõem a linha de produto objeto deste
trabalho e são inteiramente baseadas na experiência desses líderes e dos times que
eles lideram.
Foram selecionados para entrevista sete líderes dos times de desenvolvimento
de sete produtos diferentes, baseado no seu tempo de experiência no
desenvolvimento relacionado a linha de produto em questão.
Foram realizadas entrevistas pessoais, de 1 hora cada, com os 5 líderes dos
times de desenvolvimento que se encontram no Brasil.
- Foram realizadas entrevistas por telefone, de 1 hora cada, com os 2 líderes
dos times de desenvolvimento que se encontram nos Estados Unidos.
- As seguintes perguntas foram feitas para esses líderes de time:
o Na sua opinião, quais os principais problemas apresentados durante o
desenvolvimento de novas aplicações para os produtos da linha de produto de
software ?
o Na sua opinião, quais os principais problemas apresentados durante os testes
de novas aplicações para os produtos da linha de produtos de software ?
o Na sua opinião, quais os principais problemas enfrentados durante o
desenvolvimento do código para corrigir defeitos encontrados por clientes nos
produtos da linha de produtos ?
o Na sua opinião, quais os principais problemas enfrentados durante as?
correções de defeitos encontrados por clientes nos produtos da linha de produtos ?
o Na sua opinião, quais os principais problemas relacionados à influência do
código do produto núcleo no código dos outros produtos da linha de produtos ?
o Na sua opinião, quais os principais problemas relacionados à influência dos
testes realizados no produto núcleo sobre os testes realizados nos outros produtos
da linha de produtos ?
- Nas entrevista, hipóteses preliminares foram apresentadas a eles:
o Para as equipes de desenvolvimento fica muito difícil fazer algum tipo de
33 alteração ou melhoria com a segurança de que as mesmas não irão gerar impacto.
o O código, o projeto e as decisões arquiteturais das correções e das novas
funcionalidades são feitos sem uma análise de impacto em outras partes do produto
e em outros produtos da linha.
o Mudanças no produto núcleo, muitas vezes, quebram um ou mais produtos
específicos.
o Alguns defeitos abertos por clientes são resolvidos como tal mesmo sem se
ter certeza de serem defeitos ou pedidos de melhoria.
o A migração para novas versões dos produtos da linha é demorada e nem
sempre confiável.
- Como resultado das entrevistas, foram obtidas as respostas a cada uma das
perguntas apresentadas, assim como os comentários sobre cada uma das hipóteses
apresentadas preliminarmente.
- Após a análise das respostas e dos comentários realizados pelos líderes dos
times, chegou-se às 18 hipóteses de problemas (Todas as hipóteses originais
encontram-se apresentadas no apêndice deste trabalho). Essas 18 hipóteses
passaram para avaliação de outros especialistas em ODC e na linha de produto
objeto de estudo deste trabalho. Na continuidade deste trabalho, algumas hipóteses
foram fundidas e outras eliminadas, chegando-se às 12 hipótese detalhadas na
Tabela 3.
34 Tabela 3 - Detalhamento das principais hipóteses de problemas
Hipótese Descrição
1 Para as equipes de desenvolvimento fica muito difícil fazer algum tipo de
alteração ou melhoria com a segurança de que as mesmas não irão
gerar impacto.
2 O código, o projeto e as decisões arquiteturais das correções e das
novas funcionalidades são feitos sem uma análise de impacto em outras
partes do produto e em outros produtos da linha.
3 Correções de defeitos podem não corrigir o problema.
4 Desenvolvimentos de novas funcionalidades tornam o ambiente instável.
5 Desenvolvimento de novas funcionalidades não atendem aos requisitos.
6 Em determinadas versões de determinados produtos, muitos defeitos
escapam para os clientes.
7 Muitos defeitos que escapam para clientes demoram muito tempo para
serem corrigidos.
8 Vários defeitos de baixa e média severidade (severidades 3 e 4) não são
corrigidos dentro da iteração nos quais eles foram descobertos.
9 Alguns defeitos abertos por clientes são resolvidos como tal mesmo sem
se ter certeza de serem defeitos ou pedidos de melhoria.
10 A manutenção do código legado é complicada devido à inexistência de
documentação técnica e não-funcional.
11 Falta de conhecimento das regras de negócio dos serviços do software
base pelos gerentes do produto.
12 O software base e os específicos são traduzidos para vários idiomas, o
que pode gerar defeitos específicos em alguns idiomas que não são
classificados como tal.
Após a identificação das hipóteses sobre os principais problemas na manutenção
da linha de produto analisada, serão apresentados os critérios selecionados e a sua
participação na fase de testes dessas hipóteses.
O produto no qual o defeito foi encontrado é importante e será usado para que se
possa fazer uma análise quantitativa de defeitos descobertos no software base e em
cada um dos produtos da linha de produtos. Esse critério pode ser usado para
ajudar na obtenção de padrões de defeitos que possam auxiliar na identificação,
confirmação e análise das hipóteses 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 e 12.
A versão do produto é um critério que será usado para se determinar a incidência
de defeitos por versão. Com isso, pode-se descobrir tendências de ocorrência de
35 problemas relacionados a uma versão específica ou mesmo montar um histórico de
defeitos por versão. Esse critério pode ser usado para ajudar na obtenção de
padrões de defeitos que possam auxiliar na identificação, confirmação e análise das
hipóteses 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 e 12.
Os critérios severidade do defeito e impacto no cliente serão usados nos testes,
pois o uso desses critérios permite selecionar aqueles defeitos que geram maiores
problemas para os clientes e nos quais a aplicação das tarefas de manutenção
propostas irão gerar os maiores impactos. Esses critérios podem ser usados para
ajudar na obtenção de padrões de defeitos que possam auxiliar na identificação,
confirmação e análise das hipóteses 1, 2, 3, 4, 6 e 8.
O campo APAR será usado para que se possa obter a quantidade de defeitos
descobertos no ambiente de produção dos clientes. Esse critério também possibilita
descobrir a quantidade de defeitos ocorridos devido a personalizações
implementadas por esses clientes em quaisquer dos produtos da linha. Esse critério
pode ser usado para ajudar na obtenção de padrões de defeitos que possam auxiliar
na identificação, confirmação e análise das hipóteses 6, 7 e 9.
O campo estado de teste será usado para que se possa obter a incidência de
defeitos por estado de teste. Além dessa incidência, algumas análises podem ser
feitas sobre alguns valores específicos desse campo, como os defeitos já fechados,
ou os defeitos retrabalhados ou ainda os defeitos corrigidos, mas ainda não
fechados. Esse critério pode ser usado para ajudar na obtenção de padrões de
defeitos que possam auxiliar na identificação, confirmação e análise da hipótese 3.
O critério ODC atividade será usado, pois ele representa a atividade que estava
sendo feita quando se descobriu o defeito. Essa atividade pode ser mapeada para a
fase do processo de verificação que deixou o defeito escapar. Logo, esse critério
pode ser usado em conjunto com o critério gatilho para mostrar a eficácia e a
completeza do processo de verificação. Dentro do processo ODC, para cada uma
das atividades existe alguns valores do critério gatilho que podem ser usados. O
critério atividade pode ter os seguintes valores: revisão de projeto, inspeção de código, teste de unidade, teste de componente, teste de cenário/sistema. Esse
critério pode ser usado para ajudar na obtenção de padrões de defeitos que possam
auxiliar na identificação, confirmação e análise das hipóteses 1, 2, 3, 4, 5, 6, 7, 8 e
12.
O critério ODC gatilho será usado, pois através desse critério consegue-se
36 mostrar a eficácia e a completeza do processo de verificação. O processo de
verificação pode ser o teste de código ou a inspeção e/ou revisão do projeto de
software (Chillarege et al, 1992). Cada um dos valores que pode ser inserido nesse
critério pertence a (ou pode ser mapeado a) uma determinada fase do processo de
verificação que falhou e deixou o defeito em questão escapar. O critério gatilho pode
ter os seguintes valores: conformidade de projeto, lógica/fluxo, compatibilidade anterior, documentação interna, compatibilidade lateral, concorrência, dependência de linguagem, efeito colateral, situação rara, caminho simples, caminho complexo, cobertura, variação, sequenciamento, interação, carga, recuperação/exceção, inicia/reinicia, configuração de hardware, configuração de software e teste bloqueado. Esse critério pode ser usado para ajudar na
obtenção de padrões de defeitos que possam auxiliar na identificação, confirmação
e análise das hipóteses 1, 2, 3, 4, 5, 6, 7, 8 e 12.
O critério ODC alvo será usado, pois representa a identidade de alto nível do
artefato que foi corrigido. Esse alvo pode ser mapeado para a fase do processo de
desenvolvimento de software que deixou o defeito escapar. Logo, esse critério pode
ser usado em conjunto com o critério tipo do defeito para medir a eficácia desse
processo de desenvolvimento. Dentro do processo ODC, para cada um dos alvos
existe alguns valores do critério tipo do defeito que podem ser usados. O critério alvo
pode ter os seguintes valores: requisitos, projeto, código, build/pacote, desenvolvimento de informação, suporte a língua nacional. Esse critério pode
ser usado para ajudar na obtenção de padrões de defeitos que possam auxiliar na
identificação, confirmação e análise das hipóteses 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 e 12.
O critério ODC tipo de defeito será usado, pois através dele consegue-se medir o
progresso do desenvolvimento de um produto através do seu processo e também
obter-se um retorno em relação à eficácia desse processo de desenvolvimento. Isso
é possível, pois o conjunto dos tipos de defeitos é diferente o suficiente para se
cobrir todo o processo de desenvolvimento, porque esse conjunto foi montado para
ser geral o suficiente para se aplicar a vários processos de desenvolvimento de
software e porque cada um dos tipos de defeitos pode ser mapeado para a fase do
processo que deixou aquele defeito escapar (Chillarege et al, 1992). O critério tipo
de defeito pode ter os seguintes valores: atribuição/inicialização, checagem, algoritmo/método, função/classe/objeto, serialização, interface/mensagens, relacionamento. Esse critério pode ser usado para ajudar na obtenção de padrões
37 de defeitos que possam auxiliar na identificação, confirmação e análise das
hipóteses 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 e 12.
O critério ODC qualificador será usado, pois com seu uso podem-se fazer
diversas análises em relação aos defeitos encontrados. Pode-se, usando também o
atributo tipo do defeito, obter as fraquezas relacionadas aos requisitos, projeto e ao
código. Ou, em conjunto com os atributos impacto, gatilho e tipo do defeito, analisar
o uso do produto pelos clientes (He, Hao e Zhiqing, 2011). Esse critério ainda pode
ser usado em conjunto com outros critérios do método ODC para se medir a eficácia
dos testes e avaliar a estabilidade do produto (Butcher, Munro e Kratschmer, 2011).
Ele pode ser usado para ajudar na obtenção de padrões de defeitos que possam
auxiliar na identificação, confirmação e análise das hipóteses 1, 5, 11 e 12.
O critério ODC fonte será usado, pois através dele pode-se avaliar e determinar
de qual forma um elemento ou função foi introduzido no produto. Essas formas
podem ser: desenvolvido internamente, reusado de uma biblioteca, adquirido de
terceiros e portado (Bassin e Santhanam, 2001). Com essa análise, pode-se, no
trabalho em desenvolvimento, concentrar-se apenas nos artefatos desenvolvidos
internamente e reusados de bibliotecas internas, pois eles refletem o processo de
desenvolvimento da linha de produtos de software objeto de estudo desse trabalho.
Esse critério pode ser usado para ajudar na obtenção de padrões de defeitos que
possam auxiliar na identificação, confirmação e análise da hipótese 4.
O critério ODC idade será usado, pois o seu uso possibilita que se analise a
quanto tempo atrás o defeito foi adicionado no produto (Bassin e Santhanam, 2001).
Esse critério também permite avaliar a eficácia do processo de verificação, pois
defeitos introduzidos a muito tempo podem indicar uma falha ou uma cobertura
ineficiente de determinada fase desse processo. Ele pode ser usado para ajudar na
obtenção de padrões de defeitos que possam auxiliar na identificação, confirmação
e análise das hipóteses 1, 2, 4, 7, 8 e 10.
A Tabela 4 ilustra as hipóteses que podem ser identificadas, confirmadas e
analisadas por cada um dos critérios.
38 Tabela 4 - Interação entre critérios da base e hipóteses
Critérios Hipóteses
1 2 3 4 5 6 7 8 9 10 11 12
Produto X X X X X X X X X X X X
Versão X X X X X X X X X X X X
Severidade X X X X X X
APAR X X X
Estado de Teste X
Atividade X X X X X X X X X
Gatilho X X X X X X X X X
Impacto X X X X X X
Alvo X X X X X X X X X X X
Tipo do Defeito X X X X X X X X X X X
Qualificador X X X X
Fonte X
Idade X X X X X X
Uma descrição completa de todos os critérios ODC, bem como cada um dos
valores que os critérios podem ter e as explicações desses valores podem ser
encontradas em IBM Research (2002).
3.4 Avaliação da Qualidade dos Dados
Nesse item, será descrito o gabarito desenvolvido por especialistas em
classificação de defeitos usando o método ODC e que é usado pelas equipes de
desenvolvimento dos produtos que compõem a linha de produtos objeto de estudo
desse trabalho. Esse gabarito serve como referência para a classificação de cada
um dos critérios do ODC. No trabalho em desenvolvimento, esse gabarito será
usado para validar a seleção dos critérios ODC realizada no item anterior. Além
disso, uma técnica de avaliação da qualidade de dados em geral, uma técnica de
avaliação de qualidade de dados de defeitos e a realização de amostragem sobre os
dados da base de dados de defeitos serão feitos para auxiliar essa validação.
Esse gabarito é dividido em três partes. Na primeira parte, são mostrados todos
os critérios ODC que devem ser preenchidos por quem encontrou o defeito, bem
39 como os seus possíveis valores e, para cada valor, uma explicação de quando esse
valor deve ser o escolhido para o atributo em questão. Na segunda parte, são
mostrados todos os critérios ODC que devem ser preenchidos pela pessoa que
corrigiu o defeito, bem como os seus possíveis valores e, para cada valor, uma
explicação de quando esse valor deve ser o escolhido para o atributo em questão. A
terceira parte do gabarito dá dicas e conselhos gerais acerca do método ODC, bem
como explicações mais detalhadas sobre os erros mais comuns de preenchimento.
O gabarito foi montado de forma tal que os critérios mais importantes para o
método ou aqueles que possam gerar maior confusão para a seleção de um valor,
como atividade, gatilho, impacto, alvo e tipo do defeito, possuem explicações mais
detalhadas de como selecionar cada um desses valores. Logo, acredita-se que a
maior parte dos critérios ODC selecionados no item anterior esteja com seus valores
corretamente preenchidos para os defeitos presentes na base, visto que o gabarito é
amplamente adotado por todas as equipes de desenvolvimento dos produtos dessa
linha de produtos. Os critérios selecionados no item anterior e que possuem
explicações menos detalhadas no gabarito como qualificador, fonte e idade, têm
uma menor quantidade de valores e esses são de escolha mais fácil e direta. Com
isso, pode-se dizer que as chances de uma seleção de valor errada para esses
critérios é pequena.
Além do gabarito apresentado anteriormente, algumas dimensões apresentadas
por Scannapeco, Missier e Batini (2005) serão usadas para auxiliar na validação da
seleção dos critérios e na garantia da qualidade dos dados da base de dados de
defeitos. Em Scannapeco, Missier e Batini (2005), é dito que a qualidade dos dados
é multi facetada e essa qualidade deve ser avaliada levando-se em conta diferentes
dimensões. Os autores apresentam seis dimensões (precisão, completeza,
volatilidade, atualidade, coerência e consistência). As definições dessas dimensões,
todas segundo Scannapeco, Missier e Batini (2005), e uso para a validação da
seleção dos critérios e para auxiliar a verificação da qualidade de dados da base de
defeitos seguem:
- Precisão pode ser avaliada em relação a níveis de granularidades diferentes
de um modelo de dados. Essa dimensão pode ser dividida em precisão
sintática e precisão semântica. A precisão sintática é aquela que é medida
por funções de comparação que avaliam a distância de duas strings. Essa
subdivisão da dimensão precisão será escolhida para auxiliar na validação da
40
seleção dos critérios e na verificação da qualidade dos dados da base de
defeitos, pois a outra subdivisão, a precisão semântica, necessita de uma
outra base de dados para comparação, o que não se dispõe no ambiente no
qual o trabalho será executado.
- Completeza pode ser definida como a extensão no qual os dados são de
suficiente amplitude, profundidade e escopo para se realizar a tarefa
desejada. A dimensão completeza pode ser analisada em relação ao
esquema, às colunas e à população. No trabalho em questão, essa dimensão
será analisada em relação às colunas que representam os critérios
selecionados no item anterior, por ser de mais direta análise. Em relação à
completeza de coluna, deve-se medir a proporção de valores nulos em uma
coluna e, consequentemente, a proporção de valores preenchidos na mesma.
Para isso, cada um dos doze critérios levantados no item anterior terá essa
proporção medida.
- Dimensões relacionadas ao tempo: São as dimensões coerência, volatilidade
e atualidade. Elas não serão usadas para avaliar os critérios escolhidos no
item anterior, pois são fortemente associadas à variação dos dados com o
tempo.
- Consistência pode ser definida como uma dimensão que captura a violação
de regras semânticas definidas sobre itens de dados. Em referencia a teoria
relacional, as restrições de integridade são uma instanciação dessas regras
semânticas.
A técnica apresentada por Saraiya, Lohner e Baik (2006) também será usada
para ajudar na avaliação da qualidade dos dados da base de dados de defeitos.
Essa técnica, conhecida como “Matriz de Congruência“, ajuda no monitoramento da
qualidade dos dados de defeitos coletados e classificados segundo o ODC, o que
leva a uma melhora no processo de coleta desses dados e ajuda na
institucionalização do método ODC dentro das organizações. Essa matriz pode ser
normalizada por tipo de defeito ou gatilho, relaciona esses dois critérios e, cada uma
das suas células representa a probabilidade (alta, média ou baixa; na Tabela 5,
representada pelas letras A, M e B respectivamente) de se ocorrer uma combinação
dos valores das classes desses atributos. Escolheu-se a matriz normalizada por tipo
de defeito, pois esse critério ODC é preenchido quando o defeito é corrigido, logo
tem-se uma maior certeza de como preencher o seu valor, pois o problema já é
41 conhecido. A matriz será usada como referência para a verificação e validação da
classificação de cada um dos defeitos da base de dados. Com isso, pode-se verificar
se a classificação está de acordo com a probabilidade de os valores escolhidos para
os atributos tipo e gatilho acontecerem naquela combinação. A matriz de
congruência normalizada por tipo de defeito é apresentada na Tabela 5. Esta matriz
mostra em suas linhas os valores possíveis do atributos gatilho. E em suas colunas,
os valores possíveis do atributo tipo do defeito, a saber: algoritmo (ALG), atribuição
(ATR), build (BLD), checagem (CHC), documentação (DOC), função (FUN),
integração (INT) e serialização (SER).
Para montar a matriz mostrada na Tabela 5, foi aplicado, pelos autores, o seu
entendimento no processo de desenvolvimento da empresa na qual trabalhavam na
época e na sua experiência relacionada ao método ODC. Essa empresa tinha
utilizado o ODC por vários anos e em vários grupos de desenvolvimento. A primeira
matriz montada foi totalmente baseada na experiência dos autores com o método
ODC, apresentando a probabilidade de ocorrência de cada combinação de valores
dos atributos gatilho e tipo do defeito, usando os valores alto, médio e baixo. Em
uma segunda etapa foram utilizados todos os dados de defeito da empresa
classificados usando o ODC para verificar se as ocorrências de pares dos atributos
gatilho e tipo de defeito (tabela 6) eram compatíveis com a matriz proposta. Por fim,
a matriz passou por uma avaliação de vários especialistas em ODC e em
classificação de defeitos, que puderam opinar sobre a sua coerência.
42 Tabela 5 - Matriz de Congruência Normalizada por Tipo de Defeito
Gatilho Tipo do Defeito
ALG ATR BLD CHC DOC FUN INT SER
Compatibilidade Anterior A M A M B M B B
Concorrência M M B M B M B A
Consistência/Padrões de Documentos
B B B B A B B B
Dependências de Linguagem B M B B B B B B
Compatibilidade Lateral M A B M B A A A
Fases Anteriores A M B M B M M B
Situação Rara B B B B B B B M
Efeito Colateral B B B B B B B M
Fluxo / Lógica A A B A B B B B
Fonte: Saraiva, Lohner e Baik (2006)
A Tabela 6 apresenta as probabilidades, em valores percentuais, para a
classificação de cada um dos valores do atributo gatilho (linha) para um determinado
tipo de defeito (coluna).
Tabela 6 - Matriz de Congurência Normalizada por Tipo de Defeito - Probabilidade por Gatilho e Tipo
Gatilho Tipo do Defeito
ALG ATR BLD CHC DOC FUN INT SER Total
Compatibilidade Anterior 8% 5% 20% 13% 0% 12% 3% 0% 8%
Concorrência 6% 3% 20% 9% 0% 0% 3% 44% 10%
Consistência/Padrões de Documentos
3% 2% 0% 2% 67% 12% 6% 0% 4%
Dependências de Linguagem
0% 3% 0% 0% 0% 0% 0% 0% 1%
Compatibilidade Lateral 24% 33% 20% 9% 0% 48% 53% 23% 26%
Fases Anteriores 12% 21% 0% 10% 0% 12% 6% 0% 11%
Situação Rara 5% 5% 20% 10% 0% 0% 9% 10% 7%
Efeito Colateral 3% 2% 0% 4% 0% 4% 6% 21% 5%
Fluxo / Lógica 40% 26% 20% 44% 33% 12% 15% 3% 29%
Total 100% 100% 100% 100% 100% 100% 100% 100% 100%
Fonte: Saraiya, Lohner e Baik (2006)
43
3.5 Montagem das Consultas
Nesse item, os critérios selecionados no Item 3.3 serão combinados para que se
possa montar cada uma das consultas que irá ser executada sobre a base de dados
de defeitos, para se testar as hipóteses sobre os principais problemas de
manutenção ocorridos na linha de produtos em questão. Essas consultas, bem como
o seu processo de montagem, será uma das principais contribuições do trabalho em
questão.
Esses critérios serão combinados visando-se obter padrões de defeitos que
auxiliem no entendimento das hipóteses levantadas no Item 3.3. Para isso, serão
apresentados, abaixo, as combinações dos critérios para cada uma das hipóteses a
serem testadas:
- Hipótese 1: Para as equipes de desenvolvimento fica muito difícil fazer algum
tipo de alteração ou melhoria com a segurança de que as mesmas não irão
gerar impacto.
- Em todas as consultas, o critério idade terá seu valor fixado como “novo“,
para se garantir a recuperação dos defeitos gerados por alterações ou
melhorias.
- Os critérios produto, versão, impacto, qualificador e idade serão
combinados para se montar consultas que mostrem os defeitos gerados
por alterações e melhorias, por versão, por versão e produto e por versão,
produto e impacto.
- Os critérios produto, versão, impacto, qualificador, idade, atividade e
gatilho serão combinados para se montar consultas que mostrem as falhas
do processo de verificação, através dos critérios atividade e gatilho, que
deixaram os defeitos gerados por alterações e melhorias escaparem, por
versão, por versão e produto e por versão, produto e impacto.
- A Tabela 7 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
44 Tabela 7 - Consultas da hipótese 1
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
1.1 X X X
1.2 X X X X
1.3 X X X X
1.4 X X X X X
1.5 X X X X X
1.6 X X X X X X
1.7 X X X X X X
1.8 X X X X X X X
- Hipótese 2: O código, o projeto e as decisões arquiteturais das correções e
das novas funcionalidades são feitos sem uma análise de impacto em outras
partes do produto e em outros produtos da linha.
- Em todas as consultas, o critério idade terá seu valor fixado em “novo“,
para se garantir a recuperação dos defeitos gerados por novas
funcionalidades e o critério alvo terá seu valor fixado em “requisito“,
“código“ ou “projeto“, para se garantir a recuperação de defeitos gerados
por alterações no código, no projeto ou na arquitetura.
- Os critérios produto, versão, impacto, idade, alvo, atividade e gatilho serão
combinados para se montar consultas que mostrem as falhas do processo
de verificação, através dos critérios atividade e gatilho, que deixaram
defeitos gerados por correções e desenvolvimento de novas
funcionalidades escaparem, por versão, por versão e produto e por
versão, produto e impacto.
- Os critérios produto, versão, impacto, idade, alvo e tipo de defeito serão
combinados para se montar consultas que mostrem as fases do processo
de desenvolvimento, através dos atributos alvo e tipo do defeito, que
deixaram os defeitos gerados por correções e desenvolvimento de novas
funcionalidades, escaparem, por produto, por versão e produto e por
versão, produto e impacto.
45
- A Tabela 8 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 8 - Consultas da hipótese 2
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
2.1 X X X X X X
2.2 X X X X X X X
2.3 X X X X X
2.4 X X X X X X
- Hipótese 3: Correções de defeitos podem não corrigir o problema.
- Em todas as consultas, o critério severidade terá seu valor fixado em “1“
ou “2“, para se garantir a recuperação dos defeitos de maior impacto para
os clientes e o critério estado de teste terá seu valor fixado em
“retrabalho“, para se garantir a recuperação de defeitos que não corrigiram
os problemas.
- Os critérios produto, versão, severidade e estado de teste serão
combinados para se montar consultas que mostrem os defeitos, que
tiveram correções anteriores que não tenham corrigido o problema, por
produto, versão e severidade.
- Os critérios produto, versão, severidade, estado de teste, atividade e
gatilho serão combinados para se montar consultas que mostrem as falhas
do processo de verificação, através dos critérios atividade e gatilho, que
deixaram defeitos, que tiveram correções anteriores que não tenham
corrigido o problema, escaparem, por produto, versão e severidade do
mesmo.
- Os critérios produto, versão, severidade, estado de teste, alvo e tipo de
defeito serão combinados para se montar consultas que mostrem as fases
do processo de desenvolvimento, através dos atributos alvo e tipo do
46
defeito, que deixaram os defeitos, que tiveram correções anteriores que
não tenham corrigido o problema, escaparem, por produto, versão e
severidade do mesmo.
- A Tabela 9 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 9 - Consultas da hipótese 3
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
3.1 X X X
3.2 X X X X
3.3 X X X X X
3.4 X X X X X X
3.5 X X X X X
3.6 X X X X X X
- Hipótese 4: Desenvolvimentos de novas funcionalidades tornam o ambiente
instável.
- Em todas as consultas, o critério severidade terá seu valor fixado em “1“
ou “2“, para se garantir a recuperação dos defeitos de maior impacto para
os clientes e o critério idade terá seu valor fixado em “novo“, para se
garantir a recuperação de defeitos gerados por novas funcionalidades.
- Os critérios produto, versão, severidade e idade serão combinados para
se montar consultas que mostrem os defeitos relativos a novas
funcionalidades de determinados produtos que deixem o ambiente instável
por produto e produto e versão.
- Os critérios produto, versão, severidade, idade, atividade e gatilho serão
combinados para se montar consultas que mostrem as falhas do processo
de verificação, através dos critérios atividade e gatilho, que deixaram
defeitos relativos a novas funcionalidades de determinados produtos que
47
deixem o ambiente instável escaparem, por versão e severidade do
mesmo.
- Os critérios produto, versão, severidade, idade, alvo, tipo de defeito e fonte
também serão combinados para se montar consultas que mostrem as
fases do processo de desenvolvimento, através dos atributos alvo e tipo
do defeito, que deixaram os defeitos relativos a novas funcionalidades de
determinados produtos que deixem o ambiente e instável escaparem, por
produto, versão e severidade do mesmo.
- A Tabela 10 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 10 - Consultas da hipótese 4
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
4.1 X X X
4.2 X X X X
4.3 X X X X X
4.4 X X X X X X
4.5 X X X X X X
4.6 X X X X X X X
- Hipótese 5: Desenvolvimento de novas funcionalidades não atendem aos
requisitos.
- Em algumas as consultas, o critério alvo terá seu valor fixado em “projeto“
ou “requisito“, para se garantir a recuperação dos defeitos gerados por
requisitos e o critério qualificador terá seu valor fixado em “faltando“ ou
incorreto”, para se garantir a recuperação de defeitos relacionados à falta
de implementação ou implementação incorreta de requisitos.
- Em algumas as consultas, o critério alvo terá seu valor fixado em “código“,
o critério tipo de defeito terá seu valor fixado em “função“, para se garantir
48
a recuperação dos defeitos gerados por requisitos e o critério qualificador
terá seu valor fixado em “faltando“ ou incorreto”, para se garantir a
recuperação de defeitos relacionados à falta de implementação ou
implementação incorreta desses requisitos.
- Os critérios produto, versão, atividade, gatilho, alvo, tipo de defeito e
qualificador serão combinados para se montarem consultas que mostrem
os principais problemas relacionados aos requisitos e qual foi natureza das
falhas do processo de verificação que deixaram esses defeitos escapar
por produto e produto e versão.
- A Tabela 11 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 11 - Consultas da hipótese 5
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
5.1 X X X X X
5.2 X X X X X X
5.3 X X X X X X
5.4 X X X X X X X
- Hipótese 6: Em determinadas versões de determinados produtos, muitos
defeitos escapam para os clientes.
- Em todas as consultas, o critério severidade terá seu valor fixado em “1“
ou “2“, para se garantir a recuperação dos defeitos de maior impacto para
os clientes e o critério APAR deverá ser diferente de vazio, para se
garantir a recuperação de defeitos descobertos em ambiente de cliente.
- Os critérios APAR, produto, versão e severidade serão combinados para
se montar consultas que mostrem os defeitos que escapam para o cliente
por produto, versão e severidade, por produto e severidade e por versão e
severidade.
49
- Os critérios APAR, produto, versão, severidade, atividade e gatilho
também serão combinados para se montar consultas que mostrem as
falhas do processo de verificação, através dos critérios atividade e gatilho,
que deixaram os defeitos escapar, por produto, versão e severidade do
mesmo.
- Os critérios APAR, produto, versão, severidade, alvo e tipo de defeito
também serão combinados para se montar consultas que mostrem as
fases do processo de desenvolvimento, através dos atributos alvo e tipo
do defeito, que deixaram os defeitos escaparem, por produto, versão e
severidade do mesmo.
- A Tabela 12 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 12 - Consultas da hipótese 6
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
6.1 X X X
6.2 X X X X
6.3 X X X X X
6.4 X X X X X X
6.5 X X X X X
6.6 X X X X X X
- Hipótese 7: Muitos defeitos que escapam para clientes demoram muito tempo
para serem corrigidos.
- Consulta 7.1: Os critérios APAR , que deverá ter seu valor diferente de
vazio, para se garantir a recuperação de defeitos descobertos em
ambiente de cliente e idade serão combinados para se montar uma
consulta que mostre quanto tempo cada defeito demorou para ser
corrigido.
50
- Em todas as demais consultas, o critério APAR deverá ser diferente de
vazio, para se garantir a recuperação de defeitos descobertos em
ambiente de cliente e o critério idade deverá ter seu valor fixado em
“velho“ ou “reescrito“, para se garantir a recuperação de defeitos antigos.
- Os critérios APAR, idade, produto e versão serão combinados para se
montar consultas que mostrem por produto e versão quanto tempo cada
defeito demorou para ser corrigido.
- Os critérios APAR, idade, produto, versão, atividade e gatilho serão
combinados para se montar consultas que mostrem quanto tempo defeitos
demoraram para ser corrigidos por produto, versão e por cada uma das
falhas do processo de verificação, através dos critérios atividade e gatilho,
que deixaram esses defeitos escapar.
- Os critérios APAR, idade, produto, versão, alvo e tipo de defeito serão
combinados para se montar consultas que mostrem quanto tempo defeitos
demoraram para ser corrigidos por produto, versão e por cada uma das
fases do processo de desenvolvimento, através dos atributos alvo e tipo
do defeito, que deixaram os defeitos escaparem.
- A Tabela 13 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 13 - Consultas hipótese 7
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
7.1 X X
7.2 X X X
7.3 X X X X
7.4 X X X X X
7.5 X X X X X X
7.6 X X X X X
7.7 X X X X X X
51
- Hipótese 8: Vários defeitos de baixa e média severidade (severidades 3 e 4)
não são corrigidos dentro da iteração nos quais eles foram descobertos.
- Em todas as consultas, o critério severidade terá seu valor fixado em “3“
ou “4, para se garantir a recuperação dos defeitos de menor impacto e o
critério idade terá seu valor fixado em “velho“ ou “reescrito”, para se
garantir a recuperação de defeitos antigos.
- Os critérios produto, versão, severidade e idade serão combinados para
se montar consultas que mostrem os defeitos de cada uma das
severidades (3 e 4) que não são corrigidos dentro da própria iteração por
produto e versão.
- Os critérios produto, versão, severidade, idade, atividade e gatilho serão
combinados para se montar consultas que mostrem os defeitos de cada
uma das severidades (3 e 4) que não são corrigidos dentro da própria
iteração por produto, versão e cada uma das falhas do processo de
verificação, através dos critérios atividade e gatilho, que deixaram esses
defeitos escaparem.
- Os critérios produto, versão, severidade, idade, alvo e tipo de defeito serão
combinados para se montar consultas que mostrem os defeitos de cada
uma das severidades (3 e 4) que não são corrigidos dentro da própria
iteração por produto, versão e por cada uma das fases do processo de
desenvolvimento que deixaram os defeitos escaparem.
- A Tabela 14 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
52 Tabela 14 - Consultas da hipótese 8
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
8.1 X X X
8.2 X X X X
8.3 X X X X X
8.4 X X X X X X
8.5 X X X X X
8.6 X X X X X X
- Hipótese 9: Alguns defeitos abertos por clientes são resolvidos como tal
mesmo sem se ter certeza de serem defeitos ou pedidos de melhoria.
- Em todas as consultas, através dos critérios alvo e tipo do defeito poder-
se-á ter ideia de se o mesmo é um defeito ou um pedido de melhoria. E o
critério APAR deverá ter seu valor diferente de vazio, para se garantir a
recuperação de defeitos descobertos em ambiente de cliente.
- Os critérios APAR, produto, versão, alvo e tipo de defeito serão
combinados para se montar consultas que mostrem as fases do processo
de desenvolvimento, através dos atributos alvo e tipo do defeito, que
deixaram os defeitos escaparem para os clientes, por produto, versão e
produto e versão.
- A Tabela 15 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
53 Tabela 15 - Consultas da hipótese 9
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
9.1 X X X X
9.2 X X X X X
- Hipótese 10: A manutenção do código legado é complicada devido à
inexistência de documentação técnica e não-funcional.
- Em todas as consultas, o critério idade terá seu valor fixado em “base“,
para se garantir a recuperação de defeitos gerados por artefatos legados e
o critério alvo terá seu valor fixado em “código”, para garantir a
recuperação de defeitos gerados pelo código.
- Os critérios produto, versão, idade e alvo serão combinados para se
montar consultas que mostrem problemas em código legado por produto e
por produto e versão.
- Os critérios produto, versão, idade, alvo e tipo do defeito serão
combinados para se montar consultas que mostrem problemas em código
legado por produto, versão e natureza, através dos atributos alvo e tipo do
defeito, das correções.
- A Tabela 16 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 16 - Consultas da hipótese 10
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
10.1 X X X
10.2 X X X X
10.3 X X X X
10.4 X X X X X
54
- Hipótese 11: Falta de conhecimento das regras de negócio dos serviços do
software base pelos gerentes do produto.
- Em todas as consultas, o critério alvo terá seu valor fixado em “requisitos“
ou “projetos“, para se garantir a recuperação de defeitos gerados por
requisitos e projetos e o critério qualificador terá seu valor fixado em
“faltando“ ou “incorreto“, para garantir a recuperação de defeitos gerados
por falta ou implementação errada.
- Os critérios produto, versão, alvo, tipo de defeito e qualificador serão
combinados para se montar consultas que mostrem problemas
relacionados à natureza, através dos atributos alvo e tipo do defeito, das
correções dos defeitos, aos requisitos e ao projeto, por produto e versão.
- A Tabela 17 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 17 - Consultas da hipótese 11
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
11.1 X X X X
11.2 X X X X X
- Hipótese 12: Os software base e os específicos são traduzidos para vários
idiomas, o que pode gerar defeitos específicos em alguns idiomas que não
são classificados como tal.
- Em todas as consultas, o critério alvo terá seu valor fixado em “suporte a
idioma nacional“, para se garantir a recuperação de defeitos relacionados
a software em vários idiomas e o critério qualificador terá seu valor fixado
em “faltando“ ou “incorreto“, para garantir a recuperação de defeitos
gerados por falta ou implementação errada.
55
- Os critérios produto, versão, alvo, tipo de defeito e qualificador serão
combinados para se montar consultas que mostrem problemas
relacionados à tradução do software para vários idiomas por produto e
versão.
- Os critérios produto, versão, alvo, tipo de defeito, qualificador, atividade e
gatilho serão combinados para se montar consultas que mostrem as falhas
do processo de verificação, através dos critérios atividade e gatilho, que
deixaram os defeitos relacionados à tradução do software para vários
idiomas escaparem, por produto e versão.
- A Tabela 18 mostra os critérios que serão combinados, para se gerar cada
uma das consultas:
Tabela 18 - Consultas da hipótese 12
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
12.1 X X X X
12.2 X X X X X
12.3 X X X X X
12.4 X X X X X X
3.6 Conclusão
Neste capítulo, foram apresentados a descrição e o detalhamento da estrutura da
base de dados de defeitos, incluindo-se os campos usados para os critérios do
método ODC.
Posteriormente, foram apresentadas as principais hipóteses que levam aos
problemas que se deseja resolver, a seleção dos critérios que serão usados para a
obtenção dos padrões de defeitos que possam auxiliar no entendimento desses
problemas e a justificativa para a seleção desses critérios.
56
Além disso, também foram mostrados um gabarito usado para auxiliar no
preenchimento dos critérios ODC e duas técnicas encontradas na literatura para
garantir a qualidade dos dados da base de defeitos e validar a seleção de critérios.
Finalmente, a montagem das consultas baseadas na combinação dos critérios
previamente selecionados foi apresentada.
57 4 EXECUÇÃO DAS CONSULTAS
4.1 Introdução
Este capítulo mostra a execução das consultas, definidos no capítulo anterior e
que visam a comprovação da qualidade dos dados da base de dados de defeitos. O
capítulo também apresenta a execução das diversas consultas, previamente
definidas, sobre a base de dados para se obter padrões de defeitos que auxiliem na
identificação e resolução dos problemas mencionados na motivação do trabalho. Por
fim, são mostrados os resultados obtidos com essas execuções e a análise desses
resultados.
4.2 Testes - Qualidade de Dados
No capítulo anterior, algumas dimensões para avaliação da qualidade de dados,
proposta por Scannapeco, Missier e Batini (2005), foram apresentadas. Testes
foram realizados, sobre a base de dados de defeitos, usando-se as dimensões
propostas. A seguir, são apresentados os resultados desses testes, bem como
algumas conclusões acerca da qualidade de dados da base sob esses pontos de
vista:
- Precisão: A precisão sintática foi escolhida para auxiliar na verificação da
qualidade dos dados da base de defeitos, pois a outra subdivisão, a precisão
semântica, necessita de uma outra base de dados para comparação. Como
12 dos 13 critérios da base de dados de defeitos, selecionados no capítulo
anterior são apresentados para o usuário em lista de valores, acredita-se que
essa base de dados possua um alto índice de precisão sintática.
- Completeza: No trabalho em questão, essa dimensão foi analisada em
relação às colunas que representam os critérios selecionados no Item 3.3
deste trabalho. Em relação à completeza de coluna, deve-se medir a
proporção de valores nulos em uma coluna e, consequentemente, a
58
proporção de valores preenchidos na mesma. Para isso, cada um dos doze
critérios levantados no Item 3.3 terá essa proporção medida.
- Produto: 0/155429 defeitos – 0% de valores nulos – 100% de
completeza.
- Versão: 0/155429 defeitos – 0% de valores nulos – 100% de
completeza.
- Severidade: 0/155429 defeitos – 0% de valores nulos – 100% de
completeza.
- Impacto: 142843/155429 defeitos – 91% de valores nulos – 9% de
completeza. Mas esse critério só faz sentido para defeitos abertos por
clientes. Em relação aos defeitos descobertos por clientes, tem-se
881/9535 defeitos – 9% de valores nulos – 91% de completeza.
- Atividade: 11171/155429 defeitos - 7% de valores nulos - 93% de
completeza.
- Gatilho: 12569/155429 defeitos – 8% de valores nulos - 92% de
completeza.
- Alvo: 32144/155429 defeitos – 20% de valores nulos - 80% de
completeza.
- Tipo do Defeito: 38294/155429 defeitos – 24% de valores nulos - 76%
de completeza.
- Qualificador: 39194/155429 defeitos – 25% de valores nulos - 75% de
completeza.
- Fonte: 39816/155429 defeitos – 26% de valores nulos - 74% de
completeza.
- Idade: 40011/155429 defeitos – 26% de valores nulos - 76% de
completeza.
Logo, para os critério selecionados no Item 3.3, excluindo-se os critérios que
são relacionados apenas a defeitos abertos por clientes, tem-se 14% de
valores nulos e 84% de completeza de coluna, que é entendido como um alto
grau de completeza.
- Dimensões relacionadas ao tempo: Elas não serão usadas para avaliar os
critérios escolhidos no item anterior, pois são fortemente associadas à
variação dos dados com o tempo. E, no trabalho em questão, os dados da
base de dados de defeitos selecionados são aqueles que já foram revisados
59
pelo time de revisão. Logo, esses dados não serão mais alterados, sendo
dados de histórico.
- Consistência: Como, a base de dados de defeitos é implementadas como
uma série de tabelas que seguem o modelo relacional e que possuem as
restrições de integridade, como restrição de chave, restrição de entidade,
integridade de vazio, integridade referencial, entre outras, aplicadas no
próprio modelo e na instanciação do mesmo, podemos dizer que existe uma
garantia de qualidade de dados sob a ótica da dimensão consistência.
No Capítulo 3, também foi apresentada uma técnica que ajuda no monitoramento
da qualidade dos dados de defeitos coletados e classificados segundo o método
ODC. Essa técnica, apresentada por Saraiya, Lohner e Baik (2006), é conhecida
como “Matriz de Congruência“. Um teste sobre os dados foi realizado e os
resultados serão apresentados para se ter mais uma evidência de que os dados
cadastrados na base de defeitos são confiáveis. Consultas foram realizadas na base
de dados de defeitos para se levantar uma distribuição de todos esses defeitos por
cada célula da matriz de congruência. Os resultados são apresentados, nas tabelas
abaixo, em números absolutos (Tabela 19) e relativos (Tabela 20):
Tabela 19 - Matriz de Congruência - Valores absolutos da distribuição de defeitos
Gatilho Tipo do Defeito
ALG ATR BLD CHC DOC FUN INT SER
Compatibilidade Anterior 6615 523 3500 2390 0 0 789 0
Concorrência 1026 545 3 700 0 765 520 6509
Consistência/Padrões de Documentos
0 0 12 13 2230 344 450 0
Dependências de Linguagem
1569 9192 0 3490 500 280 344 0
Compatibilidade Lateral 2092 7550 0 0 12 278 10909 7790
Fases Anteriores 8901 1230 0 4500 15 1123 1090 12
Situação Rara 523 1569 0 5098 10 234 456 5300
Efeito Colateral 1026 2615 123 3981 0 765 1909 5599
Fluxo / Lógica 15090 7845 56 8901 0 2109 3409 0
Total 36842 31069 3694 29073 2767 5898 19876 25210
60 Tabela 20 - Matriz de Congruência – Valores relativos da distribuição de defeitos
Gatilho Tipo do Defeito
ALG ATR BLD CHC DOC FUN INT SER
Compatibilidade Anterior 19% 2% 94% 8% 0% 0% 4% 0%
Concorrência 3% 2% 0,5% 2% 0% 13% 3% 26%
Consistência/Padrões de Documentos
0% 0% 0,5% 0,05% 80,7%
6% 2% 0%
Dependências de Linguagem
4% 30% 0 12% 18% 5% 2% 0%
Compatibilidade Lateral 6% 24% 0 0% 0,4% 5% 55% 31%
Fases Anteriores 24% 4% 0 15% 0,5% 19% 5% 0,05%
Situação Rara 1% 5% 0 17% 0,4% 4% 2% 21%
Efeito Colateral 3% 8% 3% 13% 0% 13% 10% 21,95
%
Fluxo / Lógica 40% 25% 2% 32,95
% 0% 35% 17% 0%
Total 100% 100% 100% 100% 100
% 100% 100% 100%
Comparando os valores obtidos na matriz com os percentuais da distribuição de
defeitos da base utilizada com a matriz normalizada, pode-se concluir que do total
das 72 casas da matriz de congruência, 82% delas apresentaram resultados
compatíveis. Esse índice ajuda na conclusão de que os valores escolhidos para os
critérios ODC, selecionados no Item 3.3, possuem um índice de confiabilidade que
possibilita o uso desses critérios para o que é proposto por este trabalho.
A coluna do tipo de defeito função, na Tabela 20, foi a única que teve seus
valores discrepantes significativamente em relação à Tabela 5. Após consulta a
especialistas do método ODC, chegou-se à conclusão de que isso se deve a uma
confusão existente no preenchimento dos tipos de defeitos algoritmo e função.
Esses dois tipos de defeitos são relacionados à problemas no código, mas o tipo
defeito função também requer mudanças no projeto. A confusão dá-se pelo próprio
nome, função, que é confundido com uma função ou método de um código. Assim,
presume-se que a confiabilidade dos dados de defeito do tipo função é pior que a
dos demais tipos.
61
4.3 Consultas Gerais na Base de Dados
Essa seção apresentará a execução e os resultados das consultas mais gerais
sobre a base de dados de defeitos. Com isso, espera-se obter alguns padrões de
defeitos mais genéricos que poderão confirmar algumas das hipóteses levantadas
no Item 3.3 e que poderão ser usados como um guia para a montagem das
consultas mais específicas. A Tabela 21 apresenta o número de defeitos por
severidade.
Tabela 21 – Defeitos por Severidade
Severidade Quantidade %
Severidade 1 44008 28%
Severidade 2 70335 45%
Severidade 3 37114 24%
Severidade 4 3972 3%
Total 155429 100%
Os defeitos de severidade 2, aqueles que bloqueiam a execução de um caso de
teste ou que são de alto impacto para os clientes, mas que possuem uma alternativa
são os mais frequentes para a linha de produtos objeto de estudo deste trabalho,
representando cerca de 45% do total de defeitos cadastrados na base. Os defeitos
de severidade 1, aqueles que bloqueiam a execução de um caso de teste ou que
são de alto impacto para os clientes e não possuem uma alternativa representam
cerca de 28% do total de defeitos cadastrados na base.
A Tabela 22 apresenta o número de defeitos descobertos em clientes por
severidade.
Tabela 22 – Defeitos Descobertos em Clientes por Severidade
Severidade Quantidade %
62
Severidade Quantidade %
Severidade 1 2480 26%
Severidade 2 4419 46%
Severidade 3 2248 23%
Severidade 4 438 5%
Total 9585 100%
Entre os defeitos descobertos por clientes em seus ambientes, os defeitos de
severidade 2 também são os mais frequentes, com aproximadamente 46% do total
de defeitos descobertos por clientes para a linha de produtos em questão. Os
defeitos de severidade 1 representam cerca de 26% do total de defeitos cadastrados
na base e que foram descobertos por clientes em seus ambientes.
A Tabela 23 apresenta o número de defeitos por produto.
Tabela 23 – Defeitos por Produto
Produto Quantidade
Produto Núcleo(Core) 114827
Produto A 3248
Produto B 484
Produto C 353
Produto D 206
Produto E 3945
Produto F 2529
Produto G 514
Produto H 4519
Produto I 312
Produto J 3751
Produto K 6433
Produto L 1298
Produto M 703
Produto N 705
Produto O 4297
Produto P 1100
Produto Q 6169
63
Na comparação dos defeitos descobertos por produto, o software base dessa
linha de produtos é aquele que contribui com o maior número de defeitos, com um
total de 73% de todos os defeitos cadastrados para a linha.
A Tabela 24 apresenta o número de defeitos descobertos em cliente por produto.
Tabela 24 – Defeitos Descobertos em Cliente por Produto
Produto Quantidade
Produto Núcleo(Core) 7592
Produto A 352
Produto B 3
Produto C 18
Produto D 0
Produto E 266
Produto F 262
Produto G 2
Produto H 268
Produto I 49
Produto J 102
Produto K 0
Produto L 47
Produto M 109
Produto N 38
Produto O 201
Produto P 37
Produto Q 339
Na comparação dos defeitos descobertos nos ambientes dos clientes, por
produto, o software base dessa linha de produtos também é aquele que contribui
com o maior número de defeitos, com um total de 78% de todos os defeitos
descobertos por clientes em seus ambientes de produção para a linha de produto de
software em questão.
A Tabela 25 apresenta o número de defeitos por produto e severidade.
64
Tabela 25 – Defeitos por Produto e Severidade
Produto Quantidade/Severidade
1
Quantidade/Severidade
2
Quantidade/Severidade
3
Quantidade/Severidade
4
Produto Núcleo (Core) 32019 52854 26975 1979
Produto A 1014 1398 708 164
Produto B 43 209 210 22
Produto C 127 123 79 24
Produto D 5 83 82 26
Produto E 1039 1739 1033 134
Produto F 640 1020 773 96
Produto G 66 157 178 113
Produto H 1212 1856 1172 279
Produto I 117 110 78 7
Produto J 654 1658 1141 298
Produto K 2984 2327 1120 2
Produto L 215 596 356 131
Produto M 189 314 159 41
Produto N 160 314 196 35
Produto O 1563 1727 796 211
Produto P 160 458 352 130
Produto Q 1801 2401 1706 261
Os defeitos de severidade 2, aqueles que bloqueiam uma execução de um caso
de teste ou que são de alto impacto para os clientes, mas que possuem um contorno
são os mais frequentes para 13 dos 18 produtos que compõem a linha de produto
objeto de estudo deste trabalho.
A Tabela 26 apresenta o número de defeitos descobertos em clientes por produto
e severidade.
Tabela 26 – Defeitos Descobertos em Cliente por Produto e Severidade
Produto Quantidade/Severidade
1
Quantidade/Severidade
2
Quantidade/Severidade
3
Quantidade/Severidade
4
65
Produto Quantidade/Severidade
1
Quantidade/Severidade
2
Quantidade/Severidade
3
Quantidade/Severidade
4
Produto A 76 115 47 14
Produto B 0 3 0 0
Produto C 9 5 4 0
Produto D NA NA NA NA
Produto E 72 116 59 18
Produto Núcleo(Core) 1884 3464 1875 369
Produto F 47 164 46 5
Produto G 0 2 0 0
Produto H 48 147 60 13
Produto I 27 14 8 0
Produto J 35 38 25 4
Produto K NA NA NA NA
Produto L 15 22 8 2
Produto M 57 36 16 0
Produto N 17 16 5 0
Produto O 72 95 29 5
Produto P 12 18 7 0
Produto Q 109 162 60 8
Os defeitos de severidade 2 são os mais frequentemente descobertos por
clientes em seus ambientes em 11 dos 18 produtos que compõem a linha de produto
objeto de estudo deste trabalho.
A Tabela 27 apresenta o número de defeitos do produto núcleo por versão e
severidade.
Tabela 27 – Defeitos do Produto Núcleo por Versão e Severidade
Versão Quantidade/Severidade
1
Quantidade/Severidade
2
Quantidade/Severidade
3
Quantidade/Severidade
4
6 9000 9020 3154 94
6.1 1831 1407 553 56
6.2 18218 26436 13164 1105
6.3 48 15 15 0
66
Versão Quantidade/Severidade
1
Quantidade/Severidade
2
Quantidade/Severidade
3
Quantidade/Severidade
4
6.4 150 23 6 0
6.5 474 293 187 27
6.6 6 3 0 0
7.1 17615 27237 15354 2620
7.5 1521 2871 2479 447
O produto que mais contribui com o número de defeitos, o software base dessa
linha de produto concentra a maior parte dos seus defeitos nas versões 6.2 e 7.1.
Além disso, em cada uma dessas versões os defeitos de severidade 2 são os mais
frequentes.
Os defeitos de severidade 2, que acontecem no software base da linha de
produto em questão e, principalmente, nas versões 6.2 e 7.1 do mesmo são aqueles
com maior incidência de acordo com as análises mais gerais feitas nesta seção.
4.4 Consultas por hipótese de problema
Nesse item, os resultados das consultas usadas para se responder as hipóteses
de problemas levantadas no item 3.3 serão apresentados. Com esses resultados,
serão obtidos os padrões de defeitos que possam auxiliar na identificação e análise
dos problemas relacionados à manutenção corretiva e evolutiva em linhas de
produtos de software.
4.4.1 – Hipótese 1
Para a hipótese 1, os critérios idade, produto, versão, qualificador, impacto,
atividade e gatilho foram combinados para se recuperar os defeitos gerados por
alterações ou melhorias e para mostrar as falhas do processo de verificação que
67 deixaram estes defeitos escaparem.
Tabela 28 - Resultados da consulta 1.1
Produto Qualificador Quantidade de defeitos
Produto Núcleo Incorreto 7050
Produto Núcleo Faltando 4944
Produto Q Incorreto 2916
Produto J Faltando 2352
Produto O Incorreto 2322
Produto J Incorreto 1908
Produto P Incorreto 1728
Produto F Incorreto 1596
Produto O Faltando 1476
Produto H Incorreto 1428
A consulta 1.1, resumida na Tabela 28, mostra que os produtos que mais geram
defeitos por alterações ou melhorias são o Produto Núcleo, o Produto Q, o Produto J
e o Produto O e que a totalidade desses defeitos se deve a implementações
incorretas ou omitidas.
Tabela 29 - Resultados da consulta 1.2
Produto Impacto Qualificador Quantidade de defeitos
Produto Núcleo Capacidade (Capability)
Incorreto 4212
Produto Núcleo Capacidade (Capability)
Faltando 2424
Produto Q Capacidade (Capability)
Incorreto 1914
Produto J Capacidade (Capability)
Faltando 1908
Produto O Capacidade (Capability)
Incorreto 1650
Produto J Capacidade (Capability)
Incorreto 1536
Produto F Capacidade Incorreto 1320
68
Produto Impacto Qualificador Quantidade de defeitos (Capability)
Produto P Capacidade (Capability)
Incorreto 1182
Produto O Capacidade (Capability)
Faltando 1140
Produto Núcleo Usabilidade Incorreto 1104
A consulta 1.2, resumida na Tabela 29, mostra que os defeitos encontrados
causam ou causariam impacto para os clientes relacionados à habilidade de realizar
as funções pretendidas (Capacidade) e à facilidade de uso do sistema (Usabilidade).
Tabela 30 - Resultados da consulta 1.3
Produto Versão Qualificador Quantidade de defeitos
Produto Núcleo 7.5.1 Incorreto 2202
Produto Núcleo 7.5 Incorreto 1632
Produto Q 7.1.1 Incorreto 1608
Produto Núcleo 7.5.0.1 Incorreto 1380
Produto Núcleo 7.5.0.1 Faltando 1260
Produto Núcleo 7.5 Faltando 1092
Produto F 7.1.1 Incorreto 984
Produto Núcleo 7.5.1 Faltando 978
Produto P 7.1.1 Incorreto 972
Produto O 7.1.2 Incorreto 966
A consulta 1.3, resumida na Tabela 30, identifica as versões dos produtos que
mais geram defeitos por alterações ou melhoria: versões 7.5.1, 7.5 e 7.5.0.1 do
produto núcleo, versão 7.1.1 do produto Q, versão 7.1.1 do produto J e a versão
7.1.2 do produto O, e que a totalidade desses defeitos se devem a implementações
incorretas ou omitidas.
69 Tabela 31 - Resultados da consulta 1.4
Produto Versão Impacto Qualificador Quantidade de defeitos
Produto Núcleo 7.5.1 Capacidade (Capability)
Incorreto 1722
Produto Q 7.1.1 Capacidade (Capability)
Incorreto 1236
Produto Núcleo 7.5 Capacidade (Capability)
Incorreto 1104
Produto F 7.1.1 Capacidade (Capability)
Incorreto 828
Produto O 7.1.2 Capacidade (Capability)
Incorreto 774
Produto P 7.1.1 Capacidade (Capability)
Incorreto 732
Produto Núcleo 7.5 Capacidade (Capability)
Faltando 726
Produto J 7.1.1 Capacidade (Capability)
Faltando 726
Produto Núcleo 7.5.0.1 Capacidade (Capability)
Incorreto 648
Produto Núcleo 7.5.1 Capacidade (Capability)
Faltando 636
A consulta 1.4, resumida na Tabela 31, mostra que a totalidade dos defeitos
encontrados se deve a implementações incorretas ou omitidas e que os mesmos
causam ou causariam impacto para os clientes relacionados à habilidade de se
realizar as funções pretendidas (Capacidade).
Tabela 32 - Resultados da consulta 1.5
Produto Atividade Gatilho Qualificador Quantidade de defeitos
Produto Núcleo CVT Cobertura Incorreto 2052
Produto J CVT Cobertura Faltando 1776
Produto Q CVT Cobertura Incorreto 1488
Produto O CVT Cobertura Incorreto 1440
Produto Núcleo CVT Sequenciamento Incorreto 1410
Produto Núcleo CVT Cobertura Faltando 1350
Produto J CVT Cobertura Incorreto 1296
70
Produto Atividade Gatilho Qualificador Quantidade de defeitos
Produto Núcleo CVT Interação Incorreto 1254
Produto F CVT Cobertura Incorreto 1230
Produto P CVT Cobertura Incorreto 1074
A consulta 1.5, resumida na Tabela 32, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria dos defeitos gerados por
alterações ou melhorias escaparem são relacionados aos testes de verificação de
componentes (CVT), principalmente na execução de funções simples (Cobertura),
na execução de funções nas quais a ordem interessa (Sequenciamento) e na
execução de duas ou mais funções relacionadas (Interação).
Tabela 33 - Resultados da consulta 1.6
Produto Atividade Gatilho Impacto Qualificador Quantidade de defeitos
Produto J CVT Cobertura Capacidade (Capability)
Faltando 1530
Produto Núcleo
CVT Cobertura Capacidade (Capability)
Incorreto 1308
Produto Q CVT Cobertura Capacidade (Capability)
Incorreto 1170
Produto J CVT Cobertura Capacidade (Capability)
Incorreto 1164
Produto O CVT Cobertura Capacidade (Capability)
Incorreto 1128
Produto F CVT Cobertura Capacidade (Capability)
Incorreto 1020
Produto Núcleo
CVT Sequenciamento Capacidade (Capability)
Incorreto 1008
Produto P CVT Cobertura Capacidade (Capability)
Incorreto 864
Produto Núcleo
CVT Interação Capacidade (Capability)
Incorreto 858
Produto Núcleo
CVT Cobertura Capacidade (Capability)
Faltando 756
A consulta 1.6, resumida na Tabela 33, mostra, por produto e impacto no cliente,
71 que as principais falhas do processo de verificação que deixaram a maioria dos
defeitos gerados por alterações ou melhorias escaparem são relacionadas aos
testes de verificação de componentes (CVT), principalmente na execução de
funções simples (Cobertura), na execução de funções nas quais a ordem interessa
(Sequenciamento) e na execução de duas ou mais funções relacionadas (Interação).
Tabela 34 - Resultados da consulta 1.7
Produto Versão Atividade Gatilho Qualificador Quantidade de defeitos
Produto Q 7.1.1 CVT Cobertura Incorreto 948
Produto F 7.1.1 CVT Cobertura Incorreto 828
Produto J 7.1.1 CVT Cobertura Faltando 768
Produto P 7.1.1 CVT Cobertura Incorreto 744
Produto O 7.1.2 CVT Cobertura Incorreto 720
Produto Núcleo
7.5 CVT Sequenciamento Incorreto 636
Produto Núcleo
7.5.1 CVT Cobertura Incorreto 612
Produto J 7.5 CVT Cobertura Faltando 582
Produto J 7.1.1 CVT Cobertura Incorreto 576
Produto Núcleo
7.5.1 CVT Interação Incorreto 558
A consulta 1.7, resumida na Tabela 34, mostra as principais versões de produto
responsáveis pelos defeitos apresentados na tabela 32.
Tabela 35 - Resultados da consulta 1.8
Produto Versão Atividade Gatilho Impacto Qualificador Quantidade de defeitos
Produto Q 7.1.1 CVT Cobertura Capacidade (Capability)
Incorreto 846
Produto F 7.1.1 CVT Cobertura Capacidade (Capability)
Incorreto 690
Produto J 7.1.1 CVT Cobertura Capacidade (Capability)
Faltando 660
72
Produto Versão Atividade Gatilho Impacto Qualificador Quantidade de defeitos
Produto O 7.1.2 CVT Cobertura Capacidade (Capability)
Incorreto 618
Produto P 7.1.1 CVT Cobertura Capacidade (Capability)
Incorreto 618
Produto J 7.1.1 CVT Cobertura Capacidade (Capability)
Incorreto 552
Produto J 7.5 CVT Cobertura Capacidade (Capability)
Faltando 510
Produto Núcleo
7.5.1 CVT Interação Capacidade (Capability)
Incorreto 504
Produto Núcleo
7.5.1 CVT Cobertura Capacidade (Capability)
Incorreto 492
Produto Núcleo
7.5 CVT Sequenciamento Capacidade (Capability)
Incorreto 468
A consulta 1.8, resumida na Tabela 35, mostra as principais versões de produto
responsáveis pelos defeitos apresentados na Tabela 33.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 1.1, 1.2, 1.3 e 1.4 mostram que os produtos que mais geram
defeitos por alterações ou melhoria são o Produto Núcleo (Em suas versões 7.5.1,
7.5 e 7.5.0.1), o Produto Q (Em sua versão 7.1.1), o Produto J (Em sua versão 7.1.1)
e o Produto O (Em sua versão 7.1.2), que a totalidade desses defeitos se devem à
implementações incorretas ou omitidas e que, também, sua totalidade causa ou
causaria impacto para os clientes relacionados, principalmente, à habilidade de se
realizar as funções pretendidas (Capacidade) e, secundariamente, à facilidade de
uso do sistema (Usabilidade).
Já as consultas 1.5, 1.6, 1.7 e 1.8 mostram que as principais falhas do processo
de verificação que deixaram a maioria dos defeitos gerados por alterações ou
melhorias escaparem são relacionadas aos testes de verificação de componentes
(CVT), principalmente na execução de funções simples (Cobertura), na execução de
funções simples com parâmetros (Variação), na execução de funções nas quais a
ordem interessa (Sequenciamento) e na execução de duas ou mais funções
relacionadas (Interação).
73
4.4.2 – Hipótese 2
Para a hipótese 2, os critérios idade, alvo, produto, versão, impacto, atividade,
gatilho e tipo de defeito foram combinados para se garantir a recuperação dos
defeitos gerados por novas funcionalidades e por alterações no código, no projeto ou
na arquitetura, para se mostrar as falhas do processo de verificação que deixaram
esses defeitos escaparem e para se mostrar as fases do processo de
desenvolvimento que também deixaram esses defeitos escaparem.
Tabela 36 - Resultados da consulta 2.1
Produto Atividade Gatilho Impacto Quantidade de defeitos
Produto J CVT Cobertura Capacidade (Capability)
2748
Produto Núcleo
CVT Cobertura Capacidade (Capability)
2082
Produto O CVT Cobertura Capacidade (Capability)
1836
Produto Núcleo
CVT Sequenciamento Capacidade (Capability)
1776
Produto F CVT Cobertura Capacidade (Capability)
1698
Produto Q CVT Cobertura Capacidade (Capability)
1572
Produto P CVT Cobertura Capacidade (Capability)
1296
Produto Núcleo
CVT Interação Capacidade (Capability)
1242
Produto Núcleo
CVT Variação Capacidade (Capability)
1020
Produto H CVT Cobertura Capacidade (Capability)
774
A consulta 2.1, resumida na Tabela 36, mostra que a maioria dos defeitos
gerados por alterações no código, no projeto ou na arquitetura são relacionados aos
produtos: Produto Núcleo, Produto J, Produto O e Produto F. Que as principais
falhas do processo de verificação que deixaram a maioria desses defeitos
74 escaparem são relacionadas aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura), na execução de
funções nas quais a ordem interessa (Sequenciamento) e na execução de duas ou
mais funções relacionadas (Interação). E que a totalidade desses defeitos causa ou
causaria impacto para os clientes relacionados à habilidade de se realizar as
funções (Capacidade).
Tabela 37 - Resultados da consulta 2.2
Produto Versão Atividade Gatilho Impacto Quantidade de defeitos
Produto J 7.1.1 CVT Cobertura Capacidade (Capability)
1248
Produto F 7.1.1 CVT Cobertura Capacidade (Capability)
1122
Produto Q 7.1.1 CVT Cobertura Capacidade (Capability)
1062
Produto P 7.1.1 CVT Cobertura Capacidade (Capability)
930
Produto O 7.1.2 CVT Cobertura Capacidade (Capability)
924
Produto J 7.5 CVT Cobertura Capacidade (Capability)
918
Produto Núcleo
7.5 CVT Sequenciamento Capacidade (Capability)
882
Produto Núcleo
7.5.1 CVT Cobertura Capacidade (Capability)
702
Produto Núcleo
7.5.1 CVT Interação Capacidade (Capability)
690
Produto H 7.1.1 CVT Cobertura Capacidade (Capability)
678
A consulta 2.2, resumida na Tabela 37, identifica as versões dos produtos que
mais geram os defeitos, mostrados na Tabela 36, relacionados às alterações no
código, no projeto ou na arquitetura: versões 7.5.1 e 7.5 do produto núcleo, versões
7.1.1 e 7.5 do produtos J, versão 7.1.2 do produto O e a versão 7.1.1 do produto F.
75 Tabela 38 - Resultados da consulta 2.3
Produto Impacto Tipo do Defeito
Quantidade de defeitos
Produto Núcleo
Capacidade (Capability)
Algoritmo 2418
Produto Núcleo
Capacidade (Capability)
Atribuição 2190
Produto O Capacidade (Capability)
Algoritmo 1698
Produto J Capacidade (Capability)
Atribuição 1656
Produto Núcleo
Capacidade (Capability)
Checagem 1614
Produto Q Capacidade (Capability)
Atribuição 1464
Produto F Capacidade (Capability)
Atribuição 1362
Produto P Capacidade (Capability)
Algoritmo 1242
Produto Q Capacidade (Capability)
Algoritmo 954
Produto J Capacidade (Capability)
Algoritmo 864
A consulta 2.3, resumida na Tabela 38, mostra, por produto e impacto, que as
fases do processo de desenvolvimento que deixaram a maioria dos defeitos
relacionados às alterações no código, projeto ou arquitetura escaparem foram o
projeto de baixo nível e a construção do código.
Tabela 39 - Resultados da consulta 2.4
Produto Versão Impacto Tipo do Defeito
Quantidade de defeitos
Produto Núcleo
7.5.1 Capacidade (Capability)
Algoritmo 1350
Produto F 7.1.1 Capacidade (Capability)
Atribuição 888
Produto Q 7.1.1 Capacidade (Capability)
Atribuição 870
Produto O 7.1.2 Capacidade (Capability)
Algoritmo 864
76
Produto Versão Impacto Tipo do Defeito
Quantidade de defeitos
Produto Núcleo
7.5 Capacidade (Capability)
Atribuição 810
Produto P 7.1.1 Capacidade (Capability)
Algoritmo 810
Produto Núcleo
7.5.1 Capacidade (Capability)
Atribuição 666
Produto J 7.1.1 Capacidade (Capability)
Atribuição 666
Produto Q 7.1.1 Capacidade (Capability)
Algoritmo 666
Produto Núcleo
7.5 Capacidade (Capability)
Checagem 654
A consulta 2.4, resumida na Tabela 39, mostra, por versão, os defeitos
apresentados na Tabela 38.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 2.1 e 2.2 mostram que a maioria dos defeitos gerados por
alterações no código, no projeto ou na arquitetura são relacionados aos produtos:
Produto Núcleo (Em suas versões 7.5.1, 7.5 e 7.5.0.1), Produto J (Em suas versões
7.5.1, 7.1.1 e 7.5), Produto O (Em sua versão 7.1.2) e Produto F (Em sua versão
7.1.1). Que as principais falhas do processo de verificação que deixaram a maioria
desses defeitos escaparem são relacionadas aos testes de verificação de
componentes (CVT), principalmente na execução de funções simples (Cobertura),
na execução de funções nas quais a ordem interessa (Sequenciamento) e na
execução de duas ou mais funções relacionadas (Interação) e aos testes de
verificação do sistema (SVT) na execução de funções simples (Cobertura). E que a
totalidade desses defeitos causa ou causaria impacto para os clientes relacionados
à habilidade de se realizar as funções pretendidas (Capacidade) e à facilidade de
uso do sistema (Usabilidade).
Já as consultas 2.3 e 2.4 mostram que as fases do processo de desenvolvimento
que deixaram a maioria dos defeitos relacionados às alterações no código, projeto
ou arquitetura escaparem foram o projeto de baixo nível e a construção do código.
77
4.4.3 – Hipótese 3
Para a hipótese 3, os critérios severidade, produto, versão, estado de teste,
atividade, gatilho, alvo e tipo de defeito foram combinados para se recuperar os
defeitos de maior impacto para os clientes e cujo correções não corrigiram os
problemas, para se mostrar as falhas do processo de verificação e as fases do
processo de desenvolvimento que deixaram estes defeitos escaparem.
Tabela 40 - Resultados da consulta 3.1
Produto Quantidade de defeitos
Produto Núcleo
828
Produto E 36
Produto I 24
Produto Q 24
Produto O 18
Produto F 12
Produto M 12
Produto G 6
Produto J 6
Produto L 6
A consulta 3.1, resumida na Tabela 40, mostra que a maioria dos defeitos de alta
severidade que foram corrigidos, mas não resolveram os problemas é relacionada
aos produtos: Produto Núcleo, Produto E, Produto I e Produto Q.
Tabela 41 - Resultados da consulta 3.2
Produto Versão Quantidade de defeitos
Produto Núcleo
6.2.0.1 138
78
Produto Versão Quantidade de defeitos
Produto Núcleo
7.1.1.4 84
Produto Núcleo
5.2 66
Produto Núcleo
7.1.1.5 66
Produto Núcleo
7.1.1.6 60
Produto Núcleo
7.1.1.7 42
Produto Núcleo
6.2 36
Produto Núcleo
6.2.3 36
Produto Núcleo
6.2.2 30
Produto Núcleo
7.1.1.0 30
A consulta 3.2, resumida na Tabela 41, identifica as versões dos produtos que
mais geram defeitos de alta severidade que foram corrigidos, mas não resolveram
os problemas: versões 6.2.0.1, 7.1.1.4, 5.2 e 7.1.1.5 do produto núcleo.
Tabela 42 - Resultados da consulta 3.3
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Cobertura 618
Produto Núcleo
CVT Cobertura 36
Produto Núcleo
SVT Cobertura 30
Produto E SVT Cobertura 20
Produto Núcleo
SVT Software 24
Produto Núcleo
SVT Carga de Trabalho
18
Adaptador MS-Project
CVT Interação 18
79
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Interação 12
Produto Núcleo
UT Simples 12
Produto F UT Simples 12
A consulta 3.3, resumida na Tabela 42, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria destes defeitos
escaparem são relacionadas aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura) e na execução de duas
ou mais funções relacionadas (Interação), aos testes de verificação do sistema
(SVT), principalmente na execução de funções simples (Cobertura), na execução de
testes em configurações específicas de software (Software) e na execução de testes
de carga ou de estresse (Carga de trabalho) e aos testes de unidade (UT), na
execução de testes simples (Simples).
Tabela 43 - Resultados da consulta 3.4
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
6.2.3 SVT Cobertura 96
Produto Núcleo
7.1.1.7 CVT Cobertura 89
Produto Núcleo
7.1 SVT Cobertura 88
Produto Núcleo
6.2.0.1 UT Simples 85
Produto Núcleo
6.2.4 CVT Cobertura 71
Produto Núcleo
6.2.4 SVT Carga de Trabalho
71
Produto Núcleo
7.1 SVT Software 67
Produto Núcleo
7.1.0.1 SVT Cobertura 59
Produto Núcleo
7.1.1.0 CVT Cobertura 59
80
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.1.1.0 CVT Interação 55
A consulta 3.4, resumida na Tabela 43, mostra os defeitos da tabela 42
detalhados pelas versões do produto que mais geraram esses defeitos.
Tabela 44 - Resultados da consulta 3.5
Produto Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
Código Algoritmo 126
Produto Núcleo
Código Atribuição 48
Produto Núcleo
Código Checagem 42
Produto Núcleo
Build Algoritmo 36
Produto Núcleo
Código Função 30
Adaptador MS-Project
Código Algoritmo 24
Produto E Código Algoritmo 24
Produto F Código Atribuição 12
Produto Q Código Atribuição 12
Produto O Código Atribuição 12
A consulta 3.5, resumida na Tabela 44, mostra, por produto, que as fases do
processo de desenvolvimento que deixaram a maioria dos defeitos de alta
severidade que foram corrigidos, mas não resolveram os problemas escaparem
foram o projeto de baixo nível, a construção do código e o processo de build.
81 Tabela 45 - Resultados da consulta 3.6
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
6.2.0.1 Código Algoritmo 114
Produto Núcleo
5.2 Código Atribuição 36
Produto Núcleo
6.2 Código Checagem 36
Produto Núcleo
5.2 Build Algoritmo 30
Produto Núcleo
7.1.1.6 Código Função 30
Produto Núcleo
7.1 Código Algoritmo 24
Produto Núcleo
7.1.1.4 Código Algoritmo 24
Produto Núcleo
7.1.1.5 Código Algoritmo 24
Produto Núcleo
7.5 Código Atribuição 24
Produto Núcleo
6.1 Código Atribuição 18
A consulta 3.6, resumida na Tabela 45, mostra os defeitos da tabela 44
detalhados pelas versões do produto que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 3.1 e 3.2 mostram que a maioria dos defeitos de alta severidade
que foram corrigidos, mas não resolveram os problemas é relacionada aos produtos:
Produto Núcleo (Em suas versões 6.2.0.1, 7.1.1.4, 5.2 e 7.1.1.5), Produto E (Em sua
versão 6.3), Produto I (Em sua versão 6.2.6 e 7.1) e Produto Q (Em sua versão 7.5).
As consultas 3.3 e 3.4 mostram que as principais falhas do processo de
verificação que deixaram a maioria destes defeitos escaparem são relacionadas aos
testes de verificação de componentes (CVT), principalmente na execução de
funções simples (Cobertura), aos testes de verificação do sistema (SVT),
principalmente na execução de funções simples (Cobertura), na execução de testes
em configurações específicas de software (Software) e na execução de testes de
carga ou de estresse (Carga de trabalho) e aos testes de unidade (UT), na execução
de testes simples (Simples).
82
Já as consultas 3.5 e 3.6 mostram que as fases do processo de desenvolvimento
que deixaram a maioria dos defeitos de alta severidade que foram corrigidos, mas
não evitaram que os problemas escapassem foram o projeto de baixo nível, a
construção do código e o processo de build.
4.4.4 – Hipótese 4
Para a hipótese 4, os critérios severidade, idade, produto, versão, atividade,
gatilho, alvo, tipo de defeito e fonte foram combinados para se recuperar os defeitos
relativos a novas funcionalidades de determinados produtos que deixam o ambiente
instável, para se mostrar as falhas do processo de verificação e as fases do
processos de desenvolvimento que deixaram esses defeitos escaparem.
Tabela 46 - Resultados da consulta 4.1
Produto Quantidade de defeitos
Produto Núcleo
7770
Produto O 2910
Produto Q 2448
Produto J 2256
Produto N 1770
Produto P 1596
Produto H 1524
Produto F 1482
Produto L 930
Produto A 690
A consulta 4.1, resumida na Tabela 46, mostra que a maioria dos defeitos de alta
severidade provenientes do desenvolvimento de novas funcionalidades e que
tornam o ambiente instável é relacionada aos produtos: Produto Núcleo, Produto O,
Produto Q e Produto J.
83
Tabela 47 - Resultados da consulta 4.2
Produto Versão Quantidade de defeitos
Produto Núcleo
7.5 2160
Produto Núcleo
7.5.0.1 1866
Produto Núcleo
7.5.1 1752
Produto J 7.1.1 1128
Produto F 7.1.1 1122
Produto O 7.1.2 1056
Produto Q 7.1.1 1024
Produto N 7.5 930
Produto P 7.1.1 870
Produto Q 7.1 762
A consulta 4.2, resumida na Tabela 47, identifica as versões dos produtos que
geram a maioria dos defeitos de alta severidade provenientes do desenvolvimento
de novas funcionalidades e que tornam o ambiente instável: versões 7.5, 7.5.0.1 e
7.5.1 do produto núcleo, versões 7.1.2 e 7.1.1 do produto O, versões 7.1.1, 7.1 e 7.5
do produto Q e versões 7.1.1 e 7.5 produto J.
Tabela 48 - Resultados da consulta 4.3
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Cobertura 2010
Produto Núcleo
CVT Sequenciamento 1764
Produto O SVT Cobertura 1674
Produto J CVT Cobertura 1638
Produto Núcleo
CVT Interação 1506
Produto Q CVT Cobertura 1500
84
Produto Atividade Gatilho Quantidade de defeitos
Produto F CVT Cobertura 1104
Produto P CVT Cobertura 942
Produto Núcleo
CVT Variação 912
Produto N CVT Cobertura 750
A consulta 4.3, resumida na Tabela 48, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria destes defeitos
escaparem são relacionadas aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura), na execução de duas
ou mais funções relacionadas (Interação) e na execução de funções nas quais a
ordem interessa (Sequenciamento) e aos testes de verificação do sistema, (SVT)
principalmente na execução de funções simples (Cobertura).
Tabela 49 - Resultados da consulta 4.4
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.5 CVT Sequenciamento 954
Produto F 7.1.1 CVT Cobertura 894
Produto J 7.1.1 CVT Cobertura 876
Produto Q 7.1.1 CVT Cobertura 828
Produto O 7.1.2 CVT Cobertura 750
Produto P 7.1.1 CVT Cobertura 624
Produto Núcleo
7.5.0.1 CVT Cobertura 606
Produto Núcleo
7.5.1 CVT Interação 534
Produto N 7.5 CVT Cobertura 504
Produto Núcleo
7.5.1 CVT Cobertura 486
A consulta 4.4, resumida na Tabela 49, mostra os defeitos da tabela 48
detalhados pelas versões dos produtos que mais geraram esses defeitos.
85
Tabela 50 - Resultados da consulta 4.5
Produto Alvo Tipo de Defeito Fonte Quantidade de defeitos
Produto Núcleo
Código Algoritmo Interno 2430
Produto Núcleo
Código Atribuição Interno 2202
Produto Núcleo
Código Checagem Interno 1848
Produto O Código Algoritmo Interno 1680
Produto Q Código Atribuição Interno 1170
Produto Q Código Algoritmo Interno 948
Produto P Código Algoritmo Interno 912
Produto N Código Checagem Interno 846
Produto J Código Atribuição Interno 816
Produto F Código Atribuição Interno 810
A consulta 4.5, resumida na Tabela 50, mostra, por produto, que as fases do
processo de desenvolvimento que deixaram a maioria dos defeitos de alta
severidade provenientes do desenvolvimento de novas funcionalidades que tornam
o ambiente instável escaparem foram o projeto de baixo nível e a construção do
código. Além disso, essas consultas mostram que a totalidade desses defeitos se
devem ao desenvolvimento interno.
Tabela 51 - Resultados da consulta 4.6
Produto Versão Alvo Tipo de Defeito Fonte Quantidade de defeitos
Produto Núcleo
7.5.1 Código Algoritmo Interno 966
Produto Núcleo
7.5 Código Atribuição Interno 870
Produto Núcleo
7.5 Código Checagem Interno 720
Produto O 7.1.2 Código Algoritmo Interno 708
Produto F 7.1.1 Código Atribuição Interno 666
86
Produto Versão Alvo Tipo de Defeito Fonte Quantidade de defeitos
Produto P 7.1.1 Código Algoritmo Interno 600
Produto Núcleo
7.5.0.1 Código Algoritmo Interno 588
Produto Q 7.1.1 Código Algoritmo Interno 516
Produto N 7.5 Código Checagem Interno 498
Produto Núcleo
7.5.0.1 Código Atribuição Interno 450
A consulta 4.6, resumida na Tabela 51, mostra os defeitos da tabela 50
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 4.1 e 4.2 mostram que a maioria dos defeitos de alta severidade
provenientes do desenvolvimento de novas funcionalidades e que tornam o
ambiente instável é relacionada aos produtos: Produto Núcleo (Em suas versões
7.5, 7.5.0.1 e 7.5.1), Produto O (Em suas versões 7.1.2 e 7.1.1), Produto Q (Em
suas versões 7.1.1, 7.1 e 7.5) e Produto J (Em suas versões 7.1.1 e 7.5).
As consultas 4.3 e 4.4 mostram que as principais falhas do processo de
verificação que deixaram a maioria desses defeitos escaparem são relacionadas aos
testes de verificação de componentes (CVT), principalmente na execução de
funções simples (Cobertura) e na execução de funções nas quais a ordem interessa
(Sequenciamento) e aos testes de verificação do sistema (SVT), principalmente na
execução de funções simples (Cobertura).
Já as consultas 4.5 e 4.6 mostram que as fases do processo de desenvolvimento
que deixaram a maioria dos defeitos de alta severidade provenientes do
desenvolvimento de novas funcionalidades que tornam o ambiente instável
escaparem foram o projeto de baixo nível e a construção do código. Além disso,
estas consultas mostram que a totalidade destes defeitos se devem ao
desenvolvimento interno.
87
4.4.5 – Hipótese 5
Para a hipótese 5, os critérios alvo, qualificador, tipo de defeito, produto, versão,
atividade e gatilho, foram combinados para se recuperar os defeitos relativos ao
desenvolvimento de novas funcionalidades que não atendam aos requisitos, para se
mostrar as falhas do processo de verificação que deixaram estes defeitos
escaparem e também para se mostrar as fases do processo de desenvolvimento
que deixaram estes mesmos defeitos escaparem.
Tabela 52 - Resultados da consulta 5.1
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Cobertura 552
Produto Núcleo
CVT Cobertura 474
Produto J CVT Cobertura 300
Produto Núcleo
CVT Sequenciamento 198
Produto Núcleo
CVT Interação 192
Produto P CVT Cobertura 180
Produto F CVT Cobertura 174
Produto H CVT Cobertura 156
Produto O CVT Cobertura 120
Produto Núcleo
CVT Variação 114
A consulta 5.1, resumida na Tabela 52, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria dos defeitos provenientes
do desenvolvimento de novas funcionalidades que não atendem aos requisitos
escaparem são relacionadas aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura), na execução de duas
ou mais funções relacionadas (Interação), na execução de funções nas quais a
ordem interessa (Sequenciamento) e na execução de funções simples com
parâmetros (Variação).
88
Tabela 53 - Resultados da consulta 5.2
Produto Atividade Gatilho Alvo Tipo de Defeito
Quantidade de defeitos
Produto Núcleo
CVT Cobertura Código Função 336
Produto Núcleo
CVT Cobertura Código Função 270
Produto F CVT Cobertura Código Função 150
Produto H CVT Cobertura Código Função 144
Produto P CVT Cobertura Código Função 120
Produto Núcleo
CVT Sequenciamento Código Função 102
Produto J CVT Cobertura Código Função 102
Produto J CVT Cobertura Projeto Atribuição 96
Produto H CVT Cobertura Código Função 90
Produto Núcleo
CVT Interação Código Função 78
A consulta 5.2, resumida na Tabela 53, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria dos defeitos provenientes
do desenvolvimento de novas funcionalidades que não atendem aos requisitos
escaparem são relacionadas aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura) , na execução de duas
ou mais funções relacionadas (Interação) e na execução de funções nas quais a
ordem interessa (Sequenciamento). Essa consulta mostra, também, que as fases do
processo de desenvolvimento que deixaram a maioria destes defeitos escaparem
foram o projeto, o projeto de baixo nível e a construção do código.
Tabela 54 - Resultados da consulta 5.3
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.1.1.0 CVT Cobertura 330
Produto 7.1.1.6 CVT Cobertura 168
89
Produto Versão Atividade Gatilho Quantidade de defeitos
Núcleo
Produto Núcleo
7.1.1.5 CVT Cobertura 162
Produto J 7.1.1 CVT Cobertura 150
Produto Núcleo
7.5.0.1 CVT Cobertura 120
Produto Núcleo
7.5.0.1 CVT Interação 120
Produto Núcleo
7.1.1.5 CVT Cobertura 102
Produto J 7.5 CVT Cobertura 102
Produto P 7.1.1 CVT Cobertura 96
Produto Núcleo
6.2.1 CVT Cobertura 90
A consulta 5.3, resumida na Tabela 54, mostra os defeitos da tabela 52
detalhados pelas versões dos produtos que mais geraram esses defeitos
Tabela 55 - Resultados da consulta 5.4
Produto Versão Atividade Gatilho Alvo Tipo de Defeito
Quantidade de defeitos
Produto Núcleo
7.1.1.0 CVT Cobertura Código Função 252
Produto Núcleo
7.1.1.6 CVT Cobertura Código Função 150
Produto Núcleo
7.1.1.5 CVT Cobertura Código Função 126
Produto Núcleo
6.2.0.1 CVT Cobertura Código Função 90
Produto H 6.5 CVT Cobertura Código Função 78
Produto Núcleo
7.1.1.7 CVT Cobertura Código Função 72
Produto Núcleo
7.1.1.8 SVT Software Código Função 72
Produto Núcleo
7.5.0.1 CVT Cobertura Código Função 72
Produto Núcleo
7.5.0.1 SVT Carga de Trabalho
Requisitos Interface 66
Produto 7.5.0.1 CVT Interação Código Função 60
90
Produto Versão Atividade Gatilho Alvo Tipo de Defeito
Quantidade de defeitos
Núcleo
A consulta 5.4, resumida na Tabela 55, mostra os defeitos da tabela 53
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, podemos concluir, em relação a esta hipótese que:
As consultas 5.1, 5.2, 5.3 e 5.4 mostram que a maioria dos defeitos provenientes
do desenvolvimento de novas funcionalidades que não atendem aos requisitos é
relacionada aos produtos: Produto Núcleo (Em suas versões 7.1.1.0, 7.1.1.5 e
7.1.1.6), Produto J (Em suas versões 7.1.1 e 7.5), Produto P (Em sua versão 7.1.1)
e Produto H (Em sua versão 6.5). Que as principais falhas do processo de
verificação que deixaram a maioria desses defeitos escaparem são relacionadas aos
testes de verificação de componentes (CVT), principalmente na execução de
funções simples (Cobertura), na execução de funções nas quais a ordem interessa
(Sequenciamento) e na execução de duas ou mais funções relacionadas (Interação)
e aos testes de verificação do sistema (SVT) na execução de funções em
configurações de software específicas (Software). E que as fases do processo de
desenvolvimento que deixaram a maioria desses defeitos escaparem foram o
projeto, o projeto de baixo nível e a construção do código.
4.4.6 – Hipótese 6
Para a hipótese 6, os critérios severidade, APAR, produto, versão, atividade,
gatilho, alvo e tipo de defeito foram combinados para se recuperar os defeitos de
alta severidade que escapam para o cliente e para se mostrar as falhas do processo
de verificação e as fases do processo de desenvolvimento que deixaram estes
defeitos escaparem.
91 Tabela 56 - Resultados da consulta 6.1
Produto Quantidade de defeitos
Produto Núcleo
32922
Produto Q 1746
Produto F 1404
Produto E 1188
Produto H 1176
Produto A 1110
Produto O 1062
Primavera 558
Produto J 444
Adaptador MS-Project
258
A consulta 6.1, resumida na Tabela 56, mostra que a maioria dos defeitos de alta
severidade que foram encontrados em ambientes de produção dos clientes é
relacionada aos produtos: Produto Núcleo , Produto Q, Produto F e Produto E.
Tabela 57 - Resultados da consulta 6.2
Produto Versão Quantidade de defeitos
Produto Núcleo
6.2.0.1 21888
Produto Núcleo
7.1.1.0 15630
Produto Núcleo
7.1.1.4 6114
Produto Núcleo
6.2.2 5784
Produto Núcleo
7.1.1.6 5658
Produto Núcleo
6.2.3 5568
Produto Núcleo
7.1.1.5 5340
Produto Núcleo
7.1 4722
92
Produto Versão Quantidade de defeitos
Produto Núcleo
7.5 4296
Produto Núcleo
7.1.1.7 4236
A consulta 6.2, resumida na Tabela 57, identifica as versões dos produtos que
geraram a maioria dos defeitos de alta severidade que foram encontrados em
ambientes de produção dos clientes: versões 6.2.0.1, 7.1.1.0 e 7.1.1.4 do produto
núcleo.
Tabela 58 - Resultados da consulta 6.3
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Cobertura 31176
Produto Q CVT Cobertura 1584
Produto F CVT Cobertura 1398
Produto H CVT Cobertura 1128
Produto E SVT Cobertura 1074
Produto A CVT Cobertura 1032
Produto O CVT Cobertura 984
Produto M CVT Cobertura 558
Produto J UT Complexo 342
Produto Núcleo
SVT Software 312
A consulta 6.3, resumida na Tabela 58, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria destes defeitos
escaparem são relacionadas aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura), aos testes de
verificação do sistema (SVT), principalmente na execução de funções simples
(Cobertura) e na execução de funções em determinadas configurações de software
(Software) e aos testes de unidade (UT), principalmente em execuções de testes
93 complexos (Complexo).
Tabela 59 - Resultados da consulta 6.4
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
6.2.0.1 CVT Cobertura 21384
Produto Núcleo
7.1.1.0 CVT Cobertura 14634
Produto Núcleo
6.2.2 CVT Cobertura 5550
Produto Núcleo
7.1.1.4 CVT Cobertura 5424
Produto Núcleo
6.2.3 CVT Cobertura 5256
Produto Núcleo
7.1.1.6 CVT Cobertura 4980
Produto Núcleo
7.1.1.5 CVT Cobertura 4704
Produto Núcleo
7.1 CVT Cobertura 4398
Produto Núcleo
7.5 CVT Cobertura 423
Produto Núcleo
7.1.1.7 SVT Software 234
A consulta 6.4, resumida na Tabela 59, mostra os defeitos da tabela 58
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Tabela 60 - Resultados da consulta 6.5
Produto Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
Código Algoritmo 24822
Produto Núcleo
Código Algoritmo 2760
Produto Núcleo
Código Checagem 1506
Produto F Código Checagem 1326
94
Produto Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
Código Atribuição 1266
Produto Q Código Algoritmo 954
Produto H Código Algoritmo 756
Produto E Código Checagem 702
Produto A Código Checagem 684
Produto O Código Algoritmo 564
A consulta 6.5, resumida na Tabela 60, mostra, por produto, que as fases do
processo de desenvolvimento que deixaram a maioria dos defeitos de alta
severidade encontrados em ambientes de produção dos clientes escaparem foram o
projeto de baixo nível e a construção do código.
Tabela 61 - Resultados da consulta 6.6
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
6.2.0.1 Código Algoritmo 18924
Produto Núcleo
7.1.1.0 Código Atribuição 9534
Produto Núcleo
6.2.2 Código Atribuição 4638
Produto Núcleo
7.5 Código Checagem 4032
Produto Núcleo
6.2.3 Código Atribuição 3624
Produto Núcleo
6.2 Código Checagem 3168
Produto Núcleo
7.1 Código Checagem 2874
Produto Núcleo
7.1.1.8 Código Algoritmo 2730
Produto Núcleo
7.1.1.7 Código Algoritmo 2514
Produto Núcleo
7.1.1.4 Código Algoritmo 2394
95
A consulta 6.6, resumida na Tabela 61, mostra os defeitos da tabela 60
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 6.1 e 6.2 mostram que a maioria dos defeitos de alta severidade
que foram encontrados em ambientes de produção dos clientes é relacionada aos
produtos: Produto Núcleo (Em suas versões 6.2.0.1, 7.1.1.0 e 7.1.1.4), Produto Q
(Em suas versões 7.1.1.0, 7.1 e 6.3), Produto F (Em suas versões 6.2.0.1, 7.1.1.2 e
7.1.1.1) e Produto E (Em suas versões 6.2.0.1, 7.1.1.0 e 6.3.2).
As consultas 6.3 e 6.4 mostram que as principais falhas do processo de
verificação que deixaram a maioria destes defeitos escaparem são relacionadas aos
testes de verificação de componentes (CVT), principalmente na execução de
funções simples (Cobertura), aos testes de verificação do sistema (SVT),
principalmente na execução de funções simples (Cobertura) e na execução de
funções em determinadas configurações de software (Software) e aos testes de
unidade (UT), principalmente em execuções de testes complexos (Complexo).
Já as consultas 6.5 e 6.6 mostram que as fases do processo de desenvolvimento
que deixaram a maioria dos defeitos de alta severidade escaparem para os
ambientes de produção dos clientes foram o projeto de baixo nível e a construção do
código.
4.4.7 – Hipótese 7
Para a hipótese 7, os critérios idade, APAR, produto, versão, atividade, gatilho,
alvo e tipo de defeito foram combinados para se recuperar os defeitos que escapam
para os clientes e demoram muito tempo para serem corrigidos, para se mostrar as
falhas do processo de verificação e as fases do processo de desenvolvimento que
deixaram estes defeitos escaparem.
Tabela 62 - Resultados da consulta 7.1
Idade Quantidade de defeitos
96
Idade Quantidade de defeitos
Base 30012
Novo 11900
Recorrigido 2522
Reescrito 1312
A consulta 7.1, resumida na Tabela 62, mostra que a maioria dos defeitos
encontrados em ambientes de produção dos clientes demora para ser corrigido, pois
o critério idade com o valor base mostra que esses defeitos são de versões antigas
do produto.
Tabela 63 - Resultados da consulta 7.2
Produto Quantidade de defeitos
Produto Núcleo
7872
Produto Q 834
Produto E 618
Produto O 570
Produto A 492
Produto H 480
Produto M 318
Produto J 294
Produto F 133
Produto P 84
A consulta 7.2, resumida na Tabela 63, mostra que a maioria dos defeitos que
demoram para ser corrigidos e que foram encontrados em ambientes de produção
dos clientes é relacionada aos produtos: Produto Núcleo, Produto Q, Produto E e
Produto O.
97 Tabela 64 - Resultados da consulta 7.3
Produto Versão Quantidade de defeitos
Produto Núcleo
7.1.1.0 5646
Produto Núcleo
7.1.1.6 3666
Produto Núcleo
6.2.0.1 3090
Produto Núcleo
7.1.1.5 3054
Produto Núcleo
7.1.1.4 2706
Produto Núcleo
7.1.1.7 1884
Produto Núcleo
7.1 1770
Produto Núcleo
6.2.3 1626
Produto Núcleo
6.2.2 1110
Produto Núcleo
6.2.4 852
A consulta 7.3, resumida na Tabela 64, identifica as versões dos produtos que
mais geram os defeitos que demoram para ser corrigidos e que foram encontrados
em ambientes de produção dos clientes: versões 7.1.1.0, 7.1.1.6 e 6.2.0.1 do
produto núcleo.
Tabela 65 - Resultados da consulta 7.4
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Cobertura 5886
Produto Q CVT Cobertura 702
Produto O CVT Cobertura 468
Produto E CVT Cobertura 438
Produto H CVT Cobertura 432
Produto A UT Complexo 372
98
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
SVT Cobertura 366
Produto M UT Simples 318
Produto Núcleo
SVT Cobertura 312
Produto Núcleo
CVT Cobertura 210
A consulta 7.4, resumida na Tabela 65, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria destes defeitos
escaparem são relacionadas aos testes de verificação do componentes (CVT),
principalmente na execução de funções simples (Cobertura), aos testes de
verificação de sistemas (SVT), principalmente na execução de funções simples
(Cobertura) e aos testes de unidade (UT), principalmente na execução de funções
simples (Simples) e na execução de funções complexas (Complexo).
Tabela 66 - Resultados da consulta 7.5
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.1.1.0 CVT Cobertura 4512
Produto Núcleo
7.1.1.6 CVT Cobertura 2928
Produto Núcleo
6.2.0.1 CVT Cobertura 2454
Produto Núcleo
7.1.1.5 CVT Cobertura 2406
Produto Núcleo
7.1.1.4 CVT Cobertura 1998
Produto Núcleo
7.1.1.7 CVT Cobertura 1506
Produto Núcleo
7.1 CVT Cobertura 1404
Produto Núcleo
6.2.3 CVT Cobertura 1302
Produto Núcleo
6.2.2 CVT Cobertura 870
99
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.1.1.8 SVT Cobertura 642
A consulta 7.5, resumida na Tabela 66, mostra os defeitos da tabela 65
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Tabela 67 - Resultados da consulta 7.6
Produto Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
Código Algoritmo 3156
Produto Núcleo
Código Checagem 1776
Produto Núcleo
Código Atribuição 1638
Produto E Código Algoritmo 366
Produto O Código Algoritmo 360
Produto Q Código Atribuição 336
Produto Q Código Algoritmo 330
Produto Núcleo
Código Algoritmo 276
Produto Núcleo
Código Função 252
Produto H Código Algoritmo 228
A consulta 7.6, resumida na Tabela 67, mostra, por produto, que as fases do
processo de desenvolvimento que deixaram a maioria dos defeitos que demoram
para ser corrigidos e que foram encontrados em ambientes de produção dos clientes
escaparem foram o projeto de baixo nível e a construção do código.
Tabela 68 - Resultados da consulta 7.7
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
100
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
7.1.1.0 Código Algoritmo 2532
Produto Núcleo
7.1.16 Código Algoritmo 1908
Produto Núcleo
7.1.1.4 Código Algoritmo 1518
Produto Núcleo
7.1.1.5 Código Algoritmo 1386
Produto Núcleo
7.1.1.0 Código Checagem 1368
Produto Núcleo
7.1.1.0 Código Atribuição 1170
Produto Núcleo
6.2.0.1 Código Algoritmo 1056
Produto Núcleo
6.2.0.1 Código Atribuição 912
Produto Núcleo
7.1.1.6 Código Checagem 882
Produto Núcleo
7.1.1.7 Código Algoritmo 852
A consulta 7.7, resumida na Tabela 68, mostra os defeitos da tabela 67
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 7.1, 7.2 e 7.3 mostram que a maioria dos defeitos que demoram
para ser corrigidos e que foram encontrados em ambientes de produção dos clientes
é relacionada aos produtos: Produto Núcleo (Em suas versões 7.1.1.0, 7.1.1.6 e
6.2.0.1), Produto Q (Em suas versões 7.1.1.0, 7.1 e 6.3), Produto E (Em suas
versões 7.1.1.0, 7.1.2 e 7.1) e Produto O (Em suas versões 7.1.1.2, 7.1 e 7.1.1).
As consultas 7.4 e 7.5 mostram que as principais falhas do processo de
verificação que deixaram a maioria destes defeitos escaparem são relacionadas aos
testes de verificação do sistema (SVT), principalmente na execução de funções
simples (Cobertura), aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura) e aos testes de unidade
(UT), principalmente na execução de funções simples (Simples) e na execução de
funções complexas (Complexo).
Já as consultas 7.6 e 7.7 mostram que as fases do processo de desenvolvimento
101 que deixaram a maioria dos defeitos que demoram para ser corrigidos e que foram
encontrados em ambientes de produção dos clientes escaparem foram o projeto de
baixo nível e a construção do código.
4.4.8 – Hipótese 8
Para a hipótese 8, os critérios idade, severidade, produto, versão, atividade,
gatilho, alvo e tipo de defeito foram combinados para se recuperar os defeitos de
cada uma das severidades (3 e 4) que não são corrigidos dentro da própria iteração,
para se mostrar as falhas do processo de verificação que deixaram estes defeitos
escaparem e também para se mostrar as fases do processo de desenvolvimento
que deixaram estes mesmos defeitos escaparem.
Tabela 69 - Resultados da consulta 8.1
Produto Quantidade de defeitos
Produto Núcleo
8664
Produto H 1986
Produto E 1236
Produto O 918
Produto J 846
Produto Q 678
Produto A 432
Produto P 426
Produto F 420
Produto L 300
A consulta 8.1, resumida na Tabela 69, mostra que a maioria dos defeitos de
baixa e média severidade que não são corrigidos dentro da iteração é relacionada
aos produtos: Produto Núcleo, Produto H, Produto E e Produto O.
102
Tabela 70 - Resultados da consulta 8.2
Produto Versão Quantidade de defeitos
Produto Núcleo
7.5.0.1 1830
Produto Núcleo
7.1.1.5 1812
Produto Núcleo
7.1.1.6 1560
Produto Núcleo
7.1.1.0 1470
Produto H 7.1.1 1176
Produto Núcleo
6.2.0.1 876
Produto Núcleo
7.1.1.7 822
Produto Núcleo
7.5.0.1 792
Produto H 6.5.1 780
Produto Núcleo
7.1 648
A consulta 8.2, resumida na Tabela 70, identifica as versões dos produtos que
mais geraram os defeitos de baixa e média severidade que não são corrigidos
dentro da iteração: versões 7.5.0.1 7.1.1.5 e 7.1.1.6 do produto núcleo e versões
7.1.1, 6.5.1 e 6.5 do produto H.
Tabela 71 - Resultados da consulta 8.3
Produto Atividade Gatilho Quantidade de defeitos
Produto Núcleo
CVT Cobertura 2340
Produto Núcleo
CVT Cobertura 2268
Produto H SVT Cobertura 906
Produto Núcleo
CVT Sequenciamento 618
Produto SVT Cobertura 528
103
Produto Atividade Gatilho Quantidade de defeitos
Núcleo
Produto Núcleo
CVT Variação 462
Produto E CVT Cobertura 462
Produto H CVT Cobertura 450
Produto Núcleo
CVT Interação 366
Produto J SVT Cobertura 366
A consulta 8.3, resumida na Tabela 71, mostra, por produto, que as principais
falhas do processo de verificação que deixaram a maioria destes defeitos
escaparem são relacionadas aos testes de verificação do sistema (SVT),
principalmente na execução de funções simples (Cobertura), aos testes de
verificação de componentes (CVT), principalmente na execução de funções simples
(Cobertura), na execução de funções com parâmetros (Variação) e na execução de
funções na quais a ordem realmente importa (Sequenciamento).
Tabela 72 - Resultados da consulta 8.4
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.1.1.0 CVT Cobertura 1244
Produto Núcleo
7.5.0.1 CVT Cobertura 714
Produto Núcleo
6.2.0.1 CVT Cobertura 696
Produto Núcleo
7.1.1.5 CVT Cobertura 660
Produto H 7.1.1 SVT Cobertura 636
Produto Núcleo
7.1.1.6 CVT Cobertura 618
Produto H 6.5.1 SVT Cobertura 618
Produto Núcleo
7.1.1.5 SVT Cobertura 528
Produto Núcleo
7.1 CVT Cobertura 480
104
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto Núcleo
7.1.1.7 CVT Cobertura 330
A consulta 8.4, resumida na Tabela 72, mostra os defeitos da tabela 71
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Tabela 73 - Resultados da consulta 8.5
Produto Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
Código Atribuição 2862
Produto Núcleo
Código Algoritmo 2070
Produto Núcleo
Código Checagem 1674
Produto H Código Algoritmo 1104
Produto E Código Algoritmo 546
Produto H Código Atribuição 474
Produto O Código Atribuição 444
Produto J Código Atribuição 438
Produto E Código Atribuição 426
Produto Núcleo
Informação Técnico 384
A consulta 8.5, resumida na Tabela 73, mostra, por produto, que as fases do
processo de desenvolvimento que deixaram a maioria dos defeitos de baixa e média
severidade que não são corrigidos dentro da iteração escaparem foram o projeto de
baixo nível e a construção do código.
Tabela 74 - Resultados da consulta 8.6
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
105
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
7.1.1.5 Código Atribuição 726
Produto H 7.1.1 Código Algoritmo 720
Produto Núcleo
7.5.0.1 Código Atribuição 666
Produto Núcleo
7.1.1.6 Código Algoritmo 528
Produto Núcleo
7.1.1.5 Código Algoritmo 522
Produto Núcleo
7.1.1.0 Código Algoritmo 510
Produto H 6.5.1 Código Algoritmo 492
Produto Núcleo
7.1.1.0 Código Atribuição 462
Produto Núcleo
7.1.1.6 Código Atribuição 438
Produto Núcleo
7.1.1.6 Código Checagem 402
A consulta 8.6, resumida na Tabela 74, mostra os defeitos da tabela 73 detalhados
pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 8.1 e 8.2 mostram que a maioria dos defeitos de baixa e média
severidade que não são corrigidos dentro da iteração é relacionada aos produtos:
Produto Núcleo (Em suas versões 7.5.0.1 7.1.1.5 e 7.1.1.6), Produto H (Em suas
versões 7.1.1, 6.5.1 e 6.5), Produto E (Em suas versões 7.1, 7.1.1, 7.5.0.1) e
Produto O (Em suas versões 7.5.1, 7.1 e 7.1.1).
As consultas 8.3 e 8.4 mostram que as principais falhas do processo de
verificação que deixaram a maioria destes defeitos escaparem são relacionadas aos
testes de verificação do sistema (SVT), principalmente na execução de funções
simples (Cobertura), aos testes de verificação de componentes (CVT),
principalmente na execução de funções simples (Cobertura), na execução de
funções com parâmetros (Variação) e na execução de funções na quais a ordem
realmente importa (Sequenciamento).
Já as consultas 8.5 e 8.6 mostram que as fases do processo de desenvolvimento
que deixaram a maioria dos defeitos de baixa e média severidade que não são
106 corrigidos dentro da iteração escaparem foram o projeto de baixo nível e a
construção do código.
4.4.9 – Hipótese 9
Para a hipótese 9, os critérios APAR, produto, versão, alvo e tipo de defeito
foram combinados para se recuperar os defeitos abertos por clientes que são
resolvidos como tal mesmo sem se ter certeza se eram defeitos ou pedidos de
melhoria e, também, para mostrar as fases do processo de desenvolvimento que
deixaram estes defeitos escaparem.
Tabela 75 - Resultados da consulta 9.1
Produto Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
Código Algoritmo 35808
Produto Núcleo
Código Algoritmo 3480
Produto Núcleo
Código Checagem 2052
Produto Núcleo
Código Atribuição 1938
Produto Núcleo
Código Atribuição 1788
Produto F Código Algoritmo 1584
Produto Q Código Algoritmo 1278
Produto H Código Checagem 1092
Produto E Código Algoritmo 966
Produto A Código Atribuição 912
A consulta 9.1, resumida na Tabela 75, mostra que a maioria dos defeitos
abertos por clientes e resolvidos como tal, mesmo sem se saber se eram defeitos ou
pedidos de melhoria, é relacionada aos produtos: Produto Núcleo, Produto F,
Produto Q e Produto H. Esta consulta também mostra que as fases do processo de
107 desenvolvimento que deixaram a maioria desses defeitos escaparem foram o projeto
de baixo nível e a construção do código.
Tabela 76 - Resultados da consulta 9.2
Produto Versão Alvo Tipo de Defeito Quantidade de defeitos
Produto Núcleo
6.2.0.1 Código Algoritmo 27822
Produto Núcleo
7.1.1.0 Código Algoritmo 13140
Produto Núcleo
6.2.2. Código Atribuição 6102
Produto Núcleo
7.5 Código Checagem 5592
Produto Núcleo
6.2.3 Código Algoritmo 4806
Produto Núcleo
6.2 Código Algoritmo 4764
Produto Núcleo
7.1 Código Checagem 4230
Produto Núcleo
7.1.1.7 Código Checagem 3378
Produto Núcleo
7.1.1.8 Código Atribuição 3366
Produto Núcleo
7.1.1.4 Código Atribuição 3042
A consulta 9.2, resumida na Tabela 76, mostra os defeitos da tabela 75
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 9.1 e 9.2 mostram que a maioria dos defeitos abertos por clientes e
resolvidos como tal, mesmo sem se ter certeza de serem defeitos ou pedidos de
melhoria é relacionada aos produtos: Produto Núcleo (Em suas versões 6.2.0.1,
7.1.1.0 e 6.2.2), Produto F (Em suas versões 6.2, 7.1.1.2 e 7.1.1.1), Produto Q (Em
suas versões 7.1.1.0, 6.3, 7.1) e Produto H (Em suas versões 7.1.1.0, 6.2.0.1 e 6.2).
As consultas 9.1 e 9.2 também mostram que as fases do processo de
desenvolvimento que deixaram a maioria desses defeitos escaparem foram o projeto
de baixo nível e a construção do código.
108
4.4.10– Hipótese 10
Para a hipótese 10, os critérios idade, produto, versão, alvo e tipo de defeito
foram combinados para se recuperar os defeitos relacionados a problemas em
código legado e também para se mostrar as fases do processo de desenvolvimento
que deixaram esses defeitos escaparem.
Tabela 77 - Resultados da consulta 10.1
Produto Quantidade de defeitos
Produto Núcleo
18156
Produto H 3480
Produto O 2706
Produto E 2592
Produto Q 2526
Produto J 1614
Produto A 1388
Produto M 956
Produto F 750
Produto L 690
A consulta 10.1, resumida na Tabela 77, mostra que a maioria dos defeitos
relativos à dificuldade de se manter o código legado é relacionada aos produtos:
Produto Núcleo, Produto H, Produto O e Produto E.
Tabela 78 - Resultados da consulta 10.2
Produto Versão Quantidade de defeitos
Produto Núcleo
7.1.1.5 5856
Produto Núcleo
7.1.1.0 5376
109
Produto Versão Quantidade de defeitos
Produto Núcleo
7.1.1.6 5148
Produto Núcleo
7.5.0.1 2982
Produto Núcleo
6.2.0.1 2958
Produto Núcleo
7.1.1.4 2928
Produto Núcleo
7.1.1.7 2784
Produto Núcleo
7.1 1626
Produto Núcleo
7.5 1554
Produto Núcleo
6.2.3 1554
A consulta 10.2, resumida na Tabela 78, identifica as versões dos produtos que
mais geraram defeitos relativos à dificuldade de se manter o código legado: versões
7.1.1.5, 7.1.1.0 e 7.1.1.6 do produto núcleo.
Tabela 79 - Resultados da consulta 10.3
Produto Tipo de Defeito
Quantidade de defeitos
Produto Núcleo
Algoritmo 6552
Produto Núcleo
Atribuição 5862
Produto Núcleo
Checagem 4368
Produto H Algoritmo 1788
Produto E Algoritmo 1458
Produto O Algoritmo 1440
Produto Q Algoritmo 1152
Produto Q Atribuição 1104
Produto O Atribuição 996
Produto E Atribuição 930
110
A consulta 10.3, resumida na Tabela 79, mostra, por produto, que as fases do
processo de desenvolvimento que deixaram a maioria dos defeitos relativos à
dificuldade de se manter o código legado escapar foram o projeto de baixo nível e a
construção do código.
Tabela 80 - Resultados da consulta 10.4
Produto Versão Tipo de Defeito
Quantidade de defeitos
Produto Núcleo
7.1.1.0 Algoritmo 2526
Produto Núcleo
7.1.1.6 Algoritmo 2388
Produto Núcleo
7.1.1.5 Algoritmo 2262
Produto Núcleo
7.1.1.4 Atribuição 1824
Produto Núcleo
7.1.1.5 Algoritmo 1638
Produto Núcleo
7.1.1.0 Checagem 1380
Produto Núcleo
7.1.1.6 Checagem 1356
Produto Núcleo
7.5.0.1 Checagem 1308
Produto Núcleo
7.1.1.0 Atribuição 1182
Produto Núcleo
7.1.1.6 Atribuição 1170
A consulta 10.4, resumida na Tabela 80, mostra os defeitos da Tabela 79
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 10.1 e 10.2 mostram que a maioria dos defeitos relativos à
dificuldade de se manter o código legado é relacionada aos produtos: Produto
Núcleo (Em suas versões 7.1.1.5, 7.1.1.0 e 7.1.1.6), Produto H (Em suas versões
6.5, 6.5.1 e 7.1), Produto O (Em suas versões 7.1.1, 7.1 e 7.5) e Produto E (Em suas
versões 7.1, 7.1.1 e 7.5.0.1).
111
As consultas 10.3 e 10.4 mostram que as fases do processo de desenvolvimento
que deixaram escapar a maioria dos defeitos relativos à dificuldade de se manter o
código legado foram o projeto de baixo nível e a construção do código.
4.4.11– Hipótese 11
Para a hipótese 11, os critérios alvo, qualificador, produto, versão e tipo de
defeito foram combinados para se recuperar os defeitos relacionados a problemas
gerados pela falta de conhecimento das regras de negócio dos serviços do software
base pelos gerentes do produto e também para se mostrar as fases do processo de
desenvolvimento que deixaram estes defeitos escaparem.
Tabela 81 - Resultados da consulta 11.1
Produto Tipo de Defeito
Quantidade de defeitos
Produto Núcleo
Algoritmo 234
Produto Núcleo
Atribuição 216
Produto Núcleo
Interface 216
Produto Núcleo
Função 156
Produto J Atribuição 138
Produto Núcleo
Checagem 120
Produto P Algoritmo 84
Produto J Checagem 84
Produto O Algoritmo 66
Produto E Algoritmo 66
A consulta 11.1, resumida na Tabela 81, mostra que a maioria dos defeitos
relativos à falta de conhecimento das regras de negócio dos serviços básicos pelos
gerentes de produto é relacionada aos produtos: Produto Núcleo, Produto P,
112 Produto J e Produto O. A consulta 11.1 também mostra que as fases do processo de
desenvolvimento que deixaram a maioria destes defeitos escapar foram o projeto de
baixo nível e a construção do código.
Tabela 82 - Resultados da consulta 11.2
Produto Versão Tipo de Defeito
Quantidade de defeitos
Produto Núcleo
7.5.0.1 Interface 96
Produto Núcleo
7.5.0.1 Algoritmo 78
Produto J 7.1.1 Atribuição 78
Produto Núcleo
7.1.1.5 Atribuição 54
Produto O 7.1 Algoritmo 54
Produto E 7.1.1.0 Algoritmo 54
Produto Núcleo
7.5 Interface 48
Produto Núcleo
7.5.0.1 Checagem 48
Produto Núcleo
7.5.0.1 Função 48
Produto Núcleo
6.2.3 Algoritmo 42
A consulta 11.2, resumida na Tabela 82, mostra os defeitos da tabela 81
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 11.1 e 11.2 mostram que a maioria dos defeitos relativos à falta de
conhecimento das regras de negócio dos serviços básicos pelos gerentes de
produto é relacionada aos produtos: Produto Núcleo (Em suas versões 7.5.0.1,
7.5.0.1 e 7.1.1.5), Produto P (Em suas versões 7.1.1, 7.5 e 7.1), Produto J (Em suas
versões 7.1.1, 7.5 e 7.1) e Produto O (Em suas versões 7.1, 7.1.1 e 7.5.1). As
consultas 11.1 e 11.2 também mostram que as fases do processo de
desenvolvimento que deixaram a maioria destes defeitos escapar foram o projeto de
baixo nível e a construção do código.
113
4.4.12– Hipótese 12
Para a hipótese 12, os critérios alvo, qualificador, produto, versão, tipo de defeito,
atividade e gatilho foram combinados para se recuperar os defeitos relativos à
tradução dos produtos da linha para vários idiomas, para se mostrar as falhas do
processo de verificação e as fases do processo de desenvolvimento que deixaram
esses defeitos escaparem.
Tabela 83 - Resultados da consulta 12.1
Produto Tipo de Defeito
Quantidade de defeitos
Produto B Habilitação 288
Produto J Habilitação 198
Produto E Expectativa 96
Produto Núcleo
Tradução 60
Produto O Interface de Usuário
60
Produto Q Expectativa 54
Produto Núcleo
Habilitação 42
Produto A Tratamento 42
Produto Núcleo
Interface de Usuário
36
Produto G Habilitação 30
A consulta 12.1, resumida na Tabela 83, mostra que a maioria dos defeitos
relativos à tradução dos produtos da linha para vários idiomas é relacionada aos
produtos: Produto B, Produto J, Produto E e Produto Núcleo. A consulta 12.1
também mostra que as fases do processo de desenvolvimento que deixaram a
maioria destes defeitos escapar foi a construção do código, principalmente na sua
tentativa de habilitar um ambiente de linguagens múltiplas (Habilitação), na
capacidade de lidar com entradas e saídas em outros idiomas que não o inglês
(Expectativa) e na capacidade de lidar com caracteres específicos de outros idiomas
114 que não o inglês (Tratamento).
Tabela 84 - Resultados da consulta 12.2
Produto Versão Tipo de Defeito
Quantidade de defeitos
Produto B 7.5 Habilitação 288
Produto E 7.1 Expectativa 78
Produto J 7.1 Habilitação 72
Produto J 7.5 Habilitação 72
Produto J 7.1.1 Habilitação 48
Produto Q 7.1 Expectativa 48
Produto A 7.1 Tratamento 42
Produto Núcleo
7.1.1.5 Habilitação 30
Produto J 7.1 Expectativa 30
Produto B 7.5 Interface de Usuário
24
A consulta 12.2, resumida na Tabela 84, mostra os defeitos da tabela 83
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Tabela 85 - Resultados da consulta 12.3
Produto Atividade Gatilho Quantidade de defeitos
Produto B CVT Cobertura 186
Produto J CVT Cobertura 174
Produto B CVT Cobertura 72
Produto O CVT Cobertura 72
Produto Núcleo
CVT Cobertura 66
Produto P CVT Cobertura 54
Produto G CVT Cobertura 48
Produto E CVT Cobertura 48
Produto Q CVT Cobertura 42
Produto F CVT Cobertura 36
115
A consulta 12.3, resumida na Tabela 85, mostra, por produto, que as principais
falhas do processo de verificação, que deixaram escapar a maioria dos defeitos
relativos à tradução dos produtos da linha para vários idiomas são relacionadas aos
testes de verificação de componentes (CVT), principalmente na execução de
funções simples (Cobertura).
Tabela 86 - Resultados da consulta 12.4
Produto Versão Atividade Gatilho Quantidade de defeitos
Produto B 7.5 CVT Cobertura 186
Produto B 7.5 CVT Cobertura 72
Produto J 7.5 CVT Cobertura 66
Produto J 7.1 CVT Cobertura 60
Produto J 7.1.1 CVT Cobertura 42
Produto Núcleo
7.1.1.5 CVT Cobertura 36
Produto F 7.5 CVT Cobertura 36
Produto G 7.1 CVT Cobertura 36
Produto O 7.1.1 CVT Cobertura 36
Produto Q 7.1 CVT Cobertura 36
A consulta 12.4, resumida na Tabela 86, mostra os defeitos da tabela 85
detalhados pelas versões dos produtos que mais geraram esses defeitos.
Logo, pode-se concluir, em relação a essa hipótese que:
As consultas 12.1 e 12.2 mostram que a maioria dos defeitos relativos à tradução
dos produtos da linha para vários idiomas é relacionada aos produtos: Produto B
(Em sua versão 7.5), Produto J (Em suas versões 7.1, 7.5 e 7.1.1), Produto E (Em
suas versões 7.1, 7.1.1 e 7.1.2) e Produto Núcleo (Em suas versões 7.1.1.5, 7.1.1.6
e 7.5). As consultas 12.1 e 12.2 também mostram que as fases do processo de
desenvolvimento que deixaram a maioria desses defeitos escapar foi a construção
do código, principalmente na sua tentativa de habilitar um ambiente de linguagens
116 múltiplas (Habilitação), na capacidade de lidar com entradas e saídas em outros
idiomas que não o inglês (Expectativa) e na capacidade de lidar com caracteres
específicos de outros idiomas que não o inglês (Tratamento).
As consultas 12.3 e 12.4 mostram que as principais falhas do processo de
verificação que deixaram a maioria dos defeitos relativos à tradução dos produtos da
linha para vários idiomas escapar são relacionadas aos testes de verificação de
componentes (CVT), principalmente na execução de funções simples (Cobertura).
4.5 Conclusão
Neste capítulo, foi apresentada a matriz de congruência montada a partir da
tabulação dos dados da base de registros de defeitos ODC utilizada no estudo. A
comparação com a matriz de congruência apresentada por Saraiya, Lohner e Balk
(2006) (tabela 5) mostra uma boa similaridade entre ambas, dando confiança na
qualidade dos dados utilizados neste estudo.
A seguir, são apresentados os resultados mais significativos das consultas
usadas para se responder as hipóteses de problemas levantadas no item 3.3. A
análise desses resultados levou à descoberta dos principais padrões de defeitos que
irão auxiliar na resposta às hipóteses investigadas neste estudo. Com essas
descobertas, pode-se elaborar as propostas das tarefas de melhorias nos processos
de manutenção que serão apresentadas e discutidas no próximo capítulo.
117 5 AVALIAÇÃO DAS ANÁLISES DOS RESULTADOS
Este capítulo mostra a avaliação, pelos especialistas em ODC e no processo de
desenvolvimento da linha de produto de software em questão, das hipóteses de
problemas apresentadas no Capítulo 3, da montagem das consultas usadas para se
recuperar os dados de defeitos, também apresentadas no Capítulo 3, e das análises
dos resultados das consultas apresentadas no Capítulo 4.
5.1 Avaliação das análises por especialista
5.1.1 – Especialista 1
O primeiro especialista consultado trabalha com o método ODC de classificação
de defeitos há 15 anos, tendo participado de mais de 25 projetos nos quais o ODC
foi usado. Ele não conhece o domínio do problema, ou seja, não conhece a linha de
produto de software objeto de estudo do trabalho em questão, mas tem um amplo
conhecimento do ODC, inclusive participando da equipe que propôs melhorias para
a versão 5.1 do método.
Em relação às hipóteses de problemas, esse especialista, mesmo não
conhecendo a linha de produto de software em questão, mas após uma rápida
explicação do ambiente da mesma, disse que a maioria das hipóteses parece ser
válida, que algumas delas podem ser encontradas, inclusive, em outros tipos de
projeto. Contudo, ele não se convenceu de que a hipótese 5 estivesse correta e
disse que as hipóteses 6 e 7 são muito parecidas. Ele sugeriu que fosse verificado
com um especialista na linha de produto de software em questão o que deve ser
feito em relação a estas três hipóteses.
Em relação aos dados de defeitos apresentados no Capítulo 4, o especialista 1
disse que as verificações em relação à qualidade dos dados, também apresentadas
no Capítulo 4 são de vital importância, pois como os dados são o ponto central para
se tirar as conclusões, eles devem ser confiáveis. Ele concordou com as verificações
118 apresentadas e disse que, mesmo sem conhecer as mesmas, elas parecem ser um
bom indício de que a base de dados de defeitos possui uma boa confiabilidade.
Em relação às análises sobre os dados de defeitos, também apresentadas no
Capítulo 4, o primeiro especialista consultado disse que concorda com as mesmas,
pois elas se baseiam em um artigo do criador do método ODC, (Chillarege et al,
1992). Ele completou dizendo que métodos de análise semelhantes (baseados no
mesmo artigo) foram usados em projetos dos quais ele participou, mas sobre
amostras pequenas de dados de defeitos e para se resolver problemas pontuais.
5.1.2 – Especialista 2
O segundo especialista consultado trabalha com o método ODC de classificação
de defeitos e com a linha de produtos de software em questão há 6 anos, tendo
participado de projetos do software base e de vários dos software específicos, tendo
usado o ODC em todos eles. Atualmente, ele é uma das referências em ODC dentro
do grupo que desenvolve a linha de produto em questão, inclusive propondo
mudanças relativas ao seu uso pelo grupo.
Em relação às hipóteses de problemas, o especialista 2 disse que as mesmas
são válidas, em sua opinião, pois ele mesmo experimentou quase que a totalidade
dessas hipóteses. Ele sugeriu que se juntasse as hipóteses 6 e 7, pois,
semanticamente, elas são iguais, o que confirma a suspeita do especialista 1.
Contudo, e diferentemente da opinião do especialista 1, ele acredita que a hipótese
5 seja válida.
Sobre os dados de defeitos apresentados no Capítulo 4, o especialista 2 também
disse que as verificações em relação à qualidade dos dados são importantes e que
as verificações apresentadas no trabalho são um bom indício de que os dados da
base de dados de defeitos apresentam uma confiabilidade alta. Além disso, como
um dos validadores dos dados de defeitos em algumas versões de alguns produtos,
ele acredita que o preenchimento dos campos ODC, em cada um dos defeitos,
tenha boas chances de estar correto.
Em relação às análises sobre os dados de defeitos, também apresentadas no
Capítulo 4, o segundo especialista acredita na validade das mesmas, principalmente
119 pelo conhecimento acumulado no desenvolvimento da linha de produtos em análise,
e por sua vasta experiência com análises pontuais de dados de defeitos
classificados pelo ODC, em cada um desses projetos. Ele completou dizendo que
métodos de análise semelhantes também foram usados em algumas equipes das
quais ele fez parte, mas sobre amostras pequenas de dados de defeitos.
5.1.3 – Especialista 3
O terceiro especialista consultado trabalha com a linha de produtos de software
em questão e com o método ODC de classificação de defeitos há 11 anos, tendo
participado do projeto de algumas versões do software base e liderado várias
equipes de vários produtos da linha, durante o desenvolvimento de muitas versões.
Ele é um dos desenvolvedores/líderes com maior grau de conhecimento sobre a
linha de produtos no time, sendo também uma referência em relação à classificação
de defeitos.
Em relação às hipóteses de problemas, esse especialista disse que a maioria
das hipóteses é válida. Que a hipótese 8 precisa ser reescrita, pois ele só conseguiu
entendê-la depois de uma explicação mais detalhada sobre a mesma. Contudo, ele
concorda com o especialista 1 que as hipóteses 6 e 7 são muito parecidas, e que
talvez devessem virar apenas uma hipótese. E ele também disse que talvez uma
hipótese sobre a falta de testes de integração entre os produtos devesse ser
adicionada à lista.
Em relação aos dados de defeitos apresentados no Capítulo 4, o especialista 3
também concordou com a opinião dos outros dois especialistas sobre a importância
das verificações em relação à qualidade dos dados. Ele também mencionou que as
verificações apresentadas parecem ser um bom indício de que os dados da base de
dados de defeitos possuem uma boa confiabilidade. Além disso, como conhecedor
das equipes de desenvolvimento do software base e dos produtos específicos, ele
acredita que o preenchimento dos campos ODC, em cada um dos defeitos, tenha
boas chances de estar correto.
Em relação às análises sobre os dados de defeitos, também apresentadas no
Capítulo 4, o terceiro especialista consultado disse que as mesmas parecem ser
120 válidas, principalmente pelo seu conhecimento acerca dos times e dos produtos cujo
desenvolvimento ele liderou, mesmo não conhecendo o artigo do criador do método
ODC, (Chillarege et al, 1992), no qual as análises foram baseadas. Ele completou
dizendo que métodos de análise semelhantes foram usados em algumas das
equipes que ele liderou, mas sobre amostras pequenas de dados de defeitos e para
se resolver problemas pontuais e que a análise realizada sobre a base de dados
inteira, como a apresentada neste trabalho, faz mais sentido, pois, assim, pode-se
chegar a padrões de defeitos que poderiam estar escondidos, caso a análise feita
fosse específica. Ele, inclusive, compartilhou o material dessas análises pontuais.
5.2 Conclusão
Neste capítulo, foram mostradas as validações dos especialistas em ODC e no
processo de desenvolvimento da linha de produto de software em questão com
relação às hipóteses de problemas apresentadas no Capítulo 3, à montagem das
consultas usadas para se recuperar os dados de defeitos, também apresentadas no
capítulo 3 e às análises dos resultados apresentadas no Capítulo 4.
Os especialistas consultados concordaram com o método apresentado, fazendo
algumas ressalvas, apenas, em relação às hipóteses 5,6,7 e 8. As hipóteses 5 e 8
foram removidas do trabalho e as hipóteses 6 e 7 foram fundidas em uma só. As
hipóteses originais encontram-se no apêndice deste trabalho. Com isso, pode-se
apresentar as propostas de tarefas de melhoria no processo de manutenção para se
enfrentar o cenário apresentado na Seção 1.1 deste trabalho, para a linha de
produto de software em questão.
121 6 ELABORAÇÃO DE PROPOSTAS DE TAREFAS DE MANUTENÇÃO
Este capítulo mostra a proposição de algumas tarefas de melhoria nos processos
de manutenção que poderão ser aplicadas visando a diminuição das falhas das
partes do processo que foram identificadas como necessitando de revisão.
6.1 Propostas relacionados aos testes
6.1.1 A revisão do processo de escrita dos casos de teste da bateria de testes
de verificação de componentes (CVT).
Essa proposta justifica-se pelos resultados das consultas 1.5, 1.6, 1.7, 1.8, 2.1,
2.2, 3.3, 3.4, 4.3, 4.4, 5.1, 5.2, 5.3, 5.4, 6.3, 6.4, 7.4, 7.5, 8.3, 8.4, 12.3 e 12.4.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de dezenas de milhar) escapou
devido às falhas ou à incompleteza dos casos de teste da bateria de testes de
verificação de componentes.
Dentro da revisão desse processo, adicionar uma tarefa para que o gerente do
produto revise ou inspecione cada um dos casos de teste da bateria de testes de
verificação de componentes, para garantir que os mesmos estejam de acordo com
todos os itens da especificação de requisitos. Essa revisão feita pelo gerente de
produtos visa a diminuição do alto número de erros relacionados às falhas nos
testes de verificação de componentes.
Ainda dentro desde processo de revisão, adicionar alguns casos de teste para se
cobrir tanto a execução de funções nas quais a ordem interessa, como a execução
de duas ou mais funções relacionadas.
O especialista 2, em seus comentários sobre a proposta acima, concordou que
uma revisão, desde que detalhada e com a presença de membros da equipe de
desenvolvimento, da equipe de teste e do gerente de produto, é válida e pode
minimizar os problemas relacionados aos testes de verificação de componentes.
122 Segundo ele, essa revisão detalhada dos casos de testes não acontece com muita
frequência, principalmente nas equipes que desenvolvem o Produto Núcleo, por
existirem vários gerentes de produto para ele.
O especialista 3 também concordou que uma revisão detalhada dos casos de
testes pode ajudar a minimizar os problemas relacionados aos testes de verificação
de componentes. Contudo, ele acredita que essa revisão seria benéfica apenas se
os gerentes de produto e os líderes dos times de desenvolvimento e teste
participassem e depois replicassem o que foi decidido para seus times,
principalmente para as equipes do Produto Núcleo e do Produto O, que possuem
muitas pessoas.
6.1.2 A revisão do processo de escrita dos casos de teste da bateria de testes de
verificação de sistema.
Essa proposta baseia-se nos resultados das consultas 2.1, 2.2, 3.3, 3.4, 4.3, 4.4,
5.1, 5.2, 5.3, 5.4, 6.3, 6.4, 7.4, 7.5, 8.3 e 8.4.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de milhares) escapou devido às
falhas ou à incompleteza dos casos de teste da bateria de testes de verificação de
sistema.
Dentro da revisão desse processo, adicionar uma tarefa para que o gerente do
produto revise ou inspecione cada um dos casos de teste da bateria de testes de
verificação de sistema, para garantir que os mesmos estejam de acordo com todos
os itens da especificação de requisitos e com a integração de todos os requisitos.
Ainda dentro desde processo de revisão, adicionar casos de teste para se cobrir
a execução de testes em configurações específicas de software e de testes de carga
e estresse do sistema. Esses casos de teste serão úteis, pois um grande número de
defeitos acontece apenas em configurações específicas de software e também um
grande número está relacionado ao desempenho dos produtos como mostrado nos
resultados das consultas 3.3, 3.4, 5.4, 6.3 e 6.4.
O especialista 2 comentou que, na maioria dos projetos em que ele participou, os
casos de teste de verificação do sistema foram derivados dos casos de teste de
123 verificação de componentes. Logo, ele acredita que o detalhamento dos testes de
verificação de sistema deve ser feito com base no detalhamento dos testes de
verificação de componente e deve ter um envolvimento maior dos gerentes de
produto.
O especialista 3 comentou que as reuniões para a revisão do processo de escrita
dos casos de teste de verificação do sistema devem ser feitas apenas pelos líderes
técnicos das equipes de teste e desenvolvimento e pelo gerente de produto e que,
se os recursos forem limitados, ele apenas proporia a revisão dos casos de teste de
componentes, por terem uma cobertura mais ampla do que os casos de teste de
verificação de sistema.
6.1.3 A revisão do processo de escrita do código dos testes de unidade para
casos de teste simples e complexos.
Esta proposta é justificada pelos resultados das consultas 5.1, 5.2, 5.3, 5.4, 6.3,
6.4, 7.4 e 7.5.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem dos milhares) escapou devido às
falhas ou à incompleteza do código dos testes de unidade.
O especialista 2 concordou com a proposta acima, sem fazer nenhum
comentário.
O especialista 3 comentou que a proposta é válida, mas que o framework para o
desenvolvimento dos mesmos é muito complexo e os desenvolvedores não usam
todo o seu potencial. Logo, esse framework deveria ser simplificado ou um
treinamento sobre as funções mais complexas do framework deveria ser montado e
ministrado para todos os desenvolvedores dos times dos produtos da linha de
produtos em questão.
124
6.2 Propostas relacionados ao desenvolvimento
6.2.1 O aumento do detalhamento do projeto de baixo nível.
Essa proposta é justificada pelos resultados das consultas 2.3, 2.4, 3.5, 3.6, 4.5,
4.6, 5.2, 5.4, 6.5, 6.6, 7.6, 7.7, 8.5, 8.6, 9.1, 9.2, 10.3, 10.4, 11.1 e 11.2.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de dezenas de milhar) escapou
devido à falta de detalhamento do documento que representa o projeto de baixo
nível para os produtos da linha de produto em questão.
O projeto de baixo nível, ou projeto detalhado, dentro do processo de
desenvolvimento dos produtos da linha de produtos em questão é representado por
um documento que apenas detalha os requisitos. Essa proposta sugere que este
documento também descreva as mudanças relacionadas ao banco de dados, ao
código e à interface de usuários, que devem ser implementadas para cada requisito.
Além disso, o documento deve apresentar as alternativas e boas práticas de
implementações desses requisitos usando o framework padrão e deve ser escrito
pelo líder do time de desenvolvimento.
Os especialistas 2 e 3 concordaram com a proposta relativa ao detalhamento do
projeto de baixo nível.
6.2.2 A criação de reuniões de revisão ou inspeção do projeto de baixo nível com
os desenvolvedores.
Essa proposta é justificada pelos resultados das consultas 2.3, 2.4, 3.5, 3.6, 4.5,
4.6, 5.2, 5.4, 6.5, 6.6, 7.6, 7.7, 8.5, 8.6, 9.1, 9.2, 10.3, 10.4, 11.1 e 11.2.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de dezenas de milhar) escapou
devido à falta de detalhamento do documento que representa o projeto de baixo
nível para os produtos da linha de produto em questão.
125
O documento que representa o projeto de baixo nível, que será detalhado de
acordo com a proposta anterior, deve ser revisado ou inspecionado, em reuniões
específicas para tal finalidade. Essas reuniões devem contar com o líder do time de
desenvolvimento e os outros desenvolvedores da equipe, para garantir que todos
estejam ciente e que entendam o seu conteúdo.
O especialista 2 concordou com a proposta relativa às reuniões de revisão ou
inspeção do projeto de baixo nível, desde que o gerente de produto e o líder técnico
da equipe de desenvolvimento estejam presentes em todas as reuniões, em
conjunto com os outros membros da equipe.
O especialista 3 também concordou com a proposta relativa às reuniões de
revisão ou inspeção do projeto de baixo nível.
6.2.3 O aumento da frequência de acontecimento das reuniões de revisão de
código entre os desenvolvedores e o líder técnico do time.
Essa proposta é justificada pelos resultados das consultas 2.3, 2.4, 3.5, 3.6, 4.5,
4.6, 5.2, 5.4, 6.5, 6.6, 7.6, 7.7, 8.5, 8.6, 9.1, 9.2, 10.3, 10.4, 11.1 e 11.2.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de dezenas de milhar) escapou
devido às falhas relacionadas ao código de implementação das funcionalidades e
correções de defeitos dos produtos da linha de produto em questão.
O especialista 2 concordou com a proposta relativa às reuniões de revisão de
código, sem nenhum comentário.
O especialista 3 também concordou com a proposta relativa às reuniões de
revisão de código. O seu único comentário foi que uma outra possível proposta seria
a construção de um documento de boas práticas de codificação pelos líderes de
desenvolvimento, baseado nos principais erros encontrados.
6.2.4 A inclusão de um treinamento para os líderes dos times de
desenvolvimento e de testes sobre a configuração do scripts de geração
automática de builds para que esses possam dar manutenção nesses scripts
126
caso necessário.
Essa proposta é justificada pelos resultados das consultas 3.5 e 3.6.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de centenas) escapou devido à falta
de conhecimento relacionado à manutenção dos scripts de geração automática de
builds dos produtos da linha de produto em questão.
Os scripts de geração automática dos builds são mantidos pelo time de infra-
estrutura, contudo, quando esses precisam de manutenção esta é geralmente
demorada. Logo, é sugerido que os líderes dos times de desenvolvimento e testes
tenham um treinamento de como configurar e dar manutenção nesses scripts para
agilizar este processo e minimizar os erros.
O especialista 2 concordou com a proposta acima, sem fazer nenhum
comentário.
O especialista 3 também concordou com a proposta acima, mas acha que esse
treinamento deve ser estendido para todos os membros das equipes de teste e de
desenvolvimento, para acelerar a manutenção desses scripts, caso seja necessário.
6.2.5 A revisão do uso, por parte dos desenvolvedores, no código, de bibliotecas
externas para se habilitar o mesmo a tratar de forma automática o uso de mais
de um idioma na aplicação e a tradução de termos e palavras entre estes
idiomas.
Essa proposta é justificada pelos resultados das consultas 12.1 e 12.2.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de milhares) escapou devido à falta
de conhecimento, por parte dos desenvolvedores, das bibliotecas externas que
tratam da tradução automática de termos para idiomas que não o inglês para os
produtos da linha de produto em questão.
Como todos os produtos da linha de produtos em questão são traduzidos para
vários idiomas, várias bibliotecas que possibilitam a tradução do inglês para um
127 outro idioma são usadas no código. Logo, os novos desenvolvedores devem receber
uma orientação de como usar essas bibliotecas no código, pois o seu mau uso é o
principal fator de geração de defeitos relacionados à tradução.
O especialista 2 concordou com a proposta acima, sem fazer nenhum
comentário.
O especialista 3 também concordou com a proposta acima, mas comentou que
essas bibliotecas deveriam ser documentadas e que essa documentação deveria ser
mantida no sistema de versionamento de arquivos da linha de produtos em questão.
6.3 Propostas sugeridas pelos especialistas
6.3.1 Adição de uma reunião de demonstração da funcionalidade pronta, para o
gerente de produto, antes do término do ciclo de desenvolvimento, para garantir
aderência da funcionalidade à especificação de requisitos.
Essa proposta é justificada pelos resultados das consultas 5.2 e 5.4.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de milhares) escapou devido ao
desenvolvimento de funcionalidades que não atendem aos requisitos especificados
pelo gerente de produto para os produtos da linha de produto em questão.
O especialista 2 propôs que, após o término do desenvolvimento de uma
determinado funcionalidade ou requisito pelo time de desenvolvimento, seja
realizada uma reunião de demonstração dessa funcionalidade para o gerente do
produto. A finalidade desta demonstração é verificar, por parte do gerente do
produto, a aderência do que foi desenvolvido à especificação de requisitos o quanto
antes.
6.3.2 A revisão de todos os defeitos abertos por clientes, antes que os mesmos
comecem a ser corrigidos, pelos gerentes do produto ou pelo líder técnico de
desenvolvimento, para garantir que os mesmos são defeitos.
Essa proposta é justificada pelos resultados das consultas 9.1 e 9.2.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
128 uma grande quantidade de defeitos (na ordem de dezenas de milhar) foram
corrigidos sem se ter a certeza de serem realmente defeitos ou pedidos de melhoria
realizados pelos clientes.
Essa proposta foi sugerida pelo especialista 3 e diz respeito à realização de uma
revisão de cada defeito aberto por cliente contra as especificações de requisitos do
produto, para a garantia de que os mesmos são defeitos e não pedidos de melhoria.
Como os pedidos de melhoria não são cobertos nos contratos de suporte do
produto, esta proposta evitaria perdas financeiras.
6.3.3 A construção de um documento de boas práticas de codificação pelos
líderes de desenvolvimento, baseado nos principais erros encontrados.
Essa proposta é justificada pelos resultados das consultas 2.3, 2.4, 3.5, 3.6, 4.5,
4.6, 5.2, 5.4, 6.5, 6.6, 7.6, 7.7, 8.5, 8.6, 9.1, 9.2, 10.3, 10.4, 11.1 e 11.2.
Os resultados das consultas mencionadas no parágrafo anterior mostram que
uma grande quantidade de defeitos (na ordem de dezenas de milhar) escapou
devido às falhas relacionadas ao código de implementação das funcionalidades e
correções de defeitos dos produtos da linha de produto em questão.
Essa proposta foi feita pelo especialista 2 e sugere que o líder do time de
desenvolvimento crie e atualize constantemente um documento com boas práticas
de codificação. Este documento deverá ser criado com base no framework de
desenvolvimento usado e nos principais erros de codificação encontrados. Este
documento deverá ser entregue a todos os novos desenvolvedores das equipes de
desenvolvimento dos produtos da linha de produtos em questão.
6.4 Conclusão
Neste capítulo, foram apresentadas propostas de melhoria nas tarefas de
manutenção baseadas nos resultados das consultas realizadas. Essas propostas de
melhorias nas tarefas poderão ser aplicadas visando a diminuição dos defeitos
129 encontrados durante o desenvolvimento dos diversos produtos da linha e,
consequentemente, a diminuição das falhas de partes desse processo.
Essas propostas poderão ser aplicadas, em trabalhos futuros, no mesmo
ambiente da linha de produto em questão ou em ambientes similares para que se
verifique, com dados, a sua eficácia.
130 7 CONCLUSÃO
7.1 Resumo
Neste trabalho, foi analisada uma linha de produto de software desenvolvida em
um curto espaço de tempo, sem se seguir um processo específico para o
desenvolvimento de linhas de produto, e sem possuir um processo de manutenção
de software específico. O trabalho mostrou os resultados da execução de consultas
sobre uma base de dados de defeitos classificadas pelo método ODC para, através
da análise desses dados, propor melhorias nas práticas de manutenção.
Em uma revisão da literatura, não foram encontrados trabalhos práticos que
usassem a análise dos dados de defeitos classificados pelo método ODC para se
propor melhorias nas práticas de manutenção para os produtos de uma linha de
produto de software.
O exemplo prático deste trabalho baseou-se na verificação de 12 hipóteses de
problemas levantadas por vários participantes das equipes de desenvolvimento dos
vários produtos da linha de produtos em questão, e que foram validadas por
especialistas. O exemplo prático também foi baseado nos critérios da base de dados
de defeitos e do método ODC, para que as consultas fossem montadas. Essas
consultas foram executadas para se recuperar dados relativos aos defeitos. Esses
dados foram tabulados e analisados, com base nos critérios do método ODC, para
que se pudessem propor melhorias nas práticas de manutenção para se resolver
cada um dos 12 problemas.
O exemplo prático do trabalhou mostrou que a maioria dos defeitos é encontrada
no software base e que eles resultam de problemas na cobertura dos testes de
verificação de componentes, na execução de seus casos mais simples e de
problemas na construção do código e no projeto de baixo nível. A partir dessas
constatações, as principais práticas de manutenção propostas foram: um maior
detalhamento do projeto de baixo nível, mais sessões de revisão de código e de
revisão dos casos de teste de verificação de componentes, principalmente pela
equipe de desenvolvimento do software base.
Segundo depoimentos dos especialistas consultados, nenhuma análise de dados
131 baseados no método ODC, do seu conhecimento, utilizou uma base de dados tão
extensa como a usada neste trabalho.
Uma limitação da abordagem proposta neste trabalho é que ela é fortemente
baseada na qualidade dos dados de classificação de defeitos presentes na base.
Por isso, algumas técnicas de avaliação de qualidade de dados foram empregadas
no trabalho, para se garantir que os mesmos eram confiáveis.
7.2 Contribuições
Diferentes abordagens para tratar de problemas relacionados à manutenção e
evolução em linhas de produtos de software têm sido sugeridas. A abordagem
proposta neste trabalho aplica-se a ambientes nos quais dados de defeitos relativos
aos produtos da linha estejam disponíveis e sejam classificados através do método
ODC.
Essa abordagem foi avaliada por especialistas, tanto em ODC quanto no
processo de desenvolvimento da linha de produtos de software em questão. Esses
especialistas deram sugestões para a melhoria da abordagem. Essa interação com
esses especialistas, bem como a validação e as sugestões de melhoria na
abordagem também podem ser consideradas como contribuições do trabalho.
O desenvolvimento do trabalho prático permitiu chegar às propostas de
melhorias nas tarefas de manutenção para a linha de produto de software em
questão. Mas essas propostas, também, podem ser aplicadas a linhas de produto de
software semelhantes, ou seja, que tenham sido desenvolvidas sem a aplicação de
nenhum processo de desenvolvimento específico para linhas de produto de
software. As próprias tarefas de manutenção propostas, por si só, são contribuições
do trabalho.
132
7.3 Trabalhos futuros
As propostas de tarefas de manutenção apresentadas no Capítulo 6 poderão ser
aplicadas, em trabalhos futuros, no mesmo ambiente da linha de produto em
questão ou em ambientes similares para que se verifique, com dados reais de
projetos, a sua eficácia. De preferência, para que os dados fossem os mais corretos
possíveis, essa aplicação deveria se dar em pelo menos um ciclo de
desenvolvimento completo de uma versão do software base e de uma versão de um
dos produtos filhos.
Outra proposta de trabalho futuro seria um estudo de caso relativo a linhas de
produto de software diferentes, que também tenham sido desenvolvidas sem a
utilização de um processo específico de desenvolvimento de linhas de produto. Com
esse estudo, poderia se verificar quais são os principais problemas encontrados
nessas linhas e tentar aplicar uma abordagem mais genérica para a resolução dos
problemas mais comumente enfrentados.
133 REFERÊNCIAS BASSIN, K.; SANTHANAM, P. Managing the Maintenance of Ported, Outsourced, and Legacy Software via Orthogonal Defect Classification In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE, 17th, 2001, Florence, Italy, Proceedings of the Seventeenth IEEE International Conference on Software Maintenance. Florence: IEEE, 2001. p. 726-734 BUTCHER, M.; MUNRO, H.; KRATSCHMER, T. IMPROVING SOFTWARE TESTING VIA ODC: THREE CASE STUDIES. IBM SYSTEMS JOURNAL, YORKTOWN HEIGHTS, P.31-44, JAN/FEB/MAR. 2002. CHAUDHARY, A.; VERMA, B.; RAHEJA, J. Product Line Development Architectural Model. In: IEEE INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND INFORMATION TECHNOLOGY, 3rd, 2010, Chengdu, China, Proceedings of the Third IEEE International Conference on Computer Science and Information Technology. Chengdu: IEEE, 2010. p. 749-753 CHEN, Y.; GANNOD, G.; COLLOFELLO, J.; SARJOUGHIAN, H. Using SImulation to Facilitate the Study of Software Product Line Evolution. In: IEEE INTERNATIONAL WORKSHOP ON PRINCIPLES OF SOFTWAEE EVOLUTION, 7th, 2004, Kyoto, Japan, Proceedings of the Seventh International Workshop on Software Evolution. Kyoto: IEEE, 2004. p. 103-112 CHILLAREGE, R. et al. Orthogonal Defect Classification-A Concept for In-Process Measurements. IEEE Transactions on Software Engineering, Los Alamitos, p.943-956, November. 1992. CHILLAREGE, R. Understanding Bohr-Mandel bugs through ODC Triggers and a case study with empirical estimations of their field proportion. In: IEEE INTERNATIONAL WORKSHOP ON SOFTWARE AGING AND REJUVENATION, 3rd, 2011, Hiroshima, Japan, Proceedings of the Third International Workshop on Software Aging and Rejuvenation. Hiroshima: IEEE, 2011. p. 7-13 D’AMBROS, M. Supporting Software Evolution Analysis with Historical Dependencies and Defect Information. In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE, 24th, 2008, Beijing, China, Proceedings of the Twenty Fourth International Conference on Software Maintenance. Beijing: IEEE, 2008. p. 412-415 DHUNGANA, D.; NEUMAYER, T.; GRUNBACHER, P.; RABISER, R. Supporting Evolution in Model-based Product Line Engineering. In: INTERNATIONAL
134 SOFTWARE PRODUCT LINE CONFERENCE, 12th, 2008, San Francisco, California, Proceedings of the Twelfth International Software Product Line Conference. San Francisco: IEEE, 2008. p. 319-328 EL EMAM, K.; WIECZOREK, I. The Repeatability of Code Defect Classifications. In: IEEE INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING, 9th, 1998, Paderbom, Germany, Proceedings of the Ninth IEEE International Symposium on Software Reliability Engineering. Paderbom: IEEE, 1998. p. 322-333 GRUBB. P.; TAKANG, A. Software Maintenance: Concepts and Practice London: World Scientific Publishing Company, 2003. 372p. HE, W.; HAO, W.; ZHIQING, L. Improving Classification Efficiency of Orthogonal Defect Classification via Bayesian Network Approach. In: IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWAEE ENGINEERING, 26th, 2011, Lawrence, Kansas, Proceedings of the Twenty Sixth International Conference on Automated Software Engineering. Lawrence: IEEE/ACM, 2011. p. 412-415 HUANG, L.; NG, V.; PERSING, I.; GENG, R.; BAI, X.; TIAN, J. AutoODC: Automated Generation of Orthogonal Defect Classifications In: IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE ENGINEERING, 26th, 2011, Lawrence, Kansas, Proceedings of the Twenty Sixth International Conference on Automated Software Engineering. Lawrence: IEEE/ACM, 2011. p. 412-415 IBM RESEARCH. Details of ODC v 5.11 Yorktown Heights: IBM Research Center for Software Engineering, 2002. Disponível em: < http://www.research.ibm.com/softeng/ODC/DETODC.HTM>. Acesso em: 10 fev. 2012. JIANG, M.; ZHANG, J.; ZHAO, H.; ZHOU, Y. Maintaining Software Product Lines – an Industrial Practice. In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE, 24th, 2008, Beijing, China, Proceedings of the Twenty Fourth International Conference on Software Maintenance. Beijing: IEEE, 2008. p. 444-447 LI, Z.; LONG, J. A Case Study of Measuring Degeneration of Software Architectures From a Defect Perspective In: IEEE ASIA-PACIFIC SOFTWARE ENGINEERING CONFERENCE, 18th, 2011, Ho Chi Minh City, Vietnam, Proceedings of the Eighteenth Asia-Pacific Software Engineering Conference. Ho Chi Minh City: IEEE, 2011. p. 242-249
135 LUTZ, R. Enabling Verifiable Conformance for Product Lines. In: INTERNATIONAL SOFTWARE PRODUCT LINE CONFERENCE, 12th, 2008, San Francisco, California, Proceedings of the Twelfth International Software Product Line Conference. San Francisco: IEEE, 2008. p. 35-43 MCGREGOR, J.D.; MUTHIG, D.; YOSHIMURA, K.; JENSEN, P. SUCCESSFUL SOFTWARE PRODUCT LINE PRACTICES. IEEE SOFTWARE, LOS ALAMITOS, P.16-21, MAY/JUNE. 2010. NORTHROP, L. SEI's Software Product Line Tenets. IEEE Software, Los Alamitos, p.32-40, July/August. 2002. NORTHROP, L.; CLEMENTS, P. Framework for Software Product Line Practice, Version 5.0. Pittsburgh: Carnegie Mellon University, 2011. Disponível em: < http://www.sei.cmu.edu/productlines/frame_report/index.html >. Acesso em: 16 mai. 2013. RIVA, C.; DEL ROSSO, C. Experiences with Software Product Family Evolution. In: IEEE INTERNATIONAL WORKSHOP ON PRINCIPLES OF SOFTWAEE EVOLUTION, 6th, 2003, Helsinki, Finland, Proceedings of the Sixth International Workshop on Software Evolution. Helsinki: IEEE, 2003. p. 161-169 SARAIYA, N.; LOHNER, J.; BAIK, J. Monitoring and Improving the Quality of ODC Data using the “ODC Harmony Matrices“: A Case Study. In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING RESEARCH, 4th, 2006, Seattle, Washington, Proceedings of the Fourth International Conference on Software Engineering Research. Seattle: IEEE, 2006. p. 407-411 SCANNAPIECO, M.; MISSIER, P.; BATINI, C. DATA QUALITY AT A GLANCE. DATENBANK-SPEKTRUM, BONN, P.6-14, AUG. 2005. SOUZA, I.; OLIVEIRA, R.; GOMES, G.; ALMEIDA, E. On the Relationship between Inspection and Evolution in Software Product Lines: An Exploratory Study In: BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, 26th, 2012, Natal, Brazil, Proceedings of the Twenty Sixth Brazilian Symposium on Software Engineering. Natal: IEEE, 2012. p. 131-140 THAO, C. Managing Evolution on Software Product Line In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 34th, 2012, Zurich, Switzerland,
136 Proceedings of the Thirty Fourth International Conference on Software Engineering. Zurich: IEEE, 2012. p. 1619-1621 TIEJUN, P.; LEINA, Z.; CHENGBIN, F. Defect Tracing System Based on Orthogonal Defect Classification In: INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND SOFTWARE ENGINEERING, 1st, 2008, Wuhan, China, Proceedings of the First International Conference on Computer Science and Software Engineering. Wuhan: IEEE, 2008. p. 574-577
137 APÊNDICES APÊNDICE A – Hipóteses de problemas originais retiradas após avaliação dos especialistas.
- Hipótese 1: As manutenções realizadas nos produtos da linha são de difícil
análise, implementação e implantação.
A ser definida posteriormente.
- Hipótese 5: Correções de defeitos geram efeitos colaterais.
- Em todas as consultas, o critério severidade terá seu valor fixado em “1“
ou “2“, para se garantir a recuperação dos defeitos de maior impacto para
os clientes e o critério idade terá seu valor fixado em “recorrigido“, para se
garantir a recuperação de defeitos gerados como efeito colateral.
- Os critérios produto, versão, severidade e idade serão combinados para
se montar consultas que mostrem os defeitos, gerados como efeitos
colaterais, por produto e versão.
- Os critérios produto, versão, severidade, atividade e gatilho serão
combinados para se montar consultas que mostrem as falhas do processo
de verificação, através dos critérios atividade e gatilho, que deixaram
defeitos, gerados como efeitos colaterais, escaparem, por produto e
versão do mesmo.
- Os critérios produto, versão, severidade, alvo e tipo de defeito também
serão combinados para se montar consultas que mostrem as fases do
processo de desenvolvimento, através dos atributos alvo e tipo do defeito,
que deixaram os defeitos, gerados por efeitos colaterais, escaparem, por
produto e versão do mesmo.
- A tabela 10, abaixo, mostra os critérios que serão combinados, para se
gerar cada uma das consultas:
138 Tabela 87 - Consultas da hipótese 5
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
5.1 X X X
5.2 X X X X
5.3 X X X X X
5.4 X X X X X X
5.5 X X X X X
5.6 X X X X X X
- Hipótese 7: Desenvolvimento de novas funcionalidades atrapalham
funcionalidades que funcionavam.
- Em todas as consultas, o critério severidade terá seu valor fixado em “1“
ou “2“, para se garantir a recuperação dos defeitos de maior impacto para
os clientes e o critério idade terá seu valor fixado em “novo“, para se
garantir a recuperação de defeitos gerados por novas funcionalidades.
- Os critérios produto, versão, severidade e idade serão combinados para
se montar consultas que mostrem os defeitos relativos a novas
funcionalidades de determinados produtos que atrapalham funcionalidades
que funcionavam por produto, versão e severidade.
- Os critérios produto, versão, severidade, idade, atividade e gatilho serão
combinados para se montar consultas que mostrem as falhas do processo
de verificação, através dos critérios atividade e gatilho, que deixaram
defeitos, relativos a novas funcionalidades de determinados produtos que
atrapalham funcionalidades que funcionavam, escaparem, por produto,
versão e severidade do mesmo.
- Os critérios produto, versão, severidade, idade, alvo, tipo de defeito e fonte
também serão combinados para se montar consultas que mostrem as
fases do processo de desenvolvimento, através dos atributos alvo e tipo
do defeito, que deixaram os defeitos relativos a novas funcionalidades de
determinados produtos que atrapalham funcionalidades que funcionavam
escaparem, por produto, versão e severidade do mesmo.
139
- A tabela 12, abaixo, mostra os critérios que serão combinados, para se
gerar cada uma das consultas:
Tabela 88 - Consultas da hipótese 7
Consultas
Critérios
Produto
Versão
Severidade
Estado de teste
APAR
Atividad
e
Gatilho
Impacto Alvo
Tipo do
defeito
Qualificador
Fonte
Idade
7.1 X X X
7.2 X X X X
7.3 X X X X X
7.4 X X X X X X
7.5 X X X X X X
7.6 X X X X X X X
- Hipótese 12: Mudanças no software base, muitas vezes, quebram um ou mais
software específicos.
- A ser definido posteriormente.
- Hipótese 14: Alguns defeitos reportados por cliente, aqueles que possuem um
contorno, não são reportados para a equipe de desenvolvimento.
- A ser definido posteriormente.
- Hipótese 16: A falta de adoção de padrões de projetos dificulta a manutenção
e criação de novas funcionalidades.
- A ser definido posteriormente.
- Hipótese 18: As correções de defeitos são entregues, para os clientes, em
pacotes cumulativos, o que muitas vezes, quando instalados, quebram
personalizações feitas por esses clientes.
- A ser definido posteriormente.