The technical debt field covers an critical problem of software engineering, and this is one of the reasons why this field has received significant attention in recent years. The technical debt metaphor helps developers to think about, and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. It was created by Cunningham to improve the quality of software delivery. Many times the technical debt items are unknown, unmonitored and therefore not managed, thus resulting in high maintenance costs throughout the software life-cycle. We conducted an empirical study in an academic environment, during two offerings of a laboratory course on Extreme Programming (XP Lab) at University of São Paulo and in two Brazilian Software Companies (Company A and B). We analyzed thirteen teams, nine in the Academy and four in the Companies environment. The teams had a comprehensive lecture about technical debt and several ways to identify and manage technical debt were presented. We monitored the teams, performed interviews, did close observations and collected feedback. The obtained results show that the awareness of technical debt influences team behavior. Team members report thinking and discussing more on software quality after becoming aware of technical debt in their projects. We identified some impacts on the teams and the projects after having considered technical debt. A conceptual model for technical debt management was created including ways of how identifying, monitoring, categorizing, measuring, prioritizing, and paying off the technical debt. A few approaches and techniques for the technical debt management, identification, monitoring, measure, and payment are also suggested. / A metáfora de dívida técnica engloba um importante problema da engenharia de software e essa é uma das razões pelas quais este campo tem recebido uma grande atenção nos últimos anos. Essa metáfora auxilia os desenvolvedores de software a refletirem sobre e a monitorarem a qualidade de software. A metáfora se refere a falhas no software (geralmente causadas por atalhos para economizar tempo) que podem afetar a futura manutenção e evolução do mesmo. A metáfora foi criada por Cunningham com o objetivo de melhorar a qualidade das entregas de software. Muitas vezes as dívidas técnicas não são conhecidas, monitoradas e nem geridas, resultando em um alto custo de manutenção ao longo do ciclo de vida do software. Logo, conduziu-se um estudo empírico na academia, durante duas ofertas da disciplina de Programação Extrema (XP Lab) na Universidade de São Paulo e em duas empresas Brasileiras de desenvolvimento de software (Empresa A e B). Foram analisados treze times, sendo nove na academia e quatro nas empresas. Os times tiveram uma apresentação sobre dívida técnica e foram apresentadas algumas sugestões de abordagens para gerir dívida técnica. Monitorou-se os times, foram realizadas entrevistas, observações fechadas e informações foram coletadas. Os resultados mostraram que considerar dívida técnica influenciou o comportamento dos times. Eles reportaram que após considerar dívida técnica passaram a refletir e discutir mais a qualidade do software. Identificou-se alguns impactos nos times e nos projetos depois de considerarem dívida técnica. Um modelo conceitual para gestão de dívida técnica foi criado, incluindo formas, técnicas e abordagens de como identificar, monitorar, categorizar, medir, priorizar e pagar os itens de dívida técnica.

The technical debt field covers an critical problem of software engineering, and this is one of the reasons why this field has received significant attention in recent years. The technical debt metaphor helps developers to think about, and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. It was created by Cunningham to improve the quality of software delivery. Many times the technical debt items are unknown, unmonitored and therefore not managed, thus resulting in high maintenance costs throughout the software life-cycle. We conducted an empirical study in an academic environment, during two offerings of a laboratory course on Extreme Programming (XP Lab) at University of São Paulo and in two Brazilian Software Companies (Company A and B). We analyzed thirteen teams, nine in the Academy and four in the Companies environment. The teams had a comprehensive lecture about technical debt and several ways to identify and manage technical debt were presented. We monitored the teams, performed interviews, did close observations and collected feedback. The obtained results show that the awareness of technical debt influences team behavior. Team members report thinking and discussing more on software quality after becoming aware of technical debt in their projects. We identified some impacts on the teams and the projects after having considered technical debt. A conceptual model for technical debt management was created including ways of how identifying, monitoring, categorizing, measuring, prioritizing, and paying off the technical debt. A few approaches and techniques for the technical debt management, identification, monitoring, measure, and payment are also suggested. / A metáfora de dívida técnica engloba um importante problema da engenharia de software e essa é uma das razões pelas quais este campo tem recebido uma grande atenção nos últimos anos. Essa metáfora auxilia os desenvolvedores de software a refletirem sobre e a monitorarem a qualidade de software. A metáfora se refere a falhas no software (geralmente causadas por atalhos para economizar tempo) que podem afetar a futura manutenção e evolução do mesmo. A metáfora foi criada por Cunningham com o objetivo de melhorar a qualidade das entregas de software. Muitas vezes as dívidas técnicas não são conhecidas, monitoradas e nem geridas, resultando em um alto custo de manutenção ao longo do ciclo de vida do software. Logo, conduziu-se um estudo empírico na academia, durante duas ofertas da disciplina de Programação Extrema (XP Lab) na Universidade de São Paulo e em duas empresas Brasileiras de desenvolvimento de software (Empresa A e B). Foram analisados treze times, sendo nove na academia e quatro nas empresas. Os times tiveram uma apresentação sobre dívida técnica e foram apresentadas algumas sugestões de abordagens para gerir dívida técnica. Monitorou-se os times, foram realizadas entrevistas, observações fechadas e informações foram coletadas. Os resultados mostraram que considerar dívida técnica influenciou o comportamento dos times. Eles reportaram que após considerar dívida técnica passaram a refletir e discutir mais a qualidade do software. Identificou-se alguns impactos nos times e nos projetos depois de considerarem dívida técnica. Um modelo conceitual para gestão de dívida técnica foi criado, incluindo formas, técnicas e abordagens de como identificar, monitorar, categorizar, medir, priorizar e pagar os itens de dívida técnica.

