Change decision support:extraction and analysis of late architecture changes using change characterization and software metrics

Software maintenance is one of the most crucial aspects of software development. Software engineering researchers must develop practical solutions to handle the challenges presented in maintaining mature software systems. Research that addresses practical means of mitigating the risks involved when changing software, reducing the complexity of mature software systems, and eliminating the introduction of preventable bugs is paramount to today’s software engineering discipline. Giving software developers the information that they need to make quality decisions about changes that will negatively affect their software systems is a key aspect to mitigating those risks. This dissertation presents work performed to assist developers to collect and process data that plays a role in change decision-making during the maintenance phase. To address these problems, developers need a way to better understand the effects of a change prior to making the change. This research addresses the problems associated with increasing architectural complexity caused by software change using a twoold approach. The first approach is to characterize software changes to assess their architectural impact prior to their implementation. The second approach is to identify a set of architecture metrics that correlate to system quality and maintainability and to use these metrics to determine the level of difficulty involved in making a change. The two approaches have been combined and the results presented provide developers with a beneficial analysis framework that offers insight into the change process

Analyzing the concept of technical debt in the context of agile software development: A systematic literature review

Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. We found five research areas of interest related to the literature of TD in ASD. Among those areas, managing TD in ASD received the highest attention, followed by architecture in ASD and its relationship with TD. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. Focus on quick delivery and architectural and design issues were the most popular causes of incurring TD in ASD. Reduced productivity, system degradation and increased maintenance cost were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which refactoring and enhancing the visibility of TD were the most significant. The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation

Flora: a framework for decomposing software architecture to introduce local recovery

The decomposition of software architecture into modular units is usually driven by the required quality concerns. In this paper we focus on the impact of local recovery concern on the decomposition of the software system. For achieving local recovery, the system needs to be decomposed into separate units that can be recovered in isolation. However, it appears that this required decomposition for recovery is usually not aligned with the decomposition based on functional concerns. Moreover, introducing local recovery to a software system, while preserving the existing decomposition, is not trivial and requires substantial development and maintenance effort. To reduce this effort we propose a framework that supports the decomposition and implementation of software architecture for local recovery. The framework provides reusable abstractions for defining recoverable units and the necessary coordination and communication protocols for recovery. We discuss our experiences in the application and evaluation of the framework for introducing local recovery to the open-source media player called MPlayer. Copyright 2009 John Wiley & Sons, Ltd

System design and the cost of architectural complexity

Thesis (Ph. D.)--Massachusetts Institute of Technology, Engineering Systems Division, 2013.Cataloged from PDF version of thesis.Includes bibliographical references (p. 159-166).Many modern systems are so large that no one truly understands how they work. It is well known in the engineering community that architectural patterns (including hierarchies, modules, and abstraction layers) should be used in design because they play an important role in controlling complexity. These patterns make a system easier to evolve and keep its separate portions within the bounds of human understanding so that distributed teams can operate independently while jointly fashioning a coherent whole. This study set out to measure the link between architectural complexity (the complexity that arises within a system due to a lack or breakdown of hierarchy or modularity) and a variety of costs incurred by a development organization. A study was conducted within a successful software firm. Measures of architectural complexity were taken from eight versions of their product using techniques recently developed by MacCormack, Baldwin, and Rusnak. Significant cost drivers including defect density, developer productivity, and staff turnover were measured as well. The link between cost and complexity was explored using a variety of statistical techniques. Within this research setting, we found that differences in architectural complexity could account for 50% drops in productivity, three-fold increases in defect density, and order-of-magnitude increases in staff turnover. Using the techniques developed in this thesis, it should be possible for firms to estimate the financial cost of their complexity by assigning a monetary value to the decreased productivity, increased defect density, and increased turnover it causes. As a result, it should be possible for firms to more accurately estimate the potential dollar-value of refactoring efforts aimed at improving architecture.by Daniel J. Sturtevant.Ph.D

Optimizing decomposition of software architecture for local recovery

Cataloged from PDF version of article.The increasing size and complexity of software systems has led to an amplified number of potential failures and as such makes it harder to ensure software reliability. Since it is usually hard to prevent all the failures, fault tolerance techniques have become more important. An essential element of fault tolerance is the recovery from failures. Local recovery is an effective approach whereby only the erroneous parts of the system are recovered while the other parts remain available. For achieving local recovery, the architecture needs to be decomposed into separate units that can be recovered in isolation. Usually, there are many different alternative ways to decompose the system into recoverable units. It appears that each of these decomposition alternatives performs differently with respect to availability and performance metrics. We propose a systematic approach dedicated to optimizing the decomposition of software architecture for local recovery. The approach provides systematic guidelines to depict the design space of the possible decomposition alternatives, to reduce the design space with respect to domain and stakeholder constraints and to balance the feasible alternatives with respect to availability and performance. The approach is supported by an integrated set of tools and illustrated for the open-source MPlayer software

