软件过程框架与软件过程模型.ppt

《软件过程框架与软件过程模型.ppt》由会员分享，可在线阅读，更多相关《软件过程框架与软件过程模型.ppt（88页珍藏版）》请在三一文库上搜索。

1、第三讲 软件过程框架与软件过程模型,2,软件过程框架,什么是过程？ 针对一个给定目标的一系列操作步骤。 例如 - 目标：去火车站 - 操作步骤：去南门/东门公共汽车站，乘50/17路汽车， 每个过程都有明确的目的以及具体的操作步骤，操作步骤说明了有哪些操作以及按照什么样的方式来执行操作。,3,什么是软件开发过程？ 按照项目的进度、成本和质量限制，开发和维护满足用户需求的软件所必需的一组有序的软件开发活动集合。 软件开发活动的例子 - 需求分析 - 体系结构设计 开发活动的顺序例子 - 先做需求分析，然后再做体系结构设计 ,4,在按任务性质，软件开发活动可分为二种形式 技术活动 - 对软件项目实

2、施开发，产生软件产品 - 例如，需求分析，概要设计，编码，单元测试等等 管理活动 - 对软件项目中的人、产品和过程等实施管理的活动 - 例如，制订软件项目计划，软件配置等等,5,如何定义软件开发活动? - 名称 - 任务 - 输入: 开始所必需满足的条件 - 输出: 完成时所必须满足的条件以及结果 - 实施: 做什么，怎么做(详细的步骤)，或者如何从输入产生输出,6,软件活动例子: - 名字： 单元测试 - 任务 对软件基本单元模块进行测试，判断是否有错 - 输入 有一个已完成、被文档化和批准的软件单元测试计划 供测试的软件单元模块代码 - 实施 遵循单元测试计划，运行所有的测试用例 撰写单元

3、测试报告 - 输出 单元测试报告,7,为什么需要软件过程？ - 明确了软件开发的过程和步骤，促进工程化软件开发 - 便于制定软件项目计划 - 为软件开发提供了可视性，便于对软件开发过程进行管理和控制 - 便于细化和安排任务，使得每个人员明确各自的工作,8,软件开发过程模型,软件开发过程模型 - 软件开发过程模型是软件开发全过程、软件开发活动以及它们之间关系的结构框架 - 指导软件开发以及软件开发过程的定义 常用的软件开发过程模型 - 瀑布模型 - 原型模型 - 增量模型 - 迭代模型 - 螺旋模型,9,软件过程分类 - 基本过程类 是构成软件生存周期主要部分的那些过程, 包括：定义、构建、维护

4、等过程. - 支持过程类 可穿插到基本过程中提供支持的一系列过程, 包括：文档开发、 配置管理、 质量保证、验证、确认、联合评审、审计、问题解决等程. - 组织过程类 一个组织用来建立、实施一种基础结构, 并不断改进该基础结构的过程, 包括：管理、计划、改进、培训等过程.,10,公共软件过程框架,11,一个公共过程框架，是通过定义若干框架活动来建立的，如果不考虑其规模和复杂性，这些活动适用于所有软件项目。 任务集合每一个集合都由软件工程工作任务、项目里程碑、软件工程产品和交付物以及质量保证点组成使得框架活动适应于不同软件项目的特征和项目组的需求。 支持性活动如软件质量保证，软件配置管理和测度，

5、它们贯穿于整个过程模型之中。支持性活动独立于任何一个框架活动，且贯穿于整个过程。,12,管理性活动,- 软件项目跟踪和控制 允许项目组根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。 - 风险管理 评估可能对项目成果或者产品质量产生影响的风险。 - 软件质量保证 确定和执行用以保证软件质量的活动。 正式技术评审: 评估软件工程产品，尽量在错误传播到下一个动作或活动之前，发现并清除错误。 V&V（Verification and Validation）：验证与确认。,13,- 测量 定义和收集过程、项目和产品的度量，以帮助团队在发布软件的时候满足客户要求。同时，测量还可与其它框

