CMM2标准

　　CMM 2（可重复级）就是建立了基本的项目级管理过程，可对项目的成本、进度进行跟踪和控制，生产的过程、标准、工作产品以及服务都是被严格定义和文档化的。基于以往管理类似的项目的经验，计划和管理新项目，并可依据一定的标准重复利用类似的软件产品。CMM 2的核心就是重复利用。

　　CMM2由6个关键过程域(KPA)组成：需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)（本文略）、软件质量保证(SQA)、软件配置管理(SCM)。

　　需求管理(Requirement Management)

　　需求管理的目的是为了在客户和处理客户需求的软件项目之间建立共识。这是软件项目规划(SPP)和管理(SPTO)的基础，需求变更依赖于配置管理(SCM)的变更控制流程。在项目实施过程中，最突出的现象就是项目组成员没有完全理解需求，软件需求不稳定，客户经常变更需求，无法有效控制需求变更，需求变更往往造成项目延期和费用超支。

　　CMM2要求的需求管理的基本流程可如<图一>所示。该流程描述了软件工程组开始获取原始需求，汇总为系统需求，分配系统需求，复审软件需求，软件需求必须文档化形成需求文档，此文档必须经过相关组和个人的评审，通过评审之后才纳入配置管理，为需求文档建立基线。软件项目计划、活动及软件工作产品，应和软件需求的变化保持一致。

　　根据流程，可以结合实际开发情况确定项目的需求管理步骤：

　　a. 获取需求和确认需求以Use case（用例）为单位，以Rational Requisite Pro作为需求管理工具，使用Rational Rose进行维护Use case和Use case Model。

　　获取需求工件是：用例模型(Use case Model)、非功能性的“补充规约”、用例规约(Use case Specification)、词汇表(Glossary)

　　b. 通过访谈，从客户处获取原始需求，形成需求文档。

　　c. 分析软件需求形成Use case描述文档，与客户共同确认需求，向客户展示Use case文档，获得客户认可。

　　d. 建立基线的需求必须通过相关组的审查，包括：系统分析组、设计组、编码组、测试组、质量保证组、配置管理组、文档管理中心及个人。通过审查，项目组成员发现需求是否可行、是否完善、是否清晰、是否可进行测试。

　　e. 通过审查后，将需求文档纳入配置管理，为需求创建基线。

　　f. 通过工具管理，对需求进行跟踪，尽快找出需求变更受影响的需求及工件，并了解需求的实现情况。

　　g. 客户确认后如需变更，项目小组成员向其说明变更的影响，并有可能增加费用及时间，尽量控制客户的需求。需求变更的流程按配置管理的变更流程执行。

　　h. 一旦需求发生变更，项目计划、活动、工序随之变更，并重新提交相关组和个人复审。

　　i. 实际项目需求管理中应用的文档有：

　　项目需求管理流程定义、项目需求复审流程定义、项目需求及状态跟踪流程定义、需求获取表格、需求状态报告、需求复审报告、需求变更报告、需求跟踪报告

　　软件项目计划(Software Project Plan)

　　软件项目计划的目的在于建立合理的计划，执行软件工程和管理软件项目。软件项目计划管理在软件开发过程中处于十分重要的地位，它体现了对客户需求的理解，是开展项目活动的基础，是软件项目跟踪与监控（SPTO）的基础。

　　CMM2软件项目计划根据纳入配置管理后的软件需求进行项目估算，并依据文档化的流程，形成项目计划文档。项目计划文档经复审后纳入配置管理，由项目开发人员遵循，并据此跟踪检查计划的执行。项目计划文档在复审过程中，如果项目计划对风险估算不足或存在其它问题，就需要对项目计划文档重新修正，以获得项目组和高层管理者的支持。软件项目计划（SPP）也称为软件开发计划（SDP：Software Development Plan），软件开发计划一般是指管理软件项目的全面计划。

　　在项目实施过程中，比较常见的情况一种是制定的软件项目计划内容简单，无法具体到每一个迭代或每周，可变性太大；或者制定了详细的软件项目计划，但实际执行根本就不按照计划实施。

　　软件项目计划的实际应用模式如下：

　　a) 项目采用 Microsoft Word 拟定计划文档，以 Microsoft Project 拟定计划的进度表。

