CMMLevel-2.doc

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软件项目计划根据纳入配置管理后的软件需求进行项目估算，并依据文档化的流程，形成项目计划文档。项目计划文档经复审后纳入配置管理，由项目开发人员遵循，并据此跟踪检查计划的执行。项目计划文档在复审过程中，如果项目计划对风险估算不足或存在其它问题，就需要对项目计划文档重新修正，以获得项目组和高层管理者的支持。软件项目计划（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) 实际项目中应用的文档有： 项目跟踪与监控流程定义、项目进度报告、项目进度指标收集指南。CMM Level 2 实战（二） 作者：刘文威 宁传成来源：希赛网2003年11月24日软件质量保证(Software Quality Assurance)软件质量保证的目的是为管理人员提供软件项目所用流程和正在构建的产品的可见度。软件质量保证涉及审查和核实软件产品及其活动，以便验证它们与项目采用的过程与标准的一致性。软件质量保证是为了确保对项目进行客观、公正的审查。 软件质量保证的基本流程可如所示。该流程描述了软件质量保证计划的形成与复审，SQA人员根据质量保证计划开展质量保证活动，发现问题，跟踪解决问题，并最终向高层管理者汇报项目的执行情况。质量保证计划一般包含项目过程采用的标准（如：项目计划估算过程、计划过程、测试过程、复审过程、开发过程、风险管理等）以及软件工作产品的标准（如：编码标准、接口定义标准等）。在项目实际进行过程中，比较典型的情况就是：质量保证人员担心与项目组成员起冲突，以至复审和审计活动缺乏有效性和公正性；或者是质量保证人员单纯重视软件产品（如：文档、代码等）的审阅，对项目执行的过程不够重视。根据所示流程，在实施项目的质量保证活动时，结合实际开发情况，可确定如下的软件质量保证过程：a) 项目质量保证人员以Microsoft Word拟定项目质量保证计划文档，以Microsoft Project拟定项目质量保证活动的进度表。b) 由质量保证经理或高层管理者指定项目的质量保证人员。项目的质量保证人员在项目开发计划复审通过之后，拟定项目的质量保证计划，并提交给项目经理和质量保证经理或高层管理者复审。c) 质量保证人员根据计划对项目执行的活动进行定期审计，记录与项目流程定义不一致的问题，并形成报告。d) 质量保证人员组织人员对产出的工作产品进行复审，以验证其是否与项目采用的标准一致，并形成报告。e) 将审计和复审发现的问题记录到项目的问题跟踪进度表中，跟踪并协调问题的解决情况，并定期向高层管理者汇报。如果不能解决的由高层管理者协助解决。f) 项目经理或高层管理者定期检查质量保证人员的活动。g) 实际项目中应用的文档有： 项目质量保证流程定义、质量保证计划、流程审计报告、软件工作产品复审报告、质量保证计划进度表、SQA问题跟踪解决进度表。软件配置管理(Software Configuration Management)软件配置管理的目的是在整个软件生命周期中建立和维护软件项目中的产品的完整性。 它包括标识在给定时间点上软件的配置，系统地控制对配置的更改，并维护在整个软件生命周期内配置的完整性和可跟踪性。因此，软件配置管理可以分为两方面的内容，一是配置项的识别和管理，另一方面是变更管理。a. 配置项管理软件的配置项管理的基本流程可如所示，该流程描述了软件工程组在进行开发过程中，生成软件工作产品，识别配置项，为配置项创建基线。配置管理项最显著的特征就是包含版本号或发布日期。实际项目管理经常不知道该如何识别区分配置项和基线。b. 变更管理描述了纳入配置管理的配置项进行变更的完整流程。根据新需求、项目进度报告、客户意见反馈、软件工作产品复审记录等不同的原因提出变更申请，由项目小组或变更控制委员会（SCCB）分析其影响，确定变更请求的拒绝、接受或搁置，并根据不同的决定进行不同的处理，一直到变更请求被处理。一旦采用了严格的变更控制管理流程，才能了解变更造成的影响，所有项目组成员才了解变更，形成共识，接受变更。缺少对变更有效的控制，往往会造成配置管理的无序，导致项目返工、延期，甚至失败。根据和所示流程，可以确定软件配置管理的方法：a) 项目设定配置管理人员，以Rational ClearCase为配置管理工具，根据项目计划拟定项目的配置管理计划文档，以Microsoft Project拟定项目配置活动的进度表。b) 项目的配置管理计划包含以下内容：配置管理工具、目录结构、识别配置项的方法、配置项命名、创建配置管理库、基线管理、配置审计、配置状态报告、变更管理等。c) 在ClearCase创建项目的VOB（版本对象库），创建项目小组成员的工作区和集成区，项目组成员只在各自的工作区Check in 或Check out操作，由配置管理人员进行合并，标识出软件配置项。d) 由配置管理人员负责在适当的时机（如：里程碑处或迭代结束）创建基线，晋升基线，下降基线，并由其负责备份和恢复基线。e) 根据配置管理计划对项目的配置项和基线定期（或里程碑处）进行审计，以验证其是否与项目配置计划或项目开发计划一致。f) 所有的变更请求首先向配置管理人员提出，由配置管理人员对变更请求进行分析确定其影响，组织变更评审小组。g) 一旦同意变更，由配置管理人员Check out需变更的配置项，然后对配置项进行变更，变更完成后再由配置管理人员Check in到配置管理库中。h) 由SQA人员定期审计配置管理的活动。i) 实际项目中应用的文档有： 项目配置管理计划制定流程定义、项目配置管理活动流程定义、项目配置管理计划、配置