开发模式_敏捷开发模式 - CSDN
  • 常用的4种开发模式

    千次阅读 2019-06-29 12:39:37
    常用的4种开发模式 1. 瀑布式开发   瀑布式开发是由W.W.Royce在1970年提出的软件开发模型,是一种比较老的计算机软件开发模式,也是典型的预见性的开发模式。在瀑布式开发模式中,开发严格遵循预先计划的需求分析...

    常用的4种开发模式


    1. 瀑布式开发

      瀑布式开发是由W.W.Royce在1970年提出的软件开发模型,是一种比较老的计算机软件开发模式,也是典型的预见性的开发模式。在瀑布式开发模式中,开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行,步骤的成果作为衡量进度的方法,例如需求规格、设计文档、测试计划和代码审阅等。瀑布式开发最早强调系统开发应有完整的周期,且必须完整地经历每个周期内的每个开发阶段,并系统化地考量分析所涉及的技术、时间与资源投入等。

      瀑布式开发的主要问题是它的严格分级导致自由度降低,项目早期即作出承诺会导致对后期需求的变化难以调整且代价很大,这在需求不明晰并且在项目进行过程中可能有变化的情况下基本上是不可行的。瀑布式开发如下图所示。

    瀑布式开发

    2. 迭代式开发

      迭代式开发也被称为迭代增量式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式的一些弱点,有更高的成功率。在迭代式开发中,整个开发工作被组织为一系列短小的、固定长度的小项目,每次迭代都包括需求分析、设计、实现与测试。采用迭代式开发时,工作可以在需求被完整地确定之前启动,并在一次迭代种完成系统的一部分功能或业务,再通过客户的反馈来细化需求,并开始新一轮的迭代。迭代式开发如下图所示。

    迭代式开发

    迭代式开发有如下特点:

    • 每次只设计和实现产品的一部分。
    • 一步一步地完成。
    • 每次设计和实现一个阶段,这叫作一个迭代。

    3. 螺旋式开发

      螺旋式开发是由巴利·波姆(Barry Boehm)在1988年正式发表的软件系统开发模型,它兼顾了快速原型的迭代特征及瀑布模型的系统化和严格监控,其最大的特点是引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减少损失。同时,在每个迭代阶段构建原型是螺旋模型用来减少风险的方法。螺旋模型更适合大型的昂贵的系统级的软件开发,一开始应用的规模很小,当项目被定义得更好、更稳定时逐渐展开。其核心在于不需要在刚开始时就把所有事情都定义清楚,可以先定义最重要的功能去实现它,然后听取客户的意见,再进入下一个阶段,入此不断循环、重复,直到得到满意的产品。螺旋模型在很大程度上是一种风险驱动的方法体系,因为在每个阶段及经常发生的循环之前,都必须先进行风险评估。螺旋式开发如下图所示。

    螺旋式开发

    螺旋式开发有如下特点:

    • 制定计划:确定软件目标,选定实施方案,弄清楚项目开发的限制条件。
    • 风险分析:分析、评估所选方案,考虑如何识别和消除风险。
    • 实施工程:实施软件开发和验证。
    • 客户评估:评价开发工作,提出修正建议,制定下一步计划。

    4. 敏捷软件开发

      敏捷软件开发又被称为敏捷开发,是一种从1990年开始逐渐引起人们广泛关注的新型软件开发方式,具有应对快速变化的需求的软件开发能力。它的具体名称、理念、过程、术语都不尽相同,相对于非敏捷开发,更强调程序员团队与业务专家之间的紧密协作及面对面沟通,比单纯通过书面文档沟通更有效,能更频繁地交付新的软件版本,使自我组织、自我约束的团队能够更好地适应需求的变化,也更注重软件开发过程中人的作用。如下图所示。

    敏捷开发

    敏捷软件开发有如下特点:

    • 首要任务是尽早地、持续地交付可评价的软件,以使客户满意。
    • 乐于接受需求变更,即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化,从而赢得竞争优势。
    • 频繁交付可使用的软件,交付的间隔越短越好,可以从几个月缩减到几个星期。
    • 在整个项目开发期间,业务人员和开发人员必须朝夕工作在一起。
    • 围绕那些有推动力的人们来构建项目,给予他们所需的环境和支持,并且相信他们能够把工作做好。
    • 开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈。
    • 可使用的软件是进度的主要衡量指标。
    • 提倡可持续发现。出资人、开发人员及使用者应该共同维持稳定的开发速度。
    • 为了增强敏捷能力,应持续关注技术上的杰出成果和良好的设计。
    • 简洁,最小化那些没有必要投入的工作量是至关重要的。
    • 最好的架构、需求和设计都源于自我组织的团队。
    • 团队定期反思如何变得更有战斗力,然后相应地转变并调整其行为。

    4种开发模式总结


    • 瀑布式开发:在从需求到设计、从设计到编码、从编码到测试、从测试到提交的每个开发阶段都要做到最好,特别是在前期阶段设计得越完美,提交后的损失就越少。然而现在的系统很复杂且多变,所以很难在现实中应用瀑布式开发。

    • 迭代式开发:不要求每个阶段的任务都做到最好,可以容忍一些不足,先不去完善它,将主要功能先搭建起来,以最短的时间及最少的损失完成一个不完美的成果直至提交,然后通过客户或用户的反馈信息,在这个不完美的成果上逐步进行完善。

    • 螺旋开发:在很大程度上是一种风险驱动的方法体系,因为在每个阶段及经常发生的循环之前,都必须先进行风险评估。

    • 敏捷开发:和迭代式开发相比,两者都强调在较短的开发周期内提交软件,但是,敏捷开发的周期可能更短,且更强调队伍种的高度协作。敏捷方法有时被误认为是五计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性,适应性的方法主要用于快速适应需求的变化。当项目的需求有变化时,团队能够迅速应对新的需求。

    1478833-20180927095900947-103286317.jpg

    转载于:https://www.cnblogs.com/jfzhzo/p/9582013.html

    展开全文
  • 软件开发模式简介

    2018-12-30 21:15:56
     好吧,其实现在许多产品实际都是使用的“边做边改”模型来开发的,特别是很多小公司产品周期压缩的太短。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。  在这个...

    1. 边做边改模型(Build-and-Fix Model)

      好吧,其实现在许多产品实际都是使用的“边做边改”模型来开发的,特别是很多小公司产品周期压缩的太短。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。

      在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户和测试等等满意为止。

      这是一种类似作坊的开发方式,边做边改模型的优点毫无疑问就是前期出成效快。

      对编写逻辑不需要太严谨的小程序来说还可以对付得过去,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:

      1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;

      2) 忽略需求环节,给软件开发带来很大的风险;

      3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

     

    2. 瀑布模型(Waterfall Model)

      瀑布模型是一种比较老旧的软件开发模型,1970年温斯顿·罗伊斯提出了著名的“瀑布模型”,直到80年代都还是一直被广泛采用的模型。

      瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落

      在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。

      瀑布模型优点是严格遵循预先计划的步骤顺序进行,一切按部就班比较严谨。

      瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

      1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;

      2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;

      3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

      4) 各个软件生命周期衔接花费时间较长,团队人员交流成本大。

      5) 瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

     

    3. 迭代模型(stagewise model)(也被称作迭代增量式开发或迭代进化式开发)

      是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。

      在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。

      教学中,对迭代和版本的区别,可理解如下: 迭代一般指某版本的生产过程,包括从需求分析到测试完成; 版本一般指某阶段软件开发的结果,一个可交付使用的产品。

      与传统的瀑布模型相比较,迭代过程具有以下优点:

      1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。

      2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。

      3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。

      4)由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。因此复用性更高

     

    4. 快速原型模型(Rapid Prototype Model)

      快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

      显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。

      快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。

      快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。

     

    5、增量模型(Incremental Model)

      与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

      增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:

      1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。

      2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。

      在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。

      例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。

     

    6. 螺旋模型(Spiral Model)

      1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。

      螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

      1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

      2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;

      3) 实施工程:实施软件开发和验证;

      4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。

      螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:

      1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。

      2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。

      3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

      一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。

     

    7. 敏捷软件开发 (Agile development)

      敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

      敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果,关注业务优先级,检查与调整。

      敏捷软件开发要注意项目规模,规模增长,团队交流成本就上去了,因此敏捷软件开发暂时适合不是特别大的团队开发,比较适合一个组的团队使用。

     

    8. 演化模型(evolutionary model)

      主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求,并且当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现。软件开发人员根据用户的需求,首先开发核心系统。当该核心系统投入运行后,用户试用之,完成他们的工作,并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈,实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成,为整个系统增加一个可定义的、可管理的子集。

      在开发模式上采取分批循环开发的办法,每循环开发一部分的功能,它们成为这个产品的原型的新增功能。于是,设计就不断地演化出新的系统。 实际上,这个模型可看作是重复执行的多个“瀑布模型”。

      “演化模型”要求开发人员有能力把项目的产品需求分解为不同组,以便分批循环开发。这种分组并不是绝对随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出,每个开发循环以六周到八周为适当的长度。

     

    9. 喷泉模型(fountain model, (面向对象的生存期模型, 面向对象(Object Oriented,OO)模型))

      喷泉模型与传统的结构化生存期比较,具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来,可以落在中间,也可以落在最底部。

     

    10. 智能模型(四代技术(4GL))

      智能模型拥有一组工具(如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等),每个工具都能使开发人员在高层次上定义软件的某些特性,并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言(4GL)的支持。4GL不同于三代语言,其主要特征是用户界面极端友好,即使没有受过训练的非专业程序员,也能用它编写程序;它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL(如Foxpro等)都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。

     

    11. 混合模型(hybrid model)

      过程开发模型又叫混合模型(hybrid model),或元模型(meta-model),把几种不同模型组合成一种混合模型,它允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)。实际上,一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。

    12. DevOps  https://blog.csdn.net/Scrat_Kong/article/details/85410612

     

    大致列举部分常用软件过程模型的特点和适用范围:

    模型名称 技术特点 适用范围
    瀑布模型 简单,分阶段,阶段间存在因果关系,

    各个阶段完成后都有评审,允许反馈,不支持

    用户参与,要求预先确定需求

    需求易于完善定义且不易变更的软件系统
    快速原型模型 不要求需求预先完备定义,支持用户参与,

    支持需求的渐进式完善和确认,能够适应用户需求的变化

    需求复杂、难以确定、动态变化的软件系统
    增量模型 软件产品是被增量式地一块块开发的,

    允许开发活动并行和重叠

    技术风险较大、用户需求较为稳定的软件系统
    迭代模型 不要求一次性地开发出完整的软件系统,将软件

    开发视为一个逐步获取用广需求、完善软件产品的过程

    需求难以确定、不断变更的软件系统
    螺旋模型 结合瀑布模型、快速原型模型和迭代模

    型的思想,并引进了风险分析活动

    需求难以获取和确定、软件开发风险较大的软件系统
    展开全文
  • 软件的几种开发模式

    万次阅读 2016-11-04 13:32:54
    软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.演化模型 4.增量模型 5.螺旋模型 6.喷泉模型 7.敏捷模型-SCRUM 各种模型的优点和缺点  瀑布模型 文档驱动 系统可能不满足客户...

    软件工程之软件开发模型类型

    1.边做边改模型

    2.瀑布模型

    3.演化模型

    4.增量模型

    5.螺旋模型

    6.喷泉模型

    7.敏捷模型-SCRUM

    各种模型的优点和缺点

      瀑布模型 文档驱动 系统可能不满足客户的需求

      快速原型模型 关注满足客户需求 可能导致系统设计差、效率低,难于维护

      增量模型 开发早期反馈及时,易于维护 需要开放式体系结构,可能会设计差、效率低

    螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练

    1边做边改模型(Build-and-Fix Model)

      国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改. 在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。

      这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:

      (1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;

      (2) 忽略需求环节,给软件开发带来很大的风险;

    (3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

    2瀑布模型(Waterfall Model)

    1970年Winston Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接

    的固定次序,如同瀑布流水,逐级下落。

     

    在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一

    项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。

      瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

      (1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;

      (2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;

      (3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

    我们应该认识到,"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时,总是千方百计地将其分解或转化为一系列简 单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。线性是一种简洁,简 洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如增量模型实质就是分段的线性模型,螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子

    new

      早在20世纪50年代末期,软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型(stagewise model)”。迭代模型是RUP推荐的周期模型。被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:需求、分析设计、实施和测试工作流程。实质上,它类似小型的瀑布式项目。RUP 认为,所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。

    什么是迭代模型

      在现代过程方法XP(eXtreme Programming,极限编程)、RUP无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点,在发现那么多采用 了瀑布模型的失败的项目之后,不但放弃了对它的要求,而且从1994年的报告开始,积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时,中国中 科院也提倡选用迭代模型。

    迭代模型的选择

      对众多的开发模型和过程方法,及权威机构的看法,企业应选择什么样的开发模型,应慎重对从以下几方面进行考虑:

      1、RUP虽然内容极其丰富,定义了选起、精化、构建、产品化4个阶段和业务建模、需求、分析设计、实现、测试、部署等9个工种,提供了一大堆的文档模板,但极易让人误解是重型的过程,实施推广有一定难度。

       2、再次,在质量管理方面:以实现系统架构、核心功能目标的迭代产品生的工作成果作为质量控制重点。每次迭代进行系统集成、系统测试,达到对软件质量的持续验证。每次系统测试,需要回归测试前一次迭代遗留发现的问题。每次迭代发布的小版本组织客户(包括内部客户、外部客户)进行评价,通过演示 操作等方式,评价该次迭代是否达到预定的目标,并以此为依据来制定下一次迭代的目标。

       3、最后,在其他方面:每次迭代成果须进行配置管理,版本控制很重要。在整个迭代过程中风险无处不在,建议每周作一次风险跟踪。同时通过重点关注进度、工作量、满意度、缺陷等数据收集,关注每次迭代情况。

       总之,选择一个合适的生命周期模型,并应用正确的方法,对于任何软件项目的成功是至关重要。企业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的生命周期模型。


    迭代模型的使用条件

      1、在项目开发早期需求可能有所变化。

      2、分析设计人员对应用领域很熟悉。

      3、高风险项目。

      4、用户可不同程度地参与整个项目的开发过程。

      5、使用面向对象的语言或统一建模语言(Unified Modeling Language,UML)。

      6、使用CASE(Computer Aided Software Engineering,计算机辅助软件工程)工具,如Rose(Rose是非常受欢迎的物件软体开发工具。)。

      7、具有高素质的项目管理者和软件研发团队。


    迭代模型的优点

      与传统的瀑布模型相比较,迭代过程具有以下优点:

       1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。

       2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。

       3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。

      4)由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

    螺旋模型(Spiral Model)

      1988年,Barry Boehm正式发表了软件系统开发的"螺旋模型",它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

      (1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

      (2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;

      (3) 实施工程:实施软件开发和验证;

      (4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。

      螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:

      (1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。

      (2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。

      (3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

    一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建 造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。

    增量模型(Incremental Model)

      又称演化模型。与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多 种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产 品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:

      (1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。

      (2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。

      在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。

    例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能

    快速原型模型(Rapid Prototype Model)

       

      快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。 通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

      显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。

    快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。

    敏捷软件开发模型--SCRUM

    一 什么是Scrum?

    Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种,在最近的一两年内逐渐流行起来。

    Scrum的基本假设是:

    开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,确保每天、每个阶段都朝向目标有明确的推进。

    Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部分,开发团队必须尽力于 30 天后交付成果,团队每天用 15 分钟开会检查每个成员的进度与计划,了解所遭遇的困难并设法排除。

    二 Scrum较传统开发模型的优点

    Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。


    下图是Scrum模型和传统模型的对比:

          

    三 Scrum模型

    一)  有关Scrum的几个名词

    backlog: 可以预知的所有任务, 包括功能性的和非功能性的所有任务。

    sprint:一次跌代开发的时间周期,一般最多以30天为一个周期.在这段时间内,开发团队需要完成一个制定的backlog,并且最终成果是一个增量的,可以交付的产品。

    sprint backlog:一个sprint周期内所需要完成的任务。

    scrumMaster: 负责监督整个Scrum进程,修订计划的一个团队成员。

    time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

    sprint planning meeting: 在启动每个sprint前召开。一般为一天时间(8小时)。该会议需要制定的任务是:产品Owner和团队成员将backlog分解成小的功能模块,  决定在即将进行的sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

    Daily Scrum meeting:开发团队成员召开,一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目:今天完成了什么? 是否遇到了障碍? 即将要做什么?通过该会议,团队成员可以相互了解项目进度。

    Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

    Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。



    二)实施Scrum的过程简单介绍

    1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
    2) 召开sprint planning meeting,划分,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的,并不是按人天计算。
    3) 进入sprint开发周期,在这个周期内,每天需要召开Daily Scrum meeting。
    4) 整个sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner.
    5) 团队成员最后召开Sprint retrospective meeting,总结问题和经验。
    6) 这样周而复始,按照同样的步骤进行下一次Sprint.

    整个过程如下图所示:


    展开全文
  • 什么是软件开发模式

    2020-09-05 14:53:51
    软件开发模式这个词在学校的时候就接触,出名的瀑布模式、螺旋模式都清楚是怎么回事,但是却在网络上找不到其定义。 今天我斗胆给个基础定义,抛砖引玉。 软件开发模式,首先是一种模式,所谓模式就是一种被大家认可...

    软件开发模式这个词在学校的时候就接触,出名的瀑布模式、螺旋模式都清楚是怎么回事,但是却在网络上找不到其定义。

    今天我斗胆给个基础定义,抛砖引玉。

    软件开发模式,首先是一种模式,所谓模式就是一种被大家认可有效解决问题的一种成熟方法。软件开发,则是讲软件需求开发交付的过程,包含了需求分析、方案设计、代码开发、测试评估、发布交付的过程。
    结合起来,软件开发模式则是软件开发遵循的行之有效的方法。该方法和软件开发对象、开发人员的能力、基础支撑设施的情况是否适配决定了开发效率的高低、软件开发的成本以及竞争力。

    展开全文
  • 什么是软件开发模式

    千次阅读 2019-04-09 00:05:43
    软件开发模式简介 1. 边做边改模型(Build-and-Fix Model)  好吧,其实现在许多产品实际都是使用的“边做边改”模型来开发的,特别是很多小公司产品周期压缩的太短。在这种模型中,既没有规格说明,也没有经过...
  • java23种开发模式

    千次阅读 多人点赞 2018-01-08 14:46:46
    设计模式(Design Patterns)  ——可复用面向对象软件的基础 设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更...
  • 软件开发模式

    千次阅读 2019-03-01 09:47:30
    迭代开发 螺旋模型 敏捷开发 瀑布模型 瀑布模型是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划...
  • 四种开发模式 得区别

    万次阅读 2018-08-20 17:57:50
    敏捷开发模式 敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",...
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
  • APP的三种开发模式

    2019-04-11 16:18:42
    开发者们都知道在高端智能... 因为这些高端智能手机(Iphone、Android)的内置浏览器都是基于webkit内核的,所以在开发WEBAPP时,多数都是使用HTML5和CSS3技术做UI布局。当使用HTML5和CSS3l做UI时,若还是遵循着一...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    传统的开发模式和敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...
  • 瀑布开发模式和敏捷开发模式的区别和思考

    万次阅读 多人点赞 2017-04-12 14:18:54
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  • 1、了解开发模式与编辑模式,开发前的一些准备。 2、开发模式用户、微信服务器、个人服务器是如何交互的。什么是接口。 3、各种接口功能的调用与实现。 4、js-SDK的调用 微信公众号开发两种模式:编辑模式和...
  • WebLogic开发模式、生产模式区别及相互转换的方法 WebLogic有两种工作模式,一种是开发模式,另一种是生产模式。开发模式下,启用了自动部署;生产模式下,关闭了自动部署。自动部署是一个标志,它使得配置或...
  • tomcat的开发模式和生产模式

    千次阅读 2016-04-18 18:06:26
    tomcat这两种模式对大家的影响主要是在jsp的开发当中。... 在开发模式下容器会经常检查jsp文件的时间戳来决定是否进行编译,如果jsp文件的时间戳比对应的.class文件的时间戳晚就证明jsp又进行了修改,需要
  • 微信企业号开发—开发模式的开启

    千次阅读 2015-02-28 16:02:24
    首先说微信企业号的开发模式分为:编辑模式(普通模式)和开发模式(回调模式),在编辑模式下,只能做简单的自定义菜单和自动回复消息,要想实现其他功能还得开启开发者模式。 一、编辑模式和开发模式对消息的处理...
  • java web几种开发模式

    千次阅读 2012-04-20 01:45:57
    ava Web开发方案有多种可供选择,这里列举一些经典的开发模式进行横向比较,为Java Web的开发模式选择提供参考。除此之外还有好多方案(如Tapestry和Wicket)并不了解,这里就不列举了。 JSP+JAVABEAN开发模式:...
  • 微信公众号开发系列-启用开发模式

    千次阅读 2014-11-15 20:39:41
    微信公众平台分为两种模式:编辑模式与开发模式; 微信公众帐号申请成功后,要想用程序接收处理用户的请求,就必须要在“高级功能”里进行配置,点击“高级功能”。 从微信开发平台开发者中心中可以看到,高级功能...
  • 三种TDD开发模式

    千次阅读 2017-02-08 13:12:11
    首先了解一下这三个开发模式都是什么意思: TDD:测试驱动开发(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元...
  • JavaWeb开发模式1.C/S开发模式1.C/S架构:客户端Client/服务端Server:a.出现较早,主要应用于局域网内; b.胖客户端:需要特定软件支持(安装客户端) 逻辑关系图如下:优点: 客户端服务端直接连接,更安全,响应...
1 2 3 4 5 ... 20
收藏数 1,614,027
精华内容 645,610
关键字:

开发模式