Ariadi Nugroho

An empirical model of technical debt and interest

Cunningham introduced the metaphor of technical debt as guidance for software developers that must trade engineering quality against short-term goals. We revisit the technical debt metaphor, and translate it into terms that can help IT executives better understand their IT investments. An approach is proposed to quantify debts (cost to fix technical quality issues) and interest (extra cost spent on maintenance due to technical quality issues). Our approach is based on an empirical assessment method of software quality developed at the Software Improvement Group (SIG). The core part of the technical debt calculation is constructed on the basis of empirical data of 44 systems that are currently being monitored by SIG. In a case study, we apply the approach to a real system, and discuss how the results provide useful insights on important questions related to IT investment such as the return on investment (ROI) in software quality improvement.

A Survey of the Practice of Design -- Code Correspondence amongst Professional Software Engineers

Correspondence between the design and the code of a system is desirable for several purposes in software development, such as predicting properties of the system based on the design, and for using the documentation for understanding and maintaining the system. In this paper we report on a study into the correspondence between the design of a software system, represented by means of UML, and the implementation of the system. We performed a web-based questionnaire among professional software engineers for finding out how they deal with correspondence. The questionnaire elicited the attitude of professional software engineers with respect to: importance of correspondence, common practice in maintaining correspondence and common reasons for deterioration of correspondence. The results of the questionnaire provide a deeper understanding of the aspects of correspondence and their importance in practical software engineering.

Level of detail in UML models and its impact on model comprehension: A controlled experiment

Previous studies have shown that the style and rigor used in UML models vary widely across software projects [1-3]. However, notwithstanding the varying use of styles and rigor, little research has been conducted to investigate the drivers and effects of using different styles and rigor in modeling on software development. In this paper, we evaluate Level of Detail (LoD) in UML models as a form of style and rigor in UML modeling. Using a UML model of a library system, we experimentally investigate the impact of LoD on model comprehension. More specifically, we explore whether LoD in UML models affects the correctness and efficiency in comprehending UML models. Using two independent groups of graduate students majoring in computer science, we performed a controlled experiment. The results of the experiment confirm the significant effect of LoD in UML models on model comprehension. Nevertheless, replication of this study is necessary, especially in contexts that involve professional software engineers, to improve the generalizability of the results.

How effective is UML modeling

Modeling has become a common practice in modern software engineering. Since the mid 1990s the Unified Modeling Language (UML) has become the de facto standard for modeling software systems. The UML is used in all phases of software development: ranging from the requirement phase to the maintenance phase. However, empirical evidence regarding the effectiveness of modeling in software development is few and far apart. This paper aims to synthesize empirical evidence regarding the effectiveness of modeling using UML in software development, with a special focus on the cost and benefits.

Empirical Analysis of the Relation between Level of Detail in UML Models and Defect Density

This paper investigates the relation between the level of detail (LoD) in UML models and defect density of the associated implementation. We propose LoD measures that are applicable to both class- and sequence diagrams. Based on empirical data from an industrial software project we have found that classes with higher LoD, calculated using sequence diagram LoD metrics, correlates with lower defect density. Overall, this paper discusses a novel and practical approach to measure LoD in UML models and describes its application to a significant industrial case study.

Evaluating the Impact of UML Modeling on Software Quality: An Industrial Case Study

The contribution of formal modeling approaches in software development has always been a subject of debates. The proponents of model-driven development argue that big upfront designs although require substantial investment will payoff later in the implementation phase in terms of increased productivity and quality. On the other hand, software engineers who are not very keen on modeling perceive the activity as simply a waste of time and money without any real contribution to the final software product. Considering present advancement of model-based software development in software industry, we are challenged to investigate the real contribution of modeling in software development. Therefore, in this paper we report on an empirical investigation on the impact of UML modeling on the quality of software system. In particular, we focus on defect density as a measure of software quality. Based on a significant industrial case study, we have found that the use of UML modeling potentially reduces defect density in software system.

Assessing UML design metrics for predicting fault-prone classes in a Java system

Identifying and fixing software problems before implementation are believed to be much cheaper than after implementation. Hence, it follows that predicting fault-proneness of software modules based on early software artifacts like software design is beneficial as it allows software engineers to perform early predictions to anticipate and avoid faults early enough. Taking this motivation into consideration, in this paper we evaluate the usefulness of UML design metrics to predict fault-proneness of Java classes. We use historical data of a significant industrial Java system to build and validate a UML-based prediction model. Based on the case study we have found that level of detail of messages and import coupling—both measured from sequence diagrams, are significant predictors of class fault-proneness. We also learn that the prediction model built exclusively using the UML design metrics demonstrates a better accuracy than the one built exclusively using code metrics.

What is the value of your software

Assessment of the economic value of software systems is useful in contexts such as capitalization on the balance sheet and due diligence prior to acquisition. Current accounting practice in determining software value is based on the cost spent in software development. This approach fails to account for the efficiency with which software has been produced or the quality of the product. This paper proposes three alternative models for determining the production value of software, based on the notions of technical debt and interest. We applied the models to 367 proprietary systems developed by a range of different organisations using a range of different programming languages. We present the valuation results and discuss the weaknesses and strengths of the models.

The impact of UML modeling on defect density and defect resolution time in a proprietary system

Background: The contribution of modeling in software development has been a subject of debates. The proponents of model-driven development argue that a big upfront modeling requires substantial investment, but it will payoff later in the implementation phase in terms of increased productivity and quality. Other software engineers perceive modeling activity as a waste of time and money without any real contribution to the final software product. Considering present advancement of model-based software development in software industry, we are challenged to investigate the real contribution of modeling in software development. Objective: We analyze the impacts of UML modeling, specifically the production of class and sequence diagrams, on the quality of the code, as measured by defect density, and on defect resolution time. Method: Using data of a proprietary system, we conduct post-mortem analyses to test the difference in defect density between software modules that are modeled and not modeled. Similarly, we test the difference in resolution time between defects that are related to modeled and not modeled functionality. Result: We have found that the production of UML class diagrams and sequence diagrams reduces defect density in the code and the time required to fix defects. These results are obtained after controlling for the effects of co-factors such as code coupling and complexity. Conclusion: The results confirm that not only does the production of UML class diagrams and sequence diagrams possibly help improve the quality of software, but also it possibly help increase the productivity in software maintenance.

The use of UML class diagrams and its effect on code change-proneness

The goal of this study is to investigate the use of UML and its impact on the change proneness of the implementation code. We look at whether the use of UML class diagrams, as opposed to using no modeling notation, influences code change proneness. Furthermore, using five design metrics we measure the quality of UML class diagrams and explore its correlation with code change proneness. Based on a UML model of an industrial system and multiple snapshots of the implementation code, we have found that at the system level the change proneness of code modeled using class diagrams is lower than that of code that is not modeled at all. However, we observe different results when performing the analysis at different system levels (e.g., subsystem and sub subsystem). Additionally, we have found significant correlations between class diagram size, complexity, and level of detail and the change proneness of the implementation code.