软件质量与管理·考试复习

发表于 更新于 Waline： 阅读次数： 本文字数： 13k 阅读时长 ≈ 47 分钟
考试导向的完整复习资料，覆盖全部考点

软件过程概述

管理的基本概念

管理的三大关键要素：目标、状态、纠偏。

软件项目管理的三大典型目标：成本、质量、工期。

软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。

软件过程管理是为了让软件过程在开发效率、质量等方面有着更好的性能绩效（performance）。

核心区分

软件项目管理和软件过程管理完全是两回事。项目管理关注「完成项目」，过程管理关注「改进过程」。不要混淆两者。

  • 软件项目管理：SCRUM、Kanban 等
  • 软件过程管理：CMMI、SPICE 等
  • 软件过程改进参考元模型：PDCA、IDEAL

软件过程与生命周期模型

软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合，这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。

广义软件过程包括技术、人员以及狭义过程。其理论基石是：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。

广义软件过程的同义词有：软件开发方法、软件开发过程。例如净室（Cleanroom）方法、XP 方法、SCRUM 方法、Gate 方法。

生命周期模型与软件过程的区别和联系：

  1. 生命周期模型是对一个软件开发过程的人为划分
  2. 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分
  3. 生命周期模型往往不包括技术实践

典型生命周期模型包括：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法。

如何理解瀑布模型

  1. 瀑布模型不是单一模型，是一系列模型，覆盖最简单场景（过程元素少）到最复杂的场景（过程元素多）
  2. 软件项目应该结合实际情况选择合适过程元素的瀑布模型，基本原则是，项目面临困难和挑战越多，选择的模型应该越复杂
  3. 软件项目团队往往低估项目的挑战，选择了过于简单的不适用的瀑布模型

四大本质困难

软件开发的四大本质困难和挑战（Brooks《没有银弹》）：

  • 复杂性
  • 不可见性
  • 可变性
  • 一致性

「质量难题」不属于本质困难。本质难题可以缓解，但不可消除。三个本质难题因项目而异，四大本质难题相互促进，本质难题变化带动软件方法（过程）演变。

软件发展三大阶段

阶段 时间 应用特征 典型过程/实践
软硬件一体化 50s~70s 软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更 线性顺序过程（硬件开发流程）、Measure twice cut once、Code and Fix
软件成为独立产品 70s~90s 摆脱硬件束缚（OS）、功能强大、个人电脑出现、需求多变、兼容性要求、来自市场压力 形式化方法、结构化程序设计和瀑布模型、成熟度模型（CMM/CMMI）
网络化和服务化 90s 中期至今 功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、盛行开源和共享文化 迭代式开发、敏捷开发（XP、Scrum、Kanban）、开源软件开发方式、DevOps

选择题考点

  • 「Measure twice, cut once」对应的是代码评审（Code Review），不是软件设计或需求开发
  • Code and Fix 是软硬件一体化阶段（软件作坊阶段）的典型实践
  • 「云计算化和云原生」不属于三大阶段

经典判断题

表述 判定 原因
软件过程管理是软件项目管理应该要实现目标 ✗ 两者完全是两回事
在公司导入敏捷过程是我们今年过程改进的主要目标 ✓ 过程管理和过程改进意思相近
XP 与 CMM/CMMI 是对立的两种软件开发方法 ✗ CMM/CMMI 不是软件开发方法，而是过程管理和改进模型
CMM/CMMI 不适合当今互联网环境的项目管理需求 ✓ CMM/CMMI 是过程管理，根本不是满足项目管理需求的手段
PDCA 和 IDEAL 不适合在敏捷环境中使用 ✗ PDCA、IDEAL 是软件过程改进参考元模型，适合在任何环境中使用
不同的软件开发过程应该使用不同的生命周期模型，反之亦如此 ✗ 生命周期模型是人为划分的，不一定

软件过程管理与改进

CMMI 成熟度模型

CMMI（Capability Maturity Model Integration）五个不同的成熟度等级：

等级 名称 特征
1 Initial 初始级 开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行
2 Managed 已管理级 项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等
3 Defined 已定义级 公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司内共享
4 Quantitatively Managed 定量管理级 构建预测模型，以统计过程控制的手段来管理过程
5 Optimizing 优化级 继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题

等级 2、3 关注的是当前状态（定性、粗粒度管理）；等级 4、5 是根据未来结果进行管理（定量、细粒度管理和改进）。

高等级原因：定量管理和改进。与普通等级的本质差别：通过数据和模型来管理和改进过程。

关于 CMMI 的常见误区

  • CMMI 是过程改进模型，不是软件过程或软件过程模型
  • CMMI 不是过程优劣的标准，也不适合用作公司之间的能力比较
  • CMMI 与敏捷方法不是对立面——CMMI 是过程管理/改进，大部分敏捷方法是开发方法，两者是完全不同性质的事物

PDCA 与 IDEAL

PDCA 模型的步骤：

  1. 分析现状，找出问题（Plan）
  2. 分析影响质量的原因（Plan）
  3. 找出措施（Plan）
  4. 拟定措施计划（Plan）
  5. 执行措施，执行计划（Do）
  6. 检查效果，发现问题（Check）
  7. 总结经验，纳入标准（Act）
  8. 遗留问题转入下期 PDCA 循环（Act）

简要记忆：找出问题，分析质量问题 → 找出措施，制定措施计划 → 执行计划，检查效果 → 总结经验，进入下一循环。

