In Off-the-shelf (OTS)-based custom software projects there are common and different processes between software developers and acquirers. Better understanding of these differences may help to initiate reconciling perspectives between these stakeholders for managing the software processes. An online survey was conducted to explore the involvement of two main stakeholders in OTS-based software project, developer and acquirer, and also their roles in decision making in make vs. buy, and in OTS selection. The respondents were 35 software developers and 34 software acquirers of Indonesian background. Then, a follow-up study involving 4 respondents was conducted to investigate differences in process perspective between both stakeholders. Our study found that for common and unique processes, both stakeholders perceive to have high and medium involvement in their stakeholder's processes. Only for detailed software design and coding, acquirer involvements in OTS-based custom software development were low. This study also found that each stakeholder perceives either themselves or both to make final decision on make vs. buy. In OTS-selection, both stakeholders agreed that developers had higher involvement. Based on the follow-up study findings, we proposed a model comparing and discussing stakeholder involvements, roles and responsibilities to reconcile these differences. A real example from the follow-up study findings was given to demonstrate the proposed model.

Automated testing is a basic principle of agile development. Its benefits include early defect detection, defect causelocalization and removal of fear to apply changes to the code. Therefore, maintaining high quality test code is essential. This study introduces a model that assesses test code quality by combining source code metrics that reflect three main aspects of test codequality: completeness, effectiveness and maintainability. The model is inspired by the Software Quality Model of the SoftwareImprovement Group which aggregates source code metrics into quality ratings based on benchmarking. To validate the model we assess the relation between test code quality, as measured by the model, and issue handling performance. An experiment isconducted in which the test code quality model is applied to$18$open source systems. The test quality ratings are tested for correlation with issue handling indicators, which are obtained by mining issue repositories. In particular, we study the (1) defect resolution speed, (2) throughput and (3) productivity issue handling metrics. The results reveal a significant positive correlation between test code quality and two out of the three issue handling metrics (throughput and productivity), indicating that good test code quality positively influences issue handling performance.

Context: Research indicates that software quality, to a large extent, depends on cooperation within software teams [1] Since software development is a creative process that involves human interaction in the context of a team, it is important to understand the teamwork factors that influence performance. Objective: We present a study design in which we aim to examine the factors within software development teams that have significant influence on the performance of the team. We propose to consider factors such as communication, coordination of expertise, cohesion, trust, cooperation, and value diversity. The study investigates whether and to which extent these factors correlate with a performance of the team. In order to capture a variety of relevant teamwork factors, we created a new model extending the work of Hoegl and Gemuenden [2] and Liang et al. [3] Method: The study is based on quantitative research by means of an online questionnaire. We invited more than 20 software development teams in the Netherlands to participate in our team performance assessment, evaluating the teamwork and performance of the team. Based on an average team size of five people, one would therefore expect at least 100 participants in total. Also, product stakeholders will be asked to give their independent assessments of the performance of the team. Expected result: By analyzing the correlation between teamwork factors and team performance, we expect to gain a deeper understanding of how teamwork factors influence team performance. We also expect to validate the implemented extensions of teamwork model with respect to earlier work. Conclusion: Software teamwork factors are important to understand. In order to get a better understanding of the role of teamwork factors, this study should be conducted.

Software maintenance tasks are mainly related to fixing defects and implementing new features. Higher efficiency in performing such tasks is therefore going to reduce the costs of maintenance. A previous study involving open source systems has shown that higher software maintainability corresponds to faster speed in fixing defects [1]. In this paper we replicate the previous study by mining bug report data of three proprietary software projects. In one of the projects, a correlation between higher software maintainability and faster defect resolution is confirmed. The quality of issue handling process (e.g., issue registration accuracy and completeness, scope and complexity of issue workflow) should be considered in further research as it might explain the circumstances under which the correlation can be observed.

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.

The UML (Unified Modeling Language) has become the de facto standard for software modeling in the software industry. Despite its wide acceptance, little is known about how UML is used in practice, let alone the challenges and difficulties faced by engineers who work with this modeling notation. In this paper, we provide empirical findings from a survey on the use of UML amongst 80 professional software engineers. We explore software engineers' opinions on common styles of using UML and how they perceive the impact of using UML on productivity and quality in software development. One of the results reveals that the impact of using the UML on productivity is perceived mostly in the design, analysis, and implementation phases.

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.