期末复习

软件工程基础、软件危机与过程管理

PPT 对应位置

  • PPT/软件质量与管理.第一讲.pdf、往年整理和往年卷/ppt/软件质量与管理.第一讲.pptx：软件危机、四大本质困难、生命周期模型、软件过程管理/改进模型。
  • PPT/软件质量与管理.第二讲.pptx：本质难题、软件发展三大阶段、瀑布、CMMI、敏捷与 DevOps 的历史位置。
  • PPT/课程总结.pptx：过程线。

考法

  • 判断改错：区分软件项目管理、软件过程管理、过程改进、生命周期模型、开发过程。
  • 简答：解释软件发展的三大阶段；解释生命周期模型与软件过程的区别；解释 CMMI 为什么不是敏捷的对立面。
  • 选择：四大本质困难、三大阶段、典型实践、Measure twice, cut once 对应场景。

应掌握知识点

  • 软件危机：落后的软件生产方式无法满足增长的软件需求，导致开发和维护中出现严重问题。
  • 四大本质困难：复杂性、不可见性、可变性、一致性；其中不可见性最“本质”，其他三者因项目而异，并相互促进。
  • 软件工程两大视角：管理视角问“能否复制成功”，技术视角问“能否把问题解决得更好”。
  • 管理三要素：目标、状态、纠偏。
  • 软件项目管理：用方法、工具、技术和人员能力完成项目目标，典型目标是成本、质量、工期。
  • 软件过程：为实现目标建立的一组有顺序的实践集合；广义软件过程包含技术、人员、狭义过程。
  • 生命周期模型：对软件过程的人为、粗粒度划分，不包含具体技术实践；瀑布、迭代、增量、螺旋、原型法都属于生命周期模型。
  • 软件过程管理与过程改进：过程管理/改进关注组织长期过程能力。CMM/CMMI、SPICE 是过程管理/改进参考模型；PDCA、IDEAL 是过程改进参考元模型。
  • CMMI 五级：Initial 初始、Managed 已管理、Defined 已定义、Quantitatively Managed 定量管理、Optimizing 优化。1-3 主要管理当前状态，4-5 用模型和统计方法预测、控制和优化未来结果。
  • PDCA：Plan、Do、Check、Act；IDEAL：Initiating、Diagnosing、Establishing、Acting、Leveraging。

往年考过的原题

  • 【2018】软件发展三大阶段的特点和主流开发方法。
  • 【2020】请结合软件发展的三大阶段，描述不同阶段的典型软件开发方法和实践。
  • 【2018】软件项目管理和软件过程管理。
  • 【2018、2020】生命周期模型与软件过程的区别和联系。
  • 【2020】我们如何理解瀑布模型。
  • 【2020、2023】请描述 CMMI 模型的 5 个等级的特征，并解释为何 CMMI 模型不应该是敏捷方法的对立面。
  • 【2015、2016】请分别描述 PDCA 模型和 IDEAL 模型的主要步骤。
  • 选择题：“Measure twice, cut once”描述的是哪个软件开发场景；不属于软件发展三大阶段的是哪一项；不属于软件开发本质困难的是哪一项。

软件过程历史演变、敏捷与 DevOps

PPT 对应位置

  • PPT/软件质量与管理.第二讲.pptx：三大阶段、网络化服务化、敏捷、XP、Scrum、Kanban、DevOps。
  • PPT/8敏捷概述.pptx：敏捷宣言、敏捷知识体系、精益创业、DevOps。
  • PPT/9新方法学.pptx：需求不可预见性、适应性过程、敏捷对变化的处理。
  • 往年整理和往年卷/ppt/7DevOps.pptx：DevOps 定义、CI/CD、监控、反馈、DevSecOps。

考法

  • 简答：完整描述敏捷宣言；解释敏捷方法的特征；说明为什么“轻量级、非计划驱动、拥抱变更”等说法容易误导。
  • 简答：DevOps 三步、特点、为什么流行、列举实践。
  • 判断：敏捷不是不要计划，不是没有规范，不是无条件接受变更。

应掌握知识点

  • 软件发展三大阶段：
    • 软硬件一体化：功能单一、复杂度有限、几乎无需求变更；典型实践是线性顺序过程、Measure twice, cut once、Code and Fix。
    • 软件成为独立产品：需求多变、兼容性要求、市场压力；典型方法是形式化方法、结构化程序设计、瀑布模型、成熟度模型。
    • 网络化和服务化：规模更大、用户更多、需求快速演化、SaaS/开源/共享；典型方法是迭代式、敏捷、XP、Scrum、Kanban、开源、DevOps。
  • 敏捷出现的原因：软件开发的复杂性和可变性无法靠充分前期计划完全消除风险，因此需要快速反馈、短周期交付和适应性过程。
  • 敏捷宣言四条：个体和互动胜过流程和工具；可以工作的软件胜过详尽的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。注意“右项有价值，只是更重视左项”。
  • 敏捷特征：小周期迭代、快速响应变更、价值交付、自动化。
  • 常见误解：
    • “轻量级”不等于不严格，XP 等敏捷工程实践非常严格。
    • “拥抱变更”不是不管理变更；所有工程方法都要限制和管理变更。
    • “非计划驱动”不准确，正式项目都需要计划，敏捷只是计划周期和反馈机制不同。
    • TDD 提升质量不能简单绝对化，PPT/往年题强调没有足够证据支持“必然更高质量”。
  • DevOps：把敏捷扩展到交付和运维全生命周期，以自动化、CI/CD、监控反馈和协作文化缩短从代码提交到生产的时间，同时保证质量。
  • DevOps 三步：开发到运维从左到右快速流动；从右到左建立持续快速反馈；建立支持实验和高可信度的文化。
  • DevOps 典型实践：CI/CD、自动化测试、监控与可观察性、基础设施即代码、容器/虚拟化、微服务、无责沟通、从事件中学习、早期安全。

