软件工程

高海波
2018-9-29
主讲：高海波
电话： 15320086915
Email ： hbgao@hactcm.edu.cn
课程性质：考试课
学时：理论课 36 学时 + 实验 18 学时 =54 学时
这门课干什么？
这门课怎么上？
课程目的与任务
目的：
◦ 通过介绍软件工程的基本原理、概念与技术方法，采用理论与实践相结
合的方式，使大家初步建立工程化意识，学会用工程化思想（包括技术
、方法与环境）开发各种软件，为今后实际工程中能够进行系统分析与
设计奠定良好的基础
任务：
◦ 掌握软件与软件工程基本概念和基本知识。
◦ 掌握软件生命周期与软件开发模式。
◦ 掌握结构化程序设计的编程思想。
◦ 掌握面向对象分析、设计与编码方法。
◦ 掌握有关软件的评审、测试与维护，项目计划与项目管理方法。
◦ 能用软件工程的方法参与软件项目的分析、设计、实现和维护。
教学进度表：

章 节 主要内容 计划学时
第一章 软件工程概述 2
第二章 可行性研究 4+2
第三、四章 需求分析的任务、方法、建模 10+2
第五、六章 系统设计、实现 6+8
第七、八章 软件测试、维护 6+4
第九 - 十二章 面向对象方法、模型 6
第十三章 项目实战 2+2
总计：理论 36 学时，实验 18 学时
课程成绩构成：
形成性成绩： 40% （考勤： 10 分；实验： 30 分）
终结性考核： 60%

考核项目分值权重 　
项目一 项目
项目二 项目三 项目四 项目五 项目六 项目七
（% 项目八 九
（% （% （% （% （% （%
） （%） （%
） ） ） ） ） ）
）
合计
实验 其它自
实验
预习 、实训 动手 产品 选形式 小组 小组
考勤 、实训
报告 报告 能力 质量 考核方 自评 互评
态度
式
　 20 45 　 35 　 100%
实验及分组总要求
每组 4-5 人，推举一名负责人，在实验课程中，组织协调项目
的正常开展。
各小组成员协商，在实验课程开始前，共同商定一个题目，该
题目是小组接下来实验所需完成的项目。
学习委员统计各分组情况，填写分组名单。
各小组根据所选题目搜集资料，准备第一次实验——可行性研
究报告。
每次实验都随机由 1-2 个小组对该次实验内容进行 5 分钟左右
的简单汇报，各小组对汇报情况打分。
 参考书目

（ 1 ）蔡敏等， UML 基础和 Rose 建模教程，人民邮电出版社， 2006 年

（ 2 ）李芷，软件工程方法与实践，电子工业出版社， 2004 年
（ 3 ）郑人杰，实用软件工程 ( 第二版 ) ，清华大学出版社， 1997 年
（ 4 ）张海藩，软件工程导论 ( 第五版 ) 学习辅导，清华大学出版社， 2008
年
（ 5 ）周苏，软件工程学试验 . 科学出版社， 2005 年
第 1 章 软件工程学概述

1.1 软件危机
1.2 软件工程
1.3 软件生命周期
1.4 软件过程
1.1 软件危
机
软件发展的历程：
60 年代中期以前：通用硬件相当普遍，软件却是为某个具体的应用而
编写的，常采用“个体生产方式” 。
60 年代中到 70 年代中：随着软件规模的扩大，软件开发需几个人协
同完成，即采用“作坊生产方式”。随着软件需求量、规模及复杂度的增
大，作坊生产方式已不能够适应软件生产需要，出现“软件危机”。
软件工程时代：为应对软件危机，适应软件发展，诞生了“工
程化生产” 方式。将工程学中的原理、方法应用在软件设计和开发中来，
即软件工程。
典型的软件危机事件：
60 年代美国 IBM 公司开发 IBM360 机的操作系统，耗费
5000 人 · 年的工作量，工期一再推迟，结果依然不理想
。

项目负责人 Brook 后来对整个过程反思，总结经验和教

训，写成了《人月神话》，被称为程序员的“圣经”。

