当SOA遇到敏捷 带来全新软件交付过程

软件交付过程有赖于结构与过程，SOA与敏捷的结合能否帮助跨越业务与技术间的鸿沟？

　　长期以来，软件的交付过程一直就是一个难题，随着企业内部架构的升级和方案构建方法的更新，这一难题变得更为严重。调查数据显示，有超过80%的软件项目没有按时交付，超过50%的软件项目没有实现所需功能，而所用成本却平均超出预算15%。

　　传统的瀑布方法更加容易出现这些问题。因为在项目早期，这些方法通常很难进行完整的需求采集与归档。其中，许多方法需要在最初计划与设计上进行大量投入，但最后只会发现预先收集的消息和文档随着需求的变化被越来越多地闲置起来。更糟糕的是，由于还要及时更新文档，导致在这上面又浪费许多珍贵的资源。并且，十有八九最后软件项目草草结束，只得到一些与需求不一致的方案，或者与方案不一致的文档，而所用投资必然要超出原先的预算。

如何将迭代和敏捷开发方法与面向服务架构（SOA）和模型驱动方法相结合，以解决长久以来在软件交付方面存在的诸多问题呢？

应对软件交付难题需要思维转变

掌握第一手的需求信息

　　要确保所交付的软件满足使用者的需求，就必须在整个过程中考虑到所有的利益相关人。

　　如果只在开始阶段或者后期才去咨询用户团队的意见，最终产品可能很难令人满意。长期以来，项目团队都是通过尝试在最低的层次上定义需求来降低这种风险，但事实上，这种方式既费时费力又不友好，通常是软件用户与技术人员合作效率最低的一种方式。

　　另外，大型软件需求说明的读者群很小，其中许多还是非技术人员，对各种奇怪的概念（比如UML图）不是很熟悉。为能在第一时间掌握各种信息，各团队开始转向在整个过程都与用户保持密切联系的计划与交付模式，并尽可能地使用迭代交付的可用软件来验证并记录需求。

“看到才会明白”与迭代过程

　　一般来说，软件项目及其最终的成功都取决于“看到才会明白”的可用性测试。用户团队经常会被要求给出一个方案，或者至少清楚地描述需求以便为开发团队明确开发路线。接下来就是许多的迭代过程——研究、计划、设计、构建、修正、再研究……如此反复。虽然这一套迭代过程很重要，但更关键是要保证用于软件交付的方法与技术能够为这种交付过程做出计划并实施。

既必要又浪费的原型设计

　　到达一定阶段后，团队开始变得灵活，他们可以采用建立原型（prototype）的方式来减少可能出现的问题。这个主意相当不错，它使最终用户团体能够看到一些比较实际的东西，因此减少项目实施后再修正的风险。

虽然原型成为了这种开发方法强有力的使能技术，可以提供需求文档的预览视图，但仍被视为一种资源浪费。实际上，很早以前原型设计就开始被用来提供预览模拟功能。但原型经常缺乏一些关键因素，比如有意义的数据或者合理的执行流程，因此，很少在项目初期以外的阶段继续使用原型。一旦软件开始交付，更新需求一般会在后续的迭代周期中归档、实现，而不是再一次应用到原来的原型中。正因为这个原因，原型的价值只能保留在初期的交付阶段。

结构、方法与模型

　　多年以来，软件产业创造（或再创造）了各种各样组织和管理软件的开发交付过程方式。近期的发展焦点主要集中于基础的软件体系结构再研究，并且以能够嵌入到SOA服务的模块化软件为重点。另一个焦点则是过程，这一趋势推动软件产业走向迭代和敏捷的方法。其中，每种趋势都反映了长期以来软件产业对软件交付“最难取得一致”的两个部分的对策，而最终显露的根本问题正是业务需求与业务驱动技术之间急需填补的空白。一般认为，下述问题是普遍存在的：

早期的结构

　　－ 软件重用率低

　　－ 软件实现过程必然是“静态”的

　　－ 系统通常是“整体式（monolithic）”的

早期的方法

　　－ 软件项目的可预测性低

　　－ 软件交付计划和需求必然是“静态的”

