欢迎来到Doc100.Net免费学习资源知识分享平台!
您的位置:首页 > 程序异常 >

深入了解软件开发瀑布模型

更新时间: 2015-02-24 21:14:31 责任编辑: Author_N9

 

  提到瀑布开发的时候大部分人们可能会联想到尼亚加拉瀑布下要进行房地产开发然后设想一下当您告诉他们实际上瀑布开发是一种包含多个阶段的反复叠代的软件开发模型时他们会多么惊讶这篇文章将为您提供一份关于瀑布模型的简要介绍解释它是什么应当怎样工作以及可能导致项目失败的原因

概述

  瀑布模型其实并不新它在年前后就已经出现了但是大部分开发者对瀑布模型只有一个模糊的概念从本质来讲它是一个软件开发架构开发过程是通过一系列阶段顺序展开的从系统需求分析开始直到产品发布和维护每个阶段都会产生循环反馈因此如果有信息未被覆盖或者发现了问题那么最好返回上一个阶段并进行适当的修改开发进程从一个阶段流动到下一个阶段这也是瀑布开发名称的由来

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

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

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

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

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

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

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

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

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

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

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

优势

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

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

缺点

  除了看上去很明显的这些优势瀑布模型近来也受到了很多批评最突出的一点是围绕需求分析的通常客户一开始并不知道他们需要的是什么而是在整个项目进程中通过双向交互不断明确的而瀑布模型是强调捕获需求和设计的但在这种情况下现实世界的反复无偿就显得瀑布模型有些不切实际了

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

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

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

客户需求

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

上一篇:上一篇
下一篇:下一篇

 

随机推荐程序问答结果

 

 

如对文章有任何疑问请提交到问题反馈,或者您对内容不满意,请您反馈给我们DOC100.NET论坛发贴求解。
DOC100.NET资源网,机器学习分类整理更新日期::2015-02-24 21:14:31
如需转载,请注明文章出处和来源网址:http://www.doc100.net/bugs/t/1068079/
本文WWW.DOC100.NET DOC100.NET版权所有。