The effort that has been made to study risk management in the context of software architecture and its evolution, has so far focused on output from structured evaluations. However, earlier research shows that formal, structured evaluation is not commonly used in industry. We have performed a survey among software architects, in order to capture a more complete picture of the risk and management issues in software architecture evolution. Our survey is specifically about their current knowledge of actual challenges they have anticipated and experienced, as well as strategies they have employed in response. We received completely filled questionnaires from 82 respondents out of a total distribution of 511 architects from the software industry in Norway. While many of the risks we have identified can be aligned with results from earlier studies, we have also identified several risks which appear not to fit these risk categories. Additionally, we found a direct link to business risks, as well as a relatively low level of awareness that lack of software architecture evaluation represents a potential risk.

Test driven development (TDD) is a software engineering technique to promote fast feedback, task-oriented development, improved quality assurance and more comprehensible low-level software design. Benefits have been shown for non-reusable software development in terms of improved quality (e.g. lower defect density). We have carried out an empirical study of a framework of reusable components, to see whether these benefits can be shown for reusable components. The framework is used in building new applications and provides services to these applications during runtime. The three first versions of this framework were developed using traditional test-last development, while for the two latest versions TDD was used. Our results show benefits in terms of reduced mean defect density (35.86%), when using TDD, over two releases. Mean change density was 76.19% lower for TDD than for test-last development. Finally, the change distribution for the TDD approach was 33.3% perfective, 5.6% adaptive and 61.1% preventive.

An international survey on risk management in software development with off-the-shelf (OTS) components is reported upon and discussed. The survey investigated actual risk-management activities and their correlations with the occurrences of typical risks in OTS component-based development. Data from 133 software projects in Norway, Italy, and Germany were collected using a stratified random sample of IT companies. The results show that OTS components normally do not contribute negatively to the quality of the software system as a whole, as is commonly expected. However, issues such as the underestimation of integration effort and inefficient debugging remain problematic and require further investigation. The results also illustrate several promising effective risk-reduction activities, e.g., putting more effort into learning relevant OTS components, integrating unfamiliar components first, thoroughly evaluating the quality of candidate OTS components, and regularly monitoring the support capability of OTS providers. Five hypotheses are proposed regarding these risk-reduction activities. The results also indicate that several other factors, such as project, cultural, and human-social factors, have to be investigated to thoroughly deal with the possible risks of OTS-based projects.

This paper presents results of a survey, related to the theoretical task-technology-fitness framework. The survey was conducted in a large Oil and Gas company in Norway, namely Statoil ASA. The task-technology-fitness framework indicates which groups of medium or technology are appropriate to choose according to the task to be performed, when collaborating with others. We have here presented the extended version of the task-technology-fitness framework, according to how Statoil ASA's employees use SMS, e-mail, instant messaging and audio (phone call), in different collaborative tasks. In total, there were 333 out of 747 respondents who participated in the survey. The results reveal that SMS and Instant Messaging are not seen as efficient or well suited communication channels for collaborative tasks. E-mail seems to be favorable among the respondents for the collaborative tasks, while audio (phone call) follows closely. The results are important in that they indicate when SMS, e-mail, instant messaging and audio (phone call) are appropriate to use. The purpose of the survey was to discover potential area of improvements for Statoil ASA

Component-based software development (CBSD) is becoming more and more important since it promotes reuse to higher levels of abstraction. As a consequence, many components are available being either open-source software (OSS) or commercial-off-the-shelf (COTS). However, it is still unclear how the decision for acquiring OSS or COTS components is made in practice. This paper describes an empirical study on why project decision-makers selected COTS instead of OSS components, or vice versa. The study was performed as an international survey in Norway, Italy and Germany. It focused on decision making on using off-the-shelf (OTS) components. We have gathered answers from 83 projects using only COTS components and 44 projects using only OSS components. Results of this study show significant differences and commonalities of integrating OSS or COTS components. Moreover, the study illustrates several research questions that warrant future research.

This paper describes the results of analyzing change requests from 4 releases of a set of reusable components developed by a large Oil and Gas company in Norway, Statoil ASA. These components are total 20348 SLOC (Source Lines of Code), and have been programmed in Java. Change requests in our study cover any change in the requirements. We have investigated the distribution of change requests over the categories perfective, adaptive and preventive changes that characterize aspects of software maintenance and evolution. In total there are 208 combined perfective, adaptive and preventive changes. The results reveal that 59% of changes are perfective, 27% of changes are adaptive and 14% of changes are preventive. The corrective changes (223 in total) are excluded in this paper, since they will be analyzed in future work. We have also investigated the relation between customers' and developers' priority on change requests and found no significant difference between customer and developers' priority of change requests. Larger components had more change requests as expected and priority level of change requests increases with component size. The results are important in that they characterize and explain the changes to components. This is an indication as to which components require more effort and resources in managing software changes at Statoil ASA.