软件工程

软件工程学概论

软件危机的介绍（填空）

软件危机是指在计算机软件开发与维护的过程中所遇到的一系列严重问题

软件危机的典型表现（填空）

1. 对软件开发的成本与进度的估计往往不准确

2. 用户对“已完成的”软件系统往往不满意的现象经常发生

3. 软件产品的质量往往是靠不住的

4. 软件通常是不可维护的

5. 软件通常没有适当的文档资料

6. 软件成本在计算机系统总成本中所占的比例逐年上升

7. 软件开发生成率提高的速度，远远跟不上计算机应用迅速普及深入的趋势

软件开发的三个时期（填空）

1. 软件定义

2. 软件开发

3. 运行维护

软件开发的每个阶段的基本任务（填空）

1. 问题定义

2. 可行性分析

3. 需求分析

4. 总体设计

5. 详细设计

6. 编码与单元测试

7. 综合测试

8. 软件维护

软件工程方法学的三要素

过程、方法、工具

软件过程（注意标题与项目对应）

瀑布流模型

线性，需要文档

不适合需求模糊的系统，适合开发需求明确的软件

带反馈的瀑布流模型

优点：

• 可强迫开发人员采用规范的方法；

• 严格地规定了每个阶段必须提交的文档；

• 要求每个阶段的所有产品都必须经过质量保证小组的仔细验证；

缺点：

• 无法解决软件需求不明确或不准确的问题；可能导致最终开发的产品不能真正满足用户需要。

• 瀑布模型比较适合开发需求明确的软件。

• 最大原因：文档驱动

快速原型模型

原型是快速实现和运行的早期版本，反映最终系统部分重要特性。 常见的原型实例：人机界面；系统主要功能

用户确认原型系统之后，开发人员据此书写规格说明文档，进行下一步开发，而瀑布模型是先文档再开发

不带反馈环

优点： 软件产品的开发基本上是线性顺序进行的

增量模型

把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。

使用增量模型时，第一个阶段的增量构件往往实现软件的基本需求，提供最核心的功能；后面的增量构架逐渐添加系统的功能

必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计；

不同于瀑布流：概要和详细设计

不同于快速原型：非全部需求、非全部设计

优点：

• 能在较短的时间内，提供可完成部分工作的初步产品给用户；

• 用户有较为充裕的时间学习和适应新产品。

缺点：

• 对开发人员技术能力要求较高，要求能从系统整体出发正确划分增量构件，并进行分别开发，最后能很好地集成这些构件。

螺旋模型

快速＋风险分析

螺旋模型改进了原型模型，在每个阶段都加入风险分析-增加了风险分析的快速原型模型

喷泉模型

面向对象

迭代与无缝

Rational统一过程

四个阶段

1. 初始阶段

2. 精化阶段

3. 构建阶段

4. 移交阶段

敏捷过程与极限编程

微软过程

微软过程的每一个生命周期发布一个递进的软件版本，各个生命周期持续、快速地迭代循环

原型法和增量模型区别

原型模型适用于需求不清晰与需求经常变换的情况，增量模型不需要具体的需求

原型法和螺旋模型区别

原型模型注重快速迭代，而螺旋模型注重风险驱动与管理

敏捷过程和微软工程的适用范围

•敏捷过程具有对变化和不确定性的更快速、更敏捷的反应特性，而且在快速的同时仍然能够保持可持续的开发速度。因此较适合开发可用资源和开发时间都有较苛刻约束的小型项目。

•微软过程可以看做是RUP的一个精简配置版本，其软件过程由若干个生命周期的持续递进循环组成，每个生命周期划分为规划、设计、开发、稳定、发布5个阶段。同时，微软过程也可以看做敏捷过程的一个扩充版本，补充了敏捷过程各个阶段的具体工作流程。微软过程的适用范围是具有有限资源和有限开发时间约束的项目。

总结

例题

开发一个软件，功能为读入浮点数开平方，结果精确到小数点后4位。一旦实现并测试完成之后，该软件被抛弃。应该选用哪种生命周期模型？

瀑布流模型，因为需求明确，无需原型模型进行需求分析及设计方案验证。

开发完即抛弃，无需维护，因此有助于提高软件可维护性的增量模型和螺旋模型无用。

此类题目一般重点考虑瀑布模型、快速原型模型、增量模型、螺旋模型，其它模型可不考虑

假设你被任命为一家软件公司负责人，管理公司已被广泛应用的字处理软件的新版本开发。由于市场竞争激烈，公司规定了严格的完成期限并且已对外公布。你打算采用哪种生命周期模型？为什么

快速原型模型。

理由：

