|
|
知识路径： > 电子商务系统程序设计基础 > 电子商务系统规划 > 电子商务应用系统的总体规划 > 电子商务应用系统的生命周期和开发模型 >
|
被考次数：6次
被考频率：中频率
总体答错率：46%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：2个
|
|
|
|
|
电子商务应用系统开发模型是描述系统开发过程中各种活动如何执行的模型。系统生命周期模型确立了开发和演绎中各阶段的次序限制以及各阶段或机动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。常见的生命周期模型有如下5个模型。
|
|
|
|
|
|
瀑布模型是将软件生命周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。
|
|
|
|
瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
|
|
|
|
但是，瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
|
|
|
|
快速原型模型（Rapid Prototype Model）
|
|
|
|
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。
|
|
|
|
第二步则在第一步的基础上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
|
|
|
|
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
|
|
|
|
|
|
增量模型又称演化模型。大量的软件开发实践表明，许多开发项目在开始时对软件需求的认识是模糊的，因此很难一次开发成功。为了减少因对软件需求的了解不够确切而给开发工作带来的风险，可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。增量模型特别适用于对软件需求缺乏准确认识的情况。
|
|
|
|
|
|
对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
|
|
|
|
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。在每个螺旋周期分为如下四个工作步骤。
|
|
|
|
①制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。
|
|
|
|
|
|
|
|
④用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。
|
|
|
|
喷泉模型（Water Fountain Model）
|
|
|
|
喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。
|
|
|
