Resumo.

Bases de dados de verso e bug contm uma riqueza de informaes sobre falhas de software como ocorreu a falha, que foi afetada, e como foi resolvido. Tais informaes defeito pode ser automaticamente extrado de arquivos de software, e isso freqentemente acontece que alguns mdulos so muito mais defeitos propensos do que outros.Comoessasdiferenasvmaser?Nspesquisamoscomopropriedadesdocdigo, como (a) a complexidade do cdigo, (b) o domnio do problema, (c) o passadohistrico, ou (d) a qualidade do processo afetam defeitos de software, e como a suacorrelao com defeitosnopassado podeserusadoparapreverofuturosoftwaredepropriedades ondeosdefeitosso,comocorrigilos,bemcomoocustoassociado. 4.1Introduo Suponha que voc o gerente de um projeto de software de grande porte. Seu produto est quase pronto para ser lanado, onde significa "quase prontas" que voc suspeita que um nmero de defeitos permanecem. Para encontraressesdefeitos,vocpodegastaralguns recursos para a garantia de qualidade. Umavezqueesses recursossolimitados,voc quer gastlos da maneira mais eficaz, obtendoa melhor qualidade e o menor risco de fracasso. Portanto, voc quer gastar os recursos de garantia de mais qualidade nesses mdulos que mais precisa os mdulos que tm o maior risco de produzir fracassos. Alocao derecursosdegarantiadequalidadecomsabedoriaumatarefaarriscada.Se algum mdulo nodefeituoso testado por meses e meses, este um desperdcio de recursos. Se um mdulo com defeito no suficientemente testado, um defeito pode escapar para ocampo, causandoumafalhapotencialedanossubsequentes.Portanto,a identificao de mdulosdefeitopropensasumatarefacrucialparaagesto.Duranteo tempo de vida de um projeto, os desenvolvedores lembrar falhas, bem comoos sucessos, e esta experincia dizlhes que os mdulos em um sistema so mais freqentemente associada com problemas. Um bom gerente vai explorar essa experincia e alocar recursos de forma adequada. Infelizmente,a memria humana limitada, seletiva, e s vezes imprecisa. Portanto, ele podeser tilpara complementlo com os resultados de reais fatos, fatos sobre defeitos de software como os encontrados aps o lanamento. Na maioria das equipes de qualidadecom reconhecimento, oacesso a estes fatos no requer mais do que uma consulta de banco de dados simples. Isto assim porque os bancos de dados de bugs coletar todos os problemas relatados T. Mens,S. Demeyer (eds.), EvolutionSoftware. Visualizao dos dados de bugs do Eclipse de Michael Ogawa [401], inspirado por Martin Wattenberg "Mapa do mercado "[536]. Cada retngulo representa um pacote, a mais brilhante do retngulo, mais defeitos pslanamento que tem cerca de um produto de software. Para um sistema que j tem uma grande comunidade de usurios, bases de dados de bugs so fundamentais para o processo de desenvolvimento: novos bugs so inseridos no sistema, questes no resolvidas so controladas, e as tarefas so atribudas a desenvolvedoresindividuais.

No entanto, como uma base de dados erro cresce, ele podetambm ser utilizado para aprenderosmdulosquesopropensosadefeitosefalhas.Istoassimporque,comoos problemas so resolvidos, aplica as correes de mdulosindividuaiseportanto,podese,na verdade, calcular a quantidade de defeitos ou falhas relatadas () algum mdulo est associado. (Como estabeleceresses mapeamentos entre relatrios de bugs,correes elocaisdescritonoCaptulo3destelivro.) Figura 4.1 visualiza dados de defeitonosmdulosdoambientedeprogramaoEclipse.Como a figura mostra, a distribuio de defeitos nos mdulos muitoirregular.Porexemplo,os componentes do compilador em Eclipse tm mostrado 45 vezes como muitosdefeitos como componentes de interface de usurio [455]. Essa distribuio desigual no de todo incomum, a lei de Pareto [160, p. 132], por exemplo, j em 1975, indicou que aproximadamente 80% dos defeitosso encontradosem20%dosmdulos.Aindaassim, estadistribuiodesigualchamaparaanossaprimeiraquestodepesquisa: Por que alguns mdulos defeito mais propensas do que outras? Responder a esta pergunta ajuda a compreender a natureza dosdefeitos,comeandocomossintomas,e, em seguida, seguindo a cadeia de causa e efeito de volta para a raiz de causa e vai ajudaraevitardefeitosnofuturo.

