软件工程模型与方法 Models & Methods of Software Engineering

Presentation on theme: "软件工程模型与方法 Models & Methods of Software Engineering"— Presentation transcript:

1 软件工程模型与方法 Models & Methods of Software Engineering
第二章 软件生命周期模型 修佳鹏 © BUPT TSEG

2 本章内容 2.1 软件工程过程 2.2 软件生命周期 2.3 软件过程模型 2.4 传统软件生命周期模型 2.5 新型软件生命周期模型
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

3 2.1 软件工程过程 软件工程过程是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。
软件规格说明（specification）：规定软件的功能及其使用限制； 软件开发（development）：产生满足规格说明的软件； 软件确认（validation）：通过有效性验证以保证软件能够满足客户的要求； 软件演进（evolution）：为了满足客户的变更要求，软件必须在使用过程中进行不断地改进。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

4 2.2 软件生命周期 软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生命周期（Life Cycle）。
软件生命周期的六个基本步骤 制定计划 需求分析 设计 程序编码 测试 运行维护 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

5 制定计划 确定要开发软件系统的总目标； 给出功能、性能、可靠性以及接口等方面的要求； 完成该软件任务的可行性研究；
估计可利用的资源 (硬件，软件，人力等)、成本、效益、开发进度； 制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查； © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

6 需求分析 对用户提出的要求进行分析并给出详细的定义； 编写软件需求说明书或系统功能说明书及初步的系统用户手册； 提交管理机构评审；
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

7 设计 概要设计 — 把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应；
详细设计 — 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础； 编写设计说明书，提交评审。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

8 程序编码 把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”；
写出的程序应当是结构良好、清晰易读的，且与设计相一致的； © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

9 测试 单元测试，查找各模块在功能和结构上存在的问题并加以纠正； 组装测试，将已测试过的模块按一定顺序组装起来；
按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用； © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

10 运行维护 改正性维护：运行中发现了软件中的错误需要修正； 适应性维护：为了适应变化了的软件工作环境，需做适当变更；
完善性维护：为了增强软件的功能需做变更。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

11 2.3 软件过程模型 模型是实际事物、实际系统的抽象。
软件过程模型也称做软件生命周期模型，是从一个特定角度提出的对软件过程的简化描述，是对软件开发实际过程的抽象，它包括构成软件过程的各种活动、软件工件（artifact）以及参与角色等。 软件生命周期模型描述从软件需求定义直至软件经使用后废弃为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务的结构框架，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

12 2.4 传统软件生命周期模型 2.4.1 瀑布模型 2.4.2 V模型和W模型 2.4.3 原型方法 2.4.4 演化模型
2.4.5 增量模型 2.4.6 螺旋模型 2.4.7 喷泉模型 2.4.8 构件组装模型 2.4.9 快速应用开发模型 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

13 2.4.1 瀑布模型 Winston Royce在软件生命周期概念的基础上，于1970年提出了著名的“瀑布模型”（waterfall model）。 维护评价 瀑布模型规定了软件生命周期提出的六个基本工程活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落 。瀑布模型将软件生命周期划分为定义阶段、开发阶段和维护阶段，在定义阶段部署了计划和需求分析活动；在开发阶段部署了设计、编码和测试活动，维护阶段部署了运行/维护活动。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

14 2.4.1 瀑布模型 瀑布模型中的每一个开发活动具有下列特征：
本活动的工作对象来自于上一项活动的输出，这些输出一般是代表本阶段活动结束的里程碑式的文档。 根据本阶段的活动规程执行相应的任务。 产生本阶段活动相关产出——软件工件，作为下一活动的输入。 对本阶段活动执行情况进行评审。 瀑布模型规定了软件生命周期提出的六个基本工程活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落 。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

15 2.4.1 瀑布模型 瀑布模型的优缺点 优点 缺点 降低了软件开发的复杂程度，而且提高了软件开发过程的透明性，提高了软件开发过程的可管理性。
模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。 推迟了软件实现，强调在软件实现前必须进行分析和设计工作。 模型的风险控制能力较弱。 以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。 瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量；而且当管理人员以文档的完成情况来评估项目完成进度时，往往会产生错误的结论。 瀑布模型规定了软件生命周期提出的六个基本工程活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落 。 随着软件项目规模和复杂性的不断扩大，项目需求的不稳定性变成司空见惯的情形，瀑布模型的上述缺点变得越来越严重 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