IDEAL 模型解决了软件组织在各种质量改进环境下的需要，包括五个阶段：

  • I: Initiating 初始/开始
  • D: Diagnosing 诊断
  • E: Establishing 建立
  • A: Acting 执行
  • L: Leveraging 调整

分类辨析

  • 软件过程（开发方法）：SCRUM、XP、Kanban、Cleanroom、Gate、TSP、Waterfall
  • 软件过程管理/改进模型：CMM/CMMI、SPICE
  • 软件过程改进参考元模型：PDCA、IDEAL
  • 同类型的方法：Cleanroom / Gate / TSP（都是软件过程）；Waterfall / SCRUM / XP（都是软件实践）
  • 不同类型：CMMI / SPICE / PDCA（SPICE 是过程管理，PDCA 是过程改进元模型）；IDEAL / XP / SCRUM（IDEAL 是过程改进，其余是过程）

敏捷方法

敏捷宣言

敏捷软件开发宣言的 4 个价值观：

  1. 个体和互动 胜过 流程和工具
  2. 可以工作的软件 胜过 详尽的文档
  3. 客户合作 胜过 合同谈判
  4. 响应变化 胜过 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

理解要点：不是否定右项，而是在右项的基础上进一步发挥左项的价值。

敏捷方法的特征

  1. 小周期迭代
  2. 快速响应变更
  3. 价值交付
  4. 自动化

对敏捷的误导性描述

以下特征作为敏捷方法的对立面是不合适的：

误导性描述 为什么不合适
严格/规范方法 所有优秀的工程方法和实践都是严格的，XP 对工程规范有极为严格的要求
重型/轻量级 轻量级和重型并没有刻画具体方法，何为重型没有严格定义；对于变更，几乎所有方法都是限制
计划驱动 所有正式的项目都是计划驱动的，否则计划的作用无法体现
拥抱变更/变更驱动 仅仅是口号，对待变更，所有软件工程方法都是限制和管理的态度
TDD 提供更高的开发质量 并没有足够的证据支持

影响敏捷与规范方法选择的辩证关系：

  • 如果只有强有力的规范而缺乏敏捷，将导致官僚作风，停滞不前
  • 缺乏规范的敏捷则如同一个新创公司在盈利之前的不负责任的狂热
  • 计划驱动的开发人员必须敏捷，敏捷开发人员必须规范

典型敏捷方法

  • XP（eXtreme Programming）：偏重于一些工程实践的描述
  • SCRUM：管理框架和管理实践
  • Kanban：精益生产（丰田制造法）的具体实现——可视化工作流、限定 WIP、管理周期时间

选择题考点

  • 不属于看板方法典型实践的是：站立式会议、重构
  • XP 规定开发人员每周工作时间不超过 40 小时，连续加班不可以超过两周
  • TSP 和 SCRUM 对比：两者都是计划驱动的（不是一个计划驱动一个敏捷）；两者都适合迭代式场景（不是 SCRUM 适合迭代、TSP 适合瀑布）

团队动力学

知识工作与自主团队

软件开发是一项既复杂又富有创造性的知识工作。软件开发是一种智力劳动：

  • 处理和讨论极其抽象的概念
  • 把不同的部分（不可见）整合成一个可以工作的系统

管理知识工作的关键规则：管理者无法管理工作者，知识工作者必须实现并且学会自我管理。

自主团队的特点（6 项）：

  1. 自行定义项目的目标
  2. 自行决定团队组成形式以及成员的角色
  3. 自行决定项目的开发策略
  4. 自行定义项目的开发过程
  5. 自行制定项目的开发计划
  6. 自行度量、管理和控制项目工作

激励理论

三种激励方式

  • 威逼——交易型领导方式
  • 利诱——交易型领导方式
  • 鼓励承诺——转变型领导方式

交易型领导方式很少能产生成功的并且有创造性的团队，因此转变型领导方式（鼓励承诺）是首选。智力工作的激励方式中，应该尽可能使用鼓励承诺这种方式。

团队承诺的要求：承诺自愿、承诺公开、承诺可行、向团队承诺。

马斯洛需求层次理论

五个层次（自底向上）：生理需求 → 安全需求 → 爱与归属感 → 尊重 → 自我实现

  • 自我实现是最高层次（不是自尊！）
  • 激励来自为没有满足的需求而努力奋斗
  • 低层次的需求必须在高层次需求满足之前得到满足
  • 满足高层次的需求的途径比满足低层次的途径更为广泛（不是更少！）

选择题考点

  • 「自我实现是寻求自尊」错误——自我实现是第五层，自尊是第四层
  • 「满足高层次需求的途径比满足低层次的途径更少」错误——应该是更广泛
  • 马斯洛的需求层次理论可用于指导激励手段的选择，不是「维持激励水平」

海兹伯格的激励理论

  • 激励因素（内在因素）：成就感、责任感、晋升、被赏识/认可
  • 保健因素（外在因素）：工作环境、薪金、工作关系、安全等

麦克勒格的 X-Y 理论

X 理论（消极假设）：不喜欢工作并努力逃避、缺乏进取心、更喜欢经常的指导、避免承担责任、自我中心、反对变革。用马斯洛的底层需求（生理和安全）进行激励。

Y 理论（积极假设）：如果给予适当的激励和支持性的工作氛围会达到很高的绩效、具有创造力、能够自我约束和自我导向、渴望承担责任。用马斯洛的高层需求（自尊和自我实现）进行激励。

