对瀑布模型的认识及总结-宗燕山

1、号学/<名r£i师间教时导成指完获件x 星一原理、方域易系用2013年课程论文报告设计题目对瀑布模型的认识及总结院系名称 专业（班级）计算机科学与技术系 计算机科学与技术（1）宗燕山（1004013019）张家锐2013年7月对瀑布模型的认识及总结一、核心思想瀑布模型(waterfall model)从本质上讲，瀑布模型是一个软件开发架构，重 复应用。按工序将问题化简，将功能的实现和设计分开，便于分工协作。采用结 构化分析与设计方法，将逻辑实现与物理实现分开，依照软件生命周期自上而下、 相互衔接的顺序，如同瀑布流水逐级向下开发的开发模型。b.瀑布模型(waterfall m6d

2、el)定义阶段可行性研究与计划百覿测试x淅江今漆拄結信堤供维护阶段c、运行维护二、概述在软件开发中典型的开发模型有：瀑布模型(waterfall model)；渐增 模型/演化/送代(incremental model)；原型模型(prototype model)；螺旋 模型(spiral model)；喷泉模型(fountain model)；智能模型(intelligent model) ; 7.混合模型(hybrid model) o瀑布模型其实并不新，它在1970年前后就已经出现了，但是大部分开发者 对瀑布模型只有一个模糊的概念。从本质来讲，它是一个软件开发架构，开发过 程是通过一系列

3、阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每 个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最 好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一 个阶段，这也是瀑布开发名称的由来。这一模型存在很多变体，每种只是在阶段 名称上略有区别，但是，总体来讲，瀑布开发模型可以分为六个不同的阶段，其 定义如下：1. 需求分析：虽然是第一步，但是这一步至关重要，因为它包含了获取客户 需求与定义的信总，以及对需要解决的问题所能达到的最清晰的描述。分析包含 丫理解客户的商业环境与约束，产品必需实现的功能，产品必需达到的性能水平, 以及必需实现兼容的外部系统

4、。在这一阶段所使用的技术包括采访客户、使用案 例和软件特色的“购物清单”。分析阶段的结果通常是一份正式的需求说明书， 这也是下一阶段的起始信息资料。2. 设计：这一步包括了 “定义硬件和软件架构、组件、模块、界面和数据等 来满足指定的需求(wikipedia)。”它包括了硬件和软件架构的定义，确定性能和 安全参数，设计数据存储容器和限制，选择集成开发环境(ide)和编程语言， 并指定异常处理、资源管理和界面连接性的策略。这一阶段还强调了用户接u的 设计，包括与浏览和可用性相关的问题，这一阶段的输出结果是一份或多份设计 说明书，这些说明书将在下一阶段使用。3. 实现：这一步包含了根据设计说明书来

5、构建产品，通常，这一阶段是由开 发团队来执行的，开发团队包括了程序员、界面设计师和其他的专家，他们使用 的工具包括编译软件、调试软件、解释软件和媒体编辑软件。这一阶段将生成一 个或多个产品组件，它们是根据每一条编码标准而编写的，并且经过了调试、测 试并进行集成以满足系统架构的需求。对于大型开发团队而言，我建议使用版本 控制工具来追踪代码树的变化，这样在出现问题的时候可以还原以前的版木。4. 测试：在这一阶段，独立的组件和集成后的组件都将进行系统性验证以确 保没有错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定 义“测试实例”来评估产品是完全实现了需求还是只有部分满足。有三种测试

6、 方法可以使用：对独立的代码模块进行单元测试；对集成产品进行系统测试；以 及客户参与的验收测试。如果发现了缺陷，将会对问题进行记录并向开发闭队反 馈以进行修正。在这一阶段，还有产品文档会经过准备、评估并发布，比如用户 手册等。5. 安装：在产品通过测试并且被鉴定为符合需求的产品后，就会进入到安装 阶段，这一阶段包括了在客户站点进行系统或产品的安装和使用，这可以通过互 联网或者物理媒介进行，通常交付使用的产品都带有正式的版本号，这为今后的 产品升级提供了便利。6. 维护：这一阶段发生在安装之后，包括了对整个系统或某个组件进行修改 以改变属性或者提升性能，这些修改可能源于客户的需求变化或者系统使用