4PrevendoerrosdaHistria Infelizmente, no momento, no temos nenhuma resposta universal para esta pergunta. Parece que cada projeto tem seus prprios fatores individuais que fazem mdulos especficos propensos a defeitos e outros improvveis falhar. No entanto, podemos pelo menos tentar capturar essas propriedades para um projecto especfico exemplo, atravs da anlise e resumindo os sintomas comuns de mdulos defeito propensas. Voltando nossa definio original, sabendo que essas propriedades comuns tambm ir ajudar na alocao de recursos de garantia de qualidade. Isso ir atender a segunda, maisoportunista,masnomenosimportantepergunta: Podemosprevercomodefeitopropensoaumcomponenteser? primeira vista, esta pergunta pode parecer absurda. Ser que ns no apenas discutir como medir defeito propenso no passado? Infelizmente, o nmero de defeitos no passadopodenoserumbomindicadordofuturo: Software evolui, com refatoraes substanciais e adies esto sendo feitaso tempo todo.Comotempo,esteinvalidaasmediesanterioressobredefeitos.

 Os defeitos medimos dahistriaspodesermapeadoparacomponentes,porqueeles foram corrigidos. Dado que seconsideraqueosdefeitosocorremapsalibertao,por definio, qualquer medio de componentes de defeito propensas aplicase a uma versojobsoleta. Por estas razes, necessrio conceber com mtodos de previso que pode ser aplicada a novos, bem como componentes, evoluiu previses que dependem invariantes em pessoas, processoouestruturaquepermitempreverdefeitos,emborao prprio cdigo mudou. Na prxima seo, discutimos como encontrar alguns desses invariantes,ecomoelespodemafetaraprobabilidadededefeitos. 4.2OquefazumMduloDefeito Se as necessidades de software para ser corrigido, ele precisa ser corrigido, porque no satisfaz a exigncia. Isto significa que entre o requisito inicial e a implantao real do sistema de software, algum erro foi cometido. Este errose manifesta como um erro em algum artefato de desenvolvimento, seja ele requisitos, especificao, ou um documento de design. Em ltima anlise, o cdigo de fonte que mais importante, uma vez que a realizao dosistemadesoftwareerrosnocdigodefontesochamadosdefeitos.Se um erro em alguma fase anterior no setorne umdefeito, temos a sorte e, se ele se torna umdefeito,elepodecausarumafalhaeprecisasercorrigido. A probabilidade de falha de algum mdulo depende, assim, a sua histria,no s a sua histria de cdigo, mas toda a histria das atividades que levaram sua criao e manuteno. Como o cdigo evolui, esta histria anterioraindapermaneceinalterada,ea histriapodeser aplicadoaoutrosmdulosbem.Portanto,quandosetentapreveroerrode propenso de mdulos, devemos procurar invariantes em sua histria, e como esses invariantes pode se manifestam em mdulos. Neste captulo, discutiremos o seguintes invariantes: Complexidade. Em geral, assumese que a probabilidade deerraremalgumartefatoaumenta com: 1.onmerodedetalhes,e 2.aextensodaformacomoestesdetalhesinteragemeinterferemunscomosoutros. Isto geralmente conhecida como a complexidade, e existem muitas maneirascomplexidade manifestase nocdigo. Maisespecificamente, as mtricas de complexidade tentarmedira complexidade do cdigo, e, portanto, pode ser til para verificar se possvel prever defeitopropensobaseadonasmtricasdecomplexidade.

IssodiscutidonaSeo4.3.

Domniodoproblema. Como dito inicialmente, correes de software vir a ser porque os requisitos esto insatisfeitos. Isto implica que o mais provvel violar a exigncia, maior as chances de cometer um erro. Claro que,umgrandenmeroderesultadosdeinterfernciarequisitosdeum problema de maior complexidade e, portanto, devem manifestarse em cdigos complexos, conforme descrito acima. No entanto, ns assumimos que domnios de problemas especficos implica o seu prprio conjunto de requisitos. Portanto, deve ser capaz de preverdefeitopropensobaseadanodomniosozinho. Comosedeterminaodomniodoproblema? Ao examinar os mdulos outra mdulo interage com, como mostrado na Seo 4.4. Evolution. Os requisitospodemserinsatisfeitoporumarazomuitosimples: eles podem mudar com freqncia. Requisitos modificadosresultadoemmudado decdigoe,portanto,o cdigoquealteradocomfreqnciaindicafrequentementeamudanaderequisitos. O mesmo se aplica para as necessidades imprecisas ou exigncias que no so bem compreendidos, onde abordagens de tentativa e erro tambm pode causar correes freqentes. Finalmente, uma vez que mudanas podem introduzir novos defeitos [160], a taxa de variao elevada implica uma maior probabilidade de defeitos. Baseandose na taxadevariaodepreverdefeitosdiscutidonaSeo4.5. Processo. Todo defeito que escapa aocampoimplicaumafalhadegarantiadequalidade,odefeito simplesmentedeveriatersidocapturadoduranteaverificao,controlo,oureviso. Um bom processo de software pode compensar muitos dos riscos descritos acima, e, portanto, a qualidade do processo de desenvolvimento, tambm deve ser considerado quando se trata de prever defeitos. Discutimos estas questes em aberto na Seo 4.6. O papel destes invariantes no desenvolvimento de software temsidoanalisadaantes,eum grande corpo de conhecimento disponvel que relacione a complexidade, o domnio do problema, ou dados para defeitos de evoluo. O que vemos hoje, no entanto, a automao dessas abordagens. Por ter bases de dados de bugs e mudanas disponveis para anlise automatizada, podemos construir ferramentas que se relacionam automaticamente defeitos de possveis causas. Tais ferramentas permitem produtos e abordagensespecficosdoprojeto,oquepodesermuitomaisvaliosodoqueogeral (e, portanto, vago) recomendaes encontradas em livros de engenharia de software. Nossos resultados, discutidos nas sees seguintes, todos destacam a necessidade de tais abordagensgoaloriented. Relacionado a isso est a noo de confiabilidade do software. Confiabilidade de

softwaredefinidocomoaprobabilidadede queosoftwareirfuncionarsemfalhassob condies especficas e por um determinado perodo de tempo [388]. Uma srie de softwares de confiabilidade modelos esto disponveis. Eles vo desde o modelo simples [392] para modelos mais sofisticados, utilizando cobertura hiper geomtrica [248]ecadeiasdeMarkov[540]. 4.3Mtricas A crena comum queo cdigo maiscomplexo,maisdefeitosqueeletem.Masisso realmente verdade?Para investigarestahiptese,em primeirolugardeveviracimacomuma medida de complexidade, ou, em outras palavras, a complexidade mtrica. Uma mtrica definida como a medida quantitativa do grau em que um sistema, o componente ou processo possui um determinado atributo, [238], o nome deriva da palavra grega metron ( o), significando "medida". Aplicado ao software, uma mtrica tornase um software de mtrica. Mtricas de software desempenham umpapel essencial na compreenso e controle do processo de engenharia de software em geral. Infelizmente, as mtricas podem ser facilmente mal interpretada levando a tomada de decises pobres. Nesta seo, investigamos as relaes entre mtricas e de qualidade, em defeitos particulares: fazer as mtricasdecomplexidadecorrelacionarcomdensidadededefeitos? 4.3.1Background Comeamos esta seo,resumindorapidamentealgumasdasmtricasdecomplexidademais comumente usados em engenharia de software na Tabela 4.1. Estas mtricas podem ser extrados a partir das informaes de cdigo fonte de projectos. Pesquisa de engenharia de software em mtricas examinou umaamplavariedadedetemasrelacionadoscomaqualidade, produtividade, comunicao, aspectos sociais, etc brevemente estudos de pesquisa que investigam a relao entre mtricas e qualidade de software. Estudos tm sido realizados sobre a distribuio de falhas durante o desenvolvimento e sua relao com indicadorescomootamanho,asmtricasdecomplexidade,etc[172]. De uma perspectiva de mtricas design, tem havido estudos envolvendo a Chidamber / Kemerer (CK) Sute mtrica [111]. Essas mtricas podem ser um indicador til cedo interno da qualidade do produto externamente visvel [39,479]. OCK mtrica conjunto composto por seis indicadores (principalmente concebidos como medidas deprojetoorientado aobjetos): mtodosponderadosporclasse(WMC), acoplamentoentreosobjetos(CBO), profundidadedeherana(DIT), nmerodecrianas(NOC), respostaparaumaclasse(RFC),e faltadecoesoentreosmtodos(LCOM). As mtricas de CK tambmforaminvestigadosnocontextodefalhadepropenso.Basili

