物流软件开发过程模型

物流救件开发过程描述了物流软件开发的一组具有时间约束的活动，通常包 括需求分析、设计、编码和测试等活动，物流软件开发过程模型则以模型化的手段 来定义物流软件开发的框架。

一、瀑布模型

瀑布模型(Waterfall Model)首先内Royce提出。该模型由于酷似瀑布而闻名。如图2—l所示，在该模型中，首先确定需求，并接受害户和软件质量保证 (Software Quality Assurance，SQA)小组的验证。然后拟定规格说明，同样通过 验证后，进入计划阶段。瀑布模型中至关重要的一点是只有当一个阶段的文档已 经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强 制性地要求提供规约文档来确保每个阶段都能很好地完成任务。实际上，由于整 个模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。 虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上却有天生的缺陷。

二、快速原型模型

快速原型模型(RaPid Prototype Model)强调系统设计者与终终用户之间自始 至终的通力合作，用比较短的时间完成问题空间定义后，采用一些适当的开发工具 立即建立一个可行的原型，然后交付用户试用，提出修改意见，再采用选代法或增 量法反复倍改、完善产品的功能，形成终终产品。快速原型模型把物流系统开发大 体划分为三个阶段：快速建立一个可使用的系统试用版本；交付用户使用并听取 用户意见，修改系统，再次交给用户试用，再一次修改系统，直到用户完全满意为 止；后面，特定型的原型产品转化为终终产品交给用户。

原型模型根据原型的不同作用，分为三类

[一)探索型原型

探索型原型是把原型用于物流软件开发的需求分析阶段，日的是要弄清用户 的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模 糊，用户与开发者对项目都缺乏经验的情况，通过对原型的开发来明确用户的 需求。

I二]实验型原型

实验型原型主要用于物流软件设计阶段，考核实现方案是否合适，能否实现。 对于一个大型系统，若对设计方案没有把握时，可通过这种原型的开发来证实设计 方案酌正确性。

[三)滇化型原型

演化型原型将原型思想扩展到物沉软件开发的全过程，就是尽早向用户提交 一个原型系统，在得到用户认可后，将原型系统不断扩充演化为终终的物流软件 系统。

快速原型的开发步骤是；

(])快速分析：在分析人员与用户的配合下，迅速确定系统基本需求并开始构 造原型。

(2)构造原型 的系统。

(3)运行原型 充分协调。 通过运行快速原型，发现问题，消除误解，达到开发者与用户的

(4)评价原型：在运行的基础上，评价原型的特件，分析运行效果是否满足用 户的需求，提出全面的修改意见。

(5)修改：根据评价原型的活动结果进行修改，修改过程代替韧始的快速分 析，从而实现原型开发的循环过程。用户与开发者在这种循环过程中不断接近系 统的终终要求。

上述步骤在软件工具的支持下往往是互相交融在一起的，而不再像瀑布模型 那样进行严格的阶段划分、线性推进。 快速原型模型可尽早为用户提供有用的产品，可尽早发现问题，及时纠正错 误。可减少技术和应用风险，缩短开发时间，减少费用且提高生产率。通过实际运 行原型，提供直接评价系统的方法，促使用户主动参与开发活动，可以加强信息反 馈，促进各类人员的协调，减少误解，适应需求变化，从而有效地提高系统的质量。 快速原型的缺点是：缺乏丰富而强有力的软件工具和开发环境，缺乏有效的 管理机制，还未建立起自己的开发标准；对设计开发环境要求较高；在多次重复改 变原型的过程中，程序员会感到厌倦；系统的易变性对测试有一定影响，难以做到 彻底测试，新新文档较为困难。

三、增量模型

增量模型(1ncremental Mndel)不同于瀑布和快速原型模型，它并不试图一次 性地发布完全符合用户需求的软件。相反，终终的产品被划分为几个构件，设计、 开发、发布甚至是需求都按照一个一个构件进行。任何一个阶段，用户都可以获得

 

一个满足部分需求的实际可操作的软件。巾不是像前面介绍的模型，一般需要等 几个月、一年甚至几年才能等到一个产品。 增量模型能够适应用户的变化。变化是每一个成长中的物流企业固有的特 点，改变的要求同时也是软件开发的一部分。从企业的财务观点来看，增量模型使 得他们不需要一次性投人大量的资金。如果在开发的过程中发现问题，企业也可 以及时地撤走资金。

增量模型同样也会出现问题。其中的一个难点就是每一个新发布的构件必须 能够平滑地集成到已经存在的系统中，而不会破坏已经存在的东西。从这个角度 来讲，一个增量模型下的设计往往需要比瀑布模型非常复杂的设计。因为瀑布模 型一次性地考虑所有问题，它能够提前看到设计、实现中的所有问题(在它自己的 范围之内)。既然问题已经全部提出，就能够相对容易地解决问题。而增量模型则 不同，在构建当前的构件时，开发人员不会去考虑以后的构件。所以，以后的构件 可能需要当前构件不可预料的支持，它也可能以不可预料的方式集成到当前的系 统之中。

四、螺旋模型

螺旋模型(spiralModel)是在瀑布模型和快速原型模型的基础上，加入两者所 忽略的风险分析，建立的一种软件开发模型。如图2—2所示，沿螺旋顺时针方向 依次表达了4个方面的活动。

(1)制订计划：确定软件目标，选定实施方案，弄清项目开发的约束条件。

(2)风险分析：分析所选方案，考虑如何识别和消除风险。

(3)实施工程：实施软件开发。

(4)客户评估：评价开发工作和工作产品，提出修改建议。

在螺旋模型中，物流软件项目风险的大小作为指引软件过程的一个重要因素， 引入这一概念有对能使得物流软件开发被看作一种元模型，因为它能包容任何一 个物流开发过程模型。螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之 前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施 之后，才开始计划下一阶段的开发工作。否则，项目就很可能被取消。螺旋模型是 全生命周期的，即整个生命周期都适用的，对从事物流企业软件运营和维护的人都 可以使用。

---