CMMLevel-.docVIP

CMM Level 2 实战（一） 作者：刘文威 宁传成　来源：希赛网　　2003年11月24日 现在关于CMM的文章不在少数，但基本上都是概念性、理论性的。为了使大家对CMM有更通俗、更直观的理解，作者根据实施CMM多年积累的经验，结合实际项目的管理及应用，提出了一套可行的CMM2实施方案，以期能为同行提供有价值的参考。 一、前言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软件项目计划根据纳入配置管理后的软件需求进行项目估算，并依据文档化的流程，形成项目计划文档。项目计划文档经复审后纳入配置管理，由项目开发人员遵循，并据此跟踪检查计划