Methods for Improving the Maintainability of Application Software

Yhteiskunta on tullut monella tavalla riippuvaiseksi ohjelmistoista. Ne pyörittävät monia arkipäiväisiä rutiineja, joita me pidämme itsestäänselvyyksinä. Mitä enemmän ohjelmistot ovat yhteiskuntamme toimintoja, sitä vähemmän ohjelmistojen vaatimukset voidaan määritellä eristyksessä ympäröivästä maailmasta. Toimintaympäristön muutosten tulee näkyä myös muutoksina ohjelmistossa. Ohjelmistojen ylläpito ei ole siis vain virheiden korjaamista. Uusia ominaisuuksia tarvitaan jatkuvasti, jotta ohjelmisto pysyisi hyväksyttävänä muuttuvassa ympäristössä. Pitkäikäiselle ohjelmistolle ylläpidon kustannukset voivat muodostaa jopa yli puolet kokonaiskustannuksista. Ylläpidettävyyden parantaminen ei ainoastaan pienennä kustannuksia vaan myös pidentää ohjelmiston elinikää. Tässä diplomityössä etsimme keinoja, joilla ohjelmiston ylläpidettävyyttä voidaan parantaa jo kehitysvaiheessa. Teemme tapaustutkimuksen kolmesta projektiauditoinnista keskikokoisessa suomalaisessa ohjelmistoyrityksessä. Auditointien tavoitteena on löytää yleisiä ylläpidettävyyteen liittyviä tekijöitä. Tulemme tulokseen, että ylläpidettävyys on useiden osittain toisistaan riippumattomien tekijöiden summa. Siksi sitä tulisi tarkastella osiensa kautta sen sijaan, että sitä mitattaisiin yhtenä kokonaisuutena. Projektiauditointien perusteella listaamme yleisiä ohjeita, joita kehitystiimit voivat käyttää suuntaviivoina. Koska ylläpidettävyys on jossain määrin subjektiivista, ei ohjeita voi käyttää sellaisenaan. Ne tulee sovittaa erikseen jokaiseen toimintaympäristöön ja projektiin.Society has become in many ways dependent on software. It runs several everyday tasks that we take for granted in modern life. The more society is in interaction with software the less the requirements of software systems can be isolated from the world around them. Changes of the operation environment have to be met with changes in the software. Software maintenance is, therefore, not simply corrective changes. New features have to be constantly implemented to keep the software acceptable in the changing world. For a software with a long lifetime, maintenance can form more than a half of the costs. Improving software's maintainability not only reduces the costs but also prolongs the application's lifetime. In this thesis, we search for methods that can be used to improve software's maintainability during its development phase. We do a case-study of three project audits in a mid-sized Finnish software company. The aim is to find common issues that affect software's maintainability. We discover that maintainability is a sum of partly uncorrelated factors. It should thus be monitored through its components rather than one single measurement. Based on the project audits, we provide a list of general instructions that can be used as a guideline by development teams. As maintainability is to some extent subjective, the instructions cannot be used as such. Instead they have to be adapted to each company culture and project separately

Using real options to select stable Middleware-induced software architectures

The requirements that force decisions towards building distributed system architectures are usually of a non-functional nature. Scalability, openness, heterogeneity, and fault-tolerance are examples of such non-functional requirements. The current trend is to build distributed systems with middleware, which provide the application developer with primitives for managing the complexity of distribution, system resources, and for realising many of the non-functional requirements. As non-functional requirements evolve, the `coupling' between the middleware and architecture becomes the focal point for understanding the stability of the distributed software system architecture in the face of change. It is hypothesised that the choice of a stable distributed software architecture depends on the choice of the underlying middleware and its flexibility in responding to future changes in non-functional requirements. Drawing on a case study that adequately represents a medium-size component-based distributed architecture, it is reported how a likely future change in scalability could impact the architectural structure of two versions, each induced with a distinct middleware: one with CORBA and the other with J2EE. An option-based model is derived to value the flexibility of the induced-architectures and to guide the selection. The hypothesis is verified to be true for the given change. The paper concludes with some observations that could stimulate future research in the area of relating requirements to software architectures