期望理论

M=V×EM = V \times E

  • MM：激发力量（Motivation），调动人的积极性
  • VV：目标价值（Valence），达到目标对于满足个人需要的价值
  • EE：期望值（Expectancy），能够达到目标的概率

维持激励需要及时的绩效反馈：根据详细计划衡量进度、当前计划不准确时重做计划、为漫长而富有挑战性的项目提供中间反馈（里程碑）。

期望理论应用：为什么第一次开会不宜提出过高目标

如果提出过于雄心勃勃的计划，虽然提高了 VV（目标价值），却也提高了完成难度，降低了 EE（期望值）。如果团队认为完成难度过高，反而会降低整体激发力量 MM，降低团队凝聚力和信心。

领导者 vs 经理

知识工作者的管理需要的是领导者，而不是经理。

角色经理 团队领导者
告知 倾听
指导 询问
说服 激励/挑战
决定 促进达成一致
控制 教练
监控 授权
设定目标 挑战

知识工作领导者应该具备的品质：

  1. 善于倾听团队成员的想法，并加以分析和改进
  2. 善于通过询问来诱导团队成员向着正确方向前进
  3. 善于通过激励以及设定挑战目标等方式吸引团队成员努力表现
  4. 当出现不一致意见时，善于提供各种沟通方式，促成团队达成一致
  5. 培养团队成员技能
  6. 鼓励建立起合理的授权机制
  7. 通过挑战建立目标，确定团队努力方向

TSP 角色与职责

TSP（Team Software Process）启动过程（9 次会议）：

  1. 产品目标和业务目标
  2. 角色分配和小组目标
  3. 开发流程和策略选择（第三次会议确定开发策略）
  4. 整体计划
  5. 质量计划
  6. 个人计划和计划平衡
  7. 风险评估
  8. 准备汇报
  9. 汇报计划/总结

TSP 7 个角色：

角色 目标 主要工作内容
项目组长 建设和维持高效率的团队 激励成员、主持周例会、汇报状态、分配任务、维护资料、组织总结
计划经理 开发完整准确的计划 开发项目计划、平衡计划、跟踪进度、参与总结
开发经理 开发优秀的软件产品 制定开发策略、规模/时间估算、需求规格、高层设计、设计规格、实现、集成/系统测试、用户文档、参与总结
质量经理 按质量计划开发高质量产品 开发跟踪质量计划、警示质量问题、提交配置管理前评审、组织协调评审、参与总结
过程经理 准确记录/报告/跟踪过程数据 定义记录开发过程、支持过程改进、建立维护开发标准、记录会议记录、参与总结
支持经理 保证合适工具和环境 识别工具设施、主持配置管理委员会、维护词汇表、风险和问题跟踪、复用策略应用、参与总结
开发人员 — —

选择题考点

  • 过程经理的工作：建立团队的开发标准、记录周例会的会议记录
  • 项目组长的工作：主持项目周例会（不是过程经理）
  • 计划经理的工作：制定开发计划（不是过程经理）

SCRUM 角色

典型 SCRUM 团队由三个角色组成：

  • 产品负责人（Product Owner）：将开发团队开发产品的价值最大化；管理产品待办列表（清晰表述、排序、优化价值、确保可见性）
  • 开发团队：每个 Sprint 结束时交付潜在可发布的产品增量。特点：自组织、跨职能、平级、无子团队、责任均摊
  • Scrum Master：促进和支持 SCRUM，帮助每个人理解 SCRUM，是一位服务型领导。服务于产品负责人、开发团队、组织

估算、计划和跟踪

估算的要点

  1. 尽可能划分详细一些：当估算多个部件时，总的误差会比各个部件误差的总和要小（误差趋于抵消）
  2. 建立对结果的信心
  3. 依赖数据
  4. 估算要的是过程，而非结果——估算的过程是相关干系人达成一致共识的过程

估算本质上是一种猜测，追求的目标应该是一致性以及估算结果使用者对估算结果的信心。

关于估算准确性的陷阱

「规模估算 1000 LOC，实际 1000 LOC」——规模方面可以认为是可信的。
「时间估算 50 小时，实际 50 小时」——时间方面不能认为是准确或可信的。因为时间估算的偏差产生原因更复杂，跟人的主观能动性有关（可能就是估算多少就按多少去完成），时间偏差的原因可能是估算结果本身。

PROBE 方法

PROBE（PROxy Based Estimation）的作用：精确度量和早期规划之间的桥梁。

原理（2 点）：

  1. 设立合理的代理（Proxy）作为精确度量和早期规划需要的度量之间的桥梁
  2. 相对大小，而非绝对大小

过程：概要设计 → 代理识别和代理规模(E) → 估算并调整程序规模/资源 → 计算预测区间

PROBE A 方法估算时间时为什么不用历史数据中的生产效率数据：在估算资源需求（例如人时）的时候，生产效率一般在分母上，考虑到个体软件工程师生产效率波动，容易导致估算偏差范围变大。

PROBE ABCD 方法对历史数据的质量要求（规模估算）：

方法 数据要求 数据质量要求 计算方法
A 3 组或以上代理规模(E)与实际程序规模 r⩾0.7r \ge 0.7，s⩽0.05s \le 0.05，β0⩽\beta_0 \le 估算结果的 25%，0.5⩽β1⩽20.5 \le \beta_1 \le 2 线性回归
B 3 组或以上计划程序规模与实际程序规模 同 A 线性回归
C 有历史数据 无 按比例调整
D 没有历史数据 无 猜测

