报名系统增加了取消后递补的规则。有人取消，队首候补获得名额；两个取消请求撞在一起，也不能让同一个学生递补两次。沿用上一节的做法，团队可以运行程序、观察失败，再定位原因。净室软件工程把大量纠错工作放到首次运行之前：先写清行为，再推理设计是否兑现这些行为。程序交出去以后，仍要执行测试，取得实际使用的质量证据。
净室软件工程（Cleanroom Software Engineering，CSE）以数学和统计学为基础，追求以合理成本生产高质量、零缺陷或接近零缺陷的软件。这里的“净”指开发过程着重预防缺陷。这个目标需要规约、验证、抽样和团队配合，不能靠给项目贴上名称实现。本节沿教材的理论基础、技术手段、应用与缺点展开，先分清两类证据各在回答什么。
先规定应该怎样响应，再讨论实际使用
把程序看成函数，输入是可能的输入序列，输出是对应的响应。序列保留了发生顺序：先查询、再报名、再查询，和连续查询两次，面对的条件不同。函数规范要满足完备性，即定义域内每种输入都至少有一个规定输出；也要满足一致性，即同一输入至多对应一个规定输出。合起来，每种输入都有且只有一个规定输出。
这还没有回答“规定的输出是否符合需求”。我们只截取报名决策的一小部分：请求未重复，报名开放，资格与余量已经有效核定。不具备资格就拒绝，有资格且余量大于 0 就确认，有资格但余量为 0 就候补。如果把这三个条件全写成“拒绝”，映射依然有定义、结果唯一，却在有资格且余量为 1 时拒绝了本应确认的学生。完备、一致检查遗漏和矛盾；正确性还要对照目标规约。这个简化片段没有覆盖异常报文、重发、并发及取消，不能当作完整系统规范。
同一个“查询余量”请求先得到 1，报名发生后再得到 0，并不违反一致性。当前请求相同，完整输入历史已经改变。把历史遗漏后再要求输出一样，检查对象就错了。后面的状态盒会把必要历史压缩成状态，例如余量、已确认记录和候补队列；余量本身不足以判断重复报名和队列次序。
规约写清楚以后，另一个困难仍在：用户可能用任意长的操作序列访问系统，实际运行情形无法逐个穷尽。抽样理论把可能使用看成总体，按使用模型抽取测试序列，再依据样本分析性能和可靠性。正确性验证关注设计相对于规约是否正确，统计测试关注指定使用条件下的表现。二者的对象和证据不同，可以共同服务同一个增量。
因此，语句、判定或条件覆盖回答检查过哪些程序结构；使用模型回答用户会怎样操作、各种序列出现的可能性。高覆盖率不能直接换成可靠性百分比，抽样通过也不能反过来说明每个分支都执行过。
三盒细化同一行为，四种手段配合一个增量
先从外部观察报名：具备资格、有空位，系统回应确认；没有空位，系统回应候补。黑盒写这种可观察行为，依据当前输入及输入历史规定响应，不显式定义内部状态和程序步骤。这里的“黑盒”属于规约视图，和 黑盒测试的分类轴不同。黑盒测试关心设计用例时利用什么信息；盒结构关心怎样描述软件。
为了实现这份行为约定，状态盒引入必要状态，描述“当前输入与当前状态”如何产生“响应与新状态”。最后一个名额被确认后，余量从 1 变为 0，学生进入已确认记录。满额时有人取消，状态还需包含候补顺序，才能决定谁递补。状态盒描述转换，尚未列出实现转换的具体程序过程。
明盒再给出过程视图：怎样检查资格和当前余量、更新记录、维护队列、返回结果。三盒逐层细化同一个行为约定，每次细化都要对照上一层验证；它们可以同时存在于同一系统的设计资料里。函数是数学描述，不要求使用函数式编程语言，盒结构也支持信息隐藏与实现分离。
假如明盒省掉余量检查，对有资格的请求一律扣减，就可能在余量为 0 时仍确认报名。此时实现违反状态盒规定的转换。正确性验证要检查这种对应关系，也要检查顺序、分支和循环是否实现其预期功能。在经典净室过程中，开发团队通过函数论推理与团队评审进行验证，包括口头论证；不能把它描述成所有代码都已由机器定理证明器自动证明。
教材列出的四种技术手段可在这里各就其位：受控增量开发安排每次处理的范围；基于函数的规范与设计准确表达要实现的行为；正确性验证检查设计与规约的关系，是教材指定的核心；统计测试和软件认证提供预期使用的质量证据。函数规范与核心验证需要区分。“数学”提示理论基础，还要看题目问的是表达、验证、认证还是总体目标，不能只凭一个关键词作答。
为了看清责任，我们把开发划成两个教学增量：先完成基础报名，再加入取消与候补。这只是本例的范围安排。规格职责确定功能与预期使用，开发职责设计、编码并完成正确性验证，独立认证职责负责执行与评估；项目管理贯穿其中。它们是职责分工，不要求四个独立部门，小项目也可能有人兼任部分职责，但认证的独立评估责任仍要明确。
教材提倡开发者以正确性验证替代传统的模块执行测试与调试。在经典过程里，验证后的增量交给独立认证团队首次执行。程序仍被测试，失效仍被记录；需要修正时，开发者回到设计与代码，调查原因、修正，再验证。上一节的测试与调试仍是不同活动。统计测试也会暴露错误，不能写成“只算 MTBF、不发现缺陷”。
认证团队按使用模型生成随机样本。模型描述可能的使用顺序、状态和概率，不等于随意乱填参数，也不默认所有操作均匀出现。一次取消要有相应已报名状态；反复取消、非法请求等使用也须在相关规范和模型中规定响应。使用模型可以提前准备，统计评估随着增量积聚反复进行；认证后的增量还可交给用户评价需求是否合适。
这也说明净室不能跳过需求工程。获准的候补变更要按 基线与变更控制更新规范及相关设计，追踪对应证据。设计正确地实现了“永远拒绝”这份错误规约，仍然达不到用户目标；Verification 与 Validation的两个问题都需要回答。
结论带着条件，采用也有成本
教材介绍了 IBM 的早期净室实践、NASA 戈达德飞行中心软件工程实验室等历史应用。这些记录说明方法曾用于实际工程，不能将某个项目的未收到故障报告推广为所有净室软件永不失效。教材同时列出数学知识、训练和验证时间成本，以及不做传统模块测试的实施局限；净室仍可能带有传统软件工程中的一些问题。
“以合理成本获得高质量”是方法目标；团队引入时要花时间培训、编写规约和评审，是采用成本。希望减少后期返工，与前期投入较高可以同时成立。判断是否采用，需要看需求稳定程度、团队能力、交付约束和失效代价。仅知道净室这个名称，无法断言每个项目总成本必降或必升。
验证的结论依赖检查范围及假设。需求本身有误，要回到规约和用户确认；编程语言理解偏差、编译器或操作系统缺陷，可能使真实执行偏离设计假设。相应环境问题若没有纳入验证模型，就不能凭设计验证说它已经被排除。教材对开发小组不做传统模块测试的质疑，正落在这些现实差距上。
换一个活动，查询与正常报名占多数的使用方式变成大量取消、递补和集中并发，原先的样本就未必代表新活动。认证结果针对被测的具体版本；版本、使用模型或环境改变后，旧可靠性估计不能直接照搬，不同条件下的测试数据也不能无条件合并。这些条件应和测试结果一起记录。SEI 净室参考模型详细区分了规约、开发、认证职责与认证适用条件。
常规抽样也可能很少触及低频但高后果的双重递补。可以另建相关压力使用模型或补充定向场景，保持结果所属条件明确。即使本轮样本没有观察到一次失效，也只能先陈述这个观察；要估计可靠性，还需要相应统计模型、样本量及推断条件。零观察失败不能直接证明全体零缺陷。
回到候补变更，团队要重新核对行为规则，用状态保存新增历史条件，用过程实现转换并验证，再更新使用模型与测试证据。净室提供一套开发与质量评估方法；CMM/CMMI回答组织过程能力，二者可配合。采用增量开发也只回答怎样安排交付，仍需规约、验证和认证，才构成这里讲的净室工程配合。