CMM改进指南 第1章引入软件过程成熟度.ppt

能力成熟度模型（CMM）软件过程改进指南  Watts S. Humphrey The Capability Maturity Model Guidelines for Improving the Software Process 第1章 引入软件过程成熟度 1.0 需求背景 1.1 CMM的进化 1.2 不成熟与成熟软件组织的对比 1.3 软件过程成熟度涉及的基本概念 1.4 全面质量管理和CMM 1.5 使客户满意 1.6 基于模型改进的优点与风险 1.0 需求背景 客户满意已成为当今竞争激烈的世界中许多软件组织生存和兴旺的至理名言。与组织集中追求客户满意的同时，逐渐感到在开发高质量产品中软件是一弱项。随着软件对我们生活的日益渗透，持续了二三十年的软件危机甚至更加突出。(软件危机出现于20世纪60年代） 说“软件危机”也许并不公平。因为软件作为一种强有力的工具得到处广泛的使用，况且软件技术以争分夺秒的步伐在进步。尽管如此，软件所涉及问题的复杂性程度的增长，比我们开发和维护软件能力的增长要更快。因此在预算、进度和提交可靠、可用软件方面，继续不断地困扰着绝大多数软件组织。 寻找这些挑战的答案持续了许多年。经过二十年，应用新软件方法和技术未能兑现生产率和质量增长的承诺之后，促使组织逐渐认识到根本的问题：没有能力管理好软件过程。好的方法和工具的优势在一个无组织纪律、混乱的项目中是无法体现出来的。 引起灾难性后果的软件实例很多。据美国一个未公开的评估报告显示，17个主要的国防部（DoD）软件合同中，平均28个月的进度被推迟20个月。一个4年应该完成的任务，7年还未提交，没有一个项目按时完成。由于软件问题，推迟了B1轰炸机的部署，基于相同原因部分取消了580亿美元的A12飞机计划。美国国家统计局（GAO）一份关于主要软件挑战的相关报告[GAO-93-13]指出：“我们已反复报告，费用以百万美元上升，进度以年而不是以月为单位延误，数十亿美元的系统没有按照我们想象的那样执行。” 在总结了军队中20多个软件或有关软件问题的GAO实例分析后，该报告得出如下结论：“当现有的或突现的关键使命系统不断增加复杂性和对软件的依赖性时，没有及时懂得把软件视为一个产品、把软件开发视为一个过程” 军方遇到的问题，工业界同样会遇到。工业界的经理们直言不讳的说：“我宁愿有错也不愿延迟。我们可以在以后纠正它。”这明显看出客户满意是什么意思。对许多组织而言，不管是军用还是商用，有一点启示相同，即大的软件项目意味着潜在的麻烦。 一个研究小组在分析“软件危机”时写到[DoD87]，“很少有这样的领域，在最好的现行实践与一般的现行实践之间有如此巨大的鸿沟”，并进一步得出结论，“军用软件开发中当前最主要的问题不是技术问题，而是管理问题”。 软件工程研究所（SEI）的使命是在改进软件工程实践的当前状况方面起领导作用，以便提高依赖于软件的系统的质量。SEI软件过程规划的使命是在辅助软件组织开发并持续不断的改进他们的能力方面起领导作用 ，以便识别、选用和运用有效的管理和技术实践。这些实践由有纪律的、严格定义的以及能有效度量的软件过程组成，目的是在满足费用和进度的约束下，能提交高质量软件。 SEI创建的软件的能力成熟度模型CMM是一个框架，它描述有效软件过程的关键要素。CMM为软件组织描述了从混乱的、不成熟的过程到成熟的、有纪律的过程的一条逐渐改进的途径。这条途径包含了5个成熟度等级。 CMM覆盖了策划、设计和管理软件开发和维护的实践。遵循这些实践能够改进组织的能力，以及满足费用、进度、功能及产品质量等目标。CMM指导软件组织控制开发和维护软件的过程，并向软件工程和卓越管理的文化方向演化。 其目的是指导这些组织，通过确定它们的当前过程成熟度，明确在改进他们的软件过程和软件质量中遇到的一些关键的问题，选择过程改进策略。一个组织可以通过强调有限的一些活动和积极工作来实施这些活动，稳定地改进其整个组织软件过程，使得软件过程能力持续不断地改进。 1.1 CMM的进化 1986年11月，SEI在MITRE公司协助下，着手创建过程成熟度框架，用于帮助组织改进其软件过程。这项工作源于为联邦政府提供一种用来评价软件承包商成熟度的方法的需求。 1987年9月，SEI发布了软件过程成熟度框架的一个简短描述[Humphrey87a]，不久之后，该框架在Humphrey的著作《管理软件过程》[Humphrey89a]中做了扩充。 Humphrey开发了两种方法（软件过程评估和软件成熟度评价）和一个成熟度问卷[Humphrey87b]，用以估计软件过程成熟度。 在软件过程成熟度框架和1987年成熟度问卷采用4年后，SEI将成熟度框架演化为软件能力成熟度模