　　b) 项目经理根据项目软件需求进行估算，确定进行项目选择的生命周期、项目规模、所需的人员、时间、进度、资源、风险等内容。将估算的结果形成估算过程文档，并拟定软件开发计划。

　　c) 软件开发计划内容包含：软件项目计划、迭代计划、进度时间表、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划。

　　d) 估算过程文档和软件项目计划文档必须通过相关组的审查，以获得相关组及个人的支持，包括：系统分析组、设计组、编码组、测试组、质量保证组、配置管理组、文档管理中心及个人。通过审查，发现并修正项目估算和项目计划的偏差。只有获得了支持，软件项目组在开发过程中才能尽量避免或消除风险。

　　e) 在高层管理者复审通过后，项目经理指定人员或参与拟定软件开发计划其它部分，并由相关组和个人复审。

　　f) 配置管理人员将软件开发计划文档纳入配置管理。

　　g) 实际项目中应用的文档有：

　　制定项目计划流程定义、项目估算流程定义、项目评估表、资源评估表、软件开发计划模板（包括：软件项目计划、迭代计划、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划）、进度时间表、制订软件开发计划的指南。

　　软件项目跟踪与监控(Software Project Tracking and Oversight)

　　软件项目跟踪和监督的目的是建立对实际进展的适当的可视性，为了及时发现开发过程与项目计划之间的误差，使项目经理或高层管理者能够及时了解软件开发过程的状态，能在软件项目明显偏离软件计划时采取有效措施。

　　CMM2软件项目跟踪与监控的基本流程可如<图二>所示。该流程描述了软件项目组根据文档化的估计、承诺、计划跟踪和审查软件成果，并基于实际调整计划。文档化的软件项目计划被用作跟踪软件活动、了解状态和修正计划的基础。项目经理根据项目开发计划跟踪项目的执行情况，定期形成项目进度报告，并与项目开发计划进行对比，发现问题，根据实际情况对软件开发计划进行修正。掌握了这个核心，实施软件项目跟踪与监控活动就很容易了。

　　根据流程，在进行实际项目计划跟踪与监控时，可以采取如下方式：

　　a) 项目组使用 Rational 的工具进行管理，将 Microsoft Project 拟定的项目计划进度表导入 ClearQuest，主要以 ClearCase 和 ClearQuest 作为跟踪监控工具。

　　b) 项目经理每周根据项目的实际执行情况，拟定项目的进度报告。然后召集项目小组成员，对进度报告进行确认和修正。

　　c) 项目经理对照计划与实际执行情况，发现差距并将其纪录成问题报告，其中包括：费用、进度、风险、人员、资源状况等。

　　d) 由高层管理者复审进度报告及问题报告，并敦促项目经理修正其计划及解决项目存在的问题和风险。

　　e) 实际项目中应用的文档有：

　　项目跟踪与监控流程定义、项目进度报告、项目进度指标收集指南。

CMM3简谈

CMM3是项目管理软件。由美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(Capability Maturity Model 软件能力成熟度模型)认证评估，在过去的十几年中，对全球的软件产业产生了非常深远的影响。CMM共有五个等级，分别标志着软件企业能力成熟度的五个层次。从低到高，软件开发生产计划精度逐级升高，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI统计，通过评估的软件公司对项目的估计与控制能力约提升40%到50%；生产率提高10%到20%，软件产品出错率下降超过1/3。

CMM3是能力成熟度模型（Capability Maturity Model）的缩写，是由CMU/SEI

  

CMM3

（美国卡内基梅隆大学软件工程研究所）1987年开发成功的，现在普遍使用的是V1.1版本。CMM模型从1-5分为不同的等级，按照软件过程能力将一个组织定位于不同的成熟度等级。其一个重要思想是帮助一个组织通过基于模型的软件过程改进而达到使其软件过程向更高的能力成熟度等级迈进的目标。在这个过程中一个组织必须建立自己的软件过程，并依据CMM模型要求对此过程进行评估，针对评估结果来进一步改进自己的软件过程，再次评估自己的软件过程以期达到更高的成熟度等级或防止自己的过程能力退化。如此循环最终使一个组织的软件过程能力趋于高度的成熟。这样客户在选择其项目的承包商时可以依据一个组织达到CMM的某个等级来判断该组织的软件过程能力以及其是否有能力达到自己对于此项目的时间进度，资金控制，质量标准等方面对承包商的要求，从而决定是否会放心的将自己的项目交给某一个组织去做。也就是说，通过CMM认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。

