软件工程知识点总结——第三、四部分_面向对象测试,就是两个类继承自一个类,基类已经经过充分的测试,问两个子类要

考试题型：选择题（20），名词解释（12），简答题（30），综合题（38）
注：以下资料来自各种渠道进行筛选整理的！！！

福州大学软件工程2022年考后回忆

名词解释（喵的，我们这次要写英文全称，所以建议看看）

1. RMMM
2. 统一过程
3. 依赖倒置
4. 重构

简答题

1. 说说你对顺序图和状态图的使用的看法？
2. 面向对象测试，就是两个类继承自一个类，基类已经经过充分的测试，问两个子类要怎么测试？
3. 主观材料题，第一问是从社会、法律、环境、安全等等方面分析项目的可行性，第二问是问你要做这个软件你打算采用什么团队结构，比如随机式组织、开放式组织、封闭式组织。
4. 公司发现用户的需求不明确，所以在开始时故意报低价，在后面需求变更时再报高价，你觉得道德吗？

综合题

1. 给一个商品表，问你要实现上面的话，类图要怎么设计。第二问，现在打算做618促销活动，要怎么修改上一题的类图，使它以后添加其他促销活动（比如双十二促销活动）时比较合理，然后新设计的类图满足哪些面向对象的原则。
2. 挣值分析
3. 给一段程序，画程序流图（注意不是程序结构图），写出独立路径，再写测试用例
4. 给一段描述，画出用例图，画类图，再写第0层数据流图和第1层数据流图

第零部分 概述

软件工程知识点总结——第零部分

第一部分 软件过程 & 第二部分 建模

软件工程知识点总结——第一、二部分

第三部分 质量管理

第15章 质量概念

15.1 什么是质量

设计质量
  在软件开发中，设计质量包括设计满足需求模型规定的功能和特性的程度。

符合质量
  符合质量关注的是实现遵从设计的程度以及所得到得系统满足需求和性能目标的程度。

用户满意度 = 合格的产品 + 好的质量 + 按预算和进度安排交付

15.2 软件质量

软件质量定义：
  (1) 在一定程度上应用有效的软件过程；
  (2) 创造有用的产品；
  (3) 为生产者和使用者提供明显的价值。

15.2.2 McCall的质量因素

质量因素：
运行：

1. 正确性：系统满足需求规格说明和用户目标的程度，预定环境下能正确地完成预期能的程度;
2. 健壮性：在硬件发生故障，输入的数据无效或操作错误环境下，系统能做出适当响应的程度;
3. 效率：为了完成预定的功能，系统需的资源有多少;
4. 安全性（完整性）：对未经授权的人使用软件或数据的企图，系统能够控制的程度;
5. 可用性：一个产品可以被特定的用户在特定的场景中，有效、高效并且满意得达成特定目标的程度
6. 可靠性：系统在规定的外部条件下，按照规定的功能，能够运行指定的一段时间的效率。
7. 易用性：对程序进行学习、操作、准备输入和解释输出所需要的工作量。

修改：

1. 维护性：查出和修复程序中的一个错误所需要的工作量。
2. 灵活性：修改一个运行的程序所需的工作量。
3. 易测试性：测试程序以确保它能完成预期功能所需要的工作量。

转移：

1. 可移植性。将程序从一个硬件和(或)软件系统环境移植到另一个环境所需要的工作量。
2. 可复用性。程序 (或部分程序)在另一个应用系统中使用的程度。
3. 互操作性。将一个(子)系统连接到另一系统所需要的工作量。

15.3 软件质量困境

软件质量困境的论述：
  如果生产一个存在严重质量问题的软件系统，你将受到损失，因为没有人想去购买。另一方面，如果你花费无限的时间、极大的工作量和高额的资金来开发一个绝对完美的软件，那么完成该软件将花费很长的时间，生产成本是极其高昂的，以至于破产。要么没人购买，要么几乎耗尽所有资源、错过市场机会

15.3.2 质量的成本

质量成本包括追求质量过程中或在履行质量有关的活动中引起的费用以及质量不佳引起的费用等。
质量成本可分为：预防成本、评估成本、失效成本

第16章 软件质量保证

软件质量保证 (SQA)包括：
 (1) SQA过程；
 (2) 具体的质量保证和质量控制任务 (包括技术评审和多层次测试策略)；
 (3) 有效的软件工程实践 (方法和工具)；
 (4) 对所有软件工作产品及其变更的控制；
 (5) 保证符合软件开发标准的规程 (当适用时)；
 (6) 测量和报告机制。

16.1 背景问题

软件质量保证：就是为了保证软件高质量而必需的“有计划的、系统化的行动模式”

16.7 软件可靠性

16.7.1 可靠性和可用性的测量

可靠性的简单测量

• 平均失效间隔时间MTBF(Mean-Time-Between-Failure)
• 平均失效时间MTTF (Mean-Time-To-Failure)
• 平均维修时间MTTR (Mean-Time-To-Repair)

定义三者之间的关系：MTBF = MTTF + MTTR

失效率(Failures-In-Time, FIT)：一个部件每10亿机时发生多少次失效的统计测量。因此，1FIT相当于每10亿机时发生一次失效。

可用性：
  软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为：可用性 = MTTF / (MTTF + MTTR) ×100%
  可用性测量在某种程度上对MTTR较为敏感，MTTR是对软件可维护性的间接测量。

16.7.2 软件安全

软件安全：
  主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难。

软件可靠性和软件安全的区别：
  软件可靠性使用统计分析的方法来确定软件失效发生的可能性，而失效的发生未必导致灾难或灾祸。
  软件安全则考察失效导致灾难发生的条件。

第17章 软件测试策略

17.1 软件测试的策略性方法

17.1.1 验证与确认

验证 (verification)：确保软件正确实现特定功能的一系列活动；（对的）
确认 (validation)：确保开发的软件可追溯到用户需求的一系列活动，某种程度上是评价软件产品的有用或有效性。（有根据的）

17.1.2 软件测试组织

独立测试组 (Independent Test Group，ITG)
  为了避免开发人员进行测试所引发的固有问题；
  只有在软件体系结构完成后，独立测试组才开始介入。

17.3 传统软件的测试策略

17.3.1 单元测试

什么是单元测试 (Unit Testing)？
  指对软件中的最小可测试单元进行检查和验证。
  单元：一般应根据实际情况判定其具体含义，如，C语言中，单元指1个函数；java中，单元指1个类；图形化软件中也可以是1个窗口、1个菜单等。
  单元就是认为规定的最小被测试的模块。

单元测试主要对模块的五个基本特性进行评价

单元测试的特点

• 侧重于软件设计的最小单元的验证工作；
• 侧重于构件中的内部处理逻辑和数据结构；
• 进行得越早越好：
  测试驱动的开发：先编写测试代码，再进行开发；
• 模块接口测试是基础：
  只有数据能正确流入、流出模块的前提下，其他测试才有意
  义。