Submitted by Natalia de Souza Gonçalves (natalia.goncalves@ufpe.br) on 2016-09-28T12:23:59Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertacao_Cleydiane_FINAL_Imprimir.pdf: 3971527 bytes, checksum: f06a014d16a761f030bbfccee75d176f (MD5) / Made available in DSpace on 2016-09-28T12:23:59Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertacao_Cleydiane_FINAL_Imprimir.pdf: 3971527 bytes, checksum: f06a014d16a761f030bbfccee75d176f (MD5) Previous issue date: 2016-02-19 / Dívida Técnica (DT) está relacionada a tarefas que devem ser executadas e são acumuladas ao longo de um projeto para serem realizadas posteriormente. A falta de planejamento de tempo e recursos em um projeto, dentre outros problemas, propiciam seu surgimento. DTs não solucionadas tendem a criar dependências e aumentar o grau de complexidade para correção, resultando em maior esforço, custo e retrabalho em um projeto. A sua identificação e gerenciamento ao longo de um projeto é essencial para minimizar seu impacto e consequências negativas. Estudos apontam teste de software como uma das principais áreas impactadas por DTs em projetos de software. Nesta dissertação foram mapeadas, a partir da literatura técnica, 22 possíveis DTs relacionadas ao processo de teste de software, assim como suas causas e indicadores. Elas foram avaliadas por meio de um survey com profissionais da área de teste de software. Como resultados do survey, são apresentados os níveis de concordância obtidos para cada DT, suas causas e indicadores sugeridos. Após essa validação da concordância quanto às DTs, foi identificada a necessidade de vincular soluções às causas de cada DT, para isto foi realizada uma nova revisão de literatura. A partir dos dados das DTs, com suas causas, indicadores e, agora, soluções, foi elaborado um mapa, com objetivo de apoiar profissionais da área de teste de software na gestão de DTs que podem ocorrer no decorrer da execução do processo de teste de software. Após a elaboração do mapa de gestão de dívida técnica, o mesmo foi avaliado a partir de um questionário (baseado na técnica de revisão em pares), por profissionais experientes em teste de software (líderes e consultores). Como resultado desta avaliação, são apresentadas as opiniões e considerações destes profissionais sobre a versão inicial do mapa elaborado. Por fim, é apresentado o resultado final do mapa, com as devidas alterações baseadas nas respostas obtidas no questionário de avaliação do mapa. / Technical Debit (TD) is related to the tasks which have to be executed but are accumulated during the development of a project to be implemented later. The lack of time and resource planning on a project, among other problems, facilitate its emergence. Unsolved TDs tend to create dependencies and increase the degree of complexity for corrections, resulting in bigger efforts, costs and rework on a project. Identifying and managing those issues are essential to minimize the impacts and negative consequences. Studies point out software testing as one of the most affected areas by TDs on a software project. At this dissertation, 22 (twenty-two) possible TDs related to testing software process were mapped from the technical lecture, along with its causes and indicators. They were evaluated through surveys with testing software experts. As result of the survey, it is presented the levels of accordance for each TD, also the suggested causes and indicators. After the accordance validation of the TDs, it was identified a demand to bind solutions to the causes of every TD, for this a new study was made. From the data of the TDs, along with its causes, indicators and solutions, a map was produced in order to support testing software professionals managing TDs that may appear during the testing software process execution. After producing the technical debit management map, the same was submitted for an evaluation, using a questionnaire (based on peer review technique), to testing software experts (leaders and consultants). As result of these evaluations, it is presented the opinions and remarks of those professionals about the final version of the produced map. Finally, it is presented the final result of the map, with the modifications based on the answers obtained through the map evaluation questionnaire.