16 2.4.2 V模型和W模型 1980年代后期Paul Rook提出了V模型
瀑布模型将测试作为软件实现之后的一个独立阶段，使得在分析和设计阶段潜伏下来的错误得到纠正的时机大为推迟，造成较大的返工成本；而且体系结构级别的缺陷也只能在测试阶段才能被发现，使得瀑布模型驾驭风险的能力较低。 瀑布模型将测试阶段独立于编码之后，给人们造成了一种不良的影响，即：相对于编码而言，分析与设计工作更重要，而并没有强调测试的重要性，尽管测试有时会占据项目周期的一半时间。V模型的价值在于纠正了人们这种错误的认识，将测试分等级，并和前面的开发阶段对应起来。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

17 W模型 Evolutif公司在V模型的基础上提出了W模型 W模型由两个V型模型组成，分别代表测试与开发过程
V模型虽然强调了测试阶段的重要性（对测试进行分级，并和开发阶段相对应），但它却继承了瀑布模型的缺点，即将测试作为一个独立的阶段，所以并没有提高模型抵抗风险的能力。为了尽早发现分析与设计的缺陷，必须将测试广义化，即扩充确认（validation）和验证（verification）内容，并将广义的测试作为一个过程贯穿整个软件生命周期。基于这个出发点，Evolutif公司在V模型的基础上提出了W模型 W模型也存在局限性，它并没有改变瀑布模型中需求、设计和编码等活动的串行关系，同时测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段的工作，因此，W模型仍然只适合于需求比较稳定的软件项目。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

18 2.4.3 原型方法 原型方法的产生 瀑布模型、V模型和W模型都将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。 然而完整而准确的需求规格说明是很难得到的，因为： 在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求 随着开发工作的推进，用户可能会产生新的要求 开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境 瀑布模型以阶段划分评审、文档控制等手段来保障软件项目的进度和质量，整个过程是文档驱动的，即上一个阶段没有完成不能进入下一个阶段，因此，当用户需求获取困难，很难一次性准确进行需求分析的时候，软件项目将无法进入到设计阶段，工期也会遥遥无期。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

19 2.4.3 原型方法 原型指模拟某种最终产品的原始模型；
原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。 用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。 原型方法主要用于明确需求，但也可以用于软件开发的其他阶段。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

20 2.4.3 原型方法 原型的三种作用类型： （1）探索型：弄清用户对目标系统的要求，确定所期望的特性；探讨多种实现方案的可行性。主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。 （2）实验型；用于大规模开发和实现之前，考核技术实现方案是否合适、分析和设计的规格说明是否可靠。 （3） 进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统。它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

21 2.4.3 原型方法 由于运用原型的目的和方式不同，在使用原型时可采取以下两种不同的策略：
废弃策略 ：原型主要用于反馈和评价，据此设计出完整、准确、一致、可靠的最终系统。系统构造完成后，原来的原型系统就被废弃不用。探索型和实验型原型属于这种策略。 追加策略 ：原型作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。它对应于进化型原型。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

22 2.4.3 原型方法 原型方法的特点： （1）从认知论的角度看，原型方法遵循了人们认识事物的规律，因而更容易为人们所普遍接受，这主要表现在：
① 人们对任何事物的认知都不可能一蹴而就、尽善尽美； ② 认识和学习的过程都是循序渐进的； ③ 对于事物的描述，往往都是受环境的启发而不断完善的； ④ 人们批评指责一个已有的事物，要比空洞地描述自己的设想容易得多，改进一些事物要比创造一些事物容易得多。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

23 2.4.3 原型方法 ⑵ 原型方法将模拟的手段引入分析的初期阶段，沟通了人们的思想，缩短了用户和开发人员之间的距离。这主要表现在：
① 所有问题的讨论都是围绕某一个确定原型而进行的，彼此之间不存在误解和答非所问的可能性，为准确认识问题创造了条件。 ② 有了原型才能启发人们对原来想不起来或不易准确描述的问题有一个比较确切的描述； ③ 能够及早地暴露出系统实现后存在的一些问题，促使人们在系统实现之前就加以解决。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

24 2.4.3 原型方法 原型提供了用户与开发人员良好的沟通手段，易于被人们接受，使用原型方法有以下好处：
原型方法有助于增进软件人员和用户对系统服务需求的理解 ； 原型方法提供了一种有力的学习手段； 使用原型方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果 ； 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

25 2.4.3 原型方法 原型法的适用范围和局限性： 对于一个大型系统，如果不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。
对于大量运算的、逻辑性较强的程序模块，原型方法很难构造出该模块的原型来供人评价。 对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。 对于一个批处理系统，由于大部分活动是内部处理的，因此应用原型方法会有一定的困难。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

