精华内容
下载资源
问答
  • 软件过程模型传统软件生命周期模型--瀑布模型--演化模型--增量模型--喷泉模型--V模型--W模型--螺旋模型--构件组装模型--快速开发应用模型(RAD)--原型方法概念种类优缺点新型软件生命周期模型RUP模型敏捷建模极限...

    基本概念

    –PDCA循环(戴明环)

    PDCA循环,针对针对工程项目的质量目标提出的模型,称为戴明环(Plan, Do, Check, Action)
    在这里插入图片描述

    –软件工作过程

    软件工程过程是为了获得软件产品,在软件工具的支持下由软件工程师完成的一系列软件工程活动。
    具体活动包括:
    软件规格说明、软件开发、软件确认、软件演进、

    –软件生命周期

    指软件产品从考虑其概念开始,到该软件产品不再使用为止的整个时期。
    一般包括概念阶段、分析与设计阶段、构造阶段、移交和运行阶段等不同时期。
    软件生命周期的六个基本步骤:制定计划(P)、需求分析(D)、设计(D)、程序编码(D)、测试(C)、运行维护(A)。
    软件生命周期和戴明环的对应关系:
    在这里插入图片描述

    –软件过程模型

    对软件过程的概括描述和抽象,包括各种活动(Activities)、软件工件(artifacts)和参与角色(Actors/Roles)等。

    传统软件生命周期模型

    –瀑布模型

    工作流程
    需求分析—软件需求—分析—程序设计—编码—测试—运行
    每个阶段都需要进行审核和文档输出(文档驱动)

    模型作用
    为软件开发和维护提供了有效的管理模式。在软件开发早期,在消除非结构化软件、降低软件复杂度、促进软件开发工程化方面起着显著的作用。

    每个开发活动的特征:
    ·本活动依赖于上一项活动的输出作为工作对象,这些输出一般是代表某活动结束的里程碑式文档。
    ·根据本阶段的活动规程执行相应的任务。
    ·本阶段活动的最终产出——软件工件,将会作为下一活动的输入。
    ·对本阶段活动执行情况进行评审。

    优点:
    降低复杂度、提高透明性和可管理性、强调需求分析和设计、阶段审核和文档输出保证了阶段之间的正确衔接,能够及时发现问题。
    缺点:
    缺乏灵活性、不适用于需求不明的开发情况、风险控制能力较低、文档驱动增加了系统的工作量、只依赖于文档来评估进度,可能会得出错误结论、成功周期较长

    适用场景:
    需求明确、较大型系统、开发周期不紧张
    在这里插入图片描述

    –演化模型

    工作流程
    在瀑布模型的基础上,一次性开发难以成功,因此,演化模型提倡进行“两次开发”,分别是试验开发和产品开发。每个开发阶段按照瀑布模型进行具体开发活动。

    优点:
    明确用户需求、提高系统质量、降低开发风险
    缺点:
    管理难度提高、开发结构化较差、可能抛弃文档驱动、可能导致产品结构化较差

    适用场景:
    需求不清、开发周期短的中小型系统。
    在这里插入图片描述

    –增量模型

    模型概述:
    结合瀑布模型和演化模型的优点,在需求不清时,对最核心或最清晰的需求,利用瀑布模型实现。再对后续需求进行重复开发(可能按照需求的优先级逐个进行),从而逐步建成一个完整的软件系统。

    优点:
    保障核心功能实现、开发风险较低、保障最高优先级的功能的可靠实现、提高系统稳定性和可维护性。
    缺点:
    增量粒度难以合理选择、确定所有的需求服务较困难
    在这里插入图片描述

    –喷泉模型

    模型概述:
    又称迭代模型,每个阶段是相互重叠、多次反复的。每个开发阶段没有次序要求,可以并发进行,在某个阶段随时补充其他阶段中遗漏的需求。

    优点:
    提高效率、缩短周期
    缺点:
    管理结构性较差
    在这里插入图片描述

    –V模型

    模型概述:
    是瀑布模型的变种。它将测试模块细化分解,把测试看作与开发同等重要的过程,每一测试阶段的前提和要求是对应开发阶段的文档。

    测试模块:
    ·单元测试:根据详细设计说明书,检测每个单元模块是否符合预期要求。主要检查编码过程中可能存在的错误。
    ·集成测试:根据概要设计说明书,检测模块是否正确聚集。主要检查模块与接口之间可能存在的错误。
    ·系统测试:根据需求分析,检测系统作为一个整体在预定环境中能否正常的有效工作。
    ·验收测试: 是否满足客户的需求。

    优点
    改进开发效率和开发效果
    缺点:
    前期出现错误的话,后期难以挽救和弥补或者花费的代价巨大。
    在这里插入图片描述

    –W模型

    模型概述
    由两个V模型构成,分别代表测试与开发过程。每个开发过程对应一个测试,体现了开发和测试的并行关系,测试的不局限于程序,对于阶段文档也需要进行测试。

    优点:
    增加了软件各开发阶段中应同步进行的验证和确认活动。
    缺点:
    开发,测试活动保持着一种前后关系,无法支持迭代软件开发模型。
    在这里插入图片描述

    –螺旋模型

    模型概述:
    将开发过程分为四个类型:风险分析、制定计划、实施工程、客户评估。每次评估之后确定是否进行螺旋线的下一个回路。

    适用对象:
    风险较高、开发周期较长的大型软件项目

    优点和缺点

    降低风险,但是开发周期长。
    在这里插入图片描述

    –构件组装模型

    模型概述:
    将整个系统模块化,在一定构件模型的支持下,复用构件库中软件构件,通过组装构件构造软件系统。开发过程就是构件组装的过程,是迭代的过程,维护过程就是构件升级、替换和扩充的过程。

    优点:
    软件复用充分,提高效率,允许多项目同时开发,降低开发费用,提高可维护性,可实现分步提交软件产品。
    缺点:
    构件组装结构没有通用标准,组装过程存在风险、构件可重用性和系统高效性不易协调;构件质量直接影响产品质量。
    在这里插入图片描述

    –快速开发应用模型(RAD)

    模型概述:
    增量型开发模型,通过大量使用可复用 构件,采用基于构件的建造方法赢得了快速开发。
    其流程从业务建模开始,随后是数据建模、过程建模、应用生成、测试及反复。RAD目的是快速发布系统方案,而技术上的优美相对发布的速度来说是次要的。

    优点:
    开发周期短
    缺点:
    需求分析的阶段时间较短、适用性一般

    适用范围
    适合于管理信息系统开发,不适合于技术风险较高、与外围系统的互操作性较高的系统开发
    在这里插入图片描述

    –原型方法

    在传统的软件生命开发周期中,原型方法是经常被使用的一种开发方法。

    概念

    瀑布模型以及基于瀑布模型的软件生命周期模型,都需要精确的需求才能很好地执行后续的开发活动,但是准确的需求分析很难获取。
    原型方法指在获得基本需求后,快速分析,实现一个小型的软件系统原型,满足用户的基本要求。用户可以提出修改意见,校正需求。
    原型方法主要用于明确需求,但也可以用于软件开发的其他阶段。

    种类

    1、废弃策略

    • 探索型:弄清用户要求,确定期望特性;探讨多个方案的可行性。主要针对需求模糊、用户和开发者对项目都缺乏经验的情况。
    • 实验型:用于大规模开发和实现之前,考核技术方案是否合适、分析和设计的规格说明是否可靠。

    2、追加策略

    • 进化型:适应需求变化,不断改进原型,逐步将原型进化成最终系统。它将原型方法的思想扩展到软件开发的全过程,适用于需求经常变动的软件项目。

    优缺点

    优点:
    有助于快速理解用户需求、容易确定系统性能和设计可行性、有利于建成最终系统。
    缺点:
    文档容易被忽略、建立原型增加工作量、项目难以有效规划和管理。

    新型软件生命周期模型

    RUP模型

    模型概述:
    它是一类面向对象的程序开发方法论,既是一个生命周期模型,也是一个支持面向对象软件开发的工具。
    软件生命周期在时间上被分解为四个顺序的阶段:初始阶段、细化阶段、构造阶段、交付阶段。每个阶段在阶段结尾执行一次评估,确定阶段目标是否满足、是否可以进入下一个阶段。以用例为驱动,软件体系结构为核心,应用迭代及增量的新型软件生命周期模型。

    各阶段工作说明
    初始阶段:了解业务,确定项目边界。包括验收规范、风险评估、资源估计、阶段计划制定等
    细化阶段:分析问题领域,建立软件体系结构基础,编制项目计划,完成技术要求高、风险大的关键需求开发。
    构造阶段:将所有剩余的技术构件和业务需求功能开发出来,集合成产品,所有功能被详细测试。
    移交阶段:重点是确保软件可被最终用户使用。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量调整。

    每个迭代的主要活动:
    核心过程工作流(6个):业务建模、需求、分析和设计、实现、测试、部署
    核心支持工作流(3个):配置和变更管理、项目管理、环境

    模型特点:
    ·适应性开发:小步骤、快速反馈和调整;
    ·使用用例驱动软件建模:用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。
    ·可视化软件建模:使用UML进行软件建模。
    在这里插入图片描述
    在这里插入图片描述

    敏捷建模和极限编程

    模型概述:
    一种以实践为基础的软件工程过程和思想。使用快速反馈测试(测试驱动)、大量而迅速的交流,经过保证的测试来最大限度的满足用户的需求。主要强调用户满意,开发人员可以对需求的变化作出快速的反应。
    每个参加项目开发的人都将担任一个角色(项目经理、项目监督人等等)并履行相应的权利和义务。

    特点:

    • 测试驱动:XP内层的过程基于Test Driven Development,每个开发周期都有很多相应的单元测试。
    • 大力提倡设计复核(Review)、代码复核以及重整和优化(Refectory),这些过程也是优化设计的过程;
    • 提倡配对编程(Pair Programming),而且代码所有权是归于整个开发队伍。
    • 程序员在写程序和重整优化程序时要严格遵守编程规范。
    • 任何人可以修改其他人写的程序,但修改后要确定新程序能通过单元测试。
    • 在开始写程序之前先写单元测试。

    在这里插入图片描述

    展开全文
  • 文章目录原型实现模型分类:一、抛弃式原型开发二、演化原型开发三、增量式原型开发 一、抛弃式原型开发 1、定义:验证澄清系统的需求描述,重新构造系统。 2、流程图 3、典型例子 开发者与客户进行沟通交流,...

    一、抛弃式原型开发

    1、定义:验证和澄清系统的需求描述,重新构造系统。

    2、流程图

    3、典型例子

    开发者与客户进行沟通交流,之后获取到客户的需求,于是开发者开发了该图形用户界面(GUI)的原型。但是之后呢,系统并没有用GUI继续做开发,而是采用C++或者是其他语言来开发。

    4、有利条件

    1)Reduce risk in a project, see if something can be done.

    降低项目中的风险,评估哪些事情可以做,哪些事情不能做;

    2)Capture requirements(e.g. whether client likes the GUI or not) .

    捕捉需求,比如:客户是否喜欢GUI界面。

    5、不利条件

    1)Resources can be wasted, so control is needed.

    资源可能会被浪费,因此需要控制。

    2)Good Project Management is required.

    需要良好的项目管理。

    3)Good communication with the client is required.

    与客户保持良好的沟通。

    4)When is it a good time to stop developing the prototype.

    无法判断停止开发原型的时间。

    二、演化式原型开发

    1、定义:逐步改进和细化原型,将原型进化为最终系统。

    2、流程图

    3、典型例子

    与汽车行业类似,一款车型也在逐步完善。

    4、有利条件

    1)The client can see the changes that they want.

    客户可以看到他们想要的改变。

    2)Very good for improving user interface acceptance.

    有利于提高用户界面的接受程度。

    5、不利条件

    1)Very weak on documentation (e.g. system keeps changing)

    不利于文档撰写,比如:系统持续改变,那么文档就不好落笔。

    2)The entire project needs strong project control,the same as leader needs to monitor development.

    整个项目需要强有力的项目控制,同时领导者也需要监控项目的发展进程。

    3)When is it a good time to stop evolving and finishing the project and possible lead to a badly structured system.

    是什么时候停止发展和结束项目,我们都不知道;所以这很有可能会导致系统结构不良。

    4)Special development staff may be required.

    可能需要特殊的开发人员。

    6、适用情况

    1)Small projects.

    小型项目。

    2)Limited projects that are limited by time or money.

    受时间或金钱限制的有限项目。

    3)Those projects that need done quickly.

    那些需要快速完成的项目。

    4)Projects whose details cannot be determined in advance.

    无法预先确定其细节的项目。

    5)Projects with a high graphical content.

    ​ 图形内容丰富的项目。

    三、增量式原型开发

    1、定义:在建立软件总体设计基础上,采用增量开发方法,使原型成为最终系统。

    2、流程图

    3、典型例子

    英文版

    A software company and a client may agree on delivery of system parts. For example, a website delivery might be:

    1st January - Delivery of web-server, web-pages,verification and validation scripts.

    5th February - Delivery of database, security software.

    21st February - Delivery of merchant payment system.

    中文版

    一个软件公司和客户就系统部件的交付达成协议。 例如,一个网站交付可能是:

    1月1日 - 交付①网络服务器;②网页;③验证和确认脚本。

    2月5日 - 交付数据库和安全软件。

    2月21日 - 商家付款系统的交付。

    4、有利条件

    1)Good for breaking a larger system into parts, so components can be built easier.

    ​ 非常适合将较大的系统分解为多个部分,因此组件可以更轻松地被构建。

    2)Customer sees the system in stages, so no “big bang” approach.

    ​ 客户分阶段看到系统,所以可能比较少会有“大爆炸”的态度。

    5、不利条件

    1)Requires good communication and agreement.

    需要良好的沟通和协商。

    2)Requires good project management, control and monitoring work.

    需要良好的项目管理,控制和监视工作。

    3)communication and agreement.

    需要良好的沟通和协商。

    4)Requires good project management, control and monitoring work.

    需要良好的项目管理,控制和监视工作。

    如果这篇文章对你有帮助,记得留下star哦~

    展开全文
  • 在软件开发的设计中我们会遇到各种各样的问题。一般来说我们的架构师都是从业务入手,利用技术解决方案满足业务的需求。那么我们在设计软件的时候...第一,这个过程是不断探索需求设计不断演化的过程。第二,能够...

    在软件开发的设计中我们会遇到各种各样的问题。一般来说我们的架构师都是从业务入手,利用技术解决方案满足业务的需求。那么我们在设计软件的时候,是否有一定的套路或者说是否有一定的思维模式可以遵循呢?今天我们就一起来看看3种设计的过程模型能够给我们带来点什么吧?

    什么是设计过程模型

    设计过程模型就是把抽象的概念反应成现实。他必须满足以下三方面的要求。

    第一,这个过程是不断探索需求和设计不断演化的过程。

    第二,能够通过可视化让设计师和使用者保持观念同步的过程。

    第三,让产品的交付者和产品的使用者达成合同的工程。

    647c51fc667e9a06fb10caecb87fa110.png

    共同演化模型

    就是发现问题,解决问题不断交织的过程。设想当我们设计某个产品/架构的时候,会为了解决一个问题而引入了新的问题,随着对问题的认知提高,解决问题的方式也更加全面,更加深入。这种方式主要是设计师单独完成,是设计师不断认识问题解决问题的过程,把想法具体化以后发现具体问题再加以改进。这种方式的应用软件设计中比较少见,多是存在系统级别的应用,设计师主要需要和系统,硬件设备,软件模块打交道。在商业应用中很少见。

    53a5d244d6626eb6057b7f0296edd723.png

    如果说把这个演化模型理解为用户需求和技术实现之间的关系的话。更像是用户不断提出或者发现问题,技术工程师不断的解决问题,响应用户需求。

    f902a5c3f2f97a50e96e92ed6dfd283d.png

    Raymond的集市模型

    这个可以举一个例子,在开源社区中一个开发人员为了解决一个问题开发了一个组件,并且将这个组件上传到了开源的社区。其他的开发人员看到了这个组件觉得很好用就用到了自己的项目之中,随着用的越多也发现这个组件的其他问题,于是就对这个组件进行优化,同时把优化后的组件分享给其他人使用。在不断的好似击鼓传花的组件打磨之后,这个最开始只是给小部分人使用的组件,逐渐经过无数“设计师”的手,变成了一个可以给更多人使用的通用组件。这个就是Raymond集市模型所要达到的目的,即通过多个“设计师”针对不同场景的反复打磨,获得最终的产品/服务。这种模式可以用到设计师同时也是用户的场景,在一些软件的开源设计经常能够看到这种模式的身影。

    f399d9859bb6c8ed55aaf47904b33a58.png

    这种模式考虑多人对同一个产品/服务进行迭代,需要把控迭代的内容和使用的场景。

    Beohm的螺旋模型

    其实这种模型很想当前的原型设计法。通常我们的产品经理将需要设计的产品通过原型的方式展示给客户,这些原型除了包括功能界面还有基本交互功能。用户通过原型进行产品体验或者测试,使设计师逐渐逼近最终的产品/服务。

    17838c7981fbbba610bc69062a154f68.png

    还有一种情况,产品团队根本就不知道用户需要如何的产品,用户自己也不知道要什么,也没有更多的时间和资源去做可以交互的原型给到客户。那么,他们可以做一些最为基础的页面(毛坯页面),观察用户的使用情况,并且记录使用的路径,从而形成设计模型。这种模型在互联网设计中比较常见,因为互联网设计比较讲究时效性和用户体验,这种方式可以用最少的成本,最短的时间快速试错,加快整个产品的生命周期,做到快速迭代。

    80393b70900aec2c9c97baeaa17768e8.png
    展开全文
  • 本分析的主要问题是确定比安奇一世的周期性演化 模型,由于小宇宙常数而在截止物理学引起的大反弹转折点之间振荡。 此外,宇宙各向异性变量的平均值在整个演化过程中(包括整个大反弹阶段)都保持有限。 根据初始...
  • 软件开发模型和优缺点

    万次阅读 2018-04-05 16:30:27
    目录边做边改模型(Build-and-Fix-Model)瀑布模式(Waterfall-Model)螺旋模型(Spiral-Model)快速原型模型(Rapid-Prototype-Model)增量迭代模型增量模型(Incremental-Model)迭代模型(Stagewise-Model)...
    目录
    边做边改模型(Build-and-Fix-Model)
    在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户和测试等等满意为止。
    优点
    这是一种类似作坊的开发方式,边做边改模型的优点毫无疑问就是前期出成效快。
    缺点
    对编写逻辑不需要太严谨的小程序来说还可以对付得过去,但这种方法对任何规模的开发来说都是不能令人满意的。
    原因在于
    • 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;
    • 忽略需求环节,给软件开发带来很大的风险;
    • 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。
     

     
    瀑布模式(Waterfall-Model)
    特点:
    • 严格按照需求 ->分析->设计->编码->测试的阶段进行
    • 阶段间具有顺序性和依赖性:
      • 前一阶段完成后,才能开始后一阶段
      • 前一阶段的输出文本为后一阶段的输入文本
    • 适合于一些大型稳定的项目
    • 推迟实现的观点
    • 质量保证:
      • 以质量为第一目标
    • 每个阶段必须交付出合格的文档
    • 对文档进行审核
    优点:
    • 可以保证整个软件产品较高的质量
    • 保证缺陷能够提前的被发现和解决
    • 可以保证系统在整体上的充分把握,使系统具备良好 的扩展性和可维护性
    缺点:缺乏灵活性,太过线性理想化,不适合现代软件开发
    • 前期就需要把需求做到最全。所以对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。
    • 瀑布模型强调的保证软件的质量,往往忽略人力,时间,资源等成本因素。对于中小型的项目,需求设计和开发人员往往在项 目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况
    • 惧怕用户测试中的反馈,惧怕需求变更
    • 每次需求发生变更都要从头再来
     
     
     
    当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候,这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最大问题就是没有一个完全总体的设计,架构设计人员无法在洞悉了所有需求后从系统的可扩展性,复用等方面总体规划.
    BTW:
    很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能 够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确, 没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度.
    在项目管理中有一种压缩进度的方法叫赶工,因此瀑布模型的另外改进处就在适当的重叠各个阶段过程,达到资源的有效利用.比如我们通过讨论,会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来.
     

     
    螺旋模型(Spiral-Model)
    1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
    螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:
    (1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
    (2)风险分析:分析评估所选方案,考虑如何识别和消除风险;
    (3)实施工程:实施软件开发和验证;
    (4)客户评估:评价开发工作,提出修正建议,制定下一步计划。
    特点:
    • 需求->架构->设计->开发->测试
    • 螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险.
    • 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
    • 适合于前期需求不稳定,后期需求新增变更较多的项目,这是一种增量迭代开发的模型,每一次循环都是一次版本的升级。
    • 核心在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚.在定义最重要的功能时,去实现它,然后听取客户的意见,之后再进入到下一个阶段.如此不断轮回重复,直到得到您满意的最终产品
    优点:
    • 设计上的灵活性,可以在项目的各个阶段进行变更.
    • 以小的分段来构建大型系统,使成本计算变得简单容易
    • 客户始终参与保证了项目不偏离正确方向以及项目的可控性
    • 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互.
    • 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品.
    缺点:
    很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求.
    每轮循环包含六个步骤:
    1. 确定目标,可选项(替代方案),以及强制条件(约束条件)
    2. 识别并化解风险
    3. 评估可选项
    4. 开发并测试当前阶段
    5. 规划下一阶段
    6. 确定进入下一阶段的方法步骤.
    模型:
     
    BTW:
    螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目.
    螺旋模型复杂的地方在于尽责,专心和知识渊博的管理.因为对于每一次迭代我们要制定出清晰的目标,分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情.
    螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等.因此这是和RUP(Rational Unified Process,统一软件开发过程)提倡 的迭代模型是有区别的,RUP的每一次迭代都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶 段的工作.
     

     
    快速原型模型(Rapid-Prototype-Model)
    快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
     
    显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。
     
    快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。
    快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。
    优点:
    • 生命周期短
    • 整合“边做边改”与“瀑布模型”优点
    • 减少软件需求不明确带来的开发风险
    • 适用于小型、交互型的系统,大型系统的某些部分 
    缺点:
    • 所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下,难以维护。
    原型类型:
    • 探索型原型:目的是要型清用户的需求,确定所期望的特性,并探索各种方案的可行性。它主要针对开发目标模糊,
    • 实验型原型:主要用于设计阶段,考核;实现方案是否合适,能否实陋
    • 演化型原型:主要用于及早向用户提交一个原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到用户的认可后,将原型系统不断扩充演变为最终的软件系统
    原型的运用方式:
    • 抛弃策略是将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的。
    • 附加策略是将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略
    模型:
     
     
     
     

     
    增量和迭代模型
    增量迭代是RUP统一过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常一起使用.所以这里要先解释下增量和迭代的概念。假设现在要开发 A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二 次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐 渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的 基础功能都已经完成.
    增量模型(Incremental-Model)
     
    在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
    增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:
    1. 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
    2. 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
    在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。
    例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。
    优点:
    • 人员分配灵活,一开始不需要投入大量人力
    • 先推出核心的产品,在后续增加相应的功能
    • 增量能够有计划的管理技术风险
    • 适用于需求经常变更的软件开发过程
    缺点:
    • 如果增量包之间存在相交的情况未很好的处理,则必须做全盘的系统分析
     
    迭代模型(Stagewise-Model)(迭代增量式开发/迭代进化式开发)
    在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。
    迭代和版本的区别,可理解如下:迭代一般指某版本的生产过程,包括从需求分析到测试完成;版本一般指某阶段软件开发的结果,一个可交付使用的产品。
    优点:
    • 降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。
    • 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。
    • 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
    • 由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。因此复用性更高
     
     

     
    喷泉模型Fountain-Model
    以用户需求为动力,以对象为驱动的模型,主要用于采用对象技术的软件开发项目
    喷泉模型与传统的结构化生存期比较,具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来,可以落在中间,也可以落在最底部。
     
    喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动.该模型的各个阶段没有明显的界限,开发人员可以同步进行开发.
    优点:
    • 可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程.
    缺点:
    • 由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理
    • 此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况
    模型:
     
     

    演化模型(Evolutionary-Model)
    思想:
    主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求,并且当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现。软件开发人员根据用户的需求,首先开发核心系统。当该核心系统投入运行后,用户试用之,完成他们的工作,并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈,实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成,为整个系统增加一个可定义的、可管理的子集。
     
    在开发模式上采取分批循环开发的办法,每循环开发一部分的功能,它们成为这个产品的原型的新增功能。于是,设计就不断地演化出新的系统。 实际上,这个模型可看作是重复执行的多个“瀑布模型”。
     
    “演化模型”要求开发人员有能力把项目的产品需求分解为不同组,以便分批循环开发。这种分组并不是绝对随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出,每个开发循环以六周到八周为适当的长度。
    优点:
    • 任何功能一经开发就能进入测试以便验证是否符合产品需求
    • 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
    • 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
    • 大大有助于早期建立产品开发的配置管理
    缺点:
    • 主要需求开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性
    • 缺乏严格过程管理的话,这生命周期模型很可能退化为“试-错-改”模式
    • 不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响
     

     
    敏捷开发模型(Agile-Development-Model)
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
    敏捷开发小组主要的工作方式:
    • 作为一个整体工作;
    • 按短迭代周期工作;
    • 每次迭代交付一些成果,关注业务优先级,检查与调整。
    敏捷开发的4个核心思想:
    • 强调面对面的沟通,人和人的相互交流胜于任何流程和工具
    • 把精力集中在可执行的程序上,可以运行的产品胜于编制综合性文档,强调了原型、模型、demo等的重要性
    • 团队合作和团队激励,合作胜于谈判,敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体,大家都是一条线上的蚂蚱
    • 超强的适应能力,适应变化胜于按部就班,敏捷开发的特点就是快速
    敏捷软件开发要注意项目规模,规模增长,团队交流成本就上去了,因此敏捷软件开发暂时适合不是特别大的团队开发,比较适合一个组的团队使用。
     

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

     
    混合模型(Hybrid-Model)
    过程开发模型又叫混合模型(hybrid model),或元模型(meta-model),把几种不同模型组合成一种混合模型,它允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)。实际上,一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。
     
     大概对比了部分的模型方法
    模型名称
    技术特点
    适用范围
    瀑布模型
    简单,分阶段,阶段间存在因果关系,
    各个阶段完成后都有评审,允许反馈,不支持
    用户参与,要求预先确定需求
    需求易于完善定义且不易变更的软件系统
    快速原型模型
    不要求需求预先完备定义,支持用户参与,
    支持需求的渐进式完善和确认,能够适应用户需求的变化
    需求复杂、难以确定、动态变化的软件系统
    增量模型
    软件产品是被增量式地一块块开发的,
    允许开发活动并行和重叠
    技术风险较大、用户需求较为稳定的软件系统
    迭代模型
    不要求一次性地开发出完整的软件系统,将软件
    开发视为一个逐步获取用广需求、完善软件产品的过程
    需求难以确定、不断变更的软件系统
    螺旋模型
    结合瀑布模型、快速原型模型和迭代模
    型的思想,并引进了风险分析活动
    需求难以获取和确定、软件开发风险较大的软件系统
     
    一个有趣的介绍:
    参考资料:
    展开全文
  • Aromorphosis(生物学进化的主要趋势之一,是组织增加而没有狭窄的专业化特征),已偏爱具有最成功原型的群体(后来的相关个体群体的原始模式或模型,例如,双边对称群体脊椎动物)。 在整个古生代,优势群体...
  • 它们的定义是原型的出现,以确保其组织水平长期多样化上升的可能性,从而导致活生物体的活动显着增加以及它们对环境的独立性。 可以基于它们的优势群体建立新元古代(Ediacaran)-Phanerozoic生物圈水生环境的一...
  • 文章目录软件开发模型瀑布模型V模型喷泉模型原型化模型,演化模型,增量模型螺旋模型RAD快速开发模型构件组装模型(CBSD)敏捷化的开发方法 软件开发模型 瀑布模型 瀑布模型把软件开发分成了三个阶段,定义阶段,开发...
  • 4.演化过程模型: 包括 原型开发模型、螺旋模型、协同开发模型 5.专用过程模型: 包括 基于构件的开发模型、形式化方法模型、面向方面的软件开发模型 (参考文献:软件工程-实践者的研究方法 (美)Poger S.Pressman ) ...
  • 软件开发的4种模型和4种方法

    千次阅读 2012-05-17 15:22:10
    3.螺旋模型:结合瀑布模型和演化模型,综合两者优点,并增加风险分析,螺旋模型包括四个方面活动:制定计划,风险分析,实施工程,客户评估。   4.喷泉模型:面向对象的开发过程,具有迭代和无间隙特性,开发活
  • 典型的软件过程模型有:瀑布模型、增量模型、演化模型原型模型、螺旋模型)、喷泉模型、基于构件的开发模型、形式化方法模型等。 瀑布模型(Waterfall Model) 瀑布模型是将软件生存周期中的各个活动规定为依线性...
  • 软件开发模型(2)

    2019-04-02 20:01:47
    原型分为探索性原型、实验型原型和演化原型三种 探索型原型的目的是弄清目标的要求,确定性所希望的特性,并探讨多种方案的可行性。 实验性原型的目的是验证方案或算法的合理性,是在大规模开发和实验前,用于...
  • 典型的开发模型有:边做边改模型(Build-and-Fix Model)、瀑布模型(Waterfall Model)、快速原型模型(Rapid Prototype Model)、增量模型(Incremental Model)、螺旋模型(Spiral Model)、演化模型(Incremental Model)、....
  • 软件开发模型

    2019-04-04 20:29:55
    典型的软件过程模型有瀑布模型、增量模型、演化模型原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化模型等。 二、瀑布模型(Waterfall Model) 瀑布模型,简单来说就是开发过程像瀑布一样依次下落...
  • 1.原型开发模型(快速原型模型演化模型、增量模型) 1)快速原型: 解释:其用途是获知用户的真正需求,一旦需求确定了,原型即被抛弃。主要用于需求分析阶段。是一种“抛弃式”的原型化方法。 特征:简化项目...
  • 软件过程模型

    2018-08-07 10:43:17
    典型的软件过程有瀑布模型、增量模型、演化模型原型模型、螺旋,模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。 瀑布模型 定义:瀑布模型是将软件生产周期中的各个活动规定为依线性顺序连接的若干...
  • (5)系统开发基础

    2019-10-06 18:41:25
    (4)原型模型和演化模型 (5)螺旋模型 强调风险,成本高 (6)统一过程模型 (7)敏捷方法 2软件开发方法 3 需求分析 4软件设计 5软件测试 McCabe复...
  • 典型的软件过程模型有瀑布模型、演化模型(如增量模型、原型模型、螺旋模型)、喷泉模型、基于构建的开发模型和形式化方法模型。 提示:以下是本篇文章正文内容,下面案例可供参考 瀑布模型 给出了软件生存周期活动...
  • 一、瀑布模型(SDLC)1、瀑布模型,也称生命...2、演化模型:在快速开发一个原型的基础上,根据用户在调用原型的过程中提出的反馈一件,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产...
  • 典型的开发模型有:边做边改模型(Build-and-Fix Model)、瀑布模型(Waterfall Model)、快速原型模型(Rapid Prototype Model)、增量模型(Incremental Model)、螺旋模型(Spiral Model)、演化模型(Incremental Model)、....
  • 软件过程模型总结

    2019-05-14 17:17:17
    典型的有:瀑布模型、增量模型、演化模型原型模型、螺旋模型)、喷泉模型、基于构建的开发模型和形式化方法模型。 那么它们具体都是怎么样的呢? 瀑布模型:是将软件生存周期中的哥哥活动规定为依线性顺序连接的...
  • 软件开发工作模型

    2018-03-16 10:45:00
    包捂夫器的开处:各个阶段要完成的主要任务和常见的软件开发过程模型很多,包括瀑布模型、演化模型包括原型模型、增量模型和螺旋模型)、喷泉模型、在实践中,软件项目开发团队必须依据拟开发项目的特点 软件开发工程...
  • 增量模型

    2019-09-29 10:53:11
    增量模型(incremental model)与原型实现模型和其他演化方法一样,本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本,但提供了为用户服务的...
  • 【软考之软件过程模型总结】

    热门讨论 2016-11-06 22:38:30
    软件开发模型:常见的有瀑布模型、增量模型、演化模型原型模型和增量模型)、喷泉模型、基于构件的开发模型和形式化模型等,今天,小编来总结一下这几个模型。 核心: 【瀑布模型】 定义:
  • 演化模型 瀑布模式 特点: 阶段间具有顺序性依赖性: 前一阶段完成后,才能开始后一阶段 前一阶段的输出文本为后一阶段的输入文本 推迟实现的观点 质量保证: 每个阶段必须交付出合格的文档 对文档进行审核 ...
  • 常见的软件生存周期模型有瀑布模型、原型模型演化模型、螺旋模型和喷泉模型。下面分别来看一下各个模型。 1.瀑布模型: (1)思想:从制作时间上按工序把问题化简,将功能实现与制作分开便于分工协作。 (2)优点...

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 139
精华内容 55
关键字:

原型模型和演化模型