需求处理的妥协和更好的设计过程模型

谈起需求这个东西，果然是很有火气的，特别是采用瀑布模型进行开发的时候。因为需求不会一开始就很明确，没有足够的迭代，出来的初始需求的各个部分有可能是相互冲突的。瀑布模型又是一种顺流直下，没有反馈和迭代的，然后在现实的情况下基本是要崩溃的。于是，人们就开始想办法，怎么去保证开发一直集中在关键需求上？

     这个时候，有一个不错的想法：首先建立需求变化监管机制，层层把关；其次良好的系统工程在开发关键技术之前就开始，初始需求在系统开发过程中于第一个和第二个里程碑之间完成详细需求初始的定义；及早任命项目管理团队并责令其全程跟进；严密监控需求追踪矩阵，保证需求准确且不扩张缩减。为什么初始需求要在第一个和第二个里程碑之间进行详细表述呢？第一个里程碑主要明确性能参数；第二个里程碑是整理好的需求中经过前几个阶段运营考验的部分，是后续开发效率的重要保证依据。

     既然需求可以得到控制了，怎么去解决多方合作的责任问题？答案是合同，于是多方为了各自的利益会达成一个合同，在合同中明确的规定各方的责任和任务，保证各自的利益不会受损。但是这个合同并不是固定不变的，随着需求的变化，合同内容后续会发生变动和增加新的规定，于是给了各方大开方便之门的机会。这种情况反过来给瀑布模型支援了强大的生命力，使得瀑布模型在设计和构建复杂系统时长久的存活。

     通过设计过程中的迭代交互可以有效的确定设计的需求，不过这个也会导致工期紧风险高，前提是各方之间存在足够的信任关系，并且其中牵扯的问题各方都清楚。即便做好了这些，延期仍然是非常有可能的。

Note:理论是基于足够简化的条件的，当回归的现实的时候，需要逐步将化简条件还原到现实条件作出调整，只有所有的化简条件还原现实都满足的时候，理论才是有效的方案。所谓经验丰富就是不但知道理论，更多的解决化简条件到现实条件的各种技巧。

    每一个项目大体上都要以一个占主导地位的设计过程模型。只有参与项目的多数人都能够认同这个主导地位的过程模型，接下来的沟通和设计才会顺畅。值得参考的主流模型有：共同演化模型、集市模型、螺旋模型。

共同演化模型是一种迭代模型，问题和解空间相互作为演化的条件，只要有了初始的问题，这种演化会一直持续下去，并且是问题和解空间平行演化。这个可以举个例子：互驯。

集市模型是一种演化模型，在开源软件的设计中占有重要的地位，具体的例子是：linux的模块化，这种机制是以主要开发人开发礼物赠送给开源社区，开源社区的人通过市场机制为这个礼物做出反馈并对开发人做出点赞，这种礼物-点赞的方式就是集市模型的母本了。它的产品都是开发人的副产品。

螺旋模型是以一个可以运行的原型逐渐迭代演化的模型，它是基于设计师和产品为中心的，逐步接近用户的需求，强调风险控制。这个有可能会在接下来的时间内继续扩大影响力。