et ai. [39] estudaram apropenso a falhasemprogramasqueutilizamoitoprojetosdosalunos. Eles observaram que o WMC, CBO, DIT, NOC e RFC mtricasforam 74T. Zimmermann, N. Nagappan,A.Zeller. TabelaLines4.1.Metricdecdigo As variveis globais, a complexidade ciclomtica, Leia acoplamento, Escrever acoplamento, acoplamento endereo, fanin, fanout, mtodos Ponderadas porturma, a profundidade da herana, Classe acoplamento, Nmero de subclasses mtricas de complexidade comumente usados , a descrio donmerode no comentou linhas de cdigo do nmero de variveis globais em um mdulo a complexidade Cyclomatic mtrica [479] mede o nmero de caminhos linearmente independentes, atravs de uma unidade de programaonmerodevariveis globaislidosporumafuno.(Afuno,portanto, acoplada varivel global atravs da operao de leitura) O nmero de variveis globais escritas por uma funo. (A funo , portanto, acoplada varivel global atravsdaoperao degravao) O nmero de variveis globais cujo endereo tomado por uma funo e no leitura / gravao de acoplamento. (A funo est ligada varivel global dado que converte o endereo da varivel) O nmero de outras funes de chamada de uma dada funo num mdulo O nmero de outras funes a ser chamados a partir de uma dada funo num mdulo O nmero de mtodos em uma classe, incluindo os mtodos pblicos, privados e protegidos para uma determinada classe a profundidade mxima de herana de classe acoplamento com outras classes atravs de (a) variveis de membro de classe, (b) os parmetros da funo, (c) as classes definidas localmente em membro da classe corpos de funo. (d) Acoplamento por meio de classes base imediatas. (e) atravs de Coupling retorno digite o nmero de classes que herdam diretamente de uma determinada classe pai em um mdulo relacionado com defeitos, enquanto o LCOM mtrica no foi correlacionada comdefeitos. Alm disso,Briandetai.[82]realizaramumestudodecasoindustrialeobservadooCBO,RFC emtricasLCOMaserassociadocomafalhapropensodeumaclasse. Mtricas Estrutura levar em contaas interaes entre mdulos em um produto ou sistemae quantificartais interaes.AmtricadefluxodeinformaodefinidaporHenryeKafura[230], usa se ventilador (o nmero de mdulos que requerem um determinado mdulo) e do ventilador de sada (o nmero de mdulos que so chamadas por um determinado mdulo) para calcular uma complexidade mtrica, C p = (fanin fanout) 2. Componentes com um grande fanin (Fanin/Fanout Fanin mede o nmero de funes que chama uma determinada funo. Fanout mede o nmero de funes que uma determinadafuno chama.) e fanout grande pode indicar m concepo. Esses mdulos tm de ser decompostoscorretamente. 4.3.2EstudodeCaso:CincoProjetosdoMicrosoft

Juntamente com Thomas Ball foi realizado um estudo em grande escala na Microsoft para investigar a relao entre as mtricas de complexidade e defeitos [390].Foramabordadas asseguintesquestes: 1.Nomtricascorrelacionarcomdensidadededefeitos? 2. No mtricascorrelacionaruniversalmentecomdensidadededefeitos,ouseja, entre osprojetos? 3.Podemospreverdensidadededefeitoscommodelosderegresso? 4. Podemos transferir (ou seja, a reutilizao) de modelos de regresso entre os projetos? Para o nosso estudo, foramcoletadas as mtricas de complexidadede cdigo e de dados de defeitospslanamentoparacincocomponentesdosistemaoperacionalWindows: omduloderenderizaoHTMLdoInternetExplorer6(IE6) ocarregamentodeaplicativosparaoInternetInformationServices(IIS) Processo de Mensagens Component uma tecnologia da Microsoft que permite que os aplicativos executados em horrios diferentes se comuniquem atravs de redes e sistemas heterogneosquepodemestartemporariamenteoffline. Microsoft DirectX a tecnologia do Windows que permite maior desempenho em grficos e somquandoosusuriosestojogandojogosouassistiraumvdeoemseuPC. MicrosoftNetMeeting,umcomponenteparavozetrocademensagensentrelocaisdiferentes. Para protegerinformaesconfidenciais,temosannimososcomponentesesereferemaeles como projetos A, B, C, D eE. Em nosso estudo, observouse correlaes significativasentre as mtricas de complexidade (tanto orientado a objetos (OO) e mtricas no OO) e defeitos ps lanamento. As mtricas que tinhamosmaiorescorrelaesesto listadasnaTabela4.2. A parte interessante deste resultado que entre os projetos, diferentes mtricas de complexidade significativamente correlacionada com defeitos ps anamento.Isso indica que nenhuma das mtricas que pesquisou se qualificaria como preditor universal, mesmo em nossocontextofechadodeapenascomponentesdosistemaoperacionalWindows. Quando no h mtrica universal, podemos construir uma combinandomtricas existentes ? Ns tentamos atravs da construo de modelos de regresso [282] utilizando mtricas de complexidade. A fim de evitar a intercorrelaes entreasmtricas,aplicadacapitalProjecto componente

