在瀑布模型中引人屏障条件并非一种新观念。大多数瀑布实现都为每个开发阶段定义了开始条件和结束条件。例如，在一个严格的瀑布模型中，只有当需求阶段完成后，才会开始设计阶段。而需求阶段的结束条件可以是关键的相关方签署了需求、内部客户(或外部代表)审查了需求，以及负责生产这些需求的组织审查了需求。在修改过的重叠瀑布模型或混合瀑布模型中，只需完成了要开发的系统的需求即可，而不必完成整个产品或系统的需求。如果采用了原型，那么可能在开始主要设计前，需要在原型中模拟这些需求。

在瀑布模型中引人屏障条件并非一种新观念。大多数瀑布实现都为每个开发阶段定义了开始条件和结束条件。例如，在一个严格的瀑布模型中，只有当需求阶段完成后，才会开始设计阶段。而需求阶段的结束条件可以是关键的相关方签署了需求、内部客户(或外部代表)审查了需求，以及负责生产这些需求的组织审查了需求。在修改过的重叠瀑布模型或混合瀑布模型中，只需完成了要开发的系统的需求即可，而不必完成整个产品或系统的需求。如果采用了原型，那么可能在开始主要设计前，需要在原型中模拟这些需求。



要满足我们的目标，只需把前面列出的四个流程嵌入到已有的屏障条件中即可。架构评审委员会可以作为项目设计阶段的结束条件。代码审查，包括审查代码是否符合架构设计原则，可以作为编码或实现阶段的结束条件。性能测试应该在验证或测试阶段执行，要求是任何关键的系统资源的使用情况变化不能超过一个指定的百分比。对生产环境定义和实施的衡量标准应该作为维护阶段的结束条件，对于任何在被衡量的领域中出现的预料之外的显著增长，都应该采取措施，减少架构实施或变更带来的影响，从而实现更经济有效的扩展。

许多公司都开发了融合敏捷方法和瀑布方法的模型，有些公司则还在使用敏捷方法的前辈，即所谓快速应用开发(RAD)的方法。例如，有些公司会要求开发的软件要与合同和预先定义的需求保持致，如那些与政府组织打交道的公司。这些公司可能希望用瀑布模型提供一些对日期的预测，而用敏捷方法来迅速地实现一组功能块。

对于这些模型，关键在于在哪里安置屏障条件才是最有效的。要回答这个问题，我们需要回去看看屏障条件的目标。我们使用屏障条件的目的是要确保我们能尽早发现开发中的问题，以便减少实现目标所做的重复工作。例如，由QA组织捕捉到一个问题，就比在生产环境中才发现问题所需花费的时间和工作量少。同样地，我们在ARB中发现一个问题，要比在代码审查时才发现它所需花费的时间和工作量少。

对于在哪里安置屏障条件这个问题，答案就是在能给流程带来最大价值并且所需成本最少的地方加人屏障条件。代码审查应该安排在每个编码周期完成时，或者安排在一组功能块完成时。架构评审应该放在实现APP开发架构之前，生产指标显然应该在生产环境中衡量，而性能测试应该在把系统发布到生产环境之前执行。