【软考中级-软件设计师笔记】软件工程（上）

---

---

CMM

1）初始级（最低成熟度）

软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。

2）可重复级

建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。

3）已定义级

管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。

4）已管理级

制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。

5）优化级（最高成熟度）

加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

CMMI (Integration)

分为阶段式模型（跟上面的CMM差不多）和连续式模型

• CL0（未完成的）：过程域未执行或未得到 CL1中定义的所有目标。
• CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
• CL2（己管理的）：其共性目标集中于己管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循己文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。
• CL3（己定义级的)：其共性目标集中于己定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。
• CL4 (定量管理的)：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。
• CL5（优化的)：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。

记忆：

未完成——实现特定目标（CL1）——已管理的制度化（CL2）——已定义的制度化（CL3，定义和管理的顺序和CMM相反）——更高级的管理：定量管理过程的制度化（CL4）——量化手段和优化过程（进一步优化，CL5）

3. 瀑布模型

五个阶段：需求分析、设计、编码、测试和维护

优点：

1. 好理解
2. 强调早期的计划和需求

缺点：
3. 需要客户良好的表达需要
4. 在开始的三个阶段中，很难评估真正的状态
5. 结尾有大量集成和测试工作
6. 一旦发生错误，得从头开始
7. 抗风险能力弱，成本高

例题：

解析：有基础，可以考虑瀑布模型，选A。原型模型是在需求不明确时，先开发一个原型

4. 增量模型

划分成多个增量，每个增量能独立实现某功能，逐步实现。增量模型的第一个产品往往是核心产品，

优点：

1. 具有瀑布模型的所有优点
2. 很快能发布第一个版本，所以时间、成本少，减少用户需求的变更
3. 重要的功能先交付，所以可以经过更多的测试
4. 风险比较小

缺点：
5. 如果没有对客户的变更进行规划，初始增量可能会造成后来增量的不稳定
6. 一些增量就可能需要重新开发、重新发布
7. 管理成本比较高

适合于：
8. 需求不太清晰
9. 快速构造
10. 有原型系统和经验

例题：

解析：D，要划分成多个增量，管理成本高

5. 演化模型

分为原型模型和螺旋模型

适合对需求不明的情况

原型模型

首先开发原型系统，然后根据用户意见修改，多次迭代。但不太适合系统规模很大的时候

螺旋模型

对大型软件，将瀑布模型和原型模型加起来，考虑风险分析步骤。

将开发过程分为几个螺旋周期，每个周期大致和瀑布模型符合

适合于：
庞大、复杂并且具有高风险的系统。

优点：

1. 强调风险分析
2. 支持需求的动态变化

缺点：
3. 需要开发人员很有经验
4. 开发成本高，交付时间长

例题：

解析：DC，第一问D是增量模型

6. 喷泉模型

喷泉模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性

• 以用户需求为动力
• 以对象作为驱动
• 适合于面向对象

需要多次迭代，且无间隙（不需要需求分析之后才开始开发，而是多个阶段可以交叉进行）

优点：

1. 提高效率，减少时间
2. 支持软件重用

缺点：
3. 开发阶段重叠，需要大量开发人员
4. 文档管理严格

7. 统一过程UP模型

用UML作为工具，分成许多小的袖珍项目，每个袖珍项目具有完成的流程。

分成初始（关注项目的初创活动）、精化（关注需求分析和架构演进）、构建（关注系统的构建）、移交阶段（关注软件提交方面的工作）

RUP是UP的一个商业化产品

8. 敏捷方法

极限编程XP

4大价值观：沟通、简单性、反馈、勇气
5个原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作
12个最佳实践：

• 计划游戏：快速制定计划、随着细节的不断变化而完善
• 小型发布：系统的设计要能够尽可能早地交付
• 隐喻：找到合适的比喻传达信息
• 简单设计：只处理当前的需求，使设计保持简单
• 测试先行：先写测试代码，然后再编写程序
• 重构：重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求
• 结对编程：非正式的代码审查，以获得质量更高的代码
• 集体代码所有制：任何开发人员都可以对系统的任何部分进行改进
• 持续集成：可以按日甚至按小时为客户提供可运行的版本
• 每周工作40个小时
• 现场客户：系统最终用户代表应该全程配合XP团队
• 编码标准

水晶法 Crystal

