A CONSOLIDATED UNDERSTANDING OF TECHNICAL DEBT

Technical debt utilises financial debt as a metaphor to describe the phenomenon of increasing software development costs over time. Whilst this phenomenon is evidently detrimental to the long-term success of software development, it appears to be poorly understood in the academic literature. The absence of a clear definition and model for technical debt means that the notion of technical debt remains metaphorical, thus preventing the realisation of technical debt\u27s utility as a conceptual and technical communication device. This exploratory study reconciles the high-level, abstracted view of technical debt presented in academic literature. It establishes the boundaries of the technical debt phenomenon and develops a comprehensive theoretical framework to facilitate future research. The resulting theoretical framework portrays a holistic view of technical debt that incorporates a set of precedents and outcomes, as well as the phenomenon itself

A Domino Effect: Interdependencies among Different Types of Technical Debt

The paper examines the accrual of technical debt, which represents an increasingly pressing concern for many organizations. To advance understanding of how this debt-accumulation process unfolds, an in-depth case study was conducted with a large manufacturing firm for identifying particular types of technical debt and potential interdependencies among them. The findings point to architecture debt being "the root of all evil" at the case company, setting in motion dynamics that led to the development of other types of technical debt. Scholarship should benefit from this nuanced articulation and illustration of interdependencies across the various types of technical debt

Factors affecting Technical Debt Raw data from a systematic literature map

