2024年软件设计师中级（软考中级）详细笔记【5】软件工程基础知识下（分值10+）

第5章软件工程目录

前言
第5章软件工程基础知识（下）
- 5.5 系统测试
- - 5.5.1 系统测试与调试
  - 5.5.2 传统软件的测试策略
  - 5.5.5 测试方法
  - - 5.5.5.1 黑盒测试
    - 5.5.5.2 白盒测试
    - 白盒测试+McCabe度量法
    - 伪代码+白盒测试+McCabe
- 5.6 运行和维护知识【以背为主】
- - 5.6.2 系统维护概述
  - - 5.6.2.1 系统可维护性概念
    - 软件文档【秒杀题】
    - 5.6.2.2 系统维护的内容及类型
    - 可靠性、可用性、可维护性
  - 沟通路径
- 5.7 软件项目管理
- - 5.7.2 软件项目估算
  - 5.7.3 进度管理
  - 5.7.5 软件配置管理
  - 5.7.6 风险管理【必考】
- 5.8 软件质量
- - 5.8.1 软件质量特性【重点，背多分】
  - 5.8.3 软件评审
  - 5.8.4 软件容错技术
  - 5.10.1 软件工具
结语

前言

在备考软件设计师中级考试的过程中，我遇到了些许挑战，也收获了宝贵的经验。为了帮助其他同样正在为这门考试（证书）奋斗的朋友们，我决定将我的笔记整理出来，与大家分享。这些笔记不仅包含了书本上的知识，还加入了我对重点和难点的个人理解以及考试技巧，力求帮助大家更加高效地复习。我希望这份笔记能够成为你备考路上的一份支持，也祝愿你在考试中取得理想的成绩👍👍👍

如果有写的不好或者需要改进的地方，恳请在评论区指正！🤓🤓🤓

第5章软件工程基础知识（下）

【概念偏多，逻辑较少，以背为主，分值较多】

5.5 系统测试

5.5.1 系统测试与调试

系统测试的意义、目的及原则
【意义】系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚末发现的错误的测试。
【目的】测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。用户应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试实例，并利用这些实例来运行程序，以便发现错误的过程。
信息系统测试应包括软件测试、硬件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标进行，此处所说的测试更多的是指软件测试。
系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则。
1. 应尽早并不断地进行测试。测试不是在应用系统开发完之后才进行的。由于原始问题的复杂性、开发各阶段的多样性以及参加人员之间的协调等因素，使得在开发的各个阶段都有可能出现错误。因此，测试应贯穿在开发的各个阶段，应尽早纠正错误，消除隐患。
2. 测试工作应该避免由原开发软件的人或小组承担，一方面，开发人员往往不愿否认自己的工作，总认为自己开发的软件没有错误；另一方面，开发人员的错误很难由本人测试出来，很容易根据自己编程的思路来制定测试思路，具有局限性。测试工作应由专门人员来进行，这样会更客观、更有效。
3. 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。将实际输出结果与预期结果相比较就能发现测试对象是否正确。
4. 在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。在测试的时候，人们往往习惯按照合理的、正常的情况进行测试，而忽略了对异常、不合理、意想不到的情况进行测试，而这可能就是隐患。
5. 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。多余的工作会带来副作用，影响程序的效率，有时会带来潜在的危害或错误。
6. 严格按照测试计划来进行，避免测试的随意性。测试计划应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。严格地按照测试计划可以保证进度，使各方面都得以协调进行。
7. 妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。
8. 测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。当纠正错误，系统功能扩充后，都需要重新开始测试，而这些工作的重复性很高，可以利用以前的测试用例，或在其基础上修改，然后进行测试。
9. 系统测试阶段的目标来自于需求分析阶段。

习题：

在软件开发过程中，系统测试阶段的测试目标来自于（32）阶段。（2014、2021年下半年）
A. 需求分析 B. 概要设计 C.详细设计 D. 软件实现

答案：A
以下关于软件测试的叙述中，不正确的是_（35）。（2016年下半年）
A．在设计测试用例时应考虑输入数据和预期输出结果
B. 软件测试的目的是证明软件的正确性
C.在设计测试用例时，应该包括合理的输入条件
D．在设计测试用例时，应该包括不合理的输入条件

