软件工程：1.概述

软件工程是研究软件开发技术和软件项目管理的一门工程学科，从工程化的角度来指导软件开发、测试和项目管理等活动。

1.1 软件的概念和特点

计算机系统的构成及实现

计算机系统由硬件系统及软件系统构成，硬件系统的实现靠硬件工程，软件系统的实现靠软件工程。

软件的概念

软件（Software）是计算机系统中与硬件相互依存的另一部分，它包括程序、数据及其相关文档的完整集合。

软件 = 程序 + 数据 + 文档

• 程序是为实现软件的功能和性能要求而编写的指令序列。
• 数据是指使程序能够正常操纵信息的数据结构。
• 文档是与程序开发、维护和使用有关的图文资料。

程序 = 输入 + 数据结构 + 算法 + 系统 + 输出

软件的特点

1. 软件是一种逻辑实体而非物理实体，因而软件具有抽象性。
2. 软件的开发是人的智力的高度发挥，而不是传统意义上的硬件制造。
3. 软件可能被废弃，但不会用坏，不存在磨损、消耗问题。
4. 软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性。
5. 软件的开发至今尚未完全摆脱手工艺的开发方式，使软件的开发效率受到很大限制。
6. 软件开发是一个复杂的过程。实际问题的复杂性，程序逻辑结构的复杂性。
7. 软件成本非常高昂。

软件的分类

• 系统软件，分为操作系统和支撑软件。
• 应用软件。

1.2 软件的发展和软件危机

计算机软件的发展

计算机软件的开发经历了三个发展阶段：

计算机软件发展的三个阶段及其特点

特点\阶段	程序设计	软件设计	软件工程
软件所指	程序	程序及说明书	程序+数据+文档
主要程序设计语言	汇编及机器语言	高级语言	软件语言
软件工作范围	程序编写	设计和测试	整个软件生命周期
需求者	程序设计者本人	少数用户	市场用户
开发软件的组织	个人	开发小组	开发小组及大、中型开发机构
软件规模	小型	中、小型	大、中、小型
决定质量的因素	个人技术	小组技术水平	技术与管理水平
开发技术和手段	子程序、程序库	结构化程序设计	数据库、开发工具、集成开发环境、工程化开发方法、标准和规范、网络及分布式开发、面向对象技术、计算机辅助软件工程
维护责任者	程序设计者	开发小组	专职维护人员
硬件的特征	高价、存储容量小、可靠性差	降价，速度、容量和可靠性明显提高	向超高速、大容量、网络化、微型化方法发展
软件的特征	完全不受重视	软件的技术发展不能满足需求，出现软件危机	开发技术有进步，但仍未完全摆脱软件危机

软件危机

20世纪60年代末70年代初，西方工业发达国家经历了一场“软件危机”。这场软件危机表现在：一方面软件十分复杂，价格昂贵，供需差日益增大，另一方面软件开发时又常常受挫，质量差，指定的进度和完成日期很少能按时实现，研制过程很难管理，即软件的研制往往失去控制。

落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象称为软件危机。

软件危机的表现

1. 经费预算经常突破，完成时间一再拖延。
2. 开发的软件不能满足用户要求。
3. 开发的软件可靠性差。
4. 开发的软件可维护性差。

软件危机产生的主要原因

1. 软件规模越来越大，结构越来越复杂。
2. 软件开发管理困难。
3. 软件开发费用不断增加。
4. 软件开发技术落后。
5. 生产方式落后。
6. 开发工具落后，生产率提高缓慢。

消除软件危机的途径

消除软件危机的途径既要有技术措施（方法、工具），又要有组织管理措施，将两者结合起来以现代工程方法来开发软件。

1. 消除错误的观点和做法。
2. 推广使用成功的开发技术和方法。
3. 开发使用软件工具和软件工程支持环境。
4. 加强软件工程管理。

1.3 软件工程及其原理

软件工程的概念

软件工程的概念于 1968 年 NATO（North Atlantic Treaty Organization，北大西洋公约组织）在德国召开的一次会议上首次提出。

Friedrich Ludwig Bauer

为了消除和缓解软件危机，1968 年德国软件大师鲍尔（Bauer）在北大西洋公约组织会议上提出软件工程的定义：

建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

软件工程大师勃姆（Boehm）对软件工程的定义：

运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

1983 年 IEEE 的软件工程定义：

软件工程是开发、运行 、维护和修复软件的系统方法。

1993 年 IEEE 的一个更加综合的定义：

将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。

软件工程三要素：方法、工具和过程

软件工程方法为软件开发提供了如何做的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。

软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。目前，已经推出了许多软件工具，这些软件工具集成起来，形成一个计算机辅助软件工程（CASE）的软件开发支撑环境。

软件工程过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。

软件工程的目标

软件工程的目标是“以较少的投资获得高质量的软件”，具体包括：

• 付出较低的开发成本；
• 达到要求的软件功能；
• 取得较好的软件性能；
• 开发的软件易于移植；
• 需要较低的维护费用；
• 按时完成开发工作，及时交付使用。

