第9章_软件开发增量模型

9.1概述9.1.1.瀑布模型的局限性在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型。传统的瀑布模型如图所示。•瀑布模型的特点阶段间具有顺序性和依赖性。其中包含两重含义：①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。9.1概述9.1概述•瀑布模型的特点①瀑布模型在编码之前设置了系统分析和系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。②清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。9.1概述•瀑布模型的特点质量保证的观点①每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。9.1概述•实际的瀑布模型实际的瀑布模型是带“反馈环”的，如图所示。9.1概述•瀑布模型的优点可强迫开发人员采用规范化的方法。严格地规定了每个阶段必须提交的文档。要求每个阶段交出的所有产品都必须是经过验证的。9.1概述•瀑布模型的缺点由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。瀑布模型只适用于项目开始时需求已确定的情况。很难适应需求可变、模糊不定的软件系统的开发，而且再开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。9.1概述9.1.2增量模型的基本思想•增量模型属于非整体开发模型，它推迟某些阶段或所有阶段的细节，从而较早的产生工作软件•增量方式包括增量开发和增量提交•增量开发指在项目开发周期内，以一定的时间间隔开发部分工作软件•增量提交指在项目开发周期内，以一定的时间间隔向用户提交工作软件及相应文档。9.1概述9.1.3增量模型的分类1.渐增模型•增量构造模型:在瀑布模型基础上，对一些阶段进行整体开发，对另一些阶段进行增量开发•演化提交模型：所有阶段都进行增量开发。2.原型模型•探索型原型•实验型原型•演化型原型9.1概述1、探索型原理这种类型的原型是把原型用于开发的需求分析阶段，目的是要型清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发都对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。2、实验型原型这种原型主要用于设计阶段，考核；实现方案是否合适，能否实陋。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。3、演化型原型这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。9.2渐增模型9.2.1增量构造模型增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。9.2渐增模型•增量构造模型增量构造模型如图所示。9.2渐增模型•增量模型的优点(1)能在较短时间内向用户提交可完成一些有用的工作产品，即从第1个构件交付之日起，用户就能做一些有用的工作。(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。因此，最重要的系统服务将接受最多的测试。9.2渐增模型9.2.2演化提交模型每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布模型的方式，如图所示。9.2渐增模型•采用增量模型需注意的问题(1)在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。(2)软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。9.3快速原型模型9.3.1基本思想1.原型：原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。•快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。2。快速原型思想的产生9.3快速原型模型•由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。又把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展。即先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。9.3快速原型模型•由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。做两次需求分析原型开发与建模原型评价系统设计系统实现测用户反馈•第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求•第二次则在此基础上获得较为满意的软件产品9.3快速原型模型3.原型运用方式由于运用原型的目的和方式不同，在使用原型时也采用不同的策略，有抛弃策略和附加策略：•抛弃策略是将原型用于开发过程的某一阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型快速原型采用此策略•附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型采用此策略。9.3快速原型模型9.3.2快速原型模型表示快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型如图所示：9.3快速原型模型快速分析需求说明构造原型原型运行原型评价原型修改意见修改类型停止修改修改说明修改原型需求分析需求说明设计设计说明编码源程序测试软件产品维护9.3快速原型模型•快速原型模型的优点(1)有助于满足用户的真实需求。(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。(3)软件产品的开发基本上是按线性顺序进行。(4)因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。9.3快速原型模型•快速原型模型的优点(5)开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。(6)快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。9.3快速原型模型9.3.3原型开发过程1.原型构造要求构造原型时，不需注意功能性能的取舍，忽略一切暂时不关心的部分以加速原型的实现，同时又充分体现原型的作用，满足评价原型的要求。2.原型的特征分类•系统的界面形式•系统的总体结构•系统的主要处理功能和性能•数据库模式9.3快速原型模型3.原型开发步骤（1）快速分析在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。(2)构造原型在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚固性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。9.3快速原型模型（3）运行原型这是发现问题、消除误解、开发者与用户充分协调的一个步骤。（4）评价原型在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见。（5）修改根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。9.4快速原型的开发技术和开发环境为了减少开发原型的开销，实现快速地分析，迅速地构造出所需的原型，应采用一些特殊的有别于通常软件开发时使用的技术和工具。1.构造原型的技术(1)可执行的规格说明(2)基于脚本的设计。(3)采用非常高级语言或专门语言。(4)能重用软件。9.4快速原型的开发技术和开发环境2.构造原型的建议(1)暂不考虑速度、空间等性能效率方面的要求。(2)暂不考虑错误恢复和处理。(3)可降低可靠性和软件质量标准。(4)原型界面部分要设计得简单易学，最好能与最终系统的界面相容。(5)根据不同的软件类型和应用领域，可使用不同风格的高级语言来构造原型。9.4快速原型的开发技术和开发环境3.原型的开发环境除了上述的构造原型的技术和建议外，还应该有开发环境来辅助原型的开发。(1)交互式系统。能快速地响应使用者的要求。(2)数据库管理系统。能够提供更多工具，可以定义、建立、查询、加工信息资源。(3)通用输入/输出软件。容易使用的数据编辑，屏幕格式化软件等对原型设计和开发都有很大的帮助。(4)重用代码库。可减少重复劳动。9.5增量模型的评价1.原型的作用(1)为软件系统提供明确的需求说明，当用户要求含糊不清、不完全、不稳定时，通过原型执行、评价，使用户要求明确。(2)原型可作为新颖设计思想的思想工具，也可作为高风险开发的安全因素，从而证实设计的可行性。(3)原型模型支持软件产品的演化，对开发过程中的问题和错误具有应付变化的机制。(4)原型模型鼓励用户参与开发过程，参与原型的运用和评价，能充分地与开发者协调一致。9.5增量模型的评价•2.使用原型的建议能够使用原型的情况：(1)开发周期很长的项目，通过原型开发来缩短开发周期。(2)系统的使用可能变化较大，不能相对稳定，而原型模型具有适应变化的机制。(3)用户对系统的需求较为模糊，对某种要求缺乏信心。(4)开发者对系统的某种设计方案的实现无信心或无十分把握。上述这些情况均适合于使用原型模型来开发。9.5增量模型的评价•不宜使用原型的情况：a.缺乏开发工具，或对原型的可用工具不了解时b.用户不愿参与开发c.用户的数据资源没有很好地组织和管理时d.用户的软件资源没有被组织和管理时9.5增量模型的评价3.原型的优点(1)可及早为用户提供有用的产品。(2)可及早发现问题，随时纠正错误。(3)减少技术、应用风险，缩短开发实际，减少费用，提高生产率。(4)通过实际运行原型，提供直接评价系统的方法，促使用户主动参与开发活动，加强了信息反馈，促进各类人员的协调，减少误解，适应需求的变化，能有效提高系统质量。9.5增量模型的评价4.存在问题(1)缺乏丰富而强有力的软件工具和开发环境。(2)缺乏有效的管理机制，还未建立起自己的开发标准。(3)对设计人员水平及开发环境要求较高。(4)在多次重复改变原型的过程中，程序员会感到厌倦。(5)系统的易变性对测试有一定影响