Submitted by Daniella Sodre (daniella.sodre@ufpe.br) on 2015-03-09T12:50:30Z No. of bitstreams: 2 Dissertacao Antonio Cavalcanti.pdf: 1847589 bytes, checksum: d68a6d0a8cf07180e223791edb011bfb (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-09T12:50:30Z (GMT). No. of bitstreams: 2 Dissertacao Antonio Cavalcanti.pdf: 1847589 bytes, checksum: d68a6d0a8cf07180e223791edb011bfb (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2012-11-01 / É amplamente aceito que o custo de manutenção de um software representa mais de 90% do custo total do produto durante todo seu ciclo de vida. O custo de desenvolvimento do produto tende a se tornar insignificante principalmente em softwares com longos ciclos de vida. Softwares perdem sua importância e tendem a cair em desuso caso não sejam evoluídos. Naturalmente, durante esse processo de evolução diversas forças externas e internas corroboram para o decaimento da qualidade do código fonte do software, como por exemplo, pressões do mercado, diminuição dos orçamentos para manutenção, mudanças no time de desenvolvedores, dentre outros. Apesar de existirem técnicas para acompanhar a qualidade do código fonte de um software utilizando-­‐se métricas, nenhuma leva em consideração o contexto e decisões tomadas que levaram à diminuição da qualidade se tornando então técnicas reativas. Para explicar esse decaimento de qualidade, inserir informações contextuais sobre as decisões tomadas, permitir planejamento preventivo e acompanhar o aumento dos custos de manutenção em softwares com código fonte já comprometido, é utilizada a metáfora de Dívida Técnica. A metáfora de Dívida Técnica é uma analogia ao conceito de empréstimo financeiro. Ao comprometer a qualidade do código fonte do sistema em detrimento a algum benefício imediato, contrai-­‐se uma dívida onde o valor do empréstimo é o esforço economizado na execução da tarefa. Como toda dívida, são aplicados juros sobre o empréstimo contraído e se a dívida não for adequadamente controlado, no futuro a maior parte do esforço de manutenção e evolução será gasto amortizando os custos da dívida. Apesar de intuitiva, muito popular na comunidade de profissionais de software e útil para diminuir a distância entre o vocabulário técnico e o gerencial, a metáfora tem sua definição em evidências anedóticas, por isso se faz necessário estudos que possam descrever o fenômeno com rigor científico. Nesse contexto, o objetivo desse estudo é caracterizar a metáfora de Dívida Técnica sob a ótica de métricas de software, descrevendo relações existentes entre as tomadas de decisões e os impactos causados na qualidade, utilizando-­‐se de suítes clássicas de métricas, fundamentado em 7 anos de dados históricos de projetos reais e companhamento por 8 meses de um projeto vivo.

Submitted by Cláudia Bueno (claudiamoura18@gmail.com) on 2015-12-04T17:46:01Z No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Approved for entry into archive by Luciana Ferreira (lucgeral@gmail.com) on 2015-12-07T11:12:37Z (GMT) No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Made available in DSpace on 2015-12-07T11:12:37Z (GMT). No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) Previous issue date: 2015-09-11 / The SoftwareTechnicalDebtaimstocalculatecostsfromthefailuretocomplywithqua- lity standardsinthedevelopmentprocess,suchaslackofdocumentation,baddevelop- ment practicesanddisobediencetospecificcodingrulesofaproject.Oneoftheconcerns of organizationsandsoftwareengineersistoensuresuchqualitystandards,however,the humane wayofdoingthiscontrolallowsmistakeswhichconsequentlycausesTechnical Debt, whichintheshorttermarenotaproblem,butinthelongruncandestroyentire softwarestructures.Basedonthisproblem,itwillbeproposedanapproachforcalcu- lating theDesignTechnicalDebtofapplicationsdevelopedinJava.Themethodsused for thispurposeinvolvedataminingofopensourcecoderepositories,defecttracking softwaredatabases,timecorrectionestimativeofdesignrulesviolationandarchitectural compliance check. / A estimativadeDívidaTécnicadeSoftwaretemcomoobjetivocalcularoscustosdonão- cumprimento depadrõesdequalidadenoprocessodedesenvolvimento,taiscomofaltade documentação, máspráticasdedesenvolvimentoedesobediênciaàsregrasdecodificação específicas deumprojeto.Umadaspreocupaçõesdeorganizaçõeseengenheirosde softwareégarantirtaispadrõesdequalidade,noentanto,aformahumanadefazereste controle permiteerrosque,consequentemente,ocasionamDívidaTécnica,queemcurto prazo nãosãoumproblema,masemlongoprazopodedestruirestruturasdesoftware inteiras. Combasenesteproblema,serápropostaumaabordagemparaocálculodaDívida Técnica deDesigndeaplicaçõesdesenvolvidasemJava.Osmétodosutilizadosparaeste fim envolvemamineraçãodedadosderepositóriosdecódigoaberto,bancosdedados de softwarederastreamentodedefeitos,estimativadotempodecorreçãodeviolaçãode regrasdedesigneverificaçãodeconformidadearquitetural.

Submitted by Erika Demachki (erikademachki@gmail.com) on 2015-03-25T18:00:07Z No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Rejected by Erika Demachki (erikademachki@gmail.com), reason: on 2015-03-25T18:01:43Z (GMT) / Submitted by Erika Demachki (erikademachki@gmail.com) on 2015-03-25T18:03:23Z No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Approved for entry into archive by Erika Demachki (erikademachki@gmail.com) on 2015-03-25T18:04:48Z (GMT) No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Made available in DSpace on 2015-03-25T18:04:48Z (GMT). No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) Previous issue date: 2014-11-19 / The metaphor of technical debt (TD) is very useful for Software Engineering, it is directly related to the context of evolution and maintenance in the life cycle of a product. It can be understood as a relation between costs and effects, of short and long term, associated with project decisions during the software development process. Currently, large companies and some government sectors still have restrictions in adopting open source products by uncertainties related to its quality and reliability. In this context, this study aims to evaluate the technical debt in open source products in order to demonstrate the feasibility of this approach to evaluate the software quality. For this, were performed experimental studies, contemplating the automated data collection for a significant set of products open source, having as input its source code. These products were evaluated by SonarQube Platform, which enables collect several metrics about the quality of the source code - including the technical debt. The interpretation of the collected data allowed the analysis of the TD evolution for these products, the classification of the projects and the verification of the representativeness of the quality axis that make up the TD. The results suggest that most of the projects evaluated have shown decreased TD along their versions and they showed slightly elevated values of the metric. Another contribution is that the quality axis Coverage, Violations and Complexity is presented as the main contributors to the TD’s increase of from the set of product evaluated. It was also possible to verify the existence of a correlation between the TD implementation and the SQALE methodology, with regard assessing software quality evaluating. / A metáfora da dívida técnica (DT) apresenta-se muito útil para Engenharia de Software, estando diretamente relacionada ao contexto de evolução e manutenção existentes no ciclo de vida de um produto. Ela pode ser entendida como uma relação entre custos e efeitos, de curto e longo prazos, associados a decisões de projeto durante o processo de desenvolvimento de software. Atualmente, grandes empresas e alguns setores do governo ainda possuem restrições quanto à adoção de produtos de código aberto por incertezas relacionadas a sua qualidade e confiabilidade. Nesse contexto, o presente trabalho tem por objetivo avaliar a dívida técnica em produtos de código aberto, no intuito de demonstrar a possibilidade de utilização dessa abordagem para avaliação da qualidade de software. Para tanto, foram realizados estudos experimentais, contemplando a coleta automatizada de dados para um conjunto expressivo de produtos de código aberto, tendo como entrada o respectivo código fonte. Esses produtos foram submetidos à avaliação da Plataforma SonarQube, a qual possibilita coletar diversas métricas sobre a qualidade do código fonte – entre elas a dívida técnica (technical debt). A interpretação dos dados coletados possibilitou a análise da evolução da DT desses produtos, a classificação dos projetos e a verificação da representatividade dos eixos de qualidade que compõem a DT. Os resultados sugerem que a maioria dos projetos avaliados demonstrou diminuição da DT, ao longo de suas versões, e apresentou valores pouco elevados para a métrica. Outra contribuição consiste que os eixos de qualidade “Cobertura”, “Violações” e “Complexidade” foram identificados como aqueles que mais contribuem para o incremento da DT do conjunto de produtos avaliados. Foi possível, também, verificar a existência de uma correlação entre a implementação da DT estudada e a metodologia SQALE, no que diz respeito à avaliação da qualidade de software.