基于RUP的软件过程及应用

1 引言

软件过程（Software Process）是人们建立、维护和进化软件产品整个过程中所有技术活动和管理活动的集合 [1]。目前，软件过程技术是一个非常活跃的研究领域，吸引了大批来自学术界和工业界的专家和学者。从1984年起每年有软件过程国际研讨会 （ISPW），从1991年起开始召开软件过程国际会议（ICSP），每个国家几乎都有自己的软件过程改进网络（SPN）。软件过程技术的研究主要有三个 方向：

（1）软件过程分析和建模。软件过程建模方法是软件过程技术的起点，其中形式化半形式化建模方法有基于规则的，基于过程程序的等等。过程分析和过程建模对于保证过程定义的质量、建立全面和灵活的过程体系具有重要的作用。
　　（2）软件过程支持。软件过程支持主要是指研究和开发支持软件过程活动的CASE工具，过程支撑工具作为一种技术基础设施能够很好地支持、管理并规范化软件过程。软件过程支持工具主要包括软件过程流程工具、过程文挡工具、评审工具和人员管理工具。
　　（3）软件过程评估和改进。软件过程改进对生产高质量软件产品和提高软件生产率的重要性已被越来越多的软件开发组织所认同。由美国卡耐基·梅隆大学软 件工程研究所（CMU/SEI）提出的软件能力成熟度模型（SW-CMM）除了用于软件过程评估外，还向软件组织提供了指导其进行软件过程管理和软件过程 改进的框架。
　　Rational Unified Process(RUP)是Rational软件公司的一个软件过程产品，是由Objectory过程演化而来的，其初始版本为5。0，先后经历了5。 1、5。1。1、5。5等版本直到最新的Rational Unified Process 2000版本。RUP将项目管理、商业建模、分析与设计等统一起来，贯穿整个开发过程。RUP采用Internet技术，可以增强团队的开发效率，并为所 有成员提供最佳的软件实现方案，它使团队中每个开发人员的见解和思想得到统一，使开发小组成员的沟通更为容易，而这正是任何项目要取得成功的关键因素；它 可以增强开发人员对软件的预见性，最终的好处就是提高了软件质量，并有效缩短了软件从开发到投放市场的时间。RUP过程为软件开发提供了规范性的指南、模 板和范例，可用来开发所有类型的应用。
　　本文的第2节讨论基于RUP的软件过程，第3节给出一个应用实例，第4节是本文的结论。
　　2 基于RUP的软件过程
　　RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段(Inception)、细化阶段(Elaboration)、构建阶段(Construction)和交付阶段(Transition) [2]。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。基于RUP的软件过程模型如图1所示。

从 图1中可以看出，基于RUP的软件过程是一个迭代过程。通过初始、细化、构建和提交四个阶段就是一个开发周期，每次经过这四个阶段就会产生一代软件。除非 产品退役，否则通过重复同样的四个阶段，产品将进化为下一代产品，但每一次的侧重点都将放在不同的阶段上。这些随后的过程称为进化过程。
　　用户需求的变化、运行环境的变更、基础技术方面的变更等都会引发进化过程。通常情况下，进化过程的初始阶段和细化阶段都比较简单，因为基本产品定义和体系结构在前面的开发过程就已经决定。但也有例外情况，例如对软件体系结构(Software Architecture)进行重新定义的进化过程。
　　2.1 初始阶段
　　初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中 所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。初始阶段的实现过程如图2所示。