什么是测试用例？
  是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径是否满足某个特定需求。

单元测试的环境
  构件不是独立程序，必须为每个测试单元开发驱动程序和桩程序。
驱动程序：“主程序”，接收测试用例数据，将这些数据传递给待测试构件；
桩程序：替换那些从属于待测试构件的构件。

进行单元测试

1. 编译运行该程序，无语法错误，编译通过；
2. 静态测试，参照c语言编码规范，检查程序中是否存在不符合规范的地方，发现没有注释；
3. 动态测试：运行时，输入数据包括合法数据，非法数据，边界值：
   合法数据, 输入12340，输出为12341，符合预期结果；
   边界值问题，如输入：1234567会导致边界出错；
   非法数据的输入，如输入abcde，则结果出现某些数，因为scanf()的错误判断能力不强造成的。

17.3.2 集成测试

什么是集成测试 (Integration Testing)？
  单元测试的下一个阶段，指将通过测试的单元模块组装成系统或子系统，再进行测试。
集成测试的内容：

• 单元组装后的功能正确性：是否实现预期功能；
• 单元之间的接口：调用关系、数据传递是否正确；
• 集成后的系统性能：集成后系统资源使用情况。

集成测试的方式

• 一步到位的集成：
    所有的构件都连接在一起，全部程序作为一个整体进行测试。
• 增量集成：程序以小增量方式进行构造和测试，具体包括：
    自顶向下测试：从主控模块开始，沿着控制层次结构逐步向下，利用深度优先或广度优先的方式将从属于主控模块的模块集成到结构中去；
    自底向上测试：从原子模块开始进行构造和测试；
    组合方法（三明治）：用自顶向下方法测试程序结构较高层，用自底向上方法测试其从属层。

示例：
程序结构

一步到位集成的示意图

自顶向下测试（广度优先）（一次增加一层）

自顶向下测试（深度优先）（一次增加一条分支）

自底向上测试

三明治集成测试（先选一层为中间层，在这层下面的使用自底向上，在这层上面的使用自顶向下，例如我们选择第2层做为中间层）

三明治集成测试修正版（在三明治的基础上对中间层进行独立测试）

回归测试
  在程序有修改的情况下，保证原有功能正常的一种测试策略。
  重新执行已进行测试的某个子集，以确保变更没有传播不期望的副作用，是减少“副作用”的重要方法：这种方式采取自顶向下的方式测试被修改的模块及其子模块;将这一部分视为子系统，再自底向上测试。
  每次对软件做重要变更时（包括：新构件的集成、删除、修改），要进行回归测试。

冒烟测试（烟幕测试）
  冒烟测试是一种常用的集成测试方法，被设计为一种时间关键的项目步进机制，允许软件小组经常性地评估其软件项目。
  冒烟测试包括以下活动：

1. 将已经转换为代码的软件构件集成到构建 (build)中：
2. 设计一系列测试以暴露影响构建正确完成其功能的错误。
3. 每天将该构建与其他构建以及整个软件产品(以其当前形式)集成起来进行冒烟测试。集成方法可以是自顶向下，也可以自底向上。

当应用于复杂的、时间关键的软件工程项目时，冒烟测试提供了下列好处：

• 降低了集成风险。由于冒烟测试是每天进行的，能较早地发现不相容性和业务阻塞错误，降低因错误而对项目进度造成严重影响的可能性。
• 提高最终产品的质量。由于这种方法是面向构建 (集成)的，因此，冒烟方法既有可能发现功能性错误，也有可能发现体系结构和构件级设计错误。若较早改正了这些错误，产品的质量就会更好。
• 简化错误的诊断和修正。与所有的集成测试方法一样，冒烟测试期间所发现的错误可能与新的软件增量有关，也就是说，新发现的错误可能来自刚加入到构建中的软件。
• 易于评估进展状况。随着时间的推移，更多的软件被集成，更多地展示出软件的工作状况。这就提高了团队的士气，并使管理者对项目进展有较好的把握。

17.4 面向对象软件的测试策略

17.4.1 面向对象环境中的单元测试

面向对象软件的类测试等同于传统软件的单元测试。

17.4.2 面向对象环境中的集成测试

面向对象系统的集成测试有两种不同的策略：

• 基于线程的测试 (Thread-Based Testing)：
    对响应系统的一个输入或事件所需的一组类进行集成。每个线程单独地集成和测试。
• 基于使用的测试 (Use-Based Testing)：
    通过测试很少使用服务类的那些类(称为独立类)开始构造系统。独立类测试后，利用独立类测试下一层次的类 (称之为依赖类)。继续依赖类的测试直到完成整个系统。

17.5 确认测试

  确认测试始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正。
  在进行确认测试或系统级测试时，传统软件、面向对象软件及WebApp之间的差别已经消失。

17.5.3 α测试与β测试

α测试
  α测试是由有代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在用户的后面观看，并记录错误和使用问题。α测试在受控的环境下进行。

β测试
  β测试在一个或多个最终用户场所进行。与α测试不同，开发者通常不在场，因此， β测试是在不为开发者控制的环境下软件的“现场”应用。最终用户记录测试过程中遇见的所有问题，并定期地报告给开发者。
  β测试的一种变体称为客户验收测试，软件开发和QA人员也应该参加，有时是按照合同交付给客户时进行的。客户执行一系列的特定测试，试图在从开发者那里接收软件之前发现错误。
  在某些情况下(例如，大公司或政府系统)，验收测试可能是非常正式的，可能会测试很多天，甚至好几个星期。

17.6 系统测试

  系统测试实际上是对整个基于计算机的系统进行一系列不同考验的测试。虽然每个测试都有不同的目的，但所有测试都是为了验证系统成分已正确地集成在一起且完成了指派的功能

一些典型的系统测试包括：

• 恢复测试
• 安全测试
• 压力测试
• 性能测试
• 部署测试

17.6.1 恢复测试

恢复测试
  恢复测试通过各种方式强制让系统发生故障，并验证其能适当恢复：

• 若恢复是自动的(由系统自身完成)，则对重新初始化、检查点机制、数据恢复和重新启动都要进行正确性评估。
• 若恢复需要人工干预，则应计算平均恢复时间 (Mean-Time-To-Repair，MTTR)以确定其值是否在可接受的范围之内。

17.6.2 安全测试

安全测试
  安全测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。引用Beizer的话来说：“系统的安全必须经受住正面的攻击，但是也必须能够经受住侧面和背后的攻击。”
  在安全测试中，测试者扮演试图攻击系统角色，做什么都可以：

• 测试者可以试图通过外部手段获取密码；
• 可以使系统无法对别人提供服务；
• 可以有目的地引发系统错误以期在其恢复过程中入侵系统；
• 可以通过浏览非保密数据，从中找到进入系统的钥匙，等等。

17.6.3 压力测试

压力测试
  压力测试目的是在性能可以接受的前提下，测试系统可以支持的最大负载。
  压力测试要求以非正常的数量、频率或容量的方式执行系统：

