Abstract Software engineering is decision intensive. Evidence‐based software engineering is suggested for decision‐making concerning the use of methods and technologies when developing software. Software development often includes the reuse of software assets, for example, open‐source components. Which components to use have implications on the quality of the software (e.g., maintainability). Thus, research is needed to support decision‐making for composite software. This paper presents a roadmap for research required to support evidence‐based decision‐making for choosing and integrating assets in composite software systems. The roadmap is developed as an output from a 5‐year project in the area, including researchers from three different organizations. The roadmap is developed in an iterative process and is based on (1) systematic literature reviews of the area; (2) investigations of the state of practice, including a case survey and a survey; and (3) development and evaluation of solutions for asset identification and selection. The research activities resulted in identifying 11 areas in need of research. The areas are grouped into two categories: areas enabling evidence‐based decision‐making and those related to supporting the decision‐making. The roadmap outlines research needs in these 11 areas. The research challenges and research directions presented in this roadmap are key areas for further research to support evidence‐based decision‐making for composite software.

An intent‐driven system is a compositional system of human actors and machine actors. The aim of intent‐driven systems is to capture stakeholders’ intents and transform these into a form that enables computer processing of the intents. Only then are different machine actors able to negotiate with each other on behalf of their respective stakeholders and their intents, and suggest a mutually beneficial collaboration. The aim is to find existing methods/techniques which could be used as building blocks to construct intent‐driven systems. This is used to provide insight into what is needed to enable intent‐driven systems with the help of these methods/techniques. As a part of a design science study, a Systematic Literature Review is conducted. The existences of methods/techniques which can be used as building blocks to construct intent‐driven systems exist in the literature. How these methods/techniques can interact in order to enable realisations of intent‐driven systems is not evident in the existing literature. The synthesis shows a need for further research regarding the semantic interchange of information, actor interaction in intent‐driven systems, and the governance of intent‐driven systems.

Software supporting an enterprise’s business, also known as a business support system, needs to support the correlation of activities between actors as well as influence the activities based on knowledge about the value networks in which the enterprise acts. This requires the use of policies and rules to guide or enforce the execution of strategies or tactics within an enterprise as well as in collaborations between enterprises. With the help of policies and rules, an enterprise is able to capture an actor’s intent in its business support system, and act according to this intent on behalf of the actor. Since the value networks an enterprise is part of will change over time the business intents’ life cycle states might change. Achieving the changes in an effective and efficient way requires knowledge about the affected intents and the correlation between intents. The aim of the study is to identify how a business support system can support continuous changes to business intents. The first step is to find a theoretical model which serves as a foundation for intent-driven systems. We conducted a case study using a focus group approach with employees from Ericsson. This case study was influenced by the spiral case study process. The study resulted in a model supporting continuous definition and execution of an enterprise. The model is divided into three layers; Define, Execute, and a common governance view layer. This makes it possible to support continuous definition and execution of business intents and to identify the actors needed to support the business intents’ life cycles. This model is supported by a meta-model for capturing information into viewpoints. The research question is addressed by suggesting a solution supporting continuous definition and execution of an enterprise as a model of value architecture components and business functions. The results will affect how Ericsson will build the business studio for their next generation business support systems.

Abstract Background Software reuse is often seen as a cost avoidance rather than a gained value. This results in a rather one‐sided debate where issues such a resource control, release schedule, quality, or reuse in more than one release are neglected. Aims We propose a reuse value assessment framework, intended to provide a more nuanced view of the value and costs associated with different reuse candidates. Method This framework is constructed based on findings from an interview study at a large software development company. Results The framework considers the functionality, compliance to standards, provided quality, and provided support of a reuse candidate, thus enabling an informed comparison between different reuse candidates. Furthermore, the framework provides means for tracking the value of the reused asset throughout subsequent releases. Conclusions The reuse value assessment framework is a tool to assist in the selection between different reuse candidates. The framework also provides a means to assess the current value of a reusable asset in a product, which can be used to indicate where maintenance efforts would increase the utilized potential of the reusable asset.

Requirements traceability enables software engineers to trace a requirement from its emergence to its fulfillment. In this paper we examine requirements traceability definitions, challenges, tools and techniques, by the use of a systematic review performing an exhaustive search through the years 1997–2007. We present a number of common definitions, challenges, available tools and techniques (presenting empirical evidence when found), while complementing the results and analysis with a static validation in industry through a series of interviews.

