| 1. |
- Al Mamun, Md Abdullah, 1982, et al.
(författare)
-
Evolution of technical debt: An exploratory study
- 2019
-
Ingår i: CEUR Workshop Proceedings. - : CEUR-WS. - 1613-0073. ; 2476, s. 87-102, s. 87-102
-
Konferensbidrag (refereegranskat)abstract
- Context: Technical debt is known to impact maintainability of software. As source code files grow in size, maintainability becomes more challenging. Therefore, it is expected that the density of technical debt in larger files would be reduced for the sake of maintainability. Objective: This exploratory study investigates whether a newly introduced metric ‘technical debt density trend’ helps to better understand and explain the evolution of technical debt. The ‘technical debt density trend’ metric is the slope of the line of two successive ‘technical debt density’ measures corresponding to the ‘lines of code’ values of two consecutive revisions of a source code file. Method: This study has used 11,822 commits or revisions of 4,013 Java source files from 21 open source projects. For the technical debt measure, SonarQube tool is used with 138 code smells. Results: This study finds that ‘technical debt density trend’ metric has interesting characteristics that make it particularly attractive to understand the pattern of accrual and repayment of technical debt by breaking down a technical debt measure into multiple components, e.g., ‘technical debt density’ can be broken down into two components showing mean density corresponding to revisions that accrue technical debt and mean density corresponding to revisions that repay technical debt. The use of ‘technical debt density trend’ metric helps us understand the evolution of technical debt with greater insights.
|
|
| 2. |
- Alégroth, Emil, 1984, et al.
(författare)
-
Exploring the Presence of Technical Debt in Industrial GUI-based Testware: A Case Study
- 2016
-
Ingår i: 2016 IEEE Ninth International Conference on Software Testing, Verification and Validation Workshops. - : IEEE. - 2159-4848. - 9781509036745 ; , s. 257-262
-
Konferensbidrag (refereegranskat)abstract
- Technical debt (TD) is a concept used to describe a sub-optimal solution of a software artifact that negatively affects its comprehensibility, extendability and maintainability. As such, TD adversely affects the costs or quality associated with the artifact, which is also called interest. TD has through research been identified in all types of software artifacts, from architectural design to automated tests (Testware). However, research into testware technical debt (TTD) is limited and primarily focused on testing on lower level of system abstraction, i.e. unit-and integration tests, leaving a need for more TTD research on GUI-based testing. In this study we explore this gap in knowledge through an industrial case study at a Swedish avionics software development company. Four repositories are studied for the presence of TTD using expert interviews, semi-automated document analysis and automatic metric analysis. Results of the study provide initial support that the concept of TTD is applicable to GUI-based testware and show the presence of both TD items unique to GUI-based testware and items common to software. The implications of these results are that engineering best practices must be established for GUI-based testware to minimize TD interest.
|
|
| 3. |
- Ampatzoglou, Areti, et al.
(författare)
-
The Perception of Technical Debt in the Embedded Systems Domain: An Industrial Case Study
- 2016
-
Ingår i: 8th IEEE International Workshop on Managing Technical Debt (MTD). - 2377-8571. - 9781509038541 ; , s. 9-16
-
Konferensbidrag (refereegranskat)abstract
- Technical Debt Management (TDM) has drawn the attention of software industries during the last years, including embedded systems. However, we currently lack an overview of how practitioners from this application domain perceive technical debt. To this end, we conducted a multiple case study in the embedded systems industry, to investigate: (a) the expected lifetime of components that have TD, (b) the most frequently occurring types of TD in them, and (c) the significance of TD against run-time quality attributes. The case study was performed on seven embedded systems industries (telecommunications, printing, smart manufacturing, sensors, etc.) from five countries (Greece, Netherlands, Sweden, Austria, and Finland). The results of the case study suggest that: (a) maintainability is more seriously considered when the expected lifetime of components is larger than ten years; (b) the most frequent types of debt are test, architectural, and code debt; and (c) in embedded systems the run-time qualities are prioritized compared to design-time qualities that are usually associated with TD. The obtained results can be useful for both researchers and practitioners: the former can focus their research on the most industrially-relevant aspects of TD, whereas the latter can be informed about the most common types of TD and how to focus their TDM processes.
|
|
| 4. |
- Avgeriou, Paris C, et al.
(författare)
-
An Overview and Comparison of Technical Debt Measurement Tools
- 2021
-
Ingår i: IEEE Software. - 1937-4194 .- 0740-7459. ; 38:3, s. 61-71
-
Tidskriftsartikel (refereegranskat)abstract
- There are numerous commercial tools and research prototypes that offer support for measuring technical debt. However, different tools adopt different terms, metrics, and ways to identify and measure technical debt. These tools offer diverse features, and their popularity / community support varies significantly. Therefore, (a) practitioners face difficulties when trying to select a tool matching their needs; and (b) the concept of technical debt and its role in software development is blurred. We attempt to clarify the situation by comparing the features and popularity of technical debt measurement tools, and analyzing the existing empirical evidence on their validity. Our findings can help practitioners to find the most suitable tool for their purposes, and researchers by highlighting the current tool shortcomings.
|
|
| 5. |
- Besker, Terese, 1970, et al.
(författare)
-
A systematic literature review and a unified model of ATD
- 2016
-
Ingår i: Proceedings of the EUROMICRO Conference. - 1089-6503. - 9781509028191 ; , s. 189-197
-
Konferensbidrag (refereegranskat)abstract
- Fast software deliveries are hindered by high maintenance efforts due to internal quality issues and Technical Debt (TD) and specifically, Architectural Technical Debt (ATD) has received increased attention in the last few years. ATD has a significant influence and impact on system success and, left unchecked, it can cause expensive repercussions; it is, therefore, of maintenance and evolutionary importance to understand the basic underlying factors of ATD. Thus, with this as background, there is a need for a descriptive model to illustrate and explain the different ATD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the ATD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the ATD phenomenon. This model categorizes the main characteristics of ATD and reveals their corresponding relations. The model is based on a systematic literature review (SLR) of currently recognized knowledge concerning ATD.
|
|
| 6. |
- Besker, Terese, 1970, et al.
(författare)
-
An investigation of Technical Debt in Automatic Production Systems
- 2017
-
Ingår i: ACM International Conference Proceeding Series. - New York, NY, USA : ACM. - 9781450352642 ; Part F129907
-
Konferensbidrag (refereegranskat)abstract
- Technical Debt is a recent concept, borrowed from the financial domain. It has been recently used in software development to describe technical sub-optimal solutions that have short-term benefits but long-term extra-costs. However, no body of literature investigates how Automatic Production Systems companies deal with Technical Debt. We investigated how Technical Debt is known, how much it hurts and how is managed in an automatic production systems company. Results from one in-depth investigation show that the automatic production systems company spend quite a lot of resources because of Technical Debt, both in the extra-costs (interest) and in its management. The company presents moderate awareness of what Technical Debt is and how much is present in its systems. However, the tracking level is quite low. We, therefore, claim that Technical Debt needs more research in this domain, as it is a source of substantial extra-costs and the current practices to manage it are not suitable.
|
|
| 7. |
- Besker, Terese, 1970, et al.
(författare)
-
Carrot and Stick approaches when managing Technical Debt
- 2020
-
Ingår i: Proceedings - 2020 IEEE/ACM International Conference on Technical Debt, TechDebt 2020. - New York, NY, USA : ACM. ; , s. 21-30
-
Konferensbidrag (refereegranskat)abstract
- When developing software, it is vitally important to keep the level of technical debt down since it is well established from several studies that technical debt can, e.g., lower the development productivity, decrease the developers’ morale, and compromise the overall quality of the software. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible. This paper aims to explore how software companies encourage and reward practitioners for actively keeping the level of technical debt down and also whether the companies use any forcing or penalizing initiatives when managing technical debt. This paper reports the results of both an online web-survey provided quantitative data from 258 participants and follow-up interviews with 32 industrial software practitioners. The findings show that having a TD management strategy can significantly impact the amount of TD in the software. When surveying how commonly used different TD management strategies are, we found that only the encouraging strategy is, to some extent, adopted in today's’ software industry. This study also provides a model describing the four assessed strategies by presenting its strategies and tactics, together with recommendations on how they could be operationalized in today’s software companies.
|
|
| 8. |
- Besker, Terese, 1970, et al.
(författare)
-
How Regulations of Safety-Critical Software Affect Technical Debt
- 2019
-
Ingår i: Proceedings - 45th Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2019. ; , s. 74-81
-
Konferensbidrag (refereegranskat)abstract
- In recent years in the software industry, the use of safety-critical software is increasing at a rapid rate. However, little is known about the relationship between safety-critical regulations and the management of technical debt. The research is based on interviews with 19 practitioners working in different safety-critical domains implementing software according to different safety regulation standards. The results are three-fold. First, the result shows that performing technical debt refactoring tasks in safety-critical software requires several additional activities and costs, compared to non-safety-critical software. This study has also identified several negative effects due to the impact of these regulatory requirements. Second, the results show that the safety-critical regulations strengthen the implementation of both source code and architecture and thereby initially limit the introduction of technical debt. However, at the same time, the regulations also force the software companies to perform later suboptimal work-around solutions that are counterproductive in achieving a high-quality software since the regulations constrain the possibility of performing optimal TD refactoring activities. Third, the result shows that technical debt refactoring decisions are heavily weighed on the costs associated with the application’s recertification process and that these decisions seldom include the benefits of the refactoring activities in a structured way.
|
|
| 9. |
- Besker, Terese, 1970, et al.
(författare)
-
Impact of Architectural Technical Debt on Daily Software Development Work - A Survey of Software Practitioners
- 2017
-
Ingår i: Proceedings - 43rd Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2017. - 9781538621400 ; , s. 278-287
-
Konferensbidrag (refereegranskat)abstract
- — The negative consequences of Technical Debt is an area of increasing interest, and more specifically the Architectural aspects of it have received increased attention in the last few years. Besides the negative effects of Architectural Technical Debt on the overall software product quality in terms of hindering evolution and causing high maintenance costs, Architectural Technical Debt also has a significant negative impact on software practitioners’ daily work. Although a great deal of theoretical work on Architectural Technical Debt has been undertaken, there is a lack of empirical studies that examine the negative effects of Architectural Technical Debt during the software development lifecycle. The aim of this study is to investigate how practitioners perceive and estimate the impact of Architectural Technical Debt during the software development process. This paper reports the results of an online web survey providing quantitative data from 258 participants. The contribution of this paper is threefold: First, it shows that practitioners experience that the Architectural type of Technical Debt has the highest negative impact on daily software development work. Secondly, we provide evidence that does not support the commonly held belief that Architectural Technical Debt increases with the age of the software. Thirdly, we show that despite different responsibilities and working tasks of software professionals, Architectural Technical Debt negatively affects all roles without any significant difference between the roles.
|
|
| 10. |
- Besker, Terese, 1970, et al.
(författare)
-
Managing architectural technical debt: A unified model and systematic literature review
- 2018
-
Ingår i: Journal of Systems and Software. - : Elsevier BV. - 0164-1212. ; 135, s. 1-16
-
Tidskriftsartikel (refereegranskat)abstract
- Large Software Companies need to support the continuous and fast delivery of customer value in both the short and long term. However, this can be impeded if the evolution and maintenance of existing systems is hampered by what has been recently termed Technical Debt (TD). Specifically, Architectural TD has received increased attention in the last few years due to its significant impact on system success and, left unchecked, it can cause expensive repercussions. It is therefore important to understand the underlying factors of architectural TD. With this as background, there is a need for a descriptive model to illustrate and explain different architectural TD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the architectural TD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the architectural TD phenomenon. This model categorizes the main characteristics of architectural TD and reveals their relations. The results show that, by using this model, different stakeholders could increase the system's success rate, and lower the rate of negative consequences, by raising awareness about architectural TD.
|
|
| 11. |
- Besker, Terese, 1970, et al.
(författare)
-
Software Developer Productivity Loss Due to Technical Debt - A replication and extension study examining developers’ development work
- 2019
-
Ingår i: Journal of Systems and Software. - : Elsevier BV. - 0164-1212. ; 156, s. 41-61
-
Tidskriftsartikel (refereegranskat)abstract
- Software companies need to deliver customer value continuously, both from a short- and long-term perspective. However, software development can be impeded by technical debt (TD). Although significant theoretical work has been undertaken to describe the negative effects of TD, little empirical evidence exists on how much wasted time and additional activities TD causes. The study aims to explore the consequences of TD in terms of wastage of development time. This study investigates on which activities this wasted time is spent and whether different TD types impact the wasted time differently. This study reports the results of a longitudinal study surveying 43 developers and including16 interviews followed by validation by an additional study using a different and independent dataset and focused on replicating the findings addressing the findings. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their time due to TD and that developers are frequently forced to introduce new TD. The most common activity on which additional time is spent is performing additional testing. The study provides evidence that TD hinders developers by causing an excessive waste of working time, where the wasted time negatively affects productivity.
|
|
| 12. |
- Besker, Terese, 1970, et al.
(författare)
-
Technical Debt Cripples Software Developer Productivity
- 2018
-
Ingår i: Proceedings - International Conference on Software Engineering. - New York, NY, USA : ACM. - 0270-5257. ; , s. 105-114
-
Konferensbidrag (refereegranskat)abstract
- Software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer’s and manager’s perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing.
|
|
| 13. |
- Besker, Terese, 1970, et al.
(författare)
-
Technical Debt Triage in Backlog Management
- 2019
-
Ingår i: Proceedings - 2019 IEEE/ACM International Conference on Technical Debt, TechDebt 2019. ; , s. 13-22
-
Konferensbidrag (refereegranskat)abstract
- Remediation of technical debt through regular refactoring initiatives is considered vital for the software system's long and healthy life. However, since today’s software companies face increasing pressure to deliver customer value continuously, the balance between spending developer time, effort, and resources on implementing new features or spending it on refactoring of technical debt becomes vital. The goal of this study is to explore how the prioritization of technical debt is carried out by practitioners within today’s software industry. This study also investigates what factors influence the prioritization process and its related challenges. This paper reports the results of surveying 17 software practitioners, together with follow-up interviews with them. Our results show that there is no uniform way of prioritizing technical debt and that it is commonly done reactively without applying any explicit strategies. Often, technical debt issues are managed and prioritized in a shadow backlog, separate from the official sprint backlog. This study was also able to identify several different challenges related to prioritizing technical debt, such as the lack of quantitative information about the technical debt items and that the refactoring of technical debt issues competes with the implementation of customer requirements.
|
|
| 14. |
- Besker, Terese, 1970, et al.
(författare)
-
The Influence of Technical Debt on Software Developer Morale
- 2020
-
Ingår i: Journal of Systems and Software. - : Elsevier BV. - 0164-1212. ; 167
-
Tidskriftsartikel (refereegranskat)abstract
- Context: Previous research in the Technical Debt (TD) field has mainly focused on the technical and economic aspects, while its human aspect has received minimal attention. Objective: This paper aims to understand how software developers’ morale is influenced by TD and how their morale is influenced by TD management activities. Furthermore, this study correlates the morale with the amount of wastage of time due to TD. Method: Firstly, we conducted 15 interviews with professionals, and, secondly, these data were complemented with a survey. Thirdly, we collected 473 data points from 43 developers reporting their amount of wasted time. The collected data were analyzed using both quantitative and qualitative techniques, including thematic and statistical analysis. Results: Our results show that the occurrence of TD is associated with a lack of progress and waste of time. This might have a negative influence on developers’ morale. Further, management of TD seems to have a positive influence on developers’ morale. Conclusions: The results highlight the effects TD has on practitioners’ software work. This study presents results indicating that software suffering from TD reduces developers’ morale and thereby also their productivity. However, our results also indicate that TD management increases developers’ morale and developer productivity.
|
|
| 15. |
- Besker, Terese, 1970, et al.
(författare)
-
The Pricey Bill of Technical Debt - When and by whom will it be paid?
- 2017
-
Ingår i: IEEE International Conference on Software Maintenance and Evolution (ICSME). - 9781538609927 ; , s. 13-23
-
Konferensbidrag (refereegranskat)abstract
- — Software companies need to support continuous and fast delivery of customer value both in short and a long-term perspective. However, this can be hindered by evolution limitations and high maintenance efforts due to internal software quality issues by what is described as Technical Debt. Although significant theoretical work has been undertaken to describe the negative effects of Technical Debt, these studies tend to have a weak empirical basis and often lack quantitative data. The aim of this study is to estimate wasted time, caused by the Technical Debt interest during the software life-cycle. This study also investigates how practitioners perceive and estimate the impact of the negative consequences due to Technical Debt during the software development process. This paper reports the results of both an online web-survey provided quantitative data from 258 participants and follow-up interviews with 32 industrial software practitioners. The importance and originality of this study contributes and provides novel insights into the research on Technical Debt by quantifying the perceived interest and the negative effects it has on the software development life-cycle. The findings show that on average, 36 % of all development time is estimated to be wasted due to Technical Debt; Complex Architectural Design and Requirement Technical Debt generates most negative effect; and that most time is wasted on understanding and/or measuring the Technical Debt. Moreover, the analysis of the professional roles and the age of the software system in the survey revealed that different roles are affected differently and that the consequences of Technical Debt are also influenced by the age of the software system.
|
|
| 16. |
- Besker, Terese, 1970, et al.
(författare)
-
Time to Pay Up - Technical Debt from a Software Quality Perspective
- 2017
-
Ingår i: CibSE. - 9789873806988 ; , s. 235-248
-
Konferensbidrag (refereegranskat)abstract
- Software companies need to produce high-quality software and support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered by compromised software quality attributes that have an important influence on the overall software development lifecycle. The aim of this study is threefold: to understand which quality issues have the most negative impact on the software development lifecycle process, to deter-mine the association of these quality issues in relation to the age of the software, and relate each of these quality issues to the impact of different Technical Debt types. This paper reports the results of six initial group interviews with in total 43 practitioners, an online web-survey provided quantitative data from 258 participants and seven follow-up group interviews with in total 32 industrial software practitioners. First, this study shows that practitioners identified maintenance difficulties, a limited ability to add new features, restricted reusability, and poor reliability, and performance degradation issues as the quality issues having the most negative effect on the software development lifecycle. Secondly, we found no evidence for the generally held view that the Technical Debt increases with age of the software. Thirdly, we show that Technical Debt affects not only productivity but also several other quality attributes of the system.
|
|
| 17. |
- Eliasson, Ulf, 1984, et al.
(författare)
-
Identifying and Visualizing Architectural Debt and Its Efficiency Interest in the Automotive Domain: A Case Study
- 2015
-
Ingår i: 2015 Ieee 7th International Workshop on Managing Technical Debt (Mtd) Proceedings. - : IEEE. - 9781467373784
-
Konferensbidrag (refereegranskat)abstract
- Architectural Technical Debt has recently received the attention of the scientific community, as a suitable metaphor for describing sub-optimal architectural solutions having short-term benefits but causing a long-term negative impact. We study such phenomenon in the context of Volvo Car Group, where the development of modern cars includes complex systems with mechanical components, electronics and software working together in a complicated network to perform an increasing number of functions and meet the demands of many customers. This puts high requirements on having an architecture and design that can handle these demands. Therefore, it is of utmost importance to manage Architecture Technical Debt, in order to make sure that the advantages of sub-optimal solutions do not lead to the payment of a large interest. We conducted a case study at Volvo Car Group and we discovered that architectural violations in the detailed design had an impact on the efficiency of the communication between components, which is an essential quality in cars and other embedded systems. Such interest is not studied in literature, which usually focuses on the maintainability aspects of Technical Debt. To explore how this Architectural Technical Debt and its interest could be communicated to stakeholders, we developed a visual tool. We found that not only was the Architectural Debt highly interesting for the architects and other stakeholders at VCG, but the proposed visualization was useful in increasing the awareness of the impact that Architectural Technical Debt had on efficiency.
|
|
| 18. |
- Ghanbari, Hadi, et al.
(författare)
-
Looking for Peace of Mind? Manage your (Technical) Debt - An Exploratory Field Study
- 2017
-
Ingår i: International Symposium on Empirical Software Engineering and Measurement. - 1949-3789 .- 1949-3770. ; 2017-November
-
Konferensbidrag (refereegranskat)abstract
- Background: In the last two decades Technical Debt (TD) has received a considerable amount of attention from software engineering research and practice. Recently, a small group of studies suggests that, in addition to its technical and economic consequences, TD can affect developers’ psychological states and morale. However, until now there has been a lack of empirical research clarifying such influences. Aims: In this study, we aim at taking the first step in filling this gap by investigating the potential impacts of TD and its management on developers’ morale. Method: Drawing from previous literature on morale, we decided to explore the influence of TD and its management on three dimensions of morale called affective, future/goal, and interpersonal antecedents. In so doing, we conducted an exploratory field study and collected data from software professionals active in different industrial domains through eight qualitative interviews and an online survey (n=33). Results: Our results indicate that TD mainly has a negative influence on future/goal and affective antecedents of morale. This is mainly because the occurrence of TD hinders developers from performing their tasks and achieving their goals. TD management, on the other hand, has a positive influence on all the three dimensions of morale since it is associated with positive feelings and interpersonal feedback as well as a sense of progress. Conclusions: According to the results of this empirical study, the occurrence of TD reduces developers’ morale, while its management increases developers’ morale.
|
|
| 19. |
- Holvitie, J., et al.
(författare)
-
Co-existence of the 'technical debt' and 'software legacy' concepts
- 2016
-
Ingår i: CEUR Workshop Proceedings. - 1613-0073. ; 1771, s. 80-83
-
Konferensbidrag (refereegranskat)abstract
- 'Technical debt' and 'software legacy' are concepts that both discuss a state of software that is sub-optimal, time constrained, and explain how this state can decrease an organization's development efficiency. However, there is significant confusion in the way the software engineering community perceive these concepts. In this paper we perform an initial examination of technical debt and software legacy concepts, and examine their somewhat challenging co-existence. In motivating our work, we discuss previous survey results which show that practitioners believe that technical debt largely emerges from software legacy. We then identify sources of confusion in comparing popular definitions of both concepts. Finally, we map the use of the 'technical debt' and 'software legacy' concepts in existing research. We conclude that structured co-existence of these terms can be pursued with mutually beneficial gains.
|
|
| 20. |
- Lenarduzzi, Valentina, et al.
(författare)
-
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
- 2020
-
Ingår i: Journal of Systems and Software. - : Elsevier BV. - 0164-1212. ; 171
-
Tidskriftsartikel (refereegranskat)abstract
- Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring of Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review of 557 unique papers published until 2019, following a consolidated methodology applied in software engineering. We included 44 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that Technical Debt prioritization research is preliminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research conclusive. In this paper, we therefore outline different directions for necessary future investigations.
|
|
| 21. |
- Martini, Antonio, 1982, et al.
(författare)
-
A Framework for Speeding Up Interactions Between Agile Teams and Other Parts of the Organization
- 2014
-
Ingår i: Continuous Software Engineering. - Cham : Springer. - 9783319112824 ; 9783319112831, s. 67-82
-
Bokkapitel (övrigt vetenskapligt/konstnärligt)abstract
- A known problem in large software companies is to balance the return on investment coming from short-term and long-term business goals dependent on the responsiveness of the companies. In the previous chapter we have found challenges in interactions between the Agile team and other parts of the organization. We have conducted an investigation on three large product line companies employing Agile software development in order to find practices that would mitigate the challenges.
|
|
| 22. |
- Martini, Antonio, 1982, et al.
(författare)
-
A multiple case study of continuous architecting in large agile companies: current gaps and the CAFFEA framework
- 2016
-
Ingår i: Proceedings - 2016 13th Working IEEE/IFIP Conference on Software Architecture, WICSA 2016. - 9781509021314 ; , s. 1-10
-
Konferensbidrag (refereegranskat)abstract
- In order to continuously support the value delivery both in short-term and long-term, a key goal for large software companies is to continuously develop and manage software architecture. In order to understand how architecture management is employed in large Agile software companies, we have conducted interviews involving several roles at 5 firms. Through a combination of structured inductive and deductive analysis proper of Grounded Theory, we have identified current architect roles and gaps in the architecture practices in the studied organizations. From such investigation, we have developed an organizational framework, CAFFEA, for Agile architecting, including roles, (virtual) teams and practices. The framework has been evaluated through a cross-company workshop including participants from 5 large software companies, discussion groups and a final survey. Finally, we have evaluated the framework in practice after one year of its application at one of the companies. We found that some necessary architectural practices are overlooked in Large Agile Software Development. The evaluation of CAFFEA framework showed that the included roles and teams are needed in order to mitigate the gaps in the architectural practices. The responsibilities and the activities have been mapped to key architect roles compatible with the Scrum setting employed at the companies. The evaluation of CAFFEA shows key benefits.
|
|
| 23. |
- Martini, Antonio, 1982, et al.
(författare)
-
A multiple case study on the inter-group interaction speed in large, embedded software companies employing agile
- 2016
-
Ingår i: Journal of Software: Evolution and Process. - : Wiley. - 2047-7481 .- 2047-7473. ; 28:1, s. 4-26
-
Tidskriftsartikel (refereegranskat)abstract
- The adoption of Agile Software Development in large companies is a recent phenomenon of great interest both for researchers and practitioners. Although intra-team interaction is well supported by established agile practices, the critical interaction between the agile team and other parts of the organization is still unexplored in literature. Such interactions slow down the development, hindering the achievement of business goals based on speed: short time to market, quick replication of products of a product-line, and reaction time for product evolution.We have employed a two-year long multiple-case case-study, collecting data through interviews and a survey in three large companies developing embedded software. Through a combination of qualitative and quantitative analysis, we have found strong evidence that interaction challenges between the development team and other groups in the organization hinder speed and are widespread in the organizations.This paper also identifies current practices in use at the studied companies and provides detailed guidelines for novel solutions in the investigated domain. Such practices are called boundary-spanning activities in information system research and coordination theory. We present a comparison between large embedded software companies employing agile and developing a line of products based on reused assets and agile companies developing pure software. We highlight specific contextual factors and areas where novel spanning activities are needed for mitigating the interaction challenges hindering speed.
|
|
| 24. |
- Martini, Antonio, 1982, et al.
(författare)
-
A semi-automated framework for the identification and estimation of Architectural Technical Debt: A comparative case-study on the modularization of a software component
- 2018
-
Ingår i: Information and Software Technology. - : Elsevier BV. - 0950-5849. ; 93, s. 264-279
-
Tidskriftsartikel (refereegranskat)abstract
- Context Research and industry's attention has been focusing on developing systems that enable fast time to market in the short term, but would assure a sustainable delivery of business value and maintenance operations in the long run. A related phenomenon has been identified in Architectural Technical Debt: if the system architecture is sub-optimal for long-term business goals, it might need to be refactored. A key property of the system assuring long-term goals is its modularity, or else the degree to which components are decoupled: such property allows the product to be evolved without costly changes pervading the whole system. However, understanding the business benefits of refactoring to achieve modularity is not trivial, especially for large refactorings involving substantial architectural changes. Objective The aim of this study was to develop a technique to identify Architectural Technical Debt in the form of a non-modularized component and to quantify the convenience of its repayment. Method We have conducted a single, embedded case study in a large company, comparing a component before and after it was refactored to achieve modularity. We have developed a holistic framework for the semi-automated identification and estimation of Architectural Technical Debt in the form of non-modularized components. We then evaluate the technique reporting a comparative study of the difference in maintenance and development costs in two coexisting systems, one including the refactored component and one including the non-refactored one. Results The main contributions are a measurement system for the identification of the Architectural Technical Debt according to the stakeholders’ goals, a mathematical relationship for calculating and quantifying its interest in terms of extra-effort spent in additional development and maintenance, and an overall decision framework to assess the benefit of refactoring. We also report context-specific results that show the estimated benefits of refactoring the specific case of Architectural Technical Debt. Conclusion We found that it is possible to identify this kind of Architectural Technical Debt and to quantify its repayment convenience. Thanks to the developed framework, it was possible to estimate that the Architectural Technical Debt present in the component was causing substantial continuous extra-effort, and that the modularization would be repaid in several months of development and maintenance.
|
|
| 25. |
- Martini, Antonio, 1982
(författare)
-
Ambidexterity in large-scale software engineering
- 2015
-
Doktorsavhandling (övrigt vetenskapligt/konstnärligt)abstract
- Software is pervading our environment with products that become smarter andsmarter every day. In order to follow this trend, software companies delivercontinuously new features, in order to anticipate their competitors and to gain marketshare. For this reason, they need to adopt processes and organization solutions thatallow them to deliver continuously.A key challenge for software organizations is to balance the resources in order todeliver enough new features in the short-term but also to support the delivery of newfeatures in the long-term. In one word, companies need to be ambidextrous. In thisthesis we investigate what ambidexterity is, what are the factors that hinder largesoftware companies to be ambidextrous, and we provide initial solutions for themitigation of such challenges.The research process consists of an empirical investigation based on the GroundedTheory approach, in which we conducted several case studies based on continuousinteraction with 7 large software organizations developing embedded software. Theresults in this thesis are grounded in a large number of data collected, and corroboratedby a combination of exploratory and confirmatory, as well as qualitative andquantitative data collection.The contributions of this thesis include a comprehensive understanding of the factorsinfluencing ambidexterity, the current challenges and a proposed solution, CAFFEA. Inparticular, we found that three main challenges where hampering the achievement ofambidexterity for large software companies. The first one is the conflict between AgileSoftware Development and software reuse. The second one is the complexity ofbalancing short-term and long-term goals among a large number of stakeholders withdifferent views and expertize. The third challenge is the risky tendency, in practice, ofdeveloping systems that does not sustain long-term delivery of new features: this iscaused by the unbalanced focus on short-term deliveries rather than on the systemarchitecture quality. This phenomenon is referred to as Architectural Technical Debt,which is a financial theoretical framework that relates the implementation of suboptimalarchitectural solutions to taking a debt. Even though such sub-optimalsolutions might bring benefits in the short-term, a debt might have an interestassociated with it, which consists of a negative impact on the ability of the softwarecompany to deliver new features in the long-term. If the interest becomes too costly,then the software company suffers delays and development crises. It is thereforeimportant to avoid accumulation, in the system, of Architectural Technical Debt with ahigh interest associated with it.The solution proposed in this thesis is a comprehensive framework, CAFFEA, whichincludes the management of Architectural Technical Debt as a spanning activity (i.e., apractice shared by stakeholders belonging to different groups inside the organization).We have recognized and evaluated the strategic information required to manageArchitectural Technical Debt. Then, we have developed an organizational framework,including roles, teams and practices, which are needed by the involved stakeholders.This solutions have been empirically developed and evaluated, and companies reportinitial benefits of applying the results in practice.
|
|
| 26. |
- Martini, Antonio, 1982, et al.
(författare)
-
An Empirically Developed Method to Aid Decisions on Architectural Technical Debt Refactoring: AnaConDebt
- 2016
-
Ingår i: Proceedings - International Conference on Software Engineering. - New York, NY, USA : ACM. - 0270-5257. - 9781450342056 ; , s. 31-40
-
Konferensbidrag (refereegranskat)abstract
- Architectural Technical Debt is regarded as sub-optimal architectural solutions that need to be refactored in order to avoid the payment of a costly interest in the future. However, decisions on if and when to refactor architecture are extremely important and difficult to take, since changing software at the architectural level is quite expensive. Therefore it is important, for software organizations, to have methods and tools that aid architects and managers to understand if Architecture Technical Debt will generate a costly and growing interest to be paid or not. Current knowledge, especially empirically developed and evaluated, is quite scarce. In this paper we developed and evaluated a method, AnaConDebt, by analyzing, together with several practitioners, 12 existing cases of Architecture Debt in 6 companies. The method has been refined several times in order to be useful and effective in practice. We also report the evaluation of the method with a final case, for which we present anonymized results and subsequent refactoring decisions. The method consists of several components that need to be analyzed, combining the theoretical Technical Debt framework and the practical experience of the practitioners, in order to identify the key factors involved in the growth of interest. The output of the method shows summarized indicators that visualizes the factors in a useful way for the stakeholders. This analysis aids the practitioners in deciding on if and when to refactor Architectural Technical Debt items. The method has been evaluated and has been proven useful to support the architects into systematically analyze and decide upon a case.
|
|
| 27. |
- Martini, Antonio, 1982, et al.
(författare)
-
Architecture Technical Debt: Understanding Causes and a Qualitative Model
- 2014
-
Ingår i: 40th Euromicro Conference on Software Engineering and Advanced Applications. - 1089-6503. - 9781479957958 ; , s. 85-92
-
Konferensbidrag (refereegranskat)abstract
- A known problem in large software companies is to balance the prioritization of short-term with long-term responsiveness. Specifically, architecture violations (Architecture Technical Debt) taken to deliver fast might hinder future feature development, which would hinder agility. We conducted a multiple-case embedded case study in 7 sites at 5 large companies in order to shed light on the current causes for the accumulation of Architectural Technical Debt that causes effort. We provide a taxonomy of the factors and their influence in the accumulation of debt, and we provide a qualitative model of how the debt is accumulated and recovered over time.
|
|
| 28. |
- Martini, Antonio, 1982, et al.
(författare)
-
Communication factors for speed and reuse in large-scale agile software development
- 2013
-
Ingår i: 17th International Software Product Line Conference, August 26-30, Tokyo, Japan. - New York, NY, USA : Association for Computing Machinery (ACM). - 9781450319683
-
Konferensbidrag (refereegranskat)abstract
- An open issue in industry is the combination of software reuse in the context of large scale Agile Software Development. The speed offered by Agile Software Development is needed for short time to market, while reuse strategies such as Software Product Line Engineering are needed for long-term productivity, efficiency, and profit. The paper investigates, through a survey, communication factors affecting both speed and reuse in 3 large companies developing embedded systems and employing Agile Software Development and Software Product Line Engineering. Our results include a prioritized list of communication related factors obtained by statistical analysis and the recognition and spread of the factors in the companies. We have recognized 5 interfaces with the Agile development team that need to be improved: system engineers (architects), product management, distributed teams, inter-project teams and sales unit. Few factors (involving inter-project communication) depend on the business drivers for the company. We also reveal that Agile teams need strategic and architectural inputs in order to be implanted in a large company employing Software Product Line Engineering. Academic and industrial training as well as different tactics for co-location would improve the communication skills of engineers. There is also a need for solutions, in the reference architecture, for fostering Agile Software Development: the goal is the combination of the focus on customer value of the teams, reusability, system requirements and avoidance of organizational dependencies.
|
|
| 29. |
- Martini, Antonio, 1982, et al.
(författare)
-
Enablers and inhibitors for speed with reuse
- 2012
-
Ingår i: ACM International Conference Proceeding Series: 16th International Software Product Line Conference, SPLC 2012; Salvador; 2 September 2012 through 7 September 2012. - New York, NY, USA : ACM. - 9781450310956 ; 1, s. 116-125
-
Konferensbidrag (refereegranskat)abstract
- An open issue in industry is software reuse in the context of large scale Agile product development. The speed offered by agile practices is needed to hit the market, while reuse is needed for long-term productivity, efficiency, and profit. The paper presents an empirical investigation of factors influencing speed and reuse in three large product developing organizations seeking to implement Agile practices. The paper identifies, through a multiple case study with 3 organizations, 114 business-, process-, organizational-, architecture-, knowledge- and communication factors with positive or negative influences on reuse, speed or both. Contributions are a categorized inventory of influencing factors, a display for organizing factors for the purpose of process improvement work, and a list of key improvement areas to address when implementing reuse in organizations striving to become more Agile. Categories identified include good factors with positive influences on reuse or speed, harmful factors with negative influences, and complex factors involving inverse or ambiguous relationships. Key improvement areas in the studied organizations are intra-organizational communication practices, reuse awareness and practices, architectural integration and variability management. Results are intended to support process improvement work in the direction of Agile product development. Feedback on results from the studied organizations has been that the inventory captures current situations, and is useful for software process improvement work.
|
|
| 30. |
- Martini, Antonio, 1982, et al.
(författare)
-
Estimating and Quantifying the Benefits of Refactoring to Improve a Component Modularity: a Case Study
- 2016
-
Ingår i: 2016 42nd Euromicro Conference on Software Engineering and Advanced Applications (Seaa). - : IEEE. - 9781509028191 ; , s. 92-99
-
Konferensbidrag (refereegranskat)abstract
- In recent years, research and industry's attention has been focused on maintaining a system that would both decrease time to market in the short term and assure a sustainable feature output and smooth maintenance operations in the long run. A related phenomenon has been identified in Architectural Technical Debt: if the system architecture is sub-optimal for long-term business goals, it needs to be refactored. A key property of the system assuring long-term goals consists on modularity, or else the ability to decouple different components: such property allows the product to be evolved without costly changes pervading the whole system. However, understanding the business benefits of refactoring to achieve modularity is not trivial, especially for large refactorings involving substantial architectural changes. We have conducted a case study in a large company, analyzing a case of refactoring a component to achieve modularity. We report a comparative study of a refactored against a non-refactored component. We found that the modularization would be repaid in several months of development and maintenance. We present a method to calculate the effort saved by the modularization and an equation for calculating and quantifying the development and maintenance benefits of refactoring.
|
|
| 31. |
- Martini, Antonio, 1982, et al.
(författare)
-
Improving Businesses Success by Managing Interactions among Agile Teams in Large Organizations
- 2013
-
Ingår i: Lecture Notes in Business Information Processing. - Berlin, Heidelberg : Springer Berlin Heidelberg. - 1865-1356 .- 1865-1348. - 9783642393358 ; 150, s. 60-72
-
Konferensbidrag (refereegranskat)abstract
- To achieve successful business, large software companies employ Agile Software Development to be fast and responsive in addressing customer needs. However, a large number of small, independent and fast teams suffer from excessive inter-team interactions, which may lead to paralysis. In this paper we provide a framework to understand how such interactions affect business goals dependent on speed. We detect factors causing observable interaction effects that generate speed waste. By combining data and literature, we provide recommendations to manage such factors, complementing current Agile practices so that they can be adapted in large software organizations.
|
|
| 32. |
- Martini, Antonio, 1982, et al.
(författare)
-
Investigating Architectural Technical Debt accumulation and refactoring over time: A multiple-case study
- 2015
-
Ingår i: Information and Software Technology. - : Elsevier BV. - 0950-5849. ; 67, s. 237-253
-
Tidskriftsartikel (refereegranskat)abstract
- Context A known problem in large software companies is to balance the prioritization of short-term with long-term feature delivery speed. Specifically, Architecture Technical Debt is regarded as sub-optimal architectural solutions taken to deliver fast that might hinder future feature development, which, in turn, would hinder agility. Objective This paper aims at improving software management by shedding light on the current factors responsible for the accumulation of Architectural Technical Debt and to understand how it evolves over time. Method We conducted an exploratory multiple-case embedded case study in 7 sites at 5 large companies. We evaluated the results with additional cross-company interviews and an in-depth, company-specific case study in which we initially evaluate factors and models. Results We compiled a taxonomy of the factors and their influence in the accumulation of Architectural Technical Debt, and we provide two qualitative models of how the debt is accumulated and refactored over time in the studied companies. We also list a set of exploratory propositions on possible refactoring strategies that can be useful as insights for practitioners and as hypotheses for further research. Conclusion Several factors cause constant and unavoidable accumulation of Architecture Technical Debt, which leads to development crises. Refactorings are often overlooked in prioritization and they are often triggered by development crises, in a reactive fashion. Some of the factors are manageable, while others are external to the companies. ATD needs to be made visible, in order to postpone the crises according to the strategic goals of the companies. There is a need for practices and automated tools to proactively manage ATD.
|
|
| 33. |
- Martini, Antonio, 1982
(författare)
-
Managing Speed in Companies Developing Large-Scale Embedded Systems
- 2013
-
Ingår i: Lecture Notes in Business Information Processing. - Berlin, Heidelberg : Springer Berlin Heidelberg. - 1865-1356 .- 1865-1348. - 9783642393365 ; 150, s. 231-232
-
Konferensbidrag (refereegranskat)abstract
- An open issue is how to reach quickness and responsiveness in addressing customer needs within large-scale embedded system product development, where the processes are bound to the physical product development. Speed is a key quality that needs particular attention. We are developing a framework to understand what kinds of speed are important, what factors are determining them, what are the visible effects and what is possible to improve in order to reach speed related business goals.
|
|
| 34. |
- Martini, Antonio, 1982
(författare)
-
On the continuous inter-group interaction speed improvement in large-scale agile software development for embedded software
- 2013
-
Licentiatavhandling (övrigt vetenskapligt/konstnärligt)abstract
- An open issue in industry is how to scale-up Agile Software Development in large companies developing embedded systems. Intra-team interaction is well supported by established Agile practices, while how to handle the feedback for the Agile team from other teams and other parts of the organization is still unexplored. The adaptation of Agile Software Development (ASD) to em- bedded software, driven by an overall physical product development process, brings challenges in terms of dependencies on parallel engineering and manage- ment activities. Such interactions slow down the development, hindering the achievement of business goals based on speed, such as a short time to market, the quick replication of products of a product-line, or the reaction time for a change request. This thesis is based on a 2-year-long action research strategy, collecting data through interviews, a survey (questionnaire) and focus groups in 3 large companies developing embedded software. Through a combination of Grounded Theory (qualitative) and statistical (quantitative) analysis, to- gether with continuous empirical validation of results, we have developed a framework for monitoring and improving interaction speed. The purpose of such a framework is to identify and eliminate speed waste caused by interac- tion issues. The final goal is to improve the feedback between the development team and specifically selected parts of the organization that, we show, are crit- ical. The framework involves the recognition of visible symptoms leading to the underlying causes (factors) and the application of a set of practices for the mitigation of such factors. Such practices represent steps and activities to be implemented for software process improvement (SPI).
|
|
| 35. |
- Martini, Antonio, 1982, et al.
(författare)
-
On the interest of architectural technical debt: Uncovering the contagious debt phenomenon
- 2017
-
Ingår i: Journal of Software: Evolution and Process. - : Wiley. - 2047-7481 .- 2047-7473. ; 29:10
-
Tidskriftsartikel (refereegranskat)abstract
- A known problem in large software companies is to balance the prioritization of short-term and long-term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi-phase, multiple-case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra-activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises.
|
|
| 36. |
- Martini, Antonio, 1982, et al.
(författare)
-
Process Debt: a First Exploration
- 2020
-
Ingår i: Proceedings - Asia-Pacific Software Engineering Conference, APSEC. - 1530-1362. ; 2020-December, s. 316-325
-
Konferensbidrag (refereegranskat)abstract
- Process Debt, like Technical Debt, can be the source of short-term benefits but often is harmful in the long term for a software organization. However, we do not know much about Process Debt from current literature. We conducted an exploratory study of Process Debt in four international organizations by interviewing 16 practitioners. The findings show that Process Debt can be a harmful phenomenon that needs attention and new practices, as it is different from Technical Debt. We provide an initial framework, composed by a definition and a conceptual model for Process Debt, showing types, causes, consequences, and debt accumulation patterns.
|
|
| 37. |
- Martini, Antonio, 1982, et al.
(författare)
-
Revealing social debt with the CAFFEA framework: An antidote to architectural debt
- 2017
-
Ingår i: Proceedings - 2017 IEEE International Conference on Software Architecture Workshops, ICSAW 2017: Side Track Proceedings. - 9781509047932 ; , s. 179-181
-
Konferensbidrag (refereegranskat)abstract
- Large software companies need a well-managed Software Architecture to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both evolution and maintenance of existing systems are hampered by Architectural Technical Debt. To avoid the accumulation and the costly consequences of ATD, it is critical that the responsibilities to minimize it are well understood and shared in a large software organization. In this paper, we argue that an organizational model, based on a well validated framework such as CAFFEA, can be used to reveal sub-optimalities in the social structure of the organization: in other words, it can reveal Social Debt. Such sub-optimality, according to previous work, leads to the accumulation of ATD. In conclusion, using the CAFFEA framework as an organizational analysis tool, can reveal weak spots (Social Debt) in the organization and can help preventing costly ATD and its consequences.
|
|
| 38. |
- Martini, Antonio, 1982, et al.
(författare)
-
Role of Architects in Agile Organizations
- 2014
-
Ingår i: Continuous Software Engineering. - Cham : Springer. - 9783319112824 ; 9783319112831, s. 39-50
-
Bokkapitel (övrigt vetenskapligt/konstnärligt)abstract
- Agile software development is broadly adopted in industry and works well for small-scale projects. In the context of large-scale development, however, there is a need for additional structure in the form of roles and practices, especially in the area of software architecture. In this chapter, we introduce the CAFFEA framework that defines a model for architecture governance. The framework defines three roles, i.e., chief architect, governance architect, and team architect, as well as a set of practices and responsibilities assigned to these roles. The CAFFEA framework has been developed and validated in close collaboration with several companies.
|
|
| 39. |
- Martini, Antonio, 1982, et al.
(författare)
-
Teams Interactions Hindering Short-Term and Long-Term Business Goals
- 2014
-
Ingår i: Continuous Software Engineering. - Cham : Springer. - 9783319112824 ; 9783319112831, s. 51-65
-
Bokkapitel (övrigt vetenskapligt/konstnärligt)abstract
- A known problem in large software companies is to balance the return on investment coming from short-term and long-term business goals dependent on the responsiveness of the companies. We have conducted an investigation on three large product line companies employing Agile software development (ASD) to better understand this problem: we have recognized several challenges that were hindering one or both kinds of business goals. Interaction challenges were quite critical among the Agile teams but also between the Agile team and other parts of the organization, such as architects and product management. We also further investigated which root factors were behind the interaction challenges, what symptoms can be recognized in the organization to spot the interaction challenges, and how they were related to the recent employment of ASD in the companies.
|
|
| 40. |
- Martini, Antonio, 1982, et al.
(författare)
-
Technical debt interest assessment: From issues to project
- 2017
-
Ingår i: ACM International Conference Proceeding Series. - New York, NY, USA : ACM. - 9781450352642 ; Part F129907
-
Konferensbidrag (refereegranskat)abstract
- The interest of Technical Debt (TD) is difcult to calculate, especially on a project level. Current approaches are based on fne-grain issue assessment, but there is no evidence about how TD is assessed on a project level. A few tools use an aggregation function that sum the TD issues on a project level. We conducted a multiple case-study on four diferent projects. We asked the project teams to assess the TD both on an issue level and on a project level. We also asked the product manager and a senior developer to assess the TD on a project level. We found that the function mapping the interest of TD to a project overall is not the sum of issue-level TD. We report the quantitative results of the performed experiment and we also developed a qualitative explanation of the results based on interviews with the development team. This paper represents a frst step towards assessing the interest of TD at a project level.
|
|
| 41. |
- Martini, Antonio, 1982, et al.
(författare)
-
Technical Debt tracking: Current state of practice: A survey and multiple case study in 15 large organizations
- 2018
-
Ingår i: Science of Computer Programming. - : Elsevier BV. - 0167-6423. ; 163, s. 42-61
-
Tidskriftsartikel (refereegranskat)abstract
- Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both the evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been produced recently, its practical management lacks empirical studies. In this paper, we investigate the state of practice in several companies to understand what the cost of managing TD is, what tools are used to track TD, and how a tracking process is introduced in practice. We combined two phases: a survey involving 226 respondents from 15 organizations and an in-depth multiple case study in three organizations including 13 interviews and 79 Technical Debt issues. We selected the organizations where Technical Debt was better tracked in order to distill best practices. We found that the development time dedicated to managing Technical Debt is substantial (an average of 25% of the overall development), but mostly not systematic: only a few participants (26%) use a tool, and only 7.2% methodically track Technical Debt. We found that the most used and effective tools are currently backlogs and static analyzers. By studying the approaches in the companies participating in the case study, we report how companies start tracking Technical Debt and what the initial benefits and challenges are. Finally, we propose a Strategic Adoption Model for the introduction of tracking Technical Debt in software organizations.
|
|
| 42. |
- Martini, Antonio, 1982, et al.
(författare)
-
The Danger of Architectural Technical Debt: Contagious Debt and Vicious Circles
- 2015
-
Ingår i: Proceedings - 12th Working IEEE/IFIP Conference on Software Architecture, WICSA 2015. - 9781479919222 ; , s. 1-10
-
Konferensbidrag (refereegranskat)abstract
- A known problem in large software companies is to balance the prioritization of short-term with long-term viability. Specifically, architecture violations (Architecture Technical Debt) taken to deliver fast might hinder future feature development. However, some technical debt requires more interest to be paid than other. We have investigated which Technical Debt items generate more effort and how this effort is manifested during software development. We conducted a multiple-case embedded case study comprehending 7 sites at 5 large international software companies. We found that some Technical Debt items are contagious, causing other parts of the system to be contaminated with the same problem, which may lead to non-linear growth of interest. We also identify another socio-technical phenomenon, for which a combination of weak awareness of debt, time pressure and refactoring creates Vicious Circles of events during the development. Such phenomena need to be identified and stopped before the development is led to a crisis point. Finally, this paper presents a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics.
|
|
| 43. |
- Martini, Antonio, 1982, et al.
(författare)
-
The Introduction of Technical Debt Tracking in Large Companies - A Survey and Multiple Case-Study
- 2016
-
Ingår i: 2016 23rd Asia-Pacific Software Engineering Conference (APSEC).
-
Konferensbidrag (refereegranskat)abstract
- Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both the evolution and maintenance of existing systems are hampered by what has been recently called Technical Debt. Although a lot of theoretical work on Technical Debt has been recently produced, its practical management lacks empirical studies. In this paper we investigate the state of practice in several companies in order to understand how they start tracking Technical Debt. We combined different methodologies: we conducted a survey, involving 226 respondents from 15 organizations and a more in-depth multiple case-study in three organizations, where Technical Debt was tracked: we involved 13 interviews and 79 Technical Debt issues analysis. We found that the development time dedicated to manage Technical Debt is substantial (around 25%) but not systematic: only a few participants currently track Technical Debt. By studying the early approaches in the companies participating in the case-study, we understood how companies start tracking Technical Debt and what are the initial benefits and challenges. Finally, we propose a Strategic Adoption Model based to define and adopt a dedicated process for tracking Technical Debt.
|
|
| 44. |
- Martini, Antonio, 1982, et al.
(författare)
-
The introduction of technical debt tracking in large companies. A Survey and Multiple Case-Study
- 2016
-
Ingår i: Proceedings - Asia-Pacific Software Engineering Conference, APSEC. - 1530-1362. ; 0, s. 161-168
-
Konferensbidrag (refereegranskat)abstract
- Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been recently produced, its practical management lacks empirical studies. In this paper we investigate the state of practice in several companies in order to understand how they start tracking Technical Debt. We combined different methodologies: we conducted a survey, involving 226 respondents from 15 organizations and a more in-depth multiple case-study in three organizations, where Technical Debt was tracked: we involved 13 interviews and 79 Technical Debt issues analysis. We found that the development time dedicated to manage Technical Debt is substantial (around 25% of the overall development) but not systematic: only a few participants methodically track Technical Debt. By studying the approaches in the companies participating in the case-study, we understood how companies start tracking Technical Debt and what are the initial benefits and challenges. Finally, we propose a Strategic Adoption Model based to define and adopt a dedicated process for tracking Technical Debt.
|
|
| 45. |
- Martini, Antonio, 1982, et al.
(författare)
-
The magnificent seven: Towards a systematic estimation of technical debt interest
- 2017
-
Ingår i: ACM International Conference Proceeding Series. - New York, NY, USA : ACM. - 9781450352642 ; Part F129907
-
Konferensbidrag (refereegranskat)abstract
- The interest of Technical Debt is difcult to assess. The negative efects (severity) of Technical Debt might depend on the context of the organization and the estimations might be subjective. There is a need for assessing Technical Debt interest in a more systematic way. Based on the results of previous research, we have developed and used a lightweight tool, AnaConDebt, to assess the severity of the interest of 9 Technical Debt items with the stakeholders in 3 Agile teams. The systematic and semi-automatic assessment of seven factors and their growth has been compared to the stakeholders' intuitive estimations. The results show that the outcome of the tool is very close to the estimation given by the stakeholders. The implications are that, if further data support the hypothesis, the severity of the interest can be systematically assessed by the stakeholders by estimating only seven factors in a cost-efective manner with acceptable results.
|
|
| 46. |
- Martini, Antonio, 1982, et al.
(författare)
-
Towards introducing agile architecting in large companies: The CAFFEA framework
- 2015
-
Ingår i: Lecture Notes in Business Information Processing, Agile Processes in Software Engineering, and Extreme Programming 16th International Conference, XP 2015, Helsinki, Finland, May 25-29, 2015. - Cham : Springer International Publishing. - 1865-1348 .- 1865-1356. - 9783319186115 ; 212
-
Konferensbidrag (refereegranskat)abstract
- To continuously deliver value both in short-term and long-term, a key goal for large product lines companies is to combine Agile Software Development with the continuous development and management of software architecture. We have conducted interviews involving several roles at 3 sites from 2 large companies employing Agile. We have identified current architect roles and gaps in the practices employed at the organizations. From such investigation, we have developed an organizational framework, CAFFEA, for Agile architecting, including roles, teams and practices.
|
|
| 47. |
- Martini, Antonio, 1982, et al.
(författare)
-
Towards Prioritizing Architecture Technical Debt: Information Needs of Architects and Product Owners
- 2015
-
Ingår i: 41st Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 26-28 August, 2015. - 9781467375856 ; , s. 422-429
-
Konferensbidrag (refereegranskat)abstract
- Architectural Technical Debt is a metaphor for representing sub-optimal architectural solutions that might cause an interest, in terms of effort or quality, to be paid by the organization in the long run. Such metaphor has been regarded as useful for communicating risks of suboptimal solutions between technical and non-technical stakeholders. However, it's fundamental to understand the information needs of the involved stakeholders in order to produce technical debt measurements that would allow proper communication and informed prioritization. We have investigated, through a combination of interviews, observations and a survey, what key information is needed by agile product owners and software architects in order to prioritize the refactoring of risky architectural technical debt items with respect to feature development.
|
|
| 48. |
- Vogel-Heuser, B., et al.
(författare)
-
Technical debt in Automated Production Systems
- 2015
-
Ingår i: 7th International Workshop on Managing Technical Debt, MTD 2015, Bremen, Germany. - 9781467373784 ; , s. 49-52
-
Konferensbidrag (refereegranskat)abstract
- The term technical debt borrowed from financial debt describes the long-term negative effects of sub-optimal solutions to achieve short-term benefits. It has been widely studied so far in pure software systems. However, there is a lack of studies on technical debt in technical systems, which contain mechanical, electrical and software parts. Automated Production Systems are such technical systems. In this position paper, we introduce technical debt for Automated Production Systems and give examples from the different disciplines. Based on that description, we outline future research directions on technical debt in this field.
|
|
| 49. |
- Wang, Xiaofeng, et al.
(författare)
-
Special section on IST for ICSOB2021
- 2023
-
Ingår i: Information and Software Technology. - : Elsevier. - 0950-5849 .- 1873-6025. ; 160
-
Tidskriftsartikel (övrigt vetenskapligt/konstnärligt)
|
|
