CMM Level 2 实战

　　一、前言

　　CMM（软件能力成熟度模型：Software Capability Maturity Model)，是由美国卡内基梅隆大学(CMU)的软件工程研究所(SEI)制定的一种软件评估标准，主要用于软件开发过程和软件开发能力的评估和改进。此标准自1991年提出以来，已在美国、印度、日本、欧洲等地成功应用，并成为软件行业的工业标准。

　　尽管CMM引起了软件行业充分的重视，但如何将CMM应用到企业或项目管理中 ，大多数企业仍然毫无头绪。其实实施CMM的最大障碍通常不是技术问题，而是工程和经验方面的管理问题以及企业文化问题，这一点对于中小软件企业尤其突出。本文将从CMM2的六个KPA入手，根据作者实施CMM多年积累的经验，具体介绍CMM2的实践及应用。

　　二、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) 实际项目中应用的文档有：

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

原文转自：http://www.ltesting.net