在国外的软件开发实践中有很多很好的做法值得借鉴，这里简单地罗列了一些，如IBM、微软、日本软件企业、CMMI及RUP（Rational Unified Process，统一软件过程）等。
1．IBM的技术评审
IBM中著名的Fagan inspections（审查法，1976）是我们可以找到的最“古老”而系统的软件评审方法。Fagan七步审查法分为7步，即计划、概述、准备、审查、过程改进、修改和后继活动。有一个很著名的应用实例，休斯敦航天飞机的相关软件中缺陷的85%通过审查发现，15%通过测试发现，而完成后没有再发现缺陷。这一实例说明了评审工作的重要性，也说明了这次评审的有效性。
2．微软的技术评审
微软软件开发中的评审称为“技术评审”（technical review），包括Walkthroughs（浏览和走查）、inspections（检查和调查）和code reading（程序阅读）。微软的技术评审较强调由资深开发人员评审和发现问题，同时提倡新开发人员参与评审以获得更多经验，也鼓励新开发人员向老的设计思想提出挑战。
3．日本软件企业的技术评审
日本企业的质量管理是非常严格的，软件研发企业也不例外。现在越来越多的日本软件开发外包，所以在这里简单地提一下。
日本软件企业的技术评审包括审查和测试等，从软件开发流程的角度有试样审查、设计审查、编码审查和测试审查；从项目管理内容的角度有范围审查、质量审查、进度审查和成本审查；从审查实施人员角度有自查、项目管理者审查和独立第三方审查。
日本软件开发企业在软件开发的过程中，将验证和确认作为阶段性作业的审查结点。他们认为验证和确认的本质意义在于一是强化软件开发人员的责任感，让其认识到不能将不合格的工作成果移交给验证者和确认者；二是让验证者和确认者真正参与到软件开发中来，成为软件开发质量把关的真正力量。
4．RUP中的技术评审
RUP的指南中提供了如下3种复审。
① 复审（Review）：一次正式的会议，在会议上向用户、客户或其他相关各方介绍阶段成果，以征求对方的意见和批准。
② 检查（Inspection）：一种正式的评估方法，将由非制作者本人的个人或小组详细检查阶段成果，以查明是否有错误、是否违反开发标准及是否存在其他问题。
③ 走查（Walkthrough）：一个复审过程，由某个开发人员领导一个或多个开发团队成员对他（或她）所编写的阶段成果进行检查，同时由其他成员针对技术、风格、可能的错误、是否违反开发标准和其他问题提出问题并发表意见。
5．其他评审方法
① Gilb/Graham方法：这是一种比较严格的方法，强调用审查来量化产品质量。分为4个阶段，即动员大会Kick-off meeting（总体会议overview）、个人检查individual checking（准备preparation）、记录会议logging meeting（审查会议inspection）和编辑editing（返工rework），强调先各自检查、小部分取样检查、获取并分析错误密度分布和错误类型，对大型项目完成10%就checking10%。
② High－Impact Inspection：强调使用各种分析技术来发现缺陷并应了解软件历史、合逻辑的论据和使用场景，强调细察特定方面胜过简单地查找缺陷，经过个别检查阶段后进入讨论阶段。
③ Phased Inspection：（分阶段）一系列严格的指定角度的检查，每次只检查某一成果是否具有某一个所期望的特性。这些特性可以是关于质量的（如可移植性和可维护性），也可以是关于技术的（如某个算法逻辑的正确性）。
相关链接：