Agile development methods such as extreme programming (XP), SCRUM, Lean Software Development (Lean SD) and others have gained much popularity during the last years. Agile methodologies promise faster time-to-market, satisfied customers and high quality software. While these prospects are appealing, the suitability of agile practices to different domains and business contexts still remains unclear. In this article we investigate the applicability of agile principles in the context of market-driven software product development (MDPD), focusing on pre-project activities. This article presents results of a comparison between typical properties of agile methods to the needs of MDPD, as well as findings of a case study conducted at Ericsson, an early adopter of agile product development. The results show misalignment between the agile principles and needs of pre-project activities in market-driven development. This misalignment threatens to subtract from the positive aspects of agile development, but maybe more importantly, threaten the overall product development by disabling effective product management. Copyright © 2009 John Wiley & Sons, Ltd.

An important task in Requirements Engineering is to select which requirements that should go into a specific release of a system. This is a complex decision that requires balancing multiple perspectives against each other. In this article we investigate what students imagine is important to professionals in requirements selection. The reason for this is to understand whether the students are able to picture what industry professionals value, and whether the courses allow them to picture the state of industry practice. The results indicate that students have a good understanding of the way industry acts in the context of requirements selection, and students may work well as subjects in empirical studies in this area.

Development of software product families relies heavily on the use of variability to manage the differences between products by delaying design decisions to later stages of the development and usage of the constructed software systems. Implementation of variability is not a trivial task, and is governed by a number of factors. In this paper, we describe the factors that are relevant in determining how to implement variability, and present a taxonomy of variability realization techniques. Copyright © 2005 John Wiley & Sons, Ltd.

To sustain the qualities of a software system during evolution, and to adapt the quality attributes as the requirements evolve, it is necessary to have a clear software architecture that is understood by all developers and to which all changes to the system adheres. This software architecture can be created beforehand, but must also be updated as the domain of the software, and hence the requirements on the software system evolve. Creating a software architecture for a system or part of a system so that the architecture fulfils the desired quality requirements is often hard. In this paper we propose a decision-support method to aid in the understanding of different architecture candidates for a software system. We propose a method that is adaptable with respect to both the set of potential architecture candidates and quality attributes relevant for the system's domain to help in this task. The method creates a support framework, using a multi-criteria decision method, supporting comparison of different software architecture candidates for a specific software quality attribute and vice versa, and then uses this support framework to reach a consensus on the benefits and liabilities of the different software architecture candidates and to increase the confidence in the resulting architecture decision.

To sustain the qualities of a software system during evolution, and to adapt the quality attributes as the requirements evolve, it is necessary to have a clear software architecture that is understood by all developers and to which all changes to the system adheres. This software architecture can be created beforehand, but must also be updated as the domain of the software, and hence the requirements on the software system evolves. Creating an architectural structure for a system or part of a system so that the architecture fulfils the desired quality requirements is often hard. In this paper we propose a decision support method to aid in the understanding of different architecture structure candidates for a software system. We propose a method that is adaptable with respect to both the set of potential architecture structures, and quality attributes relevant for the system's domain to help in this task. The method creates a support framework, using a multi-criteria decision method, supporting comparison of different software architecture structures for a specific software quality attribute and vice versa. Moreover, given a prioritization of quality attributes for the software system, or part thereof, the most suitable software architecture structure can be indicated using the created framework.

The authors discuss the notion of variability. We have experienced that this concept has so far been underdefined, although we have observed that variability techniques become increasingly important. A clear indication of this trend is the recent emergence of software product lines. Software product lines are large, industrial software systems intended to specialize into specific software products. The authors provide a framework of terminology and concepts regarding variability. In addition, they present three recurring patterns of variability. Finally, they suggest a method for managing variability in software product lines.

This paper discuss the results of two case studies from a technical perspective, concentrating on the evolution of software assets in two Swedish organizations that have employed a product-line architecture approach for several years. This paper describes and analyses the commonalities and differences of these two cases, emphasising categories of the evolution of the requirements, of the software architecture and of the software components. This paper concludes with three types of lessons learned about evolution in software product lines: three evolution categories are predominant, three other categories are less significant but still common, and seven guidelines for software product-line evolution emerge. Copyright © 1999 John Wiley & Sons, Ltd.