　　－ 软件项目通常是“整体式”的

将SOA与敏捷方法相结合

　　很大程度，SOA正是为解决上述基础架构问题而做的一种尝试。将软件分成小块实现，这使得所有服务都有更大的可能以不同的方式重用，甚至是以设计服务时未考虑到的方式重用（见图1）。这样，大型系统可以分成小的部分实现，而应用程序也从必然的静态转向设置性更强的动态。将软件交付项目分解为较小组成部分的另一个好处是，它使团队成员能够更容易地设计并实现软件的具体部分，而且设计与测试对其它的组成部分没有依赖性。





敏捷方法论

　　方法论的讨论需要对软件项目的构建方式，以及与其它有形产品在生产上的不同有一个理念上的转变。以往，人们认为软件是一种“虚拟的”东西，因此应该采用与实物（比如摩天大楼）相反的流水型设计方式（见图2）。



　　这一方式的缺点在于，软件的底层技术基础是不断变化的，从而会给软件交付过程带来不可预料性。

　　敏捷方法在解决这些基本问题时采用了与SOA类似的方法。首先，这是一种不同的方法，它不会在计划与实施之前尝试描述所有的细微差别和具体细节。然后，它在线型开发实践中引入迭代这一基础单位。之前的线型开发方法在遇到非线型事件时通常会对项目造成毁灭性的负面影响，比如需求变化或者技术发展引起的变化。从根本上讲，这种转变是与SOA相似的。它将项目分成较小部分并按优先分级，在完成整体设计之前把优先级最高的部分作为重点先完成。这使初期需求收集中的浪费降低到最小，并让团队能够集中精力尽早实现可用、并且可验证的软件模块。

　　缺少的环节

　　粗略一看，对于部署SOA并且在交付环境中采用了敏捷方法的企业来说，业务与技术之间似乎已经是无缝连接。然而，虽然空白被填补，其中却还缺少一些很重要的部分，并且这一问题变得越来越明显。

　　虽然SOA和敏捷方法都在向着正确的方向发展，仍然有一系列因素限制着它们取得最终目标的能力：需求文档编制与软件实现方式仍然不完善。这是因为方法与架构虽然都有所改善，但两者之间的联系却并未改变。软件产业的第三次发展浪潮正在进行中，这次发展一定会改善这最后一环，使SOA和敏捷方法能够发挥最大的潜力。

　　声明式软件交付

　　许多人一直尝试着在业务需求与技术实现之间建立一种固定的联系。UML最早便是用来以文档编制的方式创建这种联系，然后根据文档进行一系列相应的构图，直到能够充分描述系统需求。早期的软件项目不仅因为需求变化，也会因为需求完全没有描述出来而受到灾难性的影响。因此，为了解决这一难题而创建的一系列技术与文档实践让团队能够在项目开始前充分地考虑到所有方面的需求。这是软件发展里程中很重要的第一步，但也仅仅是第一步而已。

　　软件建模与需求文档编制管理上的根本问题相对结构与方法来说远没有引起足够的重视，也一直没有很好地解决。不过，在产业逐渐适应了结构和方法向SOA和敏捷的转变之后，它将开始把软件建模和声明式(delcarative)软件交付作为第三种必要的方式来完善交付

过程。

滞后的软件建模将去向何方？

　　软件产业在找到解决软件结构与交付方法的根本问题的办法的同时，它也在积极地更新软件建模以适应当前的SOA和敏捷开发实践。下面是正在解决中的一些主要问题：

UML与典型的、瀑布交付过程的、面向对象的设计技术有很深的渊源
UML最初是一种需求归档方式，而非用来生成软件
主流架构已经从面向对象转向面向服务
主流方法已从瀑布方法转向敏捷方法
有新的需求要利用建模来创建完整的软件方案
统一建模语言（UML）的核心思想尚未做出更新以适应这些转变

　　以下对UML的批评已经持续多年：

