Josep Burgaya Pujols, Pieter Bas, Silverio Martínez-Fernández, A. Martini, Adam Trendowicz
As the development progresses, software projects tend to accumulate Technical Debt and become harder to maintain. Multiple tools exist with the mission to help practitioners to better manage Technical Debt. Despite this progress, there is a lack of tools providing actionable and self-learned suggestions to practitioners aimed at mitigating the impact of Technical Debt in real projects. We aim to create a data-driven, lightweight, and self-learning tool positioning highly impactful refactoring proposals on a Jira backlog. Bearing this goal in mind, the first two authors have founded a startup, called Skuld.ai, with the vision of becoming the go-to software renovation company. In this tool paper, we present the software architecture and demonstrate the main functionalities of our tool. It has been showcased to practitioners, receiving positive feedback. Currently, its release to the market is underway thanks to an industry-research institute collaboration with Fraunhofer IESE to incorporate self-learning technical debt capabilities.
{"title":"Skuld: A self-learning tool for impact-driven technical debt management","authors":"Josep Burgaya Pujols, Pieter Bas, Silverio Martínez-Fernández, A. Martini, Adam Trendowicz","doi":"10.1145/3387906.3388626","DOIUrl":"https://doi.org/10.1145/3387906.3388626","url":null,"abstract":"As the development progresses, software projects tend to accumulate Technical Debt and become harder to maintain. Multiple tools exist with the mission to help practitioners to better manage Technical Debt. Despite this progress, there is a lack of tools providing actionable and self-learned suggestions to practitioners aimed at mitigating the impact of Technical Debt in real projects. We aim to create a data-driven, lightweight, and self-learning tool positioning highly impactful refactoring proposals on a Jira backlog. Bearing this goal in mind, the first two authors have founded a startup, called Skuld.ai, with the vision of becoming the go-to software renovation company. In this tool paper, we present the software architecture and demonstrate the main functionalities of our tool. It has been showcased to practitioners, receiving positive feedback. Currently, its release to the market is underway thanks to an industry-research institute collaboration with Fraunhofer IESE to incorporate self-learning technical debt capabilities.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130659501","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it is particularly effective, as developers are experts in their own code and are best-suited to fix the corresponding TD issues. To what extent is TD self-fixed, which types of TD are more likely to be self-fixed and is the remediation time of self-fixed TD shorter than non-self-fixed TD? This paper attempts to answer these questions. It reports on an empirical study that analyzes the self-fixed issues of five types of TD (i.e., Code, Defect, Design, Documentation and Test), captured via static analysis, in more than 17,000 commits from 20 Python projects of the Apache Software Foundation. The results show that more than two thirds of the issues are self-fixed and that the self-fixing rate is negatively correlated with the number of commits, developers and project size. Furthermore, the survival time of self-fixed issues is generally shorter than non-self-fixed issues. Moreover, the majority of Defect Debt tends to be self-fixed and has a shorter survival time, while Test Debt and Design Debt are likely to be fixed by other developers. These results can benefit both researchers and practitioners by aiding the prioritization of TD remediation activities within development teams, and by informing the development of TD management tools.
{"title":"An Empirical Study on Self-Fixed Technical Debt","authors":"Jie Tan, Daniel Feitosa, P. Avgeriou","doi":"10.1145/3387906.3388621","DOIUrl":"https://doi.org/10.1145/3387906.3388621","url":null,"abstract":"Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it is particularly effective, as developers are experts in their own code and are best-suited to fix the corresponding TD issues. To what extent is TD self-fixed, which types of TD are more likely to be self-fixed and is the remediation time of self-fixed TD shorter than non-self-fixed TD? This paper attempts to answer these questions. It reports on an empirical study that analyzes the self-fixed issues of five types of TD (i.e., Code, Defect, Design, Documentation and Test), captured via static analysis, in more than 17,000 commits from 20 Python projects of the Apache Software Foundation. The results show that more than two thirds of the issues are self-fixed and that the self-fixing rate is negatively correlated with the number of commits, developers and project size. Furthermore, the survival time of self-fixed issues is generally shorter than non-self-fixed issues. Moreover, the majority of Defect Debt tends to be self-fixed and has a shorter survival time, while Test Debt and Design Debt are likely to be fixed by other developers. These results can benefit both researchers and practitioners by aiding the prioritization of TD remediation activities within development teams, and by informing the development of TD management tools.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125025082","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
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.
{"title":"Carrot and Stick approaches when managing Technical Debt","authors":"Terese Besker, A. Martini, J. Bosch","doi":"10.1145/3387906.3388619","DOIUrl":"https://doi.org/10.1145/3387906.3388619","url":null,"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.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121048880","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In this paper we present Software Archinaut--a tool used to help identify technical debt hotspots in an architecture, and manage the evolution of the architecture once these hotspots are discovered. Archinaut is a platform that integrates analyses from different tools. It supports three main usage scenarios: 1) understanding the architecture, 2) identifying technical debt hotspots, and 3) monitoring and controlling the evolution of the architecture. We illustrate these scenarios by using Apache Kafka as an example.
{"title":"Software Archinaut: A Tool to Understand Architecture, Identify Technical Debt Hotspots and Manage Evolution : Tool Presentation Paper","authors":"H. Cervantes, R. Kazman","doi":"10.1145/3387906.3388633","DOIUrl":"https://doi.org/10.1145/3387906.3388633","url":null,"abstract":"In this paper we present Software Archinaut--a tool used to help identify technical debt hotspots in an architecture, and manage the evolution of the architecture once these hotspots are discovered. Archinaut is a platform that integrates analyses from different tools. It supports three main usage scenarios: 1) understanding the architecture, 2) identifying technical debt hotspots, and 3) monitoring and controlling the evolution of the architecture. We illustrate these scenarios by using Apache Kafka as an example.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"261 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115895579","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Laura Waltersdorfer, Felix Rinker, Lukas Kathrein, S. Biffl
Technical Debt (TD) has proven to be a suitable communication concept for software-intensive contexts to raise awareness regarding longterm negative effects of deviations from standards and guidelines. TD has also been introduced to systems engineering domain, to communicate design shortcomings in long-running, software-assisted systems. We analysed potential TD in the engineering data exchange for production system engineering. Similar to requirements engineering in software-intensive systems, data exchange in the design phase plays an integral part in Software Engineering (SE) for Production Systems Engineering: Specifications, and physical logic have to be derived from heterogeneous plant models or parameter tables designed by different stakeholders. However, traditional procedures and inadequate tool support lead to inefficient data extraction and integration. We identified debt arising from knowledge representation, data model and the exchange process. The refinement validation of identified TD was achieved through semi-structured interviews with representatives in two analysed companies. In an online survey with ten participants from an industrial consortium we evaluated whether the identified TD concepts also applied to other companies, which is true for the majority of TD. Furthermore, we discuss promising TD management strategies to repay and manage negative effects and the accumulation of additional debt, such as improved communication, test-driven model engineering and visualisation of engineering models.
{"title":"Experiences with Technical Debt and Management Strategies in Production Systems Engineering","authors":"Laura Waltersdorfer, Felix Rinker, Lukas Kathrein, S. Biffl","doi":"10.1145/3387906.3388627","DOIUrl":"https://doi.org/10.1145/3387906.3388627","url":null,"abstract":"Technical Debt (TD) has proven to be a suitable communication concept for software-intensive contexts to raise awareness regarding longterm negative effects of deviations from standards and guidelines. TD has also been introduced to systems engineering domain, to communicate design shortcomings in long-running, software-assisted systems. We analysed potential TD in the engineering data exchange for production system engineering. Similar to requirements engineering in software-intensive systems, data exchange in the design phase plays an integral part in Software Engineering (SE) for Production Systems Engineering: Specifications, and physical logic have to be derived from heterogeneous plant models or parameter tables designed by different stakeholders. However, traditional procedures and inadequate tool support lead to inefficient data extraction and integration. We identified debt arising from knowledge representation, data model and the exchange process. The refinement validation of identified TD was achieved through semi-structured interviews with representatives in two analysed companies. In an online survey with ten participants from an industrial consortium we evaluated whether the identified TD concepts also applied to other companies, which is true for the majority of TD. Furthermore, we discuss promising TD management strategies to repay and manage negative effects and the accumulation of additional debt, such as improved communication, test-driven model engineering and visualisation of engineering models.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"7 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126202451","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Reem Alfayez, Wesam Alwehaibi, R. Winn, Elaine Venson, B. Boehm
Repaying all technical debt (TD) present in a system may be unfeasible, as there is typically a shortage in the resources allocated for TD repayment. Therefore, TD prioritization is essential to best allocate such resources to determine which TD items are to be repaid first and which items are to be delayed until later releases. This study conducts a systematic literature review (SLR) to identify and analyze the currently researched TD prioritization approaches. The employed search strategy strove to achieve high completeness through the identification of a quasi-gold standard set, which was used to establish a search string to automatically retrieve papers from select research databases. The application of selection criteria, along with forward and backward snowballing, identified 24 TD prioritization approaches. The analysis of the identified approaches revealed a scarcity of approaches that account for cost, value, and resources constraint and a lack of industry evaluation. Furthermore, this SLR unveils potential gaps in the current TD prioritization research, which future research may explore.
{"title":"A Systematic Literature Review of Technical Debt Prioritization","authors":"Reem Alfayez, Wesam Alwehaibi, R. Winn, Elaine Venson, B. Boehm","doi":"10.1145/3387906.3388630","DOIUrl":"https://doi.org/10.1145/3387906.3388630","url":null,"abstract":"Repaying all technical debt (TD) present in a system may be unfeasible, as there is typically a shortage in the resources allocated for TD repayment. Therefore, TD prioritization is essential to best allocate such resources to determine which TD items are to be repaid first and which items are to be delayed until later releases. This study conducts a systematic literature review (SLR) to identify and analyze the currently researched TD prioritization approaches. The employed search strategy strove to achieve high completeness through the identification of a quasi-gold standard set, which was used to establish a search string to automatically retrieve papers from select research databases. The application of selection criteria, along with forward and backward snowballing, identified 24 TD prioritization approaches. The analysis of the identified approaches revealed a scarcity of approaches that account for cost, value, and resources constraint and a lack of industry evaluation. Furthermore, this SLR unveils potential gaps in the current TD prioritization research, which future research may explore.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130533324","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Ilaria Pigazzini, F. Fontana, Valentina Lenarduzzi, D. Taibi
With the adoption of microservices architectural styles, practitioners started noticing increasing pitfalls in managing and maintaining such architectures, with the risk of introducing architectural debt. Previous studies identified different microservice smells (also named anti-patterns) that harm microservices architectures. However, according to our knowledge, there are no tools that can automatically detect microservice smells, so their identification is left to the experience of the developer. In this paper, we extend an existing tool developed for the detection of architectural smells to explore microservices architecture through the detection of three microservice smells: Cyclic Dependencies, Hard-Coded Endpoints, and Shared Persistence. We detected the smells on five open-source projects implemented with microservices and manually validated the precision of the detection results. This work aims to open new perspectives on facing and studying architectural debt in the field of microservices architectures.
{"title":"Towards Microservice Smells Detection","authors":"Ilaria Pigazzini, F. Fontana, Valentina Lenarduzzi, D. Taibi","doi":"10.1145/3387906.3388625","DOIUrl":"https://doi.org/10.1145/3387906.3388625","url":null,"abstract":"With the adoption of microservices architectural styles, practitioners started noticing increasing pitfalls in managing and maintaining such architectures, with the risk of introducing architectural debt. Previous studies identified different microservice smells (also named anti-patterns) that harm microservices architectures. However, according to our knowledge, there are no tools that can automatically detect microservice smells, so their identification is left to the experience of the developer. In this paper, we extend an existing tool developed for the detection of architectural smells to explore microservices architecture through the detection of three microservice smells: Cyclic Dependencies, Hard-Coded Endpoints, and Shared Persistence. We detected the smells on five open-source projects implemented with microservices and manually validated the precision of the detection results. This work aims to open new perspectives on facing and studying architectural debt in the field of microservices architectures.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129648716","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Context: The micro-services architectural pattern advocates for the partitioning of functionality into loosely coupled services, which should be backward compatible, to enable independent upgrades. Deprecation is commonly used as a tool to manage multiple versions of methods or services. However, deprecation carries a cost in that tests might be duplicated and might rely on services that have become deprecated over time.Objective: Using the terms of the Technical Debt metaphor, we explore the consequences of deprecation, and how it has affected the test base during seven years.Method: We take an exploratory approach, reporting on experiences found before and after servicing parts of the incurred Technical Debt. We mine code repositories and validate our findings with experienced developers.Results: We found that the growth of deprecation debt varied a lot. Some services experienced substantial growth, but most did not. Unit tests, where deprecation is visible in the developers’ tools, were much less affected than integration tests, which lack such visualization mechanisms. While servicing debt of 121 out of 285 deprecated services, we discovered that up to 29% of the spent effort could be attributed to accrued interest. However, this is an upper bound; there could be less impact, depending on whether scripting could be used to service the debt or not.Conclusion: This paper illustrates that integration tests can be viewed as a debt from the perspective of deprecated services. While the pattern was that deprecated services (debt principal) experienced no or little accrued interest, some, highly used, services experienced a lot, particularly during stressful times. Java-based tests, where deprecation is visible in the IDE, did not experience a similar pattern of increasing debt. We postulate that deprecation debt should be kept visible, either using developer tools or statistical reports.
{"title":"The Hidden Cost of Backward Compatibility: When Deprecation Turns into Technical Debt - An Experience Report","authors":"Anders Sundelin, J. Gonzalez-Huerta, K. Wnuk","doi":"10.1145/3387906.3388629","DOIUrl":"https://doi.org/10.1145/3387906.3388629","url":null,"abstract":"Context: The micro-services architectural pattern advocates for the partitioning of functionality into loosely coupled services, which should be backward compatible, to enable independent upgrades. Deprecation is commonly used as a tool to manage multiple versions of methods or services. However, deprecation carries a cost in that tests might be duplicated and might rely on services that have become deprecated over time.Objective: Using the terms of the Technical Debt metaphor, we explore the consequences of deprecation, and how it has affected the test base during seven years.Method: We take an exploratory approach, reporting on experiences found before and after servicing parts of the incurred Technical Debt. We mine code repositories and validate our findings with experienced developers.Results: We found that the growth of deprecation debt varied a lot. Some services experienced substantial growth, but most did not. Unit tests, where deprecation is visible in the developers’ tools, were much less affected than integration tests, which lack such visualization mechanisms. While servicing debt of 121 out of 285 deprecated services, we discovered that up to 29% of the spent effort could be attributed to accrued interest. However, this is an upper bound; there could be less impact, depending on whether scripting could be used to service the debt or not.Conclusion: This paper illustrates that integration tests can be viewed as a debt from the perspective of deprecated services. While the pattern was that deprecated services (debt principal) experienced no or little accrued interest, some, highly used, services experienced a lot, particularly during stressful times. Java-based tests, where deprecation is visible in the IDE, did not experience a similar pattern of increasing debt. We postulate that deprecation debt should be kept visible, either using developer tools or statistical reports.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124000997","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper introduces the concept of energy debt: a new metric, reflecting the implied cost in terms of energy consumption over time, of choosing a flawed implementation of a software system rather than a more robust, yet possibly time consuming, approach. A flawed implementation is considered to contain code smells, known to have a negative influence on the energy consumption.Similar to technical debt, if energy debt is not properly addressed, it can accumulate an energy “interest”. This interest will keep increasing as newversions of the software are released, and eventually reach a point where the interest will be higher than the initial energy debt. Addressing the issues/smells at such a point can remove energy debt, at the cost of having already consumed a significant amount of energy which can translate into high costs. We present all underlying concepts of energy debt, bridging the connection with the existing concept of technical debt and show how to compute the energy debt through a motivational example.
{"title":"On Energy Debt : Managing Consumption on Evolving Software","authors":"Marco Couto, Daniel Maia, J. Saraiva, Rui Pereira","doi":"10.1145/3387906.3388628","DOIUrl":"https://doi.org/10.1145/3387906.3388628","url":null,"abstract":"This paper introduces the concept of energy debt: a new metric, reflecting the implied cost in terms of energy consumption over time, of choosing a flawed implementation of a software system rather than a more robust, yet possibly time consuming, approach. A flawed implementation is considered to contain code smells, known to have a negative influence on the energy consumption.Similar to technical debt, if energy debt is not properly addressed, it can accumulate an energy “interest”. This interest will keep increasing as newversions of the software are released, and eventually reach a point where the interest will be higher than the initial energy debt. Addressing the issues/smells at such a point can remove energy debt, at the cost of having already consumed a significant amount of energy which can translate into high costs. We present all underlying concepts of energy debt, bridging the connection with the existing concept of technical debt and show how to compute the energy debt through a motivational example.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131690969","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Systems Engineering is a matter of the perspective and scope where several principles of the systems thinking approach coincide. Following the fundamental system principle of holism and interaction theory, in order to understand the whole the system should be considered as a whole. Due to the phenomena of emergence, not all properties of a system can be determined or explained by its components alone. The conceptual model of Technical Debt already recognize the context sensitivity of Technical Debt as an essential factor and identifies phenomena that fall outside the core definition of Technical Debt as a major part of future research.This short paper shows why managing the parts does not equal managing the whole by introducing Technical Debt as an emergent characteristic and why the traditional Technical Debt-Management methods can only be partially applied to Systems of Systems.
{"title":"Towards Collaborative Technical Debt Management in Systems of Systems","authors":"J. Schütz, J. Gómez","doi":"10.1145/3387906.3388620","DOIUrl":"https://doi.org/10.1145/3387906.3388620","url":null,"abstract":"Systems Engineering is a matter of the perspective and scope where several principles of the systems thinking approach coincide. Following the fundamental system principle of holism and interaction theory, in order to understand the whole the system should be considered as a whole. Due to the phenomena of emergence, not all properties of a system can be determined or explained by its components alone. The conceptual model of Technical Debt already recognize the context sensitivity of Technical Debt as an essential factor and identifies phenomena that fall outside the core definition of Technical Debt as a major part of future research.This short paper shows why managing the parts does not equal managing the whole by introducing Technical Debt as an emergent characteristic and why the traditional Technical Debt-Management methods can only be partially applied to Systems of Systems.","PeriodicalId":345508,"journal":{"name":"2020 IEEE/ACM International Conference on Technical Debt (TechDebt)","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134332896","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：