【IT168 专稿】

　　“社会公理的建立和验证与科学公理并无很大不同。能经受住考验的便是真理。”——阿尔伯特·爱因斯坦

　　从大型机发展到网络时代，软件项目开始以增量的方式进行交付与部署。大型项目几乎不可能在指定的期限内完成所有的交付或部署。迭代增量的项目管理方式由于可以在部署完成后即时获得收益而得到广泛的应用。这种方式需要项目经理为每一增量做好估计和预算，管理剩余时间与成本的常规更新，并调查所有成本偏差的原因。SOA将为IT业带来全新的敏捷体验。它不是开发路线图，而是一种用各种IT技术执行业务过程的运作方式。这意味着从多应用向基于服务的共享环境的转变。

　　SOA的一个主要内容是角色的定义和价值。业务过程设计师设定方向，系统架构设计师定义关键位置，系统进程设计师定义详细路径，其它角色则将依据这些进行设定。

　　精益是一种设计定时框架（timing framework）和定量因素（quantity factor）或进度框架的生产方法。“精益生产”这一术语源于丰田汽车生产系统，是一种工具、技术和资源利用方式的理念。其核心思想是在过程、项目或企业中消除一切浪费，提高效益。它追求的是一种实现产品最大时间价值和利润的过程框架。

　　SOA是一个迭代增量式的过程，它通过增量式开发和周期检查取得最终结果。在这一过程中，项目经理需要迭代地设计增量，并为每个增量做出估算和预算。“精益原则”可以优化这个过程。

如何有效地进行估算和预算

　　估算是对完成项目或完成第一步所需资源成本的定量评估。预算则是为取得实现项目或初步目标所需资金而制订的计划。

　　任何企业未来规划的重点都是财务价值的评估。财务计划需要多次重复进行，但资本预算只需每年伊始做一次。有效的预算首先决定需要做的和不需要做的，接着便可计算出该版本或增量（项目里程碑）所需的预算。然后进行成本监控与成本差异分析，为下一增量或版本做准备，并进行NPV（净现时价值）、IRR（内部收益率）和投资回收期等效益评估。

迭代增量式开发模式

    管理项目作业，以小块单位的形式进行开发，可以从早期开始并持续获得收益。

• 迭代：本质上是重复相同的过程。
• 迭代计划：由项目团队决定做什么，以及该怎么做。
• 版本/增量：以小块可控单位的方式交付可用功能。
• 版本/增量计划：由客户和利益相关者决定版本增量及后续版本/增量的范围。

    这样一个过程可以让项目根据需求、风险或其它因素及时做出调整。这便于在下一迭代/版本/增量中做出所需的改动。迭代/版本/增量的有效期取决于需要完成的任务内容（所实现的功能）。如果不能准时完成，则可将部分任务转移到下一版本/增量，或更后面的版本/增量。

    每个成本计划计算出各版本/增量的总成本和总直接成本（与项目作业无关的）。因此，随着版本/增量的开发，可对生产潜力、可扩展能力、当前架构配置的可行性，以及架构调整可能造成的影响进行评估（见图1）。每当一个增量/迭代过程结束时做一次评估，并依此对将来的增量/版本进行调整或改进。

应用精益原则

    软件开发的精益原则为增量或版本的部署定义了一个实用的框架。这些原则的主要目的是减少“七种浪费”：

• 生产过剩的浪费
• 等待时间的浪费
• 搬运的浪费
• 加工处理的浪费
• 库存浪费
• 动作浪费
• 不良品或业务的浪费

    在软件开发过程中，精益是一种迭代增量式的生产方式，它提倡各增量/版本要保证所有的作业、知识技能和迭代工作都是为了实现最终的版本目标（见图2）。

SOA的应用方向

    SOA的应用促进了一系列服务的发展。这里，服务是独立的业务功能或过程。

    在SOA中，服务包括联机接口和批处理接口。流程编排机制是指挥这些过程的神经中枢，以命令行的方式调用各种程序/批量循环/接口，然后由一些实用的程序执行或触发数据服务/基础服务，并将数据/信息返回主调用中心。服务编排涉及服务的诸多功能或操作，因此，应该将服务与适量的功能或操作相关联，既不能比最小值小，也不能多于可用的数量。

    进行SOA开发需要一个“过程”和“架构计划”。管理部门需要确定业务需求，决定需要建立的服务、可以重用的服务，以及应该实现的应用。

