软件系统开发方法
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
(3) 将系统中难度较大、风险较高的部分安排在早期的 迭代中，可增加项目的成功率。
第24页
2020/5/4
3.2.2 演化模型
❖ 演化模型的缺点
(1) 由于项目需求在开发初期不可能完全弄清 楚，这样会给系统总体设计带来很大的困难， 并影响系统设计的完整性。
(2) 如果在开发过程中缺乏严格的过程管理， 演化模型很可能退化为边写边改模式。
(2) 维护中对软件的变更仍然要经历软件生命 周期在开发中已经历过的各项活动。
第17页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型的优点：
(1) 为软件项目提供了按阶段划分的检查点， 强调开发的阶段性。
(2) 强调早期计划及需求调查。 (3) 强调产品测试和阶段评审。 (4) 强调文档的重要性。
第10页
2020/5/4
3.2 软件开发模型
❖ 从上节的内容中我们知道，一个软件的生命周期包 含了若干个活动，那么，这些活动应该如何组织呢？ 不同的组织方式可能会产生很大差别的结果。
❖ 实际上，与其它工程项目中安排各道工序类似，为 了反应软件开发生命周期内的各种活动应如何组织， 各活动之间应如何衔接，需要用软件开发模型做出 直观的图示来表达。
活动； (4) 对本项活动实施的工作进行评审。若得到确认，则
继续下一项活动；否则，返回到前项活动，或更前一 项活动进行返工。
第16页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型中软件维护的特点：
(1) 维护的具体要求是在软件投入使用以后提 出来的，经过评价，确定需求变更的必要性， 才进行维护工作。
第21页
2020/5/4
3.2.2 演化模型
❖ 该模型可以表示为：
第一次迭代（需求→设计→编码→测试→集成） →反馈→第二次迭代（需求→设计→编码→测 试→集成）→反馈→......
第22页
2020/5/4
3.2.2 演化模型
需求分析
设计
编码
测试
集成
反馈 交付用户
迭代1
问 迭代2
题
定 迭代3
义
需求分析
第11页
2020/5/4
3.2 软件开发模型
❖ 软件开发模型是从软件项目需求定义到软 件经使用后被废弃为止，跨越整个软件生 命周期的系统开发、运作和维护的全部过 程、活动和任务的结构框架，它给出了软 件开发活动各个阶段之间的关系。每种软 件生命周期模型代表一种软件开发与管理 的组织过程。
第12页
2020/5/4
第26页
2020/5/4
3.2.3 螺旋模型
❖ 对于复杂的大型软件系统，开发一个原型 往往很难达到要求，显然用单一的演化模 型很难开发出这样的软件系统。那么，究 竟要使用什么样的模型才适合用来开发大 型而复杂的软件系统呢？答案就是螺旋模 型。
第27页
2020/5/4
3.2.3 螺旋模型
❖ 螺旋模型沿着螺线 旋转，在笛卡尔坐 标的四个象限上分 别表达了每个迭代 周期的四个阶段， 从左象限按顺时针 方向依次为：
❖ 当用户需求不明确或经常变更时，不宜采用瀑布模型，可以 考虑其它的架构来进行项目管理，如：演化模型等。
第20页
2020/5/4
3.2.2 演化模型
❖演化模型主要针对事先不能完整定义 需求的软件开发。用户可以给出待开 发系统的核心需求，并且当看到核心 需求实现后，能够有效地提出反馈， 以支持系统的最终设计和实现。
2020/5/4
3.1 软件开发生命周期
❖ (4) 编码（Coding）
团队人员：编程人员、测试人员等。 将详细设计阶段所描述的模块程序流程图或类
的设计转换为计算机能处理的程序代码，即使 用特定的程序设计语言表示的源程序。目前， 通常使用高级程序设计语言编写程序，如C语 言、Java语言等。
第8页
第5页
2020/5/4
3.1 软件开发生命周期
❖ (2) 需求分析和定义（Requirement Analysis and Definition）
团队人员：分析人员、测试人员、领域专家及用户等。
该阶段对于待开发软件项目获取的用户需求进行分析，并给出详 细定义。这个阶段团队人员必须协同工作，让软件开发人员充分 理解用户的各项需求，并确定哪些需求是可以满足的，哪些需求 在现有技术下是不能满足的，对能满足的需求加以确切的描述。 然后，编写出软件需求规格说明书（SRS）或系统功能说明书， 以及初步的系统用户手册、测试用例等。为了团队人员之间能很 好地沟通，从这个阶段开始通常会采用一些标准的建模语言（如： 统一建模语言，Unified Modeling Language，简称UML）对系统 建模。
第6页
2020/5/4
3.1 软件开发生命周期
❖ (3) 软件设计（Software Design）
团队人员：架构设计人员、软件设计人员、数据库设计员、用户界 面设计员、封装体设计员和集成人员、测试人员等。
这个阶段通常分为两部分：概要设计和详细设计。 在软件设计阶段，软件开发人员把已经经过用户和领域专家确认的
第2页
2020/5/4
3.1 软件开发生命周期
❖ 正如任何事物一样，软件也有其孕育、诞 生、成长、成熟以及衰亡的生命过程，一 般称其为“软件生命周期”。
第3页
2020/5/4
3.1 软件开发生命周期
❖ 根据这一思想，可以得到软件生命周期的六 个阶段：
制定计划 需求分析和定义 设计 编码 测试 运行及维护。
第4页
2020/5/4
3.1 软件开发生命周期
❖ (1) 制定计划（Planning）
团队人员：分析人员、领域专家及用户等。
这个阶段的任务是确定待开发软件系统的总体目标， 给出软件系统的功能、性能及接口等方面的要求。由 团队人员协作，共同研究完成该项软件开发任务的技 术、经济、社会可行性，探讨解决问题的各种可能方 案，并对现有可利用资源、成本、可取得的效益、开 发进度等做出估计，制定出完成该项开发任务的实施 计划，并编写可行性研究报告。
第14页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型是最早出现的 软件开发模型，在软件 工程中占有十分重要的 地位，它提供了软件开 发的基本框架。瀑布模 型规定了各项软件工程 活动，其核心思想是按 工序将问题化简，将功 能的实现与设计分开， 便于分工协作，即采用 结构化的分析与设计方 法将逻辑实现与物理实 现分开。
2020/5/4
3.1 软件开发生命周期
❖ (5) 软件测试（Software Testing）
团队人员：测试人员、开发人员、用户等。
测试是保证软件质量的重要手段，其主要目的是通过软件测试暴露 出软件中隐藏的错误和缺陷。软件测试的主要方式是在设计测试用 例的基础上检验软件的各个组成部分。软件测试一般包括单元测试、 集成测试、系统测试、验收测试等几个阶段。首先进行单元测试， 查找各模块或类在功能和结构上存在的问题并加以修改，这个过程 会反复进行；其次进行集成测试，验证各软件单元集成后形成的模 块能否达到概要设计规格说明中各模块的设计目标；然后进行系统 测试，目的是对最终软件系统进行全面的测试，确保最终软件系统 满足产品需求并且遵循系统设计；最后进行确认测试，以检查已实 现的软件是否满足了需求规格说明书中确定的各种需求，包括功能 需求和性能需求，决定已开发的软件能否交付用户使用。
第18页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型的缺点：
(1) 在项目各个阶段之间极少有反馈，往往会将早期的 错误引入到后期各个阶段。
(2) 依赖于早期进行的唯一一次需求调查，用户参与较 少，不能适应需求的变化。
(3) 只有在项目生命周期的后期才能看到结果，可能与 用户的需求出现很大的偏差，使风险推迟到项目开发 的后期阶段才显露出来，因而失去及早纠正的机会。
3.2 软件开发模型
❖ 迄今为止，出现了多种软件开发模型。如：
瀑布模型 螺旋模型 演化模型 喷泉模型 智能模型 增量模型 原型化模型
第13页
2020/5/4
3.2.1 瀑布模型
❖瀑布模型将软件生命周期划分为制 定开发计划、需求分析和定义、软 件设计、程序编写、软件测试和运 行维护等六个基本活动，并且规定 了它们自上而下、相互衔接的固定 次序，如同瀑布流水，逐级下落。
各项需求转换成相应的软件体系结构。结构中的每一成份都是意义 明确的子系统、模块或用例，每个部分都和某些需求相对应，进行 所谓的概要设计。然后对每个模块或用例要完成的工作采用合适的 技术进行具体的描述，如画出模块的程序流程图或描述类的属性、 操作等，为源程序的编写工作打下基础，即所谓的详细设计。
第7页
设计
编码
测试
集成
反馈 交付用户
需求分析
设计
编码
测试
集成
反馈 交付用户
……
迭代n
Biblioteka Baidu
需求分析
设计
编码
测试
集成
交付用户
第23页
2020/5/4
3.2.2 演化模型
❖ 演化模型的主要优点：
(1) 用户能在开发过程中而不是开发接近尾声时看到自 己所需要的软件产品。对发现的问题能够提早解决。
(2) 在一定程度上减少了软件开发活动的盲目性。如果 在某次迭代中，其需求没有满足用户的要求，软件开 发人员可根据用户的反馈信息在下一次迭代中予以修 正。
第3章 软件系统开发方法
❖ 3.1 软件开发生命周期 ❖ 3.2 软件开发模型 ❖ 3.3 传统软件开发方法 ❖ 3.4 面向对象软件开发方法 ❖ 3.5 RUP统一软件开发过程 ❖ 3.6 敏捷软件开发技术
第1页
2020/5/4
❖ 在软件开发的早期，人们常用的软件开发方法是边写边改法。这种开发 方法在应用开发中最为快捷，但由于其开发的随意性，因而也最为低效。 同时，使用该方法的项目常常因为管理失控而终结。基于这种情况，业 界人士借鉴其它工程领域的方法，提出了许多有规则可言的软件系统开 发方法。最著名的当数“瀑布式”方法了，即把软件开发过程分解成这 样一些阶段：制定开发计划、需求分析和定义、系统设计、编码实现、 测试验证。然而，在软件开发实践中完全遵循这种过程取得成功的案例 并不多。其原因主要在于这种方法有一个前提条件，那就是系统需求必 须明确、不变。但在现实应用中，这几乎是不可能的。需求通常模糊不 清，并且在系统开发期间随时都有可能发生变化。因此软件开发要求采 用的方法过程也必须能适应这种变化，这就出现了其它一些软件开发方 法，如原型法、敏捷方法等。
第9页
2020/5/4
3.1 软件开发生命周期
❖ (6) 运行/维护（Running/Maintenance）
团队人员：系统支持人员等。 已交付的软件投入正式使用，软件便进入运行
阶段。软件在运行过程中可能会因为发现了软 件中存在的错误需要修改；或为了适应变化了 的软件工作环境，需做一些变更；或为了增强 软件的功能需做变更等。这就称为软件维护。
累计费用
制定目标 选择方案 设定约束条件
各步骤的进度 风险分析
风险分析
评估方案 识别并排除风险
风险分析
风险
分析 原型 1
需求计划、生 命周期计划 操作概念
原型 2 软件
开发计划 需求
需求
确认
集成与测
设计确认
试计划
与验证 验
计划下一阶段
收 测
实施
试
原型 3
可运行原型
模拟
软件产 品设计
详细设计
模型 基准
(3) 如果没有一定的约束条件，可能永远无法 得到一个最终的软件产品。
第25页
2020/5/4
3.2.2 演化模型
❖ 采用演化模型的软件开发过程，实际上是从最初 的原型逐步演化成最终软件产品的过程。在整个 演化过程中，不断修正缺陷，以开发出最终满足 用户需要的软件产品。
❖ 演化模型特别适用于用户需求不够明确的软件开 发项目，但不适宜用于大而复杂的系统。
软件计划 需求分析和定义 软件设计 实现 测试 运行维护
第15页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型每项开发活动均应具有下述特征：
(1) 从上一项活动接收本项活动的工作对象，作为本项 活动的输入；
(2) 利用这一输入实施本项活动应完成的任务； (3) 给出本项活动的工作成果，作为输出传递给下一项
编码
单
(4) 通过过多的强制完成日期和里程碑来跟踪各个项目 阶段，灵活性较差。
第19页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型缺乏灵活性，无法通过开发活动来理清本来不够明 确的需求，这将可能导致直到软件开发完成时才发现所开发 的软件并非用户所需要的，此时必将付出高额的代价才能纠 正出现的偏差。
❖ 瀑布模型一般适用于功能、性能明确、完整、无重大变化的 软件系统的开发。如操作系统、编译系统等系统软件的开发。
第24页
2020/5/4
3.2.2 演化模型
❖ 演化模型的缺点
(1) 由于项目需求在开发初期不可能完全弄清 楚，这样会给系统总体设计带来很大的困难， 并影响系统设计的完整性。
(2) 如果在开发过程中缺乏严格的过程管理， 演化模型很可能退化为边写边改模式。
(2) 维护中对软件的变更仍然要经历软件生命 周期在开发中已经历过的各项活动。
第17页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型的优点：
(1) 为软件项目提供了按阶段划分的检查点， 强调开发的阶段性。
(2) 强调早期计划及需求调查。 (3) 强调产品测试和阶段评审。 (4) 强调文档的重要性。
第10页
2020/5/4
3.2 软件开发模型
❖ 从上节的内容中我们知道，一个软件的生命周期包 含了若干个活动，那么，这些活动应该如何组织呢？ 不同的组织方式可能会产生很大差别的结果。
❖ 实际上，与其它工程项目中安排各道工序类似，为 了反应软件开发生命周期内的各种活动应如何组织， 各活动之间应如何衔接，需要用软件开发模型做出 直观的图示来表达。
活动； (4) 对本项活动实施的工作进行评审。若得到确认，则
继续下一项活动；否则，返回到前项活动，或更前一 项活动进行返工。
第16页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型中软件维护的特点：
(1) 维护的具体要求是在软件投入使用以后提 出来的，经过评价，确定需求变更的必要性， 才进行维护工作。
第21页
2020/5/4
3.2.2 演化模型
❖ 该模型可以表示为：
第一次迭代（需求→设计→编码→测试→集成） →反馈→第二次迭代（需求→设计→编码→测 试→集成）→反馈→......
第22页
2020/5/4
3.2.2 演化模型
需求分析
设计
编码
测试
集成
反馈 交付用户
迭代1
问 迭代2
题
定 迭代3
义
需求分析
第11页
2020/5/4
3.2 软件开发模型
❖ 软件开发模型是从软件项目需求定义到软 件经使用后被废弃为止，跨越整个软件生 命周期的系统开发、运作和维护的全部过 程、活动和任务的结构框架，它给出了软 件开发活动各个阶段之间的关系。每种软 件生命周期模型代表一种软件开发与管理 的组织过程。
第12页
2020/5/4
第26页
2020/5/4
3.2.3 螺旋模型
❖ 对于复杂的大型软件系统，开发一个原型 往往很难达到要求，显然用单一的演化模 型很难开发出这样的软件系统。那么，究 竟要使用什么样的模型才适合用来开发大 型而复杂的软件系统呢？答案就是螺旋模 型。
第27页
2020/5/4
3.2.3 螺旋模型
❖ 螺旋模型沿着螺线 旋转，在笛卡尔坐 标的四个象限上分 别表达了每个迭代 周期的四个阶段， 从左象限按顺时针 方向依次为：
❖ 当用户需求不明确或经常变更时，不宜采用瀑布模型，可以 考虑其它的架构来进行项目管理，如：演化模型等。
第20页
2020/5/4
3.2.2 演化模型
❖演化模型主要针对事先不能完整定义 需求的软件开发。用户可以给出待开 发系统的核心需求，并且当看到核心 需求实现后，能够有效地提出反馈， 以支持系统的最终设计和实现。
2020/5/4
3.1 软件开发生命周期
❖ (4) 编码（Coding）
团队人员：编程人员、测试人员等。 将详细设计阶段所描述的模块程序流程图或类
的设计转换为计算机能处理的程序代码，即使 用特定的程序设计语言表示的源程序。目前， 通常使用高级程序设计语言编写程序，如C语 言、Java语言等。
第8页
第5页
2020/5/4
3.1 软件开发生命周期
❖ (2) 需求分析和定义（Requirement Analysis and Definition）
团队人员：分析人员、测试人员、领域专家及用户等。
该阶段对于待开发软件项目获取的用户需求进行分析，并给出详 细定义。这个阶段团队人员必须协同工作，让软件开发人员充分 理解用户的各项需求，并确定哪些需求是可以满足的，哪些需求 在现有技术下是不能满足的，对能满足的需求加以确切的描述。 然后，编写出软件需求规格说明书（SRS）或系统功能说明书， 以及初步的系统用户手册、测试用例等。为了团队人员之间能很 好地沟通，从这个阶段开始通常会采用一些标准的建模语言（如： 统一建模语言，Unified Modeling Language，简称UML）对系统 建模。
第6页
2020/5/4
3.1 软件开发生命周期
❖ (3) 软件设计（Software Design）
团队人员：架构设计人员、软件设计人员、数据库设计员、用户界 面设计员、封装体设计员和集成人员、测试人员等。
这个阶段通常分为两部分：概要设计和详细设计。 在软件设计阶段，软件开发人员把已经经过用户和领域专家确认的
第2页
2020/5/4
3.1 软件开发生命周期
❖ 正如任何事物一样，软件也有其孕育、诞 生、成长、成熟以及衰亡的生命过程，一 般称其为“软件生命周期”。
第3页
2020/5/4
3.1 软件开发生命周期
❖ 根据这一思想，可以得到软件生命周期的六 个阶段：
制定计划 需求分析和定义 设计 编码 测试 运行及维护。
第4页
2020/5/4
3.1 软件开发生命周期
❖ (1) 制定计划（Planning）
团队人员：分析人员、领域专家及用户等。
这个阶段的任务是确定待开发软件系统的总体目标， 给出软件系统的功能、性能及接口等方面的要求。由 团队人员协作，共同研究完成该项软件开发任务的技 术、经济、社会可行性，探讨解决问题的各种可能方 案，并对现有可利用资源、成本、可取得的效益、开 发进度等做出估计，制定出完成该项开发任务的实施 计划，并编写可行性研究报告。
第14页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型是最早出现的 软件开发模型，在软件 工程中占有十分重要的 地位，它提供了软件开 发的基本框架。瀑布模 型规定了各项软件工程 活动，其核心思想是按 工序将问题化简，将功 能的实现与设计分开， 便于分工协作，即采用 结构化的分析与设计方 法将逻辑实现与物理实 现分开。
2020/5/4
3.1 软件开发生命周期
❖ (5) 软件测试（Software Testing）
团队人员：测试人员、开发人员、用户等。
测试是保证软件质量的重要手段，其主要目的是通过软件测试暴露 出软件中隐藏的错误和缺陷。软件测试的主要方式是在设计测试用 例的基础上检验软件的各个组成部分。软件测试一般包括单元测试、 集成测试、系统测试、验收测试等几个阶段。首先进行单元测试， 查找各模块或类在功能和结构上存在的问题并加以修改，这个过程 会反复进行；其次进行集成测试，验证各软件单元集成后形成的模 块能否达到概要设计规格说明中各模块的设计目标；然后进行系统 测试，目的是对最终软件系统进行全面的测试，确保最终软件系统 满足产品需求并且遵循系统设计；最后进行确认测试，以检查已实 现的软件是否满足了需求规格说明书中确定的各种需求，包括功能 需求和性能需求，决定已开发的软件能否交付用户使用。
第18页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型的缺点：
(1) 在项目各个阶段之间极少有反馈，往往会将早期的 错误引入到后期各个阶段。
(2) 依赖于早期进行的唯一一次需求调查，用户参与较 少，不能适应需求的变化。
(3) 只有在项目生命周期的后期才能看到结果，可能与 用户的需求出现很大的偏差，使风险推迟到项目开发 的后期阶段才显露出来，因而失去及早纠正的机会。
3.2 软件开发模型
❖ 迄今为止，出现了多种软件开发模型。如：
瀑布模型 螺旋模型 演化模型 喷泉模型 智能模型 增量模型 原型化模型
第13页
2020/5/4
3.2.1 瀑布模型
❖瀑布模型将软件生命周期划分为制 定开发计划、需求分析和定义、软 件设计、程序编写、软件测试和运 行维护等六个基本活动，并且规定 了它们自上而下、相互衔接的固定 次序，如同瀑布流水，逐级下落。
各项需求转换成相应的软件体系结构。结构中的每一成份都是意义 明确的子系统、模块或用例，每个部分都和某些需求相对应，进行 所谓的概要设计。然后对每个模块或用例要完成的工作采用合适的 技术进行具体的描述，如画出模块的程序流程图或描述类的属性、 操作等，为源程序的编写工作打下基础，即所谓的详细设计。
第7页
设计
编码
测试
集成
反馈 交付用户
需求分析
设计
编码
测试
集成
反馈 交付用户
……
迭代n
Biblioteka Baidu
需求分析
设计
编码
测试
集成
交付用户
第23页
2020/5/4
3.2.2 演化模型
❖ 演化模型的主要优点：
(1) 用户能在开发过程中而不是开发接近尾声时看到自 己所需要的软件产品。对发现的问题能够提早解决。
(2) 在一定程度上减少了软件开发活动的盲目性。如果 在某次迭代中，其需求没有满足用户的要求，软件开 发人员可根据用户的反馈信息在下一次迭代中予以修 正。
第3章 软件系统开发方法
❖ 3.1 软件开发生命周期 ❖ 3.2 软件开发模型 ❖ 3.3 传统软件开发方法 ❖ 3.4 面向对象软件开发方法 ❖ 3.5 RUP统一软件开发过程 ❖ 3.6 敏捷软件开发技术
第1页
2020/5/4
❖ 在软件开发的早期，人们常用的软件开发方法是边写边改法。这种开发 方法在应用开发中最为快捷，但由于其开发的随意性，因而也最为低效。 同时，使用该方法的项目常常因为管理失控而终结。基于这种情况，业 界人士借鉴其它工程领域的方法，提出了许多有规则可言的软件系统开 发方法。最著名的当数“瀑布式”方法了，即把软件开发过程分解成这 样一些阶段：制定开发计划、需求分析和定义、系统设计、编码实现、 测试验证。然而，在软件开发实践中完全遵循这种过程取得成功的案例 并不多。其原因主要在于这种方法有一个前提条件，那就是系统需求必 须明确、不变。但在现实应用中，这几乎是不可能的。需求通常模糊不 清，并且在系统开发期间随时都有可能发生变化。因此软件开发要求采 用的方法过程也必须能适应这种变化，这就出现了其它一些软件开发方 法，如原型法、敏捷方法等。
第9页
2020/5/4
3.1 软件开发生命周期
❖ (6) 运行/维护（Running/Maintenance）
团队人员：系统支持人员等。 已交付的软件投入正式使用，软件便进入运行
阶段。软件在运行过程中可能会因为发现了软 件中存在的错误需要修改；或为了适应变化了 的软件工作环境，需做一些变更；或为了增强 软件的功能需做变更等。这就称为软件维护。
累计费用
制定目标 选择方案 设定约束条件
各步骤的进度 风险分析
风险分析
评估方案 识别并排除风险
风险分析
风险
分析 原型 1
需求计划、生 命周期计划 操作概念
原型 2 软件
开发计划 需求
需求
确认
集成与测
设计确认
试计划
与验证 验
计划下一阶段
收 测
实施
试
原型 3
可运行原型
模拟
软件产 品设计
详细设计
模型 基准
(3) 如果没有一定的约束条件，可能永远无法 得到一个最终的软件产品。
第25页
2020/5/4
3.2.2 演化模型
❖ 采用演化模型的软件开发过程，实际上是从最初 的原型逐步演化成最终软件产品的过程。在整个 演化过程中，不断修正缺陷，以开发出最终满足 用户需要的软件产品。
❖ 演化模型特别适用于用户需求不够明确的软件开 发项目，但不适宜用于大而复杂的系统。
软件计划 需求分析和定义 软件设计 实现 测试 运行维护
第15页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型每项开发活动均应具有下述特征：
(1) 从上一项活动接收本项活动的工作对象，作为本项 活动的输入；
(2) 利用这一输入实施本项活动应完成的任务； (3) 给出本项活动的工作成果，作为输出传递给下一项
编码
单
(4) 通过过多的强制完成日期和里程碑来跟踪各个项目 阶段，灵活性较差。
第19页
2020/5/4
3.2.1 瀑布模型
❖ 瀑布模型缺乏灵活性，无法通过开发活动来理清本来不够明 确的需求，这将可能导致直到软件开发完成时才发现所开发 的软件并非用户所需要的，此时必将付出高额的代价才能纠 正出现的偏差。
❖ 瀑布模型一般适用于功能、性能明确、完整、无重大变化的 软件系统的开发。如操作系统、编译系统等系统软件的开发。