摘要：优良的软件过程可以为开发高质量的软件提供有效的实践方案，同时对团队的开发效率有着决定性的作用。当前在业界，既有完整的理论，又有较强可操作性的软件过程，而Rational统一过程（RUP）和敏捷过程（AP）使用最为广泛。本文通过对RUP和AP的比较，以《大连大窑湾保税港区海关监管系统》开发中的软件过程控制为例，说明了作者对Rational统一软件过程和敏捷软件过程的一些想法。

关键词：软件过程，Rational统一过程（RUP），敏捷过程（AP）

概述

随着计算机数据处理能力的飞速提高以及用户对软件系统的期望不断提升，软件系统朝着更大更复杂的方向发展，这直接导致软件开发人员需要对软件开发过程的控制能力不断增强，而这种控制能力的强弱直接决定了软件系统的成败。海关业务过程复杂，实时性、稳定性、安全性要求都很高，另外业务流程变化剧烈，因此采用成熟的、适合自己的软件开发过程来保证软件系统的质量是必然的，而这也是做好技术保障工作的必备条件之一。

对于直属海关的技术部门来讲，自身的开发资源是有限的，而开发任务涉及的范围无论是从业务还是技术的角度来讲都是很广的，所以选用合适的软件开发过程对于提升直属关的技术开发能力是非常重要的。

软件过程是从软件项目需求定义开始直至软件使用后期被废止为止，跨越整个软件生存期内的系统开发、运行和维护等全部活动及相关项的总合。下面我们来简单的介绍一下统一过程RUP（Rational Unified Process）和敏捷过程AP（Agile Process）。

Rational统一过程RUP

图 1 RUP示意图[1]

Rational统一过程是IBM Rational的软件过程理论，是一套以文档为主的软件过程理论。它是以架构为中心，用例驱动的采用迭代开发模型的软件过程。

RUP可以用二维坐标来描述（见图1）。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，每个阶段结束于一个主要的里程碑(Major Milestones)。这四个阶段及其阶段性的目标里程碑为[2]：

1)         先启(Inception)：确定项目开发的目标和范围；

2)         精化(Elaboration)：确定系统架构和明确需求；

3)         构建(Construction)：实现剩余的系统功能；

4)         产品化(Transition)：完成软件的产品化工作，将系统移交给客户。

每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。每个阶段根据项目规模来进行多次的迭代，整个系统在开发周期中的不同时期都有新的版本出现。

RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。另外这些工作流是可以根据实际项目情况进行取舍的。

RUP具有以下特点：

1)         RUP将成本风险进一步降低为获得一次增量所需要花费的资源；

2)         RUP进一步降低了项目不能按计划交付使用的风险；

3)         RUP使项目开发更能适应项目需求的变化；

4)         RUP将项目参与者分为分析员、开发人员、测试员、经理、其他角色五类；

5)         RUP以架构为中心，采用面向对象的分析方法，通过用例来驱动整个开发过程；

6)         RUP对系统的架构设计依赖性较强；

7)         对项目的管理者和系统分析人员要求较高；

8)         系统文档编写任务较多。

敏捷过程AP

随着软件过程的发展，越来越多的公司采用了庞大的、重型的过程方法来控制复杂的软件开发过程，这些过程都比较注重计划，而软件开发的流程是一个不断自我适应和调节的过程，所以在实践中和管理上应该注重这种所谓的适应性，而不该去追求事先都可以安排好的所谓的可预见性，因此产生了敏捷开发过程。敏捷开发过程的价值观为[3]：

1)         个体和交互胜过过程和工具；

2)         可以工作的软件胜过面面俱到的文档；

3)         客户合作胜过合同谈判；

4)         响应变化胜过循环计划。

通过上面的价值观也引出了敏捷开发过程的12条原则：

1)         我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意；

2)         即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势；

3)         经常性地交付可以工作地软件，交付地间隔可以从几个星期到几个月，交付地时间间隔越短越好；

4)         在整个项目开发期间，业务人员和开发人员必须天天都在一起工作；

5)         围绕被激励起来地个体来构建项目。给他们提供所需地环境和支持，并且信任他们能够完成工作；

6)         在团队内部，最具有效果并且富有效率地传递信息地方法，就是面对面交流；

7)         工作的软件是首要的进度度量标准；

8)         敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度；

9)         不断的关注优秀的技能和好的设计会增强敏捷能力；

10)     简单——使未完成的工作最大化的艺术——是根本的；

11)     最好的架构、需求和设计出自于自组织的团队；

12)     每隔一定时间、团队会在如何才能更有效地工作方面进行反省，然后相应的对自己的行为进行调整。

通过敏捷软件过程的价值观及原则，我们可以发现AP具有以下特点：

1)         用户角色对整个开发过程有重要作用；

2)         基于适应而非预测去响应变化；

3)         过程、人员、方法服务于产品；

4)         适用范围是有限资源下有限实现约束的项目；

5)         需要对系统进行多次重构；

6)         整个开发过程缺乏全局的计划，对整体不易把握。

我们的软件开发过程

通过对以上两种软件开发过程的一个基本的了解，我们可以发现它们拥有自己的优势及劣势，因此我们希望将其优势进行结合，而尽量避免各自的不足。

同敏捷过程相比RUP过于注重计划、效率不高，但符合现有的管理模式及规章制度，而敏捷过程同RUP相比文档规模小但过于自由化，因此对于我们直属关的技术部门来讲，单纯的采用RUP或AP都不是完全合适。本身在较为传统的RUP过程基础之上引入AP的思想是一个不错的解决方案。并且采用敏捷模式也并不需要将现有的整个管理模式和规章制度完全抛弃，更不需要在拆散现有的团队然后重新组建才能实践新的管理方法。我们可以在现有的管理模式上逐渐加入AP的思想及方法，逐步尝试，使AP的思想逐渐融入到现有的管理模式之中。