我国软件行业的现状而言，应该说是非常需要CMM3的。目前我国软件业CMM评估达到三级的只有2-3家，达到二级的有5家。而在软件出口居于世界首位的印度，达CMM四级、五级的软件企业已占世界总量的50%~60%。同时，据IDC统计在全球软件市场中，美国占据了2/3。美国和印度软件业为何如此发达？很重要的一个原因就是：无论规模大小，绝大多数企业都按照规范化的方法管理软件研发过程，始终把客户放在首位，把通过某种标准的评估认证放在很重要的位置上。

我国软件企业一个普遍存在的现象是一个技术骨干一走，技术往往就被带走了（尤其是对小企业而言，影响更为明显）。因此研发过程的规范化、文档化管理成了首要问题。

实施了CMM3是否能够规避此类风险呢？回答是肯定的。CMM3的实施将保证一个组织的项目软件研发真正能够做到铁打的营盘流水的兵。同时CMM3的实施还有其他妙处，印度的一家软件企业的老总说，在实施CMM3后其软件的可靠性提高了20%，成本降低了20%。

由此看来，实施CMM模型（尤其是CMM3级以上的企业）的一般意义为:

　　1、软件研发过程文档化，软件工作产品保证了一致性和可追溯性；

　　2、企业内部过程改进制度化，产品开发周期控制能力，质量、成本控制能力，风险控制能力，生产效率等明显提高；

　　3、市场竞争透明化、简单化，规范了市场竞争；

4、企业国际化能力得到质的提升。

结语：

任何过程的实施都离不开人的因素，CMM3的实施、认证也一样。CMM3的引入恰如一阵春风，它对于团队协作精神的强调隐含在模型的字里行间好的企业文化将使CMM3实施事半功倍，而希望塑造团队协作企业文化的企业，CMM3的实施将会起到强有力的推动作用。

CMM3模型对于做事能力的重视不亚于具体的工程实施，无论项目经理还是项目成员各角色，完成其角色工作的进入准则之一就是ability。在实施基于CMM模型改进过程中，将提供给员工定制的众多的培训课程，有的是针对性很强的专业课，有的是需要了解的基础课，在此过程中员工的软件工程素质得到了极大的提升，软件工程意识的提升作用于其技术上的积累，并将产生更高质的软件精品，这样的企业研发出的产品将给整个团队带来成就感，而个人素质、精神面貌与自信心也将不断改善。

CMM4实践——需求管理

1.1需求变更管理
  对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是
不可避免的。这主要有以下几种原因：
1）软件所应用的外部环境发生变化；
2）随着用户对软件的熟悉和应用，又提出新的需求；
3）用户在开始时不能很全面的知道所需软件的功能。
   因此，为了因应需求变化，必须做好准备和计划，当需求发生变化时，使项目仍然能够在控制之下。一个有效的需求变更管理过程一般包括以下几个步骤：
1）需求变更请求；
2）需求变更的影响分析；
3）项目计划调整；
4）需求变更确认。
  实际的变更需求的执行跟踪常常由后面将要讲述的配置管理过程来实现。
  在项目计划重新调整后，变更的需求从需求分析和规格化开始，重复到变更发生时已经经过的过程，直到所有需求的实现可以同步进行。虽然一个有效的需求变更管理过程能够
有效的控制和实施某个需求变更，但是，多个变更过程作用于一个项目，一般都会产生不容忽视的累积效应。比方说，在100个产品中的每个产品上发现了一个问题，我们可以说这些产品有100个问题，但是如果在一个产品上发现了100个问题，却往往意味着该产品可能
隐含着更大的问题。对一个软件项目来说，也是一样的道理，过多的需求变更常常导致软件结构凌乱、逻辑复杂。
1.2需求跟踪管理
  对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被
实现。因此，一个比较好的方法就是建立一种跟踪机制来确认所有需求在每个阶段都被实
现，这就是所谓的“需求跟踪”。进行需求跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。这个映射常常可以用需求跟踪矩阵来实现。
  我们把在项目启动前分配给该项目的需求称为“分配需求”（这些需求通常就是前面所说的用户的原始需求），把经过需求分析并规格化之后的需求称为“软件需求规格”，于是就可以建立一个分配需求到软件需求规格之间的映射，该映射反映了分配需求都被分解到了哪些软件需求规格之中。具体可以采用（分配需求ID，软件需求规格ID）的形式。由于通常是一个分配需求被分解成多个软件需求规格，因此，实际中我们常常会得到形如下
