International Journal of Software Engineering and Knowledge Engineering

This paper is the result of two related studies done on the estimation of IT projects at a large Dutch multinational company. The first one is a study about the accuracy of different dimensions of IT project estimating: schedule, budget and effort. [Note: This paper is an extension of the paper published by the authors as "An analysis of accuracy and learning in software project estimating" [28].] This study is based on a dataset of 171 projects collected at the IT department of the company. We analyzed the estimation error of budget, effort and schedule. Also, we analyzed whether there is any learning (improvement) effect over time. With the results of the first study we proceeded to research what is causing the current estimation error (inaccuracy). The results of our first study show that there is no relation between accuracy of budget, schedule and effort in the company analyzed. Besides, they show that over time there is no change in the inaccuracy (effectiveness and efficiency of the estimates). In our second study we discovered that the sources of this inaccuracy are: (IT estimation) process complexity, misuse of estimates, technical complexity, requirements redefinition and business domain instability. This paper reflects and provides recommendations on how to improve the learning from historical estimates and how to manage the diverse sources of inaccuracy inside this particular company and also in other organizations.

A well-known approach for identifying defect-prone parts of software in order to focus testing is to use different kinds of product metrics such as size or complexity. Although this approach has been evaluated in many contexts, the question remains if there are further opportunities to improve test focusing. One idea is to identify other types of information that may indicate the location of defect-prone software parts. Data from software inspections, in particular, appear to be promising. This kind of data might already lead to software parts that have inherent difficulties or programming challenges, and in consequence might be defect-prone. This article first explains how inspection and product metrics can be used to focus testing activities. Second, we compare selected product and inspection metrics commonly used to predict defect-prone parts (e.g. size and complexity metrics, inspection defect content metrics, and defect density metrics). Based on initial experience from two case studies performed in different environments, the suitability of different metrics for predicting defect-prone parts is illustrated. The studies revealed that inspection defect data seems to be a suitable predictor, and a combination of certain inspection and product metrics led to the best prioritizations in our contexts. In addition, qualitative experience is presented, which substantiates the expected benefit of using inspection results to optimize testing.

Scientific and engineering research is heavily dependent on effective development and use of software artifacts. Many of these artifacts are produced by the scientists themselves, rather than by trained software engineers. To address the challenges in this area, a research community often referred to as "Development of Scientific Software" has emerged in the last few decades. As this research area has matured, there has been a sharp increase in the number of papers and results made available, and it has thus become important to summarize and provide an overview about those studies. Through a systematic mapping and bibliometrics study, we have reviewed 130 papers in this area. We present the results of our study in this paper. Also we have made the mapping data available on an online repository which is planned to be updated on a regular basis. The results of our study seem to suggest that many software engineering techniques and activities are being used in the development of scientific software. However, there is still a need for further exploration of the usefulness of specific software engineering techniques (e.g., regarding software maintenance, evolution, refactoring, re(v)-engineering, process and project management) in the scientific context. It is hoped that this article will help (new) researchers get an overview of the research space and help them to understand the trends in the area.

Software maintainability is a very important quality attribute. Its prediction for relational database-driven software applications can help organizations improve the maintainability of these applications. The research presented herein adopts a survey-based approach where a survey was conducted with 40 software professionals aimed at identifying and ranking the important maintainability predictors for relational database-driven software applications. The survey results were analyzed using frequency analysis. The results suggest that maintainability prediction for relational database-driven applications is not the same as that of traditional software applications in terms of the importance of the predictors used for this purpose. The results also provide a baseline for creating maintainability prediction models for relational database-driven software applications.

Software Product Line (SPL) Engineering focuses on systematic software reuse, which has benefits such as reductions in time-to-market and effort, and improvements in the quality of products. However, establishing a SPL is not a simple matter, and can affect all aspects of the organization, since the approach is complex and involves major investment and considerable risk. These risks can have a negative impact on the expected ROI for an organization, if SPL is not sufficiently managed. This paper presents a mapping study of Risk Management (RM) in SPL Engineering. We analyzed a set of thirty studies in the field. The results points out the need for risk management practices in SPL, due to the little research on RM practices in SPL and the importance of identifying insight on RM in SPL. Most studies simply mention the importance of RM, however the steps for managing risk are not clearly specified. Our findings suggest that greater attention should be given, through the use of industrial case studies and experiments, to improve SPL productivity and ensure its success. This research is a first attempt within the SPL community to identify, classify, and manage risks, and establish mitigation strategies.

Software architecture recovery is to gain the architectural level understanding of a software system while its architecture description does not exist. In recent years, researchers have adopted various software clustering techniques to detect hierarchical structure of software systems. Most graph clustering techniques focus on the connectivity between program elements, but unreasonably ignore the similarity which is also a key measure for finding elements of one module. In this paper we propose a novel hierarchy graph clustering algorithm DGHC, which considers both similarity and connectivity between program elements. During the transformation of program dependence graph edges representing similarity between elements are added. Then similar elements are grouped by density-based approaches. The alternative strategy is adopted to find groups of closely connected and similar elements. Meanwhile we adjust the contribution of connectivity and similarity by a flexible clustering algorithm based on short random walk model, which can obtain more structure information of software to find its multiple layers. Furthermore a new method called Multi-layer Propagation Gap is proposed to suggest stable layers of hierarchy clustering result as multiple layers of software system. Extensive experimental results illustrate the effectiveness and efficiency of DGHC in detecting hierarchy structure of software through comparison with various software clustering methods.