案例研究

    我们来看一家飞机制造公司“材料管理系统”的SOA案例。

    客观因素

    公司的快速成长导致业务组件的增长。相应地，也导致库存、库存更新、采购、账目计算和会计活动的增长。

    面临的挑战

    这家飞机制造商在本地及全球各单位（子公司）分别实现“大型商务飞机”的模块。然后各单位便开发出不同的“应用软件”，对应不同的业务过程，并使用各自的数据库。因此，发展到一定时期，这家公司便失去对其库存、现货、采购货物数量、账目数据及会计活动等信息的掌控（见图3）。

    解决方案

    我们可以用SOA应用来解决这个问题。SOA可适用于各种业务过程，并显著降低开发成本。这意味着SOA并不是开发路线图，而是一种运用各种IT技术执行业务过程的运作方式。SOA促进产生一种新的“多重应用”方式，而不仅仅是简单重用。它采用单一的过程来指向服务并进行访问。企业需要考虑的有关SOA的主要方面包括：

• 过程对象
• 可伸缩性
• 兼容各种技术
• 可跨系统进行部署

    SOA从根本上改变了以多应用的方式进行操作，而转向基于服务的共享环境（见图4）。

    因此企业在构建SOA项目时必须确定：

    1. 项目策略：

• 项目的利润点在哪？这将决定项目的构成。
• 各部门（管理、业务与IT）之间如何协作以实现资源共享？
• 哪些团队成员负责制定SOA策略并执行？
• 有哪些可供SOA借鉴的实用案例？
• 在需求、部署等方面，各种原则之间如何交互？
• 指引各过程的流程编排机制是什么？
• SOA最重要的组成部分是什么？是“服务”吗？
• 什么是可用于现有系统、Web服务和非Web服务的差异服务？
• 如何进行应用集成？使用企业服务总线吗？
• 哪些平行方向可用于企业资源层（数据源）？
• 有哪些技术可用？
• SOA管理面临哪些挑战？
• SOA真正的优势是什么？

    2. 项目进度相关问题

• 项目的增量/版本模式是什么？
• 各增量/版本的有效期有多久？
• 各增量/版本涉及哪些功能（用例）？
• 各种风险因素都有什么解决方案？
• 万一不能按时完成增量/版本开发任务怎么办？
• 某项功能的实现技术过时了怎么办？
• 项目进行过程中关键人员发生调动怎么办？
• 公司战略方针发生变动怎么办？

    3. 项目估算和预算相关问题

• 哪些是为确定重要架构需求和主要框架而做的成本估算？
• 哪些是为部分或全部目标构建/采购/重用（内部）/重用（外部设备）而做的成本估算？
• 哪些是项目计划或增量/版本计划的成本估算？
• 项目预算方案的内容包括什么？
• 有哪些效益因素？NPV、IRR和ROI是多少？

    建立SOA框架

    第一步：确定方向

    这样，企业便不会忙于编写软件模块，而是建立服务，使用总线集成服务提供的信息并传递给不同的服务使用者（见图5）。

    第二步：实现

    设计可提供查询、更新和搜索引擎资源的门户或网站。

    相关技术涉及：STRUTS、TILES、JFACES和AJAX。

    第三步：业务组件

    确定系统所需的业务组件，建立系统功能需求文档，包括库存、发货、会计、成本计算、账目计算、采购和人力资源。

    相关技术涉及：RequisitePro、DOORS和UML建模工具（例如IBM Rational Rose和ClearCase）。

    第四步：服务流程编排

    先确定现有系统中运行的服务和过程；然后利用现有服务或新服务制定符合业务解决方案的流程；最后为新系统建立过程模型。

    相关的（实现）技术涉及：BPEL、WSDL、XSD、XML和UDDI。

    第五步：业务服务

　　确定可重用的服务，包括库存更新、前年更新、采购需求、总账账目更新、采购文件更新、账目计算请求和员工验证。

    相关技术涉及：XML、WSDL、XML、XSLT、SOAP、UDDI、MQSeries和JDBC。

　　第六步：集成层/总线

　　确定集成层。相关技术涉及：WebSphere、WebLogic和CORBA。

　　第七步：应用服务

　　确定服务注册信息，包括数据服务、遗留服务、遗留服务集成、搜索/打印服务，以及Web服务等。

　　相关的（实现）技术涉及：SQL、ETL、adapters、XML、XMI、SOAP、UDDI、MQSeries、CICS transaction gateway、IMS Connect、ApplinX、Winsurf mainframe access、EntireX、DPL、3270 Bridge、JDBC、XLinker、Artix、FUSE和PL/SQL。

