软件企业CMMI体系文件设计、实施及软件过程改进
许多软件企业在实施CMMI时，过多地采用“拿来主义”，实施工具要“拿来”（照搬国外的工具），体系“设计”也要“拿来”（用别人的成套模板改改来用）。这种做法不一定适合软件企业的实际，会使软件过程改进（SPI）失去意义，那么体系设计有没有方法？这里提出CMMI体系设计的三步曲，就是CMMI体系设计中应依次采取三种不同设计方法：概要设计、详细设计和度量设计。
一、CMMI体系文件架构
通过软件过程改进，得以构建一套系统的工程化管理体系（以下简称SEMP），该体系是以文件形式来体现的，这些文件分三类，其关系如图1。
图1 CMMI体系文件架构
体系设计的三种方法分别输出三类文件：总体文件、过程文件和支持文件。总体文件描述系统总体，指出系统设计依据、总体目标、方针、策略和系统概貌描述，在ISO9000中称为质量手册；过程文件描述具体的活动、谁、什么时候、做什么事，这是系统的主体部门；支持文件的种类非常多，提供具体的方法、规范、模板和工具，比如Java编码规范、配置管理工具使用指南、项目开发计划模板。
（一）概要设计
1、体系的概要设计要完成如下任务：
- 总体方案概述——简述实施方案；
- 总体策略——自底向上还是自顶向下，一步走还是分步到达；
- 远景目标——在比较长的一个期限内，比如1～2年，达到什么样的状态；
- 阶段目标——分段实施，每阶段的目标；
- 流程概述——设计哪些流程？各流程完成什么活动的简要叙述，各流程的相互关系；
- 生命周期——流程相对与项目生命周期的关系；
- 度量系统——度量需要达到的总体目标，源数据的获取、处理、报告、周期和角色；
- 文件图例——体系特别是过程文件的图例说明；
- 责任矩阵——体系的面向角色的职责分解；
- 体系文件清单——体系各层次文件的名录汇总。
总体文件不仅仅明确了系统设计的总体，而且它还可以极大方便使用者快速把握系统概貌。需要特别提到的是责任矩阵，过程文件通常是以过程为中心描述的，各角色的职责分散在不同的过程文件中，这样难以获得具体角色在体系中究竟何时何地做何事的信息。在总体文件中设置责任矩阵，此问题将迎刃而解。
在此阶段，将选择和裁减有关知识域构成体系设计的理论依据。
2、可利用的知识域：
- CMMI——能力成熟度模型，由美国卡内基梅隆大学软件工程研究所提出；
- ISO9000——国际标准，不只适用于软件企业；
- SEBOK——软件工程知识体系；
- PMBOK——项目管理知识体系，美国项目管理协会提出；
- PSP——个体软件过程；
- TSP——小组软件过程；
- P-CMMI——人力资源能力成熟度模型；
- Best Practice——介于理论和实践之间的结合层，经验性的知识，散布于各种著作和报道中。
上述知识域多数自成完整系统，要想不拘泥于上述体系，希望获得更灵活设计，需要设计者对上述体系都有深入的掌握。尤其要对CMMI、ISO9000、项目管理知识体系的相互关系进行透彻解析。
设计需要考虑的三个关键要素是：诊断识别出的组织的实际需求、组织的资源能力、管理基础和成熟度。
大多数情况下，以下要素是企业优先需要重视的：配置管理、项目计划、项目跟踪和监控、项目启动和项目收尾（见图2）。
图2 识别关键过程域
在实际情况中，存在很多复杂情况，缺乏基本软件工程的企业可能需要在实施配置管理的同时实施基本软件工程甚至软件技术，避免配置管理的“垃圾进垃圾出问题”。不少软件企业的部门一级没有足够权利，造成对SPI（软件过程改进）的推进乏力，可能需要先解决责权这个基本问题。
（二）详细设计
体系的详细设计阶段需要实现概设中裁定的一系列过程。过程定义有着非常标准的模板：
- 目的——定义本过程的目的；
- 角色——本过程中涉及的角色及其职责；
- 入口准则——什么条件会触发本过程的启动；
- 输入——文件、资源和数据；
- 过程步骤——本过程有关的处理步骤；
- 输出——文件、资源和数据；
- 出口准则——什么条件会触发本过程的结束。
根据需要还可以增加如下的条款：度量、过程监控方法、工具技术和方法、差距分析、过程改进历史和相关过程。
过程步骤的描述可以采用任何的形式，但是使用图形可以极大的方便阅读（见图3）。
图3 软件实现过程设计
一些良好验证过的方法和实践，不妨列入“工具技术方法”中，会对使用者提供不少方便。
（三）度量设计
度量设计常采用所谓GQM（Goal-Question-Measurement目标问题度量）法，Goal同样是从诊断得出的需求而来，通常需要优先采集的度量数据包括：代码缺陷、进度跟踪数据、开销跟踪数据。
以下两例显示GQM的使用方法：
样例一：有关缺陷的度量设计
- G：能否有重点的消除缺陷；
- Q：缺陷数据是否被记录，缺陷数据是否被分析；
- M：文件——评审报告；
- 代码：问题报告单。
样例二：对产品缺陷的度量设计输出（见图4）
度量设计的输出将体现在各类工作表单、过程数据库中，而度量总体的描述可以纳入总体文件中，方便阅读者全局把握。
二、CMMI实施中的常见问题
许多软件企业在实施CMMI过程中，都投入大量的人力、物力，公司领导更是亲自督阵，制定了各种奖惩制度，按理说，CMMI实施应该是很顺利的，但在实际实施过程中还会出现各种问题。下面是结合公司CMMI实施过程中的情况总结出的几个常见问题。
（一）缺乏经验，存在技术阻力
这里的技术不是软件开发技术，而是与CMMI实施有关的技术。阻力表现在两方面：一方面，由于对标准的要求不熟悉，所以编写过程文件质量较差；另一方面，由于项目经理对文件要求不理解，或对操作方法不熟练，导致执行的结果与要求相差甚远。
由于CMMI标准要求的内容较多，大家又都是初次接触，对标准的要求很难真正理解，更不用说熟练掌握了。因此，我们在编写公司的过程文件时，对于有些意见总是不能达成一致，需要反复讨论、甚至请教咨询方才能解决，文件编写速度很慢；有些文件主要是参考模板改编而成，改编人对原来的模板就不理解，改完后仍然不知所云。虽然用词晦涩、语义含糊、前后重复或矛盾，但为了赶时间，这些质量不高的过程文件略经评审就投入使用了。
由于过程文件用词晦涩、语义含糊，项目经理在使用时不能理解文件的要求是什么。比如，在项目计划模板中，前后出现了两处工作产品介绍，项目经理就不能理解为什么，而文件编写人员也忘了自己原来的意图。后来，经咨询方解释才知道，原来前面应该是最终的软件产品，后面才是软件工作产品。
如何把握实施力度，既保证过程质量，又不会对进度造成重大影响？由于经验不足，过程改进人员和项目经理对此总是不能取得共识。我们有一个项目计划，前后写了4版，差不多用了20天才通过评审。当然，这一方面是因为项目经理写作能力不强，文件确实存在较多问题；另一方面，也是因为SQA（软件质量保证）人员经验不足，要求太严，列出问题太多，导致项目经理无所适从。后来，还是咨询方及时纠正了这个问题，他们说：如果计划没有大的问题，能够用于指导下一阶段的工作就可以先评审通过，这样项目组工作才有据可依； 当然，问题还是要改，只要在以后的版本中予以更正即可。
（二）进度与质量难以兼顾
软件开发过程中，最常见的问题之一就是：项目进度要求与软件质量保证之间的矛盾。
在没有开发规范以前，软件开发随意性较大，通常为了赶进度而牺牲管理工作的时间。项目经理往往是项目开发主要人员，管理工作量很小。现在就不同了。项目经理不仅要关注软件开发，还要加强过程管理，并且有了SQA工程师进行监督。这时，项目经理要拿出相当多的时间去做管理。由于经验不足，上述工作花费的时间远远超过了计划时间。
由于实施CMMI占用较多的时间，高级经理、项目经理就难免会有看法，认为实施CMMI严重影响了项目进展，而短期内又难以看出质量保证的效果。而一旦他们认为质量保证对项目进度产生了负面影响，再要他们按照要求开展工作就有点困难了。
从理论上讲，按照好的过程来管理开发工作，不仅可以提高开发质量，也可以加快开发进度。但实际上，由于经验不足，在实施初期，不仅看不到质量改善的效果，反而会降低开发速度，难怪有些人不愿意去做。这就需要公司决策层进行长远考虑，采取激励措施、提供资源保证，确保体系执行，进行持续改善。
（三）目标和需求变化多，难控制
这也是软件开发中的一个常见问题。
有一个软件产品研发项目，原来定义的客户目标群是中小银行，研发立项也得到了公司有关部门的批准，项目做到了详细设计阶段。但后来，销售部门提出目前中小银行对该产品的市场需求不大，应该调整客户目标为某大银行。为了适应客户目标和提交时间的改变，项目经理不得不改变软件系统的实现方法，改变体系结构，重新进行需求分析、调整概要设计。虽然这些因素本身与CMMI无关，但是当时项目经理刚刚完成项目估计、项目计划以及文件评审工作，而现在，一切又要重新开始了。
有时，虽然项目总体目标没有大的变化，但是客户需求频频变更。按照要求，对变更请求需要评审，还要修改从需求开始的所有文件以保持一致性。这样的事情如果频频发生，项目经理的很多工作成果都会被白白浪费，项目经理容易产生挫折感，严重影响实施CMMI的积极性。
在发生这种问题时，高级经理有责任做好项目经理的思想工作，告诉项目经理这不是他的错，他做得很好，并鼓励他继续做下去。这样，在一定程度上，能激励项目经理的信心和热情。
（四）不同角色面临不同问题
对于准备实施CMMI的公司来讲，CMMI还是个新事物，绝大多数人对它不是很了解，因此在执行中问题很多。而由于资源有限，很多问题不能得到及时、有效的解决，影响了实施效果；在看不到明显效果的情况下，要求项目经理严格执行，又有很大的难度。这可能就是我们目前碰到的最大问题。
- 从项目经理来讲，他们面临着两方面的压力：高级经理对他们进度的要求，远远高于CMMI实施方面的要求；SQA人员要求他们按照CMMI标准实施，但是在具体操作方法上又没有很好的经验可以提供，需要摸索着执行，很多时候都在做无用功。
- 对于SQA人员来讲，一方面他们需要去做高级经理的工作，取得他们的理解和支持；另一方面，他们也要不断深入了解CMMI的实施要点和操作方法，但是由于没有CMMI专家的支持，经常会走弯路，导致项目经理颇有怨言。
- 从高级项目经理的角度来讲，公司给他们的资源也是有限的，客户要求的期限又是固定的，当进度与质量保证发生冲突时，如何去平衡？也确实是一个比较头疼的问题。
从上面可以看出，CMMI实施过程中，不同的角色面临着不同的问题，需要在实践中不断摸索，协商解决，寻找适当的方法去解决问题或减少问题。
从目前情况看，CMMI实施困难很多，但是，从发展趋势来看，CMMI实施的前途是光明的。越来越多的企业认识到实施CMMI的必要性，加大了实施投入来保证实施力度。而且，随着CMMI实施人员的增多，大家不断总结、交流经验，问题也越来越容易解决。
三、怎样进行软件过程改进
有人认为，如果一个软件机构在五个开发人员以下，以及开发周期短于六个月，进行基于SW-CMMI的软件过程改进是不划算的。写这篇文章的一个目的，就是帮助人力财力不那么雄厚的中小型企业进行软件过程改进，让他们能少花钱，少花时间，并且显著得益。无论人数多少，开发周期多短，改进必得益！
只要一个软件企业在开发产品，它就一定有一个软件过程（可能只是没有写下来）。如果这个过程不能很好地适应开发工作的要求，就需要进行软件过程改进。软件过程改进并不是一件很困难的事。并没有写一个操作系统，或设计一个微处理器那样的纯技术上的难度。但它面对的是一种含有大量管理成分的工程技术。这也就是为什么不容易把它做好的原因。
1、什么是“改进”？改进所涉及的几个步骤是：
- 把要想达到的状态与目前的状态作比较，找出所有差距；
- 决定要改变哪一些（注意，不一定是全部）差距，要改变到什么程度（可分阶段改）；
- 制定具体的行动计划；
- 执行计划，同时在执行过程中对行动计划按情况进行调整（以最佳效果为目标）；
- 总结这一轮改进的经验，开始下一轮改进。
下面讨论，在进行软件过程改进时，上述五个步骤中的关键内容。
- “要想达到的状态”（目标状态）：具体是指软件过程的状态。如果一个机构决定采用SW-CMMI来作参考篮本的话，就可以基于它的各个关键过程域（KPA ），制定出符合自己机构及产品特点的目标状态。（在这里，笔者强调“基于”及“符合自己特点”，意思就是不能照抄。）
- “目前的状态”：要找出什么是目前的状态，就要进行对目前软件过程的评估。评估的方法很多，最简单的就是一组熟悉本机构的日常开发运作的人员在一起讨论，把它列出来。在这里，可借助SW-CMMI的评估问卷办法。实质上，评估问卷中的问题，就是把各关键过程域的各细则内容，加上“有没有做到”、“有没有建立”、“有没有执行”等语句而构成的，并没有什么神秘之处。
- “决定要改变哪一些差距”：要从多个方面进行考虑决定。例如：“最薄弱的环节”、“最需要改进的环节”，“最易做到而又有显著收效的改进”，“有人力，财力和时间，即有条件进行”。各机构要按自己的情况作决定。
- “要改变到什么程度”：由于条件的限制，我们不可能做一切希望要做的事，或者不可能百分之百地一步实现目标。许多时候，欲速则不达，反而误了事。目标与能力，要有个平衡。
- “具体的行动计划”：“具体的”就是：
- 要有明确的，可以检验的目标；
- 要定出检验成功与否的标准；
- 要有具体的实施行动办法；
- 要指定具体执行计划的人，每人的具体责任与任务；
- 要指明计划的主要领导或协调者，以负责解决一切在执行中出现的问题；
- 要列出所采用的新技术与新工具，怎样获得它们；
- 要定出对新技术和新工具进行对本机构适用性改造的目标；
- 要有对新技术和新工具的使用进行培训的计划；
- 要列出每一改进对过程的其他部分的关系、影响、和协调的办法；
- 要建立与项目相关联的时间表；
- 要指出相关的人力、资金与时间的来源；
- 要定出在整个执行过程中，必须在什么时候提供什么数据；
- 要有对执行情况进行监察考核的具体办法及计划；
- 要准备很可能发生的，在执行过程中对行动计划按情况进行调整的行动。
- 要有对行动计划执行中可能出现的意外情况有所准备，保证项目仍然能够顺利进行。
- 必须要有高层领导、管理人员作为推动整个行动计划的动力。
- “在执行过程中对行动计划按情况进行调整”：一旦发现需要对行动计划进行调整，以期达到最佳的效果，而实际情况也允许在中途进行调整的话，可以进行经过计划的、严加控制的调整。所有的改变必须预先取得所有有关人员的同意。
- “总结这一轮改进的经验”：过程改进是一个永不停止的工作。总结经验使我们能越做越好，越做越有信心。光有未经实践的知识，还不能有信心。信心是经过运用知识解决了问题之后建立起来的。
下面，就一些问题提出笔者的看法：
2、是否一定需要外来的咨询？
企业进行软件过程改进，是否一定需要外来的咨询呢？
笔者认为，好的咨询确实能带来帮助，如果财力上付得起，同时又了解对方是有商业道德和有能力的顾问，则不妨进行一些接触，然后逐步判断他的观点和建议是否符合你们机构的需要，千万不要被对方说服去投入一个你们的机构现在不需要的，或在人力、财力、时间上条件不具备的努力。你们要进一步判断，究竟在哪一些方面，在多大的程度上需要多少外来的帮助，因为过程改进的一个目的是培养本机构的人才，过份地依赖外来咨询，会削弱这个努力，但也要综合考虑这种自主探索模式是否适合本企业，依托自身努力能否到达预设目标，自身投入和产出比等诸多因素。俗语说得好“三个臭皮匠，顶个诸葛亮”。在机构内部组织一个小组，多讨论，通过各种渠道多学习别人的经验，破除教条迷信，灵活运用自己的专业判断力，就有能力领导整个过程改进，并且在实践中成长起来。
总之，自主实施有自主实施的好处，依托外协有外协的优势，具体如何选择还是靠企业依据自身状况来决定。
注：关于是否有必要请外协的问题我在《中小企业CMMI认证实施常见管理和技术问题分析总结》一文中也有过类似的表述，在此不做过多的赘述，感兴趣的朋友可以翻阅一下之前的旧帖。
3、知道了要做什么，如何知道怎样做？
SW-CMMI只提出了要做些什么（关键过程域中的关键实践），但并没有介绍要怎样做。解决这个问题的方法很多，比如到软件工程的书中去找、向有经验的人请教、或者就自己讨论出一个可行的办法，从来都不要小看自己经过认真思考而想出来的办法。凡是从书中或别人处学得的办法，都要经过适当的改变，以适应自己的机构的条件及目前项目的特点。世界上没有适合一切人穿的鞋。
4、怎样知道过程改进带来了什么效果呢？
一般来说，你知道了目前的缺点是什么，就应当知道怎样去判断过程改进的效果。当然，效果可以分别从质和量的角度去量度。对于不同的改进，效果的检验方法就不同，比如对于项目的计划中的软件规模大小的估算，就可以从最终产品的大小中得知估算的准确度；比如进行早期缺陷预防，就可以看看在开发的各个阶段所发现的缺陷数目的分布（记得在行动计划中要有记录统计的一项）；又比如进行软件配置的版本控制改进，就可以看看是否对不同的版本有了完全及方便的控制。因此，可以看出，这些都是按常理进行的事。
5、找差距时，应对照哪些关键过程域？
SW-CMMI的能力成熟度分等级，是人为的。它是基于SEI对成熟度的由底到高的理解来划分的。有人就觉得划分得不大合理，然而，使用者是活着的人，可以按自己需要作改变。
笔者认为，对于初开始软件过程改进的机构，不妨对照全部或部分的SW-CMMI第二级的各个关键过程域，外加第三级的“交换审核”，及第五级的“缺陷预防”。（有点象从菜单上点菜） 为什么要把“交换审核”及“缺陷预防”从高的成熟度等级中“往下拉”呢？原因是，按笔者的实际经验，“交换审核”是一个简单易行而且非常有效的找出缺陷的方法，也是一种促进开发人员注重预防缺陷的好方法。至于“缺陷预防”，这是整个软件过程的核心与灵魂，从一开始就必须全力以赴。
6、在每个对照的关键过程域中，原原本本地对照每一项关键实践吗？
绝对不是。这里就牵涉到对SW-CMMI进行裁剪及解释的间题。“裁剪”是指对范围及程度的改变；“解释”是指把实际软件项目中的实践工作，解释理解为（等同为）某个关键实践。基本上，不要去裁剪那些属于目标（Goals）的关键实践。裁剪及解释，是中小企业能否成功地应用SW-CMMI的一个关键。在不影响效果的前提下，剪裁到越简单越好。要慢慢地把自己培养成裁剪高手。
7、把机构目前的一切推倒，按SW-CMMI重建，是否会更好？
千万不要这样做。基于目前的过程进行改进，证明是最有成效的方法。
8、是否起码要满足SW-CMMI第二级的所有关键过程域呢？
笔者认为不必。任何方面，任何程度的改进都是有益的。要按照你机构的担负能力及要求来决定进行软件过程改进的广度与深度。
9、软件过程改进中，应注意些什么呢？
应该注意的事情很多，但笔者认为最重要的一点是要注重执行、做实事，千万不要定出了行动计划之后就丢进抽屉中，束之高阁。另外一个要注意的问题是，要有对行动计划执行中可能出现的意外情况有所准备，保证项目仍然能够顺利进行。
