精华内容
下载资源
问答
  • 原型法开发过程框架

    2011-10-31 17:01:10
    原型法开发过程框架原型法开发过程框架原型法开发过程框架原型法开发过程框架
  • 项目开发原型法

    2020-02-29 23:23:44
    原型法的适用场合主要为处理过程明确、简单系统、涉及面窄的小型系统。原型法是一种从基本需求入手,快速构筑系统的原型,通过原型确认需求以及对原型进行改进,最终达到建立系统的目的的方法。 优点及缺点 ...

    什么是原型法

    用交互的,快速建立起来的原型取代了形式的、僵硬的(不允许更改的)大部分的规格说明,用户通过在计算机上实际运行和试用原型系统而向开发者提供真实的、具体的反馈意见。
    在这里插入图片描述

    适用场景

    原型法的适用场合主要为处理过程明确、简单系统、涉及面窄的小型系统。原型法是一种从基本需求入手,快速构筑系统的原型,通过原型确认需求以及对原型进行改进,最终达到建立系统的目的的方法。

    优点及缺点

    在这里插入图片描述

    展开全文
  • 设计方法(原型法、敏捷开发

    千次阅读 2017-03-13 15:18:58
    原型法和敏捷开发 原型法 定义:又称快速原型法,不属于敏捷开发。 根据需求用IDE实现基本功能,然后用户试用、补充和修改的重复过程,最后的版本再决定是demo还是正式版本。 分类 1. 抛弃型原型 - 此类原型在...

    原型法和敏捷开发


    [快速]原型法

    就是按照客户写的demo。


    分类
    1. 抛弃型原型 - demo的需求客户确认后就抛弃。

          a)探索性 - 为了确认需求;

          b)实验型 - 为了确认规格说明是否可靠。

    2. 进化型原型 - 先构造一个功能简单而且质量bugatti的模型作为核心,然后不断扩充修改,最后发展为最终系统。


    优点:

    1. 由于有用户的直接参与,系统更加贴近实际;

    2. 系统开发循序渐进,反复修改,确保较好的用户满意度;

    3. 开发周期短,费用相对少;


    缺点:

    1. 不适合大规模系统的开发;

    2. 开发过程管理要求高,整个开发过程要经过“修改—评价—再修改”的多次反复;

    3. 用户过早看到系统原型,误认为系统就是这个模样,易使用户失去信心;

    4. 开发人员易将原型取代系统分析;

    5. 缺乏规范化的文档资料


    适用范围:

    1. 用户需求不清,需求经常变化
    2. 规模小,不太复杂
    3. 用户界面

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发的核心思想

    •以人为本
         敏捷方法认为,人是软件开发中最重要的因素。敏捷开发的理念是充分的信任开发团队能够很好的完成任务,这是管理的中心主题。

    •适应变化
         传统的软件开发强调的是,足够清晰的需求,制定详细的文档,按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化,无法应对客户对需求的实时更改,后续的维护必将会付出巨大的代价。
         而敏捷方法则是以最简的方式来迎接变化,客户在整个开发过程中都是参与者,开发团队能够在最短的时间内得到客户的反馈,不断适应需求的变更,从而使得最终的产品能够充分的符合客户的要求。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - XP极限编程

    极限编程(eXtreme Programming)。

    “Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。极限编程强调程序设计团队与业务专家之间的紧密协作、面对面的沟通(比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法,更注重软件开发中人的作用。


    核心价值观
    •沟通(Communication)
         开发人员和设计人员、设计人员和客户的沟通。
    •简单(Simplicity)
         开发前期的整体设计、兼容等直接忽略,专注于最小化解决方案。
    •反馈(Feedback)
         尽快获得用户的反馈。
    •勇气(Courage)
         拥抱变化。


    12个实践原则
    规划策略
         以业务优先级和技术估计为基础,决定下一版本发布的范围。
    结对编程
         结对者是全职合作者,轮流执行键入和监视;这提供了持续的设计和代码评审。
    测试先行
         在编码开始之前,首先将测试写好,而后再进行编码,直至所有的测试都得以通过。
    重构
         改进软件的设计,重构帮助重新组织代码,重新清晰地体现结构和进一步改进设计。
    简单设计
         系统应设计得尽可能简单。
    代码集体所有权
         代码集体所有权强调的是整个团队,而非个人。
    持续集成
       持续集成的思想是任何时候只有一项任务完成,就集成新代码,构造系统并测试。
    现场客户
         客户是Team成员,在开发现场和开发人员一起工作。
    小型发布
         可以保证频繁地反馈和交流,保证客户有足够的依据调控开发过程,降低开发风险。 
    每周40小时工作制
        XP要求项目团队人员每周工作时间不能超过40小时,否则反而会影响生产率。
    编码规范
         编码规范代替不必要的文档。类型包括:格式、代码结构、命名约定、错误处理、注释。 
    系统隐喻
         系统隐喻是将整个系统联系起来的全局视图,每个迭代的隐喻都会演化扩展。


    适用范围
    XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的 代价来满足用户未来的需求,XP在平衡短期和长期利益之间做了巧妙的选择。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - FDD特征驱动开发

    8个实践原则
    · 领域对象建模
    构造类图。系统设计提供了一种整体框架,把对象分解为类,使得系统可以按照特征迭代增量地进行开发。
    · 按照特征开发
    用户眼中最小的、有用的功能进行开发并跟踪过程。 
    · 类(代码)拥有权
    每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。
    · 特征小组
    特征分配给一个确定的开发者,一个特征的实现会涉及到多个类及其所有者,因此,特征的所有者(特征组长)需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别:特征小组的组长更像是教练而不是超级程序员。
    · 审查
    检查软件错误的复审方法,这是FDD确保软件设计和代码质量的一个关键技术。
    · 定期构建
    定期地取出已完成功能的代码,组成完整的可以运行的系统。可以使客户观察到系统开发的进度和实现的功能是否是需要的。
    · 配置管理
    最新版本的确认和历史追踪。
    · 可视性进度报告
    项目成员应该根据完成的工作向各级管理报告工作进度。

    XP极限模式和FDD驱动模式的区别

    · 隐寓和模型
    XP是隐喻,即每个人(设计人员,开发人员、客户)都能讲出系统如何工作的。
    FDD是模型,一个全面的领域对象模型,以便特征小组对每一组特征产生更好的设计。
    · 开发团队
    XP通常不超过10人;FDD的理想团队成员数在16~20人。
    · 代码拥有权
    XP任何人都拥有代码,任何人都可以在需要时添加或修改代码。
    FDD整个开发团队拥有代码,类所有者与特征小组修改。
    · 审查
    XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。
    FDD则提倡采用结构化的形式化审查技术。
    · 测试
    XP中的正确性是由运行单元和功能测试来定义的。
    FDD中单元测试是“按照功能构建”过程的一个部分,由主程序员决定做什么更适合。
    · 项目追踪
    XP让项目经理决定项目追踪方法,鼓励减少数据搜集的工作量,鼓励使用大型图表。
    FDD中的按特征追踪项目的方法,描述了工作量小、准确度量项目进度的手段,提供进度图表。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - Crystal水晶方法

    透明水晶方法,适合于一个小团队来进行敏捷开发,人数在6人以下为宜。


    七大体系特征
    · 经常交付
      项目主办者根据团队的工作进展获得重要反馈;用户有机会发现他们原来的需求是否是他们真正想要的,也有机会将观察结果反馈到开发当中。
    · 反思改进
      如果我们能够经常在迭代会中及时的反思和改进,技术难题应该是不会发生的,或者说发生了,也能够很快的找到解决方案去应对它。
    · 渗透式交流
      若其中一名成员提出问题,工作室内的其他成员可以选择关注或不关注的态度,可以加入到这个问题的讨论当中来,也可以继续忙自己的工作。
    · 个人安全
      个人安全指的是当您指出困扰您的问题时,您不用担心受到报复。个人安全非常重要,有了它,团队可以发现和改正自身的缺点。没有它,团队成员们知而不言,缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任,团队协作才能真正的实施,开发效率也就会直线上升的。
    · 焦点
      所谓“焦点”,就是确定首先要做什么,然后安排时间,以平和的心态开展工作。
    · 与专家用户建立方便的联系
      与专家用户持续建立方便的联系能够给团队提供:对经常交付进行配置以及测试的地方,关于成品质量的快速反馈,关于设计理念的快速反馈,最新的(用户)需求。
    · 配有自动测试(auto-test)、配置管理(git)和经常集成功能的技术环境(git)
      自动测试:代码修改后自动测试,并反馈结果。提高效率。
      配置管理:提交的代码可选择某个节点发布和还原。
      经常集成:开发人员可以一天多次合入本地版本到服务器版本,加快发现错误。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - RUP统一软件开发过程

    RUP(Rational Unified Process),统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational的说法,RUP就好像一个在线的指导者,他可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。


    六个特点
    · 迭代式开发
    迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。
    · 管理需求
    确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用例和脚本的使用以证明是捕获功能性需求的有效方法。
    · 基于组件的体系结构
    组件使重用性成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性,提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
    · 可视化建模
    RUP往往和UML联系在一起,对软件系统建立可视化模型,帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化地对软件系统建模,获取有关体系结构和组件的结构和行为信息。
    · 验证软件质量
    在RUP中软件质量评估是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。
    · 控制软件变更
    RUP通过软件开发过程中的制造出的产品,隔离来自其他工作空间的变更,以此为每个开发人员建立安全的工作空间。迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。


    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - SCRUM迭代式增量软件开发过程

    Scrum是一种灵活的软件管理过程,它可以帮助驾驭迭代、递增的软件开发过程,主要用于产品开发或工作管理。


    Sprint(迭代)
        Scrum的项目过程由一系列的Sprint组成
        Sprint的长度一般控制在2~4周
        通过固定的周期保持良好的节奏
        产品的设计、开发、测试都在Sprint期间完成
        Sprint结束时交付可以工作的软件
        在Sprint过程中不允许发生变更


    敏捷方法之极限编程(XP)和 Scrum区别
    区别之一: 迭代长度的不同
    XP的一个Sprint的迭代长度大致为1~2周;
    Scrum的迭代长度一般为 2~ 4周。
    区别之二: 在迭代中, 是否允许修改需求
    XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。
    Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队受到干扰。
    区别之三: 在迭代中,User Story是否严格按照优先级别来实现
    XP是务必要遵守优先级别的。
    但Scrum在这点做得很灵活,可以不按照优先级别来做。Scrum这样处理的理由是:(1)如果优先问题的解决者,由于其它事情耽搁,那么整个进度就耽误了。(2)如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10。
    区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量
    Scrum没有对软件的整个实施过程开出工程实践的处方,要求开发者自觉保证。
    XP对整个流程方法定义非常严格,规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。


    参考链接:

    原型法

    敏捷开发



    展开全文
  • 关注蓝色按钮微信公众号了解更多信息原型法(Prototyping)原型法概述 原型是一个可以实际运行、反复修改,可以不断完善的系统。 基本思想: 在管理信息系统开发的开始阶段,凭借...原型法开发过程 1、确定系统...

    关注蓝色按钮微信公众号了解更多信息

    原型法(Prototyping)

    原型法概述

      原型是一个可以实际运行、反复修改,可以不断完善的系统。

      基本思想:

      在管理信息系统开发的开始阶段,凭借系统开发售货员对用户需求的理解与用户共同确定系统的基本要求和主要功能,在强有力的人、软件环境支持下,给出一个满足用户需求的初始系统原型,然后与用户反复协商修改,最终形成MIS系统。

    原型法的开发过程

      1、确定系统的基本要求和功能--依据

      2、构造初始原型

      3、运行、评价、修改原型

      4、确定原型后处理

    c0f7ab7a7e16e31189b3b565204ea831.png

      工作流程如图

    原型法的特点

      1、遵循了人们认识事物的客观规律,易于掌握和接受

      2、将模拟的手段引入系统分析的初始阶段,沟通了人们(用户和开发人员)的思想,缩短了用户和系统分析人员之间的距离,解决了结构化方法中最难于解决的一环。强调用户参与、描述、运行、沟通。

      3、充分利用最新的软件工具,摆脱了传统的方法,使系统开发的时间、费用大大地减少,效率、技术等方面都大大地提高。强调软件工具支持。

    原型法的优缺点

      1、从原理到流程十分简单,最终总可以获得一个满意的MIS--无高深理论和技术(方法本身)

      2、用户与开发者思想易于沟通

      3、使用软件工具效率高,摆脱了传统方法

      4、要求管理基础工作完整、准确,一般只适用于小型系统

    原型法的应用范围

      适合于:处理过程明确、简单系统;涉及面窄的小型系统。

      不适合于:大型、复杂系统,难以模拟;存在大量运算、逻辑性强的处理系统;管理基础工作不完善、处理过程不规范的系统;大量批处理系统。

    0f34a9bf3b7c6dc3d1891b906030cd70.png

    原型法周期控制的必要性

      原型法虽有其优点,但也有其缺陷。原型法的主要缺点在于系统的开发缺乏统一规划和标准,导致对系统的开发缺乏有效的控制。原型法根据环境的变化和用户的要求对原型进行修改。由于用户需求具有模糊性和变化性,使开发人员无法确定自己是否已"圆满"完成任务,从而使开发过程无法终止,成为一个"死循环"。因此,必须对原型法开发周期进行控制。

    原型法与生命周期法之比较

      在信息系统开发中常见的另一种方法为生命周期法。它强调整体上的协调和规划,为保证整体性和全局性,它要求用户在分析阶段能够提出准确、完整的系统需求,开发者则据此给出严格的需求定义和描述,并按此进行阶段性的系统开发。为了保证生命周期法的成功必须满足两个条件:首先,用户应该能清楚、完整地提供有关系统的需求,而系统开发者要能够完整、正确地理解和定义这些需求;其次,在整个开发期间,需求一旦定义就不会再发生变化。而现实生活中常常会出现相反的情况:一方面,用户由于缺乏计算机知识,很难确定和表达对未来系统的全面需求,而开发人员对用户的工作环境和内容又不熟悉,对所要解决的问题模糊不清(至少在短时间内),从而导致双方在沟通上出现各种问题,用户无法清楚、完整地表达需求,而开发者不能全面和正确地理解和定义用户需求;另一方面,由于生命周期法的开发周期一般较长,又要求系统设计的目标必须明确,在开发期内用户需求和企业环境很可能发生很大变化,使生命周期法不能适应环境、需求的变化,导致开发出来的系统达不到企业和用户的新需求。而且生命周期法的开发周期较长,用户不能在短期内看到成果,也就不能及时提出修改意见。

      鉴于此种情况,很多企业转向了更加符合实际情况的原型法。原型法则假定开发人员和用户一开始并不能正确、完整地定义需求,在开发过程中用户的需求也随着企业环境的变化而变化。原型法利用对原型的不断修改与完善解决了这两个问题。首先,原型法在系统开发初始阶段只提出一个满足用户基本需求的原型;其次,原型法更多地遵循了人们认识事物的规律,采取了"修改一反馈"循环往复的开发方式。在一个开发人员不熟悉的业务领域,用户需求不可能被开发者迅速、准确地理解,能有一个基础模型不断启发诱导,可以给用户一个非常直观、形象的印象,使用户在开发过程中逐渐加深对系统的理解,使双方都能参与到原型的完善之中,及早发现原型的不足和缺陷,及时进行修改和完善,从而使系统能不断地适应用户的新要求和企业环境的变化。而且在开发过程中用户不断参与评价和修改模型,逐步地消除了用户对计算机的恐惧感和抵触情绪,使其对计算机的了解不断深化,这也有助于用户能够更好地理解、定义系统需求,更好地与系统开发人员进行交流,同时也使用户在系统切换之后能更快、更好地掌握系统使用方法,更好地发挥系统的性能。因此原型法与生命周期法相比具有成功率高、开发周期短、适应性强、可靠性强、成本低和调试容易的特点。

      由于生命周期法本身存在的问题和原型法异常优越的性能特点,使得不少企业在开发信息系统时会倾向于选择原型法。

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

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


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

        典型的开发模型有:①瀑布模型(waterfall model);②渐增模型/演化/迭代(inCRemental model);③原型模型(prototype model);④螺旋模型(SPIral model);⑤喷泉模型(fountAIn model);⑥智能模型(intelligent model) ; 7. 混合模型(hybrid model)



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


      在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。
      这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:
      (1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;
      (2) 忽略需求环节,给软件开发带来很大的风险;
      (3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

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

        在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
      瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:
      (1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;
      (2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;
      (3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

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

    3. 快速原型模型(RAPId Prototype Model)
      快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
      显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。

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

    4. 增量模型(Incremental Model)
      与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.
      增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:
      (1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
      (2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。

     在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。
      例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。

    5.螺旋模型(Spiral Model)
      1988年,Barry Boehm正式发表了软件系统开发的"螺旋模型",它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
      螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:
      (1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
      (2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;
      (3) 实施工程:实施软件开发和验证;
      (4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。
      螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:
      (1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。
      (2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。
      (3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

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

    6.演化模型(incremental model)

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

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

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


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

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

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

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

    展开全文
  • 项目型软件的开发流程,...在项目型产品的开发过程中,依据软件工程思想的标准,遵循软件开发流程(Software development process)一步步的操作是最正统和最标准而且有效的做法,项目组人员的理解并落实这一点,...
  • 原型法, 瀑布模型, V-模型, 螺旋模型

    千次阅读 2017-11-10 22:20:46
    使用原型法,在用户的共同参与下可以改善和加快需求获取过程。其第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足...
  • 而在这个过程中,提出了许多不同的软件开发模型,典型的有:瀑布式,快速原型法,以及迭代式开发等。 瀑布式模型 是由W.W.Royce在1970年最初提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析,...
  • 文章目录瀑布模型/改进的瀑布模型螺旋模型增量和迭代模型原型法快速和敏捷开发关于选择生命周期模型的最后的总结 瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效...
  • Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 原型法在现在的软件开发过程中被
  • 原型法适用于用户没有确定其需求的明确内容的时候。他先是根据已给的和分析的需求,建立一个原始模型,这是一个可以修改的模型(在声明周期法中,需求分析一般不再多修改)。在软件开发的各个阶段都把有关信息相互...
  • 学习现代软件工程思想,体验软件开发的过程,以及开发过程中文档的撰写 一、对比原型设计工具 1.Axure 使用体会: Axure作为老牌的原型图工具,功能最齐全,交互最多样。设计过程中可以将多个页...
  • 在日常产品设计中,从产品经理到开发,Axure已经成为了标准的沟通工具及设计工具,交互设计环节也确实起到了产品设计和产品开发之间的关键作用。但是,通过跟很多产品经理的接触和沟通,我发现对于Axure这个设计工具...
  • 软件开发过程与项目管理(4.软件项目需求管理)软件需求定义软件需求管理的过程1.需求获取2.需求分析3.需求规格编写4.需求验证5.需求变更管理需求建模的基本方法介绍原型方法结构化分析面向对象的用例分析用例...
  • 浅谈界面原型

    2015-06-02 09:16:50
    原型法在现在的软件开发过程中被广泛使用。首先,我们要明确的是,任何一种方法或工具都是为我们开发、生产过程服务的,这一点必须清楚,我们不能成为方法或工具的奴隶,只要我们认为这个方法论或工具对我们的过程...
  • 本方法改进以"原型法"为基础,通过在软件界面原型的基础上增加了"成员属性信息"、"成员约束信息"和"非功能需求信息"3项内容,用来描述原型的静态属性特征,同时使用"业务流程图"和"数据流图"定义系统的动态特征。...
  • Eiffel语言的软件开发过程前面已提到,Eiffel支持整个生命周期。下述软件开发周期观点不仅从根本上不同于传统的“直瀑”模型(指一连串的独立步骤,如需求分析、总体设计、详细设计、实现,由主要的方法和表示分开...
  • (3)要有除原型法之外的其他需求获取手段; (4)收集用户需求调研活动的佐证材料(访谈录音、问卷、调研人员名单等等)。 1. 调查问卷:https://www.wjx.cn/jq/23874661.aspx  利用问卷星,列出来13道题对在校...
  • 系统开发基础

    2019-07-23 14:03:17
    软件开发方法 软件开发方法 软件开发模型 构件与软件重用 逆向工程 ... 原型法:适用于需求不明确的开发,包括抛弃型原型和进化型原型 面向对象方法:更好的复用性,关键在于建立一个全面,合...
  • 综合集成多种定性模拟、数学方法和博弈论纳什均衡的思想,设计了企业关键岗位管理人员甄选定性模拟方法,开发原型系统,包括:借鉴模糊数学和QSIM算法的思路表述定性变量;...
  • 一、瀑布模型(SDLC)1、瀑布模型,也称生命...2、演化模型:在快速开发一个原型的基础上,根据用户在调用原型过程中提出的反馈和一件,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产...
  • 生命周期

    千次阅读 2007-05-09 21:06:00
    6、生命周期法的优点是什么,原型法的缺点是什么?(1) 强调系统的整体性、全局性。它采用“自顶向下” 的原则分析和设计系统,首先解决全局问题,强调在系统整体优化的前提下,来考虑具体的解决方案。 (2) 严格区分...
  • 信息系统的开发方法

    2011-04-20 00:32:00
    信息系统的开发方法有三种,分别是结构法、原型法和面向对象法。 结构法:强调工作的整体性和全局性,严格区分工作阶段。 原型法:在需求不明确的情况下,快速的创建原型明确需求。 面向对象法:直观、方便为特点...

空空如也

空空如也

1 2 3 4 5 ... 12
收藏数 234
精华内容 93
关键字:

原型法开发过程