往年考过的原题

  • 【2020、2023】请完整描述敏捷宣言；敏捷宣言有哪些内容，如何正确理解？
  • 【2015B、2016】结合 Scrum 论述敏捷方法应具备的特征，并解释为什么“严格、重型、计划驱动”等作为敏捷对立面不合适。
  • 【2015A】敏捷方法的特征有哪些？哪些关于敏捷特征的说法不合适，为什么？
  • 【2014】为何把“规范方法”“计划驱动方法”作为敏捷对立面有误导性？
  • 【2016】DevOps 三个步骤。
  • 【2021】解释至少 5 个 DevOps 技术、实践、方法。

Scrum

PPT 对应位置

  • PPT/1Scrum.pdf：Scrum 定义、理论、33355、角色、事件、工件。
  • 软件质量与管理/Scrum.md：Scrum 理论、用户故事、DoD、BDD、Backlog。
  • PPT/软件质量与管理.第三讲.pptx：Scrum 与 TSP/Scrum Master 相关内容。

考法

  • 选择：Scrum 角色、工件、事件、价值观、理论支柱。
  • 简答：Scrum 为什么适合复杂需求；Scrum 与传统瀑布的区别；Scrum 团队特征。
  • 应用题：用户故事、验收标准、DoD、Backlog 的作用。

应掌握知识点

  • Scrum 不是具体构建产品的技术过程，而是用于复杂产品开发的轻量框架，可以容纳各种流程和技术。
  • Scrum 理论基础：经验主义和精益思维；三大支柱是透明、检视、适应。
  • Scrum 33355：
    • 3 个角色：Product Owner、Scrum Master、Developers。
    • 3 个工件：Product Backlog、Sprint Backlog、Increment。
    • 5 个事件：Sprint、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective。
    • 5 个价值观：承诺、专注、开放、尊重、勇气。
  • Scrum Team：通常 10 人以内，自管理、跨职能、无子团队或层级结构，专注单一 Product Goal。
  • Product Owner：最大化产品价值，管理 Product Backlog，负责排序、透明、清晰和最终责任；PO 是一个人，不是委员会。
  • Scrum Master：服务型领导，帮助团队和组织理解并实施 Scrum，移除障碍，保证事件积极有效且在时间盒内完成。
  • Developers：负责创建 Sprint Backlog，遵循 DoD 注入质量，每天围绕 Sprint Goal 调整计划。
  • Sprint 内需求：Sprint Goal 和质量目标不可随意改变；新的需求变化可记录到 Product Backlog，通常不打断当前 Sprint 承诺。
  • 用户故事：作为<用户>，我想<功能>，从而<价值>；3C 是 Card、Conversation、Confirmation；INVEST 是独立、可协商、有价值、可估算/短小、可测试。
  • DoD：团队对“完成”的统一标准，提升透明度、保证质量、防止技术债，是验收增量的重要依据。

往年考过的原题

  • 【2015B、2016】结合 Scrum 论述敏捷方法应具备的特征。
  • 课堂选择题：TSP 和 Scrum 都是过程框架，需要填补具体实践后才是可工作的过程；“一种计划驱动、一种敏捷”这种二分不恰当。
  • 课堂选择题：Scrum 适合迭代式场景，TSP 也可以适合；两者都需要度量数据收集和分析来支持管理决策。
  • 往年整理：Scrum 的 3 个角色、3 个工件、5 个活动、5 个价值观；产品负责人、开发团队、Scrum Master 职责。

XP、TDD、重构与持续集成

PPT 对应位置

  • PPT/XP-20260506/2xp背景变更曲线.revised.html：变更成本曲线、XP 如何压平曲线。
  • PPT/XP-20260506/3xp实践.revised.html：XP 价值观、四项活动、十二项实践。
  • PPT/XP-20260506/4xpTDDDesgin.revised.revised.html：TDD、演进式设计、YAGNI、重构。
  • PPT/XP-20260506/5xp持续集成.revised.html：持续集成实践、自测试构建、构建流水线。
  • PPT/XP-20260506/6XP_CC.revised.html：XP 与 AI 时代、CI/CD/持续部署区别。

考法

  • 简答：XP 如何压平变更成本曲线；为什么 XP 实践必须配套；TDD 红绿重构；持续集成核心实践。
  • 选择/判断：XP 价值观、十二实践、40 小时工作制、TDD 并不被绝对证明能提高质量。
  • 比较：XP 与 Scrum、Kanban 的定位差异。