面的映射：
分配需求ID                 软件需求规格ID
   r1                            srs1
   r1                            srs2
   r2                            srs3
   …                            …
也就是说，一个分配需求被映射到多个软件需求规格上。当然，根据需要也有多个分配需求被映射到一个软件需求规格上的情况，但是，考虑到软件需求规格的简明性原则，应该尽量避免这种情况。
  当软件项目开始设计后，重点都全部集中在了软件需求规格上，接下来的工作就是来实现所有的软件需求规格。我们以V模型（更加强调测试的瀑布模型）为例来说明在设计、编码和测试过程中对软件需求规格的跟踪。典型的V模型结构包括这样几个阶段：需求规格阶段，概要设计阶段，详细设计阶段，编码阶段，单元测试阶段，集成测试阶段，和系统测试阶段。对应于需求规格要进行的测试活动是系统测试，系统测试的工作是来验证需求规格中所有的功能和性能都按照特征要求被正确实现，于是可以建立一个软件需求规格到系统测试用例的映射来反映哪些需求规格在那些系统测试用例里面测试。概要设计通常是根据功能“独立分解”和“类似集中”的原则把大的系统进行模块分解，于是就可以建立一
个软件需求规格到各模块的映射来反映那些需求规格在那些模块里实现。对应于概要设计要进行的测试活动是集成测试，集成测试的工作是要验证数据能够在各模块间能够正常的流动，于是也可以建立软件需求规格到集成测试用例的映射来反映哪些需规格在那些集。

CMM5级认证能否带来软件开发能力上的飞跃

CMM5级认证之后在国内软件企业赶超美印思潮的引导下，CMM的旗帜效应越来越明显。近日，东软大连国际软件园通过CMM5级认证的消息成为软件行业中的一个热点。在CMM最高级别认证的光环的笼罩下，东软能一下子获得飞跃吗？东软总裁刘积仁表示，只有当CMM成为东软员工的一种行为习惯，成为东软内部沟通一种语言，成为东软的一种文化时，我们才能真正理解CMM的精神，才能真正贯彻好CMM的过程。 　　

首先，我们自然不能否认东软在软件开发能力上的提高，东软通过

实施CMM评估的确能提高来自于国外客户的认知度，增强在全球市场抢夺订单的核心竞争力，融进全球软件市场大的游戏规则中去。但是否所有企业，都能够借通过CMM5级认证，来实现软件开发能力上质的飞跃，还值得商榷。 　　

CMM不能变成噱头.没有人能蔑视CMM认证于中国软件产业的重要性,更没有人对CMM发出一丝的质疑声音，在国内软件行业出口的浪潮波涛汹涌的关键时刻，CMM无疑更是国内软件企业争相拥抱的香饽饽，然而，通过CMM认证究竟意味着什么？CMM能主导中国软件产业的发展轨迹？CMM能转变中国特有的程序员的思维？ 　　

CMM认证让中国软件企业的神经都紧张起来，而通过CMM相关级别认证的企业几乎要将其挂在脖项上进行标榜与炫耀，没有通过的企业则千方百计的为获取通行证而煞费苦心，表现出一副誓在必得模样，象虔诚的教徒面对上帝一样忠诚。 　　对于国内的软件企业来说，CMM的概念盛行也只是这两年中完成的，作为衡量软件企业成熟度的模型，CMM在国际上是通行的标准，是对软件开发流程控制的最高境界，没有人对其怀疑过甚至发出一点抱怨之气，然而，仔细想想，在中国这片有特色发展模式的软件行业空间内，CMM又将扮演着什么样的角色？ 　　

近日，记者接触到了各个层次的软件企业的程序员，发现了一个问题，在唯CMM马首是瞻的时代，国内的程序员们通常都带有抵触情绪，这不光是由于CMM是舶来品，也不简单的是因为水土不服的缘故，CMM在国内软件行业表面追捧的现象下，却隐藏着更为值得深思的问题。 　　