软件工程的目标，有些是互补关系，有些是互斥关系。需要按照其重要性确定其优先级并进行适当地折衷。

软件工程目标之间的关系

软件工程的原则

1. 选择合适的开发模型。
2. 采用合适的设计方法。
3. 提供高质量的工程支持。
4. 重视开发过程的管理。

软件工程的基本原理

Boehm 在综合了专家学者意见和总结多年软件开发实践的基础上于 1983 年提出了软件工程的 7 条基本原理：

1. 用分阶段的生命周期计划严格管理软件工程过程，因为 50% 以上的失败是由于计划不周。
2. 坚持在软件工程过程中进行阶段评审，因大部分错误是在编码之前造成的。
3. 实行严格的产品控制，变动控制，即“基本配置管理”。
4. 采用现代的开发技术进行软件的设计与开发，“方法大于力气”。
5. 工作结果应当能够清楚地审查。应规定开发小组的责任和产品标准。

6. 开发小组的人员应该“少而精”。
   开发小组要由各方面的专家组成，并且要少而精。当开发小组人数为 N 时，可能的通信路径有 N(N-1)/2，并且随着人数的增加，通信路径和费用急剧增加。

   
   
7. 承认不断改进软件工程实践的必要性。

软件开发方法

1.结构化方法

结构化方法（Structure Method）的基本思想可以概括为：自顶向下、逐步求精，采用模块化技术、分而治之的方法，将系统按功能分解成若干模块；模块内部由顺序、分支、循环三种基本控制结构组成；子程序实现模块化。

2.面向对象方法

面向对象方法（Objected-Oriented Method）认为：客观世界由各种对象组成，每个对象都有各自内部状态和运动规律，不同对象之间相互作用和联系构成了各种各样的系统，构成了客观世界。

面向对象方法吸取了结构化方法的基本思想和主要优点，将数据与操作放在一起，作为一个相互依存、不可分割的整体进行处理。它综合了功能抽象和数据抽象，采用数据抽象和信息隐蔽技术，将问题求解看作是一个分类演绎过程。与结构化方法相比，面向对象更接近人们认识事物和解决问题的过程和思维方式。

1.4 软件生存期

软件生存期（Software Life Cycle）是指软件产品开发的一系列相关活动的整个生命期，即从软件定义开始，经过软件开发、交付使用到运行与维护，直到最终被废弃的整个时期。它由三个时期构成，每个时期进一步划分成若干阶段。

1.4.1 软件定义时期

软件定义时期的任务:

• 确定软件开发工程必须完成的总目标；
• 确定工程的可行性；
• 导出实现工程目标应该采取的措施与系统必须完成的功能；
• 估算完成该工程需要的资源和成本；
• 制定工程进度表。

该任务又称为系统分析，由系统分析员负责完成。

软件定义部分又可划分为问题定义、可行性研究和需求分析三个阶段。

1.4.1.1 问题定义

问题定义的任务：搞清楚“要解决的问题是什么”。

如果不知道要解决的问题是什么，就没有办法解决问题，或者只能盲目的解决，最终的结果不但解决不了问题，还浪费人力、物力、时间和金钱。

系统分析员通过对问题的调研，写出关于问题性质、工程目标和工程规模的书面报告，并且要得到用户的确认。

1.4.1.2 可行性研究

可行性研究的任务：了解用户的要求及实现的环境，从技术、经济、操作和法律等方面研究并论证软件系统的可行性。

1.4.1.3 需求分析

需求分析阶段的任务：确定“目标系统必须做什么”。

需求分析在可行性分析的基础上，对用户需求进一步做深入细致的调研，对目标系统提出完整、准确、清晰、具体的要求，以便顺利进行后续阶段的工作。

在该阶段系统分析员必须和用户密切配合、充分交流信息，以便得出经过用户确认的系统需求，并撰写出需求规格说明书。

1.4.2 软件开发时期

软件开发时期的任务是具体设计和实现软件定义部分定义的软件。

软件开发时期又分为概要设计、详细设计、编码与单元测试、综合测试四个阶段。

概要设计和详细设计又称为系统设计，编码与单元测试和综合测试又称为系统实现。

1.4.2.1 概要设计

概要设计也称为总体设计。

概要设计阶段的任务：确定目标系统必须怎样做，概括的提出解决问题的办法。

概要设计要完成的基本任务：根据软件需求规格说明书建立系统的总体结构和模块间的关系，定义各个功能模块的接口，设计数据库或数据结构，规定设计约束，制定组装测试计划。编写概要设计说明书。

1.4.2.2 详细设计

详细设计也称为模块设计、物理设计。

详细设计阶段的任务：怎样具体地实现目标系统。把概要设计的解法具体化，将概要设计产生的功能模块逐步细化，形成若干个可编程的模块，并用某种过程设计语言（PDL）设计程序模块的内部细节。撰写详细设计说明书。

1.4.2.3 编码与单元测试

编码阶段的任务：把每个模块的控制结构写成计算机可接受的程序代码。并对编写出的每个模块代码进行认真细致地的测试。