应掌握知识点

  • 传统变更成本曲线：越晚发现需求/设计/代码问题，修复成本越高；瀑布强调早期锁定需求和设计。
  • XP 的核心：把开发阶段“写代码-测试-集成”这条最频繁路径升级，通过自动化测试、重构、CI、简单设计、结对等机制压平变更成本曲线。
  • XP 四大价值观：交流、简单、反馈、勇气；尊重是底座。
  • XP 四项基本活动：编码、测试、倾听、设计。
  • XP 十二实践：计划游戏、小发布、隐喻、简单设计、TDD、重构、结对编程、集体代码所有、持续集成、40 小时工作制、现场客户、编码标准。
  • XP 不是实践清单，而是一套互相支撑的系统：
    • 小发布依赖计划游戏、测试、持续集成、简单设计。
    • 集体拥有依赖测试、结对、CI、编码标准。
    • 重构依赖测试安全网和小步改动。
  • TDD：红-绿-重构。先写失败测试，最小实现让测试通过，再在测试保护下重构。
  • 简单设计：通过所有测试、消除重复、清晰表达意图、最小化类和方法；YAGNI 指不要为“未来可能需要”提前开发。
  • 重构纪律：不改变外部行为，只改善内部结构；没有测试兜底的“凭感觉重构”是破坏。
  • 持续集成：维护单一主线，自动化构建，自测试构建，每人每天向主线提交，每次主线提交触发构建，保持构建快速。
  • CI/CD/持续部署区别：
    • CI 关注频繁集成到主线并自动化验证。
    • 持续交付使任何主线版本处于可发布状态，发布仍可人工触发。
    • 持续部署将通过流水线的版本自动部署到生产环境。

往年考过的原题

  • 【2015B】XP 规定开发人员每周工作时间不超过多少小时，连续加班不超过两周？答案：40 小时。
  • 【2015A】关于敏捷特征的误导性说法：TDD 可以提供更高开发质量没有足够证据支持。
  • 往年题：XP 与 CMM/CMMI 是不是对立的两种软件开发方法？应从“XP 是开发方法，CMMI 是过程管理/改进模型”区分。
  • 课堂选择题：XP、Scrum、Kanban 是敏捷方法；TDD、CI、结对、重构是实践。

Kanban 与精益软件开发

PPT 对应位置

  • PPT/Kanban-20260518/6Kanban.pptx：Kanban 定义、历史、六大实践、看板/卡片、度量、与 Scrum/XP 融合。
  • PPT/Kanban-20260518/7精益软件开发_从丰田到硅谷的工程哲学.revised.html：JIT、自働化、消除浪费、价值流、拉动系统、PDCA。
  • 软件质量与管理/Kanban.md、软件质量与管理/精益软件开发.md：课堂笔记。

考法

  • 选择：Kanban 典型实践、不属于 Kanban 的实践；WIP、周期时间、产能等概念。
  • 简答：Kanban 六大实践；Kanban 与 Scrum、XP 的区别和互补；精益软件开发原则。
  • 应用：给一个流程判断瓶颈、WIP 限制和流动改进。

应掌握知识点

  • Kanban 定义：通过可视化、拉动式系统优化流程中价值流动的策略。
  • Kanban 三类核心活动：定义并可视化工作流程；主动管理工作流程中的事项；改进工作流程。
  • Kanban 六大实践：可视化、限制 WIP、管理流动、显式化策略、实施反馈循环、协同改进。
  • 定义工作流要说明：工作项是什么、从哪里开始到哪里结束、中间状态、WIP 限制、每个状态规则、服务水平期望 SLE。
  • Kanban 度量：
    • WIP：已开始未完成的工作项数。
    • 产能：单位时间完成工作项数。
    • 工作项存续时长：某工作项从开始到当前经过多久。
    • 周期时间：已完成工作项从开始处理到完成交付的总时长。
  • Kanban 与 Scrum：
    • Scrum 有 Sprint 时间盒、规定角色/工件/事件，适合新产品开发和结构化迭代。
    • Kanban 连续流动，无固定时间盒，按优先级拉取，更适合运维、持续交付、工单等流式工作。
    • Scrumban 是二者融合：保留部分 Scrum 节奏，引入拉动和 WIP 控制。
  • Kanban 与 XP：Kanban 管流程和流动；XP 管工程实践和代码质量；可以同时使用。
  • 精益核心：消除浪费、建立质量、延迟决策、快速交付、尊重人、全局优化；软件中库存对应 WIP，缺陷对应返工，停线可对应 CI 红灯即停。
  • JIT 与拉动：按下游需求触发上游工作，避免提前堆积和库存；软件中不要按团队容量盲目推任务，要按价值流和 WIP 拉取。

往年考过的原题

  • 【2020-mid】下列不属于看板方法典型实践的是？站立式会议、重构不是 Kanban 的核心实践；可视化工作流、限定 WIP 是。
  • 【2018】精益屋的两大支柱？
  • 【2018】JIT 及时生产，价值流和价值拉动的关系。
  • 课堂选择题：Kanban 与 Scrum 原则层面无矛盾，都以持续改进和自组织为核心，实践形式不同，应根据需求选择或组合。

团队动力学、TSP 与自主团队

