精华内容
下载资源
问答
  • 功能驱动开发模式

    2021-03-03 04:26:22
    FDD(Feature-DrivenDevelopment)是由PeterCoad、JeffdeLuca、EricLefebvre共同开发的一套针对中小型软件开发项目的开发模式。FDD是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、易于被开发团队接受,...
  • SCRUM(敏捷开发模式)演讲PPT,SCRUM(敏捷开发模式)演讲PPT
  • 什么是软件开发模式

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

    软件开发模式简介

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

     

    展开全文
  • 什么是敏捷开发1.1 敏捷开发的定义1.2 敏捷开发的原则1.3 敏捷开发的特点1.4 传统的开发模式和敏捷开发模式的对比1.5 敏捷开发的分类1.5 Scrum 一. 什么是敏捷开发 1.1 敏捷开发的定义 2001年,由Martin Fowler,...

    一. 什么是敏捷开发

    1.1 敏捷开发的定义

    2001年,由Martin Fowler,Jim Highsmith等17位软件开发专家在美国犹他州召开了雪鸟会议,会议上正式提出了敏捷开发概念,并共同签署了敏捷宣言,敏捷联盟成立。
    敏捷开发不是具体的指导性方法,它是一种观点和价值观,敏捷开发提供了一种思维方法,但真正的敏捷开发并不告诉大家怎么做。

    敏捷开发以用户需求为核心,采用迭代循序渐进的方法进行软件开发。它强调适应性而非预测性,强调以人为中心,而不是以流程为中心。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果经过测试,都具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成。在此过程中,软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。开发宣言如下:

    • · 个体和交互胜过过程和工具。
    • · 可以工作的软件胜过面面俱到的文档。
    • · 客户合作胜过合同谈判。
    • · 响应变化胜过遵循计划。
      在这里插入图片描述

    1.2 敏捷开发的原则

    1. 通过早期和持续交付有价值的软件,实现客户满意度。
    2. 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
    3. 不断交付可用的软件,周期通常是几周,越短越好。
    4. 项目过程中,业务人员与开发人员必须在一起工作。
    5. 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
    6. 面对面交谈是最好的沟通方式。
    7. 可用性是衡量进度的主要指标。
    8. 提倡可持续的开发,保持稳定的进展速度。
    9. 不断关注技术是否优秀,设计是否良好。
    10. 简单性至关重要,尽最大可能减少不必要的工作。
    11. 最好的架构、要求和设计,来自团队内部自发的认识。
    12. 团队要定期反思如何更有效,并相应地进行调整。

    1.3 敏捷开发的特点

    敏捷开发用于软件开发工作时,主张最简单的解决方案就是最好的解决方案,其特点是:

    • 1.快速迭代

    采用复杂问题分解方法,对于小版本的需求、开发和测试更加简单快速。

    • 2.让测试人员和开发者参与需求讨论

    需求讨论以研讨组的形式展开最有效率。研讨组需要包括测试人员开发者,这样可以更加轻松地定义可测试的需求,将需求分组并确定优先级。同时,该种方式也可充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。

    • 3.编写可测试的需求文档
      开始就要用“用户故事”(user story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早地提及技术实施方案,会降低对需求的注意力。

    • 4.多沟通,尽量减少文档

    任何项目中,沟通都是一个常见的问题。良好的沟通是敏捷开发的先决条件,强调高效沟通的重要性。团队要确保日常的交流,面对面沟通比邮件更有效。强调软件开发的产品是软件,而不是文档。文档是为软件开发服务的,而不是开发的主体。

    • 5.响应变更胜过遵循计划

    在敏捷方法开发软件过程中,接收需求变更,预料系统需求的变更,并快速响应变更,设计系统使之适应变更。主动适应变化,而不是预测

    • 6.及早考虑测试

    及早考虑测试在敏捷开发中很重要。传统软件开发中,测试用例大多都是最后才开始写,这导致过晚发现需求中存在的问题,使得改进成本过高。若较早地开始编写测试用例,在需求完成时,可以接受的测试用例也基本同时完成。

    1.4 传统的开发模式和敏捷开发模式的对比

    • 在采用瀑布研发模式时:
      (1)以过程为中心,流水线工作方式
      (2)重视和强调过程文档,主要通过文档来进行沟通
      (3)线性模式,缺少迭代与反馈
      (3)用户直到产品发布才能看到是不是自己想要的,最终成品与需求的偏差率相对较大。
    • 在采用敏捷研发模式时
      (1)以人为中心,以客户需求为导向
      (2)强调软件,而不是文档,减少不必要的文档。
      (3)采用迭代方法
      (3)用户能持续看到阶段性可用的产品,并能及时提出改进反馈,最终成品与需求的偏差率相对较小。

    瀑布模型:
    在这里插入图片描述

    敏捷开发模型:
    在这里插入图片描述

    当前的软件研发所面临的环节是不断快速变化的动态环境,包括新的机遇和市场、不断变化的经济条件、出现的新的竞争产品和服务。软件几乎是所有业务运行中的一部分,所以非常重要的一点是新的软件要迅速开发出来以抓住新的机遇,应对竞争和压力。在这种背景下,研发者许多时候宁愿牺牲一些软件质量、降低某些需求来赢得快速软件的交付。

    传统软件研发建立在对需求描述,然后进行设计、构造,最后再进行测试的完整计划上的软件开发过程是不适应快速软件开发的。当需求发生改变,或者是当需求出现问题时,系统设计和实现不得不返工和重新进行测试。其结果是,传统的瀑布模型或基于描述的过程总是拖延,最后的软件交付给客户的时间远远晚于最初的规定。而敏捷软件开发方法允许开发团队将主要精力集中在软件本身而不是在设计和编制文档上。敏捷方法普遍依赖迭代方法来完成软件研发,其目标是减少开发过程中烦琐多余的部分,通过避免那些从长远看未必有用的工作和减少可能永远都不会被用到的文档的方法达到目的。

    1.5 敏捷开发的分类

    敏捷开发(Agile Development)本身是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,

    敏捷开发过程主要包括:SCRUM,Crystal,特征驱动软件开发(FDD),自适应软件开发(ASD)及极限编程(XP)等。
    (1)XP(极限编程eXtreme Programming,简称XP),是一个轻量级的、灵巧的软件开发方法,同时也是一个严谨和周密的方法。XP的基础和价值观是交流、朴素、反馈和勇气,即任何一个软件项目都可以从四方面入手进行改善,加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近似螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极交流、反馈以及其他一系列方法,开发者和客户都能够非常清楚开发的进度、变化、待解决的问题和潜在困难,等等,并根据实际情况及时地调整开发过程。XP无需开发人员在软件开发初期就制作出很多文档,以适应计划的不断改变。XP提倡测试先行,这是为了将后期出现bug的概率降到最低。XP将项目的所有参与者视为同一团队成员(开发人员、客户、测试人员等),并一起工作在开放场所中。
    **(2)SCRUM。SCRUM是一种迭代的增量化过程,**用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。该方法的核心是旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进。
    **(3)Crystal Methods(水晶方法族)。**它是一个系列,因为不同类型的项目需要不同的方法。虽然“水晶系列”不如XP有那样高的产出效率,但有不少开发者接受并遵循这一开发方法。
    **(4)FDD(Feature-Driven Development,特性驱动开发)。**这是一套针对中小型软件项目的开发模式。此外,FDD是一个模型驱动的快速迭代开发过程,它强调简化、实用、易于被开发团队接受,适用于需求经常变动的项目。
    (5)ASD(Adaptive Software Development,自适应软件开发)。ASD强调开发方法的适应性,这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践做法,它更侧重为ASD的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
    **(6)DSDM(动态系统开发方法)也是敏捷开发方法中的一种,**它倡导以业务为核心,快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国,由于其在各种规模的软件组织中的成功,它已成为应用最为广泛的快速应用开发方法。DSDM方法不但遵循了敏捷方法的原理,而且也适合那些相对成熟传统开发方法具有坚实基础的软件组织。
    **(7)轻量型RUP。RUP本质上是一个过程框架,**可以包容许多不同类型的过程,一些软件专家极力主张以敏捷方式来使用RUP,并认为如此推进敏捷方法,是因为开发者广泛把RUP当做面向对象开发方法的主流。
    敏捷方法将开发与测试过程融为一体。在敏捷方法中,测试以很多不同的方法扮演着同样的角色,而不同的测试种类扮演着不同的角色。大家知道,测试大体上可分为手工测试和自动化测试。根据敏捷原则,要确保能用自动化测试的事情绝不要用手工测试,同时要做到适于手工测试的内容绝不花高昂成本做自动化测试。另外,不因为某方面不能实现自动化测试而不去做测试。敏捷开发中,如何运用手工测试和自动化测试?如何设计测试用例?这些是敏捷测试面临的挑战。

    1.5 Scrum

    (1)敏捷软件开发是一种以用户的需求进化为核心、迭代、循序渐进的开发方法。
    (2)Scrum是一种迭代式增量软件开发模型,通常用于敏捷软件开发。
    (3)XP,又叫极限编程,也是一种敏捷软件开发的模型,它以代码为核心,且由4部分组成:交流、简化、反馈、勇气,我们常说的结对编程就是其中一种模式。

    在国内,我们听到最多的是Scrum,那是因为经过很多项目和团队的实践,证明了它有效、简单、持续交付的能力,所以很多初创型企业或小规模团队都比较青睐它。
    我们通过一段对话来了解一下Scrum模型中的角色投入程度。
    鸡跟猪说:“我们一起开一家餐馆吧。”
    猪问鸡道:“餐馆起什么名字呢?”
    鸡跟猪说:“就叫‘火腿与鸡蛋’吧。”
    猪跟鸡说:“谢谢!还是算了吧。我是全身心投入的,而你只是部分参与而已。”
    从上面“猪”和“鸡”的对话中我们不难看出,在Scrum中有以下两种角色:
    (1)内部角色(全身心投入的成员),如产品负责人、敏捷教练、研发团队。
    (2)外部角色(部分投入的成员),如用户、管理层、其他利益相关者。
    最后,我们通过一张图来快速了解一下Scrum中主要的角色、产物、会议和流程。
    在这里插入图片描述
    4个角色:
    Product Owner:PO,产品负责人,团队的掌舵人,引领团队朝着正确的方向前进。
    Scrum Master:SM,敏捷教练(这是我个人最喜欢的,也是认为最贴切的中文翻译)。
    Team:由开发和测试等相关人员组成的团队,每个迭代周期内所有任务的完成者。
    利益相关人:在敏捷里,利益相关人指的是被项目过程和最终产物所影响到的角色,比如管理者、客户和用户。
    5个产物:
    Product Backlog:产品清单。
    Sprint Goal:迭代目标,也叫冲刺目标。
    Sprint Backlog:迭代清单,也叫冲刺清单。
    Task List:任务列表。
    Increment Product:增量产品。
    4个会议:
    Planning Meeting:计划会议。
    Daily Scrum Meeting:每日站会,传说中的15分钟,“站”只是多种形式中效率最高的一种。
    Review Meeting:评审会议,也叫验收会议。
    Retrospective Meeting:反思会议。我认为,这是所有会议里最重要的一个,因为敏捷思想的核心就是持续改进,而持续改进来源于持续总结和反思。
    流程:
    (1)团队在产品负责人的主持下,通过计划会议、产品清单和冲刺目标产出冲刺清单。
    (2)团队在敏捷教练的指导下,通过冲刺清单、任务列表和每日站会,在一个迭代周期(图中是30天)内产出增量产品。
    (3)产品负责人和团队通过评审会议,验收每个迭代周期产出的增量产品。
    (4)敏捷教练和团队通过反思会议,反思每个迭代周期里做得好和做得不好的地方,持续总结和改进,以此来提高每个迭代周期的战斗力。

    最后附上一些相关的概念。
    User Story:用户故事,从用户的角度来描述用户渴望得到的功能。
    Task Board:任务墙,将Scrum过程中的各项事务放大并进行可视化展示的各种类型的载体。
    Burn Down Chart:燃尽图,在迭代周期内用于跟踪任务进度的可视化图形。

    任务墙:
    在这里插入图片描述
    燃尽图:
    在这里插入图片描述

    本节来源《软件测试进阶之路:测试路上你问我答》—何飞

    展开全文
  • 文章目录0. 软件的生命周期1. 瀑布模型2. 螺旋模型3. 迭代模型4. 增量模型5....  瀑布模型是最早出现的软件开发模型,是所有其他软件开发模型的基础框架。与软件的生命周期不同的是,它缺少了软...

    0. 软件的生命周期

      软件的生命周期是指从软件产品的设想开始到软件不在使用而结束的时间。
      软件的生命周期分为6个阶段,即需求分析、计划、设计、编码、测试、运行维护

    1. 瀑布模型

    在这里插入图片描述
      瀑布模型是最早出现的软件开发模型,是所有其他软件开发模型的基础框架。与软件的生命周期不同的是,它缺少了软件运行维护阶段。
    描述: 每个阶段都只执行一次,因此是线性顺序的软件开发模型。
      正是由于每个阶段只执行一次,所以前面的需求分析和设计尤为重要。
    优点:

    1. 为项目提供了按阶段划分的检查点,强调开发的阶段性。
    2. 强调早期的计划及需求调查。
    3. 强调产品测试。

    缺点:

    1. 在各个阶段之间极少有反馈。
    2. 只有在项目周期的后期才能看到结果,所以风险往往至后期的测试阶段才显露,因此失去了及早的纠正过程。
    3. 单一流程,开发中的经验教训不能反馈应用于本产品的过程。

    适用项目: 需求比较明确且变更很少的项目。

    2. 螺旋模型

    一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模型。螺旋模型是渐进式开发模型的代表之一。
    在这里插入图片描述
    描述: 以原型为基础沿螺线旋转、每转一圈都经过计划/风险分析/实施/评估等过程且得到相应新版本、经过若干次螺旋上升得到最终版本。
    螺旋模型沿着螺旋线进行若干次迭代,图中的四个象限代表了一下活动:
    (1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
    (2)风险分析:分析评估所选方案,考虑如何识别和清楚风险;
    (3)实施工程:实施软件开发和验证;
    (4)客户评估:评价开发工作,提出修正建议,制定下一步计划。
      迭代开发的模式给软件测试带来了新的要求,它不允许有一段独立的测试时间和阶段,测试必须跟着开发的迭代而迭代,所以回归测试的很重要。
    优点:

    1. 强调严格的风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适用于规模庞大,风险大的项目
    2. 强调各个开发阶段的质量
    3. 这种的开发模式会提供机会探讨项目是否有价值继续下去。

    缺点:

    1. 由于引入了非常严格的风险识别、风险分析和风险控制,将会大大消耗人力、资源,如果严重的影响了项目的利润,风险分析将毫无意义。
    2. 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险。
    3. 软件建设周期长,但软件技术发展比较快,所以可能会和当前的技术水平有较大的的差距,无法满足当前用户需求。

    适用项目: 对新近开发,需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更。

    3. 迭代模型

    在这里插入图片描述
      开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上,迭代模型是类似小型的瀑布式项目。
    每一个迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
    描述:
    4. 一次迭代过程包括了所有软件开发流程。
    5. 每一次迭代均产生一个可发布的产品。
    6. 该产品为最终产品的一个子集。
    适用项目: 适合于事先不能完整定义产品的所有需求,计划多期开发的项目。

    4. 增量模型

    在这里插入图片描述
    描述:

    1. 采用随时间进展而交错的线性序列。
    2. 每个序列产生一个可发布的增量。
    3. 每一个增量产生一个可操作的产品。
    4. 第一个增量是核心产品。

    优点: 开始时不用投入大量人力资源,可以事先推出核心产品以稳定用户,可以有计划的管理技术风险。
    缺点: 需要开放式体系结构,可能会产生设计效果差、开发效率低的情况。
    适合项目: 需求经常发生改变的软件开发过程。

    增量和迭代模型的区别:
      增量是逐块建造的概念,例如:画一幅人物画,我们可以先画人的头部,再画身体,再画手脚……。
      迭代是反复求精的概念,例如:同样是画人物画,我们可以先画整体轮廓,在勾勒出基本雏形,再细化、着色……。

    5. 敏捷模型

    描述: 敏捷模型是一种轻量、高效、低风险、更强调团队协作和沟通的开发方式,适合于中小型开发团队,客户需求模糊或多变。
    特点:

    • 强调人与人之间的沟通。
    • 轻文档(弱化文档,但不是不需要文档)
    • 客户需要全程参与
    • 需求可以的变化
    展开全文
  • 最近和朋友谈起敏捷开发(Agile Model)和瀑布开发(Waterfall Model)模式,很多人认为敏捷开发是未来的项目实施的趋势,瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼,联想也在使用敏捷的方式实施一些...

          最近和朋友谈起敏捷开发Agile Model瀑布开发Waterfall Model模式,很多人认为敏捷开发是未来的项目实施的趋势,瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼,联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。我之前参与过敏捷开发的项目,但当时比较“年轻”,认识不是很深刻,于是最近又补习了下和大家一起分享下我对敏捷和瀑布的感悟。

           简单介绍敏捷开发和瀑布开发

           瀑布模型:瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时,开发才会应进入下一阶段。在瀑布模型中,阶段不重叠。下图演示了瀑布模型:

           对于瀑布的开发模型来看,似乎依然具备很可靠的工作逻辑,一个工程或项目分为多个阶段,每一个阶段都投入相应的资源,来完成本阶段的工作。每一个阶段到下一个阶段,都有明确的输入输出产物,不同的阶段根据自己所需的输入,进行工作活动之后,产生自己阶段的产出,投入到下一个阶段的工作中。如果不放心的话,每一个阶段还可以增加一个审批环节,让每一个环节都可以经过可靠的审批之后,再投入到下一个环节当中。

    Salesforce crm开发2.jpg

           SDLC瀑布模型一般用于这些情况:要求稳定且不经常更改;应用程序很小;没有不明白或不明确的要求;环境稳定;使用的工具和技术是稳定的;不是动态的;资源可用。

           敏捷模型:维基百科将敏捷模型定义为“一组基于迭代和增量开发的软件开发方法,其中需求和解决方案通过自组织,跨职能团队之间的协作发展。”该模型有自己的原则,往往会使流程置于backset。

    Salesforce crm开发.jpg

          
           在敏捷看来,很多情况下面,我们都无法去了解到全部的内容,或者即使是了解到,我们也不能保证这些内容是不会变化的。所以先根据主路径,完成主要功能后,我们再通过不断地迭代,去完善我们的工作,这样当我们产生变化的时候,我们推翻的工作量也是少量的,可以很快的去完成新的需求变更。通过这样的不断地变更、重构,我们可以获得一个相对客户满意的产品。

           很多支持敏捷的同学会说瀑布缺乏与业务的沟通和迭代次数,所以如果在项目的后期才发现要更改需求的话,则项目可能会失败或需要重新启动。这张图好像也解释了瀑布开发经常所面临的困境。

    Salesforce crm开发3.jpg

           在高举效率与拥抱变化的大旗之下,似乎敏捷模式,就是最好的开发模式。与之相比的是瀑布模式,在这样的呼喊之中,显得有些无法跟得上步伐,体现的是陈旧、死板的。

           “瀑布”对“敏捷”的驳斥

           敏捷本身不是项目管理框架,也不是“方法论”。它是一套与产品开发相关的原则和价值,特别是互联网产品经常会采用敏捷的方法来进行开发。但是,有一些基于敏捷原则的方法,这些方法是产品开发方法,而不是项目管理框架。

           说到需求变更,瀑布也可以走需求变更,提变更申请,按照环节一步一步走,去规划工作量。虽然比敏捷是要慢一些,但是我整个流程是可靠的!为什么就说瀑布是死板的,不符合时代的呢?

           似乎瀑布的做法也没有错误,我们何不按照这样的步骤,来完成我们的工作呢?这样的过程听起来是如此的可靠。看,我有明确的阶段;看,我有明确的审批;看,我有明确的变更流程。以瀑布模式进行开发的项目有这么多,已经证明了这是一个有效的实施方法,难道不是么?

           另外被敏捷所诟病的瀑布项目经常失败通常是发生了非常严重的错误情况下才会产生。实际上只有在对项目的控制很差的情况下才会发生这种情况。瀑布型项目没有迭代和用户的多次反馈也是不正确的 - 很多项目可以通过产品原型图的方式和业务部门确认操作的流程,只是很多项目中并没有使用这种方法。

           焦点碰撞

          敏捷模式,两周一个迭代,每个迭代都能进行一定功能模块的交付,让用户更早的看到交付物,虽然只有部分,也可以让用户来提出自己的看法,产生变更的时候,开发人员也可以在下个迭代中进行修改,让用户进行再次的确认。

          从这样看来,两者的碰撞就是在交付的及时性上与面对变更的成本上,所看到有极大的变化。瀑布在交付阶段比较靠后,交付的模块比较完整,在面对变更的时候,变更影响范围就比较大,变更的成本就极大。问题发现的阶段越靠后,解决问题所需要付出的成本就更高。这样,就体现出来了敏捷对瀑布在这样的情景下面的优势。

          时间和成本,看起来就是敏捷和瀑布在选择时主要考虑的两个方面。未来能更好的指导未来的选择,下面还列出了更详细的敏捷和瀑布的优劣势。

          I 敏捷开发的优势:
           • 开发的阶段性成果会在开发过程中尽早的进行审查,项目的风险会降低;
           • 适用于需求不明确情况,因为需求不明确,所以需要在不断迭代的过程中来逐步理清需求。
           • 灵活性较高,几乎可以在任何时间进行需求变更;
           • 敏捷鼓励开发人员与业务用户之间进行多频次的沟通,业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新,
           • 敏捷的协作通常要高得多,通常能开发出更高质量的产品;
           • 适用于快速变化的项目,特别是面向前端业务人员的CRM系统项目更容易根据业务的变化而变化。

           I 敏捷开发的劣势:
           • 敏捷的概念接受度还不算太高,初次尝试可能不会非常成功;
            • 最终交付的内容无法预测,预期和实际完成的内容经常会有很大差异;
           • 敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作,但很多情况下业务的沟通时间无法保证;
            • 当存在乙方供应商的情况,敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高;
            • 在敏捷项目中,最大的问题可能是业务部门永远不希望有最终的截止时间。

          I 瀑布开发的优势:
            • 在管理良好的项目中,瀑布可以在早期提供交付的信心;
            • 项目团队成员不需要在同一地点频繁沟通;
            • 在需要大量的设计或分析的情况下瀑布是一种更合适的方法;
            • 如果在基本产品开发之外存在许多接口和依赖关系,瀑布式项目会使用工具来建模和管理这些接口和依赖关系。

           I 瀑布开发的劣势:
            • 许多企业和业务人员确实不容易在前期定义清楚需求,早期计划中所依据的假设需求可能存在很大风险;
            • 沟通的风险要高得多 - 特别是很多项目都是前期单向的沟通,后期项目和业务人员的预期差别很大;
            • 瀑布项目的风险一般都很高,因为基于无效假设基础上的需求可能会让项目无限度扩大。 所以你会看到很多瀑布项目都出现成本超出预算或延迟的情况。

           结论:

           敏捷和瀑布的实施方法差别还是很大的,瀑布几乎可以应用于任何类型的项目,尤其是大型的项目。

           敏捷方法今年来越来越受欢迎,尤其是当前SaaS软件当道,特别像Salesforce crm系统这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代,所以我们才会看到有越来越多的企业采用敏捷的方式来进行项目实施。总的来说敏捷并不能完全替代瀑布,它只是给了我们另外一种好的选择。

           如需了解更多,欢迎访问怡海软件官网 http://www.frensworkz.com/

     

    转载于:https://my.oschina.net/frensworkz/blog/3063878

    展开全文
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
  • 在软件开发时,经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的话题。如果您以前没有使用过这种方法,那么适当了解开发方法和理论是必要的;简单地说,这是一种组织...
  • 敏捷开发模式

    千次阅读 2018-07-01 01:34:06
    1、敏捷开发的概念从1990年代开始逐渐引起广泛关注,是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。2、敏捷开发的流程(图为禅道...
  • 软件生命周期,又称为 软件生存周期 或 系统开发生命周期,是软件的产生直到报废的生命周期,周期内有以下八个阶段: 问题定义 可行性研究 需求分析 概要设计(总体设计) 详细设计 编码与单元测试 综合测试 软件...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:18:20
    传统的开发模式和敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...
  • 针对企业级的 web 应用,研究前后端分离技术,提出一种解决多终端性能、组件化开发和打包部署的完整的开发模型,通过Vue实现组件化开发思想。企业级开发应用实践证明了该开发模式及框架的高效性,满足多终端的设计及...
  • 浅谈开发模式之瀑布模型

    千次阅读 2018-02-15 10:49:48
    前面分享了N多干货,不知道看客有没有看吐,反正本凯总是写吐了。之前在合计着跳槽那点事,因为是半路出家,工作经验也只有一两年这样... 众所周知,当下圈内的开发模式,可以说有四种(瀑布,敏捷,快速应用,Dev...
  • 几种常见的软件开发模型分析

    千次阅读 2019-09-11 17:36:46
    软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码、测试和维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要...
  • 瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行...
  • 螺旋式开发模式

    千次阅读 2018-03-18 10:41:45
    螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。...
  • 四个开发模型的优缺点

    千次阅读 2019-08-01 15:01:51
    关于四个开发模式的优缺点,包括V模型、W模型、迭代模型、敏捷开发
  • 四种开发模式 得区别

    万次阅读 2018-08-20 17:57:50
    敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",更强调程序员...
  • 软件的几种开发模式

    万次阅读 2016-11-04 13:32:47
    软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.演化模型 4.增量模型 5.螺旋模型 6.喷泉模型 7.敏捷模型-SCRUM 各种模型的优点和缺点  瀑布模型 文档驱动 系统可能不满足客户...
  • 软件开发模式之敏捷开发(scrum) 版权声明:本文为博主 android_Mr_夏 原创文章,未经博主允许不得转载。 https://blog.csdn.net/xiajun2356033/article/details/81513957 简介 这几年关于敏捷开发在互联网企业...
  • MVC开发模式

    千次阅读 2018-08-15 19:19:00
     1.MVC模式(Model-View-Controller)是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。  2.MVC可对程序的后期维护和扩展提供了方便,并且使...
  • MVC+三层架构开发模式

    千次阅读 2019-04-08 19:58:11
    Web开发模式 MVC Model:javabean:封装业务数据,模型 View:jsp:显示数据,视图 Controller:servlet:调度jsp和javabean资源,控制器 三层结构: dao层: 和数据访问相关的操作 service层: 和业务逻辑相关的...
  • 火龙果软件工程技术中心本文内容包括:引言使用RationalSoftwareArchitect来应用MDDUML模型转换模式从业务问题到软件解决方案使用带有模式的MDD的好处经验教训总结参考资料模型驱动开发(Model-drivendevelopment,...
  • 然而,了解“V”模式开发模型的程序员应该不多。“V”模式开发模型是汽车电子行业在瀑布模型的基础上做了改进,以符合汽车ECU开发需要的模型。 今天来讲讲瀑布模型与“V”模式开发模型的异同。 瀑布模型 瀑布模型...
  • 常见的软件开发模型之———瀑布模型、原型模型(快速原型模型)一.瀑布模型1.1瀑布模型的基本思想1.2.瀑布模型的特点1.3.瀑布模型的优点1.4.瀑布模型的缺点1.5 瀑布模型的应用范围二. 原型模型(快速原型模型)2.1 ...
  • 瀑布开发模式和敏捷开发模式的区别和思考

    万次阅读 多人点赞 2017-04-12 14:18:54
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  • 10种软件开发模型整理

    千次阅读 2020-12-19 14:12:54
    软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确...
  • JSP开发模式--Model 2模式(二)

    千次阅读 2019-08-27 20:38:02
    这是因为该模式开发中将显示数据、控制页面跳转、数据层操作分别交给JSP、Servlet 、javaBean进行处理 Model 2是基于MVC架构的设计模式。即M(Model:业务逻辑),V(View:用户界面 UI),C(Controller:...
  • 软件测试常见的开发模型

    千次阅读 2020-12-14 23:12:28
    目录 一、软件 1、软件的概念 2、软件的特点 二、软件测试 1)软件测试的概念 2)软件测试的目的 三、软件开发模型(常见 必了解) 1)瀑布模型 2)原型模型 3)螺旋模型 4)==敏捷开发模型== 5)==W模型(双V模型)...
  • 项目开发流程及开发模式

    万次阅读 2019-01-08 11:16:07
    项目开发阶段 整体阶段:需求分析、设计、编码、测试、维护。 需求阶段:通常定义系统的需求,明白系统的目标。 设计阶段:通常确定系统使用什么数据库,系统模块的划分,各个模块的功能。 编码阶段:用编程语言对...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,531,091
精华内容 1,012,436
关键字:

开发模型