有旧版本使用经验及用户反馈，拟开发增加的新功能需求明确；

有成熟的开发团队

属于软件产品，面对市场竞争，需不断、及时更新，因此要采用开放的体系结构，便于扩充，这也是增量模型的优势

可行性研究

任务（填空）

可行性研究的目的不是解决问题，而是研究问题是否值得被解决

首先需要澄清问题的定义

再澄清问题定义后，分析员应该导出逻辑模型

可行性研究包含如下三个方面的内容（填空）

• 技术可行性：使用现有的技术能否实现这个系统

• 经济可行性：这个系统的经济效益是否超过它的开发成本

• 操作可行性：这个系统的操作方式在该客户组织内是否行得通

需求分析

需求分析的任务（填空）

1.确定对系统的综合要求（8个）

1. 功能需求

2. 性能需求

3. 可靠性和可用性需求

4. 出错处理需求

5. 接口需求

6. 约束

7. 逆向需求

8. 将来可能提出的需求

2.分析系统的数据要求

3.导出系统的逻辑模型

4.修正系统的开发计划

IPO图

IPO图是输入、处理、输出图的简称

总体设计

设计原理（填空）

1. 模块化

2. 抽象

3. 逐步求精

4. 信息隐藏与局部化

5. 独立

独立

耦合

耦合是一个软件结构中不同模块之间互连程度的度量

数据耦合

当两个模块之间通过参数交换信息，交换的信息仅仅是数据则为数据耦合。

控制耦合

当两个模块通过控制信息传递，则为控制耦合。

特征耦合

当整个数据元素通过参数传递而被调用的模块只需要使用其中一部分数据，则为特征耦合。

公共环境耦合

当两个模块通过一个公共数据环境相互作用，之间的耦合为公共环境耦合。

内容耦合

内容耦合是最高的耦合，坚决避免

结构

内聚

内聚标志着一个模块内各个元素的紧密程度。

偶然内聚

一个模块完成的任务关系很松散-偶然内聚

逻辑内聚

一个模块完成的任务在逻辑上是相同或相似的-逻辑内聚

时间内聚

一个模块包含的任务必须在时间段内执行-时间内聚

过程内聚

一个模块处理元素必须以特定顺序执行-过程内聚

通信内聚

模块内的所有元素都使用同一个输入数据和同一个输出数据-通信内聚

例：

顺序内聚

模块内必须顺序执行-顺序内聚

功能内聚

模块内的处理元素是一个整体，完成单一的功能-功能内聚

结构

HIPO图

层次图用来描绘软件的层次结构。数据结构的层次方框图相同，但是表现的内容却完全不同。层次图很适于在自顶向下设计软件的过程中使用。

HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”的英文缩写。为了能使HIPO图具有可追踪性，在H图(层次图)里除了最顶层的方框之外，每个方框都加了编号

面向数据流的设计方法（大分必考）

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。信息流有下述两种类型。

1）变换流 信息沿输入通路进入系统，由外部形式变换成内部形式，进入系统的信息通过变换中心，经加工处理以后再沿输出通路变换成外部形式离开软件系统。当数据流图具有这些特征时，这种信息流就叫作变换流。

2）事务流 数据沿输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。这类数据流应该划为一类特殊的数据流，称为事务流。图中的处理T称为事务中心， 它完成下述任务。

1）接收输入数据(输入数据又称为事务)。 2）分析每个事务以确定它的类型。 3）根据事务类型选取一条活动通路

3）设计过程

顶层数据流图

数据流图分解最多分解三次

第一次就一个圈

导出程序结构图或者IPO图

设计步骤（直接背步骤）

1.复查基本设计模型

2.复查并精细数据流图

3.确定数据流图是事务特性还是变换特性

4.确定输入和输出流的边界，从而孤立变换中心

5.第一级分解

6.第二级分解

7.进一步精化

例如

假设的仪表板将完成下述功能。

(1) 通过模数转换实现传感器和微处理机接口。

(2) 在发光二极管面板上显示数据。

(3) 指示每小时英里数(mph)，行驶的里程每加仑油行驶的英里数(mpg)等。

(4) 指示加速或减速。

(5) 超速警告：如果车速超过55英里/小时，则发出超速警告铃声

复查基本系统模型。 复查并精化数据流图。 假设在需求分析阶段产生的数字仪表板系统的数据流图如图所示

判断流程图是有变换特性还是事务特性

变换特性

确定边界

完成第一层分解

完成第二部分解

第二级分解就是把数据流图中的每个处理映射成软件结构中一个适当的模块。

