【IT168 专稿】

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

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

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

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

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

    掌握第一手的需求信息

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

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

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

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

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

    既必要又浪费的原型设计

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

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

    结构、方法与模型

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

• 早期的结构

　　－ 软件重用率低
　　－ 软件实现过程必然是“静态”的
　　－ 系统通常是“整体式（monolithic）”的

• 早期的方法

　　－ 软件项目的可预测性低
　　－ 软件交付计划和需求必然是“静态的”
　　－ 软件项目通常是“整体式”的