　　第八步：非SOA类服务

　　确定系统中不可重用的服务和独立的服务。

    相关的（实现）技术涉及：SQL、ETL、adapters、XML、XMI、SOAP、UDDI、MQSeries、CICS transaction gateway、IMS Connect、ApplinX、Winsurf mainframe access、EntireX、DPL、3270 Bridge、JDBC、XLinker、Artix、FUSE和PL/SQL。

　　第九步：IT系统

　　确定IT系统，包括数据库、遗留应用、服务器、外部应用、雇员和人事系统。

    相关技术涉及：IBM 3090、AS/400、VSAM、IMS、DB2、RDBMS、JAVA、.NET、SAP、PeopleSoft和COBOL。

　　第十步：治理（配置管理、变更管理）和安全

　　设计有关治理（配置管理、变更管理）和安全的草图。

    相关技术涉及：Tivoli Access Manager、ClearCase和Serena。

增量式的项目规划

    SOA是一个迭代增量式的过程，它通过增量式开发和周期检查获得最终结果。有关迭代增量式SOA开发的主要建议包括：

    在项目整体阶段：

• 列出系统的高层构件
• 列出各构件的组件
• 对各种技术做出评估
• 定义组件的接入点
• 使组件能协调工作以保证服务正常运行

    在促进增量/版本开发功能用例的项目层阶段：

• 列出子系统的组件
• 决定组件的元素
• 决定业务过程的数量与范围
• 验证内部服务与外部服务的活动
• 决定业务服务的数量与范围
• 决定应用服务的数量与范围
• 决定非SOA服务的数量与范围
• 估计数据需求并计算出平均影射影响
• 对技术集成做出评估
• 预测安全性方面可能面临的挑战

    项目团队将以增量式依次交付各个可用或可执行的系统（即整体系统的子系统），并最终完成整个项目。

    各个增量开发团队都应有专业技术人员（业务分析、数据分析、数据建模、架构设计师/开发人员、开发人员/测试人员等），这些技术人员要完全负责增量的交付工作、模块的部署、部署后的维护，以及将模块添加到其它模块等一系列工作。团队应该按照“精益生产方式”，减少浪费，并在交付增量中产生更多的价值。

    这样将产生一个“初始增量”，计划并说明项目目标、项目章程、项目计划、高层需求、架构框架、增量计划、部署方案和基础设施规划。

• 业务团队应该说明其高层业务需求，并依重要性分出优先级。
• 技术团队构建架构框架，并对架构规划中的各个组件做出架构风险评估，然后建立高层非功能需求的文档。

    仍以飞机制造公司的案例来说，项目经理应该根据功能和框架对增量进行规划和优先分级。这项工作的分解结构如下：

• 通过“增量1”迭代（从1到n）解决功能性问题
• 通过“增量1+a” 迭代（从1到n）标志已解决的问题
• 对“增量1”和“增量1+a”做出评估
• 以迭代方式重复“增量1”和“增量1+a”系统（从1到n）
• 用业务测试数据和生产数据验证“增量1”和“增量1+a”运行正常
• 迭代结合“增量1”和“增量1+a”（从1到n）
• 用“增量1+b” 迭代（从1到n）解决存货更新功能
• 用增量“1+c”迭代解决前年更新功能（从1到n）
• 对“增量1+b”和“增量1+c”做出评估
• 以迭代方式重复“增量1+b”和“增量1+c”的评估（从1到n）
• 用业务的测试数据和生产数据验证“增量1+b”和“增量1+c”运行正常
• 迭代结合“增量1+b”和“增量1+c”（从1到n）

    这样，如果在某个交付期限内不能完成所有的功能，便可先交付已测试好的结构和功能，然后可让同一团队开始另一增量的工作，完成剩下的功能（以增量E1代替增量1）。

    同样，如果技术或项目关键人员发生变动，项目经理或团队需要再次审阅相关参数，并对相关工具或资源做出调整。最后，如果公司战略有所变动，则项目经理或团队需要将已完成的功能列表交付到项目部门并等待进一步指示。

    因此，首要目标应该是交付和部署系统的可用部分；然后依次添加可用部分，以完成整个系统的交付。

    项目经理/团队按精益原则增加业务价值和交付系统的可用部分，并通过之前的增量学习经验改善策略，为将来的增量做准备（见图6）。

