CMM2级实施技术问题分析

CMM2级实施技术问题分析

于小葆

（本文转载自软件工程专家网www.21cmm.com）

　　一些正在实施CMM2级的企业发现有大量的重复性工作要做，原因何在？没有做好需求开发是产生这一问题的主要原因！

1 需求管理与需求工程

　　需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出现重复性的工作。导致需求开发欠佳的主要原因有以下几点：

◆ 缺乏良好的需求规格说明编写模板

　　分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。

◆ 较严重地忽略了非功能性需求

　　目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功能性需求也会越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工作的包围之中。

　　如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在的不足。

◆ 缺乏对需求文档的配置管理

　　采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。

◆ 需求规格说明缺乏可测性

　　在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题。

◆ 缺乏较好的需求规格说明转化规范

　　需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失，从而增加后续管理工作的难度。

　　需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性，因此需求工程完成得好坏对需求管理实施的工作量有很大影响。

2 配置管理与工作产品的转化

　　软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性，它需要一个较好的工具，当找不到较好的商用软件工具覆盖该关键域的实践时，许多国外软件企业会自行开发一些工具来弥补不足，并且取得了很好的效果。国内软件企业在实施该关键域时也会使用一些工具，但存在的典型问题是：有太多的SCCB（软件配置控制委员会）活动。

　　配置管理是在软件生命周期中建立和标识软件工作产品并控制基线的更改，这将保证软件工作产品的完整性和一致性。但是，作为配置项/单元标识的软件工作产品通常为典型的软件生命周期中的工作产品，这些产品具有一个共同特点：一个产品通常是由另一个产品转化而来。从一些企业配置管理下的工作产品来看，存在的主要问题是缺乏较好的可转化性。在这里，“较好的可转化性”是指把一个产品转化为另一个产品时有较规范的转化规则可循，其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产品形式，从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误解释的可能性。企业在实施这个关键过程域时，应由SCCB记录工作产品的更改以及引发这些更改的原因，这些数据能很好地帮助企业找出问题的症结。一般来说，引发类似问题的原因主要有以下3点：

　　需求规格说明书编写不好或不全；

　　工作产品模板定义不好；

　　工作产品之间转化缺乏规范定义。

3 项目计划与数据收集和分析

　　项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。

　　一般来说，期望在CMM实施之初就有一个可靠的项目计划是不现实的，因为这需要经历若干项目的实施才能获得有效数据并据此制定未来项目的计划。我们知道，配置管理可以保证项目生成的产品在软件生命周期中的完整性，因此，为了更好地实施项目计划，我们可以把用于项目计划的大部分数据放在对应的工作产品配置管理之下，必要时，还可将工作产品进一步细化，以保证对应的项目计划数据的准确性。项目完成后，我们还应该对项目计划的数据进行收集和分析，在此基础上制定下一个项目计划时，准确性就能大大提高。通过对若干项目进行同样的实践，项目经理就有了比较可靠的数据用于制定未来的项目计划。通常，项目跟踪和监督实施不好的原因很大程度上是由于项目计划的频繁更动，同时缺乏良好的项目跟踪工具，使项目管理人员逐渐失去跟踪项目的兴趣。

4 质量保证与实践反馈

　　实践反馈是质量保证体系得以有效运作的驱动力，企业应该为所有项目建立一条从SQA到项目经理以及更高层经理的反馈渠道。实践反馈是SQA组与高层经理相互沟通的过程，SQA组定期向高层经理汇报SQA的活动，并及时与项目组沟通，使项目组能尽早改进工作；当沟通不畅、发现项目组运作不力或发现组间协调困难时，应及时报告高层经理，通过高层经理的协调及时进行修正。

　　有些项目经理认为自己心里有一套计划，只要按计划进行就可以按时保质完成项目，但事实并非如此，在项目组之间的协调问题上，高层经理的作用是非常明显的。如果仅仅为满足CMM的要求而虚设高层经理，这种做法是不可取的，因为如此一来，实践反馈是不完全的。

　　SQA组在CMM实践中犹如一个司法机构，但这还不够，它还应该为改进过程管理提供资源。SQA组不一定完全由专职人员组成，也可调配一些擅长软件开发方法和软件过程管理的人员参与主要的SQA活动。

5 同行评审

　　从理论上讲，同行评审这个关键域的实施并不难，但实际上大多数企业都掌握得不够好，主要表现在以下方面：