PPT 对应位置

  • PPT/软件质量与管理.第三讲.pptx：团队动力学、马斯洛、麦克勒格、期望理论、TSP Launch、典型 TSP 角色、Scrum 对比。
  • 软件质量与管理/团队动力学.md：课堂笔记。
  • 往年整理和往年卷/质量管理.pdf：团队动力学、TSP/PSP、TSP Launch、角色职责。

考法

  • 简答：为什么软件项目管理需要自主团队；自主团队特点；知识工作领导者特点。
  • 选择：马斯洛、麦克勒格 X/Y、海兹伯格、期望理论、TSP 角色职责。
  • 应用：用期望理论解释为什么“构建高质量软件”不适合作为第一次会议的大目标；解释里程碑反馈的激励作用。

应掌握知识点

  • 软件开发是知识工作：处理抽象概念，把不可见的不同部分整合成正确系统，需要全身心参与和追求卓越。
  • 知识工作管理核心：知识工作者不能被一般意义上的管理者细节控制，只能学会自我管理。
  • 激励方式：威逼、利诱、鼓励承诺；威逼/利诱属于交易型领导，鼓励承诺属于转变型领导，更适合创造性团队。
  • 马斯洛：低层需求先于高层需求；自我实现是最高层；激励来自未满足需求。
  • 麦克勒格 X/Y：X 理论偏消极，适合底层需求激励；Y 理论偏积极，强调自我约束、自我导向、渴望承担责任，适合高层需求激励。
  • 海兹伯格：激励因素是内在因素，保健因素是外在因素。
  • 期望理论：M = V × E。目标价值高但成功期望低，激励仍会下降。
  • 自主团队特点：自行定义目标、决定团队组成和角色、决定开发策略、定义开发过程、制定计划、自行度量管理和控制工作。
  • TSP Launch：通过一系列会议建立产品/业务目标、角色、小组目标、开发流程、整体计划、质量计划、个人计划、风险评估、管理层汇报与总结。
  • 典型 TSP 角色：
    • 项目组长：激励、主持会议、分配任务、向管理层报告。
    • 计划经理：制定团队和个人计划、跟踪进度。
    • 开发经理：开发策略、需求/设计/实现/测试。
    • 质量经理：质量计划、评审组织、质量预警。
    • 过程经理：过程定义、数据记录、会议记录、过程改进。
    • 支持经理：工具环境、配置管理、风险问题跟踪、复用支持。

往年考过的原题

  • 【2013、2014、2015、2016、2020】结合软件开发特点介绍软件项目管理中自主型团队的必要性；自主团队有哪些特点？
  • 【2023】结合“软件开发作为一种知识工作，需要领导者而不是一般经理”，阐述知识工作领导者应具备的品质或特点。
  • 【2021】列出 TSP 角色并解释其中 5 个的职责。
  • 往年课堂讨论：第一次开会时，为什么“构建高质量软件”不是一个恰当计划？用期望理论解释。
  • 选择题：麦克勒格 Y 理论适用场合；马斯洛需求层次理论；团队动力学中鼓励承诺、保健因素/激励因素。

估算、PROBE、WBS、计划与跟踪

PPT 对应位置

  • PPT/软件质量与管理.第四讲.pptx：TSP/PSP、PROBE、WBS、开发策略、日程、EVM。
  • 软件质量与管理/估算、计划和追踪.md：估算、PROBE、WBS、计划、风险、EVM、总结。
  • 往年整理和往年卷/质量管理.pdf：通用计划框架、估算、WBS、EVM。

考法

  • 简答：通用计划框架；PROBE 基本原理和过程；为什么时间估算不能直接相信历史生产效率。
  • 计算/应用：PROBE A/B/C/D 数据质量要求；EVM 简单/中级/高级实现；PV/EV/AC/SV/SPI。
  • 选择：WBS、Schedule Plan 所需信息、EVM 局限。

应掌握知识点

  • 估算目的：给计划提供决策依据；估算对象包括规模、时间、日程。
  • 估算本质：不是追求“神准结果”，而是追求过程一致性、干系人共识和对结果的信心。
  • 规模估算比时间估算更值得依赖历史数据：规模偏差原因相对客观；时间偏差受人的主观能动性影响，可能受估算本身约束。
  • PROBE：Proxy Based Estimation，用代理对象连接早期规划可判断信息与后期精确度量。
  • PROBE 基本原理：设立合理代理；使用相对大小而非绝对大小；基于历史数据和回归调整估算。
  • PROBE 流程：概要设计；代理识别与代理规模估算；估算并调整程序规模；计算预测区间；估算并调整资源；计算预测区间。
  • PROBE A/B/C/D：
    • A：有 3 组以上代理规模与实际规模数据，且相关性、显著性、截距、斜率等满足质量要求。
    • B：有 3 组以上计划规模与实际规模数据，质量要求类似。
    • C：有历史数据但质量不足，按比例调整。
    • D：无历史数据，只能猜测。
  • 通用计划框架：定义需求 -> 概要设计 -> 规模估算 -> 资源估算 -> 日程计划 -> 开发产品 -> 数据收集 -> 过程分析/跟踪报告。重点是正向计划，不是从截止日期倒推。
  • WBS：以可交付成果为导向分解项目工作范围，是范围管理、估算和计划基础；最底层工作包应必要且充分、唯一、清晰、责任明确。
  • 任务计划 vs 日程计划：任务计划描述任务清单、顺序和资源；日程计划描述各任务在日历上的安排。
  • EVM：
    • 简单实现：建立 WBS，为每项工作定义 PV，用 0-100 或 50-50 规则生成 EV，不考虑 AC。
    • 中级实现：加入 SV = EV - PV、SPI = EV / PV。
    • 高级实现：加入成本线 AC 和预测线 BAC，分析成本和进度偏差。
  • EVM 局限：不适合质量管理，高度依赖估算准确，对探索型和需求频繁变化项目不友好。

