## 形式化审查时代（1976 — 1990s 中期）

起点标志：1976 年，IBM 的 Michael Fagan 发表论文《Design and Code Inspections to Reduce Defects》，首次将"代码审查"从非正式的同行互看形式化为一种结构化工程方法——他最初称之为"Code Inspection"。

| 维度 | 特征 |
|------|------|
| 审查形式 | 正式会议（in-person meeting），参与者有固定角色：主持人（moderator）、作者（author）、朗读员（reader）、记录员（recorder） |
| 审查对象 | 全量代码（不是 diff），按检查清单逐行审查 |
| 核心目标 | 缺陷检测——Fagan 的数据显示审查能在测试前发现 60-90% 的缺陷 |
| 审查者角色 | 专职审查者，审查是独立的工作环节，不嵌入开发流程 |
| 代表方法 | Fagan Inspection、Walkthrough（更轻量的变体）、Active Review（NASA） |

关键特征：重量级、高成本、高检出率。一次审查会议可能耗时数小时，需要提前准备、正式开会、会后跟踪修复。适合瀑布模型下的"里程碑式"交付节奏。

同期平行线——静态分析萌芽：1979 年 Stephen Johnson 发布了 Unix 的 lint 工具，这是自动化代码检查的最早雏形，但此时它与人工审查是两条独立线，尚未融合。

## 代表方法：Fagan Inspection

| 方法 | 维基百科链接 | 状态 |
| --- | --- | --- |
| Fagan Inspection | en.wikipedia.org/wiki/Fagan_inspection | ✅ 有独立词条 |
| Walkthrough（软件走查） | en.wikipedia.org/wiki/Software_walkthrough | ✅ 有独立词条 |

![image.png](https://developer.qcloudimg.com/http-save/yehe-11563618/9f8a04906c1c277e3ad4c0b6c827bbac.png)

## 代表方法：Active Review（NASA）

| 来源 | 链接 | 说明 |
| --- | --- | --- |
| NASA 软件形式审查指南（1998 版） | ntrs.nasa.gov/19980228472.pdf | NASA 官方形式审查流程指南，涵盖 ADR |
| NASA 软件形式检查指南（2018 版） | ntrs.nasa.gov/20180004877.pdf | 更新版的 NASA 软件形式检查要求 |
| Semantic Scholar 综述论文 | pdfs.semanticscholar.org — Code Inspection: A Review | 学术综述，明确提到 "Active Design Review (ADR)" 并将其归类为 FTR（Formal Technical Review）的一种 |
| 维基百科 Design review 词条 | en.wikipedia.org/wiki/Design_review | 提到 NASA 工程设计生命周期中的设计审查阶段，但非 ADR 专条 |

## Active Review（NASA）方法特点

**NASA 的技术标准 NASA-STD-8739.9《软件正式审查标准》（Software Formal Inspections Standard）**，2013 年 6 月批准、2018 年重新验证，用来替代 1993 年的旧版 NASA-STD-2202-93。

**一句话说，它就是：NASA 规定的"软件审查会怎么开"的一套强制流程规范。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-11563618/7a996561e8a520e25cbc09fcf3a4a0d1.png)

核心要点：

- **目的很直接**：在软件生命周期里**尽可能早地找出并消除缺陷**。越早发现 bug，修复代价越低——这对航天这种高可靠、安全关键的场景尤其要命。它源自经典的 Fagan 审查法，并融入了 NASA 实践里验证有效的最佳做法（如基于视角的阅读 perspective-based reading）。

- **管得很宽**：不止查代码，而是覆盖各类软件工作产品——软件计划、系统需求（R0）、软件需求（R1）、架构设计（I0）、详细设计（I1）、源代码（I2）、测试计划（IT1）、测试规程（IT2）。连开源、自动生成代码、COTS/GOTS/MOTS 商用货架产品、复用和遗留软件怎么审，都写进去了。

- **流程是结构化的**：定义了明确的**角色**（审查员、主持人/moderator、作者、记录员等）、**准入与准出标准**、**过程阶段**，以及必须收集的**审查数据**（缺陷数、审查速率等），并要求用这些数据反过来做过程改进。

