软件开发模型PPT课件
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第24页/共67页
适合的项目类型： ➢ 采用快速度从小到大变化的项目，例如重整企业的信息系统。
第25页/共67页
软件生命周期与软件开发模型
3、增量模型 增量模型也称为渐增模型。 使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、
➢这个模型中最终用户是很重要的角色，从图2.5 可以看出，系统构造的实践比传统其他模型要少 很多，模型中更多的任务是规划和设计，而不是 编码和测试。
➢因为在开发中采用很多的工具，例如利用代码生 成器等生成需要的系统，这样会很快构造一个系 统。采用这种方法可以不断完善地构造出一个用 户需要的系统。
➢这个系统中的构造包括详细设计、编码、测试等， 所以，快速应用开发（RAD）模型相当于将设计、 构建、测试等压缩为一系列的短的迭代式的循环。
修正前面阶段的产品之
综合测试
后再回来继续完成后面
阶段的任务。
图2.2 实际瀑布模型
维护
第9页/共67页
软件生命周期与软件开发模型
瀑布模型有许多优点：
➢ 可强迫开发人员采用规范的方法（例如，结构化技 术）；
➢ 严格地规定了每个阶段必须提交的文档； ➢ 要求每个阶段交出的所有产品必须经过质量保证小
组的仔细验证。
第27页/共67页
软件生命周期与软件开发模型
3、增量模型 ➢ 使用增量模型时，把软件产品分解成增量构件时，应该使构件的规模适中， 规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而 异。 ➢ 分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形 成的产品必须是可测试的。 ➢ 第一个增量构件往往实现软件的基本需求，提供最核心的功能。
➢ 原型的用途是获知用户的真正需求，一旦需求确定了，原型将 被抛弃。
➢ 因此，原型系统的内部结构并不重要，重要的是，必须迅速地 构建原型然后根据用户意见迅速地修改原型。
第20页/共67页
软件生命周期与软件开发模型
➢快速应用开发模型是用工具快速构造系统的一种 方法。说它是一种方法比说它是一个模型更贴切。
第10页/共67页
软件生命周期与软件开发模型
各个阶段产生的文档是维护软件产品时必不可 少的，没有文档的软件几乎是不可能维护的。
遵守瀑布模型的文档约束，将使软件维护变得 比较容易一些。
由于绝大部分软件预算都花费在软件维护上 (55%-70%)，因此，使软件变得比较容易维护就能 显著降低软件预算。
可以说，瀑布模型的成功在很大程度上是由于 它基本上是一种文档驱动的模型。
快速原型 验证
变化的需求
验证
后，维护便开始
规格说明 验证
了。 设计
根据所需完成的
验证
维护工作种类的
编码
不同，可能需要
测试
返回到需求分析、
综合测试
规格说明、设计
图2.3 快速原型模型
维护
或编码等不同阶
第19页/共67页
软件生命周期与软件开发模型
快速原型的本质是“快速” 。
➢ 开发人员应该尽可能快地建造出原型系统，以加速软件开发过 程，节约软件开发成本。
作过程中不可能不犯错误。
在设计阶段可能发现规格说明文档中的错误，而 设计上的缺陷或错误可能在实现过程中显现出来，在 综合测试阶段将发现需求分析、设计或编码阶段的许 多错误。
因此，实际的瀑布模型是带“反馈环”的，如图 2.2所示（图中实线箭头表示开发过程，虚线箭头表示 维护过程）。
当在后面阶段发现前面阶段的错误时，需要沿图 中左侧的红色反馈线返回前面的阶段，修正前面阶段 的产品之后再回来继续完成后面阶段的任务。
第3页/共67页
软件生命周期与软件开发模型
⑵ 推迟实现的观点 缺乏软件工程实践经验的软件开发人员，接到软
件开发任务以后常常急于求成，总想尽早开始编写程序。 但是，实践证明，对于规模较大的软件项目来说，
编码开始得越早最终完成开发工作所需要的时间反而越 长。
这是因为，前面阶段的工作没做或做得不扎实， 过早地考虑进行程序实现，往往导致大量返工，有时甚 至发生无法弥补的问题，带来灾难性的后果。
第15页/共67页
2、快速原型模型
➢所谓快速原型是快速建立起来的可以在计算机上运行 的程序，它所能完成的功能往往是最终产品能完成的功 能的一个子集。
➢ 快速原型模型的第一步是快速建立一个能反映用户主要需 求的原型系统，让用户在计算机上试用它，通过实践来了 解目标系统的概貌。
➢ 通常，用户试用原型系统之后会提出许多修改意见，开发 人员按照用户的意见快速地修改原型系统，然后再次请用 户试用… …。
集成和测试。 每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
第26页/共67页
软件生命周期与软件开发模型
需求分析 验证
规格说明 验证
概要设计 验证
针对每个构件,完成详细设 计,编码和集成,经测试后交 付给用户
维护
图2.6 增量模型
图2.6所示的增量模型表明，必须在开始实现各个构件之 前就全部完成需求分析、规格说明和概要设计的工作。 由于在开始构建第一个构件之前已经有了总体设计，因 此风险较小。
是渐渐地熟悉系统。 (7)不允许变更或者限制变更。
第13页/共67页
软件生命周期与软件开发模型
2. 使用指南 瀑布模型使用指南可以从三个方面说明： ⑴ 开发前，需进行概念开发和系统配置开发。概念开发 主要是确定系统级的需求，提交一份 SOW(工作说明书 statement of work) 。系统配置开发主要是确定软件 和硬件的情况。 ⑵ 开发中，需进行需求过程、设计过程、实施过程。 ⑶ 开发后，需进行安装过程、支持过程、维护过程、抛 弃过程等。
⑶ 质量保证的观点 软件工程的基本目标是优质、高产。为了保
证所开发的软件的质量，在瀑布模型的每个阶段 都应坚持两个重要做法。
① 每个阶段都必须完成规定的文档，没有 交出合格的文档就是没有完成该阶段的任务。完 整、准确的合格文档不仅是软件开发时期各类人 员之间相互沟通的媒介，也是运行时期对软件进 行维护的重要依据。
第21页/共67页
软件生命周期与软件开发模型
规划
分析
传统开发
设计
构建
测试
后置
压缩
规划
快速应用开发
后置
图2.5 快速应用开发模型与传统模型比较
第22页/共67页
软件生命周期与软件开发模型
快速应用开发模型有如下的特点： ⑴ 项目团队很小并且是由经过训练的人员组成。 ⑵ 可以用很少的人、很低的成本，改善生产率， 缩短循环周期。 ⑶ 可以用自动生成软件生成复用的部分。 ⑷ 用户可以确定系统如何适应业务需求。
第28页/共67页
• 例如，使用增量模型开发字处理软件时 ➢ 第一个增量构件可能提供基本的文件管理、编辑和文档生成功能； ➢ 第二个增量构件提供更完善的编辑和文档生成功能； ➢ 第三个增量构件实现拼写和语法检查功能； ➢ 第四个增量构件完成高级的页面排版功能。
验证
线箭头表示维护
编码
过程。
测试
这正是这种过程 模型的主要优点： 软件产品的开发
图2.3 快速原型模型
第17页/共67页
综合测试 维护
软件生命周期与软件开发模型
能做到基本上线性顺序开发的主要原因如下：
⑴ 原型系统已经通过与用户交互而得到验证， 据此产生的规格说明文档正确地描述了用户需 求，因此，在开发过程的后续阶段不会因为发 现了规格说明文档的错误而进行较大的返工。
➢ 一旦用户认为这个原型系统确实能做他们所需要的工作， 开发人员便可据此书写规范说明文档，根据这份文档开发 出的软件便可以满足用户的真实需求。
第16页/共67页
软件生命周期与软件开发模型
从图2.3可以看出， 快速原型 验证
快速原型模型是
变化的需求
验证
不带反馈环的，
规格说明 验证
图中实线箭头表
设计
示开发过程，虚
⑵ 开发人员通过建立原型系统已经学到了许多 东西（至少知道了“系统不应该做什么，以及 怎样不去做不该做的事情” ），因此，在设计 和编码阶段发生错误的可能性也比较小，这自 然减少了在后续阶段需要改正前面错误所犯错 误的可能性。
第18页/共67页
软件生命周期与软件开发模型
软件产品一旦交 付给用户使用之
第8页/共67页
软件生命周期与软件开发模型
2. 实际瀑布模型
需求分析 验证
变化的需求
验证
实际的瀑布模型是带
“反馈环”的，如图2.2 所示（图中实线箭头表
规格说明 验证
示开发过程，虚线箭头
表示维护过程）。 当在后面阶段发现
设计 验证
前面阶段的错误时，需
编码
要沿图中左侧的红色反 反馈线
测试
馈线返回前面的阶段，
第11页/共67页
软件生命周期与软件开发模型
“瀑布模型是由文档驱动的” 也是一个主要缺点。
➢ 在可运行的软件产品交付给用户之前，用户只能通过文档 来了解产品是什么样的。但是，仅仅通过写在纸上的静态 的规格说明，很难全面正确地认识动态的软件产品。
➢ 而且事实证明，一旦一个用户开始使用一个软件，在他的 头脑中关于该软件应该做什么的想法就会或多或少地发生 变化，这就使得最初提出的需求变得不完全适用了。
第4页/共67页
瀑布模型在编码之前设置了系统分析 与系统设计的各个阶段，分析与设计阶段的基 本任务规定，在这两个阶段主要考虑目标系统 的逻辑模型，不涉及软件的物理实现。
清楚地区分逻辑设计与物理设计，尽 可能推迟程序的物理实现，是按照瀑布模型开 发软件的一条重要的指导思想。
第5页/共67页
软件生命周期与软件开发模型
需求分析 验证
规格说明 验证
设计 验证
编码 测试
图2.1 传统的瀑布模型
综合测试 维护
第2页/共67页
1. 传统瀑布模型
按照传统的瀑布模型来开发软件，有如下几个特 点。 ⑴ 阶段间具有顺序性和依赖性
这个特点有两重含义： ① 必须等前一阶段的工作完成之后，才能开始 后一阶段的工作； ② 前一阶段的输出文档就是后一阶段的输入文 档，因此，只有前一阶段的输出文档正确，后一阶 段的工作才能获得正确的结果。可是，万一在生命 周期某一阶段发现了问题，很可能需要追溯到在它 之前的一些阶段，必要时还要修改前面已经完成的 文档。然而，在生命周期后期改正早期阶段造成的 问题，需要付出很高的代价。这就好像水已经从瀑 布顶部流泻到底部，再想使它返回到高处需要付出 很大能量一样。
第23页/共67页
软件生命周期与软件开发模型
使用指南 采用快速应用开发模型，包括需求规划阶段、用户
设计阶段、构建阶段和提交阶段。如果项目比较小，需 求规划阶段和用户设计阶段可以合二为一。 使用中需要注意以下几点： ⑴ 需求规划阶段主要是明确需要解决的商务流程 。 ⑵ 用户设计阶段主要是采用工具由用户参与进行的系统 规划设计。 ⑶ 构建阶段是根据用户设计的结果，采用代码生成器快 速形成需要的系统。 ⑷ 提交阶段是将产品提交使用，进行必要的培训等。
• 典型的开发模型有： • ①瀑布模型(waterfall model)； • ②快速原型模型 (prototype model)； • ③增量模型 (incremental model)； • ④螺旋模型(spiral model)；
第1页/共67页
软件生命周期与软件开发模型
1、瀑布模型
在20世纪80 年代之前，瀑布模 型一直是唯一被广 泛采用的生命周期 模型，现在它仍然 是软件工程中应用 得最广泛的过程模 型。图2.1 所示为 传统的瀑布模型。
➢ 事实上，要求用户完全不经过实践就提出完整准确的需求， 在许多情况下是不切实际的。
➢ 总之，由于瀑布模型几乎完全依赖于书面的规格说明，很 可能导致最终开发出的软件产品不能真正满足用户的需要。
第12页/共67页
第二章 软件生命周期与软件开发模型
1. 瀑布模型有如下特点： ⑴ 简单、易用、直观。 ⑵ 开发进程比较严格，一个进程顺着一个进程进行 (3)模型执行过程中需要严密控制。 (4)允许基线和配置早期接受控制。 (5)新项目不适合瀑布模型，除非处于项目的后期。 (6)用户直到项目结束才能看到产品的质量；用户不
第6页/共67页
② 每个阶段结束前要对所完成的文档 进行评审，以便尽早发现问题，改正错误。事 实上，越是早期阶段犯下的错误，暴露出来的 时间就越晚，排除故障改正错误所需付出的代 价也就越高。因此，及时审查，是保证软件质 量，降低软件成本的重要措施。
第7页/共67页
2. 实际瀑布模型 传统的瀑布模型过于理想化了，事实上，人在工
第14页/共67页
软件生命周期与软件开发模型
3. 适合的项目类型
➢ 在开发中，向下、渐进的路径占据支配地位，即 要求在项目开始前，项目的需求已经被很好地理 解，也很明确；
➢ 而且项目经理很熟悉为实现这一模型所需要的过 程，同时解决方案在项目开始前也很明确。
➢ 类似的项目如公司的财务系统、库存管理系统及 短期项目等。
适合的项目类型： ➢ 采用快速度从小到大变化的项目，例如重整企业的信息系统。
第25页/共67页
软件生命周期与软件开发模型
3、增量模型 增量模型也称为渐增模型。 使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、
➢这个模型中最终用户是很重要的角色，从图2.5 可以看出，系统构造的实践比传统其他模型要少 很多，模型中更多的任务是规划和设计，而不是 编码和测试。
➢因为在开发中采用很多的工具，例如利用代码生 成器等生成需要的系统，这样会很快构造一个系 统。采用这种方法可以不断完善地构造出一个用 户需要的系统。
➢这个系统中的构造包括详细设计、编码、测试等， 所以，快速应用开发（RAD）模型相当于将设计、 构建、测试等压缩为一系列的短的迭代式的循环。
修正前面阶段的产品之
综合测试
后再回来继续完成后面
阶段的任务。
图2.2 实际瀑布模型
维护
第9页/共67页
软件生命周期与软件开发模型
瀑布模型有许多优点：
➢ 可强迫开发人员采用规范的方法（例如，结构化技 术）；
➢ 严格地规定了每个阶段必须提交的文档； ➢ 要求每个阶段交出的所有产品必须经过质量保证小
组的仔细验证。
第27页/共67页
软件生命周期与软件开发模型
3、增量模型 ➢ 使用增量模型时，把软件产品分解成增量构件时，应该使构件的规模适中， 规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而 异。 ➢ 分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形 成的产品必须是可测试的。 ➢ 第一个增量构件往往实现软件的基本需求，提供最核心的功能。
➢ 原型的用途是获知用户的真正需求，一旦需求确定了，原型将 被抛弃。
➢ 因此，原型系统的内部结构并不重要，重要的是，必须迅速地 构建原型然后根据用户意见迅速地修改原型。
第20页/共67页
软件生命周期与软件开发模型
➢快速应用开发模型是用工具快速构造系统的一种 方法。说它是一种方法比说它是一个模型更贴切。
第10页/共67页
软件生命周期与软件开发模型
各个阶段产生的文档是维护软件产品时必不可 少的，没有文档的软件几乎是不可能维护的。
遵守瀑布模型的文档约束，将使软件维护变得 比较容易一些。
由于绝大部分软件预算都花费在软件维护上 (55%-70%)，因此，使软件变得比较容易维护就能 显著降低软件预算。
可以说，瀑布模型的成功在很大程度上是由于 它基本上是一种文档驱动的模型。
快速原型 验证
变化的需求
验证
后，维护便开始
规格说明 验证
了。 设计
根据所需完成的
验证
维护工作种类的
编码
不同，可能需要
测试
返回到需求分析、
综合测试
规格说明、设计
图2.3 快速原型模型
维护
或编码等不同阶
第19页/共67页
软件生命周期与软件开发模型
快速原型的本质是“快速” 。
➢ 开发人员应该尽可能快地建造出原型系统，以加速软件开发过 程，节约软件开发成本。
作过程中不可能不犯错误。
在设计阶段可能发现规格说明文档中的错误，而 设计上的缺陷或错误可能在实现过程中显现出来，在 综合测试阶段将发现需求分析、设计或编码阶段的许 多错误。
因此，实际的瀑布模型是带“反馈环”的，如图 2.2所示（图中实线箭头表示开发过程，虚线箭头表示 维护过程）。
当在后面阶段发现前面阶段的错误时，需要沿图 中左侧的红色反馈线返回前面的阶段，修正前面阶段 的产品之后再回来继续完成后面阶段的任务。
第3页/共67页
软件生命周期与软件开发模型
⑵ 推迟实现的观点 缺乏软件工程实践经验的软件开发人员，接到软
件开发任务以后常常急于求成，总想尽早开始编写程序。 但是，实践证明，对于规模较大的软件项目来说，
编码开始得越早最终完成开发工作所需要的时间反而越 长。
这是因为，前面阶段的工作没做或做得不扎实， 过早地考虑进行程序实现，往往导致大量返工，有时甚 至发生无法弥补的问题，带来灾难性的后果。
第15页/共67页
2、快速原型模型
➢所谓快速原型是快速建立起来的可以在计算机上运行 的程序，它所能完成的功能往往是最终产品能完成的功 能的一个子集。
➢ 快速原型模型的第一步是快速建立一个能反映用户主要需 求的原型系统，让用户在计算机上试用它，通过实践来了 解目标系统的概貌。
➢ 通常，用户试用原型系统之后会提出许多修改意见，开发 人员按照用户的意见快速地修改原型系统，然后再次请用 户试用… …。
集成和测试。 每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
第26页/共67页
软件生命周期与软件开发模型
需求分析 验证
规格说明 验证
概要设计 验证
针对每个构件,完成详细设 计,编码和集成,经测试后交 付给用户
维护
图2.6 增量模型
图2.6所示的增量模型表明，必须在开始实现各个构件之 前就全部完成需求分析、规格说明和概要设计的工作。 由于在开始构建第一个构件之前已经有了总体设计，因 此风险较小。
是渐渐地熟悉系统。 (7)不允许变更或者限制变更。
第13页/共67页
软件生命周期与软件开发模型
2. 使用指南 瀑布模型使用指南可以从三个方面说明： ⑴ 开发前，需进行概念开发和系统配置开发。概念开发 主要是确定系统级的需求，提交一份 SOW(工作说明书 statement of work) 。系统配置开发主要是确定软件 和硬件的情况。 ⑵ 开发中，需进行需求过程、设计过程、实施过程。 ⑶ 开发后，需进行安装过程、支持过程、维护过程、抛 弃过程等。
⑶ 质量保证的观点 软件工程的基本目标是优质、高产。为了保
证所开发的软件的质量，在瀑布模型的每个阶段 都应坚持两个重要做法。
① 每个阶段都必须完成规定的文档，没有 交出合格的文档就是没有完成该阶段的任务。完 整、准确的合格文档不仅是软件开发时期各类人 员之间相互沟通的媒介，也是运行时期对软件进 行维护的重要依据。
第21页/共67页
软件生命周期与软件开发模型
规划
分析
传统开发
设计
构建
测试
后置
压缩
规划
快速应用开发
后置
图2.5 快速应用开发模型与传统模型比较
第22页/共67页
软件生命周期与软件开发模型
快速应用开发模型有如下的特点： ⑴ 项目团队很小并且是由经过训练的人员组成。 ⑵ 可以用很少的人、很低的成本，改善生产率， 缩短循环周期。 ⑶ 可以用自动生成软件生成复用的部分。 ⑷ 用户可以确定系统如何适应业务需求。
第28页/共67页
• 例如，使用增量模型开发字处理软件时 ➢ 第一个增量构件可能提供基本的文件管理、编辑和文档生成功能； ➢ 第二个增量构件提供更完善的编辑和文档生成功能； ➢ 第三个增量构件实现拼写和语法检查功能； ➢ 第四个增量构件完成高级的页面排版功能。
验证
线箭头表示维护
编码
过程。
测试
这正是这种过程 模型的主要优点： 软件产品的开发
图2.3 快速原型模型
第17页/共67页
综合测试 维护
软件生命周期与软件开发模型
能做到基本上线性顺序开发的主要原因如下：
⑴ 原型系统已经通过与用户交互而得到验证， 据此产生的规格说明文档正确地描述了用户需 求，因此，在开发过程的后续阶段不会因为发 现了规格说明文档的错误而进行较大的返工。
➢ 一旦用户认为这个原型系统确实能做他们所需要的工作， 开发人员便可据此书写规范说明文档，根据这份文档开发 出的软件便可以满足用户的真实需求。
第16页/共67页
软件生命周期与软件开发模型
从图2.3可以看出， 快速原型 验证
快速原型模型是
变化的需求
验证
不带反馈环的，
规格说明 验证
图中实线箭头表
设计
示开发过程，虚
⑵ 开发人员通过建立原型系统已经学到了许多 东西（至少知道了“系统不应该做什么，以及 怎样不去做不该做的事情” ），因此，在设计 和编码阶段发生错误的可能性也比较小，这自 然减少了在后续阶段需要改正前面错误所犯错 误的可能性。
第18页/共67页
软件生命周期与软件开发模型
软件产品一旦交 付给用户使用之
第8页/共67页
软件生命周期与软件开发模型
2. 实际瀑布模型
需求分析 验证
变化的需求
验证
实际的瀑布模型是带
“反馈环”的，如图2.2 所示（图中实线箭头表
规格说明 验证
示开发过程，虚线箭头
表示维护过程）。 当在后面阶段发现
设计 验证
前面阶段的错误时，需
编码
要沿图中左侧的红色反 反馈线
测试
馈线返回前面的阶段，
第11页/共67页
软件生命周期与软件开发模型
“瀑布模型是由文档驱动的” 也是一个主要缺点。
➢ 在可运行的软件产品交付给用户之前，用户只能通过文档 来了解产品是什么样的。但是，仅仅通过写在纸上的静态 的规格说明，很难全面正确地认识动态的软件产品。
➢ 而且事实证明，一旦一个用户开始使用一个软件，在他的 头脑中关于该软件应该做什么的想法就会或多或少地发生 变化，这就使得最初提出的需求变得不完全适用了。
第4页/共67页
瀑布模型在编码之前设置了系统分析 与系统设计的各个阶段，分析与设计阶段的基 本任务规定，在这两个阶段主要考虑目标系统 的逻辑模型，不涉及软件的物理实现。
清楚地区分逻辑设计与物理设计，尽 可能推迟程序的物理实现，是按照瀑布模型开 发软件的一条重要的指导思想。
第5页/共67页
软件生命周期与软件开发模型
需求分析 验证
规格说明 验证
设计 验证
编码 测试
图2.1 传统的瀑布模型
综合测试 维护
第2页/共67页
1. 传统瀑布模型
按照传统的瀑布模型来开发软件，有如下几个特 点。 ⑴ 阶段间具有顺序性和依赖性
这个特点有两重含义： ① 必须等前一阶段的工作完成之后，才能开始 后一阶段的工作； ② 前一阶段的输出文档就是后一阶段的输入文 档，因此，只有前一阶段的输出文档正确，后一阶 段的工作才能获得正确的结果。可是，万一在生命 周期某一阶段发现了问题，很可能需要追溯到在它 之前的一些阶段，必要时还要修改前面已经完成的 文档。然而，在生命周期后期改正早期阶段造成的 问题，需要付出很高的代价。这就好像水已经从瀑 布顶部流泻到底部，再想使它返回到高处需要付出 很大能量一样。
第23页/共67页
软件生命周期与软件开发模型
使用指南 采用快速应用开发模型，包括需求规划阶段、用户
设计阶段、构建阶段和提交阶段。如果项目比较小，需 求规划阶段和用户设计阶段可以合二为一。 使用中需要注意以下几点： ⑴ 需求规划阶段主要是明确需要解决的商务流程 。 ⑵ 用户设计阶段主要是采用工具由用户参与进行的系统 规划设计。 ⑶ 构建阶段是根据用户设计的结果，采用代码生成器快 速形成需要的系统。 ⑷ 提交阶段是将产品提交使用，进行必要的培训等。
• 典型的开发模型有： • ①瀑布模型(waterfall model)； • ②快速原型模型 (prototype model)； • ③增量模型 (incremental model)； • ④螺旋模型(spiral model)；
第1页/共67页
软件生命周期与软件开发模型
1、瀑布模型
在20世纪80 年代之前，瀑布模 型一直是唯一被广 泛采用的生命周期 模型，现在它仍然 是软件工程中应用 得最广泛的过程模 型。图2.1 所示为 传统的瀑布模型。
➢ 事实上，要求用户完全不经过实践就提出完整准确的需求， 在许多情况下是不切实际的。
➢ 总之，由于瀑布模型几乎完全依赖于书面的规格说明，很 可能导致最终开发出的软件产品不能真正满足用户的需要。
第12页/共67页
第二章 软件生命周期与软件开发模型
1. 瀑布模型有如下特点： ⑴ 简单、易用、直观。 ⑵ 开发进程比较严格，一个进程顺着一个进程进行 (3)模型执行过程中需要严密控制。 (4)允许基线和配置早期接受控制。 (5)新项目不适合瀑布模型，除非处于项目的后期。 (6)用户直到项目结束才能看到产品的质量；用户不
第6页/共67页
② 每个阶段结束前要对所完成的文档 进行评审，以便尽早发现问题，改正错误。事 实上，越是早期阶段犯下的错误，暴露出来的 时间就越晚，排除故障改正错误所需付出的代 价也就越高。因此，及时审查，是保证软件质 量，降低软件成本的重要措施。
第7页/共67页
2. 实际瀑布模型 传统的瀑布模型过于理想化了，事实上，人在工
第14页/共67页
软件生命周期与软件开发模型
3. 适合的项目类型
➢ 在开发中，向下、渐进的路径占据支配地位，即 要求在项目开始前，项目的需求已经被很好地理 解，也很明确；
➢ 而且项目经理很熟悉为实现这一模型所需要的过 程，同时解决方案在项目开始前也很明确。
➢ 类似的项目如公司的财务系统、库存管理系统及 短期项目等。