往年考过的原题

  • 【2020】按通用计划框架，为开发合理项目计划，应做哪些估算？PROBE 方法充当什么角色？
  • 【2013、2015A、2018】谈谈你对项目估算的认识，并解释 PROBE 方法估算的优缺点。
  • 【2023】软件项目规模估算的基本要点有哪些？
  • 【2018、2020】描述 PROBE 方法的基本原理和过程，并解释估算时间时为什么不用历史数据中的生产效率数据。
  • 【2020】PROBE ABCD 方法在估算规模时对历史数据质量有什么要求？
  • 【2013、2014、2015A、2015B、2016】如何制定一份让人无法拒绝的计划？
  • 【2023】挣值管理简单、中级、高级三种实现方式的基本要点。
  • 选择题：WBS 哪些说法不正确；EVM 哪些说法不正确；制定 Schedule Plan 需要哪些信息。

PSP 质量管理与质量指标

PPT 对应位置

  • PPT/软件质量与管理.第五讲(1129)(1).pptx：质量概念、PSP 质量策略、评审、Yield、A/FR、PQI、Review Rate、DRL、Quality Journey。
  • 往年整理和往年卷/ppt/软件质量与管理.第五讲.pptx：质量管理同主题。
  • 往年整理和往年卷/软质管-简.pdf：PSP 质量观、质量策略、指标。

考法

  • 简答/计算：Yield、A/FR、PQI、Review Rate、DRL 定义、公式、用途。
  • 综合题：结合多个指标说明如何保证高质量。
  • 判断：Yield/DRL 能不能度量；PQI 是不是越高就充分保障质量；评审速度是否越慢越好。

应掌握知识点

  • 面向用户质量观：质量是满足用户需求的程度，要明确用户是谁、需求优先级是什么、如何度量。
  • PSP 质量策略：用缺陷管理替代质量管理；高质量产品要求各组件基本无缺陷；组件高质量通过高质量评审实现。
  • 测试发现缺陷流程：发现异常、理解程序、调试定位、修改、回归测试，后期成本高。
  • 评审发现缺陷流程：沿评审者逻辑理解程序，发现缺陷同时知道位置和原因，修正成本低。
  • Yield：阶段消除缺陷效率。
    • Phase Yield = 某阶段发现缺陷数 /（该阶段注入缺陷数 + 进入该阶段前遗留缺陷数）×100。
    • Process Yield = 第一次编译前发现缺陷数 / 第一次编译前注入缺陷数 ×100。
    • 往年题强调 Yield 主要用于估算/预测，不宜简单当作事后度量。
  • A/FR：PSP 质检成本 / PSP 失效成本。质检成本是设计评审时间 + 代码评审时间；失效成本是编译时间 + 单元测试时间。PSP 期望值约 2.0，过高会影响效率。
  • PQI：五个数据乘积，越接近 1 代表过程质量越好：
    • 设计时间应大于编码时间。
    • 设计评审时间应大于设计时间 50%。
    • 代码评审时间应大于编码时间 50%。
    • 编译缺陷密度小于 10 个/KLOC。
    • 单元测试缺陷密度小于 5 个/KLOC。
    • 用途：判断模块开发质量、规划质量活动、过程改进。
  • Review Rate：评审速度。PPT 给出代码评审速度小于 200 LOC/小时，文档评审速度小于 4 页/小时。速度过快质量差，过慢成本高。
  • DRL：缺陷消除效率比，以单元测试每小时发现缺陷率为基准，比较上游评审等活动每小时发现缺陷效率。
  • Quality Journey：测试 -> 测试前产物质量提升 -> 评审过程度量稳定 -> 质量意识/主人翁 -> 个体 review 稳定 -> 设计 -> 缺陷预防 -> 用户质量观和其他质量属性。
  • 高质量综合策略：计划中安排评审/测试；用 A/FR、PQI、Review Rate 约束评审投入；用 Yield/DRL 预测和改进；发现偏差及时补救；用过程改进提升质量。

往年考过的原题

  • 【2013、2021】基于 Yield 指标构建缺陷预测模型，并列举可能改进方案。
  • 【2013、2015、2018】解释 A/FR、PQI 的计算方式和用途。
  • 【2015A】结合 A/FR、PQI、Review Rate、DRL、Yield 尽可能具体描述一个软件项目如何从多方面确保高质量。
  • 【2013、2015A】如果对质量的追求无止境，不考虑资源和成本，有哪些可能有效策略？
  • 选择题：PSP 质量管理策略、DRL、PQI、Yield、Review Rate、Humphrey Quality Journey。

设计质量、PSP 设计模板与设计验证

