利用 Rational Unified Process 达到 CMM 级别 2…

摘要

软件工程协会 (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：软件计划、产品和活动与分配给软件的系统需求保持一致。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有