精华内容
下载资源
问答
  • 一、瀑布模型 1、按照传统的瀑布模型开发软件,有下述几个特点。 ①阶段间具有顺序性依赖性 阶段间具有顺序性依赖性,这个特点有两重含义: 1,必须等前一阶段的工作完成之后,才能开始后一阶段的工作; 2...

    一、瀑布模型

    1、按照传统的瀑布模型开发软件,有下述几个特点。

    ①阶段间具有顺序性和依赖性

    阶段间具有顺序性和依赖性,这个特点有两重含义:

    1,必须等前一阶段的工作完成之后,才能开始后一阶段的工作;

    2,前一阶段的输出文档介绍后一阶段的输入文档;

    因此,只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果。

    ②推迟实现的观点

    对于规模较大的软件项目来说,往往编程开始得越早,最终完成开发工作所需要的时间反而越长。

    ③质量保证的观点

    软件工程的基本目标是优质,高产。为了保证所开发的软件的质量,在瀑布模型的每个阶段都坚持两个重要的做法。

    (1)每个阶段都必须完成规定的文档,没有交出合格的文档介绍没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员相互通信的媒介,也是运行时期进行维护的重要依据。

    (2)每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。

             事实上,越是早期阶段犯下的错误,暴露出来的时间越晚,排除故障改正错误所需付出的代价也越高。因此,及时审查,是保证软件质量、降低软件成本的重要措施。

    2、传统的瀑布模型过于理想化

    事实上,人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档的错误,而设计上的缺陷或错误可能在实现过程中显现出来,在综合测试阶段发现需求分析、设计或编码阶段的许多错误。因此,实践的瀑布模型是带“反馈环”的。

    3、瀑布模型有许多优点:

    可强迫开发人员采用规范的方法(如结构化技术)

    严格地规定了每个阶段必须提交的文档

    要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

    缺点:

    1.只能通过文档了解产品,不经过实践是不切实际的;

    2.实际项目很少按照该模型给出的顺序进行;

    3.用户常常难以清楚地给出所有需求

    4.用户必须要耐心,等到系统开发完成

    瀑布模型的成功在很的程度上是由于它基本上是一种文档驱动的模型。

    但是,“瀑布模型是文档驱动的”这个事实也是它的一个主要的缺点。

            在可运行的软件产品交付给用户之前,用户只能通过文档来了解产品是什么样的。但是仅仅通过写在纸上的静态的规格说明,很难全面正确地认识动态的软件产品。而且事实证明,一旦一个用户开始使用一个软件,在他的头脑中关于该软件应该做说明的想法就会或多或少地发生变化,这就使得最初提出的需求变得不完全适用了。事实上,要求用户不经过实践就提出完整准确的需求,在很多情况下都是不切实际的。总之,由于瀑布模型几乎完全依赖于书面的规格说明,很有可能导致最终开发出的软件产品不能真正满足用户的需要。

    4、瀑布模型适用于:

    (1)需求是预知的

    (2)软件实现方法是成熟的

    (3)项目周期短

    二、快速原型模型

    所谓快速原型模型是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集。

    快速原型模型是不带反馈环的,这正是这种模型的主要优点

    软件产品的开发基本上线性顺序进行的

    1,能基本上做到线性顺序开发的主要原因如下:

    ①原型系统已经通过与用户交互而得到验证,据此产生的规格说明文档正确地描述了用户的需求,因此,在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。

    ②开发人员通过建立原型系统已经学到了许多东西,因此,在设计和编码阶段发生错误的可能性也比较小,这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

    快速原型的本质是“快速”。

    按照原型的目的对原型分类:

    ·  抛弃式,目的到达即可抛弃,原型不做为最终产品

    ·  演化式,系统的形成和发展是逐步完成的,是高度动态迭代和高度动态的,每次迭代都要对系统重新进行规格说明,重新设计和重新评价,所以是对付变化最为有效的方法,这也是与瀑布开发的主要不同点;

    ·  增量式,系统是一次一段地增量构造,与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然,其对付变化比演化差;

    快速原型模型的优点:

    ①尽早揭示软件可能存在的风险和不确定因素,尤其是关于用户需求一致性方面的风险。

    ②用户参与,降低风险,节省后期变更成本,提高项目成功率。

    ③不带反馈环,基本上做到线性顺序开发。

    ④开发过程与用户培训过程同步,系统易维护,对用户更友好,产品柔性好。

    三、增量模型

    增量模型也称渐增模型

    增量模型属于非整体开发思想的产物

     

    使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计,编码,集成和测试。

    每个构件由多个相互作用的模块构成,并且能够完成特定的功能。

    使用增量模型时,第一个增量构建往往实现软件的基本需求,提供最核心的功能。

    采用瀑布模型或快速原型模型开发软件时,目标都是一次就把一个满足所有需求的产品提交给用户。增量模型与之相反,它是分批逐步向用户提交产品,使得整个软件被分解成许多增量构件,开发人员一个构件接一个构件地向用户提交产品。

    优点:

    ①能在较短的时间内向用户提交可完成部分工作的产品

    ②逐步增加产品的功能可以使用户有充裕的时间学习和适应新产品,从而减少一个全新的软件可能给客户组织带来的冲击。

    缺点:

    风险大,必须保证新增构件不破坏原来已开发出来的产品

                                           风险更大的增量模型

     

    四、螺旋模型

    螺旋模型的基本思想是:使用原型及其他方法来尽量降低风险。

    理解这种模型的一个简便方法,是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。

    螺旋模型有许多优点:

    ①对可选方案和约束条件的强调有利于已有软件的重用,也有助于把软件质量作为软件开发的一个重要目标

    ②减少了过多的测试(浪费资金)或者测试不足(产品故障多)所带来的风险。

    ③在螺线模型中维护只是模型的另一个周期,在维护和开发之间并没有本质区别。

    螺旋模型的主要优势在于,它是风险驱动的,但是这也可能是它的一个弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识,否则将会出现真正的风险:当项目实际上正在走向灾难时,开发人员可能还认为一切正常。

    五、喷泉模型

    迭代是软件开发过程中普遍存在的一种内在属性。

    “喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。

    图中代表不同阶段的圆圈相互重叠,这说明表示两个活动之间存在交迭;而面向对象的方法在概念和表示方式上的一致性,保证了在各项开发活动之间的无缝过渡

    事实上,用面向对象方法开发软件时,在分析、设计和编码等项开发活动之间并不存在明显的边界。

    图中较小的圆圈代表维护,圆圈较小象征着采用了面向对象范型之后维护时间缩短了。

    为避免使用喷泉模型开发软件时开发过程过分无序,应该把应该线性过程(例如,快速原型模型)作为总目标。但是,同时也应该记住,面向对象范型本身要求经常对开发活动进行迭代或求精。

    展开全文
  • 软件开发模型(SoftwareDevelopmentModel)是指软件开发全部过程、活动任务的结构框架。软件开发包括需求、设计、编码测试等阶段,有时也包括维护阶段。   软件开发模型能清晰、直观地表达软件开发全过程,明确...

    软件开发模型(SoftwareDevelopmentModel)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。

     

    软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。

     

    最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。但计算拓广到统计分析、商业事务等领域时,大多数程序采用高级语言(如FORTRAN、COBOL等)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。

     

    典型的开发模型有:①瀑布模型(waterfallmodel);②渐增模型/演化/迭代(inCRementalmodel);③原型模型(prototypemodel);④螺旋模型(SPIralmodel);⑤喷泉模型(fountAInmodel);⑥智能模型(intelligentmodel);7.混合模型(hybridmodel)

     

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

    遗憾的是,许多产品都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改.

     

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

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

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

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

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

     

    2.瀑布模型(WaterfallModel)

    1970年WinSTonRoyce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

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

     

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

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

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

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

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

     

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

     

    3.快速原型模型(RAPIdPrototypeModel)

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

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

     

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

     

    4.增量模型(IncrementalModel)

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

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

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

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

     

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

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

     

    5.螺旋模型(SpiralModel)

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

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

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

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

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

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

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

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

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

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

     

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

     

    6.演化模型(incrementalmodel)

     

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

     

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

     

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

     

    7.喷泉模型(fountainmodel,(面向对象的生存期模型,OO模型))

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

     

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

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

     

    9.混合模型(hybridmodel)

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

     

    各种模型的比较

    每个软件开发组织应该选择适合于该组织的软件开发模型,并且应该随着当前正在开发的特定产品特性而变化,以减小所选模型的缺点,充分利用其优点,下表列出了几种常见模型的优缺点。

     

    模型

     

    优点

     

    缺点

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

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

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

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

    展开全文
  • 2.3快速原型模型的思想产生、原理及运用方式 2.4类型 2.5开发步骤 三、增量模型 3.1什么是增量模型 3.2特点 3.3优缺点 3.4作用 四、螺旋模型 4.1什么是螺旋模型 4.2特点 4.3优缺点 4.4...

    目录

    一、瀑布模型

    1.1什么是瀑布模型

    1.2特点

    1.3优缺点

    1.4客户需求

    二、快速原型模型

    2.1什么是快速原型模型

    2.2优缺点

    2.3快速原型模型的思想产生、原理及运用方式

    2.4类型

    2.5开发步骤

    三、增量模型

    3.1什么是增量模型

    3.2特点

    3.3优缺点

    3.4作用

    四、螺旋模型

    4.1什么是螺旋模型

    4.2特点

    4.3优缺点

    4.4限制条件


    一、瀑布模型

    1.1什么是瀑布模型

    1970年温斯顿.罗伊斯提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型

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

    瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动

    从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布开发名称的由来

    对于经常变化的项目而言,瀑布模型毫无价值

    1.2特点

    1、阶段间具有顺序性和依赖性

    该阶段具有两重含义

    1. 必须等前一阶段的工作完成后,才能开始后一阶段的工作
    2. 前一阶段的输出文档就是后一阶段的输入文档,因此只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果

    2、推迟实现的观点

    对于规模较大的软件项目来说,往往编码开始的越早,最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题

    瀑布模型在编码之前设置了系统分析与系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现

    清楚的区分逻辑设计与物理设计,尽可能推迟程序的物理实现,是按照瀑布模型开发软件的一条重要的指导思想

    3、质量保证的观点

    为了保证所开发的软件的质量,在瀑布模型的每一个阶段都应坚持两个重要做法

    1. 每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务
    2. 每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误

    传统的瀑布模型过于理想化,实际的瀑布模型是带"反馈环"的。如图所示(图中实线箭头表示开发过程,虚线箭头表示维护过程),当在后面阶段发现前面阶段的错误时,需要沿图中左侧的反馈线返回前面的阶段,修正前面阶段的产品后再回来继续完成后面阶段的任务

    瀑布模型是文档驱动的模型,遵守这个约束可使软件维护变得比较容易一些,从而显著降低软件预算

    1.3优缺点

    优点:

    • 项目提供了按阶段划分的检查点
    • 当前一阶段完成后,您只需要去关注后续阶段
    • 可在迭代模型中应用瀑布模型

    缺点:

    • 不适合需求模糊或需求经常变动的系统
    • 由于开销的逐步升级问题,它不希望存在早期阶段的反馈
    • 在一个系统完成以前,它无法预测一个新系统引入一个机构的影响
    • 用户可能需要较长等待时间来获得一个可供使用的系统,也许会给用户的信任程度带来影响和打击
    • 最终产品往往反映用户的初始需求而不是最终需求

    1.4客户需求

    对项目而言,是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度;对于经常变化的项目而言,瀑布模型毫无价值,可以考虑其他的架构来进行项目管理,比如螺旋模型

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

    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险
    3. 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果

    按照瀑布模型的阶段划分,软件测试可以分为单元测试集成测试系统测试

     

    二、快速原型模型

    2.1什么是快速原型模型

    快速原型是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集

    快速原型模型是增量模型的另一种形式,在开发真实系统之前,迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,在该原型的基础上,逐渐完成整个系统的开发工作

    它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护

    2.2优缺点

    优点

    • 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险
    • 适合预先不能确切定义需求的软件系统的开发

    缺点

    • 所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
    • 使用前提是要有一个展示性的产品原型,一定程度上可能会限制开发人员的创新

    2.3快速原型模型的思想产生、原理及运用方式

    1、思想产生

    在需求分析阶段得到完全、一致、准确、合理的需求说明十分困难

    获得一组基本需求说明后,就快速地使其“实现”,通过原型反馈,加深对系统的理解满足用户基本要求,使用户在试用后对需求说明进行补充和精确化,从而获得合理完整、现实可行的需求说明

    再把快速原型思想用到软件开发的其他阶段,向软件开发的全过程扩展

    先用相对少的成本,较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用,以便及早澄清并检验一些主要设计策略,在此基础上再开发实际的软件系统

    2、原理

    利用原型辅助软件开发

    经过简单快速分析快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,最终提高软件质量

    3、运用方式

    由于运用原型的目的和方式不同,在使用原型时也采取不同的策略

    • 抛弃策略:将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的
    • 附加策略:将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略

    采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、可供支持的原型开发工具和技术等,根据实际情况的特点决定

    2.4类型

    在软件开发中,原型是软件的一个早期可运行的版本,它反映最终系统的部分重要特性

    探索型

    这种原型目的是要弄清对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性

    实验型

    这种原型用于大规模开发和实现之前,考核方案是否合适,规格说明是否可靠

    进化型

    这种原型的目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统

    2.5开发步骤

    1、快速分析

    在分析人员与用户密切配合下,迅速确定系统的基本需求,根据原型需要体现的特征描述基本需求以满足开发原型的需要

    2、构造原型

    在快速分析的基础上,根据基本需求说明尽快实现一个可行的系统

    要求具有强有力的软件工具的支持,并忽略最终系统在某些细节上的要求,主要考虑原型系统能够充分反映所要评价的特性

    3、运行原型

    发现问题,消除误解,开发者与用户充分协调

    4、评价原型

    在运行的基础上,考核评价原型的特性,分析运行效果是否满足用户的愿望,纠正过去交互中的误解与分析中的错误,增添新的要求,并满足因环境变化或用户的新想法引起的系统要求变动,提出全面的修改意见

    5、修改

    根据评价原型的活动结果进行修改

    若原型未满足需求说明的要求,说明对需求说明存在不一致的理解或实现方案不够合理,根据明确的要求迅速修改原型

    快速原型模型不带反馈环,软件产品的开发基本上是线性顺序进行的

    快速原型的本质是"快速"。开发人员应尽可能地建造出原型系统,以加速软件开发过程,节约软件开发成本

    原型的用途是获知用户的真正需求,一旦需求确定了,原型将被抛弃

     

    三、增量模型

    3.1什么是增量模型

    增量模型也称渐增模型。使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成,并且能够完成特定的功能

    使用增量模型时,第一个增量构件往往实现软件的基本需求,提供最核心的功能

    把软件产品分解成增量构件时,唯一必须遵守的约束条件是,当把新构件集成到现有构件中时,所形成的产品必须是可测试的

    瀑布模型或快速原型模型目标是一次就把一个满足所有需求的产品提交给用户

    增量模型把整个软件产品分解成许多个增量构件,分批地逐步向用户提交产品

    3.2特点

    把瀑布模型的顺序特征与快速原型法的迭代特征相结合

    将软件看作一系列相互联系的增量,在开发过程的各次迭代中,每次完成其中的一个增量

    风险更大的增量模型

    确定用户需求后就着手拟定第一个构件的规格说明文档,完成后规格说明组转向第二个构件的规格说明文档,同时设计组开始涉及第一个构件

    使用该方法将不同的构件并行构建,可能加快工程进度,但将冒构建无法集成到一起的风险

    3.3优缺点

    优点

    1. 能在较短的时间内向用户提交可完成部分工作的产品
    2. 将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展
    3. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
    4. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时,还能及时地对实现顺序进行调整

    缺点

    1. 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构
    2. 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性
    3. 如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程

    3.4作用

    1、开发初期的需求定义只是用来确定软件的基本结构,使得开发初期用户只需要对软件需求进行大概的描述;而对于需求的细节性描述,则可以延迟到增量构件开发时进行,以增量构件为单位逐个地进行需求补充。这种方式能够有效适应用户需求的变更

    2、软件系统可以按照增量构件的功能安排开发的优先顺序,并逐个实现和交付使用。不仅有利于用户尽早用上系统,能够更好地适应新的软件环境,而且在以增量方式使用系统的过程中,还能获得对软件系统后续构件的需求经验

    3、软件系统是逐渐扩展的,因此开发者可以通过对诸多构件的开发,逐步积累开发经验。实际上,增量式开发还有利于技术复用,前面构件中设计的算法、采用的技术策略、编写的源码等,都可以应用到后面将要创建的增量构件中去

    4、增量式开发有利于从总体上降低软件项目的技术风险。个别的构件或许不能使用,但一般不会影响到整个系统的正常工作

    5、实际上,在采用增量模型时,具有最高优先权的核心增量构件将会被最先交付,而随着后续构件不断被集成进系统,这个核心构件将会受到最多次数的测试。这意味着软件系统最重要的心脏部分将具有最高的可靠性,这将使得整个软件系统更具健壮性

     

    四、螺旋模型

    4.1什么是螺旋模型

    螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径

    螺旋模型是快速原型模型以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。该模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段,由这4个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。用螺旋模型的软件过程如下

    简化的螺旋模型

    完整的数据模型

     

    图中带箭头的点划线的长度代表当前累计的开发费用,螺旋线的角度值代表开发进度,螺旋线的每个周期对应于一个开发阶段

    图中的四个象限代表了以下活动

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

    4.2特点

    螺旋模型在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制,它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险,直到所有的主要风险因素都被确定

    螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应,因此特别适用于庞大、复杂并具有高风险的系统

    4.3优缺点

    优点

    1. 对可选方案和约束条件的强调有利于已有软件的重用,也有助于把软件质量作为软件开发的一个重要目标
    2. 减少了过多测试(浪费资金)或测试不足(产品故障多)所带来的风险
    3. 在螺旋模型中维护只是模型的另一个周期,在维护和开发之间并没有本质区别

    缺点

    1. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失
    2. 过多的迭代次数会增加开发成本,延迟提交时间

    4.4限制条件

    1. 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发
    2. 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目
    3. 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

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

    展开全文
  • 对比十几种软件开发模型 瀑布模型 演化模型 螺旋模型 喷泉模型 快速原型模型 智能模型 混合模型 敏捷开发 极限编程XP
  • 软件过程模型 软件生命周期 从设计、投入使用到被淘汰的全过程 注意这里不只是设计、连维护也是 每个过程会产生相应的文档 软件过程模型 也称为软件开发模型、软件生存周期模型 结构框架 能直观表达软件开发全...

    软件过程模型

    软件生命周期

    • 从设计、投入使用到被淘汰的全过程
    • 注意这里不只是设计、连维护也是
    • 每个过程会产生相应的文档

    在这里插入图片描述软件过程模型

    • 也称为软件开发模型、软件生存周期模型
    • 结构框架
    • 能直观表达软件开发全过程

    能力成熟度模型

    • 用来评估软件的生产能力
    • CMM是目前国际上使用流行的一种软件生产过程行业标准模型,可定义、评价软件开发过程的成熟度,并提供提高软件质量的指导。
    • CMM模型分为五级:初始级(1级)、可重复级(2级)、定义级(3级)、管理级(4级)、优化级(5级)共5个成熟度等级,低级别是实现高级别的基础

    在这里插入图片描述
    对应说明:
    (1)初始级(initial)。

    • 工作无序,项目进行过程中常放弃当初的计划。
      管理无章法,缺乏健全的管理制度。开发项目成效不稳定,项目成功主要依靠项目负责人的经验和能力,他一但离去,工作秩序面目全非

    (2)可重复级(Repeatable)。

    • 管理制度化,建立了基本的管理制度和规程,管理工作有章可循。
      初步实现标准化,开发工作比较好地按标准实施。
      变更依法进行,做到基线化,稳定可跟踪,新项目计划和管理基于过去实践经验,具有重复以前成功项目的环境和条件。
      核心:建立基本的项目管理和实践来跟踪项目费用、进度和功能特性

    (3)已定义级(Defined)。

    • 许多组织追求的目标
      开发过程,包括技术工作和管理工作,均已实现标准化、文档化。
      建立了完善的培训制度和专家评审制度,全部技术活动和管理活动均可控制,对项目进行中的过程、岗位和职责均有共同的理解 。
      核心:使用标准开发过程(或方法论)构建(或集成)系统

    (4)已管理级(Managed)。

    • 产品和过程已建立了定量的质量目标。
      开发活动中的生产率和质量是可量度的。
      已建立过程数据库。
      已实现项目产品和过程的控制。
      可预测过程和产品质量趋势,如预测偏差,实现及时纠正。
      核心:管理层寻求更主动地应对系统的开发问题

    (5)优化级(Optimizing)。

    • 可集中精力改进过程,采用新技术、新方法。
      拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。
      可取得过程有效性的统计数据,并可据进行分析,从而得出最佳方法。
      核心:连续地监督和改进标准化的系统开发过程

    传统的软件过程模型

    瀑布模型

    • 瀑布模型(Waterfall Model) 是一个软件生命周期模型,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。
    • 是一种使用广泛,以文档为驱动的模型
    • 每个阶段都有与其相关联的里程碑和可交付产品
    • 每个阶段结束前完成文档审查,及早改正错误

    特点

    • 阶段间具有顺序性和依赖性
      必须等前一阶段的工作完成之后,才能开始后一阶段的工作。前一阶段的输出文档就是后一阶段的输入文档。
    • 推迟实现的观点
      清楚的区分逻辑设计与物理设计,尽可能推程序的物理实现,是因为编码之前阶段的工作没做或做得不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题,带来灾难性的后果。
    • 质量保证的观点
      每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。
      每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。

    在这里插入图片描述
    实际模型

    • 原因
      传统的瀑布模型过于理想化,人在工作过程中不可能不犯错误。
    • 当后面阶段发现前面阶段的错误时,需要沿图中左侧的反馈线返回前面的阶段,修正前面阶段的产品之后再回来继续完成后面阶段的任务。

    在这里插入图片描述
    缺点

    • 瀑布模型是由文档驱动,在可运行的软件产品交付给用户之前,用户只能通过文档来了解产品是什么样的。瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要。也不适合需求模糊的系统。
    • 测试只是其中一个阶段,缺乏全过程测试思想

    在这里插入图片描述
    应用场合

    • 适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合,如军工、航天、医疗

    V模型

    • V模型的中心思想是,研发人员和测试人员需要同时工作,在软件做需求分析的同时就会有测试用例的跟踪,这样可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。
    • V模型的重要意义在于,非常明确的表明了测试过程中存在的不同的级别,并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。
      单元测试:是否满足详细设计的要求
      集成测试:验证已测试过的部分是否可以很好地结合在一起
      系统测试:检验系统功能、性能是否达到系统的要求。
      验收测试:确定软件的时限是否满足用户需求或合同需求

    特点

    • V模型体现的主要思想是开发和测试同等重要,左侧代表的是开发活动,而右侧代表的是测试活动。
    • V模型针对每个开发阶段,都有一个测试级别与之相对应。
    • 测试依旧是开发生命周期中的阶段,与瀑布模型不同的是,有多个测试级别与开发阶段对应。
    • V模型适用于需求明确和需求变更不频繁的情形。

    缺点

    • 虽然测试尽早的进入到开发阶段,但是真正进行软件测试是在编码之后,这样忽视了测试对需求分析,系统设计的验证,时间效率上也大打折扣。

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

    原型模型

    博客出处

    • 在开发真实系统之前,通过构建一个可以运行的软件原型,使开发人员与用户达成共识,以便理解和澄清问题,最终在确定的客户需求基础上开发客户满意的软件产品。

    • 根据运用原型的目的和方式不同,可以将原型模型分为快速原型模型(抛弃型)和原型进化模型(渐进型)。
      在这里插入图片描述
      在这里插入图片描述

    快速原型模型

    • 快速原型模型是原型模型在软件分析、设计阶段的应用,用来解决用户对软件系统在需求上的模糊认识,或用来试探某种设计是否能够获得预期结果。

    特点

    • 快速原型是用来获取用户需求的,或是用来试探设计是否有效的。一旦需求或设计确定下来了,原型就将被抛弃。因此,快速原型要求快速构建、容易修改,以节约原型创建成本、加快开发速度。快速原型往往采用一些快速生成工具创建,例如 4GL 语言。目前,Microsoft Visual Basic、Inprise Delphi 等基于组件的可视化开发工具,也被应用于原型创建之中,并且都是非常有效的快速原型创建工具,而且还可用于原型进化。

    • 快速原型是暂时使用的,因此并不要求完整。它往往针对某个局部问题建立专门原型, 如界面原型、工作流原型、查询原型等。

    • 快速原型不能贯穿软件的整个生命周期,它需要和其他的过程模型相结合才能产生作 用。例如,在瀑布模型中应用快速原型,以解决瀑布模型在需求分析时期存在的不足。

    • 在这里插入图片描述

    原型进化模型(演化模型)

    • 原型进化对开发过程的考虑是,针对有待开发的软件系统,先开发一个原型系统给用户使用,然后根据用户使用情况的意见反馈,对原型系统不断修改,使它逐步接近并最终到达开发目标跟快速原型不同的是,快速原型在完成需求定义后将被抛弃,而原型进化所要创建的原型则是一个今后将要投入应用的系统,只是所创建的原型系统在功能、性能等方面还有许多不足,还没有达到最终开发目标,需要不断改进。 原型进化的工作流程如图所示。

    在这里插入图片描述

    特点

    • 原型进化模型将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统。
    • 原型进化模型是通过不断发布新的软件版本而使软件逐步完善的,因此,这种开发模式特别适合于那些用户急需的软件产品开发。它能够快速地向用户交付可以投入实际运行的软件成果,并能够很好地适应软件用户对需求规格的变更。原型进化模型能够适应软件需求的中途变更

    问题

    • 原型进化模型虽说使开发进程加快了,但不能像瀑布模型那样提供明确的里程碑管理,随着开发过程中版本的快速更新,项目管理、软件配置管理会变得复杂起来,管理者难以把握开发进度。因此,对于大型软件项目,原型进化模型缺乏有效的管理规程

    • 开发过程中软件版本的快速变更,还可能损伤软件的内部结构,使其缺乏整体性和稳定性。另外,用于反映软件版本变更的文档也有可能跟不上软件的变更速度。这些问题必将影响到今后软件的维护

    增量模型

    原博文

    • 把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。
      -
    • 增量模型对软件过程的考虑是:在整体上按照瀑布模型的流程实施项目开发,以方便对项目的管理;但在软件的实际创建中,则将软件系统按功能分解为许多增量构件,并以构件为单位逐个地创建与交付,直到全部增量构件创建完毕,并都被集成到系统之中交付用户使用。如同原型进化模型一样,增量模型逐步地向用户交付软件产品,但不同于原型进化模型的是,增量模型在开发过程中所交付的不是完整的新版软件,而只是新增加的构件

    增量模型的优点

    • 增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点,增量模型具有以下优点。
      1、将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展。
      2、以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
      3、开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时,还能及时地对实现顺序进行调整。

    增量模型的缺点:

    • 1、要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化,那么将会给增量开发带来很多麻烦
      2、由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。  
      3、在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而使软件过程的控制失去整体性

    增量模型适用范围:

    • 1、软件产品可以分批次地进行交付。
      2、待开发的软件系统能够被模块化。
      3、软件开发人员对应用领域不熟悉,难以一次性地进行系统开发。
      4、项目管理人员把握全局的水平较高。

    螺旋模型

    • 螺旋模型是快速原型法以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段,由这4个阶段进行迭代。螺旋模型即是一种引入了风险分析与规避机制的过程模型,是瀑布模型、快速原型方法和风险分析方法的有机结合。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失

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

    优点

    • 设计上的灵活性,可以在项目的各个阶段进行变更。

    • 以小的分段来构建大型系统,使成本计算变得简单容易。

    • 客户参与每个阶段的开发,保证了项目不偏离正确方向及项目的可控性。

    • 客户始终掌握项目的最新信息, 能够和管理层有效地交互。

    • 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

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

    喷泉模型

    • 喷泉模型是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的,就像水喷上去又可以落下来,类似一个喷泉。各个开发阶段没有特定的次序要求,并且可以交互进行,可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

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

    展开全文
  • 软件开发模型(Software Development Model)是指软件开发全部过程、活动任务的结构框架。软件开发包括需求、设计、编码测试等阶段,有时也包括维护阶段。 软件开发模型(目的)能清晰、直观地表达软件开发全过程...
  • 瀑布模型的优点:有利于大型软件开发过程中人员的组织、管理,有利于软件开发方法工具的研究,从而提高了大型软件项目开发的质量效率。 瀑布模型的缺点:开发过程一般不能逆转,否则代价太大;很难严格按该模型...
  • <br />瀑布模型、渐增模型/演化/迭代、原型模型、螺旋模型具体有什么区别? 在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前...
  • 软件工程——快速原型模型

    千次阅读 2019-07-25 19:06:04
    目录 什么是快速原型模型 快速原型模型的优缺点 ...快速原型模型是增量模型的另一种形式,在开发真实系统之前,迅速建造一个可以运行的软件原型 ,以便理解澄清问题,在该原型的基础上,逐...
  • **瀑布模型是20世纪80年代之前最受推崇的软件开发模型,它是一种线性的开发模型,具有不可回溯性。**开发人员必须等前一阶段的任务完成后,才能开始后一阶段的工作,并且前一阶段的输出往往就是后一阶段的输入。**...
  • Content瀑布模型(生命周期...2.软件工程 瀑布模型、原型模型、喷泉模型和V模型的优缺点及适用场景. 3.什么是敏捷开发? 瀑布模型(生命周期模型) 优点 前一阶段完成后,您只需要去关注后续阶段 缺点 各个阶段之间...
  • 软件工程-软件开发模型(瀑布/V/喷泉/原型/演化/螺旋/统一过程/敏捷) 瀑布模型 特性 文档为驱动 优点 容易管理 缺点 开发过程逆转代价大 脱离实际 现代客户难以明确需求,该模型对需求大依赖 效果后期才可现 反馈...
  • **瀑布模型,原型模型,增量模型,螺旋模型,喷泉模型**,在实际项目中,通常数个模型方法共同使用
  • 文章目录瀑布模型/改进的瀑布模型螺旋模型增量迭代模型原型法快速敏捷开发关于选择生命周期模型的最后的总结 瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的最效...
  • 软件生命周期模型是跨越整个生存期的系统开发、运作维护所实施的全部过程、活动任务的结构框架。 瀑布模型  优点:它提供了一个模板,这个模板使得分析、设计、编码、测试支持的方法可以在该模板下有一个...
  • 软件生命周期模型是跨越整个生存期的系统开发、运作维护所实施的全部过程、活动任务的结构框架。 下面介绍几种常见的软件生命周期模型: 瀑布模型 瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的...
  • 瀑布模型(Waterfall Model)是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好...
  •  虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求 -&gt;分析-&gt;设计-&gt;编码-&gt;测试的阶段...
  • 文章目录原型实现模型分类:一、抛弃式原型开发二、演化原型开发三、增量式原型开发 一、抛弃式原型开发 1、定义:验证澄清系统的需求描述,重新构造系统。 2、流程图 3、典型例子 开发者与客户进行沟通交流,...
  • 软件开发模型(Software Development Model)是指软件开发全部过程、活动任务的结构框架。软件开发包括需求、设计、编码测试等阶段,有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确...
  • 快速原型模型

    千次阅读 2018-03-18 10:44:41
    快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非...
  • 软件开发之演化模型

    2020-11-10 16:54:46
    按照不同的原型应用策略,演化模型可以分为两类:探索式演化模型和抛弃式演化模型。 探索式演化模型,其目标是与用户一起工作,共同探索系统需求,直到最后交付系统。这类开发从需求较清楚的部分开始,根据用户的...
  • 软件过程模型传统软件生命周期模型--瀑布模型--演化模型--增量模型--喷泉模型--V模型--W模型--螺旋模型--构件组装模型--快速开发应用模型(RAD)--原型方法概念种类优缺点新型软件生命周期模型RUP模型敏捷建模极限...
  • 此前一直对于项目生命周期的模型中出现的各种模型不是非常了解,对于迭代、原型、螺旋、敏捷开发经常感觉都一样,这次细细思考了一会,有点感觉了,关键点就是这几种模型的侧重点不一样,就如同每个人虽然都是看同一...
  • NME在线社交网络演进模型演示系统 构建设置 # install dependencies npm install # serve with hot reload at localhost:8080 npm run dev # build for production with minification npm run build # build for ...
  • 软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试测试、验收与运行、维护升级到废弃等阶段,也有将以上阶段的活动组合在内的迭代阶段,即迭代作为生命周期的阶段。 问题的定义及规划 此阶段...
  • 软件开发模型 一.软件危机软件工程 软件危机:是指落后的软件成产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象 为了解决软件危机的问题,就出现了软件工程。...
  •  虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,654
精华内容 3,861
关键字:

原型模型和演化模型