Tabela 4.2. Mtricas com altas correlaes, mtricas correlacionadas, nmero de classes e cinco derivaes, quase todas as mtricas, todos exceto profundidade de herana, apenas linhasdecdigo,nmerodefunes,nmerodearcos,McCabecomplexidade Tabela4.3.Transferindopreditoresentreprojetos

anlise [246] pela primeira vez. Para os nossos modelos de regresso, foram utilizados os componentes principais como variveis independentes. Como resultado deste experimento, obtevese para cada projeto a previso de que era capaz de prever com preciso os componentesdefeitopropensasdoprojeto[390]. Em seguida, foram aplicados esses preditores entre projetos. Os resultados na Tabela 4.3 mostra que na maioria dos casos, os preditores no poderia ser transferido. As nicas excees so entre os projetos B e C e entre C e E, onde preditores so intercambiveis. Ao comparar esses projetos, observamos que eles tinham processos de desenvolvimento semelhantes. Uma consequncia central deste resultado seria a de reutilizar nicos preditores que foram gerados em ambientes semelhantes. Dito de outra forma: Sempreavaliarcomahistriaantes de usar uma mtrica para tomardecises. Ou ainda menor: Nunca confiar cegamenteuma mtrica. Pontoschave mtricasdecomplexidadedefatosecorrelacionamcomdefeitos. Nohmtricauniversalenenhummodelodeprevisouniversal. Antes de confiar em uma mtrica para fazer previses, avalilo com uma verdadeira histriadedefeito. 4.4ProblemadeDomnio As chances de cometer errosdependemfortemente do nmero e da complexidadedos requisitos de que algum pedao de cdigo tem de satisfazer. Como discutido na Seco 4.3, um grande nmero de requisitos de interferncia pode resultar em uma maior complexidadedo cdigo.No entanto, este podenosernecessariamenteassim: umalgoritmo pode ter uma estrutura muito simples, mas pode ainda ser difcil de obter direito. Portanto, esperamos que os requisitos especficos, ou, mais geralmente, os domnios de problema especfico, para afetar o modo como defectprone cdigo do programa vai ser: Comoqueo problemadedomnioimpactoprobabilidadededefeito? 4PrevendoerrosdaHistria Tabela 4.4. Importaes bons e maus (pacotes) no Eclipse 2.0 (tomadas a partir de [455], ACM,2006)PacotesimportadosemumcomponenteC88

4.4.1ImportaeseDefeitos Para demonstrar os efeitosdo domnio de problemas sobre aprobabilidadededefeitos,vamos voltar paraadistribuiodedefeitosdeEclipse,comomostrado nafigura4.1.Vamossuporque queremos estender o cdigo existente por duas novas componentesdediferentes domniosde problemas: interfaces com o usurio e internos do compilador. Que componente mais

provvelquesejapropensadefeito? Adicionando uma nova caixa de dilogo para a GUI tem exigncias bastantesimples,na maioria dos casos, voc s tem que estender uma determinada classe. No entanto, a montagem dos elementos da caixa de dilogo leva muito complicado cdigo adicional. Em contraste, usandoum parser para construir uma rvore de sintaxe abstratarequerapenas algumas linhas decdigo, mas tem muitas exigncias bastante complexas, como escolher os parmetroscorretos.Assimqueodomniomaisprovvellevaadefeitos? No contexto da Eclipse, esta pergunta j foi respondida. Juntamente com Adrian Schrter, examinamos os componentes que so utilizados como uma expressoimplcitadodomniodo componente [455]. Ao criar um Eclipse plugin que funciona em arquivos Java, preciso importar classes JDT, se o plugin vem com uma interface de usurio, classes GUI so obrigatrios. Portanto, o que um componente importaes determina o seu domnio do problema. Uma vez que ningum sabe o que importado, podese relacionar novamente esses dados para densidades de defeitos medidos. A Tabela 4.4 mostra como o uso de pacotes especficos no Eclipse impacta probabilidade de defeitos. Um componente que utiliza internos do compilador tem uma chance de 86% de ter um defeito que precisa ser corrigido nos primeiros seis meses aps o lanamento. No entanto, um componentede interface de utilizador usando pacotes tem somente uma possibilidade de 15% de defeitos. Esta observao levanta a questo de saber se podemos prever defeito propenso usando apenas os nomes dos componentes importados? Em outras palavras: "Diga me oquevoc importar,eeuvoutedizerquantosdefeitosvocvaiter". 4.4.2EstudodeCaso:EclipseImports Podese realmenteprever a probabilidade dedefeitos,considerandoimportaessozinho?Ns construmos modelos estatsticos com a regresso linear, regresso de cumeeira, rvores de regresso, e as mquinas de vetores de suporte. Em particular, abordamos as seguintes perguntas:

Classificao. Podemospreverseumcomponentetemdefeitos? Ranking.