1968 年北大西洋公约组织的计算机科学家在西德召开国
际会议，讨论软件危机问题，在这次会议上正式提出并
使用了“软件工程”一词，软件工程学由此开始研究。
1.1.1 软件危机的介绍
软件危机：在计算机软件开发
和维护过程中，遇到的一系列严重问
题，造成软件危机。（正常、不正常
运行的软件都具有这种问题）
典型表现： 1 、成本和进度的
估计很不准确，实际成本比估计成本
高几倍十几倍，实际进度比预期进度
拖延几个月甚至几年。 2 、用户对完
成的软件系统很不满意：开发人员与
用户的信息交流不充分。 3 、产品质
量极端靠不住：软件质量保证技术的
不完善和未全面推广。
4 、软件常常不可维护：程序中的错误难以改正 ,“ 软件重用”难以
实现。
5 、没有适当的文档资料：文档资料缺乏、或不合格，软件的开发
和维护极端困难。
6 、软件成本在计算机系统中的占比逐年上升；
7 、软件生产率的提高速度，远远慢于计算机的迅速普及和深入发
展，软件产品“供不应求”。
1.1.2 软件危机的产生原因

1 ）本身特点造成；
2 ）软件开发与维护的方法问题。

主要表现：
（ a ）忽视软件需求分析；
（ b ）无统一、规范的方法论指导开发过程，文档资
料不全，坚持认为软件开发就是写程序、运行程序
；
（ c ）轻视软件维护。
不同阶段修改软件需付出的代价很不相同：

代价
高

低
早期 中期 后期 软件开发时期
引入同一修改的代价随时间变化的趋势
关于软件开发的常见观点：√ or X

◦ “ 有一个对目标的概括描述就足以着手编写程序了，许多细节可以
在以后再补充。”
◦ “ 所谓软件开发就是编写程序并设法使它运行。”
◦ “ 用户对软件的要求不断变化，然而软件是柔软而灵活的，可以轻
易地改动。”
◦ “ 软件投入生产性运行以后需要的维护工作并不多，而且维护是一
种很容易做的简单工作。”软件维护的费用占软件总费用的 55 ％－
70 ％
◦ 不完善的系统定义往往是导致软件项目失败的主要原因。
◦ 只有质量差的软件产品才需要维护。
◦ 在软件开发的过程中，若能推迟暴露其中的错误，则为修复和改正错误
所花费的代价就会降低。
◦ 只要我们写出了程序并使其正常运行，我们的工作就结束了。
◦ 我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以
帮助我们解决软件开发中遇到的任何问题。
◦ 在项目计划发生延迟的情况下，增加更多的程序员一定会加快进度。
◦ 文档是软件产品的一部分，没有文档的软件就不称其为软件。
◦ 一个成功的项目唯一提交的就是运行程序。
1.1.3 解决软件危机的途径
1 ）正确认识软件的概念。
2 ）充分认识到软件开发不是某种个体劳动的神秘技巧，而应该
是一种组织良好、管理严密、各类人员协同配合共同完成的工程
项目。
3 ）充分吸取和借鉴人类长期以来从事各种工程项目所积累的行
之有效的原理、概念、技术和方法，特别要吸取几十年来人类从
事计算机软硬件研究和开发的经验教训。
4 ）在软件开发中，要总结、使用软件开发的成功经验（技术和
方法），并探索更有效的技术和方法；
5 ）开发更好的软件工具；
6 ）良好的组织管理措施。
软件概念：软件 = 程序 + 数据 + 文
档
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据
及其相关文档的完整集合。
程序是按事先设计的功能和性能要求执行的指令序列。
数据是使程序能正常操纵信息的数据结构。
文档是与程序开发，维护和使用有关的图文材料。

开发软件≠编写程序 !
总之，为了消除软件危机，既要有技术措施（方法和工具），
又要有必要的组织管理措施。软件工程正是从管理和技术两方
面研究如何更好地开发和维护计算机软件的一门新兴学科。
 1.2 软件工
程