结合RUP和AP的特点，我们提出一种迭代加渐进式的开发过程。即将整个项目的开发任务分解为几个不同的迭代阶段来实现。每个迭代周期实现一些业务用例，下一个周期在前一周期的基础上对系统进行开发。每个迭代周期中分为分析、设计、开发、测试等几个阶段。首先，采取这样的开发过程可以避免在项目开始就需要对整个项目指定出全面的开发计划，而在第一个迭代周期中实现风险较高、难度较大的用例可以使整个项目的风险降到最低。第二，整个项目拥有多个整提的里程碑，并且每个迭代周期中又拥有多个里程碑，这样我们可以对整个项目的进度有更加准确的掌握，同时随时来纠正项目的偏差。

《大连大窑湾保税港区海关监管系统》就采用了这种开发过程。《监管平台》的开发时间只有不到三个月的时间。项目从三月下旬开始，项目开始实施时业务流程并没有完全确定，如果按照RUP模式来实施的话，存在极大的风险。所以在项目实施过程中我们将整个实施过程分为启动、细化、构建、部署4个阶段：

第一，在项目启动阶段，我们对业务需求进行第一次全面的分析，明确业务用例，基本确定系统各业务间的关系。在对业务需求第一次分析的基础之上进行架构设计，并对架构设计的关键点和高风险点进行了试验，试验通过后确定了项目的整体架构设计方案。之后对现有的业务用例根据业务优先级和复杂度进行排序，同业务部门协商确定核心业务用例及高风险业务用例为第一个开发迭代阶段的任务。项目启动阶段用时10天。

第二，在项目细化阶段，我们将开发任务分为三个迭代周期。每个迭代周期均按照需求细化，详细设计、编码实现、集成测试4个阶段来实现，而单元测试在整个迭代周期内同步进行。在第一个迭代周期中，我们首先将确定下来的周期内的业务用例进行细化，并根据细化中出现的需求不明确的问题进行总结，并召集业务人员进行集中讨论。在将这一周期内的业务用例细化完成后详细设计和测试用例编写的工作开始同步进行，之后编码实现和单元测试工作同步进行，最后进行周期内的集成测试。第一迭代周期耗时15天，在周期结束时，我们得到了一个实现基本业务流程的可实际运行的系统。面对这个可以实际运行的系统，我们对整个项目的进度有了一个相对准确的了解，同时在这个基线版本的基础上我们进行了第一迭代周期的阶段评审工作。通过阶段评审，我们总结出前面开发过程中出现的问题并对目前项目中存在的一些问题进行了及时的纠正，使得我们对整个项目有了强大的控制力。同样的我们进行了第二、第三迭代周期的工作。整个项目细化阶段耗时50天

第三，在项目构建阶段，我们不仅对前面完成的全部任务进行了完整了集成测试，并进行了系统压力测试、性能测试，更重要的是实现了前期未能确认的业务需求。在系统集成测试通过后邀请业务部门进行了业务测试。在测试过程中确认了业务流程，并对系统的操作方式进行了改进，从而完成了系统上线试运行前的准备工作。在与现场卡口设备集成后，监管系统整体测试非常顺利，在整个联调过程中监管系统表现稳定。项目构建阶段耗时10天

第四，在最后就是项目的部署阶段，经过前期一系列的工作，部署工作已经变得非常顺利。

通过以上4个阶段的工作，我们避免了项目初期需求未能全部确定而影响了项目整体进度、过于乐观的估计项目进度等通常项目容易出现的问题，并且还通过细化阶段的几个增量式的迭代保证了项目的前进方向，保证了项目各个部分的测试充分性，同时使项目的开发阶段的关联性尽可能减弱。

对于《大连大窑湾保税港区海关监管系统》的开发过程中的一些做法，以及RUP及AP的一些思想，我们得出以下几点经验：

1)         项目计划不是一个静态文档，项目小组需要重复的访问计划——更新风险、估算、进度表和其他相关信息；[4]

2)         将项目明确的划分为几个阶段，设定一些里程碑对于把握项目的整体进度是非常有效的；

3)         不要等到业务流程完全确定下来才开始项目的实施，期望业务流程一次就完全确定下来是不现实的；

4)         项目实施过程中很多工作是可以同步进行的，这样能有效的缩短项目的整体开发时间；

5)         文档是必须的，业务流程及设计思想等重要文档是团队成员的工作的方向，尤其不要忽略会议纪要；

6)         注重整体架构的设计，即使是AP倡导的重构也需要有一个良好的设计来保证；

7)         经常性地交付可以工作地软件可以保证整个项目的前进方向得到保证，前一周期的工作就是下一周期工作的原型；

8)         用例驱动的开发过程能够更有效的保证业务流程的正确性，而用例的优先级也可以降低项目的风险；

9)         重视团队成员的角色划分，责任可以保证团队工作的顺利开展；

10)     阶段性的需求获取不仅可以最大可能的降低因需求的不确定而影响项目的整体进度，而且有助于提高业务人员的参与积极性及创造性；

以上是笔者对软件开发过程实践中的一些想法，由于水平有限，实际项目经验不够丰富，对于文中的一些不妥和错误之处，恳请各位专家、读者不吝指教和帮助，对此深为感激。

参考文献：

[1].引自IBM官方网站Rational产品文档；

[2].《迭代化软件开发技术》IBM Rational 技术白皮书；

[3].《敏捷软件开发 原则、模式与实践》清华大学出版社，2003，Robert C.Martin著，邓辉译

[4].《软件工程 实践者的研究方法》机械工业出版社，2002，Roger S.Perssman著，梅宏译