Podemos prever que os componentes tero a maioria dos defeitos? Para os nossos experimentos, utilizamos aleatria divide: sortearamse de um tero do plug ins do Eclipse verso 2.0 52 como nosso conjunto de treinamento, que usamos para construir nossos modelos. Ns validamos nossos modelos nas verses 2.0 e 2.1 do Eclipse. Ambas as vezes que usouo complemento do treinamento definido como o conjunto de validao. Geramos um totalde40divisesealeatriamdiadosresultadosparacalculartrsvalores: A preciso mede muitos dos componentes previsto como defeito propenso realmente ter sido demonstrado que tm defeitos.Aaltaprecisosignificaumabaixanumberof falsos positivos. O recall mede quantos dos componentes defeito propensas so realmente previu comotal.Aaltarecordaosignificaumbaixonmerodefalsosnegativos. A correlao de Spearman mede a fora e a direodarelaoentreaclassificaoprevista eobservada.Aaltacorrelaosignificaumpoderhighpredictive. Nesta seo, discutimos os resultados das mquinas de vetores de suporte [132] (que teve melhordesempenhoemnossaavaliao). Precisoerecall Para a validao define na verso 2.0 do Eclipse, as mquinas de vetores de suporte obtido uma preciso de0,67 (verTabela 4.5). Ou seja, dois em cada trscomponentesprevistos como defeito propenso foram observados a ter defeitos.Para umpalpitealeatrioemvez disso, a preciso seria a percentagem de pacotes defeito propensas, que apenasde0,37.O recall de 0,69 para a validao define na verso 2.0 indica que dois teros dos componentes defeito propensas observados foram de fato previsto como defeito propensa. Novamente, um palpitealeatrioproduzapenasumrecallde0,37. Na prtica, isso significa queasrelaesdeimportaofornecerum bomindicadorpara os componentes defeito propensas. Este um resultado importante, uma vez que as relaes entreos componentessotipicamentedefinidosnafasedeconcepo.Assim, os componentes defeito propensas podem ser identificados precocemente, e os designers podem facilmente explorar e avaliar alternativas de projeto em termos de riscodedefeitoprevisto.

4PrevendoerrosdaHistria Tabela 4.5. Prevendo defeito propenso de pacotesdeEclipsecomSupportVector Machinese relaesdeimportao(tiradade[455],ACM,2006)

RankingvsClassification Os baixos valores para o coeficiente de correlaodeSpearmannaTabela4.5indicamqueos rankings previstos correlacionarapenaspoucocomosrankingsobservados.Noentanto, os valores de preciso para o top 5% so mais elevados do que os valores globais. Isso significa que as chances de encontrar componentes defeito propensas a aumentar para componentesaltamenteclassificados. Na prtica, isso significa que a garantia da qualidade melhor gasto nesses componentes classificados como o mais propenso defeito. Por isso, uma boa idia para analisar as importaes e histria bug para estabelecer rankings apropriadas. Aplicao de modelos em verses Os resultados paraa validaoconjuntosdeEclipseverso 2.1 socomparveis aosdaverso2.0,poisotop5%e10%doranking,osvaloresdepreciso soaindamaiores.Issoindicaquenossosmodelossorobustosaolongodotempo. Para o nosso conjunto de dados, o que significa que podeseaprenderummodeloparauma verso e apliclo para uma verso mais recente sem perder o poder de previso. Em outras palavras, as importaes realmente atuar como invariantes, como discutido na Seo 4.2. 4.4.3EstudodeCaso:WindowsServer2003 Na Microsoft, ns repetimos o estudo de Schrter et al. [455] sobre os dados de defeito do Windows Server 2003. Em vez de relaes de importao, usamos as dependncias para descrever o domnio do problema entre os binrios 2252. Uma dependncia um relacionamentodirecionado entre dois pedaos decdigo,comoexpressesoumtodos.Para os nossos experimentos, utilizamos a ferramenta MaX [473] que rastreia informaes de dependncia no nvel da funo e olha para as chamadas, importao, exportao, RPC e acessos Registro. Mais uma vez, de 80 T. Zimmermann, N. Nagappan, A. Zeller o domnio do problema foi um preditor adequado para defeitos erealizadasubstancialmentemelhordoqueo acaso(preciso0,67,recordao0,69,correlaesdeSpearmanentre0,50e0,60). Alm da replicao do estudo anterior (e os seus resultados), tambm observado um efeito domin no Windows Server 2003. O efeito domin foi indicado em 1975 por Randell [430]: Dado um conjunto arbitrrio de processos de interao, cada umcom a sua prpria estrutura de recuperao privado, um nicoerroporpartedeapenasumprocessopodecausartodosos processos de utilizarse muitos ou mesmo todos os seus pontos de recuperao, atravs de umaespciedeefeitodedomindescontrolada. Aplicando o efeito domin sobre as dependncias,issosignificaria que os defeitos em um componente pode aumentar a probabilidade de defeitos em componentes dependentes. Figura 4.2 ilustra este fenmeno em um binrio B. defeito propenso Dos trs binrios quedependem diretamente B (distncia d = 1), dois tm defeitos, resultando emuma probabilidade de defeitos de 0,67. Quando seaumenta a distncia, por exemplo para d = 2, a partir dos quatro binrios dependendo B (indirectamente), apenas dois tm defeitos, assim,

diminui a probabilidade de 0,50. Em outras palavras, a extenso do efeito de domin diminui com a distncia assim como com as partes do domin reais. Na Figura 4.3 mostramos a distribuio da probabilidade de defeito, introduzido acima, quando o alvo da dependncia defeito propensa(d = 1). Ns tambm relatamresultadosparadependnciasindiretas(d=2,d =3).Quantomaioraprobabilidade,osbinriossomaisdependentesdedefeitosdebruos. Para protegerinformaes confidenciais, ns annimos do eixoy,querelataasfreqncias,o eixo x relativa maior probabilidade de defeito observado que era figura. 4.2. Exemplo de dominefeitodeumbinrioB4PrevendoerrosdaHistriaFIG.4.3. O efeito domin no Windows Server 2003 maior do que 0,50 e relatado como X. A probabilidade de X e a escala do eixo x constante para todos os grficos de barras. Ter o maior bar do lado esquerdo (a 0,00), significa que para a maioria dos binrios os binrios dependente no tinha defeitos, o maior bar do lado direito (em X), mostra que para a maioria dos binrios, seus binrios dependentes tinham defeitos tambm. Como a Figura 4.3 mostra, diretamente, dependendo binrios com defeitos, faz com que a maioria dos binrios de ter defeitos, tambm (d = 1). Este efeitodiminuiquandoadistncia(Daumenta atendnciaparaa esquerda). Em outras palavras, o efeito domin est presente na maioriados binrios defeito propensas no Windows Server 2003. Como a distncia d aumenta, o impacto do efeito de domin diminui. Esta tendncia demonstradapelodeslocamentodamedianada direitaparaa esquerdanoquerespeitaprobabilidadededefeitos. Pontoschave O conjunto de componentes utilizados um bom indicador para a propenso de defeitos. Odomniodoproblemaumindicadoradequadoparadefeitosfuturos. Defeito propenso provvel que se propagam atravs de software em um efeito domin.

