当前，软件研制能力成熟度认证工作在国内军工企业中如火如荼地开展，已有多家单位通过了GJB 5000A成熟度二级认证或三级认证，也有部分单位开始向四级成熟度等级努力。

软件研制能力成熟度认证已在国内开展多年，有不少软件企业通过了CMMI四级、五级认证。国内 GJB 5000A-2008是等同采用CMMI-V1.2软件部分形成的国家军用标准，它是一个能力框架，给出了不同成熟度等级的能力要求（特征），但并未给出达到这些能力要求的途径或指南，因此，每个实施单位要根据本单位的实际情况制定内部标准，以指导本组织的软件过程，使组织的能力成熟度达到目标等级。不同的单位有不同的做法，但通过调查发现，在二级成熟度改进过程中，有一些共性的或者容易被忽视的方面，容易在实施过程中给企业改进活动的组织实施带来困惑，甚至产生问题。

本文结合了GJB 5000A二级认证实践，对认证过程中容易出现的几个问题进行描述，并给出了初步解决方法。

1 有测量，无测量目标

测量与分析，是软件项目实施、组织过程改进的基础。通过测量与分析活动，可以监控项目的进度、成本、质量等，使项目进展“可视化”，促进项目成功。通过测量与分析，可以改进软件开发过程，节约开发成本，开发出高质量的软件产品。

在推进软件成熟度认证的过程中，发现许多单位或项目是为了测量而测量，罗列出一堆测量项，却不知道为什么要测量这些数据、如何利用测量得到的数据。说得严重点，是为了评价。不同的成熟度等级，有不同的管理特征和需要，相应的测量需求（测量目标）就不一样，测量项要紧扣测量的目标。GJB 5000A关于测量与分析的目的描述是：测量与分析的目的是开发和保持测量能力，以支持管理信息的需要[1]。也就是说，应该选择“适用于管理信息需要的”测量项。所谓“适用”，是指能够支撑测量目标的实现，并不是越多越好，超出需要的测量会增加人力成本，甚至会因为对测量数据的理解偏差而导致混乱。

项目管理的三要素是质量、进度、成本[2]。在成熟度二级，选择能监控这三个要素的测量项就可以达到项目的基本要求了。关于项目质量、过程质量的测量项一般有：缺陷数、缺陷分类比率、缺陷密度、不符合项数量、不符合项分类比率等；关于项目进度的测量项一般有：项目阶段进度偏差、项目进度偏差以及与进度偏差项相关联的工作量偏差等；关于成本的测量项有：项目工作量、工作量偏差等。

为了支持组织的过程改进，向更高的成熟度等级迈进，一般还应定义一些组织级测量项，以支撑组织过程改进计划的制定，并作为组织内软件项目策划的基本参数。基本的组织级测量项一般包括：组织的平均生产率、千行代码平均缺陷率、需求变更比率等。

2 对配置管理认识不到位，规程繁琐

配置管理的基本目的是，在合适的时候，管住需要控制的内容。配置管理不是管得越多越好、越细越好，重点是在需要受控的节点上管住应该受控的配置项。

配置管理的关键点是配置项识别、基线的建立与变更、产品库的建立。配置项的识别要做到不多也不少。而现在的情况是经常遗漏配置项，比如外部要求、协议、驱动程序、开发环境等。基线是后续开发的基础，产品库则是用于发布和交付的最终开发物，一定要从严控制。其它配置项，则要根据其重要程度，确定控制级别。一切从严的管理办法既难以操作，也毫无必要。

配置管理是与工程开发紧密结合的过程活动，是在GJB 5000A二级改进过程中最容易见到成效的过程活动。实际上，配置管理活动还可以在一定程度上起到项目监控的作用：配置管理人员“按图索骥”，按配置管理计划检查受控配置项以及数据，可以对项目的推进起到监控、促进作用。

3 体系建设要立足长远，不能只顾眼前

体系文件是组织过程改进的重要基础，是软件项目开发过程中遵循的内部标准，一套好的体系文件，不但要符合GJB 5000A要求，更要有利于项目的开发以及组织的软件过程改进。

从现状看，各军工单位直接与科研生产有关的体系主要有：质量管理体系、安全保密体系、安全生产与职业健康体系等。此外，还有档案管理、人事管理、财务管理等体系。这么多的体系要求，往往让身在其中的人无所适从。因此，新增加的软件过程改进体系一定要最大限度地与现有体系相适应，要“顺”。所谓“顺”，就是新体系要在已有的体系基础上进行细化和优化，对照GJB 5000A要求查漏补缺，而不是另起炉灶。

另外，大多数单位软件过程改进的目标一般不会停留在二级上，而是有着持续改进、逐级提升的要求，因此，在制定二级体系文件时，一定要兼顾未来升级的要求，不能升级一次，体系推倒重来一次。实际上，GJB 5000A标准中，三级的许多过程要求，在二级中已有描述，比如三级的“组织培训”过程域要求，在二级的公用实践“培训人员”中已有体现；三级的“风险管理”过程域要求，在二级的“项目策划”过程域的“SP2.2标识项目风险”和“项目监控”过程域的“SP1.3监督项目风险”中已有所要求。因此，在制定二级体系文件时，也要瞄准三级要求。可行的做法是在二级时指定一些与三级过程域关联的规程，到三级时进行扩充、细化，保证二级到三级的平稳过渡。“在二级生根，在三级发芽、成长”，是一种切实可行的做法。

