《软件工程模型与方法 02、软件生命周期模型.ppt》由会员分享，可在线阅读，更多相关《软件工程模型与方法 02、软件生命周期模型.ppt（60页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件工程模型与方法 Models&Methods of SE第二章 软件生命周期模型肖丁肖丁 2本章内容本章内容u2.1 软件工程过程u2.2 软件生命周期u2.3 软件过程模型u2.4 传统软件生命周期模型u2.5 新型软件生命周期模型32.1 软件工程过程软件工程过程u软件工程过程是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。主要有：软件规格说明：规定软件的功能及其使用限制；软件开发：产生满足规格说明的软件；软件确认：通过有效性验证以保证软件能够满足客户的要求；软件演进：为了满足客户的变更要求，软件必须在使用过程中进行不断地改进。42.2 软件生命周期软件生命
2、周期u软件生命周期是指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交阶段等不同时期。u软件生命周期的六个基本步骤制定计划需求分析设计程序编码测试运行维护5制定计划制定计划u确定要开发软件系统的总目标；u给出功能、性能、可靠性以及接口等方面的要求；u完成该软件任务的可行性研究；u估计可利用的资源(硬件，软件，人力等)、成本、效益、开发进度；u制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查；6需求分析需求分析u对用户提出的要求进行分析并给出详细的定义；u编写软件需求规格说明书或系统功能说明书及初步的系统用户手册；u
3、提交管理机构评审；7设计设计u概要设计：把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应；u详细设计：对每个模块要完成的工作进行具体的描述，为源程序编写打下基础；u编写设计说明书，提交评审。8程序编码程序编码u把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”；u写出的程序应当是结构良好、清晰易读的，且与设计相一致的；9测试测试u单元测试，查找各模块在功能和结构上存在的问题并加以纠正；u组装测试，将已测试过的模块按一定顺序组装起来；u按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付
4、用户使用；10运行维护运行维护u改正性维护：运行中发现了软件中的错误需要修正；u适应性维护：为了适应变化了的软件工作环境，需做适当变更；u完善性维护：为了增强软件的功能需做变更。112.3 软件过程模型软件过程模型u模型是实际事物、实际系统的抽象。u模型的表示形式是可以多种多样的，可以是数学表达式、物理模型或图形文字描述等等。只要能回答所需研究问题的实际事物或系统的抽象表达式，都可称为模型。工作流（work flow）模型：描述软件过程中各种活动的序列、输入和输出，以及各种活动之间的相互依赖性。它强调软件过程中活动的组织控制策略。数据流（data flow）模型：描述将软件需求变换成软件产品的
5、整个过程中的活动，这些活动完成将输入工件变换成输出工件的功能。它强调软件过程中的工件的变换关系，对工件变换的具体实现措施没有加以限定。角色/动作模型：描述了参与软件过程的不同角色及其各自负责完成的动作，即根据参与角色的不同将软件过程应该完成的任务划分成不同的职能域（function area）。122.4 传统软件生命周期模型传统软件生命周期模型u软件过程模型也称做软件生命周期模型，是从一个特定角度提出的对软件过程的简化描述，是对软件开发实际过程的抽象，它包括构成软件过程的各种活动、软件工件（artifact）以及参与角色等。u软件生命周期模型是一个框架，描述从软件需求定义直至软件经使用后废弃
6、为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等。13模型种类模型种类u2.4.1 瀑布模型u2.4.2 V模型和W模型u2.4.3 原型方法u2.4.4 演化模型u2.4.5 增量模型u2.4.6 螺旋模型u2.4.7 喷泉模型u2.4.8 构件组装模型u2.4.9 快速应用开发模型142.4.1 瀑布模型瀑布模型uWinston Royce在软件生命周期概念的基础上，于1970年提出了著名的“瀑布模型”（waterfall model）。152.4.1 瀑布模型瀑布模型u瀑布模型中的每一个开发活动具有下列特
7、征：本活动的工作对象来自于上一项活动的输出，这些输出一般是代表该阶段活动结束的里程碑式的文档。根据本阶段的活动规程执行相应的任务。产生本阶段活动相关产出软件工件，作为下一活动的输入。对本阶段活动执行情况进行评审。162.4.1 瀑布模型瀑布模型u瀑布模型的优缺点优点缺点降低了软件开发的复杂程度，而且提高了软件开发过程的透明性，提高了软件开发过程的可管理性。模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。推迟了软件实现，强调在软件实现前必须进行分析和设计工作。模型的风险控制能力较弱。以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并
8、纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量；而且当管理人员以文档的完成情况来评估项目完成进度时，往往会产生错误的结论。172.4.2 V模型和模型和W模型模型u1980年代后期Paul Rook提出了V模型 18W模型模型uEvolutif公司在V模型的基础上提出了W模型 192.4.3 原型方法原型方法u原型方法的产生u瀑布模型、V模型和W模型都将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。u然而完整而准确的需求规格说明是很难得到的，因为：在开发早期用
9、户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求 随着开发工作的推进，用户可能会产生新的要求开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境 202.4.3 原型方法原型方法u原型指模拟某种最终产品的原始模型；u原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。u用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。u原型方法主要用于明确需求，但也可以用于软件开发的其他阶段。212.4.3 原型方法原型方法u原型的三种作用类型：探索型：弄清用户对目标系统的
10、要求，确定所期望的特性；探讨多种实现方案的可行性。主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。实验型；用于大规模开发和实现之前，考核技术实现方案是否合适、分析和设计的规格说明是否可靠。进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统。它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目。222.4.3 原型方法原型方法u由于运用原型的目的和方式不同，在使用原型时可采取以下两种不同的策略：废弃策略：原型主要用于反馈和评价，据此设计出完整、准确、一致、可靠的最终系统。系统构造完成后，原型系统就被废弃不用。探索型和实验型原型
11、属于这种策略。追加策略：原型作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。它对应于进化型原型。232.4.3 原型方法原型方法u原型提供了用户与开发人员良好的沟通手段，易于被人们接受，使用原型方法有以下好处：原型方法有助于增进软件人员和用户对系统服务需求的理解；原型方法提供了一种有力的学习手段；使用原型方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果；软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。242.4.3 原型方法原型方法
12、u原型法的适用范围和局限性：对于一个大型系统，如果不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。对于大量运算的、逻辑性较强的程序模块，原型方法很难构造出该模块的原型来供人评价。对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。对于一个批处理系统，由于大部分活动是内部处理的，因此应用原型方法会有一定的困难。252.4.3 原型方法原型方法u原型方法存在的问题：文档容易被忽略。建立原型的许多工作会被浪费掉。项目难以规划和管理。262.4.3 原型方法原型方法u1984年Boar提出一系列影响原型方法选择的因素 方面适用原型法不适用原型法系统结构联机事务处理系
13、统、相互关联的应用系统 批处理系统 逻辑结构有结构系统，如运行支持系统、管理信息系统 基于大量算法和逻辑结构的系统 用户特征积极参与、积极决策应用约束在线运行系统的补充项目管理项目负责人愿意使用原型方法 项目环境需求复杂易变、性能要求高需求明确固定272.4.3 原型方法原型方法u原型方法的应用过程282.4.3 原型方法原型方法原型方法可以支持软件生命周期的不同阶段 u辅助或代替分析阶段 u辅助设计阶段 u代替分析与设计阶段 u代替分析、设计和实现阶段 u代替全部开发阶段 292.4.4 支持原型构造的软件复用技术支持原型构造的软件复用技术 u原型快速法要求具有可复用的软件模块的支持，这些模
14、块应该满足以下条件：必须有简单而清晰的接口；应当具有高自包含性，即尽量不依赖其他模块或数据结构；应具有一些通用的功能；应有较好的文档规范描述模块的接口、功能和错误条件等 u从复用的内容角度可以划分其类型为：数据复用模块复用结构复用设计复用规格说明复用30软件复用的实现机制软件复用的实现机制u软件复用的两种实现机制：合成复用：构件是基础，构件以抽象数据类型为理论基础，将功能实现细节与数据结构封装在构件内部，对外有着精心设计的接口，供外部使用者构造应用时调用。构件本身可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用构件来构造软件系统，有较高的生产率和较短的开发周期。生成复
15、用：利用可复用的模式（Patterns），通过生成程序产生一个新的应用程序或程序段 312.4.5 演化模型演化模型u使用瀑布模型人们认识到，由于需求很难调研充分，所以很难一次性开发成功。u演化模型提倡两次开发：第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求；第二次在此基础上获得较为满意的软件产品。322.4.5 演化模型演化模型u演化模型分类：探索式演化模型抛弃式演化模型u演化模型的特点：优点：明确用户需求、提高系统质量、降低开发风险；缺点：难于管理、结构较差、技术不成熟；可能会抛弃瀑布模型的文档控制优点；可能会导致最后的软件系统的系统结构较差；u演化模型适用
16、范围：需求不清楚；小型或中小型系统；开发周期短332.4.6 增量模型增量模型uMills等人于1980年提出，指首先对系统最核心或最清晰的需求进行分析、设计、实现、测试并集成到系统中。再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法。u结合了瀑布模型和演化模型的优点。342.4.6 增量模型增量模型u增量模型的优点：客户可以在第一次增量后就使用到系统的核心功能，增强了客户使用系统的信心；项目总体失败的风险较低，因为核心功能先开发出来，即使某一次增量失败，核心功能的产品客户仍然可以使用。由于增量是按照从高到低的优先级确定的，最高优先级的功能得到最多次的测试，保障了系统重
17、要功能部分的可靠性。所有增量都是在同一个体系结构指导下进行集成的，提高了系统的稳定性和可维护性。u增量模型的缺点：增量粒度难以选择；确定所有的基本业务服务比较困难；352.4.7 螺旋模型螺旋模型uBoehm于1988年提出，主要针对大型软件项目的开发。u四个象限制定计划 风险分析实施工程客户评价 362.4.7 螺旋模型螺旋模型u制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。u 风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理
18、措施规避这些风险。u实施工程：针对每一个开发阶段的任务要求执行本开发阶段的活动。u客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。372.4.8 喷泉模型喷泉模型u喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。u各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。u优点：提高开发效率缩短开发周期u缺点：难于管理 382.4.9 构件组装模型构件组装模型u利用模块化思想将整个系统模块
19、化，并在一定构件模型的支持下复用构件库中软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的。u构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。392.4.9 构件组装模型构件组装模型u优点：充分利用软件复用，提高了软件开发的效率。允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。u缺点：缺乏通用的构件组装结构标准，风险较大；构件可重用性和系统高效性之间不易协调；由于过分依赖于构件，构件质量影响着最终产品的质量。402.4.10 快速应用开发模型快速应用开发模型u快速应用开发（Rapid App
20、lication Development，RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。412.4.10 快速应用开发模型快速应用开发模型uRAD模型的缺点：并非所有应用都适合采用RAD 由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败 RAD适合于管理信息系统的开发，对于其他类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适 422.5 新型软件生命周期模型新型软件生命周期模型u2.5.1 RUPu2.5.2 敏捷模型432.5.1 RUPuRUP（Rational Unified Process）是
21、由Rational公司（现被IBM公司收购）开发的一种软件工程过程框架，是一个面向对象的基于web的程序开发方法论。uRUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中。442.5.1 RUPuRUP的基本结构452.5.1 RUPuRUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。u每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这
22、个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。462.5.1 RUPu初始阶段 目标是为系统建立商业案例（business case）并确定项目的边界。商业案例包括项目的验收规范、风险评估、所需资源估计、阶段计划等。要确定项目边界，需识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。阶段结束里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑包括一些重要的文档，如：项目构想（vision）、原始用例模型、原始业务风险评估、一个或
23、者多个原型、原始商业案例等。需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。472.5.1 RUPu细化阶段 目标是分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。里程碑：生命周期体系结构（Lifecycle Architecture）里程碑。生命周期体系结构里程碑包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。482.5.1 RUPu构造阶段将所有剩余的技术构件和稳定业务需求功能开发出来，并集成
24、为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。里程碑：初始运行能力（Initial Operational Capability）里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运行。492.5.1 RUPu移交阶段 移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。里程碑：产品发布(Product Release)里程碑。此时，要确定最终目标是否实现，是否应该
25、开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。502.5.1 RUPuRUP的迭代增量开发思想uRUP是融合了喷泉模型和增量模型的一种综合生命周期模型。512.5.1 RUPuRUP的9个核心工作流u6个核心过程工作流商业建模（Business Modeling）需求（Requirements）分析和设计（Analysis&Design）实现（Implementation）测试（Test）部署（Deployment）u3个核心支持工作流：配置和变更管理（Configuration&Change Management）项目管理（Project Ma
26、nagement）环境（Environment）522.5.1 RUPuRUP的最佳实践：短时间分区式的迭代：26周，不鼓励时间推迟；适应性开发：小步骤、快速反馈和调整；在早期迭代中解决高技术风险和高业务价值的问题；不断地让用户参与迭代结果的评估，并及时获取反馈信息，以逐步阐明问题并引导项目进展；在早期迭代中建立内聚的核心架构。该实践是和早期处理高技术风险和高业务价值问题有关的，因为核心架构一般和高风险因素紧密相关。532.5.1 RUP不断地验证质量；尽早、经常和实际地测试；使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。可视化软件建模：使用UML
27、（Unified Modeling Language，统一建模语言）进行软件建模。仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪。拙劣的需求管理是项目陷入麻烦的一个常见原因。实行变更请求和配置管理。542.5.2 敏捷模型敏捷模型u敏捷建模（Agile Modeling，AM）是由Scott W.Ambler从许多的软件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它只是一种态度，不是一个说明性过程。uAM是对已有生命周期模型的补充，它本身不是一个完整的方法论，在应用传统的生命周期模型时可以借鉴AM的过程指导思想。552.5.2 敏捷模
28、型敏捷模型u敏捷建模的价值观沟通：建模不但能够促进团队内部开发人员之间沟通，还能够促进团队和项目干系人（project stakeholder）之间的沟通。简单：画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件开发过程的关键。反馈：通过图表来交流建模想法，可以快速获得彼此的反馈。勇气：如果一项决策证明是不合适的时候，就需要勇气做出重大的决策：放弃或重构（refactor）先前的工作，修正建模方向。谦逊：最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。562.5.2 敏捷模型敏捷模型u敏捷建模核心原则：主张简单；拥抱变化；软件开发的第二个目标应是
29、可持续性 递增的变化 令项目干系人投资最大化 有目的地建模 572.5.2 敏捷模型敏捷模型多种模型 高质量的工作 快速反馈 以有效的方式，制造出满足项目干系人所需要的软件，而不是制造无关的文档、无关的用于管理的工件，甚至无关的模型 轻装前进 582.5.2 敏捷模型敏捷模型u敏捷模型补充原则：内容比表示更重要 三人行必有我师 了解软件建模方法 了解软件开发工具 局部调整 开放诚实的沟通 利用好直觉 592.5.2 敏捷模型敏捷模型u敏捷建模核心实践项目干系人的积极参与 正确使用工件 集体所有制 测试性思维 并行创建模型 创建简单的内容 简单地建模 公开展示模型 切换到另外的工件 小增量建模 和他人一起建模 用代码验证 使用最简单的工具 602.5.2 敏捷模型敏捷模型u敏捷模型补充实践：使用建模标准 逐渐应用模式（pattern）丢弃临时模型 合同模型要正式 为外部交流建模 为帮助理解建模 重用现有的资源 不到万不得已不更新模型