通用计划框架

1
2
3

客户需求 → 定义需求 → 概要设计 → 规模估算 → 资源估算 → 日程计划 → 开发产品 → 交付产品
                        ↑ PROBE 方法 ↑
                    (规模历史数据、生产效率历史数据、团队资源水平)

虚线框内即为 PROBE，用来完成规模和资源的估算。

哪些步骤是人为干预的，哪些是自动的：

  • 必须人为干预：定义需求、概要设计
  • 可自动化：规模估算、资源估算（通过历史数据建立模型）
  • 一半人为一半自动：日程计划（需先人为定义团队资源水平和工作效率差异）

这样做的好处：比较容易扛住别人的质疑——基于历史数据和计算机自动生成的估算不会被人质疑。

如何制定让人无法拒绝的计划

  1. 制定任务计划和日程计划：前者描述项目所有的任务清单、任务之间的先后顺序、每个任务所需时间资源；后者描述各个任务在日程上的安排
  2. 制定资源计划
  3. 关键是必须用正推的方式来制订项目计划（从需求到概要设计到规模估算到日程计划，绝不是倒退式）
  4. 除了概要设计和资源估算之外，其他环节尽可能自动化完成，充分参考历史数据进行估算

日程计划需要的信息：任务清单、任务顺序、人员资源水平（不需要「质量要求」和「任务规模」）。

挣值管理（EVM）

EVM（Earned Value Management）是用来客观度量项目进度的一种项目管理方法。

简单实现

仅仅关注进度信息：

  1. 首先需要建立 WBS，定义工作范围
  2. 其次为 WBS 中每一项工作定义一个计划价值（PV, Planned Value）
  3. 最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作，该值成为挣值（EV, Earned Value）

常用规则：

  • 0-100 规则（悲观）：只有当某项任务完成时，该任务的 PV 值将转化成 EV 值
  • 50-50 规则（乐观）：只需要开始某项任务，即可以赋原 PV 值的 50% 作为 EV 值，完成时再加上另外的 50%
  • 实际完成的工作所需成本 AC 不对 EV 值产生任何影响

中级实现

在简单实现的基础上，加入日程偏差的计算：

  • 日程偏差 SV=EV−PVSV = EV - PV
  • 日程偏差指数 SPI=EV/PVSPI = EV / PV

高级实现

在中级实现的基础上，加入成本线（AC）和预测线（BAC）：

  • 成本差异 CV=EV−ACCV = EV - AC
  • 成本差异指数 CPI=EV/ACCPI = EV / AC
  • 预计完成成本 EAC=BAC/CPIEAC = BAC / CPI

通过延伸 EV 与 BAC 的交点，可以明确项目的落后时间。

关于 EVM 的选择题考点

  • EVM 不适用于质量管理（一般只适用于进度和成本管理）
  • 中级实现引入的是日程偏差（不是成本信息），高级实现才引入成本信息
  • EVM 高度依赖估算准确性
  • EVM 可以适应需求变更
  • 挣值管理与项目类型有关（不是无关）

挣值管理表格分析方法

看表格时关注 to-date（迄今为止）的数据：

  1. 先看 Earned Value to date：Actual > Plan → 进度没有落后
  2. 再看 Hours to date：Actual > Plan → 效率低于预期，存在隐患
  3. 计算每小时创造的价值：如果实际低于计划，说明下周或过几周进度可能逐渐落后

里程碑

团队动力学中里程碑的作用：根据期望理论 M=V×EM = V \times E，维持团队的动力需要及时的绩效反馈。在漫长和挑战性的项目里，及时进行里程碑评审，可以及时提供中间反馈，让团队意识到工作有了产出和成果，提升团队的信心。

质量管理

质量管理策略

软件质量：与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体。软件质量包含内外两部分——外部质量面向最终用户，内部质量不直接面向最终用户。

面向用户的质量观：定义质量为满足用户需求的程度。需要明确：用户是谁？用户需求的优先级是什么？这种优先级对开发过程产生什么影响？怎样度量质量水平？

PSP 质量策略：

  1. 用缺陷管理来替代质量管理（既有必要性，也有合理性）
  2. 高质量产品意味着组成软件产品的各个组件基本无缺陷
  3. 各个组件的高质量是通过高质量评审来实现的

PSP 质量策略选择题

  • 「用缺陷管理替代质量管理，既有必要性，也有合理性」正确
  • 「基本无缺陷的开发是通过开展高质量的评审来实现的」正确
  • 「经过训练，评审是所有消除缺陷的手段当中最高效的」错误——编译才是最高效的缺陷消除手段
  • 「PSP 质量策略主要解决的是外部质量，而非内部质量」正确——PSP 使用面向用户的视图

评审

个人评审

关键控制因素：对评审对象的整体把握、评审人员的注意力（打印后评审效果更好）。

评审时机选择：编译前。理由：

  1. 评审速度一定，先评审再编译能够节省更多时间
  2. 编译器会遗漏一部分缺陷，仍然需要通过评审消除
  3. 编译中发现的错误过多意味着隐藏着更多缺陷
  4. 编译前评审是自我学习的好机会
  5. 编译过程中没有缺陷会带来极大的成就感
  6. 先编译会使得评审心态放松，导致评审质量低

小组评审

**Capture-Recapture（捕获-再捕获）**方法：

