关键字：项目管理 RUP
第一部分：项目阶段 第二部分：核心工作流程
第三部分：角色划分
第四部分：目前实施项目规范的考虑
概述
软件开发的产品质量水平，是一个由来已久的话题。而提高软件企业的产品质量水平，必须改进软件产品的开发过程。但是这里没有什么百试百灵的灵丹妙药，我们必须根据本企业的实际情况，参考国内外先进企业的经验，总结出一种适合本企业的软件开发模式。
此规范是基于CMM模型规范，以RUP软件工程过程为蓝本，由我本人根据项目实际情况而选择修改，从而使之适应当前应用级系统设计开发的需要。
本文主要以RUP的软件工程框架为主，省略复杂概念部分。着眼点放在控制软件产品开发流程上，由于人员配置与软件分工现行状况的限制，对其中的部分细节进行了合并可省略，从而适应目前国内软件开发所要求。
Rational Unified Process（简称RUP）是一套软件工程过程（在下面介绍）。
在RUP过程中，我们可以看到它非常强调一点：循环。
现在我们做的每一个项目都存在不断变化的问题。用户需求变化、系统设计变化（可能是需求变化也可能是存在了技术问题）、编码变化（由测试与复审等环节引发的）等问题困扰着项目进行。解决这些问题的方法就是不断的循环。
这个规范是我根据自己的观点整理编写而成的，有不足之处请指教。
李杰
2001年3月14日
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. 项目阶段
从管理的观点来说，软件生命周期随着时间分为四个依次进行的阶段，每个阶段的结束都有一个主要里程碑；实质上，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估，以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。
1.1. 计划阶段
在进度和工作量方面，所有阶段都各不相同。尽管不同的项目有很大的不同，但一个中等规模项目的典型初始开发周期应该预先考虑到工作量和进度间的分配：
|
先启 |
精化 |
构建 |
产品化 | |
|
工作量 |
~5 % |
20 % |
65 % |
10% |
|
进度 |
10 % |
30 % |
50 % |
10% |
可表示为下图
对于演进周期，先启和精化阶段就小得多了。能够自动完成某些构建工作的工具将会缓解此现象，并使得构建阶段比先启阶段和精化阶段的总和还要小很多。
通过这四个阶段就是一个开发周期；每次经过这四个阶段就会产生一代软件。除非项目“死亡”，否则通过重复同样的先启阶段、精化阶段、构建阶段和产品化阶段的顺序，产品将演进为下一代产品，但每一次的侧重点都将放在不同的阶段上。这些随后的周期称为演进周期。 随着产品经历了几个周期，新一代产品随之产生。
1.2. 先启阶段
1.2.1. 目标
先启阶段的基本目标是实现项目的生命周期目标中所有相关因素（如客户等）之间的并行。 先启阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。对于重点是扩展现有系统的项目来说，先启阶段较短，但重点仍然是确保项目值得进行而且可以进行。
先启阶段的主要目标包括：
· 建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望软件中包括和不包括的内容。
· 识别系统的关键用例（也就是将造成重要设计折衷操作的主要部分）。
· 评估整个项目的总体成本和进度（以及对即将进行的精化阶段进行更详细的评估）
· 评估潜在风险（不可预测性的来源）
· 准备项目的支持环境。
1.2.2. 核心活动
· 明确地说明项目规模。这涉及了解环境以及最重要的需求和约束，以便于可以得出最终产品的验收标准。
· 计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备选方案。
· 综合考虑备选构架，评估设计和自制/外购/复用方面的折衷，从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。先启阶段的原型设计工作应该限制在确信解决方案可行就可以了。该解决方案在精化和构建阶段实现。
· 准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。
1.2.3. 里程碑：生命周期目标
生命周期目标里程碑评估项目的基本可行性。
先启阶段末是第一个重要的项目里程碑，即生命周期目标里程碑。此时，检查项目的生命周期目标，并决定继续进行项目还是取消项目。
1.2.3.1 评估标准
· 规模定义和成本／进度估算中，所有相关因素（如客户等）可并行
· 对是否已经获得正确的需求集达成一致意见，并且对这些需求的理解是共同的。
· 对成本／进度估算、优先级、风险和开发流程是否合适达成一致意见。
· 已经确定所有风险并且有针对每个风险的减轻风险策略。
如果项目无法达到该里程碑，则它可能中途失败或需要进行相当多的重新考虑。
1.2.3.2 提供的文档及模型
|
核心文档及模型（按照重要性排序） |
里程碑状态 |
|
前景 |
已经对核心项目的需求、关键功能和主要约束进行了记录。 |
|
商业理由 |
已经确定并得到了批准。 |
|
风险列表 |
已经确定了最初的项目风险。 |
|
软件开发计划 |
已经确定了最初阶段及其持续时间和目标。软件开发计划中的资源估算（特别是时间、人员和开发环境成本）必须与商业理由一致。
资源估算可以涵盖整个项目直到交付所需的资源，也可以只包括进行精化阶段所需的资源。此时，整个项目所需的资源估算应该看作是大致的“粗略估计”。该估算在每个阶段和每次迭代中都会更新，并且随着每次迭代变得更加准确。
根据项目的需要，可能在某种条件下完成了一个或多个附带的“计划”工件。此外，附带的“指南”工件通常也至少完成了“草稿”。 |
|
迭代计划 |
第一个精化迭代的迭代计划已经完成并经过了复审。 |
|
软件验收计划 |
完成复审并确定了基线；随着其他需求的发现，将对其在随后的迭代中进行改进。 |
|
项目专用模板 |
已使用文档模板制作了文档工件。 |
|
用例建模指南 |
确定了基线。 |
|
工具 |
选择了支持项目的所有工具。安装了对先启阶段的工作必要的工具。 |
|
词汇表 |
已经定义了重要的术语；完成了词汇表的复审。 |
|
用例模型（主角，用例） |
已经确定了重要的主角和用例，只为最关键的用例简要说明了事件流。 |
|
领域模型（也叫做业务对象模型） |
已经对系统中使用的核心概念进行了记录和复审。在核心概念之间存在特定关系的情况下，已用作对词汇表的补充。 |
|
原型 |
概念原型的一个或多个证据，以支持前景和商业理由、解决非常具体的风险。 |
1.3. 精化阶段
1.3.1. 目标
精化阶段的目标是建立系统构架的基线，以便为构建阶段的主要设计和实施工作提供一个稳定的基础。构架是基于对大多数重要需求（对系统构架有很大影响的需求）的考虑和风险评估发展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。
精化阶段的主要目标包括：
确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。对大多数项目来说，通过此里程碑也就相当于从简单快速的低风险运作转移到高成本、高风险的运作，并且在组织结构方面面临许多不利因素。
处理在构架方面具有重要意义的所有项目风险
建立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常可以显示项目的最大技术风险。
制作产品质量构件的演进式原型，也可能同时制作一个或多个可放弃的探索性原型，以减小特定风险，例如：
设计/需求折衷
构件复用
产品可行性或向客户和最终用户进行演示。
证明已建立基线的构架将在适当时间、以合理的成本支持系统需求。
建立支持环境。
为了实现这个主要目标，建立项目的支持环境也同等重要。这包括创建开发案例、创建模板和指南、安装工具。
1.3.2. 核心活动
· 快速确定构架、确认构架并为构架建立基线。
· 根据此阶段获得的新信息改进前景，对推动构架和计划决策的最关键用例建立可靠的了解。
· 为构建阶段创建详细的迭代计划并为其建立基线。
· 改进开发案例，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。
· 改进构架并选择构件。 评估潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。
1.3.3. 里程碑：生命周期构架
生命周期构架里程碑为系统构架建立管理基线，并使项目团队能够在构建阶段调整规模。
精化阶段末是第二个重要的项目里程碑，即生命周期构架里程碑。此时，您检查详细的系统目标和规模、选择的构架以及主要风险的解决方案。
1.3.3.1 评估标准
· 产品前景和需求是稳定的。
· 构架是稳定的。
· 可执行原型表明已经找到了主要的风险元素，并且得到妥善解决。
· 构建阶段的迭代计划足够详细和真实，可以保证工作继续进行。
· 构建阶段的迭代计划由可靠的估算支持。
· 所有客户方人员一致认为，如果在当前构架环境中执行当前计划来开发完整的系统，则当前的前景可以实现。
· 实际的资源耗费与计划的耗费相比是可以接受的。
如果项目无法达到该里程碑，则它可能中途失败或需要进行相当多的重新考虑。
1.3.3.2 提供的文档及模型
|
核心文档及模型（按照重要性排序） |
里程碑状态 |
|
原型 |
已经创建了一个或多个可执行构架原型，以探索关键功能和构架上的重要场景。 |
|
风险列表 |
已经进行了更新和复审。 新的风险可能是构架方面的，主要与处理非功能性需求有关。 |
|
项目专用模板 |
已使用文档模板制作了文档工件。 |
|
工具 |
已经安装了用于支持精化阶段工作的工具。 |
|
软件构架文档 |
编写完成并确定了基线，如果系统是分布式的或必须处理并行问题，则包括构架上重要用例的详细说明（用例视图）、关键机制和设计元素的标识（逻辑视图），以及（部署模型的）进程视图和部署视图的定义。 |
|
设计模型（和所有组成部分） |
制作完成并确定了基线。已经定义了构架方面重要场景的用例实现，并将所需行为分配给了适当的设计元素。 已经确定了构件并充分理解了自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。 |
|
数据模型 |
制作完成并确定了基线。已经确定并复审了主要的数据模型元素（例如重要实体、关系和表）。 |
|
实施模型（以及所有组成工件，包括构件） |
已经创建了最初结构，确定了主要构件并设计了原型。 |
|
前景 |
已经根据此阶段获得的新信息进行了改进，对推动构架和计划决策的最关键用例建立了可靠的了解。 |
|
软件开发计划 |
已经进行了更新和扩展，以便涵盖构建阶段和产品化阶段。 |
|
指南，如设计指南和编程指南。 |
使用指南对工作进行了支持。 |
|
迭代计划 |
已经完成并复审了构建阶段的迭代计划。 |
|
用例模型 |
用例模型（大约完成 80%）- 已经在用例模型调查中确定了所有用例、确定了所有主角并编写了大部分用例说明（需求分析）。 |
|
补充规约 |
已经对包括非功能性需求在内的补充需求进行了记录和复审。 |
|
可选 |
里程碑状态 |
|
商业理由 |
如果构架调查不涵盖变更基本项目假设的问题，则已经对商业理由进行了更新。 |
|
分析模型 |
可能作为正式工件进行了开发；进行了经常但不正式的维护，正演进为设计模型的早期版本。 |
|
培训材料 |
用户手册与其他培训材料。根据用例进行了初步起草。 如果系统具有复杂的用户界面，可能需要培训材料。 |
1.4. 构建阶段
1.4.1. 目标
构建阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。构建阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。从这种意义上说，从先启和精化阶段到构建和产品化阶段，管理上的思维定势经历了从知识产权开发到可部署产品开发的转变。
构建阶段的主要目标包括：
· 通过优化资源和避免不必要的报废和返工，使开发成本降到最低。
· 快速达到足够好的质量
· 快速完成有用的版本（Alpha 版、Beta 版和其他测试发布版）
· 完成所有所需功能的分析、开发和测试。
· 迭代式、递增式地开发随时可以发布到用户群的完整产品。这意味着描述剩余的用例和其他需求，充实设计，完成实施，并测试软件。
· 确定软件、场地和用户是否已经为部署应用程序作好准备。
· 开发团队的工作实现某种程度的并行。 即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现自然的并行（资源允许）。这种并行性可较大幅度地加速开发活动；但同时也增加了资源管理和工作流程同步的复杂程度。如果要实现任何重要的并行，强壮的构架至关重要。
1.4.2. 核心活动
· 资源管理，控制和流程优化
· 完成构件开发并根据已定义的评估标准进行测试
· 根据前景的验收标准对产品发布版进行评估。
1.4.3. 里程碑：最初操作性能
最初操作性能里程碑确定产品是否已经可以部署到 Beta 测试环境。
在最初操作性能里程碑，产品随时可以移交给产品化团队。此时，已开发了所有功能，并完成了所有 Alpha 测试（如果有测试）。除了软件之外，用户手册也已经完成，而且有对当前发布版的说明。
1.4.3.1 评估标准
构建阶段的评估标准涉及到对以下问题的回答：
· 该产品发布版是否足够稳定和成熟，可部署在用户群中？
· 是否已准备好将产品发布到用户群？
· 实际的资源耗费与计划的相比是否仍可以接受？
如果项目无法达到该里程碑，产品化可能要推迟一个发布版。
1.4.3.2 提供的文档及模型
|
核心文档及模型（按照重要性排序） |
里程碑状态 |
|
“系统” |
可执行系统本身随时可以进行“Beta”测试。 |
|
部署计划 |
已开发最初版本、进行了复审并建立了基线。 |
|
实施模型（以及所有组成部分，包括构件） |
对在精化阶段创建的模型进行了扩展；构建阶段末期完成所有构件的创建。 |
|
测试模型（和所有组成部分） |
为验证构建阶段所创建的可执行发布版而设计并开发的测试。 |
|
培训材料 |
用户手册与其他培训材料。根据用例进行了初步起草。 如果系统具有复杂的用户界面，可能需要培训材料。 |
|
迭代计划 |
已经完成并复审了产品化阶段的迭代计划。 |
|
设计模型（和所有组成部分） |
已经用新设计元素进行了更新，这些设计元素是在完成所有需求期间确定的。 |
|
项目专用模板 |
已使用文档模板制作了文档模板。 |
|
工具 |
已经安装了用于支持构建阶段工作的工具。 |
|
数据模型 |
已经用支持持续实施所需的所有元素（例如，表、索引、对象关系型映射等）进行了更新 |
|
可选 |
里程碑状态 |
|
补充规约 |
已经用构建阶段发现的新需求（如果有）进行了更新。 |
|
用例模型（主角，用例） |
已经用构建阶段发现的新用例（如果有）进行了更新。 |
1.5. 产品化阶段
1.5.1. 目标
产品化阶段的重点是确保最终用户可以使用软件。产品化阶段可跨越几个迭代，包括测试处于发布准备中的产品和基于用户反馈进行较小的调整。在生命周期中的该点处，用户反馈应主要侧重于调整产品、配置、安装和可用性问题，所有较大的结构上的问题应该在项目生命周期的早期阶段就已得到解决。
在产品化阶段生命周期结束时，目标应该已经实现，项目应处于将结束的状态。某些情况下，当前生命周期的结束可能是同一产品另一生命周期的开始，从而导致产生产品的下一代或下一版本。对于其他项目，产品化阶段结束时可能就将文档与模型完全交付给第三方，第三方负责已交付系统的操作、维护和扩展。
根据产品的种类，产品化阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。
产品化阶段的迭代期间所进行的活动取决于目标。例如，在进行调试时，实施和测试通常就足够了。 但是，如果要添加新功能，迭代类似于构建阶段中的迭代，需要进行分析设计。
当基线已经足够完善，可以部署到最终用户领域中时，则进入产品化阶段。通常，这要求系统的某个可用部分已经达到了可接受的质量级别并完成用户文档，从而向用户的转移可以为所有方面都带来积极的结果。
产品化阶段的主要目标是：
· 进行 Beta 测试，按用户的期望确认新系统
· Beta 测试和相对于正在替换的遗留系统的并行操作
· 转换操作数据库
· 培训用户和维护人员
· 市场营销、进行分发和向销售人员进行新产品介绍
· 与部署相关的工程，例如接入、商业包装和生产、销售介绍、现场人员培训
· 调整活动，如进行调试、性能或可用性的增强
· 根据产品的完整前景和验收标准，对部署基线进行的评估
· 实现用户的自我支持能力
· 在用户之间达成共识，即部署基线已完成
· 在用户之间达成共识，即部署基线与前景的评估标准一致
1.5.2. 核心活动
· 执行部署计划
· 对最终用户支持材料定稿
· 在开发现场测试可交付产品
· 制作产品发布版
· 获得用户反馈
· 基于反馈调整产品
· 使最终用户可以使用产品
1.5.3. 里程碑：产品发布
产品化阶段末是第四个重要的项目里程碑，即产品发布里程碑。此时，您确定是否达到目标，以及是否应该开始另一个开发周期。有时候，该里程碑可能与下一周期的先启阶段末重合。产品发布里程碑是项目验收复审成功完成的结果。
1.5.3.1 评估标准
产品化阶段的主要评估标准涉及到对以下问题的回答：
· 用户是否满意？
· 实际的资源耗费与计划的耗费相比是否可以接受？
在产品发布里程碑处，发布后的维护周期同时开始。这涉及开始一个新的周期，或某个其他的维护发布版。
1.5.3.2 提供的文档及模型
|
核心文档及模型（按照重要性排序） |
里程碑状态 |
|
产品工作版本 |
已按照产品需求完成。客户应该可以使用最终产品。 |
|
发布说明 |
完成。 |
|
安装产品与模型 |
完成。 |
|
培训材料 |
完成，以确保客户自己可以使用和维护产品。 |
|
最终用户支持材料 |
完成，以确保客户自己可以使用和维护产品。 |
|
可选 |
里程碑状态 |
|
测试模型 |
在客户想要进行现场测试的情况下，可以提供测试模型。 |
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