1.2.1 介绍
1968 年 NATO （北大西洋公约组织 ）会议：软件工程就是为
了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和
使用完善的工程原理。
1993 年 IEEE （美国电气和电子工程师协会）：软件工程是
（ 1 ）把系统的、规范的、可度量的途径应用于软件开发、运行和维
护过程；（ 2 ）研究（ 1 ）中提到的途径。
特性和定义：
特性：
1. 关注大型、超大型程序的构造； 2. 中心课题是控制
复杂性； 3. 软件经常变化； 4. 开发软件的效率非常重要；
5. 和谐地合作是软件开发的关键； 6. 软件必须有效地支持它
的用户； 7. 在软件工程领域中是由具有一种文化背景的人替具
有另一种文化背景的人创造产品。
定义：
软件工程是指导计算机软件开发与维护的工程学科。它
采用工程学的概念、原理、技术和方法来开发与维护软件，把
经过时间考验而证明是正确的管理技术和目前能够得到的最有
效的软件技术与方法结合起来，以经济地开发出高质量的软件
并有效地维护它，这就是软件工程。
 目标：
软件工程研究的目标是“以较少的投资获取较高质量
的软件”。
◦ （ 1 ）付出较低的开发成本
◦ （ 2 ）实现要求的软件功能
◦ （ 3 ）取得较好的软件性能
◦ （ 4 ）开发的软件易于维护
◦ （ 5 ）需要的维护费用较低
◦ （ 6 ）能按时完成开发工作，及时交付使用
1.2.2 软件工程的基本原理
1. 用分阶段的生命周期计划严格管理
把软件生命周期划分成若干个阶段，并相应地制
定出切实可行的计划，然后严格地按照计划对软件的开发
与维护工作进行管理。
2. 坚持进行阶段评审
软件的质量保证工作不能等到编码阶段结束之后
再进行。原因：一、大部分错误是在编码之前造成的，例
如，根据 Boehm 等人的统计，设计错误占软件错误的 63%
，而编码错误仅占 37% ；二、错误发现与改正得越晚，改
正错误所需付出的代价也越高。
3. 实行严格的产品控制
基线配置管理（变动控制）
4. 采用现代程序设计技术
结构化分析、设计技术、结构化程序设计技术 , 面向
对象分析和设计技术。
实践表明，采用先进的技术不仅可以提高软件开发和
维护的效率，而且可以提高软件产品的质量。
5. 结果应该能够清楚地审查
依据开发项目的总目标和完成期限，规定开发小组的
责任、产品标准及完成日期，使结果能够清楚地审查。
6. 开发小组的人员应该少而精
素质高的人员的开发效率比素质低的人员的开发
效率可能高几倍至几十倍，而且素质高的人员所开发的软件
中的错误明显少于素质低的人员所开发的软件中的错误。
随着开发小组人员数目的增加，为了交流信息、
讨论问题而造成的通信开销也急剧增加。当开发小组人数为
N 时，可能的通信路径有 N （ N － 1 ） /2 条。
7. 承认不断改进软件工程实践的必要性
软件工程随着技术的进步而不断的发展。
1.2.3 软件工程方法学
软件工程包括技术和管理两方面的内容，是技术与

管理紧密结合形成的工程学科。
管理是通过计划、组织和控制等一系列活动，合理配置和使用资源
，以达到既定目标的过程。
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为
方法学（ Methodology ），也称为范型（ Paradigm ）。
 软件工程方法学的 3 要素：方法、工具和过程。
方法是完成软件开发的各项任务的技术方法，回答“怎样做”的问题
；
工具是为运用方法而提供的自动或半自动的软件工程支撑环境；

过程是为了获得高质量的软件所需完成的一系列任务的框架，它规定
了完成各项任务的工作步骤。
1 、传统方法学（生命周期方法学或结构化范型）
—— 强调自顶向下
采用结构化技术来完成软件；
划分为若干个阶段，然后顺序地完成每个阶段的任务
；每个阶段的任务相对独立，而且比较简单，整个降低了软件
开发工程的困难程度；
前一个阶段是后一个阶段的前提和基础，而后一阶段
提出的解法更具体，细节更多；
每个阶段结束前必须从技术和管理两方面对这个阶段
的开发成果进行严格的检查，通过之后这个阶段才算结束；保
证质量，提高可维护性；
当软件规模庞大，或者的需求模糊或随时间而变化时
，传统方法学往往不成功；维护起来仍然很困难。
2 、面向对象方法学
—— 强调主动地多次反复迭代
面向对象方法：把数据和行为看成同等重要，它是一种
以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
面向对象方法学 4 个要点：
对象 (object) ：融合了数据及在数据上的操作行为。
类 (class) ：类是对具有相同数据和相同操作的一组相似
对象的定义。
继承：按照父类与子类的关系，把若干个相关类组成一
个层次结构的系统。
消息：对象彼此间仅能通过发送消息互相联系。
 面向对象方法学的优点：