4.5CdigoChurn Cdigo noesttica,ela evoluiaolongodo tempo paraatendersnovasexigncias.A forma de cdigo evoludo no passado pode ser utilizadoparaprever a sua evoluo no futuro. Em particular, existe uma noo frequentemente aceite que um cdigo que mudamuito de menor qualidade e, portanto, mais propensa a falha do que o cdigo inalterada. Como se mede a quantidade de mudana? Lehman e Belady [320] introduziu o conceito de variao de cdigo como sendo a taxa de crescimento do tamanho do software. Mas

medir as mudanas no tamanho do software no necessariamente capturar todas as mudanas que ocorreramduranteodesenvolvimentodesoftware,issoespecialmente verdadeiro se o software foire projetada.Maisgenericamente,aformaodocdigopode ser definida como uma medida da quantidade de mudanadocdigoocorrendodentrodeuma unidadedesoftwareaolongodotempo.[389].Aprincipalquestoabordamos nestaseo: O cdigochurnsecorrelacionamcomdefeitos? 4.5.1Background Vrios pesquisadores investigaram como a evoluo relacionase com defeitos.Ostrand et ai. [408] Informao uso do status de arquivo, como novos, alterados arquivos inalterados, juntamente com outras variveis explicativas, tais como linhas de cdigo, idade, etc falhas anteriores para prever o nmero de falhas em vrias verses de um sistema de software industrial. As previses feitas utilizando o modelo de regresso binomial eram de alta preciso parafalhasencontradasemestgiosprecoceemaistardededesenvolvimento. Munson et ai. [384] estudaram a KLOC 300 (mil linhas de cdigo) incorporado sistema em tempo real com 3.700mdulos programados em C. Cdigochurn mtricasforamencontrados para estar entre os mais altamente correlacionada com os relatrios de problemas. Graves et ai. [209] prev a incidncia de falhas utilizando histrico de alteraesde software. O modelo mais bem sucedido eles construram calculado o potencial de falha somandose as contribuies de mudanas para o mdulo, onde as mudanasgrandese/oucontribuir coma recentemaisapotencialfalha. 4.5.2EstudodeCaso:WindowsServer2003 Alm dos resultadosdainvestigaoacima,nsagoraresumiremdetalheosresultadosdeum estudo de caso realizado no Windows Server 2003 [389]. Analisamos o cdigo churn entre o lanamento do Windows Server 2003 e do lanamento do Windows Server2003ServicePack 1 (Windows Server 2003 SP1) para prever a densidade de defeitos no Windows Server 2003 SP1. Como discutido na Seco 4.5.1, existem diversas medidas que podem ser usadas para explicar a formaodo cdigo.Em nosso estudo,foramutilizadasasseguintesmedidaschurn [389]:

Total de LOC o nmero de linhas de no comentou linhas executveis dos arquivos que compemanovaversodeumbinrio. 4PrevendoerrosdaHistria Churned LOC a soma das linhas adicionadas e alteradas de cdigo entreuma verso de linhadebaseeumanovaversodosarquivosquecompemobinrio.

 LOC Excludos o nmero delinhas decdigoexcludosentreaversodelinhadebaseeda novaversodeumbinrio. Nmerodeficheiroonmerodearquivoscompiladosparacriarumbinrio. Semanas de churn o tempo acumulado que um arquivo foi aberto para edio apartir do sistemadecontroledeverso. Churn contagem onmero dealteraesfeitasnosarquivosquecompemumbinrioentre asduasverses(WindowsServer2003eWindowsServer2003SP1). Arquivosagitados o nmero dearquivos dentro do binrioque agitaram.Otamanhototalda base de cdigo analisados foi de cerca de 40 milhes de linhas de cdigo de binrios maisde 2000. Usando as mtricas acima, extrado a partir do sistema de controlo de verso, usamos uma abordagem relativa (como mostrado na Figura 4.4) para a construo de modelos de regresso estatsticos para prever a densidade de defeitos do sistema. A razo para as mtricas relativas que,numsistemaemdesenvolvimento,que altamentebenficoparausar umaabordagememrelaoquantificaodavariaodeumsistema. Umadiscussomaisdetalhadadoexperimentoestdisponvelem[389]. Usando tcnicas de diviso aleatria usamos o cdigo acima "relativa "churn medidas como variveis preditivas em nossos modelos estatsticos. Ns selecionamos dois teros dos binrios para construir nossosmodelos de previso estatstica (regresso, regresso logstica mltipla) para prever sistema densidade de defeitos em geral / falha propenso. Com base no nosso sta fig. 4.4. Relativa churn medidas (tomadas a partir de [389], ACM, 2005) T. Zimmermann,N.Nagappan,A.ZellerFIG.4.5. Lote de densidade real versus estimado defeito (extrado de [389], ACM, 2005) anlise estatstica fomos capazes de prever o sistema de densidade de defeitos/ falhas propenso a altos nveis de significncia estatstica. A figura 4.5, por exemplo, mostra os resultados de um dosexperimentosdivisoaleatriaparapreveradensidadededefeitosdosistemareal.

Pontoschave Quantomaisumcomponentemudou(batido),omaisprovvelterdefeitos. Cdigo batedeira medidas pode ser utilizado para prever os componentes defeito propensas. 4.6Questesemaberto Vimos como a complexidade, o domnio do problema, ou a taxa de variao pode ser usado para aprender com a histria e prevera densidade de defeitos de componentes

