第2讲 软件开发过程模型

10
运行／维护
• 改正性维护 运行中发现了软件中 的错误需要修正 • 适应性维护 为了适应变化了的软 件工作环境，需做适当变更 • 完善性维护 为了增强软件的功能 需做变更
阶段
问题定 义 可行性 研究 需求分 析
关键问题
问题是什么 有可行的解 吗 系统必须做 什么
结束标准
关于规模和目标的报告 书 系统高层逻辑模型：数 据流图，成本/效益分析 系统的逻辑模型：数据 流图，数据字典，算法 描述 可能的解法：系统流程 图，成本/效益分析，推 荐的系统结构：层次图 或结构图
• 对用户提出的要求进行分析并给出 详细的定义 • 编写软件需求说明书或系统功能说 明书及初步的系统用户手册 • 提交管理机构评审
7
软件设计 • 概要设计 — 把各项需求转换成软件 的体系结构。结构中每一组成部分 都是意义明确的模块，每个模块都 和某些需求相对应 • 详细设计 — 对每个模块要完成的工 作进行具体的描述，为源程序编写 打下基础 • 编写设计说明书，提交评审。
2.3螺旋模型
1988年， Barry 提出螺旋模型，将瀑布模型和快速原型结合， 注重风险分析，适合于大型复杂系统。
软件开发的风险： 1、 产品交付用户之后用户可能不满意； 2、到交付日期后软件可能还未开发出来； 3、实际开发成本可能超过预算； 4、一些关键的开发人员可能“跳槽”； 5、 聘请不到需要的专业人员； 基本思想：使用原型及其他方法来尽量降低风 险。可看作在每个阶段之前都增加了风险分析过程 的快速原型模型。螺旋线每个周期对应一个开发阶 段。 26
32
螺旋模型的缺陷
• 1）采用螺旋模型需要具有相当丰富的风险评估经 验和专门知识，在风险较大的项目开发中，如果 未能够及时标识风险，势必造成重大损失。 • 2）过多的迭代次数会增加开发成本，延迟提交时 间。
34
螺旋模型限制条件
• 螺旋模型强调风险分析，但要求客户接受这种风 险，并做出相关反映是不容易的。 • 如果执行风险分析会大大影响项目的利润，那么 风险分析就没有意义了。 只适合大规模软件开发 • 软件开发人员应该擅长寻找可能的风险，准确地 分析风险，否则将会带来更大的风险。
11
总体设 计
概括的说， 系统应该如 何解决这个 问题
阶段
关键问题
结束标准
详细设计 怎样具体地实 现这个系统 编码和单 正确的程序模 元测试 块 综合测试 符合要求的软 件
维护 持久地满足用 户需要的软件
12
编写规格说明： HIPO图或PDL 源程序清单，单元测 试方案和结果 综合测试方案和结果、 完整一致的软件配置
螺旋模型的基本 思想：使用原型及其 他方法来尽量降低风 险。 简化的螺旋模型 可看作在每个阶段都 增加了风险分析过程 的快速原型模型。 风险分析是对风险 进行识别，分析，采 取对策，进而消除或 减少风险的损害。
风险 分析
快速原型
验证 风险 分析 规格说明 验证 风险 分析 设计
风险分析 变化的需求 验证
• 喷泉模型不像瀑布模型那样，需要分析活动结束 后才开始设计活动，设计活动结束后才开始编码 活动。该模型的各个阶段没有明显的界限，开发 人员可以同步进行开发。
优点
• 优点是可以提高软件项目开发效率，节省开发时 间，适应于面向对象的软件开发过程。 • 可以从任何一个开发阶段（泡泡）转到其它任一 个开发阶段，各个阶段之间没有明显的界限。也 就是，在整个过程中补漏、拾遗、纠错的切入点 大大增多，不受开发阶段的限制。
完整准确的维护记录
13
2 常用软件开发过程模型
2.1瀑布模型：将各项活动规定为依固定顺序连接的若干阶段工作，从上 到下，不可逆转
计划 阶段
可行性研 究 需求分析 软件设计 开发 阶段 编码
上一项活动产生 的工作结果作为 下一步输入 每一个工作 结果进行评 审 软件测试 维护 阶段
运行、维护
图1-3 瀑布模型
19
• 过程图
快速分析 需求说明 需求分析 需求说明 设计 说修 明改 设计说明 编码 源程序清单 测试 软件产品
构造原型
原型
运行原型
原修 型改 评价原型
修改意见
修改类型 停止修改
维护
快速原型
快速原型模型特点
快速原型是快速建立起来的可以 在计算机上运行的程序，完成的功 能是最终产品能完成功能的一个子 集。 1. 快速原型模型不带反馈环，软件 开发基本上是线形顺序进行的。 2. 原型系统已经通过与用户交互得 到验证； 3 。 开发人员在建立原型中学到了 许多东西；
2.4 喷泉模型
• 喷泉模型是一种以用户需求为动力，以对象为 驱动的模型，主要用于描述面向对象的软件开 发过程。 • 该模型认为软件开发过程自下而上周期的各阶 段是相互重叠和多次反复的，就像水喷上去又 可以落下来，类似一个喷泉。 • 各个开发阶段没有特定的次序要求，并且可以 交互进行，可以在某个开发阶段中随时补充其 他任何开发阶段中的遗漏。
模型的关键
• 快速原型的关键在于尽可能快速地建造出软件原 型，一旦确定了客户的真正需求，所建造的原型 将被丢弃。因此，原型系统的内部结构并不重要， 重要的是必须迅速建立原型，随之迅速修改原型， 以反映客户的需求。
优点
• 克服瀑布模型的缺点，减少由于软件需求不明确 带来的开发风险。 • 一是开发工具先进，开发效率高，使总的开发费 用降低，时间缩短； • 二是开发人员与用户交流直观，可以澄清模糊需 求，调动用户的积极参与，能及早暴露系统实施 后潜在的一些问题； • 三是原型系统可作为培训环境，有利于用户培训 和开发同步，开发过程也是学习过程。
原型模型的缺陷
• 1） 建立原型模型的软件工具与环境与实际模型 的存在脱节的现象。 2） 以目前通用的开发工具，开发原型本身就不 是件容易的事情。 3） 原型模型对用户深层次的需求并不能深入分 析。 • 4）快速建立起来的系统结构加上连续的修改可能 会导致产品质量低下；
缺点
• 产品原型在一定程度上限制了开发人员的创新， 没有考虑软件的整体质量和长期的可维护性。 • 由于达不到质量要求产品可能被抛弃，而采用新 的模型重新设计，因此原型实现模型不适合嵌入 式、实时控制及科学数值计算等大型软件系统的 开发；
维护期
进一步开发 运行状态
集成和测试阶段
喷泉模型
编码阶段 面向对象设计阶段 面向对象分析阶段 需求阶段
各个开发阶段没有特定的次序要求，可以随时补充其他任何开发 36 阶段中的遗漏。
• 喷泉模型主要用于面向对象的软件项目，软件的 某个部分通常被重复多次，相关对象在每次迭代 中随之加入渐进的软件成分。各活动之间无明显 边界，例如设计和实现之间没有明显的边界，这 也称为“喷泉模型的无间隙性”。 • 由于对象概念的引入，表达分析、设计及实现等 活动只用对象类和关系，从而可以较容易地实现 活动的迭代和无间隙。
29
30
螺旋模型
沿着螺旋线每转一圈，表示开发一个更完善的版本。
• “螺旋模型”的核心就在于您不需要在刚开始的时 候就把所有事情都定义的清清楚楚。您轻松上阵， 定义最重要的功能，实现它，然后听取客户的意 见，之后再进入到下一个阶段。如此不断轮回重 复，直到得到您满意的最终产品。
优点：
1、对可选方案和约束条件的强调有利 于已有软件的重用，也有利于把软件质量作 为软件开发的一个重要目标； 2、减少了过多的测试或测试不足所带 来的风险； 3、维护只是模型的另一个周期，在维 护和开发之间没有本质的区别。
17
• 模型原理图
快速分析 原型 构造 运行
执 行 程 序
评价
18
• 做两次或多次 • 第一次只是试验开发，其目标只是在于探索可 行性，弄清软件需求 • 第二次则在此基础上获得较为满意的软件产品 • 显然，快速原型方法可以克服瀑布模型的缺点， 减少由于软件需求不明确带来的开发风险，具 有显著的效果。
验证
风险 分析 编码 测试 综合测试
风险 分析
简化的螺旋模型
27
维护
28
螺旋模型
• 螺旋模型沿着螺线旋转，在四个象限上分别表 达四个方面的活动，即： • 制定计划──确定软件目标，选定实施方案， 弄清项目开发的限制 • 风险分析──分析所选方案，考虑如何识别和 消除风险 • 实施工程──实施软件开发 • 客户评估──评价开发工作，提出修正建议
实线箭头表示开发过程；虚线箭头表示维护过程。
14
维护
15
瀑布模型缺点
• 项目开始阶段，开发人员和用户对需求的描述常 常不全面。如果需求阶段没发现问题，则影响后 面各阶段的工作 • 各阶段所做的工作都是文档说明，一般用户不易 理解文字所叙述的软件。用户的修改意见加大了 修改难度 • 改变会影响整个软件开发。事先选择的技术或需 求迅速发生变化，需要返回到前面，对前面一系 列内容进行修改
验证 规格说明 验证
变化的需求 验证
维护过程
设计
验证
编码 测试 综合测试
实线箭头表示开发过程；虚线箭头表示维护过程。
20
维护
特点
• 原型模型的最大特点是：利用原型法技术能够快 速实现系统的初步模型，供开发人员和用户进行 交流，以便较准确获得用户的需求，采用逐步求 精方法使原型逐步完善，是一种在新的高层次上 不断反复推进的过程。 • 它可以大大避免在瀑布模型冗长的开发过程中看 不见产品雏形的现象。
软件设计
编码 图1-2 软件的生存周期
ቤተ መጻሕፍቲ ባይዱ 5
可行性研究
• 确定要开发软件系统的总目标及可 行性 • 给出功能、性能、可靠性以及接口 等方面的要求 • 估计可利用的资源 (硬件，软件， 人力等)、成本、效益、开发进度 • 制定出完成开发任务的实施计划， 连同可行性研究报告，提交管理部 门审查
6
需求分析和定义
2
3
软件生存期 life cycle
• 软件生存期的六个步骤，即可行性研究、需求 分析、设计、程序编码、测试及运行维护
• 软件工程学的一个重要目标就是提高软件的可 维护性，减少软件维护的代价。 • 在软件开发的不同阶段进行修改需要付出的代 价很不相同：
4
软件生存周期
评价
可行性研究 运行
需求分析
软件测试
每个阶段开始时（左上象限）的任务是：确 定该项目的目标、为完成这些目标选择方案及设 定这些方案的约束条件。接下来的任务是：从风 险角度分析上步的工作结果，努力排除各种潜在 的风险，如果风险不能排除，则停止开发工作或 大幅度削减项目规模。如果成功排除了所有风险， 则启动下一个开发步骤（右下象限），这个步骤 相当于纯粹的瀑布模型。最后是评价该阶段工作 成果并计划下一阶段的工作。
缺点
• 由于喷泉模型在各个开发阶段是重叠的，因此在 开发过程中需要大量的开发人员，因此不利于项 目的管理。 • 此外这种模型要求严格管理文档，使得审核的难 度加大，尤其是面对可能随时加入各种信息、需 求与资料的情况。 •
8
程序编写 • 把软件设计转换成计算机可以接受 的程序代码，即写成以某一种特定 程序设计语言表示的“源程序清单” • 写出的程序应当是结构良好、清晰 易读的，且与设计相一致的
9
软件测试
• 单元测试，查找各模块内部在功能 和结构上存在的问题并加以纠正 • 组装测试，将已测试过的模块按一 定顺序组装起来 • 按规定的各项需求，逐项进行有效 性测试，决定已开发的软件是否合 格，能否交付用户使用
1
第二讲 软件开发过程模型
北京邮电大学计算机学院 芦效峰
1. 软件生存周期
•软件产品从提出开始，到该软件产品被淘汰的全 过程。 一个软件从定义、开发、使用、维护，直到最终被 废弃，要经历一个漫长的时期，这就如同一个人要 经过胎儿、儿童、青年、中年、老年，直到最终死 亡的漫长时期一样，通常把软件经历的这个漫长时 期称为生存周期。
需求分析
开发过程
需求分析 验证
瀑布模型特点
按照传统的瀑布模型来开发软件， 有以下特点： 1、阶段间有顺序性和依赖性； 2、推迟实现的观点； 3、质量保证的观点；
验证 规格说明 验证
维护过程
设计
验证
编码
优点：可强迫开发人员采用规范的方法；
测试 综合测试
严格规定了每个阶段必须提交的文档；要 求每个阶段交出的产品都必须经过质量保 证小组的仔细验证。
2.2 快速原型模型
• 由于在项目开发的初始阶段人们对软件的需求认识 常常不够清晰，因而使得开发项目难于做到一次开 发成功，出现返工再开发在所难免。 • 快速原型模型的第一步是建造一个快速原型，实现 客户或未来的用户与系统的交互，用户或客户对原 型进行评价，进一步细化待开发软件的需求。通过 逐步调整原型使其满足客户的要求，开发人员可以 确定客户的真正需求是什么；第二步则在第一步的 基础上开发客户满意的软件产品。