Calculating Return on Investment for Software Product Lines

NEWS AT SEI

Author

Paul C. Clements

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: February 1, 2004

Product line engineering has become a widely used methodology for the efficient development of complete portfolios of software products.1 The core idea of the approach is to regard the development of a set of products as a single, coherent development task. This approach has been shown to produce orders of magnitude economic improvements over one-at-a-time software system development.

The SEI is helping organizations understand the benefits of product line engineering. Often, the first thing a manager in an organization considering product lines wants to know is the return on investment (ROI) for changing the company’s development strategy. Until now, however, most of the economic arguments supporting the switch to product lines have been based on data derived from individual case studies,2, 3 convincing arguments based on rationality and simplistic cost curves.4 Existing models of product line development costs for the context of reuse can be applied only in a restricted way, as product line development makes some fundamental assumptions that are not reflected in these models.

A Product Line Economic Model

Recently, a small project team at the SEI has begun to work on the problem of calculating the cost benefit of the product line approach. The model is based on four cost functions:

  • Corg() is a function that, given the relevant parameters, returns the cost to an organization of adopting the product line approach for its products. Such costs can include reorganization, process improvement, training, and whatever other organizational remedies are necessary.
  • Ccab() is a function that, given the relevant parameters, returns the cost to develop a core asset base suited to satisfy a particular scope. Ccab differs from Cunique in that it must take into account the cost of performing a commonality/variability analysis, the cost of designing and then evaluating a generic (as opposed to a single-system) software architecture, and the cost of developing the software so designed. Ccab can be invoked to tell us the cost of developing a core asset base where none currently exists, or it can be invoked to tell us the cost of deriving a desired core asset base from one or more already in place.
  • Cunique() is a function that, given the relevant parameters, returns the cost to develop unique software that is not based on a product line platform. The result might be a complete product or it might be the unique part of a product whose remainder is built atop a product line core asset base.
  • Creuse() is a function that, given the relevant parameters, returns the development cost to reuse core assets in a core asset base. Creuse includes the cost of locating and checking out a core asset, tailoring it for use in the intended application, and performing the extra integration tests associated with reusing core assets.

These cost functions are not mathematically rigorous, but they do let us break down the costs into more manageable analytical chunks. They don’t actually “return” values, but let us perform thought experiments, use legacy data, or invoke more conventional cost models on smaller pieces of the problem. Hence, the cost of developing a software product line from scratch can be expressed as

Equation

where n is the number of products in the product line. Other situations can be similarly formulated, and the cost of building and managing the evolution of a product line can be compared to the cost of building the same systems from scratch. ROI is simply cost savings of doing things the new way divided by the cost of investment – which in this case is usually Ccab + Corg.

We hope this simple model will prove useful in helping software development managers or corporate decision-makers understand the cost benefits they might expect when switching to the product line approach. Our team is working to expand the model to include the non-cost benefits of product line engineering, such as higher quality and decreased time to market. We are also seeking real-world opportunities to put the model to use.

1 Special Issue on Software Product Lines. IEEE Software 19, 4 (July/August 2002).
http://csdl.computer.org/comp/mags/so/2002/04/s4toc.htm

2 Clements, P. & Northrop, L. Salion, Inc.: A Software Product Line Case Study (CMU/SEI-2002-TR-038, ADA412311). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.

3 Knauber, P.; Bermejo, J.; Böckle, G.; Leite, J.; van der Linden, F.; Northrop, L.; Stark, M.; & Weiss, D. “Quantifying Product Line Benefit,” Proceedings of the Fourth International Workshop on Product Family Engineering, Bilbao, Spain, October 3-4, 2001. Heidelberg, Germany: Springer-Verlag, 2001.

4 Weiss, D. & Lai, C. Software Product-Line Engineering. Reading, MA: Addison-Wesley, 1999.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.