两人情况：评审人员 A 发现 aa 个缺陷，B 发现 bb 个缺陷，其中 cc 个缺陷两人同时发现。

  • 缺陷总数估算：Z=a×bcZ = \dfrac{a \times b}{c}
  • 遗留缺陷数：a×bc−(a+b−c)\dfrac{a \times b}{c} - (a + b - c)

多人情况：选择独立发现缺陷最多的评审员作为 A，其他所有参与人员的整体作为 B，用同样的方式估算。

CRC 模型定义了两个参数：评审者发现缺陷能力 tt 和缺陷的难度 hh，组合出 4 个基本模型：

  • M0M_0：hh 和 tt 都一样
  • MhM_h：hh 不等而 tt 都一样
  • MtM_t：tt 不等而 hh 都一样
  • MthM_{th}：tt 和 hh 都不等

质量控制指标

Yield

用以度量每个阶段在消除缺陷方面的效率。

Phase Yield=100×某阶段发现的缺陷个数某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数Process Yield=100×第一次编译前发现的缺陷个数第一次编译前注入的缺陷个数\text{Phase Yield} = 100 \times \frac{\text{某阶段发现的缺陷个数}}{\text{某阶段注入的缺陷个数} + \text{进入该阶段前遗留的缺陷个数}}\\ \text{Process Yield} = 100 \times \frac{\text{第一次编译前发现的缺陷个数}}{\text{第一次编译前注入的缺陷个数}}

Process 是整体，若干个 Phase 组成一个 Process。

Yield 只能用来估算/预测，不可以用来精确度量。

A/FR

A/FR（Appraisal to Failure Ratio，质检失效比）：

A/FR=PSP 质检成本PSP 失效成本=设计评审时间+代码评审时间编译时间+单元测试时间\text{A/FR} = \frac{\text{PSP 质检成本}}{\text{PSP 失效成本}} = \frac{\text{设计评审时间} + \text{代码评审时间}}{\text{编译时间} + \text{单元测试时间}}

  • 理论上 A/FR 值越大，意味着质量越高
  • 过高的 A/FR 意味着做了过多的评审，导致开发效率下降
  • PSP 中 A/FR 的期望值是 2.0

PQI

PQI（Process Quality Index，过程质量指标）为 5 个数据的乘积（以基准值作为 1，结果越接近 1 质量越高）：

PQI=min⁡ ⁣(设计时间编码时间, 1)×min⁡ ⁣(2×设计评审时间设计时间, 1)×min⁡ ⁣(2×代码评审时间编码时间, 1)×min⁡ ⁣(编译缺陷密度+1020, 1)×min⁡ ⁣(单元测试缺陷密度+510, 1)\text{PQI} = \min\!\left(\frac{\text{设计时间}}{\text{编码时间}},\, 1\right) \times \min\!\left(\frac{2 \times \text{设计评审时间}}{\text{设计时间}},\, 1\right) \times \min\!\left(\frac{2 \times \text{代码评审时间}}{\text{编码时间}},\, 1\right) \times \min\!\left(\frac{\text{编译缺陷密度} + 10}{20},\, 1\right) \times \min\!\left(\frac{\text{单元测试缺陷密度} + 5}{10},\, 1\right)

五个因子的含义：

因子 含义 基准
设计质量 设计时间应大于编码时间 min⁡(设计时间/编码时间, 1)\min(\text{设计时间}/\text{编码时间},\, 1)
设计评审质量 设计评审时间应大于设计时间的 50% min⁡(2×设计评审时间/设计时间, 1)\min(2 \times \text{设计评审时间}/\text{设计时间},\, 1)
代码评审质量 代码评审时间应大于编码时间的 50% min⁡(2×代码评审时间/编码时间, 1)\min(2 \times \text{代码评审时间}/\text{编码时间},\, 1)
代码质量 编译缺陷密度应小于 10 个/千行 min⁡((编译缺陷密度+10)/20, 1)\min((\text{编译缺陷密度}+10)/20,\, 1)
程序质量 单元测试缺陷密度应小于 5 个/千行 min⁡((单元测试缺陷密度+5)/10, 1)\min((\text{单元测试缺陷密度}+5)/10,\, 1)

PQI 用途：判断模块开发质量、规划质量活动计划、过程改进。PQI 的期望值是 0.4，大于 0.4 即可认为质量较高。

PQI 选择题

  • 「PQI 越高越好」错误——过大成本太高，大于 0.4 即可
  • 「PQI 越低越好」错误
  • 「PQI 不能用作质量规划」错误——PQI 可以用作质量规划和过程改进
  • 「PQI 确保大于 1」错误——PQI 不可能大于 1（每个因子最大为 1）
  • 「PQI 只能预测，不能度量」错误——PQI 既可以预测也可以度量

Review Rate（评审速度）

  • 代码评审速度：小于 200 LOC/小时
  • 文档评审速度：小于 4 Page/小时
  • 「不超过每小时 1000 LOC 就能实现大部分质量要求」错误——应该是 200 LOC
  • 「评审速度应该根据资源水平而定」错误——应该基于项目的需求和时间限制
  • 「技能强的人可以突破每小时 1000 LOC」错误——速度有上限

DRL

DRL（Defect Removal Leverage，缺陷消除效率比）度量的是不同缺陷消除手段消除缺陷的效率。

计算方式：以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该基础的比值。

