软件开发模式_软件开发模式对比(瀑布、迭代、螺旋、敏捷) - CSDN
精华内容
参与话题
  • 软件开发的11种模式

    万次阅读 2016-11-09 23:21:53
    软件开发的11种模式 1,边做边改模型(Build-and-Fix-Model) 在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。在这个模型中,开发人员拿到项目立即根据需求编写...

    软件开发的11种模式

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


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

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

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

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

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

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

     

    2,瀑布模型(Waterfall-Model

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

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

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

    1)为项目提供了按阶段分的检查点

    2)当完成一个阶段后,只需要去关注后续阶段

    3)可在迭代模型中应用瀑布模型

    缺点:缺乏灵活性,太过线性理想化,不适合现代软件开发

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

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

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

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

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

     

    3,快速原型模型(Rapid-Prototype-Model


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

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

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

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

    优点:

    (1)生命周期短

    (2)整合边做边改瀑布模型优点

    (3)减少软件需求不明确带来的开发风险

    (4)适用于小型、交互型的系统,大型系统的某些部分

    缺点:

    1)可能导致系统设计差、效率低、难以维护

     

     4,增量模型(Incremental-Model

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

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

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

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

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

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

    优点:

    1)人员分配灵活,一开始不需要投入大量人力

    2)先推出核心的产品,在后续增加相应的功能

    3)增量能够有计划的管理技术风险

    4)适用于需求经常变更的软件开发过程

    缺点:

    1)如果增量包之间存在相交的情况未很好的处理,则必须做全盘的系统分析

     

    5,迭代模型(Stagewise-Model)(迭代增量式开发/迭代进化式开发)

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

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

    优点:

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

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

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

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

     

    6,螺旋模型(Spiral-Model


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

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

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

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

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

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

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

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

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

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

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

     

    7,敏捷开发模型(Agile-Development-Model

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

    敏捷开发小组主要的工作方式:

    (1)作为一个整体工作;

    (2)按短迭代周期工作;

    (3)每次迭代交付一些成果,关注业务优先级,检查与调整。

    敏捷开发的4个核心思想:

    (1)强调面对面的沟通,人和人的相互交流胜于任何流程和工具

    (2)把精力集中在可执行的程序上,可以运行的产品胜于编制综合性文档,强调了原型、模型、demo等的重要性

    (3)团队合作和团队激励,合作胜于谈判,敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体,大家都是一条线上的蚂蚱

    (4)超强的适应能力,适应变化胜于按部就班,敏捷开发的特点就是快速

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

     

    8,演化模型(Evolutionary-Model

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

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

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

     

    9,喷泉模型(Fountain-Model

    以用户需求为动力,以对象为驱动的模型,主要用于采用对象技术的软件开发项目

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

    优点:

    (1)可以提高软件项目开发效率,节省开发时间,适用于面向对象的软件开发过程

    缺点:

    (1)由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,不利于项目的管理

    (2)这个模型要求严格管理文档,使得审核难度加大,尤其是面对随时加入各种需求

     

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

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

     

    11,混合模型(Hybrid-Model

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

     

     大概对比了部分的模型方法

    模型名称

    技术特点

    适用范围

    瀑布模型

    简单,分阶段,阶段间存在因果关系,

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

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

    需求易于完善定义且不易变更的软件系统

    快速原型模型

    不要求需求预先完备定义,支持用户参与,

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

    需求复杂、难以确定、动态变化的软件系统

    增量模型

    软件产品是被增量式地一块块开发的,

    允许开发活动并行和重叠

    技术风险较大、用户需求较为稳定的软件系统

    迭代模型

    不要求一次性地开发出完整的软件系统,将软件

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

    需求难以确定、不断变更的软件系统

    螺旋模型

    结合瀑布模型、快速原型模型和迭代模

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

    需求难以获取和确定、软件开发风险较大的软件系统

     

    展开全文
  • 软件的几种开发模式

    万次阅读 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.

    整个过程如下图所示:


    展开全文
  • 软件开发模式

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

    思维导图:

    软件开发模式

    1.瀑布模型 2.迭代开发 3.螺旋模型 4.敏捷开发

    瀑布模型

    瀑布模型是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
    优点:

    • 调研开发的阶段性
    • 强调早期计划及需求调查
    • 确定了何时产生可交付的产品及何时进行评审和审查
    • 强调产品测试

    缺点:

    • 依赖早期进行的需求调查,不能适应需求变化
    • 流程单一,开发中的经验得不到反馈和应用于本产品的开
      发中
    • 没有反映出开发的迭代本质
    • 不包含风险评估
    • 风险往往在后期才显露,失去及早纠正机会

    迭代开发

    迭代模式每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代. 在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。
    迭代式开发的优点:
      1、降低风险
      2、得到早期用户反馈
      3、持续的测试和集成
      4、使用变更
      5、提高复用性

    螺旋开发

    螺旋开发:1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
    “螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开。
    “螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。
    螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。
    5个步骤:

    1. 确定目标,选择方案和限制条件。
    2. 对方案风险进行评估,并能解决风险。
    3. 进行本阶段的开发和测试。
    4. 计划下一阶段。
    5. 确定进入下阶段的方法。

    优点: 严格的全过程风险管理;强调各开发阶段的质量;提供机会评估项目是否有价值继续下去。
    缺点: 可能难以使用户(尤其在有合同约束的情况下)相信演化方法是可控的;项目的成功依赖于风险评估专门技术,如果一个大的风险未被发现和管理,就会出现问题。

    敏捷开发

    敏捷方法论采用迭代/增量开发的过程模型。是一种以人为核心、迭代、循序渐进的开发方法。组织上,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。时间上,相对于传统的瀑布式开发,迭代开发把软件生命周期分成很多个小周期(一般不大于2个月,建议2周),每一次迭代都可以生成一个可运行、可验证的版本,并确保软件不断的增加新的价值。
    敏捷开发由几种轻量级的软件开发方法组成。它们包括:极限编程(XP),Scrum,精益开发(LeanDevelopment)等等
    步骤: 编写用户案例,架构规范,实施规划,迭代计划,代
    码开发,单元测试,验收测试等等

    • 个体和交互 重于过程和工具。
    • 可以工作的软件 重于求全而完备的文档。
    • 客户协作重于合同谈判。
    • 随时应对变化重于循规蹈矩。

    四者对比区别:

    传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。
    特别是前期阶段,设计的越完美,提交后的成本损失就越少。

    迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。

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

    敏捷开发,相比迭代式开发两者都强调在较短的开发周期提交软件,但是,敏捷开发的周期可能更短,并且更加强调队伍中的高度协作。
    敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。
    适应性的方法集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

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

    千次阅读 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、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型, 瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    传统的开发模式和敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...
  • 从招式与内功谈起——设计模式概述(一)

    万次阅读 多人点赞 2013-12-27 13:14:08
    关于金庸小说中到底是招式重要还是内功重要的争论从未停止,我们在这里并不分析张无忌的...别急,正因为你是软件开发人员我才跟你谈这个,因为我们的软件开发技术也包括一些招式和内功:Java、C#、C++等编程语言,Eclip
  • 大话设计模式

    万次阅读 2020-01-20 09:52:28
    设计模式软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。 我们在使用Spring、Hibernate、MyBatis等这些框架的过程中,...
  • 软件开发的4种常见模型

    万次阅读 2018-03-07 14:52:21
    1.V模式(瀑布模式) V模型又称为瀑布模型,是一种普遍的软件开发模式,旨在改进软件开发的效果和效率,反映出测试活动与分析设计活动的关系。指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统...
  • 瀑布开发模式和敏捷开发模式的区别和思考

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

    万次阅读 2015-03-24 10:41:55
    作为一名软件开发人员,我们不仅应该知道怎么开发软件,还要知道怎么更好,更有质量地开发软件,从而提高软件的稳定性和可维护性,在这一方面实在不是你干瞪眼转转脑子就能想出来的,这必须要长时间的工程实践才能...
  • 四种开发模式 得区别

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

    万次阅读 2017-01-13 15:48:44
    敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可...
  • 软件工程期末复习总结

    千次阅读 多人点赞 2016-07-03 15:22:39
    软件工程
  • 瀑布模式螺旋模型快速原型模式增量模式喷泉模型演化模型   瀑布模式 特点: 阶段间具有顺序性和依赖性: 前一阶段完成后,才能开始后一阶段 前一阶段的输出文本为后一阶段的输入文本 推迟实现的观点 质量...
  • TDD、BDD、ATDD、DDD 软件开发模式

    万次阅读 2017-04-17 15:50:37
    四个开发模式意思: TDD:测试驱动开发(Test-Driven Development) BDD:行为驱动开发(Behavior Driven Development) ATDD:验收测试驱动开发(Acceptance Test Driven Development) DDD:领域驱动开发...
  • 软件架构设计经典书籍有哪些?

    万次阅读 2011-12-03 11:51:51
    1.软件架构设计 作者: 温昱 内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、...本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材,也可作为软件开发高级
  • 设计模式(C++实现)专题 -- 0.目录

    万次阅读 2019-12-26 22:09:48
    设计模式软件开发的精髓所在,非常适用于大型软件技术的开发。本系列开始讲述设计模式的专题,包括常见设计模式的基本原理以及其具体的使用场景。 文章目录设计模式专题1. 背景与概述1.1 设计模式概述1.2 设计模式...
  • 系统架构师考试需求大纲

    万次阅读 2017-11-03 09:05:58
    考试合格人员应能够根据系统需求规格说明书,结合应用领域和技术发展的实际情况,考虑有关约束条件,设计正确、合理的软件架构,确保系统架构具有良好的特性;能够对项目系统架构进行描述、分析、设计与评估;能够...
1 2 3 4 5 ... 20
收藏数 669,955
精华内容 267,982
关键字:

软件开发模式