软件工程导论第6版期末复习——JXUST

• 第一章 软件工程学概述

软件危机的概念

通常把在计算机软件的开发与维护过程中所遇到的一系列严重问题笼统地称为软件危机。

概括地说，软件危机包含以下两个方面的问题。

1. 如何开发软件以满足社会对软件日益增长的需求；
2. 如何更有效地维护数量不断膨胀的已有软件。

软件危机的典型表现

1. 对软件开发成本和进度的估计常常很不准确；
2. 用户对“已完成的”软件系统不满意的现象经常发生；
3. 软件产品的质量往往靠不住；
4. 软件常常是不可维护的；
5. 软件通常没有适当的文档资料；
6. 软件成本在计算机系统总成本中所占的比例逐年上升；
7. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

软件工程的定义

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术，和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

软件工程的本质特征

1. 软件工程关注于大型程序的构造；
2. 软件工程的中心课题是控制复杂性；
3. 软件经常变化；
4. 开发软件的效率非常重要；
5. 和谐地合作是开发软件的关键；
6. 软件必须有效地支持它的用户；
7. 软件工程领域由具有一种文化背景的人替具有另一种文化背景的人创造产品。

软件工程的基本原理

1. 用分阶段的生命周期计划严格管理；
2. 坚持进行阶段评审；
3. 实行严格的产品控制；
4. 采用现代程序设计技术；
5. 结果应能清楚地审查；
6. 开发小组的人员应该少而精；
7. 承认不断改进软件工程实践的必要性。

软件工程方法学

定义：把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（范型）。

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

主要分为：传统方法学、面向对象方法学

生命周期

生命周期概念：指某一软件项目被提出来并着手实现开始，直到该软件报废或停止使用为止的周期。

软件定义时期：

（1）问题定义

问题定义阶段必须回答的关键问题是：“要解决的问题是什么?”。

（2）可行性研究

可行性研究阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗?”

（3）需求分析

需求分析阶段的任务是准确地确定“为了解决这个问题，目标系统必须做什么”,主要是确定目标系统必须具备哪些功能。

软件开发时期：

（1）总体设计

总体设计阶段必须回答的关键问题是：“应该怎样实现目标系统?”主要是设计出实现目标系统的几种可能的方案。

（2）详细设计

详细设计阶段的任务就是把设计方案具体化，也就是回答：“应该怎样具体地实现这个系统呢?”这个阶段的任务是设计出程序的详细规格说明。

（3）编码和单元测试

编码和单元测试阶段的关键任务是写出正确的、容易理解的、容易维护的程序模块。

（4）综合测试

综合测试阶段的关键任务是通过各种类型的测试使软件达到预定的要求，最基本的测试是集成测试和验收测试。

运行维护时期：

（1）软件维护

维护阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。

通常有四类维护活动：

①改正性维护：即诊断和改正在使用过程中发现的软件错误；

②适应性维护：即修改软件以适应环境的变化；

③完善性维护：即根据用户的要求改进或扩充软件使它更完善；

④预防性维护：即修改软件，为将来的维护活动预先做准备。

软件过程及模型特点｜优缺点（问答）

瀑布模型：

定义：将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。

特点：

(1) 阶段间具有顺序性和依赖性；

1. 推迟实现的观点；
2. 质量保证的观点。

优点：

(1) 可强迫开发人员采用规范的方法；

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

(3) 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

缺点：

1. 缺乏灵活性，难以适应需求不明确或需求经常变化的软件；
2. 线性开发，开发末期见到成果，风险大（开发早期存在问题往往要到交付使用时才发现，维护代价大）。

快速原型模型：

定义：快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

优点：

1. 可以得到比较良好的需求定义，容易适应需求的变化；
2. 有利于开发与培训的同步；
3. 费用低、开发周期短且对用户更友好。

缺点：

1. 缺乏过程可见性；
2. 系统结构通常会很差。

增量模型：

定义：又称渐增模型，开发软件时将软件产品作为一系列增量构件设计、编码、集成和测试。

特点：增量模型分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。

优点：

(1) 能在较短时间内向用户提交可完成一些有用的工作的产品；

1. 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

缺点：

增量模型本身是自相矛盾的。它一方面要求开发人员把软件看做一个整体，另一方面又要求开发人员把软件看做构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。

螺旋模型：增加了风险评估阶段的快速原型模型。

特点：使用原型及其他方法来尽量降低风险。

优点：

(1) 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；

(2) 减少了过多的测试（浪费资金）或测试不足（产品故障多）所带来的风险；

(3) 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别；

(4) 它是风险驱动的。

缺点：

因为它是风险驱动的，除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险。

喷泉模型：

定义：喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。

特点：迭代是软件开发过程中普遍存在的一种内在属性。经验表明，软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代，在面向对象范型中比在结构化范型中更常见。＂喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。

• 第二章 可行性研究

可行性研究