（1）明确项目规模
　　建立项目的软件规模和边界条件，包括验收标准；了解环境及重要的需求和约束，识别系统的关键用例(Use Case)。
　　（2）评估项目风险
　　软件过程主要关心的是软件开发的已知方面，只能准确描述、计划、分配和评审那些已经知道将要完成的事情。风险管理则主要关心未知方面。在基于RUP的 迭代式软件过程中，很多决策要受风险决定。要达到这个目的，开发者需要详细了解项目所面临的风险，并对如何降低或处理风险有明确的策略。
　　（3）制订项目计划
　　估计整个项目的总体成本、进度和人员配备。综合考虑备选体系结构，评估设计和自制/外购/重用方面的方案，从而估算出成本、进度和资源。在这个过程 中，要通过对一些概念的证实来证明可行性，该证明可采用可模拟需求的模型形式或用于探索高风险区的初始原型。初始阶段的原型设计工作应该限制在确信解决方 案可行就可以了，具体实现留到细化阶段和构建阶段。
　　（4）阶段技术评审
　　初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。在评审过程中，需要考虑项目的规模定义、成本和进 度估算是否适中，估算根据是否可靠？需求是否正确，开发方和用户方对软件需求的理解是否达成一致?是否已经确定所有风险，并且有针对每个风险的规避策略等 问题。
　　2.2 细化阶段
　　细化阶段的任务是分析问题领域，建立健全的体系结构基础，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对体系结构做出决策， 包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。细化阶段的实现过程如图3所示。

（1）确定体系结构
　　确保体系结构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。通过处理体系结构方面重要的场景(Scene)，建立一个已确定基线的体系结构。证明已建立基线的体系结构将在适当时间、以合理的成本支持系统需求。
　　（2）制订构建阶段计划
　　为构建阶段制订详细的过程计划并为其建立基线。
　　（3）建立支持环境
　　建立支持环境，包括开发环境、开发流程、支持构建团队所需的工具和自动化/半自动化支持。
　　（4）选择构件
　　评估现有的(构件库)和潜在构件，充分了解自制/外购/重用决策，以便有把握地确定构建阶段的成本和进度。集成所选构件，并按主要场景进行评估。
　　（5）阶段技术评审
　　评审时，需要检验详细的系统目标和范围、体系结构的选择以及主要风险的解决方案。在技术评审中，需要考虑的问题有：
　　（1）产品需求是否稳定，体系结构是否是稳定的？
　　（2）可执行原型是否表明已经找到了主要的风险元素，并且得到妥善解决？
　　（3）构建阶段的迭代计划是否足够详细和真实， 是否有可靠的估算支持，可以保证工作继续进行？
　　（4）所有与项目有关的人员是否一致认为，如果在当前体系结构环境中执行当前计划来开发完整的系统，则当前的需求可以实现？
　　（5）实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受？
　　2.3 构建阶段
　　在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。
　　构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件作好准备。
　　在构件阶段，开发团队的工作可以实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现并行开发。这种并行性在较大幅度地加速开发进度的同时，也增加了资源管理和工作流程同步的复杂程度。
　　构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行。在评审中，需要考虑的问题有:
　　（1）该产品发布版是否足够稳定和成熟，可安装和运行在用户的实际环境中？
　　（2）所有与项目有关的人员是否已准备好将产品发布给用户？
　　（3）实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受？
　　2.4 交付阶段
　　当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。
　　交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，如进行调试、性能或可用性的增强等。
　　根据产品的种类，交付阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。
　　交付阶段结束时也要进行技术评审，评审目标是否实现，是否应该开始进化过程，用户对交付的产品是否满意等。
　　2.5 技术评审
　　在每个阶段结束时都要进行一次技术评审，以确定在完成该阶段的最终迭代后是否应该让项目进入下一阶段。 技术评审要考虑的主要问题应该主要与项目管理有关，因为主要的技术问题应该已经在该阶段的最终迭代以及随后的活动中得到解决。技术评审的步骤如图4所示。