面向对象方法学的尽量模拟人类习惯的思维方式，使开
发软件的方法与过程尽可能接近人类认识世界解决问题的方法与
过程。
面向对象方法学开发软件的过程，是一个主动地多次反
复迭代的演化过程，保证了在各项开发活动之间的平滑过渡。
促进了软件重用。最终的软件产品由许多较小的、基本
上独立的对象组成，每个对象相当于一个微型程序，而且大多数
对象都与现实世界中的实体相对应，降低了复杂性，提高了可理
解性，简化了开发和维护工作。

软件发展趋势：
以面向对象技术为手段，以可重用软件构件化和
体系架构为基础，以工业化生产方式和管理支撑体系为核心
的软件新变革。
1.3 软件生命周期
软件生命周期：指软件从提出到最终被淘汰的存在期。
三个时期八个阶段：软件生命周期由软件定义、软件开
发和运行维护（也称为软件维护）三个时期组成，每个时期又进
一步划分成若干个阶段。
三个时期： 八个阶段：
问题定义
软件定义 可行性研究
需求分析
概要设计
系统设计
软件生命周期 软件开发 详细设计
编码和单元测试
系统实现
综合测试

软件维护 运行维护
1. 问题定义（系统定义） 任务：问题是什么
◦ 通过对客户的访问调查，系统分析员扼要地写出关于问题性质
、工程目标和工程规模的书面报告。
◦ 经过讨论和必要的修改之后这份报告应该得到客户的确认。
结果：
◦ 关于系统规模和目标的报告书

2. 可行性研究 任务：有可行的解吗
◦ 系统分析员需要进行一次大大压缩和简化了的系统分析和设计
过程。
◦ 研究问题的范围，探索这个问题是否值得去解，是否有可行的
解决办法。
结果：
◦ 系统的高层逻辑模型（数据流图、成本效益分析）
◦ 可行性论证报告（立即进行 / 推迟进行 / 不能或不值得进行）
3. 需求分析 任务：必须做什么
◦ 主要是确定目标系统必须具备哪些功能。
◦ 系统分析员必须和用户密切配合，充分交流信息，以得出经过
用户确认的系统逻辑模型。
结果：
◦ 系统的逻辑模型（数据流图、数据字典、简要的算法描述）
◦ 用规格说明书准确地记录对目标系统的需求

4. 总体设计 任务：如何解决已提出的问题
◦ 设计出实现目标系统的几种可能的方案（低、中、高成本）。
◦ 用适当的表达工具描述每种方案，分析优缺点，推荐一个最佳方
案，制定出实现最佳方案的详细计划。设计程序的体系结构。
结果：
◦ 可能的解法（系统流程图、成本效益分析）
◦ 推荐的系统体系结构（层次图或结构图）
5. 详细设计 任务：怎样具体实现该系统
◦ 详细地设计每个模块，确定实现模块功能所需要的算法和数
据结构。
结果：
◦ 每个模块的算法和数据结构（程序流程图、 N-S 图、 PAD
图等）。

