0
EARLY-FIXUm Framework para Predição de Manutenção Corretiva     de Software utilizando Métricas de Produto             Gab...
Agenda1. Introdução2. Qualidade, Manutenção e Medição de Software3. Predição de Manutenção Corretiva4. EARLY-FIX5. Prova d...
1.1 Contextualização e Motivação          Manutenção de Software>50%      do esforço                                   (Ke...
1.1 Contextualização e Motivação          Manutenção de Software                     >50%     dos profissionais           ...
1.1 Contextualização e Motivação          Manutenção de Software      entre 40 e 90%                         dos custos   ...
1.1 Contextualização e MotivaçãoAumento do ciclo de vida do software                                 (Ware, 2007)         ...
1.1 Contextualização e Motivação         Desafios para academia e           indústria de software                         ...
1.1 Contextualização e Motivação             Tipos de Manutenção                             21%Adaptativa                ...
1.1 Contextualização e Motivação      Características de                                   Esforço e Assertividade da   Qu...
1.2 ObjetivoInvestigação, concepção, implementação everificação de um arcabouço (framework)para a Predição de Manutenção C...
1.3 Requisitos da pesquisa• Um levantamento bibliográfico• Uma investigação sobre trabalhos relacionados• A concepção e a ...
2.1 Processos Tradicionais de Desenvolvimento                                            (Royce, 1970)                    ...
2.2 Processos Iterativos de Desenvolvimento RUP       FDD       Scrum Open UP       XP                             13
2.3 Qualidade de Produto de Software  ISO/IEC 25000:2005 - Software Quality Requirements and Evaluation (SQuaRE)          ...
2.4 Métricas de Qualidade Interna de Software                  Métricas de Produto OO Tamanho            Complexidade     ...
2.4 Técnicas de Garantia de Qualidade Inspeções                                        Testes                             ...
2.5 Custos de Correção de Defeitos após Implantação10x      maiores do      que na fase de         construção         (McC...
3.1 Predição de Manutenção Corretiva                 Benefícios• Suporte   ao   planejamento   e   execução   das  ativida...
3.1 Predição de Manutenção Corretiva                              Trabalhos relacionados                                  ...
3.2 Predição de Defeitos      Algumas empresas que utilizam                                (Nagappan, 2005)               ...
3.2 Predição de Defeitos      Técnicas de Predição de Defeitos mais utilizadas em                  artigos entre 2005 e 20...
4.1 EARLY-FIXFramework paraPredição deManutenção Corretiva                       22
4.2 Modelo Conceitual de Indicadores de Volume (MC-IV)     Baseado no paradigma Goal-Question-Indicator-Measure (GQIM)   23
4.3 Modelo de Indicadores de Predição de Volume (MI-PV)                                                    24
4.4 Desafios de Predição em Projetos Iterativos                                                  25
4.4 Modelo de Rastreabilidade                                26
4.4 Método de Rastreabilidade entre Produto de Software.   e Histórico de Manutenções (MR-PHM)                            ...
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...
4.7 Método de Medição de Histórico de ManutençõesCorretivas (MM-HMC)Para cada arquivo de código-fonte (módulo de software)...
4.8 Método de Medições Consolidadas (MM-C) Para cada arquivo de código-fonte (módulo de software) do sistema        1 - Id...
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 so...
4.10 Método de Detecção de Módulos Propensos àmanutenção corretiva (MD-MP) 1 - Definir o indicador de manutenção corretiva...
5.1 Projetos participantes no survey                                       33
5.2 Métricas Utilizadas       Métricas de Produto *       • Tamanho       • Complexidade       • Acoplamento              ...
5.3 Implementação dos Métodos de Medição                                           35
5.4 Implementação do Método de Medições Consolidadas (MM-C)                Estrutura da tabela consolidada de medidas     ...
5.5 Análise Exploratória das Medidas                   Histograma das variáveis dependentes                               ...
5.6 MC-PV - Técnicas de Regressão implementadas           1   Regressão Linear Multivariada (MLR)               2   Regres...
5.6 MC-PV - Comparação dos Modelos de Defeitos                                      Comparação dos coeficientes           ...
5.7 MC-PV - Comparação dos Modelos de Modificação Corretiva                                      Comparação dos coeficient...
5.8 Diagramas de Dispersão – Observado x Estimado                                                    41
5.9 MD-MP - Estimativa de Defeitos                                     42
5.10 MD-MP - Estimativa de Modificações Corretivas                                                     43
5.11 Limitações da Prova de Conceito (1/2)• Projetos investigados:    – Contexto semelhante    – Defeitos não associados à...
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 Backwar...
7. Conclusão• O framework EARLY-FIX concebido resultou da investigação e da  elaboração de modelos, métodos e técnicas.• O...
7.1 Conclusões Específicas (1/5)O framework EARLY-FIX foi implementado:   • Em 2 projetos iterativos, em fase de manutençã...
7.1 Conclusões Específicas   (2/5)A partir de uma análise estatística exploratória verificou-se:   • A correteza das medid...
7.1 Conclusões Específicas (3/5)O Método de Calibração de Predição de Volume (MC-PV) foiimplementado com 5 técnicas de reg...
7.1 Conclusões Específicas (4/5)Na verificação do MC-PV:• Comparou-se os modelos preditivos obtidos com os coeficientes  R...
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):...
7.2 Considerações Gerais• Relacionamentos entre métricas de produto de software  (especialmente   de     tamanho,    compl...
7.3 Principais Contribuições                               EARLY-FIX                                           53
7.3 Contribuições Adicionais1. Implementação e verificação do EARLY-FIX em uma prova de   conceito em 2 projetos de softwa...
7. 4 Recomendações•   Implementação do EARLY-FIX em outros contextos•   Extensão do framework EARLY-FIX com novos Métodos ...
7.5 Sugestões de Trabalhos Futuros•    Construção de modelos baseados em métricas de produto, para     estimativa de esfor...
7.6 Artigos publicados relacionados com esta pesquisa1. CARVALHO, H. P. B. ; BATTAGLIA, Danilo ; MONTINI, Denis Ávila ; MO...
Upcoming SlideShare
Loading in...5
×

EARLY-FIX: Um Framework para Predição de Manutenção Corretiva de Software utilizando Métricas de Produto

2,652

Published on

Dissertação de mestrado de Gabriel de Souza Pereira Moreira, defendida e aprovada na Pós-Graduação do Instituto Tecnológico de Aeronáutica (ITA) em 14/12/2012.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,652
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • Transcript of "EARLY-FIX: Um Framework para Predição de Manutenção Corretiva de Software utilizando Métricas de Produto"

    1. 1. EARLY-FIXUm 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. 2. Agenda1. Introdução2. Qualidade, Manutenção e Medição de Software3. Predição de Manutenção Corretiva4. EARLY-FIX5. Prova de Conceito6. Conclusão 2
    3. 3. 1.1 Contextualização e Motivação Manutenção de Software>50% do esforço (Kemerer et. Al, 1999) 3
    4. 4. 1.1 Contextualização e Motivação Manutenção de Software >50% dos profissionais (Jones, 2007) 4
    5. 5. 1.1 Contextualização e Motivação Manutenção de Software entre 40 e 90% dos custos (Bennet, 2002) 5
    6. 6. 1.1 Contextualização e MotivaçãoAumento 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. 7. 1.1 Contextualização e Motivação Desafios para academia e indústria de software (Boehm, 2010) 7
    8. 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. 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. 10. 1.2 ObjetivoInvestigação, concepção, implementação everificação de um arcabouço (framework)para a Predição de Manutenção Corretivabaseada em Métricas de Produto deSoftware, envolvendo modelos, métodos,técnicas e ferramentas, a fim de fornecerinformações que possam embasar decisõestécnicas e gerenciais durante um projeto para aredução de esforços, custos e riscos emfuturas manutenções corretivas. 10
    11. 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
    12. 12. 2.1 Processos Tradicionais de Desenvolvimento (Royce, 1970) 12
    13. 13. 2.2 Processos Iterativos de Desenvolvimento RUP FDD Scrum Open UP XP 13
    14. 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. 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
    16. 16. 2.4 Técnicas de Garantia de Qualidade Inspeções Testes 16
    17. 17. 2.5 Custos de Correção de Defeitos após Implantação10x 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. 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. 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óricoPrediçã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. 20. 3.2 Predição de Defeitos Algumas empresas que utilizam (Nagappan, 2005) 20
    21. 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
    22. 22. 4.1 EARLY-FIXFramework paraPredição deManutenção Corretiva 22
    23. 23. 4.2 Modelo Conceitual de Indicadores de Volume (MC-IV) Baseado no paradigma Goal-Question-Indicator-Measure (GQIM) 23
    24. 24. 4.3 Modelo de Indicadores de Predição de Volume (MI-PV) 24
    25. 25. 4.4 Desafios de Predição em Projetos Iterativos 25
    26. 26. 4.4 Modelo de Rastreabilidade 26
    27. 27. 4.4 Método de Rastreabilidade entre Produto de Software. e Histórico de Manutenções (MR-PHM) 27
    28. 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. 29. 4.7 Método de Medição de Histórico de ManutençõesCorretivas (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. 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. 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 entrega2 - Definir a variável dependente para construção do modelo (Quantidade de Defeitos ou deModificaçõ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 dependentes4 - Definir o método de seleção de variáveis5 - Calibrar modelos de predição utilizando a técnica de regressão e o método de seleção de variáveisselecionado6 - Selecionar o modelo cujas predições melhor se aproximem dos valores observados na variáveldependente, utilizando uma medida estatística7 - Armazenar os coeficientes do modelo preditivo selecionado e associar ao indicador correspondente8 - Aplicar a função do modelo preditivo selecionado para calcular o valor dos indicadores de volume demanutenção corretiva 31
    32. 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
    33. 33. 5.1 Projetos participantes no survey 33
    34. 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
    35. 35. 5.3 Implementação dos Métodos de Medição 35
    36. 36. 5.4 Implementação do Método de Medições Consolidadas (MM-C) Estrutura da tabela consolidada de medidas 36
    37. 37. 5.5 Análise Exploratória das Medidas Histograma das variáveis dependentes 37
    38. 38. 5.6 MC-PV - Técnicas de Regressão implementadas 1 Regressão Linear Multivariada (MLR) 2 Regressão de Poisson (PR) 3 Regressão de Poisson Inflada de Zeros (ZIP) 4 Regressão Binomial Negativa (NB) 5 Regressão Binomial Negativa Inflada de Zeros (ZINB) 38
    39. 39. 5.6 MC-PV - Comparação dos Modelos de Defeitos Comparação dos coeficientes R2 de McFadden Comparação dos coeficientes R2 39
    40. 40. 5.7 MC-PV - Comparação dos Modelos de Modificação Corretiva Comparação dos coeficientes R2 de McFadden Comparação dos coeficientes R2 40
    41. 41. 5.8 Diagramas de Dispersão – Observado x Estimado 41
    42. 42. 5.9 MD-MP - Estimativa de Defeitos 42
    43. 43. 5.10 MD-MP - Estimativa de Modificações Corretivas 43
    44. 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. 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. 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. 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. 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. 49. 7.1 Conclusões Específicas (3/5)O Método de Calibração de Predição de Volume (MC-PV) foiimplementado 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. 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. 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. 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
    53. 53. 7.3 Principais Contribuições EARLY-FIX 53
    54. 54. 7.3 Contribuições Adicionais1. Implementação e verificação do EARLY-FIX em uma prova de conceito em 2 projetos de software para a indústria2. 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. 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. 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. 57. 7.6 Artigos publicados relacionados com esta pesquisa1. 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, 20102. 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, 20103. 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, 20114. 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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×