当CMM成为一种信仰,信仰的魔力是不能低估的，当一个人囿于信仰的观念下时，也等同于被神奇的力量所支配，从 国内软件企业对CMM的态度来看，CMM的诱惑力绝对可以同信仰相媲美，不同的是对待CMM，国内软件企业往往是整体战略上重视，具体到开发过程中却忽视它，甚者，有人认为国内软件企业如果按照CMM的规定方式进行软件开发与流程控制的话，反应到最终产品上时将是一种倒退。对于该观点，一些企业的软件开发人员更心有所得，即使我们都在努力依照CMM的程序操作和安排开发进度，但最终的结果往往还不如依托既有的模式开发效率高，由于本土的程序员从教育与学习的开始就有特有的理念遵从，而编程习惯与方式的改变是很难的。 　　

刻意的模仿则欲速而不达，甚至许多程序因为与CMM标准不统一而推倒重来，显然这样做既耽误了进程，又影响了产品的技术创新性，特别是固定的模版式套用方式来试图接近CMM的规则的做法，让软件设计人员与软件工程师进退两难，把握CMM规则的精髓毕竟不是一蹴而就的，需要的是整体团队的协调划一，哪怕理解上的稍微偏差都会影响整体效果的把握。 　　

因此，在国内CMM呼声渐强的情况下，程序员的难以转变角色很容易造成企业陷入为CMM而CMM的尴尬境地，对于所谓的CMM，国内一家软件企业的老总语气很是坚定，CMM就如同花瓶一样，通过CMM认证是为企业穿上漂亮的外衣而已，对于象国内企业规模偏小的企业来说，CMM很容易成为思维上的枷锁，导致产品开发创新无力，扼杀创新观念的细胞。而恰恰在国内规模小的企业占的比例要大的多。从这方面看，小企业是不适合以CMM标准来改善企业开发流程的。 　　

那么大的企业是否适合应用CMM开发模式呢，答案是肯定的，因为在大的企业中同一个项目往往需要上百人协调起来，俗话说没有规矩不成方圆，而CMM正好给我提供了可以遵循的框架。但企业适合应用CMM并不代表着上马CMM就能发挥出CMM应有的作用，这需要一个时间很长的磨合期，而这段时间对于企业来说是最为痛苦的。 　　

在一些软件企业中中，通过CMM认证往往在某阶段被指定为硬性的指标去执行，特别是最后的冲刺阶段，在心理上就带有敷衍了事、凑凑合合的态度，当CMM的评测专家莅临时，就拿出一套应急用的软件开发流程体系等框架性性的东西掩人耳目、蒙混过关，但在实际的开发过程中并没有依照CMM规定的模式去遵循。而这种情况在国内软件企业中已经是心照不宣的秘密。 　　正视CMM认证 　　CMM认证体系作为与国际接轨的通行证，成为众多国内软件厂商生存发展的关键一环，通过CMM认证也演变成企业的终极理想，但纵观国内软件企业的研发环境和软件开发管理水平，的确不尽如人意，而盲目追求认证的一窝蜂势头却令人堪忧！ 　　

CMM认证简称能力成熟度模型，是鉴定企业在开发流程化和质量管理上的国际通行标准，全球软件生产标准大都以此为基点，并都努力争取成为CMM认证队伍中的一分子，当然作为和国际软件业一脉相承的国内软件行业也概莫能外，但情绪化的激动不可避免会产生误解和感性上的崇拜，这种有悖于CMM认证理念的意念势必会伤害国内软件企业。 　　

不要为了通过CMM认证而拼，我们高攀其的最终目的是获得由此带来的管理效益，和平衡国内在开发周期上的有效控制，一叶障目，不见泰山，国内软件企业恰恰陷入了这样的不能自拔的怪圈，想象着如果自己能通过认证，就能飞黄腾达，就能摇身一变、超凡脱俗，就能凌驾于其他软件企业之上，心理上的阴影效应挥之不去的话，留下的余痛不仅伤害到肌肤，连业已建立起来的规范的质量控制体系也会无功而反。 　　

认识CMM认证需要擦亮眼睛，切勿在这一关键点上患上近视的弊病。其实CMM认证只是相对成熟的通用标准，对于国内一些还没有势力和规模通过CMM认证的企业来说，既不能妄自菲薄，也不能坐以待毙，根据自己对软件开发流程管理的认识，建立起一套符合本企业的完善的控制体系，这才是当务之急。