Book Review: Six Sigma Software Development
This book does not live up to its title, in that the connections it makes between Six Sigma and Software Development are slight. However, the book did suggest to me at least one way in which a Six Sigma concept might be used to improve Software Engineering.
Out of 276 pages (excluding appendixes), the first 109 pages provide a Six Sigma primer, though this primer does not adequately explain, in my opinion, the statistical underpinnings of Six Sigma. None of the examples used in this Six Sigma primer have anything to do with software development.
The remainder of the book is a primer on Software Development, heavily weighted toward the Waterfall Method and in-house Information Technology (IT) departments. Other methods briefly mentioned are Rapid Application Development (5 pages), Prototyping and Spiral Development (5 pages), and Client/Server and Web-Based Systems (3 pages). Other topics are Six Sigma and ... Legacy Systems (22 pp), ... Packaged Software Implementation (20 pp), ... Outsourcing (20 pp), and "The Six Sigma IT Department: Putting it All Together" (9 pages).
With respect to the SDLC or Waterfall Method, Ms. Tayntor proposes the following mapping between SDLC Phases, and the steps in Six Sigma DMAIC:
|SDLC Phase||Six Sigma (DMAIC)|
|Project initiation||Define, measure, analyze|
|System analysis||Define, measure, analyze|
|Testing and quality assurance||Improve|
|Implementation||Improve and control|
In my accustomed terminology, "Construction" corresponds to coding or implementation, and "Implementation" corresponds to release, distribution, or deployment, followed by technical support. I find this application of Six Sigma terminology to software development confusing rather than helpful.
As one with extensive experience in software product development (rather than in-house IT), and as one who has received a little training in Six Sigma, I am as yet skeptical that Six Sigma can be applied profitably to software development. Six Sigma uses statistics to measure and control unwanted variation in repetitive processes such as manufacturing and order processing. I find that the steps in software development, such as gathering and prioritizing requirements, designing, implementing, and testing, are much less tangible and difficult to quantify than are the steps in manufacturing or order processing. As the nature and scope of projects vary, the content of each of these steps will also vary. For one project, the dataset is small, and unless projects are very similar in goals and scope, it is difficult to tell (by quantitative methods) whether the software development process is improving from one project to the next. Every step in a software development project is strongly influenced by the quality of the requirements definition, and the quality of the requirements definition is difficult to quantify—but more on this at the end of the review.
Though this is also somewhat intangible, I agree with the following observation about software engineering, which is found in many books and articles: The effectiveness of software engineers varies widely from individual to individual, and the success of projects is strongly influenced by the effectiveness of the project participants. This suggests that project metrics might help in the assessment of individuals, but it is unclear how such information would be utilized in process improvement.
I opened this book in the hope that it would suggest some answers to such questions as the preceding, but on the whole, I was disappointed.
In the process of reading this book, I was, however, struck by two valid and important points: (1) it is important to identify external and internal customers, and (2) the process of defining requirements (generated by those customers) is extremely important. These are points all software developers should be aware of, but in practice they are often (if not usually) neglected. The following quotation from the book is true and important:
"The heart of Six Sigma is understanding and then delivering what Customers need, what they expect, and what will transform them from simply being satisfied to being delighted. As Mikel Harry and Richard Schroeder state in their book, Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations, 'Everything starts and ends with the customer'" (pg. 42).
One could substitute "successful software development" for "Six Sigma" in the first sentence, and the resulting sentence would also be true and important. Perhaps Customer Satisfaction Surveys could be used to measure trends in the quality of requirements, and this strikes me as a worthwhile thing to try. Beyond that, and as indicated above, it remains unclear to me how the statistical measurement methods of Six Sigma can be applied to software engineering.