• (1) 平均每秒出现1-2次中断，设计每秒产生10次中断的测试用例；
• (2) 将输入数据的量提高一个数量级以确定输入功能将如何反应；
• (3) 执行需要最大内存或其他资源的测试用例；
• (4) 设计可能在实际的运行系统中产生惨败的测试用例；
• (5) 创建让系统过多查找磁盘驻留数据的测试用例 (频繁的IO) ；

  压力测试的一个变体称为敏感性测试。在一些情况下(最常见的是在数学算法中)，包含在有效数据界限之内的一小部分数据可能会引起极端处理情况，甚至是错误处理或性能的急剧下降：
  敏感性测试试图在有效输入类中发现可能会引发系统不稳定或者错误处理的数据组合。

17.6.4 性能测试

性能测试
  性能测试是在不同负载下（负载一定时），通过一些系统参数(如反应时间等)验证系统性能指标。通过监测系统，测试人员可以发现导致效率降低和系统故障的情形。

17.6.5 部署测试

部署测试
  在很多情况下，软件必须在多种平台及操作系统环境中运行。有时也将部署测试称为配置测试，是在软件将要运行的每一种环境中测试软件。另外，部署测试检查客户将要使用的所有安装程序，并检查用于向最终用户介绍软件的所有文档。

17.7 调试技巧

  当测试用例发现错误时，调试是使错误消除的过程。调试并不是测试，但是发生在测试之后。
  对测试结果进行评估，而且期望的表现与实际表现不一致时，调试过程就开始了。调试试图找到隐藏在症状背后的原因，从而使错误得到修正

第18章 测试传统的应用软件

18.1 软件测试基础

软件可测试性：计算机程序能够被测试的容易程度。受以下方面影响：

• 可操作性：
    “运行得越好，越能有效地测试”
    若设计和实现系统时具有质量意识，那么妨碍测试执行的错误将很少，从而使测试顺利进行。
• 可观察性：
    “你所看见的就是你所测试的”
    输入会产生清楚的输出。在测试执行期间：系统状态和变量是可见的或可查询的、不正确的输出易于识别、内部错误会被自动检测和报告、源代码是可访问的。
• 可控制性：
    “对软件控制得越好，测试越能被自动执行和优化”
    通过输入的某些组合可以产生所有可能的输出，并且输入/输出格式是一致的和结构化的。
    通过输入的组合，所有代码都可以执行到。
    测试工程师能够控制软硬件的状态和变量，能够方便地对测试进行说明、自动化执行和再现。
• 可分解性：
    “通过控制测试范围，能够更快地孤立问题，完成更灵巧的再测试”
    软件由能够进行单独测试的独立模块组成。
• 简单性：
    “需要测试的内容越少，测试的速度越快”
  • 功能简单性 (例如，一个模块完成单一或者简单的功能)
  • 结构简单性 (例如，将体系结构模块化以限制错误的传播)
  • 代码简单性 (例如，采用编码标准以使代码易于审查和维护)
• 稳定性：
    “变更越少，对测试的破坏越小”
    软件的变更经常发生，当发生时是可以控制的，且不影响已有的测试，软件失效后得到良好恢复。
• 易理解性：
    “得到的信息越多，进行的测试越灵巧”
    体系结构设计以及内部构件、外部构件和共享构件之间的依赖关系能被较好地理解。
    技术文档可随时获取、组织合理、具体而详细、并且准确。

影响软件可测性的两个因素：

1. 软件开发文档不完整、不清晰、不准确；
2. 隐藏故障的代码难以测试；

好的测试具有的属性

1. 高的有效性——发现错误的可能性较高
2. 不冗余——每个测试都有不同的目标
3. 最佳性——最佳品种，使用最有可能发现所有错误的测试
4. 适当的复杂性——不太简单也不太复杂 (分解大的测试)，应该独立执行每个测试，防止错误被“掩盖”。

18.3 白盒测试

白盒测试
  把测试对象看做一个透明盒子，利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对目标逻辑路径进行测试——也称为玻璃盒测试、结构测试或逻辑驱动测试。
  在测试早期进行。

18.4 基本路径测试

  它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合。
  设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。

18.4.1 流图表示

示例：

18.4.2 独立程序路径

该图的独立路径集合为：
路径1：1-2-3-4-5-6-7
路径2：1-2-3-4-5-7
路径3：1-2-3-4-6-7
路径4：1-2-4-6-7
路径5：1-4-6-7

环形复杂度计算的三种方法：

1. 流图的区域数量应该对应于环路复杂度 V(G)；【上面的例子为V(G)=5】
2. 给定流图G的环路复杂度 V(G)定义为：V(G) = E – N + 2 。其中：E为流图中的边数量，N为流图中的节点数量。【上面的例子为V(G)=10 - 7 + 2 = 5】
3. 给定流图G的环路复杂度 V(G)也可以定义为：V(G) = P + 1，其中：P为流图中的判断节点数量；【上面的例子为V(G)=4 + 1 = 5】

独立路径数量 <= 环形复杂度V(G)

18.5 控制结构测试

18.5.1 语句覆盖

语句覆盖
  保证每个语句至少执行一次。

18.5.2 分支覆盖

分支覆盖
  保证每个分支至少执行一次。

18.5.3 条件覆盖

条件覆盖
  保证每个条件的真假至少执行一次。（当没有复合条件【 例如：a=0 && b>1】时，条件覆盖和分支覆盖等价）

18.5.4 分支/条件覆盖

分支/条件覆盖
  保证每个条件的真假至少执行一次的基础上，再保证每个分支至少执行一次。（因为单单条件覆盖，有可能会漏掉某些分支没有执行）

18.5.5 路径覆盖

路径覆盖
  保证待测程序的每条独立路径至少执行一次。

18.5.6 数据流测试

数据流测试
数据定义点：数据被赋值的点
数据使用点：数据被使用的点
数据使用：计算性使用(C-USE)和判定性使用(P-USE)

方法：找出数据所有的定义点和数据使用点，根据定义使用对设计测试用例
示例：

18.6 黑盒测试

黑盒测试
  把测试对象看做一个黑盒子：测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。又叫做功能测试、行为测试。
  在测试后期进行，作为发现其他类型错误的辅助方法。

18.6.1 等价类划分

等价类的划分有两种不同的情况：

• 有效等价类：合理的，有意义的输入数据集合。
• 无效等价类：不合理的，无意义的输入数据集合。

在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

等价类划分原则

1. 输入条件规定了取值范围，可以确立一个有效等价类和两个无效等价类。
2. 输入条件规定了输入值的集合，可确立一个有效等价类和一个无效等价类。
3. 如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理，针对这组值确立多个有效等价类；针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。
4. 如果规定了输入数据必须遵守的规则，可以确立一个有效等价类（符合规则）和若干个无效等价类。（从不同角度违反规则）
   例：Pascal语言规定 “一个语句必须以分号‘;’结束”
   则：可以确定一个有效等价类 “以‘;’结束”，若干个无效等价类 “以‘:’结束”、“以‘,’结束”、“以‘ ’结束”、“以’EOF‘结束”等。

