利用 RUP达到 CMM2和3级

摘自：http://www.ltesting.net/html/29/n-141629.html

摘要
软件工程协会 (SEI) 的能力成熟度模型 (CMM) 提供了一种著名的软件流程成熟度基准。CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件流程的成熟程度。本白皮书说明了 Rational Unified Process 如何支持正在努力达到 CMM 级别 2 （可重复的）和级别 3（已定义的）的组织。
简介
软件工程协会 (SEI) 的能力成熟度模型 (CMM) 是一个描述有效软件流程元素的框架 [REF1]。CMM 描述了一条从临时的、未成熟的流程向成熟的、规范化的流程演进的途径。
CMM 覆盖软件开发和维护的规划、工程以及管理经验。这些关键的经验提高了组织实现成本、进度、功能性和产品质量等目标的能力。
CMM 有五个成熟级别：从级别 1 到级别 5。如下图所示。每个成熟级别由关键流程领域（Key Process Areas，KPA）组成，每个KPA确定一组相关活动。当这些相关活动一起开展时，它们完成一系列被认为对在该成熟级别建立流程能力有重要影响的目标。

级别 2，“可重复的级别”定义如下：
在 可重复级别，应建立管理软件项目的策略以及实施这些策略的过程步骤。新项目的规划和管理是以类似项目的经验为基础的。达到级别 2 的目标就是为了使软件项目的有效管理流程制度化，从而让组织重复在过去的项目中获得的成功经验，即使项目实施的具体流程可能存在差异。有效流程的特征可以 归纳为熟练的、文档化的、加强的、培训的、评测的和可以改进。
级别 2 的组织的项目已经安装了基本的软件管理控制。符合现实的项目承诺是根据对以前项目的观察结果和当前项目的需求做出的。项目的软件经理跟踪软件成本、进度和 功能，并确定在履行承诺期间出现的问题。创建软件需求和为满足这些需求开发的工作产品的基线，并控制它们的完整性。定义软件项目标准后，组织确保这些标准 得到不折不扣的执行。如果有分包商，则软件项目可以和分包商合作，建立牢靠的顾客供应商关系。
级别 2 组织的软件流程能力可以用规范化来概括，因为软件项目的规划和跟踪是稳定的，以前的成功经验可重复使用。项目的流程受项目管理系统的有效控制，遵守根据以前项目的性能制定的符合现实的计划。
级别 2 KPA 是：
需求管理
软件项目规划
软件项目跟踪与勘察
软件分包管理
软件质量保证
软件配置管理
级别 3，“已定义的级别”定义如下：
在 已定义的级别上，组织开发维护软件的标准流程已做记录（包括软件工程和管理流程），而且这些流程都集成到一个连贯的整体中。标准流程在整个 CMM 中始终是指组织的标准软件流程。在级别 3 建立的流程用于（必要的时候可修改）帮助软件经理和技术人员更有效地执行任务。组织在建立标准化的软件流程的时候，利用了有效的软件工程的经验和方法。有 一个小组负责组织的软件流程活动，如软件工程或SEPG。为了确保员工和经理具有完成分配给他们的任务必须掌握的知识和技能，需要在整个组织范围内实施培 训计划。
项目对组织的标准软件流程进行定制，开发它们自己定义的软件流程，使项目具有独一无二的特点。这个定制流程在 CMM 中是指项目的已定义软件流程。已定义的软件流程包含了定义明确的软件工程和管理流程的一个一致、完整的集合。明确定义的流程其特征可以归纳为包含准备就绪 的准则、输入、执行工作的标准和过程、验证机制（如平级复审）、输出和完成标准等。由于明确定义了软件流程，管理层对所有项目的技术进展都有深刻的了解。
级别 3 组织的软件流程能力可以用标准一致来概括，因为软件工程和管理活动不仅稳定而且可重复。在已建立的产品线内，成本、进度和功能都受到控制，并且软件质量获得跟踪。这一流程能力建立在整个组织对已定义的软件流程的活动、角色和责任形成共同理解的基础上。
级别 3 KPA 是：
组织流程重点
组织流程定义
培训计划
综合软件管理
软件产品工程
组间协作
平级复审
本文各节描述 Rational Unified Process 特性、方法、程序和工件如何实现 KPA 目标。
本文是为关心达到 CMM 框架内的组织成熟级别 2 和级别 3 的组织人员而编写的。
级别 2，可重复的
需求管理
需 求管理的目的是为了在客户和处理客户需求的软件项目之间建立共识。与客户达成的统一认识是软件项目规划（如软件项目规划 KPA 所述）和管理（如软件项目跟踪与勘察 KPA 所述）的基础。对客户关系的控制依赖于执行有效的变更控制流程（如软件配置管理 KPA 所述）。
Rational Unified Process 的关键特性之一在于它是用例驱动的。用例代表了获取、组织和传达用户需求的一种系统化方案。它们提供了记录功能性需求的方式，而功能性需求是项目开发、测试和迭代规划的基础。在 Rational Unified Process 中，用例在用例模型中进行维护，并在项目的整个生命周期里统一引用，从分析到测试一直到维护。
在工程环境中获取需求的 Rational Unified Process 工件是：
由用例和用例包构成的用例模型
非功能性的“补充规约”
用例模型调查
用例报告
词汇表
在管理环境中使用的、说明待开发用例及场景（需求）的 Rational Unified Process 工件包括：
迭代计划
集成构建计划
项目计划
软件开发计划
所有这些工件都建立了基线，并受某个变更管理规定的制约。
目标 1 ：对分配给软件的系统需求进行控制，以便创建软件工程和管理的基线。
Rational Unified Process 主张对所有演进的工件进行连续的配置控制，然而，“正式的”基线与以下里程碑对应。
生命周期目标里程碑（先启阶段），
生命周期构架里程碑（精化阶段），
初始操作能力里程碑（构建阶段），以及
产品发布里程碑（产品化阶段）。
同样，Rational Unified Process 在需求、需求管理、跟踪及创建基线上与 CMM 一致。
目标 2：软件计划、产品和活动与分配给软件的系统需求保持一致。
该 CMM 目标重点在于确保交付的系统满足用户需求。Rational Unified Process 通过两种方式帮助组织实现这一目标：
用例方案确保用户需求得到理解并被获取。获取需求后，需求向下流动到各个“可视的” Rational Unified Process 模型（用例、设计、实施和测试），以保证一致性和连贯性。
控 制的迭代式开发方案是一种风险降低策略，藉此项目风险能够及早得到理解和研究，然后经常重新检查。每一次累进迭代，通过不断集成新增的功能，及早揭示风 险。若使用传统的瀑布式方法，则这些风险直到开发生命周期的后期才能够被发现。及早识别风险对项目管理有直接好处，可重新定义需求规模，或者提出其他战术 改变。
Rational Unified Process 管理文档包括：
商业理由
软件开发计划
评测计划
风险列表
项目计划
迭代计划
迭代评估和状态评估。
有效的变更控制和管理是 Rational Unified Process 的另一特性，它确保了软件根据分配的、受到跟踪的指定需求来开发。
Rational Unified Process 主张每个项目都应设立一个变更控制委员会 (CCB)，对提议的变更或者开发过程中发现的缺陷在规模及影响方面（预算、技术或时间安排）作出公断。为了协助 CCB 的运作，Rational Unified Process 建议使用强大的配置管理和版本控制工具/环境。
软件项目规划
软件项目规划的目的在于建立合理的计划，执行软件工程和管理软件项目。这些计划是软件项目管理（如软件项目跟踪与勘察 KPA 所述）所必不可少的。没有符合现实的计划，就不可能实施有效的项目管理。
目标1：对软件估算进行记录，以便用于规划和跟踪软件项目。
Rational Unified Process 的目标之一是确保各方面的期望都同步进行并且保持一致。它通过在项目生命周期内进行定期评估来确保完成，并记录在状态评估报告中。报告需要对资源（人员配 备和财政）、首要的十大风险、技术进步的追踪数据，通过指标和主要的里程碑结果来进行测量。
Rational Unified Process 利用了以下类别的指标：
进度（代码行、类的个数、每次迭代的功能点、返工）
稳定性（返工类型、需求或实施变更率）
适应性（返工成本）
模块度（返工影响范围）
质量（缺陷发现频率、密度、继承深度、返工指示符）
成熟程度（每次故障的测试时间）
资源耗费配置文件（计划的与实际的）
目标 2：计划并记录软件项目活动和承诺。
获取项目计划和承诺的 Rational Unified Process 文档包括：
商业理由
软件开发计划
评测计划
风险列表
项目计划
迭代计划
迭代评估，以及
状态评估。
软件项目跟踪与勘察
软件项目跟踪与勘察的目的在于建立实际进度的适当可见度，以便管理人员在软件项目的执行极大偏离软件计划时采取有效的措施。
目标 1：对比软件计划追踪实际结果和性能。
如软件项目规划一节所述，Rational Unified Process 有几个级别的项目计划和一个状态评估报告。状态评估报告对比计划与实际的结果，从而进行评估。为特定里程碑生成状态评估报告是项目经理的职责。
主要的 Rational Unified Process 里程碑对应着一个阶段（先启、精化、构建或产品化）的结束，有明确指定的完成标准。一个阶段的每次迭代结束时，在次要的里程碑处都存在复审的机会，这也是决策点，是未来发展方向的经验教训。
例 如，精化阶段的目标是分析问题领域，建立一个坚固的构架基础，制定项目计划，消除项目中的风险最高的元素。必须对整个系统有了理解之后，才能做出构架决 策。这就暗示着在描述大部分用例时会考虑一些约束：补充需求。为验证构架，实施一个系统，来证明所选构架是正确的，并执行意义重大的用例。
在精化阶段结束时，检查详细的系统目标和规模，以及选择的构架和确定的主要风险。当实际结果和性能极大地偏离软件计划时，采取纠正措施，并管理至项目结束。
风 险列表是一个 Rational Unified Process 工件，它概括了项目中所有已知风险，并作为规划和项目评估的输入。每个风险都根据它的影响和应急计划来进行描述，应急计划是为降低风险而制定的。风险列表 与业务案例一起制定，它们形成了“执行”或“不执行”项目的决策基础。风险列表在项目的整个生命周期都要进行维护。
目标 2：软件承诺的变更得到受影响的小组和个人的同意。
如 Rational Unified Process 所述，受控的迭代式开发流程确保涉众能经常看到项目进展情况以及为了保持项目不偏离轨道所作的任何必要的变更。提议的变更由变更控制委员会 (CCB) 进行复审，确保变更符合现实的，并且可以被项目的整体日程接受。