6、架协同使用。 - 软件配置管理 管理整个软件过程中变更所带来的影响。 - 可复用管理 定义产品复用的标准（包括软件构件），并且建立构件复用机制。 - 工作产品（Work Product）的准备和生产 包括了创建产品所必须的活动如建模、文档、日志、表格和列表等。,14,主要的开发和支持过程 1、软件需求分析 任务：收集、分析、理解、确定用户的要求；然后把用户的要求精确、完整地描述表达出来。 目的：要回答“要解决什么问题？”， 既系统“做什么？”。 输入：系统需求文档/问题陈述、本过程相关工作计划 步骤：可行性研究、需求分析、制定相关开发计划 输出：可行性报告、需求规范、下一过程开发计划 需求说明

7、书是让用户理解:“什么是他们真正需要的”； 让开发者理解“什么是他们真正的开发目标”。,15,Review Item Discrepancy,16,任务：给出实现系统的实施蓝图。 目的：要回答“如何解决该问题？”， 既系统“怎样做？”。 输入：软件需求规范、本过程相关计划 步骤： 概要设计：解决系统的子系统/模块划分、子系统/模块的层次结构及数据库设计； 详细设计：解决每个模块/类内部算法和数据结构； 制定下一过程相关计划。 输出：体系结构设计说明书、详细设计说明书、下一过程相关计划,2、软件设计,17,18,19,3、软件构造,任务：根据设计说明书中每个模块的控制流程编写出相应的源程序。 目

8、的：写出高质量的代码和相应的文档。 - 构造要注意使系统更易于使用和系统的可重用性。 - 选择合适的开发工具及系统软件、数据库软件、中间件等。制定编程规范。 输入：软件设计文档、本过程相关计划 步骤：编程、单元测试、制定下一阶段相关计划、编制用户文档 输出：源程序和相关文档、下一过程相关计划,20,4、软件测试,任务：检查、发现程序中的错误，提高系统可靠性。 目的：保证系统的正确性、可靠性和可用性。 回答：“该系统是否能实现规定的操作？”。 输入：已经完成的代码、本过程相关的计划 步骤：集成测试、系统测试、确认测试 输出：测试报告和软件修改报告等。,21,5、软件维护,任务：改正软件系统在使用

9、过程中发现的隐含错误，扩充在使用过程中新的功能要求。 目的：维护软件系统的正常运行。 回答：系统是否满足用户的应用要求。 输入：问题报告 步骤：问题报告审批、问题修改、审核 输出：软件修改报告。,22,6.软件配置管理,软件修改后会发生什么呢？ - 同步更新当两个或两个以上的角色各自工作在同一产物上时，最后一个修改者会破坏前者的工作。 - 通知不达当被若干开发者共享的产品中的问题被解决时，修改未被通知到一些开发者。 - 多个版本软件修改与文档不一致。 - 新版本公布的管理和监控。 配置和变更管理提供了准则管理演化系统中的多个变体，跟踪给定软件创建过程中的版本。,23,SRD,24,7.软件工程

10、管理,项目管理是过程管理的主要体现： (1)建立与客户的沟通渠道； (2)制订计划，定义资源、时限、落实到开发组； (3)风险分析，评估所采用的技术和管理带来的风险； (4)技术过程监控； (5)客户评审，获得客户的反馈。,25,26,27,8.软件质量保证,软件质量保证SQA活动，贯穿于软件过程始终。开发单位成立SQA小组负责全面质量管理。在开发项目计划时就要做出SQA计划。其工作： - 各种测试：测试软件是否满足规格说明要求。 - 各种评审/审计：为多种人员参与的讨论会，以规格说明或各种标准、规范为准评价各项软件工作。 - 报告和记录：所有测试、评审、审计都要详细记录并写出报告，报告和记录