DRL 只能度量，不能预测。（注意与 Yield 相反：Yield 只能预测不能度量）

  • 「DRL 以单元测试发现的缺陷个数作为基准」错误——应该是每小时发现的缺陷率
  • 「DRL 只能预测，不能度量」错误——说反了，DRL 只能度量不能预测
  • 「DRL 期望值是大于 2.0」错误——DRL 没有固定的期望值（2.0 是 A/FR 的期望值）

五大质量指标总结

指标 能预测 能度量 用途
Yield ✓ ✗ 度量各阶段消除缺陷的效率
A/FR ✓ — 衡量评审时间占比，期望值 2.0
PQI ✓ ✓ 判断模块开发质量、规划质量活动、过程改进
Review Rate ✓ ✓ 指导有效评审的速度控制
DRL ✗ ✓ 比较不同阶段消除缺陷的效率

如何从多方面确保开发的高质量

结合 A/FR、PQI、Review Rate、DRL、Yield 确保高质量：

  1. 在项目计划过程中应该安排确保高质量开发结果的活动，例如按照 A/FR、PQI 等指标的要求，安排对各类产物的个人评审和小组评审
  2. 这些评审活动应该满足一定的要求：评审时间应多于测试时间的两倍以上（A/FR）；评审时间应是相应开发时间的 50% 以上（PQI）；评审速度要求（Review Rate）
  3. 充分借鉴质量指标所体现的开发质量状况，尽早制订相应的质量补救措施
  4. 利用 Yield 等指标构建质量预测模型，更加积极（Proactive）地判定和控制开发质量
  5. 依据 PQI 和 Yield 指标所体现的信息，通过过程改进来提升开发质量

质量路径 Quality Journey

为了追求极高的质量，八个步骤（顺序不能更换）：

  1. 各种测试
  2. 进入测试之前的产物质量提升
  3. 评审过程度量和稳定
  4. 质量意识和主人翁态度
  5. 个体 review 的度量和稳定
  6. 诉诸设计
  7. 缺陷预防
  8. 用户质量观——其他质量属性

Quality Journey 选择题

  • 「步骤可以在适当的时候更换顺序」错误
  • 「加强需求开发应该是 QJ 早期的必备步骤」错误——QJ 并不包括需求开发
  • 「QJ 仍然是在'用缺陷管理替代质量管理'这一基本策略之下进行讨论」正确
  • 「测试应该先于评审得到贯彻和改善」正确（测试是第一步，评审过程度量和稳定是第三步）

不考虑资源和成本时追求质量的有效策略

  1. 重视测试，并且将测试过程文档化并且稳定化
  2. 重视小组评审，定义评审过程，使评审过程的 performance 稳定化
  3. 重视个人评审，提升评审者技能
  4. 重视设计
  5. 开展设计验证

基于 Yield 指标构建缺陷预测模型

总体思想：利用回归技术预测软件开发过程中各阶段的缺陷注入率（Inject Rate）和缺陷消除率（Yield）。

需要知道的指标：

  1. 注入阶段注入多少缺陷
  2. 缺陷注入的密度（需求每一页注入多少缺陷）
  3. 缺陷注入的速度（每小时注入多少缺陷）
  4. 消除阶段的缺陷注入密度和速度
  5. 历史数据中的软件规模、文档规模、开发人员规模

步骤：

  1. 确定纳入影响因子的数据以及数据度量方法
  2. 从系统历史库中收集历史数据，并进行整理
  3. 依照回归技术进行计算
  4. 在项目进行过程中不断收集数据，与预测数据进行比较，调整回归参数
  5. 项目过程中依据实际数据与预测数据的误差进行风险的预防、识别和控制

可能的改进方案：

  • 维护高质量历史数据
  • 影响因子不仅需要软件规模数据，还需要开发过程、文档、人员等方面的可度量化数据
  • 反馈模型——在开发过程中以实际数据调整回归参数
  • （重要） 假设注入水平和消除水平都符合正态分布，计算均值和标准差，用蒙特卡罗方法模拟结果

设计

PSP 四大设计模板

模板 全称 描述 信息类型
OST Operational Specification Template 系统与外界的交互（用户与系统的正常/异常交互）；可用于定义测试场景和测试用例 外部动态
FST Functional Specification Template 系统对外的接口（类和继承关系、外部可见属性和方法）；消除二义性，尽可能用形式化符号 外部静态
SST State Specification Template 精确定义程序的所有状态、转换及伴随的动作 内部动态
LST Logical Specification Template 精确描述系统的内部静态逻辑；建议用伪代码配合形式化符号 内部静态

信息分类矩阵：

动态信息 静态信息
外部信息 OST / FST FST
内部信息 SST LST

选择题考点

  • 记录内部动态信息的是 SST
  • 「OST 在 UML 中没有对应的设计图」错误——OST 对应用例图和时序图
  • 「UML 中的类结构以及类之间的关系，在 PSP 四大设计模板中无法体现」正确（UML 时序图/类图描述的类间关系和对象交互在 PSP 中没有对应内容）
  • 「LST 在 UML 中可以通过类图来体现」错误——LST 描述内部静态逻辑，UML 中没有对应图示
  • 「FST 在 UML 中可以通过类图来体现」错误——FST 描述方法的行为，类图不能体现

设计验证方法

状态机验证

正确的状态机应满足：

  1. 没有死循环和陷阱
  2. 状态转化条件满足正交性（同一状态的同一输入对应同一结果）
  3. 状态转化条件满足完整性
  4. 符合设计意图

