软件工程第2章软件生存周期及其模型
- 格式：pptx
- 大小：591.79 KB
- 文档页数：45
下载文档原格式
合集下载
第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
- 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）上，首次提出了“软件工程” 的概念。提出了在软件生产中采用工程化的方法， 采用一系列科学的、现代化的方法技术来开发软件。 这种工程化的思想贯穿到软件开发和维护的全过程。