Alexis da Rocha Silva - IPT - Instituto de Pesquisas...

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



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



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


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


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%


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


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



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.


uma das consultas:


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.



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



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.


uma das consultas:


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.


uma das consultas:


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.



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


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



do defeito, que deixaram os defeitos escaparem, por produto, versão e

severidade do mesmo.


uma das consultas:


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


do defeito, que deixaram os defeitos escaparem.


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.


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.


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.


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.


uma das consultas:


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.


uma das consultas:


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.


uma das consultas:


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.


uma das consultas:


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



deixaram os defeitos relacionados à tradução do software para vários

idiomas escaparem, por produto e versão.


uma das consultas:


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



Compatibilidade Anterior 6615 523 3500 2390 0 0 789 0

Concorrência 1026 545 3 700 0 765 520 6509


0 0 12 13 2230 344 450 0


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



Compatibilidade Anterior 19% 2% 94% 8% 0% 0% 4% 0%

Concorrência 3% 2% 0,5% 2% 0% 13% 3% 26%


0% 0% 0,5% 0,05% 80,7%

6% 2% 0%


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%




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


62





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


3


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


1


2


3


4

65


1


2


3


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


2


3


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


2


3


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.


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


Incorreto 1536

Produto F Capacidade Incorreto 1320

68

Produto Impacto Qualificador Quantidade de defeitos (Capability)

Produto P Capacidade (Capability)

Incorreto 1182


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


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


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


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


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


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


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.


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


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


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.


Produto Atividade Gatilho Impacto Quantidade de defeitos


2748

Produto Núcleo


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


Produto Versão Atividade Gatilho Impacto Quantidade de defeitos


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


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.


Produto Impacto Tipo do Defeito

Quantidade de defeitos

Produto Núcleo

Capacidade (Capability)

Algoritmo 2418

Produto Núcleo


Atribuição 2190


Algoritmo 1698


Atribuição 1656

Produto Núcleo


Checagem 1614


Atribuição 1464

Produto F Capacidade (Capability)

Atribuição 1362

Produto P Capacidade (Capability)

Algoritmo 1242


Algoritmo 954


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.


Produto Versão Impacto Tipo do Defeito


Produto Núcleo

7.5.1 Capacidade (Capability)

Algoritmo 1350

Produto F 7.1.1 Capacidade (Capability)

Atribuição 888


Atribuição 870

Produto O 7.1.2 Capacidade (Capability)

Algoritmo 864

76

Produto Versão Impacto Tipo do Defeito


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


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.


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


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.


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.


Produto Versão Quantidade de defeitos

Produto Núcleo

6.2.0.1 138

78


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


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.


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 Núcleo

CVT Interação 12

Produto Núcleo

UT Simples 12

Produto F UT Simples 12


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


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


80


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.


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



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.


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


Produto Núcleo


Produto Núcleo


Produto Núcleo



detalhados pelas versões do produto que mais geraram esses defeitos.


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


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


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.


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.



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


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



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


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.



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 F CVT Cobertura 1104

Produto P CVT Cobertura 942

Produto Núcleo

CVT Variação 912

Produto N CVT Cobertura 750




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



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


Produto Núcleo

7.5.1 CVT Interação 534

Produto N 7.5 CVT Cobertura 504

Produto Núcleo



detalhados pelas versões dos produtos que mais geraram esses defeitos.

85


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



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.


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





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


verificação que deixaram a maioria desses defeitos escaparem são relacionadas aos


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


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


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.



Produto Núcleo

CVT Cobertura 552

Produto Núcleo

CVT Cobertura 474


Produto Núcleo


Produto Núcleo

CVT Interação 192



Produto H CVT Cobertura 156

Produto O CVT Cobertura 120

Produto Núcleo

CVT Variação 114


falhas do processo de verificação que deixaram a maioria dos defeitos provenientes

do desenvolvimento de novas funcionalidades que não atendem aos requisitos


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


Produto Atividade Gatilho Alvo Tipo de Defeito


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


falhas do processo de verificação que deixaram a maioria dos defeitos provenientes

do desenvolvimento de novas funcionalidades que não atendem aos requisitos


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.



Produto Núcleo


Produto 7.1.1.6 CVT Cobertura 168

89


Núcleo

Produto Núcleo



Produto Núcleo


Produto Núcleo

7.5.0.1 CVT Interação 120

Produto Núcleo


Produto J 7.5 CVT Cobertura 102

Produto P 7.1.1 CVT Cobertura 96

Produto Núcleo



detalhados pelas versões dos produtos que mais geraram esses defeitos


Produto Versão Atividade Gatilho Alvo Tipo de Defeito


Produto Núcleo

7.1.1.0 CVT Cobertura Código Função 252

Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto H 6.5 CVT Cobertura Código Função 78

Produto Núcleo


Produto Núcleo

7.1.1.8 SVT Software Código Função 72

Produto Núcleo


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


Núcleo



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


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.


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.



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


258


severidade que foram encontrados em ambientes de produção dos clientes é

relacionada aos produtos: Produto Núcleo , Produto Q, Produto F e Produto E.



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 Núcleo

