障碍条件和瀑布开发混合模型

在瀑布模型中引入障碍条件并不是一个新概念。大多数瀑布实现定义了每个开发阶段的开始和结束条件。例如，在严格的瀑布模型中，设计阶段仅在需求阶段完成时才开始。需求阶段的结束可以是关键利益相关者签署要求，内部客户（或外部代表）审查要求，负责制定这些要求的组织审查要求。在改进的重叠瀑布模型或混合瀑布模型中，仅需要完成要开发的系统的要求而不必完成整个产品或系统的要求。如果使用原型，可能需要在开始主设计之前在原型中模拟这些要求。

在瀑布模型中引入障碍条件并不是一个新概念。大多数瀑布实现定义了每个开发阶段的开始和结束条件。例如，在严格的瀑布模型中，设计阶段仅在需求阶段完成时才开始。需求阶段的结束可以是关键利益相关者签署要求，内部客户（或外部代表）审查要求，负责制定这些要求的组织审查要求。在改进的重叠瀑布模型或混合瀑布模型中，仅需要完成要开发的系统的要求而不必完成整个产品或系统的要求。如果使用原型，可能需要在开始主设计之前在原型中模拟这些要求。为了实现我们的目标，只需将上面列出的四个流程嵌入到现有的屏障条件中。架构评审委员会可以作为项目设计阶段的最终条件。代码审查，包括审查架构设计原则的代码，可以用作编码或实施阶段的最终条件。应在验证或测试阶段执行性能测试，要求将任何关键系统资源的使用更改不超过指定的百分比。生产环境的定义和实施的指标应该是维护阶段的结束，并且应该采取所测量区域的任何意外的显着增长来减少实施或改变架构的影响。实现更具成本效益的扩展。许多公司已经开发了包含敏捷方法和瀑布方法的模型，一些公司仍在使用敏捷方法的前身，即所谓的快速应用程序开发（RAD）方法。例如，一些公司将要求开发软件以符合合同和预定义的要求，例如与政府组织打交道的要求。这些公司可能希望使用瀑布模型来提供日期的一些预测，以及快速实现一组功能块的敏捷方法。对于这些模型，关键是将屏障条件置于最有效的位置。要回答这个问题，我们需要回过头来看看屏障状况的目标。 我们的障碍的目的是确保我们能够尽早发现发展中的问题，以减少重复工作以实现我们的目标。例如，QA组织捕获问题所花费的时间和精力比在生产环境中查找问题要少。同样，我们发现ARB中的问题比审查时花费的时间和精力更少。对于何处设置障碍的问题的答案是增加障碍，使流程能够带来最大的价值并且成本极低。应在每个编码周期结束时或完成一组功能块时安排代码审查。架构评审应放在app开发架构的实施之前。显然应该在生产环境中测量生产指标，并且应该在系统发布到生产环境之前执行性能测试。