novos e evoluiu. Assim, podemos realmente prever erros de histria, e at mesmo fazlo de uma forma totalmenteautomtica.Esteumclarobenefciodeter umafaixabem guardado de defeitos anteriores: evitar falhas futuras, direcionando os esforos de garantiadequalidade. Os exemplos neste captulo todos dependem de recursos de cdigo para prever defeitos. Por no significa que analisamos todososrecursospossveisdecdigoquepodevir a ser bons preditores de defeitos. Esperamos que futuras pesquisas para chegar a muito melhores preditores Tabela 4.6 enumera vrios conjuntos de dados que esto disponveis publicamentedemodoquequalquerpessoapodetestlaouasuaideiafavorita. Promessa de dados Repository NASA mtricas de dados Eclipse Bug Dados ISBSG Dados finlandesesDefinirFLOSSmole Tabela4.6.Conjuntosdedadosparaestudosempricos O Repositrio de Dados promessa contm conjuntos de dados para estimativa de esforo, a previso de defeitos, e mineraodetexto.Atualmente,compostopor23conjuntosde dados, masestenmeroestemconstantecrescimento(gratuito). http://promisedata.org/ O repositrio da NASA IV & V Facility Metrics Programa de Dados contm as mtricas de software (como McCabeeHalstead)eosdadosdeerroassociadasao nveldafuno/mtodopara13projetos(gratuito). http://mdp.ivv.nasa.gov/ Estes dados contm os defeitos deprlanamentoepslanamento de trs verses do Eclipse IDE (gratuito). repositrio http://www.st.cs.unisb.de/softevo/The de ISBSG contm dados empricos para estimativa de software, produtividade, anlise de risco e informaesdecusto(comercial).http://www.isbsg.org/ Este conjunto de dados recolhido por sttf para apoiar benchmarks de custos de software, desenvolvimento,produtividadeeprocessosdesoftware(comercial). http://www.sttf.fi/ FLOSSmole uma"coleo de colaborao e anlisede dados do projeto de cdigo livre / libre / open". http://ossmole.sourceforge.net/ Outra caracterstica comum das abordagensdiscutidasatagoraquetodoselesprevemonmerodedefeitos. Em geral, contudo, os gestores no s quer minimizar o nmero de defeitos, mas minimizar o dano total, que envolve o impacto cada defeito,isto , o nmero de falhas efetivas,eosdanoscausados porcadafalha. Finalmente, todas as previses discutidas neste captulo requerem um histrico de defeitos para aprender. Ao longo da histria, podemos saber quais as caractersticas do cdigo ou do processo de desenvolvimento tm mais probabilidade de se correlacionam com defeitos e estasmesmasfunespodemassimserutilizadosparaprevercomponentesdefeito propensas. Claroque, quanto maisdetalhadadesta histriadefalhas,mais precisasas

previses ser. No entanto, ter uma longa histria de falhas algo que gostaria de evitar completamente. Pelo menos, ns gostaramos de aprender o suficiente de um histrico do projetoparaevitarrepetilanoprximoprojeto: Existe uma maneira de fazer previses para novos produtos sem histricoconhecido ainda? Como podemos aproveitar e abstrato nosso conhecimento sobre os defeitos de um projetoparaoutro? Existem propriedades universais de programas e processos que, invariavelmente, resultamemumadensidademaiordefeito? Acreditamos que tais propriedades universais de fato noexistem. Noentanto, muito pouco provvel que essas propriedades so propriedades do cdigo sozinho. Lembrese que nos concentramos em defeitos T. Zimmermann, N. Nagappan, A. Zeller, que ocorrem aps o lanamento, ou seja, em um momento emque as pessoas j tomaram conta de garantia de qualidade. razovel supor que quanto mais (emelhor)de garantia de qualidade aplicado, menos defeitos permanecer. No entanto, nenhum dos nossos modelos de previso leva a extenso ouaeficciadagarantiadaqualidadeemconta,simplesmente porque o cdigo no diz como ele foi testado, verificado, revisado ou verificado. A eficcia da garantia da qualidade umacaracterstica do processo desoftware,enoo software em si. H maneiras decaracterizar e avaliar tcnicasdegarantiadequalidade, por exemplo, podese verificar a coberturade umconjunto de testes ou a sua eficcia em descobrir mutaes. Estas so caractersticas importantes do processo de software que podemajudarapreverdefeitos. Alm da garantia de qualidade, existem outras caractersticas do processo paraolhar.A qualificao do programador, combinado com o tempo necessrio para escrever um componente, a qualidade da especificao, a qualidade do projecto, a competncia de gesto continuidade do fluxo de trabalho de todos estes, emuitosoutros,sofactores quecontribuemparaopessoasacometererros(ouevitlos). De alguma forma, procuradepropriedadesuniversaisqueosdefeitoscausacomoprocurar uma maneira universal para escrever software. Como uma meta intermediria, ele j pode ser tilparaescolherentrevrias"boas"maneiras. O que quer que apresenta preditores futuro ser baseado upon h uma invariante que permanece: Qualquer preditor acabar por revelarse errada. Isto porque se prev um preditor de um maior nmero de defeitos (ou falhas ou danos,paraesseefeito),ocomponente ser mais cuidadosamente verificado que ir, evidentemente, reduzir a densidade. Qualquer preditordefeito,assim,produzirautodestrutivoprofecias,eistoumacoisaboa.