PPT 对应位置

  • PPT/软件质量与管理.第五讲(1129)(1).pptx：设计与质量关系、PSP 四大设计模板、UML 关系、设计验证方法。
  • 往年整理和往年卷/软件质量与管理-课上选择题-含答案.pdf：OST/FST/SST/LST、状态机、验证手段选择题。

考法

  • 选择：四大设计模板与信息类型、UML 对应关系、状态机正确性条件。
  • 简答：设计为什么影响质量；设计验证有哪些方法；状态机验证检查什么。

应掌握知识点

  • 设计与质量关系：低劣设计导致返工、维护困难和用户不满；充分设计可减少程序规模并提升质量；设计本身也是排错过程。
  • 设计内容：
    • 外部动态信息：系统与外界交互。
    • 外部静态信息：系统对外接口、功能。
    • 内部动态信息：内部行为、状态机。
    • 内部静态信息：内部结构、业务逻辑。
  • PSP 四大设计模板：
    • OST：操作规格模板，描述系统与外界交互，可用于测试场景/用例和需求讨论。
    • FST：功能规格模板，描述对外接口、类/属性/方法等外部静态信息。
    • SST：状态规格模板，描述所有状态、转换条件和动作，用于状态机设计。
    • LST：逻辑规格模板，描述内部静态逻辑，常用伪代码和形式化符号。
  • UML 与 PSP 模板：
    • 用例图/时序图可提供类似 OST 的信息。
    • 类图记录结构，但方法行为需要 FST 补充。
    • UML 无直接对应 LST 的图示方法。
    • UML 状态图类似 SST，但 SST 对条件和动作描述更细。
  • 设计验证方法：状态机验证、符号化执行验证、执行表验证、跟踪表验证、正确性验证。
  • 正确状态机：无死循环和陷阱；状态转换条件完整；状态转换条件正交；还要评价是否体现设计意图。
  • while-do 正确性证明要点：条件为 false 时满足后置条件；条件为 true 时循环体加循环结构与原循环一致；还要能终止，但这种方法不保证算法实现了设计意图。

往年考过的原题

  • 选择题：下述设计模板中用来记录内部动态信息的是？答案指向 SST。
  • 选择题：PSP 四大设计模板和 UML 典型设计图的描述。
  • 选择题：一个完全正确的状态机应该满足什么？
  • 选择题：各种设计验证手段的描述。
  • 选择题：使用程序正确性证明验证 while-do 循环设计的正确描述。

需求开发、团队设计、集成策略与 V&V

PPT 对应位置

  • PPT/软件质量与管理.第六讲.pptx：需求开发、团队设计、实现策略、集成策略、验证与确认。
  • 往年整理和往年卷/软件质量与管理-课上选择题-含答案.pdf：需求、集成策略、V&V 选择题。

考法

  • 简答：需求开发完整过程；客户需求与产品需求区别；V&V 含义和关系。
  • 选择：典型客户需求、设计标准、团队设计注意点、集成策略、验证/确认对象。
  • 应用：判断某活动属于 Verification 还是 Validation。

应掌握知识点

  • 需求是一切工程活动基础，也是设计、集成、验证、确认和项目计划的关键输入。
  • 需求类别：
    • 客户需求：客户期望和实际问题，靠近问题域，可能包含预算、时间、法律法规、行业限制。
    • 产品需求：开发团队提供的解决方案，靠近解法域。
    • 产品组件需求：各组件更低层次的功能、性能、形式等需求规格。
  • 需求开发过程：需求获取、需求汇总、需求验证、需求文档制作。
  • 需求获取：不仅采集显式需求，还要积极识别客户未明确提出的限制和额外需求。
  • 需求汇总：整理信息、识别缺失、解决冲突、把客户需求转化为产品/组件需求、推导隐含需求。
  • 优秀 SRS 特征：内聚、完整、一致、原子、可跟踪、非过期、可行、非二义、强制、可验证。
  • 团队设计需要额外考虑：团队智慧、设计标准、复用、可测试性、可用性。
  • 典型设计标准：命名规范、接口标准、异常/出错信息、设计表示标准。
  • 复用性支持：复用接口标准、复用文档标准、复用质量保证机制。
  • 实现策略：自顶向下设计，自底向上实现更利于评审、复用和建立底层质量基础。
  • 集成策略：
    • 大爆炸：测试用例可能少，但要求组件质量高，否则定位困难。
    • 逐一添加：易定位缺陷，适合组件质量不高，但回归测试成本高。
    • 集簇集成：按相关功能形成可工作组件，利于复用和较早获得可用组件，但系统整体缺陷暴露较晚。
    • 扁平化集成：尽快构建可工作的系统骨架，较早暴露系统级缺陷，但需要大量 stub。
    • CI/CD 本质上接近逐一添加/小步集成策略。
  • V&V：
    • Verification 验证：确保工作产品与事先指定的产品/组件需求一致，即“正确地构建产品”。
    • Validation 确认：确保产品在真实/预期使用环境中满足客户需求，即“构建了正确的产品”。
    • 二者相互依赖：验证为确认提供前提，验证依据最终来自客户需求。

