文/刘庆生

摘要：在计算机软件开发中，需求变更和项目管理贯穿了项目的整个生命周期，航运市场和管理模式变化造成应用系统频繁修改，产生了开发成本大和开发周期长等问题。分析需求变更产生的原因和其必然性，除加强需求管理措施外，从内贸航运业务特点和本质出发，设计出能包容整个业务需求的技术框架，经系统组件的复用、组合和集成来满足业务中不同的需求，从基础上保障系统的可维护性与扩展性，减低了需求变更对系统造成的影响。

【关键词】需求变更 软件工程 组件

1 引言

需求变更是软件项目一个突出的特点，也是软件项目最为普遍的一个特性，频繁而无管理的需求变更非常容易导致复杂、无形的软件在多变的情况下失控，加剧软件开发过程中的不稳定。随着对业务深入了解，用户的需求才逐渐变得明确。同样、在软件开发过程中需求的变更会给开发带来不确定性，所以必须接受“需求会变动”这个事实，做好需求变更管理工作。

2 需求变更的分析和影响

2.1 需求变更的原因和必然性

2.1.1 开发者对业务具体的操作和流程掌握不够需求分析人员往往由技术人员担当，在业务上只能做到收集，进行业务归纳工作比较困难，开发者对用户需求的理解与用户本来愿望有差异，以至于项目初期就埋下了错误的种子，可以说项目开始就存在需求变更，不管是用户还是开发技术人员，都是随着项目的进展而不断对业务、对软件系统的加深理解，同时伴随着需求变更的到来。

2.1.2 开发者设计的应用架构设计灵活性不够设计者在没有全面、系统的对业务需求了解的情况下，很难全盘考虑设计架构，尤其是有些需求分析人员没有行业经验，不能将各类需求举一反三，进行归纳合并，往往采取满足具体单个岗位的需求来设计，设计出的软件个性化太强而没有灵活性，这样势必造成软件的复用性差，在业务或操作模式稍微调整的情况下软件就无法支持，并按需求变更来处理。

2.1.3 用户对软件需求的描述不精确

用户对自身的业务逻辑不太明确，特别是处于激烈竞争情况下的用户要随着市场情况的变化，随时调整自己的运作来适应这种变化，会对相关软件产品提出更多的变更要求[2]，往往期望通过业务管理的信息化来规范现有业务操作流程，软件开发中没有现成的业务流程可供参考。

2.1.4 用户对开发方依赖程度太大

现在用户视野相对开阔，认为开发人员设计出的程序应该象标准软件产品，对定制开发没有做好思想上的准备，没有思考业务上需要做什么，怎么做会更好，认为系统开发是技术人员的事，一些基本功能开发人员应该想到而不需用户具体提出，造成用户在项目工作中的参与投入不足。

2.2 需求变更影响的分析

需求变更是当今软件危机原因之一，因需求变更造成程序维护工作在整个计算机系统中的比重越来越大，甚至许多个体化软件变得无法维护；大型软件的开发成本急剧上升，质量得不到保证；据统计、软件失败原因中的“不完整的需求”、“缺少用户的参与”和“改变需求和规格说明”分别占13.1%、12.4% 和8.7%。

2.2.1 需求变更的分析

在项目过程中的不同时间点，需求变更造成的影响不同。如图1 所示，原计划是6 个月内项目上线，因为试运行中发现10% 的需求变更，此时需要花费2 个月进行设计分析和开发，项目第一次延期2 个月；正式上线后发现3% 的需求需要变更，之后在3-6 个月内又有需求变更和一些操作方便性、系统性能等非功能需求的完善等需要修改程序，至此、项目延期将近6 个月；而此延期的6 个月内的实际需求只占整个需求的16%，可见后期的需求变更工作效率低且影响大。

2.2.2 需求变更的影响

需求变更会影响项目无法按时上线验收而往后拖延，如开发方有多个项目在时间衔接上造成影响，对用户方来说，原来业务上的计划安排被打乱，有时涉及到外部工作安排更是损坏公司的形象，造成工作上的被动。从内部看，多次延期使员工及领导对项目期望降低、信心及参与热情减弱，甚至怀疑项目组是否有能力完成整个项目，更换人员、控制后期投资甚至停止项目等都有可能发生。

