软件工程瀑布模型的出现是软件工程成熟的标志。在此之后人们又从实际工程中提炼出了很多的模型。例如现在都被人们称道的RAD模型，螺旋模型以及RUP模型。模型的出现给了人们一个参考的标准。然而事实证明就只是照着模型的样子就可以做出客户心目中的产品这是不现实的。对于不同的人来说理解的不一致性，分工的不同，做完工程的每一个阶段，并不等于做工程。工程不是过程的累加，不是这么随随便便就能成功的。做过程不是做工程的精义，也不是目的。
编程中实现才是目的。工程只是实现的手段。小到一个称手的工具，大到一个几千万的项目，实现才是目的。前人没有工程的概念，也照样做出了产品。他们关心的是怎么实现这个问题，客户的要求是什么样的。而现在我们有了工程，却放错了关注的焦点，我们把重心放在了工程要怎么做，工程要求怎么做上，然而结果却是工程完成了，过程的每一步都完成了，然而却没有实现每一个目标。
为了工程而工程，让我们迷失了自己。我们关心的是怎么把工程图画的更完美一点而不是花时间考虑客户的要求工程的目标。在沟通中，我们也是走过场。每个部门都按照自己的想法描述了工程的情况，而没有论及任何事关客户意图的事情，就像演戏一样，一切都完成了，一遍遍的排练，只是过场的话，将会是无休止的演出，最后也将会是以项目的失败告终。
模型用的好，将是软件行业对客户的福利。瀑布模型描述了开发的主要环节，后来一群人把这些环节捏来捏去或反复叠加，就成了RAD,RUP以及其他的未知模型。应用的好的当属被称为“日本IT工业开发史的活字典”的V模型。
在日本近年来老龄化严重，因此劳动力短缺导致的劳动输入和项目外包，直接影响了它的组织管理模式。因此根据实际问题的需要，V模型应运而生。模型的左端是外包给的团队或公司，右端则是日本企业软件中有丰富经验的工程人员。这样既节省人力，又可以保障工程质量。那么根据我们实际情况的需要，瀑布模型是不是也可以为我们所用，将它改变成勋章模型，烟斗模型呢？答案是肯定的。当我们做完工程后，回头反思一下，是不是我们的工程里也蕴含着宝藏般的经验呢？或许你会有着惊人的发现。
学习要学其精髓。学一些实实在在的东西。越是简单的东西，往往越接近本质。学习瀑布模型，可思过程的本质，学习RUP不成只剩一些文档模版可抄。如果懂得模型都可以换做最原始的瀑布模型，而文档的书写却可以是XP或者RUP，你还会去选择架子上的东西么？
工程不是做出来的。工程需要组织。项目经理行驶好角色，让每个人都有适合的工作去完成，并把大家都联系在一起。工程择日就完工。