完成第二级分解的方法是，从变换中心的边界开始逆着输入通路向外移动，把输入通路中每个处理映射成软件结构中Ca控制下的一个低层模块；然后沿输出通路向外移动，把输出通路中每个处理映射成直接或间接受模块Ce控制的一个低层模块；最后把变换中心内的每个处理映射成受Ct控制的一个模块

进一步精化

详细设计

工具（填空）

程序流程图

盒图

PAD图（problem analysis diagram）

判断表

判定树

过程设计语言

程序复杂度度量（必考）

McCabe

计算环形复杂度

1. 线性无关的区域数等于环形复杂度

2. V=E-N+2 E为edge 边，N为结点数

3. V=P+1 P为判断节点分支的数目（最简单）

实现

单元测试

在这个测试步骤中所发现的往往是编码和详细设计的错误

• 模块接口

• 局部数据结构

• 重要的执行通路

• 出错处理通路

• 边界条件

集成测试

• 自顶向下的集成

• 自底向上的集成

确定测试

确认测试也称为验收测试，它的目标是验证软件的有效性

白盒测试（必考）

白盒测试（又称结构测试）是把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。

逻辑覆盖

语句覆盖

每个语句执行一次

判定覆盖（分支覆盖）

每个判定的各种可能的结果至少执行一次，也就是每个判定的每个分支都至少执行一次

条件覆盖

所有条件要取到各种可能的结果，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果

判定条件覆盖

判定/条件覆盖是一种能同时满足判定覆盖和条件覆盖的逻辑覆盖，它的含义是，选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。

条件组合覆盖技术

条件组合覆盖是更强的逻辑覆盖标准，它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次

点覆盖

图论中点覆盖的定义如下：如果连通图G的子图G′是连通的，而且包含G的所有结点，则称G′是G的点覆盖

边覆盖

图论中边覆盖的定义是：如果连通图G的子图G″是连通的，而且包含G的所有边，则称G″是G的边覆盖。为了满足边覆盖的测试标准，要求选取足够多测试数据，使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。

路径覆盖

路径覆盖就是设计足够的测试用例，使程序的每条可能路径都至少执行一次。（如果程序种有环，则要求每个环至少执行一次）

总结

控制结构测试

基本路径测试是Tom McCabe提出的一种白盒测试技术。使用基本路径测试设计测试用例时，首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合，从该基本集合导出的测试用例可以保证程序中的每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值

基本路径测试(背)

1. 画出相应的流图

2. 计算环形复杂度

3. 确定线性独立路径的基本集合

4. 设计可强制执行每条集合的基本路径的测试用例

例

条件测试

循环测试

黑盒测试（必考）

黑盒测试（又称功能测试）把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息（例如数据库或文件）的完整性。

等价划分

等价划分把程序的输入域划分成若干个数据类，据此导出测试用例。等价划分法力图设计出能发现若干类程序错误的测试用例，从而减少必须设计的测试用例的数目。

如果把所有可能的输入数据(有效的和无效的)划分成若干个等价类，则可以合理地做出下述假定：每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。因此，可以从每个等价类中只取一组数据作为测试数据。这样选取的测试数据最有代表性，最可能发现程序中的错误。

使用等价划分法设计测试方案首先需要划分输入数据的等价类，为此需要研究程序的功能说明，从而确定输入数据的有效等价类和无效等价类

例如

假设有一个把数字串转变成整数的函数。运行程序的计算机字长16位，用二进制补码表示整数。这个函数是用Pascal语言编写的，它的说明如下：

function strtoint (dstr:shortstr):integer;

函数的参数类型是shortstr,它的说明是:

type shortstr=array［1..6］ of char;

被处理的数字串是右对齐的，也就是说，如果数字串比6个字符短，则在它的左边补空格。如果数字串是负的，则负号和最高位数字紧相邻(负号在最高位数字左边一位)。

考虑到Pascal编译程序固有的检错功能，测试时不需要使用长度不等于6的数组做实在参数，更不需要使用任何非字符数组类型的实在参数。

有效输入的等价类有

(1) 1～6个数字字符组成的数字串(最高位数字不是零)。

(2) 最高位数字是零的数字串。

(3) 最高位数字左邻是负号的数字串。

无效输入的等价类有

(1) 空字符串(全是空格)。

(2) 左部填充的字符既不是零也不是空格。

(3) 最高位数字右面由数字和空格混合组成。

(4) 最高位数字右面由数字和其他字符混合组成。

(5) 负号与最高位数字之间有空格。

合法输出的等价类有

(1) 在计算机能表示的最小负整数和零之间的负整数。

(2) 零。

(3) 在零和计算机能表示的最大正整数之间的正整数。

