第一章 软件工程学概述
迄今为止，计算机系统已经经历了4个不同的发展阶段(主要元器件分别是：电子管；晶体管；中、小规模集成电路；大规模、超大规模集成电路)，但是，人们仍然没有彻底摆脱“软件危机”的困扰，软件已经成为限制计算机系统发展的瓶颈。
为了更有效地开发与维护软件，软件工作者在20世纪60年代后期开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科——计算机软件工程学（简称为软件工程）。
1.1 软件危机
1.1.1 软件危机的介绍
软件危机是指：在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机包含下述两方面问题：
（1）如何开发软件，以满足对软件日益增长的需求；
（2）如何维护数量不断膨胀的已有软件。
软件危机的典型表现：
1、对软件开发成本和进度的估计常常很不准确
2、用户对“已完成的”软件系统不满意的现象经常发生
3、软件产品的质量往往靠不住。
4、软件常常是不可维护的。
5、软件通常没有适当的文档资料。
6、软件成本在计算机系统总成本中所占的比例逐年上升。美国1985年，软件成本约占90%。
7、软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
1.1.2 产生软件危机的原因
与软件本身的特点有关系：
- 软件不同于硬件，软件缺乏可见性，管理和控制软件开发过程相当困难。
- 软件在运行过程中不会因为使用时间过长而被 “用坏 “如果运行中发现了错误,很可能是遇到了一个在开发时期引入的在测试阶段没能检测出来的错误。
- 软件不同于一般程序 ，它的一个显著特点是规模庞大 ，而且程序复杂性将随着程序规模的增加而呈指数上升。
- 目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念 。在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
- 错误的认识和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行,轻视软件维护等
- 事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。
软件开发与维护的方法不正确有关：
- 只重视程序而忽视软件配置其余成分的糊涂观念。
- 软件开发人员在定义时期没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现 “已完成的 ”软件不完全符合用户的需要。
- 严重的问题是在软件开发的不同阶段进行修改需要付出的代价是很不相同的。
在软件开发的不同阶段进行修改需要付出的代价：
1.1.3 消除软件危机的途径
- 首先应该对计算机软件有一个正确的认识。事实上，软件是程序、数据及相关文档的完整集合。
- 充分认识到软件开发不是某种个体劳动的神秘技巧 ，而应该是各类人员协同配合，共同完成的工程项目。
- 推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法。
- 应该开发和使用更好的软件工具。
总之，从管理和技术两方面研究解决软件危机。
1.2 软件工程
1.2.1 软件工程的介绍
软件工程概述
软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
软件工程的两个典型定义：
- 1968年在第一届NATO会议上曾经给出了软件工程的一个早期定义：
“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。” - 1993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是：
①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；
②研究①中提到的途径。
软件工程具有的本质特征：
- 软件工程关注于大型程序的构造
通常把一个人在较短时间内写出的程序称为小型程序。
把多人合作用时半年以上才写的程序称为大型程序。 - 软件工程的中心课题是控制复杂性
不能把问题作为整体通盘考虑，人们不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。 - 软件经常变化
现实世界不断变化，软件为了不被淘汰，必须随着所模拟的现实世界一起变化。 - 开发软件的效率非常重要
- 和谐地合作是开发软件的关键
- 软件必须有效地支持它的用户
必须仔细的研究用户，适当地培训用户。 - 在软件工程领域中通常有具有一种文化背景的人替具有另一种文化背景的人创造产品
软件工程师+领域专家
1.2.2 软件工程的基本原理
1、用分阶段的生命周期计划严格管理
2、坚持进行阶段评审
3、实行严格的产品控制
一切有关修改软件的建议，特别是涉及对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能随意修改。
4、采用现代程序设计技术
5、结果应能清楚地审查
6、开发小组的人员应该少而精
7、承认不断改进软件工程实践的必要性
1.2.3 软件工程方法学
软件工程方法学包含3个要素：方法、工具和过程。
方法：完成软件开发的各项任务的技术方法，回答“怎样做”的问题
工具：为运用方法而提供的自动的或半自动的软件工程支撑环境
过程：为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤
目前，软件工程方法学主要分为以下两类：
-
传统方法学
概念：传统方法学也称为生命周期方法学或结构化范型。
它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。传统方法学的特点：
(1)传统方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。
(2)每个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。
(3)在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审。
审查的一条主要标准就是每个阶段都应该交出“最新式的”(即和所开发的软件完全一致的)高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。 -
面向对象方法学：
概念：
面向对象方法把数据和行为看成是同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。面向对象方法学具有下述四个要点：
① 把对象(object)作为融合了数据及在数据上的操作行为的统一的软件构件。
② 把所有对象都划分成类(class)。
③ 按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。 （继承性）
④ 对象彼此间仅能通过发送消息互相联系。(封装性)面向对象方法学基本原则：
尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程，从而使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。面向对象方法学优点：
降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。
面向对象方法特有的继承性和多态性，进一步提高了面向对象软件的可重用性。
1.3 软件生命周期
软件生命周期每个阶段的基本任务：
-
问题定义
① 回答“要解决的问题是什么？”
② 通过对客户访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告。 -
可行性研究
① 回答“对于上一阶段所确定的问题有行得通的解决办法吗？”；
② 探索这个问题是否值得去解，是否有可行的解决办法；
③ 及时终止不值得投资的工程项目，可以避免更大的浪费。 -
需求分析
① 回答“为了解决这个问题，目标系统必须做什么？”；
② 主要是确定目标系统必须具备哪些功能；
③ 必须准确完整地体现用户的要求。 -
概要设计
① 回答“概括地说，应该怎样实现目标系统？”，又称概要设计；
② 设计出实现目标系统的几种可能的方案；
③ 推荐一个最佳方案，制定出实现最佳方案的详细计划；
④ 确定程序由哪些模块组成以及模块间的关系。 -
详细设计
① 回答“应该怎样具体地实现这个系统呢？”；
② 又称模块设计，详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。 -
编码与单元测试
① 关键任务：写出正确的容易理解、容易维护的程序模块；
② 选取一种适当的高级程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。 -
综合测试
① 关键任务：通过各种类型的测试使软件达到预定的要求；
② 集成测试、验收测试、现场测试、平行运行等测试方法 -
运行维护
① 关键任务：通过各种必要的维护活动，使系统持久地满足用户的需要；
② 改正性维护、适应性维护、完善性维护、预防性维护
在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素，都影响阶段的划分。
1.4 软件过程
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件过程描述为了开发出客户需要的软件，什么人（who）、在什么时候（when）、做什么事（what）以及怎样（how）做这些事以实现某一个特定的具体目标。
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件过程描述为了开发出客户需要的软件，什么人（who）、在什么时候（when）、做什么事（what）以及怎样（how）做这些事以实现某一个特定的具体目标。
1.4.1 瀑布模型
瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。
按照传统的瀑布模型开发软件，有下述的几个特点。
- 阶段间具有顺序性和依赖性
两重含义：
①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
②前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。 - 推迟实现的观点
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。 - 质量保证的观点
软件工程的基本目标是优质、高产。
为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法。
① 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
② 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。
实际的瀑布模型是带“反馈环”的：
瀑布模型有许多优点：
① 可强迫开发人员采用规范的方法（例如，结构化技术）；
② 严格地规定了每个阶段必须提交的文档；
③ 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点： 由文档驱动的
1.4.2 快速原型模型
概念：
快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型模型是不带反馈环的，这正是这种过程模型的主要优点： 软件产品的开发基本上是线性顺序进行的。
快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。
能基本上做到线性顺序开发的主要原因如下：
（1） 原型系统已经通过与用户交互而得到验证
据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
（2） 开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
1.4.3 增量模型
概念：
增量模型也称为渐增模型。
使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。
使用增量模型的优点：
能在较短时间内向用户提交可完成部分工作的产品。
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
使用增量模型的困难：
在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
还有一种风险更大的增量模型：构件可能无法集成到一起。
1.4.4 螺旋模型
概念：
螺旋模型的基本思想：使用原型及其他方法来尽量降低风险。
理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。
1.4.5 喷泉模型
概念：
“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。
迭代是软件开发过程中普遍存在的一种内在属性。用面向对象方法学开发软件时，工作重点应该放在生命周期中的分析阶段。
1.4.6 Rational统一过程
概念：
Rational统一过程（Rational Unified Process,RUP）是由Rational软件公司推出的一种完整而且完美的软件过程。
RUP总结了经过多年商业化验证的6条最有效的软件开发经验，这些经验被称为“最佳实践”。
最佳实践
① 迭代式开发
迭代式开发允许在每次迭代过程中需求都可以有变化，这种开发方法通过一系列细化来加深对问题的理解，因此能更容易地容纳需求的变更。
② 管理需求
RUP描述了如何提取、组织系统的功能性需求和约束条件并把它们文档化。
③ 使用基于构件的体系结构
RUP提供了使用现有的或新开发的构件定义体系结构的系统化方法，从而有助于降低软件开发的复杂性，提高软件重用率。
④ 可视化建模
可视化建模语言UML紧密地联系在一起，在开发过程中建立起软件系统的可视化模型，可以帮助人们提高管理软件复杂性的能力。
⑤ 验证软件质量
软件质量评估不再是事后型的或由单独小组进行的孤立活动，而是内建在贯穿于整个开发过程的、由全体成员参与的所有活动中。
⑥ 控制软件变更
RUP描述了如何控制、跟踪和监控修改，以确保迭代开发的成功。
RUP软件开发生命周期
RUP软件开发生命周期是一个二维的生命周期模型 。
(1)核心工作流
RUP中有9个核心工作流，其中前6个为核心过程工作流程，后3个为核心支持工作流程。
6个核心过程工作流
- 业务建模：深入了解使用目标系统的机构及其商业动作
- 需求：捕获客户需求，使开发人员与用户达成需求共识
- 分析与设计：把需求分析的结果转化成分析模型与设计模型
- 实现：把设计模型转换成实现结果
- 测试：识别、确认缺陷并确保在软件部署前消除缺陷
- 部署：生成可运行版本，把软件移交给最终用户
3个核心支持工作流
- 配置与变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性
- 项目管理：提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的实用准则
- 环境：向软件开发机构提供软件开发环境，包括过程管理和工具支持
(2)工作阶段
RUP把软件生命周期划分成4个连续的阶段。
每个阶段都有明确的目标，并且定义了用来评估是否达到这些目标的里程碑。
每个阶段的目标通过一次或多次迭代来完成。
- 初始阶段： 建立业务模型，定义最终产品视图，并且确定项目的范围。
- 精化阶段： 设计并确定系统的体系结构，制定项目计划，确定资源需求。
构建阶段： 开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能。 - 移交阶段： 把开发出的产品提交给用户使用。
(3)RUP迭代式开发
RUP强调采用迭代和渐增的方式来开发软件。
RUP重复一系列组成软件生命周期的循环。
每次循环都经历一个完整的生命周期，每次循环结束都向用户交付产品的一个可运行的版本。
每个阶段又进一步细分为一次或多次迭代过程。
1.4.7 敏捷过程与极限编程
敏捷过程
概念：
敏捷过程：为了使软件开发团队具有高效工作和快速响应变化的能力，17位著名的软件专家于2001年2月联合起草了敏捷软件开发宣言。
敏捷软件开发宣言由下述4个简单的价值观声明组成。
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
极限编程
极限编程：
极限编程（eXtreme Programming,XP）是敏捷过程中最富盛名的一个，其名称中“极限”二字的含义是指把好的开发实践运用到极致。
目前，极限编程已经成为一种典型的开发方法，广泛应用于需求模糊且经常改变的场合。
极限项目的整体开发过程：
极限编程的迭代过程：
首先，项目组针对客户代表提出的“用户故事” 进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探”
然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划。
接下来开始多个迭代过程，在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次开发过程不受干扰。开发出的新版本软件通过验收测试之后交付用户使用。
1.4.8 微软过程
微软过程准则：
- 项目计划应该兼顾未来的不确定因素。
- 用有效的风险管理来减少不确定因素的影响。
- 经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性。
- 采用快速循环、递进的开发过程。
- 用创造性的工作来平衡产品特性和产品成本。
- 项目进度表应该具有较高稳定性和权威性。
- 使用小型项目组并发地完成开发工作。
- 在项目早期把软件配置项基线化，项目后期则冻结产品。
- 使用原型验证概念，对项目进行早期论证。
- 把零缺陷作为追求的目标。
- 里程碑评审会的目的是改进工作，切忌相互指责。
微软软件生命周期：
规划阶段 - 设计阶段 - 开发阶段 - 稳定阶段 - 发布阶段
微软软件生命周期阶段划分和主要里程碑
微软过程模型：
微软过程的每一个生命周期发布一个递进的软件版本，各个生命周期持续、快速地迭代循环。
微软过程的生命周期模型：
1.5 本章小结
- 本章对计算机软件工程学作一个简短的概述，回顾计算机系统发展简史。
- 本章介绍 软件工程的基本原理和方法有概括的本质的认识，详细讲解生命周期相关知识。
- 详细讲解8种典型的软件过程模型。
作业
- 软件危机的定义？
- 产生软件危机的原因。
- 什么是软件工程。
- 软件工程基本原理
- 软件工程方法学的三要素
- 软件生命周期：三个时期 八个任务
- 软件过程的定义及模型（至少前5个）