18.6.2 边界值分析

边界值分析：
  多数错误出现在输入域的边界处，而不是在 “中间”；
指导原则：

1. 若输入条件指定为以a和b为边界的范围，则测试用例应该包括a和b，略大于a和略小于b ；
2. 若输入条件为一组值，则测试用例应当执行其中的最大值和最小值；
3. 以上指导原则也适用于输出条件，确保输出也符合要求；
4. 若内部程序数据结构有预定义的边界值，要在其边界处测试数据结构 (例如，某张表有100项的定义限制)；

示例：

第19章 测试面向对象的应用

19.5 类级可应用的测试方法

19.5.1 面向对象类的随机测试

19.5.2 类级的划分测试

划分测试的目的是减小测试特定类所需的测试用例数量。可以采用以下划分方法：

• 基于状态的划分：操作分为：改变状态操作集、不改变状态操作集
  改变状态集：deposit , withdraw
  不改变状态集: balance, acctSummary, creditLimit
  用例1 (检查改变状态的操作)：open • setupAccnt • deposit • deposit • withdraw • withdraw • close
  用例2 (检查不改变状态的操作) ：open • setupAccnt • deposit • creditLimit • acctSummary • balance • withdraw • close
• 基于属性划分—根据使用的属性进行划分。
  属性creditLimit可用于定义划分，操作可以分为3类：
  (1) 查询creditLimit的操作；
  (2) 修改creditLimit的操作；
  (3) 既不查询也不修改creditLimit的操作。
• 基于类别划分—根据每个操作完成的一般功能进行划分：
  (1) 初始化操作 (open、setup)；
  (2) 计算操作 (deposit、withdraw)；
  (3) 查询操作 (balance、summarize、creditLimit)；
  (4) 终止操作 (close)。

19.6 类间测试用例设计

类间测试用例设计
  当开始集成面向对象系统时，测试用例的设计变得更为复杂。在这个阶段必须开始类间协作的测试。与单个类的测试相似，类协作测试可运用以下方法：

• 随机方法
• 划分方法
• 基于场景测试
• 行为测试

19.6.2 从行为模型导出测试用例

• 覆盖所有状态的测试用例：
  用例3 ⇒ open • setupAccnt • deposit • withdraw • close
• 覆盖所有操作的测试用例：
  用例4 ⇒ open • setupAccnt • deposit • withdraw • balance• credit • accntInfo • withdraw • close

关于测试的一些题目

选择题

综合题

  对下面的程序给出流图，以及基本路径、语句测试、分支测试、条件测试用例；标记a的所有定义点、使用点以及可能的定义使用关系，并给出测试用例

解：

第20章 安全性工程

软件的安全性提供了使软件系统保护资产免于受到攻击的机制。

20.1 安全性需求分析

软件的安全性需求是由以下两方面确定的：

• 一是与客户合作共同识别出的必须得到保护的资产；
• 二是当出现安全性漏洞时，这些资产受损的成本。损失可用恢复或重建资产的时间和成本来度量。无关紧要的资产无需保护。

20.4 安全性保证

安全性保证是为了向最终用户和其他利益相关者表明确已开发出一个安全产品，从而增强他们的信心。

20.5 安全性风险分析

威胁建模
  威胁建模是一种安全性分析方法，可用于识别那些最有可能引发基于软件系统的破坏的威胁。
  威胁建模是在项目的初期阶段利用需求模型完成。
微软建议的威胁建模的生成步骤如下：

1. 确认资产
2. 给出体系结构概述
3. 分解应用
4. 确认威胁
5. 记录威胁
6. 评估威胁

第21章 软件配置管理

  软件配置管理（SCM）协调软件开发，使混乱降到最小的技术，也叫变更管理，是贯穿于整个软件过程的普适性活动。
  软件配置管理用于：

• 标识变更
• 控制变更
• 保证恰当地实施变更
• 向利益相关者报告变更

软件支持和软件配置管理的区别：

• 软件支持是一组发生在软件已经交付给客户并投入运行后的软件工程活动；
• 软件配置管理则是在软件项目开始时就启动，并且只有当软件被淘汰时才终止的一组跟踪和控制活动。

21.1 软件配置管理概述

软件过程的输出信息可以分成3个主要类别：
 (1) 计算机程序 (源代码和可执行程序)
 (2) 描述计算机程序的文档 (针对不同软件开发人员和客户)
 (3) 数据或内容 (包含在程序内部和在程序外部)

  在软件过程中产生的所有信息项总称为软件配置，软件配置是软件的具体形态在某一时刻的瞬时影像。

变更的起因是什么？
4种基本的变更源：

• 新的业务或市场条件，引起产品需求或者业务规则的变更。
• 新的客户需要，要求修改信息系统产生的数据、产品提供的功能或基于计算机的系统提供的服务。
• 企业改组或扩大/缩小规模，导致项目优先级或软件工程团队结构的变更。
• 预算或进度的限制，导致系统或产品的重定义。

软件维护(也称软件支持)的类型有三种：

1. 改正性维护：为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的不当使用。
2. 适应性维护：为使软件适应外部环境和数据环境的变化，而去修改软件的过程就叫做适应性维护。
3. 完善性维护：为满足在软件使用过程中，用户对软件提出新的功能与性能要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、提高软件的可维护性。

  实践表明，在几种维护活动中，完善性维护所占的比重最大。即大部分维护工作是改变和加强软件，而不是纠错。

21.1.1 SCM场景

  典型的CM(配置管理)有关人员包括：负责软件小组的项目经理、负责CM规程和方针的配置管理员、负责开发和维护软件产品的软件工程师以及使用软件产品的客户。

21.1.3 基线

基线定义：
  已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。
  基线是软件开发中的里程碑，能够帮助我们在不严重阻碍合理变更的条件下控制变更。
  在软件配置项成为基线之前，可以较快地且非正规地进行变更。然而，一旦成为基线，虽然可以进行变更，但是必须应用特定的、正式的规程来评估和验证每次变更。

21.1.4 软件配置项

软件配置项
  缩写为SCI，在软件工程过程中创建的信息。在现实中，将SCI组织成配置对象，这些配置对象具有自己的名字，并且按类别存储在项目数据库中。

  一个配置对象具有一个名称和多个属性，并通过关系来表示与其他配置对象的关联。
  单向箭头(A->B)表示组合关系，即B是A的组成部分。
  双向箭头说明对象之间存在内在联系，如果某个对象发生变更，软件工程师通过查看内在联系能够确定哪些对象可能受到影响。

21.2 SCM中心存储库

SCM中心存储库
  SCM中心存储库是一组机制和数据结构，它使软件团队可以有效地管理变更。

