Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Software process improvement: blueprints versus recipes
Aaen I. IEEE Software20 (5):86-93,2003.Type:Article
Date Reviewed: May 25 2005

Aaen presents an interesting argument against using the traditional software process improvement (SPI) model for an organization’s existing software process, where SPI can be viewed as blueprint that is rigid, and that is unlikely to reach its full potential in practice. The author presents an idea to optimize SPI, and suggests that SPI can be viewed more as a recipe than a blueprint. The recipe view can be thought of as a set of guidelines used to tailor specific conditions that arise using the traditional SPI model, and that would otherwise fall short using the blueprint view, thereby leaving potential process improvement gains on the table.

By relaxing aspects of the traditional SPI model, the author suggests that the optimized recipe version provides the practitioner with a better view of an organization’s software development culture. In addition, the open-ended nature of using a recipe (instead of a blueprint) enables the practitioner to better understand the future needs of the organization’s software development culture.

The SPI model is known to be problematic, however, as suggested by the author, where a practitioner’s beliefs, values, emotions, perceptions, and behaviors could potentially alter the outcome of the traditional SPI model (and yield less than optimal results). So why is it better for the practitioner to use a recipe over a blueprint when it comes to the cost associated with this optimization? Also, doesn’t the open-ended nature of using a recipe instead of a blueprint actually introduce process complexity instead of reducing it, and translate into higher costs associated with the improvement? These are just a couple of questions related to potential costs that are not addressed by the author, but are important questions for practitioners to ask if they are considering SPI (since a benefit/cost analysis is usually required to justify an SPI project).

The author makes a bold attempt at an argument to optimize the traditional SPI model. The SPI practitioner should think very carefully before making any such changes to his or her organization’s software development culture, in order to yield improved gains in its software process. Otherwise, he or she might introduce inadvertent process complexity, which might result in higher costs associated with the improvement project.

Reviewer:  Eric W. Yocam Review #: CR131328 (0512-1330)
Bookmark and Share
  Reviewer Selected
Featured Reviewer
 
 
Software Process Models (D.2.9 ... )
 
 
Software Process (K.6.3 ... )
 
Would you recommend this review?
yes
no
Other reviews under "Software Process Models": Date
Cognitive patterns
Gardner K., Rush A., Crist M., Konitzer R., Teegarden B., Cambridge University Press, New York, NY, 1998. Type: Book (9780521649988)
Aug 1 1998
CMM implementation guide
Caputo K., Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1998. Type: Book (9780201379389)
Sep 1 1998
Applying use cases
Schneider G., Winters J., Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1998. Type: Book (9780201309812)
May 1 1999
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy