您好,欢迎访问三七文档
瀑布模型WaterfallModel一、瀑布模型(Waterfallmodel)1.什么是瀑布模型?2.瀑布模型核心思想3.存在的问题二、生命周期的划分1.各个阶段的说明2.瀑布模型的四个特点3.适用场合三、瀑布模型的优缺点1.瀑布模型有以下优点2.瀑布模型有以下缺点四、瀑布模型的客户需求什么是瀑布模型?最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。直到80年代早期,它一直是唯一被广泛采用的软件开发模型。该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。瀑布模型的核心思想瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。瀑布模型的核心思想存在的问题(1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;(2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;(3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。生命周期划分各个阶段的说明1.需求分析:虽然是第一步,但是这一步至关重要,因为它包含了获取客户需求与定义的信息,以及对需要解决的问题所能达到的最清晰的描述。分析包含了理解客户的商业环境与约束,产品必需实现的功能,产品必需达到的性能水平,以及必需实现兼容的外部系统。在这一阶段所使用的技术包括采访客户、使用案例和软件特色的“购物清单”。分析阶段的结果通常是一份正式的需求说明书,这也是下一阶段的起始信息资料。各个阶段的说明2.设计:这一步包括了“定义硬件和软件架构、组件、模块、界面和数据等来满足指定的需求(Wikipedia)。”它包括了硬件和软件架构的定义,确定性能和安全参数,设计数据存储容器和限制,选择集成开发环境(IDE)和编程语言,并指定异常处理、资源管理和界面连接性的策略。这一阶段还强调了用户接口的设计,包括与浏览和可用性相关的问题,这一阶段的输出结果是一份或多份设计说明书,这些说明书将在下一阶段使用。各个阶段的说明3.实现:这一步包含了根据设计说明书来构建产品,通常,这一阶段是由开发团队来执行的,开发团队包括了程序员、界面设计师和其他的专家,他们使用的工具包括编译软件、调试软件、解释软件和媒体编辑软件。这一阶段将生成一个或多个产品组件,它们是根据每一条编码标准而编写的,并且经过了调试、测试并进行集成以满足系统架构的需求。对于大型开发团队而言,我建议使用版本控制工具来追踪代码树的变化,这样在出现问题的时候可以还原以前的版本。各个阶段的说明4.测试:在这一阶段,独立的组件和集成后的组件都将进行系统性验证以确保没有错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定义“测试实例”来评估产品是完全实现了需求还是只有部分满足。有三种测试方法可以使用:对独立的代码模块进行单元测试;对集成产品进行系统测试;以及客户参与的验收测试。如果发现了缺陷,将会对问题进行记录并向开发团队反馈以进行修正。在这一阶段,还有产品文档会经过准备、评估并发布,比如用户手册等。各个阶段的说明5.安装:在产品通过测试并且被鉴定为符合需求的产品后,就会进入到安装阶段,这一阶段包括了在客户站点进行系统或产品的安装和使用,这可以通过互联网或者物理媒介进行,通常交付使用的产品都带有正式的版本号,这为今后的产品升级提供了便利。各个阶段的说明6.维护:这一阶段发生在安装之后,包括了对整个系统或某个组件进行修改以改变属性或者提升性能,这些修改可能源于客户的需求变化或者系统使用中没有覆盖到的缺陷,通常,在维护阶段对产品的修改都会被记录下来并产生新的发布版本(称作“维护版本”并伴随升级了的版本号)以确保客户可以从升级中获益。瀑布模型的四个特点:阶段间具有顺序性和依赖性。质量保证:每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。易于组织,易于管理:因为你可以预先完成所有计划。是一种严格线性的、按阶段顺序的、逐步细化的过程模型(开发模式)。适用场合:当有一个稳定的产品定义和很容易被理解的技术解决方案时,纯瀑布模型特别合适。当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上,瀑布模型也特别合适。对于那些容易理解但很复杂的项目,采用纯瀑布模型比较合适,因为可以用顺序方法处理问题。在质量需求高于成本需求和进度需求的时候,它尤为出色。当开发队伍的技术力量比较弱或者缺乏经验时,瀑布模型更为适合。瀑布模型有以下优点:为项目提供了按阶段划分的检查点。当前一阶段完成后,您只需要去关注后续阶段。可在迭代模型中应用瀑布模型。它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。瀑布模型有以下缺点:各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。通过过多的强制完成日期和里程碑来跟踪各个项目阶段。瀑布模型的突出缺点是不适应用户需求的变化。尽管瀑布模型招致了很多批评,但是它对很多类型的项目而言依然是有效的,如果正确使用,可以节省大量的时间和金钱。对于您的项目而言,是否使用这一模型主要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度,对于经常变化的项目而言,瀑布模型毫无价值,对于这种情况,您可以考虑其他的架构来进行项目管理,比如名为螺旋模型(spiralmodel)的方法。瀑布式开发方法适合软件需求非常明确、设计方案确定、编码环境熟悉等所有阶段都有较大把握的软件开发活动。客户需求在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:客户需求(1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;(2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;(3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
本文标题:瀑布模型
链接地址:https://www.777doc.com/doc-5291651 .html