读书笔记,软件生存期模型

软件生存期模型是指软件项目的实施策略。

基本特征有:

  • 描述了开发的主要阶段
  • 定义了每一个阶段要完成的主要过程和活动
  • 规范了每一个阶段的输入和输出

常见的生存期模型有:瀑布模型,V模型,原型模型,增量式模型,渐进式模型,敏捷模型。如雷贯耳啊,哎,天天在耳边出现的这些词原来来源这里。

瀑布模型

实施起来就是如同瀑布,逐级下落。

瀑布模型的优点:

  • 1)简单、易用、直观。
  • 2)开发进程比较严格,一个进程接着一个进程进行。
  • 3)模型执行过程中需要严密控制。
  • 4)允许基线和配置早期接受控制。
  • 5)为项目提供了按阶段划分的检查点,当前一个阶段完成后,只需要关注后续阶段。

瀑布模型的缺点:

  • 1)在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。
  • 2)由于开发模型是线性的,模型中没有反馈过程,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
  • 3)一个新的项目不适合瀑布模型,除非在项目的后期。
  • 4)用户直到项目结束才能看见产品的质量,用户不是渐渐的熟悉系统。
  • 5)不允许变更或者限制变更。
  • 6)早期的错误可能要等到开发后期才能发现,进而带来严重后果。

V模型

是瀑布模型的一种变种,同样需要一步一步进行,前一阶段任务完成之后才可以进行下一阶段的任务。模型强调测试的重要性,将开发活动与测试活动紧密的联系在一起。每一步都将比前一阶段进行更加完善的测试。我以为简单的说就是提倡TDD(测试驱动开发)。

V模型的优点:

  • 1)简单易用、只要按照规定的步骤一步一步的执行即可。
  • 2)强调测试过程与开发过程的对应性和并行性。
  • 3)开发进程比较严格,执行过程需要严密控制。
  • 4)允许基线和配置早期接受控制。
  • 5)为项目提供了按阶段划分的检查点,当前一个阶段完成后,只需要关注后续阶段。

V模型缺点:

  • 1)在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。
  • 2)软件项目的实现方案需要很明确。
  • 3)允许变更或者限制变更。

快速原型模型

快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护。

原型模型的优点:

  • 1)可以克服瀑布模型的缺点,减少由于软件需求不确定带来的开发风险。
  • 2)用户根据快速构建的原型系统的优缺点,给开发人员提出反馈意见。
  • 3)根据反馈意见修改软件需求规格,以便系统可以更正确地反映用户的需求。
  • 4)可以减少项目的各种假设及风险。

原型模型的缺点:

  • 1)需求定义之前,需要快速构建一个原型系统。
  • 2)所选用的开发技术和工具不一定符合主流的发展。
  • 3)快速建立起来的系统结构加上连续的修改可能会导致产品质量的下降。
  • 4)先依赖一个可以展示模拟的产品原型,在一定程度上可能会限制开发人员的创新。

增量式模型

增量模型是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言,采用增量模型进行开发,开发人员不需要一次性地把整个软件产品提交给用户,而是可以分批次进行提交。

 

增量式模型的优点:

  • 1)软件开发可以较好地适应变化,客户可以不断的看到所开发的软件,从而降低软件开发风险。
  • 2)可以避免一次性投资太多带来的风险,首先实现主要的功能或者风险大的功能,逐步完善,保证投入的有效性。
  • 3)可以更快地开发出可以操作的系统。
  • 4)可以减少开发过程中用户需求的变更。

增量式模型的缺点:

  • 1)由于各个构件是逐渐并入已有的软件体系结构中的,因此加入构件必须不破坏已构建好的系统部分,这需要软件具备开发式的体系结构。(开放封闭原则?)
  • 2)在开发过程中,需求的变化是不可避免的。增量式模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和原型模型,但一些增量可能需要重新开发,从而使软件过程的控制失去整体性。(比如需要底层推翻重来)

渐进式模型

渐进模型(incrementalism)(连续性+微调):要求决策者必须保留对以往政策的承诺。政策制定要以现行政策为基础,不能推倒重来。
 
注重研究现行政策的缺陷。注重对现行政策的修改与补充,弥补现行政策的缺陷。
强调目标与方案之间的相互调适不是一步到位,一劳永逸,要注意反馈调节,不断微调。
各政策主体通过妥协调适、良性互动实现政策的动态均衡(dynamic equilibruim)
渐进调适,探索前进,直至满意或达到目标。
 

渐进式模型的优点:

  • 1)阶段式提交一个可运行的产品,而且每个阶段提交的产品是独立的系统(插件/模块)。
  • 2)关键的功能更早出现,可以提高开发人员和客户的信心。
  • 3)通过阶段式提交可以运行的产品来说明项目的实际进展,减少项目报告的负担。
  • 4)通过阶段式产品提交,可以早期预警问题,避免后期发现问题的高成本。
  • 5)阶段性的完成可以降低估计失误,因为通过阶段完成的评审,可以重新估算下一阶段的计划。
  • 6)阶段性完成均衡了弹性与效率,提高开发人员的效率和士气。

渐进式模型的缺点:

  • 1)需要精心规划各个阶段的目标。
  • 2)每个阶段提交的是正式版本,工作量会增加。

敏捷模型

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。

压轴模型啊,久仰大名了!

敏捷模型可以单独写好多篇文章了,先画个脑图理一下:

上图描述了3种敏捷实践:Scrum,XP,OpenUP.

敏捷宣言:

  • 个体和交互胜过过程和工具。
  • 可以工作的软件过程胜过面面俱到的文档。
  • 客户合作胜过合同谈判。
  • 响应变化胜过遵循计划。

全部模型的插图均来源于网络!随笔内容是自己亲自照着书本敲的。方法虽然笨,但是精神可嘉不是么。

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值