软件开发模型之一 万祖归宗是瀑布
案例
案例一
某公司承接了一个电子政务平台的项目，该项目主要分“政务办公”与“政务公开” 两大部分。甲方很配合，协助整理了国家电子政务管理规范与相当文档。沟通拟定的开发周期也相对宽松。
甲方聘请了监理；三方各派代表成立项目控制委员会（CCB）。公司也在项目团队中派了长驻QA小组，协助项目管理。
但是，电子政务并不是公司的主营业务，整个研发团队是公司临时招聘组建，约六人左右，大多是应届毕业，除了项目经理之外，最有经验的也不过两三年开发经历。
针对这种情况，作为项目经理，应该采用哪种开发模式比较合理？
案例二
当项目刚开始不久，甲方接到通知，要在当年国庆前后参加全国电子政务网站评比，当地主管领导希望能在九月份先进行本地区评比。准备充足后，再备战全国评比。而此时，刚过五一，总计用于研发时间也就四个月左右。
项目主管在了解情况后，向CCB提出项目变更申请，考虑先做前端功能，后端仅做现阶段需要的模块。同时，向公司申请从其它项目组，抽调技术骨干到该项目组协助。
经各方协商，以上方案得到支持，项目范围、开发计划的变更得到认可；公司抽调三名有多年协作经验的老员工，到该团队参与开发。
在这种情况下，作为项目经理，应该采用哪种开发模式？
案例三
最终，该电子政务平台项目完满成功。团队成员觉得可以考虑将该项目转化为产品，作为一项稳定业务看待，向公司建议后，得到公司高层支持，公司内部通过评审，确定以上思路。项目经理转为产品研发经理，从事产品化工作。
在评审过程中，也顾虑到很多问题，具体如下：
研发经理考虑到在项目开发中，由于工期限制，程序架构不够灵活，产品化后调整工作量会比较大，存在技术风险；
公司高层认为，市场定位依然不够明晰，大幅投资不太现实，现阶段仅限尝试。
在这种情况下，该研发经理，应该采用哪种开发模式？
分析
当然在实际开发中，情况各不相同，在同一个开发周期内，使用多个开发模型也是很正常的。在这里，为了方便讲解，我仅列举主要的开发模型。
案例一
第一种情况，首选瀑布模型
几乎在所有软件开发模型中（除了瀑布模型），都会说，“由于传统的瀑布式开发……”，然后都是它的一堆问题。我们听了它太多的不足，却很少有人关注它的优势了。几乎在所有的软件工程章节中，介绍软件开发模型时，无一例外第一个就是“瀑布”，可见瀑布模型的重要性。我可以这么说，软件开发模型万祖归宗是“瀑布”。其它的开发模型都是为了解决瀑布模型的缺陷而产生的，没有哪个可以颠覆瀑布模型。
我们看看上述项目情况，最大的不利之处是项目团队不成熟，技术强弱先不说，新团队沟通肯定存在障碍，而且成员稳定性有待考验，越是新人离职率越高。
说一句名言，“新团队，用新技术，开发新产品，成功率接近零”。而对一个新团队来说，当务之急是规范化管理，瀑布模型是比较容易实施规范的。虽然它应对需求变化时不够灵活，但在上述情况上，需求范围相对明确，开发周期相对宽松，虽然细节还需要沟通，但可以用时间弥补变更影响。
另一方面，甲方聘请监理，监理会遵循成熟的项目过程管理的方法，CMMI将是他的首先理论依据。虽然程序员会认为文档是形式化的东西，但是监理一定会要。
文档驱动是瀑布模型的最大特点，是它的优势，也是它的劣势。
案例二
第二种情况 可以采用RUP模型
当研发周期被缩短后，并不代表监理将不再监管项目。他依然会按照项目过程管理的方法来监管，只是有可能要求的不那么严格了。
新增加的三名老员工，不仅提升了技术力量，也有效弥补了沟通上的不足。在开发人力上，九名成员已经相当充沛了。虽然需求细节不明确，但需求范围是比较明确的。所以，团队成员面临的最大问题是如何应对需求不明晰带来的影响。
团队成员决定，尽可能把各项工作提前。例如，哪些需求明确了，就开始设计哪些；哪些设计了，就开始开发哪些；哪些开发了，哪些开始测试……，整体仍然按瀑布式的方式走，但各个环节相互交叠，通过迭代 逐渐精化各个环节。总之，搞清楚哪些就先做哪些。这个理念是不是很像敏捷开发？不，它不是，这种开发模型是RUP（统一过程）。
敏捷开发与RUP还是有区别的，以后再说。
案例三
第三种情况 建议采用螺旋模型
当项目转为产品时，会面临很多问题。首先是“技术债务”，快速开发会造成大量垃圾代码，虽然公司提倡重构，但项目结束后，骨干力量被抽走，个别成员离职，等等原因，很难会有机会、有人再对项目进行重构。只能在以后的工作日，逐渐改善。这其中就隐含了技术风险。
再加上产品化的市场定位问题，营销的不确定性，经营风险也会被公司权衡。公司会考虑，先做一段试试，如果做得好，就继续做，如果不行就另做打算。
在这种情况下，风险的控制是当前开发中的最大问题，而螺旋模型就是针对此类问题而生。
每个螺旋过程，首先是风险分析、需求确定、计划、实施、评测；达到一个阶段后，再进行风险分析，如果可行，就进入下一个螺旋。
要注意的是，每一个螺旋，就是一个小瀑布。
后记：精义入神，以致用
上述案例只是为了方便大家理解开发模型的特点，还有很多细节未能涉及。关键是，理解了它，才能更加有效的利用它。不同的开发模型，针对不同的问题有特效，我在前文中用粗体标识出了。在我看过的大多数软件工程书中，这三种开发模型都是在列的，很具典型性。
除了上述三种开发模型，还有喷泉模型、V型、微软开发模型等等，甚至还有原型开发模型，但我个人认为欠妥 ，原型开发不能算模型，它就像敏捷开发一样，只能算开发方法。
“精义入神，以致用（引自《周易》）”