答案：B，是为了发现错误，而不是为了证明软件的正确性
以下关于测试的叙述中，正确的是（34）。（2019 年上半年）
A. 实际上，可以采用穷举测试来发现软件中的所有错误
B.错误很多的程序段在修改后错误一般会非常少
C.测试可以用来证明软件没有错误
D．白盒测试技术中，路径覆盖法往往能比语句覆盖法发现更多的错误

答案：D

5.5.2 传统软件的测试策略

单元测试
单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测试法。这类测试可以对多个模块同时进行。
1. 单元测试的测试内容
  单元测试主要检查模块的以下5个特征。【了解】
  (1)模块接口。模块的接口保证了测试模块的数据流可以正确地流入、流出。
  (2)局部数据结构。
  (3)重要的执行路径
  (4)出错处理
  (5)边界套件
2. 单元测试过程
  由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发两种模块。单元测试环境如图 5-9 所示。
  - 驱动模块。相当于一个主程序，接收测试例子的数据，将这些数据送到测试模块，输出测试结果。
  - 桩模块（也称为存根模块)。桩模块用来代替测试模块中所调用的子模块，其内部可进行少量的数据处理，目的是为了检验入口，输出调用和返回的信息。
  提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具体模块来讲，所需的测试方案数据会显著减少，而且更容易发现和预测模块中的错误。
  图5-9

习题：

单元测试中，检查模块接口时，不需要考虑_（36）。(2013年上半年）
A. 测试模块的输入参数和形式参数的个数、属性、单位上是否一致
B.全局变量在各模块中的定义和用法是否一致
C. 输入是否改变了形式参数
D. 输入参数是否使用了尚未赋值或者尚未初始化的变量

答案：D，D是局部数据结构里的
（36)不是单元测试主要检查的内容。（2013年下半年）
(36) A. 模块接口 B.局部数据结构 C. 全局数据结构 D.重要的执行路径

答案：C
集成测试
1. 自顶向下集成测试
  需要编写桩模块，不需要编写驱动模块
  自顶向下集成测试是一种构造软件体系结构的增量方法。模块的集成顺序为从主控模块（主程序）开始，沿者控制层次逐步向下，以深度优先或广度优先的方式将从属于（或间接从属于）主控模块的模块集成到结构中。
  如图 5-10 所示，深度优先集成是首先集成位于程序结构中主控路径上的所有构件，也可以根据特定应用系统的特征进行选择。
  5-10
  1. 主控模块用作测试驱动模块，用这些从属于主控模块的所有模块代替桩模块。
  2. 依靠所选择的集成方法（即深度优先或广度优先)，每次用实际模块替换一个从属桩模块。
  3. 在集成每个模块后都进行测试。
  4. 在完成每个测试集之后，用实际模块替换另一个桩模块。
  5. 可以执行回归测试，以确保没有引入新的错误。回到第（2）步继续执行此过程，直到完成了整个程序结构的构造。
    回到第2步继续执行此过程，直到完成了整个程序结构的构造
2. 自底向上集成测试
  不需要编写桩模块，需要编写驱动模块
  自底向上集成测试就是从原子模块（程序结构的最底层构件）开始进行构造和测试。由于构件是自底向上集成的，在处理时所需要的从属于给定层次的模块总是存在的，因此，没有必要使用桩模块。自底向上集成策略可以利用以下步骤来实现。
  1. 连接低层构件以构成完成特定子功能的簇。
  2. 编写驱动模块（测试的控制程序）以协调测试用例的输入和输出。
  3. 测试簇。
  4. 去掉驱动程序，沿着程序结构向上逐步连接簇。
    遵循这种模式的集成如图 5-11 所示。连接相应的构件形成簇1、簇2和簇3，利用驱动模块（图中的虚线框）对每个簇进行测试。簇1 和簇2 中的构件从属于模块 M_a，去掉驱动模块D₁和D₂，将这两个簇直接与 M_a相连。与之相类似，在簇3与M_b连接之前去掉驱动模块D₃，最后将 M_a和M_b与构件M_c连接在一起。
    图5-11
