软件工程案例开发与实践2-2

软件工程案例开发与实践北京交通大学出版社2.3软件开发模型•2.3.1瀑布模型•将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。2.3.2螺旋模型•螺旋模型沿着螺线进行若干次迭代，图2-5中的四个象限代表了以下活动.螺旋模型沿着螺线旋转，每个螺旋推进的过程都是渐进的实现过程，整个过程的实现，按照”制定计划、风险分析、实施工程和客户评估”四个步骤循环实施。•（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。定义资源、进度及其他相关项目信息所需要的任务，以调整项目的目标和改善系统实施的效率。•（2）风险分析：分析评估所选方案，考虑如何识别和消除风险。从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。基于上述目标，评估技术及管理的风险，以决定如何实施项目。•（3）实施工程：实施软件开发和验证。包括系统需求分析、概要设计、详细设计、编程、单元测试、系统测试和验证测试等项目具体实施的各种任务。•(4）客户评估：评价开发工作，提出修正建议，制定下一步计划。•螺旋模型的缺点是：•(1)它可能难以使用户相信演化方法是可控的；•（2）瀑布模型要求在软件开发的初期就完全确定软件的需求，这在很多情况下往往是无法实现的。螺旋模型加入了瀑布模型所忽略的风险分析，从而弥补了瀑布模型的不足。•螺旋模型也有一定的限制条件，这些限制条件是：•1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。•2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。•3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。2.3.3增量模型•增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。•而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早的产生工作软件。•增量模型是在项目的开发过程中以一系列的增量方式开发系统。•增量方式包括增量开发和增量提交。•增量模型也存在以下缺陷：•（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。2.3.4喷泉模型•该模型表明软件刻画活动需要多次重复。•例如，在编码之前，（实践之后），再次进行分析和设计，其间添加有关功能，使系统得以演化。•同时，该模型还表明活动之间没有明显的间隙，例如在分析和设计之间没有明显的界限。2.4快速原型开发•软件原型化方法是指，在获得一组基本需求说明后，经过快速分析构造出一个小型的软件系统（原型系统），满足用户的基本要求。用户试用该原型系统，从中得到感受和启发，并对该原型系统做出反映和评价，然后开发者根据用户的意见对原型加以改进。•随着不断地实验、纠错、使用、评价和修改，不断获得新的原型版本。如此反复，逐步减少分析和通信中的误解，弥补不足，进一步确定各种需求细节，适应需求的变更，从而提高最终产品的质量。2.4.2．软件原型的分类•1.废弃型•也称为快速建立需求规格原型RSP法。先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，从而形成较好设计思想。•2.追加型•也称为快速建立渐进原型RCP法。采用循环渐进的开发方式，对系统模型作连续精化，即先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，将系统需要具备的性质逐步添加上去，通过不断地扩充修改，逐步追加新的要求，直至所有性质全部满足，此时的原型模型也就是最终的产品。2.4.3.原型软件的周期•1．原型分析•原型分析是指在分析者和用户的紧密配合下，快速确定软件系统的基本要求。根据原型所要体现的特性（或总体结构、处理功能，模拟性能、界面形式等），描述基本需求规格说明，以满足开发原型的需要。当在分析阶段使用原型化方法时，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。•2．原型构造•在原型分析的基础上，根据基本需求规格说明，忽略细节，只考虑主要特性，快速构造一个可运行的系统。为此需要强有力的软件工具的支持。•3．原型运行与评价•原型运行与评价阶段是软件开发人员与用户频繁通讯、发现问题、消除误解的重要阶段。其目的是验证原型的正确程度，进而开发新的并修改原有的需求。•4．原型修正•对于原型系统，一定要根据修改意见进行修正。如果原型运行的结果没能满足需求规格说明中的需求，那么就反映出对需求规格说明存在着不一致的理解或实现方案不够合理。若因为严重的理解错误而使正常操作的原型与用户要求相违背时，就有可能产出废品，因此应当立即放弃。•5．判定原型完成•如果原型经过修正或和改进，获得了参与者的一致认可，那么原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。•判定的结果有两个不同的转向：一个是继续迭代验证；另一个是进行详细说明，比如将需求转化为报表，给出统计数字等。对于那些不能通过模型进行说明的成分，如果必要，须提供说明，并利用屏幕等进行讨论和确定。•6．判定原型效果•考察用户新加入的需求信息和细部说明信息，看其对模型效果有何影响？是否会影响模块的有效性？如果使模型效果受到影响，甚至导致模型实效，则要进行修正和改进。•7．整理原型和提供文档•整理原型的目的是为进一步开发提供依据。原型的初期需求模型是一个自动的文档。2.4.4快速原型的优点•1、增进了软件开发人员和用户对系统需求的理解，便于将用户模糊的功能需求明确化。•2、为用户提供了一种强有力的学习手段。•3、易于确定系统的性能，是理解和确认软件需求规格说明的良好工具。•4、按照快速建立渐进原型（RCP）法建立的原型即为最终的产品。2.5软件工程思维的培养•1．考虑整个项目或者产品的市场前景。•2．从用户的角度来考虑问题。•3．从技术的角度考虑问题。•4．合理进行模块的分割。•5．人员的组织和调度。•6．开发过程中文档的编写。•7．充分考虑实施时可能遇到的问题。再见！！！