7、中没 有覆盖到的缺陷，通常，在维护阶段对产品的修改都会被记泶不來并产生新的发 布版本（称作“维护版本”并伴随升级了的版本号）以确保客户可以从升级中获 益。二、瀑布模型幵发的优缺点1. 优点上述的瀑布模型为软件开发人员提供了众多优势，首先，这个阶段性的软件 开发模型规定了以下规则：每个阶段都有指定的起点和终点，过程最终可以被客 户和开发者识别（通过使用里程碑），在编写第一行代码之前充分强调了需求和 设计，这避免了时间的浪费以及跳票的风险，同吋还可以尽可能地保证实现客户 的预期需求。提取需求和设计提高y产品质量，因为在设计阶段捕获并修正可能 存在的漏洞耍比测试阶段容易很多，毕竟在组件集成之后来追踪

8、特定的错误要复 杂很多。最后，因为前两个阶段生成了规范的说明书，当团队成员分散在不同地 点的时候，瀑布模型可以帮助实现有效的知识传递。2. 缺点除了看上去很明显的这些优势，瀑布模型近来也受到了很多批评，最突出的 一点是围绕需求分析的，通常客户一开始并不知道他们需要的是什么，而是在整 个项目进程中通过双向交互不断明确的；而瀑布模型是强调捕获需求和设计的， 但在这种情况下，现实世界的反复无偿就显得瀑布模型冇些不切实际了。除此以 外，即使给定了客户需求，根据这些需求在一定的精确性范围a （瀑布模型所建 议的）估算时间和成本是非常困难的。因此，建议在客户需求可以在最初阶段明 确的情况下并且和对稳定的项

9、目中使用瀑布模型。另外的批评指出瀑布模型还假定设计可以被转换为真实的产品，这往往导致 开发者在工作时陷入困境，通常，看上去合理可行的设计方案在现实中往往代价 昂贵或者异常艰难，从而需耍重新设计，这样就破坏了传统瀑布模型中清晰的阶 段界限。有些批评还指出瀑布模型暗示了清晰的分工，将参与开发的人员分为“设 计师”、“程序员”和“测试员”，但是在现实中，这样的分工对于软件公司而言 既不现实也没有效率。四、对于瀑布模型的看法对于需求不明确或经常变动的情况，瀑布模型是不适应的，其实就是需求确 定，其实瀑布模型也不是很好的，因为人的思维过程是连续的，不可能一下子考 虑的很全面，因此如果在瀑布的不同阶段使用

10、不同的人员，很难保证这个阶段方 案真的能满足下一阶段的要求，而瀑布模型恰恰要求做到这样（因为它不允许循 环和迭代，冇循环和迭代就不叫瀑布模型了，谁见过瀑布还会自己流冋山上的）, 这个要求是不符合人的思维习惯的。所以可操作的过程必须是有灵活性的，可以处理不同类型的项目（或者 针对不同类型的项目采用不同的过程），比如对于一个开发周期长的项h，清晰 严谨的文档很重要，但对于一个快速开发的项目，就不能有太繁重的 paper work。所以关键是过程要能根据实际情况剪裁，同时过程要能被持续 地改进，试图一步到位地建立和实施一个新的过程是很难成功的，过程改进是持 续的也意味着是渐进的，不要一次引进太多的变

11、化。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接 受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要 进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活 动，否则返回修改。瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。 但是，这种模型的线性过程太理想化，己不再适合现代的软件开发模式，几乎被 业界抛弃，其主要问题在于：（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作 量；（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果， 从而增加了开发的风险；（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后 果。但是我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。 当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转