往年考过的原题

  • 【2015】给出需求开发完整过程，并解释客户需求和产品需求含义及其体现。
  • 【2015B】解释质量保障活动中的 V&V 分别是什么含义，两者关系是什么？
  • 选择题：典型客户需求是什么；工期/预算是否属于客户需求方面。
  • 选择题：团队设计活动中设计标准包括命名规范、接口标准、出错信息、设计表示方式。
  • 选择题：团队设计应注意设计标准、复用、可测试性、可用性。
  • 选择题：集成策略相关判断；考虑集成策略应注意组件质量、获取方式、功能关系、数量。
  • 选择题：需求评审/详细设计评审/单元测试属于验证；验收测试、用户手册、系统使用培训材料更偏确认对象/活动。

项目支持活动：配置管理、度量分析、决策分析与根因分析

PPT 对应位置

  • PPT/软件质量与管理.第七讲.pptx：配置管理、度量与分析、GQM、决策分析、根因分析。
  • 软件质量与管理/估算、计划和追踪.md：度量、项目总结、TSP 总结与角色总结。

考法

  • 选择：配置项、配置审计、决策分析、根因分析。
  • 简答：配置管理目的和对象；为什么度量与分析重要；正式决策分析步骤；根因分析过程。
  • 应用：给技术选型或缺陷问题，要求列标准、备选方案、评价方法或根因角度。

应掌握知识点

  • 配置项：在配置管理中作为单独实体管理和控制的工作产品集合。
  • 基线：配置项持续演进的稳定基础；典型基线可在需求分析后、设计后、单元测试后、最终发布时建立。
  • 配置管理目的：建立和维护工作产品完整性。
  • 配置管理活动：识别和记录配置项物理/功能特性；控制变更；记录报告变更和状态；验证配置项与需求一致。
  • 典型配置项：过程说明、项目计划、需求规格、设计规格、设计图、产品规格、程序代码、开发环境、产品数据、技术文件、用户支持文档。
  • 度量与分析意义：支持客观估计与计划；跟踪实际进展；识别过程改进议题；为未来过程提供数据基础。
  • GQM：Goal-Question-Metric，从目标出发，提出能刻画目标达成情况的问题，再定义可测量指标。
  • 决策分析正式步骤：建立准则；识别备选方案；选择评价方法；用准则和方法评价方案；依据准则选择建议方案。
  • 决策分析关键：明确什么场合需要正式决策分析；评价方法体现决策者利益诉求，必须谨慎设计；候选方案通常应在评价标准之后或至少与标准相互校验。
  • 根因分析目的：避免类似错误反复发生。
  • 根因分析过程：识别和选定问题；根因分析；建立改进行动方案；实施改进；评估效果；记录数据和经验。
  • 根因分析角度：技术、人员、培训、过程。鱼骨图是有效工具。
  • 根因分析终止不只是“找到根因”，还要有行动方案、实施与效果评价。

往年考过的原题

  • 选择题：哪些产物属于典型配置项？接口设计文档、源代码、用户手册、系统使用培训材料都可作为配置项。
  • 选择题：团队内部配置审计通常关注什么？物理审计、配置项列表、配置管理记录、基线计划。
  • 选择题：关于决策分析的论述中不恰当的是哪项。
  • 选择题：关于根因分析的论述中不恰当的是哪项。

课堂选择题高频易错点

PPT 对应位置

  • 往年整理和往年卷/软件质量与管理-课上选择题-含答案.pdf：课上选择题合集。
  • 2026 敏捷课堂测试-20260616/2026 Agile.html、2026 Scrum.html、2026 XP.html、2026 Kanban Lean.html：今年敏捷课堂测试材料。

考法

  • 单选/多选，常见特点是概念边界很细，选项会故意混淆“模型/方法/实践/工具”“项目管理/过程管理”“验证/确认”“Scrum/Kanban/XP”。

应掌握知识点

  • Measure twice, cut once：往年整理中常作为软硬件一体化阶段/计划驱动思想的典型表述；课堂笔记里曾标成软件设计相关场景，考试遇到要结合选项和课件上下文。
  • TSP 与 Scrum：都可以是过程框架，都需要补充具体实践；二者都可收集和分析度量数据支持管理决策；不要简单说一个计划驱动一个敏捷。
  • WBS：不是 OBS；WBS 提供范围管理基础；最底层工作包要必要且充分；同层分解标准问题要谨慎。
  • EVM：可以跟踪进度/成本，不能直接用于质量管理；中级实现不引入 AC，AC 是高级实现；EVM 依赖估算准确，对频繁变更场景有限制。
  • PSP 质量策略：重点是用缺陷管理简化质量管理，通过高质量评审获得基本无缺陷组件。
  • PQI/Yield/DRL：注意“能用于预测/规划/过程改进”与“直接保证质量/直接度量”的区别。
  • Review Rate：代码评审 PPT 给出小于 200 LOC/小时，文档评审小于 4 页/小时；不是“技能强就可以无限突破”。
  • 需求与 V&V：客户需求不是简单功能列表，预算/法律法规/限制也可能是需求；验证看是否符合规格，确认看是否满足真实使用环境和客户需求。
  • 集成策略：组件质量高可考虑大爆炸；组件质量不高适合逐一添加；需要尽早获得可工作组件可考虑集簇；尽早暴露系统级问题可考虑扁平化。
  • 配置管理：用户手册、培训材料等面向交付/支持的产物也可以是配置项。

