CÓDIGO DE SANCIONES
5.-COACHES Y JUGADORES
Watts S. Humphrey, founder of the SEI Software Process Program and a fellow of the SEI, has been awarded the prestigious 2003 National Medal of Technology for his contributions to the software engineering community. The National Medal of Tech- nology is the highest honor awarded by the President of the United States to Amer- ica’s leading innovators. A formal ceremony took place March 14, 2005, at the White House. Speaking as a recognized authority on software development and soft- ware quality, Watts Humphrey made these comments about software quality [42]3:
Software suppliers do not generally take responsibility for the defect content of their products. They often even ship products that contain known defects, and they com- monly charge customers for a significant part of the costs of fixing these defective products. The public is increasingly aware of and unhappy with these practices. Software is routinely blamed for common problems in almost any industry that serves the public, and the public has come to expect software to perform badly.
While today it may seem rational for the software industry to disclaim all respon- sibility for the quality of their products, this is tantamount to insisting that the mar- ket change before the industry will. This stance guarantees that when the market changes, as it must, the public must first be damaged. This will cause avoidable harm and discredit the present suppliers. Continuing with this strategy will mean that software quality will inevitably become a hot political issue.
At the start of his book, Managing the Software Process, Watts Humphrey states: “The framework used here … roughly parallels the quality maturity structure defined by Crosby” [43]. (See Section 2.8.) This framework, of course, are the matu- rity levels in the CMM®for Software. The five maturing stages through which sys- tems and software development evolve are as follows:
• Initial; • Managed;
• Defined;
• Quantitatively managed; • Optimizing.
Table 2.6 updates these maturity levels from the CMMI® for Development (CMMI®-DEV, v1.2), which was based upon the Capability Maturity Model® (CMM®) for Software that Watts Humphrey provided conceptual leadership for while at the SEI. For each of the process areas listed, such as Requirements Manage- ment, there are required goal(s) and associated specific and generic practices. The practices describe the activities that are expected to result in achievement of the goals of a process area. CMM®for Software became the generally accepted stan- dard for assessing and improving software processes worldwide. Now, the CMMI®-DEV, v1.2 is becoming the standard for product development.
The CMM®for Software and its successors (e.g., CMMI®-DEV) have become the industry accepted standard for understanding the maturity of software develop- ment in many parts of the world. It is this incisive concept of Watts Humphrey that motivated his receiving the 2003 National Medal of Technology. The measured improvements in software development have arisen from the CMM®for Software and its successors (e.g., CMMI®-DEV) over the past few years.
2.9 Watts S. Humphrey 57
Table 2.6 CMMI®
for Development (v 1.2) Maturity Levels [Category for that Process Area in the Continuous Representation] {LEVEL 1—Initial}
Ad hoc
{LEVEL 2—Managed}
Requirements Management (REQM) [Engineering] Project Planning (PP) [Project Mgmt.]
Project Monitoring and Control (PMC) [Project Mgmt.] Supplier Agreement Management (SAM) [Project Mgmt.] Measurement and Analysis (MA) [Support]
Configuration Management (CM) [Support]
Process and Product Quality Assurance (PPQA) [Support] {LEVEL 3—Defined}
Requirements Development (RD) [Engineering] Technical Solution (TS) [Engineering]
Product Integration (PI) [Engineering] Verification (VER) [Engineering] Validation (VAL) [Engineering]
Organizational Process Focus (OPF) [Process Mgmt.]
Organizational Process Definition (OPD) + IPPD [Process Mgmt.] Organizational Training (OT) [Process Mgmt]
Integrated Project Management (IPM) + IPPD [Project Mgmt.] Risk Management (RSKM) [Project Mgmt.]
Decision Analysis and Resolution (DAR) [Support] {LEVEL 4—Quantitatively Managed}
Organizational Process Performance (OPP) [Process Mgmt.] Quantitative Project Management (QPM) [Project Mgmt.] {LEVEL 5—Optimizing}
Causal Analysis and Resolution (CAR) [Support]
Organizational Innovation and Deployment (OID) [Process Mgmt.]
Recognizing the benefits of the CMM®for Software, during the 1990s Watts Humphrey decided a method was needed to have those benefits accrue to individual and teams of software developer(s). So he defined the Personal Software Process (PSPSM) and the Team Software Process (TSPSM). The PSPSMproject was aimed at demonstrating that a CMM®process could be used by an individual to develop high-quality software without excessive process overhead. PSPSMproved quite suc- cessful and TSPSM was developed to provide a framework for applying PSPSM in a team setting to develop high quality software (Figure 2.5). The two processes are licensed SEI technologies. They are almost always used together in a project setting [45]:
The PSPSM
is an SEI technology that brings discipline to the practices of individual software engineers, dramatically improving product quality, increasing cost and schedule predictability, and reducing development cycle time for software.
The TSPSM
is a complementary SEI technology that enables teams to develop software-intensive products more effectively. TSPSM
shows a team of engineers how to produce quality products for planned costs and on aggressive schedules.
PSPSM
is a lightweight CMM®
process designed for cost effective individual use. It
PSP : improves individual skills and discipline, personal focus
SM
TSP : improves team performance, team, and product focus SM CMMI : improves organization’s capability, management focus ® CMMI®+PSPSM+TSPSM Figure 2.5 CMMI® , TSPSM and PSPSM
relationships. (From: [46]. © 2000 Software Engineering Institute. Reprinted with permission.)
applies to most structured software development tasks including requirements defi- nition, architecture design, module development, and documentation production. It is capable of efficiently producing very high quality software products. There is no cost overhead involved in achieving these high software quality levels. In fact, PSPSM
projects are generally faster and cheaper than more conventional approaches to software development.
TSPSM
adds a project management layer to the PSPSM
. It helps engineers to produce quality products for planned costs and on aggressive schedules. It addresses the CMM®
levels 2 and 3 management processes using high performance interdisciplin- ary work teams. Engineers manage their own work and take ownership of their plans and processes. TSPSM
helps the engineers to build a gelled, self-directed team and to perform as effective team members. It shows management how to guide and support these teams and how to maintain an environment that fosters high team performance.
PSPSM
augmented by TSPSM
can support the development of large-scale software systems. It can be used to accelerate an organization from CMM®
level 2 to level 5. It provides an excellent foundation for application of six sigma statistical tools. It does not require a high level of process maturity for introduction. CMM®
level 1 organizations have used it very successfully.
The SEI has provided a representation of the relationships among the CMMI®, TSPSM, and PSPSMto highlight the goals and improvements provided by each.
The SEI produced a technical report for those interested in both CMMI®and the TSPSMand in how these two technologies might be used together to accelerate their process improvement efforts. Key to the report is Figure 2.6; it shows TSPSM practice coverage by process category in the CMMI®. This type of overview pro- vides support to how well the technologies thought of by Watts Humphrey become useful and complimentary within an organization.
2.9 Watts S. Humphrey 59 0% 25% 50% 75% Process management Project management Engineering Support Directly addressed Supported Partially addressed Not addressed Unrated 100%
TSPSMand CMMI process categories®
Figure 2.6 Summary of TSPSM
project practice coverage by process category. (From: [47]. © 2005 Software Engineering Institute. Reprinted with permission.)
2.10
Conclusion
This chapter applies the overall quality principles of leaders in the quality revolution to the specialty area of software and development quality. These principles lead to a philosophy about the application of what may appear to be remote principles to the reality of producing quality products involving software.
Kaoru Ishikawa has laid a quality framework of six features, each of which have applicability to development of quality software-intensive products. Joseph M. Juran’s three methods for meeting the Japanese quality challenge all have applicabil- ity to the production of quality software-intensive products. The QFD concepts of Dr. Yoji Akao because of their focus on customer satisfaction also show applicabil- ity to software quality. Statistical methods and the Deming Circle taught by W. Edwards Deming have very specific application to software reliability and quality. Also, Dr. Deming’s 14 Points are shown to be applicable to development of software-intensive products. The Taguchi Method of reduction in variability of pro- duction is applied to the production of software. Shigeo Shingo’s zero quality con- trol applies source inspection for the zero defect software methodology. Software quality can be shown as progressing through the five maturing stages of Philip Crosby’s Quality Management Maturity Grid. Through the influence of Watts Humphrey, Crosby’s Quality Management Maturity Grid morphed into the Capa- bility Maturity Model®for Software.
These experts have been responsible for a revolution in world economics brought about by attention to quality. The state of computer software will improve significantly by applying these revolutionary quality principles to software-intensive product development. The groundwork has been surveyed in this chapter, but there is so much to learn and apply from each expert that it is hoped others will expand the scope of their work and apply their teachings to the quality of software-intensive product development. The key message from Juran, Deming, and others in the qual- ity movement is that long-term improvement only comes about from systematic study and action, not from slogans or arbitrary objectives [48].
This chapter started with a quotation: “Quality is never an accident; it is always the result of intelligent effort,” and so it concludes with a philosophical quotation from Robert Persig about the need to understanding quality in order to use it [49]:
A real understanding of quality doesn’t just serve the System, or even beat it or even escape it. A real understanding of quality captures the System, tames it and puts it to work for one’s own personal use, while leaving one completely free to fulfill his inner destiny.
References
[1] Oberle, J., “Quality Gurus: The Men and Their Message,” Training, January 1990, p. 47. [2] Main, J., “Under the Spell of the Quality Gurus,” Fortune, August 18, 1986, p. 30. [3] Oberle, J., “Quality Gurus: The Men and Their Message,” Training, January 1990, p.48. [4] Crosby, P., Quality Is Free, New York: New American Library, reproduced with permission
[5] Tice, Jr., G. D. “Management Policy & Practices for Quality Software,” ASQC Quality
Congress Transactions, Boston, MA: Copyright American Society for Quality Control,
Inc., 1983.
[6] Ishikawa, K., “Quality Control in Japan,” 13th IAQ Meeting, Kyoto, Japan, 1978. [7] QC Circle Koryo, “General Principles of the QC Circles,” Tokyo: Union of Japanese Scien-
tists and Engineers (JUSE), 1980.
[8] Aubrey, II, C. A., and P. K. Felkins, Teamwork: Involving People in Quality and Productiv-
ity Improvement, New York: American Society for Quality Control, 1988, p. 5.
[9] Tribus, M., “Prize-Winning Japanese Firms’ Quality Management Programs Pass Inspec- tion,” AMA Forum, Management Review, February 1984.
[10] Juran, J. M., “Product Quality—A Prescription for the West, Part I: Training and Improve- ment Programs,” Management Review, June 1981; and “Product Quality—A Prescription for the West, Part II: Upper-Management Leadership and Employee Relations,” Manage-
ment Review, July 1981.
[11] Juran, J. M. “Quality Problems, Remedies and Nostrums,” Industrial Quality Control, Vol. 22, No. 12, June 1966, pp. 647–653.
[12] Deming, W. E., “On Some Statistical Aids Toward Economic Production,” Interfaces, Vol. 5, No. 4, August 1975, p. 8.
[13] Deming, W. E., “What Happened in Japan?” Industrial Quality Control, Vol. 24, No. 2, August 1967, p. 91.
[14] Swartout, W., and R. Balzer, “On the Inevitable Intertwining of Specification and Imple- mentation,” Communications of the ACM, Vol. 25, No. 7, July 1982, pp. 438–440. [15] Sandholm, L., “Japanese Quality Circles—A Remedy for the West’s Quality Problems?”
Quality Progress, February 1983, pp. 20–23, Copyright American Society for Quality Con-
trol, Inc., Reprinted by permission.
[16] Deming, W. E., “My View of Quality Control in Japan,” Reports of Statistical Application
Research, JUSE, Vol. 22, No. 2, June 1975, p. 77.
[17] Gottlieb, D., “The Outlook Interview: W. Edwards Deming, U.S. Guru to Japanese Indus- try, Talks to Daniel Gottlieb,” The Washington Post, January 15, 1984, p. D3.
[18] Zultner, R. E., Quality Function Deployment (QFD) for Software, Princeton: Zultner & Company, 1992, p. 1.
[19] Haag, S., M. K. Raja, and L. L. Schkade, “Quality Function Deployment: Usage in Software Development,” Communications of the ACM, Vol. 39, No. 1, January 1996, p. 42. [20] Zells, L., Applying Japanese Total Quality Management to U.S. Software Engineering,
Washington D.C.: ACM Lecture Notes, 1991, pp. 51, 52.
[21] Zultner, R. E., Quality Function Deployment (QFD) for Software, Princeton, NJ: Zultner & Company, 1992, p. 2.
[22] Haag, S., M. Raja, and L. Schkade, “Quality Function Deployment (QFD) Usage in Soft- ware Development,” Communications of the ACM, Vol. 39, No. 1, January 1996, p. 41. [23] Haag, S., M. K. Raja, and L. L. Schkade, “Quality Function Deployment (QFD) Usage in
Software Development,” Communications of the ACM, Vol. 39, No. 1, January 1996, p. 45.
[24] Noguchi, J., “The Legacy of W. Edwards Deming,” Quality Progress, December 1995, p. 37.
[25] Deming, W. E., “My View of Quality Control in Japan,” Reports of Statistical Application
Research, JUSE, Vol. 22, No. 2, June 1975, p. 73.
[26] Cho, C.-K., An Introduction to Software Quality Control, New York: John Wiley & Sons, 1980.
[27] Deming, W. E., “It Does Work,” Reprinted with permission from Quality, August 1980, A Hitchcock publication, p. Q31.
[28] Gremba, J., and C. Myers, “The IDEALSM
Model: A Practical Guide for Improvement,”
Bridge, Pittsburgh, PA: Software Engineering Institute, Issue 3, 1997, p. 8. Special permis-
sion to reproduce “The IDEALSM
Model: A Practical Guide for Improvement,” © 1997 by Carnegie Mellon University, is granted by the Software Engineering Institute.
[29] Zultner, R., “The Deming Way—A Guide to Software Quality,” adapted by Richard Zultner, brochure from Zultner & Co., Princeton, NJ: Zultner & Co., 1988.
[30] Hansen, R. L., “An Overview to the Application of Total Quality Management,” Aeronau- tical System’s Division, U.S. Air Force, 1990, © 1990 IEEE, pp. 1465, 1466.
[31] Windham, J., “Implementing Deming’s Fourth Point,” Quality Progress, December 1995. [32] Zultner, R., CQE, “SPC for Software Quality,” NSIA Software Quality Conference, Alex-
andria, VA, 1989.
[33] Taguchi Method One Day Seminar, August 10, 1988, Dearborn, MI: American Supplier Institute, Inc., 38705 Seven Mile Road, Suite 345, Livonia, MI 48152, Tel: (734) 464-1395, (800) 462-4500, Fax: (734) 464-1399, all rights reserved, 1988.
[34] Shingo, S., Zero Quality Control: Source Inspections and the Poka-yoke System, Tokyo: Japan Management Association, 1985; English translation: Cambridge, MA: Productivity, Inc., 1986.
[35] Shingo, S., Zero Quality Control: Source Inspections and the Poka-yoke System, Tokyo: Japan Management Association, 1985; English translation: Cambridge, MA: Productivity, Inc., 1986, pp. v, vi.
[36] Schulmeyer, G. G., Zero Defect Software, New York: McGraw-Hill, 1990, p. 33. [37] McCarthy, J., Dynamics of Software Development, Redmond, WA: Microsoft Press, 2006,
p. 35. All rights reserved.
[38] Schulmeyer, G. G., Zero Defect Software, New York: McGraw-Hill, 1990, p. 38. Repro- duced with permission.
[39] Burrill, C. W., and L. W. Ellsworth, Quality Data Processing, The Profit Potential for the
80’s, Tenafly, NJ: Burrill-Ellsworth Associates, 1982, p. 176.
[40] Walter, C., “Management Commitment to Quality: Hewlett-Packard Company,” Quality
Progress, August 1983, p. 22.
[41] Turnbull, D., “The Manual—Why?” Quality, August 1980, p. Q5.
[42] Humphrey, W. S., “Comments on Software Quality,” Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, http://www.cs.queensu.ca/~cisc853/readings/papers/ humphreyOnSW.pdf#search=%22watts%20s%20humphrey%22, December 2006. Spe- cial permission to reproduce is granted by the Software Engineering Institute.
[43] Humphrey, W., Managing the Software Process, Reading, MA: Addison-Wesley, 1989, p. 4. [44] Capability Maturity Model Integration®
for Development, version 1.2 (CMMI® -DEV, v1.2), CMU-SEI-2006-TR-008, Pittsburgh, PA: Carnegie Mellon University, August 2001. [45] PS&J Software Six Sigma, “Personal Software Process & Team Software Process,”
http://www.softwaresixsigma.com/Tsp_Main_PspTsp.htm, December 2006. [46] Humphrey, W., The Team Software ProcessSM
(TSPSM
), Technical Report CMU/SEI-2000-
TR-023, Pittsburgh, PA: Software Engineering Institute, November 2000, p. 8. Special per- mission to use portions is granted by the Software Engineering Institute.
[47] McHale, J., and D. Wall, Mapping TSPSM
to CMMI®
, CMU/SEI-2004-TR-014, Pittsburgh, PA: Software Engineering Institute, April 2005, p. 7. Special permission to use portions is granted by the Software Engineering Institute.
[48] Fowler, P., and S. Rifkin, Software Engineering Process Group Guide, Software Engineer- ing Institute Technical Report CMU/SEI-90-TR-24, Pittsburgh, PA: Software Engineering Institute, September 1990, p. 95.
[49] Persig, R. M., Zen and the Art of Motorcycle Maintenance, New York: Bantam Books, 1974, p. 200.
C H A P T E R 3