Change search
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf
Understanding Asset Degradation in Software Engineering
Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.ORCID iD: 0000-0002-1729-5154
2023 (English)Doctoral thesis, comprehensive summary (Other academic)
Abstract [en]

Background: As software is everywhere, and almost every company has nowadays a dependency on software, designing and developing software-intensive products or services has become significantly challenging and time-consuming. The challenges are due to the continuous growth of the size and complexity of software and the fast pace of change. It is important that software-developing organisations’ engineering practices adapt to the rising challenges by adopting well-engineered development activities. Organisations deal with many software artefacts, some of which are more relevant for the organisation. We define Software Assets as artefacts intended to be used more than once. Given softwared evelopment’s continuous and evolutionary aspect, the assets involved degrade over time. Organisations need to understand what assets are relevant and how they degrade to exercise quality control over software assets. Asset degradation is inevitable, and it may manifest in different ways. 

Objective: The main objective of this thesis is: (i) to contribute to the software engineering body of knowledge by providing an understanding of what assets are and how they degrade; and (ii) to gather empirical evidence regarding asset degradation and different factors that might impact it on industrial settings. 

Method: To achieve the thesis goals, several studies have been conducted. The collected data is from peer-reviewed literature and collaboration with five companies that included extracting archival data from over 20 million LOC and archival data from open-source repositories. 

Results: The first contribution of this thesis is defining the concept of assets and asset degradation in a position paper. We aim to provide an understanding of software assets and asset degradation and its impact on software development.  Additionally, a taxonomy of assets is created using academic and industrial input. The taxonomy includes 57 assets and their categories. To further investigate the concept of asset degradation, we have conducted in-depth analyses of multiple industrial case studies on selected assets. This thesis presents results to provide evidence on the impact of different factors on asset degradation, including: (I) how the accumulation of technical debt is affected by different development activities; (ii) how degradation ‘survives’; and (iii) how working from home or the misalignment between ownership and contribution impacts the faster accumulation of asset degradation. Additionally, we created a model to calculate the degree of the alignment between ownership and contribution to code. 

Conclusion: The results can help organisations identify and understand the relevant software assets and characterize their quality degradation. Understanding how assets degrade and which factors might impact their faster accumulation is the first step to conducting sufficient and practical asset management activities. For example, by engaging (i) proactively in preventing uncontrolled growth of degradation (e.g., aligning ownership and contribution); and (ii) reactively in prioritizing mitigation strategies and activities (focusing on recently introducing TD items).

Place, publisher, year, edition, pages
Karlskrona: Blekinge Tekniska Högskola, 2023.
Series
Blekinge Institute of Technology Doctoral Dissertation Series, ISSN 1653-2090 ; 5
Keywords [en]
Assets in Software Engineering, Asset Management, Asset Degradation, Technical Debt
National Category
Software Engineering
Research subject
Software Engineering
Identifiers
URN: urn:nbn:se:bth-24429ISBN: 978-91-7295-455-7 (print)OAI: oai:DiVA.org:bth-24429DiVA, id: diva2:1749696
Public defence
2023-05-31, J1630 och Zoom, Campus Karlskrona, Karlskrona, 13:00 (English)
Opponent
Supervisors
Available from: 2023-04-12 Created: 2023-04-11 Last updated: 2023-06-07Bibliographically approved
List of papers
1. Assets in Software Engineering: What are they after all?
Open this publication in new window or tab >>Assets in Software Engineering: What are they after all?
Show others...
2022 (English)In: Journal of Systems and Software, ISSN 0164-1212, E-ISSN 1873-1228, Vol. 193, article id 111485Article, review/survey (Refereed) Published
Abstract [en]

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product's final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets’ characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction. © 2022 The Authors

Place, publisher, year, edition, pages
Elsevier, 2022
Keywords
Asset degradation, Asset management, Assets, Software artefacts, Technical debt, Cost effectiveness, Cost engineering, Software design, Asset, Assets management, Cost effective, Position papers, Product and services, Software development process, Software engineering practices, Technical debts, Terminology
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-23601 (URN)10.1016/j.jss.2022.111485 (DOI)000967989300022 ()2-s2.0-85136495111 (Scopus ID)
Funder
Knowledge Foundation, 20170176Knowledge Foundation, 20180010
Note

open access

Available from: 2022-09-12 Created: 2022-09-12 Last updated: 2023-05-08Bibliographically approved
2. A taxonomy of assets for the development of software-intensive products and services
Open this publication in new window or tab >>A taxonomy of assets for the development of software-intensive products and services
Show others...
2023 (English)In: Journal of Systems and Software, ISSN 0164-1212, E-ISSN 1873-1228, Vol. 202, article id 111701Article in journal (Refereed) Published
Abstract [en]

Context:Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management.

Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood.

Methods:We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy.

Results:We present the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets.

Conclusions:The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

