Successful Product Line Engineering Requires More Than Reuse

Paul C. Clements

Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213
Tel: (512) 453-1471
Email: clements@sei.cmu.edu.


Abstract

This paper describes the experience of one company that successfully has implemented a product line approach to the construction of large, complex, software- intensive systems. Their experience shows that the technical factors enabling systematic, planned reuse are necessary, but not sufficient for success. Organizational, process, and business factors are equally important.

Keywords: product lines, software architecture, software reuse, program families.

Workshop Goals: To explore those necessary aspects of large-scale industrial product-line development and deployment other than the straightforward reuse of software assets; to capture industrial experience and best practices.

Working Groups: Product line practices.

1 Background

1.1 Product Lines

One approach to reducing the cost of software is to amortize the investment across more than one system. A product line is, from a marketing view point, a group of similar products within a market segment (or mission domain). A product family is a set of products that share acommon design and standards (or assets). A product line built from product family assets maximizes reuse yielding economies of production. Our references to product lines through the remainder of this paper subscribes to this combined definition.

Product lines epitomize reuse. A product line reuses a wide variety of assets, including requirements, the analysis of the system and software requirements, the overall system and software design (the architecture), the actual software components, documentation, test strategies and plans, and test cases and data. In addition, the knowledge and skill of project personnel, the processes, methods, and tools used to develop and evolve a system, and scheduling and budgeting estimates are reusable.

This paper describes the experience of one company that successfully has implemented a product line approach to the construction of large, complex, software- intensive systems. Their experience shows that the technical factors enabling systematic, planned reuse are necessary, but not sufficient for success. Organizational, process, and business factors are equally important.

1.2 A Case Study

CelsiusTech Systems is one of Sweden's leading suppliers of command and control systems. They are part of the CelsiusTech Group, Sweden's largest, and one of Europe's leading, defense industry groups. CelsiusTech Systems has approximately 900 employees and annual sales of 175 million U.S. dollars. CelsiusTech Systems' areas of expertise include command, control, and communication (C3) systems, fire control systems, and electronic warfare systems for navy, army, and air force applications.

CelsiusTech refers to their naval product line as the Ship System 2000 (SS2000). This product line provides an integrated system unifying all fire control, command and control, and communication systems. The SS2000 product line consists of one architecture that defines one family of application components. The components support multiple ship classes and configurations and multiple platforms and operating systems. Each product is created by selecting components from the component family. Customer-specific parameters provide further system tailoring.

Typical system configurations include 1-1.7 million lines of Ada code and 50 to 80 thousand lines of C code distributed on a dual Ethernet local area network (LAN) running TCP/IP protocol with 30 to 70 micro-processors configured onto 15 to 30 nodes. Nodes correspond to a crew station, a weapons platform, or a sensor suite. C code is used solely for some operating system extensions and device drivers. No mission application code is written in C.

A wide variety of naval systems, both surface and submarine, are in various stages of development from the same product line assets. Systems built from the product line vary greatly in size, function, and armaments. Each country requires different operator displays on differing hardware and presentation languages. Submarines have quite different requirements than surface vessels. Yet the SS2000 product line is flexible and robust enough to support this range of possible systems.

CelsiusTech has now built and delivered five different ship classes from the product line. Three more ship classes have started recently. CelsiusTech can now reliably deliver million-plus line systems, with the performance and distribution behavior known before the start of the project, within two years. With the use of the SS2000 product line, CelsiusTech has changed its hardware to software cost ratio from 35:65 to 80:20. On average, 70% of the systems are reused verbatim, that is, without code modification. Commonality for CelsiusTech goes beyond the typical approach of copying a component from one system to another. All components are under strict configuration management (CM). CelsiusTech may use a component in several different systems in the product line, but they centrally maintain the component as a product line asset that does not belong to any one of the systems.

2 Position

The central position of this paper is that software reuse practices, as traditionally espoused in the software engineering community, are far from sufficient for successfully developing, deploying, and migrating a software product line.

2.1 The Importance of Architecture

To achieve their naval product line, CelsiusTech saw that the architecture was central to their success. If the architecture was not viable, the set of components would most likely never form a viable system. CelsiusTech also recognized that while the architecture was the foundation for the product line, their business approach, organizational structure and personnel, development approach, and management must support and work in harmony with the architecture.

The SS2000 product line software architecture is a classically layered architecture. Interfaces between layers are well-defined and controlled. The lowest layer provides a virtual machine, encapsulating the target platform, operating system, and inter-process communications. General domain support services, such as track distribution, are provided in the next higher layer. Mission applications, standard across most systems, form the next layer. Finally, customer specific capabilities form the top-most layer. The layers and theirs contents have a consistent and extensive use of abstraction and encapsulation, thus providing a resilience to change and ease of reuse.