1.4.2.4 综合测试

综合测试阶段的任务：通过各种类型的测试使软件达到预期的效果。

单元测试 -> 集成测试 -> 系统测试 -> 验收测试

1.4.3 软件运行维护时期

运行与维护部分的任务是使软件永久地满足用户的需求。

• 修正性维护：改正软件在使用过程中发现的错误；
• 适应性维护：修改软件以适应新的运行环境；
• 完善性维护：改进软件满足用户新的需求；
• 预防性维护：为了给未来的改进提供更好的基础或改善软件未来的可维护性或可靠性而做出的修改。

软件退役是软件生存周期中的最后一个阶段，终止对软件产品的支持，软件停止使用。

1.4.4 软件生存期总结

1.5 软件生存周期模型

软件生存周期：软件有一个孕育、诞生、成长、成熟、衰亡的生存过程，这个过程即为软件的生存周期。

软件生存周期模型：描述软件开发过程中各种活动如何执行的模型。软件生存周期模型确立了软件开发和演绎中各阶段的次序以及各阶段活动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调和人员通信，有利于活动重用和活动管理。

常见的软件生存周期模型：瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型等。

1.5.1 瀑布模型

瀑布模型（Waterfall Model） 是将软件生存周期规定为依线性顺序联接的若干阶段的模型。它包括问题定义、可行性分析、需求分析、概要设计、详细设计、编码、测试和维护。 它规定了由前至后、相互衔接的固定次序。

瀑布模型为软件开发提供了一种有效的管理模型。根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段，有效地对整个开发过程进行指导。因此它是以文档作为驱动、适合于需求很明确的软件项目开发的模型。

瀑布模型

瀑布模型的特点

1. 阶段明确清楚。
2. 经典。

瀑布模型的缺点

1. 用户看到软件产品的时间靠后，因此开发的产品很可能不是建立在全面、正确认识基础上的。
2. 测试放在最后，出错后修改的代价高。

1.5.2 原型模型

原型模型（Prototyping Model） 又称为快速原型模型。

核心思想是：在软件开发的早期，软件开发人员根据用户提出的软件需求快速建立目标系统的原型，反复让用户对原型进行评估并提出修改意见，开发人员根据用户意见对原型进行修补和完善，直到用户对所开发的系统原型满意为止。

原型模型

原型模型的两种类型

1. 演进型原型：与客户一起工作，通过反复向客户演示原型系统并征求他们的意见，进行不断地修改，从而迭代出满足客户需求的可交付使用的最终产品。
2. 废弃型原型：其用途是为了获得用户的真正需求，一旦需求确定了，原型将被抛弃。

原型模型的适用范围

• 特别适用需求分析与定义规格说明；
• 设计人机界面；
• 充作同步培训工具。

1.5.3 增量模型

增量模型（Increment Model） 是一种非整体开发模型。软件在该模型中是“逐渐”被开发出来的，软件开发出一部分，就向用户展示一部分，可让用户及早看到部分软件，及早发现问题。或者先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。

瀑布模型是一种整体开发模型。在开发过程中，用户看不到软件是什么样子，只有开发完成后，整个软件才全部展现在用户面前。这时如果用户发现有不满意的地方，为时已晚。增量模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。

增量模型

例：用增量模型开发一个文字处理软件。

增量1：基本的文字输入和编辑功能；
增量2：格式处理功能；
增量3：拼写检查功能；
增量4：排版和打印功能。

增量模型的优点

1. 能在较短的时间内向用户提供一些已完成的且有用的工作产品。
2. 逐步增加的产品功能使用户有充足时间学习适应新产品。

使用增量模型应注意：在把每个新的构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。

1.5.4 螺旋模型

螺旋模型（Spiral Model） 是 Boehm 于 1988 年提出来的。螺旋模型是在原型模型的基础上扩展而成的，它结合了瀑布模型的特点，并在原有的基础上加入了风险分析的机制。

螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险。

螺旋模型通常用来指导大型软件项目的开发，它将开发划分为制订计划、风险分析、实施开发和客户评估四类活动。

螺旋模型

螺旋模型沿着螺线旋转，每转一圈，表示开发出一个更完善的新的软件版本。四个象限分别表达了四个方面的活动，即：

• 制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件。
• 风险分析──分析所选方案，考虑如何识别和消除风险。
• 实施工程──实施软件开发。
• 客户评估──评价开发工作，提出修正建议。

螺旋模型的优点

对软件开发风险有充分认识，因此适用于内部开发的大规模软件项目。

但进行风险评估需要开发人员具有丰富的开发经验和各方面的专业知识。

1.5.5 喷泉模型

喷泉模型（Water Fountain Model） 是 B.H.Sollers 和 J.M.Edwards 于 1990 年提出的一种软件开发模型。喷泉模型是以面向对象的软件开发技术为基础，以用户需求为动力，以对象来驱动的模型。它克服了瀑布模型不支持软件重用和生存期中多项开发活动集成的局限性，使得软件开发过程具有迭代和无缝的特性。

喷泉模型