软件质量与管理 · 课上选择题 解答与解析¶
试题来源：
assets/exams/软件质量与管理-课上选择题-含答案.pdf（荣国平，2022-2023 学年课堂练习）参考资料：
assets/other/目录下学长整理的课堂笔记，包括： - 《SQM非敏捷终版笔记》（陈宇航、白信羽、梁卓颖整理） - 《要背的-蔡之恒》 - 《质量管理》 - 《非敏捷视角课程笔记》
一、软件发展与过程（Q1–Q5）¶
（1）"Measure twice, cut once" 描述的是下述哪个软件开发场景¶
A. 软件设计 B. 代码评审 C. 需求开发 D. V&V
点击查看答案与解析
答案：B（代码评审）
题目解析："Measure twice, cut once"（三思而后行）是软硬件一体化阶段（1950s–1970s）的典型实践。该阶段受硬件开发流程影响，强调在应用更改之前仔细检查代码，在问题成为主要问题之前识别和纠正。这与代码评审（Code Review）的场景完全一致——在代码合入前仔细审查。软件设计、需求开发、V&V 均不匹配此描述的时序特征。
知识点出处：
软件质量与管理.第二讲.pdfSlide 2-5（软件发展三大阶段）。参考资料：
assets/other/要背的-蔡之恒.pdf第 1 页 —— "Measure twice, cut once" 和 Code and Fix 同属软硬件一体化阶段典型实践。题目来源：本题在历年课堂选择题中反复出现（2022Fall、2023 选择题，2022 年试卷 Q1）。
（2）整体来看，我们可以把软件的发展分为三大阶段，以下不属于三大主要阶段的是¶
A. 软硬件一体化 B. 网络化和服务化 C. 云计算化和云原生 D. 软件成为独立产品
点击查看答案与解析
答案：C（云计算化和云原生）
题目解析：软件发展三大阶段及其时间范围：①软硬件一体化阶段（1950s–1970s）：线性顺序过程，典型实践为 Measure twice cut once、Code and Fix；②软件成为独立产品阶段（1970s–1990s）：结构化程序设计、瀑布模型、成熟度模型；③网络化和服务化阶段（1990s 中期迄今）：迭代式开发、敏捷（XP/SCRUM/Kanban）、开源、DevOps。云计算化和云原生是网络化和服务化阶段的子趋势，不是独立的三大阶段之一。
知识点出处：
软件质量与管理.第二讲.pdfSlide 2-5（三大阶段）。参考资料：
assets/other/要背的-蔡之恒.pdf第 1 页第 6 条 —— 三大阶段完整总结；assets/other/SQM非敏捷终版笔记.pdf—— 三大阶段与典型实践对照。题目来源：本题在历年课堂选择题中反复出现（2022Fall、2023 选择题，2022 年试卷 Q2）。
（3）以下描述中，不属于软件开发本质困难或者本质挑战的是¶
A. 质量难题 B. 复杂性 C. 不可见 D. 一致性
点击查看答案与解析
答案：A（质量难题）
题目解析：Fred Brooks 在《没有银弹》（No Silver Bullet，1986）中定义了软件开发的四大本质困难（Essential Difficulties）：①复杂性（Complexity）——软件是世界上最复杂的人造产物，状态空间爆炸；②不可见性（Invisibility）——软件没有物理形态，本质上不可见，无法用几何可视化呈现；③可变性（Changeability）——软件极易被修改，外部环境持续变化驱动软件演进；④一致性（Conformity）——软件必须与现有系统、接口、协议、人为惯例保持一致。"质量挑战/质量难题"不在四大本质困难之列，是选择题中最常见的干扰项，几乎每年必考。
本质困难根植于软件本身特性，工具/语言/平台的进步只能缓解，无法彻底消除。它们也是驱动三大阶段软件方法演变的根本动力。
知识点出处：
软件质量与管理.第二讲.pdfSlide 2（Brooks 四大本质困难）。参考资料：
assets/other/要背的-蔡之恒.pdf第 1 页第 1 条 —— Brooks 四大本质困难；assets/other/SQM非敏捷终版笔记.pdf—— 本质困难驱动方法论演变。题目来源：本题在 2020-mid 期中、2022Fall 课堂选择、2023 课堂选择、2022 年试卷 Q3、2023 年试卷 Q3 中均出现。
（4）以下描述中，哪一种实践是软硬件一体化阶段的典型实践¶
A. Code and Fix B. 迭代式开发 C. 瀑布生命周期模型 D. 成熟度模型
点击查看答案与解析
答案：A（Code and Fix）
题目解析：软硬件一体化阶段的典型方法包括："Measure twice, cut once" 和 Code and Fix（编码+改错）。B 迭代式开发是网络化和服务化阶段（90s 中期至今）的实践；C 瀑布生命周期模型和 D 成熟度模型（如 CMM）是软件成为独立产品阶段（70s–90s）的实践。
知识点出处：
软件质量与管理.第二讲.pdfSlide 2-5（三大阶段典型实践）。参考资料：
assets/other/要背的-蔡之恒.pdf第 1 页第 6 条 —— 三阶段典型实践对照表。题目来源：本题在历年课堂选择题中反复出现（2022Fall、2023 选择题，2022 年试卷 Q4）。
（5）对比TSP和SCRUM，下列说法不恰当的是¶
A. 都是过程框架，需要填补具体实践之后才是一个可以工作的过程 B. 一种是计划驱动方法，另外一种是敏捷方法 C. SCRUM适合迭代式场景，TSP适合瀑布场景 D. 两种方法都需要进行度量数据收集、分析，从而支持管理决策
点击查看答案与解析
答案：B、C
题目解析： - A 正确：TSP 和 Scrum 都是过程框架（Process Framework），需要填补具体工程实践（如编码规范、测试策略等）之后才是一个完整可工作的过程。 - B 不恰当：TSP 和 Scrum 都是计划驱动方法。Scrum 也有 Sprint Planning、Daily Scrum、Sprint Review 等计划活动，不能简单将 Scrum 与"计划驱动"对立。 - C 不恰当：两者都适合迭代式场景。TSP 采用迭代式开发周期（Launch → Development → Postmortem），并非仅适用于瀑布场景。 - D 正确：两者都强调度量的重要性，都需要收集和分析数据以支持管理决策（TSP 有严格的过程数据收集，Scrum 有燃尽图、速率等度量）。
知识点出处：
软件质量与管理.第三讲.pdfSlide 约 20-25（TSP 与 Scrum 对比）。参考资料：
assets/other/SQM非敏捷终版笔记.pdf—— TSP 和 Scrum 对比论述。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q5 中出现。
二、团队与激励（Q6–Q8）¶
（6）以下特征适用麦克勒格Y理论（McGregor's Theory Y）激励的场合是¶
A. 关注工作环境，薪金等 B. 更喜欢经常的指导，避免承担责任，缺乏主动性 C. 自我中心，对组织需求反应淡漠，反对变革 D. 能够自我约束，自我导向与控制，渴望承担责任
点击查看答案与解析
答案：D
题目解析： - D 正确：Y 理论认为员工能够自我约束、自我导向与控制、渴望承担责任，对工作有天然的投入感。用马斯洛的高层需求（自尊和自我实现）进行激励。 - A 属于保健因素（Herzberg 双因素理论中的外在因素）——工作环境、薪金等。 - B、C 属于X 理论特征——X 理论假设员工缺乏主动性、规避责任、需要被指导和控制。X 理论适合用马斯洛底层需求（生理和安全）激励。
知识点出处：
软件质量与管理.第三讲.pdfSlide 15-16（McGregor X-Y 理论）。参考资料：
assets/other/要背的-蔡之恒.pdf第 3-4 页 —— X 理论和 Y 理论完整对比。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q6 中出现。
（7）以下关于马斯洛的需求层次理论描述不正确的是¶
A. 自我实现是寻求自尊（Esteem） B. 激励来自为没有满足的需求而努力奋斗 C. 低层次的需求必须在高层次需求满足之前得到满足 D. 满足高层次的需求的途径比满足低层次的途径更少
点击查看答案与解析
答案：A、D
题目解析： - A 不正确：自我实现（Self-Actualization）是马斯洛需求层次的第五层（最高层），而自尊（Esteem）是第四层，两者不可混为一谈。 - D 不正确：满足高层次需求的途径比满足低层次的途径更为广泛（更多而非更少）。 - B 正确：激励的基本原理就是来自为尚未满足的需求而努力奋斗。 - C 正确：低层次需求需先满足——马斯洛晚年虽有所修正（认为不一定要完全满足后才出现高层次需求），但低层次需求仍需在较大程度上得到满足后才出现高层次需求。
知识点出处：
软件质量与管理.第三讲.pdfSlide 7-8（马斯洛需求层次理论）。参考资料：
assets/other/要背的-蔡之恒.pdf第 3 页第 10 条 —— 马斯洛需求层次理论要点。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q7 中出现。
（8）以下关于团队动力学的论述，不恰当的是¶
A. 马斯洛的需求层次理论可以用来更好地维持激励水平 B. 智力工作的激励方式中，应该尽可能使用鼓励承诺这种方式 C. 麦克勒格的X理论适合用马斯洛底层需求激励 D. 海兹伯格的激励理论区分为内在因素和外在因素两种
点击查看答案与解析
答案：A
题目解析： - A 不恰当：马斯洛的需求层次理论可用于指导激励手段的选择（如针对不同需求层次设计不同激励方式），而非主要用于"维持激励水平"。 - B 正确：智力工作中，鼓励承诺（Commitment）是有效的激励方式——相比威逼和利诱，承诺更能激发知识工作者的内在动力。 - C 正确：X 理论的员工关注底层需求（生理、安全），适合用马斯洛底层需求（薪酬、工作保障）来激励。 - D 正确：Herzberg 将激励因素分为内在因素（成就感、责任感、晋升、被赏识）和外在因素/保健因素（薪酬、工作环境、公司政策、安全）。
知识点出处：
软件质量与管理.第三讲.pdfSlide 13-16（团队动力学综合：马斯洛、McGregor X-Y、Herzberg 双因素）。参考资料：
assets/other/要背的-蔡之恒.pdf第 3-4 页 —— Herzberg 激励理论与 X/Y 理论要点；assets/other/SQM非敏捷终版笔记.pdf—— 团队动力学综合论述（"并不是激励维持手段，而是用于指导激励手段的选择"）。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q8 中出现。
三、估算、计划与跟踪（Q9–Q11）¶
（9）下列关于挣值管理方法的描述中正确的是¶
A. 挣值管理中进度的计算可以区分悲观和乐观两种方式 B. 挣值管理的简单、中级和高级实现三种方式中，只有高级实现才会涉及成本因素 C. 挣值管理与项目类型无关 D. 挣值管理不适用与需求频繁变更的软件项目管理中
点击查看答案与解析
答案：B
题目解析： - A 错：EVM 进度计算不区分悲观/乐观方式。赋 EV 值采用固定规则（如 0-100 原则、50-50 原则），跟乐观/悲观无关。 - B 正确：简单实现仅关注进度信息（EV）；中级实现加入 PV 和日程偏差（SV/SPI）；只有高级实现才引入 AC（实际成本）和成本偏差（CV/CPI），所以"只有高级实现才会涉及成本因素"是正确的。 - C 错：EVM 与项目类型有关，不同类型的项目需要调整 EVM 的应用方式。 - D 错：EVM 可以适应需求变更——燃尽图（Burndown Chart）即为 EVM 简单实现在敏捷/变更频繁场景中的变形应用。
知识点出处：
软件质量与管理.第四讲.pdfSlide 约 30-35（挣值管理 EVM）。参考资料：
assets/other/要背的-蔡之恒.pdf第 7-8 页第 19 条 —— EVM 三种实现详解。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q9 中出现。
（10）下述关于WBS的描述中，哪些说法不正确的？¶
A. WBS应该对应OBS B. WBS提供了范围管理的基础 C. WBS工作分解最底层的要素是实现目标的充分必要条件 D. WBS分解的时候，同一层不能应用不同标准
点击查看答案与解析
答案：A
题目解析： - A 不正确：WBS（工作分解结构）和 OBS（组织分解结构）关注角度和目的不同。WBS 关注"做什么"，OBS 关注"谁来做"，WBS 不一定必须对应 OBS。 - B 正确：WBS 提供了项目范围管理的基础，定义了需要完成的所有工作。 - C 正确：WBS 最底层要素是实现目标的充分必要条件（100% 规则），即所有底层工作包加起来恰好覆盖全部范围，不多不少。 - D 正确：WBS 分解时同一层应保持一致的分解标准（如同层均按功能分解或均按阶段分解），不建议混用不同标准，否则容易产生遗漏或重叠。
知识点出处：
软件质量与管理.第四讲.pdfSlide 24-28（WBS 工作分解结构）。参考资料：
assets/other/质量管理.pdf—— WBS 创建方法与 100% 规则。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q10 中出现。
（11）下述关于EVM的描述中，哪些说法不正确的？¶
A. EVM不适用于质量管理 B. EVM的中级实现中引入成本信息 C. EVM高度依赖估算准确 D. EVM可以适应需求变更
点击查看答案与解析
答案：B
题目解析： - A 正确（不选）：EVM 是项目管理工具（跟踪进度和成本），不适用于质量管理。质量管理有独立的指标体系（PQI、DRL、Yield、A/FR 等，在第五讲讲授）。进度偏差不等于质量问题。 - B 不正确（入选）：中级实现只引入 PV（计划价值，即进度信息）和 SV/SPI，不引入成本信息；只有高级实现才引入 AC（实际成本）和 CV/CPI。 - C 正确（不选）：EVM 高度依赖初始估算（PV 值）的准确性，估算不准则所有偏差指标都会失真。 - D 正确（不选）：EVM 可以适应需求变更，如燃尽图（Burndown Chart）就是 EVM 简单实现在敏捷/变更频繁场景中的变形。
知识点出处：
软件质量与管理.第四讲.pdfSlide 约 30-35（挣值管理 EVM）。EVM 是项目管理工具，质量管理在第五讲。参考资料：
assets/other/要背的-蔡之恒.pdf第 7-8 页第 19 条。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q11 中出现。
四、质量管理指标（Q12–Q17）¶
（12）关于PSP质量管理策略，下列说法中正确的是¶
A. 用缺陷管理替代质量管理，既有必要性，也有合理性 B. 基本无缺陷的开发是通过开展高质量的评审来实现的 C. 经过训练，评审是所有消除缺陷的手段当中最高效的 D. PSP质量策略主要解决的是外部质量，而非内部质量
点击查看答案与解析
答案：A、B
题目解析： - A 正确：
final-recite.md8.3 节——PSP 核心思想："用缺陷管理替代抽象的质量管理"。质量概念抽象难以直接度量，缺陷具体可计数，可作代理指标。 - B 正确：final-recite.md8.3 节——"尽早通过高质量评审消除缺陷"。PSP 追求基本无缺陷的开发，靠的是评审而非依赖后期测试。 - C 错：final-recite.md8.3 节仅说"代码评审/设计评审通常比后期测试更高效"，没有说评审比编译更高效。编译自动检出语法/类型错误几乎零成本，PSP 流程也是"评审 → 编译 → 测试"的顺序。评审比测试高效 ≠ 评审是所有手段中最高效。 - D 错：final-recite.md8.3 节——PSP 用缺陷管理替代质量管理。缺陷、PQI、DRL、Yield、Review Rate 全部是内部过程度量指标，不是外部质量属性。final-recite.md8.2 节引《代码大全》区分外部质量与内部质量——PSP 直接解决的是内部质量，外部质量是间接效果。"主要解决外部质量"不符合 PSP 的实际工作内容。知识点出处：
final-recite.md8.2 节（用户质量观）、8.3 节（质量管理策略和背后逻辑）。
（13）关于DRL，下列说法中不正确的是¶
A. 这是一种模块级开发中质量控制的指标 B. DRL以单元测试每小时发现缺陷率作为基准，考察上游其他缺陷消除阶段的消除效率 C. DRL以单元测试发现的缺陷个数作为基准，考察上游其他缺陷消除阶段消除缺陷的效率 D. DRL只能预测，不能度量
点击查看答案与解析
答案：C、D
题目解析： - A 正确：DRL（Defect Removal Leverage，缺陷消除效率比）是模块级（而非项目级）开发中用于质量控制的指标。 - B 正确：DRL = 某阶段每小时发现缺陷数 / 单元测试每小时发现缺陷数。以单元测试每小时缺陷发现率（而非缺陷个数）作为基准。 - C 不正确：DRL 的基准是"每小时发现缺陷率"，不是"缺陷个数"。用个数做基准无法消除规模差异的影响。 - D 不正确：DRL 是度量指标（可直接计算当前值），也可用于预测，不能说"只能预测不能度量"。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 18-20（DRL 缺陷消除效率比）。参考资料：
assets/other/要背的-蔡之恒.pdf第 11 页第 20 条 —— DRL 计算公式与含义。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q13 中出现。
（14）关于PQI，下列说法中不正确的是¶
A. PQI表征模块级别开发中的过程规范化程度 B. PQI越高越好，可以充分保障质量 C. PQI越低越好 D. PQI不能用作质量规划
点击查看答案与解析
答案：B、C、D
题目解析： - A 正确：PQI（Process Quality Index，过程质量指标）表征模块级别开发中的过程规范化程度。 - B 不正确：PQI 越接近 1 越好（并非"越高越好"），五个分指标有各自上限（不能超过 1.0）；且 PQI 是一种指标而非质量保障手段，"可以充分保障质量"说法不准确。PQI 的期望值是 0.4，超过 0.4 即可认为质量较高。 - C 不正确：PQI 越低越差，反映过程规范化程度越低。 - D 不正确：PQI 可以用作质量规划，指导质量计划活动，也可提供过程改进依据。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 15-18（PQI 过程质量指标）。参考资料：
assets/other/要背的-蔡之恒.pdf第 10 页第 20 条 —— PQI 五个分指标及期望值 0.4。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q14 中出现。
（15）关于PQI，下列说法中正确的是¶
A. PQI可以辅助判断模块开发质量 B. PQI可以提供过程改进的依据 C. PQI确保大于1，从而确保开发质量 D. PQI只能预测，不能度量
点击查看答案与解析
答案：A、B
题目解析： - A、B 正确：PQI 可辅助判断模块开发质量、提供过程改进依据。 - C 不正确：PQI 的每个分项值 ≤ 1（如设计时间 > 编码时间 → 该项 > 1 则取 1），整体 PQI ≤ 1，不可能"大于 1"。 - D 不正确：PQI 既是可度量的指标（可直接计算），也可用于预测，不能说"只能预测不能度量"。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 15-18（PQI）。参考资料：
assets/other/SQM非敏捷终版笔记.pdf—— "PQI 可以预测和度量，可以指导质量计划"。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q15 中出现。
（16）关于Yield，下列说法中正确的是¶
A. Yield可以辅助判断模块开发质量 B. Yield可以提供过程改进的依据 C. Yield区分为Process Yield和Phase Yield D. Yield只能预测，不能度量
点击查看答案与解析
答案：A、B、C
题目解析： - C 正确：Yield 分为 Phase Yield（某阶段消除缺陷的比例，以该阶段注入+进入的缺陷为分母）和 Process Yield（过程整体消除缺陷的比例，以第一次编译前注入的缺陷为分母）。 - D 不正确：Yield 既是度量指标（可计算当前值），也可用于构建预测模型。但因为无法得知具体注入的缺陷数目，Yield 只能根据已有的缺陷密度估算缺陷注入数，所以 Yield 本质上属于估计度量，不能精确度量。
Yield 体现缺陷消除的效率问题：上游的问题可以引发更多的问题；不能确定单元测试后是否还有错误（不可知）。IBM 经验法则："最后的测试如果发现了一个错误，那么其中一定还有一个错误没有被发现。"
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 13-15（Yield 缺陷消除率）。参考资料：
assets/other/要背的-蔡之恒.pdf第 9 页第 20 条 —— Yield 计算公式；assets/other/SQM非敏捷终版笔记.pdf—— Yield 只能估算不可精确度量。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q16 中出现。
（17）关于评审速度，下列说法中正确的是¶
A. 进行代码评审的时候，控制评审速度不超过每小时1000LOC就能实现大部分质量要求 B. 实战中，评审速度应该根据资源水平而定，时间充分就评审慢一些 C. 文档评审速度应该控制每小时不超过4页 D. 评审速度与人的技能有关，技能强的人可以突破每小时1000 LOC代码这个限制
点击查看答案与解析
答案：C
题目解析： - A 错：代码评审速度应控制在不超过 200 LOC/小时，不是 1000 LOC/h。1000 LOC/h 过快，无法有效发现缺陷。 - B 错：评审速度有明确的标准上限（代码 ≤200 LOC/h，文档 ≤4 页/h），不应随意根据资源水平调整。评审太快无法有效发现缺陷，评审太慢效率低下。 - C 正确：文档评审速度应控制在每小时不超过 4 页。 - D 错：评审速度限制与个人技能无关，是认知处理能力的上限——人类大脑处理代码和文档的速率有生理性限制，与技能高低无关。技能强的人也不能突破这一生理上限。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 20-22（评审速度 Review Rate）。参考资料：
assets/other/要背的-蔡之恒.pdf第 10 页第 20 条 —— "代码评审速度小于 200 LOC/小时，文档评审速度小于 4 Page/小时"。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q17 中出现。
五、Quality Journey 与设计（Q18–Q23）¶
（18）关于Humphrey 梳理的Quality Journey，下列说法中正确的是¶
A. Quality Journey中列出的步骤可以在适当的时候更换顺序 B. 由于需求是一切工程活动的基础，因此加强需求开发应该是Quality Journey早期的必备步骤 C. Quality Journey仍然仅仅是在"用缺陷管理替代质量管理"这一基本策略之下进行讨论 D. Quality Journey中测试应该先于评审得到贯彻和改善
点击查看答案与解析
答案：D
题目解析： - A 错：Quality Journey 的各步骤有严格顺序，每一步建立在前一步的基础上，不可随意更换。 - B 错：Quality Journey 的早期必备步骤是稳定各种形式的测试，而非加强需求开发。需求开发不在 Quality Journey 的八步中。 - C 错：Quality Journey 后期走向用户质量观，超越了"用缺陷管理替代质量管理"的范畴，将质量视角从缺陷扩展到更全面的用户质量属性。 - D 正确：在 Quality Journey 的八步顺序中，测试（第 1 步：稳定各种形式的测试）先于评审（第 3 步：度量并稳定团队评审）得到贯彻和改善。
Quality Journey 完整顺序（不可更改）： 1. 各种测试 → 2. 进入测试之前的产物质量提升 → 3. 评审过程度量和稳定（团队评审） → 4. 质量意识和主人翁态度 → 5. 个体 review 的度量和稳定 → 6. 诉诸设计 → 7. 缺陷预防 → 8. 用户质量观（其他质量属性）
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 25-28（Quality Journey）。参考资料：
assets/other/SQM非敏捷终版笔记.pdf第 4.6 节 —— Quality Journey 完整八步及哲学解释；assets/other/要背的-蔡之恒.pdf第 11 页第 21 条。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q18、2023 年试卷 Q13 中出现。
（19）下述设计模板中用来记录内部动态信息的是¶
A. OST B. SST C. LST D. FST
点击查看答案与解析
答案：B（SST）
题目解析：PSP 四大设计模板及其职责： - OST（Operational Specification Template，操作规格模板）：描述系统与外部交互的场景和行为（正常和异常情况），可用来定义测试场景和用例。 - SST（State Specification Template，状态规格模板）：记录内部动态信息，精确定义程序所有的状态、状态转移以及伴随每次状态转换的动作。 - LST（Logic Specification Template，逻辑规格模板）：精确描述系统的内部静态逻辑和关键算法，建议用伪代码配合形式化符号描述。 - FST（Functional Specification Template，功能规格模板）：描述系统的对外接口、类结构和类之间的关系，属于静态信息描述。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 30-34（PSP 四大设计模板）。参考资料：
assets/other/要背的-蔡之恒.pdf第 11-12 页第 22 条 —— PSP 四大设计模板详解。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q19 中出现。
（20）下述关于PSP四大设计模板和UML典型设计图的描述中完全正确的是¶
A. OST在UML中没有对应的设计图 B. UML中的类结构以及类之间的关系，在PSP四大设计模板中无法体现 C. LST在UML中可以通过类图来体现 D. FST在UML中可以通过类图来体现
点击查看答案与解析
答案：B
题目解析（依据：
软件质量与管理.第五讲.pdfSlide 38 原文）： - A 错：Slide 38——「UML的用例图和时序图提供了与PSP中OST同样的信息」。OST 在 UML 中有对应设计图，即用例图（Use Case Diagram）和时序图（Sequence Diagram）。 - B 正确：Slide 38——「UML中的时序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP4个设计模板中没有对应的内容」。因此，类结构和类之间的关系在 PSP 四大设计模板中确实无法体现。 - C 错：Slide 38——「PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法」。LST（逻辑规格模板）在 UML 中没有任何对应的图示方法，不能通过类图体现。 - D 错：Slide 38——「UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容」。FST 描述的是方法的行为，而 UML 类图只记录方法型构（签名），不描述行为。因此 FST 的内容不能通过 UML 类图体现。⚠️ 关键辨析：FST 描述的是系统对外的接口（含方法行为），UML 类图只描述静态结构（类+方法签名），不包括方法行为。因此 D 是错误的，B 才是唯一正确的选项。2022 年试卷 Q20 答案也是 B。
知识点出处：
软件质量与管理.第五讲.pdfSlide 38（PSP 设计模板与 UML 的对应关系）。参考资料：
assets/other/要背的-蔡之恒.pdf第 11-12 页第 22 条 —— 设计模板与 UML 对照。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q20 中出现。
（21）一个完全正确的状态机应该满足¶
A. 没有死循环和陷阱 B. 状态转化条件满足正交性 C. 状态转化条件满足完整性 D. 状态转化条件满足独立性
点击查看答案与解析
答案：A、B、C
题目解析：一个完全正确的状态机需要同时满足形式正确性和业务正确性： - A 正确：没有死循环和陷阱（终止性），即状态机不能进入永远无法退出的状态循环。 - B 正确：状态转化条件满足正交性——对于任意状态，任意两个转换条件不能同时为真（避免非确定性触发）。 - C 正确：状态转化条件满足完整性——对于任意状态，所有可能的输入组合都应有对应的转换定义。 - D 错误："独立性"不是状态机验证的标准条件。正交性（不能同时为真）和完整性（所有输入都有对应转换）是状态机的两个核心属性。
除此之外，状态机还必须符合设计意图（业务正确性）。形式正确 ≠ 业务正确。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 35-37（状态机验证）。参考资料：
assets/other/要背的-蔡之恒.pdf第 12 页第 23 条 —— "正确的状态机应该是：完整、正交的"。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q21 中出现。
（22）下列关于各种设计验证手段的描述中正确的是¶
A. 执行表是唯一一种提供全面设计验证的手段 B. 跟踪表是唯一一种提供全面设计验证的手段 C. 受限于手工方式，都易于出错 D. 符号化执行验证不适合复杂的计算过程
点击查看答案与解析
答案：C
题目解析： - A、B 错：没有任何一种手段是"唯一"的全面设计验证手段。执行表（Execution Table）和跟踪表（Trace Table）各有适用范围。符号化执行验证很多时候往往是唯一提供全面验证的方式。 - C 正确：执行表、跟踪表等手工验证手段受限于手工方式，都易于出错（人为遗漏、计算失误等）。 - D 错：符号化执行验证适合复杂的计算过程（可通过符号推导验证复杂算法逻辑），但不适合复杂的逻辑（因为状态空间爆炸，分支组合过多）。选项 D 说"不适合复杂的计算过程"恰好说反了——正确的是"适合复杂计算，不适合复杂逻辑"。
⚠️ 辨析：符号化验证的优点：实施简单、可给出一般化的验证结果，通常用在验证复杂算法中；缺点：不适用于有复杂逻辑的场合，纯手工验证容易引入人为错误。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 37-40（设计验证手段：状态机验证、符号化执行验证、执行表、跟踪表、正确性检验）。参考资料：
assets/other/要背的-蔡之恒.pdf第 12 页第 23 条 —— 符号化执行验证"通常用在验证一些复杂算法中"、"不适用于有复杂逻辑的场合"。2022 年试卷 Q22 答案也是 C。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q22 中出现。
（23）关于使用程序正确性证明手段验证while-do循环设计的描述中，正确的是¶
A. 如果设计是正确的，那么应满足的条件之一是循环判断条件最后一定可以变为false B. 如果设计是正确的，那么应满足的条件之一是循环判断条件为真的时候，单独的循环结构执行结果与循环体再加一个循环结构，其执行结果一致 C. 如果设计是正确的，那么应满足的条件之一是循环判断条件为false的时候，循环体内所有变量不能被修改 D. 该方法并不能保证循环体算法实现设计意图
点击查看答案与解析
答案：A、B、C、D
题目解析：while-do 循环的正确性需满足三个形式条件： - A 正确：终止性——循环判断条件最后一定可以变为 false，否则循环不会结束（死循环）。 - B 正确：归纳性——循环体执行后保持某种不变式（invariant），即"循环条件为真时，单独的循环结构执行结果 = 循环体 + 再一个循环结构的执行结果"。 - C 正确：不变性——循环条件为 false 时循环体不执行，循环体内所有变量不能被修改。 - D 正确：程序正确性证明只能验证形式正确性（如终止、归纳、不变），无法保证算法实现了设计意图（业务正确性）。形式正确 ≠ 业务正确。
知识点出处：
软件质量与管理.第五讲.pdfSlide 约 40-42（程序正确性证明——while-do 循环验证）。参考资料：
assets/other/要背的-蔡之恒.pdf第 12-13 页第 23 条 —— 正确性检验三项标准问题。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q23 中出现。
六、团队工程开发（Q24–Q33）¶
（24）下面描述属于典型客户需求的是¶
A. 客户期望 B. 预算限制 C. 法律法规限制 D. 系统功能描述
点击查看答案与解析
答案：A、B、C
题目解析：客户需求描述的是客户的期望和问题，处于问题域（而非解决域）。典型客户需求包括： - A 正确：客户期望——客户希望软件达成的业务目标和效果。 - B 正确：预算限制——客户在财务上的约束。 - C 正确：法律法规限制——软件必须遵守的外部法规和合规要求。 - D 错误：系统功能描述属于产品需求（而非客户需求），是开发团队针对客户需求设计的解决方案，处于解决域。需求开发流程：获取客户需求 → 分析澄清 → 转化为产品需求 → 形成需求规格说明。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 2-5（需求开发与客户需求 vs 产品需求）；软件质量与管理.第四讲.pdf—— 需求开发过程。参考资料：
assets/other/SQM非敏捷终版笔记.pdf—— 客户需求与产品需求的区分。题目来源：本题在 2022Fall 课堂选择、2023 课堂选择、2022 年试卷 Q24、2023 年试卷 Q7 中出现。
（25）在团队设计活动中，应该注意设计标准，下列属于典型的设计标准应该约定的是¶
A. 命名规范 B. 接口标准 C. 出错或者异常处理信息 D. 设计表示方式
点击查看答案与解析
答案：A、B、C、D
题目解析：团队设计活动中需要约定设计标准以保证多人协作的一致性，典型的设计标准包括： - A 正确：命名规范——变量、函数、类等的命名约定。 - B 正确：接口标准——模块间接口的定义规范。 - C 正确：出错或异常处理信息——系统错误信息和异常处理的标准格式。 - D 正确：设计表示方式——设计文档的表达方式和模板。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 8-10（团队设计活动——设计标准）。参考资料：
assets/other/质量管理.pdf—— 团队设计标准约定。题目来源：本题在 2022Fall 课堂选择中出现。
（26）典型地，在团队设计活动中，应该注意哪些内容¶
A. 设计标准的应用 B. 复用的考虑 C. 可测试性支持 D. 可用性支持
点击查看答案与解析
答案：A、B、C、D
题目解析：团队设计活动需要考虑的典型内容： - A 正确：设计标准的应用——确保团队遵循统一的设计规范。 - B 正确：复用的考虑——设计时考虑现有组件和模块的复用。 - C 正确：可测试性支持——设计时考虑如何方便后续的单元测试和集成测试。 - D 正确：可用性支持——设计时考虑终端用户的易用性。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 8-10（团队设计活动）。参考资料：
assets/other/质量管理.pdf—— 团队设计额外关注内容。题目来源：本题在 2022Fall 课堂选择中出现。
（27）关于集成策略，下述描述中正确的是¶
A. 当待集成组件质量普遍不高的时候，不可以使用扁平化策略 B. 当需要尽早获取可以工作的组件的时候，应该使用集簇式策略 C. 当待集成组件质量普通较高的时候，可以使用大爆炸式集成策略 D. 持续集成本质上就是逐一添加策略
点击查看答案与解析
答案：B、C、D
题目解析：四种集成策略的使用场景和特点： - A 错：扁平化策略的核心限制是需要大量打桩（Stub），而非组件质量。质量高低不是扁平化的适用条件——质量低时真正不适合的是大爆炸策略（定位困难）。扁平化优先集成高层部件构建骨架系统，与组件质量无关。 - B 正确：集簇式策略按功能簇分组集成，有助于尽早获取可工作的组件。 - C 正确：当组件质量普遍较高时，大爆炸式集成简单直接、风险可控。 - D 正确：持续集成（CI）本质上就是逐一添加策略——每次集成一个或少量的变更，持续验证。
四种集成策略：大爆炸集成（需高质量） → 逐一添加集成（需自动化测试，CI 本质） → 集簇集成（可早获工作组件，无系统整体观） → 扁平化集成（可早发现系统缺陷，需大量打桩）
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 12-16（集成策略）。参考资料：
assets/other/要背的-蔡之恒.pdf第 13 页第 24 条 —— 四种集成策略；assets/other/质量管理.pdf—— 集成策略特点与选择。题目来源：本题在 2022Fall 课堂选择、2022 年试卷 Q25 中出现。
（28）当考虑集成策略的时候，应该注意如下哪些方面？¶
A. 待集成组件的质量状态 B. 待集成组件的获取方式 C. 待集成组件的功能和关系 D. 待集成组件的数量
点击查看答案与解析
答案：A、B、C、D
题目解析：集成策略选择需综合考虑以下因素： - A：组件质量状态——质量高可大爆炸，质量低需用逐一添加。 - B：组件获取方式——自研组件与第三方组件的集成方式不同。 - C：组件功能和关系——相互依赖的组件应优先集成。 - D：组件数量——数量多时应分批集成，而非一次性大爆炸。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 12-16（集成策略选择因素）。参考资料：
assets/other/质量管理.pdf—— 集成策略选择考虑因素。题目来源：本题在 2022Fall 课堂选择中出现。
（29）关于扁平化集成策略和集簇式集成策略，下述说法中正确的是¶
A. 扁平化策略可以较早地充分地暴露系统级别的错误 B. 扁平化策略对于系统级别错误的暴露能力有限 C. 集簇式集成策略有助于复用策略的实现 D. 扁平化策略和集簇式策略的优缺点正好相反
点击查看答案与解析
答案：B
题目解析： - A 错：集成策略材料——扁平化"可以尽早发现系统层面的缺陷"，但"不能覆盖整个系统应该处理的多种状态"。能发现 ≠ "充分地"发现，A 夸大了。 - B 正确：扁平化需要大量打桩，不能覆盖系统所有状态，对系统级错误的暴露能力确实有限。 - C 无出处：集簇集成策略的优点在材料中明确为"可以尽早获得一些可以工作的组件，有利于其他组件测试工作的开展"，未提及"复用策略的实现"。 - D 错：两者关注维度不同（扁平化聚焦系统整体架构，集簇聚焦功能簇和可工作组件），各有独立优缺点，谈不上"正好相反"。
⚠️ 辨析：扁平化与集簇不是互逆的对立策略，而是在"系统整体 vs 组件簇"两个维度上各有取舍。扁平化的核心优势是早发现系统缺陷（代价：打桩），集簇的核心优势是早获取可工作组件（代价：缺乏系统整体观）。两者互补而非相反。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 14-16（课堂练习 6——集成策略对比）。
（30）下述活动是典型的验证（Verification）的是¶
A. 需求评审 B. 详细设计评审 C. 单元测试 D. 试运行
点击查看答案与解析
答案：B、C
题目解析： - 验证（Verification）：确保工作产品与事先指定给该工作产品的需求一致（"Are we building the product right?"）。验证要求存在一个前置的正式规格作为参照。 - 确认（Validation）：确保开发完成的产品在目标环境中工作正确，满足用户需求（"Are we building the right product?"）。 - A 错（需求评审）：需求文档是开发活动的第一份正式规格，之前不存在可参照的正式前置文档。需求评审检查的是需求是否真正反映用户需要——这是确认（Validation），不是验证。 - B 正确：详细设计评审——以需求文档为前置规格，检查设计是否与需求一致 → 验证。 - C 正确：单元测试——以设计/代码规格为前置参照，检查代码是否与规格一致 → 验证。 - D 错：试运行——在目标环境中检验产品是否满足用户需求 → 确认（Validation）。
⚠️ 辨析：验证 = 有前置规格可对照；确认 = 以用户需求/目标环境为最终标准。需求评审没有前置规格，属于确认而非验证。
（31）下述活动是典型的确认（Validation）的是¶
A. 验收测试 B. 代码评审 C. 系统测试 D. 持续集成
点击查看答案与解析
答案：A
题目解析： - 确认（Validation）：确认最终产品是否满足用户真实需求和使用意图，回答"是否构建了正确的产品"。关键特征：无前置正式规格可对照，以用户需求/目标环境为最终检验标准。 - A 正确：验收测试——客户/用户在目标环境中检验产品是否满足业务需求，属于确认。 - B 错：代码评审——以设计规格为前置参照，检查代码是否与规格一致 → 验证（Verification）。 - C 错：系统测试——开发团队在测试环境中对照需求规格说明书执行，有前置正式规格可对照 → 属于验证，不是确认。 - D 错：持续集成——属于集成策略，不是 V&V 活动。
⚠️ 辨析：系统测试 ≠ 确认。系统测试对照的是需求规格（一份正式文档），不是用户真实使用场景。只有验收测试（客户参与、目标环境）才算确认。这和 Q30 中需求评审的判断逻辑一致——无前置规格对照的才是确认。
（32）下述产物中属于典型的确认（Validation）对象的是¶
A. 接口设计文档 B. 源代码 C. 用户手册 D. 系统使用培训材料（视频、录像等）
点击查看答案与解析
答案：C、D
题目解析： - 确认对象关注最终用户使用相关的产物，即用户直接接触的内容： - C 正确：用户手册——最终用户直接使用，需要确认其准确性和可用性。 - D 正确：系统使用培训材料——最终用户直接使用，需要确认其是否准确反映系统功能。 - 验证对象关注开发过程产物，即开发团队内部产物： - A 错误：接口设计文档——属于验证对象，检查是否与需求一致。 - B 错误：源代码——属于验证对象，检查是否与设计一致。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 18-20（课堂练习 9——验证对象 vs 确认对象）。题目来源：本题在 2022Fall 课堂选择中出现。
（33）下述关于需求开发的描述中，哪些是正确的？¶
A. 客户需求是指客户提出的关于软件功能的具体要求 B. 工期或者预算往往都是客户需求的一个方面 C. 产品需求需要跟客户充分讨论才能获取 D. 客户应该在需求开发活动中起到主导作用
点击查看答案与解析
答案：B、C
题目解析： - A 不正确：客户需求不限于具体功能要求，还包括期望、约束（预算、工期、法规）等。客户需求描述的是客户业务目标、问题和使用场景。 - B 正确：工期/预算属于客户需求的一个方面——客户除了功能期望外，还有资源约束。 - C 正确：产品需求（开发团队的解决方案）需要与客户充分讨论才能获取，以确保解决方案确实满足客户需求。 - D 不正确：需求开发过程（获取→汇总→验证→文档制作）由开发团队管理，客户提供需求输入，双方协作协商（2016 年卷原文："需要开发团队与客户一起交流协商"）。客户提供需求来源，但不是单方面"主导"——需求分析、澄清、转化、文档化均由团队完成。
知识点出处：
软件质量与管理.第六讲.pdfSlide 约 2-5（课堂练习 10——需求开发）。参考资料：
assets/other/SQM非敏捷终版笔记.pdf—— 需求开发完整过程与客户/产品需求区分。题目来源：本题在 2022Fall 课堂选择中出现。
七、项目支持活动（Q34–Q37）¶
（34）下述产物中属于典型的配置项是¶
A. 接口设计文档 B. 源代码 C. 用户手册 D. 系统使用培训材料（视频、录像等）
点击查看答案与解析
答案：A、B、C、D
题目解析：配置项（Configuration Item）是指所有需要受配置管理控制的工作产品。配置管理的目的是建立与维护工作产品的完整性。典型配置项包括： - A 正确：接口设计文档——需要版本控制，一旦变更影响多个模块。 - B 正确：源代码——最核心的配置项，需严格版本控制。 - C 正确：用户手册——与软件版本配套，需要配置管理。 - D 正确：系统使用培训材料——属于交付产物的一部分，需要配置管理以确保与软件版本一致。
知识点出处：
软件质量与管理.第七讲.pdfSlide 约 5-8（课堂练习 1——配置管理）。参考资料：
assets/other/要背的-蔡之恒.pdf第 13 页第 26 条 —— 配置管理目的和活动。题目来源：本题在 2022Fall 课堂选择中出现。
（35）团队内部的配置审计通常应该关注什么¶
A. 物理审计 B. 配置项列表 C. 配置管理记录 D. 基线计划
点击查看答案与解析
答案：A、B、C、D
题目解析：配置审计关注的内容包括： - A 正确：物理审计——检查实际的配置项是否与记录一致。 - B 正确：配置项列表——检查配置项的完整性。 - C 正确：配置管理记录——检查变更记录、版本记录是否完整规范。 - D 正确：基线计划——检查基线是否按计划建立和维护。
知识点出处：
软件质量与管理.第七讲.pdfSlide 约 5-8（课堂练习 2——配置审计）。题目来源：本题在 2022Fall 课堂选择中出现。
（36）下列关于决策分析的论述中，不恰当的是¶
A. 决策分析指南中最关键的是明确需要开展决策分析活动的判定标准 B. 评价方法是体现决策者利益诉求的关键，因此，需要谨慎设计 C. 候选方案的识别应该晚于评价标准 D. 现实生活中的项目投标就是一个典型的决策分析活动
点击查看答案与解析
答案：B、D
题目解析： - A 正确：决策分析指南中最关键的是明确"什么场合之下需要开展正式的决策分析活动"的判定标准——不是每个决策都需要正式 DAR。 - B 不恰当：评价方法/标准应当客观，服务于项目和组织目标，而非体现决策者个人的"利益诉求"。将评价方法设计为迎合某方利益会引入偏见，损害决策质量。 - C 正确：候选方案应在评价标准之后识别。先确定评价标准（知道"什么是好的"），再有方向地识别候选方案，避免盲目收集。 - D 不恰当：项目投标是采购活动，候选人来自外部，受招投标法规约束，与软件过程管理中内部化的正式决策分析（DAR——如技术选型、架构决策、自制/外购决策）有本质区别。将其视为"典型的决策分析活动"混淆了采购和 DAR。
（37）下列关于根因分析的论述中，不恰当的是¶
A. 根因分析必须基于丰富的数据来选择合适的问题 B. 鱼骨图是根因分析的有效手段 C. 典型地，可以从技术、人员、培训以及过程角度开展根因分析 D. 根因分析活动终止的唯一特征就是找到相应的根因的明确解决方案
点击查看答案与解析
答案：A、D
题目解析： - A 不恰当：问题选定在数据收集之前——先根据影响程度、紧急性和优先级识别和选定问题，然后针对该问题收集数据进行分析。数据服务于根因分析阶段，不是问题选择的前提。"必须基于丰富的数据来选择合适的问题"颠倒了顺序。 - B 正确：鱼骨图（因果图）是根因分析的经典工具，帮助从技术、人员、培训、过程等多维度梳理可能的原因。 - C 正确：根因分析的典型角度包括技术、人员、培训、过程四个维度。 - D 不恰当：根因分析找到根本原因和解决方案后，还要实施改进并评估效果，活动才算完成。正式流程包含：①识别和选定问题 → ②根因分析 → ③建立改进的行动方案 → ④实施改进，评估效果。找到方案不是终点。
知识点速查表¶
| 题号 | 主题 | 关键知识点 | 课件出处 |
|---|---|---|---|
| 1 | 软件发展阶段 | Measure twice, cut once = 代码评审 | 第二讲 |
| 2 | 软件三阶段 | 软硬件一体化 / 独立产品 / 网络化和服务化 | 第二讲 |
| 3 | 本质困难 | 复杂性、不可见性、可变性、一致性（质量不是） | 第二讲 Slide 2 |
| 4 | 阶段实践 | 一体化→Code and Fix / 独立→瀑布 / 网络化→敏捷 | 第二讲 |
| 5 | TSP vs Scrum | 都是计划驱动，都适合迭代式场景 | 第三讲 |
| 6 | Y理论 | 自我约束、自我导向、渴望承担责任 | 第三讲 Slide 15-16 |
| 7 | 马斯洛 | 自我实现≠自尊；高层次满足途径更广（非更少） | 第三讲 Slide 7-8 |
| 8 | 团队动力学 | 马斯洛≠激励维持手段，而是激励选择指导 | 第三讲 Slide 13-16 |
| 9 | EVM | 中级无成本，高级有成本 | 第四讲 |
| 10 | WBS | 不一定对应 OBS；同层应一致标准（100%规则） | 第四讲 Slide 24-28 |
| 11 | EVM | 中级实现不引入成本信息 | 第四讲 |
| 12 | PSP 策略 | 缺陷管理替代质量管理；评审比测试高效（非"最高效"）；PSP 直接解决内部质量 | 第五讲 |
| 13 | DRL | 以单元测试每小时发现缺陷率为基准（非缺陷个数） | 第五讲 |
| 14-15 | PQI | 五因子乘积，越接近 1 越好，不能超 1.0，期望值 0.4 | 第五讲 |
| 16 | Yield | Phase Yield / Process Yield；估计度量不可精确 | 第五讲 |
| 17 | 评审速度 | 代码≤200 LOC/h，文档≤4 页/h；认知上限与技能无关 | 第五讲 |
| 18 | Quality Journey | 测试先于评审；八步顺序不可更改；后期走向用户质量观 | 第五讲 |
| 19 | 设计模板 | SST = 内部动态信息 | 第五讲 |
| 20 | PSP vs UML | 类结构和关系在PSP模板中无法体现（非FST）；FST=方法行为≠类图 | 第五讲 Slide 38 |
| 21 | 状态机 | 无死循环+完整性+正交性（独立性不是） | 第五讲 |
| 22 | 设计验证 | 手工方式易出错；符号化验证适合复杂计算、不适合复杂逻辑 | 第五讲 |
| 23 | while-do | 终止性+归纳+不变性；形式正确≠业务正确 | 第五讲 |
| 24 | 客户需求 | 期望、预算、法律限制（系统功能描述属于产品需求） | 第六讲 / 第四讲 |
| 25-26 | 团队设计 | 设计标准、复用、可测试性、可用性 | 第六讲 |
| 27-29 | 集成策略 | 四种策略；扁平化可早发现系统缺陷但不充分；集簇未提复用；两者非相反 | 第六讲 |
| 30-32 | V&V | 验证需前置规格对照；需求评审无前置规格→属确认；设计评审/单元测试→验证 | 第六讲 |
| 33 | 需求开发 | 客户主导、工期预算属客户需求 | 第六讲 |
| 34-35 | 配置管理 | 配置项范围、审计关注点 | 第七讲 |
| 36 | 决策分析 | 候选方案不应晚于评价标准 | 第七讲 |
| 37 | 根因分析 | 找到方案≠终止，还需实施改进并评估效果 | 第七讲 |