26 2.4.3 原型方法 原型方法存在的问题： 文档容易被忽略。 建立原型的许多工作会被浪费掉 。 项目难以规划和管理。
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

27 有结构系统，如运行支持系统、管理信息系统
2.4.3 原型方法 1984年Boar提出一系列影响原型方法选择的因素 方面 适用原型法 不适用原型法 系统结构 联机事务处理系统、相互关联的应用系统 批处理系统 逻辑结构 有结构系统，如运行支持系统、管理信息系统 基于大量算法和逻辑结构的系统 用户特征 积极参与、积极决策 应用约束 在线运行系统的补充 项目管理 项目负责人愿意使用原型方法 项目负责人不愿意使用原型方法 项目环境 需求复杂易变、性能要求高 需求明确固定 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

28 2.4.3 原型方法 原型方法的应用过程 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

29 2.4.3 原型方法 原型方法可以支持软件生命周期的不同阶段 辅助或代替分析阶段 辅助设计阶段 代替分析与设计阶段 代替分析、设计和实现阶段
代替全部开发阶段 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

30 2.4.3 原型方法 支持原型构造的软件复用技术 所谓复用就是利用一些从早先软件开发过程中收集到的、对建立新系统有用的信息来构建新系统。
从复用的内容角度可以划分其类型为： 数据复用：实现不同数据环境的移植； 模块复用：COM/DCOM、JavaBean/EJB、CORBA 结构复用：领域内通用业务逻辑；实现MVC（Model-View-Control，模型－视图－控制器）体系结构的Struts框架、实现数据库访问逻辑复用的Hibernate框架等 设计复用：MDA（Model Driven Architecture，模型驱动体系结构） 规格说明复用：规格说明可使用或者可参照使用。 数据复用：指在功能不做任何修改，甚至输入和输出数据的格式也无需改动的情况下，软件系统能够从一个数据环境移植到另一个数据环境。 模块复用：可复用的模块是指完成特定功能的封装体，有着良好定义的接口，可以容易地连接到大型应用程序中。基于构件的软件开发（Component Based Software Development，CBSD）就是典型的模块复用，目前具有几种标准的构件模型：Microsoft公司的COM/COM+/DCOM模型、SUN公司的JavaBean/EJB模型、OMG（Object Management Group，对象管理集团）的CORBA（Common Object Request Broker Architecture，通用对象请求代理体系结构）模型等。 结构复用是针对某一特定应用领域的，在该领域内，特定应用的控制逻辑是一致的，不同的只是应用对象的差异， 设计复用：软件设计与实现是两个不同的阶段，如果对于同一个设计可以采用不同的实现方法，那么这样的设计就是可复用的。近年来发展迅速的MDA（Model Driven Architecture，模型驱动体系结构）思想就是试图将软件设计分为两个部分：一部分是对应用领域进行抽象设计的PIM（Platform Independent Model，平台无关模型），另一部分是和具体的实现平台相关的一个或者多个PSM（Platform Specific Model，平台相关模型），PIM可以映射到具体的PSM，而一个PSM可以自动化地生成特定平台的实现代码。这样，PIM设计就是可以复用的，MDA思想通过设计模型复用和代码自动生成技术大大提高了软件开发效率和质量，同时提高了软件的可维护性。 规格说明复用：某一新问题与过去的某一软件在某个抽象层次上属于同一类的情况下，原规格说明仍然可使用或者可参照使用。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

31 2.4.3 原型方法 软件复用的两种实现机制： 合成复用：构件是基础，构件以抽象数据类型为理论基础，将功能实现细节与数据结构封装在构件内部，对外有着精心设计的接口，供外部使用者构造应用时调用。构件本身可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用构件来构造软件系统，有较高的生产率和较短的开发周期。 生成复用：利用可复用的模式（Patterns），通过生成程序产生一个新的应用程序或程序段 生成技术利用可复用的模式（Patterns），通过生成程序产生一个新的应用程序或程序段，产生的程序可以看成是模式的实例。可复用的模式有两种不同的形式：代码模式和规则模式。前者的例子是应用生成器（generator），可复用的代码模式就存储在生成器内部，通过特定的参数替换，自动生成抽象软件模块的具体实体。后者的例子是程序变换系统，它通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，然后利用程序变换系统将此形式化需求规格说明自动变换成某种可执行语言的程序。这种超高级语言抽象能力高、逻辑性强、形式化好，便于维护。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

