项目管理规范-RUP管理实施

项目管理规范-RUP管理实施

第一部分：项目阶段 第二部分：核心工作流程 第三部分：角色划分

第四部分：目前实施项目规范的考虑 概述

软件开发的产品质量水平，是一个由来已久的话题。而提高软件企业的产品质量水平，必须改进软件产品的开发过程。但是这里没有什么百试百灵的灵丹妙药，我们必须根据本企业的实际情况，参考国内外先进企业的经验，总结出一种适合本企业的软件开发模式。

此规范是基于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需要一个相对较长的过程。 1. 项目阶段

从管理的观点来说，软件生命周期随着时间分为四个依次进行的阶段，每个阶段的结束都有一个主要里程碑；实质上，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估，以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。 . 计划阶段

在进度和工作量方面，所有阶段都各不相同。尽管不同的项目有很大的不同，但一个中等规模项目的典型初始开发周期应该预先考虑到工作量和进度间的分配： 先启 精化 构建 产品化 工作量 ~5% 20% 65% 10% 进度 10% 30% 50% 10% 可表示为下图

对于演进周期，先启和精化阶段就小得多了。能够自动完成某些构建工作的工具将会缓解此现象，并使得构建阶段比先启阶段和精化阶段的总和还要小很多。

通过这四个阶段就是一个开发周期；每次经过这四个阶段就会产生一代软件。除非项目“死亡”，否则通过重复同样的先启阶段、精化阶段、构建阶段和产品化阶段的顺序，产品将演进为下一代产品，但每一次的侧重点都将放在不同的阶段上。这些随后的周期称为演进周期。 随着产品经历了几个周期，新一代产品随之产生。 . 先启阶段 1.2.1. 目标

先启阶段的基本目标是实现项目的生命周期目标中所有相关因素（如客户等）之间的并行。 先启阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续

进行之前得到解决。对于重点是扩展现有系统的项目来说，先启阶段较短，但重点仍然是确保项目值得进行而且可以进行。 先启阶段的主要目标包括：

建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望软件中包括和不包括的内容。

识别系统的关键用例（也就是将造成重要设计折衷操作的主要部分）。

评估整个项目的总体成本和进度（以及对即将进行的精化阶段进行更详细的评估） 评估潜在风险（不可预测性的来源） 准备项目的支持环境。

明确地说明项目规模。这涉及了解环境以及最重要的需求和约束，以便于可以得出最终产品的验收标准。

计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备选方案。 综合考虑备选构架，评估设计和自制/外购/复用方面的折衷，从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。先启阶段的原型设计工作应该限制在确信解决方案可行就可以了。该解决方案在精化和构建阶段实现。

准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。

生命周期目标里程碑评估项目的基本可行性。

先启阶段末是第一个重要的项目里程碑，即生命周期目标里程碑。此时，检查项目的生命周期目标，并决定继续进行项目还是取消项目。

规模定义和成本／进度估算中，所有相关因素（如客户等）可并行

对是否已经获得正确的需求集达成一致意见，并且对这些需求的理解是共同的。 对成本／进度估算、优先级、风险和开发流程是否合适达成一致意见。 已经确定所有风险并且有针对每个风险的减轻风险策略。

如果项目无法达到该里程碑，则它可能中途失败或需要进行相当多的重新考虑。

核心文档及模型（按照重要性排序） 里程碑状态

前景 已经对核心项目的需求、关键功能和主要约束进行了记录。 商业理由 已经确定并得到了批准。 风险列表 已经确定了最初的项目风险。

软件开发计划 已经确定了最初阶段及其持续时间和目标。软件开发计划中的资源估算（特别是时间、人员和开发环境成本）必须与商业理由一致。

资源估算可以涵盖整个项目直到交付所需的资源，也可以只包括进行精化阶段所需的资源。此时，整个项目所需的资源估算应该看作是大致的“粗略估计”。该估算在每个阶段和每次迭代中都会更新，并且随着每次迭代变得更加准确。 根据项目的需要，可能在某种条件下完成了一个或多个附带的“计划”工件。此外，附带的“指南”工件通常也至少完成了“草稿”。 迭代计划 第一个精化迭代的迭代计划已经完成并经过了复审。