1. 绪论
优良的软件过程可以为开发高质量的软件提供有效的实践方案。随着软件开发复杂性的日益增强及软件行业规范化管理经验的逐渐积累，通过依托某种软件过程在开发中产生恰当制品、科 学有效地控制开发节奏与步骤，从而合理调配与使用开发资源、满足开发愿景，已经成为提高软件生产率、确保如期按质地提交软件成果的重要途径，而这一观念也正被越来越多的软件开发公司所认同和采用。
2. 软件过程和敏捷建模
经典软件工程理论所阐述的软件过程，特别是瀑布模型，由于其较强的理想化环境条件假设，所以如果在实际软件开发项目中采用，往往会与实际情况产生较大脱节，使得实施效果大打折扣，故而往往只以具有理论参考意义的面孔出现。而当前在业界，既有完整理论，又有较强可操作性的软件过程，则以统一过程（the Unified Process,简称UP）和极限编程（the eXtreme Programming,简称XP）最为令人瞩目。
2.1 统一过程与极限编程及其思想观念
2.1.1 UP与XP的特征
统一过程作为一种重量级的指导性的软件过程，其基本特征体现在用例驱动、以架构为中心、迭代和增量开发等几方面。根据对统一过程生命周期的不同划分方法，统一过程还分为企业统一过程（EUP）、Rational统一过程（RUP）等不同子类型。而极限编程则不同于统一过程，它在本质上属于更为敏捷的一种软件过程，并由一系列简单却互为补充的实践所组成。
2.1.2 统一过程的优势
虽然比较XP而言，UP更为传统一些，其过程控制灵活度也相对较弱，但由于这种软件过程非常适用于复杂、需求多变、开发难度大的情况，同时也可以根据项目特点进行适当裁剪，所以仍然被许多软件企业所广泛采用。特别是，对于一些在软件过程控制方面依据UP原则已经形成较为固定模式、同时又注重以各阶段的指定制品控制开发节奏的公司而言，如何在保持UP基本方法的前提下，提高UP项目开发的敏捷性则是一个非常现实而重要的课题。
2.2 以敏捷建模改造统一过程的可行性
2.1.3 敏捷建模与统一过程在实践中的内在联系
事实上，敏捷建模（Agile Modeling，简称AM）所倡导的一系列实践中有许多做法与UP的实践是不谋而合的，有的还加强或改进了UP的某些实践。比如：
UP和AM都强调“项目关系人积极参与”的重要意义，甚至允许项目关系人参与建模。
UP和AM都强调“用代码验证”、“并行创建多个模型”。即使是UP，在必要情况下也可调整决定同时执行源于不同规程的活动。
UP和AM都遵循“增量建模”的实践，但AM通过减小增量的幅度，改善了UP的迭代实践。
AM“有危害时才更新模型”的实践改进了UP及时同步各阶段不同制品的要求。
AM“使用合适的制品”的实践改进了UP对UML建模制品的过分依赖。
AM“集体所有”的实践改进了UP项目中有关配置管理的观念，通过营造开放、交流的团队文化，使所有项目成员都能访问和修改各自想处理的制品，包括模型和文档。
AM“使用最简单的工具”的实践拓展了UP只注重使用CASE工具的局限。
2.1.4 实践敏捷建模的主要原则
与UP、XP相比，AM本身则是一种基于实践的、不完整的、有序与混乱并存的软件过程。通常，软件的开发可将UP、XP等作为基础软件过程，用AM增强这些更加完整的软件过程。
AM的概念吸收了敏捷开发联盟（Agile Software Development Alliance）所倡导的若干原则（限于篇幅，这些条款将不在文中详述），并形成了自己的一系列原则与实践。纵观AM论坛发起人Scott W. Ambler所提出的涉及AM的11条核心原则和13条核心实践，笔者认为，体现AM精髓的原则主要集中在如下几个方面：
(1）明确最终目标：即软件本身才是应当确保的工作目标；
(2）快速迭代反馈：明确各阶段问题焦点，快速修订前一阶段过程中的制品，并推回后一阶段；
(3）多种模型建模：即要勇于突破传统软件过程所规定的建模工具的约束，根据效果特点采用适用的建模模型描述软件；
(4）简化工作过程：任何阶段都要以最简单的解决方案来达至工作目标，不要追求形式、不要过度构建软件。
虽然按照Ambler的观点，必须完全执行所有11条核心原则和13条核心实践才能算得上是在敏捷建模，但笔者认为，由于AM本身就是一种不完整的软件过程，况且AM本身必定会在行业实践中进一步得到充实，所以可以认为，在目前阶段，实践上面总结出来的四条原则即可基本反映出AM的精髓。
3. 太原同城系统开发中的敏捷建模实践
在上述方针的指导下，可以利用敏捷建模对统一过程施行改造。以下将以山西省太原市人民银行同城票据清算系统v2.0（以下简称“太原同城系统”）为例，说明应用AM原则与实践在改造一个UP开发项目过程中的一些体会。
3.1太原同城清算系统介绍
3.1.1开发背景
太原同城系统是在金融体制改革的形势下，由北京市泰通电子技术公司承担开发的，在太原市辖区范围内建设的一个连接该市各个商业银行和与人民银行清算中心的票据实时清算系统。通过实时处理贷记、借记票据交换业务，可以改变传统的票据手工交换方式，以电子流代替票据流，使资金可即时抵用，为各商业银行提供统一、快捷、安全、可靠的资金清算渠道，也为人民银行提供了监控资金流量与流向的现代化手段。
3.1.2系统体系结构
太原同城系统是一个基于交易中间件、复合平台、多语言联合开发的三层C/S结构系统。其三层架构分别为：
(1）数据层：运行在人行结算中心的数据库服务器上，OS为TurboLinux Enterprise 8.0，DBMS为Oracle9i Enterprise for linux。
(2）中间层：运行在人行结算中心的应用服务器上，OS为TurboLinux Enterprise 8.0，用C++语言实现了核心商业服务，开发工具选用Borland C++BuilderX 1.0 Enterprise。
(3）表示层：运行在各商业银行的PC前端机（SCO UNIX 5.05平台，270台）及人行结算中心的PC前端机（Win2000/RedflagLinux4.0平台，5台）上。商行前端程序用C语言实现；人行前端程序用JAVA语言实现，开发工具选用Borland JBuilder 7 Enterprise。
上述三个层次分别安装了东方通科技公司的消息中间件TongEASY 4.5 for Linux/SCO UNIX/Windows，整个系统的事务处理功能即由它保证。TongEASY作为一个基于三层C/S体系结构的中间件，其构成的交易管理平台提供了交易管理、负载均衡、应用调度等功能。其包含的通讯管理模块还提供了可靠的数据传输、网络监控、流量控制等功能。
3.2太原同城系统开发中的敏捷建模实践
本人作为太原同城系统的项目经理，按照上文所述观点，将敏捷实践中“明确最终目标、快速迭代反馈、多种模型建模、简化工作过程”这四方面的内容与实际开发的过程控制进行了结合。以下是对其中这几方面实践内容的总结。
3.2.1太原同城系统的快速迭代与增量式开发实践
这一实践体现了“快速迭蠢 钡木瘛Ｌ窍低车幕救砑滩捎肦UP。按照Rational公司对UP的定义，软件开发的生命周期被划分为初始、细化、构造、交付四个阶段，每个阶段结束于定义良好的里程碑――即某些关键决策必须做出的时间点。为了更好地控制变更、减少开发风险，太原同城系统的开发遵循了RUP所规定的从一个迭代过程到下一个迭代过程的递增式增长，从而形成了最终系统。具体而言，这些迭代过程包括：
(1）第一次迭代（历时一个半月）：
跨越UP所定义的初始阶段。该次迭代实现的UP规程主要包括：初步业务建模、捕获业务需求、建立开发环境等。通过该次迭代，完成了架构方案的确定，实现了部分子系统中最关键的业务用例的分析设计与编码、测试――比如票据发送、票据接收、票据文件生成等。同时，通过测试比较，项目组明确了系统的体系结构，即：立足于基于消息中间件的三层C/S结构系统。此外，还根据上述体系结构的特点，确定了开发语言与开发工具。值得一提的是，该次迭代的初衷并非单纯针对太原同城系统，但太原同城系统事实上成为了此次迭代过程的第一个受益者。
(2）第二次迭代（历时两个半月）：
跨越了UP所定义的细化阶段和构造阶段。该次迭代实现的UP规程包括业务建模、需求分析、体系结构设计、编码实现，它所包括的数次小的迭代过程分别侧重于分析、设计和编码实现。首先，通过本次迭代，基本完成了对所有概要级别用例、用户级别用例及大部分子功能级别用例的分析，同时，还完成了类设计、基本数据静态结构设计与数据动态流向设计。系统架构的整体搭建也在此阶段完成。之后，在上述架构的基础上实现了相应的编码工作。
(3）第三次迭代（历时两个半月）：
跨越了UP所定义的构造阶段和移交阶段。该次迭代实现的UP规程包括补充业务建模、补充需求分析、补充编码实现、系统测试、运行和支持等。通过该次迭代，完成了对各级别用例的修改、补充，补充完善了各功能模块的代码，完成了系统测试和部署准备。
当然，系统最终迭代次数的变更结果取决于太原同城系统的实际部署效果和部署后用户的意见反馈。
同时，系统在进行某一阶段的建模工作时，还注意尽量避免在该阶段只专注于一个制品的制作。比如，在用例建模阶段，还同时进行了用户界面原型的设计工作；在数据建模阶段，还将设计会议包括进来。
3.2.2太原同城系统的多种模型建模实践
太原同城系统的过程控制实践很注重改造系统启动时组织内部因沿袭UP思维方式而可能存在的不符合AM原则的文化障碍。比如，根据AM“多种模型建模”的精神，太原同城系统的建模过程就没有受限于UML规定的若干建模制品。
虽然UML定义了一系列的建模制品，但很显然，完整创建其定义的所有建模制品是没有必要的。另一方面，UML建模制品至少在分析需求时并不完备，也存在盲点。比如，UML无法满足用户界面建模需求、UML的活动图无法描述一个信息存储的位置信息等等。因此，在太原同城系统的开发中对UML制品根据需要进行了取舍。针对UML建模制品的不足，还补充了其它一些制品，包括一些UML问世之前就存在了的建模制品（如数据流图），甚至包括一些有独创性的建模制品（如数据流向设计）。下面是太原同城系统分析设计过程中一些制品的制作情况描述：
⑴ 编写有效用例，透彻描述和分解需求规格说明书中提出的各项功能需求。
比如，对于“中心日初始化”这一功能而言，我们需要清楚地说明人行结算中心在每个工作日业务开始时，日初始化功能涉及到的主执行者、目标、前置条件、触发条件、主要场景、意外情况处理等细节情况。其有效用例主要部分摘要如下：
“中心日初始化”处理用例
n 主执行者：人行结算中心系统管理员
n 语境中的目标：人行结算中心系统能开始处理税票信息。
文章来源于领测软件测试网 https://www.ltesting.net/