3. 回归测试
  每当加入一个新模块作为集成测试的一部分时，软件发生变更，建立了新的数据流路径，可能出现新的I/O，以及调用新的控制逻辑。这些变更可能会使原来可以正常工作的功能产生问题。在集成测试策略的环境下，回归测试是重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。
  回归测试有助于保证变更不引入无意识行为或额外的错误。回归测试可以手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动执行。捕捉/回放工具使软件工程师能够为后续的回放与比较捕捉测试用例和测试结果。回归测试要执行的测试子集包含以下3 种测试用例。
4. 冒烟测试【了解】

5.5.5 测试方法

软件测试方法分为静态测试和动态测试

动态测试。动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。
测试用例由测试输入数据和与之对应的预期输出结果组成。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

5.5.5.1 黑盒测试

黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。
常见的黑盒测试技术有等价类划分法、边界值分析、错误推测【了解】和因果图【了解】等。

等价类划分法
- 有效等价类
- 无效等价类
边界值划分法
- （五点法）一般边界值分析：最小值、比最小值略大、中间值、比最大值略小、最大值
- （七点法）健壮性边界值分析：比最小值略小、最小值、比最小值略大、中间值、比最大值略小、最大值、比最大值略大
McCabe度量法
McCabe 度量法是通过定义环路复杂度，建立程序复永性的度量，它基于一个程序模块的程序图中环路的个数。计算有向图G的环路复杂性的公式为：V(G）=m-n+2，环路个数=箭头-节点+2，秒杀方式【验证方式】：V(G)=闭合区域+1，其中V（G)是有向图G中的环路个数，m是G中的有向弧数，n是G中的节点数。

习题：