21.2.1 一般特征和内容

作为软件工程团队的中心存储库，应该具备以下四点：

1. 支持过程管理功能 (过程：一组将输入转化为输出的相互关联或相互作用的活动 【ISO9000:2000】)；
2. 支持SCM的特定规则和维护数据；
3. 提供与其他软件工程工具的接口；
4. 能够存储各种数据对象 (例如，文本、图形、视频、音频)

中心存储库内容

21.3 SCM过程

21.3.2 版本控制

版本控制可以用来管理在软件过程中所创建的配置对象的不同版本。
版本：某个特定系统的一个配置。就是一个系统实例，在某种程度上区别于其他系统实例
发布：一个改进了的系统，用于替代原系统，分发给客户的版本。

  一个系统的版本要比发布版本多得多，因为一个系统的内部版本是为内部开发或测试而创建的，有些根本不会发布给客户。

第四部分 管理软件项目

第22章 项目管理概念

22.1 管理涉及的范围

软件项目管理的“4个P”
  人员（People）、产品（Product）、过程（Process）、项目（Project）。

22.2 人员

人员：
  是整个项目成功最重要的因素；
  每个组织都需要不断地提高他们的能力来吸引、发展、激励、组织和留住那些为实现其战略业务目标所需的劳动力；
  人员能力成熟度模型 (People-CMM)：针对软件人员定义了一些关键实践域：人员配备、沟通与协调、工作环境、业绩管理、培训、报酬、能力素质分析与开发、个人事业发展、工作组发展、团队精神或企业文化培养等。

22.2.1 利益相关者

参与软件过程的利益相关者可以分为以下5类：

• 高级管理者：
  负责定义业务问题；
• 项目(技术)管理者：
  计划、激励、组织和控制软件开发人员；
• 开发人员：
  拥有开发产品或应用软件所需技能的人员；
• 客户：
  需求提出者；
• 最终用户：
  软件发布为产品后，直接与软件进行交互的人。

22.2.2 团队负责人

领导能力的MOI模型：

1. 激励(motivation)：鼓励团队成员发挥其最大潜能；
2. 组织(organization)：沿用已有过程（或创新过程），从而将最初概念转换成最终产品；
3. 思想或创新(idea or innovation)：即便被具体开发目标所约束，亦能鼓励团队成员创新，并让其感受到内在的创造力；

具有实战能力的项目经理应该具有的4种品质：

1. 解决问题：
   应能够准确地诊断出最为密切相关的技术问题和组织问题；
   能够系统地制定解决方案，适当地激励其他开发人员来实现该方案；
   能够将在过去项目中学到的经验应用到新环境中；
   如果最初的解决方案没有结果，能够灵活地改变方向。
2. 管理者的特性：
   优秀的项目经理必须能够掌管整个项目。要有信心进行项目控制，同时还要允许优秀的技术人员能够按照他们的本意行事。
3. 成就团队成员：
   为了优化项目团队的生产效率，一位称职的项目经理必须奖励那些工作积极主动并且做出成绩的人。
4. 影响和队伍建设：
   具有实战能力的项目经理必须能够“理解”人。他必须能理解语言和非语言信号，并对发出这些信号的人的要求做出反应。
   项目经理必须能在高压力的环境下保持良好的控制能力。

22.2.3 软件团队

  团队结构取决于组织的管理风格、团队里的人员数目与技能水平，以及问题的总体难易程度。

软件工程团队的四种组织范型：

1. 封闭式范型。按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件时，这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。
2. 随机式范型。松散地组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的团队很有优势。但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。
3. 开放式范型。试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。良好的沟通和根据团队整体意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型团队那么有效率。
4. 同步式范型。 依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流。

5个培育潜在含毒团队的环境：

1. 狂乱的工作氛围
2. 重大挫折使得团队成员产生摩擦
3. 糟糕的软件过程
4. 成员角色模糊
5. 反复地失败

22.3 产品

产品——项目团队将要开发的软件：
  确定产品的目标只是识别出产品的总体目标 (从利益相关者的角度)，而不用考虑如何实现这些目标。
  确定产品的范围是要标识出产品的主要数据、功能和行为特性，更为重要的是，应以量化的方式界定这些特性。
  了解产品的目标和范围之后，就要开始考虑备选的解决方案。管理者和参与开发的人员应根据给定的约束条件选择“最好”的方案，而约束条件包括产品交付期限、预算限制、可用人员、技术接口以及其他各种因素。

22.3.1 软件范围

软件范围
  软件项目范围在管理层和技术层都必须是无歧义的和可理解的。

• 要明确给出定量的数据 (例如，并发用户数、目标坏境，允许的最大响应时间)；
• 说明约束和限制 (例如，产品要求限制内存的大小)。

22.4 过程

过程：
  为完成工作所要求的框架活动和软件工程任务；

  软件过程管理中，需要定义整个软件开发经历的活动、所采用的技术方法、每个阶段的验收标准等。

22.5 项目

项目：
  实现产品的所有工作。

90-90规则
  系统前面90%的任务会花费所分配总工作量和时间的90%，系统最后10%的任务也会花费所分配总工作量和时间的90%。

如何避免90-90问题？

1. 在正确的基础上开始工作。通过以下两点来实现：首先努力地正确理解要解决的问题，然后为每个参与项目的人员设置现实的目标和期望。
2. 保持动力。很多项目的启动都有一个良好的开端，但是，后来慢慢地开始瓦解。为了维持动力，项目经理必须采取激励措施使人员变动量保持绝对最小，团队应该重视它完成的每项任务的质量，而高层管理应该尽可能不干涉团队的工作。
3. 跟踪进展。对于软件项目而言：跟踪项目进展要作为质量保证活动的一部分。此外，可以收集软件过程和项目测量数据，然后对照软件开发组织的平均数据来评估项目的进展。
4. 做出英明的决策。总体上，项目经理和软件团队的决策应该“保持项目的简单性”：只要有可能，就使用商用成品软件或现有的软件构件或模式；采用标准方法时避免定制接口；识别并避免显而易见的风险；分配比你认为的时间更多的时间来完成复杂或有风险的任务。
5. 进行事后分析。建立统一的机制，从每个项目中获取可学习的经验。评估计划进度和实际进度，收集和分析软件项目度量数据，从团队成员和客户处获取反馈，并记录所有的发现。

22.6 W⁵HH原则

W⁵HH原则

1. 为什么要开发这个系统？ Why
   了解软件工作的商业理由是否有效？是否值得做？
2. 将要做什么？ What
   定义项目所需的任务集。
3. 什么时候做？ When
   团队制定项目进度，标识出何时开展项目任务以及何时到达里程碑。
4. 某功能由谁负责？ Who
   规定软件团队每个成员的角色和责任。
5. 他们的机构组织位于何处？ Where
   并非所有角色和责任均属于软件团队，客户、用户和其他利益相关者也有责任。
