首页 > 代码库 > 软件工程 -- 开发模型
软件工程 -- 开发模型
软件工程 -- 开发模型
目录
瀑布模式
螺旋模型
快速原型模式
增量模式
喷泉模型
演化模型
瀑布模式
特点:
阶段间具有顺序性和依赖性:
前一阶段完成后,才能开始后一阶段
前一阶段的输出文本为后一阶段的输入文本
推迟实现的观点
质量保证:
每个阶段必须交付出合格的文档
对文档进行审核
缺点:
开始需要把需求做到最全
惧怕用户测试中的反馈,惧怕需求变更
mux
螺旋模型
限制条件:
适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此
适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义)
软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
优点:
设计上的灵活性,可以在项目的各个阶段进行变更.
以小的分段来构建大型系统,使成本计算变得简单容易
客户始终参为保证了项目不偏离正确方向以及项目的可控性
客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互.
客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品.
缺点:
很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求.
核心:
在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚.在定义最重要的功能时,去实现它,然后听取客户的意见,之后再进入到下一个阶段.如此不断轮回重复,直到得到您满意的最终产品
每轮循环包含如下六个步骤:
确定目标,可选项,以及强制条件
识别并化解风险
评估可选项
开发并测试当前阶段
规划下一阶段
确定进入下一阶段的方法步骤.
模型:
快速原型模型
优缺点:
优点: 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。
缺点: 所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
原型类型:
探索型原型: 目的是要型清用户的需求,确定所期望的特性,并探索各种方案的可行性。它主要针对开发目标模糊,
实验型原型: 主要用于设计阶段,考核;实现方案是否合适,能否实陋
演化型原型: 主要用于及早向用户提交一个原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到用户的认可后,将原型系统不断扩充演变为最终的软件系统
原型的运用方式:
抛弃策略是将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的。
附加策略是将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略
模型:
增量模型
构件思想:
第一构件完成软件提供的基本最核心的功能
后面的增构件是为了第一构件提供服务提供功能的
而且避免吧难题退后,首先完成的应该是高风险和重要部分
困难:
每个新的构件集成到现有的软件结构中必须破坏原来以开发的产品,所以必须定义很好的接口
优点:
短时间内向用户提供可完成部分工作的产品
逐步增加产品功能可以使用户有时间了解和适应新产品
开放结构的软件拥有的维护性明显好于封闭结构的软件
缺陷:
容易退化为边做边改模型,从而使软件过程的控制失去整体性
如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析
模型:
喷泉模型
优点:
喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动.该模型的各个阶段没有明显的界限,开发人员可以同步进行开发.其优点是可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程.
缺点:
由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理.此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况.
模型:
演化模型
思想:
演化模型主要针对事先不能完整定义需求的软件开发.用户可以给出待开发系统的核心需求,并且当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现
开发顺序:
根据用户的核心需求,设计,编码,测试,后提交用户
精化:根据以能满足用户核心需求的核心系统上,增加用户反馈的其他全部功能
优点:
任何功能一经开发就能进入测试以便验证是否符合产品需求
开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
大大有助于早期建立产品开发的配置管理
缺点:
主要需求开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性
缺乏严格过程管理的话,这生命周期模型很可能退化为“试-错-改”模式
不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响