11、均要整理、归档。 以上活动均应在软件质量保证计划中列出。,28,29,传统软件生命周期模型,1. 瀑布模型 Winston Royce在软件生命周期概念的基础上，于1970年提出了著名的“瀑布模型”（waterfall model）。,30,瀑布模型中的每一个开发活动具有下列特征： - 本活动的工作对象来自于上一项活动的输出，这些输出一般是代表本阶段活动结束的里程碑式的文档。 - 根据本阶段的活动规程执行相应的任务。 - 产生本阶段活动相关产出软件产品，作为下一活动的输入。 - 对本阶段活动执行情况进行评审。,31,瀑布模型的优缺点,32,2. V模型和W模型,1980年代后期Paul Roo

12、k提出了V模型,33,Evolutif公司在V模型的基础上提出了W模型,34,3. 原型方法,原型方法的产生 - 瀑布模型、V模型和W模型都将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。 - 然而完整而准确的需求规格说明是很难得到的，因为： 在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求 随着开发工作的推进，用户可能会产生新的要求 开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境,35,原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。 用户通

13、过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。 原型方法主要用于明确需求，但也可以用于软件开发的其它阶段。,36,原型的三种作用类型： （1）探索型：弄清用户对目标系统的要求，确定所期望的特性；探讨多种实现方案的可行性。主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。 （2）实验型；用于大规模开发和实现之前，考核技术实现方案是否合适。 （3） 进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统。它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目。,37,原型方法的特点： （1）从认

14、知论的角度看，原型方法遵循了人们认识事物的规律，因而更容易为人们所普遍接受，这主要表现在： 人们对任何事物的认知都不可能一蹴而就、尽善尽美； 认识和学习的过程都是循序渐进的； 对于事物的描述，往往都是受环境的启发而不断完善的； 人们批评指责一个已有的事物，要比空洞地描述自己的设想容易得多，改进一些事物要比创造一些事物容易得多。,38, 原型方法将模拟的手段引入分析的初期阶段，沟通了人们的思想，缩短了用户和开发人员之间的距离。这主要表现在： 所有问题的讨论都是围绕某一个确定原型而进行的，彼此之间不存在误解和答非所问的可能性，为准确认识问题创造了条件。 有了原型才能启发人们对原来想不起来或不易准确

15、描述的问题有一个比较确切的描述； 能够及早地暴露出系统实现后存在的一些问题，促使人们在系统实现之前就加以解决。,39,原型法的适用范围和局限性： - 对于一个大型系统，如果不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。 - 对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。 - 对于一个批处理系统，由于大部分活动是内部处理的，因此应用原型方法会有一定的困难。,40,原型方法存在的问题： - 文档容易被忽略。 - 建立原型的许多工作会被浪费掉 。 - 项目难以规划和管理。,41,原型方法可以支持软件生命周期的不同阶段,42,4. 迭代模型(Iterativ

16、e),使用瀑布模型人们认识到，由于需求很难调研充分，所以很难一次性开发成功。 迭代模型提倡两次开发： - 第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求； - 第二次在此基础上获得较为满意的软件产品。,43,迭代模型分类： - 探索式迭代模型 - 进化型迭代模型 迭代模型的特点： - 优点：明确用户需求、提高系统质量、降低开发风险； - 缺点：难于管理、结构较差、技术不成熟； 迭代模型适用范围： - 需求不清楚； - 小型或中小型系统； - 开发周期短,44,5. 增量模型,Mills等人于1980年提出 ，指首先对系统最核心或最清晰的需求进行分析、设计、实现、

17、测试并集成到系统中。再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法。,45,46,增量模型的优点： - 有利于增加客户对系统的信心； - 降低系统失败风险； - 提高系统可靠性； - 提高了系统的稳定性和可维护性； 增量模型的缺点： - 增量粒度难以选择； - 确定所有的基本业务服务比较困难 。,47,6. 螺旋模型,Boehm于1988年提出，主要针对大型软件项目的开发。 大型软件项目的特点： （1）需求功能复杂，无法一开始就明确；开发周期长，中途需求经常变化； （2）往往存在诸多风险因素，在不同程度上损害软件开发过程和软件产品的质量，所以必须对风险进行管理。 螺旋