"This document presents the complete list of references that have been short listed during the systematic review process carried out during the months of April-September 2012. The objective of the systematic review was to identify current research trends in technical debt and to explore the relationship between technical debt measures and agile software development. This documents includes 352 references that are categorized according to their relevance to technical debt research." [Abstract

Comparing Four Approaches for Technical Debt Identification

Background: Software systems accumulate technical debt (TD) when short-term goals in software development are traded for long term goals (e.g., quick-and-dirty implementation to reach a release date vs. a well-refactored implementation that supports the long term health of the project). Some forms of TD accumulate over time in the form of source code that is difficult to work with and exhibits a variety of anomalies. A number of source code analysis techniques and tools have been proposed to potentially identify the code-level debt accumulated in a system. What has not yet been studied is if using multiple tools to detect TD can lead to benefits, i.e. if different tools will flag the same or different source code components. Further, these techniques also lack investigation into the symptoms of TD "interest" that they lead to. To address this latter question, we also investigated whether TD, as identified by the source code analysis techniques, correlates with interest payments in the form of increased defect- and change-proneness. Aims: Comparing the results of different TD identification approaches to understand their commonalities and differences and to evaluate their relationship to indicators of future TD "interest". Method: We selected four different TD identification techniques (code smells, automatic static analysis (ASA) issues, grime buildup, and modularity violations) and applied them to 13 versions of the Apache Hadoop open source software project. We collected and aggregated statistical measures to investigate whether the different techniques identified TD indicators in the same or different classes and whether those classes in turn exhibited high interest (in the form of a large number of defects and higher change proneness). Results: The outputs of the four approaches have very little overlap and are therefore pointing to different problems in the source code. Dispersed coupling and modularity violations were co-located in classes with higher defect proneness. We also observed a strong relationship between modularity violations and change proneness. Conclusions: Our main contribution is an initial overview of the TD landscape, showing that different TD techniques are loosely coupled and therefore indicate problems in different locations of the source code. Moreover, our proxy interest indicators (change- and defect-proneness) correlate with only a small subset of TD indicator

Comparing Four Approaches for Technical Debt Identification

Background: Software systems accumulate technical debt (TD) when short-term goals in software development are traded for long term goals (e.g., quick-and-dirty implementation to reach a release date vs. a well-refactored implementation that supports the long term health of the project). Some forms of TD accumulate over time in the form of source code that is difficult to work with and exhibits a variety of anomalies. A number of source code analysis techniques and tools have been proposed to potentially identify the code-level debt accumulated in a system. What has not yet been studied is if using multiple tools to detect TD can lead to benefits, i.e. if different tools will flag the same or different source code components. Further, these techniques also lack investigation into the symptoms of TD “interest” that they lead to. To address this latter question, we also investigated whether TD, as identified by the source code analysis techniques, correlates with interest payments in the form of increased defect- and change-proneness. Aims: Comparing the results of different TD identification approaches to understand their commonalities and differences and to evaluate their relationship to indicators of future TD “interest”. Method: We selected four different TD identification techniques (code smells, automatic static analysis (ASA) issues, grime buildup, and modularity violations) and applied them to 13 versions of the Apache Hadoop open source software project. We collected and aggregated statistical measures to investigate whether the different techniques identified TD indicators in the same or different classes and whether those classes in turn exhibited high interest (in the form of a large number of defects and higher change proneness). Results: The outputs of the four approaches have very little overlap and are therefore pointing to different problems in the source code. Dispersed coupling and modularity violations were co-located in classes with higher defect proneness. We also observed a strong relationship between modularity violations and change proneness. Conclusions: Our main contribution is an initial overview of the TD landscape, showing that different TD techniques are loosely coupled and therefore indicate problems in different locations of the source code. Moreover, our proxy interest indicators (change- and defect-proneness) correlate with only a small subset of TD indicators

A maturity model based on ISO/IEC/IEEE 42010:2011 to identify technical debt in software architecture

Software architecture is considered an important area of Software Engineering, as it is useful for managing the development and maintenance of large scale software-intensive systems. The software architecture as a development product is useful for technical activities, such as describing the views and concerns of the future software products, as well as for management activities, including allocating tasks to each team and as an input for project management activities. One main issue when describing the software architecture is knowing what elements must be included in the architecture, and at what level of detail. Thus, the description of a Software Architecture has been considered a crucial deliverable in a software development process because it is read by many stakeholders when developing and maintaining complex software systems that are composed of multiple elements, including software, systems, hardware, and processes. Due to Software Architecture importance, the ISO/IEC/IEEE 42010:2011 standard was published in 2011. In order to facilitate and assist in the documentation of software architecture, many contributions have been proposed in the past decades for architectural standards, provided by academia and industry. This master thesis proposes the use of standard ISO/IEC/IEEE 42010:2011 to develop a maturity model, named ArchCaMo, which is based on sections 5, 6, and 7 of the mentioned standard. To support the designing of ArchCaMo, a Systematic Mapping Study was performed for describing studies that explicitly used the ISO/IEC/IEEE 42010:2011 standard, and identifying which parts of this standard were most considered in the literature. The ArchCaMo is useful to evaluate current architectures and analyze the rate of architecture debt. In addition, it is effective for organizations that are struggling with organizing, describing, and communicating the software architecture for multiple stakeholders. For each level of architecture maturity, the organization knows what to expect concerning activities and deliverables. Within this objective, three organizations are selected as case studies. The researchers conducted the survey by means of interviews with their software architect or the chief of the software architecture team. By analyzing the obtained results, the authors checked the compliance of their software architecture activities with ISO/IEC/IEEE 42010:2011. As a result, all three organizations were classified on level 1, which means that these organizations fail in at least one aspect to formalize and define the software architecture.Fundação de Apoio a Pesquisa e à Inovação Tecnológica do Estado de Sergipe - FAPITEC/SEArquitetura de software é considerada uma área importante da Engenharia de Software, pois é útil para gerenciar o desenvolvimento e a manutenção de sistemas intensivos de software em larga escala. A arquitetura de software como produto de desenvolvimento é útil para atividades técnicas, como descrever as visões e expectativas dos futuros produtos de software, bem como para atividades de gerenciamento, incluindo a alocação de tarefas para cada equipe e como entrada para as atividades de gerenciamento de projetos. Um problema principal ao descrever a arquitetura do software é saber quais elementos devem ser incluídos na arquitetura e em que nível de detalhe. Assim, a descrição de uma arquitetura de software é considerada uma entrega crucial em um processo de desenvolvimento de software, porque é lida por muitas partes interessadas em desenvolver e manter sistemas de software complexos compostos por vários elementos, incluindo software, sistemas, hardware e processos. Devido à importância da arquitetura de software, o padrão ISO/IEC/IEEE 42010:2011 foi publicado em 2011. Para facilitar e auxiliar na documentação da arquitetura de software, muitas contribuições foram propostas nas últimas décadas para os padrões de arquitetura, fornecidos pela academia e pela indústria. Esta dissertação de mestrado propõe o uso da norma ISO/IEC/IEEE 42010:2011 para desenvolver um modelo de maturidade, denominado ArchCaMo, baseado nas seções 5, 6 e 7 da norma mencionada. Para apoiar o projeto do ArchCaMo, foi realizado um Mapeamento Sistemático para descrever estudos que usavam explicitamente o padrão ISO/IEC/IEEE 42010:2011 e identificar quais partes desse padrão foram mais consideradas na literatura. ArchCaMo é útil para avaliar arquiteturas atuais e analisar a taxa de dívida técnica da arquitetura. Além disso, ele é eficaz para organizações que estão lutando para organizar, descrever e comunicar a arquitetura de software para vários interessados. Para cada nível de maturidade da arquitetura, a organização sabe o que esperar em relação a atividades e entregas. Dentro deste objetivo, três organizações são selecionadas como estudos de caso. Os pesquisadores conduziram a pesquisa por meio de entrevistas com seu arquiteto de software ou com o chefe da equipe de arquitetura de software. Ao analisar os resultados obtidos, os autores verificaram a conformidade de suas atividades de arquitetura de software com a norma ISO/IEC/IEEE 42010:2011. Como resultado, todas as três organizações foram classificadas no nível 1, o que significa que essas organizações falham em pelo menos um aspecto em formalizar e definir a arquitetura do software.São Cristóvão, S

DEVELOPMENT OF A QUALITY MANAGEMENT ASSESSMENT TOOL TO EVALUATE SOFTWARE USING SOFTWARE QUALITY MANAGEMENT BEST PRACTICES

Organizations are constantly in search of competitive advantages in today’s complex global marketplace through improvement of quality, better affordability, and quicker delivery of products and services. This is significantly true for software as a product and service. With other things being equal, the quality of software will impact consumers, organizations, and nations. The quality and efficiency of the process utilized to create and deploy software can result in cost and schedule overruns, cancelled projects, loss of revenue, loss of market share, and loss of consumer confidence. Hence, it behooves us to constantly explore quality management strategies to deliver high quality software quickly at an affordable price. This research identifies software quality management best practices derived from scholarly literature using bibliometric techniques in conjunction with literature review, synthesizes these best practices into an assessment tool for industrial practitioners, refines the assessment tool based on academic expert review, further refines the assessment tool based on a pilot test with industry experts, and undertakes industry expert validation. Key elements of this software quality assessment tool include issues dealing with people, organizational environment, process, and technology best practices. Additionally, weights were assigned to issues of people, organizational environment, process, and technology best practices based on their relative importance, to calculate an overall weighted score for organizations to evaluate where they stand with respect to their peers in pursuing the business of producing quality software. This research study indicates that people best practices carry 40% of overall weight, organizational best v practices carry 30% of overall weight, process best practices carry 15% of overall weight, and technology best practices carry 15% of overall weight. The assessment tool that is developed will be valuable to organizations that seek to take advantage of rapid innovations in pursuing higher software quality. These organizations can use the assessment tool for implementing best practices based on the latest cutting edge management strategies that can lead to improved software quality and other competitive advantages in the global marketplace. This research contributed to the current academic literature in software quality by presenting a quality assessment tool based on software quality management best practices, contributed to the body of knowledge on software quality management, and expanded the knowledgebase on quality management practices. This research also contributed to current professional practice by incorporating software quality management best practices into a quality management assessment tool to evaluate software

Value- and debt-aware selection and composition in cloud-based service-oriented architectures using real options

This thesis presents a novel model for service selection and composition in Cloud-based Service-Oriented Architectures (CB-SOA), which is called CloudMTD, using real options, Dependency Structure Matrix (DSM) and propagation-cost metrics. CB-SOA architectures are composed of web services, which are leased or bought off the cloud marketplace. CB-SOA can improve its utility and add value to its composition by substituting its constituent services. The substitution decisions may introduce technical debt, which needs to be managed. The thesis defines the concept of technical debt for CB-SOA and reports on the available technical debt definitions and approaches in the literature. The formulation of service substitution problem and its technical debt valuation is based on options, which exploits Binomial Options Analysis. This thesis looks at different option types under uncertainty. This thesis is concerned with some scenarios that may lead to technical debt, which are related to web service selection and composition that has been driven by either a technical or a business objective. In each scenario, we are interested in three decisions (1) keep, (2) substitute or (3) abandon the current service. Each scenario takes into consideration either one or more QoS attribute dimension (e.g. Availability). We address these scenarios from an option-based perspective. Each scenario is linked to a suitable option type. A specific option type depends on the nature of the application, problem to be investigated, and the decision to be taken. In addition, we use Dependency Structure Matrix (DSM) in order to represent dependencies among web services in CB-SOA. We introduce time and complexity sensitive propagation-cost metrics to DSM to solve the problem. In addition, CloudMTD model informs the time-value of the decisions under uncertainty based on behavioral and structural aspects of CB-SOA