◆ 评审时组间争论过多或过少

　　这一问题在不同企业的表现也不同。调查表明，争论较多的情况是工作产品的输入/输出不清楚，组间缺乏沟通的公共平台，因此组间只有通过较多的讨论甚至争论才能弄清其他组的需求。遗憾的是，事后大家并没有坐下来认真讨论如何改进原工作产品的模板形式或表现形式，因而也就无法从根本上解决问题。另一种较极端的情况是，评审一个组的工作产品时，其他组很少发表意见，尽管有些问题是十分明显的。通过调研发现，这实际上是企业文化的问题。一种普遍的想法是“等我们实际做的时侯自然就清楚了”，但实际情况往往事与愿违，这使企业的工作效率大打折扣，但又不易被管理层意识到。无论是哪种情况，最终的原因是：“项目甚至企业缺乏持续改进过程管理的意识。”

◆ 缺乏心理训练

　　做好同行评审的最大挑战是克服心理障碍。简单地说，同行评审就是被别人挑错或挑别人的错。因此，评审会就像是答辩会，必须做好充分的准备。当角色互换，自己成了挑错方时，则应该把被评审的工作产品看成是自己在较早前完成的，现在再做一次修改，且修改完成后，自己要拿它去参加评审答辩。经历几次这种心理角色换位，就会逐渐适应。如果大家都这么做，同行评审就会形成良好的氛围，这对形成健康的企业文化将起促进作用。

◆ 竞争与合作意识不充分

　　从另一个角度看，同行评审又是竞争与合作的最佳表现场所和形式，凡在这种场合讲话有理且意见中肯的人逐渐会成为团队的核心人物。在这种竞争的环境中，合作是基础，同行评审的目的就是在合作的前提下尽早且有效地排除工作产品中的缺陷。把握好竞争与合作的尺度，将有益于企业文化的发展，否则有可能出现恶性循环。如何把握呢？从大量的案例看，多数消化少数是较好的方法，因为文化是不可创造的。

◆ 考虑不全面

　　同行评审存在的另一个问题是评审时仅注意工作产品内容本身，大家面对面地弄清内容后，却忽略了如何改进工作产品的表现形式，使新表现形式下的工作产品可更好地用书面形式表示，进而可减少面对面沟通的需求。当然，面对面的沟通并不是不好，但如果一个工作产品需要太多的口头表达才能被理解，则原因只有两个：书写不清楚或模板定义不好，如果是后者则情况更糟。

6 缺陷预防与度量

　　缺陷预防的目的是为了识别产生缺陷的原因并防止其再次发生。一些实施低级别CMM的企业通常都采用一些度量（metrics）来预防缺陷，包括软件大小、软件设计错误、编码错误、测试错误、设计评审覆盖、编码评审覆盖、产生测试覆盖、与过程原因相关的缺陷、与项目原因相关的缺陷等。

　　个别企业选用了一些难度更大的度量。大多数情况下，这些企业并非要达到更高级别的CMM，而是从产品需求的特性出发，对工作产品进行缺陷分析和预防。其过程通常是：获取数据、数据整理、度量、发现原因并确定过程的改进措施，其典型例子包括设计复杂性与测试覆盖及测试深度、模块复杂性与测试覆盖及测试深度等。这类企业的软件产品一般具有以下特点：软件产品规模较大，通常在软件产品交付给用户后，通过相当长时间的不断维护，稳定性才能达到满意程度。如果在早期对可能产生较多错误的软件模块进行识别，加强对这些模块的早期关注和测试，就可较早地使系统达到稳定。这种方法常常用在大型软件开发中，但真正用好的并不多，主要原因有以下几点：

◆ 忽略了使用度量的环境

　　大多数工作产品的度量都是为某一种特定的设计方法或编程语言设计的，忽略了这个因素，度量就容易失去准确性。此外，软件产品不同的行业特性往往也是造成度量产生偏差的原因。

◆ 忽略了对度量参数的修改

　　一些度量参数是在原来的实践环境下确定的，当在新环境下使用时，其中的参数很可能需要进行修改，才能使度量的准确性得到保证。

◆ 忽略了对相关性的研究

　　使用的度量与缺陷在本地的相关性越高，度量的价值就越大。获取这种相关性的方法一般是对本地的历史数据进行相关性研究，企业只有在确认满意的相关性后才可将度量用于缺陷预防。