软件生命周期模型课件.ppt

1本章内容本章内容u2.1 软件工程过程u2.2 软件生命周期u2.3 软件过程模型u2.4 传统软件生命周期模型u2.5 新型软件生命周期模型© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心22.1 软件工程过程软件工程过程u软件工程过程是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动 Ø软件规格说明（specification）：规定软件的功能及其使用限制；Ø软件开发（development）：产生满足规格说明的软件；Ø软件确认（validation）：通过有效性验证以保证软件能够满足客户的要求；Ø软件演进（evolution）：为了满足客户的变更要求，软件必须在使用过程中进行不断地改进© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心32.2 软件生命周期软件生命周期u软件有一个孕育、诞生、成长、成熟、衰亡的生存过程这个过程即为计算机软件的生命周期（Life Cycle）u软件生命周期的六个基本步骤Ø制定计划Ø需求分析Ø设计Ø程序编码Ø测试Ø运行维护© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4制定计划制定计划u确定要开发软件系统的总目标；u给出功能、性能、可靠性以及接口等方面的要求；u完成该软件任务的可行性研究；u估计可利用的资源 (硬件，软件，人力等)、成本、效益、开发进度；u制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查；© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心5需求分析需求分析u对用户提出的要求进行分析并给出详细的定义；u编写软件需求说明书或系统功能说明书及初步的系统用户手册；u提交管理机构评审；© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心6设计设计u概要设计 — 把各项需求转换成软件的体系结构。

结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应；u详细设计 — 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础；u编写设计说明书，提交评审© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心7程序编码程序编码u把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”；u写出的程序应当是结构良好、清晰易读的，且与设计相一致的；© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心8测试测试u单元测试，查找各模块在功能和结构上存在的问题并加以纠正；u组装测试，将已测试过的模块按一定顺序组装起来；u按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用；© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心9运行维护运行维护u改正性维护：运行中发现了软件中的错误需要修正；u适应性维护：为了适应变化了的软件工作环境，需做适当变更；u完善性维护：为了增强软件的功能需做变更。

© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心102.3 软件过程模型软件过程模型u模型是实际事物、实际系统的抽象 u软件过程模型也称做软件生命周期模型，是从一个特定角度提出的对软件过程的简化描述，是对软件开发实际过程的抽象，它包括构成软件过程的各种活动、软件工件（artifact）以及参与角色等u软件生命周期模型描述从软件需求定义直至软件经使用后废弃为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务的结构框架，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等  © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心112.4 传统软件生命周期模型传统软件生命周期模型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 快速应用开发模型© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心122.4.1 瀑布模型瀑布模型uWinston Royce在软件生命周期概念的基础上，于1970年提出了著名的“瀑布模型”（waterfall model）。

 维护评价© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心132.4.1 瀑布模型瀑布模型u瀑布模型中的每一个开发活动具有下列特征： Ø本活动的工作对象来自于上一项活动的输出，这些输出一般是代表本阶段活动结束的里程碑式的文档 Ø根据本阶段的活动规程执行相应的任务Ø产生本阶段活动相关产出——软件工件，作为下一活动的输入Ø对本阶段活动执行情况进行评审 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心142.4.1 瀑布模型瀑布模型u瀑布模型的优缺点© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心152.4.2 V模型和模型和W模型模型u1980年代后期Paul Rook提出了V模型 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心16W模型模型uEvolutif公司在V模型的基础上提出了W模型 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心172.4.3 原型方法原型方法u原型方法的产生u瀑布模型、V模型和W模型都将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。

u然而完整而准确的需求规格说明是很难得到的，因为：Ø在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求 Ø随着开发工作的推进，用户可能会产生新的要求Ø开发者有可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心182.4.3 原型方法原型方法u原型指模拟某种最终产品的原始模型；u原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求u用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确u原型方法主要用于明确需求，但也可以用于软件开发的其他阶段  © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心192.4.3 原型方法原型方法u原型的三种作用类型：Ø（1）探索型：弄清用户对目标系统的要求，确定所期望的特性；探讨多种实现方案的可行性主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。

Ø（2）实验型；用于大规模开发和实现之前，考核技术实现方案是否合适、分析和设计的规格说明是否可靠Ø（3） 进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心202.4.3 原型方法原型方法u由于运用原型的目的和方式不同，在使用原型时可采取以下两种不同的策略：Ø废弃策略 ：原型主要用于反馈和评价，据此设计出完整、准确、一致、可靠的最终系统系统构造完成后，原来的原型系统就被废弃不用探索型和实验型原型属于这种策略 Ø追加策略 ：原型作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统它对应于进化型原型 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心212.4.3 原型方法原型方法u原型方法的特点：u（1）从认知论的角度看，原型方法遵循了人们认识事物的规律，因而更容易为人们所普遍接受，这主要表现在：Ø① 人们对任何事物的认知都不可能一蹴而就、尽善尽美；Ø② 认识和学习的过程都是循序渐进的；Ø③ 对于事物的描述，往往都是受环境的启发而不断完善的；Ø④ 人们批评指责一个已有的事物，要比空洞地描述自己的设想容易得多，改进一些事物要比创造一些事物容易得多。

© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心222.4.3 原型方法原型方法u⑵ 原型方法将模拟的手段引入分析的初期阶段，沟通了人们的思想，缩短了用户和开发人员之间的距离这主要表现在：Ø① 所有问题的讨论都是围绕某一个确定原型而进行的，彼此之间不存在误解和答非所问的可能性，为准确认识问题创造了条件Ø② 有了原型才能启发人们对原来想不起来或不易准确描述的问题有一个比较确切的描述；Ø③ 能够及早地暴露出系统实现后存在的一些问题，促使人们在系统实现之前就加以解决© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心232.4.3 原型方法原型方法u原型提供了用户与开发人员良好的沟通手段，易于被人们接受，使用原型方法有以下好处：Ø原型方法有助于增进软件人员和用户对系统服务需求的理解 ；Ø原型方法提供了一种有力的学习手段； Ø使用原型方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果 ；Ø软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。

 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心242.4.3 原型方法原型方法u原型法的适用范围和局限性：Ø对于一个大型系统，如果不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的Ø对于大量运算的、逻辑性较强的程序模块，原型方法很难构造出该模块的原型来供人评价Ø对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难Ø对于一个批处理系统，由于大部分活动是内部处理的，因此应用原型方法会有一定的困难  © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心252.4.3 原型方法原型方法u原型方法存在的问题：Ø文档容易被忽略 Ø建立原型的许多工作会被浪费掉 Ø项目难以规划和管理 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心262.4.3 原型方法原型方法u1984年Boar提出一系列影响原型方法选择的因素 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心272.4.3 原型方法原型方法u原型方法的应用过程© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心282.4.3 原型方法原型方法u原型方法可以支持软件生命周期的不同阶段 u辅助或代替分析阶段 u辅助设计阶段 u代替分析与设计阶段 u代替分析、设计和实现阶段 u代替全部开发阶段 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心292.4.3 原型方法原型方法u支持原型构造的软件复用技术u所谓复用就是利用一些从早先软件开发过程中收集到的、对建立新系统有用的信息来构建新系统。

 u从复用的内容角度可以划分其类型为： Ø数据复用：实现不同数据环境的移植；Ø模块复用：COM/DCOM、JavaBean/EJB、CORBAØ结构复用：领域内通用业务逻辑；实现MVC（Model-View-Control，模型－视图－控制器）体系结构的Struts框架、实现数据库访问逻辑复用的Hibernate框架等 Ø设计复用：MDA（Model Driven Architecture，模型驱动体系结构） Ø规格说明复用：规格说明可使用或者可参照使用  © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心302.4.3 原型方法原型方法u软件复用的两种实现机制：Ø合成复用：构件是基础，构件以抽象数据类型为理论基础，将功能实现细节与数据结构封装在构件内部，对外有着精心设计的接口，供外部使用者构造应用时调用构件本身可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用构件来构造软件系统，有较高的生产率和较短的开发周期 Ø生成复用：利用可复用的模式（Patterns），通过生成程序产生一个新的应用程序或程序段 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心312.4.4 演化模型演化模型u使用瀑布模型人们认识到，由于需求很难调研充分，所以很难一次性开发成功。