为迭代增量做预算

    企业财务通过一系列财政指标（ROI、NPV、IRR和投资回收期）做成本估计和利润预算，进而确定项目资金。其中主要标准是支出总额与时间、收入总额与时间。

    因此，在项目开始的时候，面临的第一个挑战便是估计所需资源，并拟定预算方案。为满足上面提到的标准，项目经理必须确定任务构成、列出所需资源，并根据这些资源计算所需资金。

    增量式的估算可减少整体项目框架对增量版本的限制。

    迭代式估算可对当前任务所需资源与资金做出估计，并预测将来可能需要的资源。这种预测通过比较方案之间的差异计算所需的额外资源（即“将来”所需资源和“现有”资源之间的差异）。

    迭代增量式预算是公司治理的工具，它通过成本计划和成本控制管理操作成本。

• 成本计划的目的是进行成本预测并计算目标成本。
• 成本管理的目标是确定整个项目的资金，并对比审核各增量版本如何花费这些资金。

    增量式预算的目的是为增量/版本募集资金并审核资金的应用方式。

    迭代式预算则是为了明确每一次迭代操作的成本，并确定所有成本总和在预算范围内。

    以飞机制造商的材料管理系统这个案例来说，项目经理需要经常为各增量进行估算和预算。

    为初始增量做估算和预算时，第一步是做出实现目标所需的成本估计，确定高层需求，并做出与企业架构方针相符的框架。第二步是确定各增量/版本的作业成本。第三步是确定实现整个项目所必须的各种与作业无关的成本消耗。第四步是为项目章程、增量式的项目进度、项目计划、增量/版本计划、各增量版本的部署方案和基础设施规划做成本估计。第五步是添加当前所有增量/版本成本的价值并做出项目预算。第六步也是最后一步，是计算初始增量版本的成本预算。

    要为增量/版本做估算和预算，首先要对增量/版本的高层需求及这些需求的变化做出估计。然后做框架和由增量/版本引起的框架变化的成本估算。第三步是对详细需求、资本支出（环境、硬件、网络系统和技术）、构件开发成本、资源层成本（数据源）、测试成本、安全计划、变动和配置管理以及部署成本做出估算。第四步是对进行中的活动（比如培训、游学）成本和行政成本做出估算。最后基于增量/版本期限估计计算增量/版本成本预算。

    在为（某个增量）迭代作估算和预算时，第一步是确定增量/版本中的作业及迭代的次数。迭代的次数可能由于增量/版本不同而变化。第二步是评估每次迭代的成本（迭代的作业成本、持续成本和行政成本）。第三步对增长方案中的增长迭代进行评估。第四步是审校每次迭代的成本，确保所有迭代包括增长迭代的总成本在增量/版本成本估算范围之内。最后一步是计算迭代成本的预算。

    另一项常规工作是通过部署在每一增量/版本中的功能评估，列出公司能获得的利益，资产方面、功能方面和财务方面等。这样，项目或项目经理就要考虑到所有增量/版本中的利润因素（净现金流量、投资回报率、净现时价值、内部收益率和投资回收期等）；然后项目经理提交申请并等待审批和资金分配。

　　总之，项目经理要为所有增量/版本（根据功能问题、功能实现）做成本估算、成本预算并考虑利润因素。这有助于项目经理和公司管理人员决定应该选择构建、购买、重用（内部）还是直接使用（外部工具）某个增量/版本。也有助于项目经理用更低的预算规划迭代成本，这样对附加的功能、架构技术和界面窗口进行调整时便无需增加成本消耗。

　　综上，预算的首要目标是各增量/版本使用的资金。预测支出总额和时间，以及收入总额和时间是主要方面。这样公司才能为增量/版本分配资金，项目经理和团队也遵从了根本的精益原则。

提升业务价值

　　作为一个根本原则，精益原则应该可以为客户实现应有的价值，因此项目应该可以实现增量/版本的所有应有功能。如果整个增量（增量1）没有在增量期限内完成，这个增量/版本仍将准时交付。然后项目经理需要设计新的增量（增量E1），并将剩余功能的实现任务交给同一团队来完成。再检查为剩余增量（根据功能性）所作的估算和预算，计算出增量E1的估算和预算。

　　由于精益原则的其它主要方面是开发团队潜力，项目经理和团队也应该尝试提高团队的（增量）工作效率，减少由于整个项目预算的限制给增量成本带来的影响。因此，项目经理和团队需要经常评估当前增量，为剩余增量设计新的增量计划和新的期限（起始日期和结束日期），并做出剩余增量的估算和预算。

　　这就是可在资金范围内执行、并通过交付可用部件最终完成整个系统来提升业务价值的精益生产方式。