No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Technical Debt in Service-Oriented Software Systems
Abstract
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
ResearchGate has not been able to resolve any citations for this publication.
There are numerous commercial tools and research prototypes that offer support for measuring technical debt. However, different tools adopt different terms, metrics, and ways to identify and measure technical debt. These tools offer diverse features, and their popularity / community support varies significantly. Therefore, (a) practitioners face difficulties when trying to select a tool matching their needs; and (b) the concept of technical debt and its role in software development is blurred. We attempt to clarify the situation by comparing the features and popularity of technical debt measurement tools, and analyzing the existing empirical evidence on their validity. Our findings can help practitioners to find the most suitable tool for their purposes, and researchers by highlighting the current tool shortcomings
Software teams are often asked to deliver new features within strict deadlines leading developers to deliberately or inadvertently serve “not quite right code” compromising software quality and maintainability. This non-ideal state of software is efficiently captured by the Technical Debt (TD) metaphor, which reflects the additional effort that has to be spent to maintain software. Although several tools are available for assessing TD, each tool essentially checks software against a particular ruleset. The use of different rulesets can often be beneficial as it leads to the identification of a wider set of problems; however, for the common usage scenario where developers or researchers rely on a single tool, diverse estimates of TD and the identification of different mitigation actions limits the credibility and applicability of the findings. The objective of this study is two-fold: First, we evaluate the degree of agreement among leading TD assessment tools. Second, we propose a framework to capture the diversity of the examined tools with the aim of identifying few “reference assessments” (or class/file profiles) representing characteristic cases of classes/files with respect to their level of TD. By extracting sets of classes/files exhibiting similarity to a selected profile (e.g., that of high TD levels in all employed tools) we establish a basis that can be used either for prioritization of maintenance activities or for training more sophisticated TD identification techniques. The proposed framework is illustrated through a case study on fifty (50) open source projects and two programming languages (Java and JavaScript) employing three leading TD tools.
Several companies are re-architecting their monolithic information sys- tems with microservices. However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners’ blogs. Because of the novelty of the topic, practitioners and consultancy are learning by doing how to migrate, thus facing several issues but also several benefits. In this chapter, we introduce a catalog and a taxonomy of the most common microservices anti-patterns in order to identify common problems. Our anti-pattern catalogue is based on the experience summarized by different practitioners we interviewed in the last three years. We identified a taxonomy of 20 anti-patterns, including orga- nizational (team oriented and technology/tool oriented) anti-patterns and technical (internal and communication) anti-patterns. The results can be useful to practitioners to avoid experiencing the same difficult situations in the systems they develop. More- over, researchers can benefit of this catalog and further validate the harmfulness of the anti-patterns identified.
Introduction: Software companies aim to achieve continuous delivery to constantly provide value to their customers. A popular strategy is to use microservices architecture. However, such an architecture is also subject to debt, which hinders the continuous delivery process and thus negatively affects the software released to the customers.
Objectives: The aim of this study is to identify issues, solutions and risks related to Architecture Technical Debt in microservices.
Method: We conducted an exploratory case study of a real life project with about 1000 services in a large, international company. Through qualitative analysis of documents and interviews, we investigated Architecture Technical Debt in the communication layer of a system with microservices architecture.
Results: Our main contributions are a list of Architecture Technical Debt issues specific for the communication layer in a system with microservices architecture, as well as their associated negative impact (interest), a solution to repay the debt and the its cost (principal). Among the found Architecture Technical Debt issues were the existence of business logic in the communication layer and a high amount of point-to-point connections between services. The studied solution consists of the implementation of different canonical models specific to different domains, the removal of business logic from the communication layer, and migration from services to use the communication layer correctly. We also contributed with a list of possible risks that can affect the payment of the debt, as lack of funding and inadequate prioritization.
Conclusion: We found issues, solutions and possible risks that are specific for microservices architectures not yet encountered in the current literature. Our results may be useful for practitioners that want to avoid or repay Technical Debt in their microservices architecture.
Maintainability assurance techniques are used to control this quality attribute and limit the accumulation of potentially unknown technical debt. Since the industry state of practice and especially the handling of Service- and Microservice-Based Systems in this regard are not well covered in scientific literature, we created a survey to gather evidence for a) used processes, tools, and metrics in the industry, b) maintainability-related treatment of systems based on service-orientation, and c) influences on developer satisfaction w.r.t. maintainability. 60 software professionals responded to our online questionnaire. The results indicate that using explicit and systematic techniques has benefits for maintainability. The more sophisticated the applied methods the more satisfied participants were with the maintainability of their software while no link to a hindrance in productivity could be established. Other important findings were the absence of architecture-level evolvability control mechanisms as well as a significant neglect of service-oriented particularities for quality assurance. The results suggest that industry has to improve its quality control in these regards to avoid problems with long-living service-based software systems.
Some microservices proponents claim that microservices form a new architectural style; in contrast, advocates of service-oriented architecture (SOA) argue that microservices merely are an implementation approach to SOA. This overview and vision paper first reviews popular introductions to microservices to identify microservices tenets. It then compares two microservices definitions and contrasts them with SOA principles and patterns. This analysis confirms that microservices indeed can be seen as a development- and deployment-level variant of SOA; such microservices implementations have the potential to overcome the deficiencies of earlier approaches to SOA realizations by employing modern software engineering paradigms and Web technologies such as domain-driven design, RESTful HTTP, IDEAL cloud application architectures, polyglot persistence, lightweight containers, a continuous DevOps approach to service delivery, and comprehensive but lean fault management. However, these paradigms and technologies also cause a number of additional design choices to be made and create new options for many “distribution classics” type of architectural decisions. As a result, the cognitive load for (micro-)services architects increases, as well as the design, testing and maintenance efforts that are required to benefit from an adoption of microservices. To initiate and frame the buildup of architectural knowledge supporting microservices projects, this paper compiles related practitioner questions; it also derives research topics from these questions. The paper concludes with a summarizing position statement: microservices constitute one particular implementation approach to SOA (service development and deployment).
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
A Cloud-based Service-Oriented Architecture (CBSOA) is typically composed of web services, which are offered off the cloud marketplace. CB-SOA can improve its utility and add value to its composition by switching among its constituent services. We look at the option to defer the decision of substitution under uncertainty. We exploit Binomial Options to the formulation. We quantify the time-value of the architecture decisions of switching web services and technical debt they can imply on the structure. As CB-SOA are market-sensitive, dynamic and "volatile", the decision of deferral tends to be sensitive to these dynamics. Henceforth, the structural complexity of a CB-SOAcan change over time and so the technical debt as its constituent web services are modified, replaced, upgraded, etc. The method builds on Design Structure Matrix (DSM) and introduces time and complexity aware propagation cost metrics to assess the value of deferral decisions relative to changes in the structure. Architects of CB-SOA can use our method to assess the time value of deferring the decisions to switch web services relative to complexity, technical debt and value creation. We demonstrate the applicability of the method using an illustrative example.
Context: The technical debt (TD) concept describes a tradeoff between short-term and long-term goals in software development. While it is highly useful as a metaphor, it has utility beyond the facilitation of discussion, to inspire a useful set of methods and tools that support the identification, measurement, monitoring, management, and payment of TD. Objective: This study focuses on the identification of TD. We evaluate human elicitation of TD and compare it to automated identification. Method: We asked a development team to identify TD items in artifacts from a software project on which they were working. We provided the participants with a TD template and a short questionnaire. In addition, we also collected the output of three tools to automatically identify TD and compared it to the results of human elicitation. Results: There is little overlap between the TD reported by different developers, so aggregation, rather than consensus, is an appropriate way to combine TD reported by multiple developers. The tools used are especially useful for identifying defect debt but cannot help in identifying many other types of debt, so involving humans in the identification process is necessary. Conclusion: We have conducted a case study that focuses on the practical identification of TD, one area that could be facilitated by tools and techniques. It contributes to the TD landscape, which depicts an understanding of relationships between different types of debt and how they are best discovered
“Social debt” in software engineering informally refers to unforeseen project cost connected to a “suboptimal” development community. The causes of suboptimal development communities can be many, ranging from global distance to organisational barriers to wrong or uninformed socio-technical decisions (i.e., decisions that influence both social and technical aspects of software development). Much like technical debt, social debt impacts heavily on software development success. We argue that, to ensure quality software engineering, practitioners should be provided with mechanisms to detect and manage the social debt connected to their development communities. This paper defines and elaborates on social debt, pointing out relevant research paths. We illustrate social debt by comparison with technical debt and discuss common real-life scenarios that exhibit “sub-optimal” development communities.
Technical Debt (TD) is a successful metaphor in conveying the consequences of software inefficiencies and their elimination to both technical and non-technical stakeholders, primarily due to its monetary nature. The identification and quantification of TD rely heavily on the use of a small handful of sophisticated tools that check for violations of certain predefined rules, usually through static analysis. Different tools result in divergent TD estimates calling into question the reliability of findings derived by a single tool. To alleviate this issue we use 18 metrics pertaining to source code, repository activity, issue tracking, refactorings, duplication and commenting rates of each class as features for statistical and Machine Learning models, so as to classify them as High-TD or not. As a benchmark we exploit 18,857 classes obtained from 25 Java projects, whose high levels of TD has been confirmed by three leading tools. The findings indicate that it is feasible to identify TD issues with sufficient accuracy and reasonable effort: a subset of superior classifiers achieved an F 2-measure score of approximately 0.79 with an associated Module Inspection ratio of approximately 0.10. Based on the results a tool prototype for automatically assessing the TD of Java projects has been implemented.
Design defects are symptoms of poor design and implementation solutions adopted by developers during the development of their software systems. While the research community devoted a lot of effort to studying and devising approaches for detecting the traditional design defects in object-oriented (OO) applications, little knowledge and support is available for an emerging category of Web service interface design defects. Indeed, it has been shown that service designers and developers tend to pay little attention to their service interfaces design. Such design defects can be subjectively interpreted and hence detected in different ways.
In this paper, we propose a novel approach, named WS3D, using machine learning techniques that combines Support Vector Machine (SVM) and Simulated Annealing (SA) to learn from real world examples of service design defects. WS3D has been empirically evaluated on a benchmark of Web services from 10 different application domains. We compared WS3D with the state-of-the-art approaches which rely on traditional declarative techniques to detect service design defects by combining metrics and threshold values. Results show that WS3D outperforms the the compared approaches in terms of accuracy with a precision and recall scores of 91% and 94%, respectively.
Context
The technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice.
Objective
This paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities.
Method
A systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated.
Results
We proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested.
Conclusion
The results of this mapping study can help to identify points that still require further investigation in technical debt research.
Introduction Design of the Case Study Data Collection Data Analysis Reporting and Dissemination Lessons Learned
Growing number of reports on the problems with SOA projects indicates that SOA faces substantial problems. It can be a consequence of the fact that SOA passes the disgustion phase of the hypo curve. It, however, must have some concrete reasons. We analyze frequently used and often even recommended SOA development practices and processes and we show that the processes implicitly apply few known and usually most important SOA antipatterns. The cure is not easy. We show using causal diagrams to analyze dependencies that the practices involve developing (unstable) causal cycles. It requires strong managerial countermeasures a a careful analysis. We show that the most important is to avoid fine-grained services and interfaces.
Software teams, as they communicate throughout the life-cycle of their projects, generate a substantial stream of textual data. Through emails and chats, developers discuss the requirements of their software system, they negotiate the distribution of tasks among them, and they make decisions about the system design, and the internal structure and functionalities of its code modules. The software research community has long recognized the importance and potential usefulness of such textual information. In this paper, we discuss our recent work on systematically analyzing several textual streams collected through our WikiDev2.0 tool. We use two different text-analysis methods to examine five different sources of textual data. We report on our experience using our method on analyzing the communications of a nine-member team over four months.
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 ...
This paper is a description of inductive and deductive content analysis.
Content analysis is a method that may be used with either qualitative or quantitative data and in an inductive or deductive way. Qualitative content analysis is commonly used in nursing studies but little has been published on the analysis process and many research books generally only provide a short description of this method.
When using content analysis, the aim was to build a model to describe the phenomenon in a conceptual form. Both inductive and deductive analysis processes are represented as three main phases: preparation, organizing and reporting. The preparation phase is similar in both approaches. The concepts are derived from the data in inductive content analysis. Deductive content analysis is used when the structure of analysis is operationalized on the basis of previous knowledge.
Inductive content analysis is used in cases where there are no previous studies dealing with the phenomenon or when it is fragmented. A deductive approach is useful if the general aim was to test a previous theory in a different situation or to compare categories at different time periods.
While empirical studies in software engineering are beginning to
gain recognition in the research community, this subarea is also
entering a new level of maturity by beginning to address the human
aspects of software development. This added focus has added a new layer
of complexity to an already challenging area of research. Along with new
research questions, new research methods are needed to study
nontechnical aspects of software engineering. In many other disciplines,
qualitative research methods have been developed and are commonly used
to handle the complexity of issues involving human behaviour. The paper
presents several qualitative methods for data collection and analysis
and describes them in terms of how they might be incorporated into
empirical studies of software engineering, in particular how they might
be combined with quantitative methods. To illustrate this use of
qualitative methods, examples from real software engineering studies are
used throughout
System Usability Scale (SUS): A quick-and-dirty method of system evaluation user information
- J Brooke
Javaparser: visited. Leanpub
- N Smith
- D Van Bruggen
- F Tomassetti