项目管理规范-RUP管理实施（二）

作者：李杰 发文时间：2002.03.29

第一部分：项目阶段 第二部分：核心工作流程 第三部分：角色划分 第四部分：目前实施项目规范的考虑 软件开发的产品质量水平，是一个由来已久的话题。而提高软件企业的产品质量水平，必须改进软件产品的开发过程。但是这里没有什么百试百灵的灵丹妙药，我们必须根据本企业的实际情况，参考国内外先进企业的经验，总结出一种适合本企业的软件开发模式。 此规范是基于CMM模型规范，以RUP软件工程过程为蓝本，由我本人根据项目实际情况而选择修改，从而使之适应当前应用级系统设计开发的需要。 本文主要以RUP的软件工程框架为主，省略复杂概念部分。着眼点放在控制软件产品开发流程上，由于人员配置与软件分工现行状况的限制，对其中的部分细节进行了合并可省略，从而适应目前国内软件开发所要求。 Rational Unified Process（简称RUP）是一套软件工程过程（在下面介绍）。 在RUP过程中，我们可以看到它非常强调一点：循环。 现在我们做的每一个项目都存在不断变化的问题。用户需求变化、系统设计变化（可能是需求变化也可能是存在了技术问题）、编码变化（由测试与复审等环节引发的）等问题困扰着项目进行。解决这些问题的方法就是不断的循环。 这个规范是我根据自己的观点整理编写而成的，有不足之处请指教。 RUP简介 Rational Unified Process（简称RUP）是一套软件工程过程，主要由Ivar Jacobson的 The Objectory Approch 和 The Rational Approch 发展而来。同时，它又是文档化的软件工程产品，所有RUP 的实施细节及方法导引均以Web文档的方式集成在一张光盘上，由Rational公司开发、维护并销售，当前版本是RUP2000。RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。 RUP 吸收了多种开发模型的优点，具有很好的可操作性和实用性、从它一推出市场，凭借Booch、Ivar Jacobson、以及Rumbaugh 在业界的领导地位、以及与统一建模语言（Unified Model Language , 以下简称UML）的良好集成、多种CASE工具的支持、不断的升级与维护，迅速得到业界广泛的认同，越来越多的组织以它作为软件开发模型框架。 在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。


如上图所示，时间维从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分。它可进一步描述为周期（Cycle）、阶段（phase）、迭代(Iteration)。 核心工作流从技术角度描述RUP的静态组成部分，它可进一步描述为行为（activities）、工作流（workflow）、产品（artifact）、工人（worker）。 图中的阴影部分描述了不同的工作流，在不同的时间段内工作量的不同。值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是大小不同而已。这与Waterfall process 有明显的不同。 RUP采用Use Case的概念，把要开发的系统根据各功能使用的情况划分多个Use Case，并采用迭代的思想把系统的风险分布在四个阶段，风险越大的迭代越要放在靠前的阶段做，使软件产品的风险不断降低；而不是像传统软件工程那样越往开发的后期问题越多。所以RUP的思想一推出就受到软件企业的欢迎。按照RUP的开发模式一般可以达到CMM2、3级的水平。当然，理解和掌握RUP需要一个相对较长的过程。 2. 核心工作流程 软件工程中的工作流程分为两部分：核心工作流程与核心支持工作流程 核心工作流程（在项目中的流程）

业务需求建模

分析设计

实施

测试

部署

核心支持工作流程（在组织中的流程）

环境

项目管理

配置与变更管理

2.1. 业务需求建模 2.1.1. 目的 业务建模的目的在于：

了解目标组织（将要在其中部署系统的组织）的结构及机制。

了解目标组织中当前存在的问题并确定改进的可能性。

确保客户、最终用户和开发人员就目标组织达成共识。

导出支持目标组织所需的系统需求。

为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。 作为对这些模型的补充，还编写了以下文档：

补充业务规约

词汇表

