软件生命周期模型

瀑布型：
    思想：
       从制作时间上按工序把问题化简
       将功能实现与制作分开便于分工协作
    优点：
       奠定了软件工程方法的基础
       流水依赖，便于分工协作

       推迟物理实现，易于修改文档，有复审质量保证

    不足

  瀑布型的主要缺点是没有把软件看作是一个问题求解的过程，瀑布模型产生于硬件领域，它是从制造业的角度看软件开 发，但是，制造业是重复产生某一特定的产品，而软件并不是这样开发的，相反，随着人们对问题的逐步理解和候选方案的评估，软件在不断的演化，因此，软件是一个创造的过程，而不是一个制造的过程。瀑布模型并没有说明我们创建最终产品过程中所需的往返活动的任何特有信息。尤其是创造通常包含不同的尝试、开发、和评估原型，评价需求的可行性、比较若干种设计以及从失败的教训中学习，从而最终决定令人满意的解决方案。

    适用范围：
        适用于系统要求明确的系统

        各种应用软件的开发均可使用 

    开发方法：   

   遵循软件生命期的划分，明确规定每个阶段的任务，上一阶段完成确定的任务后就产生一定格式的文档给下一阶段，不同 阶段的任务一般有不同级别的软件人员承担。

    开发特点：
        时间的顺序性和依赖性
        推迟实现的观点
        质量保证的观点
                                    瀑布型 图示
                                                          
                                                         
渐增模型
    基本思想：
       允许从部分需求出发，先建立一个不全面的系统通过测试这个系统，进一步使系统扩充和完善
    优点：

  开发的始终开发人员和用户都共同参与，有问题可以随时修改，从而很好的满足了用户的需求。

    适用范围：
       适用与那些知识型软件系统的开发
    特点：
       从整体结构上不如瀑布型清晰
       软件的文档不如瀑布型的划分严格
       周期长，成本高

                                    渐增型 图示

                                            

                         
螺旋模型

　  首先螺旋模型是遵从瀑布模型的.即需求->架构->设计->开发->测试的路线.螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险.

螺旋模型的每一次迭代都包含了以下六个步骤

　　1.决定目标,替代方案和约束

　　2.识别和解决项目的风险

　　3.评估技术方案和替代解决方案

　　4.开发本次迭代的交付物和验证迭代产出的正确性.

　　5.计划下一次迭代

　　6.提交下一次迭代的步骤和方案.

　  螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目.

　  螺旋模型复杂的地方在于尽责,专心和知识渊博的管理.因为对于每一次迭代我们要制定出清晰的目标,分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情.

　  螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等.因此这是和RUP提倡的迭代模型是有区别的,RUP的每一次迭代都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶段的工作.

                                                            

                              螺旋型图示

                                                        

喷泉模型

     喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动，即分析、设计和编码之间不存在明显的边界。   

                                         喷泉模型图示

                                                                

增量和迭代模型

　  增量迭代是 RUP统一过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常一起使用.所以这里要先解释下增量和迭代的概念.假设现在要开发 A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成.

    RUP强调的每次迭代都包含了需求,设计和开发,测试等各个过程,而且每次迭代完成后都是一个可以交付的原型.迭代不是并行,在每次迭代过程中仍然要遵循需求->设计->开发的瀑布过程.迭代周期的长度跟项目的周期和规模有很大的关系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周一次迭代.如果项目没有一个很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相关的交付和产出.因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好的模型.

    就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决.但迭代模型在这方面更有优势.迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化.

　  业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量.同时每个增量也可以是独立发布的小版本.由于系统的总体设计往往对一个系统的架构和可扩展性有重大的影响,因此我们推荐的增量最好是在架构设计完成后再开始进行增量,这样可以更好的保证系统的健壮性和可扩展性.

                                        

原型法

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

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

　  原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的 DEMO,则这种原型一般都建议抛弃掉.而对于迭代开发来将,每次迭代的产出都是可以独

    立运行和包含基础功能的系统,是后续细化的基础,这类原型一般都不建议抛弃,后期的设计开发也要基于该原型逐渐的进行完善.

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