4 没有技术提升，软件开发人员失去热情

GJB 5000A二级是要达到项目已策划、受管理、可控制。因此，二级过程改进的重点是管理。但从根本上来说，管理的提升是组织层面的目标，对于软件开发人员个体来说，技术的提升更是其兴趣所在。如果在二级过程改进时，仅仅是按标准要求，制订了一堆规程和表单，开发人员很可能把其视作约束，认为GJB 5000A徒然增加了许多工作量，对软件技术的提高和项目的开发无益，进而在推进过程中产生抵触情绪，降低改进效果。

从具体实践来看，试点项目顺次启动并拉开时间梯次、建立组织资源库，可以比较好的解决这一问题。第一个试点项目启动时，几乎全部EPG参与辅导，并全程参与技术类文档、管理类文档的编制、评审；第二个试点项目在第一个项目两个阶段后启动，全面参考第一个项目，EPG退出，但在阶段点进行重点监控，随时解决问题；从第一、第二个项目中选取比较完善的工作产品，纳入组织资源库；后续启动的项目利用组织资源库中的资源，实施就比较顺利了。

组织资源库建设，是GJB 5000A三级的要求，但在二级时建立，可以让各项目参加人员提前享受软件过程改进的成果，提高其参与改进的动力。

5 项目计划不合理

刚开始过程改进的组织，往往对工作量和风险估计不足，或者仅有感性上的认识，导致在制定计划以及WBS时，往往会认为所有的工作都已经考虑到了，所有的工作量都已经体现在WBS中，没有考虑到风险识别不到位、体系文件存在缺陷或培训不到位、在执行过程中会走很多弯路、增加较多的计划外工作量等情况，使得实际进度与计划存在较大偏差。因此，在试点阶段，项目计划应留有一定余量，防止过多的修改计划导致项目不能按期交付。

软件开发，“唯一不变的是变更”[3]。在软件开发过程中，最有可能出现的非计划任务是变更。大多数软件开发项目，都存在变更过程，比如因策划阶段与用户沟通不到位而引起的需求变更，其他如资源因素，需要推迟交付期的计划变更等等。那么，在分解WBS，或制定计划时，怎么考虑变更对计划的影响？

比较可行的方法是：在总的WBS中安排有可能发生的变更工作量（如估计工作量的10%），该工作量不分配到各阶段，但在项目的WBS中为其安排相应工期，计划变更时，就可以使用这部分的工期，但不影响项目最终的交付进度。当然，这个工作量也有可能不发生，在统计阶段工作量时，在哪个阶段发生的变更工作量，就统计在哪个阶段。这样做的另一个好处是：不在阶段预留变更工作量，能如实反映出每个阶段估计工作量和实际工作量的偏差，反映出估计人员进行项目估计应该注意的地方，这样可以为项目及后续项目开发积累数据，可在后续项目中参考此偏差，对每个阶段的工作量进行较为准确的估计。

6 培训不到位

在GJB 5000A二级认证过程中，许多单位因为培训不到位，带来了很多问题，如：各项目组对标准、过程体系的理解五花八门，导致执行的流程南辕北辙；即使制订了文档模板，项目组编制的软件文档也是“你说东，我说西”，条目类似，内容相去甚远；组织热衷于管理过程的宣贯以便获得认证，对具体的软件工程技术不太关心，导致项目组的开发水平提高不大，对过程改进失去兴趣，反过来阻碍成熟度提升。在实际的评价实践中，一般都会把“提高组织培训的有效性”作为一个待改进项。

为什么会有这样的问题呢？据分析，由于组织培训是成熟度三级的过程域，因此，许多单位在实施成熟度二级的过程改进时，不太重视培训，既没有在制度上予以保证，又没有采取有效实践，导致上述问题发生。

由此可以看出，实施GJB 5000A二级认证时，组织培训也是非常重要的方面，必须加以考虑。组织培训虽然是三级必须满足的过程域，但它对二级成熟度的达成具有至关重要的作用，在二级过程改进活动中必须给予足够重视。实施组织培训过程，对二级成熟度的达成能起到很好的保证、支持作用。为了规范化培训活动，可以在二级时就制定一个培训程序，指导单位和项目进行培训，提高体系执行的有效性和一致性。

7 结论

GJB 5000A认证牵涉到管理、支持、工程的多个方面，是一个规范化的过程改进活动，认证过程中必然会遇到各种各样的问题。总的来说，不应该以过级为目的，僵化地按成熟度等级来实施过程改进，而应该以实实在在地提升单位的软件工程化水平为目的。本文就实际实施过程中碰到的一些具体问题进行了探讨，并给出了一些解决措施，希望能对GJB 5000A二级认证征途上的同行有一些助益。