（1）安排评审会议日程
　　技术评审会议的参加者必须包括外部人员（用户代表和领域专家）、项目的管理团队（项目经理以及项目团队各功能区域的团队负责人）和项目评审委员会。
　　与会者一旦确定，就应安排会议的召开日期和时间，以便为与会者留出充足的准备时间，让他们能够评审有关材料。
　　（2）分发会议材料
　　在会议召开之前，应当将技术评审材料分发给评审人员。要在会议召开之前及早地将这些材料分发出去，让评审人员有充足的时间对其进行审阅。
　　（3）召开评审会议
　　在会议期间， 评审人员主要关注状态评估。在会议结束时，评审人员应作出是否批准的决定。 技术评审会议可能会得到以下结果之一：
　　（Ⅰ）阶段被接受：评审委员会认为项目实现了该阶段的预期目标，可以进入下一阶段。
　　（Ⅱ）有条件接受：评审委员会同意项目可以进入下一阶段，但必须先完成指定的纠正操作。如果发现的问题很少并且不是很重要，则客户可能决定在项目团队执行某些纠正操作的同时有条件地接受该产品。在这种情况下， 项目经理需要根据问题的重要性，或选择开始新的迭代，以处理所出现的问题，或只是通过延长最终迭代来处理问题，二者的差异在于所需的计划工作量。
　　（Ⅲ）阶段不被接受：项目没有实现该阶段的预期目标，项目经理就可能必须开始另一次迭代，甚至项目经理无法决定对问题的解决方案，而需要由有关人员根据合同重新确定项目规模或终止项目。
　　（4）记录会议决定
　　在会议结束时应完成评审记录，其中包括重要的讨论或活动以及评审的结果。如果结果是"阶段不被接受"，则应暂时安排一次后续复审。
　　3 应用实例
　　在为某水电厂开发的综合信息管理系统中，我们全面采用了基于RUP的软件过程。水电厂综合管理信息系统是一个大型信息管理系统，其中包含运行管理、设 备管理、安全管理、图形开票、生产技术管理、行政管理、人事管理、技术台帐管理、班组建设、学习培训、系统维护等十多个模块。不仅如此，系统还要与现有的 某些监控设备接口，从中获取数据。系统能对水电厂实行全面的运行管理，能及时对系统的信息作统计分析处理，能给管理者提供及时准确的数据，对水电厂的运行 决策提供必要的依据。
　　在项目的初始阶段，我们主要建立项目的软件规模和边界条件，明确用户的需求，形成规格说明书，作为验收标准。同时，估计了整个项目的总体成本和进度， 评估了潜在的风险，作出了具有20%资源预留的项目计划。最后，根据客户要求，我们选择了Rational Rose 2000作为分析和建模工具、Project 2000作为项目管理工具。系统开发工具采用visual Studio 6。0，后台数据库管理系统采用MS SQL Server 7。0。
　　在项目的细化阶段，我们根据实际需求，选择了B/S和C/S混合的异构软件体系结构。对一些关键性的算法，制作了探索型的原型。并在此基础上，为构建 阶段制订了详细的迭代计划。在构件的选择方面，我们决定主要采用已有构件（我们曾经开发过变电站综合管理信息系统），对构件库中没有的构件，则重新开发。
　　在项目的构建阶段，我们的主要任务是完成新构件的开发和测试，集成所有构件，进行集成测试。在这一阶段，我们采用并行开发方式，大大地提高了开发效率。
　　在项目的交付阶段，我们把经过集成测试的软件制作安装盘，安装在水电厂，接受实际环境的测试。然后对有关用户和维护人员进行培训和指导。
　　在以上各阶段结束时，我们都进行了阶段技术评审。在评审中，我们不但按要求邀请了客户代表，还邀请了第三方专家参与评审。
　　由于全面采用了基于RUP的软件过程，规范了管理和开发流程，有效地控制了资源，该项目在没有使用预留资源的情况下顺利完成。在系统运行期间，根据水 电厂的要求和我单位的商业战略，我们又对该软件进行了三次进化过程，最终由软件项目过渡到一个产品。现在，该软件产品已经在全国的多个水电站使用，用户反 映良好。
　　4 结论
　　RUP在迭代的开发过程、需求管理、基于构件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。
　　本文讨论了基于RUP的软件过程，并把该过程应用于水电厂综合管理信息系统的开发。与传统的软件过程相比较，基于RUP的软件过程可以降低产品风险，规范管理和开发流程，有效地控制资源，提高开发效率。