原型法

　　原型一般都不是单独采用的一种生命周期模型,往往会结合瀑布和增量迭代等方法一起使用.对于螺旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期模型.对于迭代开发来讲,每一个迭代周期的产出都可以看做是下个阶段要精化的原型.而对于瀑布模型开发来讲,我们在需求阶段也可以进行界面和操作建模,形成DEMO后和用户做进一部的需求沟通和确认.

　　当你的用户没有信息系统的使用经验,你的系统分析员也没有过多的需求分析和挖掘经验的时候,需求分析和调研过程则更需要是一个启发式的过程.而原型则是这种很好的启发式方法,可以快速的挖掘用户需求并达成需求理解上的一致.否则即使双方都签字认可的需求往往仍然不是客户真正想要的东西.

　　原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的DEMO,则这种原型一般都建议抛弃掉.而对于迭代开发来将,每次迭代的产出都是可以独立运行和包含基础功能的系统,是后续细化的基础,这类原型一般都不建议抛弃,后期的设计开发也要基于该原型逐渐的进行完善.

　　快速和敏捷开发

　　我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是减少繁重和不必要的工件的输出,提高效率.而不是要我们去挑阶段或过程,不是分析设计都还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.

　　关于选择生命周期模型的最后的总结

　　1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
　　2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
　　3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
　　4.在需求不稳定情况下尽量采用增量迭代模型
　　5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
　　6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
　　7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
　　8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
　　9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.