Pontoschave Atagora,todososindicadoresdedefeitodeumhistricodedefeitosanteriores. preditoresautomatizadosnoaindaprocessardadosdiretamentedealavancagem. A busca de universais (por exemplo, a histria de menos) preditores defeito ainda estaberta. 4.7AmeaasValidade Tal como acontece com todos os estudos empricos desenho concluses gerais a partir de estudos de caso na engenharia de software difcil, porque qualquer processo depende, em grande medida, umnmeropotencialmentegrandede variveis de contexto relevantes. Por esta razo, no se pode assumir, a priori, que os resultados de um estudo de generalizar para alm do ambiente especfico no qual foi conduzido [40].Algumasdasameaasvalidade denossosestudossodiscutidasabaixo. Poderia ter havido erros na medio. Em geral, todas as medies de dados de software nos nossos estudos foi realizado utilizando ferramentas automatizadas. Isso alivia a um certo grau de erros na medio. Mas possvel que essas ferramentas poderiamtertidoerrosdeprojetoquepoderiamterlevadoaerrosnamedio. Os estudos de caso foram realizados por dois grandes sistemas ou seja, Windows Server 2003 e Eclipse. possvel que no pode ser observado destes resultados para os sistemas mais pequenos ou outra. Alm disso estes sistemas tm, possivelmente, vrios milhes de usurios. Por isso, possvel que outros sistemas que no possuem tal perfil de uso ativopodenoteramaioriadeseusdefeitosdecampoencontradosigualmente. Pelo menos umdostrsautoresfaziam partedecadaestudodecasodescritonestecaptulo. Inconscientemente,teriasidopossvelintroduzirvisexperimentadoremestudosdecaso.

Toda a anlise em nossos estudos foi feito aps the verdade, ou seja, todos os defeitosde campo havia sido relatadopara trs e ns tinha usadoparaosnossosmodelosdepreviso. difcil para ns, para avaliar como a nossa previso feita antes da mo teria influenciado o comportamento do time de desenvolvimento efetivamente beneficiando lospara identificar os componentespropensasproblemanoincio. Os modelos estatsticos construdos para os sistemas de software podem ser aplicadas apenas para a determinada famlia de sistemas para os quais eles so construdos para [61]. Por exemplo, pode no ser til para usar um modelo construdo sobre o Eclipse para prever bugsemprogramasdebrinquedo. Apesar de nossos estudos decasopreverdefeitossignificativamenteoutrasinformaes,tais como a gravidade, o impacto da informao falha etcestofaltandoasnossasprevises.Este tipo de previses seria parte de futuras investigaes nesta rea de pesquisa. Basili et ai.

afirmam que os pesquisadores tornamse mais confiantes em uma teoria, quando as concluses semelhantes surgem em diferentes contextos [40]. Para este fim, esperamosque nosso estudo de caso contribui para a construo do corpo emprico j existente de conhecimentonestedomnio[275,274,384,402,172,209,408,326]. 4.8ConclusoeConsequncias Aprendendo com a histria significa aprender com os sucessos e fracassos e como tomar asdecisescorretasnofuturo.Nonossocaso,ahistriadesucessos efracassos fornecido pelo banco de dados de bugs: descobre minerao sistemticas que os mdulos somais propensosadefeitosefalhas.Correlacionandodefeitoscommtricas de complexidade ou o domnio do problema til para predizer problemas para componentes novos ou evoluiu. Da mesma forma, um cdigo que muda muito mais propensoafalhasdoqueumcdigoquenoalterado. Aprendendo com a histria tem uma grande vantagem: pode se concentrar noaspecto da histria que maisrelevanteparaasituaoatual.Nonossocaso,isso significaqueas predies sempre ser melhor se a histria feita a partir do produto ou do projecto na mo. Mas enquanto ns podemos chegar a indicadores precisos, precisamos de maistrabalhopara entender as causasde defeitos de softwaree estetrabalhodevelevaremcontaopapelde garantiadaqualidadeedoprocessodesoftwareemgeral. A esta luz, sentimos que o nosso trabalho tem apenas arranhamos a superfcie do que possvel e do que necessrio. Nosso trabalho futuro ir concentrarse sobre os seguintes tpicos: T. Zimmermann, N. Nagappan, A. Zeller Mais dados do processo. Como dito acima, os recursos de cdigo so apenas um fator na produo dedefeitos de software, caractersticas doprocessopodesertilparadescobrirporqueosdefeitos no socapturados.Pretendemosexplorareextrairfontesdedadosadicionais,informaesde garantiadequalidade,nomeadamenteparacobrirmaisdadosdoprocesso. Melhores mtricas e modelos. Agora, as mtricas que usamos como entrada para preditores ainda so muito simples.Pretendemos alavancar os dados de falha de diversos projetos para avaliarmtricasmaissofisticadasemodelosqueresultarnovamenteemmelhorespreditores. Abordagens combinadas. At agora, os mtodos descritos neste captulo todos examinaram caractersticas especficas de forma isolada. Combinlos, como em "Eu tenho um mdulo complexo importar internal.compiler, que no teve defeitos at agora "deve render ainda melhoresprevises. Aumento da granularidade. Ao invs de apenas analisar recursos no nvel do componente, podese ir para abordagens mais refinadas, tais como relaes chamador chamado. Tais relaes de granulao fina tambm pode permitir previses de densidade de defeitos para

aulasindividuaisoumtodosoufunes,mesmoindividuais. Em geral, essas etapasdevemajudarnosnosparaprever ondedefeitosser,mastambm para compreender as suas causas, de modo que possamos evitlos no futuro. Arquivos verso desempenham um papel fundamental em dizer queashiptesesseaplicamequeno, paraoprojetoemmos,ouuniversalmente. Reconhecimento. Christian Lindig, Rahul Premraj e Andrzej Wasylkowski forneceram comentrios teis sobre revises anteriores deste captulo. A obradeAndreasZellereThomas Zimmmermann em arquivos de softwaredemineraofoiapoiadopeloDeutscheForschungs Gemeinschaft, concesso Ze 509/11. Thomas Zimmermann adicionalmente suportada pelo DFG Graduiertenkolleg "Leistungsgarantien fr Rechnersysteme". Gostaramosde reconhecer os desenvolvedores do Eclipse, bem como os grupos de produtos da Microsoft para a sua cooperaonestesestudos.