The Third Software
|
|
|
|
|
Governing Software Product Lines and Reorganizations
Truman Jolley, Boeing
Commercial Airplanes
David
Kasik, Boeing Commercial Airplanes
Tammy Ben, Boeing Commercial
Airplanes
It's a fact of life that organizations love to reorganize. Reorganizations have a profound effect on the way product lines are governed. We introduce the concept of the Responsibility, Authority, and Accountability (RAA) network. An RAA network assists in the governance process of product lines for internal information systems, even in the face of massive reorganization. Armour ("Reorg Cycle") describes the pressures of reorganization to balance the "dimensions of organization" (e.g., geography, customers, product technology); we apply polarity management to balance the dimensions. Armour describes the difficulty of applying hierarchical organization charts"single dimension management structures"to the above "multidimensional environments"; we apply lean RAA networks to span organization charts and provide the multidimensional view needed for product lines. Armour observes that network organization approaches "do not have a good track record"; our experience is that lean, resilient RAA networks document the product line's governance architecture. These governance architecture patterns are applied repeatedly to the strata of products in the product line. We present the governance architect's RAA to define, monitor, and sustain governance health using these tools: polarity maps, polarity networks, RAA maps, and RAA networks.
Software Product Line Support in Coremetrics OA2004
James Snyder, Coremetrics,
Inc.
Harry Lai, Coremetrics,
Inc.
Shirish Reddy, Coremetrics,
Inc.
Jimmy Wan, Coremetrics,
Inc.
We present the transformation of the Coremetrics analytic application software engineering approaches from a traditional Java 2 Enterprise Edition (J2EE) environment to a software product line approach. Particular emphasis is placed on the motivation for a product line approach and the software engineering challenges faced particularly as an application service provider. We also discuss our definitions of product line variation and binding, and how we provide tool support using the open source Integrated Development Environment Eclipse. We also provide our observations about the software product line approach, how our work and findings relate to other work in this area, and lastly, how configuration management plays an integral and complementary role in our approach.
Introducing Product Line Approach at Bosch Gasoline Systems: Experiences and Practices
Mirjam Steger, Robert
Bosch GmbH
Christian
Tischer, Robert Bosch GmbH
Wolfgang Stolz, Robert Bosch GmbH
Stefan Ferber, Robert Bosch
GmbH
Software engineering in the automotive domain faces outstanding challenges in terms of quality, cost, and functional complexity. To ensure process and product excellence, Bosch Gasoline Systems (GS) introduced a process improvement program based on Capability Maturity Model Integration (CMMI) and adopted the product line approach (PLA). Business strategies for software products, software sharing with customers, and common solutions for diesel and gasoline engine control software are inputs for the product line architecture. The steps towards the PLA started with an evaluation project followed by an evolutionary rollout. The lack of suitable mechanisms and tools for some crucial nonfunctional requirements is a major drawback for introducing the PLA. Nevertheless, GS considers it the only systematic approach to dealing with current and future challenges.
Four Mechanisms for Adaptable Systems A Meta-Level Approach to Building a Software Product Line
Claudia Fritsch,
Robert Bosch GmbH
Burkhardt Renz, University
of Applied Sciences Giessen-Friedberg
For more than ten years, we have developed and maintained a software product line of legal expert systems. They share certain functionality, such as interaction with the user by means of a graphical interface, capturing data, storing information in a database, and printing documents. They differ mainly in two areas: domain description and technical infrastructure.
When we designed the architecture for this software product line, we focused on two requirements in particular:
Using a meta-level architecture, we achieved a sound decoupling: Domain descriptions are kept in the meta level. Appropriate engines included in the base level act according to these descriptions.
We present the four meta-level mechanisms that we have developed for the design of this software product line. They separate domain descriptions from technical code in the following areas:
Automatic Generation of Program Families by Model Restrictions
Andrzej Wasowski, IT University of Copenhagen
We study the generative development of control programs for families of embedded devices. A software family is described by a single common model and restriction specifications for each of the family members. The model and the specifications are used in the automatic generation of restricted programs. We describe an application of the process of modeling reactive systems with statecharts. A trace inclusion refinement relation is established for automatically generated family members, inducing a behavioral inheritance hierarchy over the generated programs.
Software Product Lines in ArchJava
Sebastian Pavel, Ecole des
Mines de Nantes
Jacques
Noyé, Ecole des Mines de Nantes
Jean-Claude Royer, Ecole des Mines
de Nantes
This paper considers the use of a state-of-the-art, general-purpose, component-programming language, specifically ArchJava, to implement software product lines. Component-programming languages provide a more straightforward mapping between components as assets and components as implementation artifacts. However, guaranteeing that the implementation conforms to the architecture raises new issues with respect to dynamic configuration. We show how this can be solved in ArchJava by making the components auto-configurable, which corresponds to replacing components by component generators. Such a scheme can be implemented in various ways, in particular with a two-stage generator. This solution goes beyond the initial technical ArchJava issue and complements the standard static generative approach to software product line implementation.
Software Product Family Evaluation
Frank van der
Linden, Philips Medical Systems
Jan
Bosch, University of Groningen
Erik Kamsties, University of
Duisburg-Essen
Kari
Känsälä, Nokia Research Center
Henk Obbink, Philips Research
Laboratories
This paper proposes a four-dimensional evaluation framework for software product family engineering. The four dimensions relate to the software engineering concerns of business, architecture, organisation, and process. The evaluation framework is intended for use within software developing organisa-tions to determine the status of their own software product family engineering and the priorities for improving. The results of the evaluation can be used for benchmarking, roadmapping, and developing improvement plans. An initial evaluation of a real industrial case is presented to show the validity of the framework.
Practical Evaluation of Software Product Family Architectures
Eila Niemelä, VTT
Technical Research Centre of Finland
Mari Matinlassi, VTT Technical
Research Centre of Finland
Anne
Taulavuori, VTT Technical Research Centre of Finland
Faster time to market and decreased development and maintenance costs are goals most companies are trying to reach. Product family engineering (PFE) provides a means of achieving these goals. Product family architecture (PFA) is the key issue in family engineering. However, companies have to decide how to adopt PFE and how to develop their software PFA. This paper introduces the basic issues essential to PFA development, explores three different approaches to applying PFAs in industrial settings, and, finally, presents the evaluation results through an evaluation model of software product families.
On the Development of Software Product-Family Components
Jan Bosch, University of Groningen
Several approaches to the development of shared artefacts in software product families exist. Each has advantages and disadvantages, but there is no clear framework for selecting among these alternatives. As a consequence, mismatches between the optimal approach and the one currently used by an organization may lead to several problems, such as a high degree of erosion, mismatches between product needs and shared components, organizational "noise" and inefficient knowledge management. This paper (1) presents the problems resulting from the aforementioned mismatch, (2) presents the relevant decision dimensions that define the space of alternatives, (3) discusses the advantages and disadvantages of each alternative and (4) presents a framework for selecting the best alternative for each decision dimension based on a three-stage adoption model.
Experiences in Software Product Families: Problems and Issues during Product Derivation
Sybren Deelstra, University
of Groningen
Marco Sinnema,
University of Groningen
Jan Bosch,
University of Groningen
A fundamental reason for investing in product families is to minimize the application engineering costs. Several organizations that employ product families, however, are becoming increasingly aware of the fact that, despite the efforts in domain engineering, deriving individual products from their shared software assets is a time- and effort-consuming activity. In this paper, we present a collection of product derivation problems that we identified during a case study at two large and mature industrial organizations. These problems are attributed to the lack of methodological support for application engineering, and to underlying causes of complexity and implicit properties. For each problem, we provide a description and an example, while for each cause we present a description, consequences, solutions, and research issues. The discussions in this paper are relevant outside the context of the two companies, as the challenges they face arise in, for example, comparable or less mature organizations.
A Feature-Based Approach to Product Line Production Planning
Jaejoon Lee, Pohang University
of Science and Technology
Kyo Kang,
Pohang University of Science and Technology
Sajoong Kim, Korea IT Industry Promotion
Agency
A production plan, which describes how core assets are used to develop products, has an important role in product line engineering as a communications medium between core asset developers and product developers. Recently, there have been efforts to address issues related to production planning, most of which focus on the process and business/management aspects of production planning; not much emphasis is given to technical issues such as deciding which features will be made as core assets and what their granularity will be. In this paper, we introduce a feature-based approach to product line production planning and illustrate how our approach addresses these technical issues. In our approach, a feature model and feature-binding information are used as primary input to production plan development. A product line production plan created using our approach could be customized easily to a product-specific production plan, because when we developed the approach, we considered units of product configurations as well as their integration techniques.
COVAMOF: A Framework for Modeling Variability in Software Product Families
Marco Sinnema, University of
Groningen
Sybren Deelstra,
University of Groningen
Jos
Nijhuis, University of Groningen
Jan
Bosch, University of Groningen
A key aspect of variability management in software product families is the explicit representation of the variability. Experiences at several industrial software development companies have shown that a software variability model should do four things: (1) uniformly represent variation points as first-class entities in all abstraction layers (ranging from features to code), (2) allow for the hierarchical organization of the variability, (3) allow for the first-class representation of simple (i.e., one-to-one) and complex (i.e., n-to-m) dependencies, and (4) allow for modeling the relations between dependencies. Existing variability modeling approaches support the first two requirements, but lack support for the latter two. The contribution of this paper is a framework for variability modelingCOVAMOFthat provides support for all four requirements.
Observations from the Recovery of a Software Product Family
Patricia Lago, Vrije
Universiteit
Hans van Vliet, Vrije
Universiteit
The problem of managing the evolution of complex and large software systems is well known. Evolution implies the reuse and modification of existing software artifacts, and this means that the related knowledge must be documented and maintained.
This paper focuses on the evolution of software product families, although the same principles apply in other software development environments as well. We describe our experience gained in a case study recovering a family of six software products. We give an overview of the case study, and provide lessons learned, implicit assumptions reconstructed during the case study, and some rules we think are generally applicable. Our experience indicates that organizing architectural knowledge is a difficult task. To properly serve the various uses of this knowledge, it needs to be organized along different dimensions and tools are required. Our experience also indicates that, next to variability explicitly designed into the product family, a ``variation creep'' is caused by different, and evolving, technical and organizational environments of the products. We propose explicitly modeling invariabilities, next to variabilities, in software product lines to get a better grip on this variation creep.
Product Line Potential Analysis
Claudia Fritsch,
Robert Bosch GmbH
Ralf Hahn,
Robert Bosch GmbH
A Product Line Potential Analysis (PLPA)enables us to make a quick decision as to whether the product line approach (PLA) is suitable for a given set of products and target market. The PLA framework offers no support for this as yet.
A PLPA is executed in a half-day workshop. A structured interview based on a questionnaire examines products, software, markets, and customers. The answers are compared to a set of criteria for the applicability of the PLA. The analysis results primarily in the decisions: "yes" (the PLA is suitable for these products and markets), "no", or "investigation required". Up to now our team has performed four PLPAs.
We present the list of criteria, a part of our questionnaire, and the workshop format. We discuss the PLPA in the light of related work and its limits and lessons learned, and we look at future work.
Generalized Release Planning for Product-line Architectures
Louis Taborda, Macquarie Graduate School of Management
This paper elaborates on the coordination and management of evolving software product lines, where development teams work around a shared and reusable domain infrastructure. The trend away from monolithic applications and towards component-based, product line architectures has enabled the de-velopment of complex software to be undertaken by autonomous and often, geographically separated teams. Delivering a complete product or product line requires significant coordination to bring the separate development streams to-gether, at agreed-upon points in the schedule, for integration and test. In such complex development scenarios, a Release Matrix has been proposed as a gen-eralization of release planning and tracking, addressing multiple products, com-ponents, and their interdependencies at an enterprise or marketplace level. Here, we describe the results of the practical trials of the Release Matrix that provide pragmatic guidelines for its use and indicate areas for future research. Relation-ships to established processes, including requirements engineering and configu-ration management, are clarified, and the methodology-neutral technique is shown to complement work in areas, including Agile Methods and component contracts.
A Methodology for the Derivation and Verification of Use Cases for Product Lines
Alessandro Fantechi,
University of Florence
Stefania
Gnesi, I.S.T.I. - C.N.R.
Giuseppe Lami, I.S.T.I. -
C.N.R.
Emiliano Nesti,
University of Florence
In this paper, we present a methodology to express, in a formal way, the requirements of products belonging to a product line. We relied on a formalism allowing the representation of variabilities at the family level and the instantiation of them in order to move to the requirements of a single product. The proposed methodology also allows the formalization of the family constraints to be taken into account for the construction of the products belonging to it, along with the verification of the compliance to those constraints of a single product requirements document. This approach is promising due to its simplicity and effectiveness for being supported by automatic tools.
Staged Configuration Using Feature Models
Krzysztof Czarnecki, University
of Waterloo
Simon Helsen,
University of Waterloo
Ulrich
Eisenecker, University of Applied Sciences Kaiserslautern
Feature modeling is an important approach to capturing commonalities and variabilities in system families and product lines. In this paper, we propose a cardinality-based notation for feature modeling, which integrates a number of existing extensions of previous approaches. We then introduce and motivate the novel concept of staged configuration. Staged configuration can be achieved by the stepwise specialization of feature models. This is important because in a realistic development process, different groups and different people eliminate product variability in different stages. We also indicate how cardinality-based feature models and their specialization can be given a precise formal semantics.
Scenario-Based Decision Making for Architectural Variability in Product Families
Pierre America, Philips
Research
Dieter Hammer, Technical
University Eindhoven
Mugurel Ionita,
Technical University Eindhoven
Henk
Obbink, Philips Research
Eelco
Rommes, Philips Research
In this paper, we present a systematic approach towards decision making for variability in product families in the context of uncertainty. Our approach consists of the following ingredients: a suitable set of architectural views that bridge the gap between customer needs and available technology, a multi-view variation modeling technique, the selection of several scenarios of different kinds, and a quantitative analysis of quality aspects for these scenarios.