Place, publisher, year, edition, pages
Elsevier, 2023
Keywords
Assets in software engineering, Asset management in software engineering, Assets for software-intensive products or services, Taxonomy
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-24426 (URN)10.1016/j.jss.2023.111701 (DOI)000984121100001 ()2-s2.0-85152899759 (Scopus ID)
Funder
Knowledge Foundation, 20170176Knowledge Foundation, 20180010
Available from: 2023-04-11 Created: 2023-04-11 Last updated: 2023-06-02Bibliographically approved
3. Refactoring, Bug Fixing, and New Development Effect on Technical Debt: An Industrial Case Study
Open this publication in new window or tab >>Refactoring, Bug Fixing, and New Development Effect on Technical Debt: An Industrial Case Study
2020 (English)In: Proceedings - 46th Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2020 / [ed] Martini A.,Wimmer M.,Skavhaug A., Institute of Electrical and Electronics Engineers Inc. , 2020, p. 376-384, article id 9226289Conference paper, Published paper (Refereed)
Abstract [en]

Code evolution, whether related to the development of new features, bug fixing, or refactoring, inevitably changes the quality of the code. One particular type of such change is the accumulation of Technical Debt (TD) resulting from sub-optimal design decisions. Traditionally, refactoring is one of the means that has been acknowledged to help to keep TD under control. Developers refactor their code to improve its maintainability and to repay TD (e.g., by removing existing code smells and anti-patterns in the source code). While the accumulation of the TD and the effect of refactoring on TD have been studied before, there is a lack of empirical evidence from industrial projects on how the different types of code changes affect the TD and whether specific refactoring operations are more effective for repaying TD. To fill this gap, we conducted an empirical study on an industrial project and investigated how Refactoring, Bug Fixing, and New Development affect the TD. We have analyzed 2, 286 commits in total to identify which activities reduced, kept the same, or even increased the TD, further delving into specific refactoring operations to assess their impact. Our results suggest that TD in the studied project is mainly introduced in the development of new features (estimated in 72.8 hours). Counterintuitively, from the commits tagged as refactoring, only 22.90% repay TD (estimated to repay 8.30 hours of the TD). Moreover, while some types of refactoring operations (e.g., Extract Method), help repaying TD, other refactoring operations (e.g., Move Class) are highly prone to introduce more TD. © 2020 IEEE.

Place, publisher, year, edition, pages
Institute of Electrical and Electronics Engineers Inc., 2020
Keywords
Bug Fixing, Case Study, Empirical Study, Industrial Study, New Development, Refactoring, Technical Debt, Engineering, Industrial engineering, Anti-patterns, Code changes, Development effect, Empirical studies, Industrial case study, Industrial projects, Sub-optimal designs, Technical debts, Application programs
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-20813 (URN)10.1109/SEAA51224.2020.00068 (DOI)000702094100057 ()2-s2.0-85096620525 (Scopus ID)9781728195322 (ISBN)
Conference
46th Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2020, Kranj, Slovenia, 26 August 2020 through 28 August 2020
Available from: 2020-12-04 Created: 2020-12-04 Last updated: 2023-04-11Bibliographically approved
4. Further Investigation of the Survivability of Code Technical Debt Items
Open this publication in new window or tab >>Further Investigation of the Survivability of Code Technical Debt Items
2022 (English)In: JOURNAL OF SOFTWARE-EVOLUTION AND PROCESS, ISSN 2047-7473, Vol. 34, no 2, article id e2425Article in journal (Refereed) Published
Abstract [en]

Context: Technical Debt (TD) discusses the negative impact of sub-optimal decisions to cope with the need-for-speed in software development. Code Technical Debt Items (TDI) are atomic elements of TD that can be observed in code artifacts. Empirical results on open-source systems demonstrated how code-smells, which are just one type of TDIs, are introduced and "survive" during release cycles. However, little is known about whether the results on the survivability of code-smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings.Goal: Understanding the survivability of code TDIs by conducting an empirical study analyzing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analyzed 144,476 code TDIs (35,372 from the industrial systems) detected by Sonarqube (in 193,196 commits) to assess their survivability using survivability models.Results: In general, code TDIs tend to remain and linger for long periods in open-source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.

Place, publisher, year, edition, pages
John Wiley & Sons, 2022
Keywords
bugs, code smells, code technical debt items, survivability, vulnerabilities
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-21269 (URN)10.1002/smr.2425 (DOI)000740993400001 ()2-s2.0-85122929311 (Scopus ID)
Funder
Knowledge Foundation, 2017/0176Knowledge Foundation, 2018/010
Note

open access

Available from: 2021-03-19 Created: 2021-03-19 Last updated: 2023-04-11Bibliographically approved
5. Ownership vs Contribution: Investigating the Alignment between Ownership and Contribution
Open this publication in new window or tab >>Ownership vs Contribution: Investigating the Alignment between Ownership and Contribution
2022 (English)In: IEEE 19th International Conference on Software Architecture Companion, ICSA-C 2022, Institute of Electrical and Electronics Engineers (IEEE), 2022, p. 30-34Conference paper, Published paper (Refereed)
Abstract [en]

