软件工程第2章软件生存周期及其模型
合集下载
第2 章软件生存周期及开发模型
2.2 典型的软件过程模型
2.2 典型的软件过程模型
2.2 典型的软件过程模型
2.2 典型的软件过程模型
2.3 面向对象的软件过程模型
统一开发过程（RUP）
2.3 面向对象的软件过程模型
1．初始阶段：为系统建立业务用例和确定项目的边界 2．细化阶段：分析问题域，建立健全的体系结构基础， 编制项目计划，淘汰项目中最高风险的元素 3．构建阶段：所有剩余的构件和应用程序功能被开发并 集成为产品，所有的功能被详尽的测试。这个阶段的重点 在管理资源和控制运作以优化成本、日程、质量生产过程。 4．交付阶段：完成最后的软件产品和产品验收测试，并 编制用户文档，进行用户培训等，将软件产品交付给用户 群体
2.1.2 软件过程模型
软件过程:是整个软件生存周期中一系列有序的软件 生产活动的流程。为了能高效地开发一个高质量的软 件产品，通常把软件生存周期中各项开发活动的流程 用一个合理的框架 —— 开发模型来规范描述，这就是 软件过程模型，也称为软件生存周期模型。
过程模型: 能够清晰、直观地表达软件开发的 全过程，明确规定了要完成的主要活动和任务， 是软件项目工作的基础。 建模: 是软件过程中最常使用的技术手段之一。
极限编程过程
第2章软件生存周期及开发模型
1．策划：策划活动开始于建立一系列描述待 开发软件的必要特征与功能的“故事”。每个 故事由客户书写并置于一张索引卡上，客户根 据对应特征或功能的全局业务价值标明权值( 即优先级)。 (1)所有选定故事将在几周之内尽快实现； (2)具有最高价值的故事将移到进度表的前 面并首先实现； (3)高风险故事将首先实现。
2.3 面向对象的软件过程模型
第2章 软件生存周期及开发模型
第2章 软件生存周期及开发模型
软件工程与方法 软件生存周期与软件过程
简化的螺旋模型图
35
螺旋模型
螺旋模型将瀑布模型与增量模型结合 起来，加入了两种模型均忽略了的风 险分析，弥补了这两种模型的不足。 螺旋模型是一种风险驱动的模型。 螺旋模型将开发过程分为几个螺旋周 期，每个螺旋周期大致和瀑布模型相 符合。 螺旋模型适合于大型软件的开发。
36
制定计划
螺旋模型
风险分析
(1)原型系统只包括未来系统的主要功能及
接口 (2)开发原型系统应尽量使用能开发周期短 的语言和工具。
23
原型范型
听取用户 意见 建造/修改 原型
用户测试 运行原型
24
原型模型分类
原型是项目系统中的一个方面或者 多个方面的工作模型。 抛弃型原型：用于试验某些概 念，试验完系统将无用处。 进化型原型：原型系统不断被开 发和被修正，最终它变为一个真 正的系统。
31
增量模型图
把软件看作一系列相互联系的增量，每次迭代完成一个增量
构件1： 需求 设计 实现和集成 交付客户
构件2：
需求
设计
实现和集成
交付客户
构件3：Βιβλιοθήκη 需求设计实现和集成
交付客户
规格说明组 设计组 实现和集成组 构件n： 需求 设计 实现和集成 交付客户
32
增量模型的特点
增量
小而可用的软件 第1个增量通常是软件的核心部分 在前面增量的基础上开发后面的增量 每个增量的开发可用瀑布或快速原型模型 每个增量开发的顺序性和总体的迭代性相结 合 难度较大或需要使用新硬件的部分可以放在 较后的增量中开发
15
2.2.1.瀑布模型
定义 可行性研究与计划 需求分析 设计 开 发 编码 测试 维护 运行维护
《软件工程实用教程》第2章软件生存周期及开发模型
第2章軟體生存週期及開發模型
本章學習內容： 1．掌握軟體的生存（生命）週期的概念 2．明確學習軟體過程模型的意義 3．掌握各種過程模型的特點與適用範圍 4．掌握面向對象軟體過程模型的內容與過 程
第2章軟體生存週期及開發模型
2. 1 軟體過程概述
2.1.1 軟體生存週期
軟體的生存週期指軟體產品從功能確 定、設計、開發成功、投入使用，並 在使用中不斷修改、完善，直至被新 的軟體所替代而停止該軟體的使用的 全過程。
第2章軟體生存週期及開發模型
2.2.4 螺旋模型
第2章軟體生存週期及開發模型
改進的瀑布模型
第2章軟體生存週期及開發模型
2.2.2 原型模型
1．快速原型方法 快速原型方法是原型模型在軟體分析、設計 階段的應用，用來解決用戶對軟體系統在需 求分析上的模糊認識。 快速原型法的特點： 快速原型是用來獲取用戶需求的，或是用來 試探某種設計是否有效。一旦需求或設計確 定下來，原型就將被拋棄。
第2章軟體生存週期及開發模型
瀑布模型的缺點 階段與階段劃分固定，階段間產生大量的文檔， 極大地增加了工作量； 由於開發模型呈線性，當開發成果尚未經過測試 時，用戶無法看到軟體的效果，這些問題往往會 導致開發出來的軟體不是用戶真正需要的軟體； 無法通過開發活動澄清本來不夠確切的軟體需求， 因此，需要返工或者不得不在維護中糾正需求的 偏差； 由於固定順序，前期工作中造成的差錯越到後期 階段所造成的損失越大，為了糾正偏差，需要付 出高昂的代價。
第2章軟體生存週期及開發模型
2.2 典型的軟體過程模型
軟體過程模型 把軟體生存週期中各項開發活動的流程用一 個合理的框架——開發模型來規範描述，這 就是軟體過程模型 。 軟體過程模型是從一個特定的角度表現一個 過程，主要根據軟體的類型、規模，特別是 軟體的開發方法、開發環境等多種因素確立 過程模型。
本章學習內容： 1．掌握軟體的生存（生命）週期的概念 2．明確學習軟體過程模型的意義 3．掌握各種過程模型的特點與適用範圍 4．掌握面向對象軟體過程模型的內容與過 程
第2章軟體生存週期及開發模型
2. 1 軟體過程概述
2.1.1 軟體生存週期
軟體的生存週期指軟體產品從功能確 定、設計、開發成功、投入使用，並 在使用中不斷修改、完善，直至被新 的軟體所替代而停止該軟體的使用的 全過程。
第2章軟體生存週期及開發模型
2.2.4 螺旋模型
第2章軟體生存週期及開發模型
改進的瀑布模型
第2章軟體生存週期及開發模型
2.2.2 原型模型
1．快速原型方法 快速原型方法是原型模型在軟體分析、設計 階段的應用，用來解決用戶對軟體系統在需 求分析上的模糊認識。 快速原型法的特點： 快速原型是用來獲取用戶需求的，或是用來 試探某種設計是否有效。一旦需求或設計確 定下來，原型就將被拋棄。
第2章軟體生存週期及開發模型
瀑布模型的缺點 階段與階段劃分固定，階段間產生大量的文檔， 極大地增加了工作量； 由於開發模型呈線性，當開發成果尚未經過測試 時，用戶無法看到軟體的效果，這些問題往往會 導致開發出來的軟體不是用戶真正需要的軟體； 無法通過開發活動澄清本來不夠確切的軟體需求， 因此，需要返工或者不得不在維護中糾正需求的 偏差； 由於固定順序，前期工作中造成的差錯越到後期 階段所造成的損失越大，為了糾正偏差，需要付 出高昂的代價。
第2章軟體生存週期及開發模型
2.2 典型的軟體過程模型
軟體過程模型 把軟體生存週期中各項開發活動的流程用一 個合理的框架——開發模型來規範描述，這 就是軟體過程模型 。 軟體過程模型是從一個特定的角度表現一個 過程，主要根據軟體的類型、規模，特別是 軟體的開發方法、開發環境等多種因素確立 過程模型。
软件工程 第2章_软件生存周期及其模型
典型的软件生存周期包括以下阶段： 典型的软件生存周期包括以下阶段：
5. 编码 6. 测试 7. 软件维护
基本任务： 基本任务 ： 通过各种必要的维 护活动使系统持久地满足用户 需要， 需要 ， 是软件生存周期中时间 最长的阶段。 最长的阶段。 结பைடு நூலகம்标准： 结束标准 ： 以某种程序设计语 言表示的源程序清单。 言表示的源程序清单。
软件过程模型
• 软件过程模型是软件开发全过程、软件开 软件过程模型是软件开发全过程、 发活动以及它们之间关系的结构框架 • 软件项目的管理提供里程碑和进度表 • 为软件开发提供原则和方法
五类软件开发过程模型
1. 以软件需求完全确定为前提的瀑布模型 以软件需求完全确定为前提的瀑布模型 2. 在软件开发初期只能提供基本需求所采用 的渐进式开发模型如原型模型 螺旋模型、 原型模型、 的渐进式开发模型如原型模型、螺旋模型、 增量模型、 增量模型、并发开发模型 3. 以形式化开发方法为基础的变换模型 以形式化开发方法为基础的变换模型 4. 基于构件的开发过程 5. 敏捷开发过程 统一软件开发过程 敏捷开发过程---统一软件开发过程 统一软件开发过程RUP
瀑布模型的缺点
• 项目开始阶段用户很难精确的提出产品需求， 项目开始阶段用户很难精确的提出产品需求， 由于技术进步，用户对系统深入的理解， 由于技术进步，用户对系统深入的理解，修改 需求十分普遍。 需求十分普遍。 • 项目开发晚期才能得到程序的运行版本，这时 项目开发晚期才能得到程序的运行版本， 修改软件需求和开发中的错误代价很大。 修改软件需求和开发中的错误代价很大。 • 采用线性模型组织项目开发经常发生开发小组 人员“堵塞状态” 特别是项目的开始和结束。 人员“堵塞状态”，特别是项目的开始和结束。
软件工程第二章 软件生存周期及模型
13
13
5、瀑布模型特点 是一个理想化过程。会掩饰项目中真正的风险，当你 太晚发现它们时已无济于事。 过程逆转性很差，因为上游的错误会在下游进 行发散性传播。所以逆转会造成很大损失。 缺乏灵活性;特别是无法解决软件需求不明确或 不准确的问题后期错误，修正代价高 。
纯瀑布模型的缺点是在项目开始的时候，在设 计工作完成前和代码写出来前，很难充分描述 需求。
被审文档、开审查会、返工、复查。
❖管理复审的主要任务是在软件生存周期的每个 重要的里程碑，对工程项目的成本、实际花费的 经费、投资回收的前景、项目的进度等经济因素 从管理角度进行审查。从管理角度对软件开发工 程进行复审，是对工程进行管理和控制的主要手 段，对发现的问题可以及时采取措施加以解决， 2021/8必/5 要时甚至可以取消开发工程以避免更大的损失。12 12
它是一个记号，只需经过内部评审。它是一个检查点，但不一定是基线。
评审
审计
顾客>客 户>用户 现有系统 目标系统
2021/8/5
是对软件工作产品质量的一次开会或汇签活动。
是复查评审活动程序的合法性，是否按程序与规范进行。
客户是顾客的一部分，顾客包括潜在的客户。用户是软件产品的最终使 用者，用户是客户的一部分。 现有系统是用户当前正在使用的系统（可能是手工系统）；目标系统是 将要实现的系统。
2021/8/5
27
27
五、原型模型----概念
快速原型模型：先开发一个“原型”软件，完成主
瀑布模型最主要的问题是缺乏灵活性。必须在 项目开始前说明全部需求。但这恰恰是非常困 难的。
2021/8/5
14
14
6、瀑布模型适用场合
当有一个稳定的产品定义和很容易被理解的技术解决方案 时，纯瀑布模型特别合适
13
5、瀑布模型特点 是一个理想化过程。会掩饰项目中真正的风险，当你 太晚发现它们时已无济于事。 过程逆转性很差，因为上游的错误会在下游进 行发散性传播。所以逆转会造成很大损失。 缺乏灵活性;特别是无法解决软件需求不明确或 不准确的问题后期错误，修正代价高 。
纯瀑布模型的缺点是在项目开始的时候，在设 计工作完成前和代码写出来前，很难充分描述 需求。
被审文档、开审查会、返工、复查。
❖管理复审的主要任务是在软件生存周期的每个 重要的里程碑，对工程项目的成本、实际花费的 经费、投资回收的前景、项目的进度等经济因素 从管理角度进行审查。从管理角度对软件开发工 程进行复审，是对工程进行管理和控制的主要手 段，对发现的问题可以及时采取措施加以解决， 2021/8必/5 要时甚至可以取消开发工程以避免更大的损失。12 12
它是一个记号，只需经过内部评审。它是一个检查点，但不一定是基线。
评审
审计
顾客>客 户>用户 现有系统 目标系统
2021/8/5
是对软件工作产品质量的一次开会或汇签活动。
是复查评审活动程序的合法性，是否按程序与规范进行。
客户是顾客的一部分，顾客包括潜在的客户。用户是软件产品的最终使 用者，用户是客户的一部分。 现有系统是用户当前正在使用的系统（可能是手工系统）；目标系统是 将要实现的系统。
2021/8/5
27
27
五、原型模型----概念
快速原型模型：先开发一个“原型”软件，完成主
瀑布模型最主要的问题是缺乏灵活性。必须在 项目开始前说明全部需求。但这恰恰是非常困 难的。
2021/8/5
14
14
6、瀑布模型适用场合
当有一个稳定的产品定义和很容易被理解的技术解决方案 时，纯瀑布模型特别合适
软件工程(概论)生存期和开发模型-作业2
发散性传播的原理，所以逆转将会延误工期，增加成本，造成重大损失。
2.3 软件开发模型
4．模型的优点 开发阶段清晰，便于评审、审计、跟踪、管理和控制。
5．模型的缺点 传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布
只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期，出现“问题堆积”，更可怕的是，错
一阶段（活3）动用的户输使入用，环继境续很进稳行定下；一阶段的活动，否则返回上一阶段修改。 （4）用户除提出需求以外，很少参与开发工作。
2．模瀑型布的模特型点认为：项目经理或软件管理人员，只要控制好每级台阶的高度 （和1宽）度里，程在碑每或个基台线阶驱处动设，立或里者程说碑文或档基驱线动，；并组织好对基线的评审与审 （计2，）就过可程以逆控转制性好很项差目或的者开说发不成可本逆、转进，度因和为质根量据。上游的错误会在下游进行
误的传递会采取发散扩大的方式。
瀑布模型反馈环
CMM/CMMI采取阶段评审和不符合项(Noncompliance Items)的动态跟踪制度， 只有前一阶段不符合项全部改正，才允许开发人员进入后一阶段工作。
不符合项，就是在评审中发现的问题项，它不同于Bug。对于这些不符合项，软 件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底 。
可行性研究的结果是负责人作出是否继续进行这项工程的决定的重要依据。 可行性研究以后的各个阶段，将需要投入多少相应的人力物力。 及时终止不值得投资的工程项目，可以避免更大的浪费。
2.2 软件工程过程
3. 需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须 具备哪些功能。产生《需求规格说明书》。
2.3 软件开发模型
4．模型的优点 开发阶段清晰，便于评审、审计、跟踪、管理和控制。
5．模型的缺点 传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布
只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期，出现“问题堆积”，更可怕的是，错
一阶段（活3）动用的户输使入用，环继境续很进稳行定下；一阶段的活动，否则返回上一阶段修改。 （4）用户除提出需求以外，很少参与开发工作。
2．模瀑型布的模特型点认为：项目经理或软件管理人员，只要控制好每级台阶的高度 （和1宽）度里，程在碑每或个基台线阶驱处动设，立或里者程说碑文或档基驱线动，；并组织好对基线的评审与审 （计2，）就过可程以逆控转制性好很项差目或的者开说发不成可本逆、转进，度因和为质根量据。上游的错误会在下游进行
误的传递会采取发散扩大的方式。
瀑布模型反馈环
CMM/CMMI采取阶段评审和不符合项(Noncompliance Items)的动态跟踪制度， 只有前一阶段不符合项全部改正，才允许开发人员进入后一阶段工作。
不符合项，就是在评审中发现的问题项，它不同于Bug。对于这些不符合项，软 件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底 。
可行性研究的结果是负责人作出是否继续进行这项工程的决定的重要依据。 可行性研究以后的各个阶段，将需要投入多少相应的人力物力。 及时终止不值得投资的工程项目，可以避免更大的浪费。
2.2 软件工程过程
3. 需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须 具备哪些功能。产生《需求规格说明书》。
软件生存周期及开发模型
据模型PDM 据模型PDM
面向对象的编程工具,在软件企业强大的类库,构件库 面向对象的编程工具,在软件企业强大的类库, 的支撑下,快速地实现需求分析中确认的流程,功能, 的支撑下,快速地实现需求分析中确认的流程,功能, 性能和接口 交付给用户试用,反复循环几次, 交付给用户试用,反复循环几次,直到客户确认满意为 止.
9
增量模型(续) 增量模型(
选择模型的条件 条件: 3,选择模型的条件: 接受分阶段交付. 在项目开发过程中,客户接受分阶段交付 (1)在项目开发过程中,客户接受分阶段交付. (2)开发人员对应用领域不熟悉,难以一步到位. 开发人员对应用领域不熟悉,难以一步到位. 工期过紧的中等或高风险项目 中等或高风险项目. (3)工期过紧的中等或高风险项目. 用户可参与到整个软件开发过程中 到整个软件开发过程中. (4)用户可参与到整个软件开发过程中. 面向对象语言. 使用面向对象语言 (5)使用面向对象语言. 软件公司自己有较好的类库 构件库. 类库, (6)软件公司自己有较好的类库,构件库.
6
瀑布模型(续) 瀑布模型(
3,选择模型的条件: 选择模型的条件 条件: 很少变化. (1)在开发时间内需求没有或很少变化. 在开发时间内需求没有或很少变化 (2)分析设计人员对应用领域很熟悉. 分析设计人员对应用领域很熟悉 领域很熟悉. (3)低风险项目(对目标,环境很熟悉). 低风险项目(对目标,环境很熟悉). (4)用户使用环境很稳定. 用户使用环境很稳定 稳定. 用户除提出需求以外 很少参与开发. 除提出需求以外, (5)用户除提出需求以外,很少参与开发.
12
原型模型(续) 原型模型(
选择模型的条件 条件: 3,选择模型的条件: 已有产品或产品的原型 只需客户化的项目. 或产品的原型, (1)已有产品或产品的原型,只需客户化的项目. 简单而熟悉的行业或领域 或领域. (2)简单而熟悉的行业或领域. 有快速原型开发工具 开发工具. (3)有快速原型开发工具. (4)进行产品移植或升级. 进行产品移植或升级 移植或升级. 4,优点 开发速度快 开发速度快 实时反馈用户意见 实时反馈用户意见 模型的缺点 不利于开发人员的 缺点: 开发人员的创新 5,模型的缺点:不利于开发人员的创新
第2章 软件生存期模型
➢ 每个构件由多个相互作用的模块构成，并且能够 完成特定的功能。
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
软件工程 第2章 软件生存周期与软件过程 CUMT 11-07-26
课件制作人：谢希仁
课件制作人：谢希仁
螺旋模型的限制条件 （1）螺旋模型强调风险分析，但要求许多客户 接受和相信这种分析，并做出相关反应是不容 易的，因此，这种模型往往适应于内部的大规 模软件开发。 （2）如果执行风险分析将大大影响项目的利润， 那么进行风险分析毫无意义，因此，螺旋模型 只适合于大规模软件项目。 （3）软件开发人员应该擅长寻找可能的风险， 准确地分析风险，否则将会带来更大的风险。
2.2.1边做边改模型
遗憾的是，许多产品都是使用“边做边改” 模型来开发的。在这种模型中，既没有规格说 明，也没有经过设计，软件随着客户的需要一 次又一次地不断被修改。
课件制作人：谢希仁
2.2.2瀑布模型
1970年Winston Royce提出了著名的"瀑布 模型"，直到80年代早期，它一直是唯一被广泛 采用的软件开发模型。 该模型将基本的过程活动、描述、开发、 有效性验证和进化，看成是一些界限分明的独 立的过程阶段，如：需求描述阶段、软件设计 阶段、实现阶段、测试阶段等。 该模型也可以看成是软件的生命周期模型。 该模型是计划驱动的，理论上，在开始工 作之前，必须对所有的过程活动制定计划并给 出进度安排。
5.测试 单元测试，查找各模块在功能和结构上存在的问题并加 以纠正。 组装测试，将已测试过的模块按一定顺序组装起来。
按规定的各项需求，逐项进行有效性测试，决定已开发 的软件是否合格，能否交付用户使用。
课件制作人：谢希仁
2.1.3运行时期
运行时期的主要工作是维护
改正性维护 运行中发现了软件中的错误需要修正。 适应性维护 为了适应变化了的软件工作环境，需做适当变更。 完善性维护
课件制作人：谢希仁
2.2.2瀑布模型
《软件工程》第二章软件生命周期及软件开发模型
喷泉模型该模型表明软件开发活动之间没 有明显的间隙，用于支持面向对象开发过程。 由于对象概念的引入，使分析、设计、实现之 间的表达没有明显间隙。并且，这一表达自然 地支持复用。
谢谢聆听
共同学习相互提高
•问题定义 可行性
问题计划 开发时期
运行时期
2.2.1 瀑布模型
•需求分析
•总体设计
•详细设计
•编码
•测试
维护
图2.2 瀑布模型
2.2.2 演化模型
需
求 设 计 编 码 测 试 集 成
需 求
设 计
编 码
测 试
集 成
需 求
设 计
编 码
测 试
集 成
2.2.3 原型模型
开始
需求采集细化
停止
产品
快速
样本
可行性研究 需求分析 概要设计 详细设计
实现 调试 维护 退役 图 2.1 软 件 生 命 周 期
2。2软件开发生命周期过程和活动
软件生命周期过程的IEEE（美国电气电子工程师学 会 IEEE）标准描述了一系列活动和过程，对于[IEEE Std．1074-1995]的软件的开发和和维护来说这些活动 是强制性的。它的目标是为开发生命周期模型建立一 个通用框架。在这一节，我们描述由这一标准引入的 主要过程和活动。
设计
对原型
建造
加工
原型
用户评价原型 原型
指定计划： 决定目标 方案限制
提交线 评审
客户评价
2.2.4 螺旋模型
累计成本
需求计划 生存期 计划
开发计划
组装测试
风险分析
风险分析
风险分析
原型 3
原型 2
原型 1
谢谢聆听
共同学习相互提高
•问题定义 可行性
问题计划 开发时期
运行时期
2.2.1 瀑布模型
•需求分析
•总体设计
•详细设计
•编码
•测试
维护
图2.2 瀑布模型
2.2.2 演化模型
需
求 设 计 编 码 测 试 集 成
需 求
设 计
编 码
测 试
集 成
需 求
设 计
编 码
测 试
集 成
2.2.3 原型模型
开始
需求采集细化
停止
产品
快速
样本
可行性研究 需求分析 概要设计 详细设计
实现 调试 维护 退役 图 2.1 软 件 生 命 周 期
2。2软件开发生命周期过程和活动
软件生命周期过程的IEEE（美国电气电子工程师学 会 IEEE）标准描述了一系列活动和过程，对于[IEEE Std．1074-1995]的软件的开发和和维护来说这些活动 是强制性的。它的目标是为开发生命周期模型建立一 个通用框架。在这一节，我们描述由这一标准引入的 主要过程和活动。
设计
对原型
建造
加工
原型
用户评价原型 原型
指定计划： 决定目标 方案限制
提交线 评审
客户评价
2.2.4 螺旋模型
累计成本
需求计划 生存期 计划
开发计划
组装测试
风险分析
风险分析
风险分析
原型 3
原型 2
原型 1
实用软件工程第2章PPT课件
25
快速原型法选择的条件
项目组中有数据库分析和设计的专家，有 面向对象编程的专家，文档制作有成熟的 模板，而且系统或项目又不是非常大。
软件有一个孕育、诞生、成长、成熟、衰 亡的生存过程。这个过程即为计算机软件 的生存期 软件生存期9个步骤：立项（或签合同、 下达任务书）、需求分析、概要设计、详 细设计、编码实现、软件测试、软件发布 与实施、软件维护和版本更新或退役。
4
软件生存周期示意图
计划时期
立项、下达任务书 需求分析
开发时期
概要设计 详细设计 编码实现 软件测试 软件发布与实施
15
瀑布模型的特征
阶段间的顺序性和依赖性 推迟实现的观点 质量保证的观点
16
瀑布模型的特点：
(1) 里程碑或基线驱动，或者说文档驱动； (2) 过程逆转性很差，或者说不可逆转。
17
选择模型的条件：
不是任何软件都可以采用瀑布模型的，软件项 目或产品选择瀑布模型，必须满足下列条件： （1）在开发时间内需求没有或很少变化。 （2）分析设计人员对应用领域很熟悉。 （3）低风险项目（对目标、环境很熟悉）。 （4）用户使用环境很稳定。 （5）用户除提出需求以外，很少参与开发。
22
原型模型特点：
(1)原型驱动。开发者必须先有一个原型。 (2)与迭代模型相同点是反复循环几次， 直到客户确认为止。不同点是原型模型 事先有一个展示性的产品原型，而迭代 模型可能没有。
23
原型模型的缺点：
因为事先有一个展示性的产品原型，所 以在一定程度上，不利于开发人员的创 新。
24
快速原型法
由于原型模型的开发速度较快，有时也将它称做 快速原型法（Rapid Prototyping）。在开发 工具和开发环境迅速发展的今天，在信息系统开 发中，原型法和快速原型法又被赋予新的内容： 事先没有原型产品，也可以采取这种办法。基本 思路是：采用以面向数据为主的方法，在需求分 析的基础上，利用Power Designer等数据库分 析和设计工具，快速建立信息系统的概念数据模 型CDM和物理数据模型PDM；然后利用面向对 象的编程工具，在软件企业强大的类库、构件库 的支撑下，快速地实现需求分析中确认的流程、 功能、性能和接口；之后交付给用户试用，反复 循环几次，直到客户确认满意为止。
快速原型法选择的条件
项目组中有数据库分析和设计的专家，有 面向对象编程的专家，文档制作有成熟的 模板，而且系统或项目又不是非常大。
软件有一个孕育、诞生、成长、成熟、衰 亡的生存过程。这个过程即为计算机软件 的生存期 软件生存期9个步骤：立项（或签合同、 下达任务书）、需求分析、概要设计、详 细设计、编码实现、软件测试、软件发布 与实施、软件维护和版本更新或退役。
4
软件生存周期示意图
计划时期
立项、下达任务书 需求分析
开发时期
概要设计 详细设计 编码实现 软件测试 软件发布与实施
15
瀑布模型的特征
阶段间的顺序性和依赖性 推迟实现的观点 质量保证的观点
16
瀑布模型的特点：
(1) 里程碑或基线驱动，或者说文档驱动； (2) 过程逆转性很差，或者说不可逆转。
17
选择模型的条件：
不是任何软件都可以采用瀑布模型的，软件项 目或产品选择瀑布模型，必须满足下列条件： （1）在开发时间内需求没有或很少变化。 （2）分析设计人员对应用领域很熟悉。 （3）低风险项目（对目标、环境很熟悉）。 （4）用户使用环境很稳定。 （5）用户除提出需求以外，很少参与开发。
22
原型模型特点：
(1)原型驱动。开发者必须先有一个原型。 (2)与迭代模型相同点是反复循环几次， 直到客户确认为止。不同点是原型模型 事先有一个展示性的产品原型，而迭代 模型可能没有。
23
原型模型的缺点：
因为事先有一个展示性的产品原型，所 以在一定程度上，不利于开发人员的创 新。
24
快速原型法
由于原型模型的开发速度较快，有时也将它称做 快速原型法（Rapid Prototyping）。在开发 工具和开发环境迅速发展的今天，在信息系统开 发中，原型法和快速原型法又被赋予新的内容： 事先没有原型产品，也可以采取这种办法。基本 思路是：采用以面向数据为主的方法，在需求分 析的基础上，利用Power Designer等数据库分 析和设计工具，快速建立信息系统的概念数据模 型CDM和物理数据模型PDM；然后利用面向对 象的编程工具，在软件企业强大的类库、构件库 的支撑下，快速地实现需求分析中确认的流程、 功能、性能和接口；之后交付给用户试用，反复 循环几次，直到客户确认满意为止。
chap2-软件生存期
分析
设计
编码
测试
增量2
分析
设计
编码
测试
增量3
分析
设计
编码
测试
增量4
分析
设计
编码
测试
增量模型
� 增量
�小而可用的软件
� 特点
�在前面增量的基础上开发后面的增量 �每个增量的开发可用瀑布或快速原型模型 �迭代的思路
螺旋模型
螺旋模型
� 特点
� 瀑布模型+快速原型+风险分析 � 迭代过程
� 一个螺旋式周期
The Importance of Modeling
Less Important More Important
Paper Airplane
Fighter Jet
Software Teams Often Do Not Model
� Many software teams build applications approaching the problem like they were building paper airplanes � Start coding from project requirements � Work longer hours and create more code � Lacks any planned architecture � Doomed to failure � Modeling is a common thread to successful projects
� 规划
� 确定目标，选择方案，选定完成目标的策略
� 风险分析
� 风险角度分析该策略
� 原型开发
� 启动一个开发阶段
第二章 软件生存周期与软件过程
统计性 使用测
试
验证
2.5 统一过程和敏 捷过程
2.5.1统一过程
统一过程描述了软件开发中各个环节 应该做什么，怎么做，什么时候做以及为 什么要做，描述了一组以某种顺序完成的 活动。
统一过程在一个二维空间中描述软件 开发活动，水平轴代表时间，显示了动态 过程的一面。垂直轴代表过程静态的一面 其中活动代表怎么做，用产品表示做什么 ，用人员表示谁来做，用工作流表示什么 时候来描述。
2.3.1 增量模型（渐增模型） (Incremental Model)
先完成一个系统子集的开发，再按同样的开发 步骤增加功能 (系统子集),如此递增下去直至 满足全部系统需求。
系统的总体设计在初始子集设计阶段就应作出 设想。
增量1 需求
设计
和设计
交付客户
增量2
需求
设计 实现和集成
交付客房
增量3
统一过程有四个阶段
1.初始阶段
本阶段确定所设立的项目是否可行。
2.细化阶段
识别出剩余的大多数用例。对当前迭代的每个用例 进行细化，分析用例的处理流程，状态细节以及可能 发生的状态变化。
3.构造阶段
识别出剩余的用例。每一次迭代开发都是针对用例 进行分析，设计，编码，测试和集成的过程，所得到 的产品是满足项目需求的一个子集。由于细化阶段的 软件设计已经完成，这样各项目可以并行开发。
为保证软件质量，瀑布模型每一阶段必 须完成规定的文档，并对文档进行复审， 及早发现问题消除隐患。可参照下图如：
• 传统的瀑布模型过于理想化。事实上， 人在工作过程中不可能不犯错误。
• 在设计阶段可能发生规格说明文档中的 错误。
• 而设计上的缺陷或错误可能在实现过程 中显现出来。
第2章 软件生存周期与软件过程
增量模型
把软件看作一系列相互联系的增量，每次迭代完成一个增量
构件1： 需求 设计 实现和集成 交付客户
构件2：
需求
设计
实现和集成
交付客户
构件3：
需求
设计
实现和集成
交付客户
规格说明组 设计组 实现和集成组
构件n： 需求 设计 实现和集成 交付客户
增量模型的特点
增量
小而可用的软件
在前面增量的基础上开发后面的增量 每个增量的开发可用瀑布或快速原型模型 迭代的思路 先开发的增量往往是系统的核心部分
目标系统
转换模型
开发过程
确定形式化需求规格说明书 进行自动的程序变换 针对形式化开发记录进行测试 形式化软件开发方法
特点
形式化需求规格说明 变换技术
程序自动生成技术 确保正确
净室模型
增量1 需求
收集
盒结构 形式化 正确性 规约 设计 证明 测试计划
代码生成 与检查
统计性使 认证 用测试
极限编程
eXtreme Programming是一种轻量级的、敏捷 的软件开发方法 4个价值观
交流、简单、反馈、勇气
4个方面改善
加强交流、从简单做起、寻求反馈、勇于实事就是
完整团队、计划对策、测试、简单设计、结对编程、 小软件版本、设计改进、持续集成、代码共有、编 码标准、系统比喻、可持续的速度
净室模型
形式化的增量开发模型，在洁净状态下实现软件 开发团队熟悉形式化方法，中 制作 小型软件开发
5. 统一过程和敏捷过程
《软件工程》课件 第二章-软件生存周期及模型
模型适合的项目：
项目开始，明确了需求的大部分，但是需
求可能会发生变化
对于市场和用户把握不是很准，需要逐步
了解
对于有庞大和复杂功能的系统进行功能改
进，就需要一步一步实施的。
银行业务系统的生存期实例
项目规划
．银行业务需求 ．原形系统源代码 业务需求分析 产品阶段1设计 项目规划
产品阶段n设计
加工原型 客户评价原型
建造原型
原型开发过程
▲快速分析：分析人员与用户配合，迅速确定系统的基 本要求。要根据原型所要体现的特征，描述基本需求。 关键是要注意分析描述内容的选取。 ▲构造原型：在软件工具支持下尽快实现一个可运行的 系统。 ▲运行原型：是发现问题、消除误解、开发者与用户充 分协调的一个步骤。 ▲评价原型：评价原型的特性，纠正误解与错误，增添 新要求或提出要求变动，提出全面的修改意见。 ▲修改：原型开发的循环。
确认系统
把软件产品分解成一系列的增量构件，在增量开发迭代 中逐步加入。
每个构件由多个相互作用的模块构成，并且能够完成特
定的功能。 增量开发方法的新演进版本叫做 “极限程序设计 （eXtreme Programming）”。
增量模型
第一增量 第二增量 第三增量
……
核心功能
核心功能
核心功能
1
1
2
V模型:瀑布模型的细化－－对测试的展开
适合的项目
项目的需求在项目开始前很明确
解决方案在项目开始前也很明确
对系统的性能安全很严格的项目 类似的项目如：
航天飞机等 公司的财务系统
2.增量模型
定义 基本需求
将需求赋予 增量构件
第2章_软件生存周期与软件过程
形式化开发记录 与需求比较后 修正 变换n
……
形式化 规格说明 系统需求 变换2 测试 目标系统
变换1
图2.2 转换模型
2.4.2 净室模型（Cleanroom Model)
净室模型是一种形式化的增量开发模型。 该模型只适合于软件的形式化开发方法；需要 严格的数学理论和形式化技术支持；需要一整 套开发环境（如程序变换工具、定理证明工具 等）的支持。
2．细化阶段 细化阶段的目标是分析问题域，建立健全的体系结 构基础，编制项目计划，淘汰项目中最高风险的元素。 本阶段的具体目标如下： 确保软件结构、需求、计划足够稳定；确保项目风 险已经降低到能够预计完成整个项目的成本和日程的 程度； 针对项目的软件结构上的主要风险已经解决或处理 完成； 通过完成软件结构上的主要场景建立软件体系结构 的基线； 建立一个包含高质量构件的可演化的产品原型； 说明基线化的软件体系结构可保障需求可控制在合 理的成本和时间范围内； 建立好产品的支持环境。
2.5 统一过程和敏捷过程
2.5.1 统一过程(Rational Unified Process, RUP) ●RUP 是美国 Rational 公司（现被IBM 公司兼并， 称 IBM- Rational 公司）开发的一种支持UML建模 过程的软件工具。 ●RUP是以用例为驱动、以系统架构为中心的迭代 与增量过程。 ●RUP在一个二维空间中描述软件开发活动，水平 轴代表时间，显示了过程动态的一面，它将一个软件 生存周期分为4个阶段，包括初始、细化、构造和移 交阶段,每个阶段又可以分为多个迭代。
3．构造阶段 在构造阶段，所有剩余的构件和应用程序功能被开发 并集成为产品，所有的功能被详尽地测试。本阶段的 主要目标如下： 通过优化资源和避免不必要的返工达到开发成本的 最小化； 根据实际需要达到适当的质量目标； 据实际需要形成各个版本； 对所有必须的功能完成分析、设计、开发和测试工 作； 采用循环渐进的方式开发出一个可以提交给最终用 户的完整产品； 确定软件、站点和用户都为产品的最终部署做好了 相关准备； 达成一定程度上的并行开发机制。
《软件工程实用教程》第2章软件生存周期及开发模型
第期的概念 2．明确学习软件过程模型的意义 3．掌握各种过程模型的特点与适用范围 4．掌握面向对象软件过程模型的内容与过 程
第2章软件生存周期及开发模型
2. 1 软件过程概述
2.1.1 软件生存周期
软件的生存周期指软件产品从功能确 定、设计、开发成功、投入使用，并 在使用中不断修改、完善，直至被新 的软件所替代而停止该软件的使用的 全过程。
建立好产品的支持环境。
第2章软件生存周期及开发模型
3．构造阶段 在构造阶段，所有剩余的构件和应用程序功能被开发 并集成为产品，所有的功能被详尽地测试。本阶 段的主要目标如下：
通过优化资源和避免不必要的返工达到开发成本的最小化； 根据实际需要达到适当的质量目标； 据实际需要形成各个版本； 对所有必须的功能完成分析、设计、开发和测试工作； 采用循环渐进的方式开发出一个可以提交给最终用户的完 整产品； 确定软件、站点和用户都为产品的最终部署做好了相关准 备； 达成一定程度上的并行开发机制。
第2章软件生存周期及开发模型
2.2.4 螺旋模型
第2章软件生存周期及开发模型
2.2.4 螺旋模型
在笛卡尔坐标的4个象限上分别表达各方面的 活动：
制订计划：确定软件目标，选定实施方案， 弄清项目开发限制条件。 风险分析：分析所选方案，考虑如何识别和 消除风险。 实施工程：实施软件开发。 用户评估：评价开发工作，提出修正建议。
第2章软件生存周期及开发模型
2.2.3 增量模型
增量模型的工作流程
定义需求框架
开发增量构件 细化构件需求 设计构件
按照构件组成及其关系 设计软件系统体系结构
将构件集成进系统 验证系统
实现构件
否
系统已完 成 是 最终系统
第2章软件生存周期及开发模型
2. 1 软件过程概述
2.1.1 软件生存周期
软件的生存周期指软件产品从功能确 定、设计、开发成功、投入使用，并 在使用中不断修改、完善，直至被新 的软件所替代而停止该软件的使用的 全过程。
建立好产品的支持环境。
第2章软件生存周期及开发模型
3．构造阶段 在构造阶段，所有剩余的构件和应用程序功能被开发 并集成为产品，所有的功能被详尽地测试。本阶 段的主要目标如下：
通过优化资源和避免不必要的返工达到开发成本的最小化； 根据实际需要达到适当的质量目标； 据实际需要形成各个版本； 对所有必须的功能完成分析、设计、开发和测试工作； 采用循环渐进的方式开发出一个可以提交给最终用户的完 整产品； 确定软件、站点和用户都为产品的最终部署做好了相关准 备； 达成一定程度上的并行开发机制。
第2章软件生存周期及开发模型
2.2.4 螺旋模型
第2章软件生存周期及开发模型
2.2.4 螺旋模型
在笛卡尔坐标的4个象限上分别表达各方面的 活动：
制订计划：确定软件目标，选定实施方案， 弄清项目开发限制条件。 风险分析：分析所选方案，考虑如何识别和 消除风险。 实施工程：实施软件开发。 用户评估：评价开发工作，提出修正建议。
第2章软件生存周期及开发模型
2.2.3 增量模型
增量模型的工作流程
定义需求框架
开发增量构件 细化构件需求 设计构件
按照构件组成及其关系 设计软件系统体系结构
将构件集成进系统 验证系统
实现构件
否
系统已完 成 是 最终系统
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2.需求分析
3.概要设计 4.详细设计
基本任务：为了解决问题，目标系 统必须做什么？确定目标系统的功 能。 结束标准：给出软件需求说明书
典型的软件生存周期包括以下阶段：
1.可行性研究和项目开发计划
2.需求分析
3.概要设计 4.详细设计
基本任务：概括地说，应如何解决 这个问题？把确定的各项功能需求 转换成需要的体系结构。设计软件 的结构，确定程序由哪些模块组成 及模块间的关系，同时设计该项目 的总体数据结构和数据库结构。 结束标准：给出概要设计文档
软件工程过程
（Software engineering process）
规程与方法
有技能经过培 训的开发人员
过程
工具和设备
软件工程三要素
Байду номын сангаас
软件工程
工具
方法 过程
软件工程釆用层次化的方法,每个层次都包括过程、 方法、工具三要素。
软件生存周期
• 软件的生存周期是指一个软件从提出开发要求直 到该软件报废为止的整个时期。
目前典型的软件开发模型有：
瀑布模型、增量模型、原型模型、螺旋模型、 喷泉模型、变换模型和基于知识的模型等。
不同的开发方法有不同的软件过程模型。
软件过程模型
• 软件过程模型是软件开发全过程、软件开 发活动以及它们之间关系的结构框架
• 软件项目的管理提供里程碑和进度表 • 为软件开发提供原则和方法
五类软件开发过程模型
(目标与范围说明书)
(可行性论证论告) (需求说明书) (设计文档) (程序)
(测试报告)
瀑布模型
(维护报告)
瀑布模型主要思想
– 软件开发过程与软件生命周期是一致的 – 相邻二阶段之间存在因果关系 – 需对阶段性产品进行评审
瀑布模型的优点
• 软件生命周期模型,使软件开发过程可以在 分析、设计、编码、测试和维护的框架下 进行；
计划 时期
开发 时期
运行 时期
(目标与范围说明书) (可行性论证论告) (需求说明书) (设计文档) (源程序清单) (测试报告) (维护报告)
瀑布模型
常用的软件开发模型
软件开发模型是描述软件开发过程中各种活动如何 执行的模型。因此又称为软件过程模型。
软件过程模型是对软件开发实际过程的抽象和 简化。
软件工程过程
（Software engineering process）
是指在软件工具的支持下，所进行的一系列软 件开发和进化的活动。
通常包括以下四类基本过程： 1、软件规格说明：规定软件的功能及其运行环境。 2、软件开发：产生满足规格说明的软件。 3、软件确认：确认软件能够完成客户提出的要求。 4、软件演进：为满足客户的变更要求，软件必须在 使用的过程中演进。
• 软件开发过程具有系统性、可控性，克服 了软件开发的随意性 。
瀑布模型的缺点
• 项目开始阶段用户很难精确的提出产品需求， 由于技术进步，用户对系统深入的理解，修改 需求十分普遍。
1.可行性研究和项目开发计划
2.需求分析 3.概要设计 4.详细设计
基本任务：要解决的问题是什 么？该问题有行得通的解决办 法吗？若有，则需要多少费用、 资源、时间等？
结束标准：提出书面可行性研 究报告；若问题值得去解决， 制定项目开发计划。
典型的软件生存周期包括以下阶段：
1.可行性研究和项目开发计划
1. 以软件需求完全确定为前提的瀑布模型 2. 在软件开发初期只能提供基本需求所采用
的渐进式开发模型如原型模型、螺旋模型、 增量模型、并发开发模型 3. 以形式化开发方法为基础的变换模型 4. 基于构件的开发过程 5. 敏捷开发过程---统一软件开发过程RUP
计划 时期
开发 时期
运行 时期
瀑布模型
典型的软件生存周期包括以下阶段：
1.可行性研究和项目开发计划
2.需求分析
3.概要设计 4.详细设计
基本任务：应怎样具体地实现这个 系统？为每个模块完成的功能进行 具体描述，把功能描述转变为精确 的、结构化的过程描述。 结束标准：设计出程序的详细规格 说明书
典型的软件生存周期包括以下阶段：
5.编码 6.测试 7.软件维护
基本任务：为保证软件的质量， 在设计测试用例的基础上检验 软件的各个组成部分，是否达 到预定要求。
结束标准：软件合格，能交付 用户使用。
典型的软件生存周期包括以下阶段：
5. 编码 6. 测试 7. 软件维护
基本任务：通过各种必要的维 护活动使系统持久地满足用户 需要，是软件生存周期中时间 最长的阶段。
典型的软件生存周期包括以下阶段：
5. 编码 6. 测试 7. 软件维护
基本任务：把每个模块的控制 结构转换成计算机可接受的程 序代码。程序应是结构好、清 晰易读，并且与设计一致。
结束标准：以某种程序设计语 言表示的源程序清单。
典型的软件生存周期包括以下阶段：
5. 编码 6. 测试 7. 软件维护
结束标准：以某种程序设计语 言表示的源程序清单。
技术审查和管理复审
• 技术审查是从技术角度进行审查，是保证软件质量和 降低软件成本的重要措施。
• 技术审查通常由专家组成的审查小组来承担审查工作。
• 管理复审的主要任务实在软件生存周期的每个重要里 程碑，对工程项目的成本、实际花费的经费、投资回 收的前景、项目的进度等经济因素从管理角度进行审 查。
• 软件的生存周期一次划分为若干阶段，生存阶段 划分时应遵循的基本原则是各阶段的任务尽可能 相对独立，同一阶段各项任务的性质尽可能相同， 每一阶段都有明确的任务。
典型的软件生存周期包括以下阶段：
1.可行性研究和项目开发计划 2.需求分析 3.概要设计 4.详细设计
典型的软件生存周期包括以下阶段：
2.2 软件生存周期模型
• 软件生存周期模型是描述软件开发过程中各种活 动如何执行的模型。
• 软件生存周期模型的选择受软件规模、种类、开 发方式、开发环境以及开发使用的方法等因素影 响。
• 软件生存周期模型一旦确定，软件开发过程就应 该按照模型严格执行，不可随意更改。
软件生命周期（SDLD）—瀑布模型
2
第二章
生存周期及其模型
2.1 软件工程过程与软件生存期
为了克服软件危机，人们从其他产业的工业化 生产得到启示，于是在68年北大西洋公约的软件可 靠性会议（NATO）上，首次提出了“软件工程” 的概念。提出了在软件生产中采用工程化的方法， 采用一系列科学的、现代化的方法技术来开发软件。 这种工程化的思想贯穿到软件开发和维护的全过程。