18、模型最大特点就是引入了明确的风险管理。,48,49,制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。 风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理措施规避这些风险。 实施工程：针对每一个开发阶段的任务要求执行本开发阶段的活动。 客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。,50,7. 喷泉模型,喷泉模型认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷

19、泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。 各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。 优点： - 提高开发效率 - 缩短开发周期 缺点：难于管理,51,52,特点： 1、各阶段之间的无缝连接； 2、箭头表示各阶段内部的迭代； 3、维护期圆较小，说明维护时间缩短。,53,8. 构件组装模型,构件组装模型利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的 。 构件组装模型的开发过程就是构件组

20、装的过程，维护的过程就是构件升级、替换和扩充的过程。,54,55,优点： - 充分利用软件复用，提高了软件开发的效率。 - 允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。 缺点： - 缺乏通用的构件组装结构标准，风险较大； - 构件可重用性和系统高效性之间不易协调； - 由于过分依赖于构件，构件质量影响着最终产品的质量。,56,9. 快速应用开发模型,快速应用开发（Rapid Application Development，RAD）是一个增量型的软件开发过程模型，强调极短的开发周期 。,57,RAD模型的缺点： - 并非所有应用都适合采用RAD，如果一个应用不能被模

21、块化，那么构造应用的构件就无法快速获取； - 由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败 ； - RAD适合于管理信息系统的开发；对于其它类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适 。,58,传统方法学的缺点,过分强调了分阶段实施，使得开发过程各个阶段之间存在严重的顺序性和依赖性； 思维成果的可重用性很差； 忽视了人在软件开发过程中的地位和作用。,59,新型软件生命周期模型,1. RUP RUP（Rational Unified Process）统一过程模型是由Rational公司（现被IBM公司收购）

22、开发的一种软件工程过程框架，是一个面向对象的基于web的程序开发方法论 。 RUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件（Work product）要素整合在统一的框架中 。,60,RUP的基本结构,61,RUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。 每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满

23、意的话，可以允许项目进入下一个阶段。,62,RUP的9个核心工作流 6个核心过程工作流 - 业务建模（Business Modeling） - 需求（Requirements） - 分析和设计（Analysis & Design） - 实现（Implementation） - 测试（Test） - 部署（Deployment）,63,3个核心支持工作流： - 配置和变更管理（Configuration & Change Management） - 项目管理（Project Management） - 环境（Environment）,64,初始阶段 - 目标是为系统建立商业企划（business

24、 case）并确定项目的边界。 - 商业企划包括项目的验收规范、风险评估、所需资源估计、阶段计划等。 - 要确定项目边界，需识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。,65,- 阶段结束里程碑：生命周期目标（Lifecycle Objective）里程碑，包括一些重要的文档，如：项目构想（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始商业企划等。 需要对这些文档进行评审，以确定：正确理解用例需求、项目风险评估合理、阶段计划可行等。,66,细化阶段 - 目标是分析问题

25、领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。 - 里程碑：包括：风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。 通过评审确定：软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。,67,构造阶段 - 将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。 - 里程碑：初始运行能力（Initial Operational Capability）里程碑。包括：可以运行的软件产品、

26、用户手册等，它决定了产品是否可以在测试环境中进行部署。 通过评审确定：软件、环境、用户是否可以开始系统的运行。,68,移交阶段 - 移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。 - 里程碑：产品发布(Product Release)里程碑。 通过评审确定：最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。,69,RUP通过迭代增量建模思想提高了风险控制能力，这体现在： 迭代计划安排是风险驱动的，高风险因素集中在前两个阶段解决，特别是体系结构级的风险

27、在细化阶段就得到了解决，及早降低了系统风险； 每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的；,70, 每一个阶段结束时还有严格的质量评审，保证里程碑文档的质量； 由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，所以，可以根据市场竞争的情况适时推出中间版本，降低市场风险。,71,RUP的最佳实践： 短时间分区式的迭代：26周，不鼓励时间推迟； 适应性开发：小步骤、快速反馈和调整； 在早期迭代中解决高技术风险和高业务价值的问题； 不断地让用户参与迭代结果的评估，并及时获取

