NEWS AT SEI
This article was originally published in News at SEI on: January 1, 2006
Leveraging core assets (software, designs, documentation, test artifacts, budgets and schedules, tools, and more) across a family of systems—instead of building each system separately—enables organizations to dramatically increase quality and reduce cost and time to market. But what kinds of organizations are most successful at building software product lines, and must organizations pursue process improvement to initiate product line practice? This is the third in a series of columns to answer some of the questions most frequently asked by organizations considering a product line approach.
"Do successful software product line organizations have certain traits in common?"
They do indeed. The most successful ones are comfortable with process discipline, have a strong and tireless champion for the approach in a position of leadership, and have lengthy and broad experience in the application areas covered by the product line. Less tangible but just as observable is one other trait, something we've nicknamed "the e pluribus unum effect." E pluribus unum is Latin, of course, for "out of many, one." All of the most successful product line organizations we've observed regard their primary missions as building and maintaining the product line (singular) or equivalently, a production capability. Organizations that have still not fully embraced the product line approach tend to describe themselves as turning out products (plural). The difference in mindset is subtle but significant. Companies with the singular outlook realize that they have built a product capability that transcends any one product, or even any group of products. To them, turning out products is easy.
"What's the difference between domain analysis and requirements analysis?"
Domain analysis tends to be broader in scope than requirements analysis. Requirements analysis usually focuses on a specific application while domain analysis looks at the broader requirements for a family of applications. For example, domain analysis would emphasize commonality and variability across a family of products whereas requirements analysis would not. In a product line, however, this distinction is not so sharply drawn, since requirements analysis is often performed for the set of products as a whole during the scoping exercise.
"What is the relationship between process improvement and product line practice?"
Process improvement is broader in scope. Product line practice focuses on how to use a common set of core assets to modify, assemble, instantiate, or generate multiple products that are referred to as a product line. The focus is on improvement in product management. Process improvement applies to software engineering in general. While there is overlap between process improvement and product line practice in key practice areas, product line practices provide guidance for one particular approach to software development. However, experience shows that an organization with poorly defined software processes will not fare well in the transition to product line practice. Consequently, organizations need to apply product line practice and process improvement concurrently. As organizations improve their processes, they often enjoy productivity increases. Organizations with higher process maturity can continue to make productivity increases by turning their attention to product line practices.
"Must all products in the software product line share the same architecture? If my products have different architectures but make heavy use of other shared assets, isn't that a software product line?"
In theory, yes. However, to date, in all of the software product lines we've studied, all products share either the same architecture or slight variations of the same architecture (e.g., by replacing one component with a similar one, by instantiating a multiple component a different number of times, or by exhibiting some subset of the overall architecture).
Next column: Product lines in the context of acquisition
About the Author
Paul Clements is a senior member of the technical staff at the SEI, where he has worked for 10 years leading or co-leading projects in software product line engineering and software architecture design, documentation, and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998; second edition, 2003), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also written dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a BS in mathematical sciences in 1977 and an MS in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a PhD in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.