6. 如何完成技术和管理？ How
   一旦确定了产品范围，就必须定义项目的管理策略和技术策略。
7. 每种资源需要多少？ How much
   通过估算得到。

22.7 关键实践

关键实践包括：

1. 基于度量的项目管理。（第23章）
2. 成本及进度的经验估算。（第24章）
3. 获得价值跟踪。（第25章）
4. 根据质量目标跟踪缺陷。（第15、16章）
5. 人员计划管理。（第22章 22.2节）

第23章 过程度量与项目度量

对软件进行测量的理由：

• 刻画：我们通过刻画而获得对过程、产品、资源和环境的了解，并建立和未来评估比较的基线。
• 评价：通过评价来确定相对于计划的状况。
• 预测：通过取得对过程和产品间关系的理解，并建造这些关系的模型来进行预测 。
• 改进：通过识别产品的不足来改善产品质量和过程性能。

23.1 过程领域和项目领域中的度量

项目度量使得软件项目管理者能够：

1. 评估正在进行的项目的状态；
2. 跟踪潜在的风险；
3. 在问题造成不良影响之前发现它们；
4. 调整工作流程或任务；
5. 评估项目组控制软件工程工作产品质量的能力。

23.1.1 过程度量和软件过程改进

不同类型的过程数据可分为“私有的和公有的”的使用。

• 私有的度量数据的例子有：（按人的）缺陷率、（按模块的）缺陷率、开发中发现的错误数。
    “私有过程数据”思想与汉弗莱(Humphrey) 所建议的个人软件过程(Personal Software Process, PSP)方法相一致。Humphrey认为软件过程改进能够、也应该开始于个人级。私有过程数据是软件工程师个人改进其工作的重要驱动力：
    一个基本的PSP原则是：每个人都是不同的，对于某个工程师有效的方法不一定适合另一个。
    PSP帮助工程师测量和跟踪他们自己的工作，使得他们能够找到最适合自己的方法。
• 某些过程度量对软件项目组是私有的，但对所有小组成员是公有的。例如：主要软件功能（由多个开发人员完成）的缺陷报告；技术评审中发现的错误；每个模块和函数的代码行或功能点。

统计软件过程改进 (statistical software process improvement，SSPI)
  随着一个组织更加得心应手地收集和使用过程度量，更精确的统计软件过程改进方法将取代简单的指标获取方式。
  统计软件过程改进 (statistical software process improvement，SSPI) 使用软件失效分析方法，来收集应用软件、系统或产品开发及使用过程中所遇到的所有错误及缺陷信息。

23.1.2 项目度量

可以用以下指标进行生产率度量：

• 根据创建的模型；
• 文档的页数；
• 功能点；
• 交付的源代码行数。

23.2 软件测量

软件测量
  测量在现实世界中可分为两类：直接测量和间接测量。
软件度量也可以这样分类：

• 软件过程的直接测量包括花费的成本和工作量、产生的代码行(lines of code，LOC)、运行速度、存储容量以及某段时间内报告的缺陷。
• 产品的间接测量包括功能、质量、复杂性、有效性、可靠性、可维护性等。

软件度量范围分为产品度量、项目度量和过程度量：
  产品度量对个人来讲是私有的，将产品度量合并起来生成项目度量。
  项目度量对软件团队来说是公有的，再将项目度量联合起来可以得到整个软件组织公有的过程度量。

23.2.1 面向规模的度量

  为了产生可以与其它项目相比较的度量，可以选择代码行作为规范化值。根据表中所包含的基本数据，能够为每个项目产生一组简单的面向规模度量：

• 每千行代码（KLOC）的错误数；
• 每千行代码（KLOC）的缺陷数；
• 每千行代码（KLOC）的花费；
• 每千行代码（KLOC）的文档页数。

  除此之外，还能够计算出其它有意义的度量：

• 每人月的错误数；
• 每人月的代码行（LOC）；
• 每页文档的花费。

示例：

23.2.2 面向功能的度量

  面向功能度量是由Albrecht首先提出来的，他建议使用功能点 (Function Point, FP)的测量：

• 功能点是基于软件信息域的特性及软件复杂性的评估而导出；
• 考虑程序的“功能性”和“实用性”，而不是对LOC计数。

计算功能点公式：FP ＝ 总计数 × ( 0.65＋ 0.01×SUM (Fi))

• SUM（Fi）是求和函数(对14个问题进行打分)，Fi（i＝1…14）是复杂性校正值；
  取值0-5：0 没有影响；1 偶然的；2 适中的；3 普通的；4 重要的；5 极重要的。
• 

23.3 软件质量的度量

23.3.1 测量质量

测量质量的指标

• 正确性： 正确性是软件完成所需的功能的程度。
    一个程序必须能够正确操作，否则对于用户就没有价值了。关于正确性的最常用的测量是每千行（KLOC）的缺陷数，这里缺陷定义为验证出的与需求不符的地方。当考虑某软件产品的整体质量时，缺陷是指软件发布后由某用户报告的那些问题。缺陷是按某标准时间段计数的，比如1年。
• 可维护性：可维护性是指遇到错误时程序能被修改的容易程度，环境发生变化时程序能够适应的容易程度，用户希望改变需求时程序能被增强的容易程度。
    一个简单的面向时间的度量是平均变更时间（mean-time-to-change，MTTC），它包括：分析变更需求、设计合适的修改方案、实现变更、测试、并将变更后的结果发布给用户所花的时间。一般情况下，与那些不可维护的程序相比，可维护的程序应该有较低的MTTC (对于相同类型的变更)。
  可维护性度量的特性主要有可理解性、可测试性和可修改性：
  • 可理解性被定义为人们通过阅读源代码和文档，了解软件系统的结构、接口、功能、内部过程以及如何运行的难易程度；
  • 可测试性被定义为诊断和测试系统的难易程度；
  • 可修改性被定义为修改软件系统的难易程度；
• 完整性：测量系统在安全方面的抗攻击（包括偶然的和蓄意的）能力。
    攻击可针对软件的三个主要成分：程序、数据及文档。为了测量完整性，必须定义两个附加属性：危险性和安全性（危险性是某个特定类型的攻击在给定时间内发生的概率）（安全性是某个特定类型的攻击将被击退的概率）。 一个系统的完整性可以定义为：完整性 = [ 1－ ( 危险性 × (1 - 安全性 ) ) ]
  例如：
  • 假设危险性 (发生攻击的可能性)是0.25，安全性 (击退攻击的可能性)是0.95，则系统的完整性是0.99 (很高)。
  • 假设危险性 (发生攻击的可能性)是0.5，安全性 (击退攻击的可能性)是0.25，则系统的完整性是0.63 (低的无法接受)。
• 可用性：
  在对软件产品的讨论中，“用户友好性” (容易使用)这个词已经是普遍存在的。如果一个程序不是“用户友好的”，那么它是注定会失败的，即使它所完成的功能很有价值。可用性力图对“使用的容易程度”进行量化。