采用 McCabe 度華法计算下图所示程序的环路复杂性为(36）。（2016年上半年）

A.1 B.2 C.3 D.4

答案：C；
边-节+2=11-10+2=3；
闭合圈+1=2+1=3

5.5.5.2 白盒测试

白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。
白盒测试常用的技术是逻辑覆盖、循环覆盖和基本路径测试。

逻辑覆盖。逻辑覆盖考察用测试数据运行被测程序时对程序逻辑的覆盖程度，主要的逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖6种。
1. 语句覆盖。
  语句覆盖是最弱的
  语句覆盖：设计测试用例，使得程序中每条语句至少被执行一次
  语句覆盖率 = 被执行过的语句数量/可执行的语句总数
2. 判断覆盖
  判断覆盖：也叫分支覆盖，设计测试用例，使得程序中的每个判断的”真“和”假“都至少被执行一次
  判断覆盖率 = 每个判定的真假值至少出现一次/判断结果的总数
3. 条件覆盖
  条件覆盖：设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值
  条件覆盖率 = 每个条件的真价值至少出现一次/条件结果的总数(条件结果 = 判断数 * 条件数)
4. 判定条件覆盖
  判定条件覆盖：设计测试用例，使得被测程序中的每个判断本身的判定结果(真假)至少满足一次，每个逻辑条件的可能值也至少被满足一次。就是既满足判断覆盖，也满足条件覆盖。
  判断条件覆盖率 =每个判断真假值和条件真假值至少出现一次/(判断结果的总数 + 条件结果的总数)
5. 条件组合覆盖
  条件组合覆盖：设计测试用例，使得被测程序中的每个判定中条件结果的所有可能组合至少执行一次
  条件组合覆盖率 = 条件组合至少出现一次的数量/条件组合的总数
6. 路径覆盖
  路径覆盖：设计测试用例，覆盖程序中所有可能的路径
  路径覆盖率 = 至少被执行过一次的路径数/总的路径数
循环覆盖。
基本路线测试。

白盒测试的原则如下。

程序模块中的所有独立路径至少执行一次。
在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
每个循环都应在边界条件和一般条件下各执行一次。
测试程序内部数据结构的有效性等。

判定（分支）覆盖：直接看最底层的分支个数
路径覆盖：不会就看return语句数

习题：

当用分支覆盖法对以下流程图进行测试时，至少需要设计（35）个测试用例。（2009年上半年）

A、4 B、5 C、6 D、7

答案：C
使用白盒测试方法时，应根据_（17）_和指定的爱盖标准确定测试数据。（2010 年上半年）
（17） A. 程序的内部逻辑 B. 程序结构的复杂性 C. 使用说明书 D.程序的功能

答案：A
下图所示的逻辑流，最少需要_（35)_个测试用例可实现语句覆盖。(2011年上半年）
A、1 B、2 C、3 D、4

答案：A，冒泡排序
下图所示的逻辑流实现折半查找功能，最少需要（34）个测试用例可以覆盖所有的可能路径。（2011 年下半年）

A、1 B、2 C、3 D、4

答案：B；实在不知道怎么做，直接看return数目

白盒测试+McCabe度量法

简单路径是路径中没有重复的结点，没要包含重复的路径。一条走到底。

下图所示的程序流程图中有（34）条不同的简单路径。采用 McCabe 度量法计算该程序图的环路复杂性为（35）。（2014 年下半年）

A、3 B 、4 C、5 D、6
A、3 B、4 C、5 D、6

答案：A；
简单路径是路径中没有重复的结点，没要包含重复的路径

A;边-节点+2=10-9+2=3

伪代码+白盒测试+McCabe

将代码转换成流程图

习题：

如下所示代码（用缩进表示程序块），要实现语句覆盖，至少需要（34〉个测试用例。采用 McCabe 度量法计算该代码对应的程序流图的环路复杂性为（35）。(2021年下半年）
```
input A,n
  for i=2 to n 
    key=A[i]
    j=i-1
    while j>0 and A[j]>key
    	A[j+1]=A[j]
    	j=j-1
    A[j+1]=key
```
（34）A、1 B、2 C、3 D、4
（35）A、1 B、2 C、3 D、4

答案：A;C
这种题需要自己画图

5.6 运行和维护知识【以背为主】

5.6.2 系统维护概述

5.6.2.1 系统可维护性概念

系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度。提高可维护性是开发软件系统所有步骤的关键目的，系统是否能被很好地维护，可以用系统的可维护性这一指标来衡量。

系统可维护性的评价指标
【记】：系统可维护性的评价指标包括理解、测试、修改，以下了解
1. 可理解性。指别人能理解系统的结构、界面、功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等都有助于提高可理解性。
2. 可测试性。诊断和测试的容易程度取决于易理解的程度。好的文档资料有利于诊断和测试，同时，程序的结构、高性能的测试工具以及周密计划的测试工序也是至关重要的。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在进行系统维护时，应该充分利用在系统测试阶段保存下来的测试用例。
3. 可修改性。诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的耦合、内聚、作用范围与控制范围的关系等都对可修改性有影响。
维护与软件文档
文档是软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档显得非常重要。
软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。
可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中应该着重对可维护性进行复审。

软件可维护性是软件开发各个阶段的关键目标
习题：

以下关于软件维护和可维护性的叙述中，不正确的是（36）。（2014年下半年）
(36） A.软件维护要解决软件产品交付用户之后运行中发生的各种问题
B.软件的维护期通常比开发期长得多，其投入也大得多
C.进行质量保证审查可以提高软件产品的可维护性
D.提高可维护性是在软件维护阶段考虑的问题

答案：D，在开发的时候就需要考虑维护

软件文档【秒杀题】

编写高质量文档可以提高软件开发的质量
文档也是软件产品的一部分，没有文档的软件就不能称之为软件。
软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量
高质量文档对于软件产品的效益有着重要的意义

总的来说，软件文档只好不坏，选项中说软件文档不好的就是不正确的。

习题：

以下关于软件系统文档的叙述中，错误的是（34）。（2010年下半年）
A.软件系统文档既包括有一定格式要求的规范文档，又包括系统建设过程中的各种来往文件、会议纪要、会计单据等资料形成的不规范文档
B. 软件系统文档可以提高软件开发的可见度
C.软件系统文档不能提高软件开发效率
D.软件系统文档便于用户理解软件的功能、性能等各项指标

答案：C

5.6.2.2 系统维护的内容及类型

系统维护主要包括硬件维护【了解】、软件维护【重点】和数据维护【了解】。

软件维护
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。修改时应充分利用源程序，修改后要填写程序修改登记表，并在程序变更通知书上写明新旧程序的不同之处。
软件维护的内容一般有以下几个方面。

正确性维护【改正性】。正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的 17%～21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行；而有的错误非常重要，甚至会影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。
适应性维护。适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%～25%。由于目前计算机硬件价格不断下降，各类系统软件层出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。
完善性维护。这是为扩充功能和改善性能而进行的修改，主要是指对己有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，它还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%～60%，比重较大，也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外，还要注意将相关的文档资料加入到前面相应的文档中。【运行期】
预防性维护。为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。这方面的维护工作量占整个维护工作量的4%左右。

习题:

某银行为了使其网上银行系统能够支持信用卡多币种付款功能而进行扩充升级，这需要对数据类型稍微进行一些改变，这一状况需要对网上银行系统进行（36）维护。（2009年上半年）
(36) A. 正确性 B. 适应性 C.完善性 D. 预防性

B
进行防错性程序设计，可以有效地控制_（36）_维护成本。（2011年下半年）
(36) A. 正确性 B. 适应性 C. 完善性 D. 预防性
答案：A
由于信用卡公司升级了其信用卡支付系统，导致超市的原有信息系统也需要做相应的修改工作，该类维护属于（34）（2012 年下半年）
(34） A. 正确性维护 B.适应性维护 C.完善性维护 D.预防性维护

答案：B
系统交付用户使用了一段时间后发现，系统的某个功能响应非常慢。修改了某模块的一个算法使其运行速度得到了提升，则该行为属于（36）维护。（2019 年上半年）【21年差不多】
(36） A. 改正性 B. 适应性 C.改善性 D.预防性

答案：C

可靠性、可用性、可维护性

【以下纯背得分】

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

习题：

计算机系统的_（34）_可以用 MTBF/(1+MTBF)来度量，其中 MTBF 为平均失效间隔时间。（2016 年下半年）
（34） A. 可靠性 B. 可用性 C.可维护性 D. 健壮性

答案：B
软件可维护性是一个系统在特定的时间间隔内可以正常进行维护活动的概率。用MTTF 和MTTR 分别表示平均无故障时间和平均故障修复时间，则软件可维护性计算公式
为（35）。（2021年上半年）
(35) A. MTTF/ (1+MTTF) B. 1/ (1+MTTF） C. MTTR/ (1+MTTR) D. 1/ (1+MTTR)

答案：D

沟通路径

有主程序员：n个成员小组，1个主程序员，普通程序员只需要与主程序员沟通。
沟通路径：n-1。
无主程序员：n个成员的项目小组，相互之间都可以沟通。
沟通路径：n (n-1) /2。

习题：

在进行软件开发时，采用无主程序员的开发小组，成员之间相互平等;而主程序员负责制的开发小组，由一个主程序员和若干成员组成，成员之间没有沟通。在一个由8名开发人员构成的小组中，无主程序员组和主程序员组的沟通路径分别是（19）。（2017年上半年）
(19)A. 32 和8 B. 32 和7 C. 28 和8 D. 28 和7
答案：D，套公式
10 个成员组成的开发小组，若任意两人之间都有沟通路径，则一共有（17）条沟通路径。（2019年上半年）
(17) A. 100 B. 90 C. 50 D. 45
答案：D

5.7 软件项目管理

5.7.2 软件项目估算

COCOMO模型
COCOMO 模型是一种精确的、易于使用的成本估算模型。COCOMO 模型按其详细程度分为基本 COCOMO 模型、中级 COCOMO 模型和详细 COCOMO 模型。
1. 基本COCOMO 模型
  基本 COCOMO 模型是一个静态单变量模型，用于对整个软件系统进行估算。
2. 中级COCOMO模型
  中级 COCOMO 模型是一个静态多变量模型，它将软件系统模型分为系统和部件两个层次，系统由部件构成，它把软件开发所需的人力（成本）看作是程序大小和一系列“成本驱动属性”的函数。
3. 详细COCOMO模型
  它将软件系统模型分为系统、子系统和模块3个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影啊。
COCOMOⅡ模型
有三个阶段性模型
1. 应用组装模型【对象】
2. 早起设计阶段模型【功能点】
3. 体系结构阶段模型【代码行】
  和所有的软件估算模型一样，COCOMOI 模型也需要使用规模估算信息，在模型层次结构中有3种不同的规模估算选择：对象点、功能点和代码行。应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换为代码行。

5.7.3 进度管理

Gantt图【了解】
Gantt 图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。【关键词：依赖、关键、并行】
PERT图【了解】
PERT 图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间。图中的结点表示流入结点的任务的结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示菜个时间点。一个事件有一个事件号和出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始：最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有一个松弛时间（Slack Time)，表示在不影响整个工期的前提下完成该任务有多少机动余地。为了表示任务间的关系，在图中还可以加入一些空任务（用虚线箭头表示)，完成空任务的时间为0。
关键路径是图中起点到终点的最长路径。
图 5-13 是 PERT 图的一个实例。不难看出，该图中松弛时间为0 的这些任务是完成整个工程的关键路径，其事件流为1→2→3→4→6→8→10→11。
- 最早时刻：从0时刻开始，如果又两个分支合一，则选择最大Max的时刻作为最早时刻，例如事件8
- 最迟时刻：从最后事件流开始，最早时刻=最迟时刻，然后从最后的事件往前推，例如上图的事件11，最迟时刻为23。如果两个分支合一则选择最小Min时刻。
- 松弛时间=任务进入事件的最迟时刻-任务持续时间-任务发出事件最早时间
项目活动图【重点】
主要考：关键路径、关键路径长度、松弛时间、某个顶点或者活动是否在关键路径上
松弛时间=关键路径长度（最迟时间）-最早时间
- 关键路径法是图中源点至汇点的最长路径，关键路径的时间称之为项目工期，也表述为项目完成所需的最少时间。
- 总时差是在不延误总工期的前提下，该活动的机动时间。一般在图中，以最晚结束时间减去最早结束时间求取，或以最晚开始时间减去最早开始时间求取。

缩短关键路径上的活动才能缩短整个项目的工时
最少需要多少工时=关键路径=最长的路径

5.7.5 软件配置管理

【考点内容需背】
软件配罝管理其主要目标包括：变更标识、变更控制、版本控制、确保变更正确的实现、变更报告
软件配罝管理其主要内容包括：版本管理、配罝支持、变更支持、过程支持、团队支持、变化报告、审计支持。
上下为两个不同的版本
软件配罝管理其主要内容包括：软件配置标识、变更管理、版本控制、系统建立、配置审核、配置状态报告。
配置数据库可以分为以下三类。

开发库。专供开发人员使用，其中的信息可能做频繁修改，对其控制相当宽松。
受控库。在生存期菜一阶段工作结束时发布的阶段产品，这些是与软件开发工作相关的计算机可读信息和人工可读信息。软件配置管理正是对受控库中的各个软件项进行管理，受挖库也称为软件配置库。
产品库。在开发的软件产品完成系统测试后，作为最终产品存入产品库，等待交付用
户或现场安装。

5.7.6 风险管理【必考】

【考法分析】
本知识点的考查形式，主要有：对风险相关概念描述判断正误；计算风险曝光度。
【要点分析】
1、风险的特性：具有不确定性，可能会造成损失。不确定性是指风险可能发生也可能不发生；损失是指如果风险发生，就会产生恶性后果。
2、风险的类别：项目风险涉及到各种形式的预算、进度、人员、资源以及客户相关的问题，并且可能导致项目损失。技术风险涉及到技术相关的可能会导致项目损失的问题。商业风险与市场因素相关。社会风险涉及到政策、法规等因素。
3、风险暴露：又称风险曝光度，测量的是资产的整个安全性风险，它将表示实际损失的可能性与表示大量可能损失的资讯结合到单一数字评估中。在形式最简单的定量性风险分析中，风险曝光度可通过将风险可能性及影响相乘算出。

如果风险真的发生，有3个因素可能会影响风险所产生的后果，即风险的本质、范围和时间。
风险曝光度(Risk Exposure，RE)=错误出现率（风险出现率）×错误造成损失（风险损失）。

风险识别
风险识别试图系统化地指出对项目计划（估算、进度、资源分配等）的威胁。识别出已知风险和可预测风险后，项目管理者首先要做的是在可能时回避这些风险，在必要时控制这些风险。
风险预测
风险预测又称风险估计，它试图从两个方面评估一个风险；风险发生的可能性或概率；如果风险发生了所产生的后果。
风险评估
一种风险评估很有用的技术就是定义风险参照水准。
风险控制【以上这四点看书本298】
- 活动的目的是辅助项目组建立处理风险的策略，有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划，而其中风险避免是最好的风险控制策略。

5.8 软件质量

5.8.1 软件质量特性【重点，背多分】

ISO/IEC 9126软件质量模型
ISO/TEC 9126 软件质量模型由3个层次组成：第一层是质量特性，第二层是质量子特性，第三层是度量指标。该模型的质量特性和质量子特性如图5-15 所示。
1
其中，各质量特性和质量子特性的含义如下。

功能性（Functionality)。与一组功能及其指定的性质的存在有关的一组属性，功能是指满足规定或隐含需求的那些功能。
- 适应性（Suitability)。与对规定任务能否提供一组功能以及这组功能是否适合有关的软件属性。
- 准确性（Aceurateness)。与能够得到正确或相符的结果或效果有关的软件属性。
- 互用性（Interoperability)。与其他指定系统进行交互操作的能力相关的软件属性。
- 依从性(Compliance)。使软件服从有关的标准、约定、法规及类似规定的软件属性。
- 安全性（Security)。与避免对程序及数据的非授权故意或意外访问的能力有关的软件属性。
可靠性(Reliability)。与在规定的一段时间内和规定的条件下软件维持在其性能水平有关的能力。
- 成熟性（Maturity)。与由软件故障引起失效的频度有关的软件属性。
- 容错性（Fault tolerance)。与在软件错误或违反指定接口的情况下维持指定的性能水平的能力有关的软件属性。
- 易恢复性(Recoverability)。与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和务力有关的软件属性。
易使用性（Usability)。与为使用所需的努力和由一组规定或隐含的用户对这样使用所做的个别评价有关的一组属性。
- 易理解性（Understandability)。与用户为理解逻辑概念及其应用所付出的劳动有关的软件属性。
- 易学性(Leamability)。与用户为学习其应用（例如操作控制、输入、输出）所付出的努力相关的软件属性。
- 易操作性(Operability)。与用户为进行操作和操作控制所付出的努力有关的软件属性。
效率(Eficiency)。在规定条件下，与软件的性能水平与所用资源量之间的关系有关的软件属性。
- 时间特性（Time behavior)。与响应和处理时间以及软件执行其功能时的吞吐量有关的软件属性。
- 资源特性(Resource behavior)。与软件执行其功能时，所使用的资源量以及使用资源的持续时间有关的软件属性。
可维护性(Maintainability)。与进行规定的修改所需要的努力有关的一组属性。易分析性（Analyzability)。与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性。
- 易改变性（Changcability)。与进行修改、排错或适应环境变换所需努力有关的软件属性。
- 稳定性(Stability)。与修改造成未预料效果的风险有关的软件属性。
- 易测试性（Testability)。为确认经修改软件所需努力有关的软件属性。
可移植性（Portability)。与软件可从某一环境转移到另一环境的能力有关的一组展性。
- 适应性（Adaptability)。与软件转移到不同环境时的处理或手段有关的软件属性。
- 易安装性（Installability)。与在指定环境下安装软件所需务力有关的软件属性。
- 一致性（Conformance)。使软件服从与可移植性有关的标准或约定的软件属性。
- 易替换性（Replaceability)。与一软件在该软件环境中用来替代指定的其他软件的可能和努力有关的软件属性。