1、 UML 软件工程组织 火龙果软件工程技术中心CMM 软件能力成熟度模型实践指导作者：邓冰博士撰写 来源：上海科技中国加入 WTO 以后，作为信息产业核心之一的软件产地如何与国际接轨将成为整个 IT 界关心的重点。软件产业要想国际化，首先必须采纳国际通行的软件工业化生产标准，即 CMM 认证。由美国软件工程研究所 SEI(Software Engineering Instituto)开发完成的软件能力度成熟模型 CMM(Capabitity Maturity Model )是一种协助企业改进软件制作质量与管理流程并进行评估的标准。它是 SEI 集多年软件研究的经验所研制的过程标准，如今已成为国
2、际上最流行最适用的软件质量改进体系。本文将就 CMM 的整个框架及各级阶段中的重点领域作详细描述，使读者对 CMM 的基本概念和内部结构有一个全面的了解。本文还附有 CMM 过程改进自测表，以协助企业检查并洞测自身软件生产能力的实际水准。一 基本概念二 CMM 发展概况三 CMM 框架 四 CMM 应用五 可重复级六 定义级七 管理级八 优化级第二级（可重复级）自测表第三级（定义级）自测表第四级（管理级）自测表第五级（优化级）自测表 一 基本概念软件过程（Software Process）：过程即人们为实现某一既定目标所执行的一系列步骤（IEEE-STD-610）。软件过程则可定义为企业设计，
3、研制和维护软件产品及相关资料文档的全部生产活动和工程管理活动。理解包括 SEI 在内的美国过程学派的一个核心概念就是-只要过程正确及构成过程的解决方法正确，产品就会正确。软件过程能力（Software Process Capability）：企业实施软件过程所能实现预期目标的程度。它可用于预测企业的软件过程水平。软件过程行为（Software Process Performance）：企业在项目开发中遵循其软件过程所能得到的实际结果。 软件过程成熟度（Software Process Maturity）：软件过程行为可被定义，预测和控制并被持续性提高的程度。它主要用来表明不同项目所遵循的软件过
4、程的一致性。软件能力成熟度等级（Software Capability Maturity Ievels）：企业的软件开发在由低到高成熟化演进过程中所普遍面临的具有一定成熟度标志特征的平台。成熟与不成熟（Mature and Immature）：不成熟的标志有-没有明确的软件过程体系可以依据；无法对生产进行预测；不严格执行生产过程；质量无法保证；无健全的过程控制及质量控制体系；项目开发没有准则可遵循；开发结果主要依据项目小组及个人的带有主观因素的能力发挥。成熟的标志有-项目开发是依据企业早已明确的过程准则来实施；开发结果较少依赖个人能力和自然因素；项目由过程控制并可对整个生产作出预测；产品质量得
5、到有效监控（借助客观定量化的数据）；过去的开发项目中所获经验得以积累并可系统地用于现行和未来的项目之中。配置管理（Configuration Management）：包括以下管理行为：对某个配置项的功能和物理特性进行识别和编档；对这些特征的变动进行控制；对变动和事实进行记录、汇报；验证需求计划的实现。偏差（Deviation）：针对开发中的计划、标准、规划等的明显偏离和变动。 同业复审（Peer Review）：软件项目开发成员的同行遵循某一规则对项目产品所作的检查，用于发现缺陷所在。风险管理（Risk Management）：运用风险概率方法分析评估项目开发中设计的各类风险，包括风险识别，风
6、险分析，风险等级排序和风险控制。软件工程过程组（Software Engineering Process Group）：协助开发机构对所采纳的软件过程进行制定、分析、监控和改进的专家组。它应直接想机构的最高领导层负责。软件生命周期（Software Life Cycle）：指软件开发所涉及的全过程，包括从产品设计到产品终结的整个周期，一般分为概念阶段，需求阶段，设计阶段，实施阶段，测试阶段，安装调试阶段，运行维护阶段，终止阶段。软件需求（Software Requirement）：用户为实现某种目标或解决某种问题要求软件给予满足的条件。二 CMM 发展概况CMM 模型是基于多年产品质量研究成果
7、所建立。美国的 Walter Shewart 于上世纪 30 年代发表了统计质量控制成果。在 Watts Hunaphrey 和 Ron Radice 等人的研究成果之上，卡莱基.梅隆大学软件工程研究所将这套质量控制方法改造为能力成熟度框架并标明不同城市度等级，Humphrey 并于 1987 年发表了初步的成熟度提向单。1990 年 SEI 公布 CMM 的 0.0 版。1991 年SEI 公布了包含第二级 KPA 方案的 CMM0.4 版及包含第三级方案的 CMM0.5 版，同年，又发布了包含第四级和第五级 KPA 方案的 0.7 版。CMM1.0 版于 1991 年底发布，1993 年
8、SEI 公布CMM1.1 版。目前通行的版本是 1.1 版，改进版 2.0 版原定于 1997 年完成，但由于 CMMI（能力成熟度集成）的开发，2.0 版被推迟。CMMI（Capability Maturity Model Integration）将把各种能力成熟度模型整合到同一架构中去，由此建立起包括软件工程软件采购和系统工程在内的诸模型集成，以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。CMMI 框架包括软件能力成熟度模型，系统工程能力成熟度模型，软件采购能力成熟度模型，继承产品 和过程开发等。1995 年，个体软件过程（Personal Software Process
9、，PSP）又被提出，用于控制和改进个人软件开发方式，PSP 是一个过程描述、检测和方法的集合，能够帮助软件工程师改善其个人软件开发性能。它包括一整套适用于个人软件工作者在实践中应用的表格，脚本和标准，以帮助软件工程师预估和计划其工作减少软件工作缺陷并提高计划和生产效率。CMM 是适用于软件开发组织中的流程管理，而 PSP 则面向个体开发人员。本文的探讨仅限于 CMM 软件能力成熟度模型。CMM 的出现是为了克服软件生产的危机。所谓软件生产的危机是指尽管新的软件开发方法和技术不断生产，但软件生产率和质量并未得到有效提高，软件产品不能按时完成，软件生产预算超支，而且交付客户使用的软件产品（特别是大
10、型软件工程）中由于各种原因产生的错误无法克服。在 80 年代末期前后，美国国防部门和工业界开始认识到在软件开发中最重要的问题在于软件生产商对软件的生产过程管理不力，也就是说，软件生产过程的成败比新技术和开发方法更能决定一个项目或企业的成败。没有完善的软件生产过程体系，软件开发的成败只能依靠人为主观或偶然因素-比如某一杰出软件天才或小组的成就-而非可持续的客观标准及体系，因此，对成功的软件过程的重复使用，对以往经验或教训的分析总结，对全部开发案例的系统编档存档就成了一套完整而成熟的软件过程，需要一个从无序到有序，从人为到客观标准，从定性到定量的不断积累与完善的过程，这一过程的演变中软件企业会面临
11、一系列有代表意义的成熟阶段。美国 SEI 提出的软件能力的评价与改进指导体系。软件开发企业可以依据 CMM 的框架对项目管理和项目工程进行定量控制和能力评估，而软件应用单位也可依据 CMM 来衡量和预测项目承接方的实际软件生产能力。这样，软件开发方与产品用户方都基于一个同样的标准来对软件生产和管理作评测与控制。大体来说，软件开发企业在以CMM 为标准改进其生产过程中应采取如下步骤：1 领会 CMM 要领并依据其框架确定企业目前所属的实际能力成熟度级别；2 针对欲达到的成熟度级别的核心过程域的要求并参照自身的薄弱环节将重复重点集中在关键目标上改进生产过程；3 加强员工培训4 有序地建立完善的过程
12、检测体系与软件开发文档体系，保证以往开发经验得到客观化，定量化的分析总结和积累，使成功的开发模式可以得到规模化的拷贝。随着企业 CMM 成熟度等级的提高，项目开发中的风险可以得到逐步减低，开发时间也大大缩短，开发成本得以减少并大大降低软件产品中的错误发生率。CMM 不仅可以提高企业在国际市场上的软件出口竞争力，也可提高企业自身的软件管理与开发水平，有助于客户对企业生产能力树立信心。目前，欧美等国的大型软件用户与软件供应商共同采纳 CMM 作为供需双方软件产品质量及工程预算的标准。印度软件企业更是对 CMM 全力投入，每年定期进行 CMM 培训，目前全球通过 CMM 四级与五级的软件企业中，印度
13、占半数以上，印度企业的软件产品出口总值也从 10 年前的五千万美圆增长到五十亿美元，并预计于 2008 年达到五百亿美元。印度约有 1000 家软件企业，34 万从业人员，财富杂志全球 500 强企业中近半数为印度软件企业的客户。到 1999 年止，全球范围内共进行了 1330 次 CMM 评测，总计评测项目有 5452项，参加评测的机构逐年攀升，其中有 7.2%是海外项目，参加国别有 34 个，参加机构类型，商业机构占 56.1%，美国国防部供应商占 29.8%，军方和政府机构占 10.5%。其中，初始级机构占总评估数的 43.2%，可重复级占 34.2%，定义级占 17.3%，管理级占 4
14、%，优化级占1.4%。第二级（可重复级）比例最高的为 25 人到 100 人的机构，第三级（定义级）所占比例最高的为 1000 到 2000 人的企业，第五级（优化级）所占比例最高的为 2000 人以上的企业。由此可见，通过 CMM 第二级的最佳规模为 25 人到 100 人。三 CMM 框架软件生产过程理论告诉我们，软件质量往往取决于软件过程的能力水平，企业在软件过程中所采用的各种技术应适合该过程的成熟度水平。软件过程是一个可度量的，可控制的，不断改进的流程。CMM 强调企业应对软件过程进行连续的改进，在这一改进过程中，分级结构将提供不同等级中的目标和核心领域来规范这一过程并为企业评论和改进
15、自身生产能力提供客观标准。CMM 成熟程度理论不可以被看作纯粹的关于软件生产技术的标准，也不可以被看作普通的管理理论，它实际上是对软件开发实践所设计的整个工程流程的规定和分析，它的体系既包括软件工程过程本身，也包括对这一过程的管理。 CMM 为企业软件能力提供了一个阶段式的五级进程。任何开始采纳 CMM 体系的机构都一并归与第一级的起点，即初始级（Initial level）除第一节外，每一级都设定了各自的目标组。如果达到了这一目标，则可向下一级推进，由于每一个级别都必须建立在实现了低于它的全部级别的基础之上，CMM 等级的提高只能是一个渐进有序的过程。CMM 的评估包括五个等级，共计 18
16、个核心过程域，52 个目标，300 多个核心实践，每一级别的评估由美国卡莱基*梅隆大学软件工程研究所授权的主评估师领导的评估小组进行。其成员来自企业内部，评估过程包括企业员工培训，问卷填写，文档与数据分析，相关项目组成员面试，拟定评估报告。评估结束由主评估师签订生效。CMM 五级标准按由低到高的成熟度分别为：第一级 初始级 （Initial level）第二级 可重复级 （Repeatable level）第三级 定义级 （Defined level）第四级 管理级 （Managed level）第五级 优化级 （Optimizing level）1. 初始级 此级是个人英雄主义的天下，绝无可
17、重复性，也无甚积累，项目的执行是随意甚至混乱的，软件开发过程未经定义，即使有某些规范也并未严格执行，企业不具备稳定的软件开发与维护环境，面对开发中所遇的各类具体实施问题往往选择放弃原定计划仍由编程人员凭个人经验与主观感觉应对，对客户的承诺多数无法兑现，许诺客户的产品与服务质量并无客观的预测与监控体系保证实现。在此，能力只是个人行为不是组织行为，一旦人员流动或变动，整个企业的开发能力也随之而去。整个企业没有稳定的过程规则可依据。现有的种种规章制度也互不协调或矛盾。开发人员的工作方式是救火式，那里有漏洞就往哪里填补，很少收集关于开发过程的数据，新技术的引进也要冒极大风险。总之，整个企业的软件生产是
18、不可重复，不可预见，不成体系，不可积累及不稳定的。 本阶段改进重点包括：建立软件项目开发过程并进行有效管理；建立需求管理，明确客户要求；建立各类项目计划；建立完善的文档体系，严格执行质量监控；按 CMM 二级所规定的各项核心实践进行开发。2 可重复级确定了基本的软件生产管理和控制，能针对特定软件项目制定开发过程及管理措施，能将以往项目开发经验用于类似的新项目，有一套不同的软件生产过程提供不同项目选择。软件生产成本和工期能得以客观预测并被有效追踪，过程标准在项目实施中能保证被遵循。项目的开发是有计划的，有控制的，并可重复的行为，总原则是：一个可管理的过程是一个可重复的过程并能逐渐改进和成熟。第二
19、级的管理过程包括需求管理，项目计划，项目追踪和监控，子合同管理，质量保证与配置管理等六个方面。在该级的企业可以给客户较有保证的承诺，因为企业可在以往同类项目的成功经验上总结和建立起一整套过程准则来保证成功地重复。项目管理采用基准（Baseline）来标识进展并对成本和进度进行追踪，企业通过子合同管理同客户建立了有效的供求关系，面对开发缺陷有规则可以依据来纠正错误，个人英雄行为被稀释并分解到企业整体的规则和管理框架之中，文档的准备和项目数据的收集也相应完备。本阶段改进重点包括：将各项目的过程经验总结为整个企业的标准过程，是整个企业的过程能力得以提高，注意，跨项目间的过程管理协调和支持，树立齐全组
20、织的过程标准概念，建立软件工程过程小组（SEPG），对各项目的过程和质量进行评估和监控，使软件过程得以正确地调整。建立软件工程数据库和文档库，加强培训。3 定义级过程在整个企业范围内得以确立。企业制定了一套软件过程规则对所有软件工程和管理行为给与指导。企业有了标准化的过程并可在所开发的项目中，依据具体项目的需要，将标准过程调整为合适的项目过程。企业内部设置了软件工程小组（SEPG）负责过程的制定，修改，调整和监督。这一小组直接向企业最高领导层汇报。企业还有培训机构专门对全企业员工进行过程培训。各项目组的开发经验可相互借鉴并支持，对项目成本，工期及质量均可最终控制。有关软件工程及管理工程的过程文
21、件被编制并成为企业标准，所有项目都必须按照这些标准过程或经调整后的项目过程来实施，从而保障了每一次工程开发的投入和时间，项目计划，产品功能及软件质量得以控制。软件过程在此得到的稳定的，重复的和持续性的应用，使开发风险大为下降。各项目组人员参与软件过程的制定和修改，并引进符合项目过程的新的软件开发技术，在各项目开发过程中收集的数据被系统共享。总而言之，第三级的主要特点在于软件过程已被编制为各个标准化过程，并在企业范围内执行，从而使软件生产和管理更具可重复性，可控制性，稳定性和持续性。本阶段改进重点：应准备对整个软件过程，包括生产和管理两方面的定量评测分析，以便尽可能将软件工程所涉及的定性因素转变
22、为定量标准，从而对软件进行定量控制和预测。应使整个企业的软件能力在定量基础上可预测和控制。4管理级第四级的过程是量化的过程，所有项目和产品的质量都有明确的定量化衡量标准，软件也被置于这样一个度量体系中进行分析、比较和监控，所有定量指标都被尽可能地详细采集并描述，使之可具体用于软件产品的控制之中，软件开发真正成为一种工业化生产行为，由专门的软件过程数据库收集和分析软件过程中的各类数据并以此为对软件活动的质量评估的基准。企业所有项目的生产过程在定量化的基础上大大提高了可控制性和可预测性，生产过程中可能面对的偏差被控制在一定的量化范围内并被分析和解决，新技术的采纳也在量化基础上有控制的地进行，从而控
23、制了风险。在此级中，所有的软件过程和产品都树立了定量的目标并被定量的管理，使软件组织的能力可以很好地预测。此阶段中所有定量标准都是明确定义并持续一致的，可以用于对软件过程和管理的评估与调节。所有修正和调节方法（包括对偏差及缺陷的校正分析）都是基于变化指标上，新的软件开发技术也在定量的基础上被评估。项目组成员对整个过程及其管理体系有高度一致的理解并已学会运用数据库等方法定量地看待和理解软件工程。本级主要特点是定量化，可预测化和高质量。本阶段改进重点：注意采取必要措施与方案减少项目缺陷，尽量建立起缺陷防范的有效机制，引进技术变动管理以发挥新技术的功用，引进自动化工具以减少软件工程中人为误差，实行过
24、程管理，不断改进已有的过程体系。5优化级第五级的软件过程应是持续改进的过程，并且有一整套有效机制确保软件工程误差接近最小或零。每一个过程在具体项目的运用中，可根据周边和反馈信息来判断下一步实施所需的最佳过程，以持续改善过程使之最优化。因此，企业能不断调整软件生产过程，按优化方案改进并执行所需过程。 这样，企业的精力集中于持续的过程改进之中。新技术的采用也被作为日常活动加以规划，各项目组已具备尽早和尽快识别工程缺陷并改正错误的手段。这需要完善的数据库和长期积累的量化指标来协助实现，新技术和自动化工具也使软件工程人员能够预防软件缺陷并找到其根源以防止错误再现，企业资源在第五级阶段被有效利用并节约。
25、一般来讲，企业在优化级所遵循的持续改进措施既包括对已有过程的渐进改善，也包括应用新技术和工具所产生的革新式改进，整个企业的过程定义、分析、校正和处理能力也大大加强，这些都需建立在第四级的定量化标准之上。项目组都能主动找到产生软件问题的根源，也能对导致人力和时间浪费等低效率因素进行改进，防止浪费再发生。整个机构都有强烈的团队意识，每个人都致力于过程改进、缺陷防范和高品质的追求。本阶段总的特点是新技术的采用和过程的不断改进被作为企业的常规工作，以实现缺陷防范的目标。 CMM 描述的五个等级的软件过程反映了从混乱无序的软件生产到有纪律的开发过程，再到标准化、可管理和不断完善的开发过程的阶梯式结构。任
26、何一个软件机构的项目生产都可以纳入其中，除第一级初始级外，每一级成熟度都由若干核心过程域构成，这些核心过程域分别针对软件开发过程的某一方面阐述了这一等级的软件过程在此方面应达到的目标组的核心实践。所有核心实践又可划分为五种共性：完成目标组所需的承诺、执行能力、执行活动、测量分析、实验验证。当然，任何一个级别的核心过程域都不仅包括本级所有的核心实践。例如，第四级管理级的实现必须完成第四级本身具备的两个核心过程以及第三级中的七个核心过程域和第二级中的六个核心过程域，共十五个核心过程域。 核心过程域又称关键过程域（Key Process Area，KPA），每一个 KPA 都与一些目标相关，代表某种
27、对过程的要求，我们可根据 KPA 对软件过程进行评估并找到改进的重点所在。可见，除第一级 KPA 外，CMM 的每一级都按相同结构组成，KPA 不仅标明了某级成熟度所要求的目标和评估标准，也说明了要达到此级成熟标准所需解决的具体要点。实施每个核心过程域所包含的核心实践（Key Practices），就是实现此核心过程域所制定的目标并提高软件过程能力。如前所述，各个核心过程域中的核心实践都可按公共属性进行分类，每个 KPA 都包括五类核心实践。应该指出，核心实践只是规定了软件过程必须达到什么样的标准而未规定这些标准应如何实现，因此，对同样的过程水平，不同企业，不同项目可采纳不同的过程和实施方式去
28、完成。下面，我们将就五类不同的核心实践给予具体说明：1执行保证（Commitment to perform）：为完成核心过程域中的目标组成所需的承诺又称执行保证，它是企业执行特定的核心过程域（KPA）所拟定的指导开发过程的规则和项目管理责任。2执行能力（Ability to perform）：指企业执行核心过程域的前提条件，包括企业资源、过程制定、人员培训等多种措施。对 PKA 的执行必须建立在此基础之上，才可保证所规划的目标得以实现。3执行能力（Activities performed）：它说明了执行核心过程域所需采纳的必要行动和步骤，与项目执行息息相关，包括计划、跟踪、检测等，这是核心实践
29、的五种归类中与项目执行唯一相关的属性，其余四个属性都关注于软件组织的基础能力建设。4测量分析（Measurement and Analysis）：是关于过程的定量度测和度测分析，以确定所执行活动的效果并根据此作出分析判断。 5实施验证（Verify Implementation）：在过程执行的中途及末尾对过程实施进行验证以确保执行活动与制定的过程相一致。它包括检测、复审等一系列质量保证活动，这些质量保证活动需要通过项目组以外的独立的质检人员和管理人员来保证验证的有效执行，从而确保产品符合计划要求。如果我们把执行活动看作是与项目执行相关的属性，则其他所有属性可一起视为企业成熟度能力基础建设。在实
30、施 CMM 过程中，可根据各个企业面临的不同问题决定实现核心过程域的先后秩序并按此秩序逐步进行。而在实施每一个具体的核心过程域时，对其目标组及核心实践也可确定执行的先后顺序，逐步实现总体目标。最后，我们将第二、三、四、五等等级始终的核心过程域简介如下：第二级（可重复级） 需求管理（Requirement Management）- 软件项目的开发必须以客户的需求为指向，需求管理目的在于使开发商和客户对客户本身的真实需求有统一认识。 软件项目计划（Software Project Planning）- 软件项目管理必须事先拟订合乎规范的开发计划及其他相关计划，例如，检测与追踪计划。 软件项目追踪和
31、监控（Software Project Tracking and Oversight）- 防范项目实施过程中所产生的计划偏离问题，使项目组对软件项目的进展充分了解并控制。 软件与合同管理(Software Subcontract Management) 建立规范化的软件分包管理制度以保证软件质量的一致性。 软件质量保证（Software Quality Assurance）通过对软件开发过程的监控和评测保证软件质量。 软件配置管理（Software Configuration Management）保证在软件项目开发生命周期的完整性。 第三级（定义级） 企业过程焦点（Organization
32、Process Focus）在整个企业范围内树立标准的过程并将其列为企业工作重点。 企业过程制定（Organization Process Definition）对企业过程进行确立。 培训计划（Training Program）对项目组员工进行必要的过程培训。 集成软件管理（Integrated Software Management）调整企业的标准软件过程并将软件工程和管理集成为一个确定的项目过程。 软件产品工程（Software Product Engineering）关于软件项目的技术层面的目标在此确立，如设计、编码、测试和校正。 组际协调（Intergroup Coordination
33、）促进各项目组之间的借鉴与支持在全企业范围内实现。 同业复查（Peer Reviews）促进各项目组成员之间运用排查、审阅和检测等手段找到并排除产品中的缺陷。 第四级（管理级） 定量过程管理（Quantitative Process Management）对软件过程的各个元素进行定量化描述和分析并收集量化数据协调管理。 软件质量管理（Software Quality Management）通过定量手段追踪并掌握软件产品质量使其达到预定标准。 第五级（优化级） 缺陷预防（Defect Prevention）通过有效机制识别软件缺陷并分析缺陷来源从而防止错误再现，减少软件错误发生率。 技术变动管理
34、（Technology Change Management）引入新工具和技术并将其融入企业软件过程之中，以促进生产工效和质量。 过程变动管理（Process Change Management）在定量管理基础上坚持全企业范围的，持续性的软件过程改进，提高生产率，减少投入和开发时间，保证企业的过程长期处于不断更新和主动调节之中。 四 CMM 应用 基于 CMM 成熟度模型，包括中小企业在内的软件企业如何进行软件过程改造，如何在具体项目中引入并实施 CMM 的标准成为人们关注的重点。CMM 的实施核心焦点不在于软件的开发技术层面，而在于工程过程层面和工程管理层面。所谓工程过程层面是指将工程开发的整
35、个过程所涉及的相关议题作为过程学的体系来研究和执行。过程学本身既不同于通常所说的软件工程技术，（如编码，操作系统等等），也不同于一般所言的工程管理学，软件过程既是对软件工程这一领域中所涉及的流程按其独特特性进行专门描述。事实上，任何企业在开发工程产品的实践中，都有开发过程产生，虽然很多企业并未对其进行记录或关注。按照工程过程学派的观点，没有正确的过程就不可能有正确的产品产生，因此对开发组织的过程需要规范和改进。 由于软件过程必然与工程管理相关，因而它不象具体的开发技术问题那样容易规划并着手实施，特别是国内广大的中小软件企业和部门，在采纳某一过程体系进行开发流程的改造时，应特别注意如下几方面的问
36、题，将其作为过程实施开端的要领加以掌握：1不可急于求成和盲目乐观。任何新体系的采纳和改进都必然涉及对旧有体系的重组和调整，需要投入相当的决心和时间。如果企业在充分评估后决定了以 CMM 工程标准来规范建构自身的软件开发行为，则应该在次序改进的前提下尽早实施企业开发过程调整以便有充裕时间理解和评估前期改造的成效。2必须懂得 CMM 作为一套标准，它指明的是该作什么（What）而非怎样去做（How），同时CMM 也代表了一种对软件生产过程进行理解和分析的独到观点（Philosophy）。CMM 着重于过程中的关键要素，而非面面俱到，它主要不是为了解决某个具体项目的问题，也不能保证在此框架下产品开发
37、 100%成功，CMM 所述的软件过程集合了工程过程和管理过程等方面，对它的过程改进要靠许多细小的阶段性的步骤而非一蹴而就的革新。3CMM1.1 版主要针对大型软件企业，这些企业的开发工作通常关涉软件生产过程的方方面面。对于 20 人以下的小型企业，1.1 版中的一些环节可能并不适用。4企业在采纳 CMM 过程改进的同时，可以引入新技术与自动化工具帮助软件开发的实现，不过，对过程的改进要求企业全面投入并需较长周期，而技术引进则相对周期较短。但如果企业只是依靠技术改进而不注重过程改进，长远看来，企业可能收获甚少。5“知己知彼，百战不殆“。实施改进之前，企业应对自身当前所有的软件能力水平及过程状态
38、有尽可能的客观、详尽的了解。可以参考本文后附企业开发能力自测表进行初步诊断，在明了自身实际过程等级之后，企业应确定需要达到的等级目标并找到主要差距所在。企业要想达到的等级目标包括它所特定的过程目标及核心过程域（KPA）。这一等级应符合企业自身开发水平与项目特征。在企业明了了自身实际等级与目标等级之间的差距之后，应制定规划，决定改进次序及程度，可参考的决策因素包括：目标与能力的平衡，投入工期与质量的保证，企业总体发展与当前项目开发的平衡，员工素质条件，最薄弱环节与最急需改进环节，还有最易见效的环节，等等。6如有可能，在企业内部成立专门的过程改进规划组，并配合企业外聘的咨询机构或顾问，拟订出详细的
39、过程实施方案，同时注意在实施过程中对计划进行修正和调节。在此，应将改进方案指定得尽量具体详细，这包括： 目标明确并可检验,有助于切实的检验标准；有详细的实施步骤,有专人负责每一环节的落实,有协调方解决各环节之间的冲突；如需采纳新技术和工具，应详细分析他们的作用及获取方式并准备对新技术和工具进 行改造，对员工进行培训以适应项目所需。制定项目开发时间表，将每个过程环节的实施与此时间表挂钩。对项目开发的投入工期进行预测并据此规划开发工作。 预先规划开发过程中相关数据的采集，分析和提供方式与时段；所有过程，包括：需求分析、项目计划、项目验收和交付，都必须编档并保留，应有具体的监控和考核计划来监督过程的
40、实施。这一计划应考虑到偏差的可能性及应对方案。企业的高层和相关管理人员应参与过程的制定与实施并形成制度。领导层应负责对每一阶段改进的总结并制定出相应的后继方案，另外，凡涉及对已定计划和过程的调整必须事先申请备案并经领导层同意。需强调的最重要的一条原则是，过程改进不可流于书面形式，所有员工都应理解并参与其中。 CMM 模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施 CMM 的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术
41、上的 how to do。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。作为一种模型，CMM 实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。目前，世界范围内已采纳 CMM 标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳 CM
42、M 体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。卡莱基梅隆大学软件研究所提出了一套实施 CMM 标准的方法，按照他们的建议，IDEAL 是企业开始引入 CMM 体系的良好参照模式，它包括：I-启动（Initiating）,表示开发机构应为 CMM 的引入准备好前期基础设施和程序。D-诊断（Diagnosing）,明确机构目前所处的能力水平及目标等级所在。E-建构（Establishing）,制定如何实现目标等级的计划。A-行动（Acting）,具体实施该计划。L-学习（Learning）,积累以往经验并将其用于持续的改进过程之中，同时注意新技术和工具的引入以协助过程实施。如有可
43、能，企业在咨询机构或咨询师的协助下可以加快 CMM 体系引入的过程，但企业必须同时着力于培训自身理解工程过程的人才。较好的方法包括在开发组织内部分项目形成 CMM 研讨小组以促进开发组及开发人员之间的经验交流。显而易见，实施 CMM 的成效应根据机构自身特有的实际情况作判断，正确的实施应该从质和量两方面对过程的各环节发生作用。CMM体系在中小企业的应用中并未要求逐字照章对应每一项核心过程域和核心实践来进行，机构可以用裁减的办法对其应用程度作修正，也可选用阐述的办法将某项具体的实施工作等同为特定的核心实施。根据 SEI 的研究数据，绝大多数软件项目的成功都遵循了下述的工程原则：a,将软件生命周期
44、划分为若干阶段并进行严格的计划，包括项目计划，里程碑计划，质量检测计划，维护计划等。b,在开发过程中，分阶段进行复审和评估，以便尽早发现错误所在。 c,项目组成员应注重包括技术和流程在内的培训，提高人员素质。d,软件过程的改进应是持续性的，不断调整的进程。e,尽可能采用度量数据来描述过程中的每一环节，从而提高可预测性和可控制性。f,对以往所有开发工作必须进行文档工作，积累经验以用于未来的开发之中。g,如果项目允许，尽可能采纳较为先进的技术与工具，例如，面向对象的编程方式(OOP)五 可重复级达到可重复级软件能力成熟度能力的企业有能力重复在以前项目上所作开发的成功经验，虽然项目的具体实施各不相同
45、，但通过企业的制度化的有效管理过程，各项目组能够在当前和未来的项目中保证已建立的软件项目管理和实施规则能够得到正确和有效地执行，从而可在新项目上用积累的制度化有序化和文档化的经验进行有成功保障的开发实践，这种成功保障也可在开发前期的项目成本，工程进度和质量预算上得到体现。在此阶段的软件开发组织已拥有了一套有效过程，它们是实用的、文档化的、实施验证过的、可测量的和能改进的。单个项目组通常会面对各类项目约定问题，项目组对项目的正确约定来源于以往开发项目的经验及当前项目的各级需求。项目经理应成为一个有序体系中的重要环节，他们负责追踪软件成本、进度和功能，能迅速发现项目级约定中出现的问题并设法解决。各
46、项目组对软件需求和实现需求的软件产品已建立了基于验证的基准或基限，项目标准也得到确立，软件组织能保证正确地执行标准。第二级软件组织的过程能力是有纪律的，项目的规划和追踪是稳定的，项目过程也在项目管理体系的有效控制之下重复着被验证的成功经验。在此，组织体系和管理的问题比技术问题更加重要。一个成熟度等级是一个正确定义的向软件更高成熟度进步中的平台。除第一组外，每个成熟度等级被分为若干核心或关键过程域，帮助软件企业明了改进其软件过程所应关注的环节。这些环节都是为了达到此一等级所必须解决的问题。SEI 制定的各个核心过程域都标志出了一系列相关的工程活动。理论上，完成全部活动软件组织应能实现一个或数个对
47、增进过程能力绝对重要的目标。为使软件开发组织实现特定的核心过程域，它必须实现与该核心过程域相关的所有目标。虽然由于各个项目的应用环境不同，导致实现核心过程域各目标的途径不同，所有核心过程目标都应由软件组织实现。如果软件组织的所有项目都已持续实现特定核心过程域的所有目标，则该软件组织已具备该核心过程域所代表的所有过程能力并使其规范化。由于 CMM 并不描述所有与软件开发和维护有关的过程领域，它所选的是在改进软件组织过程能力上最有效的，最具影响力的环节和达到一定成熟度等级的必要条件。 CMM 全部五级能力成熟度等级的实现是一个有序的渐进过程，软件开发组织和项目组为了实现某个成熟度等级必须首先实现该
48、等级中的全部核心过程域，而为实现一个核心过程域，首先应该达到该过程域的每一个目标的要求。这是因为 SEI 定义的目标概括了一个核心过程域的核心或关键实践，用以判断软件组织或项目是否已经有效地、正确地实现了该核心过程域。每一个目标都表明了一定核心过程的范围、界限和意义。随着软件组织向更高能力成熟度的前进，它在每个核心过程域中所应实施的具体活动内容也有所发展。可重复级的核心过程域反映了软件项目应关注的与基本项目管理和控制有关的事项：需求管理在软件项目和客户之间尽可能明确客户自身对该软件项目或产品的真实需求，需求双方有一致的、细致的和可靠的对需求的共同认识。软件项目组将负责按既定程序处理客户的所有事
49、项，此核心过程域保证了与客户的协议成为软件项目计划和追踪监控的基础，应注意在此项目组或组织与客户的关系上应遵循正确有效的，如配置管理中所述的变动控制过程。 软件项目计划制定进行软件工程和软件项目管理的适当计划，并使之成为项目管理的基础所在。项目组可据此对软件项目追踪和监控。一个细致的、切合实际的计划是有效实施项目管理的保证。软件项目追踪与监控建立适当的对软件工程实际进展的可视性与控制性，以使项目管理者在该项目明显偏离原计划时能采取有效的纠正措施。软件子合同管理帮助软件开发组织在软件开发的整体商业环境中正确选择合适的软件工程与合同承包商并对其实施有效管理，它应有效协调软件质量保证、软件配置管理等核心过程域中诸相关因素与基本管理控制的核心过程域中的重要因素，包括需求管理、软件项目计划以及软件项目追踪与监控等。 软件质量保证为软件开发提供关于软件项目的过程和软件产品的状况的可视性与控制性，它是软件工程过程和软件管理过程必不可少的组成部分。软件配置管理在软件项目开发的整个生命周期中，确立和维护有关产品的完整性。它与软件工程涉及的一系列硬件、软件与系统的正确、高效的配置和应用息息相关。六 定
