软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目开发的基础
1.瀑布模型(waterfall model)
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布开发名称的由来。
特点:
1. 阶段间具有顺序性和依赖性。
2. 推迟程序的物理实现。
3. 质量保证:每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。
4. 易于组织,易于管理:因为你可以预先完成所有计划。
5. 是一种严格线性的、按阶段顺序的、逐步细化的过程模型(开发模式)
适用场合:
1. 当有一个稳定的产品定义和很容易被理解的技术解决方案时,纯瀑布模型特别合适。
2. 当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上,瀑布模型也特别合适。
3. 对于那些容易理解但很复杂的项目,采用纯瀑布模型比较合适,因为可以用顺序方法处理问题。
4. 在质量需求高于成本需求和进度需求的时候,它尤为出色。
5. 当开发队伍的技术力量比较弱或者缺乏经验时,瀑布模型更为适合。
缺陷:
1. 在项目开始的时候,用户常常难以清楚地给出所有需求;用户与开发人员对需求理解存在差异。
2. 实际的项目很少按照顺序模型进行。
3. 缺乏灵活性:因为瀑布模型确定了需求分析的绝对重要性,但是在实践中要想获得完善的需求说明是非常困难的,导致“阻塞状态”。反馈信息慢,开发周期长。
4. 虽然存在不少缺陷,瀑布模型经常被嘲笑为“旧式的”,但是在需求被很好地理解的情况下,仍然是一种合理的方法。
2.快速原型模型(Rapid Prototype Model)
快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。一旦确定了客户的真正需求,所建造的原型将被丢弃因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。
特点:
快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。原型模型比瀑布模型更符合人们认识事物的过程和规律,是一种较实用的开发框架。
适用场合:
它适合于那些不能预先确切定义需求的软件系统的开发,更适合于那些项目组成员(包括分析员、设计员、程序员和用户)不能很好交流或通信有困难的情况。
缺陷:
所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
3.增量模型(Incremental Model)
与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。
特点:
增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。
适用场合:
在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。
缺陷:
1. 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
2. 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
4.螺旋模型(Spiral Model)
螺旋模型将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。图中的四个象限代表了以下活动:
1. 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
2. 风险分析:分析评估所选方案,考虑如何识别和消除风险;
3. 实施工程:实施软件开发和验证;
4. 客户评估:评价开发工作,提出修正建议,制定下一步计划。
特点:
螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。
适用场合:
1. 内部的大规模软件开发:螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的。
2. 大规模软件项目:如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义。
缺陷:
1. 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
2. 很难让用户确信这种演化方法的结果是可以控制的。建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求
5.V-Model
V模型是一种对瀑布模型进行扩展的软件开发过程。它不采用向下移动的线性方式,而是在编码阶段完成后进程发生变化,形成典型的V形。V -模型表明了软件开发生命周期的每一阶段及其相关的测试阶段之间的关系。
特点:
把软件生命周期中基本活动的垂直关系平行的关联起来,开发活动和测试活动几乎同时的开始. 这两个并行的动态的过程就会极大的较少bug和error出现的几率.单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。
适用场合:
适用瀑布模型的场合
缺陷:
1. 把测试过程作为在需求分析、系统设计及编码之后的一个阶段
2. 忽视了测试对需求分析,系统设计的验证,一直到后期的验收测试才被发现。
总结
模型 |
优点 |
缺点 |
瀑布模型 |
文档驱动 |
系统可能不满足客户的需求 |
快速原型模型 |
关注满足客户需求 |
可能导致系统设计差、效率低,难于维护 |
增量模型 |
开发早期反馈及时,易于维护 |
需要开放式体系结构,可能会设计差、效率低 |
螺旋模型 |
风险驱动 |
风险分析人员需要有经验且经过充分训练 |