软件生命周期的瀑布模型是什么啊？

首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。 然而轻易抛弃瀑布模型的观点也是非常错误的，瀑布模型还是所有软件开发模型的基础，体现了软件开发的本质过程。对于一些大型 的软件项目，试图过于简化瀑布的前期的需求和设计阶段，用一个简单的原型或者迭代来模拟未来的系统，并试图帮助确认和挖掘客户的需求，是不可能的，不仅此时离客户的最终需求和隔山万千重，系统的架构也会随着过程而有很大被抛弃和大幅调整的过程，原型也就起不到原型的作用，成本和时间反而浪费，所以前期的功课还是少不了的，尤其对于复杂系统。即使对于简单如定制一件衣服，在给客户提出修改的时候，它要基本是一件衣服，而不是几块布片，否则客户无从提出进一步的需求，前期的功夫也是白费的。