文档介绍：项目管理规范-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. 项目阶段从管理的观点来说,软件生命周期随着时间分为四个依次进行的阶段, 每个阶段的结束都有一个主要里程碑; 实质上, 每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估, 以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。 . 计划阶段在进度和工作量方面, 所有阶段都各不相同。尽管不同的项目有很大的不同, 但一个中等规模项目的典型初始开发周期应该预先考虑到工作量和进度间的分配: 先启精化构建产品化可表示为下图对于演进周期, 先启和精化阶段就小得多了。能够自动完成某些构建工作的工具将会缓解此现象, 并使得构建阶段比先启阶段和精化阶段的总和还要小很多。通过这四个阶段就是一个开发周期; 每次经过这四个阶段就会产生一代软件。除非项目“死亡”, 否则通过重复同样的先启阶段、精化阶段、构建阶段和产品化阶段的顺序, 产品将演进为下一代产品, 但每一次的侧重点