认为每一个不同的项目都需要一套不同的策略、约定和方法论。

并列争求法 Scrum

把每30天一次的迭代称为一个**“冲刺”**。

自适应软件开发（ASD）

6个基本原则：

• 有一个使命作为指导；
• 特征被视为客户价值的关键点；
• 过程中的等待是很重要的，因此“重做”与“做”同样关键；
• 变化不被视为改正，而是被视为对软件开发实际情况的调整；
• 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；
• 风险也包含其中。

敏捷统一过程 AUP

原理：在大型上连续，在小型上迭代

6个活动：

• 建模：建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进。
• 实现：将模型翻译成源代码。
• 测试：像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
• 部署：对软件增量的交付以及获取最终用户的反馈。
• 配置及项目管理：着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
• 环境管理：协调标准、工具以及适用于开发团队的支持技术等过程基础设施。

例题：

解析：B，测试先行

9. 系统设计

概要设计

1. 设计软件系统总体结构

   • 确定每个模块的功能
   • 确定模块之间的调用关系
   • 确定模块之间的接口

2. 数据结构及数据库设计

3. 编写概要设计文档

4. 评审

详细设计

1. 对每个模块进行详细的算法设计
2. 对模块内的数据结构进行设计
3. 对数据库进行物理设计
4. 其他设计
   1. 代码设计
   2. 输入输出格式设计
   3. 用户界面设计
5. 编写详细设计说明书
6. 评审

10. 系统测试

原则：

1. 应尽早并不断地进行测试。
2. 测试工作应该避免由原开发软件的人或小组承担。
3. 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。
4. 在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。
5. 在测试程序时，不仅要检验程序是否做了该做的事，还要校验程序是否做了不该做的事。
6. 严格按照测试计划来进行，避免测试的随意性。
7. 妥善保存测试计划、测试用例。
8. 测试用例都是精心设计出来的。
9. 系统测试阶段的测试目标来自于需求分析阶段。

例题：

解析：测试是用来发现错误，不是用来证明没有错误，C错。AB显然错。D对，语句覆盖最弱，路径覆盖最强。

单元测试

测试内容：

• 模块接口
  – 具体来说：

- 测试模块的输入参数和形式参数在个数、属性、单位上是否一致。
- 调用其他模块时，所给出的实际参数和被调用模块的形式参数在个数、属性、单位上是否一致。
- 调用标准函数时，所用的参数在属性、数目和顺序上是否正确。
- 全局变量在各模块中的定义和用法是否一致。
- 输入是否仅改变了形式参数。
- 开/关的语句是否正确。
- 规定的I/O格式是否与输入/输出语句一致。
- 在使用文件之前是否已经打开文件或使用文件之后是否己经关闭文件。

• 局部数据结构
• 重要的执行路径
• 出错处理
• 边界条件

测试过程：

• 驱动模块：模拟被测试模块的上一级模块，相当于被测模块的主程序。
• 桩模块：代替测试模块中所调用的子模块，其内部可进行少量的数据处理。目的是为了检验入口、输出调用和返回的信息。

集成测试

1. 自顶向下测试

从上层模块，以DFS或者BFS集成各个模块并迭代测试，自顶向下集成不需要驱动模块，需要桩模块。

2. 自底向上测试

从原子模块开始构造测试，需要驱动模块，不需要桩模块。

3. 回归测试

变更后，有些修改可能使得原本正常的也出问题，所以回归测试就是重新测试避免错误

4. 冒烟测试

时间关键项目的决定性机制，它让软件团队频繁地对项目进行评估。

11. 测试方法

分类：

1. 静态测试：人工测试，代码检查、静态结构分析等
2. 动态测试：黑盒测试，白盒测试

黑盒测试

在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性

方法：

• 等价类划分：将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。当测试用例全是无效等价类时则不是一个好的测试用例。分类为：
  • 有效等价类
  • 无效等价类
  • 理解：就是把输入分成若干种，输入每种有代表性的
• 边界值分析：输入的边界比中间更加容易发生错误，因此用边界值分析来补充等价类划分的测试用例设计技术。
• 错误推测
• 因果图

例题：

解析：当测试用例都是无效时不是一个好的用例，所以选C

解析：C，C选项不合理的最多

McCabe度量法

度量程序的复杂性，通过环路个数进行度量。有向图G环路复杂性公式为：

