Gong, Zhixiong, Lyu, Feng
Context. Technical debt (TD) is a metaphor reflecting technical compromises that sacrifice long-term health of a software product to achieve short term benefit. TD is a strategy for the development team to obtain business value. TD can do both harm and good to a software based on the situation of TD accumulation. Therefore, it is important to manage TD in order to avoid the accumulated TD across the breaking point. In large-scale distributed projects, development teams located in different sites, technical debt management (TDM) becomes more complex and difficult compared with traditional collocated projects. In recent years, TD metaphor has attracted the attention from academics, but there are few studies in real settings and none in large-scale globally distributed projects. Objectives. In this study, we aim to explore the factors that have significant impact on TD and how practitioner manage TD in large-scale distributed projects. Methods. We conducted an exploratory case study to achieve the objectives. The data was collected through archival records and a semi-structured interview. For the archival data, hierarchical multiple regression was used to analyze the relationship between identified factors and TD. For interview data, we used qualitative content analysis method to get a deep understanding of TDM in this studied case. Results. Based on the results of archival data analysis, we identified three factors that show significant positive correlation with TD. These three factors were task complexity, global distance, and maturity, which were evaluated by the architect during the semi-structured interview. The architect also believed that these factors have strong relationships with TD. TDM in this case includes seven management activities: TD prevention, identification, measurement, documentation, communication, prioritization, and repayment. The tool used for TDM is an internally implemented tool called wiki page. We also summarize the roles involved and approaches used with respect to each TDM activity. Two identified TDM challenges in this case were TD measurement and prioritization. Conclusions. We conclude that 1) TDM in this case is not complete. Due to the lack of TD monitoring, the measurement of TD is static and lacks an efficient way to track the change of cost and benefit of unresolved TD over time. Therefore, it is difficult to find a proper time point to repay a TD. 2) The wiki page is not enough to support TDM, and some specific tools should be combined with wiki page to manage TD comprehensively. 3) TD measurement and prioritization should get more attention both from practitioners and academics to find a suitable way to solve such challenges in TDM. 4) Factors that make significant contribution to TD should be carefully considered, which increase the accuracy of TD prediction and improve the efficiency of TDM.
(has links) (PDF)
Deficiencies in software design or architecture can severely impede and slow down the software development and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have been proposed to assist software engineers in identifying smells and guiding them through corresponding refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend to produce false positives which represent conscious constructs with symptoms similar or identical to actual bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design review in order to identify (missed) design smells and/or re-assess detected smell candidates. UML diagrams are the quasi-standard for documenting software design and are often available in software projects. In this position paper, we investigate whether (and to what extent) UML diagrams can be used for identifying and assessing design smells. Based on a description of difficulties in the smell detection process, we discuss the importance of design reviews. We then investigate to what extent design documentation in terms of UML2 diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss further challenges for UML-based identification and assessment of bad smells.
Technical debt management in the context of agile methods in software development / Gerenciamento de dívida técnica no Ccontexto de desenvolvimento de software ágil.Graziela Simone Tonin 23 March 2018 (has links)
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.
Page generated in 0.105 seconds