23.3.2 缺陷排除效率

  缺陷排除效率（DRE）是对质量保证及控制活动中滤除缺陷能力的一个测量，这些活动贯穿于所有过程框架活动。
  当把项目作为一个整体来考虑时，DRE按如下方式定义：DRE = E /（E ＋ D）。其中： E = 软件交付之前所发现的错误数，D = 软件交付之后所发现的缺陷数
  DRE也能够用于在项目中评估一个团队在错误传递到下一个框架活动或软件工程任务之前发现这些错误的能力。DRE_i = E_i / ( E_i ＋ E_i+1 )。其中： E_i = 软件工程活动i中所发现的错误数，E_i+1 = 软件工程活动 i+1中所发现的错误数，这些错误起源于软件工程活动i中未能发现的错误。

第24章 软件项目估算

24.1 对估算的观察

  软件项目管理从项目策划开始，估算是项目策划的第一项活动，是其他项目策划活动的基础。

24.4 资源

  项目策划的第二个任务是对完成软件开发工作所需的资源进行估算。有3类主要的软件工程资源：人员、可复用的软件构件以及开发环境。

24.6 分解技术

24.6.1 软件规模估算

在项目计划中，规模是指软件项目的可量化结果：

• 如果采用直接的方法，规模可以用代码行 (LOC)来测量；
• 如果选择间接的方法，规模可以用功能点 (FP)来表示。

24.6.2 基于问题的估算

计算三点估算（综合不同的估计结果）：
  先确定规模的乐观值 (S_opt)、可能值 (S_m)和悲观值 (S_pess)，再将它们结合起来 (加权平均)
  期望值 S = ( S_opt + 4S_m + S_pess ) / 6
  假定实际的规模结果落在乐观值与悲观值范围之外的概率很小

24.6.3 基于LOC的估算

示例：
  回顾历史数据，此类系统的平均生产率 = 620 LOC/pm.
  一个劳动力每月成本 = $ 8000, 则每行代码成本 = $8000/ 620 = $13 ；
  根据LOC估算及历史生产率数据，该项目总成本估算值 = 33 200 * 13 = $431,000 ，工作量估算值是 = 33 200 / 620 = 54人月。

24.6.4 基于FP的估算

示例：
  总计Fp为320，FP的估算值：FP_estimated = 总计 * [0.65 + 0.01 × Σ(F_i)] = 320 * 1.17 = 375
  假设此类系统的平均生产率 = 6.5 FP/pm，劳动力价格 = $8000 per month, 每个FP的成本约为 $8000 / 6.5 = $ 1230；
  根据FP估算和历史生产率数据，项目总成本估算为$ 1230 *375 = $461,000 ，项目工作量估算为58人月= (375 / 6.5) 或 (461,000 / 8,000)。

24.7 经验估算模型

24.7.2 COCOMO Ⅱ模型