32 2.4.4 演化模型 使用瀑布模型人们认识到，由于需求很难调研充分，所以很难一次性开发成功。 演化模型提倡两次开发：
第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求； 第二次在此基础上获得较为满意的软件产品。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

33 2.4.4 演化模型 演化模型分类： 演化模型的特点： 演化模型适用范围： 探索式演化模型 抛弃式演化模型
优点：明确用户需求、提高系统质量、降低开发风险； 缺点：难于管理、结构较差、技术不成熟； 演化模型适用范围： 需求不清楚； 小型或中小型系统； 开发周期短 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

34 2.4.5 增量模型 Mills等人于1980年提出 ，指首先对系统最核心或最清晰的需求进行分析、设计、实现、测试并集成到系统中。再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法。 增量模型（Incremental Model）结合了瀑布模型和演化模型的优点。它可以让客户得到一些机会延迟对详细需求的决策，即客户的需求可以逐步提出来；另外每一次“增量”需求的划分与“增量”实现的集成是以不影响系统体系结构为前提的。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

35 2.4.5 增量模型 使用增量模型开发字处理软件时，可以按照以下优先级进行增量开发： 第一个增量实现基本的文件管理、编辑和文档生成功能；
第二个增量实现更加完善的编辑和文档生成功能； 第三个增量实现拼写和文法检查功能； 第四个增量完成高级的页面布局功能。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

36 2.4.5 增量模型 增量模型的优点： 增量模型的缺点： 有利于增加客户对系统的信心； 降低系统失败风险； 提高系统可靠性；
提高了系统的稳定性和可维护性； 增量模型的缺点： 增量粒度难以选择； 确定所有的基本业务服务比较困难 。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

37 2.4.6 螺旋模型 Boehm于1988年提出，主要针对大型软件项目的开发。 大型软件项目的特点：
（1）需求功能复杂，无法一开始就明确；开发周期长，中途需求经常变化； （2）往往存在诸多风险因素，在不同程度上损害软件开发过程和软件产品的质量，所以必须对风险进行管理。 螺旋模型最大特点就是引入了明确的风险管理。 实践证明：项目规模越大，问题越复杂，资源、成本、进度等因素的不确定性就越大，项目承担风险也就越大。 螺旋模型和其他软件过程模型的最大区别就是：螺旋模型中的风险考虑是明确的。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

38 2.4.6 螺旋模型 四个象限 制定计划 风险分析 实施工程 客户评价
螺旋中沿横轴一圈的回路表示软件过程的一个阶段，因此，最里面的回路可能与系统可行性有关，下一个回路与系统需求定义有关，再下一个回路与系统设计有关等等。 如：需求不清晰的风险，需要开发一个原型来逐步明确需求；可靠性要求较高的风险需要开发一个原型来试验技术方案能否达到可靠性要求；对于时间性能要求较高的风险需要开发一个原型来试验算法性能能否达到时间要求等。风险管理措施应该纳入选定的项目实施方案中。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

39 2.4.6 螺旋模型 制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。 风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理措施规避这些风险。 实施工程：针对每一个开发阶段的任务要求执行本开发阶段的活动。 客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

40 2.4.7 喷泉模型 喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。 各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。 优点： 提高开发效率 缩短开发周期 缺点：难于管理 迭代性、无间隙性 喷泉模型是以对象驱动的模型，主要用于描述面向对象的软件开发过程。 开发人员可以针对不同的对象集合并行进行开发，即存在多个子开发流程，这些子开发流程在对象集成时同步。其优点是可以提高软件项目开发效率，节省开发时间。但是，由于各个开发阶段的重叠性，开发人员的管理和阶段生成的工件管理存在困难，因此，在应用喷泉模型时需要结合其他模型，比如结合增量模型在增量管理方面的优点，合理地划分并发任务，控制开发人员的调度；结合瀑布模型在文档控制方面的优点，严格控制每一个迭代周期应该产生的文档，并进行评审，对于在本周期没有完成的任务，不应该象瀑布模型那样不允许进入下一阶段，而是纳入下一次迭代周期。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

41 2.4.8 构件组装模型 构件组装模型利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的 。 构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

42 2.4.8 构件组装模型 优点： 缺点： 充分利用软件复用，提高了软件开发的效率。
允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。 缺点： 缺乏通用的构件组装结构标准，风险较大； 构件可重用性和系统高效性之间不易协调； 由于过分依赖于构件，构件质量影响着最终产品的质量。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

43 2.4.9 快速应用开发模型 快速应用开发（Rapid Application Development，RAD）是一个增量型的软件开发过程模型，强调极短的开发周期 。 RAD模型使用构件组装方法进行快速开发。如果需求理解得很好且约束了项目范围，RAD过程使得一个开发队伍能够在很短时间内（如60到90天）创建出系统。 RAD采用第四代语言技术快速生成应用 ⑴ 业务建模：通过捕获业务过程中信息流的流动及处理情况描述业务处理系统应该完成的功能，主要回答下列问题：什么信息驱动业务流程？生成什么信息？谁生成该信息？该信息流往何处？谁处理它？ ⑵ 数据建模：对业务建模阶段中部分定义的信息流进行细化，形成一组支持该业务处理功能所需的数据对象。标识出每个数据对象的特征，并定义这些数据对象之间的关系。 ⑶ 过程建模：数据建模阶段定义的数据对象被变换以实现完成一个业务功能所需的信息流，过程建模则对业务建模中的业务处理功能进行详细定义，这些业务处理功能的操作对象就是数据建模阶段形成的数据对象。 ⑷ 应用生成：RAD利用第四代语言技术（4GL），复用已有的程序构件或是创建新的可复用构件，在自动化工具辅助下，完成软件的构件组装或者软件的自动生成，从而快速构造软件系统。 ⑸ 测试及迭代：RAD模型强调复用，许多程序构件已经是测试过的，这减少了软件系统测试的时间，但新构件必须测试，所有构件间的接口也必须完全测试到。当一轮需求完成快速开发后，可以迭代进入下一轮需求的开发。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

44 2.4.9 快速应用开发模型 RAD模型的缺点： 并非所有应用都适合采用RAD，如果一个应用不能被模块化，那么构造应用的构件就无法快速获取
© 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

45 2.5 新型软件生命周期模型 2.5.1 RUP 2.5.2 敏捷模型 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

46 2.5.1 RUP RUP（Rational Unified Process）统一过程模型是由Rational公司（现被IBM公司收购）开发的一种软件工程过程框架，是一个面向对象的基于web的程序开发方法论 。 RUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中 。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

47 2.5.1 RUP RUP的基本结构 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

48 2.5.1 RUP RUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。 每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

49 2.5.1 RUP RUP的9个核心工作流 6个核心过程工作流 商业建模（Business Modeling）
需求（Requirements） 分析和设计（Analysis & Design） 实现（Implementation） 测试（Test） 部署（Deployment） © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

50 2.5.1 RUP 3个核心支持工作流： 配置和变更管理（Configuration & Change Management）
项目管理（Project Management） 环境（Environment） © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

51 2.5.1 RUP 初始阶段 目标是为系统建立商业案例（business case）并确定项目的边界。
商业案例包括项目的验收规范、风险评估、所需资源估计、阶段计划等。 要确定项目边界，需识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。 阶段结束里程碑：生命周期目标（Lifecycle Objective）里程碑，包括一些重要的文档，如：项目构想（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始商业案例等。需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。 Business case ：业务用例 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

52 2.5.1 RUP 细化阶段 目标是分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。
里程碑：生命周期体系结构（Lifecycle Architecture）里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。 为了达到该目的，必须在理解整个系统的功能需求、性能需求和特性（feature）需求的基础上，详细分析系统的业务和技术风险，对系统体系结构作出设计决策；然后针对体系结构中业务需求重要等级和技术风险等级编制项目总体计划和具体的迭代计划，并对高风险的部分进行详细分析设计，完成其增量原型开发；同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

53 2.5.1 RUP 构造阶段 将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。 里程碑：初始运行能力（Initial Operational Capability）里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运行。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

54 2.5.1 RUP 移交阶段 移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。 里程碑：产品发布(Product Release)里程碑。此时，要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

55 2.5.1 RUP RUP的迭代增量开发思想 RUP是融合了喷泉模型和增量模型的一种综合生命周期模型。 每一次迭代就是为 了完成一定阶段性
小目标而从事的一 系列开发活动 。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

56 2.5.1 RUP RUP通过迭代增量建模思想提高了风险控制能力，这体现在：
⑴ 迭代计划安排是风险驱动的，高风险因素集中在前两个阶段解决，特别是体系结构级的风险在细化阶段就得到了解决，及早降低了系统风险； ⑵ 每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的； © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

