软件工程课件第2章软件开发模型

Spiral 模型（Boehm， 1988提出）在结合了原型模 模型（ 提出） ， 提出 迭代特征和顺序模型的控制和系统化优点的基础 型迭代特征和顺序模型的控制和系统化优点的基础 增加了风险分析(risk analysis)。 上，增加了风险分析 。
瀑布模型+快速原型+风险分析 迭代过程
沿螺旋线顺时针迭代，每迭代一次， 沿螺旋线顺时针迭代，每迭代一次，螺旋线前进一 周，每一轮周期均包含风险分析 每一轮都采用原型作为减少风险的机制， 每一轮都采用原型作为减少风险的机制，用传统的 生存期开发方法进行工程化处理。 生存期开发方法进行工程化处理。 可以看作在每个阶段之前都增加了风险分析过程的 快速原型模型
增量1 增量1 规格说明 增量2 增量2 规格说明
设计
实现和集成
设计
实现和集成
交付客户第2 交付客户第2增量
拼写检查&语法检查 拼写检查&
增量3 增量3 规格说明
设计
实现和集成
交付客户第3 交付客户第3增量
高级页面排版功 能
增量4 增量4 规格说明
设计
实现和集成
交付客户第4 交付客户第4增量
delivery of 4th increment calendar time
典型的软件过程模型
瀑布模型 waterfall model 传统软件开发模型 快速原型 rapid prototype model 增量模型incremental model 增量模型 软件演化模型 螺旋模型spiral model 螺旋模型 面向对象开发模型 喷泉模型fountain model 喷泉模型 构件集成模型 component integration model 形式化方法模型 转换模型transformational model 转换模型 净室模型cleanroom model 净室模型 目录
思想：渐增式或迭代开发
演化模型是利用一种迭代的思想方 是利用一种迭代的思想方 是利用一种迭代 它的特征是使软件工程师渐进 法，它的特征是使软件工程师渐进 开发逐步完善的软件版本。 地开发逐步完善的软件版本。
增量模型 (Incremental Model) 螺旋模型 (Spiral Model)
目录
2.3软件演化模型
(1)增量模型 (2)螺旋模型
2.4面向对象开发模型
基于构件的开发方法
2.5 形式化方法模型
净室模型
软件过程&软件过程模型 软件过程 软件过程模型
软件过程
软件开发机构(企业 为开发高质量软件所需完成的一 软件开发机构 企业)为开发高质量软件所需完成的一 企业 系列任务的框架步骤。 系列任务的框架步骤。
第二章 软件开发模型
Software Process Model
瀑布模型 快速原型模型 增量模型 螺旋模型 基于构件的开发方法 净室模型
目录
2.0软件过程&软件过程模型 2.1瀑布模型
软件生存周期的瀑布模型 各阶段文档 瀑布模型的特点 瀑布模型存在的问题
2.2快速原型模型
模型 原型系统的注意事项 原型模型的分类 原型模型存在的问题
用于试验某些概念， 用于试验某些概念，试验完系统将无用处
进化型原型(Exploratory programming)
原型系统不断被开发和被修正， 原型系统不断被开发和被修正，最终它变为 一个真正的系统。 一个真正的系统。
原型模型存在的问题
用户有时误解了原型的角色，例如他们可能误解 原型应该和真实系统一样可靠。 缺少控制，由于用户可能不断提出新要求，因而 原型迭代的周期很难控制。 额外的花费：研究结果表明构造一个原型可能需 要10%额外花费。 为了尽快实现原型，采用了不合适的技术，后来 忘了修改，运行效率可能会受影响。 原型法要求开发者与用户密切接触，有时这是不 可能的。例如外包软件。
软件生存周期的瀑布模型
问题定义 计划时期 可行性研究 需求分析 开发时期 软件设计 编 测 运行时期 维 码 试 护
(1)计划时期 计划时期
问题定义
要解决的问题是什么？ 要解决的问题是什么 ——确定系统总目标 目标和范围说明书
可行性研究
这个项目值得开发么？时间，投资？ 这个项目值得开发么？时间，投资？ 对上一阶段所确定的问题有行的通的解决方案么？ 对上一阶段所确定的问题有行的通的解决方案么？ ——项目继续or终止？ 可行性论证报告
推迟实现的观点
区分逻辑设计与物理设计尽可能推迟程序物理实现
质量保证的观点
每个阶段都必须完成规定的文档， 每个阶段都必须完成规定的文档，没有交出合格 的文档就是没有完成该阶段的任务。 的文档就是没有完成该阶段的任务。 每个阶段结束前都进行评审，若确认， 每个阶段结束前都进行评审，若确认，则进行下 一阶段，否则返回前项。尽早发现问题改正错误。 一阶段，否则返回前项。尽早发现问题改正错误。
目录
2.3软件演化模型Evolutionary Model 软件演化模型
人们已经越来越认识到软件就象所有复杂系 统一样要经过一段时间的演化。业务和产品 需求随着开发的发展常常发生改变，想找到 最终产品的一条直线路径是不可能的。 紧迫的市场期限使得难以完成一个完善的软 件产品，但可以先提交一个有限的版本以对 付竞争或商业的压力；只要核心产品或系统 需求能够很好地理解，而产品或系统的细节 部分可以进一步定义。
2.1瀑布模型(Waterfall Model) 瀑布模型
也称典型生存周期模型(classic life cycle)或 也称典型生存周期模型 或 线性顺序模型(liner sequential model) 线性顺序模型
软件生存周期(Software Life Cycle)
如同任何事务一样，软件也有一个孕育、诞 生。成长、成熟、衰亡的生存过程，称为软 件的生存周期。
软件需求比较明确，需求反复性小，开发技术比 较成熟的场合
目录
2.2快速原型模型(Rapid Prototype Model) 快速原型模型
思想：样机， 思想：样机，样板房
听取用户 意见
建造/修改 建造 修改 原型
用户测试 运行原型
模型
需求分析 原型开发 原型评价 用户 反馈 最终系统设计 最终系统实现 突出“快”，用户和系统分析员从纸上谈兵－>真枪实弹， 突出“ 用户和系统分析员从纸上谈兵－ 真枪实弹， 真枪实弹 如一个实际系统，使用原型比瀑布式的方法开销少40％， 如一个实际系统， ％ 工作量少45％ ％
返回
(3)运行时期 运行时期
软件维护
使软件在整个生存期内满足用户需求， 使软件在整个生存期内满足用户需求， 并延长使用寿命 改正性维护：诊断和改正使用过程中发现的错误 适应性维护：修改软件以适应环境的变化 完善性维护：根据用户要求改进或扩充软件使它 更完善 预防性维护：修改软件为将来维护活动预先做准备
瀑布模型存在的问题
这种生存期模型所基于的假设——只要当分 只要当分 这种生存期模型所基于的假设 析员能够作出准确的需求分析时， 析员能够作出准确的需求分析时，才能得到 预期的正确结果 顺序性太过理想化，是文档驱动的， 顺序性太过理想化，是文档驱动的，在对软 件产品试用前， 件产品试用前，用户只能从静态的文档来了 解产品，要用户完全精确和正确的对一个软 解产品， 件产品提出确切的需求，实际上是不可能的。 件产品提出确切的需求，实际上是不可能的。 适合： 适合：
1.确定计划 确定计划
确定目标、 确定目标、方案和约 束
累计费用
2.风险分析 风险分析
评估方案，识别消除风险, 评估方案，识别消除风险, 决定项目命运
初始需求分析和 项目计划 基于用户说 明的计划
提交线
各步骤进度
基于初始需求的 风险分析 基于用户反馈的 风险分析
可运行的原型
评审 用户评价
产品规格 产品设计
返回
(2)开发时期 开发时期
设计(需求分析＋软件设计)＋实现(编码＋测试)）
需求分析
为了解决这个问题目标系统必须做什么？ ——用户对软件系统的全部需求 用户对软件系统的全部需求 需求规格说明书
软件的功能需求 性能需求 环境和外部接口 约束条件
Βιβλιοθήκη Baidu返回
软件设计
将需求－ 软件的表现形式 将需求－>软件的表现形式 总体设计： 总体设计： 软件的总体结构 详细设计 详细设计每个模块 确定模块功能所需要的算法和数据结构 目标: 目标 : 应使编码的程序员根据它们可很容易的写 出代码! 出代码! 设计文档
以增量开发字处理软件为例
增量模型的特点
优点：
分批逐步提交产品， 分批逐步提交产品，短时间内提交部分功能产品 逐步增加产品功能， 逐步增加产品功能，用户有时间学习适应新产品
困难
构件集成问题－ 构件集成问题－>软件体系结构必须是开放的 增量模型自身的矛盾性
软件应看作一个整体 软件又是构件序列， 软件又是构件序列，构件间相互独立 目录
返回
编码： 设计－ 产生计算机 产生计算机源程序 编码： 设计－>产生计算机源程序 测试： 发现错误！ 测试： 发现错误！
软件是否有错(功能上的，逻辑上的)？ 软件是否达到需求规格说明书预定的要求？ 软件是否满足用户需求？ 单元测试 集成测试 确认测试 系统测试
测试报告：测试计划＋测试用例＋测试结果
细化的快速原型模型
快速分析， 快速分析，确定初步规格说明 构造原型 运行/评价原型 运行 评价原型 修 正 改 进 原 型 N 原型完成否 Y 要细部说明否 Y 严格说明细部 N 效果满意否 Y 整理原型提供文档 N
原型系统的注意事项
思想来源于“样机”，但是不同于工业样 机 原型应充分展示软件的可见部分
(2)螺旋模型Spiral Model 螺旋模型
背景
“软件风险”是任何软件开发项目中都普遍存 软件风险” 在的实际问题 制定项目计划时，尽管系统分析员对项目预算、 制定项目计划时，尽管系统分析员对项目预算、 进度、技术、进行分析和估算， 进度、技术、进行分析和估算，但是给出准确 无误的回答是不容易的。 无误的回答是不容易的。 项目越大，软件越复杂，所冒风险越大 项目越大，软件越复杂， 及时对风险进行识别、分析、 及时对风险进行识别、分析、并采取对策
(1)增量模型Incremental Model
增量模型把软件产品看作一系列 增量构件(Increments)，在开发 过程的各次迭代中，每次完成其 中的一个增量。
Core product 文件管理编辑， 文件管理编辑，文档生成 More features and 交付客户第1 交付客户第1增量 functionality 完善的编辑和文档生 成
仅包括系统主要功能和主要接口，不包括细节
本质是“快速”，尽量缩短开发原型的时 间
使用快速原型语言（shell，超文本，4GL） 使用快速原型语言（shell，超文本，4GL） 采用软件重用技术 在算法的时/ 在算法的时/空开销方面也可以让步
原型模型的分类
抛弃型原型(Throw-away prototyping)
维护报告
各阶段文档
问题定义 计划时期 可行性研究 需求分析 开发时期 软件设计 编 测 运行时期 维 码 试 护
目标和范围说明书 可行性论证报告 需求说明书 设计文档 程序 测试报告 维护报告
瀑布模型的特点
阶段间具有顺序性和依赖性
阶段的工作完成之后， 前—阶段的工作完成之后，才能开始后一阶段的工作； 阶段的工作完成之后 才能开始后一阶段的工作； 前一阶段的输出文档就是后一阶段的输入文档 前一阶段的输出文档正确， 前一阶段的输出文档正确 ， 后一阶段工作才能获得正确 的结果。 的结果。
真实的实现
初始原型实现
4.客户评估 客户评估
评价开发工作, 评价开发工作 计划下一轮工作
3.实施工程 实施工程
实施软件开发, 实施软件开发 相当于瀑布模型
Cumulative cost
1.确定计划 确定计划
确定目标、 确定目标、方案和约 束
累计费用Progress through steps 各步骤进度
包括工程技术和管理活动。 包括工程技术和管理活动。 如方法使用的顺序，可交付产品和文档的格式… 如方法使用的顺序，可交付产品和文档的格式
软件过程模型
是软件过程的抽象表示， 是软件过程的抽象表示，为各项软件开发活动的流程 所确定的合理的框架
能直观的表达软件开发的全过程， 能直观的表达软件开发的全过程，明确规定要完成的主要 活动和任务的框架 也称为软件过程模型，软件工程范型或软件生存周期模型 也称为软件过程模型，软件工程范型或软件生存周期模型