Software development is a collaborative endeavour. Organisations that develop software assign modules to different teams, i.e., teams own their modules and are responsible for them. These modules are rarely isolated, meaning that there exist dependencies among them. Therefore, other teams might often contribute to developing modules they do not own. The contribution can be, among other types, in the form of code authorship, code review, and issue detection. This research presents a model to investigate the alignment between module ownership and contribution and the preliminary results of an industrial case study to evaluate the model in practice. Our model uses seven metrics to assess teams' contributions. Initial results suggest that the model correctly identifies misalignment between ownership and contribution. The detection of misalignment between ownership and contribution is the first step towards investigating the impact it might have on the faster accumulation of Technical Debt. © 2022 IEEE.

Place, publisher, year, edition, pages
Institute of Electrical and Electronics Engineers (IEEE), 2022
Keywords
Measurement, Codes, Software architecture, Conferences, Refining, Collaboration, Software
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-23320 (URN)10.1109/ICSA-C54293.2022.00013 (DOI)000838715700009 ()2-s2.0-85132145417 (Scopus ID)9781665494939 (ISBN)
Conference
2022 IEEE 19th International Conference on Software Architecture Companion, ICSA-C, Honolulu, 12 March 2022 through 15 March 2022
Funder
Knowledge Foundation, 20170176Knowledge Foundation, 20180010
Note

open access

Available from: 2022-06-27 Created: 2022-06-27 Last updated: 2023-04-11Bibliographically approved
6. The Impact of Forced Working-From-Home on Code Technical Debt: An Industrial Case Study
Open this publication in new window or tab >>The Impact of Forced Working-From-Home on Code Technical Debt: An Industrial Case Study
2022 (English)In: Proceedings - 48th Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2022 / [ed] Callico G.M., Hebig R., Wortmann A., Institute of Electrical and Electronics Engineers (IEEE), 2022, p. 298-305Conference paper, Published paper (Refereed)
Abstract [en]

Background: The COVID-19 outbreak interrupted regular activities for over a year in many countries and resulted in a radical change in ways of working for software development companies, i.e., most software development companies switched to a forced Working-From-Home (WFH) mode. Aim: Although several studies have analysed different aspects of forced WFH mode, it is unknown whether and to what extent WFH impacted the accumulation of technical debt (TD) when developers have different ways to coordinate and communicate with peers. Method: Using the year 2019 as a baseline, we carried out an industrial case study to analyse the evolution of TD in five components that are part of a large project while WFH. As part of the data collection, we carried out a focus group with developers to explain the different patterns observed from the quantitative data analysis. Results: TD accumulated at a slower pace during WFH as compared with the working-from-office period in four components out of five. These differences were found to be statistically significant. Through a focus group, we have identified different factors that might explain the changes in TD accumulation. One of these factors is responsibility diffusion which seems to explain why TD grows faster during the WFH period in one of the components. Conclusion: The results suggest that when the ways of working change, the change between working from office and working from home does not result in an increased accumulation of TD. © 2022 IEEE.

Place, publisher, year, edition, pages
Institute of Electrical and Electronics Engineers (IEEE), 2022
Series
Proceedings of the EUROMICRO Conference
Keywords
Case Study, COVID-19, Empirical Study, Industrial Study, Technical Debt, Telework, Work From Home
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-24427 (URN)10.1109/SEAA56994.2022.00054 (DOI)2-s2.0-85142493452 (Scopus ID)9781665461528 (ISBN)
Conference
48th Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2022, Gran Canaria, 31 August through 2 September 2022
Available from: 2023-04-11 Created: 2023-04-11 Last updated: 2023-04-18Bibliographically approved
7. The Impact of Ownership and Contribution Alignment on Code Technical Debt Accumulation
Open this publication in new window or tab >>The Impact of Ownership and Contribution Alignment on Code Technical Debt Accumulation
(English)Manuscript (preprint) (Other academic)
National Category
Software Engineering
Identifiers
urn:nbn:se:bth-24428 (URN)
Available from: 2023-04-11 Created: 2023-04-11 Last updated: 2023-04-24Bibliographically approved

Open Access in DiVA

fulltext(19385 kB)222 downloads
File information
File name FULLTEXT01.pdfFile size 19385 kBChecksum SHA-512
880d647767bdec3f34d4589f81bc39484b30a1329b2ae2becc58beb3d38b17760a94b57fa12201d4aa2c8366788015bf523d0572ecd4f6573ae3cc2897fa3faa
Type fulltextMimetype application/pdf

Search in DiVA

By author/editor
Zabardast, Ehsan
By organisation
Department of Software Engineering
Software Engineering

Search outside of DiVA

GoogleGoogle Scholar
Total: 222 downloads
The number of downloads is the sum of all downloads of full texts. It may include eg previous versions that are now no longer available

isbn
urn-nbn

Altmetric score

isbn
urn-nbn
Total: 728 hits
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf