软件工程第九章.doc

9.1 概述 在瀑布模型的开发过程中，人们花费极大的努力进行严格开发，但终究难以接近理想目标，在需求说明维以完善、难以明确的情况下，由快速分析而构造一个小的原形系统，满足用户的某些要求后，使用户在使用过程中受其启发，逐步确定各种需求，因此，产生了所谓的渐增模型和快速原型模型9.1.1瀑布模型的局限性 瀑布模型这种模型本质上是一种线性顺序模型，因此存在着较明显的缺点，各阶段之间存在着严格的顺序性和依赖性，特别强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步的实现这些需求。但是实际项目很少遵循着这种线性顺序进行的。虽然瀑布模型也允许迭代，但这种改变往往对项目开发带来混乱。在系统建立之前很难只依靠分析就确定出一套完整、准确、一致、有效的用户需求，这种预先定义需求的方法更不能适应用户需求的不断变化的情况。 1.需求是可变的 某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关，因此需求是随时变化的。 2.需求是模糊的 对于大多数更常使用的应用系统，例如管理信息系统，其需求往往很难预先准确的指定，也就是说，预先定义需求的策略所做出的假设，只对某些软件成立，对多数软件并不成立。许多用户对他们的需求最初只是模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的。人们为了充实和细化他们的初步设想，通常需要经过在某个能运行的系统上实践的过程。 3.用户和开发者难于沟通 大型软件的开发需要系统分析员、软件工程师、程序员、用户、领域专家等各类人员的协调配合。然而大多数用户和领域专家不熟悉计算机和软件技术，软件开发人员也往往不熟悉用户的专业领域，开发人员和用户之间很难做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不正确的。传统的瀑布模型很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程，缺乏灵活性，不适应实际的开发过程。9.1.2 增量模型的基本思想 为了克服瀑布模型的局限性，使开发过程具有一定的灵活性和可修改性，于是产生了增量模型。增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早的产生工作软件。 增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，以一定的时间间隔开发部分工作软件；增量提交是指在项目开发周期内，以一定的时间间隔增量方式向用户提交工作软件及相应文档。9.1.3 增量模型的分类 有多种增量模型，根据增量的方式和形式的不同，分为渐增量模型和原型模型。1.增量模型： (1)增量构造模型。 它在瀑布模型基础上，对一些阶段进行整体开发，对另一些阶段进行增量开发。即前面的开发阶段按瀑布模型进行整体开发，后面的开发阶段按增量方式开方。 (2)演化提交模型。 它在瀑布模型的基础上，所有阶段都进行增量开发，也就是说不仅是增量开发，也是增量提交。2.原型模型 这种开发模型又称快速原型模型，它是增量型的另一种形式。它是在开发真实系统之前，构造一个原型的基础上，逐渐完成整个系统的开发工作。根据原型的不同作用，有三类原型模型： (1)探索模型。 这种类型的原型模型是把原型用于开发的需求分析阶段，目的是要弄清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要对开发目标模糊，用户与开发者对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。 (2)实验型原型。 这种原型主要用于设计阶段，考核实现方案是否合适，能否实现。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。 (3)演化型原型。 这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。9.2渐增模型9.2.1 增量构造模型 需求分析阶段和设计阶段都是按瀑布模型的整体方式开发，但是编码阶段和测试阶段是按增量方式开发。9.2.2 演化提交模型 在该模型中，项目开发的各个阶段都是增量方式。先对某部分功能进行需求分析，然后顺序进行设计、编码测试，把该功能的软件交付给用户，然后再对另一部分功能进行开发，提交用户直至所有功能全部增量开发完毕。9.3 快速原型模型9.3.1 基本思想1.原型 原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。2.快速原型思想的产生 由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。又把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展。即先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。3.快速原型的原理 快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。4.原型运用方式 由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。 (1)抛弃策略是将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的。 (2)附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。 采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、人员素质、可供支持的原型开发工具和技术等，这要根据实际情况的特点来决定。9.3.2快速原型模型表示9.3.3 原型开发过程1.原型开发步骤 (1)快速分析。 在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。 (2)构造原型。 在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚固性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。 (3)运行原型。 这是发现问题、消除误解、开发者与用户充分协调的一个步骤。 (4)评价原型。 在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见。 (5)修改。 根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。9.4快速原型的开发技术和开发环境 为了减少开发原型的开销，实现快速地分析，迅速地构造出所需的原型，应采用一些特殊的有别于通常软件开发时使用的技术和工具。 1.构造原型的技术 (1)可执行的规格说明 (2)基于脚本的设计。 (3)采用非常高级语言或专门语言。 (4)能重用软件。 2.构造原型的建议 (1)暂不考虑速度、空间等性能效率方面的要求。 (2)暂不考虑错误恢复和处理。 (3)可降低可靠性和软件质量标准。 (4)原型界面部分要设计得简单易学，最好能与最终系统的界面相容。 (5)根据不同的软件类型和应用领域，可使用不同风格的高级语言来构造原型。 3.原型的开发环境 除了上述的构造原型的技术和建议外，还应该有开发环境来辅助原型的开发。 (1)交互式系统。能快速地响应使用者的要求。 (2)数据库管理系统。能够提供更多工具，可以定义、建立、查询、加工信息资源。 (3)通用输入/输出软件。容易使用的数据编辑，屏幕格式化软件等对原型设计和开发都有很大的帮助。 (4)重用代码库。可减少重复劳动。9.5增量模型的评价 1.原型的作用 (1)为软件系统提供明确的需求说明，当用户要求含糊不清、不完全、不稳定时，通过原型执行、评价，使用户要求明确。 (2)原型可作为新颖设计思想的思想工具，也可作为高风险开发的安全因素，从而证实设计的可行性。 (3)原型模型支持软件产品的演化，对开发过程中的问题和错误具有应付变化的机制。 (4)原型模型鼓励用户参与开发过程，参与原型的运用和评价，能充分地与开发者协调一致。 2.使用原型的建议 能够使用原型的情况： (1)开发周期很长的项目，通过原型开发来缩短开发周期。 (2)系统的使用可能变化较大，不能相对稳定，而原型模型具有适应变化的机制。 (3)用户对系统的需求较为模糊，对某种要求缺乏信心。 (4)开发者对系统的某种设计方案的实现无信心或无十分把握。 上述这些情况均适合于使用原型模型来开发。 3.原型的优点 (1)可及早为用户提供有用的产品。 (2)可及早发现问题，随时纠正错误。 (3)减少技术、应用风险，缩短开发实际，减少费用，提高生产率。 (4)通过实际运行原