- **约束力分层**：文中带 "shall" 的是**强制要求**（编号形如 [SFI-###]），"should" 是推荐做法，"may/can" 是酌情。真要豁免某条要求，必须正式记录并报技术权威（Technical Authority）批准。

- **责任在项目经理**：但项目经理不必亲自上阵主持审查，可委托给软件负责人、首席审查协调员或软件保证负责人等。

## Active Review（NASA）方法八类审查

| 代号 | 审查类型 | 工作产品 | 推荐起始速率上限 |
|---|---|---|---|
| — | 软件计划 (7.2) | 开发/管理计划、配置管理、维护、保证、安全计划 | **≤15 页/小时** |
| R0 | 系统需求 (7.3) | 系统定义与需求文档 | 未给指标 |
| R1 | 软件需求 (7.4) | 软件需求规格、模型/故事/待办列表 | **≤15 页/小时** |
| I0 | 架构（概要）设计 (7.5) | 架构/初步设计描述、设计模型 | **≤20 页/小时** |
| I1 | 详细设计 (7.6) | 详细设计说明 | **≤20 页/小时** |
| I2 | 源代码 (7.7) | 源码、自动生成代码 | **≤10 页/小时**（最慢） |
| IT1 | 测试计划 (7.8) | 测试计划 | **≤20 页/小时** |
| IT2 | 测试规程 (7.9) | 测试规程/脚本 | **≤20 页/小时** |



### 1. 软件计划审查（7.2）
检查单要覆盖：各活动的**工作量/进度/成本估算是否合理**；资源（工具、具备技能的人员）是否配足；**风险是否全部识别**并记录概率、影响、缓解策略；项目数据管理是否充分；是否有机读可行的**持续保障与退役计划**；内容是否符合 NPR 7150.2 / NASA-HDBK-2203A 的推荐目录。

参与方：软件工程师、系统工程师、软件保证人员、安全工程师（如适用）、软件安全人员（如适用）、配置管理人员（审配置管理计划时）。必要时可拉项目管理人员进组，但要注意 5.2 节关于团队构成的告诫。

### 2. 系统需求审查 R0（7.3）
重点在**分配与可追溯**：功能是否正确分配到软件/固件/硬件/操作；所有外部使用接口是否验证；系统功能是否分解到配置项、边界是否清晰、配置项间接口是否列全；需求与属性是否可量化、可验证；能否向上追溯到任务需求（用例等），以及追溯到**系统安全与可靠性分析**（PHA、FTA、FMEA、危险报告）。

参考材料：接口定义/规格文档、验证与确认计划（如有）、安全关键软件的安靠性分析。参与方要包含需求定义者、子系统集成责任人、各子系统实现责任人、质量/保证/可靠性人员，安全关键时加软件安全责任人。

### 3. 软件需求审查 R1（7.4）
检查每个规格是否完整准确：软件功能、输入/输出参数、状态与模式、性能相关的时序与规模需求、接口、用例。还要确认是否写入了**错误检测与恢复、可靠性、可维护性、性能、安全、精度**；安全需求是否被显式标识；安全关键模式/状态与约束是否识别；需求是否**可度量、一致、完整、清晰、简明、可测试**，且足以支撑设计。

特别提醒（7.4.2）：需求不一定落在文档上。**模型、用例、场景**，甚至敏捷的**故事、产品待办、每个 sprint 的需求集**都可以审——把上面这张检查单改造一下套用即可；喂给自动代码生成器的模型更要审。

### 4. 架构设计审查 I0（7.5）
关注：设计是否满足已批准需求、模块间接口是否验证、模块清单与各自功能是否完整、故障检测/识别/恢复需求是否验证、可复用组件选型是否验证、设计到需求的可追溯性、每个设计决策是否契合系统目标。安全关键时，确认**安全控制与缓解措施**在设计文档中明确标识。

审面向对象/其他设计模型时额外查：图符是否符合约定标准（如 UML）；设计是否模块化；**内聚与耦合是否恰当**；是否使用了架构风格与设计模式（若用了，验证选型是否合适）；静态分析工具输出。

### 5. 详细设计审查 I1（7.6）
关注：数据结构、逻辑算法（若规定）、模块间关系选型是否验证；每个模块的详细设计是否完整；能否追溯需求与架构设计；**是否可测试**；能否在所选架构约束内落地实现；是否有静态分析输出。

### 6. 源代码审查 I2（7.7）
检查单：代码相对需求的**技术正确性与完整性**；是否实现了详细设计；是否满足全部标准（含编码标准）；是否潜藏**越界、缓冲区溢出、除零**一类错误；到需求与详细设计的双向可追溯；有静态/动态分析则查其结果。

**自动生成代码（7.7.2）**：因正确性难验证，建议纳入审查，安全关键系统尤其如此。除常规项外加查：生成代码所用**模型的正确性**；代码生成器是否针对目标环境正确配置；生成代码与其余代码库的接口是否一致正确；生成器的已知问题是否被规避/缓解并文档化。

### 7. 测试计划审查 IT1（7.8）
关注：测试目的与是否服务任务目标；所有新增/修改功能是否在目标环境下按批准需求被验证；所需资源与环境是否识别；所有新增/修改接口是否验证；是否清除了多余或过时的测试计划；**每条需求是否都有对应测试**；测试人员是否在执行前就确定了预期结果。

安全关键系统（7.8.1.h）两条硬要求：所有安全关键功能/危险控制与缓解都要被测试，且要验证**异常发生时系统能进入安全状态**；用安全与可靠性分析来确定要测哪些故障及故障组合。

### 8. 测试规程审查 IT2（7.9）
每条规程要给出：完整准确的目的描述、如何执行的描述、**全部预期结果**；标识所测需求且确实测对了；标识所需软硬件配置；是否存在验证安全关键控制及危险控制/缓解的规程，并覆盖从不同模式、状态、条件进入安全状态；能否客观判定实现是否满足需求。

**自动生成测试规程/脚本（7.9.2）**同样建议审查，加查：生成模型正确性、生成器配置、生成器已知问题的规避与文档化（较代码少一条"接口一致性"）。














起点标志：1976 年，IBM 的 Michael Fagan 发表论文《Design and Code Inspections to Reduce Defects》，首次将"代码审查"从非正式的同行互看形式化为一种结构化工程方法——他最初称之为"Code Inspection"。

【CR01】第一代代码评审技术 & NASA方法分析

特别是NASA方法，对AI时代的Code Review怎么做，还是很有启发的。

编程语言

开发工具

测试

形式化代码审查的开端标志是1976年IBM的Fagan Inspection，将同行互看转为结构化会议，固定角色逐行审查，能在测试前发现60-90%缺陷。同期lint工具萌芽，NASA的ActiveReview方法覆盖八类软件工作产品，强调缺陷尽早消除，为高可靠系统提供强制审查规范。

数据管理

软件工程

软件需求

瀑布模型

数据结构

Unix

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【CR01】第一代代码评审技术 & NASA方法分析-腾讯云开发者社区-腾讯云

【CR01】第一代代码评审技术 & NASA方法分析

【CR01】第一代代码评审技术 & NASA方法分析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