「状态转化条件满足独立性」不对——应该是正交性和完整性。

符号化执行验证

基本思想：将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示，然后手工分析伪码程序的行为。

  • 优点：实施简单，可以给出一般化的验证结果，很多时候往往是唯一提供全面验证的方式；通常用于验证复杂算法，特别是对遗留系统的改造
  • 缺点：不适用于有复杂逻辑的场合；纯手工的验证方法容易引入人为的错误

执行表验证

采用构建执行表的方式跟踪伪码程序的执行状况，分析程序行为。用具体数值初始化变量。

跟踪表验证

是对执行表验证的一种扩充，区别在于：

  1. 会识别将伪码程序符号化的机会，并加以符号化
  2. 定义并且优化用例组合

跟踪表能够更一般化地验证程序行为。

正确性证明

把伪码程序变成数学推理，采用形式化方法加以验证。

关于 while-do 循环的正确性验证：

  • 循环判断条件最后一定可以变为 false（终止性）
  • 循环判断条件为真时，单独的循环结构执行结果与循环体再加一个循环结构执行结果一致（不变式）
  • 循环判断条件为 false 时，循环体内所有变量不能被修改
  • 该方法并不能保证循环体算法实现设计意图

设计验证选择题

  • 「执行表是唯一一种提供全面设计验证的手段」错误——符号化执行验证才是
  • 「跟踪表是唯一一种提供全面设计验证的手段」错误
  • 「受限于手工方式，都易于出错」正确
  • 「符号化执行不适合复杂的计算过程」错误——不适合的是复杂逻辑，适合复杂计算/算法
  • 「执行表是跟踪表的扩展」错误——跟踪表是执行表的扩展

团队工程开发

需求开发

需求开发的完整过程：需求获取 → 需求汇总 → 需求验证 → 需求文档制作

客户需求描述的是客户的期望——客户在实际工作中碰到的具体问题，希望通过某个东西来解决。客户需求靠近问题域一侧。

产品需求描述的是开发团队所提供的解决方案——针对客户需求，设计出可以帮助客户解决问题的方案。产品需求靠近解决域一侧。

需求选择题

  • 典型客户需求包括：客户期望、预算限制、法律法规限制（不包括系统功能描述——那是产品需求）
  • 「客户需求是指客户提出的关于软件功能的具体要求」错误——客户需求是期望，不一定是具体功能要求
  • 「工期或者预算往往都是客户需求的一个方面」正确
  • 「产品需求需要跟客户充分讨论才能获取」正确
  • 「客户应该在需求开发活动中起到主导作用」错误——开发团队应该主导

设计标准

团队设计活动中应注意的设计标准：命名规范、接口标准、出错/异常处理信息、设计表示方式。

团队设计活动中应注意的内容：设计标准的应用、复用的考虑、可测试性支持、可用性支持。

集成策略

策略 描述 优点 缺点
大爆炸 所有组件一次集成 模块质量高时效率最高，测试用例数量少 难以定位缺陷位置
逐一添加 一次添加一个组件（CI/CD 本质上就是此策略） 容易定位缺陷位置 需要非常多测试用例
集簇集成 优先集成相似、关联组件形成可工作组件，再不断向上集成 尽早获得可工作组件，有利于复用策略 过于关注个别组件，不能尽早发现系统层面缺陷
扁平化集成 自顶向下集成，不断替换桩 可以较早发现系统层面的缺陷 需要大量桩程序，往往不能覆盖多种状态

集成策略选择题

  • 「当待集成组件质量普遍不高时，不可以使用扁平化策略」错误——可以使用
  • 「当需要尽早获取可以工作的组件时，应该使用集簇式策略」正确
  • 「当待集成组件质量普遍较高时，可以使用大爆炸式集成策略」正确
  • 「持续集成本质上就是逐一添加策略」正确
  • 「扁平化策略可以较早地充分地暴露系统级别的错误」错误——能较早但不能充分
  • 「集簇式集成策略有助于复用策略的实现」正确
  • 「扁平化策略和集簇式策略的优缺点正好相反」错误——关注点不同，不是恰恰相反

V&V（验证与确认）

验证（Verification）：确保选定的工作产品与事先指定给该工作产品的需求（产品需求）一致。关注的是产品需求是否被正确实现。

确认（Validation）：确保开发完成的产品在即将使用的环境中工作正确。关注的是客户需求是否得到满足。

两者关系：

  • 验证活动的依据来源于确认的目标（产品组件需求必须与客户需求一致）
  • 验证活动为确认活动提供了前提条件（在完成产品需求之前，考虑客户需求是否满足没有意义）
类型 关注 典型活动
验证（Verification） 产品需求 需求评审、详细设计评审、单元测试、代码评审
确认（Validation） 客户需求 验收测试

V&V 选择题

  • 典型的验证活动：详细设计评审、单元测试（不是需求评审和试运行）
  • 典型的确认活动：验收测试（不是代码评审、系统测试、持续集成）
  • 典型的确认对象：用户手册、系统使用培训材料
  • 配置项：接口设计文档、源代码、用户手册、系统使用培训材料（全部都是）

配置管理

目的是建立与维护工作产品的完整性。

核心概念：

  • 配置项：配置管理中作为单独实体进行管理和控制的工作产品集合
  • 基线：配置项持续演进的稳定基础。经典基线包括需求分析之后、设计完成之后、单元测试之后以及最终产品发布