u演化模型提倡两次开发：Ø第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求；Ø第二次在此基础上获得较为满意的软件产品 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心322.4.4 演化模型演化模型u演化模型分类：Ø探索式演化模型Ø抛弃式演化模型u演化模型的特点：Ø优点：明确用户需求、提高系统质量、降低开发风险；Ø缺点：难于管理、结构较差、技术不成熟；u演化模型适用范围：Ø需求不清楚；Ø小型或中小型系统；Ø开发周期短© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心332.4.5 增量模型增量模型uMills等人于1980年提出 ，指首先对系统最核心或最清晰的需求进行分析、设计、实现、测试并集成到系统中再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心342.4.5 增量模型增量模型u使用增量模型开发字处理软件时，可以按照以下优先级进行增量开发：Ø第一个增量实现基本的文件管理、编辑和文档生成功能；Ø第二个增量实现更加完善的编辑和文档生成功能；Ø第三个增量实现拼写和文法检查功能；Ø第四个增量完成高级的页面布局功能。

 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心352.4.5 增量模型增量模型u增量模型的优点：Ø有利于增加客户对系统的信心；Ø降低系统失败风险；Ø提高系统可靠性；Ø提高了系统的稳定性和可维护性；u增量模型的缺点：Ø增量粒度难以选择；Ø确定所有的基本业务服务比较困难 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心362.4.6 螺旋模型螺旋模型uBoehm于1988年提出，主要针对大型软件项目的开发u大型软件项目的特点：Ø（1）需求功能复杂，无法一开始就明确；开发周期长，中途需求经常变化；Ø（2）往往存在诸多风险因素，在不同程度上损害软件开发过程和软件产品的质量，所以必须对风险进行管理u螺旋模型最大特点就是引入了明确的风险管理© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心372.4.6 螺旋模型螺旋模型u四个象限Ø制定计划 Ø风险分析Ø实施工程Ø客户评价© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心382.4.6 螺旋模型螺旋模型u制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。

u 风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理措施规避这些风险u实施工程：针对每一个开发阶段的任务要求执行本开发阶段的活动u客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心392.4.7 喷泉模型喷泉模型u喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部u各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求u优点：Ø提高开发效率Ø缩短开发周期u缺点：难于管理 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心402.4.8 构件组装模型构件组装模型u构件组装模型利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组装高效率、高质量地构造软件系统。

构件组装模型本质上是演化的，开发过程是迭代的 u构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心412.4.8 构件组装模型构件组装模型u优点：Ø充分利用软件复用，提高了软件开发的效率 Ø允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品 u缺点：Ø缺乏通用的构件组装结构标准，风险较大；Ø构件可重用性和系统高效性之间不易协调；Ø由于过分依赖于构件，构件质量影响着最终产品的质量 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心422.4.9 快速应用开发模型快速应用开发模型u快速应用开发（Rapid Application Development，RAD）是一个增量型的软件开发过程模型，强调极短的开发周期 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心432.4.9 快速应用开发模型快速应用开发模型uRAD模型的缺点：Ø并非所有应用都适合采用RAD，如果一个应用不能被模块化，那么构造应用的构件就无法快速获取 Ø由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败 ØRAD适合于管理信息系统的开发，对于其他类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心442.5 新型软件生命周期模型新型软件生命周期模型u2.5.1 RUPu2.5.2 敏捷模型© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心452.5.1 RUPuRUP（Rational Unified Process）统一过程模型是由Rational公司（现被IBM公司收购）开发的一种软件工程过程框架，是一个面向对象的基于web的程序开发方法论 。

uRUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心462.5.1 RUPuRUP的基本结构© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心472.5.1 RUPuRUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）u每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足如果评估结果令人满意的话，可以允许项目进入下一个阶段© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心482.5.1 RUPuRUP的9个核心工作流u6个核心过程工作流Ø商业建模（Business Modeling） Ø需求（Requirements） Ø分析和设计（Analysis & Design） Ø实现（Implementation） Ø测试（Test） Ø部署（Deployment） © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心492.5.1 RUPu3个核心支持工作流：Ø配置和变更管理（Configuration & Change Management） Ø项目管理（Project Management） Ø环境（Environment） © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心502.5.1 RUPu初始阶段 Ø目标是为系统建立商业案例（business case）并确定项目的边界。

Ø商业案例包括项目的验收规范、风险评估、所需资源估计、阶段计划等Ø要确定项目边界，需识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例Ø阶段结束里程碑：生命周期目标（Lifecycle Objective）里程碑，包括一些重要的文档，如：项目构想（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始商业案例等需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心512.5.1 RUPu细化阶段 Ø目标是分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发Ø里程碑：生命周期体系结构（Lifecycle Architecture）里程碑包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心522.5.1 RUPu构造阶段Ø将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量Ø里程碑：初始运行能力（Initial Operational Capability）里程碑包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署此刻，要确定软件、环境、用户是否可以开始系统的运行© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心532.5.1 RUPu移交阶段 Ø移交阶段的重点是确保软件对最终用户是可用的交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整Ø里程碑：产品发布(Product Release)里程碑此时，要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。

© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心542.5.1 RUPuRUP的迭代增量开发思想uRUP是融合了喷泉模型和增量模型的一种综合生命周期模型 每一次迭代就是为了完成一定阶段性小目标而从事的一系列开发活动 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心552.5.1 RUPuRUP通过迭代增量建模思想提高了风险控制能力，这体现在：Ø⑴ 迭代计划安排是风险驱动的，高风险因素集中在前两个阶段解决，特别是体系结构级的风险在细化阶段就得到了解决，及早降低了系统风险；Ø⑵ 每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的；© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心562.5.1 RUPØ⑶ 每一个阶段结束时还有严格的质量评审，保证里程碑文档的质量；Ø⑷ 由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，所以，可以根据市场竞争的情况适时推出中间版本，降低市场风险。

© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心572.5.1 RUPuRUP的最佳实践：Ø⑴ 短时间分区式的迭代：2～6周，不鼓励时间推迟；Ø⑵ 适应性开发：小步骤、快速反馈和调整；Ø⑶ 在早期迭代中解决高技术风险和高业务价值的问题；Ø⑷ 不断地让用户参与迭代结果的评估，并及时获取反馈信息，以逐步阐明问题并引导项目进展；Ø⑸ 在早期迭代中建立内聚的核心架构© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心582.5.1 RUPØ⑹ 不断地验证质量；尽早、经常和实际地测试；Ø⑺ 使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量Ø⑻ 可视化软件建模：使用UML（Unified Modeling Language，统一建模语言）进行软件建模Ø⑼ 仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪拙劣的需求管理是项目陷入麻烦的一个常见原因Ø⑽ 实行变更请求和配置管理© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心592.5.1 RUPuRUP是一个通用的过程模板，包含了很多开发指南、工件、开发过程所涉及到的角色说明等，因此，具体开发机构在应用RUP开发项目时要做裁剪。

RUP裁剪可以分为以下几步：Ø⑴ 确定本项目需要的工作流Ø⑵ 确定每个工作流需要的工件Ø⑶ 确定4个阶段之间的演进计划以风险控制为原则，决定每个阶段实施的工作流，每个工作流的执行程度，生成的工件及其完成程度等Ø⑷ 确定每个阶段内的迭代计划规划RUP的4个阶段中每次迭代开发的内容Ø⑸ 规划工作流内部结构用活动图（activity diagram）规划工作流中涉及的角色、角色负责的活动及产出的工件© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心602.5.2 敏捷模型敏捷模型u敏捷建模（Agile Modeling，AM）是由Scott W. Ambler从许多的软件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它只是一种态度，不是一个说明性过程 uAM是对已有生命周期模型的补充，它本身不是一个完整的方法论，在应用传统的生命周期模型时可以借鉴AM的过程指导思想 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心612.5.2 敏捷模型敏捷模型u敏捷建模的价值观：Ø个人和交互胜过过程和工具；Ø 实用的软件胜过面面俱到的文档；Ø客户合作胜过合同谈判；Ø响应变化胜过遵循计划。

u沟通、简单、反馈、勇气、谦逊© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心622.5.2 敏捷模型敏捷模型u敏捷建模原则：Ø(1)优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意；Ø(2)即使到了开发的后期，也欢迎改变需求；Ø(3)敏捷过程利用变化来为客户创造竞争优势；Ø(4)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好；Ø(5)围绕被激励起来的个体来构建项目；Ø(6)给他们提供所需的环境和支持，并且信任他们能够完成工作；© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心632.5.2 敏捷模型敏捷模型Ø(7)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；工作的软件是首要的进度度量标准；敏捷过程提倡可持续的开发速度；Ø(8)责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度；Ø(9)优秀的技能和好的设计会增强敏捷能力；Ø(10)简单是最根本的；Ø(11)最好的构架、需求和设计出于自组织团队；Ø(12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，对自己的行为进行调整。

© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心642.5.2 敏捷模型敏捷模型u敏捷建模核心实践Ø项目干系人的积极参与 Ø正确使用工件 Ø集体所有制 Ø测试性思维 Ø并行创建模型 Ø创建简单的内容 Ø简单地建模 Ø公开展示模型 Ø切换到另外的工件 Ø小增量建模 Ø和他人一起建模 Ø用代码验证 Ø使用最简单的工具 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心652.5.2 敏捷模型敏捷模型u敏捷模型补充实践：Ø使用建模标准 Ø逐渐应用模式（pattern） Ø丢弃临时模型 Ø合同模型要正式 Ø为外部交流建模 Ø为帮助理解建模 Ø重用现有的资源 Ø不到万不得已不更新模型 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心66极限编程极限编程u极限编程(eXtreme Programming，XP)是敏捷模型的一种实现过程，由Kent Beck在2019年提出 © 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心67极限编程极限编程u极限编程的12个实践 ：Ø（1）小版本。

为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划Ø（2）规划游戏就是客户需求，以客户故事的形式，由客户负责编写极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现当然游戏规则可进行多次，每次迭代完毕后再行修改客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的© 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心68极限编程极限编程Ø（3）现场客户极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈Ø（4）隐喻隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异Ø（5）简单设计极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。

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

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