As part of defining the product line architecture, CelsiusTech determined that an Ada package was too small a unit for integration and therefore reuse. With early system size estimates of over one million lines of code, ten thousand or more Ada packages was possible. A larger conceptual entity was necessary. For CelsiusTech, a system function represents a set of Ada packages that form a logical part of their domain. System functions are the unit of reuse for the SS2000 product line and number 250. System functions are the product line components used to compose customer systems. To assist in the management of the development staff, system functions were grouped into 30 system function

groups clustered into 4 functional areas, including weapons, man-machine interface, fundamental services, and command, control, communications. Large-grained reuse was a key technical factor to success.

2.2 Process Factors

CelsiusTech's development approach focused on creating a product line architecture and assets for their particular domain to meet their business objectives. Their process includes

early focusing on the architecture, its critical interfaces and key mechanisms, and the high-level design

prototyping of performance characteristics for the system and the software at the macro level (architecture and high-level design)

monitoring and analysis of performance characteristics for the deployed system components, thus forming an "as is" system behavior model

CelsiusTech's product line assets include not only software but documentation, requirements, and test plans, cases, and data. Managing the integration and configurations for the product line assets plus all customer systems built from the product line was vital to their success. The integration and CM functions must support change coordination such that product line assets are maintained in coordination with all other customer projects. One principal aspect of their solution in this area was the institutionalization of continuous integration (rather than the more traditional "all at once").

Tool support for the magnitude of integration and configuration management required, we believe, was critical. Robust integration and CM tools that support the large-scale development of multiple, parallel development teams, and multiple, parallel system builds and deliveries, are necessary.

2.3 Organization and People Factors

CelsiusTech's architecture and development approach are supported through their organization structure. This synergy is a key factor to their success at institutionalizing a product line approach. Two aspects were paramount. The first was establishinga small, technical architecture team with the authority and responsibility for product line architecture's creation and evolution. The second was merging the integration and CM functions into a strong integration team that drives the iterations and controls the configurations of the product line assets and the customer systems.

Management focus on the learning curve of all stakeholders during the creation stage was vital. Technical training provided was extensive compared to most organizations during 1986 to 1989; representing a re-education program rather than training. Such a commitment of resources would send a strong message to the development staff on the company's commitment to the product line approach.

CelsiusTech now finds that required technical expertise in their staff has changed from programming (Ada, object technology and their development environment) to domain and product line knowledge.

2.4 Business Factors

Fundamental to CelsiusTech's success is that the product line approach was conceived of as a business strategy. All architecture, process, method, tool, organizational, and management decisions support that strategy. Thus, the product line assets are treated as business assets. This becomes a powerful strategy for the transition and institutionalization of technology.

A number of other business factors were vital to their success. These include

domain knowledge and previous experience with non-mainframe, non-centralized, high-performance systems

validating the architecture, components, and development approach by building more than one system in parallel

tools that scale to very large, parallel development

substantial and long-term up-front commitment and investment

retaining ownership of components and architecture

Finally, CelsiusTech has managed customer expectations well. Customers now see a benefit (lower cost, greater reliability) to fitting their requirements into the context of the product line. There is now a SS2000 User Group to guide evolution of the product line.

3 Comparison

The CelsiusTech case study, documented in [1], is to our knowledge the largest example of a software product line that has been described in detail in the open literature. Other examples of software product lines (dating back to IBM's famous OS/360 family of operating systems) are, of course, well known. However, the CelsiusTech study provides new insight into the organizational factors necessary to achieve the goal of product lines, which epitomize systematic asset reuse. Other organizations have adopted similar approaches. Lucent Technologies' FAST process [2] is an example of a process for building product families around expected commonalities an variations in small- to medium-scale application-level utilities. All such techniques rely on domain engineering, whether implicitly or explicitly, to identify the commonalities that the members of the family can assume, and the variations which the family must be prepared to accommodate.

References

[1] Clements, Brownsword, "A Case Study in Successful Product Line Development", Software Engineering Institute technical report, November 1996.

[2] Cuko, Weiss, "An Example of FAST Domain Engineering", IEEE TSE, 1997, to appear.

Biography

Paul C. Clements is a senior member of the technical staff at the Software Engineering Institute of Carnegie Mellon University in Pittsburgh, where he specializes in software architecture issues, especially in the formal representation, analysis, and evaluation of architectures. Prior to joining the SEI, he was a software engineer at the Naval Research Laboratory in Washington. He holds a Masters in computer science from the University of North Carolina at Chapel Hill, and a Ph.D. from the University of Texas at Austin; his dissertation was in requirements specification languages for hard-real-time embedded systems. Clements is the author of some three dozen published papers in software engineering, including design methodologies, software architecture, and requirements engineering.