6. 编码和单元测试 任务：得到正确的程序模块
◦ 选取一种适当的高级程序设计语言 ( 必要时用汇编语言 ) ，
把详细设计的结果翻译成用选定的语言书写的程序；
◦ 并且仔细测试编写出的每一个模块。
结果：
◦ 代码和测试报告
7. 综合测试 任务：得到符合要求的软件
◦ 通过集成测试、验收测试、现场测试、平行运行等方法对
目标系统进一步测试检验。
◦ 通过对软件测试结果的分析可以预测软件的可靠性；反之
，根据对软件可靠性的要求，也可以决定测试和调试过程
什么时候可以结束。
结果：
◦ 测试计划、详细测试方案以及实际测试结果
◦ 完整一致的软件配置
8. 软件维护 任务：使系统持久地满足用户的需要
◦改正性维护，诊断和改正在使用过程中发现的软件错误；
◦适应性维护，修改软件以适应环境的变化；
◦完善性维护，根据用户的要求改进或扩充软件；
◦预防性维护，修改软件为将来的维护活动做准备。
◦每一项维护活动实质上是经历了一次压缩和简化了的软件定
义和开发的全过程。
结果：
◦完整准确的维护记录 各类维护工作量 维护工作量在软件生
所占比例 命周期所占比例

适应性维护 改正性维护
18%~25% 17%~21%
预防性维护
4%

维护
完善性维护 60%以上
50%~66%
 1.4 软件过
程
软件过程：为了获得高质量软件所需要完成的一系列任务
的框架，它规定了完成各项任务的工作步骤。
软件过程（ ISO9000 ）：使用资源将输入转化为输出的活
动所构成的系统。
输入：如软件需求
输出：如软件产品

软件过程定义了运用方法的顺序、应该交付的文档资
料、为保证软件质量和协调变化所需要采取的管理措施，以及标
志软件开发各个阶段任务完成的里程碑。为获得高质量的软件产
品，软件过程必须科学、有效。
1.4.1 瀑布模型

传统的瀑布模型 实际的瀑布模型
瀑布模型的特点：
1. 阶段间具有顺序性和依赖性
前一阶段的工作完成之后，才能开始后一阶段的工作；
前一阶段的输出文档就是后一阶段的输入文档。
2. 推迟实现的观点
对于规模较大的软件项目来说，往往编码开始得越早最
终完成开发工作所需要的时间反而越长。
3. 质量保证的观点
每个阶段都必须完成规定的文档，是“文档驱动”的模
型；
每个阶段结束前都要对所完成的文档进行评审，尽早发现
问题，改正错误。
瀑布模型的优点：
可强迫开发人员采用规范的方法；
严格地规定了每个阶段必须提交的文档；
要求每个阶段交出的所有产品都必须经过质量保证小组的
仔细验证。
瀑布模型的缺点：
只能通过文档了解产品，不经过实践的需求是不切实际的
。
瀑布模型适用于：
需求是预知的； 软件实现方法是成熟的；项目周期较短。
1.4.2 快速原型模型
快速原型：是快速建立起来的可
以在计算机上运行的程序，它所能完成
的功能往往是最终产品能完成的功能的
一个子集。

快速原型模型的特点：
快速原型模型不带反馈环，软
件产品的开发基本上是线性顺序进行的。
快速原型的本质是“快速”。
应该尽可能快地建造出原型系统，以加速
软件开发过程，节约成本。
快速原型模型
 1.4.3 增量模型
增量模型把软件产品作为一系列的增量构件来设计、编
码、集成和测试。每个构件由多个相互作用的模块构成，并且能够
完成特定的功能。
增量模型的优点：
人员分配灵活，刚开始不
用投入大量人力资源。
当配备的人员不能在设定
的期限内完成产品时，它提供了一
种先推出核心产品的途径。
逐步增加产品功能可以
使用户有较充裕的时间学习和适应
新产品。
增量模型的难点：
软件体系结构必须是开放的。
模型本身是自相矛盾的。整体——独立构件。
不同的构件并行地构建有可能加快工程进度，但
是冒无法集成到一起的风险。