28、反馈信息，以逐步阐明问题并引导项目进展； 在早期迭代中建立内聚的核心架构。,72, 不断地验证质量；尽早、经常和实际地测试； 使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。 可视化软件建模：使用UML（Unified Modeling Language，统一建模语言）进行软件建模。 仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪。拙劣的需求管理是项目陷入麻烦的一个常见原因。 实行变更请求和配置管理。,73,RUP模型的优点 提高了团队生产力，在迭代的开发过程、需求管理、可视化软件建模、验证软件质量及控制软件变更等

29、方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。 RUP模型的缺点 RUP在理论上，是比较理想的，但在实际应用上，还需要更多的工具的支持和普及推广工作。,74,2. 敏捷模型,为了避免许多公司的软件团队陷入过程泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：Scrum，Crystal，特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发（Adaptive Software Development，简称ASD），以及极限编程

30、（eXtreme Programming,简称XP）。 敏捷开发过程是对已有生命周期模型的补充，它本身不是一个完整的方法论，在应用传统的生命周期模型时可以借鉴敏捷开发的过程指导思想 。,75,敏捷开发的价值观： - 个人和交互胜过过程和工具； - 实用的软件胜过面面俱到的文档； - 客户合作胜过合同谈判； - 响应变化胜过遵循计划。,76,敏捷开发原则： (1)优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意； (2)即使到了开发的后期，也欢迎改变需求； (3)敏捷过程利用变化来为客户创造竞争优势； (4)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短

31、越好； (5)围绕被激励起来的个体来构建项目； (6)给他们提供所需的环境和支持，并且信任他们能够完成工作；,77,(7)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；工作的软件是首要的进度度量标准；敏捷过程提倡可持续的开发速度； (8)负责人、开发者和用户应该能够保持一个长期的、稳定的开发速度； (9)不断地关注优秀的技能和好的设计会增强敏捷能力； (10)简单是最根本的； (11)最好的构架、需求和设计出自于团队； (12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，对自己的行为进行调整。,78,敏捷开发的核心实践 - 项目相关人员的积极参与 - 集体所有

32、制 - 测试性思维 （TDD） - 创建简单的内容 - 简单地建模,79,- 公开展示模型 - 小增量建模 - 和他人一起建模 - 用代码验证 - 使用最简单的工具,80,极限编程(XP-eXtreme Programming)是敏捷模型的一种实现过程，由Kent Beck在1996年提出 。,81,极限编程的12个实践 ： （1）小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 （2）项目计划。客户需求以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户

33、需求收集，也不是由开发人员整理，而是采取让客户编写，设定优先级别，开发人员进行分析，并进行技术实现。 当然项目计划可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。,82,（3）现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。 （4）隐喻（metaphor）。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。 （5）

34、简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。,83,（6）重构。重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。 （7）测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直

35、接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。,84,（8）持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。 （9）结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。,85,（10） 代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有

36、的人都熟悉所有的编码。 （11）编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的。 （12）每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。,86,优点 采用简单计划策略，不需要长期计划和复杂模型，开发周期短； 在全过程采用迭代增量开发、反馈修正和反复测试的方法，能够适应用户经常变化的需求。,87,缺点 目前主要在小规模项目上应用并取得成功，但是否适用于中等规模或大规模软件产品，需慎重考虑； 由于这个模型较新产品交付后维护成本是否降低，不能确定； 对编码人员的经验要求高。,88,1. 为什么需要软件过程？ 2. 说明软件过程的分类。 3. 说明最基本的过程框架活动。 4. 瀑布模型虽然是最早的软件生命周期模型，但在现实中，是否仍然具有实用价值？为什么？ 5. 说明增量模型的过程及特点。 6. 说明极限编程模型的过程及特点。,思考题,