Asset Management Taxonomy: A Roadmap
Ehsan Zabardast, Javier Gonzalez-Huerta, Tony Gorschek, Darja ?mite, Emil Alégroth, Fabian Fagerholm
AAsset Management Taxonomy: A Roadmap
Ehsan Zabardast a , ∗ , Javier Gonzalez-Huerta a , Tony Gorschek a , Darja Šmite a , Emil Alégroth a andFabian Fagerholm a,b a Software Engineering Research Lab SERL, Blekinge Institute of Technology, Campus Gräsvik, Valhallavägen 1, Karlskrona, Sweden b Department of Computer Science, Aalto University, Espoo, Finland
A R T I C L E I N F O
Keywords :TaxonomyAsset Management in Software Engi-neeringAssets for Software-Intensive Productsand ServicesTechnical DebtValue
A B S T R A C T
Developing a software-intensive product or service can be a significant undertaking, associated withunique challenges in each project stage, from inception to development, delivery, maintenance, andevolution. Each step results in artefacts that are crucial for the project outcome, such as source-codeand supporting deliverables, e.g., documentation.Artefacts which have inherent value for the organisation are assets, and as assets, they are subjectto degradation. This degradation occurs over time, as artefacts age, and can be more immediate orslowly over a period of time, similar to the concept of technical debt. One challenge with the conceptof assets is that it seems not to be well-understood and generally delimited to a few types of assets(often code-based), overlooking other equally important assets.To bridge this gap, we have performed a study to formulate a structured taxonomy of assets. We useempirical data collected through industrial workshops and a literature review to ground the taxonomy.The taxonomy serves as foundations for concepts like asset degradation and asset management. Thetaxonomy can help contextualise, homogenise, extend the concept of technical debt, and serves as aconceptual framework for better identification, discussion, and utilisation of assets.
1. Introduction
The fast pace of software-intensive product and servicedevelopment (SIPS) impacts the decision-making processboth in design and operational decisions. Acting fast to copewith change will compromise the values of the deliveredproduct, environment, development process, and the arte-facts involved, such as source code, test cases, and documen-tation [14]. Though the decisions that are made under thesecircumstances focus on delivery, they might impact the qual-ity of the delivered product or service, causing degradationof supporting artefacts such as code, architecture, and doc-umentation, to name a few. Researchers and practitionershave traditionally used the Technical Debt (TD) [18] metaphorto refer to the impact of the intentional and unintentional sub-optimal decisions on assets as a consequence to meet dead-lines [35]. However, the original TD metaphor focuses oncode-based artefacts and often does not take non-technicalassets such as documentation, test-cases, and supporting itemsinto account [4]. This is evident from, for example, the toolsavailable for measuring TD [55].To elaborate and move towards a more holistic view of
This research was supported by the KKS foundation through theSHADE KKS Hög project with ref: 20170176 and the KKS S.E.R.T. Re-search Profile with ref. 2018010 project at Blekinge Institute of Technology,SERLSweden. ∗ Corresponding author [email protected] (E. Zabardast); [email protected] (J. Gonzalez-Huerta); [email protected] (T. Gorschek); [email protected] (D. Šmite); [email protected] (E. Alégroth); [email protected] (F.Fagerholm) https://ehsanzabardast.com/ (E. Zabardast); http://gonzalez-huerta.net/ (J. Gonzalez-Huerta); https://gorschek.com/ (T. Gorschek)
ORCID (s): (E. Zabardast); (J. Gonzalez-Huerta); (F. Fagerholm) artefacts, more relevantly described as “assets” (having in-herent value to the organisation in their efforts) [77], awayfrom studying them in isolation [55], this paper presents thefirst version of a taxonomy, expandible as the field matures,of assets that are relevant for companies during the inception,planning, realisation, and evolution of SIPS. We define theterm “asset” in the software engineering context by refiningthe definition in [ISO5500:2014] [30], as follows: an asset is “any artefact with an inherent value for the organisation,and that is used for, and/or enables the inception, develop-ment, delivery, or evolution of software-intensive productsor services over time” [77].From a practitioner perspective, the degradation of as-sets is central as its accumulation slows down the product’smaintenance and evolution [4]. Degradation is compoundedby the increase of SIPS complexity and size in general, evenwithout the degradation [43, 42]. The need for further re-search into assets and asset degradation is also evident fromthe empirical study presented in this paper and the fact thatassets are often not associated with the traditional technicaldebt concept despite being deemed critical to the deliverableproduct/service itself.From a research perspective, the benefit of widening theterm of an implicit “debt” to assets is that it takes the so-called “items of value” [49] into account and widens theview of what can hold value in a SIPS development context.This widening fosters an understanding of what artefacts canbe negatively impacted by degradation, making it harder todevelop and evolve SIPS. To this end, having a common vo-cabulary and structure of potential assets – a taxonomy ofassets is presented – and the concepts of value and degrada-tion are explored [77]. Besides, the purpose of a taxonomyis to identify knowledge gaps and interrelationships betweenobjects and support decision-making [72, 71, 74, 70]. This
Zabardast et al.:
Preprint submitted to Elsevier
Page 1 of 22 a r X i v : . [ c s . S E ] F e b sset Management Taxonomy: A Roadmap work is mostly based on related work and industrial cases,i.e., companies addressing challenges related to asset degra-dation.The taxonomy presented in this paper is based on the re-sults acquired through a an empirical study. Our work’s verymotivation is connected to the interests of the five partnercompanies, and the bulk of the results were acquired througha workshop-survey with these companies. The workshopswere held on-site with participants sampled using conve-nience sampling but included individuals with varying ex-pertise and roles, e.g., project managers, senior architects,and developers. These results were complemented with lit-erature from peer-reviewed articles about assets, artefacts,and technical debt, as well as the researchers’ own empiri-cal experiences and knowledge. The aggregated results werethen synthesised to categorise and classify assets.The paper is structured as follows: Section 2 providesthe background and related work on the topic. Section 3 de-scribes the research methodology, which separately coversthe literature review and the industrial workshops. The re-sults are presented in Section 4, together with the proposedAsset Management Taxonomy. Section 5 discussed the prin-cipal findings and the implications of the results. The threatsto validity are also discussed and addressed in Section 5.And finally, Section 6 presents the conclusion and the con-tinuation of the work together with the future directions.
2. Background and Related Work
Assets related to SIPS have been studied previously, forinstance, from a managerial perspective where the term assetis used to discuss that the products in product lines that aredeveloped from a set of core assets that might have built-in variation mechanisms [53]. In contrast to this work, ourfocus is instead on the inception, development, evolution,and maintenance of software related assets and does therebynot cover business- or market-related assets such as the workof Ampatzoglou et al. [3], Cicchetti et al. [15], Wohlin et al.[75], and Wolfram et al. [76].
Describing how a software system is envisioned, built,and maintained is part of the Software Development Pro-cesses (SDP) [62]. The SDP prescribes the set of activi-ties and roles to manipulate documents, i.e., software arte-facts, namely source code, documentation, reports, and oth-ers [14]. The artefacts in software engineering are definedas i) “documentation of the results of development steps”[14]; ii) “a work product that is produced, modified, or usedby a sequence of tasks that have value to a role” [49]; andiii) ”a self-contained work result, having a context-specificpurpose and constitutes a physical representation, a syntac-tic structure and a semantic content of said purpose, formingthree levels of perception” [49]. Software artefacts are self-contained documentation and work products that are pro-duced, modified, or used by a sequence of tasks that havevalue to a role [49]. The definition and organisation of software artefacts havea significant influence on software development. The de-scriptions and documentation in large-scale systems can growexponentially and get “very large”; therefore, there is a needfor structural organisation of software artefacts [14]. Arte-facts defined by most of the SDPs are monolithic and un-structured [66]. The content of poorly structured artefacts isdifficult to reuse, and the evolution of such monolithic arte-facts is cumbersome [60]. Therefore, different SDPs presentvarious models for presenting software artefacts, e.g., theRational Unified Process (RUP) [32, 33]. There are manyways to classify and structure software artefacts based onwell-known modeling concepts. Examples of such modelsare the work of Broy [14] and Silva et al. [60]. Moreover,there are ontologies and metamodels to classify artefacts inspecific software development areas (e.g., Mendez et al. [50],Zhao et al. [78], and Constantopoulos and Doerr [17]).The definitions of artefacts presented in the literature donot distinguish between the artefacts that have an inherentvalue for the development organisation and are the artefactsthat subject to degradation over time from the artefacts thatdo not have any value for the organisation. The value of eachasset is a property that can characterise its degradation, i.e.,if an asset degrades, it is still an asset, but its value for the or-ganisation has degraded. Following this reasoning, an arte-fact that does not have value for the organisation cannot beclassified as an asset and cannot be described with respect toits degradation. We have defined assets as artefacts with value for the or-ganisation and, therefore, subject to degradation. Cunning-ham introduced the Technical Debt (TD) metaphor in 1992to describe the compromises resulting from suboptimal de-cisions to achieve short-term benefits [18]. We assume thatTD’s focus is to identify the consequences of these subop-timal decisions on relevant assets [47], and that is why westudy literature on this phenomenon intending to find rele-vant assets.The TD metaphor has been extended and studied by manyresearchers [55]. It has been an interesting topic for bothacademia and industry, and it has grown from a metaphor topractice [36]. TD is currently recognised as one of the criti-cal issues in the software development industry [8]. The ac-tivities that are performed to prevent, identify, monitor, mea-sure, prioritise, and repay technical debt are called TechnicalDebt Management (TDM) activities [4, 26] and include, forexample, identifying TD items in the code, visualising theevolution of TD, evaluating source code state, and calculat-ing TD principal [55].As the TD metaphor was extended to include differentaspects of software development, various Technical Debt typeswere introduced [4], e.g., requirements debt, test debt, anddocumentation debt. The introduction of different types ofTD has led researchers to attempt to classify the different Mendez et al. [49] define artefacts as having value for a role which issubstantially different from having value for the organisation.
Zabardast et al.:
Preprint submitted to Elsevier
Page 2 of 22sset Management Taxonomy: A Roadmap types and categories of TD. One of the earliest classifica-tions of TD is the work of Tom et al. [67]. Other secondaryand tertiary studies have been performed to summarise thecurrent state of TD and TD types, e.g., by Lenarduzzi et al.[44], Rios et al. [55], and Li et al. [47].The original TD definition focuses on source code, i.e.,code, design, and architecture [4]. The organisational andsocial aspects of technical debt have not received the sameamount of attention [55]. However, they might have beenstudied under different topics than TD. Moreover, TD typesare often studied in isolation, not considering how they co-occur and the permeation to other TD types [4]. For ex-ample, when the code TD grows, a valid question would bewhether and how it affects the test TD and the extent of suchassociation’s impact.Moreover, the TD management activities have not beeninvestigated thoroughly [4]. TD management activities havebeen investigated in several secondary studies with differentperspectives, some focusing on tools, others on strategies,but there is still a lack of unified analysis aligning these dif-ferent perspectives [55]. Lastly, TD is generally studied inthe current state of the software and it is not studied with re-gards to the evolutionary aspects of TD, i.e., studying TD ona “snapshot” of a system is not enough [21, 54]. Therefore,a more appropriate approach to study TD is to study its evo-lution [13]. It is only by periodically monitoring TD that wecan study the economic consequences of TD [19], determinethe performance of the system in the future [20], and createmethods and frameworks to react quickly to the accumula-tion of TD [45]. Based on research, but described slightlydifferently can be as follows. An asset has value for an organ-isation. If for any reason this value is degraded (e.g., codecomments are not kept up to date due to time constraints,or an API description is not updated, etc.), you lessen thevalue of the said asset. If you identify this value degradationto be a problem, and you need to plan to invest resourcesinto addressing the issue (e.g., updating code comments),this investment’s cost can be seen as the repayment of theTD. Thus, TD is the delta between the current value of anasset and the value of said asset’s preferred value (by the or-ganisation).
Scientists and researchers have long used taxonomies asa tool to communicate knowledge as early as the eighteencentury. One of the examples of early taxonomies is the workof Carl von Linné [48]. Taxonomies are mainly created andused to communicate knowledge, provide a common vocab-ulary, and help structure and advance knowledge in the field[24, 40, 70]. Taxonomies can be developed in one of twoapproaches; top-down, also referred to as enumerative, andbottom-up, also referred to as analytico-synthetic [12]. Thetaxonomies that are created using the top-down method usethe existing knowledge structures and categories with estab-lished definitions. In contrast, the taxonomies that use thebottom-up approach are created using the available data suchas experts’ knowledge and literature, enabling them to enrich the existing taxonomies by adding new categories and clas-sifications [69].Software Engineering (SE) is continually evolving andbecoming one of the principal fields of study with many sub-areas. Therefore, the researchers of the field are required tocreate and update the taxonomies and ontologies to help ma-ture, extend, and evolve SE knowledge [70]. The Guide tothe Software Engineering Body of Knowledge (SWEBOK)can be considered as a taxonomy that classifies software en-gineering discipline and its body of knowledge in a struc-tured way [11]. Software engineering knowledge areas aredefined in SWEBOK, and they can be used as a structuredway of communication in the discipline. Other examples oftaxonomies in software engineering are the work of Glasset al. [25] and Blum [10]. Specialised taxonomies with nar-rower scopes are also popular in the field. These taxonomiesare focused on specific sub-fields of software engineeringsuch as Taxonomy of IoT Client Architecture [65], Taxon-omy of Requirement Change [58], Taxonomy of Architec-ture Microservices [23], Taxonomy of Global Software En-gineering [61], and Taxonomy of Variability Realisation Tech-niques [64] to name a few.This paper presents a taxonomy of assets in the incep-tion, planning, development, evolution, and maintenance ofa SIPS. The taxonomy is built using a hybrid method, i.e.,the combination of top-down and bottom-up. The details ofthe taxonomy creation are presented in Section 3.4. The pur-pose of our taxonomy is to cluster.
In this paper, we introduce assets in software develop-ment and software engineering. We use the concept of arte-facts and their intentional degradation from the research inthe field of Technical Debt as a starting point for this work,which we expand to include various types of valuable arte-facts as Assets.In particular, we aim to address the following challengesand gaps:• Identifying and distinguishing between the artefactswith inherent value (assets) with those without.• Identifying assets by considering every aspect of soft-ware development. For example, Environment-and-Infrastructure-, Development-Process-, Ways-of-Working-, and Organisation-related aspects [4, 55] that have notreceived much attention in TD.• Laying the groundwork for capturing the evolution-ary aspect of assets and their degradation. The TDmetaphor generally applies to the current state of theproduct and dismisses the assets’ evolutionary aspect[21, 54]. As described in Section 2.2, studying TDwith regards to its evolution is needed to understandthe economic consequences of TD [19], the quality ofthe system in the future such as system performance[20], and the creation of TD management frameworks[45].
Zabardast et al.:
Preprint submitted to Elsevier
Page 3 of 22sset Management Taxonomy: A Roadmap
Based on the asset’s definition in [77], we identify theartefacts that adhere to this definition and which of these arecommon in the industry. There are adjacent and similar tax-onomies that cover subsets and part of this work. However,their purposes are different than what are aiming to achieve.To the best of our knowledge, there is no ontology or taxon-omy that we can use to describe and classify assets and theirinterrelations.
3. Research Overview
This section presents the research methodology and de-sign of the study. The study is divided into two parts; a lit-erature review and an empirical study of industrial cases. Inthe following subsections, we first cover how we performedthe literature review (Section 3.2). We explain how the datawas gathered, coded, and analysed. We describe the pro-cess of studying company cases, the data collection, and theanalysis (Section 3.3). Later, we describe how the taxon-omy was created based on the collected data (Section 3.4).The steps taken to internally validate the taxonomy by theresearchers involved in the industrial workshops are pre-sented (Section 3.5).To make the research objective more concrete, it has beenbroken down into the following research question: 𝑅𝑄 ∶ What assets are important for organisations dur-ing the inception, planning, development, evolution, and main-tenance of SIPS?
We aim to provide a systematically constructed and extend-able taxonomy to accommodate the set of terms and conceptsused in both academia and industrial practice as it pertainsto SIPS.We performed a literature review to capture the classi-fications and definitions of various assets studied and pre-sented in research venues (top-down method). Included aresystematic literature reviews, systematic mapping studies,and tertiary studies. The details of the literature review pro-cedure are presented in Section 3.2.To study state-of-practice, we performed industrial work-shops over multiple companies to find evidence on how as-sets are defined and used. The five cases were selected usingconvenience sampling as companies involved in an ongoingresearch project that is interested in addressing asset degra-dation challenges. We organised several workshops withthe industrial partners to investigate and discuss the topicswith experts in each area. The reports and results from theworkshops were then coded and used for the construction ofthe taxonomy. We used the bottom-up method for updatingthe existing structure that we obtained from the literature re-view. This approach enabled us to enrich the existing struc-ture from the literature. The details of the procedure of theindustrial workshops are presented in Section 3.3.Usman et al. [70] present a revised method for the devel-opment of taxonomies in software engineering. The revisedmethod includes four phases of
Planning, Identification and Industrial workshops refer to the workshops where the data was col-lected.
Extraction, Design and Construction, and
Validation . Theasset management taxonomy was created by following thementioned method.
Phase 1: during which the taxonomy’s context and objec-tive (software engineering knowledge area, objective, sub-ject matter, classification structure, and information sources)were decided. This phase is corresponding to the planning phase of the method (see Section 3.1)
Phase 2: during which the raw data for creating the taxon-omy was collected. This phase is corresponding to the iden-tification and extraction phase of the method (see Section 3.2and Section 3.3)
Phase 3: during which the taxonomy categories were ex-tracted, and the relations between the items (i.e., the nodesin the taxonomy tree) were identified. This phase is corre-sponding to the design and construction phase of the method(see Section 3.4)
Phase 4: during which the taxonomy was internally vali-dated by utility demonstration. The utility of the taxonomywas demonstrated by expert opinion (i.e., researchers). Thisphase is corresponding to the validation phase of the method(see Section 3.5)
The complexity of developing software-intensive prod-ucts and services makes it challenging to identify and main-tain the assets [77]. In such cases, the need for an organ-ised, well-structured body of knowledge is crucial. We dis-cussed the concept and definition of assets in our previouswork [77] and planned to create a taxonomy of assets utilis-ing the knowledge from academia and the industry to capturethe body of knowledge in an organised structure.
To investigate the terminology used in the area of as-sets and asset management, we reviewed research papers thatclassify assets and provide definitions of the term.The assets (i.e., artefacts that we are interested in) aresubject to technical debt which makes the research on TDa good input area to find assets. However, we do not de-limit ourselves to the artefacts that are discussed in TD. Wechose to do a literature review on the topic of technical debtand the classifications provided by the TD literature (i.e., TDtypes) because the TD metaphor is a subset of asset manage-ment (see Figure 1). Technical Debt is part of Asset Degra-dation defined in [77]. Moreover, the TD literature is con-cerned with different aspects of software development. TheTD metaphor has been used as an umbrella term to includeall the assets involved during the development. TD has re-ceived a growing interest in academia and the industry. Andthe TD topic has been studied in various venues and researchfor a considerable time.We began by collecting the start set of the papers us-ing “technical debt” AND (“systematic literature review”OR “systematic mapping study” OR “tertiary study”) as thesearch string in Google Scholar. We selected the articlesthat presented a classification for TD. Finally, we completed
Zabardast et al.:
Preprint submitted to Elsevier
Page 4 of 22sset Management Taxonomy: A Roadmap
TechnicalDebtAssetManagement
Sub-OptimalSolutionsLongitudinalDegradation
Figure 1:
Venn diagram depicting how Asset Management andTechnical Debt are related in their context. the set by following the snowballing iteration guidelines pro-vided by Wohlin [73].The execution process included the following steps asillustrated in Figure 2. The results of this process are pre-sented in Section 4.1.•
Step 1:
Collection of the start set of relevant arti-cles (seed papers) including SLRs, SMSs, and Ter-tiary studies on technical debt.•
Step 2:
Evaluate the papers - start set in the first it-eration - for inclusion/exclusion based on the criteria,i.e., papers that presented any classification of TD andartefacts affected by TD.•
Step 3:
The snowballing procedure for identifying ad-ditional secondary and tertiary studies on TD that sat-isfy our inclusion/exclusion criteria: – Step 3.1:
Backward snowballing by looking atthe references of the papers. – Step 3.2:
Forward snowballing by looking at thepapers that cite the papers.•
Step 4:
Extracting different types of assets and assets together with their respective definitions from the se-lected articles.•
Step 5:
Synthesising the definitions of the types ofassets and assets provided by the selected articles.•
Step 6:
Creating the matrix of types of assets and as-sets based on technical debt classifications defined bythe selected articles.
To collect data, we performed workshops with industrialpartners that develop and maintain software-intensive prod-ucts and services according to the process presented in Fig-ure 3.
We have collected the data for this study collaboratingwith five companies that work construction machinery in-dustry, communication technology industry, and banking andfinancial services. The research partner companies are Eric-sson (telecommunication & ICT), Fortnox (Finance), Time People Group / Qtema (Consultancy), and Volvo CE (Au-tomotive Industry). The companies were selected by conve-nience and availability. The partner companies are mature intheir development practices and have well-established, suc-cessful products. They are interested in continuously im-proving their products and development life-cycles, whichturns into their willingness on participating in studies likethis. All the collaborating companies work on developingsoftware-intensive products and services and are involved inan ongoing research project . The details of the case com-panies are presented in Table 1. Note that the order of thecompanies in Table 1 does not correspond with the orderof workshops (workshops IDs) in Table 4, which has beenshuffled to preserve confidentiality. The workshops include six steps (see Figure 3):•
IW1.
Workshop participants introducing themselves.•
IW2.
One of the moderating researchers presentingthe topic.•
IW3.
Workshop participants discussing the topic, pro-viding insight into their views/experiences with TDand document them in notes.•
IW4.
Workshop participants discussing assets and as-set management in detail after a second presentationof the concept.•
IW5.
Workshop participants discussing what they wrotebefore as technical debt examples and rethinking themin terms of assets, asset degradation, and asset man-agement.•
IW6.
A closing discussion and focus groups.Each workshop starts with participants introducing them-selves with background information about their work, in-cluding their current role in the organisation (step IW1). Oneof the moderating researchers then presents the workshop’sagenda and covers the importance of the topic and the grow-ing interest in value creation and waste reduction both inacademia and in the industry (step IW2).After the initial introduction of the topic by the moder-ating researchers, the participants are divided into groups.They are asked to list and discuss the challenges with theirways of working (while considering varying aspects of tech-nical debt), i.e., the problems they know or have encounteredor experienced (step IW3). After the time is up, the notes areread, discussed, and abstracted to a more general descriptionand later put on a whiteboard. The connections between theitems on the board are identified and marked down with amarker.After the second presentation, i.e., introducing the par-ticipants with the concepts related to Asset Management (AM)and Asset Degradation (AD) [77] (step IW4), participants See . Zabardast et al.:
Preprint submitted to Elsevier
Page 5 of 22sset Management Taxonomy: A Roadmap
Collection of the StartSet Selection of RelevantArticles with TDClassification Snowballing Extracting Assets andTypes of Assets Sythesizing theDefinitionsForward SnowballingBackwardSnowballing
Step 1: Step 2: Step 3:Step 3.1: Step 3.2: Step 4: Step 5:
Creating the Matrix ofAssets and Types ofAssets
Step 6:
Figure 2:
The literature review execution process.
Company SelectionIndustrial Workshops IW Data Extraction DE Extracting the Asset Matrix Closing DiscussionParticipants' View on TD Items in Terms of AssetsIntroduction of the Concept of Asset ManagementParticipants' View on What TD IsIntroduction of the TopicIntroduction of the ParticipantsFirst Cycle Coding
In Vivo Coding
Validating and Resolving the ConflictsSecond Cycle
Coding Pattern Coding
Validating and Resolving the Conflicts
IW1DE1 IW2IW3IW4IW5IW6DE2DE3DE4
Figure 3:
The execution process for industrial cases. add new items to the previous notes on the board. Partici-pants then refine the items from the board for the rest of theworkshop (step IW5). The workshop ends with a closingdiscussion on the topic and the items (step IW6).In the context of this research, we have moved the focusfrom the traditional technical debt metaphor to asset degra-dation. In this framework, we talk about asset degradation asthe deviation of an asset from its representation. That way,we can focus, potentially, on any type of asset and its repre-sentation. This framework provides us with a broader, holis-tic view that allows us to study how an asset’s degradation(e.g., requirements) might introduce degradation in other as-sets (e.g., code or test cases) [77].The written notes from the participants, the minutes ofthe workshops, as well as the final reports that were sent tocompanies after the workshops were used as raw data. Theresearchers’ minutes were written during each session andwere then aggregated and summarised in a report sent to thecompanies. The notes were used for coding and later to ex-tract types of assets and explicit assets . The details of thedata extraction and taxonomy creation are described in Sec-tion 3.4.
Two sources of raw data were gathered from the indus-trial workshops; written notes from workshop participantsand notes from moderating researchers specifically assignedto scribe each session’s discussions. To create the matrix of assets from industrial insights, we use the hybrid method ofcoding, as Saldaña [59] suggested. The coding is dividedinto two main cycles: First Cycle Coding and Second CycleCoding.
First Cycle Coding of the raw data happens in the ini-tial stage of coding. The raw data, which can be a clause, asentence, a compound sentence, or a paragraph, is labelledbased on the semantic content and the context in which itwas discussed during the workshop. We have used the invivo coding method to label the raw data in the first cycle.In vivo coding is suitable for labelling raw data in the firstcycle coding. It prioritises the interviewees’ / participants’opinions [59]. It adheres to the “verbatim principle, usingterms and concepts drawn from the words of the participantsthemselves. By doing so [the researchers] are more likely tocapture the meanings inherent to people’s experiences.” [63,p. 140] It is commonly used in empirical and practitionerresearch. [63, 16, 22]The coding was done by two researchers independently(step DE1, see Figure 3). The labels were then compared tovalidate the labels and to identify conflicting cases. A thirdresearcher helped to resolve the conflicts by discussing thelabels with the two initial researchers (step DE2, see Fig-ure 3).
Second Cycle Coding is done primarily to categorise,theorise, conceptualise, or reorganise the coded data fromthe first cycle coding. We have used Pattern Coding [59]
Zabardast et al.:
Preprint submitted to Elsevier
Page 6 of 22sset Management Taxonomy: A Roadmap
Table 1
Case company details. The table is ordered alphabetically based on the name of thecompanies, and does not correspond to the order in Table 4.
Company Domain InvestigatedSite EnterpriseSize Participants’ Roles
Ericsson Telecommunication& ICT Karlskrona,Sweden Large Senior System ArchitectCorporate Senior Strategic ExpertOperations & TestingFortnox Finance Växjö,Sweden Large Head of DevelopmentProduct OwnersDevelopment ManagersSystem ArchitectTestingQtema † Consultancy Stockholm,Sweden SME Chairman of the BoardRequirements AnalystSales ManagerProject ManagerIT Administration ManagerTime People Group † Consultancy Stockholm,Sweden SME Data ConsultantProject Manager ConsultantSenior Agile CoachIT Project ManagerTeam LeaderChief Exevutive Officer (CEO)ConsultantTest LeaderVovlo CE ConstructionMachinery Gothenburg,Sweden Large Enterprise ArchitectsSolution ArchitectBusiness Information Architect † Time People Group and Qtema participated in the same workshop. as the second cycle coding method. According to Mileset al. [51, p. 86], pattern coding is used in cases where: (i) theresearchers aim to turn larger amounts of data into smalleranalytical units. (ii) the researchers aim to identify themesfrom the data. (iii) the researchers aim to perform cross-case analysis on common themes from the data gathered bystudying multiple cases.Similar to the first cycle coding process, pattern codingwas done by two researchers independently (step DE3, seeFigure 3). The results were compared to validate the classi-fications and to identify conflicting cases. A third researcherresolved the conflicting cases in a discussion session with thetwo researchers (step DE4, see Figure 3). The results of theinsights gathered from industrial workshops are presented inSection 4.2.
To describe a precise syntax and the semantics of the dif-ferent concepts used for the taxonomy creation, we createda metamodel (presented in Figure 4). The metamodel sum-marises and identifies the metaclasses, i.e., the characteris-tics of assets, their definitions, and their relation. The meta-model illustrates the structural relationships between the meta-classes. The metaclasses presented in the metamodel are: • The “AssetComponent” metaclass is the container meta-class for the items in the model.• The “TypeOfAsset” metaclass represents the hierar-chical classification of assets. The items belonging tothis metaclass can be further broken down into sub-classifications representing various groups of assets.The types of assets are containers for the assets. Assettypes are identified from the state-of-the-art (i.e., ex-isting academic literature), state-of-practice (i.e., theindustrial insights gathered through the industrial work-shops), or the identified by researchers.• The “Asset” metaclass represents atomic and measur-able assets. Each asset belongs to a type of asset. As-sets are identified from the state-of-the-art (i.e., exist-ing academic literature), state-of-practice (i.e., the in-dustrial insights gathered through the industrial work-shops), or identified by researchers.• The “Reference” metaclass represents the referencesfrom which each asset or type of asset has been iden-tified. Reference can originate from academic litera-ture (the literature review) or industrial insights (gath-ered from industrial workshops). References can bemapped to individual assets/type of assets or multiple
Zabardast et al.:
Preprint submitted to Elsevier
Page 7 of 22sset Management Taxonomy: A Roadmap assets/type of assets . Referencetitle : Stringtype : StringTypeOfAssetname : Stringdefinition : String
Assetname : Stringdefinition : String
AssetComponent
Figure 4:
Asset Management Metamodel.
The creation of the taxonomy included three steps. First,we created an asset matrix based on the technical debt types(top-down approach) with items that we extracted from theliterature review. We created the matrix based on the lit-erature’s definitions, i.e., by synthesising the definitions toidentify similarities, differences, and hierarchies of identi-fied items. We have grouped the definitions provided by theliterature based on their semantic meaning.In the second step, we utilised the extracted assets fromindustrial workshops (Section 3.3.3) to create a second as-set matrix (bottom-up approach). Like the previous step, weused the definitions of the assets and their types and the par-ticipants’ statements from the workshops.By combining the two matrices in the last step, we cre-ated the asset management tree. To complete the tree, weadded some nodes based on the researchers’ expertise thatwe perceive were missing nodes and leaves. We mentionsuch cases as
Author Defined Assets (ADA) when present-ing the results.The process of adding ADA started with researchers sug-gesting assets that should be included in the taxonomy. Thesesuggested assets were brought up in internal workshops where all the researchers discussed, reflected, improved, andadded / removed the suggested assets. User Stories , as anexample, were suggested by one of the researchers to beconsidered as assets during one of the internal workshops.The discussion was regarding (i) whether or not
User Sto-ries are assets, (ii) if they fit in the taxonomy according tothe definition, (iii) where they belong in the tree, (iv) whatthey represent, (v) and how they degrade. After the discus-sions, the researchers decided that
User Stories belong to [AM1] - [AM1.1] Functional-Requirements-Related Assets in the taxonomy tree. Internal workshops refer to the workshops where the researchers dis-cussed the taxonomy.
The assets included in the taxonomy should adhere tothe definition of an asset presented in [77], thereby also thefollowing inclusion criteria:• Assets are artefacts that have inherent value for theorganisation and are subject to degradation, i.e., thevalue of the asset can degrade (lessen).• Assets are persistent and not inherently transient, i.e.,we do not consider intermediate entities as assets. Inour definition, artefacts that are created with a particu-lar purpose and then immediately transformed to otherartefacts are not assets.
The taxonomy was created by the authors after the datacollection was complete. We conducted internal workshopsto validate the taxonomy and its structure with the sevenresearchers who were involved during the industrial work-shops.
Step 1:
The taxonomy was sent to all the researchers to studyand prepare for the internal workshop.
Step 2:
An internal workshop was held where the first andsecond authors presented the taxonomy and the researchersprovided their feedback. The discussions were on both thestructure of the taxonomy and on the assets.
Step 3:
The taxonomy was updated based on the discussionand the feedback provided during the internal workshops.
Step 4:
The authors held individual meetings with each re-searcher to further discuss the latest updates on the taxonomyand delve into the areas of expertise of each researcher.
Step 5:
The taxonomy was updated based on the individualmeetings and presented to the researchers for the final ap-proval.
4. Results
This section presents the results of the literature review,then the results of the workshops. Finally, we will presentthe Asset Management Taxonomy based on both.
The final list of papers included nine articles presentedin Table 2. To create the assets matrix, we extracted thetypes of technical debt from each article. For example, inpaper P8 [44], we refer to Table 1 on page 4 of the arti-cle, where the authors summarise different types of technicaldebt and their respective definitions. The authors define Re-quirements TD as “the distance between the optimal require-ments specifications and the actual system implementation,under domain assumptions and constraints” [44]. Require-ments is also mentioned as a TD item in P3 , P4 , P5 , and P6 .Table 3 presents the asset matrix based on the types of tech-nical debt. The codes of the papers are used as a referencethroughout this paper.Looking at Table 3 we can see that there are fewer cat-egories in the earlier studies ( P1 and P2 ). The papers thatfollow these studies break down the bigger categories into Zabardast et al.:
Preprint submitted to Elsevier
Page 8 of 22sset Management Taxonomy: A Roadmap
Table 2
The articles gathered for the literature review during the snowballing process.
Code Title SeedPaper BackwardSnowballing ForwardSnowballing
P1 A Consolidated Understanding of Technical Debt [67] xP2 An Exploration of Technical Debt [68] xP3 Towards an Ontology of Terms on Technical Debt [2] xP4 A Systematic Mapping Study on Technical Debt and Its Management [47] xP5 Identification and Management of Technical Debt: A Systematic MappingStudy [1] xP6 Managing Architectural Technical Debt: A Unified Model and SystematicLiterature Review [9] xP7 A tertiary study on technical debt: Types, management strategies, researchtrends, and base information for practitioners [55] xP8 Technical Debt Prioritisation: State of the Art. A Systematic LiteratureReview [44] xP9 Investigate, identify and estimate the technical debt: a systematic mappingstudy [6] x more specific categories. For example,
Architecture and De-sign are put into one category in P1 and P2 and later, theyare broken down to their own categories. It is important tomention that P7 has fewer categories since the study is onthe specific topic of Architectural Technical Debt . There were a total number of four workshops, each heldwith participation of different companies. The workshops’procedure stayed the same while the closing discussion ofeach workshop was on the topic of interest for the work-shop participants (the stakeholders). The topics included,but were not limited to,
Lack of Knowledge/Competence , Ar-chitecture Artefact Lifecycle , Business Models for Products ,and
Backlog Update Issues/Backlog Size .The data extraction process was done, as described inSection 3.3.3. Two researchers used the in vivo coding methodto label statements during the first cycle coding. Aftermatching and validating the labels, cases of conflictinglabels were identified. The conflicting labels were resolvedduring a discussion session with a third researcher. The re-searchers agreed on the new labels for the conflicting casesduring the discussion.After solving the conflicting cases of in vivo coding, theresearchers continued with pattern coding [59] of the firstcycle coding results. The two researchers classified the as-sets based on in vivo labels. Table 4 presents the asset matrixbased on the results of the second cycle coding.The workshops presented in Table 4 are chronological,i.e., WS1 was the first workshop. Though the workshopswere executed using the same procedure, we only extractedrelevant statements. Therefore,
WS1 has fewer entries in Ta-ble 4. That is why we observe only two assets/types of assetsin the first column, and this might be due to the profiles orexperience of the participants.Examining Table 4, we can observe that assets are men-tioned more often than types of assets in the industrial work-shops whereas types of assets are more frequent in the liter- ature review (see Table 3). Finally, assets that are related to
Operations , Management , and
Organisational Management were highlighted more in the industrial workshops than theliterature review.It appears that the assets that are mentioned frequentlyare:•
Easier to contextualise : It is easier for the stakehold-ers to identify such assets in the software product con-text. For example, the data that the company acquiresfrom the operation of the product, i.e.,
ApplicationData , can be used as input to improve the product.•
More tangible : The assets that have been studied anddiscussed before, and the concept is not foreign any-more. For example, every software company, one wayor another, has a
Product Backlog with specific char-acteristics which is familiar for all the people involvedin the development of the software-intensive product.•
Easier to measure : There are already existing metricsused to measure the state of such assets. For example,there are many metrics available to measure
SourceCode , such as LOC and Cyclomatic Complexity.•
Used universally : The assets that are defined in thesame way across different organisations and academia,meaning that they are not organisation-specific. Forexample, the software’s architecture (Code Structure) is a universal and inherent aspect of any software-intensiveproduct.
Using the key concepts extracted from the labelled data(presented in Table 3 and Table 4), we build the taxonomyof assets. The taxonomy contains the terminology identifiedthrough the literature review and the industrial workshops.The terms included in the taxonomy are presented in a tree
Zabardast et al.:
Preprint submitted to Elsevier
Page 9 of 22sset Management Taxonomy: A Roadmap
Table 3
Asset matrix from technical debt literature. P P P P P P P P P E m e r g i n g C a t e go r y ( i e s ) P h a s e , du r i n g w h i c h t h e a r t e f a c t i s p r o du c e d F e a t u r e s R e qu i r e m e n t s R e qu i r e m e n t s R e qu i r e m e n t s R e qu i r e m e n t s R e qu i r e m e n t s R e qu i r e m e n t s P r o du c t R e qu i r e m e n t s R e qu i r e m e n t s U s a b ili t y U s a b ili t y U s a b ili t y Q u a li t y R e qu i r e m e n t s D e s i g n \ A r c h i t ec t u r e D e s i g n a nd A r c h i t ec t u r e A r c h i t ec t u r e D e s i g n A r c h i t ec t u r e D e s i g n A r c h i t ec t u r e D e s i g n A r c h i t ec t u r e D e s i g n A r c h i t ec t u r e A r c h i t ec t u r e D e s i g n A r c h i t ec t u r e D e s i g n A r c h i t ec t u r e D e s i g n D ec i s i o n s D o c u m e n t a t i o n D e s i g n D o c u m e n t a t i o n D o c u m e n t a t i o n D o c u m e n t a t i o n D o c u m e n t a t i o n D o c u m e n t a t i o n D o c u m e n t a t i o n D o c u m e n t a t i o n D o c u m e n t a t i o n P r o du c t D o c u m e n t a t i o n D e s i g n S p ec i fi c a t i o n s A r c h i t ec t u r a l D o c u m e n t a t i o n A r c h i t ec t u r a l D o c u m e n t a t i o n C o d e C o d e C o d e C o d e C o d e C o d e C o d e C o d e C o d e S o u r ce C o d e D e v e l o p m e n t B u il d B u il d B u il d B u il d B u il d B u il d B u il d D o c u m e n t a t i o n S e r v i ce S e r v i ce S e r v i ce S e r v i ce W e b S e r v i ce s V e r s i o n i n g V e r s i o n i n g V e r s i o n i n g V e r s i o n i n g V e r s i o n i n g V e r s i o n i n g T e s t i n g T e s t i n g T e s t T e s t T e s t T e s t T e s t T e s t F un c t i o n a l T e s t s V e r i fi c a t i o n a nd V a li d a t i o n D e f ec t s / K n o w n D e f ec t s D e f ec t D e f ec t D e f ec t D e f ec t D e f ec t T e s t A u t o m a t i o n T e s t A u t o m a t i o n T e s t A u t o m a t i o n T e s t A u t o m a t i o n T e s t A u t o m a t i o n T e s t C a s e D o c u m e n t a t i o n T e s t D o c u m e n t a t i o n E n v i r o n m e n t E n v i r o n m e n t a nd I n f r a s t r u c t u r e O p e r a t i o n s I n f r a s t r u c t u r e H a r d w a r e I n f r a s t r u c t u r e I n f r a s t r u c t u r e I n f r a s t r u c t u r e I n f r a s t r u c t u r e I n f r a s t r u c t u r e I n f r a s t r u c t u r e I n f r a s t r u c t u r e E n v i r o n m e n t a nd I n f r a s t r u c t u r e O p e r a t i o n a l P r o ce ss e s O p e r a t i o n s P r o ce ss P r o ce ss P r o ce ss P r o ce ss P r o ce ss M a n a g m e n e t M a n a g e m e n t D o c u m e n t a t i o n S p ec i fi c a t i o n s D o c u m e n t a t i o n I n t e r n a l R u l e s a nd S p ec i fi c a t i o n s C o l o r G u i d e : A ss e t s T y p e s o f A ss e t s T e m p o r a r y A r t e f a c t s Zabardast et al.:
Preprint submitted to Elsevier
Page 10 of 22sset Management Taxonomy: A Roadmap
Table 4
Asset matrix from industrial workshops.
WS1 WS2 WS3 WS4 EmergingCategory(ies) Phase, duringwhich theartefact is produced
ContradictoryRequirements Requirements Requirements Requirements
Product Requirements
RequirementsArchitectural Models
Documentation
Documentation Documentation
Product Documentation
DesignArchitecturalDocuments ArchitecturalDocumentation
ArchitecturalDocumentation
Architecture Software Structure Architecture Architectural(Source Code)Dangerous Code Code Code Code Source Code DevelopmentAPIs API Versions
APIs
Libraries Third Party Products Libraries\External LibrariesTest Cases Tests Test Cases
Test Cases
VerificationandValidationAutomated Tests
Test Automation Scripts
Bug Reports Application Data
Application Data
OperationsKubernets Containers\Kubernets
Tools
Ways of Working Ways of Working Documentation aboutWays of Working
Documentation aboutWays of Working
ManagementCoding Standards Coding Standards
Coding Standards
Architectural Rules
Architectural InternalStandards
DocumentationStandards
Documentation InternalRules\Standards
Product Roadmap Product Management
Product Management
Backlog
Product Backlog
Organisation’sRoadmap Holistic Strategy
Organisation’s Strategy
OrganisationalManagementOrganisation’s Structure
Organisation’s Structure
Business Models
Business Models
Color Guide: Assets Types of Assets Temporary Artefacts (graph). The nodes represent the assets (the leaf nodes) andthe types/categories of assets (non-leaf nodes).The tree presented in Figure 5 contains the types of as-sets (The full tree is presented in Appendix A). Note that thenodes in the tree in Figure 5 are mapped to represent theirsource. For example, a node can be assigned with [P1] as areference for an article in the literature review. Similarly, [WS1] as a reference for an asset coming from industrialworkshops . And finally, Author Defined Assets ( [ADA] )which are assets included in the taxonomy by the researchersalthough it was not coming from industrial workshops orfrom the TD literature that we have covered but is supportedby SE literature.The following example clarifies the distinction between Temporary Artefact (grey cells presented in Table 3 and Ta-ble 4) and
Assets :An API description used by developers as a reference hasvalue in the development effort. If changes are made (newdecisions, new ways to adhere to components, etc.), but theAPI description is not updated to reflect this, the utility (value)of the API description becomes lower (the asset degrades).On the other hand, an automatically generated bug report isnot seen as an asset, as it is transient or intermediate. It is The IDs on the workshops on Table 4 have been obfuscated to preserveanonymity, and has no relationship with the order of companies shown inTable 1. generally created as a work product used once to be “trans-formed” into “change requests” or other management arte-facts. Once transformed, it is discarded to be replaced witha new bug report in subsequent test runs.The process of combining the asset matrices from the lit-erature review, the input from the industrial workshop, andcompleting the tree with
Author Defined Assets (ADA) re-sulted in the taxonomy containing asset types and the to-tal of assets. In the following subsections, we will firstpresent the types of assets and then describe the eight majortypes of assets labelled AM1 - AM8 . We include the defini-tions of each asset type together with their correspondingassets. After following the process described in Section 3.4,the following major types of assets were extracted:
Product-Requirements-Related Assets (AM1) refer to thetypes of assets and assets concerned with software require-ments, including the elicitation, analysis, specification, vali-dation, and management of requirements during the life cy-cle of the software product.
Product-Representation-Related Assets (AM2) refer to thetypes of assets and assets concerned with system-and archi-tectural design and any documentation related to these arte-facts.
Development-Related Assets (AM3) refer to the types ofassets and assets concerned with the development of the soft-ware product, including the code, build, versioning, and arte-
Zabardast et al.:
Preprint submitted to Elsevier
Page 11 of 22sset Management Taxonomy: A Roadmap
Figure 5:
The Asset Management Taxonomy. The tree contains only the types of assets.The full tree is presented in Appendix A. facts related to them.
Verification-and-Validation-Related Assets (AM4) refer tothe types of assets (including sub-types) and assets concernedwith software testing and quality assurance, and the outputprovided by such sub-type assets that help the stakeholdersinvestigate the quality of the software product.
Operations-Related Assets (AM5) refer to the types of as-sets and assets concerned with the data produced from oper-ational activities.
Environment-and-Infrastructure-Related Assets (AM6) refers to the types of assets and assets concerned with thedevelopment environment, the infrastructure, and the toolsand artefacts (including support applications) that facilitatethe development process.
Development-Process/Ways-of-Working- Related Assets(AM7) refer to the types of assets and assets concerned withall the interrelated processes and procedures that transforminputs into outputs during the development process.
Organisation-Related Assets (AM8) refer to the types ofassets and assets concerned with the organisation itself, suchas team constellation, team collaborations, and organisationalgovernance.
Product-Requirements-Related Assets include the follow-ing three types of assets (see Figure 6). Table 5 presentsproduct-requirements-related assets, their properties, and def-initions.
Functional-Requirement-Related Assets (AM1.1) refer to theassets related to the functions that the software shall provideand that can be tested [11]. We have observed the follow-ing assets belonging to this type:
Feature-Related BacklogItems , User Stories , and
Use Cases . Quality-Requirement-Related Assets (AM1.2) refer to the as-sets related to non-functional requirements that act to con-strain the solution [11]. We have observed the following as-sets belonging to this type:
System Requirements , User Inter-face Designs , Quality Scenarios (i.e., the -ilities), and
UserExperience Requirements . Product-Modification-Related Assets (AM1.3) refer to assetsthat mandate a change of the system and, but not necessarily,the requirements.
Change Requests is an asset we observedbelonging to this type.
Product-Representation-Related Assets include the fol-lowing two types of assets (see Figure 7). Table 6 presentsproduct-representation-related assets, their properties, and
Zabardast et al.:
Preprint submitted to Elsevier
Page 12 of 22sset Management Taxonomy: A Roadmap
Figure 6:
Product-Requirements-Related Assets Subtree.
Table 5
Product-Requirements-Related Assets’ Definitions.
Asset AM type Definition
Feature-RelatedBacklog Items AM1.1 Feature-Related Backlog Items are the results of refining and breaking down the user stories to createexecutable tasks [52].User Stories AM1.1 User Stories are, according to the agile development paradigm, a way to specify the features of the softwarethat is being developed [52].Use Cases AM1.1 Use Cases are lists of actions or events that describe how a user will achieve a goal in a system [34].System Requirements AM1.2 “System Requirements are the requirements for the system as a whole. System Requirements [...] encompassuser requirements, requirements of other stakeholders (such as regulatory authorities), and requirementswithout an identifiable human source.” [11].User Interface Designs AM1.2 “User Interface Design is an essential part of the software design process. User interface design should ensurethat interaction between the human and the machine provides for effective operation and control of themachine. For software to achieve its full potential, the user interface should be designed to match the skills,experience, and expectations of its anticipated users.” [11].Quality Scenarios(The -ilities) AM1.2 “A quality attribute (QA) is a measurable or testable property of a system that is used to indicate how wellthe system satisfies the needs of its stakeholders.” [5] A quality scenario is a way of stating a requirement inan unambiguous and testable manner [5].User Experience Re-quirements AM1.2 User Experience Requirements “are considered key quality determinants of any product, system or serviceintended for human use, which in turn can be considered as product, system or service success or failureindicators and improve user loyalty.” [41, 38].Change Requests AM1.3 Change Requests are the modifications to the software product that are not coming from the requirementsanalysis of the product. definitions.
Architecture-and-Design-Related Assets (AM2.1) refer to theassets that are used to design, communicate, represent, main-tain, and evolve the software product, which is divided into:•
Architectural-Documentation-Related Assets (AM2.1.1) refer to the assets used to design, communicate, repre-sent, maintain, and evolve the architectural represen-tation of a software product. We have observed thefollowing assets belonging to this type:
ArchitecturalModels and
Architectural Documentation .• Design-Related Assets (AM2.1.2) refer to the assetsthat belong to the design and design artefacts used dur-ing the development process. We have observed thefollowing assets belonging to this type:
Design Deci-sions Documentation and
System Designs . Product-Documentation-Related Assets (AM2.2) refer to theassets that belong to the product documentation and the pro-cess of creating such documentation. We have observed thefollowing assets belonging to this type:
Documentation Au-tomation Scripts and
Product Documentation . Development-Related Assets include the following threetypes of assets (see Figure 8). Table 7 presents the development-related assets, their properties, and definitions.
Build-Documentation-Related Assets (AM3.1) refer to the as-sets related to the build system itself, the build environment,and the build process. We have observed the following as-sets belonging to this type:
Build Plans , Build Results , and
Build Scripts . Code-Related Assets (AM3.2) refer to the assets that are re-lated to the source code. We have observed the following as-sets belonging to this type:
Source Code , Code Comments , APIs , Architecture (Code Structure) —i.e., a set of structuresthat can be used to reason about the system including the ele-ments, relations among them, and their properties [5]—, and
Libraries/External Libraries . Source-Code-Management-Related Assets (AM3.3) refer tothe assets related to managing the source code such as ver-sioning and problems in code versioning and burndown charts.
Versioning Comments is an asset we observed belonging tothis type.
Verification-and-Validation-Related Assets include the fol-lowing four types of assets (see Figure 9). Table 8 presentsverification-and-validation-related assets, their properties, anddefinitions.
Functional-Tests-Related Assets (AM4.1) refer to the assetsrelated to testing the functionality of the system, its relatedfeatures, and how they work together. We have observed the
Zabardast et al.:
Preprint submitted to Elsevier
Page 13 of 22sset Management Taxonomy: A Roadmap
Figure 7:
Product-Representation-Related Assets Subtree.
Table 6
Product-Representation-Related Assets’ Definitions.
Asset AM type Definition
Architectural Models AM2.1.1 Architecture Models are partial abstractions of systems, they capture different properties of the system [37].“Architecture modeling involves identifying the characteristics of the system and expressing it as models sothat the system can be understood. Architecture models allow visualisation of information about the systemrepresented by the model.” [39]Architectural Docu-mentation AM2.1.1 Architectural Documentation are the representations of the decisions made to construct the architecture ofthe software [37].Design Decisions Doc-umentation AM2.1.2 Design Decisions Documentation are the results of the design decisions that architects create and documentduring the architectural design process [11].System Designs AM2.1.2 System Designs are the processes of defining elements of a system. These elements are specified in therequirements and are extracted to create modules, architecture, components and their interfaces and datafor a system.DocumentationAutomation Scripts AM2.2 Documentation Automation Scripts are the scripts that generate documentation based on the state of thesource code.Product Documenta-tion AM2.2 Product Documentation are the operational guidelines (such as user manuals and installation guides ) forwhen the product is in use. following assets belonging to this type:
Unit Tests , Integra-tion Tests , System Tests , and
Acceptance Tests . Non-Functional-Test-Related Assets (AM4.2) refer to the as-sets related to testing the quality attributes of the system andwhether they satisfy the business goals and requirements.We have observed the following assets belonging to this type:
Non-Functional Test Cases and
Non-Functional Test Results . Test-Documentation-Related Assets (AM4.3) refer to the as-sets related to documenting the testing process.
Test Plans is an asset we observed belonging to this type.
Test-Automation-Related Assets (AM4.4) refer to the assetsthat are utilised for automated testing of the system. We haveobserved the following assets belonging to this type:
TestAutomation Scripts and
Test Automation (Real/Synthetic) Data . Operation-Related Assets are all the assets created as theresult of operational activities, extracted during the oper- ational activities, or used during the operational activities,e.g., any data collected during product use (see Figure 10).The observed operations-related assets include
Customer Data , Application Data , and
Usage Data . Table 9 presents operations-related assets, their properties, and definitions.
Environment-and-Infrastructure-Related Assets are all theassets used in the development environment or as an infras-tructure for development during software development (seeFigure 11). The observed environment-and-infrastructure-related assets include
Deployment Infrastructure , Tools , and
Tools Pipelines . Table 10 presents environment-and- infras-tructure -related assets, their properties, and definitions.
Figure 8:
Development-Related Assets Subtree.Zabardast et al.:
Preprint submitted to Elsevier
Page 14 of 22sset Management Taxonomy: A Roadmap
Table 7
Development-Related Assets’ Definitions.
Asset AM type Definition
Build Plans AM3.1 Build Plans are the descriptions of how developers intend to build the software, i.e., by compilation ofartefacts in a build chain, which will end in a running software.Build Results AM3.1 Build Results are the results of the build process, including the comments, documentation, and other artefactsthat are generated during the build process.This is seen as a persistent asset if it holds more data than justan automated “throw away” report, and/or if the asset is used for reference over time.Build Scripts AM3.1 Build Scripts are the scripts that are used to run the build process.Source Code AM3.2 Source Code is the collection of code written in a human-readable and comprehensible manner stored asplain text [31].Code Comments AM3.2 Code Comments are the comments that developers integrate and write within the source code to clarify anddescribe certain parts of the code or its functionality [27].APIs AM3.2 APIs (Application Program Interfaces) are the interfaces that are created to facilitate interaction of differentcomponents and modules.Architecture (CodeStructure) AM3.2 Architecture is the actual and fundamental relationships and structure of a software system and its sourcecode [5].Libraries/ External Li-braries AM3.2 Libraries/External Libraries are source code that belongs to the product but is not developed or maintainedwithin the project, i.e., the developers. The software project depends on it and references the library.Web Services AM3.2 Web Services are running services on devices handling requests coming from networksVersioning Comments AM3.3 Versioning comments are the comments that developers submit to any version control application they usefor the development. Such comments can later be extracted and viewed to identify the purpose of eachevent.
Figure 9:
Verification-and-Validation-Related Assets Subtree.
Development-Process / Ways-of-Working-Related Assetsinclude the following three types of assets (see Figure 12).Table 11 presents development-process / ways-of-working-related assets, their properties, and definitions.
Product-Management-Related Assets (AM7.1) refer to the as-sets related to dealing with the specific software-intensiveproduct that is being created. These assets come from dif-ferent stages, such as business justification, planning, devel- opment, verification, pricing, and product launch. We haveobserved the following assets belonging to this type:
Prod-uct Management Documentation , Documentation About Re-lease Procedure , Product Business Models , Product Roadmap , Product Scope , and
Product Backlog . Process-Management-Related Assets (AM7.2) refer to the as-sets related to managing the development process, includinginternal rules, plans, descriptions, specifications, strategies,and standards. We have observed the following assets be-longing to this type:
Requirements Internal Standards , Ar-
Table 8
Verification-and-Validation-Related Assets Definitions.
Asset AM type Definition
Unit Tests AM4.1 Unit Tests are the tests written to examine the individual units of the code [28]. “Unit tests generallyfocus on the program logic within a software component and on correct implementation of the componentinterface.” [7]Integration Tests AM4.1 Integration Tests are the tests written to examine the combined set of modules as a group [7, 29].System Tests AM4.1 System Tests are the tests written to examine the system’s compliance with the requirements.Acceptance Tests AM4.1 Acceptance Tests are the tests conducted to examine and determine whether the requirements are metaccording to the specifications of the requirements.Non-Functional TestCases AM4.2 Non-Functional Test Cases are the tests that examine the quality of the system, i.e., non-functional aspectssuch as performance, availability, and scalability.Test Plans AM4.3 Test Plans are the documents that describe the testing scope and test activities that will be performed onthe system throughout the development lifecycle.Test AutomationScripts AM4.4 Test Automation Scripts are the scripts that automate part of the testing process. More specifically, thescripts automate distinct testing activities or types of tests.Test Automation(Real/ Synthetic)Data AM4.4 Test Automation (Real/Synthetic) Data is the generated data that are used by the automation scripts totest the system.
Zabardast et al.:
Preprint submitted to Elsevier
Page 15 of 22sset Management Taxonomy: A Roadmap
Figure 10:
Operation-Related Assets Subtree.
Table 9
Operations-Related Assets’ Definitions.
Asset AM type Definition
Customer Data AM5 Customer Data is data that is collected from the customers (end users) of the software product such as userfeedback.Application Data AM5 Application Data is the data that is created, collected, used, and maintained while developing the softwareproduct such as system performance.Usage Data AM5 Usage Data is the data that is collected while the software product is operational such as the data relatedto the performance of the system. chitectural Internal Standards , Documentation Internal Rules/ Specifications , Build Internal Standards , Coding InternalStandards / Specifications , Versioning Internal Rules / Spec-ifications , Testing Internal Rules / Specifications / Plans /Strategies , Process Internal Descriptions , Process Data , and
Documentation About Ways of Working . Organisation-Related Assets are all the assets that repre-sent organisations’ properties (see Figure 13). The observedorganisation-related assets include Organisation’s Structure,Organisation’s Strategy, Human Capital, and Business Mod-els. Table 12 presents organisation-related assets, their prop-erties, and definitions.
5. Discussion
In this section, we first discuss our findings in light of theresearch questions, followed by the general lessons learnedand implications. 𝑅𝑄 ∶ What assets are important for organisations dur-ing the inception, planning, development, evolution, and main-tenance of SIPS?
We present a taxonomy of assets, which includes eightmajor types of assets
AM1 to AM8 . The types of assets be-longing to each of the major types of assets are not isolated,i.e., some types of assets and assets in them are interrelated.For example, the asset architectural documentation is di-rectly related to the asset architecture . Architectural doc-umentation represents the architecture of the system.Out of the eight major types of assets, two types have
Figure 11:
Environment-and-Infrastructure-Related Assets Subtree.
Table 10
Environment-and-Infrastructure-Related Assets’ Definitions.
Asset AM type Definition
Deployment Infras-tructure AM6 Deployment Infrastructure are all the steps, activities, tools, process descriptions, and processes that facilitatethe deployment of a software-intensive product.Tools AM6 Tools are any physical and virtual entities that are used for the development of a software product such asintegrated development environments (IDE), version control systems, spreadsheets applications, compilers,and debuggers.Tools Pipelines AM6 Tool Pipelines are automated processes and activities that facilitate and enable developers to reliably andefficiently compile, build, and deploy the software-intensive product.
Zabardast et al.:
Preprint submitted to Elsevier
Page 16 of 22sset Management Taxonomy: A Roadmap
Figure 12:
Development-Process/Ways-of-Working-Related Assets Subtree.
Table 11
Development-Process/Ways-of-Working-Related Assets’ Definitions.
Asset AM type Definition
Product ManagementDocumentation AM7.1 Product Management Documentation is any documentation that is used to facilitate the managementactivities and processes during the product development.DocumentationAbout Release Proce-dure AM7.1 Documentation About Release Procedure is the description of the product release plan and the entities andactivities associated with release.Product BusinessModels AM7.1 Product Business Models are the descriptions of how the organisation creates value for the customers withthe software-intensive product.Product Roadmap AM7.1 Product Road Map is the abstract, high-level description of the evolution of the product during the devel-opment.Product Scope AM7.1 Product Scope is the description of the characteristics, functionality, and features of the software-intensiveproduct.Product Backlog AM7.1 Product Backlog is any document that acts as a list where the features, change requests, bug fixes, andother similar activities are stored, listed, and prioritised.Requirements InternalStandards AM7.2 Requirements Internal Standards are the specific rules that the company introduces and utilises internallyfor dealing with the requirements of the product.Architectural InternalStandards AM7.2 Architectural Internal Standards are the specific rules that the development team introduces and utilisesinternally for designing, creating, and maintaining the architecture of the software-intensive product.Documentation Inter-nal Rules / Specifica-tions AM7.2 Documentation Internal Rules/Specifications are the specific rules that the development team introducesand utilises internally for creating and maintaining the documentation.Build Internal Stan-dards AM7.2 Build Internal Standards are the specific rules that the development team introduces and utilises internallyfor the build activities.Coding Internal Stan-dards/Specifications AM7.2 Coding Internal Standards/Specifications are the rules that the development team introduces and utilisesinternally while developing the software-intensive product.Versioning InternalRules / Specifications AM7.2 Versioning Internal Rules/Specifications are the rules that the development team introduces and utilisesinternally for version control during the development of software-intensive products.Testing Internal Rules/ Specifications /Plans / Strategies AM7.2 Testing Internal Rules/Specifications/Plans/Strategies are the rules that the development team introducesand utilises internally for testing activities and procedures.Process Internal De-scriptions AM7.2 Process Internal Descriptions are the descriptions of the procedures and activities that the development teamintroduce and utilise during the development of software-intensive products.Process Data AM7.2 Process Data is are the metrics and other information that concern the past and current status of thedevelopment process. Examples of such data are velocity, issues, bugs, backlog items, etc.DocumentationAbout Ways ofWorking AM7.2 Documentation About Ways of Working are the description of work plans and working patterns, i.e., howthe organisation and the development team plan to create and release the software-intensive product.
Figure 13:
Organisation-Related Assets Subtree.Zabardast et al.:
Preprint submitted to Elsevier
Page 17 of 22sset Management Taxonomy: A Roadmap
Table 12
Organisation-Related Assets’ Definitions.
Asset AM type Definition
Organisation’s Struc-ture AM8 Organisation’s Structure is the description of how the organisation directs the activities to achieve organisa-tional goals.Organisation’s Strat-egy AM8 Organisation’s Strategy is the description of the plans that guide the organisation how to allocate its resourcesto support the development of the software-intensive product.Business Models AM8 Business Models are the descriptions of how the organisation creates value with the software-intensive productfor the organisation. been studied more extensively, namely
Development-Related
Assets and
Product-Representation-Related
Assets, whichare aligned with previous studies such [4], i.e., prior studiesfocus on source-code-related assets. These types of assetsare easier to study due to the abundance of metrics and eval-uation methods and, therefore, have been studied in manyarticles. The reason behind this might be that:• The technical debt metaphor was initially introducedin the context of these prevalent assets [4]. Thereforethe researchers had more time investigating and ex-ploring this specific phenomenon. For example, manypapers investigate a software product’s architecture,exploring different ways of evaluating architecture us-ing different tools and measurements.• These types of assets are easier to contextualise in theTD metaphor, i.e., identifying such assets and howthey can be subject to incur debt. For example, theconcept of code smells is easier to grasp since it isa more tangible artefact. It is simple to define howthe software product can incur debt if the code is not“quite right”; i.e., it is smelly.The rest of the types of assets have not received extensivetime to be explored. The reason behind this might be that:• These types of assets were added later as “types oftechnical debt,” such as Requirements Debt and Pro-cess Debt. The technical debt metaphor was not ini-tially used to deal with these types of artefacts [4].These types of TD were introduced in an effort to ex-tend the metaphor and, therefore, have not been inves-tigated thoroughly.• Unlike the other types (i.e.,
Development-Related and
Product-Representation-Related
Assets), it is harderto identify and/or define how and to what extent theycan incur debt in software products. For example, in-curring Documentation Debt might differ in differentcompanies and development teams.• These types of assets are intertwined with the contextof the development process, the culture of the com-pany and the development team, and their standardsand way-of-work. What is considered debt might bedifferent depending on the context.We have seen that the existing literature on TD classi-fies various TD types and presents ontologies on the topic. These classifications have evolved since the introduction ofthe extended TD metaphor. We observe that the relevant as-set categories we have extracted from industrial insights canbe mapped to the classifications provided in TD literature.We observe that:• Some existing TD types and categories, such as codethat are well-defined and well-recognised fit into sim-ilar categories as in the presented taxonomy. The in-dustrial insights and definitions of such assets are con-sistent with the definitions from TD literature.• Some asset types that are relevant to the industry havebeen understudied. There is room for extending theresearch in such areas, e.g.,
Operations-Related Assets(AM5) and
Environment-and-Infrastructure-Related As-sets (AM6) , which is noticeable when examining Ta-ble 3, i.e., more assets and types of assets are in thetop rows of the matrix (see Section 4.1).• By creating the taxonomy, we highlight both the areasof interest and the gaps in research. Therefore, iden-tifying the areas in the software engineering body ofknowledge that need to be investigated and the areasthat need to evolve according to the current interest.
In this section, we will present the lessons learned fromrunning the industrial workshops, synthesising the findings,and creating the taxonomy. The importance of source-code-related assets is undeniable (i.e., assets in
AM1 , AM2 , AM3 ,and
AM4 ). However, we observe that the social and organi-sation aspect of the development is very important to indus-try though these aspects have not received as much attentionin the TD area [4, 55]. Taking a look at some statementsfrom participants in the industrial workshops highlights thisfact. Examples of such statements are:• “There are many people who work in the same areain the same code base. Creates conflicts and slow re-leases.” • “The problem is the delta operation, and the plan isat such a high level that it is impossible to understand.Too abstract.” • “... training the teams in what is considered best prac-tices improves team cohesion and eases collaboration.” • “[There is] no holistic platform strategy (Conway’slaw).” Zabardast et al.:
Preprint submitted to Elsevier
Page 18 of 22sset Management Taxonomy: A Roadmap
The large-scale software projects developed in large or-ganisations are highly coupled with the social and organisa-tion aspect of work. The prevalence of assets related to thesocial and organisation aspect of development, e.g.,
Busi-ness Models and
Product Management Documentation , in-dicates the necessity to characterise and standardise such as-sets, how they are perceived, and how they are measured andmonitored.While creating the taxonomy, we observed that assetsdo not exist in isolation, i.e., they are entities with charac-teristics and properties that exist in a software developmentecosystem. In the following, we will discuss the assets withsimilar characteristics and properties and assets that have im-plicit relations between each other.
Assets that have similar characteristics and properties.
For example,
Unit Tests have similar characteristics and prop-erties as
Source Code , i.e., unit tests are code, and there-fore, their value degradation can have analogous connota-tions. This means that there are possibilities to evaluate suchassets’ degradation with similar characteristics and proper-ties using similar metrics. Still, the degradation of one (e.g.,Unit Tests) regarding the other (e.g., Source Code) is alsorelevant.- Moreover, the degradation of one asset (e.g., SourceCode) might impact the degradation of the other asset (e.g.,Unit Tests). Therefore, such coupling and relations of theassets should be considered when analysing and managingsuch assets.
Assets that have implicit relations between each other.
Implicit relations between assets can arise from their inher-ent coupling properties. Different assets related to certainaspects of the product will have implicit relations that are notvisible in the taxonomy as presented now. For example,
Ar-chitectural Models and
Architecture (Code Structure) havean inherent relationship. Architectural Models should bethe representation of the architecture of the system, i.e., thecode structure. Therefore, similar to the previous point, thevalue degradation of the assets with such implicit relationscan have analogous connotations. Their degradation mightimpact the degradation of the other assets in the relation-ship. For example, the degradation of any of the functional-requirements-related assets will eventually be reflected in thedegradation of functional-test-related assets.
The contribution of this work is the following:• Providing common terminology and taxonomy for as-sets that are utilised during software development and;• Providing a mapping over the assets and the input usedto create the taxonomy, i.e., input from the literatureand input from the industryOne contribution of the taxonomy is that it is a guidelinefor future research by providing a map of different types ofassets. The map illustrates the different areas that are definedand studied, and the ones that are not standardised or under-explored. Therefore, the taxonomy provides a summary of the body of knowledge by linking empirical studies with in-dustrial insights gathered through the industrial workshops.Providing a common taxonomy and vocabulary:• Makes it easier for the communities to communicatethe knowledge.• Creates the opportunity to find and build upon previ-ous work.• Helps to identify the gaps by linking the empiricalstudies to the taxonomy.• Highlights the areas of interest.• Makes it possible to build and add to the taxonomy(new assets, details) as knowledge is changed over timeby researchers in the field.• For practitioners, the evolving taxonomy can be usedas a map of different assets that are normally not as-sociated with the implications of degradation, and po-tentially the implications of said degradation can betraced.Another minor contribution is that the taxonomy helpsdraw out the assets with similar characteristics and implicitrelations between each other. Most of such similarities ofcharacteristics, properties, and relations are not immediatelyvisible when considering the assets from certain perspec-tives. Taking a more abstract and high-level look at the assetsinvolved in the development of software-intensive productscan help facilitate the management activities and the overalldevelopment process.Finally, large companies deal with developing SIPS, andthey rely on external resources to help them achieve the busi-ness goals of their products. A major external contributorto new knowledge that can help the practitioners in the in-dustry is research findings. Therefore, understanding andapplying the research findings is crucial for them. Havinga taxonomy of assets summarising the state-of-the-art andstate-of-practice body of knowledge for the assets utilisedfor developing software-intensive products is useful. Prac-titioners can refer to the taxonomy systematically built withthe accumulated knowledge of academia and other practi-tioners to extract what they need in specific domains.We believe that our observations and effort to bring thedifferent assets and terminologies used to describe the assetswill help practitioners be more aware of each type of assetsand how they are managed in the context.
Similar to any other research work, this research has itslimitations and threats to validity. In this section, we coverthe limitations of our work and how they might affect theresults. The asset management taxonomy dimensions, bothasset types and assets, do not represent an exhaustive list.The taxonomy is created based on the data extracted fromthe literature review and the industrial workshops. We com-bined the inputs from literature and industry to create the
Zabardast et al.:
Preprint submitted to Elsevier
Page 19 of 22sset Management Taxonomy: A Roadmap taxonomy. We designed the taxonomy to be extendable withnew data identified by us and others in future studies as soft-ware engineering areas evolve. We encourage researchersand practitioners to consider the taxonomy within their or-ganisation and identify the potential new asset types and as-sets that can complement the asset management taxonomy’srepresentativeness.In the rest of this section, we cover the threats to con-struct, internal, and external validity as suggested by Rune-son and Höst [56] and Runeson et al. [57].•
Construct validity reflects the operational measurementsand how the study represents what is being investi-gated. Our research uses two primary sources of data,namely the literature review and the industrial work-shops. We are aware that the literature review is notinclusive, and it is within a limited area, i.e., Techni-cal Debt. We chose the technical debt topic for thereasons mentioned in Section 3.2. We acknowledgethat limiting the literature review to a specific topicmight affect the construct validity of this work, i.e.,the input from literature. We are also aware that theparticipants’ statements in the workshops can be in-terpreted differently by the researcher and the partic-ipants. We mitigate this threat in two ways. First, byhaving two researchers coding the raw data indepen-dently; and second, by choosing to code the data usingthe in vivo coding method, the qualitative analysis pri-oritises the participants’ opinions.•
External validity refers to the generalisability of theresults and whether the results of a particular study canhold in other cases. We acknowledge and understandthat the results are not comprehensive and might notbe generalisable. The created taxonomy is based onthe collected data and is extendable. Additionally, thetaxonomy was designed to be agnostic to processes,but since some of the assets are more associated withcertain processes, the taxonomy cannot be truly ag-nostic. Finally, other threats that can affect the study’sexternal validity are the number of involved compa-nies, the country where the companies (investigatedsites) are located, i.e., Sweden, and involvement of allthe roles in these organisations.•
Reliability refers to the extend that the data and analy-sis is dependent of the researchers. When conductingqualitative studies, the threat to validity is the replica-bility of the results and the process [46]. In the case ofour study, the context and the participants of the work-shops are unique and therefore not repeatable. Butthere is an acceptable margin of validity on the resultswhen conducting qualitative research [46]. We havetried to mitigate this threat by relying on consistencyin both when conducting the workshops and the anal-ysis.
6. Conclusions and Future Work
This paper presents a taxonomy for classifying assets thathave inherent value for an organisation and are subject todegradation. These assets are used during the developmentof SIPS. The taxonomy is created and built upon the dataextracted from a literature review and industrial workshops.The authors completed the taxonomy by identifying the as-sets that were not mentioned during the workshops or the lit-erature review, i.e., author defined assets (ADA). This work,i.e., the creation of the taxonomy of assets, attempts to pro-vide an overarching perspective on various assets for aca-demicians and practitioners. The taxonomy allows us to char-acterise and organise the body of knowledge by providing acommon vocabulary of and for assets.We have addressed the research question by creating thetaxonomy and defining the types of assets and the assets thatbelong to those types. Eight major asset types are introducedin the taxonomy: assets related to
Product Requirements , Product Representation , Development , Verification and Val-idation , Operations , Environment and Infrastructure , Devel-opment Process/ Ways-of-Working , and
Organisation . Thetaxonomy could be used for:• Identify the gaps in research by providing the pointsof interest from practitioners’ perspectives.• Identify the state-of-the-art research for individual as-sets and their properties for practitioners.• Communicate and disperse the body of knowledge.The dimensions provided by our taxonomy are not ex-haustive. Therefore, we intend to conduct further investiga-tion to complement the taxonomy by incorporating the newknowledge. Furthermore, we would like to study assets thatco-occur in management activities and how they impact eachother and the development process. Lastly, we intend to in-vestigate the individual properties of assets to identify themetrics used for measuring the asset (or lack thereof). Themetrics will be investigated to evaluate how they can help uspresent the state of assets and their degradation.Besides, future and ongoing work will use the taxon-omy as a base for further studies and exploration of assets,their characteristics, and the concepts of value, degradation,and different types of degradation. Finally, we would like toinvestigate how the taxonomy can be utilised practically inthe industry beyond the mainstream of (mostly) code relatedtools and methods.
A. Appendix: The Asset ManagementTaxonomy
The full tree of the asset management taxonomy is pre-sented in Figure 14.
References [1] Alves, N.S., Mendes, T.S., de Mendonça, M.G., Spínola, R.O., Shull,F., Seaman, C., 2016. Identification and management of technical
Zabardast et al.:
Preprint submitted to Elsevier
Page 20 of 22sset Management Taxonomy: A Roadmap debt: A systematic mapping study. Information and Software Tech-nology 70, 100–121.[2] Alves, N.S., Ribeiro, L.F., Caires, V., Mendes, T.S., Spínola, R.O.,2014. Towards an ontology of terms on technical debt, in: 2014 SixthInternational Workshop on Managing Technical Debt, IEEE. pp. 1–7.[3] Ampatzoglou, A., Bibi, S., Chatzigeorgiou, A., Avgeriou, P., Stame-los, I., 2018. Reusability index: A measure for assessing softwareassets reusability, in: International Conference on Software Reuse,Springer. pp. 43–58.[4] Avgeriou, P., Kruchten, P., Ozkaya, I., Seaman, C., 2016. Manag-ing technical debt in software engineering (dagstuhl seminar 16162),in: Dagstuhl Reports, Schloss Dagstuhl-Leibniz-Zentrum fuer Infor-matik.[5] Bass, L., Clements, P., Kazman, R., 2003. Software architecture inpractice. Addison-Wesley Professional.[6] BenIdris, M., 2020. Investigate, identify and estimate the technicaldebt: a systematic mapping study. Available at SSRN 3606172 .[7] Berner, S., Weber, R., Keller, R.K., 2005. Observations and lessonslearned from automated testing, in: Proceedings. 27th InternationalConference on Software Engineering, 2005. ICSE 2005., pp. 571–579. doi: .[8] Besker, T., Martini, A., Bosch, J., 2017. Time to pay up: Technicaldebt from a software quality perspective., in: CIbSE, pp. 235–248.[9] Besker, T., Martini, A., Bosch, J., 2018. Managing architectural tech-nical debt: A unified model and systematic literature review. Journalof Systems and Software 135, 1–16.[10] Blum, B.I., 1994. A taxonomy of software development methods.Communications of the ACM 37, 82–94.[11] Bourque, P., Fairley, R.E., et al., 2014. Guide to the software engineer-ing body of knowledge (SWEBOK (R)): Version 3.0. IEEE ComputerSociety Press.[12] Broughton, V., 2015. Essential classification. Facet Publishing.[13] Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P.,Lim, E., MacCormack, A., Nord, R., Ozkaya, I., et al., 2010. Manag-ing technical debt in software-reliant systems, in: Proceedings of theFSE/SDP workshop on Future of software engineering research, pp.47–52.[14] Broy, M., 2018. A logical approach to systems engineering artifacts:semantic relationships and dependencies beyond traceability—fromrequirements to functional and architectural views. Software & Sys-tems Modeling 17, 365–393.[15] Cicchetti, A., Borg, M., Sentilles, S., Wnuk, K., Carlson, J., Pap-atheocharous, E., 2016. Towards software assets origin selection sup-ported by a knowledge repository, in: 2016 1st International Work-shop on Decision Making in Software ARCHitecture (MARCH),IEEE. pp. 22–29.[16] Coghlan, D., Brannick, T., 2014. Doing Action Research in Your OwnOrganization (4th ed.). London: Sage.[17] Constantopoulos, P., Doerr, M., 1995. Component classification inthe software information base. Object-Oriented Software Composi-tion , 177.[18] Cunningham, W., 1992. The wycash portfolio management system.ACM SIGPLAN OOPS Messenger 4, 29–30.[19] Falessi, D., Shaw, M.A., Shull, F., Mullen, K., Keymind, M.S., 2013.Practical considerations, challenges, and requirements of tool-supportfor managing technical debt, in: 2013 4th International Workshop onManaging Technical Debt (MTD), IEEE. pp. 16–19.[20] Fernández-Sánchez, C., Díaz, J., Pérez, J., Garbajosa, J., 2014. Guid-ing flexibility investment in agile architecting, in: 2014 47th HawaiiInternational Conference on System Sciences, IEEE. pp. 4807–4816.[21] Fernández-Sánchez, C., Garbajosa, J., Yagüe, A., Perez, J., 2017.Identification and analysis of the elements required to manage techni-cal debt by means of a systematic mapping study. Journal of Systemsand Software 124, 22–38.[22] Fox, M., Green, G., Martin, P., 2007. Doing practitioner research.Sage.[23] Garriga, M., 2017. Towards a taxonomy of microservices architec-tures, in: International Conference on Software Engineering and For- mal Methods, Springer. pp. 203–218.[24] Glass, R.L., Vessey, I., 1995. Contemporary application-domain tax-onomies. IEEE Software 12, 63–76.[25] Glass, R.L., Vessey, I., Ramesh, V., 2002. Research in software en-gineering: an analysis of the literature. Information and Softwaretechnology 44, 491–506.[26] Griffith, I., Taffahi, H., Izurieta, C., Claudio, D., 2014. A simula-tion study of practical methods for technical debt management in ag-ile software development, in: Proceedings of the Winter SimulationConference 2014, IEEE. pp. 1014–1025.[27] Grubb, P., Takang, A.A., 2003. Software maintenance: concepts andpractice. World Scientific.[28] Hamill, P., 2004. Unit test frameworks: tools for high-quality softwaredevelopment. " O’Reilly Media, Inc.".[29] ISO/IEC/IEEE, 2010. Systems and software engineering.ISO/IEC/IEEE 24765:2010. Technical Report. ISO/IEC/IEEE.[30] ISO/IEC/IEEE, 2014. Asset management - Overview, principles,andsch terminology ISO/IEC/IEEE 55000:2014. Technical Report.ISO/IEC/IEEE.[31] Kernighan, B.W., 1974. ‘programming in c- a tutorial. Unpublishedinternal memorandum, Bell Laboratories .[32] Kroll, P., Kruchten, P., 2003. The Rational Unified Process MadeEasy: A Practitioner’s Guide to the RUP: A Practitioner’s Guide tothe RUP. Addison-Wesley Professional.[33] Kruchten, P., 2000. The rational unified process 2nd edition: An in-troduction.[34] Kruchten, P., 2004. The rational unified process: an introduction.Addison-Wesley Professional.[35] Kruchten, P., Nord, R., Ozkaya, I., 2019. Managing Technical Debt:Reducing Friction in Software Development. Addison-Wesley Pro-fessional.[36] Kruchten, P., Nord, R.L., Ozkaya, I., 2012. Technical debt: Frommetaphor to theory and practice. Ieee software 29, 18–21.[37] Kruchten, P.B., 1995. The 4+ 1 view model of architecture. IEEEsoftware 12, 42–50.[38] Kujala, S., Miron-Shatz, T., 2013. Emotions, experiences and usabil-ity in real-life mobile phone use, in: Proceedings of the SIGCHI Con-ference on Human Factors in Computing Systems, pp. 1061–1070.[39] Kumar, A., Nori, K.V., Natarajan, S., Lokku, D.S., 2014. Value ma-trix: From value to quality and architecture, in: Economics-DrivenSoftware Architecture. Elsevier, pp. 205–240.[40] Kwasnik, B.H., 1992. The role of classification structures in reflectingand building theory. Advances in Classification Research Online 3,63–82.[41] Law, E.L.C., Van Schaik, P., 2010. Modelling user experience–anagenda for research and practice. Interacting with computers 22, 313–322.[42] Lehman, M., 1996. Laws of software evolution revisited, in: Euro-pean Workshop on Software Process Technology, Springer, Berlin,Heidelberg. pp. 108–124.[43] Lehman, M.M., 1979. On understanding laws, evolution, and conser-vation in the large-program life cycle. Journal of Systems and Soft-ware 1, 213–221.[44] Lenarduzzi, V., Besker, T., Taibi, D., Martini, A., Fontana, F.A.,2019. Technical debt prioritization: State of the art. a systematic lit-erature review. arXiv preprint arXiv:1904.12538 .[45] Letouzey, J.L., Ilkiewicz, M., 2012. Managing technical debt with thesqale method. IEEE software 29, 44–51.[46] Leung, L., 2015. Validity, reliability, and generalizability in qualita-tive research. Journal of family medicine and primary care 4, 324.[47] Li, Z., Avgeriou, P., Liang, P., 2015. A systematic mapping study ontechnical debt and its management. Journal of Systems and Software101, 193–220.[48] von Linné, C., 1735. Systema naturae; sive, Regna tria naturae: sys-tematice proposita per classes, ordines, genera & species. Haak.[49] Méndez, D., Böhm, W., Vogelsang, A., Mund, J., Broy, M.,Kuhrmann, M., Weyer, T., 2019. Artefacts in software engineering:a fundamental positioning. Software & Systems Modeling 18, 2777–
Zabardast et al.:
Preprint submitted to Elsevier
Page 21 of 22sset Management Taxonomy: A Roadmap , a, Z., Prikladnicki, R., 2014. An empir-ically based terminology and taxonomy for global software engineer-ing. Empirical Software Engineering 19, 105–153.[62] Sommerville, I., 2015. Software engineering. 10th, in: BookSoftware Engineering. 10th, Series Software Engineering. Addison-Wesley.[63] Stringer, E.T., 2014. Action Research (4th Edition). Thousand Oaks,CA: Sage.[64] Svahnberg, M., Van Gurp, J., Bosch, J., 2005. A taxonomy of vari-ability realization techniques. Software: Practice and experience 35,705–754.[65] Taivalsaari, A., Mikkonen, T., 2018. A taxonomy of iot client archi-tectures. IEEE software 35, 83–88.[66] Tilley, S., Huang, S., 2002. Documenting software systems withviews iii: towards a task-oriented classification of program visual-ization techniques, in: Proceedings of the 20th annual internationalconference on Computer documentation, pp. 226–233.[67] Tom, E., Aurum, A., Vidgen, R., 2012. A consolidated understandingof technical debt .[68] Tom, E., Aurum, A., Vidgen, R., 2013. An exploration of technicaldebt. Journal of Systems and Software 86, 1498–1516.[69] Unterkalmsteiner, M., Feldt, R., Gorschek, T., 2014. A taxonomy forrequirements engineering and software test alignment. ACM Transac-tions on Software Engineering and Methodology (TOSEM) 23, 1–38.[70] Usman, M., Britto, R., Börstler, J., Mendes, E., 2017. Taxonomies insoftware engineering: A systematic mapping study and a revised tax-onomy development method. Information and Software Technology85, 43–59. [71] Vegas, S., Juristo, N., Basili, V.R., 2009. Maturing software engineer-ing knowledge through classifications: A case study on unit testingtechniques. IEEE Transactions on Software Engineering 35, 551–565.[72] Vessey, I., Ramesh, V., Glass, R.L., 2005. A unified classificationsystem for research in the computing disciplines. Information andSoftware Technology 47, 245–255.[73] Wohlin, C., 2014a. Guidelines for snowballing in systematic litera-ture studies and a replication in software engineering, in: Proceedingsof the 18th international conference on evaluation and assessment insoftware engineering, pp. 1–10.[74] Wohlin, C., 2014b. Writing for synthesis of evidence in empiricalsoftware engineering, in: Proceedings of the 8th ACM/IEEE Interna-tional Symposium on Empirical Software Engineering and Measure-ment, pp. 1–4.[75] Wohlin, C., Wnuk, K., Smite, D., Franke, U., Badampudi, D., Cic-chetti, A., 2016. Supporting strategic decision-making for selectionof software assets, in: International conference of software business,Springer. pp. 1–15.[76] Wolfram, K., Martine, M., Sudnik, P., 2020. Recognising the types ofsoftware assets and its impact on asset reuse, in: European Conferenceon Software Process Improvement, Springer. pp. 162–174.[77] Zabardast, E., Frattini, J., Gonzalez-Huerta, J., Mendez, D.,Gorschek, T., 2021. Asset management in software engineering –what is it after all? arXiv preprint arXiv:2101.07768 .[78] Zhao, Y., Dong, J., Peng, T., 2009. Ontology classification forsemantic-web-based software engineering. IEEE Transactions on Ser-vices Computing 2, 303–317. Zabardast et al.:
Preprint submitted to Elsevier
Page 22 of 22sset Management Taxonomy: A Roadmap
Figure 14:
The asset management taxonomy.Zabardast et al.: