联调时，报名记录已经写入，通知构件却超时了。项目负责人要同时查四件事：这次发布用了哪个版本，取消递补的测试覆盖了什么，联调延误会不会影响上线，以及通知服务下次失效时怎样处理。它们分别进入配置、质量、进度和风险管理。四个观察维度落在同一个项目上，彼此提供证据，也会改变彼此的计划。
校园报名系统是本章的虚构教学项目。目前批准的基线仍是B2，R17@1.1规定容量100、先进先出候补递补。本节先把交付工作拆清楚，再安排时间；随后沿一次新需求变更，看看计划、版本、质量证据和风险怎样一起更新。计算案例会另行标明条件，不把不同网络的数字混在一起。
5.7.1 项目管理：先知道交什么、由谁完成
教材的4P是人员（People）、产品（Product）、过程（Process）、项目（Project）。它们描述管理对象：谁参与，交付什么，怎样开展工程活动，以及怎样在这个项目的约束下组织这些工作。进度、成本与质量则是项目目标及约束，不能拿“进度”替换第四个P。5.1的过程模型与RUP帮助安排活动；项目管理从启动时就参与资源、范围和责任的组织，并随开发与交付持续调整。
“取消后按队列顺序递补”属于产品范围，回答成果具备什么特性。为了交付它，团队还要澄清异常规则、实现代码、执行测试、编写说明并培训使用者；这些工作进入项目范围。项目范围说明书通常包含产品范围描述，功能清单本身并未列出全部交付工作。
工作分解结构（WBS）按交付范围逐层分解，最低层是工作包。候补交付包需要可核对的代码、测试成果和使用说明，也需要完成标准与一个明确的责任主体。多人可以协作，责任主体负责协调和报告。教材“不超过6层”是一般建议，分解深度仍要服务于可估算、可分派、可验收的工作。
参考资料中的范围基准通常包括范围说明书、WBS和WBS词典，这是本节的支撑扩展。定义范围可以随认识深入而迭代；批准后需要受控变更。质量控制核实成果是否符合规定，客户确认范围则正式接受交付物，两个活动的目的有区别，可以结合项目流程协调。不要把某份没有注明版本的“输入清单”当所有项目通用的固定规则。
WBS同级工作包可以存在前后依赖，也可能因共享人员不能并行。网络计划补上依赖，甘特图显示时间位置；看见树或条形图，要先判断它在回答什么问题。教材六项进度活动是活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制。它们分工明确，实际会反馈迭代：人员不足可能改变历时，执行偏差又可能要求调整活动安排。
5.7.2 进度管理：顺着完整网络计算
以下A–F网络为自编，使用单代号表示法：节点是活动，箭头是完成到开始（FS）的依赖。所有滞后为0，资源不限，统一以工作日计，第0天开始，无外加日期约束，计划工期等于计算工期。若改成箭线表示活动的双代号网络，就不能把节点时间直接当同一个活动的ES/EF；先识别表示法和题给条件。
| 活动 | 工作 | 历时 | 紧前 | ES | EF | LS | LF | TF | FF |
|---|---|---|---|---|---|---|---|---|---|
| A | 候补设计确认 | 3 | 无 | 0 | 3 | 0 | 3 | 0 | 0 |
| B | 通知构件接入 | 4 | A | 3 | 7 | 5 | 9 | 2 | 0 |
| C | 报名递补实现 | 8 | A | 3 | 11 | 3 | 11 | 0 | 0 |
| D | 通知联调 | 2 | B | 7 | 9 | 9 | 11 | 2 | 2 |
| E | 系统集成 | 2 | C、D | 11 | 13 | 11 | 13 | 0 | 0 |
| F | 发布与演练 | 1 | E | 13 | 14 | 13 | 14 | 0 | 0 |
先正推最早开始（ES）和最早完成（EF）：ES＝紧前活动EF的最大值，EF＝ES＋历时。B完成于7，D完成于9，C完成于11，所以E必须等到max(9,11)＝11才开始。F在14完成，两条路径A-C-E-F和A-B-D-E-F分别长14天、12天，最长的A-C-E-F决定当前计算工期。
再从F的最晚完成（LF）＝14逆推：LF＝紧后活动最晚开始（LS）的最小值，LS＝LF−历时。E必须13开始前完成，故它的LS是11；B的后继D最晚9开始，B就必须9完成、5开始。A还要同时满足B的LS5和C的LS3，取min(5,3)＝3作为LF。前推的“都完成才能继续”和逆推的“不能妨碍任何后继”决定了最大与最小，公式因此有方向。
总时差（TF）＝LS−ES＝LF−EF，关注推迟活动对项目完工的影响。自由时差（FF）＝紧后活动ES的最小值−本活动EF，关注是否妨碍后继最早开始；末项可接0天完成节点。B的TF2、FF0：B延1天便迫使D从8开始、10完成，但E仍可在11开始，项目仍14天。自由时差为0并不能证明活动关键。
B和D还共享非关键支路的2天余量。若B额外等待2天，从5开始、9完成，D受依赖影响只能9开始。此时D再额外等待2天到11开始，13完成，E便要13开始，F在16完成。两张表里各有TF2，并不让同一条支路多出4天可用时间；这里“额外等待”是相对已经传播后的开始时刻。
把网络留在上方，再沿黑板算一次：前推到E时，C与D谁晚完成就等谁；逆推到A时，B与C谁要求更早开始就先满足谁。最后只看B的直接后继D，便能解释为什么它一推迟就会影响D，却还有2天余量可以不影响项目完工。这里假设其它活动不另加延误。
在本例条件下，0≤FF≤TF，TF0可判关键活动。如果另强加12天完工期限，逆推起点改变，关键路径会出现负总时差，必须重新计算。历史记录有“TF0而FF2”的争议题，条件不足时保留争议；不靠它改写完整合法网络的定义。GAO进度评估指南的关键路径与时差检查也强调要结合网络、约束和可用时差评估计划。
给活动估历时：三点估计多回答一个问题
通知接口何时调通还不确定，排期前便需要估计。另设三点练习O＝5天、M＝14天、P＝17天，分别表示乐观、最可能、悲观历时；这组数来自参考试题，和上面C的确定历时8天是两个案例。经典PERT近似给出加权期望(5＋4×14＋17)/6＝13天，标准差(17−5)/6＝2天，方差为4天²。最可能值14和简单算术平均12都没有使用规定的权重。
黑板上的μ表示期望历时估计，σ表示标准差估计。M的14天被乘以4，因为这个公式给最可能值更高权重；σ的2天描述离散程度，平方后才是方差4天²。先认清题目要哪一个量，最后再检查单位，就不容易把三个结果互相替换。
把13填进网络后，可以计算一份基于估计值的确定计划。随机项目整体完工期望及概率还涉及路径切换、相关性等条件；不能从单活动三点数直接宣称整个项目在±1σ或±2σ内有固定概率完成。旧截图中G的数字被遮挡，本文没有补成一张“已核原卷”的完整网络。
赶工：先换条件，再比较所有关键路径
上线日期提前时，赶工投入额外资源压缩可压活动；快速跟进让原先串行的部分工作重叠，例如按接口草案先做桩模块。前者要看资源增加是否有效，后者要看重叠是否允许、返工风险多大；两者都要复查质量与风险。增加一倍人员，并没有给出历时减半的依据。
下面按参考试题的完整题干重设演算，官方原卷身份未确认。活动依赖为A→B与A→C→D，两路都完成才结束；FS零滞后、资源不限，只允许整数天，压缩费用线性。单位另改为万元，间接费为5万元/天。
| 活动 | 紧前 | 正常/最短天 | 正常直接费 | 缩1天增费 |
|---|---|---|---|---|
| A | 无 | 3/1 | 10 | 4 |
| B | A | 7/3 | 15 | 2 |
| C | A | 4/2 | 12 | 4 |
| D | C | 5/2 | 18 | 2 |
正常直接费55，工期max(3＋7,3＋4＋5)＝12，总费用55＋12×5＝115。先把关键路径A-C-D上的D压2天，路径从12缩到10，与A-B同为关键；直接费增加4、间接费降到50，总费109。D还有一天可压，但单压它已经不能让另一条10天路径提前。
从10缩到9，必须覆盖两条关键路径。公共A缩1天增4；B、D各缩1天也增2＋2＝4，公共活动并不因此更便宜。选择后者，持续时间变成(3,6,4,2)，直接63、间接45，总108。D到下限后，非公共组合只剩B＋C，每少1天增6；公共A每少1天增4。于是A再压2天，得到(1,6,4,2)，两路7天，费用71＋35＝106。
再求6天，就要B、C各缩1天，直接增加6、间接只省5，总费成为77＋30＝107。最低费用与最短工期回答不同目标。本题按全部180个整数状态计算，各恰好工期的最低总费如下；这一证明范围不扩到任意网络或连续工期。
| 工期天 | 一份最低费方案A/B/C/D | 直接＋间接＝总费（万） |
|---|---|---|
| 12 | 3/7/4/5 | 55＋60＝115 |
| 11 | 3/7/4/4 | 57＋55＝112 |
| 10 | 3/7/4/3 | 59＋50＝109 |
| 9 | 3/6/4/2 | 63＋45＝108 |
| 8 | 2/6/4/2 | 67＋40＝107 |
| 7 | 1/6/4/2 | 71＋35＝106 |
| 6 | 1/5/3/2 | 77＋30＝107 |
| 5 | 1/4/2/2 | 83＋25＝108 |
极限5天用(1,4,2,2)即可。若全部压到(1,3,2,2)，B多压一天却没改最长路径，费用变110。只问“所有任务取下限”时110正确，问“达到5天的最低费用”时应答108。若一轮直接增费刚好等于间接节约，则总费持平、工期变短，不能由此说必亏。
资源指派：先满足约束，再求最小值
现在换一个问题：甲乙丙丁各做一个岗位，A/B/C/D各由一人完成，目标是最小总工时。下图的完整矩阵来自参考指派题，统一以天作为教学单位，不加未经核实的官方年份。每个人选自己最短的任务，行最低相加只有13，但甲乙都选C，方案不满足约束。
先各行减2/3/4/4，得到甲[5,3,0,1]、乙[6,1,0,4]、丙[1,0,3,1]、丁[0,2,1,2]；再D列减1，得到图中右表。任何完整指派都恰用每行每列一次，所以都被减去同一个13＋1＝14，相对优劣保持不变。归约后全非负，14便是原总工时的下界。
选甲D、乙C、丙B、丁A，四个零互不同行列；回原矩阵算3＋3＋4＋4＝14，达到下界，就证明最优。若独立零不足4个，匈牙利法还要用最少线覆盖所有零：取未覆盖最小值m，未覆盖减m，双覆盖加m，单覆盖不变，再寻找完整匹配。不能把一次归约或局部挑零当完整算法。
如果四人同时开始、四项互不依赖，当前安排的完成历时是max(3,3,4,4)＝4天，总工时仍是14人天。换成“最短并行历时”目标就要优化最大值，不能默认任何最小总工时解都同时最小化历时。
在黑板上把两问放到一起：先用下界与合法配对证明“总工时最小”，再用这份安排中最慢的一项算“多久做完”。归约表里的0是减去公共部分后的代价值，任务本身仍要花3或4天；回到原表取数，才能得到正确的工时和历时。
展开完整记录改编：九任务电子商务项目与已发生延误
参考的下午试题转录有完整数值，尚未确认官方原卷年份。这里仅允许每项选正常或赶工两种模式，前驱全为FS零滞后、资源不限，不给间接费用。每格为“正常/赶工”，单位天、元。
| 活动 | 紧前 | 天 | 直接费元 |
|---|---|---|---|
| A | 无 | 4/3 | 7200/8400 |
| B | A | 2/1 | 1600/1900 |
| C | B | 6/4 | 9600/14200 |
| D | C | 12/8 | 22200/27600 |
| E | D | 3/2 | 5100/5700 |
| F | D | 6/5 | 8700/10000 |
| G | D | 4/4 | 6000/6000 |
| H | E、F、G | 7/4 | 9800/12800 |
| I | H | 4/2 | 4000/5000 |
正常主干A-B-C-D长24，E/F/G分支为3/6/4，收尾H-I长11，所以三路径为38/41/39天，工期41、直接费74200元。若要求34天，A、B、H、I分别缩1/1/3/2天，增费1200＋300＋3000＋1000＝5500，直接79700元；三路径变31/34/32。逐项两模式枚举核实，这也是本条件下满足34天的最低直接费用方案。
全部可压任务取下限时为27天、91600元。求27天最低直接费，E仍可保留3天，因为F压后5天仍控制汇合，省600而成为91000元。“全部任务赶工”与“达到该工期最低费用”再次给出不同答案。
若A已经实际用7天完成，偏差3天已经发生，就只能压尚未完成的活动。B缩1、I缩2，剩余赶工增加1300元，恢复41天目标；不能回头把A改写为3天。A实际费用没有给出，1300只是剩余任务追加赶工费，不能擅算整个项目实际总成本。
5.7.3 配置管理：把变更连到具体版本
测试报告写“递补正常”，却没写测过哪个代码版本，便无法用于当前发布决策。产品配置是生命周期中各形式、各版本的文档、程序、部件和数据集合；配置项（Configuration Item，CI）是选定受控的实体，可以是单件或聚合；配置管理是管理这些对象的活动。它们有集合、元素与活动的区别。
配置项是否纳入由受控范围决定。管理报告也能是配置项，设备清单也不能因“不是软件代码”就永远排除。经典五活动为识别、版本控制、变更控制、状态记录与报告、配置审计。版本记录回答改过什么，授权控制回答谁可以改、为何改。SCCS/RCS用于版本管理，lint做静态分析，make组织构建，gdb调试；现代工具可以组合这些功能，不能凭工具名称推整个配置管理过程已经完成。
校方另提CR09，希望容量100改为1000。需求方说明理由，相关人员评估产品、工期、成本、测试和风险影响，CCB或其它被授权者决定接受或拒绝。拒绝就继续B2；接受后才修订工作副本中的需求、代码、用例和说明，原B2仍可识别和取回。容量增加不会自动意味着任意并发或所有性能要求都已获批，评估时应把新的验收条件写清楚。
提交代码记录内容变化，构建成功证明本次构建满足相应条件，测试给出特定版本、数据和环境中的执行证据；这些都没有自动提供发布授权。新版本经约定验证、已知缺陷处理和授权批准后建立B3，发布清单列明各配置项具体版本，状态记录保存谁、何时、依据什么批准。需求追踪串起受影响产物，回归测试检查改变带来的影响，构件契约与版本决定依赖是否匹配。NASA配置管理说明也将识别、控制、状态记录和验证审计相互配合。
开发库、受控库、产品库分别服务日常修改、受控基线、正式交付；它们是职责边界，可以在同一仓库用权限与标签落实。草稿、正式发布、正在修改是经典三状态，评审与批准是动作；具体流程可以增加状态，初版也不统一强制1.0。功能配置审计（FCA）核功能与规约是否符合，物理配置审计（PCA）核实际制品、文档与版本是否一致，审计不能替代所有执行测试。
交付后又改代码，先问触发原因
维护类型是修改的动因维度，配置管理则控制修改的对象和版本。传统软考四类里，运行中暴露递补乱序后修复是改正性；身份平台协议升级后适配是适应性；增加新业务或改善性能是完善性；交付后发现潜伏故障、在它尚未在实际运行中显露前修正，是预防性。提高可维护性也可能进入完善性，单写“重构”或“微服务化”还不能唯一判断。
旧题将“今天的方法用于昨天系统以满足明天需要”归预防性，应保留该题语境，并继续看实际修改原因。版本也有边界：SWEBOK v4.0a §7.1.6列改正、预防、适应、增补（additive）、完善五类，另述紧急维护；enhancement是其上位归组，不能冒充第五类名称。这里以传统考试四类讲题，现代框架对新增功能还会细分。
成本还要拆分类轴。在明确期间与业务量范围内，固定总价租赁可是固定成本，按条结算短信是变动成本，基础费加按量部分是混合成本；“外包”两个字没有给出合同结算方式。直接/间接成本看能否向项目或成果归集，固定/变动看总额如何随业务量变化，可以同时成立。四作业赶工的直接费＋按天间接费使用了自己的给定模型，不从名称推导其它项目成本。
5.7.4 质量管理：检查结果，也检查取得结果的办法
软件质量关注与明确及隐含需求、规定标准的一致程度。取消后是否按FIFO递补，可以实际执行用例检查产品行为，属于质量控制（QC）。审核团队有没有按约定规程实施、报告能否追到所测版本，并跟踪不符合，进入质量保证（QA/SQA）。判断看活动目的；QA会审工作产品，QC也能在开发早期评审进行，两者可贯穿项目，不能按“事前/事后”或人的职位一刀切。5.4的测试、调试与验证确认给出相邻概念的边界。
SQA三任务是审计评审、报告、处理不符合。若测试报告缺少版本身份，先记录不符合及责任期限，再跟踪纠正、核验证据、按规则关闭或升级。修复程序Bug没有自动关闭“报告无版本”的过程问题。教材有报告“不必发项目管理人员”的特殊原句，“不必”也不表示禁止；报告分发应依职责与沟通规则，本文不补造这句原话的组织背景。
同一个系统现在用起来怎样、将来改动怎样、换环境怎样，是产品运行、修改、转移三个质量视角，可以同时评价，并非开发的三个阶段。教材图5-8共有13项，分布6/4/3；二手学习资料中的McCall11分布5/3/3。读题先看来源，避免看见三组就沿用同一个因素清单。
| 视角 | 本教材图5-8 | 二手资料McCall11 |
|---|---|---|
| 运行 | 正确性、健壮性、效率、完整性、可用性、风险（6） | 正确性、可靠性、效率、完整性、易用性（5） |
| 修改 | 可理解性、可维修性、灵活性、可测试性（4） | 可维护性、灵活性、可测试性（3） |
| 转移 | 可移植性、可再用性、互运行性（3） | 可移植性、可重用性、互操作性（3） |
教材“健壮性”问意外环境能否适当响应，“可用性”问我能否使用，“风险”问能否按预定计划完成；不能擅把后者改写成运行事故风险。参考资料中的usability指易用性，别与availability服务可用率混读。McCall原典本次只核作者、年份与书目信息，未通读全文，11因素由二手学习资料支撑；两个来源保留各自术语，不强配健壮与可靠为同义词。
教材ISO 9001:1994的二十要素属于历史语境。2026-10-04核官方公开信息，ISO 9001:2026第6版已于2026-09-16发布，ISO 9000:2026第5版是基础与词汇标准；这里只核公开版本信息，没有阅读付费新版全文。ISO 9000族与名为ISO 9000的具体标准要分开，ISO 9001提供组织质量管理体系要求。组织认证及CMM/CMMI过程能力评价都不能替某个具体版本证明零缺陷或满足真实业务需要。
5.7.5 风险管理：未发生的条件，也要有人跟踪
联调已经出现通知超时，是需要处理的问题；“上线高峰可能再次超时，导致确认积压”才是尚未发生的不确定事件。风险发生后转入问题处理，同时评估余下风险。把已发生故障继续只写成一个概率，团队就缺少实际纠正动作。
教材Boehm分两组：风险估计包含辨识、分析、排序，风险控制包含管理计划、处理、监督；Charette分风险分析（辨识、估计、评价）与风险管理（计划、控制、监督）。它们给出各自的划分层次，字面相近也不能逐项强配同义。SEI的软件风险评估SRE、持续风险管理CRM、团队风险管理TRM则回答评估方式、持续机制、协作范围，能够配合，不能排成三个先后阶段。该版还提到CMM，其过程能力作用回看5.1，不将它追加成风险工作的第四阶段。
排序需要看概率，也看影响。另设教学估计：身份平台上线前不可用的概率0.3、损失10万元，风险曝光RE＝0.3×10＝3万元；通知服务失效概率0.6、损失2万元，RE＝1.2万元。概率较大的事件在期望损失标尺上反而较小；3和1.2的单位是万元，不能画成概率。两项虚构估计只示范该标尺，实际仍要考虑严重度、相关性及其它不能由平均损失表达的条件。
这次比较固定在同一考察期。写成RE＝p×L，p是发生概率，L是事件一旦发生的损失额：先把30%变成0.3，再乘10万元。算出的3万元表示期望损失标尺，并不表示一次事故一定损失3万元。若题目给的是概率—影响矩阵的等级分，它在做分级，不能直接把分数当成这里的金额。
应对策略作为记录扩展，可以规避、减轻、转移或接受。经授权移除短信依赖可规避这条依赖失效风险，但新的通知路径还要评估；准备且验证备用服务可以减轻影响；合同分担后果属于转移，运营监控及残余风险仍归相应责任人；接受则明确承受条件和储备安排，不能默认填表后风险已经消失。
例如由接口负责人跟踪身份服务，测试负责人提前验证备用方案，上线前若连续超时达到约定阈值，就启动已批准的备用动作并报告影响。触发条件、责任、期限和备用动作使登记册可以执行。SEI风险管理报告中的持续管理也将沟通贯穿各项工作。外部条件变化后，重新检查工期余量、受控版本和质量证据，不能继续使用已经失效的假设。
回到开头的通知超时：进度算依赖与可用余量，配置找到当前制品及授权，质量核对当前证据，风险准备后续不确定条件的应对。前几节给出需求、设计、测试和复用的工作方法，本节把这些工作放回同一交付项目。遇到题干条件变化，先判断它改变了哪个对象、哪条依赖或哪份证据，再决定原答案是否还能成立。