7.5 4296

Produto Núcleo

7.1.1.7 4236


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.



Produto Núcleo

CVT Cobertura 31176




Produto E SVT Cobertura 1074

Produto A CVT Cobertura 1032


Produto M CVT Cobertura 558

Produto J UT Complexo 342

Produto Núcleo

SVT Software 312




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



Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo

7.1 CVT Cobertura 4398

Produto Núcleo


Produto Núcleo

7.1.1.7 SVT Software 234





Produto Núcleo


Produto Núcleo


Produto Núcleo

Código Checagem 1506

Produto F Código Checagem 1326

94


Produto Núcleo


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



severidade encontrados em ambientes de produção dos clientes escaparem foram o

projeto de baixo nível e a construção do código.



Produto Núcleo


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


Produto Núcleo

6.2.3 Código Atribuição 3624

Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


95





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




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


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.


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.


Idade Quantidade de defeitos

96

Idade Quantidade de defeitos

Base 30012

Novo 11900

Recorrigido 2522

Reescrito 1312


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.



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.



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


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.



Produto Núcleo

CVT Cobertura 5886



Produto E CVT Cobertura 438


Produto A UT Complexo 372

98


Produto Núcleo

SVT Cobertura 366

Produto M UT Simples 318

Produto Núcleo

SVT Cobertura 312

Produto Núcleo

CVT Cobertura 210



escaparem são relacionadas aos testes de verificação do componentes (CVT),


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



Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


99


Produto Núcleo






Produto Núcleo


Produto Núcleo


Produto Núcleo



Produto O Código Algoritmo 360

Produto Q Código Atribuição 336


Produto Núcleo


Produto Núcleo

Código Função 252



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.



100


Produto Núcleo


Produto Núcleo

7.1.16 Código Algoritmo 1908

Produto Núcleo


Produto Núcleo


Produto Núcleo

7.1.1.0 Código Checagem 1368

Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo





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



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


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.


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.



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



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


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.



Produto Núcleo

CVT Cobertura 2340

Produto Núcleo

CVT Cobertura 2268

Produto H SVT Cobertura 906

Produto Núcleo


Produto SVT Cobertura 528

103


Núcleo

Produto Núcleo

CVT Variação 462



Produto Núcleo

CVT Interação 366

Produto J SVT Cobertura 366



escaparem são relacionadas aos testes de verificação do sistema (SVT),


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



Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto H 7.1.1 SVT Cobertura 636

Produto Núcleo


Produto H 6.5.1 SVT Cobertura 618

Produto Núcleo


Produto Núcleo


104


Produto Núcleo






Produto Núcleo


Produto Núcleo


Produto Núcleo




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


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




105


Produto Núcleo


Produto H 7.1.1 Código Algoritmo 720

Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto H 6.5.1 Código Algoritmo 492

Produto Núcleo


Produto Núcleo


Produto Núcleo


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.


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



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


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.


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.



Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto F Código Algoritmo 1584


Produto H Código Checagem 1092


Produto A Código Atribuição 912


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.



Produto Núcleo


Produto Núcleo


Produto Núcleo

6.2.2. Código Atribuição 6102

Produto Núcleo


Produto Núcleo

6.2.3 Código Algoritmo 4806

Produto Núcleo

6.2 Código Algoritmo 4764

Produto Núcleo


Produto Núcleo


Produto Núcleo


Produto Núcleo





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.



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


relativos à dificuldade de se manter o código legado é relacionada aos produtos:

Produto Núcleo, Produto H, Produto O e Produto E.



Produto Núcleo

7.1.1.5 5856

Produto Núcleo

7.1.1.0 5376

109


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


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.


Produto Tipo de Defeito


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


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.


Produto Versão Tipo de Defeito


Produto Núcleo

7.1.1.0 Algoritmo 2526

Produto Núcleo


Produto Núcleo


Produto Núcleo

7.1.1.4 Atribuição 1824

Produto Núcleo


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


Produto Núcleo


A consulta 10.4, resumida na Tabela 80, mostra os defeitos da Tabela 79



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.


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.




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


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





Produto Núcleo

7.5.0.1 Interface 96

Produto Núcleo


Produto J 7.1.1 Atribuição 78

Produto Núcleo


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




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


113


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.




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


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




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





Produto B CVT Cobertura 186


Produto B CVT Cobertura 72


Produto Núcleo

CVT Cobertura 66


Produto G CVT Cobertura 48




115


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


funções simples (Cobertura).



Produto B 7.5 CVT Cobertura 186

Produto B 7.5 CVT Cobertura 72




Produto Núcleo


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




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


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.


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.


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.


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.


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


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.


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.


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.



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.


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.



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.


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.



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.


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.


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.



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.


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.



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.



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.


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.



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.



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.


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



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:


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.



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.


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.




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



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:


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.


- Hipótese 16: A falta de adoção de padrões de projetos dificulta a manutenção

e criação de novas funcionalidades.


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


Alexis da Rocha Silva - IPT - Instituto de Pesquisas...

Documents

Transcript of Alexis da Rocha Silva - IPT - Instituto de Pesquisas...