1、瀑布模型:
瀑布模型为项目提供了按阶段划分的检查点,当前一个阶段完成后,我们只需要去关注后面的阶段,而不用再去关注之前的阶段,并且瀑布模型可以应用在迭代模型中,同时瀑布模型提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。但是瀑布模型中各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。通过过多的强制完成日期和里程碑来跟踪各瀑布模型的突出缺点是不适应用户需求的变化。
按照瀑布模型的阶段划分,软件测试可以分为单元测试,集成测试,系统测试。瀑布模型适用于那些结构不叫固定,不经常变化的项目。
2、原型模型:
原型模型是先借用已有系统作为原型模型,通过“样品”不断改进,使得最后的产品就是用户所需要的。开发人员和用户在“原型”上达成一致。这样一来,可以减少设计中的错误和开发中的风险,也减少了对用户培训的时间,而提高了系统的实用、正确性以及用户的满意程度。原型模型缩短了开发周期,加快了工程进度,并且降低了成本。
原型模型适用于开发者想要让一个原型快速运行起来,通过这种方式就可以达到目的,但是原型模型不宜利用原型系统作为最终产品。采用原型模型开发系统,用户和开发者必须达成一致:原型被建造仅仅是用户用来定义需求,之后便部分或全部抛弃,最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。
3、增量模型:
增量模型融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征,该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。增量模型由于能够在较短的时间内向用户提交一些有用的工作产品,因此能够解决用户的一些急用功能。并且由于每次只提交用户部分功能,用户有较充分的时间学习和适应新的产品。同时对系统的可维护性是一个极大的提高,因为整个系统是由一个个构件集成在一起的,当需求变更时只变更部分部件,而不必影响整个系统。但是由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而使软件过程的控制失去整体性。如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
增量模型能够在较短的时间内向用户提交一些有用的工作产品,所以适用于那些用户急用某些功能时使用。
4、螺旋模型:
螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型设计上的灵活性,可以在项目的各个阶段进行变更。它以小的分段来构建大型系统,使成本计算变得简单容易。而且客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。在螺旋模型中随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。并且客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。但是它很难让用户确信这种演化方法的结果是可以控制的。建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。
螺旋模型的项目适用于新近开发,需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更。
5 、RUP模型:
RUP(Rational Unified Process),统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。RUP具有很多长处:提高了团队生产力,在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面,针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导,并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构,为开发过程提供较大的通用性。但同时它也存在一些不足:RUP只是一个开发过程,并没有涵盖软件过程的全部内容,例如它缺少关于软件运行和支持等方面的内容;此外,它没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端,但并不完美,在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。