瀑布模式框架
特色:工具
- 阶段间具备顺序性和依赖性:
- 前一阶段完成后,才能开始后一阶段
- 前一阶段的输出作为后一阶段的输入
- 推迟实现的观点
- 质量保证:
缺点:性能
- 开始须要把需求作到最全
- 害怕用户测试中的反馈,害怕需求变动

螺旋模型
限制条件:测试
- 适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都没法接受和相信这种分析所以
- 适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无心义)
- 软件开发人员应该擅长寻找可能的风险,准确地分析风险,不然将会带来更大的风险
优势:优化
- 设计上的灵活性,能够在项目的各个阶段进行变动.
- 以小的分段来构建大型系统,使成本计算变得简单容易
- 客户始终参为保证了项目不偏离正确方向以及项目的可控性
- 客户始终掌握项目的最新信息,从而他或她可以和管理层有效地交互.
- 客户承认这种公司内部的开发方式带来的良好的沟通和高质量的产品.
缺点:编码
很难让用户确信这种演化方法的结果是能够控制的.建设周期长,而软件技术发展比较快,因此常常出现软件开发完毕后,和当前的技术水平有了较大的差距,没法知足当前用户需求.设计
核心:对象
在于您不须要在刚开始的时候就把全部事情都定义的清清楚楚.在定义最重要的功能时,去实现它,而后听取客户的意见,以后再进入到下一个阶段.如此不断轮回重复,直到获得您满意的最终产品blog
每轮循环包含以下六个步骤:接口
- 肯定目标,可选项,以及强制条件
- 识别并化解风险
- 评估可选项
- 开发并测试当前阶段
- 规划下一阶段
- 肯定进入下一阶段的方法步骤.
模型:

快速原型模型
优缺点:
- 优势: 克服瀑布模型的缺点,减小因为软件需求不明确带来的开发风险。
- 缺点: 所选用的开发技术和工具不必定符合主流的发展;快速创建起来的系统结构加上连续的修改可能会致使产品质量低下。
原型类型:
- 探索型原型: 目的是要型清用户的需求,肯定所指望的特性,并探索各类方案的可行性。它主要针对开发目标模糊,
- 实验型原型: 主要用于设计阶段,考核;实现方案是否合适,可否实陋
- 演化型原型: 主要用于及早向用户提交一个原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在获得用户的承认后,将原型系统不断扩充演变为最终的软件系统
原型的运用方式:
- 抛弃策略是将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之做废。探索型和实验型就是采用此策略的。
- 附加策略是将原型用于开发的全过程,原型由最基本的核心开始,逐步增长新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略
模型:

增量模型
构件思想:
- 第一构件完成软件提供的基本最核心的功能
- 后面的增构件是为了第一构件提供服务提供功能的
- 并且避免吧难题退后,首先完成的应该是高风险和重要部分
困难:
每一个新的构件集成到现有的软件结构中必须破坏原来以开发的产品,因此必须定义很好的接口
优势:
- 短期内向用户提供可完成部分工做的产品
- 逐步增长产品功能可使用户有时间了解和适应新产品
- 开放结构的软件拥有的维护性明显好于封闭结构的软件
缺陷:
- 容易退化为边作边改模型,从而使软件过程的控制失去总体性
- 若是增量包之间存在相交的状况且未很好处理,则必须作全盘系统分析
模型:

喷泉模型
优势:
喷泉模型不像瀑布模型那样,须要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动.该模型的各个阶段没有明显的界限,开发人员能够同步进行开发.其优势是能够提升软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程.
缺点:
因为喷泉模型在各个开发阶段是重叠的,所以在开发过程当中须要大量的开发人员,所以不利于项目的管理.此外这种模型要求严格管理文档,使得审核的难度加大,尤为是面对可能随时加入各类信息、需求与资料的状况.
模型:

演化模型
思想:
演化模型主要针对事先不能完整定义需求的软件开发.用户能够给出待开发系统的核心需求,而且当看到核心需求实现后,可以有效地提出反馈,以支持系统的最终设计和实现
开发顺序:
- 根据用户的核心需求,设计,编码,测试,后提交用户
- 精化:根据以能知足用户核心需求的核心系统上,增长用户反馈的其余所有功能
优势:
- 任何功能一经开发就能进入测试以便验证是否符合产品需求
- 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提升质量与效率
- 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提升质量与效率
- 大大有助于早期创建产品开发的配置管理
缺点:
- 主要需求开始并不彻底弄清楚的话,会给整体设计带来困难及削弱产品设计的完整性,并于是影响产品性能的优化及产品的可维护性
- 缺少严格过程管理的话,这生命周期模型极可能退化为“试-错-改”模式
- 不加控制地让用户接触开发中还没有测试稳定的功能,可能对开发人员及用户都产生负面的影响