非法输出的等价类有

(1) 比计算机能表示的最小负整数还小的负整数。

(2) 比计算机能表示的最大正整数还大的正整数。

因为所用的计算机字长16位，用二进制补码表示整数，所以能表示的最小负整数是-32 768，能表示的最大正整数是32 767。

边界值分析

使用边界值分析方法设计测试方案首先应该确定边界情况，通常输入等价类和输出等价类的边界，就是应该着重测试的程序边界

软件可靠性

基本概念（填空）

可靠性：软件在给定的时间间隔内，按照规格说明书的规定成功地运行的概率

可用性：软件在给定的时间点上，按照规格说明书的规定成功运行的概率

维护

定义（填空）

所谓软件维护，就是在软件交付使用后，为了修改错误和满足新的需要而修改软件的过程。

改正性维护：诊断并修改错误的过程

适应性维护：与变换了的环境相配合而修改软件的活动

完善性维护：改进原有的软件

预防性维护：改进未来的可靠性和可维护性的活动

软件维护的特点(填空)

• 结构化维护

• 非结构化维护

决定软件可维护的因素（填空）

• 可理解性

• 可测试性

• 可修改性

• 可移植性

• 可重用性

软件项目管理

估算软件规模(大分)

代码行技术

\bar a为最小规模

\bar m为最可能的规模

\bar b为最大规模

L为估计值

功能点技术

信息域

5个特性

输入项数（inp）：用户向软件输入的项数，这些输入给软件提供面向应用的数据

输出项数（Out）：软件向用户输出的项数，它们向用户提供面向应用的信息

查询项数（Inq）：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应

主文件数（Maf）：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目

外部接口数（Inf）：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统

估算功能点的步骤

1.计算未调整的功能点数(UFP) -Unadjusted feature points

其中：a_i为信息域特性系数，如下表

2.计算技术复杂因子(TCF)-Technical complexity factor

其中，DI为综合影响度，F_i技术因素为下表

技术复杂性因子

3.计算功能点数(FP)-Function Point

例题

步骤

(1)列出子功能

(2)代码行技术估算规模（L_i=\frac{\bar a+4\bar m+\bar b}{6}\ L=\sum_{1}^{i=n}L_i)

(3)FP技术估算软件规模时，对软件的分解是基于信息域特性而不是基于软件功能（不考虑（1）的功能模块划分，考虑系统整体的5个信息域）。为了计算未调整的功能点数，假设每个信息域的复杂度都是平均级别的。

步骤：

①估算未调整的功能点数UFP

②计算技术复杂性因子TCF

③计算功能点数FP

(4)计算

软件质量保证措施（SAQ-software quality assurance）（填空）

• 技术复审的必要性

• 走查

• 审查

• 程序正确性证明

软件配置管理用来（填空）

• 标识变化

• 控制变化

• 确保适合地实现变化

• 向需要知道这类信息的人报告变化

软件成熟度模型（填空）

• 初始级

• 可重复级

• 已定义级

• 已管理型级

• 优化级

补充填空题

估算软件规模的功能点技术依据软件信息域特性和软件复杂性的评估结果，估算软件规模，信息域特性包括： 、 、 、 、 。 工作量估算的常用方法有： 、 、 。 项目管理者的目标是： 。 软件组织常见的人员组织模式有如下3种形式： 、 、 。 影响软件质量的因素可以划分为3组： 、 、

软件质量保证的措施主要有： 、 、 。 走查有2种方式： 、 。 审查过程包含下述5个步骤： 、 、 、 、 。 软件配置管理的活动包括： 、 、 、 。 CMM的5个等级按从低到高的顺序是： 、 、 、 、 。

本栏目推荐文章
• 2024/1/13 算法笔记
• Python学习笔记
• 从C++CLI工程的依赖库引用问题看.Net加载程序集机制
• HDP 笔记
• 学习进度笔记2
• 微软企业库Unity学习笔记(一)
• 微软企业库Unity学习笔记(二)
• kepware关于U-CON的使用笔记 (串口_非主动问答式)
• Anaconda使用笔记
• 多项式定积分计算软件2025 64位WIN版下载Polynomial definite integral calculation software 2025 64 bit WIN version download

软件工程 导论 笔记 工程 软件软件工程 导论 笔记 工程 读后 软件工程 读后感 导论 软件工程 导论 项目 工程 软件工程 导论 工程 软件 读后 软件工程 导论 工程 软件工程 导论 伙伴 项目 软件工程 导论 代码 项目 软件工程 笔记 工程 软件 软件工程 笔记 方法 工程 实践者 软件工程 笔记 方法