精华内容
参与话题
问答
  • 【软件工程】瀑布模型

    千次阅读 热门讨论 2018-09-16 19:16:22
    瀑布模式  瀑布模型(Waterfall Model),它是一个项目开发架构,它的开发过程是通过设计一系列的阶段顺序展开的,从系统需求分析到产品的发布和维护,一共分为六个基本的阶段。  即:指定计划、需求分析、软件...

    瀑布模型
    这里写图片描述
    瀑布模型(Waterfall Model),它是一个项目开发架构,它的开发过程是通过设计一系列的阶段顺序展开的,从系统需求分析到产品的发布和维护,一共分为六个基本的阶段。
    即:指定计划、需求分析、软件设计、程序编写、软件测试、运行和维护

      每个阶段都会产生循环反馈,这样某个阶段出现问题时,就可以去上个阶段或者更上一个阶段去进行修改。
      ·第一次接触软件工程的开发模型,也听过往后很多的模型跟瀑布模型都有联系,所以对此模型要好好了解了解
      为什么叫做瀑布模型?顾名思义,因为这样的开发过程就像是瀑布一样,水的流向是一样的,都朝向同一个方向,并且只有经过这个过程才可以到下一个过程,就像该模型一样,先做计划,做好计划才可以进行需求分析,做完需求分析才可以进行设计,当然你也可以先设计再去需求分析,不过那样的话就不能叫做瀑布模型了

    定义
      【1】瀑布模式是将软件生存周期的各项活动规定为按固定顺序而连接的若干工作阶段,形如瀑布流水,最终得到软件产品
      【2】是很牛的温斯顿·罗伊斯在1970年提出来的。

    核心思想
      瀑布模型核心思想是按工序将问题简化,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑现实与物理现实分开。

    简单描述
      它是最早出现的软件开发模型,现在介绍一下它的运行过程,其过程是从上一个过程输出的结果作为该项过程的所需对象并作为输入,利用这一输入实施该项过程应完成的任务给出该项过程的工作结果,并把其作为输出对象传给下一个过程。同时评审该过程的实施,如果没有问题,则进行下一个过程;否则,返回前面,或者更前面的过程。
      不过对于那些经常变化的项目而言,瀑布模式毫无价值。

    优点
    【1】提供按阶段划分的检查点
    【2】可在迭代模型中应用瀑布模型

    缺点
    【1】各阶段完全固定,阶段之间产生大量文档,极大地增加了工作量
    【2】因为是线性开发,所以只能在末期看到开发结果,增加了开发风险
    【3】我觉得最突出的就是不灵活,不能适应用户的需求变化

    ·目前对于瀑布模型的了解仅限于能查到的对其的介绍,不过再往后接触的过程中一定会更深层次地对瀑布模型进行分析与理解

    展开全文
  • 一、瀑布模型 1.1什么是瀑布模型 1.2特点 1.3优缺点 1.4客户需求 二、快速原型模型 2.1什么是快速原型模型 2.2优缺点 2.3快速原型模型的思想产生、原理及运用方式 2.4类型 2.5开发步骤 三、增量模型 3.1...

    目录

    一、瀑布模型

    1.1什么是瀑布模型

    1.2特点

    1.3优缺点

    1.4客户需求

    二、快速原型模型

    2.1什么是快速原型模型

    2.2优缺点

    2.3快速原型模型的思想产生、原理及运用方式

    2.4类型

    2.5开发步骤

    三、增量模型

    3.1什么是增量模型

    3.2特点

    3.3优缺点

    3.4作用

    四、螺旋模型

    4.1什么是螺旋模型

    4.2特点

    4.3优缺点

    4.4限制条件


    一、瀑布模型

    1.1什么是瀑布模型

    1970年温斯顿.罗伊斯提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型

    瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落

    瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动

    从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布开发名称的由来

    对于经常变化的项目而言,瀑布模型毫无价值

    1.2特点

    1、阶段间具有顺序性和依赖性

    该阶段具有两重含义

    1. 必须等前一阶段的工作完成后,才能开始后一阶段的工作
    2. 前一阶段的输出文档就是后一阶段的输入文档,因此只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果

    2、推迟实现的观点

    对于规模较大的软件项目来说,往往编码开始的越早,最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题

    瀑布模型在编码之前设置了系统分析与系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现

    清楚的区分逻辑设计与物理设计,尽可能推迟程序的物理实现,是按照瀑布模型开发软件的一条重要的指导思想

    3、质量保证的观点

    为了保证所开发的软件的质量,在瀑布模型的每一个阶段都应坚持两个重要做法

    1. 每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务
    2. 每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误

    传统的瀑布模型过于理想化,实际的瀑布模型是带"反馈环"的。如图所示(图中实线箭头表示开发过程,虚线箭头表示维护过程),当在后面阶段发现前面阶段的错误时,需要沿图中左侧的反馈线返回前面的阶段,修正前面阶段的产品后再回来继续完成后面阶段的任务

    瀑布模型是文档驱动的模型,遵守这个约束可使软件维护变得比较容易一些,从而显著降低软件预算

    1.3优缺点

    优点:

    • 项目提供了按阶段划分的检查点
    • 当前一阶段完成后,您只需要去关注后续阶段
    • 可在迭代模型中应用瀑布模型

    缺点:

    • 不适合需求模糊或需求经常变动的系统
    • 由于开销的逐步升级问题,它不希望存在早期阶段的反馈
    • 在一个系统完成以前,它无法预测一个新系统引入一个机构的影响
    • 用户可能需要较长等待时间来获得一个可供使用的系统,也许会给用户的信任程度带来影响和打击
    • 最终产品往往反映用户的初始需求而不是最终需求

    1.4客户需求

    对项目而言,是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度;对于经常变化的项目而言,瀑布模型毫无价值,可以考虑其他的架构来进行项目管理,比如螺旋模型

    瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险
    3. 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果

    按照瀑布模型的阶段划分,软件测试可以分为单元测试集成测试系统测试

     

    二、快速原型模型

    2.1什么是快速原型模型

    快速原型是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集

    快速原型模型是增量模型的另一种形式,在开发真实系统之前,迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,在该原型的基础上,逐渐完成整个系统的开发工作

    它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护

    2.2优缺点

    优点

    • 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险
    • 适合预先不能确切定义需求的软件系统的开发

    缺点

    • 所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
    • 使用前提是要有一个展示性的产品原型,一定程度上可能会限制开发人员的创新

    2.3快速原型模型的思想产生、原理及运用方式

    1、思想产生

    在需求分析阶段得到完全、一致、准确、合理的需求说明十分困难

    获得一组基本需求说明后,就快速地使其“实现”,通过原型反馈,加深对系统的理解满足用户基本要求,使用户在试用后对需求说明进行补充和精确化,从而获得合理完整、现实可行的需求说明

    再把快速原型思想用到软件开发的其他阶段,向软件开发的全过程扩展

    先用相对少的成本,较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用,以便及早澄清并检验一些主要设计策略,在此基础上再开发实际的软件系统

    2、原理

    利用原型辅助软件开发

    经过简单快速分析快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,最终提高软件质量

    3、运用方式

    由于运用原型的目的和方式不同,在使用原型时也采取不同的策略

    • 抛弃策略:将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的
    • 附加策略:将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略

    采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、可供支持的原型开发工具和技术等,根据实际情况的特点决定

    2.4类型

    在软件开发中,原型是软件的一个早期可运行的版本,它反映最终系统的部分重要特性

    探索型

    这种原型目的是要弄清对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性

    实验型

    这种原型用于大规模开发和实现之前,考核方案是否合适,规格说明是否可靠

    进化型

    这种原型的目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统

    2.5开发步骤

    1、快速分析

    在分析人员与用户密切配合下,迅速确定系统的基本需求,根据原型需要体现的特征描述基本需求以满足开发原型的需要

    2、构造原型

    在快速分析的基础上,根据基本需求说明尽快实现一个可行的系统

    要求具有强有力的软件工具的支持,并忽略最终系统在某些细节上的要求,主要考虑原型系统能够充分反映所要评价的特性

    3、运行原型

    发现问题,消除误解,开发者与用户充分协调

    4、评价原型

    在运行的基础上,考核评价原型的特性,分析运行效果是否满足用户的愿望,纠正过去交互中的误解与分析中的错误,增添新的要求,并满足因环境变化或用户的新想法引起的系统要求变动,提出全面的修改意见

    5、修改

    根据评价原型的活动结果进行修改

    若原型未满足需求说明的要求,说明对需求说明存在不一致的理解或实现方案不够合理,根据明确的要求迅速修改原型

    快速原型模型不带反馈环,软件产品的开发基本上是线性顺序进行的

    快速原型的本质是"快速"。开发人员应尽可能地建造出原型系统,以加速软件开发过程,节约软件开发成本

    原型的用途是获知用户的真正需求,一旦需求确定了,原型将被抛弃

     

    三、增量模型

    3.1什么是增量模型

    增量模型也称渐增模型。使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成,并且能够完成特定的功能

    使用增量模型时,第一个增量构件往往实现软件的基本需求,提供最核心的功能

    把软件产品分解成增量构件时,唯一必须遵守的约束条件是,当把新构件集成到现有构件中时,所形成的产品必须是可测试的

    瀑布模型或快速原型模型目标是一次就把一个满足所有需求的产品提交给用户

    增量模型把整个软件产品分解成许多个增量构件,分批地逐步向用户提交产品

    3.2特点

    把瀑布模型的顺序特征与快速原型法的迭代特征相结合

    将软件看作一系列相互联系的增量,在开发过程的各次迭代中,每次完成其中的一个增量

    风险更大的增量模型

    确定用户需求后就着手拟定第一个构件的规格说明文档,完成后规格说明组转向第二个构件的规格说明文档,同时设计组开始涉及第一个构件

    使用该方法将不同的构件并行构建,可能加快工程进度,但将冒构建无法集成到一起的风险

    3.3优缺点

    优点

    1. 能在较短的时间内向用户提交可完成部分工作的产品
    2. 将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展
    3. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
    4. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时,还能及时地对实现顺序进行调整

    缺点

    1. 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构
    2. 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性
    3. 如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程

    3.4作用

    1、开发初期的需求定义只是用来确定软件的基本结构,使得开发初期用户只需要对软件需求进行大概的描述;而对于需求的细节性描述,则可以延迟到增量构件开发时进行,以增量构件为单位逐个地进行需求补充。这种方式能够有效适应用户需求的变更

    2、软件系统可以按照增量构件的功能安排开发的优先顺序,并逐个实现和交付使用。不仅有利于用户尽早用上系统,能够更好地适应新的软件环境,而且在以增量方式使用系统的过程中,还能获得对软件系统后续构件的需求经验

    3、软件系统是逐渐扩展的,因此开发者可以通过对诸多构件的开发,逐步积累开发经验。实际上,增量式开发还有利于技术复用,前面构件中设计的算法、采用的技术策略、编写的源码等,都可以应用到后面将要创建的增量构件中去

    4、增量式开发有利于从总体上降低软件项目的技术风险。个别的构件或许不能使用,但一般不会影响到整个系统的正常工作

    5、实际上,在采用增量模型时,具有最高优先权的核心增量构件将会被最先交付,而随着后续构件不断被集成进系统,这个核心构件将会受到最多次数的测试。这意味着软件系统最重要的心脏部分将具有最高的可靠性,这将使得整个软件系统更具健壮性

     

    四、螺旋模型

    4.1什么是螺旋模型

    螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径

    螺旋模型是快速原型模型以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。该模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段,由这4个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。用螺旋模型的软件过程如下

    简化的螺旋模型

    完整的数据模型

     

    图中带箭头的点划线的长度代表当前累计的开发费用,螺旋线的角度值代表开发进度,螺旋线的每个周期对应于一个开发阶段

    图中的四个象限代表了以下活动

    1. 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件
    2. 风险分析:分析评估所选方案,考虑如何识别和消除风险
    3. 实施工程:实施软件开发和验证
    4. 客户评估:评价开发工作,提出修正建议,制定下一步计划

    4.2特点

    螺旋模型在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制,它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险,直到所有的主要风险因素都被确定

    螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应,因此特别适用于庞大、复杂并具有高风险的系统

    4.3优缺点

    优点

    1. 对可选方案和约束条件的强调有利于已有软件的重用,也有助于把软件质量作为软件开发的一个重要目标
    2. 减少了过多测试(浪费资金)或测试不足(产品故障多)所带来的风险
    3. 在螺旋模型中维护只是模型的另一个周期,在维护和开发之间并没有本质区别

    缺点

    1. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失
    2. 过多的迭代次数会增加开发成本,延迟提交时间

    4.4限制条件

    1. 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发
    2. 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目
    3. 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

    一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段

    展开全文
  • 类似于这种项目,采用传统意义上的瀑布模型就非常合适了,如果范围控制和风险控制做的比较好的话,真的如同一个瀑布一样,会“飞流直下三千尺”,直接将项目送到客户的小机上,部署运行,大家欢乐的拿到绩效
    总结一下经常可以见到的系统开发周期模型。
        在过去的几年里,可以很奇葩的碰到类似于“创业项目库”这种需求非常明确,工作量十分可控,对质量要求比较低,业务建模比较easy,功能构成比较少的“面子项目”。类似于这种项目,采用传统意义上的瀑布模型就非常合适了,如果范围控制和风险控制做的比较好的话,真的如同一个瀑布一样,会“飞流直下三千尺”,直接将项目送到客户的小机上,部署运行,大家欢乐的拿到绩效奖金,回家happy去了。
        但是仅仅注重“面子”的项目很难碰到几次,另一方面,即便是“面子型”的项目,也应当极其重视质量环节。项目管理的几个要素:质量,成本,时间,范围。质量是项目最重要的一环,如果丧失了质量,可以说项目产品就变成了无根之树,空中楼阁。所以,加强质量的把控是非常重要的,也需要对每一个阶段进行质量方面的控制,因此,V模型就是这样一种将开发过程与验证过程想对应的一种对称型的结构。
        在项目实践中,用户的需求总是随着项目进展而更加明确,控制用户的需求变得非常的重要。为了让用户能在项目的起始阶段就深入的对自己的需求有一个明确的理解,原型就变得非常的重要,我们经常在开发中看到的LOW-FI的页面原型、其他类似项目的DEMO就算这种类型,用户对将来的产品有了直观的了解。建立在这种基础上的分析开发,会减少很多后面流程中可能出现的风险。在瀑布模型以及V模型当中,在需求分析阶段采用原型化,是目前非常有效甚至是必须要采用的手段。
        现在的软件项目越来越大,同项目可能由相互联系的若干个子系统构成的,这样仅凭开发一个模型或者多个模型是满足不了项目对于多方面的要求,于是就衍生出了螺旋模型,螺旋模型适合于大型的软件的原因是,它更加注重风险的控制,强调风险的识别、风险的分析、以及风险的消除。
        工作的后几年里,经常会按照Sprint(冲刺短跑)为周期的进行开发。这种敏捷的方式,是属于迭代式开发的一种实现。所谓迭代式模型就是在项目的每一个小的阶段中,都会执行一个传统的、完整的串行过程,执行一次就是一次迭代,每次迭代都可能会包含需求分析、设计、编码、测试等其中的全部或者部分活动。
        这样就对软件的四种开发模型有了简单的了解:瀑布模型,V模型,原型化模型、螺旋模型、迭代模型。    


        下面对几个开发模型,结合理论逐一分析。
        1.迭代模型
        迭代模型,摒弃了传统的需求分析,设计,编码,测试的流程,而是将整个生命周期变成若干个冲刺(Sprint)阶段,而每一个阶段都是由以上若干或者全部传统的流程组成,在每一个阶段中,都会包含下面四个阶段:初始阶段,细化阶段,构建阶段,交付阶段。在初始阶段中,确认本次冲刺的范围,边界,系统选择的架构,计划,以及所需要的资源等信息。在细化阶段中,对问题进行建域,创建开发案例,创建模板以及准备工具等。在构建阶段的主要任务就是完成构建的开发并且进行测试,将完成的构建集成为产品,并且测试所有的功能(CI)。在交付阶段,主要是完成本次冲刺,将软件产品交付给相关的干系人。


        2.螺旋模型
        螺旋模型,尤其重视风险分析阶段,特别适用于庞大并且复杂,非常高风险的项目。通常螺旋模型由四个阶段组成:制定计划、风险分析、实施工程和客户评估。螺旋模型中,发布的第一个模型甚至可能是没有任何产出的,可能仅仅是纸上谈兵的一个目标,但是随着一次次的交付,每一个版本都会朝着固定的目标迈进,最终得到一个更加完善的版本。


        3.原型化模型
        原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。在实际的项目过程中,借助于组织过程资产以及快速模型软件,一般在需求分析的时候,就可以建立一些简单的原型,例如在第一家YH公司中,因为是“行业软件提供商”,所以拥有各个地域的行业解决软件方案,惯用的伎俩就是将其他地市的项目拿到本次项目实施地,作为原型化模型。原型化模型是极具意义的项目实践。


        4.V模型
        V模型从整体上看起来,就是一个V字型的结构,由左右两边组成。左边的下划线分别代表了需求分析、概要设计、详细设计、编码。右边的上划线代表了单元测试、集成测试、系统测试与验收测试。看起来V模型就是一个对称的结构,它的重要意义在于,非常明确的表明了测试过程中存在的不同的级别,并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。


        5.瀑布模型
        瀑布模型是一个特别经典,甚至有点老套的周期模型,一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑,上一个周期的结束需要输出本次活动的工作结果,本次的活动的工作结果将会作为下一个周期的输入。这样,当某一个阶段出现了不可控的问题的时候,就会导致返工,返回到上一个阶段,甚至会延迟下一个阶段。
    展开全文
  • 软件生命周期模型——瀑布模型

    万次阅读 2018-06-09 11:03:49
    模型概述 瀑布模型是一个经典的软件生命周期模型,也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里,在项目生命周期的尽早时间,要确定项目范围及交付此范围所需的时间和成本。 在这个模型里,项目启动...

    模型概述

        瀑布模型是一个经典的软件生命周期模型,也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里,在项目生命周期的尽早时间,要确定项目范围及交付此范围所需的时间和成本。

          在这个模型里,项目启动时,项目团队专注于定义产品和项目的总体范围,然后制定产品(及相关可交付成果)交付计划,接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增范围,则需要重新计划和正式确认。对于经常变化的项目而言,瀑布模型毫无价值。    

          以下情况优先选择这种生命周期:项目需求明确、充分了解拟交付的产品、有厚实的行业实践基础、或者整批一次性交付产品有利于干系人。

          例如开发一个软件项目时,如果采用这个模型的话,一般将软件开发分为可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段,如下图所示。

     

    模型特点:

         瀑布模型中每项开发活动具有以下特点。
        (1)
    从上一项开发活动接受其成果作为本次活动的输入。
        (2)
    利用这一输入,实施本次活动应完成的工作内容。
        (3)
    给出本次活动的工作成果,作为输出传给下一项开发活动。

        (4)对本次活动的实施工作成果进行评审。若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。

    瀑布模型优缺点都很明显:

    优点:有利于大型软件开发过程中人员的组织、管理,有利于软件开发方法和工具的研究,从而提高了大型软件项目开发的质量和效率。

    缺点:开发过程一般不能逆转,否则代价太大;很难严格按该模型进行;很难清楚地给出所有的需求。

    瀑布模型的使用范围:用户的需求非常清楚全面,且在开发过程中没有或很少变化,对软件的应用领域很熟悉;用户的使用环境非常稳定;开发工作对用户参与的要求很低。

    模型阶段

    这一模型存在很多变体,每种只是在阶段名称上略有区别,但是,总体来讲,瀑布开发模型可以分为六个不同的阶段,其定义如下:

      1.需求分析:虽然是第一步,但是这一步至关重要,因为它包含了获取客户需求与定义的信息,以及对需要解决的问题所能达到的最清晰的描述。分析包含了理解客户的商业环境与约束,产品必需实现的功能,产品必需达到的性能水平,以及必需实现兼容的外部系统。

      在这一阶段所使用的技术包括采访客户、使用案例和软件特色的“购物清单”。分析阶段的结果通常是一份正式的需求说明书,这也是下一阶段的起始信息资料。

      2.设计:这一步包括了“定义硬件和软件架构、组件、模块、界面和数据等来满足指定的需求(Wikipedia)。”它包括了硬件和软件架构的定义,确定性能和安全参数,设计数据存储容器和限制,选择集成开发环境(IDE)和编程语言,并指定异常处理、资源管理和界面连接性的策略。

      这一阶段还强调了用户接口的设计,包括与浏览和可用性相关的问题,这一阶段的输出结果是一份或多份设计说明书,这些说明书将在下一阶段使用。

      3.实现:这一步包含了根据设计说明书来构建产品,通常,这一阶段是由开发团队来执行的,开发团队包括了程序员、界面设计师和其他的专家,他们使用的工具包括编译软件、调试软件、解释软件和媒体编辑软件。

      这一阶段将生成一个或多个产品组件,它们是根据每一条编码标准而编写的,并且经过了调试、测试并进行集成以满足系统架构的需求。对于大型开发团队而言,我建议使用版本控制工具来追踪代码树的变化,这样在出现问题的时候可以还原以前的版本。

      4.测试:在这一阶段,独立的组件和集成后的组件都将进行系统性验证以确保没有错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定义“测试实例”来评估产品是完全实现了需求还是只有部分满足。

      有三种测试方法可以使用:对独立的代码模块进行单元测试;对集成产品进行系统测试;以及客户参与的验收测试。如果发现了缺陷,将会对问题进行记录并向开发团队反馈以进行修正。在这一阶段,还有产品文档会经过准备、评估并发布,比如用户手册等。

      5.安装:在产品通过测试并且被鉴定为符合需求的产品后,就会进入到安装阶段,这一阶段包括了在客户站点进行系统或产品的安装和使用,这可以通过互联网或者物理媒介进行,通常交付使用的产品都带有正式的版本号,这为今后的产品升级提供了便利。

      6.维护:这一阶段发生在安装之后,包括了对整个系统或某个组件进行修改以改变属性或者提升性能,这些修改可能源于客户的需求变化或者系统使用中没有覆盖到的缺陷,通常,在维护阶段对产品的修改都会被记录下来并产生新的发布版本(称作“维护版本”并伴随升级了的版本号)以确保客户可以从升级中获益。

    瀑布模型优势

      瀑布模型为软件开发人员提供了众多优势,首先,这个阶段性的软件开发模型规定了以下规则:每个阶段都有指定的起点和终点,过程最终可以被客户和开发者识别(通过使用里程碑),在编写第一行代码之前充分强调了需求和设计,项目开发中涉及到的几乎一切都预先计划,从而便于确定预期的开发成本和开发时间。这避免了时间的浪费以及跳票的风险,同时还可以尽可能地保证实现客户的预期需求。

      提取需求和设计提高了产品质量,因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易很多,毕竟在组件集成之后来追踪特定的错误要复杂很多。最后,因为前两个阶段生成了规范的说明书,当团队成员分散在不同地点的时候,瀑布模型可以帮助实现有效的知识传递。

      瀑布模型缺点

      除了看上去很明显的这些优势,瀑布模型近来也受到了很多批评,最突出的一点是围绕需求分析的,通常客户一开始并不知道他们需要的是什么,而是在整个项目进程中通过双向交互不断明确的;而瀑布模型是强调捕获需求和设计的,但在这种情况下,现实世界的反复无常就显得瀑布模型有些不切实际了。例如,McCracken和Jackson指出,瀑布模型在系统开发之上强加了一种项目管理结构(McCracken and Jackson 1981)。"主张任何一种生命周期方案(即使它具有各种变种)能够适用于所有的系统开发显然是违背现实的,或者由于假定一个过于简陋的生命周期而显得毫无意义。"

        除此以外,即使给定了客户需求,根据这些需求在一定的精确性范围内(瀑布模型所建议的)估算时间和成本是非常困难的。因此,建议在客户需求可以在最初阶段明确的情况下并且相对稳定的项目中使用瀑布模型。

      另外的批评指出瀑布模型还假定设计可以被转换为真实的产品,这往往导致开发者在工作时陷入困境,通常,看上去合理可行的设计方案在现实中往往代价昂贵或者异常艰难,从而需要重新设计,这样就破坏了传统瀑布模型中清晰的阶段界限。

      有些批评还指出瀑布模型暗示了清晰的分工,将参与开发的人员分为“设计师”、“程序员”和“测试员”,但是在现实中,这样的分工对于软件公司而言既不现实也没有效率。

          尽管瀑布模型招致了很多批评,但是它对很多类型的项目而言依然是有效的,如果正确使用,可以节省大量的时间和金钱。对于您的项目而言,是否使用这一模型主要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度,对于经常变化的项目而言,瀑布模型毫无价值,对于这种情况,您可以考虑其他的架构来进行项目管理,比如名为敏捷方法或者螺旋模型(spiralmodel)等。

    展开全文
  • 瀑布模型

    千次阅读 2018-02-25 16:23:16
    规定了各项软件工程活动,以及它们自上而下,互相衔接的固定次序,如同瀑布流水逐级下落。是一种使用广泛,以文档为驱动的模型。 特点:1,阶段间具有顺序性和依赖性。2,推迟实现的观点。3,每个阶段必须完成规定...
  • 开发架构-------瀑布模型

    千次阅读 2018-06-13 13:20:59
    什么是瀑布模型瀑布模型的优缺点什么是瀑布模型 瀑布模型是按工作顺序将问题化简,将功能实现和设计分开,便与分工协作,采用结构化的方式分开。 其生命周期划分为: 软件设计、需求分析和定义、软件实现、软件...
  • 瀑布模型

    2019-12-13 11:43:39
    软件过程是为了获得高质量软件所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤。在完成开发任务时必须进行一些开发活动,并且使用适当的资源,在过程结束时将把输入转化为...生命周期模型规定了把...
  • 瀑布模型

    2020-10-30 15:17:51
    瀑布模型有以下优点 1)为项目提供了按阶段划分的检瀑布模型。 2)当前一阶段完成后,您只需要去关注后续阶段。 3)可在迭代模型中应用瀑布模型。 增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可...
  • 瀑布模型的问题是什么?

    千次阅读 2019-01-22 11:10:44
    瀑布模型是一种相对线性的顺序设计方法,适用于某些工程设计领域。 在软件开发中,它往往是较少迭代和灵活的方法之一,因为进展在很大程度上向下流动,如瀑布,通过概念,启动,分析,设计,构建,测试,部署和维护...
  • 普及篇:什么是瀑布模型

    千次阅读 2017-07-13 14:49:15
    瀑布模型作为最早出现的软件开发模型,提供了软件开发的基本框架,为后续出现的开发模型奠定了基础。从1970年被温斯顿·罗伊斯(Winston Royce)提出后,直到80年代早期,一直是被广泛采用。 这种模式有明确的...
  • 瀑布模型 瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题...
  • 一、瀑布模型  瀑布模型是应用广泛的一种软件开发模型,易于理解和掌握。 瀑布模型是将软件生命周期的各项活动规定为按照固定顺序相连的若干阶段性工作,形如瀑布流水,最终得到软件产品。因形如瀑布,故此得名。...
  • 瀑布模型

    2014-02-27 23:34:26
    瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好...
  • 瀑布模型

    千次阅读 2018-03-18 10:43:01
    瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好...
  • 瀑布模型2. 螺旋模型3. 迭代模型4. 增量模型5. 敏捷模型 0. 软件的生命周期   软件的生命周期是指从软件产品的设想开始到软件不在使用而结束的时间。   软件的生命周期分为6个阶段,即需求分析、计划、设计、...
  • 瀑布模型

    2016-09-22 15:55:40
    链接:http://blog.csdn.net/xianshengsun/article/details/17246967
  • 瀑布模型 每个阶段都有文档产出 文档驱动的有序方法 只能通过文档了解产品,交付产品可能不符合客户的要求 项目周期较短。需求是预知的,软件实现方法是成熟的; 快速原型模型 不带反馈环,线性顺序进行,本质是...
  • 瀑布模型

    2019-09-29 10:53:10
    瀑布模型核心思想 瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采 瀑布模型 用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析...
  • 软件工程--瀑布模型特点详解

    千次阅读 2019-11-11 14:41:19
    瀑布模型 在20世纪80年代之前,瀑布模型一直是唯一被广泛采用的生命周期模型,现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程,基本上可以用瀑布模型来描述。 如下图所示为传统的瀑布...
  • 软件开发模型(SoftwareDevelopmentModel)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计...最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。该模型给出了固定的顺序,将生存期活动从...

空空如也

1 2 3 4 5 ... 20
收藏数 23,377
精华内容 9,350
关键字:

瀑布模型