一章软件工程基本概念

1.4 软件开发过程模型
原型：一个具体的可执行模型，它实现 了系统的若干功能。 原型法：不断地运行系统“原型”来进 行启发、揭示和判断的系统开发方法。
1.4 软件开发过程模型
2. 原型模型
1.4 软件开发过程模型
– 在“需求分析”、“原型设计”两个阶段中， 开发者和用户一起为想象中的系统的某些主 要部分定义需求和规格说明，并由开发者在 规格说明级用原型描述语言构造一个系统原 型，它代表了部分系统，包括那些为满足用 户需求的必要属性。该原型可用来帮助分析 和设计工作，而不是一个软件产品。
– 软件工程的传统途径是“生命周期法”，强 调“结构化分析、结构化设计”。
1. “生命周期法”的起源
人类解决复杂问题时普遍采用的一个策略是“各个 击破”，也就是对问题进行分解，然后再分别解决 各个子问题的策略。 软件工程采用的“生命周期法”，就是从时间角度 对软件开发和维护的复杂问题进行分解，把软件生 存的漫长周期依次划分为若干个阶段，每个阶段有 相对独立的任务，然后再逐步完成每个阶段的任务。
1.3 软件工程
2. 生命周期划分的原则
• 各阶段的任务彼此间尽可能相对独立，同一个阶 段各项任务的性质尽可能相同，从而降低每个阶 段任务的复杂性，简化不同阶段之间的联系，有 利于软件开发过程的组织管理。
3. 生命周期的划分
• 软件生命周期一般分为：软件定义（问题定义、 可行性研究、需求分百度文库）、软件开发（总体设计、 详细设计、编码和单元测试、综合测试）、软件 维护等三个时期。
1.4 软件开发过程模型
– 在演示原型期间，用户可以根据他所期望的 系统行为来评价原型的实际行为。如果原型 不能满意地运行，用户能立刻找出问题和不 可接受的地方，并与开发者重新定义需求。 该过程一直持续到用户认为该原型能成功地 体现想象中的系统的主要部分功能为止。在 这期间，用户和开发者都不要为程序算法或 设计技巧等枝节问题分心，而是要确定开发 者是否理解了用户的意思，同时试验实现它 们的若干方法。
1.4 软件开发过程模型
软件维护往往经历软件生存期的各个阶段，从而构成 生存期循环。
1.4 软件开发过程模型
具有维护循环的软件生存期的瀑布模型
1.4 软件开发过程模型
– 瀑布模型的缺点：
1. 从认识论角度看，人的认识是一个多次反复循 环的过程，不可能一次完成。但瀑布模型中划 分的几个阶段，没有反映出这种认识过程的反 复性。
生命周期法各阶段的工作小结
阶段 关键问题 结束标准
问题定义 问 题 是 什 关于规模和目标的报告书 么？
可行性研 究 需求分析
有可行的解 吗？ 系统必须做 什么？
系统的高层逻辑模型：数据 流 图 、 成 本 /效 益 分 析 系统的逻辑模型：数据流图、 数据字典、算法描述
总体设计
如何解决已 可能的解法：系统流程图、
1.2 软件危机
四、产生软件危机的原因
2. 软件不易于维护
（2）软件不同于一般程序，它的规模大，不易于 维护。
3. 在软件开发过程中，或多或少地采用了错误 的方法和技术。
4. 对用户需求没有完整准确的认识，就匆忙着 手编写程序。
1.2 软件危机
五、解决软件危机的途径
1. 技术措施
使用更好的软件开发方法和开发工具
专职维护人员
硬件特征 软件特征
价高、存储 小、可靠性 差 完全不受重 视
降价；速度、向超高速、大容 容 量 、 可 靠 量、微型化发展 性明显提高 软件技术的发展 开发技术有进步，但 不满足需要，出 未获得突破性进展， 现软件危机 软件危机未完全摆脱
1.2 软件危机
二、什么是软件危机
– 软件危机是指在计算机软件的开发和维护过 程中所遇到的一系列严重问题。主要是两个 问题。
2. 软件开发是一个知识密集型的开发活动，需要 相互合作完成，但瀑布模型没有体现这一点。
1.4 软件开发过程模型
二、原型模型
1. 基本思想 – 在获取一组基本的需求定义后，利用高级软件工具
的可开发环境，快速地建立一个目标系统的最初版 本，并把它交给用户试用、补充和修改，再进行新 的版本开发。反复进行这个过程，直到得出系统的 “精确解”，即用户满意为止。经过这样一个反复 补充和修改的过程，应用系统的“最初版本”就逐 步演变为系统的“最终版本”。
– 软件工程是一门涉及软件计划、需求分析、 设计、编码、测试和维护的原理、方法及工 具的研究和应用的学科。
1.3 软件工程
二、软件工程的基本原理
– 1968年在联邦德国召开的国际会议上正式 “软件工程”术语。
– 目前有100多条关于软件工程的准则，其中 最出名的是著名软件工程专家B.W.Boehm在 1983年提出的7条基本原理。
2. 组织管理措施
• 软件开发不是某种个体劳动的神秘技巧，而应该 是一种组织良好、管理严密、各类人员协同配合、 共同完成的工程项目。
1.3 软件工程
一、什么是软件工程
– 软件工程是指导计算机软件开发和维护的工 程学科。它采用工程的概念、原理、技术和 方法来开发与维护软件，把经过时间考验而 证明正确的管理技术和当前能够得到的最好 的技术方法结合起来。
– 大部分错误是在编码之前造成的 – 错误发现与改正得越晚，所需付出的代价越
高。 因此，在每个阶段都进行严格的评审，以便尽
早发现在软件开发过程的错误
1.3 软件工程
3. 实行严格的产品控制
– 在软件开发过程中不要随意改变需求，因为改变某 项需求往往需要付出较高的代价，但在实践中用户 往往会提出需求变更，因此需要采取科学的产品控 制技术。
– 目前主要实行基准配置管理：基准配置是指经过阶 段评审后的软件配置成分，如各个阶段产生的文档 或程序代码。
– 对涉及基准配置的修改，必须经过严格的评审，通 过后才能实施修改。
1.3 软件工程
4. 采用现代程序设计技术
– 实践表明：采用先进的技术既可提高软件开 发的效率，又可提高软件维护的效率。
– 80年代及之前：结构化分析、设计技术 – 90年代：面向对象分析、设计技术
1.4 软件开发过程模型
➢(3)从需求分析到最终产品都可作原型，即可 为不同目标作原型。
➢(4)它必须快速、廉价。 ➢(5)它是迭代过程的集成部分，即每次经用户
评价后修改、运行，不断重复双方认可。
1.4 软件开发过程模型
4. 原型法的评价
– 优点 1.原型法在得到良好的需求定义上比传统生存周期法
1.3 软件工程
1. 用分阶段的生命周期计划严格管理
– 经统计表明，不成功的软件项目中有一半左 右是由于计划不周造成的。
– Boehm认为，在软件的整个生命周期中应制 定并严格执行六类计划：项目概要计划、里 程碑计划、项目控制计划、产品控制计划、 验证计划、运行维护计划。
1.3 软件工程
2. 坚持进行阶段评审
好得多，可处理模糊需求，开发者和用户可充分通 信。 2.原型系统可作为培训环境，有利于用户培训和开发 同步，开发过程也是学习过程。 3.原型给用户以机会更改心中原先设想的、不尽合理 的最终系统。 4.原型可低风险开发柔性较大的计算机系统。 5.原型增加使系统更易维护、对用户更友好的机会。 6.原型使总的开发费用降低，时间缩短。
书
软件）
主 要 程 序 汇 编 及 机 器 高级语言 设计语言 语言
高级语言系统、 程序设计语言
软 件 工 作 程序编写 范围
包 括 设 计 和 软件生存期 测试
需求者
程 序 设 计 者 少数用户 本人
市场用户
计算机软件发展的三个时期及特点
程序设计 程序系统 软件工程
维 护 责 任 程序设计者 开发小组 者
2. 第二代（60年代中期-70年代中期）程序系 统阶段
• 出现“软件作坊”、产品软件；“个体化”开发 方法。
3. 第三代（70年代中期之后）软件工程阶段
软件开发成为一门新兴的工程学科——软件工程。
计算机软件发展的三个时期及特点
程序设计 程序系统 软件工程
软 件 的 范 程序 畴
程 序 及 说 明 产品软件（项目
1.4 软件开发过程模型
– 缺点 1.“模型效应”或“管中窥豹”。对于开发者不熟悉
的领域把次要部分当作主要框架，做出不切题的原 型。 2.原型迭代不收敛于开发者预先的目标。即每次更改， 为了消除错误，次要部分越来越大，“淹没”了主 要部分。 3.原型过快收敛于需求集合，而忽略了一些基本点。 4.资源规划和管理较为困难，随时更新文档也带来麻 烦。 5.长期在原型环境上开发，只注意得到满意的原型， 容易“遗忘”用户环境和原型环境的差异。
维护
持 久 地 满 足 完整准确的维护记录
需要的软件
1.3 软件工程
4. “生命周期法”的特点
• 阶段具有顺序性和依赖性 • 推迟实现的观点 • 质量保证的观点
– 每个阶段都必须完成规定的文档 – 每个阶段结束前都要对所完成的文档进行评审，以便
尽早发现问题，改正错误。
1.4 软件开发过程模型
一、瀑布模型
提 出 的 问 成 本 /效 益 分 析 ； 推 荐 的 系 统
题？
结构：层次图或结构图
生命周期法各阶段的工作小结
阶段 关键问题 结束标准
详细设计
编码和单 元测试 综合测试
怎样具体地 实现这个系 统？ 正确的程序 模块 符合要求的 软件
编 码 规 格 说 明 ： H IP O 图 或 PD L
原程序清单：单元测试方案 和结果 综合测试方案和结果；完整 一致的软件配置
– (1)它是一个可实际运行的系统。
1.4 软件开发过程模型
– (2)它没有固定的生存期。一种极端是扔掉原 型（以最简便方式大量借用已有软件，做出 最后产品的模型，证实产品设想是成功的， 但产品中并不使用）；另一种极端是最终产 品的一部分即增量原型（先做出最终产品的 核心部分，逐步增加补充模块），演进原型 居于其中（每一版本扔掉一点，增加一点， 逐步完善至最终产品）。
1.2 软件危机
四、产生软件危机的原因
1. 与软件本身的特点有关
• 软件不同于硬件，它是计算机系统的逻辑部件而 不是物理部件。在写出程序代码并在计算机运行 之前，软件开发过程的进展情况较难衡量，软件 开发的质量也较难评价。因此，管理和控制软件 开发过程相当困难。
2. 软件不易于维护
（1）软件维护通常意味着改正或修改原来的设计， 客观上使软件较难维护。
1. 如何开发软件，怎样满足对软件的日益增长 的需求。
2. 如何维护数量不断膨胀的已有软件
1.2 软件危机
三、软件危机的主要表现
1. 对软件开发成本和进度的估计不准确 2. 用户不满意 3. 软件质量不高、可靠性差 4. 软件常常不可维护、错误难以改正。 5. 缺乏适当的文档资料 6. 软件成本占系统总成本的比例逐年上升 7. 软件开发速度跟不上计算机发展速度
1.1 软件
软件的特点
– 抽象性：逻辑实体，可记录，但看不到 – 可复制性：与开发成本相比，复制成本很低 – 无折旧 – 受硬件制约 – 未完全摆脱手工工艺 – 开发费用高
1.2 软件危机
一、计算机软件发展的三个时期
1. 早期时代（60年代中期之前）程序设计阶段
• 硬件通用，软件专用；程序规模小，编写者和使 用者为同一人（同组人）。
1.3 软件工程
5. 结果应能清楚地审查
– 软件产品是看不见、摸不着的逻辑产品，开 发过程难以评价和管理。
– 根据软件开发项目的总目标及完成期限，规 定开发组织的责任和产品标准，使所得的结 果能够清楚地审查
1.3 软件工程
6. 开发小组的人员应该少而精
– 开发小组人员的素质和数量是影响软件产品 质量和开发效率的重要因素。
1.4 软件开发过程模型
– 有了满意的系统原型，同时也积累了使用原 型的经验，用户常会提出新目标，从而进一 步重新原型周期。新目标的范围要比修改或 补充不满意的原型大。
1.4 软件开发过程模型
3. 原型特征
– 软件原型是软件的最初版本，以最少的费用、 最短的时间开发出的、以反映最后软件的主 要特征的系统。它具有以下特征：
– 开发小组人员数目的增加，使相互交流复杂、 费用增加。
1.3 软件工程
7. 承认不断改进软件工程实践的必要性
– 遵循前6条基本原理，就能够按照当代软件 工程基本原理实现软件的工程化生产，但不 能保证赶上时代前进的步伐。
– 积极主动采纳新的软件技术，且不断总结经 验。
1.3 软件工程
三、软件工程的传统途径
– 典型瀑布模型具有顺序性和依赖性
1.4 软件开发过程模型
– 瀑布模型的特征
1. 从上一项活动中接受该项活动的工作对象，作 为输入。
2. 利用这一输入实施该项活动应完成的内容 3. 给出该项活动的工作成果，作为输出传给下一
项活动 4. 对该项活动实施的工作进行评审。若其工作得
到确认，则继续下一项活动。