瀑布模型/改进的瀑布模型
虽然瀑布模型还存在许多问题，但是瀑布模型仍然是最基本有效的软件开发生命周期模型。 瀑布模型要求软件开发严格遵循需求-分析-设计-编码-测试阶段，每个阶段都可以定义明确的交付件和验证标准。 瀑布模型在每个阶段完成后，可以组织相关的评审和验证，只有在评审通过后才能进入下一个阶段。
由于每个阶段都需要验证，瀑布模型在每个阶段都需要生产明确的文档，对于严格的瀑布模型，每个阶段不应该重叠，应该通过审查，相关产品基线化后再进入下一个阶段
瀑布模型的优点仍然是保证整个软件产品的高质量，缺陷可以早期发现和解决。 采用瀑布模型，可以充分掌握整个系统，使系统具有良好的可扩展性和可维护性。 但是，在前期需求不明确、短时间内难以明确的项目中，很难很好地利用瀑布模型。 此外，在中小型项目中，需求设计和开发人员往往在项目启动后全部投入项目中，而不是分阶段投资，因此采用瀑布模型可能会导致项目人力资源过度闲置。 这也需要考虑。
很多人往往不选择瀑布模型就受制于进度，这往往是错误的看法。 造成这种状况的一个重要因素往往是概念需求阶段的人才短缺。 因此，在概念需求阶段人才得到充分保证的情况下，瀑布模型和迭代模型在开发周期上没有很大的差异。 相反，很多项目对迭代模型和敏捷模型运行不佳，为了加快进度，前期需求不明确，不经过整体架构设计就开始编码，后期会出现很多返工
体系结构设计是软件开发中的重要热点问题之一。 因此，RUP中也提到软件开发要以体系结构为中心。 因此，在架构设计完成后，系统被分为相关的子系统和功能模块。 各功能模块之间的接口可以明确定义。 在这种情况下，在模块b的详细设计完成之后，通常不需要在其他模块的详细设计完全完成之前开始编码。 因此，体系结构设计完成后，可以将系统分成多个模块并行开发，每个模块仍然遵循先设计编码测试的瀑布模型的思路。这是瀑布模型最重要的改进思路
如果在一个新系统的开发中存在多个完全无关的独立需求的功能开发，则也可以将整个开发过程按独立需求分为多个小瀑布来操作。 这种方式最大的问题是没有完整的总体设计，体系结构设计人员在了解所有需求的基础上，无法从系统的可扩展性、复用等方面进行总体规划。
由于项目管理有一种压缩应急进度的方法，瀑布模型的其他改进将各个阶段的过程进行了适当的重叠，达到了资源的有效利用。 例如，通过我们的讨论，会议决定的实现方式可以监督下一阶段的工作，而不用完全等待相关成果记录下来。
螺旋模型
首先，螺旋模型遵循瀑布模型。 这就是需求-体系结构-设计-开发-测试的途径。 螺旋模型的最大价值是整个开发过程以迭代和风险驱动。 通过将瀑布模型的多个阶段转换为多个迭代过程来降低项目风险。
螺旋模型的每个迭代包括六个步骤：
1 .确定目标、备选方案和制约
2 .确定和解决项目风险
3 .评价技术方案和备选方案
4 .本次迭代成果开发和迭代生产正确性验证
5 .计划下一次迭代
6 .提出下一步迭代的步骤和方案。
螺旋模型实现了随着项目成本投入的增加，风险逐渐减小。 加强对项目的管理和跟踪，每次迭代结束都需要对成果进行评估和验证，如果发现无法再进行下去，可以提前终止项目。
螺旋模型的复杂之处在于尽职尽责，专注于专业知识和深度管理。 因为要为每次迭代制定明确的目标，分析能够在相关重要风险和计划中进行验证和测试的成果并不是一件容易的事情。
螺旋模型的每个迭代只包含瀑布模型的一个或两个阶段。 例如，第二次迭代侧重于需求，第三次迭代是总体设计和后续设计开发计划等。 因此，这与RUP建议的迭代模型不同，RUP的每个迭代包括需求、设计、开发和测试等各个阶段的活动。 RUP迭代的目的不是完成瀑布模型的某个阶段的工作，而是逐步努力。
增量和迭代模型
增量迭代是RUP集成过程中常用的软件开发生命周期模型。 增量和迭代有区别，但两者经常一起使用。 因此，这里首先说明增量和迭代的概念。 假设目前开发a、b、c、d四大业务功能，每个功能的开发需要两周时间。 增量方法可以将四个功能分为两次增量完成，第一次增量完成a、b的功能，第二次增量完成c，而迭代开发则分为两次迭代进行开发。 第一次迭代完成a、b、c、d四个基本业务功能，但不包含复杂的业务逻辑，第二个功能完全细化补充相关业务逻辑。 第一个月后，开始采用增量时，a、b都开发完成，c、d一点也没有动； 而采用迭代开发时，a、b、c、d四个基础功能均已完成。 RUP强调的每次迭代都包含需求、设计和开发、测试等各个过程，而且是每次迭代完成都可以交付的原型。 迭代不是并行的，每次迭代遵循需求-设计-g
t;开发的瀑布过程.迭代周期的长度跟项目的周期和规模有很大的关系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周一次迭代.如果项目没有一个很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相关的交付和产出.因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好的模型.就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决.但迭代模型在这方面更有优势.迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化.
业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量.同时每个增量也可以是独立发布的小版本.由于系统的总体设计往往对一个系统的架构和可扩展性有重大的影响,因此我们推荐的增量最好是在架构设计完成后再开始进行增量,这样可以更好的保证系统的健壮性和可扩展性.
原型法
原型一般都不是单独采用的一种生命周期模型,往往会结合瀑布和增量迭代等方法一起使用.对于螺旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期模型.对于迭代开发来讲,每一个迭代周期的产出都可以看做是下个阶段要精化的原型.而对于瀑布模型开发来讲,我们在需求阶段也可以进行界面和操作建模,形成DEMO后和用户做进一部的需求沟通和确认.
yydcb的用户没有信息系统的使用经验,你的系统分析员也没有过多的需求分析和挖掘经验的时候,需求分析和调研过程则更需要是一个启发式的过程.而原型则是这种很好的启发式方法,可以快速的挖掘用户需求并达成需求理解上的一致.否则即使双方都签字认可的需求往往仍然不是客户真正想要的东西.
原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的DEMO,则这种原型一般都建议抛弃掉.而对于迭代开发来将,每次迭代的产出都是可以独立运行和包含基础功能的系统,是后续细化的基础,这类原型一般都不建议抛弃,后期的设计开发也要基于该原型逐渐的进行完善.
快速和敏捷开发
我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是减少繁重和不必要的工件的输出,提高效率.而不是要我们去挑阶段或过程,不是分析设计都还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.
关于选择生命周期模型的最后的总结
1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4.在需求不稳定情况下尽量采用增量迭代模型
5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则。