Este documento apresenta o framework EARLY-FIX para predição de manutenção corretiva de software utilizando métricas de produto. O framework inclui modelos conceituais para indicadores de volume e predição de volume, métodos para medição de produto, histórico de manutenção e calibração de modelos preditivos, e técnicas para detecção de módulos propensos a defeitos. O framework foi implementado e testado em dois projetos da indústria para validar sua aplicabilidade.
EARLY-FIX: Um Framework para Predição de Manutenção Corretiva de Software utilizando Métricas de Produto
1. EARLY-FIX
Um Framework para Predição de Manutenção Corretiva
de Software utilizando Métricas de Produto
Gabriel de Souza Pereira Moreira
(mestrando)
Prof. Dr. Adilson Marques da Cunha
(orientador)
Instituto Tecnológico de Aeronáutica
Pós-Graduação em Engenharia Eletrônica e Computação
Área de Informática
14 de Dezembro de 2011
2. Agenda
1. Introdução
2. Qualidade, Manutenção e Medição de Software
3. Predição de Manutenção Corretiva
4. EARLY-FIX
5. Prova de Conceito
6. Conclusão
2
3. 1.1 Contextualização e Motivação
Manutenção de Software
>50% do esforço
(Kemerer et. Al, 1999)
3
4. 1.1 Contextualização e Motivação
Manutenção de Software
>50% dos profissionais
(Jones, 2007)
4
5. 1.1 Contextualização e Motivação
Manutenção de Software
entre 40 e 90%
dos custos
(Bennet, 2002)
5
6. 1.1 Contextualização e Motivação
Aumento do ciclo de vida do software
(Ware, 2007)
Menor foco em práticas e técnicas para
atividades de manutenção (Blanc, 2009)
6
7. 1.1 Contextualização e Motivação
Desafios para academia e
indústria de software
(Boehm, 2010)
7
8. 1.1 Contextualização e Motivação
Tipos de Manutenção
21%
Adaptativa Corretiva
Preventiva de Melhoria
(ISO 14764, 2006)
(Singh, 2007)
8
9. 1.1 Contextualização e Motivação
Características de
Esforço e Assertividade da
Qualidade do Produto de
Manutenção
Software
(Ware 2007), (Ahn 2003), (ISO 25000)
9
10. 1.2 Objetivo
Investigação, concepção, implementação e
verificação de um arcabouço (framework)
para a Predição de Manutenção Corretiva
baseada em Métricas de Produto de
Software, envolvendo modelos, métodos,
técnicas e ferramentas, a fim de fornecer
informações que possam embasar decisões
técnicas e gerenciais durante um projeto para a
redução de esforços, custos e riscos em
futuras manutenções corretivas.
10
11. 1.3 Requisitos da pesquisa
• Um levantamento bibliográfico
• Uma investigação sobre trabalhos relacionados
• A concepção e a elaboração de um framework
para predição de manutenção corretiva
• A implementação e verificação do framework
em dois projetos da indústria
• A comparação dos modelos preditivos obtidos
• Uma análise e discussão dos principais
resultados.
11
14. 2.3 Qualidade de Produto de Software
ISO/IEC 25000:2005 - Software Quality Requirements and Evaluation (SQuaRE)
Focos desta pesquisa
Modelo de Qualidade no Ciclo de Vida (ISO 25000, 2005)
14
15. 2.4 Métricas de Qualidade Interna de Software
Métricas de Produto OO
Tamanho Complexidade Acoplamento Coesão Herança
• LOC •CC - Complexidade • AC – Aferent • LCOM – Lack of • NOC - Number
Ciclomática
• N. Métodos Coupling Cohesion of Children
•Métricas de Methods
• N. Atributos Halstead • EC – Eferent • DIT - Depth of
•MCD - Max
Coupling • LCOM-HS - Lack Inheritance Tree
Conditional Depth • ABC – of Cohesion Of
•MLD - Max Loop Association Methods
Depth Between Classes Henderson-
•DD - Decision Sellers
Density
Principais métricas utilizadas nesta pesquisa 15
17. 2.5 Custos de Correção de Defeitos após Implantação
10x maiores do
que na fase de
construção
(McConnell, 2004)
10
maiores do
que na fase
0x
de análise e
design
(Boehm, 2001)
17
18. 3.1 Predição de Manutenção Corretiva
Benefícios
• Suporte ao planejamento e execução das
atividades de testes (Denaro, 2006)
• Priorização de módulos mais propensos a defeitos
para realização de inspeções e refatorações
(Ware, 2007)
• Identificação de fatores que influenciam na
ocorrência de defeitos (Boehm, 2010)
• Suporte aos modelos de estimativa de custos e
riscos de manutenção corretiva (Yu, 2006).
18
19. 3.1 Predição de Manutenção Corretiva
Trabalhos relacionados
Focos desta pesquisa
Defeitos
Volume de
Modificações Métricas de Produto
(código-fonte)
Defeitos
Propensão a Tendência de Histórico
de Defeitos
Modificações
Utilizando como Tendência de Histórico
Predição de Esforços preditores de Modificações
Manutenção em Custos Tamanho Funcional
(e.g. Pontos de Função)
Riscos
Fatores coletados em
Característica de questionários
Qualidade
Manutenibilidade
como
Esforço de
Modificações
19
20. 3.2 Predição de Defeitos
Algumas empresas que utilizam
(Nagappan, 2005)
20
21. 3.2 Predição de Defeitos
Técnicas de Predição de Defeitos mais utilizadas em
artigos entre 2005 e 2008 *
9
8
7
6
5
4
3
2
1
0
* Segundo revisão sistemática conduzida em (Pontes, 2009)
21
27. 4.4 Método de Rastreabilidade entre Produto de Software
. e Histórico de Manutenções (MR-PHM)
27
28. 4.6 Método de Medição de Produto de Software (MM-PS)
1 - Copiar localmente a última revisão do código-fonte do sistema, a
partir do repositório do SCV
2 - Realizar a compilação do código-fonte e gerar os respectivos
arquivos binários
3 - Utilizar técnicas de análise estática para extração de medidas de
módulos de software
4 - Armazenar as medidas dos módulos em um repositório de
dados, associadas à data da revisão.
28
29. 4.7 Método de Medição de Histórico de Manutenções
Corretivas (MM-HMC)
Para cada arquivo de código-fonte (módulo de software) do sistema
Para cada revisão (do SCV) onde o arquivo foi modificado
Se a revisão estiver associada a correção de um defeito registrado no sistema
Issue Tracker
1 - Incrementar e armazenar a medida Quantidade de Defeitos
encontrados no módulo de software, associada à data da detecção
2 - Calcular a quantidade de linhas inseridas, alteradas e removidas
em relação à revisão anterior do arquivo
3 - Armazenar a medida Quantidade de Modificações
Corretivas, associada à data da correção
29
30. 4.8 Método de Medições Consolidadas (MM-C)
Para cada arquivo de código-fonte (módulo de software) do sistema
1 - Identificar a data em que o módulo de software foi implantado no ambiente do
usuário
2 - Obter as medidas do módulo de software na última revisão antes de sua implantação
3 - Acumular a quantidade de defeitos detectados após a implantação do
módulo, agrupada por período de tempo
4 - Acumular a quantidade de modificações corretivas realizadas após a implantação do
módulo, agrupada por período de tempo
5 - Inserir na tabela consolidada um registro com as medidas do módulo de software
obtidas, a quantidade de defeitos e de modificações corretivas por período.
30
31. 4.9 Método de Calibração de Predição de Volume (MC-PV)
1 - Utilizar como variáveis independentes as medidas do módulo de software em sua revisão de entrega
2 - Definir a variável dependente para construção do modelo (Quantidade de Defeitos ou de
Modificações Corretivas) para um determinado período (3, 6 ou 12 meses)
3 - Definir uma técnica de regressão para gerar modelos preditivos das variáveis dependentes
4 - Definir o método de seleção de variáveis
5 - Calibrar modelos de predição utilizando a técnica de regressão e o método de seleção de variáveis
selecionado
6 - Selecionar o modelo cujas predições melhor se aproximem dos valores observados na variável
dependente, utilizando uma medida estatística
7 - Armazenar os coeficientes do modelo preditivo selecionado e associar ao indicador correspondente
8 - Aplicar a função do modelo preditivo selecionado para calcular o valor dos indicadores de volume de
manutenção corretiva
31
32. 4.10 Método de Detecção de Módulos Propensos à
manutenção corretiva (MD-MP)
1 - Definir o indicador de manutenção corretiva que será utilizado na Análise de
Pareto (Quantidade de Defeitos ou de Modificações Corretivas de um período)
2 - Ordenar, em ordem decrescente, os módulos pelos valores estimados para o
indicador de manutenção corretiva selecionado
3 - Definir o percentual do critério de corte da Análise de Pareto
4 - Selecionar os módulos com maiores valores, até que seja atingido o percentual
de módulos definido no critério de corte
5 - Priorizar os módulos selecionados para realização de atividades relacionadas à
qualidade
32
34. 5.2 Métricas Utilizadas
Métricas de Produto *
• Tamanho
• Complexidade
• Acoplamento
Variáveis
• Coesão Independentes
• Herança
Predição
* na revisão de entrega da classe
Métricas de Volume de Manutenção Corretiva **
• Quantidade de Defeitos Variáveis
• Quantidade de Modificações Corretivas Dependentes
** para os primeiros 3, 6 e 12 meses pós-implantação
34
43. 5.10 MD-MP - Estimativa de Modificações Corretivas
43
44. 5.11 Limitações da Prova de Conceito (1/2)
• Projetos investigados:
– Contexto semelhante
– Defeitos não associados às modificações que os corrigiram.
(Projetos A e B com 67% e 45% dos defeitos associados, respectivamente)
– Diferença entre datas de entrega de iteração e datas de implantação
• Métricas de Produto e de Manutenção Utilizadas:
– Críticas a Complexidade Ciclomática e da suíte de Halstead
– As métricas de produto utilizadas para calibração dos modelos referem-se à revisão
de entrega, não sendo atualizadas após manutenções futuras
44
45. 5.11 Limitações da Prova de Conceito (2/2)
• Análise Estatística:
– Utilização do método de seleção de variáveis Backward Elimination removeu
variáveis de baixa significância, porém reduziu a eficiência de predição
– As variáveis dependentes, especialmente de modificações corretivas, apresentaram
super-dispersão. Mesmo assim, as técnicas de Regressão de Poisson geraram os
modelos com melhor predição de variabilidade e desvio
– Não utilização de técnicas de segmentação de base, calibrando os modelos sobre
toda a base que se deseja prever
45
46. 7. Conclusão
• O framework EARLY-FIX concebido resultou da investigação e da
elaboração de modelos, métodos e técnicas.
• O EARLY-FIX propiciou:
• Coleta de medidas
• Predição de volume de manutenção corretiva
• Detecção de módulos propensos a defeitos
• Endereçamento de projetos iterativos de software
46
47. 7.1 Conclusões Específicas (1/5)
O framework EARLY-FIX foi implementado:
• Em 2 projetos iterativos, em fase de manutenção, da
indústria de software
• Utilizando uma integração entre os sistemas de issue tracker
Mantis e de controle de versão SVN
• A partir de duas ferramentas e scripts desenvolvidos para
automatização da implementação dos métodos de medição
47
48. 7.1 Conclusões Específicas (2/5)
A partir de uma análise estatística exploratória verificou-se:
• A correteza das medidas obtidas de produto
• Outliers nas medidas de volume de manutenção
• Semelhanças entre distribuições das variáveis dependentes e
de Poisson
48
49. 7.1 Conclusões Específicas (3/5)
O Método de Calibração de Predição de Volume (MC-PV) foi
implementado com 5 técnicas de regressão:
• Linear Multivariada (MLR)
• Poisson (PR)
• Poisson Inflada de Zeros (ZIP)
• Binominal Negativa (NB)
• Binomial Negativa Inflada de Zeros (ZINB)
49
50. 7.1 Conclusões Específicas (4/5)
Na verificação do MC-PV:
• Comparou-se os modelos preditivos obtidos com os coeficientes
R2 e R2 de McFadden
• Observou-se que as técnicas de PR e ZIP geraram os modelos
com maior predição da variabilidade (R2) e do desvio (R2 de
McFadden) das variáveis dependentes
• Verificou-se distribuições segundo a Lei de Pareto (80-20) nas
variáveis dependentes
50
51. 7.1 Conclusões Específicas (5/5)
Na implementação do Método de Detecção de Módulos Propensos
à manutenção corretiva (MD-MP):
• Utilizou-se a técnica de Análise de Pareto sobre os valores
estimados pelos modelos
• Com 5% (14 das 274 classes) como critério de corte, selecionou-
se as que representaram:
• 51% das modificações corretivas
• 57% das mais defeituosas dos projetos.
51
52. 7.2 Considerações Gerais
• Relacionamentos entre métricas de produto de software
(especialmente de tamanho, complexidade e
acoplamento), e de volume de manutenções corretivas
normalmente ocorrem (Riaz, 2009)
• Defeitos apresentam, em geral, uma distribuição segundo a
Lei de Pareto (Endres, 2010)
• Métricas de produto de software:
• Buscam mensurar características de código-fonte e de
design (ISO 25000, 2005)
• Apresentam potencial para predição de volume de
manutenção corretiva (Nair, 2010)
52
54. 7.3 Contribuições Adicionais
1. Implementação e verificação do EARLY-FIX em uma prova de
conceito em 2 projetos de software para a indústria
2. Comparação entre os modelos gerados pelas 5 técnicas de
regressão, utilizando os 2 coeficientes de performance:
• R2
• R2 de McFadden
54
55. 7. 4 Recomendações
• Implementação do EARLY-FIX em outros contextos
• Extensão do framework EARLY-FIX com novos Métodos de
Calibração e Modelos de Indicadores
• Criação de modelos de apoio a tomada de decisão, visando
reduzir o volume de manutenções corretivas futuras
• Criação de mecanismos que evitem commits de correções
não associados a defeitos, visando reduzir desvios nos
modelos preditivos
55
56. 7.5 Sugestões de Trabalhos Futuros
• Construção de modelos baseados em métricas de produto, para
estimativa de esforços, custos e riscos de manutenção corretiva
• Implementação do EARLY-FIX em projetos em execução e
análise dos benefícios obtidos com ações direcionadas a partir
das informações obtidas com o framework
• Extensão do EARLY-FIX, utilizando modelos de análise
temporal, para avaliar tendências a defeitos, em futuras
iterações
56
57. 7.6 Artigos publicados relacionados com esta pesquisa
1. CARVALHO, H. P. B. ; BATTAGLIA, Danilo ; MONTINI, Denis Ávila ; MOREIRA, Gabriel de Souza
Pereira ; DIAS, Luiz Alberto Vieira; TASINAFFO, P. M. . ETL Integration of Software Model for
Production Line Manufacture Cells MIS. In: ITNG '10. Seventh International Conference on
Information Technology: New Generations, 2010, 2010, Las Vegas, NE, USA. ITNG 2010
Proceedings, 2010
2. MOREIRA, Gabriel de Souza Pereira ; MELLADO, Roberto Pepato ; MONTINI, Denis Ávila ;
DIAS, Luiz Alberto Vieira; CUNHA, Adilson Marques da . Software Product Measurement and
Analysis in a Continuous Integration Environment. In: ITNG '10. Seventh International
Conference on Information Technology: New Generations, 2010, 2010, Las Vegas, NE, USA. ITNG
2010 Proceedings, 2010
3. MOREIRA, Gabriel de Souza Pereira ; MELLADO, Roberto Pepato ; CUNHA, Adilson Marques da ;
DIAS, Luiz Alberto Vieira. METACOM: Um Método para Análise de Correlação entre Métricas de
Produto de Software e Propensão a Manutenção. In: Simpósio Brasileiro de Qualidade de
Software - SBQS, 2011, Curitiba-PR. Proceedings of Simpósio Brasileiro de Qualidade de
Software 2011, 2011
4. MELLADO, R. P. ; MOREIRA, Gabriel de Souza Pereira ; Junior, R. L. M. ; CUNHA, Adilson Marques
da ; DIAS, Luiz Alberto Vieira. An Empirical Analysis of eXtreme Programming Practices and its
Impact on Software Quality Metrics. In: Workshop Brasileiro de Métodos Ágeis -
WBMA, 2011, Fortaleza - CE. Proceedings of Workshop Brasileiro de Métodos Ágeis 2011, 2011
57
Notas del editor
Empresas buscam aumentar o ciclo de vida de um software, devidos aos investimentos realizados (BLANC-DIT-GRENADIER et al., 2009)Contudo, mMenos atenc~ao, entretanto, tem recebido as atividades de desenvolvimento apos a implantacao (release) de um produto como correcao de defeitos, inclus~ao de novas funcionalidades, adaptacao a diferentes ambientes de execucao e otimizacao de desempenho(WARE; WILKIE; SHAPCOTT, 2007).
Em (NGUYEN; BOEHM; DANPHITSANUPHAN, 2010), Boehm arma que avaliar os fatoresde manutencao e desenvolver tecnicas que permitam a estimativa de atividades demanutencao ainda representam importantes desaos para a comunidade de software.
A norma ISO/IEC 14764:2006 (ISO, 2006) classica quatro categorias de manuten-c~ao: Corretiva, Adaptativa, de Melhoria e Preventiva. Dene-se manutencao corretiva desoftware como uma modicac~ao reativa para corrigir problemas descobertos\\cite{Pressman2009} afirma que a manutenção preventiva ou refatoração facilita a realização dos outros três tipos de manutenção. Segundo (SINGH; GOEL, 2007), a manutenc~ao corretiva representa cerca de 21% doesforco total de manutenc~ao de um sistema de software. Os resultados de experimentosrealizados em (NGUYEN; BOEHM; DANPHITSANUPHAN, 2010) indicam que manutenc~aocorretiva apresenta menor produtividade em relac~ao a manutenc~ao de melhoria e de remoc~ao de funcionalidades.
À medida que o ciclo de vida de um software se torna maior, a qualidade de código apresenta-se como um importante fator para a redução de custos de desenvolvimento e de manutenção. Apesar de difundidos os conhecimentos sobre os princípios de qualidade de software, ainda são raros os engenheiros que se utilizam de métodos, técnicas e ferramentas de qualidade de código na prática [Blanc 2009].[Jones 2008] afirma que os maiores responsáveis pelo aumento do custo de manutenção relacionam-se ao tamanho, à complexidade e à idade do software.Estudos Empíricos - Características de Qualidade de Produto => Esforço e Assertividade da Manutenção ([Ware 2007], [Ahn 2003]
Os processos tradicionais de desenvolvimento de software, também chamados de Orientadas à Documentação ou Orientadas ao Plano, surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado em \\textit{mainframes} e terminais de apresentação \\cite{Royce1970}, onde o custo de modificação de um software era muito alto. O Modelo Clássico de desenvolvimento, também conhecido como Sequencial, Cascata ou Preditivo, estabelece uma sequência de etapas com entregáveis (em geral documentação), de cuja aprovação depende o início da fase posterior \\cite{Koscianski2007}. De uma forma geral, fazem parte do Modelo Clássico as etapas de Definição de Requisitos, Análise e Projeto do Software, Implementação e Testes Unitários, de Integração e de Sistema, Implantação e Manutenção. No modelo Cascata original não se prevêem mudanças nas especificações. Já o Modelo Espiral \\cite{Boehm1988} admite um retorno às fases anteriores, mas não suporta a idéia de execução paralela de fases.O Modelo Clássico dominou o desenvolvimento de software até o início da década de 1990, apesar de receber duras críticas de pesquisadores como \\cite{Brooks1987} e \\cite{Gilb1988}.
Processos de desenvolvimento iterativos organizam suas fases em ciclos com entregáveis menores, visando mitigar riscos. Os ciclos podem incluir atividades de elaboração e construção de um software, como ocorre no \\textit{Rational Unified Process (RUP)} \\cite{Kruchten2000}, ou um ciclo completo de atividades, como ocorre em processos ágeis.Na Figura~\\ref{fig:ModeloProjetosIterativos}, apresenta-se um modelo geral de processos iterativos, onde ilustram-se as atividades executadas no ciclo de uma iteração em projetos ágeis: Planejamento, Análise de Requisitos, Análise e \\textit{Design}, Implementação, Testes, Validação e Implantação de funcionalidades.Em projetos iterativos, idealmente devem ocorrem implantações frequentes em um ambiente em que o usuário possa validar periodicamente as funcionalidades. Neste contexto, pode-se realizar manutenções corretivas dos defeitos encontrados pelo usuário, em paralelo com o desenvolvimento de novas funcionalidades.
ISO/IEC 25000:2005 - Software Quality Requirements and Evaluation (SQuaRE)Evoluiu a partir das séries de normas ISO/IEC 9126 e 145983 modelos de qualidade (Interna, Externa e Em Uso) com métricas específicosQualidade Interna => Qualidade Externa => Qualidade em UsoQualidade Interna - Capacidade de um conjunto de atributos estáticos de um produto de software satisfazer necessidades explícitas e implícitas, quando utilizado sob condições específicasAtributos Estáticos: Relacionados à arquitetura e estrutura, verificáveis por meio de inspeção ou ferramentas automatizadasQualidade Interna – Aspectos de arquitetura do código, como complexidade, acoplamento, entre outros;Qualidade Externa – Observada na execução do software; eQualidade no Uso – Observada na utilização do software pelo usuário final, em atividades rotineiras de seu ambiente de trabalho.
O IEEE Standard for Software Reviews and Audits - 1028-2008 \\cite{IEEE1028-2008} define cinco tipos de revisões e auditorias formais. Dentre elas destacam-se as Revisões Técnicas, as Inspeções e os \\textit{Walkthroughs}. Estas revisões têm como principal objetivo a inspeção de um produto de software para avaliar sua adequabilidade ao fim proposto, identificar anomalias e favorecer a disseminação de conhecimento sobre o produto e as melhores práticas para seu desenvolvimento.
De acordo com \\cite{McConnell2004}, no desenvolvimento com metodologias tradicionais, a correção de um defeito detectado na etapa de testes pode custar dez vezes mais caro que na fase de construção.Segundo Boehm e Basili \\cite{Boehm2001}, localizar e corrigir defeitos de software depois da sua entrega, com frequência, pode custar até cem vezes mais do que na etapas iniciais do projeto.
Grandes empresas como a Microsoft \\cite{Nagappan2005}, a Ericcson \\cite{Tomaszewski2006} e a IBM \\cite{Moser2008} têm aplicado técnicas de predição de defeitos. Contudo, a adesão a estas técnicas tem sido menos representativa em empresas de menor porte, em parte devido aos conhecimentos especializados necessários e aos custos de implementação.Oman posteriormente estendeu o \\textit{MI} e descreveu como ele foi calibrado para um grande conjunto de código de projetos reais da indústria \\cite{Oman1994}. Os coeficientes apresentados na equação são resultado de calibração usando dados de numerosos sistemas mantidos pela \\textit{Hewlett-Packard}, tendo os detalhes de calibração detalhados em \\cite{Oman1994} e \\cite{Welker1997}. Oman comparou comparou os parâmetros de métricas com dados subjetivos resultantes de pesquisa com um questionário de avaliação de manutenibilidade \\textit{AFOTEC} \\cite{SEI1997}.
Grandes empresas como a Microsoft \\cite{Nagappan2005}, a Ericcson \\cite{Tomaszewski2006} e a IBM \\cite{Moser2008} têm aplicado técnicas de predição de defeitos. Contudo, a adesão a estas técnicas tem sido menos representativa em empresas de menor porte, em parte devido aos conhecimentos especializados necessários e aos custos de implementação.Oman posteriormente estendeu o \\textit{MI} e descreveu como ele foi calibrado para um grande conjunto de código de projetos reais da indústria \\cite{Oman1994}. Os coeficientes apresentados na equação são resultado de calibração usando dados de numerosos sistemas mantidos pela \\textit{Hewlett-Packard}, tendo os detalhes de calibração detalhados em \\cite{Oman1994} e \\cite{Welker1997}. Oman comparou comparou os parâmetros de métricas com dados subjetivos resultantes de pesquisa com um questionário de avaliação de manutenibilidade \\textit{AFOTEC} \\cite{SEI1997}.
Segundo uma revisão sistemática conduzida por \\cite{Pontes2009}, considerando artigos entre 2005 e 2008, as técnicas estatísticas para predição de defeitos com maior ocorrência são: a Regressão Binomial Negativa, a Regressão Logística e a Regressão Linear. Neste contexto, destacam-se ainda algumas técnicas de aprendizado de máquina como Classificadores Bayesianos e Árvores de Decisão.
Neste capítulo, apresenta-se a principal contribuição deste trabalho: um \\textit{Framework} denominado EARLY-FIX para Predição de Manutenção Corretiva de Software utilizando Métricas de Produto. Um arcabouço (\\textit{framework}) pode ser definido como um conjunto de componentes e estruturas independentes que se relacionam, de uma maneira pré-definida, com o objetivo de realizar uma tarefa. Ele pode ser utilizado em situações similares ao contexto em que foi concebido \\cite{Pree2001}.A constatação de que a correção de defeitos apresenta custos mais elevados após a implantação \\cite{Boehm2001} inspirou a concepção do nome deste \\textit{framework}: \\textit{early fix} (``correção antecipada''). ma maneira de se direcionar o esforço de testes e aumentar as chances de encontrar defeitos em fases iniciais de um projeto consiste na antecipação da localização dos mesmos, permitindo-se que ações corretivas sejam tomadas \\cite{Bezerra2008}. O \\textit{framework} EARLY-FIX busca facilitar a estimativa do volume de manutenção corretiva e a detecção prévia de módulos de software propensos a defeitos. Estas informações podem embasar decisões gerenciais e técnicas, que favoreçam a redução dos esforços e dos custos de manutenções corretivas futuras. O EARLY-FIX foi concebido com base no Modelo de Informação de Medição da norma ISO/IEC 15939 \\cite{ISO15939}, apresentado no Apêndice~\\ref{apen:ProcessosMedicao}. Um modelo de informação fornece uma base para a tomada de decisão. Ele consiste de uma estrutura que relaciona necessidades de informação a indicadores, obtidos a partir da medição de atributos de entidades de interesse \\cite{ISO15939}. A parte superior da figura apresenta as entidades (Produto de Software e Histórico de Manutenções de Software), cujo relacionamento é estabelecido por um Método de Rastreabilidade. Estas entidades caracterizam-se por meio de atributos. Os atributos têm suas medidas básicas obtidas por Métodos de Medição. Finalmente, os Indicadores têm seus valores estimados a partir dos modelos gerados pelos Métodos de Calibração.
\\textit{Goal-Question-Metric (GQM)} consiste em um paradigma para associar importantes tópicos de software a outras questões de negócio \\cite{Basili1984}. Ele foi estendido posteriormente pelo próprio autor, Victor Basili, com a inclusão da etapa Indicador (\\textit{Indicator - I}), se tornando \\textit{Goal-Question-Indicator-Measure (GQ(I)M)}. Este paradigma facilita a identificação das medidas de software requeridas, bem como a razão para a coleta do dado. O direcionamento da interpretação dos dados por objetivos táticos e estratégicos possibilita o reuso de planos e procedimentos de medição em futuros projetos e atividades \\cite{Basili2006}. No paradigma \\textit{GQ(I)M}, ``Objetivo'' (\\textit{Goal}) representa um objetivo de medição, que visa monitoramento ou aprendizado sobre uma ou mais entidades relacionadas aos objetivos de negócio de uma corporação. ``Questão'' (\\textit{Question}) representa uma pergunta de resposta quantificável, visando alcançar o objetivo. ``Indicador'' (\\textit{Indicator}) é uma função ou medida derivada, que suporta a resposta de uma questão. A``Medida'' (\\textit{Measure}) representa um conjunto de medidas básicas, utilizadas para geração de um Indicador.Nesta pesquisa, aplicou-se a abordagem \\textit{top-down} utilizada pelo \\textit{GQ(I)M} no planejamento e implementação da medição de produto de software proposta no EARLY-FIX. Na Figura~\\ref{fig:FigHeuristicaQuestoesModIndic}, apresenta-se o Modelo Conceitual de Indicadores de Volume concebido nesta pesquisa, baseado em \\textit{GQ(I)M}. Neste modelo, o objetivo (\\textit{Goal} G1) consiste em reduzir o volume de manutenções corretivas, tendo em vista o elevado custo de correções de defeitos pós-implantação \\cite{Boehm2001}. Para atingir a este objetivo, apresentam-se questões quantificáveis (Q1 a Q5), relacionadas à predição de defeitos e modificações corretivas localizada por módulos de software (por classe, componente ou sistema) em determinado período de tempo após a implantação de uma funcionalidade (primeiros 3, 6 e 12 meses). As respostas destas questões embasam o Modelo de Indicadores de Predição de Volume (MI-PV) de manutenção corretiva, apresentado na seção~\\ref{sec:ModeloIndicadoresVolume}. As métricas que compõem cada um dos indicadores podem variar de acordo com o paradigma, linguagem, plataforma e tecnologias utilizadas. Na prova de conceito relatada no Capítulo~\\ref{cap:Survey}, apresenta-se um conjunto de métricas utilizadas para composição dos indicadores propostos.
No EARLY-FIX, propõe-se a utilização do Modelo de Indicadores de Predição de Volume (MI-PV) de manutenção corretiva em módulos de software.Um módulo de software encapsula as funções relacionadas de um programa. Neste trabalho, módulo de software representa o código-fonte em três níveis de granularidade: arquivo de código-fonte; componente; e sistema. No paradigma de Orientação a Objetos, por exemplo, um arquivo de código-fonte representa uma classe. Para este estudo, define-se componente como um conjunto lógico de classes relacionadas, podendo formar uma unidade binária de software. O sistema representa todo o código-fonte que compõe um produto de software.Neste trabalho, os indicadores de volume representam a quantidade de defeitos e de modificações corretivas. Modificações se referem ao número de linhas de código adicionadas, modificadas ou removidas em um módulo de software. Modificações corretivas são as modificações de código-fonte realizadas em atividades de manutenção corretiva.O volume de modificações relaciona-se com a dificuldade e a intensidade de manutenção \\cite{Ware2007} e pode ser utilizado como uma medida indireta de esforço de manutenção (\\cite{Jorgensen1995} e \\cite{Yu2006}).No modelo de indicadores, utiliza-se o termo densidade para representar a razão entre defeitos (\\textit{defect density}) ou modificações (\\textit{change density}) corretivas e a quantidade de linhas de código de uma classe \\cite{SWEBOK2004}. O modelo de indicadores de predição do EARLY-FIX é calibrado, a partir de medidas de produto e do histórico de manutenções observado no mesmo. O histórico de manutenções compõe-se de registros de defeitos detectados e de modificações corretivas realizadas nos módulos de software. Na Figura~\\ref{fig:FigCuboIndicVolumeManut}, apresenta-se o Modelo de Indicadores de Predição de Volume de manutenção corretiva (MI-PV) concebido. Este modelo permite analisar os indicadores sob as dimensões Nível de Granularidade (classe, componente e sistema) e Período (primeiros 3, 6 e 12 meses). Estes indicadores endereçam respostas quantitativas às questões do modelo conceitual baseado em \\textit{GQ(I)M}, apresentado na Figura~\\ref{fig:FigHeuristicaQuestoesModIndic}. O MI-PV é composto por três grupos de indicadores de predição: os indicadores básicos, apresentados em azul; os derivados, apresentados em verde; e os agregados (apresentados em cinza). A seguir, descreve-se a estrutura dos indicadores.Indicadores Básicos - Estimados a partir dos modelos de predição baseados em métricas de produto:Quantidade de Defeitos - Quantidade de defeitos detectados em um módulo de software, durante um período de tempo após sua implantação; eQuantidade de Modificações Corretivas - Quantidade de modificações realizadas para correção de defeitos em um módulo de software, durante um período de tempo após sua implantação.Indicadores Derivados - Calculados a partir de operações aritméticas utilizando os indicadores básicos:Densidade de Defeitos - Razão entre a Quantidade de Defeitos e o Número de Linhas do Módulo de Software (\\textit{LOC});Densidade de Modificações - Razão entre a Quantidade de Modificações Corretivas e o Número de Linhas do Módulo de Software (\\textit{LOC}); eModificações por Defeito - Razão entre a Quantidade de Modificações Corretivas e a Quantidade de Defeitos (média de modificações por defeito).Indicadores Agregados - Calculados a partir da soma dos indicadores básicos, em dois níveis de granularidade:Por Componente - Soma dos indicadores básicos das classes, ao nível de componente; ePor Sistema - Soma dos indicadores básicos das classes, ao nível de sistema.
Uma grande parcela dos trabalhos relacionados à predição de defeitos de software envolve a realização de experimentos em projetos de código-aberto (\\textit{open-source}), como \\cite{Zhou2008} e \\cite{Olague2008}, e em projetos tradicionais (não iterativos), como \\cite{VanKoten2006} e \\cite{Zhou2007}. A indústria tem adotado, de forma crescente, o desenvolvimento de projetos de software de forma iterativa.Em projetos tradicionais, a etapa de manutenção tem em geral um início definido, a partir do qual podem ocorrer testes mais detalhados pelos usuários. Este cenário facilita a identificação do histórico de defeitos detectados e de correções realizadas após a implantação. Em projetos de software desenvolvidos iterativamente, ocorre idealmente a implantação das funcionalidades desenvolvidas a cada iteração, de forma que os usuários possam testá-las, verificá-las e validá-las. Em alguns casos, enquanto o time de desenvolvimento trabalha com a implementação de novas funcionalidades, pode ocorrer em paralelo a correção de defeitos detectados pelos usuários. Em um cenário de projetos iterativos de software, alguns desafios para predição de defeitos podem ser encontrados. Entre eles, destacam-se:Como identificar as modificações corretivas em entregas iterativas?A correção de defeitos em paralelo com desenvolvimento de novas funcionalidades e outros tipos de manutenção (adaptativa, preventiva e de melhoria) torna um desafio a identificação das modificações relativas especificamente à manutenção corretiva em projetos iterativos; eComo identificar os módulos mais defeituosos em entregas iterativas?Em projetos iterativos, para contabilizar os defeitos detectados após a implantação de um módulo de software, torna-se necessário determinar o momento em que a respectiva funcionalidade foi implantada, passando a estar disponível para utilização pelo usuário final. Neste cenário, não se pode simplesmente comparar a quantidade de defeitos detectados em funcionalidades entregues na primeira e entregues na última iteração, pois representam diferentes período de utilização pelos usuários. Naturalmente, espera-se que tenham sido detectados mais defeitos em módulos implantados a mais tempo. Contudo, isto não significa que estes módulos sejam mais propensos à defeitos.
O EARLY-FIX endereça os desafios para predição de manutenção corretiva em projetos iterativos, mencionados na seção~\\ref{sec:DesafiosProjetosIterativos}, através do Método de Rastreabilidade entre Produto de software e Histórico de Manutenções (MR-PHM). Neste contexto, pode-se classificar como uma funcionalidade, por exemplo: um Caso de Uso (\\textit{Use Case - UC}), como no processo \\textit{Rational Unified Process (RUP)}; uma Estória de Usuário (\\textit{User Story}), como nos processos ágeis \\textit{Scrum} \\cite{Schwaber2002} e \\textit{eXtreme Programming} \\cite{Beck1999}; ou Funcionalidade \\textit{Feature} como no processo \\textit{Feature-Driven Development (FDD)} \\cite{Palmer2002}.O Modelo de Rastreabilidade, apresentado na Figura~\\ref{fig:RastreabilidadeClasseFuncDef}, ilustra o relacionamento entre Funcionalidades, Classes e Defeitos considerado no MR-PHM. O relacionamento entre Funcionalidades e Classes possibilita a identificação das classes que implementam uma funcionalidade. O relacionamento entre Funcionalidade e Defeitos permite determinar a localização funcional de defeitos. Por fim, o relacionamento entre Defeitos e Classes torna possível a identificação da localização dos módulos defeituosos e das respectivas modificações corretivas.
Para a realização dessa rastreabilidade, de forma prática, o MR-PHM descreve um processo de integração entre as ferramentas de Controle de Versão (seção~\\ref{sec:ControleVersao}), com foco no armazenamento das modificações de código-fonte e de \\textit{Issue Tracker} (seção~\\ref{sec:RastreamentoDefeitos}), voltadas ao registro e funcionalidades e defeitos identificados. Estratégias semelhantes de integração têm sido utilizadas em trabalhos recentes de extração de medidas para embasamento de modelos de predição, como em \\cite{Couto2011} e \\cite{DAmbros2010}.Sistemas de Controle de Versão armazenam revisões do código-fonte e registram informações sobre as modificações realizadas. Sistemas de \\textit{Issue Tracker} possuem recursos para relacionar funcionalidades e defeitos, além de registrarem modificações de \\textit{status} (estado) das funcionalidades e defeitos. Desta forma, torna-se possível identificar a data da detecção de um defeito ou a data de implantação de uma funcionalidade.A Figura~\\ref{fig:MetodoRastreabilidade} apresenta o Método de Rastreabilidade entre Produto de software e Histórico de Manutenções (MR-PHM), onde especificam-se as atividades (na cor azul) relacionadas à rastreabilidade que devem ocorrer durante o desenvolvimento e manutenção de um produto de software. Estas atividades são comuns em projetos iterativos, portanto a implantação do MR-PHM não requer alteração significativa do processo de desenvolvimento em uso. Apresentam-se a seguir as atividades envolvidas para permitir a rastreabilidade proposta:1. Registro de funcionalidade / defeito - As funcionalidades a serem desenvolvidas e os defeitos detectados devem ser registrados em um sistema de \\textit{Issue Tracker}; 2. Commit de código-fonte associado ao desenvolvimento de funcionalidade / correção de defeito - Na operação de \\textit{commit}, as modificações de código-fonte das classes são enviadas ao Servidor de Controle de Versão. Na realização de um \\textit{commit}, deve-se identificar no texto do comentário o código da \\textit{issue} (funcionalidade ou defeito) que foi endereçada nas modificações. Devido à natureza desta ação ser manual, facultativa e sujeita a inconsistências, sugere-se a utilização de mecanismos que tornem obrigatória a associação das modificações a um item de trabalho válido, no momento do \\textit{commit}; e3. Implantação da funcionalidade / correção - Neste momento, deve-se atualizar o \\textit{status} da funcionalidade para indicar que a mesma foi entregue em uma iteração e implantada para utilização pelo usuário. Devido a associação prévia entre funcionalidades e classes, torna-se possível a identificação da data em que o módulo de software passou a estar disponível para testes do usuário final.
Este método define a extração de medidas de produto de software utilizando técnicas de Análise Estática de Código (AEC) e dos binários gerados. Na seção~\\ref{sec:AnaliseEstaticaCodigo}, apresenta-se uma breve descrição de técnicas de AEC.Em linguagens orientadas a objetos, podem-se considerar métricas relacionadas a atributos como tamanho, complexidade, acoplamento, coesão e herança. As métricas podem variar de acordo com a linguagem e plataforma de desenvolvimento, e devem ser selecionadas de acordo com seu relacionamento entre o atributo que buscam medir e os objetivos de medição \\cite{ISO15939}, conforme apresentado na Figura~\\ref{fig:FigHeuristicaQuestoesModIndic}, referente ao Modelo Conceitual dos Indicadores de Volume (MC-IV) do EARLY-FIX. O código-fonte do produto pode ser obtido através de um Sistema de Controle de Versão (SCV). Um SCV armazena as revisões do código-fonte (\\textit{snapshots}), geradas por sequências de modificações de código-fonte (\\textit{change sets}) e armazenadas em uma operação de \\textit{commit} \\cite{Thummalapenta2010}. Copiar localmente a última revisão do código-fonte do sistema, a partir do repositório do SCVRealizar a compilação do código-fonte e gerar os respectivos arquivos binários (apenas para linguagens compiladas)Utilizar técnicas de análise estática para extração de medidas de módulos de software, a partir do código-fonte e dos arquivos binários geradosArmazenar as medidas dos módulos, associadas à data da revisão, em um repositório de dados.Recomenda-se atrelar a execução da implementação deste método ao processo de Integração Contínua (IC), apresentado na seção~\\ref{sec:IntegracaoContinua}, para garantir a coleta automática das medidas em operações de \\textit{commit} (envio de modificações de código ao SCV) ou a cada intervalo de tempo. O processo de Integração Contínua já inclui necessariamente os passos 1 e 2 deste método.
O Método de Medição de Histórico de Manutenção Corretiva (MM-HMC) destina-se a medição do volume de defeitos detectados e das modificações corretivas realizadas em um módulo de software. Para tal, este método utiliza-se da rastreabilidade entre classes e defeitos definida no MR-PHM (seção~\\ref{sec:MetodoRastreabilidade}), cuja implementação utiliza uma integração entre os sistemas de Controle de Versão (SCV) e de \\textit{Issue Tracker}. Os passos do MM-HMC são:
O Método de Medições Consolidadas (MM-C) visa a geração de uma tabela, utilizada para calibração dos modelos de predição. A consolidação utiliza técnicas de Extração, Transformação e Carga (\\textit{Extract, Transform and Load - ETL}) (seção~\\ref{sec:ETL}) a partir das medidas coletadas pelo Método de Medição para Produto de Software (MM-PS) e pelo Método de Medição de Histórico de Manutenção Corretiva (MM-HMC). Consiste nos seguintes passos:Para cada arquivo de código-fonte (módulo de software) do sistema Identificar a data em que o módulo de software foi implantado no ambiente do usuário (obtida através das informações propiciadas pelo MM-HMC (seção~\\ref{sec:MetodoRastreabilidade})); Obter as medidas do módulo de software na última revisão antes de sua implantação; Acumular a quantidade de defeitos detectados após a implantação do módulo, agrupada por período de tempo; Acumular a quantidade de modificações corretivas realizadas após a implantação do módulo, agrupada por período de tempo; e Inserir na tabela consolidada um registro com as medidas de produto obtidas, a quantidade de defeitos e de modificações corretivas por período. Neste contexto, o período representa um tempo de observação em que são contabilizados os defeitos e as modificações corretivas. Este período se inicia na implantação da funcionalidade e respectivos módulos de software. A duração deve coincidir com o período determinado no Modelo de Indicadores de Predição de Volume (MI-PV) de manutenção corretiva(seção~\\ref{sec:ModeloIndicadoresVolume}). Para exemplificar, consideraram-se no MI-PV os períodos dos primeiros 3, 6 e 12 meses, após a implantação da funcionalidade.Técnicas de SuporteA fim de suportar a implementação dos Métodos de Medição de forma automatizada, consideraram-se algumas técnicas de engenharia de software: Análise Estática de Código, Integração Contínua, Controle de Versão, Rastreamento de Defeitos e \\textit{ETL}. No Anexo~\\ref{anexo:TecnicasSuporteFramework}, apresenta-se uma breve descrição destas técnicas.
Define-se calibração como o conjunto de operações que estabelece, sob condições específicas, a relação entre os valores indicados por um instrumento de medição e os valores correspondentes das grandezas estabelecidas por padrões \\cite{ISOVocMetr1993}.Os métodos de calibração visam a construção de modelos preditivos a partir de variáveis dependentes, que se desejam prever, e independentes, utilizadas como parâmetros de predição. Neste trabalho, as variáveis independentes são métricas de produto de software e as dependentes relacionam-se ao volume de manutenção corretiva. Os métodos de calibração utilizam a tabela gerada pelo Método de Medições Consolidadas (MM-C) de produto de software e de manutenção corretiva. A partir desta tabela, como apresentado no Capítulo~\\ref{cap:TrabRelacionados}, podem-se utilizar diversas técnicas de predição baseadas em estatística e aprendizado de máquina, entre entre elas:Utilizar como variáveis independentes as medidas do módulo de software, no momento de sua implantaçãoDefinir a variável dependente para construção do modelo (Quantidade de Defeitos ou de Modificações Corretivas) para um determinado período (3, 6 ou 12 meses); Definir uma técnica de regressão para gerar modelos preditivos das variáveis dependentes;Definir método de seleção de variáveis (seção \\ref{sec:RegressaoLinear});Calibrar modelos de predição utilizando a técnica de regressão e o método de seleção de variáveis selecionado;Selecionar o modelo cujas predições melhor se aproximem dos valores observados na variável dependente, utilizando uma medida estatística (e.g. coeficiente de determinação ($R^2$), logaritmo da máxima verossimilhança (\\textit{log-likehood});Armazenar os coeficientes do modelo preditivo selecionado e associar ao indicador correspondente; eAplicar a função do modelo preditivo selecionado para o calcular o valor dos indicadores de volume de manutenção corretiva.Técnicas de SuporteO Método de Calibração de Predição de Volume (MC-PV) pode ser implementado utilizando diferentes técnicas estatísticas de regressão como: Regressão Linear Multivariada; Regressão de Poisson; Regressão Binomial Negativa; ou variações das mesmas. Apresenta-se uma descrição mais detalhada destas técnicas na seção~\\ref{sec:TecnicasRegressao} do Anexo~\\ref{anexo:TecnicasSuporteFramework}.
Módulos propensos à modificação (\\textit{change-prone}) são os que apresentam em sua estimativa um representativo volume de modificação em termos de revisões e linhas de código adicionadas ou removidas \\cite{Ware2007}. Além da utilização dos indicadores como medida indireta do esforço de manutenção \\cite{Yu2006}, eles apresentam também potencial aplicação na identificação de módulos com propensão à grande volume de defeitos ou modificações corretivas. Desta forma, os valores estimados podem ser utilizados para priorizar nestes módulos a realização de atividades de qualidade, como testes, inspeção e refatoração, direcionando os esforços de forma mais eficaz.Como apresentado na seção~\\ref{sec:AnalisePareto}, estudos como \\cite{Ware2007}, \\cite{Fenton2000} e \\cite{Couto2011} demonstram que a distribuição de defeitos e modificações corretivas através dos módulos de software geralmente seguem o princípio de Pareto (80-20). Ou seja, a maior parte dos potenciais problemas se encontra na minoria dos módulos.O Método de Detecção de Módulos Propensos à manutenção corretiva (MD-MP) utiliza a técnica de Análise de Pareto para seleção de módulos mais propensos a apresentarem defeitos. O MD-MP apresenta uma proposta diferente do trabalho \\cite{Ware2007}, apresentado na seção~\\ref{sec:AnalisePareto}. No trabalho citado, realiza-se a seleção da Análise de Pareto diretamente sobre métricas de produto, como Linhas de Código (LOC) ou Complexidade Ciclomática. No MD-MP, realiza-se a seleção sobre os valores estimados pelos modelos de predição dos indicadores, que consideram as medidas de produto calibradas.Definir o indicador de manutenção corretiva que será utilizado na Análise de Pareto (Quantidade de Defeitos ou de Modificações Corretivas, em um determinado período)Ordenar, em ordem decrescente, os módulos pelos valores estimados para o indicador de manutenção corretiva selecionado;Definir o percentual do critério de corte da Análise de Pareto; Selecionar os módulos com maiores valores, até que seja atingido o percentual de módulos definido no critério de corte; ePriorizar os módulos selecionados para realização de atividades relacionadas à qualidade.
Neste \\textit{survey}, consideram-se dois projetos, doravante denominados Projeto A e Projeto B, desenvolvidos por uma fábrica de software. Os produtos eram destinados ao suporte à decisão de uma indústria multinacional. Ambos os projetos foram desenvolvidos para plataforma web, segundo o paradigma de orientação a objetos, na linguagem C\\# (.NET). Consistem em aplicações baseadas em Sistemas de Informação Geográfica (\\textit{Geographic Information Systems - GIS}), que possibilitam o georeferenciamento de dados de negócio e a realização de análises espaciais. Em sua maior parte, a implementação dos projetos foi realizada por profissionais distintos, tendo três desenvolvedores participado dos dois projetos, incluindo o autor deste trabalho. Os projetos foram executados segundo de um processo de desenvolvimento iterativo estabelecido pela Fábrica de Software, baseado no \\textit{Rational Unified Process (RUP)}. Este processo incluía como requisitos do projeto a modelagem dos casos de uso, o registro dos defeitos em ferramenta de \\textit{issue tracker} e a rastreabilidade entre classes, casos de uso e defeitos, de acordo com o Método de Rastreabilidade entre Produto de software e Histórico de Manutenções (MR-PHM) proposto. Este cenário permitiu obter informações detalhadas a respeito do histórico de desenvolvimento dos mesmos e identificar relações entre métricas de produto e volume de manutenções, em nível de classe. Na Tabela~\\ref{tab:ProjetosSurvey}, apresentam-se informações sobre os projetos e os produtos desenvolvidos. Pode observar-se que a quantidade de casos de uso, a quantidade de linhas de código e o \\textit{turn-over} de profissionais do Projeto A são superiores ao Projeto B. Percebe-se ainda uma grande diferença da quantidade e densidade de defeitos entre os Projetos A e B. Finalmente, apesar de possuir menos linhas de código, o Projeto B contém mais tipos, o que pode indicar um software mais modularizado.
Neste \\textit{survey}, implementou-se o Método de Medição de Produto de Software (MM-PS). Utilizaram-se trinta e uma (31) métricas de produto de software relacionadas aos atributos: tamanho; complexidade; acoplamento; coesão; e herança. Métricas tradicionais como a suíte de Halstead \\cite{Halstead1977} e Complexidade Ciclomática \\cite{McCabe1976}; além de métricas de linguagens orientadas a objetos, como a suíte \\textit{CK} \\cite{Chidamber1994} e métricas de acoplamento (\\textit{AC, EC, ABC}) \\cite{Martin1994} também foram utilizadas. A métrica Índice de Manutenibilidade (\\textit{Maintainability Index - MI}), proposta em \\cite{Oman1994}, foi também considerada como variável independente, para investigação de seu potencial preditivo.As métricas de produto de software utilizadas neste \\textit{survey} são apresentadas no Anexo~\\ref{anexo:MetricasProduto} e detalhadas no Apêndice~\\ref{apen:MetricasTecnicas}.Diversos trabalhos têm discutido a validade de métricas de software, sob a ótica da metrologia. Em \\cite{Abran2010} apresentam-se críticas às métricas da suite de Halstead e as baseadas na Complexidade Ciclomática, principalmente com relação à escala e unidade de métricas e à efetividade da medição do atributo endereçado pela métricas.Apesar destas discussões, diversos trabalhos têm se utilizado destas métricas básicas para predição de defeitos, conforme apresentado no Capítulo~\\ref{cap:TrabRelacionados}. Neste trabalho de pesquisa, não há pretensão de se propor novas métricas, mais aderentes aos conceitos de metrologia, mas da utilização de métricas referenciadas na academia e implementadas em ferramentas, que possam ser obtidas de maneira prática em projetos de software.
Neste \\textit{survey}, os métodos de medição propostos para o EARLY-FIX foram implementados. Durante a realização deste trabalho, os projetos considerados já haviam encerrado seu desenvolvimento e estavam em período de manutenção. Os projetos não utilizaram o processo de Integração Contínua em conjunto com a extração de medidas de produto, portanto não havia um repositório de medidas das classes ao longo de seu desenvolvimento.Para implementação do Método de Medição de Produto de Software (MM-PS) e geração do repositório de medidas, foi necessário utilizar uma estratégia de recuperar todas as revisões de código-fonte dos projetos, a partir do Servidor de Controle de Versão (SCV). Esta estratégia de integração foi adaptada de \\cite{Moreira2011a}, conforme descrito na seção \\ref{sec:MetodosMedicao}. As medições de produto e de histórico de manutenção corretiva foram congeladas no final do primeiro trimestre de 2011, a fim de possibilitar a implementação e verificação dos métodos de Medições Consolidadas (MM-C), de Calibração de Predição de Volume (MC-PV) e do Modelo de Indicadores de Predição de Volume (MI-PV).Na Figura~\\ref{fig:ImplMetodosMedicao}, apresenta-se o processo integrado de implementação dos Métodos de Medição neste \\textit{survey}, incluindo as ferramentas utilizadas para realização das etapas. As informações sobre o histórico de defeitos foram extraídas a partir do sistema de \\textit{Issue Tracker} Mantis, ferramenta utilizada nos projetos para registrar os defeitos identificados no software. As informações do histórico de modificações foram obtidas a partir de \\textit{logs} do Sistema de Controle de Versão Subversion (\\textit{SVN}), também utilizado por estes projetos. A integração entre os sistemas de \\textit{Issue Tracker} e Controle de Versão, possibilitada pela utilização do MR-PHM (seção~\\ref{sec:MetodoRastreabilidade}) durante o desenvolvimento dos projetos, possibilitaram a identificação das modificações de manutenção corretiva.A implementação dos Métodos de Medição, durante a pesquisa, envolveu a integração de diversas ferramentas de código aberto (\\textit{open-source}) e comerciais, além do desenvolvimento de duas novas ferramentas e de scripts de automatização, conforme apresentado na Tabela~\\ref{tab:FerramentasImplMedicao}.
Na Figura~\\ref{fig:ModeloTabelaMetricasSurvey}, apresenta-se a estrutura da tabela produzida após o processo de consolidação das medidas, descrita a seguir:As linhas representam as classes desenvolvidas nos projetos de software;As colunas representam as medidas de produto (seção \\ref{tab:MetricasProdutoSurvey}) e do histórico de manutenção corretiva (seção \\ref{tab:MetricasHistoricoManutSurvey});As medidas de produto da classe referem-se à revisão de entrega da mesma, ou seja, da última versão na data da implantação da funcionalidade; eAs medidas de histórico de manutenção e defeitos da classe são acumuladas nos períodos dos primeiros 3, 6 e 12 meses de manutenção, a partir da respectiva revisão de entrega.
O histograma das variáveis dependentes é apresentado na Figura~\\ref{fig:GraficosHistograma}. Pode-se observar, visualmente, que as variáveis apresentam distribuição semelhante à de Poisson, voltada para variáveis discretas, na qual quantidade de eventos elevados são raros. A distribuição de Poisson tem como característica que a variância da variável seja semelhante a sua média, o que não ocorre com frequência. Para esta população, as variáveis de defeitos tem média relativamente aproximada da mediana, o que não ocorre para as variáveis de modificações corretivas, para as quais ocorre super dispersão (\\textit{overdispersion}).
A técnica de Regressão Linear tem sido consistentemente utilizada e verificada no contexto de predição de defeitos, como em (\\cite{VanKoten2006} e \\cite{Nagappan2005}), e possui amplo suporte em ferramentas e pacotes estatísticos. No Anexo~\\ref{anexo:TecnicasSuporteFramework} apresenta-se uma breve descrição da técnica de regressão linear.A técnica de Regressão de Poisson destina-se à predição de dados discretos de contagem (\\textit{counts}), para os quais valores elevados são eventos raros \\cite{Neter1996}. Devido à medida de defeitos encontrados em módulos de software apresentar as características citadas, artigos como \\cite{Kpodjedo2011}, \\cite{Li2006} têm utilizado a Regressão de Poisson para predição de volume de defeitos. Outros artigos como \\cite{Succi2001} e \\cite{Khoshgoftaar2001} aplicam a extensão Regressão de Poisson Inflada de Zeros (\\textit{Zero-Inflated Poisson}), que se mostra mais adequada em casos onde a variância é muito superior à média da variável dependente (defeitos) em uma população.--------------------------------------------------------------------A técnica de Regressão Linear Multivariada (\\textit{Multivariate Linear Regression - MLR}) estima os coeficientes de uma equação linear, envolvendo uma ou mais variáveis independentes, que melhor prevêem o valor de uma variável dependente. Modelos de regressão de contagem (\\textit{count models}) podem ser utilizados para predição de variáveis discretas de contagem, como ocorre com a quantidade de defeitos e modificações corretivas. A Regressão de Poisson (\\textit{Poisson Regression - PR}), um destes modelos, estima os coeficientes de uma função não linear, adequada para predição de variáveis de contagem, nas quais valores elevados sejam eventos raros. Uma variação desta técnica consiste na Regressão de Poisson Inflada de Zeros (\\textit{Zero-Inflated Poisson - ZIP}). Esta técnica se mostra mais adequada em distribuições onde ocorre excesso de valores iguais a zero.Dados empíricos são frequentemente super dispersos (\\textit{overdispersed}). A principal razão para isto consiste na falta de controle total sobre experimentos, atribuindo grande parte da variabilidade observada a fontes desconhecidas \\cite{Succi2001}.Entretanto, a regressão de Poisson tem como premissa que a variância da variável dependente seja semelhante a sua média, o que não ocorre com frequência. No contexto de predição de defeitos, a técnica de Regressão Binomial Negativa (\\textit{Negative Binomial regression - NB}) tem sido utilizada nesses casos, por suportar variáveis com elevada dispersão (\\textit{overdispersion}) \\cite{Succi2001}. Esta técnica também possui uma variação que endereça distribuições onde ocorre excesso de valores iguais a zero: a Regressão Binomial Negativa Inflada de Zeros (\\textit{Zero-Inflated Negative Binomial Regression - ZIBN}).
Neste trabalho, utilizou-se o método para seleção de variáveis \\textit{Backward Elimination}. Neste método, calibra-se o modelo, considerando inicialmente todas as variáveis independentes. As variáveis são então testadas individualmente pelo nível descritivo (\\textit{p-value}), sendo removidas a cada passo as variáveis menos significativas. O processo é interrompido, quando as variáveis restantes apresentam no máximo o nível de significância desejado para o modelo. Nesta prova de conceito, o nível de significância foi fixado em 0.1 (90\\%). Os coeficientes dos modelos obtidos são apresentados no Anexo~\\ref{anexo:ModelosRegressaoSurvey}.---------------------------------------------------A primeira comparação é realizada considerando o coeficiente de determinação $R^{2}$. O $R^{2}$ é uma medida estatística que avalia o quanto da variabilidade da variável dependente pode ser prevista por um modelo. Um valor de $R^{2}$ igual a 1,0 (100\\%) significa um ajuste perfeito à amostra de dados. A medida de $R^{2}$ ajustado também pode ser utilizada para explicar algum desvio do $R^{2}$ , pois considera os graus de liberdade das variáveis preditivas na mesma população. Detalha-se mais a forma de cálculo dos coeficientes $R^{2}$ e $R^{2}$ ajustado na seção~\\ref{sec:CoeficDeterminacao} do Anexo~\\ref{anexo:TecnicasSuporteFramework}.No processo de calibração de modelos de regressão linear, busca-se encontrar coeficientes que permitam obter uma reta de regressão que apresente menor variância em relação aos valores observados. Neste tipo de regressão, o coeficiente $R^{2}$ tem sido frequentemente utilizado como medida de desempenho do ajuste, pois apresenta valores maiores para modelos que apresentem menor variância. Ou seja, o $R^{2}$ busca medir o que a regressão linear se propõe a fazer.Em técnicas de regressão de dados de contagem (\\textit{count models}), como as utilizados nesta prova de conceito (\\textit{PR, ZIP, NB, ZINB}), para obtenção de um modelo, realiza-se estimativa por máxima verossimilhança (\\textit{Maximum Likelihood Estimation - MLE}), através de um processo iterativo. Para estes casos, diversos autores têm proposto medidas inspiradas no coeficiente de determinação $R^{2}$, chamadas pseudo-$R^{2}$. Estas medidas são chamadas ``pseudo''-$R^{2}$, por apresentaram semelhança ao $R^{2}$ na escala, variando entre 0 e 1, cujos valores mais elevados indicam um melhor ajuste de modelo. Entretanto, elas não podem ser comparadas com coeficientes $R^{2}$, pois podem apresentar valores muito diferentes.Entre os pseudo-$R^{2}$, encontra-se o coeficiente $R^{2}$ de McFadden, também conhecido como razão da verossimilhança (\\textit{ratio of the likelihoods}), descrito na seção~\\ref{sec:CoeficDeterminacao} do Anexo~\\ref{anexo:TecnicasSuporteFramework}. Este coeficiente pode ser interpretado como a proporção do desvio explicada pelo modelo.Desta forma, a segunda comparação de modelos é realizada apenas sobre os modelos obtidos com técnicas de regressão de contagem (\\textit{PR, ZIP, NB, ZINB}), com a utilização os coeficientes $R^{2}$ e $R^{2}$ ajustado de McFadden.-------------------------------------------------------------------------------Pode-se observar que os modelos de predição das variáveis de volume de defeitos apresentaram coeficientes semelhantes. Para a variável $DEF_{1tri}$, as técnicas de Regressão de Poisson (\\textit{PR}) e Regressão Binomial Negativa (\\textit{NBR}) apresentaram coeficientes levemente superiores. Já para as variáveis $DEF_{1sem}$ e $DEF_{1ano}$, a técnica de Regressão Binomial Negativa Inflada de Zeros (\\textit{ZIP}) gerou modelos com os maiores coeficientes.Na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_DEF_McFadden}, apresenta-se uma comparação dos modelos de predição de volume de defeitos, utilizando o coeficiente $R^2$ de McFadden. Diferentemente da comparação utilizando $R^2$, apresentada na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_DEF}, percebe-se maior diferença entre os coeficientes dos modelos. Os modelos gerados com a técnica de Regressão de Poisson (\\textit{PR}) apresentaram coeficientes superiores para as três variáveis de defeitos, seguidas pelos modelos obtidos com a técnica de Regressão de Poisson Inflada de Zeros (\\textit{ZIP}).
Nos modelos de predição de variáveis de volume de modificações corretivas, representados na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_LCOR}, pode-se observar uma representativa diferença entre os coeficientes dos modelos calibrados por técnicas de regressão distintas. Para as variáveis $LCOR_{1trim}$, $LCOR_{1sem}$ e $LCOR_{1ano}$, os modelos gerados pela técnica de Regressão de Poisson (\\textit{PR}) apresentaram coeficientes $R^2$ superiores, seguidos pela Regressão Binomial Negativa Inflada de Zeros (\\textit{ZIBN}) para $LCOR_{1sem}$ e $LCOR_{1ano}$, e Regressão Linear, para $LCOR_{1trim}$.----------------------------------------------------------Na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_LCOR_McFadden}, apresenta-se uma comparação análoga para os modelos de predição de volume de modificações corretivas, também utilizando o coeficiente $R^2$ de McFadden. Neste gráfico, observa-se que as técnicas de Regressão de Poisson (\\textit{PR}) e de Regressão de Poisson Inflada de Zeros (\\textit{ZIP}) apresentam mais uma vez os maiores coeficientes. Entretanto, a diferença de $R^2$ de McFadden entre os modelos obtidos com as duas técnicas de Poisson é bastante reduzida em relação a comparação utilizando o coeficiente $R^2$, apresentada na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_LCOR}. Isto indica que, apesar de os modelos (\\textit{ZIP}) apresentarem predição da variabilidade inferior aos modelos (\\textit{PR}), eles apresentaram nível semelhante de melhoria da máxima verossimilhança da predição. Já os modelos obtidos com Regressão Binomial Negativa (\\textit{BN}) e Regressão Binomial Negativa Inflada de Zeros (\\textit{ZIBN}), apresentaram coeficientes de McFadden bastante inferiores, de forma alinhada com a comparação utilizando $R^2$.-----------------------------------------------------------De forma geral, a técnica de Regressão de Poisson (\\textit{PR}) e sua variação, Regressão de Poisson Inflada de Zeros (\\textit{ZIP}), geraram os modelos com maior predição da variabilidade ($R^2$) das variáveis dependentes, como observado na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_DEF}. Já as técnicas de Regressão Linear Multivariada, Regressão Binomial Negativa e Regressão Binomial Negativa Inflada de Zeros, apresentaram coeficientes $R^2$ semelhantes para variáveis de volume de defeitos, mas valores de $R^{2}$ muito inferiores para variáveis de modificações corretivas, como se pode observar na Figura~\\ref{fig:GraficoComparacaoModelosRegressao_LCOR}.De forma geral, pode-se observar que as técnicas de Regressão de Poisson (\\textit{PR}) e de Regressão de Poisson Inflada de Zeros (\\textit{ZIP}) apresentaram os maiores coeficientes de predição de variabilidade ($R^2$) e de proporção de desvio explicada pelo modelo ($R^2$ de McFadden), caracterizando potencial utilização das mesmas na predição de defeitos e modificações corretivas.
Na Figura~\\ref{fig:ScatterPlotsModelos}, sintetizam-se os gráficos de espalhamento (\\textit{scatter plots}) dos valores observados (eixo $x$) e estimados (eixo $y$) para as variáveis dependentes, onde cada ponto representa uma classe. Para cada variável dependente, selecionou-se a técnica de regressão que gerou modelos com maior coeficiente de determinação $R^2$. Idealmente, os valores estimados deveriam estar próximos do observado, ou seja, da diagonal do gráfico. Observa-se que, de forma geral, as estimativas geradas pelos modelos obtidos se aproximam da diagonal, especialmente nas medidas mais extremas, cuja identificação apresenta grande interesse para este trabalho, devido ao volume e o esforço de manutenção corretiva empregado nestes módulos.
Nesta seção, descrevem-se a implementação e a verificação do Método de Detecção de Módulos Propensos à manutenção corretiva (MD-MP), apresentado na seção~\\ref{sec:MetodoAnalisePareto}.O MD-MP baseia-se na utilização da técnica de Análise de Pareto, considerando a suposição de que a maioria dos defeitos encontra-se em um pequeno conjunto dos módulos de um software (\\cite{Ware2007} e \\cite{Fenton2000}). Na análise estatística descritiva, apresentada no Anexo~\\ref{anexo:AnaliseExploratoria}, pode-se verificar que, nos projetos considerados neste \\textit{survey}, também ocorre uma distribuição semelhante à lei de Pareto, pois 74\\% dos defeitos foram localizados em 20\\% dos módulos. Para implementação e verificação do MD-MP, selecionaram-se dois indicadores, representando os valores estimados do volume de defeitos detectados ($DEF_{1ano}$) e de modificações corretivas realizadas ($LCOR_{1ano}$), durante o primeiro ano após a implantação dos módulos de software. Utilizaram-se, para estimativa, os modelos com maior coeficiente $R^2$ para os indicadores, gerados com as técnicas de Regressão de Poisson (\\textit{PR}), para $LCOR_{1ano}$, e de Regressão de Poisson Inflada de Zeros (\\textit{ZIP}), para $DEF_{1ano}$.Na implementação do MD-MP, realizou-se uma Análise de Pareto sobre os indicadores selecionados ($DEF_{1ano}$ e $LCOR_{1ano}$), individualmente. A tabela consolidada possuia 274 registros, referentes a módulos de software (classes). Consideraram-se como critérios de corte 5\\%, 10\\% e 20\\%, representando respectivamente os primeiros 14, 27 e 54 módulos ordenados, de forma decrescente, pelo valor estimado para a variável dependente.Para a verificação da assertividade da análise de Pareto, utilizaram-se duas medidas de desempenho:Percentual de classes de maior volume de defeitos ou modificações, dentro da seleção} - Representa o percentual dos módulos de maior volume de defeitos ou modificações observadas que são selecionados pelo mesmo critério de corte (5\\%, 10\\% ou 20\\%), quando ordenados pelo valor estimado para a variável dependente; ePercentual de defeitos/modificações corretivas dentro da seleção} - Representa o número de defeitos ou modificações corretivas realizadas nas classes selecionadas, divido pelo total de modificações corretivas ou defeitos realizadas em todas as classes.A Figura~\\ref{fig:AnaliseParetoDEF_1ano} e a Tabela~\\ref{tab:AnalisePareto_DEF_1ano} compilam uma análise semelhante para o indicador $DEF_{1ano}$. Com os critérios de corte 5\\%, 10\\% e 20\\%, identificam-se entre 57\\%, 62\\% e 83\\% do conjunto das classes onde foram detectados mais defeitos, considerando os mesmos critérios de corte. \\\\Observa-se também que as classes selecionadas pelos cortes de 5\\%, 10\\% e 20\\%, concentraram cerca de 27\\%, 42\\% e 65\\% do total de defeitos detectados nos projetos. \\\\Analisando os resultados de outra maneira, observa-se que, para o indicador $DEF_{1ano}$, com o critério de corte de 10\\% (27 classes), por exemplo, selecionaram-se 17 (62\\%) do conjunto das 27 das classes mais defeituosas dos projetos. As classes selecionadas nesta análise concentraram 42\\% dos defeitos encontrados nos projetos.
A Figura~\\ref{fig:AnaliseParetoLCOR_1ano} e a Tabela~\\ref{tab:AnalisePareto_LCOR_1ano} sintetizam a análise de Pareto para o indicador $LCOR_{1ano}$. Pode-se observar que com os critérios de corte 5\\%, 10\\% ou 20\\% são selecionadas respectivamente 71\\%, 55\\% e 51\\% do conjunto das classes com maior volume de modificações corretivas observadas, utilizando os mesmos percentuais de critério de corte. \\\\Observa-se também que as classes selecionadas pelos cortes de 5\\%, 10\\% e 20\\%, concentraram respectivamente cerca de 51\\%, 57\\% e 69\\% do total de modificações corretivas nos projetos. \\\\Analisando os resultados sob outro prisma, pode-se observar que para o indicador $LCOR_{1ano}$, com o critério de corte de 5\\%, identificaram-se 14 classes que apresentaram 51\\% do volume total de modificações corretivas realizados nos projetos, uma medida indireta de esforço. Das 14 classes selecionadas, 10 (71\\%) fazem parte do conjunto das 15 classes que mais sofreram modificações corretivas.--------------------------------------------------------A diferença entre os percentuais dos critérios de corte da Análise de Pareto e os volumes de defeitos e modificações corretivas dos módulos selecionados, indica potencial de utilização do MD-MP em projetos de software. Através da priorização dos módulos mais propensos à defeitos, pode-se melhorar o direcionamento de atividades de qualidade, como testes, inspeções e refatorações, visando minimizar o esforço e o custo futuro em atividades de manutenção corretiva.Neste capítulo, apresentou-se a implementação e a verificação do EARLY-FIX em uma prova de conceito, utilizando o histórico de manutenções corretivas de dois projetos de software desenvolvidos na indústria. No próximo capítulo, descrevem-se análises e discussões sobre os principais resultados obtidos neste trabalho de pesquisa.
Limitações dos Projetos investigadosA prova de conceito foi baseada em uma base de dados extraída, a partir do histórico de manutenções de dois produtos de software, desenvolvidos por uma mesma indústria e utilizando processo baseado em \\textit{Rational Unified Process (RUP)}. Ambos produtos encontram-se voltados à plataforma web, desenvolvidos com a linguagem de programação C#.NET, com tecnologias e objetivos de negócio similares. Ajustaram-se os modelos preditivos para as medidas destes projetos, portanto, os modelos obtidos limitam-se a este contexto. Recomenda-se a implementação do EARLY-FIX em diferentes contextos, a fim de verificar sua validade externa.Para extração das variáveis dependentes, considerou-se a utilização nos projetos do Método de Rastrabilidade (MR-PHM), através do qual modificações de código são associadas a casos de uso ou correção de defeitos. Nestes projetos, a rastreabilidade dependia de ação manual, pois era necessário que os desenvolvedores associassem um item de trabalho (caso de uso ou defeito) ao enviar as modificações para um Sistema de Controle de Versão. Este processo manual permitiu que manutenções de código não fossem associadas aos respectivos defeitos. No Projeto A 67\\% (669/998) dos defeitos corrigidos foram indicados nos \\textit{commits} das respectivas modificações, enquanto no Projeto B apenas 45\\% (139/304) dos defeitos foram associados. A existência de defeitos e modificações corretivas não contabilizadas nas classes afeta a validade interna dos resultados. Por este motivo, em futuras implementações do EARLY-FIX, sugere-se a configuração do sistema de Controle de Versão com restrições que impeçam o \\textit{commit} de modificações do código sem associação com um item de trabalho (funcionalidade ou defeito), de forma a garantir a rastreabilidade necessária para predição de defeitos.Em projetos iterativos, deveria idealmente ocorrer uma implantação após uma iteração, de forma a encurtar o tempo de retorno dos usuários sobre as funcionalidades desenvolvidas e nortear os próximos passos. Os dois projetos considerados neste \\textit{survey} destinaram-se a uma empresa com processo bastante rígido de implantação de projetos de software, realizado por empresas terceiras. O processo de implantação do software e respectivo modelos de dados nos ambientes de desenvolvimento, homologação e produção chegou a consumir mais de um mês em algumas iterações. Somente após a finalização deste processo, o usuário pôde iniciar as validações em seu ambiente. Entretanto, devido à disponibilidade limitada de informações, considerou-se como data de entrega das funcionalidades a data da validação dos casos de uso, que ocorria ao final da iteração, antes do início do processo de implantação do cliente.Limitações das Métricas de Produto e de Manutenção UtilizadasComo descrito na seção~\\ref{sec:MetricasProdutoSurvey}, alguns trabalhos têm discutido a validade de métricas de software. As métricas de Halstead por exemplo, oriundas de linguagens estruturadas, foram utilizadas como variáveis independentes. Entretanto, não há consenso de como o cálculo destas métricas tradicionais é executado em linguagens OO populares como C\\# ou Java. Em \\cite{Abran2010}, apresentam-se críticas às métricas da suite de Halstead e baseadas na Complexidade Ciclomática, principalmente, com relação à escala e unidade de métricas e à efetividade da medição do atributo endereçado pela métricas.Apesar destas discussões, diversos trabalhos têm se utilizado destas métricas básicas para construção de modelos estatísticos e de aprendizagem de máquina para predição de defeitos, conforme apresentado no Capítulo~\\ref{cap:TrabRelacionados}. Neste trabalho de pesquisa, não houve pretensão de se propor novas métricas, mais aderentes aos conceitos de metrologia, mas sim utilizar-se de métricas referenciadas na academia e implementadas em ferramentas, que possam ser obtidas de maneira prática em projetos de software.Nesta investigação, os modelos preditivos foram calibrados no nível de granularidade de módulos de software (classes). Em projetos desenvolvidos iterativamente, funcionalidades são mantidas enquanto outras novas são desenvolvidas. Com base nas informações disponíveis nesta prova de conceitto, considerou-se que a implantação de uma classe ocorreu quando um caso de uso relacionado à classe foi validado e implantado. A partir deste momento, modificações associadas à correção de defeitos são contabilizadas para a classe.Sabe-se que manutenção preventiva visa melhorar a qualidade do código, impactando em sua manutenibilidade. Logo, espera-se que classes refatoradas tenham o volume de defeitos e de modificações corretivas reduzido, após a manutenção preventiva. Entretanto, utilizam-se para calibração da predição as medidas da classe em sua revisão de entrega, a última revisão anterior a data da implantação da funcionalidade. Desta maneira, ignoram-se melhorias futuras no código-fonte e \\textit{design} da classe, que podem torná-la menos propensa à defeitos ao longo do tempo. Sugere-se estender o EARLY-FIX com modelos que considerem as medições de produto das classes à cada entrega de iteração na predição dos defeitos das próximas iterações.Limitações da Análise EstatísticaA acurácia de uma medida derivada, em conjunto com os erros de medição correspondentes, é diretamente relacionada à acurácia de cada uma das medidas básicas, e como estas são matematicamente combinadas. A qualidade dos dispositivos de medição das medidas básicas impactam a qualidade das medidas derivadas e indicadores \\cite{Abran2010}. Como observado na análise estatística descritiva, a maior parte das métricas de produto e histórico de manutenção corretiva não apresentaram distribuição normal, o que limitou as técnicas estatísticas que poderiam ser aplicadas sobre os dados. Por este motivo, incluiu-se na análise de correlações o coeficiente de postos de Spearman, por não apresentar como pré-requisito a normalidade das medidas.Na implementação do Método de Calibração de Predição de Volume de manutenção corretiva (MC-PV), optou-se por reduzir o número de variáveis utilizadas no modelo com a técnica de seleção de variáveis \\textit{Backward Elimination}, mantendo apenas as que apresentassem significância estatística (0.1). Esta estratégia permitiu gerar modelos que permitem uma melhor análise das métricas de produto que influenciaram uma variável dependente, de forma significativa. Contudo, para análise individual dos coeficientes, é importante que as variáveis independentes selecionadas não apresentem forte correlação entre sí \\cite{Neter1996}. Este cenário não ocorre com a maioria das métricas de produto de software, inclusive as utilizadas neste \\textit{survey}, que em grande parte possuem correlação com o tamanho da classe (LOC). Contudo, a utilização de métodos de seleção de variáveis pode produzir modelos com menor coeficiente de determinação ($R^2$) do que a utilização de todas as variáveis disponíveis. Em futuras implementações do MC-PV, recomenda-se analisar se a prioridade do modelos é a predição ou a compreensão dos fatores que influenciam na manutenção corretiva. Segundo \\cite{Neter1996}, o fato de os modelos incluírem variáveis correlacionadas entre sí não afeta a capacidade de se obter uma predição satisfatória no ajuste dos modelos e predição de novas observações.Conforme discutido na seção~\\ref{sec:ComparacaoModelosDiscuss}, na implementação do MC-PV, as variáveis de defeitos ($DEF$) apresentaram valor médio próximo a variância. Esta distribuição, portanto, mostra-se adequada para a utilização das técnicas de \\textit{PR} e \\textit{ZIP}.As variáveis de modificações corretivas ($LCOR$), contudo, apresentam variância muito superior à média, caracterizando super dispersão (\\textit{overdispersion}). Apesar de trabalhos relacionados, como os de \\cite{Weyuker2008}, recomendarem a utilização de Regressão Binomial Negativa, nestes casos, os modelos gerados com as técnicas de \\textit{PR} e \\textit{ZIP} apresentaram coeficientes $R^{2}$ muito superiores do que as outras técnicas de regressão analisadas.
Limitações dos Projetos investigadosA prova de conceito foi baseada em uma base de dados extraída, a partir do histórico de manutenções de dois produtos de software, desenvolvidos por uma mesma indústria e utilizando processo baseado em \\textit{Rational Unified Process (RUP)}. Ambos produtos encontram-se voltados à plataforma web, desenvolvidos com a linguagem de programação C#.NET, com tecnologias e objetivos de negócio similares. Ajustaram-se os modelos preditivos para as medidas destes projetos, portanto, os modelos obtidos limitam-se a este contexto. Recomenda-se a implementação do EARLY-FIX em diferentes contextos, a fim de verificar sua validade externa.Para extração das variáveis dependentes, considerou-se a utilização nos projetos do Método de Rastrabilidade (MR-PHM), através do qual modificações de código são associadas a casos de uso ou correção de defeitos. Nestes projetos, a rastreabilidade dependia de ação manual, pois era necessário que os desenvolvedores associassem um item de trabalho (caso de uso ou defeito) ao enviar as modificações para um Sistema de Controle de Versão. Este processo manual permitiu que manutenções de código não fossem associadas aos respectivos defeitos. No Projeto A 67\\% (669/998) dos defeitos corrigidos foram indicados nos \\textit{commits} das respectivas modificações, enquanto no Projeto B apenas 45\\% (139/304) dos defeitos foram associados. A existência de defeitos e modificações corretivas não contabilizadas nas classes afeta a validade interna dos resultados. Por este motivo, em futuras implementações do EARLY-FIX, sugere-se a configuração do sistema de Controle de Versão com restrições que impeçam o \\textit{commit} de modificações do código sem associação com um item de trabalho (funcionalidade ou defeito), de forma a garantir a rastreabilidade necessária para predição de defeitos.Em projetos iterativos, deveria idealmente ocorrer uma implantação após uma iteração, de forma a encurtar o tempo de retorno dos usuários sobre as funcionalidades desenvolvidas e nortear os próximos passos. Os dois projetos considerados neste \\textit{survey} destinaram-se a uma empresa com processo bastante rígido de implantação de projetos de software, realizado por empresas terceiras. O processo de implantação do software e respectivo modelos de dados nos ambientes de desenvolvimento, homologação e produção chegou a consumir mais de um mês em algumas iterações. Somente após a finalização deste processo, o usuário pôde iniciar as validações em seu ambiente. Entretanto, devido à disponibilidade limitada de informações, considerou-se como data de entrega das funcionalidades a data da validação dos casos de uso, que ocorria ao final da iteração, antes do início do processo de implantação do cliente.Limitações das Métricas de Produto e de Manutenção UtilizadasComo descrito na seção~\\ref{sec:MetricasProdutoSurvey}, alguns trabalhos têm discutido a validade de métricas de software. As métricas de Halstead por exemplo, oriundas de linguagens estruturadas, foram utilizadas como variáveis independentes. Entretanto, não há consenso de como o cálculo destas métricas tradicionais é executado em linguagens OO populares como C\\# ou Java. Em \\cite{Abran2010}, apresentam-se críticas às métricas da suite de Halstead e baseadas na Complexidade Ciclomática, principalmente, com relação à escala e unidade de métricas e à efetividade da medição do atributo endereçado pela métricas.Apesar destas discussões, diversos trabalhos têm se utilizado destas métricas básicas para construção de modelos estatísticos e de aprendizagem de máquina para predição de defeitos, conforme apresentado no Capítulo~\\ref{cap:TrabRelacionados}. Neste trabalho de pesquisa, não houve pretensão de se propor novas métricas, mais aderentes aos conceitos de metrologia, mas sim utilizar-se de métricas referenciadas na academia e implementadas em ferramentas, que possam ser obtidas de maneira prática em projetos de software.Nesta investigação, os modelos preditivos foram calibrados no nível de granularidade de módulos de software (classes). Em projetos desenvolvidos iterativamente, funcionalidades são mantidas enquanto outras novas são desenvolvidas. Com base nas informações disponíveis nesta prova de conceitto, considerou-se que a implantação de uma classe ocorreu quando um caso de uso relacionado à classe foi validado e implantado. A partir deste momento, modificações associadas à correção de defeitos são contabilizadas para a classe.Sabe-se que manutenção preventiva visa melhorar a qualidade do código, impactando em sua manutenibilidade. Logo, espera-se que classes refatoradas tenham o volume de defeitos e de modificações corretivas reduzido, após a manutenção preventiva. Entretanto, utilizam-se para calibração da predição as medidas da classe em sua revisão de entrega, a última revisão anterior a data da implantação da funcionalidade. Desta maneira, ignoram-se melhorias futuras no código-fonte e \\textit{design} da classe, que podem torná-la menos propensa à defeitos ao longo do tempo. Sugere-se estender o EARLY-FIX com modelos que considerem as medições de produto das classes à cada entrega de iteração na predição dos defeitos das próximas iterações.Limitações da Análise EstatísticaA acurácia de uma medida derivada, em conjunto com os erros de medição correspondentes, é diretamente relacionada à acurácia de cada uma das medidas básicas, e como estas são matematicamente combinadas. A qualidade dos dispositivos de medição das medidas básicas impactam a qualidade das medidas derivadas e indicadores \\cite{Abran2010}. Como observado na análise estatística descritiva, a maior parte das métricas de produto e histórico de manutenção corretiva não apresentaram distribuição normal, o que limitou as técnicas estatísticas que poderiam ser aplicadas sobre os dados. Por este motivo, incluiu-se na análise de correlações o coeficiente de postos de Spearman, por não apresentar como pré-requisito a normalidade das medidas.Na implementação do Método de Calibração de Predição de Volume de manutenção corretiva (MC-PV), optou-se por reduzir o número de variáveis utilizadas no modelo com a técnica de seleção de variáveis \\textit{Backward Elimination}, mantendo apenas as que apresentassem significância estatística (0.1). Esta estratégia permitiu gerar modelos que permitem uma melhor análise das métricas de produto que influenciaram uma variável dependente, de forma significativa. Contudo, para análise individual dos coeficientes, é importante que as variáveis independentes selecionadas não apresentem forte correlação entre sí \\cite{Neter1996}. Este cenário não ocorre com a maioria das métricas de produto de software, inclusive as utilizadas neste \\textit{survey}, que em grande parte possuem correlação com o tamanho da classe (LOC). Contudo, a utilização de métodos de seleção de variáveis pode produzir modelos com menor coeficiente de determinação ($R^2$) do que a utilização de todas as variáveis disponíveis. Em futuras implementações do MC-PV, recomenda-se analisar se a prioridade do modelos é a predição ou a compreensão dos fatores que influenciam na manutenção corretiva. Segundo \\cite{Neter1996}, o fato de os modelos incluírem variáveis correlacionadas entre sí não afeta a capacidade de se obter uma predição satisfatória no ajuste dos modelos e predição de novas observações.Conforme discutido na seção~\\ref{sec:ComparacaoModelosDiscuss}, na implementação do MC-PV, as variáveis de defeitos ($DEF$) apresentaram valor médio próximo a variância. Esta distribuição, portanto, mostra-se adequada para a utilização das técnicas de \\textit{PR} e \\textit{ZIP}.As variáveis de modificações corretivas ($LCOR$), contudo, apresentam variância muito superior à média, caracterizando super dispersão (\\textit{overdispersion}). Apesar de trabalhos relacionados, como os de \\cite{Weyuker2008}, recomendarem a utilização de Regressão Binomial Negativa, nestes casos, os modelos gerados com as técnicas de \\textit{PR} e \\textit{ZIP} apresentaram coeficientes $R^{2}$ muito superiores do que as outras técnicas de regressão analisadas.
Em projetos desenvolvidos com processos iterativos, como \\textit{RUP}, \\textit{Scrum} e \\textit{XP}, ocorre idealmente a implantação das funcionalidades desenvolvidas a cada iteração, de forma que os usuários possam testá-las e validá-las. Enquanto o time de desenvolvimento trabalha com a implementação de novas funcionalidades, pode ocorrer em paralelo a correção de defeitos detectados pelos usuários. O cenário de projetos iterativos apresenta alguns desafios para predição de defeitos, entre eles: (1) a identificação das modificações corretivas; e (2) a identificação dos módulos mais defeituosos. O EARLY-FIX endereça estes desafios através do Método de Rastreabilidade entre Produto de software e Histórico de Manutenções (MR-PHM), cuja implementação envolve uma integração entre sistemas de controle de versão e de rastreamento de defeitos (\\textit{issue tracker}).
O EARLY-FIX foi implementado e verificado no contexto de dois projetos de software da indústria. Os projetos foram desenvolvidos por uma Fábrica de Software, no modelo de \\textit{outsourcing}, e destinados a uma empresa multinacional. O desenvolvimento ocorreu segundo um processo iterativo baseado no \\textit{Rational Unified Process (RUP)}. Os produtos de software eram voltados à plataforma web e consistiam em Sistemas de Informação Geográfica (\\textit{GIS}). Foram desenvolvidos na linguagem C\\#, segundo o paradigma de Orientação a Objetos (OO).Para os projetos considerados na prova de conceito, não havia uma base com o histórico de evolução das medidas de produto dos módulos de software. Por este motivo, realizou-se um processo de extração das medidas dos módulos ao longo do tempo, obtidas a partir das revisões de código-fonte armazenadas no sistema de controle de versão Subversion (\\textit{SVN}). Para obtenção do volume de manutenção corretiva observado nos módulos dos projetos, informações foram extraídas do sistema de \\textit{issue tracker} Mantis. A utilização do Método de Rastreabilidade proposto (MR-PHM) nos projetos considerados, e a integração implementada entre as ferramentas de controle de versão e \\textit{issue tracker}, foram fatores que permitiram a identificação das modificações de código-fonte associadas a correção de defeitos. Durante a implementação dos Métodos de Medição do EARLY-FIX, desenvolveram-se duas ferramentas, e uma série de \\textit{scripts}, para automatização dos processos de: recuperação do código-fonte de uma revisão; compilação; extração de medidas, transformação e carga (\\textit{ETL}) de medidas para uma base de dados.
O EARLY-FIX foi implementado e verificado no contexto de dois projetos de software da indústria. Os projetos foram desenvolvidos por uma Fábrica de Software, no modelo de \\textit{outsourcing}, e destinados a uma empresa multinacional. O desenvolvimento ocorreu segundo um processo iterativo baseado no \\textit{Rational Unified Process (RUP)}. Os produtos de software eram voltados à plataforma web e consistiam em Sistemas de Informação Geográfica (\\textit{GIS}). Foram desenvolvidos na linguagem C\\#, segundo o paradigma de Orientação a Objetos (OO).Para os projetos considerados na prova de conceito, não havia uma base com o histórico de evolução das medidas de produto dos módulos de software. Por este motivo, realizou-se um processo de extração das medidas dos módulos ao longo do tempo, obtidas a partir das revisões de código-fonte armazenadas no sistema de controle de versão Subversion (\\textit{SVN}). Para obtenção do volume de manutenção corretiva observado nos módulos dos projetos, informações foram extraídas do sistema de \\textit{issue tracker} Mantis. A utilização do Método de Rastreabilidade proposto (MR-PHM) nos projetos considerados, e a integração implementada entre as ferramentas de controle de versão e \\textit{issue tracker}, foram fatores que permitiram a identificação das modificações de código-fonte associadas a correção de defeitos. Durante a implementação dos Métodos de Medição do EARLY-FIX, desenvolveram-se duas ferramentas, e uma série de \\textit{scripts}, para automatização dos processos de: recuperação do código-fonte de uma revisão; compilação; extração de medidas, transformação e carga (\\textit{ETL}) de medidas para uma base de dados.
Extrairam-se cerca de 292.000 registros referentes as medidas de produto, ao longo do histórico de evolução das classes dos projetos. Após esta etapa, na implementação do Método de Medições Consolidadas (MM-C), ocorreu o pré-processamento desta base com medidas, a fim de produzir uma tabela para calibração dos modelos de predição. A tabela consolidada consistiu de 274 registros, um para cada classe, onde se encontravam as medidas de produto na data de implantação e o volume de defeitos e de modificações corretivas observados posteriormente na classe, agrupados por período de tempo.Uma análise estatística descritiva realizada sobre as medidas permitiu verificar que as medições foram realizadas corretamente. Nesta etapa, observou-se que a distribuição da maior parte das métricas não apresentou normalidade, limitando as técnicas estatísicas que poderiam ser aplicadas sobre as mesmas. A análise de correlações permitiu verificar que as métricas de tamanho, complexidade e acoplamento apresentaram forte correlação com as métricas de volume de manutenção corretiva.Realizou-se ainda uma avaliação da medição e dos produtos de informação produzidos pelos Métodos de Medição, baseada nos critérios da norma ISO/IEC 15939:2007 - \\textit{Systems and software engineering - Measurement Process} \\cite{ISO15939}.Na implementação do Método de Calibração de Predição de Volume (MC-PV), utilizaram-se cinco técnicas estatísticas de regressão para comparação: Regressão Linear Multivariada (\\textit{Multivariate Linear Regression - MLR}); Regressão de Poisson (\\textit{Poisson Regression - PR}); Regressão de Poisson Inflada de Zeros (\\textit{Zero-Inflated Poisson - ZIP}); Regressão Binomial Negativa (\\textit{Negative Binomial regression - NB}); e Regressão Binomial Negativa Inflada de Zeros (\\textit{Zero-Inflated Negative Binomial Regression - ZIBN}). Utilizou-se o método para seleção de variáveis \\textit{Backward Elimination}, visando manter nos modelos preditivos apenas métricas de produto estatisticamente significantes.Foram realizadas duas comparações entre os modelos preditivos gerados pelas diferentes técnicas de regressão, utilizando os coeficientes: $R^2$; e $R^2$ de McFadden. O coeficiente de determinação $R^2$ indica a proporção da variância explicada pelo modelo. O coeficiente de razão da verossimilhança $R^2$ de McFadden, pode ser interpretado como a proporção do desvio explicada pelo modelo.De forma geral, a técnica de Regressão de Poisson (\\textit{PR}) e sua variação, Regressão de Poisson Inflada de Zeros (\\textit{ZIP}), geraram os modelos de melhor predição da variabilidade e do desvio das variáveis dependentes. Já as técnicas de Regressão Linear Multivariada, Regressão Binomial Negativa e Regressão Binomial Negativa Inflada de Zeros, apresentaram coeficientes semelhantes para variáveis de volume de defeitos, em termos de $R^{2}$, mas coeficientes bastante inferiores para variáveis de modificações corretivas.Utilizaram-se os modelos gerados pelo MC-PV para implementação do Modelo de Indicadores de Predição de Volume (MI-PV). As estimativas foram armazenadas em um \\textit{data warehouse}, cuja modelagem multidimensional permitiu a realização de análises \\textit{OLAP} das predições, sob as dimensões de período e nível de granularidade.Neste estudo, observou-se que variáveis dependentes (defeitos e modificações corretivas) apresentaram distribuição semelhante a lei de Pareto (80-20), pois 74\\% dos defeitos detectados no primeiro ano pós-implantação ($DEF_{1ano}$) se encontravam em 20\\% dos módulos. A partir desta constatação, concebeu-se o Método de Detecção de Módulos Propensos à manutenção corretiva (MD-MP), utilizando a técnica de Análise de Pareto.
Extrairam-se cerca de 292.000 registros referentes as medidas de produto, ao longo do histórico de evolução das classes dos projetos. Após esta etapa, na implementação do Método de Medições Consolidadas (MM-C), ocorreu o pré-processamento desta base com medidas, a fim de produzir uma tabela para calibração dos modelos de predição. A tabela consolidada consistiu de 274 registros, um para cada classe, onde se encontravam as medidas de produto na data de implantação e o volume de defeitos e de modificações corretivas observados posteriormente na classe, agrupados por período de tempo.Uma análise estatística descritiva realizada sobre as medidas permitiu verificar que as medições foram realizadas corretamente. Nesta etapa, observou-se que a distribuição da maior parte das métricas não apresentou normalidade, limitando as técnicas estatísicas que poderiam ser aplicadas sobre as mesmas. A análise de correlações permitiu verificar que as métricas de tamanho, complexidade e acoplamento apresentaram forte correlação com as métricas de volume de manutenção corretiva.Realizou-se ainda uma avaliação da medição e dos produtos de informação produzidos pelos Métodos de Medição, baseada nos critérios da norma ISO/IEC 15939:2007 - \\textit{Systems and software engineering - Measurement Process} \\cite{ISO15939}.Na implementação do Método de Calibração de Predição de Volume (MC-PV), utilizaram-se cinco técnicas estatísticas de regressão para comparação: Regressão Linear Multivariada (\\textit{Multivariate Linear Regression - MLR}); Regressão de Poisson (\\textit{Poisson Regression - PR}); Regressão de Poisson Inflada de Zeros (\\textit{Zero-Inflated Poisson - ZIP}); Regressão Binomial Negativa (\\textit{Negative Binomial regression - NB}); e Regressão Binomial Negativa Inflada de Zeros (\\textit{Zero-Inflated Negative Binomial Regression - ZIBN}). Utilizou-se o método para seleção de variáveis \\textit{Backward Elimination}, visando manter nos modelos preditivos apenas métricas de produto estatisticamente significantes.Foram realizadas duas comparações entre os modelos preditivos gerados pelas diferentes técnicas de regressão, utilizando os coeficientes: $R^2$; e $R^2$ de McFadden. O coeficiente de determinação $R^2$ indica a proporção da variância explicada pelo modelo. O coeficiente de razão da verossimilhança $R^2$ de McFadden, pode ser interpretado como a proporção do desvio explicada pelo modelo.De forma geral, a técnica de Regressão de Poisson (\\textit{PR}) e sua variação, Regressão de Poisson Inflada de Zeros (\\textit{ZIP}), geraram os modelos de melhor predição da variabilidade e do desvio das variáveis dependentes. Já as técnicas de Regressão Linear Multivariada, Regressão Binomial Negativa e Regressão Binomial Negativa Inflada de Zeros, apresentaram coeficientes semelhantes para variáveis de volume de defeitos, em termos de $R^{2}$, mas coeficientes bastante inferiores para variáveis de modificações corretivas.Utilizaram-se os modelos gerados pelo MC-PV para implementação do Modelo de Indicadores de Predição de Volume (MI-PV). As estimativas foram armazenadas em um \\textit{data warehouse}, cuja modelagem multidimensional permitiu a realização de análises \\textit{OLAP} das predições, sob as dimensões de período e nível de granularidade.Neste estudo, observou-se que variáveis dependentes (defeitos e modificações corretivas) apresentaram distribuição semelhante a lei de Pareto (80-20), pois 74\\% dos defeitos detectados no primeiro ano pós-implantação ($DEF_{1ano}$) se encontravam em 20\\% dos módulos. A partir desta constatação, concebeu-se o Método de Detecção de Módulos Propensos à manutenção corretiva (MD-MP), utilizando a técnica de Análise de Pareto.
Na implementação do MD-MP, aplicou-se a Análise de Pareto sobre os valores estimados para defeitos e modificações corretivas, gerados pelos modelos calibrados pelo MC-PV. Verificou-se que, com o critério de corte de 5\\% (15 das 292 classes), por exemplo, selecionam-se as classes que representaram 51\\% do volume total das modificações corretivas sofridas pelo produto e 57\\% das classes mais defeituosas dos projetos. Desta forma, o MD-MP monstrou potencial para sua utilização no direcionamento de atividades de qualidade, através da priorização dos módulos mais propensos à defeitos visando minimizar os esforços e os custos futuros de manutenção corretiva.
Métricas de produto de software buscam mensurar características relacionadas ao código-fonte e \\textit{design}, relacionadas a tamanho, complexidade, acoplamento, coesão e outros aspectos específicos de paradigmas de programação, como herança, em orientação a objetos. Estas caraterístisticas estão relacionadas à manutenibilidade, ou seja, ao o esforço necessário para se manter ou modificar um software. A suposição do relacionamento entre as métricas de produto e o volume de defeitos e modificações corretivas em um módulo de software mostrou-se pertinente, como observou-se na análise de correlações.Os resultados obtidos pelos modelos preditivos indicam que as técnicas de Regressão de Poisson e Regressão de Poisson Inflada de Zeros podem apresentar predição de defeitos superior a outras técnicas, como a Regressão Linear Multivariada, de forma alinhada com trabalhos relacionados \\cite{Succi2001}.Observou-se potencial da abordagem proposta na detecção antecipada de módulos de software, cujas medidas de produto possam indicar propensão a defeitos. A mitigação prévia destes riscos de qualidade favorece a manutenibilidade, podendo diminuir o esforço de se manter a base de código no futuro. Além disso, espera-se reduzir os custos de manutenção corretiva através de detecção prévia de defeitos, antes da implantação de um software \\cite{Boehm2001}.
O MR-PHM elenca as atividades necessárias para obtenção das informações necessárias para predição de defeitos, tornando explícita sua execução dentro do processo de desenvolvimento de software utilizado.O Método de Medições Consolidadas (MM-C) objetivou a integração das medidas coletadas pelos Métodos de Medição de Produto de Software (MM-PS) e de Histórico de Manutenção Corretiva (MM-HMC) em uma base consolidada, utilizada para calibração dos modelos preditivos.Os métodos de calibração do EARLY-FIX visaram a construção de modelos preditivos baseados em variáveis dependentes, que se desejam prever, e independentes, utilizadas como parâmetros de predição. Elaborou-se o Método de Calibração de Predição de Volume (MC-PV) de manutenção corretiva, a fim de gerar as predições para o Modelo de Indicadores de Predição de Volume (MI-PV). O Modelo de Indicadores de Predição de Volume (MI-PV) de Manutenção Corretiva proposto reuniu indicadores relacionados a quantidade de defeitos e de modificações corretivas em módulos de software. O modelo consistiu de um cubo, cujas dimensões permitem análises dos indicadores preditivos em diferentes períodos (primeiros 3, 6 e 12 meses após a implantação) e níveis de granularidade (classe, componente e sistema).O Método de Detecção de Módulos Propensos à Manutenção Corretiva (MD-MP) foi concebido de forma a aplicar a técnica de Análise de Pareto sobre as predições dos indicadores, para identificar os módulos para os quais estimaram-se as maiores quantidades de defeitos e modificações corretivas. Desta forma, pode-se priorizar sobre estes módulos, a realização de atividades de qualidade, como testes, inspeções e refatorações.
O autor recomenda a implementação do EARLY-FIX em outros contextos, que envolvam diferentes organizações, naturezas de projeto, objetivos de negócio, linguagens, plataformas e paradigmas de desenvolvimento. A prova de conceito deste trabalho endereçou projetos desenvolvidos com C\\# (.NET), ma linguagem orientada à objetos estaticamente tipada, a semelhança de C++, Java e Object Pascal (Delphi). Recomenda-se a experimentação do EARLY-FIX em outras linguagens estaticamente tipadas, e também em linguagens OO dinâmicas, como Python e Ruby, principalmente devido às particularidades das mesmas em relação a meta-programação e ao \\textit{design} dinâmico.O \\textit{framework} EARLY-FIX foi elaborado para suportar sua extensão, através da inclusão de novos Métodos de Calibração e Modelos de Indicadores. Recomenda-se a experimentação de outras técnicas preditivas, baseadas em estatística ou aprendizado de máquina.Para evitar desvios nos modelos preditivos, recomenda-se a configuração do sistema de Controle de Versão com restrições que impeçam o \\textit{commit} de modificações do código sem associação com um item de trabalho (funcionalidade ou defeito), de forma a garantir a rastreabilidade necessária para predição de defeitos.Em futuras implementações do MC-PV, recomenda-se analisar se a prioridade do modelos é a predição ou a compreensão dos fatores que influenciam na manutenção corretiva. Se o objetivo for de compreensão, devem ser inseridas no modelo apenas variáveis significantes e idealmente não correlacionadas, o que pode diminuir de forma representativa a acurácia da predição. Segundo \\cite{Neter1996}, o fato de os modelos incluírem variáveis correlacionadas entre sí não afeta a capacidade de se obter uma predição satisfatória no ajuste dos modelos e predição de novas observações.Neste trabalho, apresentou-se como recomendação o uso das informações obtidas para direcionar atividades de qualidade como inspeção, refatoração e testes. Uma proposta de extensão do EARLY-FIX consiste na criação de modelos de apoio à tomada de decisão, que utilizem critérios para recomendar ações visando minimizar o impacto e o risco de manutenções corretivas futuras.
Sugere-se estender o EARLY-FIX com modelos que considerem as medições das classes a cada entrega de iteração, utilizando análise temporal para avaliar a tendência de defeitos para as próximas iterações.Outra sugestão, consiste na utilização da predição de volume, propiciada pelos modelos gerados pelo MC-PV, como base para a construção de modelos de estimativa de esforço, custo e risco de manutenção corretiva de software \\cite{Ware2007}. Segundo \\cite{Ware2007}, o volume de modificações, em termos de linhas de código (\\textit{LOC}), encontra-se relacionado a dificuldade e a intensidade de manutenção e pode ser utilizado como uma medida indireta de esforço de manutenção (\\cite{Jorgensen1995} e \\cite{Yu2006}).Um estudo de caso que demonstre a utilização do EARLY-FIX durante projetos em desenvolvimento caracteriza uma sugestão para trabalhos futuros. Para tal, pode-se atrelar execução automatizada do EARLY-FIX a processos de agendamento de tarefas, dentre os quais os servidores de Integração Contínua apresentam-se bastante adequados. Uma análise dos benefícios obtidos através de ações de mitigação de riscos, baseadas nas informações produzidas pelo EARLY-FIX, também apresenta uma oportunidade de contribuição.
Destes, os 4 trabalhos listados abaixo, em ordem cronológica, possuem forte interseção com o tema da dissertação. O artigo 1 se refere a um processo de ETL para consolidação de métricas de processo em um DW para apoio a decisão técnico e gerencial. O artigo 2 apresenta um processo de medição de produto de software utilizando técnicas de análise estática de código, atrelado à técnica de Integração Contínua, visando extração automatizada de métricas. O artigo 3 apresenta o método METACOM, concebido e implementado, para extração de métricas de produto à partir de repositórios de sistema de controle de versão e de histórico de manutenção, de forma a propiciar uma base para a realização de correlações entre métricas de produto e de volume de manutenção. O artigo 4 utiliza a abordagem de análise temporal para avaliar como métricas de sistemas OO relacionadas a tamanho, acoplamento e complexidade evoluem ao longo do ciclo de vida de um produto de software.