Article

The WyCash portfolio management system

Authors:
To read the full-text of this research, you can request a copy directly from the author.

Abstract

The AUTOSPEC system is an automatic motor specification software system that primarily serves to non-interactively produce bill of materials from sales orders. At the core, the system applies Expert System and coordinated Relational Database technology ...

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the author.

... In particular, debt principal indicates the effort required to fix a current, non-optimal solution, whereas debt interest indicates the recurrent effort necessary to keep maintaining it [1]. As an example, consider a portfolio management system that requires massive revisions in order to accommodate for the changes required by the customer [2]. The interest represents the recurrent costs of making the revisions, whereas the principal is the cost of completely replacing the solution with a new one that would allow these changes to be seamless. ...
... In the next sub-section, we will give examples of six different cases, in order to provide a richer, qualitative description of both the smells and the participants perception. The examples were chosen to best represent the various aspects of our data set such as: (1) the ratio of agreement/disagreement with estimations; (2) whether the project is open source or industrial; (3) whether it concerned large or small smell instances; and finally, (4) whether the cases simply presented more insights. ...
Preprint
Full-text available
A key aspect of technical debt (TD) management is the ability to measure the amount of principal accumulated in a system. The current literature contains an array of approaches to estimate TD principal, however, only a few of them focus specifically on architectural TD, and none of these are fully automated, freely available, and thoroughly validated. Moreover, a recent study has shown that many of the current approaches suffer from certain shortcomings, such as relying on hand-picked thresholds. In this paper, we propose a novel approach to estimate architectural technical debt principal based on machine learning and architectural smells to address such shortcomings. Our approach can estimate the amount of technical debt principal generated by a single architectural smell instance. To do so, we adopt novel techniques from Information Retrieval to train a learning-to-rank machine learning model that estimates the severity of an architectural smell and ensure the transparency of the predictions. Then, for each instance, we statically analyse the source code to calculate the exact number of lines of code creating the smell. Finally, we combine these two values to calculate the technical debt principal. To validate the approach, we conducted a case study and interviewed 16 practitioners, from both open source and industry, and asked them about their opinions on the TD principal estimations for several smells detected in their projects. The results show that for 71\% of instances, practitioners agreed that the estimations provided were \emph{representative} of the effort necessary to refactor the smell.
... The debt metaphor reflects that debt accumulates interest: the later it is paid, the more it costs 5 [1]. While TD can be treated as an investment to enable rapid delivery in time-critical situations, such as meeting market windows for early adopters, it should be carefully managed to ensure that its negative consequences do not exceed its benefits [1,2]. Specifically, the accumulation of TD in a given system can lead to a significant drop in system quality, increased maintenance 10 costs, eventual system decay, customer dissatisfaction, and a negative impact on software practitioners [3,4]. ...
... Lastly, Section 8 concludes the study. 4 J o u r n a l P r e -p r o o f Journal Pre-proof 2 ...
... Consequently, developers often tend to overlook good programming practices and principles to deliver the most appropriate product on time [2]- [4]. This manner of programming causes the introduction of the so-called technical debt (TD) [5], i.e., a metaphor from the financial domain that consists in adopting (intentionally or not [6]) a limited solution instead of a better one that would require more effort. ...
... Over the last years, several studies have proven the harmfulness of keeping technical debt alive in software systems and the negative consequences it entails. These studies have demonstrated that technical debt leads to increase costs [7], [8], decrease product quality [9], [10], and slow down the entire software development process [5], [11], thus being detrimental to software systems. ...
Conference Paper
Full-text available
Technical debt management is a critical activity that is gaining the attention of both practitioners and researchers. Several tools providing automatic support for technical debt management have been introduced over the last years. SonarQube is one of the most widely applied tools to automatically measure technical debt in software systems. SonarQube has been adopted to quantify the diffuseness of technical debt in projects of the Apache Software Foundation ecosystem. Lenarduzzi et al. [1] found that the vast majority of technical debt issues in the code are code smells and that, surprisingly, developers tend to take more time to remove severe issues than the less-severe ones. While this study provides very interesting insights both for researchers and practitioners interested in technical debt management, we identified some major limitations that could have led to results that do not perfectly reflect reality. This study aims to address such limitations by presenting a differentiated replication study. Our findings have pointed out significant differences with the reference work. The results show that technical debt issues appear much more rarely than what the reference work reported. In this study, we implemented a new methodology to calculate the diffuseness of SonarQube issues at project and commit level, based on the reconstruction of the SonarQube quality profile in order to understand how the quality profile has evolved and to compare the number of active rules per category and severity level with the respective number of issues found. The results show that over 50% of rules active in the quality profile, are Code Smell rules and that over 90% of the issues belong to Code Smell category. Furthermore, analyzing the life span of the issues, we found that developers take into account the level of severity of the issues only for the Bug category, thus fixing the issues starting from the most severe, which is not the case for the other categories.
... The metaphor of Technical Debt (TD) in software was proposed by Ward Cunningham in 1992 (Cunningham, 1992) as a way to visualize and communicate the harmful consequences of quality compromises in software development, and the need for continuous refactoring. Since then, it has been a popular topic in research studies, which have mainly focused on code-related TD and different ways to calculate it (Ciolkowski et al., 2021;Tsoukalas et al., 2018). ...
... Cunningham introduced the TD metaphor to motivate refactoring as a key feature in any iterative development process (Cunningham, 1992). The steady growing body of research has focused on lowlevel TD (e.g. ...
Preprint
Full-text available
The metaphor of Technical Debt (TD) has generated a conceptual framework on factors that weaken the quality of software and accumulate a repair cost. However, user-related aspects like user experience (UX) receive little consideration among TD types, for reasons like the substantial focus on code TD, some dynamics inherent to agile processes, and an apparent lack of cumulative cost over time. This article has two main goals: first, to present evidence of the existence of UXDebt as a type of TD, with a cumulative cost for the development team as well as stakeholders; second, to propose a definition and characterization of UXDebt that may serve as a frame for further research on methods and tools for continuous management within agile processes. For the first goal, we have compiled evidence on the current state of UXDebt from three sources: a literature review, a survey among software engineering professionals in agile teams, and the analysis of UX issues in GitHub. All sources have evidenced some form of UXDebt; surveyed practitioners have recognized its poor management with a cost for the entire team that accumulates over time. Moreover, issue-tracking systems allow to visualize and measure a technical form of UXDebt. For the second goal, we have defined a conceptual model that characterizes UXDebt in terms of both technical and non-technical aspects. On the technical side, we propose the notion of UX smells which allows us to discuss concrete management activities.
... Technical Debt (TD) was first introduced by Cunningham almost three decades ago [5]. TD is described as a collection of decisions that are expedient in the short term but set up a technical context that can make future changes more costly or even prohibitive [3]. ...
... Technical Debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefits but may hurt the long-term health of a software system [3]. The term was introduced by Cunningham [5] when discussing with stakeholders the consequences of releasing poorly written code snippets to accelerate the development process. The TD metaphor is frequently used to communicate with non-technical stakeholders (e.g., corporate managers, clients, among others) about immature software artifacts and their impact. ...
... Prior research has also investigated a specific outcome from a particular subset of implementation design decisions in depth-technical debt. These occur when developers choose implementations that bias time to market over software quality [16]. Technical debt comes in several forms, such as architectural, structural, documentation, test, infrastructure, and requirements debts [4], [5]. ...
Preprint
Full-text available
Decision-making is a key software engineering skill. Developers constantly make choices throughout the software development process, from requirements to implementation. While prior work has studied developer decision-making, the choices made while choosing what solution to write in code remain understudied. In this mixed-methods study, we examine the phenomenon where developers select one specific way to implement a behavior in code, given many potential alternatives. We call these decisions implementation design decisions. Our mixed-methods study includes 46 survey responses and 14 semi-structured interviews with professional developers about their decision types, considerations, processes, and expertise for implementation design decisions. We find that implementation design decisions, rather than being a natural outcome from higher levels of design, require constant monitoring of higher level design choices, such as requirements and architecture. We also show that developers have a consistent general structure to their implementation decision-making process, but no single process is exactly the same. We discuss the implications of our findings on research, education, and practice, including insights on teaching developers how to make implementation design decisions.
... Daily changes made under pressure to software code is one of the sources of the appearance of code issues. Hence, the need for adding new features and fixing bugs in the codebase multiple times per day [1] is a recurrent problem that often leads to the appearance of technical debt [2] in its various forms (e.g. architecture or code debt [3] [4]). ...
... Definition. The term was coined by Cunningham [8] when discussing with stakeholders the consequences of releasing poorly written code snippets to accelerate the development process. TD can have a positive or negative influence on the software quality attributes (SQA), and it may occur due to many factors, such as a lack of team members' knowledge of coding without following principles, patterns, and other best practices. ...
Conference Paper
Technical Debt (TD) is a consequence of decision-making in the development process that can negatively impact Software Quality Attributes (SQA) in the long term. Technical Debt Management (TDM) is a complex task to minimize TD that relies on a decision process based on multiple and heterogeneous data that are not straightforward to synthesize. Recent studies show that Intelligent Techniques can be a promising opportunity to support TDM activities since they explore data for knowledge discovery, reasoning, learning, or supporting decision-making. Although these techniques can improve TDM activities, there is a need to identify and analyze solutions based on Intelligent Techniques to support TDM activities and their impact on SQA. For doing so, a Systematic Mapping Study was performed, covering publications between 2010 and 2020. From 2276 extracted studies, we selected 111 unique studies. We found a positive trend in applying Intelligent Techniques to support TDM activities being Machine Learning and Reasoning Under Uncertainty the most recurrent ones. Design and Code were the most frequently investigated TD types. TDM activities supported by intelligent techniques impact different characteristics of SQA, mainly Maintainability, Reliability, and Security. Although the research area is up-and-coming, it is still in its infancy, and this study provides a baseline for future research.
... Technical debt (TD) refers to delayed tasks and immature artifacts that constitute a "debt" since they may bring short-term benefits but incur extra costs of change during maintenance and evolution in the long term (Cunningham, 1992;Avgeriou et al., 2016). TD can be classified into several types from the perspective of different stages of the software development lifecycle, such as architecture TD and design TD (Tom et al., 2013;Li et al., 2015). ...
Preprint
Full-text available
Technical debt (TD) refers to delayed tasks and immature artifacts that may bring short-term benefits but incur extra costs of change during maintenance and evolution in the long term. TD has been extensively studied in the past decade, and numerous open source software (OSS) projects were used to explore specific aspects of TD and validate various approaches for TD management (TDM). However, there still lacks a comprehensive understanding on the practice of TDM in OSS development, which penetrates the OSS community's perception of the TD concept and how TD is managed in OSS development. To this end, we conducted an empirical study on the whole GitHub to explore the adoption and execution of TDM based on issues in OSS projects. We collected 35,278 issues labeled as TD (TD issues) distributed over 3,598 repositories in total from the issue tracking system of GitHub between 2009 and 2020. The findings are that: (1) the OSS community is embracing the TD concept; (2) the analysis of TD instances shows that TD may affect both internal and external quality of software systems; (3) only one TD issue was identified in 31.1% of the repositories and all TD issues were identified by only one developer in 69.0% of the repositories; (4) TDM was ignored in 27.3% of the repositories after TD issues were identified; and (5) among the repositories with TD labels, 32.9% have abandoned TDM while only 8.2% adopt TDM as a consistent practice. These findings provide valuable insights for practitioners in TDM and promising research directions for further investigation.
... The lack of adequate documentation of changes during an agile project leads to a problem called technical debt. This debt is generated by the activities of the development team members when they do not do certain project activities in due time, preventing or hindering future development [9]. The longer one waits to carry out the postponed tasks, the more costly (in terms of time) it will be for the project, and the more difficulties will carry with it. ...
Article
Full-text available
Agile software development is one of the most important development paradigms these days. However, there are still some challenges to consider to reduce problems during the documentation process. Some assistive methods have been created to support developers in their documentation activities. In this regard, Natural Language Processing (NLP) can be used to create various related tools (such as assistants) to help with the documentation process. This paper presents the current state-of-the-art NLP techniques used in the agile development documentation process. A mapping review was done to complete the objective, the search strategy is used to obtain relevant studies from ScienceDirect, IEEE Xplore, ACM Digital Library, SpringerLink, and Willey. The search results after inclusion and exclusion criteria application left 47 relevant papers identified. These papers were analyzed to obtain the most used NLP techniques and NLP toolkits. The toolkits were also classified by the kind of techniques that are available in each of them. In addition, the behavior of the research area over time was analyzed using the relevant paper found by year. We found that performance measuring methods are not standardized, and, in consequence, the works are not easily comparable. In general, the number of related works and its distribution per year shows a growing trend of the works related to this topic in recent years; this indicates that the adoption of NLP techniques to improve agile methodologies is increasing.
... The term technical debt (TD) has been originally coined by Cunningham to describe short-term decisions at the expense of long-term consequences [6]. ...
Preprint
Full-text available
Context: Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored. Objective: We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners' understanding and managing of requirements engineering debt (RED). Method: We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory. Results: We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results. Conclusions: The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.
... The term "Technical Debt" (TD) was first coined by programmer Ward Cunningham in a 1992 article stating that while an organization may be able to save money in the short term by writing imperfect code, over time, interest from TD will build up, just like with monetary debt, making the initial problem increasingly expensive to solve [13]. With his metaphor, Ward describes debt as the natural result of writing code on something that you don't have an adequate understanding of. ...
Chapter
Technical Debt describes a deficit in terms of functions, architecture, or integration, which must subsequently be filled to allow a homogeneous functioning of the product itself or its dependencies. It is predominantly caused by pursuing rapid development versus a correct development procedure. Technical Debt is therefore the result of a non-optimal software development process, which if not managed promptly can compromise the quality of the software. This study presents a technical debt trend forecasting approach based on the use of a temporal convolutional network and a broad set of product and process metrics, collected commit by commit. The model was tested on the entire evolutionary history of two open-source Java software systems available on Github: Commons-codec and Commons-net. The results are excellent and demonstrate the effectiveness of the model, which could be a pioneer in developing a TD reimbursement strategy recommendation tool that can predict when a software product might become too difficult to maintain.KeywordsTechnical debtSonarQubeSoftware quality metricsProcess metricsFeature selectionTemporal convolutional network
... The term Technical Debt (TD) was first introduced in the early 1990s by Ward Cunningham, one of the founders of Agile programming. Cunningham stating "not quite right code which we postpone making it right" [1] conceived this metaphor to assimilate the complexity of software to financial debt and the effort required to add new functionality to the interest paid on the debt. The strength of this metaphor consists in making it clear that the refactoring activities of the code are necessary to "repay" the share of the debt. ...
Article
Technical debt is considered detrimental to the long-term success of software development, but despite the numerous studies in the literature, there are still many aspects that need to be investigated for a better understanding of it. In particular, the main problems that hinder its complete understanding are the absence of a clear definition and a model for its identification, management, and forecasting. Focusing on forecasting technical debt, there is a growing notion that preventing technical debt build-up allows you to identify and address the riskiest debt items for the project before they can permanently compromise it. However, despite this high relevance, the forecast of technical debt is still little explored. To this end, this study aims to evaluate whether the quality metrics of a software system can be useful for the correct prediction of the technical debt. Therefore, the data related to the quality metrics of 8 different open-source software systems were analyzed and supplied as input to multiple machine learning algorithms to perform the prediction of the technical debt. In addition, several partitions of the initial dataset were evaluated to assess whether prediction performance could be improved by performing a data selection. The results obtained show good forecasting performance and the proposed document provides a useful approach to understanding the overall phenomenon of technical debt for practical purposes.
... Dívida Técnica (DT)é um conceito usado na metáfora criada por Ward Cunningham [Cunningham 1992] para explicar o risco de obter benefícios de curto prazo através da aquisição de dívidas técnicas, que precisarão ser resolvidas posteriormente para evitar danos ao software em desenvolvimento. Cunningham fez uma referência com a contração de uma dívida financeira, para obter uma vantagem imediata, mas que precisa ser paga posteriormente com a incidência de juros. ...
Conference Paper
Contexto: Dívida Técnica (DT) refere-se às soluções de baixa qualidade para um benefício imediato que precisam ser resolvidas posteriormente. Problema: Um projeto pode ter um volume de DTs que inviabilize a sua total quitação. É necessário priorizá-las para focar nas DTs com maior risco ao negócio. Objetivo: Contribuir com a avaliação da abordagem de priorização de DT alinhada ao negócio. Método: Estudo de caso com profissionais da indústria. Resultados: Identificamos o nível de alinhamento entre as visões técnica e de negócio, regra de priorização, e fatores que impactam a priorização das DTs. Conclusão: A validade da abordagem Tracy foi conferida em novo ambiente, bem como uma oportunidade de desdobramento da pesquisa foi observado.
... Technical Debt (Technical gap) is a metaphor introduced by Cunningham [4] to represent sub-optimal design or implementation solutions that yield a benefit in the short term but make changes more costly or even impossible in the medium to long term [2]. It describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. ...
Research
Full-text available
The objective of this study is to build a model that will evaluate policies, processes or activities that have been foregone or missing in the project by the novice, junior or student developers in university projects. The study will enable mitigating the occurrence of the technical debt as early as possible in project prototypes. This study seeks to answer the following research questions(RQ) as a way of understanding the existence and evaluation of technical debt in processes of software development by young teams. RQ1: To what extent is technical debt present in software development processes by amateur or young teams? RQ2: Is there a relationship between the techniques young teams use on software projects and occurrence of technical debt? RQ3: Does awareness about technical debt by young teams minimise project failure?
... The term technical debt (TD) has been originally coined by Cunningham to describe short-term decisions at the expense of long-term consequences [6]. ...
Article
Full-text available
Context: Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored. Objective: We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED). Method: We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory. Results: We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results. Conclusions: The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.
... In 1992, Cunningham introduced technical debt (TD) to the software community as "the debt incurred through the speeding up of software project development which results in a number of deficiencies ending up in high maintenance overheads." [3] Avgeriou et al [4] further elaborated on this definition: "In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability." ...
Article
In software engineering, technical debt (TD) has been widely investigated, but debt regarding social issues, people, and processes has not been explored as much. It should be noted here that we use nontechnical debt (NTD) as an umbrella term to cover social, process, and people debts. Although the number of studies on NTD in software is increasing, the majority of them are descriptive rather than rigorous, and there is no systematic development of cumulative knowledge. As a result, identifying the fundamental causes of NTD and the associated mitigation techniques in software engineering is challenging. Therefore, this study investigates the scientific evidence regarding NTD till date by conducting a systematic mapping review of software engineering research between January 2000 and October 2021. The search strategy resulted in 175 studies, 17 of which were identified as unique and relevant primary papers. The primary studies show that NTD and TD are inextricably linked. In addition, this study also captured a plethora of causes and mitigation strategies for managing NTD and thus makes four important contributions: (i) highlighting state‐of‐the‐art NTD research; (ii) identification of the reported causes and mitigation strategies in the primary papers; and (iii) determination of opportunities for future NTD research. Both technical and nontechnical debt (NTD) have a symbiotic relationship and affect software and systems. According to the literature, NTD can lead to technical debt and vice versa. In recent years, there has been an increase in studies in the NTD research realm. However, NTD research area is still in its infancy, and most of evidence is anecdotal. NTD in software engineering lack the cumulative building of knowledge or that there will be “fragmented adhocracy.”
... The software industry recurrently has to choose short-term delivery over long-term responses. This phenomenon -referred to as technical debt (TD) -is illustrated by the financial metaphor in which suboptimal decisions are made in short term to meet delivery targets, assuming the financial debt to be repaid in the long term [Cunningham 1993]. TD occurs along with all software life cycle, including the architectural design [Kruchten et al. 2006]. ...
... Technical Debt (TD) is a term introduced by Ward Cunningham (Cunningham 1993) to describe the situation where accomplishing short-term goals is chosen over long-term code quality. Just like financial debt, TD can accumulate interest if it is not dealt with quickly. ...
Article
Full-text available
Technical Debt occurs when development teams favour short-term operability over long-term stability. Since this places software maintainability at risk, technical debt requires early attention to avoid paying for accumulated interest. Most of the existing work focuses on detecting technical debt using code comments, known as Self-Admitted Technical Debt (SATD). However, there are many cases where technical debt instances are not explicitly acknowledged but deeply hidden in the code. In this paper, we propose a framework that caters for the absence of SATD comments in code. Our Self-Admitted Technical Debt Identification and Description (SATDID) framework determines if technical debt should be self-admitted for an input code fragment. If that is the case, SATDID will automatically generate the appropriate descriptive SATD comment that can be attached with the code. While our approach is applicable in principle to any type of code fragments, we focus in this study on technical debt hidden in conditional statements, one of the most TD-carrying parts of code. We explore and evaluate different implementations of SATDID. The evaluation results demonstrate the applicability and effectiveness of our framework over multiple benchmarks. Comparing with the results from the benchmarks, our approach provides at least 21.35, 59.36, 31.78, and 583.33% improvements in terms of Precision, Recall, F-1, and Bleu-4 scores, respectively. In addition, we conduct a human evaluation to the SATD comments generated by SATDID. In 1-5 and 0–5 scales for Acceptability and Understandability, the total means achieved by our approach are 3.128 and 3.172, respectively.
Article
Due to the exploratory nature of computational notebook development, a notebook can be extensively evolved even though it is small, potentially incurring substantial technical debt. Indeed, in interview studies notebook authors have attested to performing on-going tidying and big cleanups. However, many notebook authors are not trained as software developers, and environments like JupyterLab possess few features to aid notebook maintenance. As software refactoring is traditionally a critical tool for reducing technical debt, we sought to better understand the unique and growing ecology of computational notebooks by investigating the refactoring of public Jupyter notebooks. We randomly selected 15,000 Jupyter notebooks hosted on GitHub and studied 200 with meaningful commit histories. We found that notebook authors do refactor, favoring a few basic classic refactorings as well as those involving the notebook cell construct. Those with a computing background refactored differently than others, but not more so. Exploration-focused notebooks had a unique refactoring profile compared to more exposition-focused notebooks. Authors more often refactored their code as they went along, rather than deferring maintenance to big cleanups. These findings point to refactoring being intrinsic to notebook development.
Preprint
Full-text available
Adaptive and flexible production systems require modular and reusable software especially considering their long term life cycle of up to 50 years. SWMAT4aPS, an approach to measure Software Maturity for automated Production Systems is introduced. The approach identifies weaknesses and strengths of various companie's solutions for modularity of software in the design of automated Production Systems (aPS). At first, a self assessed questionnaire is used to evaluate a large number of companies concerning their software maturity. Secondly, we analyze PLC code, architectural levels, workflows and abilities to configure code automatically out of engineering information in four selected companies. In this paper, the questionnaire results from 16 German world leading companies in machine and plant manufacturing and four case studies validating the results from the detailed analyses are introduced to prove the applicability of the approach and give a survey of the state of the art in industry.
Chapter
Technical debt solely focuses on the technical aspect and fails to provide a holistic view to address the misalignment between business and IT aspects of enterprise architecture (EA). To provide a more holistic view and to include the business aspect in the context of debt, researchers have proposed the concept of EA debt. It refers to the gap between the present state and the hypothetically ideal state of EA. EA debt, if accumulated, has negative impacts on the enterprise and can result in a decrease in the value, maintainability, agility, and efficiency of EA. Therefore, it is very crucial to manage EA debt. Furthermore, each stakeholder in the enterprise has an interest in certain aspects and areas of EA. By applying viewpoints, stakeholders can analyze EA debt by focusing on aspects and areas of their interest. By analyzing EA debt, stakeholders can make informed decisions during EA debt management (EADM). This paper presents a systematic mapping study carried out to collect predefined viewpoints from areas of enterprise architecture, software architecture, and technical debt. The collected viewpoints are then assessed to determine if they can be used for the analysis of EA debt. Further, six categories are defined to categorize EA debt viewpoints based on their purpose and content.
Chapter
Enterprise Architecture (EA) is the discipline that aims to provide a holistic view of the enterprise by explicating business and IT alignment from the perspectives of high-level corporate strategy down to daily operations and network infrastructures. EAs are consequently complex as they compose and integrate many aspects on different architecture layers. A recent proposal to cope with this complexity and to make EAs amenable to automated and intuitive visual analysis is the transformation of EA models into EA Knowledge Graphs. A remaining limitation of these approaches is that they perceive the EA to be static, i.e., they represent and analyze EAs at a single point in time. In the paper at hand, we introduce a historization concept, a prototypical implementation, and a performance analysis for how EAs can be represented and processed to enable the analysis of their evolution.KeywordsEnterprise architectureHistorical analysisKnowledge graph
Chapter
Service-Oriented Architectures (SOA) have become a standard for developing software applications, including but not limited to cloud-based ones and enterprise systems. When using SOA, the software engineers organize the desired functionality into self-contained and independent services, that are invoked through end-points (API calls). At the maintenance phase, the tickets (bugs, functional updates, new features, etc.) usually correspond to specific services. Therefore, for maintenance-related estimates it makes sense to use as unit of analysis the service-per se, rather than the complete project (too coarse-grained analysis) or a specific class (too fine-grained analysis). Currently, some of the most emergent maintenance estimates are related to Technical Debt (TD), i.e., the additional maintenance cost incurred due to code or design inefficiencies. In the literature, there is no established way on how to quantify TD at the service level. To this end, in this paper, we present a novel methodology to measure the TD of each service considering the underlying code that sup-ports the corresponding endpoint. The proposed methodology relies on the method call graph, initiated by the service end-point, and traverses all methods that provide the service functionality. To evaluate the usefulness of this approach, we have conducted an industrial study, validating the methodology (and the accompanying tool) with respect to usefulness, obtained benefits, and usability.KeywordsTechnical debtService analysisEndpoint analysisQuality
Chapter
Context: Exploratory testing plays an important role in the continuous integration and delivery pipelines of large-scale software systems, but a holistic and structured approach is needed to realize efficient and effective exploratory testing. Objective: This paper seeks to address the need for a structured and reliable approach by providing a tangible model, supporting practitioners in the industry to optimize exploratory testing in each individual case. Method: The reported study includes interviews, group interviews and workshops with representatives from six companies, all multi-national organizations with more than 2,000 employees. Results: The ExET model (Excellence in Exploratory Testing) is presented. It is shown that the ExET model allows companies to identify and visualize strengths and improvement areas. The model is based on a set of key factors that have been shown to enable efficient and effective exploratory testing of large-scale software systems, grouped into four themes: “The testers’ knowledge, experience and personality”, “Purpose and scope”, “Ways of working” and “Recording and reporting”. Conclusions: The validation of the ExET model showed that the model is novel, actionable and useful in practice, showing companies what they should prioritize in order to enable efficient and effective exploratory testing in their organization.
Chapter
Continuous experimentation (CE) refers to a group of practices used by software companies to rapidly assess the usage, value and performance of deployed software using data collected from customers and the deployed system. Despite its increasing popularity in the development of web-facing applications, CE has not been discussed in the development process of business-to-business (B2B) mission-critical systems. We investigated in a case study the use of CE practices within several products, teams and areas inside Ericsson. By observing the CE practices of different teams, we were able to identify the key activities in four main areas and inductively derive an experimentation process, the HURRIER process, that addresses the deployment of experiments with customers in the B2B and with mission-critical systems. We illustrate this process with a case study in the development of a large mission-critical functionality in the Long Term Evolution (4G) product. In this case study, the HURRIER process is not only used to validate the value delivered by the solution but to increase the quality and the confidence from both the customers and the R&D organization in the deployed solution. Additionally, we discuss the challenges, opportunities and lessons learned from applying CE and the HURRIER process in B2B mission-critical systems.
Chapter
Measuring properties of software systems, organizations, and processes has much more to it than meets the eye. Numbers and quantities are at the center of it, but that is far from everything. Software measures (or metrics, as some call them) exist in a context of a measurement program, which involves the technology used to measure, store, process, and visualize data, as well as people who make decisions based on the data and software engineers who ensure that the data can be trusted. z
Chapter
Software developers in big and medium-size companies are working with millions of lines of code in their codebases. Assuring the quality of this code has shifted from simple defect management to proactive assurance of internal code quality. Although static code analysis and code reviews have been at the forefront of research and practice in this area, code reviews are still an effort-intensive and interpretation-prone activity. The aim of this research is to support code reviews by automatically recognizing company-specific code guidelines violations in large-scale, industrial source code. In our action research project, we constructed a machine-learning-based tool for code analysis where software developers and architects in big and medium-sized companies can use a few examples of source code lines violating code/design guidelines (up to 700 lines of code) to train decision-tree classifiers to find similar violations in their codebases (up to 3 million lines of code). Our action research project consisted of (i) understanding the challenges of two large software development companies, (ii) applying the machine-learning-based tool to detect violations of Sun’s and Google’s coding conventions in the code of three large open source projects implemented in Java, (iii) evaluating the tool on evolving industrial codebase, and (iv) finding the best learning strategies to reduce the cost of training the classifiers. We were able to achieve the average accuracy of over 99% and the average F-score of 0.80 for open source projects when using ca. 40K lines for training the tool. We obtained a similar average F-score of 0.78 for the industrial code but this time using only up to 700 lines of code as a training dataset. Finally, we observed the tool performed visibly better for the rules requiring to understand a single line of code or the context of a few lines (often allowing to reach the F-score of 0.90 or higher). Based on these results, we could observe that this approach can provide modern software development companies with the ability to use examples to teach an algorithm to recognize violations of code/design guidelines and thus increase the number of reviews conducted before the product release. This, in turn, leads to the increased quality of the final software.
Chapter
Continuous Integration is a software practice where developers integrate frequently, at least daily. While this is an ostensibly simple concept, it does leave ample room for interpretation: what is it the developers integrate with, what happens when they do, and what happens before they do? These are all open questions with regards to the details of how one implements the practice of continuous integration, and it is conceivable that not all such implementations in the industry are alike. In this paper we show through a literature review that there are differences in how the practice of continuous integration is interpreted and implemented from case to case. Based on these findings we propose a descriptive model for documenting and thereby better understanding implementations of the continuous integration practice and their differences. The application of the model to an industry software development project is then described in an illustrative case study.
Chapter
Measurement programs in large software development organizations contain a large number of indicators, base and derived measures to monitor products, processes and projects. The diversity and the number of these measures causes the measurement programs to become large, combining multiple needs, measurement tools and organizational goals. For the measurement program to effectively support organization’s goals, it should be scalable, automated, standardized and flexible – i.e. robust. In this paper we present a method for assessing the robustness of measurement programs. The method is based on the robustness model which has been developed in collaboration between seven companies and a university. The purpose of the method is to support the companies to optimize the value obtained from the measurement programs and their cost. We evaluated the method at the seven companies and the results from applying the method to each company quantified the robustness of their programs, reflecting the real-world status of the programs and pinpointed strengths and improvements of the programs.
Chapter
In many ways, digitalization has confirmed that the success of new technologies and innovations is fully realized only when these are effectively adopted and integrated into the daily practices of a company. During the last decade, we have seen how the speed of technology developments only accelerates, and there are numerous examples of innovations that have fundamentally changed businesses as well as everyday life for the customers they serve. In the manufacturing industry, automation is key for improving efficiency as well as for increasing safety. In the automotive domain, electrification of cars and autonomous drive technologies are replacing mechanical power and human intervention. In the telecom domain, seamless connectivity and digital infrastructures allow systems to adapt and respond within the blink of an eye. In the security and surveillance domain, intelligent technologies provide organizations with the ability to detect, respond, and mitigate potential risks and threats with an accuracy and preciseness we could only dream about a few decades ago. While these are only a few examples, they reflect how digital technologies, and the ever-increasing access to data, are transforming businesses to an extent that we have only seen the beginnings of.
Chapter
Context: Agile methods have become mainstream even in large-scale systems engineering companies that need to accommodate different development cycles of hardware and software. For such companies, requirements engineering is an essential activity that involves upfront and detailed analysis which can be at odds with agile development methods. Objective: This paper presents a multiple case study with seven large-scale systems companies, reporting their challenges, together with best practices from industry. We also analyse literature about two popular large-scale agile frameworks, SAFe® and LeSS, to derive potential solutions for the challenges. Method: Our results are based on 20 qualitative interviews, five focus groups, and eight cross-company workshops which we used to both collect and validate our results. Results: We found 24 challenges which we grouped in six themes, then mapped to solutions from SAFe®, LeSS, and our companies, when available. Conclusion: In this way, we contribute a comprehensive overview of RE challenges in relation to large-scale agile system development, evaluate the degree to which they have been addressed, and outline research gaps. We expect these results to be useful for practitioners who are responsible for designing processes, methods, or tools for large scale agile development as well as guidance for researchers.
Chapter
Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both the evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been produced recently, its practical management lacks empirical studies. In this paper, we investigate the state of practice in several companies to understand what the cost of managing TD is, what tools are used to track TD, and how a tracking process is introduced in practice. We combined two phases: a survey involving 226 respondents from 15 organizations and an in-depth multiple case study in three organizations including 13 interviews and 79 Technical Debt issues. We selected the organizations where Technical Debt was better tracked in order to distill best practices. We found that the development time dedicated to managing Technical Debt is substantial (an average of 25% of the overall development), but mostly not systematic: only a few participants (26%) use a tool, and only 7.2% methodically track Technical Debt. We found that the most used and effective tools are currently backlogs and static analyzers. By studying the approaches in the companies participating in the case study, we report how companies start tracking Technical Debt and what the initial benefits and challenges are. Finally, we propose a Strategic Adoption Model for the introduction of tracking Technical Debt in software organizations.
Chapter
Even though there were many forerunners, the most widespread reference to Continuous Integration as a method was put forward by Grady Booch in 1990 [44] (page 209). In the 1995 book Microsoft Secrets, Cusumano and Selby interviewed 38 Microsoft employees to document how the world’s leading software provider was managing its own software development [80]. One of the key practices found was the Daily Build concept. In the popular literature, this was described as everyone needed to check in their code and build the product at the end of the workday. In tight connection to the build, some smoke tests were run to ensure that the individual contributions could be integrated. If the build was broken, the person who broke it had to fix his/her code before going home. There was also modern folklore mentioning that the breaker of the build had to wear a funny hat for the remainder of the day.
Chapter
The term artificial intelligence (AI) triggers many things in terms of its inherent meaning and potential. The notion of a machine with the same level of intellect as a human or even far exceeding it is enthralling and scary at the same time. Several science fiction movies build on the HAL 9000 or Terminator theme of artificial intelligence bent on controlling or even exterminating humankind.
Chapter
Development of high-quality complex software, in particular in modern embedded and cyber-physical systems, requires careful attention to the software architecture and design in order to achieve the desired quality attributes. Generally speaking, the evolution in software development methods during the last decade, towards more agile practices with short iterations and early feedback, has focused more on implementation and validation activities than architectural design. It is sometimes argued, even, that the concept of architecture is obsolete in modern software development. However, architectural decisions still have a significant impact on software quality, including crucial aspects like performance, safety, and security. Moreover, although architecture can, and should, evolve over time, it does so at a slow pace compared to implementation changes, meaning that the architecture impacts how quickly new functionality can be implemented in response to changed market needs. Thus, for any long-lived systems, but in particular for systems where for example safety assurance is critical, there is definitely a need to document and reason about architecture. Architectural documentation no longer plays the role of a static, a priori, specification for developers to follow but should rather be viewed as an artifact that continuously evolves together with the implementation.
Chapter
Agile software development is increasingly adopted by companies evolving and maintaining software products to support better planning and tracking the realization of user stories and features. While convincing success stories help to further spread the adoption of Agile, mechatronics-driven companies need guidance to implement Agile for non-software teams. In this comparative case study of three companies from the Nordic region, we systematically investigate expectations and challenges from scaling Agile in organizations dealing with mechatronics development by conducting on-site workshops and surveys. Our findings show that all companies have already successfully implemented Agile in their software teams. The expected main benefit of successfully scaling agile development is a faster time-to-market product development; however, the two main challenges are: (a) An inflexible test environment that inhibits fast feedback to changed or added features, and (b) the existing organizational structure including the company’s mind-set that needs to be opened-up for agile principles.
Chapter
Full-text available
Artificial intelligence (AI) and machine learning (ML) are increasingly broadly adopted in industry, However, based on well over a dozen case studies, we have learned that deploying industry-strength, production quality ML models in systems proves to be challenging. Companies experience challenges related to data quality, design methods and processes, performance of models as well as deployment and compliance. We learned that a new, structured engineering approach is required to construct and evolve systems that contain ML/DL components. In this chapter, we provide a conceptualization of the typical evolution patterns that companies experience when employing ML as well as an overview of the key problems experienced by the companies that we have studied. The main contribution of the chapter is a research agenda for AI engineering that provides an overview of the key engineering challenges surrounding ML solutions and an overview of open items that need to be addressed by the research community at large.
Chapter
Background: Profiling software development projects, in order to compare them, find similar sub-projects or sets of activities, helps to monitor changes in software processes. Since we lack objective measures for profiling or hashing, researchers often fall back on manual assessments. Objective: The goal of our study is to define an objective and intuitive measure of similarity between software development projects based on software defect-inflow profiles. Method: We defined a measure of project similarity called SimSAX which is based on segmentation of defect-inflow profiles, coding them into strings (sequences of symbols) and comparing these strings to find so-called motifs. We use simulations to find and calibrate the parameters of the measure. The objects in the simulations are two different large industry projects for which we know the similarity a priori, based on the input from industry experts. Finally, we apply the measure to find similarities between five industrial and six open source projects. Results: Our results show that the measure provides the most accurate simulated results when the compared motifs are long (32 or more weeks) and we use an alphabet of 5 or more symbols. The measure provides the possibility to calibrate for each industrial case, thus allowing to optimize the method for finding specific patterns in project similarity. Conclusions: We conclude that our proposed measure provides a good approximation for project similarity. The industrial evaluation showed that it can provide a good starting point for finding similar periods in software development projects.
Chapter
In model-based development projects, models at different abstraction levels capture different aspects of a software system, e.g., specification or design. Inconsistencies between these models can cause inefficient and incorrect development. A tool-based framework to assist developers creating and maintaining models conforming to different languages (i.e. heterogeneous models) and consistency between them is not only important but also much needed in practice. In this work, we focus on assisting developers bringing about multi-view consistency in the context of agile model-based development, through frequent, lightweight consistency checks across views and between heterogeneous models. The checks are lightweight in the sense that they are easy to create, edit, use and maintain, and since they find inconsistencies but do not attempt to automatically resolve them. With respect to ease of use, we explicitly separate the two main concerns in defining consistency checks, being (i) which modelling elements across heterogeneous models should be consistent with each other and (ii) what constitutes consistency between them. We assess the feasibility and illustrate the potential usefulness of our consistency checking approach, from an industrial agile model-based development point-of-view, through a proof-of-concept implementation on a sample project leveraging models expressed in SysML and Simulink. A continuous integration pipeline hosts the initial definition and subsequent execution of consistency checks, it is also the place where the user can view results of consistency checks and reconfigure them.
Chapter
Agile software development is well-known for its focus on close customer collaboration and customer feedback. In emphasizing flexibility, efficiency and speed, agile practices have led to a paradigm shift in how software is developed. However, while agile practices have succeeded in involving the customer in the development cycle, there is an urgent need to learn from customer usage of software also after delivering and deployment of the software product. The concept of continuous deployment, i.e. the ability to deliver software functionality frequently to customers and subsequently, the ability to continuously learn from real-time customer usage of software, has become attractive to companies realizing the potential in having even shorter feedback loops. However, the transition towards continuous deployment involves a number of barriers. This paper presents a multiple-case study in which we explore barriers associated with the transition towards continuous deployment. Based on interviews at four different software development companies we present key barriers in this transition as well as actions that need to be taken to address these.
Chapter
Software development companies are increasingly aiming to become data-driven by trying to continuously experiment with the products used by their customers. Although familiar with the competitive edge that the A/B testing technology delivers, they seldom succeed in evolving and adopting the methodology. In this paper, and based on an exhaustive and collaborative case study research in a large software-intense company with highly developed experimentation culture, we present the evolution process of moving from ad-hoc customer data analysis towards continuous controlled experimentation at scale. Our main contribution is the “Experimentation Evolution Model” in which we detail three phases of evolution: technical, organizational and business evolution. With our contribution, we aim to provide guidance to practitioners on how to develop and scale continuous experimentation in software organizations with the purpose of becoming data-driven at scale.
Presentation
Full-text available
Software companies especially startups aim to achieve quick delivery of software products to constantly provide value to their customers. The best framework in terms of architecture is to use microservices to achieve this target. Consequently, this microservice architecture is not inevitable to effects of technical debt due to hasty decisions taken thus limiting the desired continuous delivery of software products to the customers. Objectives: The aim of this paper is to identify the developer practices (bad smells), causes, solutions as related to causing architectural technical debt in microservices. Method: We base our analysis of bad practices on an empirical study that was made to determine practitioners' handling of bad smells in software development. The practitioners reported a total of 265 different bad practices together with the solutions they had applied to overcome them. Conclusion: We found issues, solutions and possible causes of microser-vices architectures not yet encountered in the current literature. The results of this study might be useful for the practitioners who want to minimize the occurrence of Architectural Technical debt in their startups.
ResearchGate has not been able to resolve any references for this publication.