3 应对需求变更的策略及方法

3.1 传统软件工程管理模式的局限

在国内企业的业务应用系统中，采用传统的软件工程管理模式应对需求变更有一定的局限性，有很多的前提条件是目前企业实际情况所达不到。有些大型项目虽然按照软件工程所要求的变更基线来控制需求变更，但在实际操作中效果并不理想，虽有多种因素造成需求变更，但最主要是项目从开始时，不管是开发人员还是用户都不能明确说明真正的需求，只能在项目过程中逐渐调整；作为前车之鉴，有必要采取一种新的项目设计思想和管理模式，对项目中需求变更要有充分认识，在此基础上主动、积极完成整个项目的开发实施工作。

3.2 正确面对需求变更需求变更的解决方

法有很多文章介绍，基本上是按照流程，需求范围确定（基线设定），控制需求变更，通过软件工程中“带有反馈的瀑布模型”、“原型模型" 和" 增量和迭代模型”等方式，这在一定范围内减少一些后期需求变更，但不能从根本上解决问题，对于没有完整业务操作流程的公司，测试期间用户根据各自对业务的理解来做，这样、后期的需求变更数量仍然很大。

3.3 系统组件是解决需求变更的基础

为了应对经常性的需求变更，关键是建立航运行业统一的应用架构体系，增强系统的可扩充性、健壮性和可靠性；通过技术设计手段来满足反复出现的需求变更，避免或减少需求变更所带来的影响。图2 是建立应用架构顺序图，其关键点就是以行业本质和特点来作为应用架构设计的导向，区别于传统需求分析中以用户需求为导向；将可能发生需求变更的情况均考虑在所设计的应用架构体系中，这在一定程度上规避了用户需求上的变更所带来的影响。

（1）“行业本质”是指物流运输行业所特有的操作规则，这种规则描述了运输中大家普遍遵循的通用业务环节和流程，这需要又有经验的行业专家进行提炼、归纳，最后合并成“询报价”、“订舱”、“运输”、“结算”等几个主要通用模块，在此模块基础上进行数据结构的搭建、分解模块至最小单元、制定业务规划和流程。

（2）根据数据结构和业务最小单元生成应用框架的构件，组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访问逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑，达到适应变化的松偶合、高内聚的原则。由于‘通用模块’基本上是按全集设计，能覆盖具体业务调研中的需求，也就保证了今后用户的需求变更基本都能在‘通用模块’范围之内，保证了结构主体不改变。

（3）按照业务操作岗位，通过配置最小单元生成功能点，提供给用户具体操作。

3.4 遵照软件工程的管理方式

3.4.1 组建业务流程设计小组

流程设计小组的是保证业务应用架构顺利搭建的关键，用户或开发方有资深、熟悉本行业需求分析的人员均可加入，实在没有可在系统内或外部聘请有经验的行业专家，对整个应用架构把关和审核。

3.4.2 建立需求变更的流程根据需求变更级别不同走不同的审批流程，对于不影响项目计划的微小调整，需要通过实施人员和关键用户审批；影响项目计划的一般调整，但不影响项目里程碑，必须通过项目经理或者业务负责人审批；影响项目里程碑的重大调整，必须通过项目领导和项目管理委员会审批；所有的项目变更需要进行汇总后汇报给项目领导和项目管理委员会。

3.4.3 集成及用户测试：安排专职、懂业务的人员进行软件功能测试，需求变更尽量在测试期间发现和解决。

4 总结

通过采用以上介绍的开发设计方式，虽然其开发成本略高些，但在后续需求变更上花费的代价较小，大部分需求变更通过框架中配置即可满足，在实际使用中效果不错，保证了项目在可控制范围。采纳系统组件方式来开发设计项目的前提条件是，需要有对物流航运业操作、管理全面熟悉和有经验的专家，具有对业务分析、提升和归纳的能力，同时对计算机应用结构有相当的了解，这样才能保证做出的方案可行，并覆盖一般物流航运企业的需求。

参考文献

[1] 张晗澍. 浅析需求变更与缺陷变更[J].电脑知识与技术,2010.

[2] 李东旭, 雷相波. 试谈软件开发中需求变更的管理[J]. 电脑编程技巧与维护,2011.

作者单位

中国外运阳光速航运输有限公司 上海市200001