Rikard Land

COTS Selection Best Practices in Literature and in Industry

This paper presents an extensive literature survey of the software COTS component selection methods published to date, followed by a meta-model consolidating the activities and practices of these methods. Together with data collected from practitioners and researchers in the embedded systems domain, we provide concrete recommendations which will enable organizations to identify suitable practices when designing a customized selection processes.

Software systems integration and architectural analysis - a case study

Software systems no longer evolve as separate entities but are also integrated with each other. The purpose of integrating software systems can be to increase user-value or to decrease maintenance costs. Different approaches, one of which is software architectural analysis, can be used in the process of integration planning and design. This paper presents a case study in which three software systems were to be integrated. We show how architectural reasoning was used to design and compare integration alternatives. In particular, four different levels of the integration were discussed (interoperation, a so-called enterprise application integration, an integration based on a common data model, and a full integration). We also show how cost, time to delivery and maintainability of the integrated solution were estimated. On the basis of the case study, we analyze the advantages and limits of the architectural approach as such and conclude by outlining directions for future research: how to incorporate analysis of cost; time to delivery; and risk in architectural analysis, and how to make architectural analysis more suitable for comparing many aspects of many alternatives during development. Finally we outline the limitations of architectural analysis.

Customers' Role in Teaching Distributed Software Development

This paper describes different aspects of teaching distributed software development, regarding the types of project customers: industry and academia. These approaches enable students to be more engaged in real-world situations, by having customers from the industry, local or distributed customers in universities, distributed customers in software engineering contests or being involved in an ongoing project, thus simulating the company merging. The methods we describe are used in a distributed project-oriented course, which is jointly carried out by two universities from Sweden and Croatia. The paper presents our experiences of such projects being done during the course, the differences in each approach, issues observed and ways to solve them, in order to create a more engaging education for better-prepared engineers of tomorrow.

Migrating Industrial Systems towards Software Product Lines: Experiences and Observations through Case Studies

Software product line engineering has emerged as one of the dominant paradigms for developing variety of software products based on a shared platform and shared software artifacts. An important and challenging type of software maintenance and evolution is how to cost-effectively manage the migration of legacy systems towards product lines. This paper presents a structured migration method and describes our experiences in migrating industrial legacy systems into product lines. In addition, we present a number of specific recommendations for the transition process which will be of value to organizations that are considering a product line approach to their business. The recommendations cover four perspectives: business, organization, product development processes and technology.

Software systems in-house integration: Architecture, process practices, and strategy selection

As organizations merge or collaborate closely, an important question is how their existing software assets should be handled. If these previously separate organizations are in the same business domain - they might even have been competitors - it is likely that they have developed similar software systems. To rationalize, these existing software assets should be integrated, in the sense that similar features should be implemented only once. The integration can be achieved in different ways. Success of it involves properly managing challenges such as making as well founded decisions as early as possible, maintaining commitment within the organization, managing the complexities of distributed teams, and synchronizing the integration efforts with concurrent evolution of the existing systems. This paper presents a multiple case study involving nine cases of such in-house integration processes. Based both on positive and negative experiences of the cases, we pinpoint crucial issues to consider early in the process, and suggest a number of process practices.

Reuse with Software Components - A Survey of Industrial State of Practice

Software is often built from pre-existing, reusable components, but there is a lack of knowledge regarding how efficient this is in practice. In this paper we therefore present qualitative results from an industrial survey on current practices and preferences, highlighting differences and similarities between development with reusable components, development without reusable components, and development of components for reuse. Component reuse does happen, but the findings are still partly disappointing: currently, many potential benefits are not achieved. Still, the findings are encouraging: there are indeed good, reusable components properly verified and documented, and mature organizations who manage to reuse these components efficiently, e.g. by leveraging the previous component verification. We also find that replacing one component for another is not necessarily complicated and costly.

Using dependency model to support software architecture evolution

Evolution of software systems is characterized by inevitable changes of software and increasing software complexity, which in turn may lead to huge maintenance and development costs. For long-lived systems, there is a need to address and maintain evolvability (i.e. a systempsilas ability to easily accommodate changes) during the entire lifecycle. As designing software for ease of extension and contraction depends on how well the software structure is organized, this paper explores the relationships between evolvability, modularity and inter-module dependency. Through a case study of an industrial power control and protection system, we describe our work in managing its software architecture evolution, guided by the dependency analysis at the architectural level. The paper includes also the main analysis results, our experiences and reflections during the dependency analysis process in the case study.

Importance of Software Architecture during Release Planning

Release planning is the process of deciding what to include in future release(s) of a product. In this paper we look at how software architects are involved during release planning in industry today, and how architectural issues are considered during this phase.

Key Aspects of Software Release Planning in Industry

Software release planning is the process of deciding what to include in future release(s) of a product. Basically the problem can be seen as a company-wide optimization problem involving many stakeholders where the goal is to maximize utilization of the often limited resources of a company and turn them into business benefit. Saliu and Ruhe have proposed a set of key aspects for release planning methods, of which only a subset have been validated in industry. In this paper we use the Saliu and Ruhe key aspects as a starting point for identifying key aspects of release planning. To do this we have performed a multiple case study involving 7 international industrial companies, all producers of software intensive products. Our contribution is (1) a more strict meaning of a release planning key aspect, (2) validation of some of the aspects proposed by Saliu and Ruhe, and (3) an extension of the key aspects. We also capture state-of-the-practice for release planning in industry.

Reusable Component Analysis for Component-Based Embedded Real-Time Systems

Component-Based Software Engineering (CBSE) promises an improved ability to reuse software which would potentially decrease the development time while also improving the quality of the system, since the components are (re-)used by many. However, CBSE has not been as successful in the embedded systems domain as in the desktop domain, partly because requirements on embedded systems are stricter (e.g. requirements on safety, real-time and minimizing hardware resources). Moreover these requirements differ between industrial domains. Paradoxically, components should be context-unaware to be reusable at the same time as they should be context sensitive in order to be predictable and resource efficient. This seems to be a fundamental problem to overcome before the CBSE paradigm will be successful also in the embedded systems domain. Another problem is that some of the stricter requirements for embedded systems require certain analyses to be made, which may be very complicated and time-consuming for the system developer. This paper describes how one particular kind of analysis, of worst-case execution time, would fit into the CBSE development processes so that the component developer performs some analyses and presents the results in a form that is easily used for component and system verification during system development. This process model is not restricted to worst-case execution time analysis, but we believe other types of analyses could be performed in a similar way.