可行性研究目的：

用最小的代价在尽可能短的时间内确定问题能否解决。

可行性研究任务/内容：

对以后的行动提出建议、必须分析集中主要的方案利弊、对每种方案分析可行性。

1.技术可行性：使用现有的技术能实现这个系统吗?

2.经济可行性：这个系统的经济效益能超过它的开发成本吗?

3.操作可行性：系统的操作方式在这个用户组织内行得通吗?

4.法律可行性

数据流图

数据流图(DFD)描绘信息流和数据从输入移动到输出的过程中所经受的变换。

数据字典

数据字典是关于数据的信息的集合，是对数据流图中包含的所有元素的定义的集合。

成本/效益分析的方法（理解|选择）

成本/效益分析的第一步是估计开发成本，运行费用和新系统将带来的经济效益。

1.货币的时间价值；

2.投资回收期；

3.纯收入；

4.投资回收率。

• 第三章 需求分析

与用户沟通获取需求的方法（理解|选择|问答）

1.客户访谈：分为正式的和非正式的两种基本形式，还有调查表；

2.面向数据流自顶向下求精：实质是结构化分析方法；

3.简易的应用规格说明技术：提倡用户和开发者密切合作，共同标识问题提出解决方案要素。

4.快速建立软件原型。

结构化分析建立的几种模型|每个模型对应的图形工具

在需求分析阶段建立数据模型，功能模型和行为模型

1. 实体联系图——数据（ER）模型

2. 数据流图——功能模型

3. 状态图——行为模型

• 第五章 总体设计

设计原理（选择）

1.模块化

2.抽象

3.逐步求精

4.信息隐藏和局部化

5.模块独立

耦合（重点）

耦合：衡量不同模块相互依赖的紧密程度

两个模块彼此完全独立，无任何连接，无直接耦合（最低耦合）。

两个模块间通过参数交换信息，交换的信息仅仅是数据，数据耦合（低耦合）。

若传递信息中有控制信息，控制耦合（中等耦合）。

把整个数据结构作参数传递，被调用模块只需要使用一部分元素就出现了特征耦合。

当两个或多个模块通过一个公共数据环境相互作用的时候，公共环境耦合

内容耦合（最不希望出现）：一个模块访问另一个模块内部数据；一个模块不通过正常入口而转到另一个模块内部；两个模块有一部分程序代码重叠；一个模块有多个入口。

程度：（由低到高）无直接耦合-数据耦合-控制耦合-特征耦合-公共环境耦合—内容耦合

原则：尽量使用数据耦合，少用控制耦合，限制公共环境耦合，完全不用内容耦合。

内聚（重点）

内聚：衡量模块内各元素结合的紧密程度

低内聚：

模块间完成一组任务，这些任务彼此有关系但关系松散，偶然内聚。

一个模块完成的任务在逻辑上属于相同或相似的一类，逻辑内聚。

一个模块包含的任务必须在同一时间段执行（如模块初始化），时间内聚。

中内聚：

模块中处理元素相关并依特定次序执行，过程内聚。

模块中所有元素都用同一个输入数据并产生同一个输出数据，通信内聚。

高内聚：

模块中处理元素和统一功能密切相关，而且这些处理必须依次执行，顺序内聚。

模块中所有元素属于一个整体并且处理同一个功能，功能内聚。