配置管理的活动：识别和记录配置项的物理特性和功能特性 → 控制上述特性的变更 → 记录和报告变更过程和配置项状态 → 验证配置项是否与需求一致。

团队内部的配置审计通常应关注：物理审计、配置项列表、配置管理记录、基线计划（全部都要关注）。

项目支持活动

度量与分析（GQM）

GQM（Goal-Question-Metric）是一种建立软件度量体系的方法，从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼为可以测量的值。

  • 概念层（目标 Goal）：为某个特定对象定义目标
  • 操作层（问题 Question）：使用一系列问题来定义和评估目标达成的进展
  • 量化层（度量 Metric）：以量化方式回答上述问题

决策分析

决策分析选择题

  • 「决策分析指南中最关键的是明确判定标准」正确
  • 「评价方法是体现决策者利益诉求的关键」错误——应该是评价标准才是关键
  • 「候选方案的识别应该晚于评价标准」正确
  • 「项目投标就是一个典型的决策分析活动」错误——招标才是决策分析过程

根因分析

目的：避免类似错误反复发生。

根因分析的活动：识别和选定问题 → 根因分析 → 建立改进的行动方案 → 实施改进，评估效果。

典型角度：技术角度、人员角度、培训角度、过程角度。工具：鱼骨图。原则：2-8 法则（20% 的因素影响 80% 的结果，关注「关键的少数」）。

根因分析选择题

  • 「根因分析必须基于丰富的数据来选择合适的问题」错误——有时没有丰富数据也需要做
  • 「根因分析活动终止的唯一特征就是找到根因的明确解决方案」错误——有时确定没有解决方案也要终止

DevOps

DevOps 三步法

  1. 第一步：实现开发到运维的工作快速地从左向右流动
  2. 第二步：从右向左的每个阶段，采用持续、快速的工作反馈机制
  3. 第三步：建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验

DevOps 典型实践和方法（至少 5 个）

  1. 开发运维一体化
  2. 方法论基础是敏捷软件开发、精益思想以及看板 Kanban 方法
  3. 以领域驱动设计为指导的微服务架构方式
  4. 大量虚拟化技术的使用
  5. 一切皆服务 XaaS（X as a Service）的理念指导
  6. 构建了强大的工具链，支持高水平自动化

DevOps 最佳实践

  1. 培养协作和无责沟通的文化
  2. 采用持续集成和交付（CI/CD）
  3. 设置自动化测试
  4. 关注可观察性并找到正确的指标
  5. 使用自动化避免手动工作
  6. 在开发生命周期的早期加入安全性
  7. 从事件中学习并围绕它们构建流程
  8. 首先关注概念，然后找到合适的工具
  9. 采用基础设施即代码（IaC）并推动自助式基础设施模型

开源软件开发方法

基于并行开发模式的软件开发的组织与管理方式。

Linus 定律：如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。（已经不适用）

核心原则：早发布、常发布、倾听用户反馈；把用户当成开发合作者对待；设计上的完美不是没有东西可以再加，而是没有东西可以再减。

代码管理：严格的代码提交社区审核制度。

演化形式：内部开源（inner source）、众包（Crowdsourcing）。

选择题速查

WBS 相关

  • 「WBS 应该对应 OBS」错误——WBS 和 OBS 关注的角度和目的不同
  • 「WBS 提供了范围管理的基础」正确
  • 「WBS 工作分解最底层的要素是实现目标的充分必要条件」正确
  • 「WBS 分解的时候同一层不能应用不同标准」正确

关于软件过程的补充分类

不属于管理活动三大要素（目标、状态、纠偏）的是：成本、质量、工期（这些是三大典型目标）。

不属于软件过程的有：CMM/CMMI（过程管理模型）、IDEAL（过程改进元模型）。

PSP 缺陷日志

至关重要的信息：缺陷发现时间、缺陷根因描述。（缺陷重现方式和缺陷关联的其他缺陷不是至关重要的）

日程计划制定

为了制定 Schedule Plan 不需要的是：Task size（任务规模）。

需要补充的一项数据：Task List（任务清单）。

规模估算和度量

  • 「功能点是一种可提供精确规模度量结果的方式」错误——功能点可在早期提供直观结果，但不能精确度量
  • 「规模数据扮演了沟通历史数据的桥梁的角色」正确
  • 「PROBE 只用于规模估算」错误——还可用于时间估算

重要简答题模板

AI 与软件工程（2023 开放题）

结合 ChatGPT/大模型背景，从三个话题展开：

项目管理：AI 可以在项目规划和进度管理方面提供更准确的预测，帮助更好地分配资源、识别风险；挑战在于需要适应与 AI 系统的集成，确保人机合作的高效性。

质量管理：AI 可以通过自动化测试、静态代码分析和缺陷预测等技术提高软件质量；挑战在于 AI 模型的不透明性和复杂性使测试更加困难，需要创新性的测试方法和工具。

过程改进：AI 可以帮助发现效率低下的环节、优化流程、提供个性化指导；挑战在于关注数据质量和模型解释性，确保 AI 系统的可解释性和可信度。

缺陷消除时间规律

  1. 一个缺陷存在越久，消除它的代价就越高，而且代价的增长是非线性的
  2. 通过阅读代码来消除缺陷（Code Review）是最高效的
  3. System Test 左侧基本是模块内部，System Test 是系统级跨模块的。要想尽一切办法在模块内部消除缺陷，但不能因为代价高就放弃系统测试