2.1.2. 业务建模工作流程

2.1.3. 提供的文档与模型

商业逻辑建模（USE CASE）（ROSE）

业务需求说明书（MS WORD）

专业词汇表（英汉对照）（MS WORD）

风险说明（MS WORD）

复审说明书

2.1.4. 文档模板 参见项目管理规范目录下业务需求文档模板子目录 2.2. 分析设计 2.2.1. 目的 分析设计的目的在于：

将业务需求转换为未来系统的设计。

逐步开发强壮的系统构架。

使设计适合于实施环境，为提高性能而进行设计。

2.2.2. 分析设计工作流程

2.2.3. 提供的文档与模型

系统总体设计报告（MS WORD）

系统设计模型DOMAIN MODEL（ROSE）

系统设计模型DESIGN MODEL （ROSE）

数据库设计模型 （POWER DESIGNER）

数据字典（MS WORD）

系统详细设计报告（MS WORD）

工作量化书（MS WORD）

2.2.4. 文档模板 参见项目管理规范目录下分析设计文档模板子目录 2.3. 实施 2.3.1. 目的 实施的目的包括：

对照实施子系统的分层结构定义代码结构、

以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式实施类和对象、

对已开发的构件按单元来测试，并且

将各实施员（或团队）完成的结果集成到可执行系统中。

实施工作流程的范围仅限于如何对各个类进行单元测试。系统测试和集成测试将在测试工作流程中进行说明。 测试的目的在于：

核实对象之间的交互。

核实软件的所有构件是否正确集成。

核实所有需求是否已经正确实施。

确定缺陷并确保在部署软件之前将缺陷解决。

2.3.2. 实施工作流程

2.3.3. 提供的文档与模型

实施总结书（MS WORD）

实施模型（ROSE）

系统集成书（MS WORD）

代码审核意见书（MS WORD）

源代码（MS WORD）

用户使用手册（MS WORD）

错误解决记录手册（MS WORD）

构件及其说明

2.3.4. 文档模板 参见项目管理规范目录下实施文档模板子目录 2.4. 项目管理 2.4.1. 目的 本部分的目标是，通过提供一些项目管理的环境，使这个任务更加容易完成。它虽然不是成功的秘诀，但它介绍了可以显著提高成功交付软件可能性的项目管理方法。 项目管理的目的是：

为对软件密集型项目进行管理提供框架。

为项目的计划、人员配备、执行和监测提供实用的准则。

为管理风险提供框架。

该工作流程主要侧重于迭代式开发流程的以下重要方面：

风险管理

计划迭代式项目，贯穿生命周期并针对特定的迭代

监测迭代式项目的进度、指标

2.4.2. 项目管理工作流程

2.4.3. 提供的文档和模板

风险管理计划（MS EXCEL）

工作计划书（MS EXCEL）

风险列表（MS EXCEL）

迭代计划（MS EXCEL）

问题解决计划（MS EXCEL）

测试计划书（MS EXCEL）

系统集成计划书（MS EXCEL）

子系统集成计划书（MS EXCEL）

工作单（MS EXCEL）

产品验收计划（MS EXCEL）

评测计划（MS EXCEL）

项目计划复审意见书（MS WORD）

开发总结（MS WORD）

2.4.4. 文档模板 参见项目管理规范目录下项目管理文档模板子目录 2.5. 部署 2.5.1. 目的 部署工作流程用来描述那些为确保最终用户可以正常使用软件产品而进行的活动。

部署工作流程描述了两种产品部署的模式：

自定义安装

通过 Internet 使用软件

在每个实例中，都强调要在开发场所对产品进行测试，并在产品最终发布之前进行 Beta 测试。 尽管部署活动主要集中于产品化阶段，但在较早的一些阶段中也会有一些为部署进行计划和准备的活动。 2.5.2. 提供的文档和模板

部署计划

安装文档

发布说明

『引自 UMLCHINA』

概述