程度:(由低到高）偶然内聚-逻辑内聚-时间内聚-过程内聚-通信内聚-顺序内聚-功能内聚

改进原则：高内聚、低耦合。（功能内聚，数据耦合）

启发规则（理解）

1.改进软件结构提高模块独立性；

2.模块规模应该适中；

3.深度、宽度、扇出和扇入都应适当；（重点）

深度：软件结构控制层数，标识系统的大小和复杂程度。

宽度：软件结构同一层次模块数最大值，越大系统越复杂。

扇出：一模块直接控制（调用）模块数，过大，模块复杂，过小也不好。平均扇出为3或4,上限5-9

扇入：有多少上级模块直接调用它，越大共享该模块上级模块越多。

4.模块的作用域应该在控制域之内；（重点）

作用域：指受该模块内一个判定影响的所有模块的集合。

控制域：是这个模块本身以及所有直接或间接从属于它的模块的集合。

5.力争降低模块接口的复杂程度；

6.设计单入口单出口的模块；

7.模块功能应该可以预测。

• 第六章 详细设计

过程设计的工具：

描述程序处理过程的工具称为过程设计的工具，可分为图形、表格和语言 3 类程序流程图、盒图、PAD 图（选择）

程序流程图

优点：

对控制流程描绘直观，便于初学者掌握。

缺点：

1. 不是逐步求精的好工具，过早考虑控制流程，非整体结构；
2. 用箭头代表控制流，程序员随意转移控制；
3. 不易表示数据结构和调用关系。

盒图|判定表|判定树|伪码（理解|不要求绘制）

McCabe方法

McCabe方法：McCabe根据程序控制流的复杂程度度量 程序的复杂程度，这样度量出的结果称为程序的环形复杂度。

①流图的表示

1. 结点：用圆表示，一个圆代表一条或多条语句；
2. 边：箭头线称为边，代表控制流；
3. 区域：由边和结点围成的面积称为区域，计算区域数时应包括图外未被围起的区域；
4. 判定结点：包含条件的结点。

②计算环形复杂度的方法

1. 流图中线性无关的区域数等于环形复杂度；
2. 流图G的环形复杂度V(G)=E-N+2,其中E是流图中边的条数，N是结点数；
3. 流图G的环形复杂度V(G)=P+1,其中P是流图中判定结点的数目。

• 第七章 实现

测试步骤（问答）

1. 模块测试：这个测试步骤中所发现的往往是编码和详细设计的错误。
2. 子系统测试：这个步骤着重测试模块的接口。
3. 系统测试：这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。

注意：不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。

1. 验收测试：这个测试步骤中发现的往往是系统需求说明书中的错误。
2. 平行运行：同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。

白盒测试（选择|大题）

逻辑覆盖：是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。

1.语句覆盖

选择测试数据，使被测程序中每个语句至少执行一次。

2.判定覆盖

每个语句至少执行一次，每个判定的真假分支至少执行一次。

3.条件覆盖

每个语句至少执行一次，判定表达式每个条件取各种可能结果。

4.判定/条件覆盖

取足够多测试数据，使判定表达式每个条件都取各种可能值，且每个判定表达式也取得各种可能结果。

5.条件组合覆盖

选足够多的数据，是每个判定表达式中条件的各种组合都至少执行一次

控制结构测试（大题）

黑盒测试

黑盒着重：软件功能

黑盒发现的错误类型：

1.功能不正确或遗漏；

2.界面错误；

3.数据结构或外部数据库访问错误；

4.性能错误；

5.初始化或终止错误。

等价划分（重点）：

把程序的输入域划分成若干数据类，从每一数据类选取少数有代表性数据做为测试用例。在各数据类中，各输入数据对揭露程序中的错误等效。

1.划分等价类

1. 有效等价类：合理，有意义输入数据构成集合。
2. 无效等价类：不合理，无意义输入数据构成的集合。
3. 等价类划分原则：

1.输入条件规定范围，定义一有效等价类和两无效等价类。

2.输入条件是布尔量，一个有效等价类和一个无效等价类。

3.规定输入数据一组值，程序对每个输入值分别进行处理。每个输入值确立一有效等价类，针对这组值确立一无效等价类。

4.规定输入数据必须遵守规则，定义一有效等价类（符合规则）和若干无效等价类（从不同角度违反规则）。

5.已划分等价类中各元素在程序中处理方式不同，将等价类进一步划分更小等价类。

2.确定测试用例

建立等价类表，列出所有划分出等价类

1. 为每一等价类规定一唯一编号；
2. 设计一新测试用例，尽可能多覆盖尚未被覆盖有效等价类，重复，直到所有有效等价类被覆盖；
3. 设计一新测试用例，仅覆盖一尚未被覆盖无效等价类，重复，直到所有无效等价类被覆盖。

• 第八章 维护

软件维护

定义：在软件已经交付使用之后，为改正错误或满足新的需要而修改软件的过程。

分类：

①改正性维护：即诊断和改正在使用过程中发现的软件错误；

②适应性维护：即修改软件以适应环境的变化；

③完善性维护：即根据用户的要求改进或扩充软件使它更完善；

④预防性维护：即修改软件，为将来的维护活动预先做准备

软件维护的特点

1. 结构化和非结构化维护差别巨大；

非结构化维护由于没有文档，需要付出巨大代价

结构化维护有完整的文档能减少精力浪费，提高维护质量。

1. 维护的代价高昂；
2. 维护的问题很多。

理解别人写的程序困难、文档不足、没有考虑修改、无人想做。

• 第九章 面向对象方法学引论

面向对象方法学的要点

①基本原则/概念：尽可能模拟人类习惯的思维方式，开发软件的方法和过程尽可能接近人类认识的世界解决问题的方法和过程。

②四个要点（选择）

（1）软件是由对象组成的，任何元素都是对象，复杂软件对象由比较简单的软件对象组成；

（2）所有对象都划分成对象类，类都定义了一组数据和一组方法；

（3）按子类与父类的关系，把若干对象类组成一个层次结构的系统；

（4）对象彼此之间仅能通过传递消息互相联系。

• 第十章 面向对象分析

建立对象模型——表达系统中的类和类之间的关系

建立动态模型——表达对象之间的动态交互关系

建立功能模型——表达对象的状态转换关系

• 第十三章 软件项目管理

估算软件规模的两种技术：代码行技术和功能点技术

代码行技术

定义：代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。

功能点技术

定义：依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。