示例：

  使用COCOMO II模型来估算构造一个困难的ATM软件所需的工作量，它产生12个屏幕、10个报表，将需要大约80个软件构件。假定该软件具有困难复杂度和平均开发者/环境成熟度。要求使用基于对象点的应用组装模型计算工作量。
  对象点 = 12 × 3 + 10 × 8 + 80 × 10 = 916
  工作量 = 对象点 / 生产率 = 916 / 13 = 71 /人月

  当采用基于构件的开发或一般的软件复用时，还要估算复用的百分比，并调整对象点数：
  新对象点 = 对象点 * [(100-复用的百分比) / 100

第25章 项目进度安排

25.1 基本概念

案例
  假定你负责的软件团队受命开发一个医疗诊断仪器的实时控制器，该控制器要在9个月之内推向市场。在你进行了仔细的估算和风险分析之后得到的结论是：在现有人员条件下，需要14个月的时间才能完成这一软件。你下一步该怎么办呢？闯进客户的办公室并要求修改交付日期？

项目延期的解决步骤

1. 按照以往项目的历史数据和本项目进展情况，重新进行详细的估算，确定新的估算工作量和工期。
2. 采用增量过程模型，制定一个软件过程策略，以保证能够在规定交付日期提供主要功能，而将其他功能的实现推到以后。
3. 与客户交流，用详细的估算结果说明规定的交付日期是不现实的，一定要指出所有这些估算都是基于以往的项目实践，而且为了在目前规定的交付期限完成该项目，与以往相比在工作效率上必须提高的百分比：
     “我认为在XYZ控制器软件的交付日期方面存在问题，我已经将一份以往项目中生产率的简化明细分类表和以多种不同方式进行的项目估算提交给各位，你们会注意到，在假设与以往的生产率相比有加20%提高的情况下，交付时间仍然需要14个月而不是9个月。”
4. 将增量开发策略作为可选计划提交给客户。

25.2 项目进度安排概述

项目进度安排
  软件项目进度安排 (Software Project Scheduling)是一种活动，通过将工作量分配给特定的软件工程任务。
  进度是随时间而不断演化的：
  在项目计划早期，建立的是一张宏观进度表，该进度表标识了所有主要的过程框架活动。
  随着项目的进展，宏观进度表中的每个条目都会被细化成详细的进度表，这样就标识了特定的 (完成一个活动所必须实现的)软件活动和任务，同时也进行了进度安排。

25.2.1 基本原则

软件项目进度安排的基本指导原则：

• 划分：将项目划分成多个可以管理的活动、动作和任务。为了实现项目的划分，产品和过程都需要进行分解。
• 相互依赖性：划分后的各个活动、动作或任务之间的相互依赖关系必须是明确的。有些任务必须按顺序出现，而有些任务则可以并发进行。
• 时间分配：每个安排进度计划的任务必须分配一定数量的工作单位；必须为每个任务指定开始日期和完成日期。
• 工作量确认：必须确保在任意时段中分配的人员数量不会超过项目团队中的总人员数量。
• 确定责任：每个任务都应该指定特定的团队成员来负责。
• 明确结果：每个任务都应该有一个明确的输出结果，输出结果通常是一个工作产品 (例如，一个模块的设计)或某个工作产品的一部分。多个工作产品可以组合成可交付产品。
• 确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联。当一个或多个工作产品经过质量评审并且得到认可时，标志着一个里程碑的完成。

25.2.2 人员与工作量之间的关系

人员与工作量之间的关系
软件神话：即使进度拖后，我们也总是可以在项目后期增加更多的程序员来跟上进度。
  项目后期增加人手经常会对项目产生破坏性影响，使进度进一步拖延，原因如下：

1. 后期增加的人员需要培训，而培训者会降低本应有的工作时间；
2. 增加交流路径数量和交流复杂度，增加额外的工作量。

项目进度具有弹性：

• 在一定程度上可以缩短项目交付日期（增加资源），也可以拖延项目交付日期（减少资源）；
• 如果能够拖延交付时间，则可以明显降低项目成本。

PNG曲线

25.2.3 工作量分配

工作量分配： 40%(前期的分析和设计) + 20%(编码) + 40%(后期测试)
  这种工作量分配方法只能作为指导原则。各个项目的特点决定了其工作量如何分配：

• 用于项目计划的工作量很少超过2%-3%。
• 客户交流与需求分析大约占用10%-25%的项目工作量。
• 通常有20%-25%的工作量用于软件设计。
• 15%-20%就可以完成编码工作。
• 测试和调试将占用30%-40%的工作量。

25.6 挣值分析（EVA）

挣值分析
  挣值分析是在软件小组按项目进度表工作时，定量分析项目进展的技术：
  挣值系统为每个(软件项目)任务提供通用的值尺度，可以估算完成整个项目所需要的总小时数。并且可以根据各个任务所估算的小时数占总小时数的百分比来确定该任务的挣值。
  更简单地说，挣值是对项目进展的测量。它使得计划者能够不依赖于感觉，采用定量的分析方法来评估一个项目的“完成百分比”。

挣值确定的步骤：

1. 为进度表中的每个工作任务确定计划的预算成本BCWS(Budgeted Cost of Work Scheduled)：一个工作任务有一个BCWS值，特定时间点的BCWS值是在项目进度表中，该时间点应该完成的所有工作任务的BCWS值之和。
2. 所有任务的BCWS值相加，得工作总预算BAC (Budget At Completion)。
3. 计算完成工作的预算成本BCWP (Budgeted Cost of Work Performed，也称Earned Value 获得值)：该时间点实际完成的所有工作任务的BCWS值之和。

进度情况评估：

• 进度表执行指标 SPI = 实际完成任务BCWP / 计划完成任务BCWS，SPI是效率指标，指出项目使用预定资源的效率，SPI值越接近1，说明项目的执行效率越高。
• 进度表偏差 SV = BCWP - BCWS，SV表示与计划进度的偏差。
• 预定完成百分比 = BCWS / 总预算BAC，表示在时间点 t 应该完成工作的百分比值。
• 完成百分比 = BCWP / BAC，表示在特定时间点 t 实际完成工作的百分比值。

预算准确性评估：

• 已完成工作的实际成本ACWP (Actual Cost of Work Performed)为项目进度表中某个时间点已经完成工作的实际工作量之和
• 成本执行指标 CPI = BCWP / ACWP，CPI值越接近1.0说明项目与预算越接近。
• 成本偏差 CV = BCWP - ACWP，CV表示在项目特定阶段的成本节省(相对于计划成本)或短缺

示例1：
  假设你是一个软件项目管理者，授命为一个小型软件项目进行挣值统计。这个项目共计划了56个工作任务，估计需要582人日才能完成。目前有12个工作任务已经完成，但是，按照项目进度，现在应该完成15个任务，下面给出相关进度安排数据（单位：人日），请你做出挣值分析。

  计算该项目的进度执行指标SPI、进度表偏差SV、预定完成百分比、完成百分比、成本执行指标CPI、成本偏差CV。

解：

示例2 ：

  计算4.1前的进度执行指标SPI、进度表偏差SV、预定完成百分比、完成百分比、成本执行指标CPI、成本偏差CV。
解：

示例3：

解：

选择题

第26章 风险管理

26.2 软件风险

软件风险
  具有负面后果、人们不希望发生的事件，包含两个特性：

• 不确定性：可能发生，也可能不发生：事件发生的概率称为风险概率，当概率为1时，风险变成了必然发生的问题，不再称为风险。
• 损失：具有负面后果，是不希望发生的事：与风险有关的损失称为风险影响。

软件风险的类型：

• 项目风险：威胁到项目计划，具体包括：预算、进度、人员、资源、利益相关方、需求、项目复杂度、规模及结构不确定性；
• 技术风险：威胁到软件的质量及交付时间，具体包：设计、实现、接口、验证和维护，规格说明中的歧义性、技术的不确定性、技术陈旧以及“前沿”技术；
• 商业风险：威胁到软件的生存能力，具体包括：市场 (开发没有人需要的产品)、策略 (产品不符合公司的整体商业策略)、销售 (销售人员不知道如何去销售的产品)、管理 (重点的转移、人员的变动以及失去高层支持)、预算 (没有得到预算或人员的保证)

另一种风险分类方法：

• 已知风险：通过仔细评估项目计划、开发项目的商业及技术环境、以及其他可靠的信息来源之后可以发现的风险，例如：不现实的交付时间、没有文档化需求、没有文档化软件范围、恶劣的开发环境；
• 可预测风险：能够从过去项目的经验中推断出来，例如：人员变动、与客户之间欠缺沟通、由于正在进行维护而使开发人员精力分散；
• 不可预测风险：可能会出现，但很难事先识别出它们来。

风险管理的4个主要作用：

• 提高项目的成功率；
• 保证风险发生时的及时反应；
• 增加团队的健壮性；
• 帮助项目经理抓住工作重点；

26.4 风险预测

26.4.2 评估风险影响

风险显露度 (risk exposure, RE)：RE = P * C
  其中P是风险发生的概率，C是风险发生时带来的项目成本；

示例
 假设软件团队按如下方式定义了项目风险：

• 风险识别。计划可复用的软件构件中只有70%将集成到应用系统中，其他功能必须定制开发。
• 风险概率。80%
• 风险影响。计划了60个可复用的软件构件，如果只能利用70%，则18个构件必须从头开发。平均每个构件的程序行数是100 LOC，本地数据表明每个LOC的软件工程成本是$14.0，开发构件的总成本将是 C = 18 * 100 * 14 = $25200
• 风险显露度。RE = 0.8 * $25200 = $20200

26.5 风险细化

风险细化
  在项目计划的早期，风险很可能只是一个大概的描述。随着时间的推移，对项目和风险的了解加深，可以将风险精化为一组更详细的风险，在某种程度上，这些风险更易于缓解、监测和管理。
  风险求精的实现方法之一是按条件-转化-结果(conditiontransition-consequence, CTC)格式来表示，即：给定<条件>，则(可能)将导致：<结果>。

26.6 风险缓解、监测和管理

风险回避：通过建立一个风险缓解计划来回避风险。
风险监测：监测那些可以表明风险正在变高或变低的因素。
风险管理及应急计划：风险发生时的应对措施，是以缓解工作已经失败、而且风险已经发生为先决条件。

26.7 RMMM计划

  风险缓解、监测和管理计划RMMM= (Risk Mitigation, Monitoring and Management Plan)计划将所有风险分析工作文档化，项目管理者还可将其作为整个项目计划的一部分：

• 缓解：我们能够规避风险吗？
• 监测：哪些因素能够显示风险在变化？
• 管理：风险发生时，如何应对？

  有些软件团队并不建立正式的RMMM文档，而是将每个风险分别使用风险信息表单 (risk information sheet, RIS)进行文档化。在大多数情况下，RIS采用数据库系统进行维护，这样容易完成创建、信息输入、优先级排序、查找以及其他分析。