边做边改模型 | 瀑布模型 | 快速原型模型 | 增量模型 | 螺旋模型 | |
思 想
| 不断的修正版本不断的供用户使用,如果出现错误或是新的需求又不断的修改代码。 | 软件的开发严格的按照线性方式进行,当前活动的工作结果,实施完成所需要的工作结果需要验证,如果验证通过,则结果作为下一项活动的输入,继续。否则返回。 | 快速原型模型利用的是原型辅助软件开发的一种思想。经过简单、快速的分析,快速实现一个原型,用户与开发人员在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高软件质量。 | 软件被看作是一系列的增量构建来设计、实现、集成和测试,每一个构建由多种相互作用的模块所形成的提供特定功能呢的代码片段构成。 开发出一部分就向用户展示一部分,及早的发现问题。先开发一个原型模型的软件,完成模型的主要功能。展示给用户征求意见。 | 这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段,由这4个阶段进行迭代。 |
优 点 | 在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。 | 一种有效的管理视图。每项开发活动均处于一个质量环节。文档驱动,以项目阶段评审和文档控制为手段有效的对整个开发过程进行指导。 | (1)快速模型克服瀑布模型的特点,减少由于软件需求不明确带来的开发风险,具有显著的效果 。(2)能快速吸引用户,从而抢占市场。 | 1.缩短时间 2.开发人员与用户可以通过原型充分的交流; 3.有利于用户的培训和开发的同步。 4.加入构建必须不破坏已构造好的体系结构。 5.模型的灵活性可以使其适应需求的变化 | (1)可以在项目的各个阶段进行变更(2)可以分段来构建大型系统,使成本计算变得简单、容易。(3)用户参与开发,保证项目不偏离正确方向。 |
缺 点 | 缺少规划和设计环节。忽略需求环节,风险大。周期长费用高。 | 缺乏灵活性,太过于理想化。 如果开发其中,客户难以明确需求,需求错误在后期就难以纠正。 | (1)没有考虑软件的整体质量和长期的可维护性。(2)这种模型在大部分情况下是不适合的,采用该模型往往是为了演示功能的需要或它的方便性。(3)由于达不到质量要求可能被抛弃,而采用新的模型重新设计。 | 很容易退化为边做边改模型 | (1)不能让用户确信这种演化方法结果是可控的。(2)建设周期长 |
适 用 场 合 | 对于需求非常简单和容易明白,软件期望的功能行为容易定义,实现的成功或失败容易检验的工程可以使用这种模型。 | 适合于客户的需求较明确的情况下。 | 用户需求不明确、小型或是交互型式的系统、大型系统的某些部分 | 技术风险较大、用户需求较为稳定的软件系统 | 适合于大型复杂的系统 |
| 迭代模型 | 喷泉模型 | 敏捷模型 | 混合模式 |
思 想 | 整个开发工作被组织为一系列的短小的、 | 软件开发过程的各个阶段是相互迭代的、无间歇的。软件的某个部分常常被重复工作多次,相关对象在每次迭代中加入渐近的软件成分。 | 把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 | 把几种不同模型组合成一种混合模型,它允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)。实际上,一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。 |
优 点 | 降低风险、得到早期用户反馈、持续的测试和集成、使用变更、提高复用性 | 可以提高软件项目开发效率,节省开发时间。 | 紧密协作、面对面的沟通 | 给企业管理者和开发者提供了一个舞台,使每个模型的长处得到发挥 |
缺点 | 项目风险可能会很高 | 不利于项目管理 | 文档少 | 对企业的管理和技术都提出了更高的要求 |
适用场合 | 早期需求变化很大,项目管理者和软件研发团队素质较高 | 面向对象的软件开发过程 | 适合小型项目 | 用户的管理和技术都较完善;开发者技术较高,知识面较广 |