往年考过的原题

  • 课上选择题 1-37：覆盖软件发展、本质困难、TSP/Scrum、团队动力学、WBS/EVM、PSP 质量指标、设计模板、状态机、需求、集成、V&V、配置管理、决策分析、根因分析。
  • 2026 敏捷课堂测试：Agile、Scrum、XP、Kanban/Lean，对应今年新增/强化的敏捷重点。

老师口头强调

来源说明

  • 依据录音 /Users/huatiancen/Library/Containers/com.tencent.qq/Data/Downloads/2026年06月16日 11点51分.m4a 的本地 Whisper 转写整理。
  • 录音中老师明确把课程复习分成三条主线：过程线、项目管理线、质量管理线。
  • 转写中有少量识别误差，以下按课程语境校正：IDAL/PCA 对应 IDEAL/PDCA，互模型 对应瀑布模型，CMP 语境上对应 TSP，政治管理 对应挣值管理，平整 对应评审。

1. 过程线是第一条主线

  • 老师说如果抓几条脉络，第一条就是“过程”。
  • 要先记概念：什么是过程、什么是管理、什么是过程管理。
  • 管理视角强调“复制成功”：软件工程管理很多时候不是凭空创新，而是把已有成功经验变成可复制的过程。
  • 过程管理/过程改进模型要会放在正确层次理解：PDCA、IDEAL、CMM/CMMI 等不是同一种东西。
  • 软件工程提出是为了解决软件开发的本质难题；本质难题在不同历史阶段的凸显方式不同，所以软件工程方法也随阶段演化。
  • 三个历史阶段要会串起来：软硬件一体化、软件独立成产品、网络化和服务化。
  • 重点不是死背阶段名，而是解释“每个阶段的软件工程方法如何解决当时凸显的本质难题”。
  • 对一些听过但容易理解偏差的概念要特别小心：生命周期模型、软件过程、迭代式开发之间的关系。
  • 瀑布模型是重点易错点：老师强调正确理解瀑布模型可以区分是否真正学过软件过程。瀑布模型不是一个单一、僵死的模型，而是一个 family；Royce 并不是简单否定瀑布。应根据项目挑战、能力和复杂度调整过程元素。现实中常见问题是低估项目难度，选择了过于简单、不适用的瀑布式过程。

2. 项目管理线是第二条主线

  • 项目管理三大目标要牢牢记住：成本、工期、质量。
  • 项目管理就是用各种技术、方法和手段去实现这些目标的过程。
  • 团队动力学是项目管理线里的重要内容。软件开发是智力工作/知识工作，不能靠一般意义上的微观控制来管理，需要理解激励和自我管理。
  • 激励理论要掌握：马斯洛、麦克勒格 X/Y、海兹伯格等都讲过，但老师特别点名“期望理论”。
  • 期望理论重点：动机来自两个要素相乘，一个是目标价值，一个是成功概率。这个思想会影响后续整个项目管理理解。
  • 自主团队要掌握：自主团队的内外部环境特征，以及为什么软件开发需要自主团队。
  • TSP 启动过程要熟悉。老师提到课程实践本身就在做类似 TSP 的事情，所以 TSP Launch、角色、会议和计划过程都应当非常熟悉。
  • Scrum 相关角色也要知道，但录音里老师说“角色这些都讲过了”，口头强调更偏向 TSP 启动和项目管理逻辑。
  • 估算要作为重点看。老师强调：估算会不会做、能不能做，很大程度取决于是否正确认识软件项目估算的意图和目标。
  • 定量管理和估算相关，但定量管理不是简单估算；它更强调使用定量管理手段和过程模型。
  • 项目进度跟踪的重点是挣值管理体系。简单、中级、高级实现都要掌握。

3. 质量管理线是第三条主线

  • 质量管理的核心难点可以从管理三要素理解：最难的是判断“状态是什么”，也就是如何知道当前质量状态。
  • 因此要掌握质量的过程度量与结果度量，以及质量管理策略。
  • 评审是质量管理中的重点。老师口头强调了评审的关键控制因素：评审速度、评审时机选择、小组评审，以及相关质量控制指标。
  • 各质量指标都要熟悉，并且要会说明每个指标的用途，而不是只背公式。
  • 为了追求高质量，应该怎么做，也就是 Quality Journey/质量路径这类思路需要掌握。
  • 设计被老师特别强调。即使不完全从考试角度，老师也建议认真理解设计，因为未来软件工程师展现核心竞争力的机会之一就是“做出更好的设计”。
  • 课程内关于设计的重点：到底什么是设计、什么是完整设计；要把内部/外部、动态/静态分开理解；还要理解设计的层次。

复习优先级提示

  • 第一优先级：过程线的概念辨析、三大历史阶段、瀑布模型正确理解、CMMI/PDCA/IDEAL 层次。
  • 第二优先级：项目管理线的团队动力学、期望理论、自主团队、TSP Launch、估算、PROBE、挣值管理。
  • 第三优先级：质量管理线的 PSP 质量策略、评审、Yield/A-FR/PQI/Review Rate/DRL、Quality Journey、设计模板与设计验证。