V(G) = m - n + 2, 
V(G): 环路个数
m: 有向边数
n: 节点数

例题：

解析：m = 10, n = 7, V(G) = m - n + 2 = 5, D

白盒测试

根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试

• 逻辑覆盖：逻辑覆盖标准有6种，它们的覆盖程度从低到高为：

  1. 语句覆盖：指选择足够的测试数据，使被测试程序中的每条语句至少执行一次。语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。

  理解：就是设计一堆用例，让每个语句都能执行到，这里面只是细化的看语句，而不涉及逻辑，所以说很弱的逻辑覆盖
  

  2. 判定覆盖（分支覆盖）：指设计足够的测试用例，使得被测程序中的每个判定表达式至少获得一次“真”/“假”值。判定覆盖的判定表达式是指判定表达式整体。判定覆盖要比语句覆盖更强一些。

  3. 条件覆盖：指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。

  比如，if (a == 2 || b == 3)这种，a和b至少覆盖一次
  

  条件覆盖的判定语句是指判定表达式下的判定语句（如果有），即用AND、OR等逻辑运算符连接起来的语句（不包含逻辑运算符的语句）。

  4. 判定/条件覆盖：就是同时满足判定+条件覆盖

  5. 条件组合覆盖：指设计足够的测试用例，使得每个判定中条件的各种可能值的组合都至少出现一次。

     满足条件组合覆盖的测试用例一定满足：

     • 判定覆盖
     • 条件覆盖
     • 判定/条件覆盖

  比如说，if (a > 0 && b > 0), 测试这个语句，那么就需要把(a > 0, b > 0), (a > 0, b <= 0), (a <= 0, b <= 0), (a <= 0, b > 0)各种情况都覆盖
  

  6. 路径覆盖：指覆盖被测试程序中所有可能的路径。

比如这个图，一共就有四种路径。

• 循环覆盖

• 基本路径测试

例题：

解析：看流程图，是冒泡排序，其实只需要1个用例即可，就是想一个不规则排序的数组。

解析：B，有两个return语句，肯定是需要2个。至于查找的过程，有循环，是很容易都覆盖的。

解析：AC。路径见图中的不同颜色。注意有循环的时候，可以用=有一条跑很长的路径。

解析：各个用例路径如上。1 2实现了语句覆盖，要实现路径覆盖，显然选择1 2 3. AC。

6.

解析：

特别注意语句覆盖和路径覆盖的区别。语句覆盖是每个语句经过一下就可以，路径覆盖是从出发到终点，所有的不同路径的种类。对这个题，语句覆盖是两条，如下图：

因为我们不能保证在一次循环当中，判断2的两个分支都能经历，所以需要两条。

路径覆盖如下图：

环路复杂度：边数11，节点数11，答案为2.

最终的答案：2，4，2

解析：

首先注意，在只有逻辑运算没有and or的时候，判定覆盖和条件覆盖是一样的。 判定覆盖是每个逻辑运算if (A)的A是true，false要各一次，条件覆盖是if (A || B)中A，B的可能各取一次。

首先根据伪代码画图：

每个逻辑判断要取到T和F，可以列举如下可能：（注意不是222=8）

i > j > k (三个逻辑判断是TFT)
i > j < k (TFF)
i < j > k (FTT)
i < j < k (FFF)

所以需要4个用例，边数11，节点数9，复杂度为4

解析：

首先画出流程图：

语句覆盖，比较容易满足，1个用例即可。边数8，节点7，环路复杂度3

12. 运维

可维护性的评价指标：

可理解性、可测试性、可修改性

• 可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可以用 MTTF/(1+MTTF) 来度量，其中 MTTF 为平均无故障时间。
• 可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。可以用 MTBF/(1+MTBF) 来度量，其中 MTBF 为平均失效间隔时间。
• 可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。可以用 1/(1+MTTR) 来度量，其中 MTTR 为平均修复时间。

记忆：
可靠，就是要没有故障，所以是看平均无故障时间,
可用，就是按照要求可以用，所以是平均失效时间，记住是硬盘的TB，MTBF
可维护性：就是看修复，平均修复时间，MTTR，R说的是Recovery, 只有它的分子是1

软件文档：凡是选项中说软件文档不好的都是错的

系统维护的内容及类型

分类：硬件维护、软件维护、数据维护。重点考软件维护

软件维护：