增量模型适用于：
适用于需求经常改变的软件开发过程。
如果在项目既定的商业要求期限之前不可能找到
足够的开发人员，在这种情况下，增量模型显得特别有用。
一种风险更大的增量模型：
1.4.4 螺旋模型
螺旋模型的基本思想：
使用原型及其他方法来尽
量降低风险。可以把它看作在每个
阶段之前都增加了风险分析过程的
快速原型模型。
螺旋模型的优点：
主要优势在于它是风险驱动的
。
对可选方案和约束条件的强调
有利于已有软件的重用，也有助于把软
件质量作为软件开发的一个重要目标；
减少了过多测试或测试不足所
带来的风险；
维护只是模型的另一个周期， 简化的螺旋模型
维护和开发之间没有本质区别。
完整的螺旋模型
螺旋模型的缺点：
采用螺旋模型需要具有相当丰富的风险评估经验和
专门知识，在风险较大的项目开发中，如果未能够及时标识风
险，势必造成重大损失。
过多的迭代次数会增加开发成本，延迟提交时间。
螺旋模型适用于：
特别适用于庞大、复杂并具有高风险的系统。
适用于内部开发的大规模软件项目。
1.4.5 喷泉模型
喷泉模型：是典型
的面向对象生命周期模型。
“喷泉”这个词体现了面向对
象软件开发过程迭代和无缝的
特性。为避免使用喷泉模型开
发软件时开发过程过分无序，
应该把一个线性过程 ( 例如，
快速原型模型或图中的中心垂
线 ) 作为总目标。
喷泉模型的优点：
该模型的各个阶段没有明显的界限，开发人员可以同
步进行开发。多次反复地增加或明确目标系统，而不是本质性的
改动，降低错误的可能性。
喷泉模型的缺点：
由于喷泉模型在各个开发阶段是重叠的，因此在开发
过程中需要大量的开发人员，不利于项目的管理。
要求严格管理文档，使得审核的难度加大，尤其是面
对可能随时加入各种信息、需求与资料的情况。
喷泉模型适用于：适用于面向对象的软件开发过程。
1.4.6 Rational 统一过程
Rational 统一过程 (Rational Unified Process, RUP)
是由 Rational 软件公司推出的一种完整而完美的软
件过程。
RUP 是一种迭代的，以架构为中心的，用例驱动的
软件开发方法。强调用迭代和渐增的方式开发软件
。
RUP 是一种具有明确定义和结构的软件工程过程。
RUP 被广泛应用在不同工业领域中的不同企业中。
RUP 总结了 6 条软件开发经验——最佳实践：
迭代式开发
管理需求：有效地捕获需求，用于设计和实现
使用基于构件（模块或子系统）的体系结构
可视化建模：采用图形形式建模（ UML ）
验证软件质量：贯穿于整个开发过程中
控制软件变更：描述了如何控制、跟踪和监控修改
RUP 软件开发生命周期 ( 二维 ) ：

核
心
过
程

核
心
支
持

时间
 1.4.7 敏捷过程与极限编程
1. 敏捷过程 具有高效、快速响应变化的开发过程。其核心价
值观是：
（ 1 ）个体和交互胜过过程和工具；
（ 2 ）可以工作的软件胜过面面俱到的文档；
（ 3 ）客户合作胜过合同谈判；
（ 4 ）响应变化胜过遵循计划。
2. 极限编程 : 敏捷过程中最著名的一种，指把好的开发实践运用
到极致，多应用于软件需求模糊的场合。使得敏捷过程能够较好
地适应商业竞争环境下对小型项目提出的有限资源和有限开发时
间的约束。
XP 项目的整体开发过程
XP 迭代开发过程
1.4.8 微软过程
1 、微软过程准则
2 、微软软件生命周期
3 、微软过程模型
◦每一个生命周期发布一个递进的版本，各生命周期持续
快速地迭代循环
◦优点： 综合了 Rational 统一过程和敏捷过程的优点
◦缺点：对方法、工具和产品等方面的论述不够全面
 课程小结
计算机软件
◦ 基础概念、计算机软件系统发展；
软件危机
◦ 典型表现、原因、解决方法
软件工程
◦ 基本特征、原理、方法学
软件生命周期
◦ 三个时期、八个阶段
软件过程
◦ 过程模型
课后思考题
1. 什么是软件危机，它有哪些典型表现？为何
会出现软件危机？
2. 什么是软件工程？如何利用软件工程消除软
件危机？
3. 什么是软件过程？它与软件工程方法学有何
关系？
4. 什么是软件生命周期？试比较每种模型的适
用范围。