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: December 1, 2003
People considering the move to a product line strategy usually get around to asking some form of the question, “So how much is this going to cost us in the short term?” A time-based version of the question is, “How many days/months/years will it take for my up-front investment to be recouped by cost savings?” As you can imagine, it’s a difficult question to answer, because of the enormous variations among organizations, products, and markets. The answer is an unsatisfying “It depends.”
Figure 1: Software Product Line Payoff Point
But that is only if the questioner insists on an answer given in dollars or days. It so happens that there is a very satisfying way to re-frame the question that normalizes the answer across all of the variables. Figure 1 (adapted from Weiss ) illustrates the cost model for product lines versus one-at-a-time systems. Without product lines, the cumulative cost begins at zero and rises steadily. With product lines, the cumulative cost begins with the initial cost of the core assets, and then climbs at a shallower rate as projects are turned out. The point at which the two lines cross (and the one-at-a-time cost curve becomes higher) is the payoff point. That cross-over point can be expressed in terms of the number of systems built. Thus, the question becomes how many systems do we need to field before the savings from reuse pay for the up-front investment in building the core asset base? Surprisingly, the answer to this question does not seem to vary much across organizations, products, or markets. What do you imagine it is? Five or six, maybe? Ten? Well, it turns out for the product line approach to pay off, experts agree that the number of systems you need to build is…
Two. Maybe three.
That’s all. And that’s a very good answer indeed, because it’s hard to imagine a product line without at least two or three family members. This means that, practically speaking, every single product line can be expected to reap cost savings when compared to building and maintaining its constituent products separately. Who says so? Apparently, just about everyone:
The reuse figures would not seem to take into account the overhead of organizational change that is inherent in adopting a product line approach, and so might seem a little low--at least at first glance. But organizations that are aggressive and disciplined about reuse (even if they don’t call what they’re doing a product line) must have worked out responsibilities for building the reusable assets and insuring their reuse in a disciplined way, and so their payoff point reflects the organizational re-structuring necessary to achieve that. So accepting their payoff point at face value will probably not take us too far off the mark. And to reinforce that, the Lucent, SPC, and aerospace examples do take the organizational costs into account, and their payoff points are even a bit lower.
This result is very encouraging. It’s almost a certainty that if you’re planning a product line, you’re planning to have at least three products in it. So a slightly different flavor of our opening question is “Will I save money by adopting a product line approach?” And the answer is a very reassuring “Almost certainly.”
Now we aren’t promising that you’ll make money. People have to actually buy your products for that to happen, and even the most breathtakingly efficient production process can’t guarantee that. Instead, we’re talking about the relative costs of building a set of products as a product line, versus building the same set as unrelated one-of-a-kind products. The point here is that if you’re planning to build three or more related systems – not a particularly burdensome requirement for a product line--then building them from a common set of core assets is almost guaranteed to be the more economical way to turn them out.
 Mockus, A. & Siy, H. “Measuring Domain Engineering Effects on Software Coding Cost,” 304-311. Proceedings of Metrics 99: Sixth International Symposium on Software Metrics, Boca Raton, FL, November, 1999. New York, NY: IEEE Computer Society Press, 1999.
 Poulin, J. S. Measuring Software Reuse: Principles, Practices, and Economic Models. Reading, MA: Addison-Wesley, 1997.
Dr. Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis.
Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), 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 authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems.
He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. 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.