57 2.5.1 RUP ⑶ 每一个阶段结束时还有严格的质量评审，保证里程碑文档的质量；
⑷ 由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，所以，可以根据市场竞争的情况适时推出中间版本，降低市场风险。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

58 2.5.1 RUP RUP的最佳实践： ⑴ 短时间分区式的迭代：2～6周，不鼓励时间推迟； ⑵ 适应性开发：小步骤、快速反馈和调整；
⑶ 在早期迭代中解决高技术风险和高业务价值的问题； ⑷ 不断地让用户参与迭代结果的评估，并及时获取反馈信息，以逐步阐明问题并引导项目进展； ⑸ 在早期迭代中建立内聚的核心架构。 该实践是和早期处理高技术风险和高业务价值问题有关的，因为核心架构一般和高风险因素紧密相关。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

59 2.5.1 RUP ⑹ 不断地验证质量；尽早、经常和实际地测试；
⑺ 使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。 ⑻ 可视化软件建模：使用UML（Unified Modeling Language，统一建模语言）进行软件建模。 ⑼ 仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪。拙劣的需求管理是项目陷入麻烦的一个常见原因。 ⑽ 实行变更请求和配置管理。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

60 2.5.1 RUP RUP是一个通用的过程模板，包含了很多开发指南、工件、开发过程所涉及到的角色说明等，因此，具体开发机构在应用RUP开发项目时要做裁剪。RUP裁剪可以分为以下几步： ⑴ 确定本项目需要的工作流。 ⑵ 确定每个工作流需要的工件。 ⑶ 确定4个阶段之间的演进计划。以风险控制为原则，决定每个阶段实施的工作流，每个工作流的执行程度，生成的工件及其完成程度等。 ⑷ 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。 ⑸ 规划工作流内部结构。用活动图（activity diagram）规划工作流中涉及的角色、角色负责的活动及产出的工件。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

61 2.5.2 敏捷模型 敏捷建模（Agile Modeling，AM）是由Scott W. Ambler从许多的软件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它只是一种态度，不是一个说明性过程 。 AM是对已有生命周期模型的补充，它本身不是一个完整的方法论，在应用传统的生命周期模型时可以借鉴AM的过程指导思想 。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

62 沟通、简单、反馈、勇气、谦逊 2.5.2 敏捷模型 敏捷建模的价值观： 个人和交互胜过过程和工具； 实用的软件胜过面面俱到的文档；
客户合作胜过合同谈判； 响应变化胜过遵循计划。 沟通、简单、反馈、勇气、谦逊 敏捷软件开发的这个价值观强调了敏捷软件开 发中应该集中精力的方面但不完全排除另一方面。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

63 2.5.2 敏捷模型 敏捷建模原则： (1)优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意；
(2)即使到了开发的后期，也欢迎改变需求； (3)敏捷过程利用变化来为客户创造竞争优势； (4)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好； (5)围绕被激励起来的个体来构建项目； (6)给他们提供所需的环境和支持，并且信任他们能够完成工作； © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

64 2.5.2 敏捷模型 (7)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；工作的软件是首要的进度度量标准；敏捷过程提倡可持续的开发速度； (8)责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度； (9)不断地关注优秀的技能和好的设计会增强敏捷能力； (10)简单是最根本的； (11)最好的构架、需求和设计出于自组织团队； (12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，对自己的行为进行调整。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

65 2.5.2 敏捷模型 敏捷建模核心实践 项目干系人的积极参与 正确使用工件 集体所有制 测试性思维 并行创建模型 创建简单的内容 简单地建模
公开展示模型 切换到另外的工件 小增量建模 和他人一起建模 用代码验证 使用最简单的工具 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

66 2.5.2 敏捷模型 敏捷模型补充实践： 使用建模标准 逐渐应用模式（pattern） 丢弃临时模型 合同模型要正式 为外部交流建模
为帮助理解建模 重用现有的资源 不到万不得已不更新模型 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

67 极限编程 极限编程(eXtreme Programming，XP)是敏捷模型的一种实现过程，由Kent Beck在1996年提出 。
2001年，17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。 “Extreme”（极限） 是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、 做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其 开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。  © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

68 极限编程 极限编程的12个实践 ： （1）小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 （2）规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

69 极限编程 （3）现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。
（4）隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。 （5）简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

70 极限编程 （6）重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。 （7）测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。 （8）持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

71 极限编程 （9）结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。 （10） 代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。 （11）编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。 （12）每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心

72 软件文档 © 2008 BUPT TSEG 北京邮电大学 通信软件工程中心