• 正确性维护 17%~21%。指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
• 适应性维护 18%~25%。使应用软件适应信息技术变化和管理需求变化而进行的修改。(偏被动）
• 完善性维护 50%~60%。为扩充功能和改善性能而进行的修改。（偏主动）
• 预防性维护 4%。为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。

例题：

13. 沟通路径

例题：

解析：
7 + … + 1 = (1 + 7) / 2 * 7 = A, 等差数列求和

解析：

无主程序员的情况，就是全连通图，路径为7 + … + 1 = 28
有主程序员的情况，类似于星型图，仅有主程序员和其他程序员之间有边，所以是7. D

14. 软件项目估算

** COCOMO模型**

1. 基本COCOMO模型：是一个静态单变量模型，用于对整个软件系统进行估算。
2. 中级COCOMO模型：是一个静态多变量模型，它将软件系统模型分为系统和部件两个层次，系统由部件构成，它把软件开发所需的人力（成本）看作是程序大小和一系列“成本驱动属性”的函数。
3. 详细COCOMO模型：将软件系统模型分为系统、子系统和模块3个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。

COCOMO II模型

1. 应用组装模型：在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的。

   规模估算选择：对象点。

2. 早期设计阶段模型：在需求己经稳定并且基本的软件体系结构己经建立时使用。

   规模估算选择：功能点。功能点可转换为代码行。

3. 体系结构阶段模型：在软件的构造过程中使用。

   规模估算选择：代码行。

15. 进度管理

15.1 甘特图

优点：

1. 清晰看出开始、结束时间、进展情况
2. 清晰看出任务之间的并行

缺点：

1. 不能清晰地反映各任务之间的依赖关系；
2. 难以确定整个项目的关键所在，即不能清晰地确定影响进度的关键任务；
3. 不能反映计划中有潜力的部分。

15.2 PERT图

PERT图是一个有向图：

箭头上面的是持续时间，只有当前驱节点都完成时，当前节点才能够启用，也才能够开启后续的节点。节点仅仅表示时间点，它本身并不占用资源，也就是说，**节点是时间点，箭头上面的时间是任务过程，**并且：

• 开始节点（入度为0的节点）的开始时刻必须为0

根据定义，我们可以推出每个节点的最早时刻，那就是它前一个任务的最早时间+箭头上的时间（如果有多条路径，就取max），例如：

同理，最迟时刻是从最后一个节点（出度为0）的必须最迟完成的时刻开始往前推。不再赘述。当然，如果出度有多个任务的，要取min。

PERT图的松弛时间和关键路径：

松弛时间，说白了就是能摸多少鱼。比如说，两个节点如下：

节点1：最早时刻2，最迟时刻2 ---3--->>> 节点2：最早时刻5，最迟时刻5

那么就2 + 3 = 5，所以一点裕度都没有，松弛时间是0.

如果：

节点1：最早时刻6，最迟时刻17 ---2--->>> 节点2：最早时刻8，最迟时刻19

考虑极限情况：1在6开始，在19到达2，是满足要求的最长时间，19-6=13，而任务还要持续2，所以松弛时间就是13-2=11.

关键路径就是松弛时间=0的连起来的路径

优点：

• 给出了每个任务的开始时间、结束时间和完成该任务所需的时间；
• 给出了任务之间的关系（依赖关系）。即任务之间的执行顺序。

缺点：

• PERT图不能清晰地描述任务之间的并行情况。

例题：

解析：做题方法：先转换为PERT图，正着推出最早时刻，再从任务结束时刻倒着推出最迟时刻，然后计算松弛时间。

转换后的PERT图：

橙色是最早时刻，红色是最晚时刻，黑色是持续时间，棕色是松弛时间，可以看出，BEGI是关键路径，A最迟可以第2天开始，选CB。

15.3 项目活动图

跟PERT图有点类似，节点表示里程碑，边表示活动，上面的值表示持续时间：

求解方法看例题

例题：

解析：
求出PERT图：

绿色是最早时刻，蓝色是最迟时刻，红色是松弛时间。关键路径是0 2 5 7 8 9，答案B。注意，在推最早、最迟时刻的时候，为了避免混乱，一定按照广度优先的方式去推，记好最早时刻取max，最迟时刻取min。

解析：
PERT图如下：

立即得出，最短需要22天，BD松弛时间是0. 答案CA