|
|
 |
|
 |
中国电子标准化研究所吴源俊
随着我国计算机软件产业的形成和发展，软件产品质量保证这一课题逐渐受到各个软件开发组织和政府有关管理机构的重视。一些规模较大的软件开发组织各自在本单位运用质量管理理论指导开展了软件产品质量保证活动；有些软件开发公司引入了国际通行的质量管理体系质量保证模式——ISO9001（或ISO9002）。鉴于软件产品本身及其开发和生产的特殊性，不少软件开发组织在实施ISO9001的同时亦不同程度地感到ISO9001（加上ISO9000-3）与他们的实际活动不是那么相适应。于是，一种专门针对软件开发组织的软件质量保证模型悄然进入我国一些软件开发组织和有关研究单位的研讨日程，这就是CMM。
近几年来，我国一些单位有组织地或自发地开展了对CMM的研究，有的还在本单位内进行了尝试性的CMM实施。特别是自1998年以来，我国计算机软件业界对CMM的研究热迅速升温；“采用ISO9001还是CMM?”的问题也悄然出现。无论是实施ISO9001，还是寻求运用其他软件产品质量保证渠道，这些对保证软件产品质量的热情正是我国软件产业正在走向成熟的标志。恰当地选择软件开发组织的产品质量保证途径不仅将有助于各个软件开发组织提高软件产品开发和生产能力，亦将为加快我国软件产业的成熟作出贡献。鉴于CMM在其“原产国”实际应用中的有效表现，引起包括我国在内的许多国家软件业界的兴趣，国际标准化组织（ISO）也顺应各国的兴趣而开展了与CMM密切相关的标准课题研究。本文将对CMM作简要介绍，并且把CMM与ISO9001加以比较，最后谈谈CMM的应用问题。
一CMM简介
我国目前谈及的CMM是指“软件能力成熟度模型”，其英文全称为Capability Maturity Model for Software （英文缩写名是SM-CMM），更确切地说，是指“软件能力成熟度模型.1.1版”和“能力成熟度模型的关键惯例.1.1版”（Capability Maturity Model for software,Version1.1和Key Practices of the Capability Maturity Model,Version1.1简称CMM1.1版}。CMM是美国卡内基—梅隆大学软件工程研究所（以下简称SEI）的研究成果；CMM1.1版发表于1993年。SEI是美国国防部出资于1984年设立。从1986年开始，SEI针对软件组织改善其软件过程，特别是美国国防部对软件承包商的能力评价问题，研究“过程成熟度框架”。1987年9月，SEI发表了关于过程成熟度框架的简要说明和成熟度调查问卷。以这一过程成熟度框架为蓝本，在美国联邦政府促进下，从1987年到1991年在美国的一些大公司的软件组织进行了软件过程能力成熟度模型的评估实践。根据这4年的实践经验，特别是从美国政府和工业界反馈的关于软件过程评估的信息，SEI在原过程成熟度框架的基础上开发出了“软件能力成熟度模型（CMM）0.0版”。在CMM0.0版发表后的两年里，先后产生了30多稿草案，于1993年2月发表了“软件能力成熟度模型1.1版”和“能力成熟度模型的关键惯例1.1版”（统称SM-CMM1.1版，有时干脆简称为CMM）。
大家都知道，软件产品的质量在很大程度上取决于构筑软件时所使用的软件开发和维护过程的质量。软件过程是人员密集和设计密集的作业过程；若缺乏有素的训练，就难以建立起支持实现成功改进软件过程的基础，改进工作亦将难以取得成效。CMM描述的这个框架正是勾列出从无定规的混沌过程向训练有素的成熟过程演进的途径。
迄今为止，CMM既不是政府标准也不是行业协会标准，而是美国卡内基—梅隆大学软件工程研究所（SEI）发表的一份技术报告；不过，它在美国已成为事实上的标准。鉴于CMM的巨大应用前景，SEI已在美国注册了CMM, Capability Maturity Model和Capability Maturity Modeling的专利和商标。与此同时，围绕以CMM为基础的软件过程评估和软件能力评价建立了从审核员培训到提供评估和评价的一整套服务体系。
SEI给CMM下的定义是：对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。
如前所述CMM1.1版包括两部分：“软件能力成熟度模型”和“能力成熟度模型的关键惯例”。“软件能力成熟度模型”主要是描述这种模型的结构，并且给出该模型的基本构件的定义；为便于读者理解，还进一步对成熟度模型及其构件做了大量解释。“能力成熟度模型的关键惯例”除了重复叙述能力成熟度模型结构及其构件外，以大量篇幅详细描述了每个“关键过程方面”涉及的“关键惯例”。“关键过程方面”是指：一组相关联的活动；通过执行这些活动可以实现既定的过程能力。所谓“关键惯例”是指：使关键过程方面得以有效实现和制度化的作用最大的基础设施和活动。各个关键惯例按每个关键过程方面的5个“公共特性”（对执行该过程的承诺，执行该过程的能力，该过程中要执行的活动，对该过程执行情况的度量和分析，及证实所执行的活动符合该过程）归类，逐一详细描述。按CMM的规定，作到了某个关键过程的全部关键惯例就认为实现了该关键过程，实现了某成熟度级及其以低各级所含的全部关键过程就认为达到了该级。
CMM把软件开发组织的能力成熟度分为5个可能的等级。除了第1级外，其他每一级由几个关键过程方面组成。每一个关键过程方面都由上述5种公共特性予以表征。CMM给每个关键过程规定了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就达到了，也就表明该关键过程实现了。这种分级的思路在于把一个组织执行软件过程的成熟程度分成循序渐进的几个阶段，这与软件组织提高自身能力的实际推进过程相吻合。这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。这一点很重要，因为大多数软件组织只能在某一段时间里集中开展少数几项过程改进活动。
CMM总体结构图示说明参见图1。
图1能力成熟度模型的结构
CMM的开发者们结合他们的软件产业环境和软件产品质量保证的需要，在CMM1.1版中把具有最高能力成熟度的组织设定为处于这样一种情况下的组织：整个组织都持续致力于过程改进；这个组织具备足够的手段用于事先发现过程的长处及短处和防止发生缺陷；它拥有丰富的软件过程成功经验的数据并且可用于对新技术进行“费/效”分析和提出对本组织软件过程的更改建议；它能发现那些可能发掘出最佳软件工程惯例的合理化建议并使之在整个组织里实现转化。这种能力成熟度被定义为CMM的第5级，称之为“（持续）优化级”。
另一方面，现实的软件业里尚有不少组织还不具备稳定的环境用于软件开发和维护,它们缺乏健全的管理惯例，其软件过程能力无法预计；它们的软件过程是一片混沌；并且它们的软件过程总是随着软件开发工作的推进而处于变更和调整之中。这种情况被CMM定义为第1级能力成熟度，称之为“初始级”。
第2级为可重复级。在处于可重复级的组织里，顾客的需求和本组织的工作产物是受控的并且建立起了基本的项目管理惯例。藉以产生软件产品的一系列过程有如一连串“黑盒子”；尽管管理者可能不知道在“黑盒子”里具体发生了什么，但是，他能掌握过程的产物和那些确认过程是否正常的校验点，从而在发生问题时作出反应。这一级有6个关键过程方面，共含121个关键惯例：
——需求管理（12，这是关键惯例数，以下同）
——软件项目策划（25）
——软件项目追踪和监督（24）
——软件分包方管理（22）
——软件质量保证（17）
——软件配置管理。（21）
第3级是（明确）定义级。在这一级，对于在整个组织里用于软件开发和维护的标准过程以文件形式被固定下来。针对各个基本过程建立起文件化的“标准软件过程”，这是第3级能力成熟度的突出特点。这些标准软件过程（包括工程过程和管理过程）被集成为一个相关的整体；这些标准软件过程有助于软件经理和技术人员更有效地履行他们的职责。实践表明，对软件过程加以标准化的过程，也就是发掘高效软件工程惯例的过程。而标准软件过程的建立和实施则为本组织软件项目的实施提供了公共的工程环境。较普遍的看法是，只有当达到了第3级能力成熟度时，才表明这个组织的软件能力“成熟”了。因为，在到达这一级后，表明上述的“黑盒子”被打开了。在第2级的基础上，第3级包括7个关键过程方面，共含108个关键惯例：
——组织过程定焦（16）
——组织过程定义（11）
——培训（16）
——集成式软件管理（19）
——软件产品工程（20）
——组间协调（17）
——对等审查。（9）
第4级是定量管理级。处于这一级的组织已经能够为软件产品和软件过程设定定量的质量目标，并且能对跨项目的重要软件过程活动的效率和质量予以度量；可以利用本组织的软件过程数据库汇集各项目软件过程产生的数据并加以分析。处于第4级是，该组织的各个软件过程是用各种确切定义并且一致地尺度来说明的；这些尺度是用以评价项目的软件过程和产物的定量基础。在第2，3级的基础上，第4级包括两个关键过程方面，共含32个关键惯例：
——定量过程管理（19）
——软件质量管理。（13）
如前所述，第5级叫持续优化级。在前几级的基础上，第5级包括3个关键过程方面，共含59个关键惯例：
——缺陷预防（18）
——技术变更管理（22）
——过程变更管理。（19）
CMM1.1版总计18个关键过程方面，320个关键惯例。
这18个关键过程方面可以划分为3大类：管理类，组织类和工程类。其中有的关键过程方面是跨类的，见图2。
软件组织的成熟度等级只能逐级递进，不可能越级。成熟度级别的提高也就意味着实现的关键惯例大幅度增加；其间关系见图3。
图2关键过程方面分类
图3成熟度等级递进与关键惯例含量
二CMM与ISO
CMM和ISO9001都涉及质量管理和过程管理，并且都受到类似的厉害关系驱动，两者之间有着相似之处。因此，往往产生这样的问题：
——符合ISO9001的软件组织达到CMM的哪一级？
——达到CMM的第2或3级的软件组织是否符合ISO9001？
——一个组织打算推进质量管理或改进软件过程时是采用ISO9001还是采用CMM？
ISO9001被认为是适用于所有各类专业领域的一种质量保证模式；但是，对于软件组织来说，尽管加上了ISO9000-3作为实施指南，ISO9001似乎仍然不够贴切，留给审核员作解释的回旋余地相当大。于是就软件能力评定而言，按ISO9001进行认证时，不确定性很大；换言之，同是通过了ISO9001认证的组织，其间的软件能力可能有很大差别。
CMM是专门针对软件组织设计的一种描述软件过程能力的模型。CMM研制的主要目的有二：一是用于帮助事先确定承包商的软件能力；二是用于软件组织的过程改进。考虑到按ISO9001对软件组织进行认证审核时存在的较大不确定性，在设计CMM时，注意了尽量缩小审核员解释的回旋余地，因此，不仅对每个关键过程方面给出了明确的目标和体现这些目标的各个关键惯例，而且对各个关键惯例都给出了明确的定义和详细的说明，以期按CMM进行评估时能有较大的一致性和可靠性。结果，CMM成了一个“庞然大物”——长达500余页。
如上所述，CMM与ISO9001的设计思路不同，并且一个是“专用”，一个是“泛用”，因此，尽管两者都由于涉及质量管理和过程而有着相似之处，但也存在很大差别。下面依次按ISO9001的20个要素对CMM作一些简单比较。
1.管理职责
ISO9001要求确定质量方针并且加以文件化，理解，执行和维护；要求确定所有员工在规定，达到和监控质量方面的责任和权限；要求确定自有的验证资源，进行培训和给予财政支持。由一名指定的经理保证质量计划的实现和维护。
在CMM中，管理层在质量方针和验证活动方面的责任主要反映在“软件质量保证”中，在“软件项目策划”和“软件项目跟踪和监督”中只是指出履行所有项目角色时的责任。
高级管理层和项目管理层的软件项目管理责任是在确认实现中反映。一般，领导问题反映在公共特性的“承诺”方面，组织和资源问题反映在公共特性的“能力”方面。虽然CMM在第4级的“软件质量管理”中也描述了质量方针，不过，第4级的质量方针是定量的。此外，ISO9001中关于度量在质量管理体系中的作用也有点含糊，ISO9001第4.20条要求确定质量目标并且形成文件，而没有要求量化。
2.质量体系
ISO9001要求建立文件化的质量体系，包括程序和指导书。ISO9000-3以质量体系作为整个软件生存周期的综合过程。
CMM主要在“软件质量保证”中涉及质量体系活动。各项程序分布在“关键过程方面”的各项“要执行的活动”中。
软件项目将用到的特定程序和标准在“软件项目策划”中描述的软件开发计划中规定。通过“软件质量保证”和执行“确认实现”中的审核活动来确保符合这些标准和程序。
“软件产品工程”要求确定各项软件工程任务，加以综合并且统一执行；这一点与ISO9000-3关于此条的指南对应。
CMM第3级“组织过程定义”这一关键过程方面描述了一组组织一级的软件过程财富，包括标准，程序和过程说明。运用“组织过程定义”肯定有助于达到此条要求，但是在ISO9001的这一条里，标准和程序可能直接在项目级处理。ISO9001讨论供方的质量体系，而不讨论组织支持与项目实现的关系；CMM作了讨论。另一方面，在ISO9000-3中，关于质量策划的指南有两节：4.2.3节讨论跨项目的质量策划；5.5节讨论具体开发工作中的质量策划。
3.合同评审
ISO9001要求评审合同，以确定各项要求是否充分规定，是否与标书一致，是否能实现。
在CMM中，对顾客软件需求的审查在“需求管理”中叙述。软件组织（供方）确保分配给软件的（系统）要求形成文件并且予以审查，确保那些可能引起误解的或含混的要求得以澄清。因为CMM仅限于软件方面，所以顾客需求作为一个整体归于“需求管理”这个关键过程方面里。
CMM中的“软件项目策划”描述了为签定合同而要提出的软件开发计划建议和工作陈述，并且要求软件工程组和高级管理层加以审查。
CMM还就软件组织通过分包获得软件的情况作了规定（在“软件分包方管理”中叙述）。合同可以是与某个外部顾客的，也可以是与分包方的；虽然这一点在ISO9001的这一节中没有明确规定，但也可以意识到。
4.设计控制
ISO9001要求建立控制和证实设计的程序。这包括策划设计活动，标识输入和输出，证实设计和控制设计变更。ISO9000-3用了几条来详细描述了这一条：购方需求规范（5.3），开发策划（5.4），质量策划（5.5），设计和实现（5.6），测试和验证（5.7）和配置管理（6.1）。
CMM中，需求分析，设计，编码和测试等生存周期活动在“软件产品工程”中描述。这些活动的策划是在“软件项目策划”中描述。“软件项目跟踪和监督”描述这些活动的控制，而“软件配置管理”描述的是这些活动产生的软件工作产物的配置管理。
ISO9001要求进行诸如记录并且保存设计审查和鉴定测试之类的设计控制手段。ISO9000-3指出，供方应该进行审查，以保证需求得到满足和设计方法得到正确执行。虽然对设计控制手段有要求，但是使用了“shoud”（最好）之类短语则为具体控制手段的使用赋予了灵活性。相反，CMM要求专门的质量控制机制：对等审查。“对等审查”这一关键过程方面支持生存周期从需求分析到测试的各个过程。
“软件质量管理”中描述的定量的设计过程方面更为正规，但ISO9001不一定要求这种正规程度。
5.文件控制
ISO9001要求对文件的分发和修改予以控制。
在CMM中，反映文件控制的配置管理惯例在“软件配置管理”中描述。在CMM中，可以置于配置管理下的具体程序，标准和其他文件分布在各个关键过程方面的各种“要执行的活动”惯例中。为运行和维护质量体系所要求的文件在“软件产品工程”的“活动8”中作了具体规定。
6.采购
ISO9001要求采购的产品符合它们的规定要求。这包括评估潜在的分包方和验证采购的产品。
在CMM中，这个要求反映在“软件分包管理”中。分包方的评估在“活动2”中描述，分包软件的验收测试在“活动12”中处理。
7.顾客提供的产品
ISO9001要求任何由顾客提供的物资都要经过验证和予以维护。ISO9000-3是在包含软件产品（包括商业现货软件）的条文（6.8）中讨论这一条。
在“综合软件管理”中的“活动6.3”是CMM中描述外购软件使用的唯一惯例。它把标示现货软件或可再用软件的条款作为项目策划的一部分。现货软件和可再用软件的综合是CMM中的薄弱方面。这一条在ISO9000-3中专门做了扩展，而CMM考虑得不够。虽然不够，不过，“软件分包管理”的“活动12”中分包软件的验收测试惯例可用之于任何所包含的软件产品，算是一点弥补。
8.产品标识和溯源
ISO9001要求在产品生产，交付和安装的所有阶段都要给产品加标识并且可追溯。
CMM覆盖这一条的主要是“软件配置管理”，不过“软件产品工程”的“活动10”指出了对软件工作产物之间的一致性和可追溯性的特定要求。
9.过程控制
ISO9001要求确定各项生产过程并进行策划。这包括在受控条件下按照文件化的作业指导书进行生产。对于未能充分验证的专用过程要持续监控。ISO9000-3有几条包含了此条内容：设计和实现（5.6）；规则，惯例和约定（6.5）；以及工具和技术（6.6）。
CMM中规定软件生产过程的程序分布在各个关键过程方面的各项“要执行的活动”惯例中。将用到的具体惯例和标准，按“软件项目策划”的“活动7”所述，在软件开发计划中规定。软件生产过程的定义和集成在“软件产品工程”中描述。过程保证在“软件质量保证”的“活动4”中描述（产品保证在“活动5”中规定）。
在CMM中，“定量过程管理”涉及到定量控制，并且要求给出统计过程控制的例证，而按ISO9001的审核中一般不要求满足这一条。
值得注意的是，ISO9000-3第6.6条指出，供方在必要时应改善这些工具和技术，以便把新技术引入本组织（与CMM中“技术变更管理”讨论的内容相近）。
10.检验和测试
ISO9001要求对进货在使用前检验或验证，要求进行过程中检验和测试。在成品予以放行前执行最终检验和测试。检验和测试记录予以保存。
CMM是在“软件产品工程”中的第5，6和7项活动里描述测试问题。关于软件方面的过程中检验是在“对等审查”中处理。
11.检验，测量和测试设备
ISO9001要求对用于证明符合性的设备于以控制，校准和维护。在使用测试硬件和测试软件时，要在使用之前检查并且按预定的时间间隔复检。ISO9000-3在以下几条中对这一条作了澄清：测试和确认（5.7）；规则，惯例和约定（6.5）；以及工具和技术（6.6）。
在CMM中，此条是在“软件产品工程”的测试惯例中做了一般性处理。在“能力1.2”（描述支持测试的工具）中特别提到了测试软件。
12.检验和测试状态
ISO9001要求，随着软件项经由各个处理步骤推进时，其检验和测试状态得以维护。
在CMM中，用“软件产品工程”的测试惯例和“软件配置管理”中的“活动5”（问题报告）和“活动8”（配置状态）处理这一条的要求。
13.不合格品的控制
9000-3把这个概念映射到以下几条：设计和实现（5.6）；测试和确认（5.7）；复制，交货和安装（5.9）以及配置管理（6.1）。
在CMM中，设计，实现，测试和确认是在“软件产品工程”中处理。在“软件配置管理”中，“活动8”涉及软件配置项的状态，包括已知有缺陷（但尚未定位）的软件项的状态。ISO9001第4.15条所述的安装在CMM中未涉及。
在制造业里，这一条很重要，因为有时有必要使用未符合全部要求的构件建造产品。在做这种决策后，必须小心控制不合格品。
与之类似，在软件业，有时系统可能使用的工具或复用软件没有满足全部相关的标准。例如，如果已在以前的应用中证明FORTRAN码的价值，在Ada程序中复用FORTRAN码也许有良好“费/效”比。然而，这个码可能给Ada系统带来很大风险，必须充分掌握这种风险。
CMM中没有专门谈及不合格品。ISO9000-3中，有关不合格品的要求基本上隐含在软件生存周期的许多有关过程中：设计和实施（5.6）；测试和确认（5.7）；复制，交付和安装（5.9）和配置管理(6.1)。
14.纠正措施
ISO9001要求找出造成不合格品的原因，消除造成不合格品的潜在原因，根据纠正结果改变程序。
这一段的文字隐含着CMM中“缺陷预防”里的许多惯例。这一段中讨论的纠正措施往往是顾客投诉引发的。因此往往是由软件工程组查找现场缺陷，分析其发生原因，并且采取纠正措施。这种情况常常发生在对现场软件的修补或升级过程中。按CMM的思路，是在报告问题之后对基线工作产品的维护加以控制。问题报告是在CMM的“软件配置管理”中描述。
从审核角度看，纠正措施是要处理审核中发现的不符合项，无论是内部还是外部审核中发现的。这一点是在CMM的“软件质量保证”中处理。
在ISO9001运用于软件领域时，这是个有争论的问题。有的认为软件领域的缺陷预防过程与制造业环境的类似，有的认为只要求涉及用户问题报告即可。在CMM中，此点亦尚无定论——究竟“缺陷预防”中要描述多少过程中因果分析和缺陷预防才能满足ISO9001中这一段的要求，还有争论。
15.搬运，储存，包装和交付
ISO9001要求建立并维护关于搬运，储存，包装和交付的程序。
ISO9000-3中与这段对应的是接受（5.8）和复制，交付和安装（5.9）。
CMM中没有覆盖复制，交付和安装。在“软件产品工程”的”活动7”涉及验收测试，而“软件配置管理”的“活动7”描述了软件产品的创建和释放。不过CMM中没有描述交付和安装产品。
从CMM的修订版情况看，可能将在“软件产品工程”这个关键过程方面中增加一个关于软件产品交付和安装的惯例。
16.质量记录
ISO9001要求收集，维护和处置质量记录。
在CMM中，对需要维护的质量记录加以定义的惯例是以“要执行的活动”的形式分布在各个关键过程方面。在“软件产品工程”中的测试和对等审查惯例，特别是“活动9”中关于缺陷数据的收集和分析反映了这一段的内容。问题报告是在“软件配置管理”的“活动5”中描述，而对等审查数据的收集是“对等审查”的“活动3”中描述。
17.内部质量审核
ISO9001要求策划并执行质量审核。审核结果要通知管理层，发现的缺陷要予以纠正。
在CMM中，质量审核过程由“软件质量保证”描述；具体的审核要求反映在“确认实现”这一公共特性的审核惯例中。
18.培训
ISO9001要求确定并提供必要的培训，因为所选择的任务可能要求有相应资格的人员。培训记录要维护。
CMM中，是在“执行能力”这一公共特性的培训和定向惯例中反映具体的培训需要。
一般性的培训设施是在“培训大纲”（包括“活动6”中的维护培训记录）中描述。
19.服务
ISO9001要求按规定执行服务活动。ISO9000-3把这一段的要求作为维护（5.10）来处理。
虽然CMM的意图是既适用于软件开发也适用于维护环境，但CMM中的惯例并不直接处理属于维护环境的独特特性。维护被镶嵌在CMM的各个惯例中，并且必须按开发或维护的前因后果作相应解释。
因此，在CMM中，维护不是一个独立的过程。从CMM的修改情况看，有可能在措辞上更明确地涉及维护环境，以便清楚地表达CMM在维护项目方面的应用。
20.统计技术
ISO9001指出，适用时，应确定适当的统计技术并且用于验证过程能力和产品特性的可接受性。ISO9000-3简单地在度量（6.4）中表述了这一段的特性。
CMM中描述度量的惯例分布在各个关键过程方面。产品度量一般是包含在各个“要执行的活动”惯例中，而过程度量是在“度量和分析”这一公共特性中描述。
“组织过程定义”的“活动5”描述了建立组织级数据库，以便本组织用于收集过程和产品数据。这种数据库是在组织一级维护。在CMM中，项目级的统计数据是在第2级里各个项目管理关键过程方面描述。
如果说这一条指的是统计过程控制，那么，在CMM中是通过“定量过程管理”和“软件质量管理”予以满足。不过，要注意是在“适用时”使用统计技术。
由上述的大致比较可以看出，尽管ISO9001中的一些内容在CMM中没有覆盖，CMM中的一些内容在ISO9001没有涉及，但是，ISO9001与CMM之间有着很强的相关性。不过，细节上的差别很大：ISO9001第4章大约有5页；（ISO9000-3的第5，6和7节大约11页；）而CMM长达500多页。不过，这两分文件间的最大差别在于，CMM强调的是持续的过程改进；而ISO9001涉及的是质量体系的最低可接受标准。此外，CMM专门针对软件领域，而ISO9001适用范围很广（硬件，软件，流程性材料和服务）。
CMM和ISO9001这两者的最大相似之点在于它们都是“说你要做的，做你要说的”。ISO9001的基本要求在于，在整个质量控制活动中每个重要过程都应该文件化并且每个交付件都接受质量检查。
ISO9001要求编制出指导书或指南之类文件，用以说明应该做什么或应该如何做。在CMM中，同样强调过程和惯例要“文件化”。
CMM强调要求记录信息以便供该过程以后使用或供改善该过程用。这相当于ISO9001中的质量记录——证明所要求的质量是否达到和质量体系是否有效运行。
若仅从上述ISO9001和CMM中的基本概念比较看，似乎可以得出结论：获得ISO9001认证的组织应该处于CMM的第3或第4级。但是，有资料表明，有的组织虽然尚处于第1级，也取得了ISO9001认证。原因之一是由于ISO9001的高度概括性而造成的对文件解释的多样性。
那么，一个符合ISO9001的软件组织，如果它完全没有实现ISO9001中未包含的管理或工程惯例，它处于CMM的哪个成熟度等级？这是一个极端情况，不过它给出了一个符合ISO9001的组织的成熟度的下边界。图4示出这个组织的关键过程方面的轮廓。图中，黑影表示ISO9001或ISO9000-3直接谈到的关键惯例；灰影表示按照对ISO9001的解释可能涉及的关键惯例；无阴影表示ISO9001未涉及的关键惯例。因此，就各个关键过程方面而言，根据不同解释，可以得出部分满足或全部满足或不满足的结论。阴影条的长度表示ISO9001或ISO9000-3中涉及到的关键惯例的百分比。
图4一个符合ISO9001的组织的关键过程轮廓
由此轮廓可看出，处于CMM第1级的组织的确有可能通过符合ISO9001的认证；同时，该组织又可能具有很强的第2级的过程实力和明显的第3级的过程实力。在美国的有关业界里普遍认为，一个得到并且维持ISO9001认证的组织，它应该是接近第2级的。
如果一个组织遵循ISO9001的精神，而不止于符合其书面条款，这个组织有可能接近或超过了第2级。一个软件组织可以得到ISO9001证书但却处于第1级，这种情况反映出ISO9001的精神与字面的差别。
是否可以把处于第3级的组织看成是符合ISO9001的呢？不行，因为即使这个组织处于第3级，它还需要确保ISO9001的（4.15）条中描述的交付和安装要求得到满足，并且应该考虑ISO9000-3中（6.8）条描述的“所包含的软件产品的使用”。当然，这些要求对处于第3级的组织来说是微不足道的，即使是处于第2级的组织也不难通过ISO9001认证审核。
从上述分析不难得出这一结论：在CMM中，虽然有的问题谈的还不够充分，但大体上包容了ISO9001，ISO9001却不能包容CMM。
那么，软件过程改进应该以CMM为基础（也许再补充一些ISO9001的内容），还是致力于ISO9001认证？对于一个软件组织来说，市场可能要求它拥有ISO9001证书。无疑，瞄准CMM的要求进行软件过程改进将有助于本组织通过ISO9001认证审核。就软件过程改进而言，虽然这两份文件都可用，不过CMM给出的指南更详细并且视野更宽阔，因此CMM应该是较好的选择。
从本质上说，在构筑竞争优势时应该致力于改进，而不是只为得到ISO9001证书或达到某个CMM成熟度级。
三CMM的应用
设计CMM的初衷是为了用以支持美国国防部对软件组织的能力进行评定。因此，从1987年SEI拿出CMM的雏形（“软件成熟度框架”）后，美国国防部便把它用于软件组织评估，以支持选择承包商时的决策。后来，随着CMM研制和试用工作的推进，设计者，参与者和支持者们发现了它的巨大应用潜力，于是，CMM的研制目标扩大为：
——以实践为基础，
——反映最好的实践经验，
——反映那些从事软件过程改进，软件过程评价和软件能力评估的人士的需要，
——形成书面文件，
——供大众使用。
由于接受并且通过了CMM评估给公司在合同竞争中带来的好处，使CMM很快在美国和美国以外那些希望得到美国的软件开发项目合同的公司传播开。由于CMM评估需求大大增加，1994年，在美国国防部的支持下，设立了“软件过程改进（SPI）服务部”，明码市价对外提供各种CMM相关服务。现在，美国已有多家咨询或服务机构获得授权开展此项服务业务，以应付日益增多的CMM应用需要。对CMM趋之若骛的现象，一些软件界资深管理人士认为，这是因为“今天，在软件开发中的最大问题不是技术问题，而是管理问题。”
正式发表的CMM建立了一套准则，供大众用于描述成熟软件组织的特性。这些准则可以由软件组织用于改进它们的开发和维护软件的过程，也可以由政府或商业组织用来对它们在打算与某公司签定软件项目合同时涉及的风险进行评价。简言之，CMM主要用途有两大类：
——过程改进；
——能力评估。
CMM用之于软件过程改进时，是通过按CMM给出的准则对软件过程实施评价，从而为作出改进决策和实施改进提供支持；所以，往往又把CMM在过程改进方面的应用看成是过程评价。于是，上述CMM的两种主要用途又归结为两种评定方法：
·软件过程评价；用于确定组织目前的软件过程状态，确定组织面临的突出软件过程问题，从而求得组织的软件过程改进的支持。
·软件能力评估。用于识别合格的软件工作承包商，或用于监控现行软件工作项目上用的软件过程的状态。
CMM是软件过程评价和软件能力评估的公共基础。不过，两种用法的目的不同，而且具体用法也有很大差异。软件过程评价侧重于确定本组织软件过程改进的轻重缓急；软件能力评估侧重于确定在选择软件项目承包商时可能碰到的风险，或者说是确定软件组织在软件能力方面的置信程度。后面这一点正是许多软件组织看好按CMM评定等级的原因。软件过程评价与软件能力评估在动机，目标，范围以及审核结果所有权等方面都有所不同。
按CMM进行软件过程评价或软件能力评估的几个大步骤基本相同，从选定评估组后：
——以成熟度调查问卷作为现场访问的出发点；
——用CMM作为指导现场调查研究的路线图；
——针对CMM中的关键过程方面指出反映该组织软件过程的强，弱之点；
——根据所了解到的该组织达到CMM关键过程方面目标的情况描绘出该组织的软件过程的概貌；
——向被审核者说明评估结果。
参见图5。
图5软件过程评价和软件能力评估的共同步骤
CMM仅仅是模型，为了保证可靠且一致地使用它，美国卡内基-梅隆大学软件工程研究所围绕CMM拟制了一系列支持性文件（包括相应的评价框架，方法描述和实施指南）以及各种工具。使用CMM的大致思路是：1）围绕CMM拟制出CMM评估框架（CAF），从CAF中归类出各类要求，（CAF已由SEI拟出并发表）；2）针对各类要求进行相应准备；3）按对象及其需求采用适当的方法进行评定。以CMM为基础实施评定的概念见图6。
图6以CMM为基础实施评定的概念图
（图中CAF=CMM评估框架IPI=综合过程改进SCE=软件能力评估）
如前面所述，CMM是由美国国防部斥资启动研究的。原定用途是为了确保所选的承包商确有开发重大软件项目的能力。因此，CMM涉及了软件组织软件能力的方方面面并且详细非常。实施CMM评定将牵涉大量人力，财力和时间。例如，美国的CMM评审机构为进行一次评估（或评价）开出的价码是7~10万美圆。从接受评估申请到完成评估跨时2到3个月；如果涉及过程改进，将可能需时18~24个月。为了适应中，小组织的需要，人们已开始探讨CMM的裁剪和压缩问题。不过，对于软件组织来说，能力的不断增强是根本所在，所以，美国的一些规模不大的软件公司也早已开始寻求CMM评估，而没有等待“小型CMM”出现。
CMM这个模型把软件组织的能力成熟度分成5个等级。从1987年发表CMM的最初框架到1993年发布CMM1.1版的这6年试运行，除了一些过去已经通过TQM或其他质量管理活动而达到高成熟度的大型公司外，经过评估并达到的成熟度等级大多数是第2或第3级。原因在于，CMM勾画出的这个分级递进式框架虽然描述了第4和第5级成熟度的特征，但是，究竟应该用什么样的实际表现来定位第4和第5级，尚有争论。就成熟度升级而言，美国CMM评估业界和软件业界认为，从拟订出软件过程改进大纲算起，至少要18~24个月才能真正完成改进，并且随着软件项目开发的启动往往要“冻结”各项相关的软件过程，也就是说，在软件开发过程中一般不会去更改该项目开发涉及的软件过程；此外，所处水平越高升级亦越难——CMM的设计也融入了这种思想。因此，尽管从CMM1.1版发布之日算也已过去了6年，即使在美国本土接受并通过CMM第4或第5级评估的主要还是那些在制定出CMM之前就有很强软件能力的公司（如IBM,波音，洛克希德，休斯，莫托罗拉等）里的软件组织。从1995年，即CMM1.1发布后的第3年起，CMM又进入了另一个修改的高峰期。美国政府和软件业界大力支持和积极参与下，SEI先后发表了CMM2.0版的A版，B版和C版草案；1997年，应美国国防部之请，CMM2.0(C)版草案停止推进。SEI宣布，CMM1.1版和CMM2.0版的C版草案都有效并且SEI及其授权的机构为这两种版本提供相应的服务。与此同时，名为“综合能力成熟度模型”（英文缩写为CMMI）的一个综合性模型投入研制。自CMM1.1发布起，为与之配合，在以后几年里SEI相继研制并发布了“人员能力成熟度模型”（P-CMM），“软件采办能力成熟度模型”（SA-CMM）和“系统工程能力成熟度模型”（SE-CMM）及其支持文件。经过试运行，产生了把SM-CMM, P-CMM, SA-CMM和SE-CMM合并在一起的想法和行动，于是开始了上述的CMMI研制工作。
受CMM思路的影响，国际标准化组织（ISO）开始了围绕SPICE（软件过程改进和能力确定）的大题目展开了有关软件过程评估的成套标准制定活动。SPICE包含的过程管理参考模型与SM-CMM类似，不过，SM-CMM着眼于过程能力，SPICE着眼点是组织能力，而且SPICE提出的一套通用惯例适用于任何过程的过程管理，而不仅仅是软件过程。目前，ISO将作为技术报告发布的ISO15504（软件过程评估）包括9个部分：
第1部分概念与导论
第2部分过程和过程能力的参考模型
第3部分评估
第4部分评估指南
第5部分用于评估模型和指针的指南
第6部分审核员资格审定指南
第7部分在过程改进中参考模型使用指南
第8部分在确定供方过程能力中参考模型使用指南
第9部分词汇。
CMM虽然已在美国成为事实上的标准，但它毕竟只是美国一个研究所的一份技术报告，而且还一直处于修改和变更的过程中。因此，CMM尽管引起不少国家软件业界的关注，但是，除了因合同需要而寻求CMM评估之外，大多处于分析和研究阶段；相比之下，国际标准化组织的步子更大些。如前所述，由于软件产业发展的需要，CMM所表达的思路也引起了我国一些软件组织和其他机构的兴趣，几年前即已开展了相应的探讨和研究工作。现在有的软件组织开始谈论“是寻求ISO9001认证，还是CMM评估”的现实问题，有的软件组织正在摸索本组织实施CMM的可能性，有的已经在尝试准备按CMM评估。对于这些现象，有人归结为“CMM在我国的应用问题”。笔者认为，除了那些因接受软件出口合同的要求而不得不接受CMM评估的情况之外，在考虑“CMM在我国的应用”这一问题时，特别是在行业或政府一级考虑这个问题时至少要注意以下三点：
·CMM和Capability Maturity Model已经由美国卡内基-梅隆大学软件工程研究所在美国注册了专利和商标；
·CMM产生于美国的软件产业那个环境；在那个环境里，有的公司的软件组织在CMM产生之前就有相当成熟的软件能力。这种能力不是单靠评估或认证能达得到的，应该说，这主要是得益于大量软件项目实践以及充分尊重，积累和运用实践经验的结果。此环境非彼环境。
·从比较ISO9001与CMM中可以看出，ISO9001和CMM的精神是一致的，两者都强调“说的要做到，做的要说到”，都强调“文件化（制度化）”；我国许多软件组织结合ISO9001做了大量实施准备工作或接受并通过了审核认证。在我们引入更好的软件质量保证途径时，应充分利用这些质量保证方面的努力。CMM的思路较好地反映了软件和软件开发工作的特点，围绕CMM而设计和拟制的大量支持文件和工具又为实施一致且可靠的评估提供了保证；但是，CMM至少存在一个不足之处——它只强调“关键过程方面”和“关键惯例”，因此，接受CMM评估的组织往往容易忽视那些“非关键”的过程和（或）惯例，而这些“非关键”的过程和惯例仍是必须执行的。按ISO9001的精神去理解，软件组织倒不一定忽视这些必须执行的“非关键”。此外，正在修订之中的ISO9000系列标准和ISO15504（软件过程评估）亦应关注。
当然，对于企业来说，在本组织内利用CMM或其思路进行软件过程改进尝试当属例外。其实，这种摸索尝试将有益于我国软件行业探求推进软件开发能力的最佳途径。希望这些宝贵的实践经验能在我国软件行业或政府有关部门的相应工作中发挥作用，既不要藏之高阁，亦不要置之不理。
从CMM本身的发展历程可以看出，并不是一蹴而就，而是边拟制边实践，不厌其烦地发布一版又一版修改稿，不断调整，不断完善。此外，提出CMM者并未止步于这个“标准”文本，同时还拿出了与之配套的文件和工具，并且进一步展开了拓展研究。在我们开展类似工作时，这些经验是值得借鉴的。操之过急或一哄而起是不可取的。 |
| |
|
