NEWS AT SEI
This library item is related to the following area(s) of work:Software Product Lines
This article was originally published in News at SEI on: January 1, 2007
"All right, I want to start a software product line. What do I do first?"
There are many resources available to you, many of which are available on or through our web site. You can
Other steps are involved, but these will get you off to a good start.
"My company builds a broadly related group of products, each of which is a group of closely related products. Should I plan to build a single product line, or a group of product lines?"
This can be answered by making a business case for each alternative and weighing the costs and benefits. The SEI's Structured Intuitive Model for Product Line Economics (SIMPLE) can help with this. We've seen this situation in practice many times. Often, the choice has almost always been to go with the single, large product line. Examples come from avionics, missile software, embedded engine controllers, and shipboard command-and-control systems. However, other organizations have chosen to work with separate product lines, or even hierarchical product lines. A hierarchical product line is essentially a product line of product lines. The decision depends on the amount of commonality that can be extracted from the broadly related group, and also how easy it is to communicate and cooperate across the different groups involved. If the products exist in separate business units, for example, the organization might find separate product lines to be more manageable. Finally, if you're just beginning to use the product line concept, it will be much easier to launch one product line than several.
"I want to pilot software product lines in my organization. What are the criteria for a good pilot project?"
The general criteria are the same as for any pilot project. It should be manageable and not too complex. It should be strategic, but not so central that the failure of the pilot will bring down the organization. It should build on strengths rather than weaknesses. Product line pilots should be in an established and well-understood problem area and should be led by some of the best innovators. Starting with a legacy system rather than starting from scratch makes sense if the legacy system is in good health (architecturally sound, well documented, and using modern technologies). If there is an established core asset base from which the product line can be built, so much the better. Finally, the scope of the pilot should be narrow enough that results can be achieved and assessed quickly. See the "Launching and Institutionalizing" practice area for more information.
"Should I plan to take the proactive approach or the reactive approach to my software product line?"
As described in the Framework section "All Three Together," the proactive approach involves building the core assets first and then using those to spin out products, whereas the reactive approach calls for having products first and then extracting the core assets from those products. These are two extremes of a spectrum of possibilities in between. A likely compromise is to develop some fresh core assets while producing others from an existing product or stable of products. A key determinant is how well you can predict the future. If you can confidently map out the scope of your software product line in detail, describing the commonalities and variabilities that your products will require, then proactively building the core assets to serve that scope will probably provide a rapid product-production capability. If, on the other hand, your scope is defined only in more general terms, then trying to build the core assets ahead of time will probably result in a large amount of re-work and frustration. In that case, it is better to refine the core assets as you field more products and gain more knowledge about your market. Use whatever information you have when you have it--but no more and no sooner.
"Where is the resistance to adopting a product line approach usually found?"
It can come from almost anywhere, but we observe that often it shows up at the middle-management level. Many times the front-line staff members recognize the benefits of doing things the new way because they're the ones who must implement and re-implement almost identical applications multiple times. Conversely, senior management tends to have the vision and see the financial bottom lines. This is by no means always the case, however. We also know of an organization in which senior management was preoccupied with buy-outs and mergers, and middle management stepped in and initiated the transition to product line practice; when senior managers turned their attention inward, they discovered to their surprise that their company was building software in an entirely new way.
"Where can I go to get more information?"
The SEI's Product Line Practice initiative Web site is a good place to start.
There are also several books on software product lines, including Software Product Lines: Practices and Patterns [Clements 01], Software Product-Line Engineering: A Family-Based Software Development Process [Weiss 99], and Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach [Bosch 00]. In addition, Software Reuse: Architecture, Process, and Organization for Business Success [Jacobson 97] is oriented toward projects employing large-scale strategic reuse and is compatible in many ways with product line practice. A new book by van der Linden, Schmid, and Rommes called Software Product Lines in Action [van der Linden 07] is expected this year.
Conferences on software product lines produce papers about both theory and practice. The premier product line conference is the International Software Product Line Conference (SPLC); the next one will be in Kyoto in September.
Where can I read about other organizations that have successfully adopted the software product line approach?
Case studies are excellent resources to help you get started because they show you how other organizations approached the product line issues they faced.
In addition, you should visit the Software Product Line Hall of Fame, where software product lines of lasting community value are inducted at each Software Product Line Conference. Each inducted product line is described, and references for more information are given.
Clements, P. & Northrop, L. Software Product Lines: Practices and Patterns. Boston, MA: Addison-Wesley, 2002.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.