SEI Capability Maturity Model comp.software-eng archive file "maturity" last changed 31 Jul 1993 This file contains information on the following subjects. Numbers in column 1 count distinct messages with the corresponding subject. 1 Availability of SEI CMM reports (Postscript) 1 Availability of SEI CMM tech reports 1 CMM reports electronically available 1 Executive overview of Capability Maturity Model 1 Larry Druffle comments on process assessments 20 SEI Level for New Organization? 2 SEI Level for New Organization? (LONG) 16 SEI Process Maturity Model 2 SEI Process Maturity Model [Bellcore QPS-88.001; Curtis reaction] 2 SEI Process Utopia (Was: SEI Level for New Organization?) 1 SEI Process tapioca. 2 SEI maturity model papers 1 SEI technical reports 1 SEI, software process maturity ? 1 Software QA Survey Results 1 The SEI Capability Maturity Model 1 postscript versions of SEI CMM reports requested ------------------------------------------------------------------------ The Sofware Engineering Institute's address is: Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213-3890 (412) 268-6874 Their customer relations group, which services requests for information, can be contacted at: internet: customer-relations@sei.cmu.edu Phone: (412) 268-5800 From: darryl@darryl.b23b.ingr.com (Darryl Davis) Subject: Executive overview of Capability Maturity Model Date: 7 Feb 92 20:07:39 GMT Organization: DAZIX, An Intergraph Company We hope that this executive overview of the SEI's Capability Maturity Model will be helpful. This has a few of our own comments, but is mostly condensed from the SEI writings. It emphasizes the bottom two levels of the maturity model. AN EXECUTIVE OVERVIEW OF THE CAPABILITY MATURITY MODEL FOR SOFTWARE Prepared by Darryl Davis and Dana Wallace DAZIX, An Intergraph Company February 7, 1992 The software process is the set of activities, methods, and practices people use to develop and maintain software and the associated products. It is the combination of the software management process and the software engineering process. It has been proven that process improvement greatly contributes to improved profitability, with very significant returns on the investment. The quality, cost, and schedule of a software product is greatly affected by the quality of the process used to create it. After failing to realize promised productivity and quality gains from new methods and technologies, organizations have come to realize that the fundamental problem is the inability to manage the overall software process. Improving the process, and improving our understanding of the process, will have the direct result of improved software at less cost and in less time. The Carnegie Mellon University (CMU) Software Engineering Institute's (SEI's) Capability Maturity Model (CMM) for Software [Paulk91, Weber91] provides an evolutionary strategy for software organizations to use in developing a mature, disciplined, software process. It covers practices for planning, engineering, and managing software development and maintenance. The CMM helps answer the questions: o How good is our current software process? o What must we do to improve it? o Where do we start? The CMM is based on time-proven quality principles. It applies Total Quality Management to software. Its roots are in statistical quality control, which was developed by Shewart in the 1930s and further developed and successfully demonstrated (primarily in Japan) by Deming [Deming86] and Juran [Juran88, Juran89]. The CMM casts these principles into a maturity framework (first inspired by Crosby [Crosby79]). The framework consists of five maturity levels that describe the progression from a chaotic process to a well controlled, optimizing process. The levels lay successive foundations for continuous process improvement. By determining their position in this framework, organizations can readily identify the most fruitful areas for improvement actions. [Humphrey91] Each level establishes an intermediate set of goals toward higher levels of process maturity. Level 5, the "optimizing" level, is the highest level of maturity represented in the model. At level 5, the process is self-optimizing based on the feedback of process measurements. But before an organization can attempt to achieve this level, these process measurements must be in place. At level 4, the "managed" level, a quantitatively measured process has been established. But before a process can be measured, it must first be well defined. At level 3, the "defined" level, the process is well defined and institutionalized. "At this point advanced technology can usefully be introduced." [Humphrey89] But an organization cannot devote the attention needed to successfully establish such a process unless they are out of "crisis mode." At level 2, the "repeatable" level, the organization is not tied up battling crisis situations. Basic project management, requirements management, subcontract management, configuration management, and software quality assurance are in place. "Planning and managing new projects is based on experience with similar projects." [Paulk91] The commitments are realistic. "Project managers track software costs, schedules, and functionality; and problems in meeting commitments are identified when they arise. Software requirements and the artifacts developed to satisfy them are baselined, and their integrity is controlled." [Paulk91] Project standards are defined and followed. Project teams work with their customers and subcontractors to establish an effective working environment. The organization is able to repeat successful practices developed on earlier projects. At this stage, basic software engineering methods and technologies can be introduced if great care is used to keep the risk down. Level 1, the "initial" level, is the lowest level of maturity. The process is ad hoc and maybe even chaotic. Sound management practices are lacking. Quality, cost, and schedule are generally unpredictable. It is an unstable environment for software development and maintenance. Poor planning and reaction-driven commitments undermine the benefits of software engineering practices. It is "difficult or even impossible to introduce advanced methods and technology." [Humphrey89] The projects are frequently in crisis, driving them to abandon any planned procedures and revert to coding and testing. A project's success depends completely on its having an exceptional manager and software team. These very rare managers can sometimes withstand the pressures to take shortcuts in the process, but when they leave the project their stabilizing influence leaves with them. Experience has shown that it typically takes an organization committed to process improvement anywhere from a year and a half (by some small organizations) to three years to progress by one complete level of maturity; but the progression from level 1 to level 2 may require more on the order of three to five years. However, there are many factors that may cause the time to vary more widely. The CMM is: o Cutting edge: The CMM is the product of the most up-to-date research by the nation's foremost software engineering organization. Extensive testing continues in order to improve and evolve the CMM. o Evolutionary: It is based on many small, evolutionary steps each providing the foundation for the next step. o Focused: Organizations can use the CMM to identify deficiencies and work aggressively on the few issues most critical to improving the software process. o Low risk: The SEI performs extensive research to identify, experiment with, scale up, and prove the practices in the CMM. Risk is minimized for managers who must meet commitments and cannot afford to experiment with their process. o Flexible: The CMM does not require any specific software technology, organizational structure, life-cycle model, or set of documents. Care has been taken to provide a complete set of valid principles that apply to a wide range of situations, not a rigid set of rules and regulations. o Specific: The CMM consists of clear-cut goals, and specific practices that can be used to achieve those goals. o Supported: The SEI supports the CMM with comprehensive documentation, training, and certified vendors. The CMM is further described in the CMU SEI technical reports Capability Maturity Model for Software [Paulk91] and Key Practices of the Capability Maturity Model [Weber91]. Each US DAZIX site has copies of these documents for their library. Also, copies can be obtained from Darryl Davis. FURTHER READING The SEI technical report "Capability Maturity Model for Software" [Paulk91] gives an overview of the CMM. Specifically, it includes a brief history and rationale, describes the framework and structure of the CMM, and explains how organizations can use the CMM to improve their process. The SEI technical report "Key Practices of the Capability Maturity Model" [Weber91] describes the practices that correspond to each maturity level of the CMM. "It is an elaboration of what is meant by maturity at each level of the CMM and a guide that can be used for software process assessments, software capability evaluations, and process improvements." [Weber91] The book Managing the Software Process [Humphrey89] covers the essentials of software management. It, together with the paper "Characterizing the Software Process," [Humphrey88] provided the initial foundation for the CMM. This book is the place to turn to for more comprehensive and detailed guidance for improving the process. The paper "Software Process Improvement at Hughes Aircraft" [Humphrey91] presents how Hughes' Software Engineering Division progressed from level 2 to level 3 of the model in just two years, and discusses how much it cost and the benefits gained. REFERENCES [Crosby79] P. B. Crosby, Quality is Free, McGraw-Hill, New York, NY, 1979. [Deming86] W. Edwards Deming, Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986. [Humphrey88] Watts S. Humphrey, "Characterizing the Software Process," IEEE Software, March 1988. [Humphrey89] Watts S. Humphrey, Managing the Software Process, Addison-Wesley, Reading, Mass., 1989. [Humphrey91] Watts S. Humphrey, Terry R. Snyder, and Ronald R. Willis, "Software Process Improvement at Hughes Aircraft," IEEE Software, July 1991. [Juran88] Joseph M. Juran, Juran on Planning for Quality, Macmillan, New York, NY, 1988. [Juran89] Joseph M. Juran, Juran on Leadership for Quality, The Free Press, New York, NY, 1989. [Paulk91] Mark C. Paulk, et. al., "Capability Maturity Model for Software," Tech. Report CMU/SEI-91-TR-24, SEI, CMU, Pittsburgh, Pennsylvania, August 1991. [Weber91] Charles V. Weber, et. al., "Key Practices of the Capability Maturity Model," Tech. Report CMU/SEI-91-TR-25, SEI, CMU, Pittsburgh, Pennsylvania, August 1991. From: mcp@sei.cmu.edu (Mark Paulk) Newsgroups: comp.software-eng Subject: SEI maturity model papers Keywords: SEI, maturity model, maturity questionnaire, process improvement Message-ID: <28376@as0c.sei.cmu.edu> Date: 9 Jul 91 16:21:00 GMT Organization: Carnegie Mellon University (Software Engineering Institute) Lines: 84 Following is a listing of selected papers and books on the software process maturity model. This may answer some of the questions that have been asked about where to find out more. I should also note that the SEI Affiliates Symposium, 27-29 Aug, will be focused on our work with software process. Technical reports that have DTIC numbers are available from the Defense Technical Information Center (DTIC) and the National Technical Information Service (NTIS). (As an example, ADA169705 is the DTIC number for the SEI report "Toward a Reform of the Defense Department Software Acquisition Policy.") If you wish to request a copy of one of the following reports, please contact either DTIC or NTIS directly. DTIC: Defense Technical Information Center ATTN: FDRA Cameron Station Alexandria, VA 22304-6145 NTIS: National Technical Information Service U.S. Department of Commerce Springfield, VA 22161 --------- Books, papers, and reports on the SEI maturity model: W.S. Humphrey, MANAGING THE SOFTWARE PROCESS, Addison-Wesley, Reading, MA, 1989. Characterizing the Software Process: A Maturity Framework, June 1987. CMU/SEI-87-TR-11, ESD-TR-87-112, ADA182895 W.S. Humphrey, "Characterizing the Software Process," IEEE Software, Vol. 5, No. 2, March, 1988, pp. 73-79. W.S. Humphrey, D.H. Kitson, and T. Kasse, "The State of Software Engineering Practice: A Preliminary Report," Software Engineering Institute, CMU/SEI-89- TR-1, DTIC Number ADA206573, February, 1989. The Role of Assessment in Software Process Improvement, December 1989. CMU/SEI-89-TR-3, ESD-TR-89-3, ADA227426 W. S. Humphrey and W. L. Sweet, "A Method for Assessing the Software Engineering Capability of Contractors", Software Engineering Institute, CMU/SEI-87-TR-23, DTIC Number ADA187320, September 1987. W.S. Humphrey, T.R. Snyder, and R.R. Willis, "Software Process Improvement at Hughes Aircraft," IEEE Software, Vol. 8, No. 4, July, 1991, pp. 11-23. R. Dion, "Quantifying the Benefit of Software Process Improvement," presentation at the Software Process Improvement Workshop, Chantilly, VA, 8-9 November, 1990. W.S. Humphrey, D.H. Kitson, and J. Gale, "A Comparison of U.S. and Japanese Software Process Maturity," PROCEEDINGS OF THE 13TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, Austin, TX, 13-17 May 1991, pp. 38-49. T. Bollinger and C. McGowan, "A Critical Look at Software Capability Evaluations," IEEE Software, Vol. 8, No. 4, July, 1991, pp. 25-41. W.S. Humphrey and B. Curtis, "Comments on 'A Critical Look'," IEEE Software, Vol. 8, No. 4, July, 1991, pp. 42-46. M.W. Bush, "Process Assessments in NASA," PROCEEDINGS OF THE 13TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, Austin, TX, 13-17 May 1991, pp. 299-304. W. S. Humphrey, "The IBM Large-Systems Software Development Process: Objectives and Direction," IBM Systems Journal, Vol. 24, No. 2, 1985, pp. 76-78. P. Fowler and S. Rifkin, "Software Engineering Process Group Guide," Software Engineering Institute, CMU/SEI-90-TR-24, September, 1990. W.S. Humphrey, "Process Fitness and Fidelity," PROCEEDINGS OF THE SEVENTH INTERNATIONAL SOFTWARE PROCESS WORKSHOP, 16-18 October 1991. W.S. Humphrey, "CASE Planning and the Software Process," Software Engineering Institute, CMU/SEI-89-TR-26, DTIC Number ADA219066, May, 1989. ---------- Some general reading on process management: W. Edwards Deming, OUT OF THE CRISIS, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986. J.M. Juran, JURAN ON PLANNING FOR QUALITY, Macmillan, New York, NY, 1988. P.B. Crosby, QUALITY IS FREE, McGraw-Hill, New York, NY, 1979. ------ Later additions to reading list (dalamb) ------ Humphrey and D.H. Kitson: ``Preliminary Report on Conducting SEI-Assited Assessments of Software Engineering Capability,'' SEI-87-TR-16, July 1987. Conducting SEI-Assisted Software Process Assessments, February 1989. CMU/SEI-89-TR-7, ESD-TR-89-7, ADA219065 From: mcp@sei.cmu.edu (Mark Paulk) Newsgroups: comp.software-eng Subject: Re: SEI maturity model papers Keywords: SEI, maturity model, maturity questionnaire, process improvement Message-ID: <28725@as0c.sei.cmu.edu> Date: 16 Jul 91 17:58:54 GMT Reply-To: mcp@sei.cmu.edu (Mark Paulk) Organization: Software Engineering Institute, Pittsburgh, PA Lines: 25 There have been a number of queries on the Baldrige restructuring for software. The gentleman who did that has not yet forwarded his analysis, and even if/when he does, it's really his place to decide whether it should be posted, and I'll ask about that. In any event, I'll post any interesting developments with ISO 9001. I can state that the SEI has been officially asked to participate in the study group on software process and ISO 9000, and Bill Curtis, the Process Program director, is following up on that. Someone here, probably Watts since he's now a Baldrige examiner, will undoubtedly write a paper on the maturity model and ISO 9000/Baldrige. I'd do it myself if I had the time, but that'll be a while, since I'm working hard on elaborating the model itself. We're currently putting a large product set together on the maturity model, etc. We haven't yet decided whether/how it will be electronically distributed, although we have been debating the issue. If we do decide to make it available to the net, I'll post the news. It will definitely be available as technical reports/papers after the SEI Affiliates Symposium 27-29 Aug. I'll post info on how to get them, even if they aren't electronically available. -- Mark C. Paulk mcp@sei.cmu.edu "Maturity is a function of scar tissue." From: mcp@sei.cmu.edu (Mark Paulk) Subject: The SEI Capability Maturity Model Date: 16 Sep 91 15:38:40 GMT Organization: Carnegie Mellon University (Software Engineering Institute) Two SEI technical reports on the CMM are available by anonymous ftp. Instructions and further information follows. Anyone running a repository is welcome to electronically distribute these reports further. The text of the cover letter which goes with the CMM follows. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 13 September 1991 To: requesters of information on the Capability Maturity Model (CMM) From: the SEI's Capability Maturity Model project Re: the CMM technical reports Dear colleague, A notebook containing two SEI technical reports on the Capability Maturity Model for Software was distributed at the SEI Affiliates Symposium 27-29 August 1991. We believe that the CMM addresses a need of the community, and we solicit your further feedback as you use these materials. The effort thus far has been intense, but we hope useful; we plan to continue to refine and improve the software process tools and methods, based on the recommendations of the software community. The citations for these two technical reports are: SEI-91-TR-24 M.C. Paulk, B. Curtis, M.B. Chrissis, et al., "Capability Maturity Model for Software," Software Engineering Institute, CMU/SEI-91-TR-24, August, 1991. SEI-91-TR-25 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, "Key Practices of the Capability Maturity Model," Software Engineering Institute, CMU/SEI-91-TR-25, August, 1991. These technical reports will be available to the software community via several avenues. Like all SEI technical reports, they will be available from the National Technical Information Service (NTIS) and the Defense Technical Information Center (DTIC). When they are cataloged and available, you will be able to obtain them by writing to: DTIC Defense Technical Information Center ATTN: FDRA Cameron Station Alexandria, VA 22304-6145 NTIS National Technical Information Service U.S. Department of Commerce Springfield, VA 22161 These reports will be available to our affiliates, in notebook format, from the SEI on a cost recovery basis. SEI affiliates and government organizations may order documents directly from the SEI by submitting a written request, accompanied by a mailing label with your return address, to: Software Engineering Institute ATTN: Publications Requests Carnegie Mellon University Pittsburgh, PA 15213-3890 You may also request these reports via e-mail. The Internet address is: cmm-info@sei.cmu.edu We plan to make electronic versions available through the Internet. To obtain these files using anonymous ftp: ftp ftp.sei.cmu.edu cd pub/cmm get quit The primary electronic version is a set of Mac Word 4.0 files, which have been compressed and formatted for net distribution using StuffIt Classic(TM) and BinHex. They are archived as SEI-91-TR-24.sit.hqx and SEI-91-TR-25.sit.hqx. There are also ASCII text versions of the files (with the suffix .ascii), but they lose much of the formatting and are very difficult to read. See the file CMM_read_me for further information on these. We encourage you to copy these reports, either by photocopy or electronically, for the internal use of your company. If you wish to use these reports as part of a commercial venture, we ask that you obtain the appropriate permission from the SEI by contacting the head of Information Management: Purvis Jackson (412) 268-7622 Internet address: pmj@sei.cmu.edu Sincerely, Mark C. Paulk The contents of file CMM_read_me.ascii: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = The CMM notebook consists of two technical reports. The various ways of obtaining these technical reports is described in the "CMM cover letter" attached to this file. This file, CMM_read_me.ascii, provides instructions for downloading an ascii version of the CMM. The ascii text of "Capability Maturity Model for Software," SEI-91-TR-24, consists of one file: CMM_model_paper.ascii The ascii text of "Key Practices for the Capability Maturity Model for Software," SEI-91-TR-25, consists of the following files and should be printed in this order. Overview.ascii overview of the key practices and how to read them ML2.ascii KP's for ml2 ML3.ascii KP's for ml3 ML4.ascii KP's for ml4 ML5.ascii KP's for ml5 Appendices.ascii the appendices to the TR You are warned that the ascii text version of the report is very difficult to read because of the loss of formatting in going from Mac Word 4.0 to ascii. I recommend that you use the Word archives, also contained in this directory, to download these reports, if you have a Mac, BinHex, and StuffIt available. There is also a bibliography of papers and books relevant to process in file process.biblio It is provided for your information and is not an SEI product. Comments and suggestions are welcome. From: mcp@sei.cmu.edu (Mark Paulk) Subject: postscript versions of SEI CMM reports requested Date: 17 Sep 91 14:42:22 GMT Organization: Carnegie Mellon University (Software Engineering Institute) I received a request from Barry Kaplan: >Mark, >Would it be possible to make available PostScript versions of SEI reports. As >stated, that ASCII versions are hard to read, and [I believe] not many people >who will get the reports via ftp will have Mac Word--postscript is pretty much >the defacto standard for ftpable documents. and from a couple of others to similar effect. Unfortunately, I'm not a Mac Word hacker (I went to the Mac with some reluctance, although it's a nice workstation, because I now have to remember 4 OS/editor/.../software sets, but it's the de facto standard here). I've asked Computing Facilities about a conversion program, since the reports were written in Mac Word, but I don't know if we have one. (All I know is that postscript is not one of the Mac Word "save as" options.) If anyone can tell me an easy way to take a Mac Word file and save it as postscript, I'll do so. From: mcp@sei.cmu.edu (Mark Paulk) Newsgroups: comp.software-eng Subject: CMM reports electronically available Keywords: CMM, software process, maturity model Message-ID: <32315@as0c.sei.cmu.edu> Date: 27 Sep 91 20:17:19 GMT Organization: Carnegie Mellon University (Software Engineering Institute) Lines: 37 A number of people have complained/commented on the slowness of ftp (or that it hung) in obtaining the CMM technical reports. This was investigated, and I am told that communications remains a black art. The problem apparently was a new ftp machine that was too fast. It was swamping a router, which lead to excessive security checks - something similar to thrashing. In any event it was suggested that fg.sei.cmu.edu should be used for anonymous ftp. I have tried to reply to everyone who has sent me e-mail on net delays, net addressing problems, etc. We are still working on getting Postscript versions of the files available. Some replies did bounce, however, so I include the following to wrap up my open action items for the net. >Subject: Re: Internet address of ftp.sei.cmu.edu >Date: Wed, 18 Sep 91 14:40:00 EDT >From: Tod Pike > >Mark: > The name "ftp.sei.cmu.edu" is actually a pointer to the machine >as0c.sei.cmu.edu. This machine has the Internet address 128.237.1.13. >If people can't get to that machine (because they can't look up it's >address), then the machine fg.sei.cmu.edu is also available. They contain >the same data.... > > The problem should only happen on MILNet sites, which still use the old >host tables. Any modern site that uses the Domain Name System should be >able to ftp to the machine ftp.sei.cmu.edu. > > Tod From: spray@convex.com (Rob Spray) Subject: Re: Software QA Survey Results Date: 26 Nov 91 15:05:49 GMT Organization: CONVEX Computer Corporation, Richardson, Tx., USA In <10250001@hpfcdc.fc.hp.com> randyc@hpfcdc.fc.hp.com (Randy Campbell) writes: >Maybe things have improved drastically in a year's time, but as recently >as late 1990 (according to an article by Pfleeger and McGowan, Journal of >Systems and Software), SEI had not identified any companies operating at >levels 4 and 5. Of course the "SEI had not identified any companies". Most SEI assessments are confidential. There's been a persistent rumor that a certain organisation of a large Blue company, located near the Johnson Space Center, scored a 5 on an SEI assessment. Some cynics have suggested that this 40-person shop was specifically set up to gain a 5 rating so that the parent company could allude to being a Level 5er. A similar phenomenon has occured with (divisions of) IBM and GM being Baldrige winners. Other observers have suggested that it was an experiment by this company, and that the costs of Level 5 were exorbitant under the current economics of government software contracting. Disclaimer: This is UseNet and these are rumors I have heard. Anyone got any facts that they are at liberty to divulge? From: mcp@sei.cmu.edu (Mark Paulk) Subject: Availability of SEI CMM reports (Postscript) Date: 18 Dec 91 22:08:04 GMT Organization: Carnegie Mellon University (Software Engineering Institute) The Postscript version of SEI-91-TR-24 and TR-25 (the CMM notebook) is at long last available via anonymous ftp. The generic cover letter and specific instructions for downloading these reports follows. = ================== 18 December 1991 Dear colleague, Thank you for your interest in our work with software process maturity. A notebook containing two SEI technical reports on the Capability Maturity Model for Software was distributed at the SEI Affiliates Symposium, 27-29 August 1991. We believe that the CMM addresses a need of the community, and we solicit your further feedback as you use these materials. We plan to continue to refine and improve the software process tools and methods, based on the recommendations of the software community. The citations for these two technical reports are: SEI-91-TR-24 M.C. Paulk, B. Curtis, M.B. Chrissis, et al., "Capability Maturity Model for Software," Software Engineering Institute, CMU/SEI-91-TR-24, DTIC Number ADA240603, August, 1991. SEI-91-TR-25 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, "Key Practices of the Capability Maturity Model," Software Engineering Institute, CMU/SEI-91-TR-25, DTIC Number ADA240604, August, 1991. These technical reports are available to the software community via several avenues. If your company is an SEI affiliate, a copy was mailed to your SEI liasion. They are available from the National Technical Information Service (NTIS) and the Defense Technical Information Center (DTIC). You may obtain them by writing to: DTIC Defense Technical Information Center ATTN: FDRA Cameron Station Alexandria, VA 22304-6145 NTIS National Technical Information Service U.S. Department of Commerce Springfield, VA 22161 The CMM notebook is also be available from the SEI on a cost recovery basis for $75 (make the check or purchase order out to Carnegie Mellon University/SEI). You may order documents directly from the SEI by submitting a written request, accompanied by a mailing label with your return address, to: Software Engineering Institute ATTN: Publications Requests Carnegie Mellon University Pittsburgh, PA 15213-3890 You may also request these reports via e-mail. The Internet address is: cmm-info@sei.cmu.edu Electronic versions are available through the Internet. If you have Internet access, you may obtain these files using anonymous ftp by entering the following: ftp ftp.sei.cmu.edu login: anonymous password: cd pub/cmm get quit The instructions for obtaining these files is contained in READ.ME. The primary electronic version is a set of Mac Word 4.0 files, which have been compressed and formatted for net distribution using StuffIt ClassicTM and BinHex. Other formats, including ASCII text and Postscript, are also available. Please note that electronic versions are only available via the network; we do not distribute these reports via floppy disk or similar media. An ASCII change request form is included in the Internet files as CMM_change_request.ascii. It may be used to submit your comments and suggestions on the CMM electronically to cmmchange@sei.cmu.edu A Postscript version is available as CMM_change_request.ps, if you prefer to send your comments in hardcopy format. We encourage you to copy these reports, either by photocopy or electronically, for the internal use of your company, provided that copies contain the appropriate SEI copyright notice and notice of government sponsorship. If you wish to use these reports as part of a commercial venture (e.g., teaching a tutorial), we ask that you obtain the appropriate permission from the SEI by contacting the head of Information Management: Purvis Jackson (412) 268-7622 Internet address: pmj@sei.cmu.edu Sincerely, Mark C. Paulk Project Leader Capability Maturity Model Project = =========================== READ.ME Instructions on downloading TR-24 and TR-25. The CMM notebook consists of two technical reports: SEI-91-TR-24 M.C. Paulk, B. Curtis, M.B. Chrissis, et al., "Capability Maturity Model for Software," Software Engineering Institute, CMU/SEI-91-TR-24, August, 1991. SEI-91-TR-25 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, "Key Practices of the Capability Maturity Model," Software Engineering Institute, CMU/SEI-91-TR-25, August, 1991. The various ways of obtaining these technical reports are described in the file CMM_cover_letter.ascii This file, CMM_read_me.ascii, provides instructions for downloading ASCII, Postscript, or MacWord versions of the technical reports. There is a change request template in the file CMM_change_request.ascii which you may use for electronically submitting your comments and suggestions. Please address them to cmmchange@sei.cmu.edu You may also use the Postscript version of the form in CMM_change_request.ps There is a bibliography of papers and books relevant to process in the file process.biblio It is provided for your information and is not an SEI product. Comments and suggestions are welcome. There is an electronic copy of the 1987 maturity questionnaire in the file mq.v0 There is a mapping of the 1987 maturity questionnaire to the CMM in the file mqv0_cmm.map = = = ASCII The ASCII text of "Capability Maturity Model for Software," SEI-91-TR-24, consists of one file: CMM_model_paper.ascii The ASCII text of "Key Practices for the Capability Maturity Model for Software," SEI-91-TR-25, consists of the following files and should be printed in this order: CMM_Overview.ascii overview of key practices and how to read them CMM_ML2.ascii KP's for ml2 CMM_ML3.ascii KP's for ml3 CMM_ML4.ascii KP's for ml4 CMM_ML5.ascii KP's for ml5 CMM_Appendices.ascii the appendices to the TR You are warned that the ASCII text version of the report is very difficult to read because of the loss of formatting in going from Mac Word 4.0 to ASCII. I recommend that you use the Word archives, also contained in this directory, to download these reports, if you have a Mac, BinHex, and StuffIt available, or the Postscript version. = = = MacWord The primary electronic version is a set of Mac Word 4.0 files, which have been compressed and formatted for net distribution using StuffIt Classic(TM) and BinHex. The archives are: SEI-91-TR-24.sit.hqx SEI-91-TR-25.sit.hqx Since the last shareware version of StuffIt was 1.5.1, for wider compatibility the StuffIt archives are now in that version. There is also a 1.6 version in the archives TR-24-1.6.sit.hqx and TR-25-1.6.sit.hqx for those people who have the later version. These archives contain the same files as the ASCII versions (except for the .ascii suffix, of course), plus the CMM cover letter, title pages, and a change request form, all in Mac Word 4.0 format. The Mac Word 4.0 files use Palatino font, by the way, and you should use Mac Word 4.00b (the latest version we have) to get the right spacing from the headers. = = = Postscript The Postscript versions are in files TR24.ps and TR25-Overview.ps TR25-KP-titles.ps TR25-ML2.ps TR25-ML3.ps TR25-ML4.ps TR25-ML5.ps TR25-Appendices.ps -- Mark C. Paulk (412) 268-5794 Internet: mcp@sei.cmu.edu Project Leader, Capability Maturity Model Project Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA 15213-3890 Article 7823 of comp.software-eng: Path: mimsy!nsisrv!ames!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!sei.cmu.edu!mcp From: mcp@sei.cmu.edu (Mark Paulk) Newsgroups: comp.software-eng Subject: SEI technical reports Keywords: SEI, reports Message-ID: <36831@as0c.sei.cmu.edu> Date: 18 Dec 91 22:13:10 GMT Organization: Carnegie Mellon University (Software Engineering Institute) Lines: 20 The following message was posted in a more detailed form on our bboard. I pass it along to the group FYI. Postscript versions of the SEI documents are now available via anonymous ftp. These postscript files live in directories within pub/documents and the machine name is ftp.sei.cmu.edu As new SEI reports are created, postscript files will be generated and archived appropriately in pub/documents. (And the same is true with older reports where postscript versions may yet need to be generated -- as the postscript files are generated, copies will be archived into the appropriate ftp directory.) A longer version of this message, listing the reports available, has been posted to comp.doc.techreports. -- Mark C. Paulk (412) 268-5794 Internet: mcp@sei.cmu.edu Project Leader, Capability Maturity Model Project Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA 15213-3890 From: mcp@sei.cmu.edu (Mark Paulk) Subject: Availability of SEI CMM tech reports Date: 31 Jan 92 20:52:09 GMT Organization: Carnegie Mellon University (Software Engineering Institute) I have cleaned up the pub/cmm directory, separating the reports out into separate subdirectories. Instructions are in a READ.ME file which follows: READ.ME Instructions on downloading TR-24 and TR-25. The CMM notebook consists of two technical reports: SEI-91-TR-24 M.C. Paulk, B. Curtis, M.B. Chrissis, et al., "Capability Maturity Model for Software," Software Engineering Institute, CMU/SEI-91-TR-24, August, 1991. SEI-91-TR-25 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, "Key Practices of the Capability Maturity Model," Software Engineering Institute, CMU/SEI-91-TR-25, August, 1991. The various ways of obtaining these technical reports are described in the file CMM_cover_letter.ascii This file, READ.ME, provides instructions for downloading ASCII, Postscript, or MacWord versions of the technical reports, as well as various other items that may be of interest. The files are contained in various subdirectories: ascii Postscript MacWord Misc as described in the following instructions. = = = ASCII versions contained in subdirectory "ascii" The ASCII text of "Capability Maturity Model for Software," SEI-91-TR-24, consists of one file: CMM_model_paper.ascii The ASCII text of "Key Practices for the Capability Maturity Model for Software," SEI-91-TR-25, consists of the following files and should be printed in this order: CMM_Overview.ascii overview of key practices and how to read them CMM_ML2.ascii KP's for ml2 CMM_ML3.ascii KP's for ml3 CMM_ML4.ascii KP's for ml4 CMM_ML5.ascii KP's for ml5 CMM_Appendices.ascii the appendices to the TR You are warned that the ASCII text version of the report is very difficult to read because of the loss of formatting in going from Mac Word 4.0 to ASCII. I recommend that you use the Word archives, also contained in this directory, to download these reports, if you have a Mac, BinHex, and StuffIt available, or the Postscript version. = = = MacWord versions contained in the subdirectory "MacWord" The primary electronic version is a set of Mac Word 4.0 files, which have been compressed and formatted for net distribution using StuffIt Classic(TM) and BinHex. The archives are: SEI-91-TR-24.sit.hqx SEI-91-TR-25.sit.hqx Since the last shareware version of StuffIt was 1.5.1, for wider compatibility the StuffIt archives are now in that version. There is also a 1.6 version in the archives TR-24-1.6.sit.hqx and TR-25-1.6.sit.hqx for those people who have the later version. These archives contain the same files as the ASCII versions (except for the .ascii suffix, of course), plus the CMM cover letter, title pages, and a change request form, all in Mac Word 4.0 format. The Mac Word 4.0 files use Palatino font, by the way, and you should use Mac Word 4.00b (the latest version we have) to get the right spacing for the headers. = = = Postscript versions contained in the subdirectory "Postscript" The Postscript versions are in files TR24.ps and TR25-Overview.ps TR25-KP-titles.ps TR25-ML2.ps TR25-ML3.ps TR25-ML4.ps TR25-ML5.ps TR25-Appendices.ps WARNING: The first line in the Postscript file has to be edited to be %! (Adobe version number removed) to work correctly when moving from Mac to Unix systems. When I update/insert new versions of the Postscript files, in the various directories, I may forget to make this edit. If you have problems printing any .ps files, check this before contacting me (but please send e-mail so I can make the correction for others). Thanks, mcp. = = = Miscellaneous items contained in subdirectory "Misc" There is a change request template in the file CMM_change_request.ascii which you may use for electronically submitting your comments and suggestions. Please address them to cmmchange@sei.cmu.edu You may also use the Postscript version of the form in CMM_change_request.ps There is a bibliography of papers and books relevant to process in the file process.biblio It is provided for your information and is not an SEI product. Comments and suggestions are welcome. There is an ascii copy of the 1987 maturity questionnaire in the file mq.v0 There is a mapping of the 1987 maturity questionnaire to the CMM in the file mqv0_cmm.map There is a Postscript version of a paper entitled "Software Process Assessments: Issues and Lessons Learned" to be presented at ISQE92 in SPA-Lessons-Learned.ps From: mcp@sei.cmu.edu (Mark Paulk) Subject: Re: SEI, software process maturity ? Date: 5 Feb 92 12:04:10 GMT Organization: Software Engineering Institute, Pittsburgh, PA We get asked fairly often, "Where is the new maturity questionnaire?" There are a couple of different things going on. 1. We want people to focus on the capability maturity model. By releasing it first and telling people that we're putting together a suite of process assessment/evaluation products based on the CMM, we're providing a transition time to become comfortable with the basic material. Hopefully, organizations will focus their action plans on addressing the practices in the model rather than changing a No answer on the questionnaire to Yes (which tends to be what managers would like to do to get a good score, but misses the point of installing/improving good engineering and management processes to help do the job better). 2. We want to build a set of reliable, consistent instruments to support assessments and evaluations. The MQ is only one of these instruments. Because it has been the embodiment of the model to many people since 1987, it tends to be a focus point of concern, but the MQ is only valid in the context of its proper use in an assessment and evaluation. It's a springboard to focus attention on problems at the beginning of the assessment/evaluation process. We have acquired some expertise to help us computer types understand the behavioral issues, and we're going through a pilot testing phase. Yes, this does involve prototypes of new MQs, but we're only distributing them to our pilot test partners. We have about 60 companies who've volunteered to help us out with clarity testing, protocol analysis, field testing, etc. So the answer is, there is no revised MQ publicly available at this time. The official release is still the 1987 version. When we release a new MQ, as part of a product suite, I'll post the info on comp.software-eng. From: steves@IMD.Sterling.COM (Steve Scheuber) Subject: Larry Druffle comments on process assessments Organization: Sterling Software, IMD In the SEI's December 91 issue of Bridge, Larry Druffle, the Director of the Software Engineering Institute, discussed the role of software process assessments (and the maturity questionnaire) in an improvement effort. IMHO his comments are are pertinent to this thread. In case your wondering, "Material in Bridge may be reproduced without permission provided that credit is given to the SEI and its sponsor, the U.S. Department of Defense." Credit is so given... :) =======begin Druffle comments==================================== First, the principle motivation for our work [the SEI's] is to enable organizations to improve their software process, not simply to get a score. Second, process improvement is a journey that takes several years, not a quick fix. ...The Capability Maturity Model, which consists of key practices, is the basis for our software process efforts. Our questionnaire is designed to highlight strengths or weaknesses in the implementation of those practices. The Questionnaire serves as an important first step in an assessment. One result of scoring the questionnaire as a number from one to five is that an organization has an indication of its relative maturity. The most important aspect of an assessment is that it serves as the basis for an improvement plan. The priorities for that improvement are established to increase an organization's capability for developing and maintaining software improvement. Unfortunately, in some cases, the focus has been on the assessment and the resulting score. An analogy in the academic system is the unfortunate focus on tests and grades. As we all understand, grades are not the ultimate goal. Learning is the goal. To the extent that a test illuminates the weakness in understanding, it offers guidance to the student to improve. The grade is only an indication that a certain level of learning has been achieved. By the same token, the goal of a process assessment is to establish the basis for improvement. My second point [is that] software process improvement takes time and resource commitment. Our experience to date is that it takes a significant amount of time, along with commitment by managers, for an organization to put key practices in place throughout the organization and to make those practices become institutionalized. Those who have experienced the attendant improvements are unanimous in their assessment that (a) the amount of effort is significant and (b) the benefits are worth the effort. My message is simply this: The purpose of an assessment is to serve as the basis for an improvement effort. The effort is significant but the benefits are worth the investment. -Larry Druffle, Director of the Software Engineering Institute ================================================================== I do not represent the SEI, nor pretend to. -- From: rms@miles.com (Rob Schultz) Subject: SEI Level for New Organization? Date: 16 Jun 92 21:15:08 GMT Organization: Miles Inc., Diagnostics Division, Elkhart, IN I am familiar with the SEI Maturity Index, and I realize that an organization cannot skip levels (a level 1 organization *must* become a level 2 organization before it can become a level 3 organization). What happens, however, when a new organization is started, either as a new company, or a new group within a company? If the new group consists mainly of people who are experienced in fairly mature organizations, and they take a reasonable amount of time to prepare, would it be possible for the new organization to have everything in place to start off at level 3 or 4? Does it make a differnce if those forming the new group come from the same or different (mature) groups? Does anyone have any experience with this? It is my general feeling that the group could start off as high as level 4 (since level 5 is really just demonstrating level 4 techniques over a period of time). From: croes@imec.be (Kris Croes) Subject: Re: SEI Level for New Organization? Date: 17 Jun 92 07:17:45 GMT Organization: IMEC vzw, Leuven, Belgium Here is my contribution. New company: possible, and preffered at level 4. I think that a company that starts off at level 4 can not be anything else than successfull. I would do it anyhow, if I would start a new company. The first thing what I would do is to make sure (procedures,...) that level 4 was attained, even before I hired the first guy that wrote the first letter of software. New group within a company: If I had to start up a new group, I would try to do it at level 4 anyhow (see above). Here comes the difficult (although well known) part: YOU'VE GOT TO CONVINCE MANAGEMENT BEFORE THESE THINGS WORK. Humphrey writes: "The best test is to observe how such an organization behaves in a crisis". One of the crisises that could occur is that your boss asks for results (spinning of wheels). Even though the management inside the new group can be convinced that they have to be in level 4, they should not get sacked by their bosses in that "crisis situation". Similar Maturity Levels can be defined for all activities in a company. That new group will have to stick to the level that the entire company is in. From: claird@NeoSoft.com (Cameron Laird) Subject: Re: SEI Level for New Organization? Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Wed, 17 Jun 1992 18:46:23 GMT In article <1751@imec.UUCP> croes@imec.be (Kris Croes) writes: > YOU'VE GOT TO CONVINCE MANAGEMENT BEFORE THESE THINGS WORK. Juvenile tangent: we all believe that operating at higher levels, and disciplined structured analysis, and cleanroom methods and re-engineering and ... are Good Things, because they save resources and improve Quality. Have we included the cost of battling Management? Some--few--advocates of modern approaches to software engineering are rather irritating in their zealotry, for the message they give is, "This is a better Way, but {management,old-time programmers,...} is stupid and refuses to see that." Perhaps the Way isn't what it should be, if {management, programmers, ...} can't see its superiority, even after all the preaching. I summarize: perhaps M. Cusumano is right to describe software engineering in terms of management goals and commitment. If we believe in top-down analysis, and quality control, we need to spend more time there, doing the hard work of understanding management's viewpoint(s), and less time fussing with details of structure chart icon selection. From: martinc@grover.cs.unc.edu (Charles R. Martin) Subject: Re: SEI Level for New Organization? Date: 18 Jun 92 14:28:31 GMT Organization: /theta/theta5/unc/martinc/.organization In-reply-to: claird@NeoSoft.com's message of 17 Jun 92 18:46:23 GMT In article <1992Jun17.184623.6668@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes: Juvenile tangent: ... Not so juvenile at all. On my last Real Job, our customer started coming out to visit us about once every two weeks, brings requirements changes, wanting to meet with the programmers, auditing the unit-development folders, and so on. We eventually had to establish a charge number for dealing with dippy management at the client. ...." Perhaps the Way isn't what it should be, if ... can't see its superiority, even after all the preaching. We often don't "pitch" SE improvements in a way that makes much sense to management -- we tell them how wonderful it will be, but what they care about is what it'll cost. Thus my argument for using costing data to sell Cleanroom a few notes ago. ... doing the hard work of understanding management's viewpoint(s), and less time fussing with details of ... You bet. Figure out what *management's* reward structure is and show them how new methods will get them greater rewards. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Level for New Organization? Date: 19 Jun 92 22:03:02 GMT In article <1992Jun16.211508.6815@miles.com> rms@miles.com (Rob Schultz) writes: >New company: possible, and preffered at level 4... If this were possible, why would every new software company take this stance and just start at level 4, instead of starting up at the bottom and working through the transitions just like everyone else. Indeed, why wouldn't existing companies take all their profits and create new companies at this level and then transfer their software too it, rather than spending a few years slogging up the curve. I believe that it may be because it is either not possible, or because it would only be possible by predefining such a confining process that you wouldn't be able to take advantage of the special skills and capabilities of the people you hire, or the products you can acquire. To have a managed process, you must have three things: a defined process (i.e. a plan for how things SHOULD be done) and a means of monitoring the actual process, and a way to intercompare the desired process with the actual process and to either adjust the desired process (if it was wrong) or adjust the actual process (if people didn't follow a plan that should have been correct). It is hard for a new organization to have a defined process, because you don't know the characteristics of the people you will be able to hire, the users who will buy or use the products, etc. Indeed, the reason that companies take so long to go up the curve is that it is very easy to overlook small details that in the end with hamstring your project. In my experience, when comparing the plan (or pre-defined model) which conflicts with the actual process--it is generally (though not alway) the model that was in error. If you have no history (and new organizations don't) it is hard to define a process without such flaws. So, you can't afford to enforce the defined process until it has been further debugged--this pulls you off level four. Alternatively, you might define an ideal process and stick with it, and then hire the people, etc. But try as you might, you probably won't find all the people you want with precisely the same predefined characteristics--therefore there will be "friction" occuring where the people's capabilities and motivations don't exactly match what the predefined process expected. Similarly, you may get feedback from early customer prospects, or users, that suggest that you made the wrong tradeoffs between development time, quality and functionality, etc. which causes friction between your process and deliverable goals. A new company that pursues such a process, even if at level four, can indeed fail in the same way that an auto manufacturer with a robot factory that produces large cars when people only want to buy small ones can fail, or if the factory was designed to develop metal parts and is suddenly given some ceramic ingots... A final reason that companies don't just start at level four is that you face a tradeoff between process being more important than product. Of course, while process can affect your product development costs, not having a product means no revenue at all. Business pressures naturally encourage companies to therefore try to accellerate delivery of product as much as possible so that income can fund additional work. From: tim@hpfcbig.SDE.HP.COM (Tim Mikkelsen) Subject: Re: SEI Level for New Organization? Date: 19 Jun 92 17:28:31 GMT Organization: HP SESD, Fort Collins, CO It may be possible to start out high (given the technical and managerial people that make up the company). However, it strikes me that there is a danger of slipping into the lower levels as the organization grows. If care is not taken to bring the new staff into 'higher level culture', this would happen even with like-minded new employees. It also seems that new companies would need to forgo some high growth opportunities. (So, a company funded by venture capital may be forced into fast growth which would cause a drop in level.) From: sr@seas.gwu.edu (Stan Rifkin) Subject: Re: SEI Level for New Organization? Date: 21 Jun 92 23:30:16 GMT Organization: George Washington University When I was the SEI, we *almost* had a chance to try this. There was an organization that *no* employees in the proposed site city that had (perhaps remarkably) won a DoD contract, and therefore could potentially start at a level higher than 1. We made a plan for them to start at level 3, before the contract was canceled before starting. From: rms@miles.com (Rob Schultz) Subject: Re: SEI Level for New Organization? (LONG) Organization: Miles Inc., Diagnostics Division, Elkhart, IN Date: Mon, 22 Jun 1992 15:00:38 GMT In article <53328@athertn.Atherton.COM> mcgregor@netcom.com writes: >If this were possible, why would every new software company take this stance >and just start at level 4, instead of starting up at the bottom and working >through the transitions just like everyone else. There are several reasons why every new company couldn't do this: 1. Start-up management not convinced of need. 2. New company can't find sufficient number of people experienced in both the software area of interest (comms, medical, flight control, etc.) *and* in a mature development organization to provide the impetus and inertia to start and continue at a high maturity level. 3. As noted below, development schedule pressures can often cripple efforts to improve the process. This is at least as much of a problem in existing companies, however, where there is a well-entrenched culture of reducing development time at the expense of development process improvements. >Indeed, why wouldn't existing companies take all their profits and create new >companies at this level ... In a sense, existing companies are already doing this when new projects are started with a side-goal of using/defining an improved process. These projects have a decided advantage over a start-up company in that they have the financial backing of an existing company to pay the bills during the research/ development phase. These projects also have the advantage of a large pool of human resources to pull from. These new people (both engineers and managers) are far more likely to give such a project a shot since the cost of failure is generally very low. (In contrast, the cost of failure in a start-up can be very high: loss of retirement/benefits/salary/etc are big disincentives for people thinking of changing companies, especially if the new company has an inordinate amount of risk attached, such as trying an entirely new process.) Among the qualities of a Level 4 (Managed) process are the ability to decide when new technologies are appropriate and a mechanism for introducing those new technologies. As far as using the special skills of new people, I don't think that the model adresses this issue, so both a new company/project and an existing company crawling up the ladder have the same problem. >[inclusion re problems of a new company deleted - DAL] But these are exactly the same problems that an existing organization has with improving its process. For example, an organization that I know of is just starting to drag itself out of the depths of chaos. They have taken that all- important first step and written a set of Software Development Procedures. These procedures are very detailed, and even include Coding Standards for C and PL/M. The problem is that they have no mechanism for addressing the problems of C++ and Assembly language, nor do they have a mechanism for introducing new coding standards for any new language they might be using. >[tradeoff between process and product deleted - DAL] Again, these problems are common to existing companies trying to bootstrap themselves into higher maturity levels and new companies trying to start off at a high maturity level. I still think that existing companies spawning off new projects have the best chance of starting them at a high maturity level. It is possible that these new projects can then be used as models for continual improvement on existing projects. From: rms@miles.com (Rob Schultz) Subject: Re: SEI Level for New Organization? Organization: Miles Inc., Diagnostics Division, Elkhart, IN Date: Mon, 22 Jun 1992 15:11:42 GMT In article <440027@hpfcbig.SDE.HP.COM> tim@hpfcbig.SDE.HP.COM (Tim Mikkelsen) writes: >... it strikes me that there is a danger of slipping into the lower levels as > the organization grows. One of the requirements for a level 3 (Defined) organization is a required software engineering training program for software developers. This should help to prevent 'backsliding'. The fast growth problem can affect maturity because the money may not be available in a start-up to effectively train a large number of new employees. I am not sure how to overcome this. Note that the requirements for a level 3 organization carry over for a level 4 organization, so that a level 4 organization cannot 'forget' the requirements for levels 2 & 3. From: rms@miles.com (Rob Schultz) Subject: Re: SEI Level for New Organization? Organization: Miles Inc., Diagnostics Division, Elkhart, IN Date: Mon, 22 Jun 1992 15:16:44 GMT In article <1992Jun21.233016.15095@seas.gwu.edu> sr@seas.gwu.edu (Stan Rifkin) writes: >When I was the SEI, we *almost* had a chance to try this. Could you post any generalizations about this (almost) experience? What additional costs were incurred because of the maturity level? What did the plan look like? Was the contract cancelled because of costs or did it have nothing to do with the company but rather the whims of the U S Government? Was there ever a report issued on this project? (Please do not post any confidential information or information that could identify the company.) Some of these details would be extremely helpful to those of us working on this problem. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Level for New Organization? (LONG) Date: 23 Jun 92 21:44:55 GMT In article <1992Jun22.150038.23012@miles.com> rms@miles.com (Rob Schultz) writes: > But these are exactly the same problems that an existing organization has > with improving its process... I agree these are the problems common to existing companies trying to bootstrap themselves into higher maturity levels. In other words, these problems are those that characterize existing at the lower maturity levels, and wanting to improve. Thus if a new company has these problems it can't be "at level 4" in any meaningful sense when it is behaving exactly the same as an existing company that you would claim is at a lower level. This is why I say that all organizations must start at the bottom, and can only work their way up as they get experience. You can't have a "repeatable" process until you've done something at least once so you can repeat it (and therefore when you are brand new you can't possibly be at level 2). You could potentially "define" an abstract process without knowing if it can work (level 3), though doing so is meaningless except theoretically. And you can't manage it (i.e. compare with actuals, level 4) until you have some actuals to compare with (i.e. level 2 data)--but as we pointed out that can't happen till you have done it once--which implies not a brand new organization. I'll grant you that you might be able to hire more motivated, experienced people, willing to do the kinds of activities that are required at level 4--and because of their willingness (and the fewer number of entrenched people to overcome) they might climb the maturity latter more quickly than other companies--but they still have to climb it through experience. Plans, such as for a training program or design guidelines, etc., are part of what enables you to be at a given level, but they aren't sufficient. In just the way, you can't take a newborn baby and make it start with an adult's maturity level just by purchasing adult size clothing and signing it up for a college lecture class. Similarly, a new company, with no employees hired yet, with a plan to send everyone (eventually, once hired) to software engineering class, and an untested code standards document doesn't advance to level 4 by that plan alone--you have to implement the plan--and survive! An existing company that had a similar plan and document, but which no one had taken that class (yet) and no one had read that document (yet) wouldn't be promoted to a higher level for having the proper plan clothing alone, and a new organization isn't different in any meaninful sense, so I claim that they are both at the lower levels. As yet unimplemented verbal/written commitment in a new organization is indistinguishable from lip service support in an existing one. Only results determine a meaningful level of maturity--and results are the one thing a new organization doesn't have. I'd dearly love to start a brand new organization at an elevated level, and I am sure that I could find many other experienced and motivated people to join me. But I'm humble enough to realize that despite our good intentions we won't know if what we are doing is doable with that group of people and tools and market, let alone repeatable, until we finish doing it once. From: bassler@informatik.uni-stuttgart.de (Thomas Bassler) Subject: Re: SEI Level for New Organization? Date: 22 Jun 92 07:23:03 GMT Organization: University of Stuttgart, FRG In article <53328@athertn.Atherton.COM>, mcgregor@netcom.com (Scott L. McGregor) writes: >[process/product tradeoff] I would argue that this last point doesn't mean companies cannot start off at level 4, but rather that evolving from level 1 to level 4 means changing an initially labour-intensive process to a more cost-intensive process. Thus, any organization wanting to start off at maturity level 4 has to invest large amounts of money just to ensure an appropriate development environment (including spending lots of person months to define guidelines for software development and software process management, to establish metrics a.s.o.). Nevertheless, I would agree that starting off at level 4 is impossible due to lacking experience with the performance of the newly formed organization. On the other hand, level 2 (repeatable) should be possible, and even level 3 (defined), I suppose. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Level for New Organization? Date: 30 Jun 92 17:13:56 GMT In article <22322@ifi.informatik.uni-stuttgart.de> bassler@informatik.uni-stuttgart.de (Thomas Bassler) writes: > Nevertheless, I would agree that starting off at level 4 is impossible due to Theoretically, I can agree with you, but practically these designations are meaningless for a new organization. How could you tell whether you were really repeatable or not until you had actually completed something (and documented the creation well enougy) to repeat. It is like at the start of the some sport season a brand new team claiming "We are unbeaten so far, and (because we did the right things in preseason training) we are therefore unbeatable". Until you prove it, it is just a boast, even if you have assembled all the right players and coaches, and special equipment and mental and physical training, etc. Assembling all the right players, etc. is helpful, maybe even necessary to achieving the goal of winning every game, but that alone doesn't assure it. I'd be hestitant to award the title before success had been demonstrated on the playing field. I think that this attempt to declare a new organization level 2, 3, 4 or 5--before they have demonstrated a single success is doing the same thing, boasting in the absence of demonstrable proof. Similarly, in what sense does it matter that you can "define" an arbitrary process, when you don't know it is useful to the new and particular needs of the new organization. You can define a utopia on paper, but it doesn't really measure up until it is working in the real world. By that time of course the organization isn't brand new any more. From: terry@aslws01.asl.dl.nec.com (Terry Bollinger) Subject: SEI Process Utopia (Was: SEI Level for New Organization?) Date: 1 Jul 92 15:55:55 GMT Organization: NEC America, Inc. Irving, Texas In article <53971@athertn.Atherton.COM> mcgregor@netcom.com writes: > ... You can define a utopia on paper ... Hmm. I wonder, does all of this mean that brand-new organizations and small timers might as well close up shop before they begin? Even if they are, say, a tiny group like the collection of five or so highly experienced programmers who orginally developed the popular and increasingly important tool FrameMaker? Or Unix? Or C? Or spreadsheet programs? Or who knows how many other small to middle size software products that have made a significant impact in the computer market? And what of the individual programmer -- the truly one-man shop? When I think back on some of the most impressive code development efforts that I've seen in day-to-day commercial environments, it's kind of hard to ignore the huge impact one application-experienced, quality conscious individual can make in terms of quality, productivity, and customer acceptance of the final product. Odd. Why is it that so many of the software products that have had truly significant impacts in the commercial marketplace were developed by people, processes, or even entire organizations that clearly don't qualify for anything but an F (Level 1) on the SEI process test? The quote mentions the dangers of creating "paper utopias" in deciding the maturity of a new organization. Good point, and I like the idea. Thus a "paper utopia" is one in which substantial claims have been made in the absence of any clear, bottom-line results to back up those claims? Hmm... I wonder, how exacty does the SEI Process Maturity Model itself rate under such a definition? Its basic premise -- that a very close analogy of software to assembly- line production of watches or copper sheets will make the software industry "mature" -- is an intriguing research premise, but was it ever actually proven rigorously by with extensive collection of data and (especially) bottom-line productivity and quality results? Do we truly achieve the excellent objectives of Demings/Juran style quality by simply brushing away any differences and teaching software developers to adapt to the mental equivalent of repetitive motion syndrome? Or do we take the Demings/Juran model *really* seriously and work very hard to understand why software and other design-intensive activities seem to be as stubbornly dependent on having good, experience people as they are on good management and documentation practices? From: rms@miles.com (Rob Schultz) Subject: Re: SEI Level for New Organization? Organization: Miles Inc., Diagnostics Division, Elkhart, IN Date: Wed, 1 Jul 1992 13:48:22 GMT There has been much discussion here about my recent proposal to start an organization at a high maturity level. The consensus seems to be that until an organization has been through at least one project, you cannot say what level it is at. I think I can agree with this, although several other questions then come to mind. First, does this mean that maturity levels are meaningless until a group has some real experience? That is, instead of being a level 1 organization, should a new group simply be considered "too new to classify"? The main problem I have with rating a new organization at level 1 is that all new organizations are at a distinct disadvantage WRT government or other contracts/sales when competing with an established organization. This extends to groups within a company as well. New organizations may in fact have a much better and more advanced development process than existing organizations, but the new group has to be classified at level 1 while the existing group may be at level 3. This makes it much harder for the new group to get the contract. Next question: At what point can a group be re-assessed and attain a higher rating? It has been established that the SEI model does not allow an organization to skip levels. Does this mean a new orgnization must start out at level 1, then be assessed at level 2, then level 3, etc? How often can these assessments take place? It would seem to me that a new assessment only makes sense after completion of a project (otherwise, the group has not tested the new process thoroughly). This means that it would take at least 3 projects before a group can be considered a level 4 group. In a typical environment, this would likely take a minimum of 5 to 8 years, much longer for a group which takes on larger projects. Indeed, some groups only work on one project, and then are disbanded (except for maintenance). These groups can thus never attain a maturity level higher than Initial, even though other organizations within the same company are operating at a Managed (4) or Optimizing (5) level. Is this a flaw in the model, or in my understanding of the model? Thanks for any input - From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) Subject: Re: SEI Process tapioca. Date: 1 Jul 92 13:42:49 EST In article <1992Jul1.155555.14391@asl.dl.nec.com>, terry@aslws01.asl.dl.nec.com (Terry Bollinger) writes: > Even if they are, say, a tiny group like the collection of five or so ... I think that this is somewhat of a strawman. It is very clear that small groups can have a major impact. It also seems to be clear that none of these groups stayed at that size to continue the experiment. Was it impossible to do so? In addition, has the "small group developed" tool remained stable when it was not released and controlled by some organization, i.e., Unix and C? Many a small organization deals with the level 3 and 4 issues without calling them that. And for a small group, the institutional memory appears to usually be sufficient to keep the group on track. Again, with a product like C or Unix, as it grew outside of the originators' control, it diverged, and became a series of products (good, bad? - dunno, but maintainable as a unit? - don't think so). > And what of the individual programmer -- the truly one-man shop? ... Please quote size of, etc. The space shuttle is a fairly impressive achievement, and a reasonably high quality levels. Of course so are the Voyagers, and they are one man shops, essentially. Also, please note the individual that you identify in this paragraph. How many people around you, and in the industry, really satisfy those criteria. This is not a knock. The main issue is in application knowledge. Most people don't have it and one of the failings of the software industry is often people writing software think that they do because it's "software'. Well, it ain't, seee! (8:-)) Point to make. I spent 25% of my time in the field in one industry. I know that this was insufficient to know the application field as well as I needed to. It is a failure of the industry that many engineers have a lot less time to spend on gaining application knowledge than this. > [ significant impact from organizations at level 1 - DAL] I would not argue with people, but the processes and organizations that you mention here, I would like to have some examples. You have indicated that small groups can have large impacts, and I agree. I guess that I would be asking for examples of large (generally chaotic) organizations or processes that have produced the successes of which you speak. This may be obvious to many people but I am insufficiently knowledgable in the field of large developments like this. I would like to know their history. > ...how exacty does the SEI Process Maturity Model itself rate? The SEI CMM is a classical improvement model applied to software. It rates as a measuring scale for process improvement well within other models applied to other processes. > Its basic premise -- that a very close analogy of software to assembly- > line production of watches or copper sheets will make the software > industry "mature" ... I do not think that this is the basic premise of the CMM. (OK, SEI folks, time to jump in!) I think that it is process improvement, and Humphrey gave a classical scale in software terms, mapped into software activities that can proved useful in figuring out where you are and where you want to go. The CMM is not asking for repetitive motion, it is asking for engineering discipline applied to software. It is asking for quantitative, embedded institutional memory of events. It is asking for measurement and proof of what you are doing. How about accepting the CMM as a place to start, and then apply the process of measurement? If it ain't perfect, then let's use measurement to correct and improve. (BTW, I have not been paid off by the SEI.) I would turn your question around. What makes you think that the intellectual processes that are so important to sw are not applied by many people in many industries who have successfully used the DJ methods? Prove to me that sw is different. > Or do we take the Demings/Juran model *really* seriously and work very > hard to understand why software and other design-intensive activities > seem to be as stubbornly dependent on having good, experience people > as they are on good management and documentation practices? Don't fool yourself. Every industry requires these people. From: johnm@cory.Berkeley.EDU (John D. Mitchell) Subject: Re: SEI Level for New Organization? Date: 2 Jul 92 03:11:59 GMT Organization: University of California, at Berkeley In article <1992Jul1.134822.29549@miles.com> rms@miles.com (Rob Schultz) writes: [...] >The consensus seems to be that until an organization has been >through at least one project, you cannot say what level it is at. Yep. >... instead of being a level 1 organization, should a new group simply be > considered "too new to classify"? Yep. >... all new organizations are at a distinct disadvantage WRT government or >other contracts/sales when competing with an established organization. This is true only if (as is the case with a lot of government work) those selecting are rigidly dogmatic about the whole "must be an organization of level X or greater on the Y classification scale". If they have a brain then that will be only one part of their selection process. :-) > At what point can a group be re-assessed and attain a higher rating? I think that you're confusing the statement that the *organization* must transition through each level to get to the next (i.e. the skills, techniques, whatever of all of the levels preceding a given level are necessary to be at that level). This has nothing to do with assesment process. If your hot new company does a single project and has established a level 4 (not 5 because that's an on-going thing) development process by the end then an assesment could be made at that time saying so. From: jch@genrad.com (John C. Howland) Subject: Re: SEI Level for New Organization? Date: 2 Jul 92 13:01:53 GMT Organization: GenRad, Inc. Although the discussion on SEI levels for new organizations is healthy, do not lose sight of the true goal: to deliver top quality software products at a profit that meet customer needs and expectations. We have done SEI assessments internally a couple of times. The VALUE of the assessment is not the number. The value is what you LEARN about your processes and where you can improve over the next 6 to 18 months. If I were starting a new organization, I would use the SEI recommended practices as a guideline for setting up the fundamental policies and processes. I'd be sure that level 2 was covered first. Most try to shoot for level 3 & 4 activities before they can manage and track a project. From: casavant@elmer.orl.mmc.com (John Casavant) Subject: Re: SEI Level for New Organization? Date: 2 Jul 92 11:49:05 GMT Organization: Martin Marietta It appears that the words "new organization" are continually being defined as a seminal company (one just starting -- without prior working knowledge of the SEI maturity schema). It is my opinion that a new company with work experience in a previous organization (ie. our current positions (as analysts/designers/ et. al.) can and would probably have the experience and possibly even a Level 3 defined process in place. Most of us here on the net, with 100's of years of combined experience could probably 1.) create a defined process that conforms to the SEI level 3 rating, 2) start a new company and implement that defined process. As with most thing we do not work in static environments an even the best known defined process will require change in a dynamic "real world" situation. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Level for New Organization? Date: 2 Jul 92 18:27:00 GMT In article <1992Jul1.134822.29549@miles.com> rms@miles.com (Rob Schultz) writes: > ... new groups "too new to classify"? That seems reasonable. >... all new organizations are at a distinct disadvantage WRT government or > other contracts/sales when competing with an established organization. I understand what you are saying. I think the problem is not with a new organization being able to claim a higher level without any demonstration that it has operated at that level, but with the fact that the government might want to require a particular level. I believe that it is important to understand why the government (or other group) would want to have such a requirement. A contract administrator might say well the reason we have such a requirement is to improve the chances that we will have high quality, etc. in the products we purchase from these organizations, and we have found that statistically corelated with organizations that get a higher level on this test. If this were the case, and an administrator was open minded and willing to take some risk, that administrator might look over your organization, and your plans and make a *judgement* that he thinks you could deliver the desired quality, etc. even though you don't have a track record. That's a fair judgement to make. On the other hand, the administrator might be very risk adverse, and the lack of the track record might concern him, and for that reason alone he might choose not to be the first person to test you out. That's a valid business decision too. Now, by making this decision he might rule out a better *possible* outcome, but then that "better than expected, better than the competition" outcome becomes the potential reward for the for the administrator who takes a little extra risk. There are more and less successful contract administrators too, striving for excellence over each other. A requirement that an organization be a level 3 is like a job requirement for a programming job that you must have a college degree. I have known many very talented programmers who never completed college. But admittedly they are the exception, *most* of the programmers I know do have a college degree. And *many* job applicants who don't have college degrees don't have the skills to be good programmers off the bat. And it is a pain to read through all those irrelevant resumes. Some places would therefore say "requires a college degree or equivalent experience" and take advantage of the infrequent but truly wonderful exception who doesn't have the degree but is loaded with experience. Other places are prepared to pass up some exceptional people in order to avoid having to scan through all the other irrelevant applicants. They prosper or fail depending on how right these strategies work for them. > At what point can a group be re-assessed and attain a higher rating? From a theoretical point of view, it would seem that you can re-asses and attain a higher rating whenever you have new data that supports that model. But in practice the answer will be that the administrators need to decide often they will look at new data. If too long the administrator risks the possibility of losing a good bid unnecessarily. If too short, the administrator will be swamped with re-evaluations that don't pay for themselves. Every administrator must find their own balance. > ...does not allow an organization to skip levels. No, that would depend on how often reassements take place. If you are arbitrarily quick in increasing your maturity, and arbitrarily long in reassesment there is the real possibility that you will be measured at one level and the next measurement may be two levels higher. This doesn't mean that you skipped a level any more than it means that if you glance at the speedometer and see 50miles per hour, and then a few minutes later is says 60miles per hour, well sometime in between (according to the fundamental theorem of calculus) you were going 55miles per hour for an instant. The same thing is true about software maturity. If you go from 2 in one test to 4 in the next, you probably didn't skip 3, it is just you passed through it in the duration. > This means that it would take at > least 3 projects before a group can be considered a level 4 group. > In a typical environment, this would likely take a minimum of 5 to > 8 years, much longer for a group which takes on larger projects. Which is one reason why people say it takes so long to go up the curve. It is not merely reticence on management's part--it is hard work and lots of it for a long time no matter what. > Indeed, some groups only work on one project, and then are disbanded > (except for maintenance). These groups can thus never attain a > maturity level higher than Initial True. That's a choice you run when you choose to start up and close down groups a lot. The same is true in factories. If you can keep a factory running and make small changes all the time you are less likely to get some classes of errors than if you are constantly doing a whole new tool up, small run, and complete shut down. I don't think it is a flaw in the model that not every management choice will allow an organization to be a level 4. Process maturity is just one contributor in the success of a business. A commitment to it doesn't guarrantee success, nor does low commitment ensure failure. The success of the organization, is the cross product of several business determinant vectors. Good business is chosing the right allocation of effort and resources to the right vectors in order to get the best resultant. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Process Utopia (Was: SEI Level for New Organization?) Date: 2 Jul 92 19:14:02 GMT In article <1992Jul1.155555.14391@asl.dl.nec.com> terry@aslws01.asl.dl.nec.com (Terry Bollinger) writes: > Hmm. I wonder, does all of this mean that brand-new organizations and > small timers might as well close up shop before they begin? Not in my mind. Indeed, I've formed many brand new organizations in the past and hope to do many more in the future. However their measured process maturity is not the only determinant of organizational success. > Even if they are, say, a tiny group like the collection of five ... Especially if they are such people, they do not need to fear a software process maturity rating at start up. Their success is likely to be determined by many other things, such as their unique understanding of the market they are serving, their much better than average individual skills, and the simplicity of communication which can occur in smaller organizations where there are fewer people to communicate with. > And what of the individual programmer -- the truly one-man shop? What of this person? Some people are "artists". In terms of their process, they are definately "chaotic", so they would be classified as level 1. And sometimes the make genius discoveries quickly and sometimes they spend lots of time and get nowhere. Very unpredictable. But those strokes of occasional genius may be quite sufficient to impress the market place, which in the end doesn't care about an SEI rating any more than the programmers SAT score--in the end it is the quality and suitability of the product to the customers problem that determines customer satisfaction. A lot of other things have to go right too (like saving enough money this week to pay next weeks bills) for a company like this to be successful, but these other things can just as easily put a company with a level 5 SEI rating out of business. An SEI rating is just a measure of one thing, the thing it measures, and not the ultimate success measure of an organization. Indeed, consider a business whose forte is their ability to do completely novel one-time throw away things, to a continuously changing clientel in different locales (typical of some contract project businesses). I imagine these people eschew much of the higher level SEI stuff as expensive to do and not contributing to their ongoing needs. On the other hand, it is clear why a large, multi-year project like the Space Shuttle would seek to get as high as they could. > [significant impact by level 1 organizations] Because commercial success is more determined by having the right product, the right distribution channels, the right price, than by an SEI rating--unless for that product and customer the SEI rating is what determines if it is right or not. > Hmm... I wonder, how exacty does the SEI Process Maturity Model itself > rate under such a definition? It should be noted that when Taylor and Gilbreth were developing "Scientific Management" systems, and applying time and motion studies, there were mainly only anecdotal results at first. And many faults in their studies and methodologies were found, and yet there was a seed of truth in them that comes down to this: Managing complex processes is difficult, and every person and machine and object increases the possible number of combinations, and especially the possible number of inefficient combinations. Prior to scientific management, you just selected one combination and lived with it. If it was a right one, you survived, if not you went out of business eventually. Scientific management gave a method to try to choose some better combinations out of all the possibilities, it gave means to organize a system around a solution to the combinations problem. But note today that small organizations often are much more successful than larger ones, precisely because there are less combinations where things can go wrong, and more of the possible combination solution set can be analyzed, and thus error can be avoided. Scientific Management has changed large factories, like auto plants, but hasn't changed the corner garage much, or even the local job shop welding operation. There's a reason for that. I think the relevant question should not be whether a new (and consequently small) organization can be at level 4, but rather whether it needs all that extra support and scaffolding to solve its simpler communications and organization problems cheaply. > Do we truly achieve the excellent objectives of Demings/Juran style quality > by simply brushing away any differences and teaching software developers > to adapt to the mental equivalent of repetitive motion syndrome? The thing that I see here is that we haven't really done those motion studies. If you walk into a factory, you can see work in progress moving from here to there. You can see where an incomplete part sits in the wrong place for a long time, while the next person waits for it. You can see where someone is putting defective pieces that accidentally get picked up and put back on the line. Now take a walk through a programming lab. What do you see. A bunch of people staring at tubes. Whose waiting for key parts? You can't tell. Who has completed work, but others haven't picked it up yet? You can't tell. Are files sitting in one place while people are looking in the other places? Are people looking for files and grabbing the wrong (i.e. defective) version and incorporating it back into the new release? We don't know. If you try very hard, you can create lots of reports, or do lots of on-line queries to begin to get some of this data, but it is still mainly symbolic and too hard to process, it isn't visible and immediate like walking in a factory. And there are so many files moving around, versioning, etc. that people are overwhelmed (this was true in factories too and it took decades to get good results in manufacturing, but we software guys are in a big hurry to change the world). Till this kind of visual support is widely available, I think the true ability to be "repeatable" is even very limited without large commitment. > Or do we take the Demings/Juran model *really* seriously and work very > hard to understand why software and other design-intensive activities > seem to be as stubbornly dependent on having good, experience people > as they are on good management and documentation practices? All organizations benefit from having good, experienced people. The problem is that there are a limited number of them in the world. In one recent survey, 50% of all software engineering graduates were ranked in the lower half of their graduating classes. :-) The larger you get, the more pressure you feel to accept some less experienced people in order to grow. A large organization *MUST* find ways to *SURVIVE* even in the presence of mainly mediocre and limited experience people, because that's mainly whats out there in the hiring pool. In order to *THRIVE* a large organization must not only protect its survival in the face of the mediocre, but also in doing so not unfairly hamper the ability of the good and experienced to do more than mediocre work. The problems for large and small organizations are not the same, which is why it is often difficult for small organizations to successfuly transition to large sizes. I think it is precisely the need to be serious about the Demings/Juran model that makes those of us trying to make a living applying or teaching this stuff to consider process maturity goals, etc. in the context of an entire enterprise success model, and not in isolation or in purely theoretical examples. From: reid@csgrad.cs.vt.edu (Thomas F. Reid) Subject: Re: SEI Level for New Organization? Date: 4 Jul 92 22:02:05 GMT Organization: VPI&SU Computer Science Department, Blacksburg, VA In article <54127@athertn.Atherton.COM> mcgregor@netcom.com writes: >A contract administrator might say well the reason we have such a requirement >is to improve the chances that we will have high quality, etc. in the products The logical conclusion to this argument is that soon only experienced level 3s will be able to compete and competition is stiffled (no new firms can come up through the ranks). Then, the government will have to open a new category of set-asides like 8-A for "impoverished SW development firms". Can you imagine the bizarre rules? In short, the government will shoot itself in the foot by requiring only "certified" level n competition. It would be liveable if there were a maximum of say 10% "really" critical projects. From: steves@IMD.Sterling.COM (Steve Scheuber) Subject: Re: SEI Level for New Organization? Summary: You've confused SPAs and SCEs. There is no "SEI rating" Organization: Sterling Software, IMD Date: Mon, 6 Jul 1992 20:35:53 GMT I'm concerned with the perceptions that can be derived from this thread. Therefore, I've decided to jump in and offer my two cents worth. In the following paragraphs, I make two assertions and attempt to provide supporting material. Hopefully, I haven't rambled too much (there is a lot of material). Assertions: 1) This thread has appears to have confused Software Process Assessments (SPA)s and Software Capability Evaluations (SCE)s (they are two different animals, used for two totally different problems. 2) There is no such thing as an "SEI rating." Software Process Assessments (SPA)s: The fundamental premise behind the SPA methodology is that it's for internal organizational improvement (it's a self-analysis of sorts). The advantage of a SPA is that it focuses a software process improvement program on the critical issues that must be addressed in order to achieve improvements in software process maturity (notice that I did not say "SEI rating"). It also motivates senior management to act on problems (i.e., findings) because they have now become a matter of public record (at the final findings presentation and in the final report). One of the objectives of the SPA methodology is to produce a small set of things (5 +- 2) for the organization to focus on--not a laundry list of all the issues an organization should address (such a list would be too large for any organization to constructively address). Given the purpose of a SPA, would plan (and do) full-scale assessments every 18 - 24 months. The main purpose is to produce a new list of 5 +- 2 things to work on. When used iteratively, the SPA methodology will help keep software process improvement efforts focused, over the long-haul. Used in this fashion (as intended by the SEI and Watts Humphrey) I would not expect the SPA methodology to produce results as drastic as jumping from Level 2 findings to Level 4 findings (wishful thinking :) though). As Scott's posting highlighted (in essence) change takes time. I believe people are setting themselves up for failure if they are planning on going from level 2 to level 4 in less than 18 - 24 months. In fact, one of the best "worst practices" offered at the April 92 SEI SEPG (Software Engineering Process Group) symposium was "Level 2 in 92, Level 3 in 93, out the door in 94." With respect to just "passing through" levels, undetected, ... I don't see how this could happen if you haven't consciously targeted those areas for process improvement activities. My basic assumption is that you use the SPA methodology to target areas. If an area hasn't been targeted, why is anybody working on it under the auspices of software process improvement? If someone is working on it, why? The most critical issues were identified during the assessment... work on those. If they're satisfied, do another assessment and start the cycle over. For additional information on the SPA methodology and how it relates to software process improvement, please see the SEI's Technical Report entitled "The Role of Assessment in Software Process Improvement," CMU/SEI-89-TR-3, by Dave Kitson and Watts Humphrey. Software Capability Evaluations (SCE)s: My understanding of the SCE methodology (and its exact use in the procurement process) is somewhat less complete than the SPA methodology. That notwithstanding, the below represents my dump of the SCE methodology and how it relates to the source selection process. The fundamental differences between the SPA methodology and the SCE methodology are tremendous. The SCE methodology is, in essence, supposed to be a "risk analysis" performed by the organization purchasing software services. In the case of an SCE, the "findings" are really those areas that the purchaser evaluates to be the weakest aspect of your company's software process (of course, as they pertain to the CMM). SCE's are supposed to be performed on "like" projects (i.e., that suggests that you have some "like" projects to offer). Consequently, given that you have many projects, and many customers, the results of each SCE could (and probably would) turn out different--which is certainly a concern of many in this area (i.e., the results are not necessarily predictable). In the end, the SEI teaches customers (i.e., those getting trained in the SCE methodology) to *NOT* focus on an "SEI level." Rather, they should focus on the findings (risks) and use those during the vendor selection period. In short, some risks may be acceptable, while others are not -- these would certainly be determined on a case by case basis (and perhaps unfairly IMHO). Getting to my second assertion, that there is no such thing as an "SEI rating," IMHO, the biggest misconception in the software process arena, particularly as it relates to the Capability Maturity Model, SPAs, and SCEs is that company's get "punched in" at some SEI level-- that you can get an "SEI rating." This just simply is not the case. The SPA methodology only references the maturity level in passing (in the findings presentation and in the final report). The real meat of a SPA is the 5 +-2 key issues uncovered by the assessment team (i.e., the findings). and the recommendations the team makes (what to do about those findings). With respect to the SCE methodology, it too is targeted at the "findings" and not the maturity level. Since SCE results are dependent upon the "like" projects, and those vary (depending on the job you're bidding) it isn't in anyones best interest to keep "ratings" on file. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Level for New Organization? Date: 6 Jul 92 18:51:46 GMT I am in agreement that many experienced people could create a defined process that conforms to SEI level 3 rating, and 2) start a new company that *intends* to implement that defined process. However, in my opinion, you cannot say that the new company *is* at level 3 until it has demonstrated that it *has* implemented the process and got successful results, not merely that it intends to do so. One of the problems of real life in new organizations is that even if you are very experienced, you don't know everything in advance about who you will be able to hire, which potential customers will buy from you and which won't, whether you will have the cash to finance your plan as expected, etc. As a result, you have to change your plans to fit reality--or go out of business. But if the former, will you still be level 3? If the latter, does it matter that your process would have been level 3? Failure to tie a measure like this to real demonstrated results in the current organization is asking for people to "boast" that they are level 3. A new organization with plans to train everyone--plans that aren't yet implemented because the people aren't hired yet--is it really any different from an existing dinosaur organization with a lip service commitment to training that it too hasn't quite implemented yet? Maybe that dinosaur will actually do so next month. Maybe some major cash pinches will prevent the new company from implementing its plan. In my view, an SEI rating is only meaningful if it has demonstrated results to back it. Consider the Olympics, should we just award the US team the gold medal without bothering to play any games--because they hired the most talented, experienced players, had a good coaching and training plan, etc. or should we have them prove it on the court first? Some promoter might be offering TV commercial contracts for "olympic gold medal winners only", and could possibly be missing out on better stars, if they sign up people today--well, that's their loss right? If government contract restrictions accomplish the same thing that too is a mistake--complain to your congressman about it. As a potential founder of a small organization myself, I am concerned that a Government contract administrator might deny me a contract because my organization is so new that I can't have a demonstrated SEI rating. I feel that will be bad for both of us. I'd hope that he would be open to the possibility that we could do a better job than established competitors even though we have no track record. If the administrator can't be open to an exception in this case, then they will face a shrinking number of less competative bidders. The administrator will have to decide for himself whether that less competative situation is acceptable. In the meantime, I will look for more open minded (non-government?) customers and build my business there--and I can come back later when I have a track record, if that government market still looks attractive--because then that track record barrier to entry would be in my favor. At the same time, I hope there won't be too many people here bitterly complaining when I become "a business special interest" and begin "lobbying" congressmen to overthrow this kind of contract restriction even though this is clearly motivated by "my own selfish interest". I believe that there are serious flaws in the way governments let contracts, but I don't think that the rest of the world should be turned inside out to conform to these flaws. It might be better to fix the flaws. From: keating@casemo.UUCP (John Keating ) Subject: Re: SEI Level for New Organization? Date: 8 Jul 92 17:05:43 GMT Organization: Dowty Communications, Inc. In a previous article, johnm@cory.Berkeley.EDU (John D. Mitchell) responds to a post by rms@miles.com (Rob Schultz) writes: > This is true only if ... those selecting are rigidly dogmatic ... I believe that this is what Rob was worried about. When bureaucracies start demanding level x compliance, it won't matter a whit to the paper pusher behind the desk how good a start-up company actually is. Just as long as it is that level. This leaves the startup companies, (which were/are the moving factors of this technology, IMHO) out in the cold, whilst the older, established companies trudge on, leaving innovation scrunched beneath their feet. From: 71033.536@compuserve.com (Terry Bollinger) Subject: SEI Process Maturity Model Organization: NEC America, Advanced Switching Laboratory Date: Thu, 9 Jul 1992 22:33:54 GMT Hi folks, Interesting and in some cases amusing discussion. Allow me to address a few specific points and questions: 1. Is the SEI Maturity Model REALLY based on the assumption that building new software is "just like" mass production of, say, copper sheeting? Yes. In fact, I may well have understated the case in terms of how firmly Watts Humphrey, the originator and primary promulgator of the model, views software development. He came and gave a talk when I took SEI Process Assessment training (at SEI), and the talk consisted almost entirely of telling us how detection of holes in copper sheets shows us how we should strive to build rock-solid software processes that will chug out "hole-less" (defect free) software. Scan through his book and you will find that it makes frequent and very definite analogies of software production to such items as watches and cars. He does NOT make any comparisons of note to design-intensive activities such as chip design (vs. replication), only to assembly-line (replication) processes. Don't take my word for it -- get out your copy of Humphrey's book and LOOK. One thing that continually astonishes me about the whole SEI Process Program is how often this point seems to slip by -- that is, that the concept of maturity that it promulgates is strongly and fundamentally based on the premise that software can be treated as a substance or medium that can be processed very, very much like some sort of metal or ceramic on an assembly line. You might want to keep it in mind the next time you or someone else quotes "Level 4" or "Level 5" as if they were PROVEN ideas for how to build high-quality software. And again: This sort of premise -- what I refer to as the "strong factory hypothesis" -- is very much a RESEARCH premise. It's never been proven. No company has ever made a mint by practicing it. I suspect that more than a few folks on the academic side of the house would scoff the idea off as a bit silly, and tell any grad student who proposed it to go back and read a few books like Bertrand Meyer's Object-Oriented Software Construction before trying to go any further with it as a thesis topic. 2. IS the production of defect-free software different in any really significant way from the production of defect-free copper sheets? Yes, emphatically. The former is a design process, the latter is a replication process. These two process types have markedly different resource and management needs, risk types and factors, measurement needs, and potential for automation. Slurring them together not only is inaccurate, it can be disastrous for your ability to produce high quality software, because it will lead management to look at the WRONG process control indicators. Says who? Well, let's try a simple comparison: How does a bakery with many separate locations ensure that the quality, flavor, and texture of their products will all be consistent? Simple answer: By setting up a management process and measurement program that will ensure that all products will be IDENTICAL to within some well-defined set of tolerances. Initial risks come more from poor adherence to the defined management practices than from practices themselves. Poor products result from deviations from a predefined recipe, and can be traced back to whatever part of the process is failing to EXACTLY match the predefined standard for a good product. In short, it's a replication process -- a process in which innovation *of the product itself* is (by definition) forbidden. You may be allowed to make innovations in the PROCESS for making that product -- e.g., going from a batch style to a more assembly-line style -- but changing the product itself counts as a violation of the way all the different bakery locations have agreed to make their products. Another simple question: Could a bakery also use the above type of process also be used to create NEW recipes and products -- say to go from making biscuits to croissants? Well, let's just listen in on the ensuing conversation: "Hey JACQUE -- just whaddaya think you're DOING?!? You're rolling that dough out to a measly 0.1 mm thickness -- don't you realize that you're *10,000%* OUT OF LINE WITH THE BISCUIT SPEC?!?" Somebody's head's gonna ROLL when Quality Control tells the boss about THIS one... and it sure ain't gonna be MINE!" "But... but Messier Bubba, the boss he asked for a croissant... how can I make a croissant with dough layers a CENTIMETER thick?" "Heyooo, you CRE-A-TIVE types is all alike, ain'tcha? Always gotta go around messin' up a SURE thing, huh, cause you thinks you can do SOOOOOOO much better? Well I've got some news for you -- our biscuits have sold GREAT for 40 years, and hey, we might even tolerate a 5% deviation in the name of goin' after a new market -- but you listen up, buster, our process is already mature here and no INN-O-VA-TOR is gonna mess it up, you hear? And besides... ARGGGGGHHH!!! *WHAT* ARE YOU DOIN' WITH ALL THAT *BUTTER??* YOU'RE 5000% OUT OF SPEC!!! Get *OUT OF HERE!*" (For those who hate to be left hanging, there's a happy ending -- Jacque returned to France and founded an extremely profitable company for building computerized automation systems for bakeries. Bubba, alas, was replaced by one of Jacque's computers...) 3. Does following the SEI maturity model *necessarily* ensure that you will "deliver top quality software products at a profit that meet customer needs and expectations?" Well if it does I'd SURE like to see the data -- wouldn't you? One of the really nice features of defining a maturity model in which NO ONE is "mature" is that you can play some very interesting games in how you describe the higher levels of the model. Examples? Easy. Let's say that I've just decided that there is a bundle of cash to be made simply by joining in on the SEI bandwagon. Being basically market-oriented, I prepare my slides diligently: "Let's speculate that every additional level of the SEI Model will produce a 20 times increase in productivity. It it thus clear that all companies should invest huge sums of money to ensure that they will remain competitive in the future market of truly mature Level 4 and Level 5 software organizations." "Note that Level 4 means that you have finally reached the point where your process is measured and controlled. Thus for the first time your organization will be able to produce software products in a thoroughly controlled, accurately measured work environment in which anything that affects quality will be immediately identified and corrected. Massive increases in productivity will at this point be practically inevitable." "When you reach Level 5 you will find that your company has a huge market advantage -- the advantage of rapid process optimization and improvement. With this advantage you will for the first time be able to rapidly and reliably navigate the treacherous waters of new technology and CASE tool usage. Your products will be of absolutely outstanding quality, and you will produce them far more rapidly and with less resources than your less mature competitors." Now ain't all that great? I mean absolutely GREAT? How can ANYONE be against such an absolutely outstanding program if it will result in such UNBELIEVABLE results? Well... that's sort of the problem, isn't it? "Unbelievable?" As in: If I claim to you that your Fairy Godmother will come down and shower you with kisses when you reach Level 5, WHO is to say that I'm WRONG? How are you going to judge the believability of a set of claims when they are based on descriptions of a hypothetical organization that NEVER EXISTED at the time the maturity model was devised? There WAS no data, good or bad, for such an organization at that time, so how do I judge ANY kind of assertion about it? (I'll discuss the Space Shuttle case a bit later...) The Department of Defense originally asked SEI to develop an audit program for them that would PROVE to them that a company could do what it was paying them for. I might note that I happen to consider that a very reasonable goal on the part of the Department of Defense. But if that was the goal, why didn't the SEI folks do just that -- give the DoD a model that could be PROVEN against bona fide data collected through intensive interviews with companies noted for building good software products? As opposed to, say, building the model around an empirically UNproven research idea, the strong-factory analogy? If you are planning to restructure the way the world does software, which of the above two approaches sounds more reasonable to YOU? 4. "The VALUE of [SEI Process Assessments] is not the number. The value is what you LEARN about your processes and where you can improve over the next 6 to 18 months." Surprise! I concur completely. SEI has developed some really good management and "group therapy" methods over the past few years, and they are impressive at producing changes in otherwise unchanging projects. They also have next to nothing to do with the SEI Maturity Model. Try out an SEI-style Process Assessment one and you'll see what I mean -- the questions wind up being used more as a technique for opening up discussion than for actually *pinpointing* problems. 5. Can a new organization jump immediately to a higher SEI grade? No. SEI grading (1987-1992 time frame) requires that you have *more than one* project under your belt before you can even join in on the fun, so you lose by default. 6. Level 5 organizations DO exist. Look at the space shuttle software. When you look at Space Shuttle software, here is what you SHOULD see if you wish to be accurate about the matter: A whole lot of well-verified, well-tested software that was developed primarily by a LEVEL 1 organization! What?? LEVEL 1?? But those fellows are Level 5, aren't they?? Sure. NOW they are Level 5. Care to make a bet how they would have rated if the 1987-1992 questionnaire/SCE methods had been used to rate them when they actually WROTE 99% of that mostly unchanging code? I bet Level 1 -- *maybe*, just *maybe* Level 2 in a pinch. Why? Because the 1987-1992 questionnaire that is used to actually assign a numeric rating is strikingly picky and arbitrary, making the chances that even a quite decent organization will "hit" all the right answers *without knowing the questions first* almost nil. So who exactly is claiming credit for what? Clem and I made a prediction in our paper that whenever someone *did* reach Level 5 in the SEI Model, it would *not* be a complex new-design activity, but some sort of maintenance activity in which changes of a very consistent type are being made over an over again to a very small percentage of the overall code. Like the space shuttle -- where *most* of the code was carefully verified many years ago (back in the Level 1/2 stage?), and each new mission is best viewed as a set of delta changes against that original code base. I'd say our prediction was pretty much right on track. And while maintenance is a very important component of our industry, it's not the *entire* picture, is it? 7. "There is no such thing as an SEI rating." NEWS FLASH! In a remarkable new study, researchers from Plodsky U have shown that contrary to a very common misconception, the sky is white, not blue. "The problem," says Dr. Plodsky, "is that people have been focusing on what is unimportant, rather than what is important. We have dozens of spectrographs showing that light from the sky covers the entire spectrum in a remarkably even fashion, with only a slight enhancement of the blue portion. Thus it is actually white, not blue -- it's just that people keep focusing on the more conspicuous, but actually irrelevant, slight enhancement of the blue portion." When this reporter asked him about their Plodsky U's parallel Government-sponsored research program for rating how blue the sky is on a five-level scale (and for shutting down any town that did not rate Level 3 Blue or above), Dr. Plodsky had the following comments: "No no, you are confusing the issue. People MUST stop worrying about how or even whether the sky is blue, and focus instead on the great benefits to be achieved by realizing that it is really white." When this reporter then pointed out to some towns that had been shut down did not feel that the grading methods used to assess their sky color had been particularly thorough, well-thought-out, or even fair Dr. Plodsky provided me with some truly persuasive data and figures. "Hmmmm... yes, let me show you this chart of your home state... yes, yes, hmm, you're town looks a bit *gray* in this initial analysis doesn't it? Never mind, never mind, 99% of them start out that way anyway... its just the DEADBEATS that don't get with the PROGRAM who wind up actually getting SHUT DOWN, wouldn't you say?... Hmm, yes, most interesting data is it not?..." As I gazed at the chart it suddenly struck me with a blinding clarity I had never known before -- by GOLLY, the sky *IS* WHITE! I could not imagine how I had *ever* seen it in any other way! Dr. Plodsky smiled at me benignly and went on his way, obviously warmed by the thought that the truth, once it is brought out in the proper fashion, will ALWAYS prevail in the end. From: wahl@merton.enet.dec.com (David Wahl) Subject: Re: SEI Process Maturity Model Date: 10 Jul 92 15:22:34 GMT Organization: Digital Equipment Corporation In article <1992Jul9.223354.26306@asl.dl.nec.com>, 71033.536@compuserve.com (Terry Bollinger) writes: >[deleted - see immediately previous article - DAL] Terry, I enjoyed your thoughtful article. I have had the same concern about the whole assumption that statistical quality control is applicable to software development. I do think, though, that you failed to address a key issue regarding the CMM: the issue of whether metrics -- ANY metrics -- are useful in determining how to improve the quality of software. I think it's really there that your arguments succeed or fail; the choice of manufacturing analogies to software is, I think, simply because most of what we know about measurable quality comes from manufacturing process improvement. While I agree that there are some fundamental differences between replicative processes and design-intensive processes, I think you have to step back a second and ask what management can do to impose change from above to improve the design-intensive process. If it's an organization large enough to produce and maintain really complex software with replaceable people, the only objective tool management has to get a handle on the problem is to measure things about how the process is working and compare them against some baseline. I think you can argue about which metrics and where the baseline comes from, but I think the notion of trying to measure the process is sound. I think metrics are often portrayed in the hearts of programmers as something which will remove all creativity from the process and make us all 1984 drones victimized by Big Brother management, but the truth is that projects get large enough that even the most experienced technical leaders can't get a handle on where the quality problems are. In my experience, even teams with lots of experience, supportive management and the best of intentions have blind spots and a bit of self-deception regarding quality. I don't have proof that metrics work; I'm a lead programmer, not a researcher. But my friends who work in organizations here in Colorado which are struggling to improve along the lines of the CMM because of government contract requirements now believe that complexity and quality metrics DO improve maintainability. They are not by any means completely sold on the CMM, but they are convinced that their quality as it applies to maintenance has improved. From: ir@cs.man.ac.uk (Ian Robertson (BCW MSc 89)) Subject: SEI Process Maturity Model Date: 10 Jul 92 09:11:41 GMT Organization: Department of Computer Science, University of Manchester Thank God for Terry's breath of fresh air in this debate. Why are software engineers so introspective? People have been `designing' things for centuries: surely someone has sat down, sucked his/her pencil and wondered about the DESIGN process? If we could crack that one, then we might have a chance of getting a handle on the software engineering process. One thing is certain, as Terry eloquently demonstrated; whatever it is, it is NOT a production process. But factories do have design offices. What goes on in there? Ther must be kilos and kilos of paper written about it. Can anyone furnish references? From: terry@aslws01.asl.dl.nec.com (Terry Bollinger) Subject: Re: SEI Process Maturity Model Organization: NEC America, Inc. Irving, Texas Date: Mon, 13 Jul 1992 15:15:30 GMT Hi folks, In article <1992Jul10.152234.17009@nntpd2.cxo.dec.com> wahl@merton.enet.dec.com (David Wahl) writes: > [are metrics useful in determining how to improve software quality?] If I'd had to pick a single question that I was hoping someone would ask, that would probably have been it. It's a good question *and* a tough question. Short answer from my perspective is that metrics are *more* important, not less, in a design process -- but that you need to be careful of what you select and how you set up your feedback loops for using your metrics. The Bubba Effect (elimination of all creativity in the software process through an excessive focus on replication) is quite real and needs to be recognized, else your metrics program may not produce *quite* the results you were anticipating. On the other hand, carefully selected replication metrics and feedback loops clearly *can* promote design by keeping people from wasting time in pointless re-invention, and by encouraging clear partitioning of complex problems. Examples? Sure -- one straightforward and largely automated example is the Ada package mechanism. The use of package specifications helps enforce *replication* of a set of functional interface definitions throughout the design -- a type of replication which in this case helps the process along by enforcing clear partitioning of the design issues. So Bubba is not *always* wrong -- you just have to be a bit selective in when and where you turn him loose. My objection to the SEI model is not that Bubba exists in it, but that they've give the whole kitchen over to him -- lock, stock, and barrel. P.S. -- You mentioned complexity metrics. It's interesting to note that in transmission (information) theory, the idea of "complexity" corresponds quite closely to the idea of "information". And without *some* intrinsic information -- complexity -- in a message transmission, you cannot convey any new data at all to the receiver. But if you garble up the message with a lot of useless noise that adds nothing to the actual message, the message becomes increasingly difficult to decipher. It also becomes harder to change or modify. Hmm, I wonder... Are we really trying to *eliminate* complexity from programs -- or are we really trying to eliminate only that portion of the complexity that corresponds to unnecessary noise? A program is, after all, quite literally a binary message being conveyed from us to the computer. If we eliminate *all* complexity, does our program still *say* anything? From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Process Maturity Model Date: 15 Jul 92 17:34:52 GMT In article <5299@m1.cs.man.ac.uk> ir@cs.man.ac.uk (Ian Robertson (BCW MSc 89)) writes: > People have been `designing' things for centuries: surely someone has sat > down, sucked his/her pencil and wondered about the DESIGN process? Indeed, Terry makes an eloquent point, but the criticism seems to focus on there being only two approaches: a design centered (craft production?) and a production centered (mass production). In fact, traditional manufacturing industries are being turned inside out by a new approach. This approach, which Woman, Jones and Roos term "lean production" is a combination of many changes to traditional process manufacturing, including Just-In-Time (kanban) manufacturing, small batches, versatile machines and skilled labor, quality circles, incremental improvement (kaizen), shared process information boards (andon) and designing for manufacturability. Many of these new techniques are very relevant to software development. Many here have claimed that the "manufacturing" part of software is the reproduction of disks. I would claim it is not. I would claim that the "manufacturing" part of software is the part typically done by "release engineering" and "system test" groups: the assembly of separately produced and (unit) tested components into a release version of the system. In many small systems this is not even seen, just as rework departments weren't seen in the craft production automobiles: because all parts were reworked as they were designed and put together in a single process. However, in larger software systems development, release engineering, configuration management and systems test groups are ponderously large, and consume large amounts of time and effort in the product release cycle. In effect, these groups are like the rework areas in large mass production facilities; they make up for designs that are not easily assembleable. It is therefore, in my opinion, quite appropriate for software engineering work to focus on both this software component assembly process, and also on the software design processes which yield the components being assembled. This includes the SEI approaches, including Software Process Maturity, even if their particular implementation may be imperfect. Some software professionals have rejected much of these "factory oriented techniques". In some cases they fear that their application will result in mind-numbing specialized but deskilled tasks for programmers, just as mass production techniques replaced the skilled craftsman of craft production with masses of unskilled labor. If mass production were the ONLY form of factory techniques this might be a real concern. However, it is not. Lean production relies on the use of skilled assemblers AND skilled designers. Lean production is less specialized--assemblers must understand not only a single part, but all the related parts, and how the parts relate to the assembly tools, etc. So it might mean programmers would become more generalists. Moreover, while mass production centralizes decision making authority, lean production decentralizes it. Lean production may therefore be precisely the right model for a "profession" of skilled generalist practitioners needing little management directive. Moreover, metrics in such situations are the common property of ALL of the assemblers, *not of management*, and are shared among them allowing each person to understand the needs and dependencies of those around them in a collaborative fashion rather than as a management operated punishment tool. For more on Lean Production, I recommend readers to check out the highly readable "The Machine That Changed The World" subtitled "The story of Lean Production. How Japan's secret weapon in the global auto wars will revolutionize western industry." By James P. Womack, Daniel T. Jones, and Daniel Roos of the MIT International motor vehicle program. New York: Harper Perrenial, 1991. $11.00 US -- The book focusses on the auto industry but touches on how these techniques are being adopted in all manufacturing businesses. You don't need to know anything about auto production to understand or enjoy the book. It doesn't go into the parallel to software engineering that I suggested above--if you need someone to do that you should contact those of us who do consulting, training or lecturing in this area. This last one, designing for manufacturability is perhaps one of the keys to the new lean production systems. The effort of manufacturing is substantially reduced by DESIGN processes. It is also relevant to the way software is designed. From: mcgregor@netcom.com (Scott L. McGregor) Subject: Re: SEI Process Maturity Model Date: 15 Jul 92 18:29:15 GMT In article <1992Jul13.151530.19576@asl.dl.nec.com> terry@aslws01.asl.dl.nec.com (Terry Bollinger) writes: > ... Are we really trying to *eliminate* complexity from programs? This is a problem that I have personally seen where complexity metrics were used to reject routines unthinkingly. The result was that no routine was overly complex, but there were many more routines, and the problem of configuration management and release engineering of the different modules was made worse. One form of complexity was just changed into another. So, I don't think that we are trying to eliminate all complexity. It is good to eliminate unnecessary noise--that's one of the reason I encourage people to remove features that people don't use, just like it is a good idea to remove "dead" code. But I think that there is something else going on, which is managing necessary complexity. Said another way, to the degree you can focus on just SOME part of a larger problem, complexity that is necessary to solve the other parts of the problem is distracting for the particular task. Managing complexity is like using "false color filters" in visual processing--they pinpoint some features and hide others that are irrelevant. The human brain is really rather limited in its communication bandwidth, and in its short term memory and processing. It can be easily overwhelmed if the needle is in too much haystack. So finding ways to compartmentalize things allows you to manage complexity--not to eliminate it, but to hide it when it is irrelevant. Human communication, based upon large shared models crucially relies on this ability to focus. Programming techniques have done this to some degree as well. We have notions of encapsulation, data hiding, etc. We've seen emphasis on keeping complexity of a single module down to what can be grasped at once--typically a page or less. 4GLs convey more information more compactly, by hiding irrelevant detail that exists in assembler, etc. However more could be done here. Graphical (aka Visual) programming might offer some improvements not because graphics are better than text, but because if well chosen they can show a more compact representation. On the other hand poorly chosen graphics might yield a less compact representation and therefore convey even less before "information overload" occurs. From: robertsi@cs.man.ac.uk (Ian Robertson (BCW MSc 89)) Subject: Re: SEI Process Maturity Model Date: 17 Jul 92 08:28:40 GMT Organization: Department of Computer Science, University of Manchester Scott's response concentrates only on the `making of things. `Software design processes' do NOT