The First Software
Product Line
Conference
Technical Papers
(Authors and Abstracts)
This material is being posted by Carnegie Mellon University's Software Engineering Institute (SEI) on this Web site as a community service.
The First Software
|
|
The following information provides the title, author(s), and abstract of each of the 27 technical papers accepted for The First Software Product Line Conference. Papers are alphabetically listed based on first author.
Pierre America1, Henk Obbink1, Rob van
Ommering1, and Frank van der
Linden2
1Philips Research, Prof. Holstlaan 5656 AA,
Eindhoven, The Netherlands
2Philips Medical Systems, Veenpluis
4–6, 5684 PC Best, The Netherlands
{pierre.america, henk.obbink,
rob.van.ommering, frank.van.der.linden}@philips.com
Abstract: In this paper we describe a family of methods that enable the development of product family architectures. These methods have in common that they offer support in developing a family of software-intensive products on the basis of one or more common platforms, that they use component technology to build the platforms and the products, and that they use several well-defined software development processes. The methods differ in many important decisions regarding processes and architecture, which are tuned carefully to the business and organizational context. In this way the method family establishes a significant synergy in the development of several product families in a large and diverse industrial company.
Mark Ardis, Peter Dudak, Liz Dor, Wen-jenq Leu, Lloyd Nakatani, Bob
Olsen, and Paul Pontrelli
Lucent Technologies
{maa, pddudak, dor,
wleu, lhn, rgo, pontrelli}@lucent.com
Abstract: This paper describes the experiences of a small team of domain experts in re-engineering the configuration control software for the 5ESS® switch. The project consisted of three main phases: discovery, design, and deployment. During the discovery phase the team conducted a domain analysis of configuration control software. In the design phase the team created domain-specific languages and supporting tools. The deployment phase consisted of trial use and modification in response to feedback from users. Lessons learned during each of these phases are summarized.
Colin Atkinson, Joachim Bayer, and Dirk Muthig
Fraunhofer
Institute for Experimental Software Engineering (IESE), Sauerwiesen 6,
D-67661 Kaiserslautern, Germany
{atkinson, bayer,
muthig}@iese.fhg.de
Abstract: The product line and component-based approaches to software engineering both hold the potential to significantly increase the level of reuse in industrial software development and maintenance. They also have complementary strengths, since they address the problem of reuse at opposite ends of the granularity spectrum—product line development essentially supports "reuse in the large" while component based development supports "reuse in the small." This paper describes a method, KobrA, which cleanly integrates the two paradigms into a systematic, unified approach to software development and maintenance. Key synergies resulting from this integration include support for the rapid and flexible instantiation of system variants, and the provision of methodological support for component-based framework development.
Don Batory1, Rich Cardone1, and Yannis
Smaragdakis2
1Department of Computer Sciences, The
University of Texas, Austin, Texas 78712
2College of Computing,
Georgia Institute of Technology, Atlanta, Georgia 30332
{batory,
richcar}@cs.utexas.edu, yannis@cc.gatech.edu
Abstract: Frameworks are a common object-oriented code-structuring technique that is used in application product lines. A framework is a set of abstract classes that embody an abstract design; a framework instance is a set of concrete classes that subclass abstract classes to provide an executable subsystem. Frameworks are designed for reuse: abstract classes encapsulate common code and concrete classes encapsulate instance-specific code. Unfortunately, this delineation of reusable vs. instance-specific code is problematic. Concrete classes of different framework instances can have much in common and there can be variations in abstract classes, all of which lead to unnecessary code replication. In this paper, we show how to overcome these limitations by decomposing frameworks and framework instances into primitive and reusable components. Doing so reduces code replication and creates a component-based product line of frameworks and framework instances.
Günter Böckle
Siemens AG, Corporate Technology, D-81730
Munich, Germany
Guenter.Boeckle@mchp.siemens.de
Abstract: Product line engineering is a major approach for developing products with many variants, or for a collection of products sharing a common set of reusable assets where a short time to market is needed or where the reuse of tested assets brings significant savings in development time and product quality. Requirements engineering is an important part of software and systems engineering but it needs some specific support for its application in product line engineering. Tracing differences of the requirements for different products of the family to different architecture instantiations and different component variants and to the corresponding design decisions on a requirements model can reduce development time significantly. Requirements engineering is used in both domain engineering and application engineering. A good requirements model can support major parts of both, such as commonality analysis and tracing of connections between requirements, architecture, components, and tests. This paper presents our approach for a requirements engineering model, as well as showing how working groups can work in parallel on products of the product family.
Michel Coriat1, Jean Jourdan1, and Fabien
Boisbourdin2
LCAT (Alcatel / Thomson-CSF Common Research
Laboratory)
1Thomson-CSF / LCR
2Alcatel /
CRC
Domaine de Corbeville - 91404 Orsay Cedex - France
{michel.coriat,
jean.jourdan, fabien.boisbourdin}@lcr.thomson-csf.com
Abstract: This paper presents SPLIT (Software Product Line Integrated Technology), an experimental method that helps Thomson-CSF and Alcatel to define and build product lines. SPLIT is organized as a global framework to help engineer product lines of software intensive systems. In this context the paper focuses on three themes: product line requirements (Cloud), product line architecture (Daisy), and product line process (Wheel). Although SPLIT proposes models independently of the notation used for their description, in this paper we have illustrated the approach by the use of the unified modeling language (UML).
James C. Dager
Cummins Engine Company
Jim.C.Dager@Cummins.com
Abstract: Over six years ago, Cummins Engine Company established a software product line for its real-time embedded diesel engine controls. The engine controls product line requirements domain is very complex. As the world's largest manufacturer of diesel engines over 200 horsepower, Cummins makes engines for a large, world-wide variety of applications, customers, original equipment manufacturers (OEM's), engine sizes, and engine configurations. Cummins' software product line program slashed development costs and cycle time across these highly varying products, and resulted in many successful product launches over the past four years. Over these years, Cummins has gained a great deal of experience and has crossed many hurdles in establishing its product line architecture. This paper describes Cummins’ experiences developing, documenting and maintaining a software product line architecture. The paper focuses on the development process and covers topics such as domain analysis, architectural views, and use of Software Engineering Institute (SEI) practices and literature to guide Cummins’ development approach. Also described are the architecture development process, the organizational challenges faced, and the lessons learned over this 6-year development window.
Bryan S. Doerr and David Sharp
The Boeing Company, St. Louis,
MO
{bryan.s.doerr, david.sharp}@boeing.com
Abstract: Product line software architectures and supporting components are the focus of an increasing number of software organizations attempting to reduce software costs. One essential attribute of a product line architecture is that it effectively isolate the logical, or static, aspects of the application from any product-specific variations in the physical architecture, or execution environment. A primary element of this isolation is hardware and low-level software (e.g., operating system) independence. The focus of this paper is on the various ways physical architecture attributes can be designed for flexibility without introducing volatility into the application architecture.
Stuart R. Faulk1, Robert R. Harmon2, and David M.
Raffo2
1University of
Oregon
2Portland State University
faulk@cs.uoregon.edu,
{roberth, davidr}@sba.pdx.edu
Abstract: We consider a set of programs a family when it pays to look at their common aspects before looking at their differences. For commercial software developers the implications are twofold: First, making rational decisions about product-line processes and products requires the ability to answer the question: "Does it pay?" Second, whether or not something pays is ultimately a business (rather than software engineering) question. In short, making sound software engineering decisions requires understanding the business implications of those decisions, and vice versa. This paper describes work in progress to develop a product-line process model and common value metric that adequately link product value drivers (what it pays) with the software engineering decisions that affect those drivers. In it, we describe a systematic approach to quantifying the return for both product and process improvements based on common software engineering principles and a common value metric, customer value.
Martin L. Griss
Hewlett-Packard Company, Laboratories, Palo Alto,
CA, USA
griss@hpl.hp.com
Abstract: Emerging e-commerce systems are highly dynamic and require even more flexibility and reduced time to market than that traditionally provided by product-line development and component-based software engineering (CBSE). In this paper we describe our work on agent-based, product-line CBSE for flexible e-commerce systems. We are integrating several technologies for product-line analysis and component design, implementation, and customization to create a basis for systematic product-line development. Largely independent work on reuse ("domain analysis") and object-oriented technology ("design and code") has matured to the degree that integration of the techniques promises a coherent approach. We outline a practical development process that structures a set of common and variable features supporting a product line, to produce reusable elements ("aspects"). These aspects can be combined into customized components and frameworks to support the product line.
Andreas Hein, Michael Schlick, and Renato Vinga-Martins
Robert
Bosch GmbH, Corporate Research and Development – FV/SLD
P.O. Box 90 01
69, D-60441 Frankfurt am Main – Germany
{andreas.hein1,michael.schlick}@de.bosch.com
Abstract: A software product line is a collection of products sharing a common set of features that address the specific needs of a given business. The PRAISE project, partly funded by the European Commission under ESPRIT contract 28651 and pursued by Thomson-CSF/LCR (France), Robert Bosch GmbH (Germany), and the European Software Institute (Spain), is currently investigating product-line realization and its assessment in industrial settings. A part of the project is dedicated to the validation and consolidation of proposed product-line technologies in real-world industrial experiments. This paper presents the first experimental results obtained by Bosch. The Bosch experiment is located in the Car Periphery Supervision (CPS) domain. One focus has been on feasibility of variability modelling with feature-oriented domain analysis (FODA. The experiment has shown that the FODA model does not provide the necessary expressiveness to represent the different types of crosslinks that are necessary to describe the domain. This paper presents an extension to overcome this shortcoming.
H. James Hoover1, Tony Olekshy2, Garry
Froehlich1, and Paul Sorenson1
1Dept. of
Computing Science, University of Alberta, Edmonton, Alberta
2Avra Software Lab, Inc., Edmonton, Alberta.
{hoover, garry,
sorenson}@cs.ualberta.ca, olekshy@avrasoft.com
Abstract: Product line developers have two primary problems to solve: keeping their applications relevant to the associated manufactured product line, and evolving their applications to exploit new information technologies. This paper reports on our experience in developing commercial applications for engineered product manufacturers. High quality object-oriented frameworks with good factoring into services are crucial to addressing both of these issues. We have also learned that it is not sufficient to develop frameworks that address only the development of the application. They must also support other parts of the process: from production of documentation, through help desk integration, to defect tracking and resolution. This work also contains a catalogue of best practices and advanced features that we believe will be valuable to other builders of engineering tools.
Tomoji Kishi and Natsuko Noda
Software Design Laboratories, NEC
Corporation,Tokyo, Japan
{kishi, n-noda}@ccs.mt.nec.co.jp
Abstract: In designing a product-line architecture (PLA), it is important to analyze common and variable requirements in a product family. These requirements must be analyzed not only from the functional aspect but also from aspects related to quality attributes such as performance and reliability. For example, if two products are required to attain different levels of performance, architectures for these products may be different even if they provide the same functionality. In this paper, we propose an aspect-oriented analysis method for PLA design in which we analyze product requirements from each aspect separately. In the method, we identify important factors for each quality attribute, and characterize the services in terms of the factors. Based on the characterization, we separate requirements related to each quality attribute from the original requirements. Using the method, we can examine the architecture styles required for a PLA from each aspect, which can make PLA design easier.
Kwanwoo Lee1, Kyo C. Kang1, Eunman
Koh2, Wonsuk Chae1, Bokyoung Kim1, and Byoung
Wook Choi3
1Department of Computer Science and
Engineering, Pohang University of Science and Technology (POSTECH) San 31
Pohang Kyoungbuk 790-784, Korea
2Department of Computer and
Communications Engineering, Graduate School for Information Technology,
POSTECH. Also affiliated with LG Industrial Systems Co., Ltd.
3Division of Mechanical and Control Engineering, Sunmoon University;
work also done at LG Industrial Systems Co., Ltd.
{kwlee, kck, emkoh,
sein92, bogus}@postech.ac.kr, bwchoi@mail.lgis.co.kr
Abstract: Development and maintenance of embedded control software has been a difficult challenge for the manufacturing industry because of the diversity of customers’ needs, rapidly changing market requirements, and the quick response of market competition. In order to retain a market share in a competitive market, embedded control software must be designed to respond quickly to both the customer and the market, and be of high quality. LG Industrial Systems Co. Ltd. (LGIS), one of Korea’s leading suppliers of elevator control systems, has also been faced with the same difficulty in the development and maintenance of elevator control software (ECS). In order to help LGIS improve the productivity and maintainability as well as the quality of its ECS, we have adopted a domain-oriented approach for reuse, and verification and validation technology for improving software quality. We have found that we can reduce maintenance costs drastically as we have developed the software by utilizing reusable and adaptable components that can easily accommodate contextual as well as requirement changes, and have verified and validated ECS in the early phase of development.
Yoshitomi Morisawa
Nihon Unisys, Ltd., Tokyo, Japan; Graduate
School of Information Science, Nara Institute of Science and Technology, Nara,
Japan
Yoshitomi.Morisawa@unisys.co.jp
Abstract: When implementing an application system in a distributed computing environment, several architectural questions arise, such as how and where computing resources are distributed, and how the communication among computing resources should be implemented. To simplify the process of making these choices, we have developed a distributed computing model. The model classifies product lines for distributed processing systems into seven categories based on the location of data storage and the style of processing between client and server. This paper describes our model and its uses in selecting a product set in a kernel reference model of the Open Solution Framework and in planning the infrastructure of a new system for one of our customers.
Alessandro Pasetti and Wolfgang Pree
Faculty of Computer Science,
University of Constance, D-78457, Constance, Germany
pasetti@fmi.uni-konstanz.de, pree@acm.org
Abstract: Framelets and implementation cases are new concepts to manage the complexity of product line development. Framelets are "small product lines" that address, as self-standing units, specific problems within the product line. A product line is obtained as a combination of framelets. Framelets simplify the development and extension of product lines, and make their integration with other product lines and with other software simpler. Implementation cases are introduced as ways to continuously monitor the adequacy of an evolving product line design. They describe an aspect of the product line instantiation process by specifying how an architectural feature for an application can be implemented using the constructs offered by the product line. This paper discusses the two concepts in the context of the design of a product line of on-board satellite software. Heuristics for defining framelets and implementation cases derived from the experience are also discussed.
B.J. Pronk
Philips Medical Systems
ben.pronk@philips.com
Abstract: In the medical imaging domain the market pressure and increased software content of products form the driving force for the introduction of product line architectures. This paper describes a new product line architecture that is based upon a generic platform that can only be varied through well-defined interfaces. It explains the rationale behind this approach and elaborates on the experiences so far. The paper gives a short overview of the architectural requirements for the product line and the methodology followed. The focus is on the actual platform architecture and its technical implementation.
Stephen R. Schach1 and Amir
Tomer2
1Vanderbilt University, Nashville, TN,
USA
2RAFAEL, Haifa, Israel
srs@vuse.vanderbilt.edu,
tomera@rafael.co.il
Abstract: The evolution tree model is a two-dimensional model that describes how the versions of the artifacts of a software product evolve. The propagation graph is a data structure that can be used for effective control of the evolution of the artifacts of a software product. In this paper we extend the evolution tree model and propagation graph to handle the evolution of a software product line. Software product lines are characterized by large-scale reuse, especially of core assets. We show how a third dimension can be added to the evolution tree model to handle this reuse. In particular, the new model incorporates bidirectional reuse within product lines. That is, the new model can handle the transfer of an artifact from the core assets repository to a specific product (acquiring a core asset), as well as the transfer of a specific asset from a specific product to the core assets repository (mining an existing asset).
Klaus Schmid
Fraunhofer Institute for Experimental Software
Engineering (IESE), Sauerwiesen 6,
D-67661 Kaiserslautern, Germany
Klaus.Schmid@iese.fhg.de
Abstract: Software product line development is a rather new topic area within domain-specific software engineering that builds on previous work in domain engineering. A crucial step in developing a product line is the scoping step, which aims at determining the boundaries for the product line. This is one of the core planning activities that may determine the success or failure of the whole product line effort. In this paper, we seek to analyze the existing body of knowledge on product line scoping. As the relationship to domain engineering is very close we will also include domain scoping approaches in our analysis. Further, we will look at product line scoping related activities in other fields of study besides software engineering. As a result of this survey we provide a taxonomy of existing approaches both on a problem level, as well as on a solution level, discuss the relative advantages of the various approaches, and show some ways on using the results of this paper for enhancing existing scoping approaches and developing new approaches.
David C. Sharp
The Boeing Company, St. Louis, MO
david.sharp@boeing.com
Abstract: Just as hardware integrated circuits, or components, can be used to inexpensively manufacture a product line of related hardware systems, re-usable software components can be used to create software systems. This is accomplished by developing a common framework for a product line of related software systems that forms the component operating environment. A development architecture is presented based on our work using object-oriented analysis and design techniques to create reusable software components that combine with aircraft specific customizations to form an avionics software system.
Douglas Stuart, Wonhee Sull, Steve Pruitt, Deborah Cobb, Fred
Waskiewicz, and T. W. Cook
Microelectronics and Computer Technology
Corporation
stuart@mcc.com, sull@sktelecom.com, pruitt@mcc.com,
cobb_deborah@hotmail.com, wask@austin.rr.com, tw@acm.org
Abstract: In this paper, we describe the SSEP (Software and Systems Engineering Productivity) product line development toolset that was created to provide the tool support necessary to improve the viability of product line development. Navigation between the various artifacts that arise during architecture-based product line development is crucial to successful product line development. The SSEP toolset was developed with such navigation, provided by using XML as a representation mechanism, as a key feature. The goals of product line development are achieved through planned reuse of product line artifacts in multiple applications in the product line. Such strategic reuse depends on the application engineer’s being able to develop the application within the context of the product line, which requires access to product line artifacts in their context. Such in-context access can only be provided by links capturing the dependence relationships between product line artifacts. The SSEP toolset provides such access.
Steffen Thiel1 and Fabio
Peruzzi2
1Software Technology Center, Corporate
Research and Development, Robert Bosch GmbH, Germany
2B4E GmbH,
Germany
steffen.thiel@de.bosch.com
Abstract: At the present time, systems for the automotive market are typically developed independently from each other. The resulting systems are closed systems in the sense that they are built to perform specific operations but nothing more. Interoperability between those systems is difficult to establish. The need for a more integrated, software-based development approach is changing the way these systems are designed. Many car manufacturers and system providers are moving in this direction and it is broadly accepted that this paradigm shift in the development of automotive systems will be reflected in a very interesting new market. So far this market is an envisioned market, and specific products have not yet been developed. This paper describes a part of the process defined during the initiative undertaken by Robert Bosch GmbH and the Software Engineering Institute of Carnegie Mellon University to instantiate a product line for innovative automotive systems. The process steps described in this report specifically deal with the early phases of product line development. In particular, the experience gathered from defining and applying product line analysis and design in the domain of automotive systems is described.
Peter Toft, Derek Coleman, and Joni Ohta
Product Generation
Consulting, Hewlett-Packard, Palo Alto, USA
peter@tofty.com,
{derek_coleman, joni_ohta}@hp.com
Abstract: Organizations developing software for families of related products must meet the challenge of leveraging software development effort across the product families, while still allowing individual product teams to focus on developing their specific products. This can be a tough balancing act: too much centralization can result in slow decision making, increased time to market and conflict between product teams. Too little centralization can waste opportunities for leverage and can increase redundant and incompatible development. In this paper we explore an approach that is very similar to the traditional notion of cooperative organizations. We show how product teams are organized into a software cooperative, and examine the key roles that support this organizational model. We reason about why this model is successful. We also show how this organizational model is facilitated by an explicit software architecture, and by a specific software configuration management approach.
Jay van Zyl1 and A.J.
Walker2
1Rubico, Johannesburg, South Africa &
California, U.S.A.
2Software Engineering Applications
Laboratory, Electrical Engineering,University of the Witwatersrand,
Johannesburg, South Africa
jay@rubico.com, walker@seal.ac.za
Abstract: Product strategists are faced with difficult, but challenging tasks when it comes to product innovation, concept development and product commercialization. Product innovation must take place in order to create products and services that potential customers do not yet know they need. Different, but integrated, standards are needed in the pursuit of building capable processes for delivering these products. Strategic Product Development is an approach that uses a number of industry standards in building an organization capable of delivering commercially successful products. This paper presents an overview of the integrated approach that ties many concepts together in assisting the product development team to deliver world-class software products. Rubico Technologies is used as a case study to show how the concepts were implemented.
Thomas Wappler
IBM Consulting Group, IBM Unternehmensberatung
GmbH, Am Fichtenberg 1, D-71083 Herrenberg, Germany
wappler@de.ibm.com
Abstract: The concept of a software product line developed by the Software Engineering Institute is a comprehensive model for an organization building applications based on common architectures and other core assets. In a transition project for launching and institutionalizing a software product line we need to address virtually all areas of a software development organization. Such a transition project will be very difficult and there is usually very little experience in the organization in running such a project successfully. This paper discusses four factors that are essential for the transition project’s success. These factors are a clearly defined goal, strong project management, strong management support and pilot projects. Although these factors seem to be very basic, experience shows that they are often neglected. In this paper we will show why they are essential for a successful transition project.
William G. Wood
Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, PA 15213
wgw@sei.cmu.edu
Abstract: Government agencies often acquire large-scale software-intensive systems to be installed in many sites widely distributed across the country. These are often single-baseline systems that must be tailored to the particular environment of a site to allow for variations in both physical and functional configurations. For example, the Federal Aviation Administration (FAA) may acquire a single display system that can be installed in all en-route Air Traffic Control Centers (ARTCCS). Such systems often take a long time to develop and a significant time period to distribute to the sites; by the time the installations are completed, the system components are close to or past obsolescence since technology is continuously evolving. This inevitably leads to a future "big bang" acquisition. This paper proposes that these problems can be resolved by considering the systems to be a product line that evolves incrementally, with new technology and functionality added over the lifetime of the product line. In this way the systems will remain state-of-the-shelf and avoid a future "big bang" acquisition.
Sherif Yacoub1, Ali Mili1, Chakri
Kaveri1, and Mark Dehlin2
1Department of
CSEE, West Virginia University, Morgantown, WV
2The National
Product Line Asset Center 1000 Technology Drive, Fairmont, WV
{yacoub,
amili, kaveri}@csee.wvu.edu, dehlin@nplace.wvhtf.org
Abstract: At the same time as we recognize that generic forms of software reuse have fallen short of their expectations (in terms of gains in process productivity, product quality, and time to market), we also find that specialized forms of software reuse, such as commercial-off-the-shelf (COTS) based development and product-line engineering (PLE), have a great deal of potential in practice. To reap the benefits of practicing these two specialized forms of software reuse, COTS components can be used in product lines to streamline the development process. However, acquiring commercial components for a product line carries several risks. Testing and certification techniques are essentially required to assess the suitability of a COTS component for integration in a product-line architecture. The National Product Line Asset Center (NPLACE) is confronted with the problem of developing certification and suitability testing criteria for several COTS components in the market. In this paper, we develop a hierarchical reference model to guide the development of COTS certification criteria. We use an example of a database management system (DBMS) to illustrate the applicability of the model.