语言臃肿。UML常因不必要的庞大和复杂而受到批评。它包含太多多余的或者很少使用的图示和构造。其中UML2.0受到的这类指责要多于UML1.0，因为新版本的修正在“委员会式的设计”方式上做了更多妥协。
学习与采用上的困难。上述问题使学习与应用UML成为一个难题，特别是在管理层强迫缺乏必要技能的工程师使用UML时。
只有代码才能与代码同步。有不同的观点认为，只有可运行的系统才是最重要的，而不是漂亮的模型。
累积阻抗/阻抗失配。和任何其它符号系统一样，UML能更简洁、更有效地描述一个系统。因此，开发人员要尽力寻找能够将UML与编码语言的长处完美结合的最佳方案。如果所用的编码语言无需遵守保守的面向对象的设计方式，这个问题会尤为突出。
试图成为万能语言。UML是一种希望能够与各种实现语言都兼容的通用建模语言。以一个具体的项目为例，设计团队必须限定UML最合适的用途以取得既定的目标。而将UML的使用范围限制到特定领域的方法本身便饱受批评，尚未成形。

　　敏捷方法强调可用、可验证的软件，而不是臃肿的需求过程。这暗示着可用的软件可以成为用户与技术人员之间沟通的桥梁。为达到这个目的，就要尽可能快地交付可用的软件。在软件建模能够成功地融入SOA和敏捷方法之前，必须满足如下几个关键的要求：

让利益相关人参与建模过程
迅速创建可用的原型
原型要可以长期使用而不能被废弃
自我描述与归档
包含面向服务的概念
基于XML并且技术中立
涵盖集成与分布的概念
容易被大众理解

　　如果软件建模能满足以上标准，那么软件产业将可直接通过新方法交付面向服务的软件。这个模型有描述软件需求和生成可用方案的双重作用，使所交付软件的质量更高、迭代周期更短。对建模中曾经面临的技术与方法上的困难进行分析还会获得更多的益处，包括：

同步的需求与实现
更快更频繁的迭代
利益相关人之间的关系更为紧密
更好的可预测性
需求与架构的一致性
提高生产效率
减少浪费
广泛的应用

原型设计的迭代

　　使用软件模型有助于在短的迭代周期内创建可用的软件，使软件需求和实现之间可以有更好的交流。这保证了需求与代码之间不再分离，并使用户能更好地参与软件和服务的交付过程。

　　这种方法使需求、代码和原型间不再有明显的界限，还能最大程度减小保持软件项目同步的传统难题。从软件模型中生成的原型通常包含大部分的软件逻辑、业务规则，并随着项目的进展得到越来越完善的用户体验。这不仅可以加快迭代的频率，还能提高评定的质量，减少与需求相关的交流误解。

　　如果能实现快速的迭代方案，原型设计阶段便不会滞后，并在整个开发周期中得到应用，成为各方利益相关人之间互相交流的强力纽带。（见图3）





XML的广泛应用

　　XML作为一种软件描述语言得到越来越广泛的应用。比如，XML标准被普遍用于描述各种Web服务标准，包括服务终端的定义，在服务执行过程中传输的数据等。业务流程执行语言（BPEL）和其它过程语言都用XML表示服务编排。大多数开发平台使用XML文档说明软件开发的各个方面，包括用户界面流控制、持久规则和部署概念。服务数据模型通常也用XML进行描述。许多工具厂商在XML文档中加入可视化的编辑功能，生成一种类似于可视化开发语言的东西。软件建模本身就是XML文档和可视化XML设计工具结合的产物。这些文档和工具经过适当调整逐渐适应以可视化XML呈现的、标准的程序设计概念。

新的软件交付方式

　　最新的软件交付实践引入更丰富、更成熟的方法、技术和工具来最大化项目的质量和可用性。软件建模将服务的概念直接引入模型中，同时还可记录变化的软件需求，从而将迭代开发与SOA的优点再一次放大，并且能通过组件化与再生产的软件技术提高软件的可预测性和重用性，保证软件交付标准的一致性。基于XML的软件开发的影响越来越大，从数据定义和流程编排直接进入服务和用户界面建模及实现领域。

以上这些趋势都是由简化软件交付过程和继续加强业务与业务驱动技术之间联系这一共同目应运而生。