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

软件过程框架与软件过程模型第一页，共八十八页，编辑于2023年，星期三软件过程框架什么是过程？针对一个给定目标的一系列操作步骤。

例如

-目标：去火车站

-操作步骤：去南门/东门公共汽车站，乘50/17路汽车，…

每个过程都有明确的目的以及具体的操作步骤，操作步骤说明了有哪些操作以及按照什么样的方式来执行操作。2第二页，共八十八页，编辑于2023年，星期三什么是软件开发过程？按照项目的进度、成本和质量限制，开发和维护满足用户需求的软件所必需的一组有序的软件开发活动集合。

软件开发活动的例子-需求分析-体系结构设计

开发活动的顺序例子-先做需求分析，然后再做体系结构设计……3第三页，共八十八页，编辑于2023年，星期三在按任务性质，软件开发活动可分为二种形式技术活动-对软件项目实施开发，产生软件产品-例如，需求分析，概要设计，编码，单元测试等等管理活动-对软件项目中的人、产品和过程等实施管理的活动-例如，制订软件项目计划，软件配置等等4第四页，共八十八页，编辑于2023年，星期三如何定义软件开发活动?-名称-任务-输入:开始所必需满足的条件-输出:完成时所必须满足的条件以及结果-实施:做什么，怎么做(详细的步骤)，或者如何从输入产生输出软件开发活动输入输出5第五页，共八十八页，编辑于2023年，星期三软件活动例子:-名字：单元测试-任务对软件基本单元模块进行测试，判断是否有错-输入有一个已完成、被文档化和批准的软件单元测试计划供测试的软件单元模块代码-实施遵循单元测试计划，运行所有的测试用例撰写单元测试报告-输出单元测试报告6第六页，共八十八页，编辑于2023年，星期三为什么需要软件过程？

-明确了软件开发的过程和步骤，促进工程化软件开发

-便于制定软件项目计划

-为软件开发提供了可视性，便于对软件开发过程进行管理和控制

-便于细化和安排任务，使得每个人员明确各自的工作7第七页，共八十八页，编辑于2023年，星期三软件开发过程模型软件开发过程模型-软件开发过程模型是软件开发全过程、软件开发活动以及它们之间关系的结构框架-指导软件开发以及软件开发过程的定义常用的软件开发过程模型-瀑布模型-原型模型-增量模型-迭代模型-螺旋模型8第八页，共八十八页，编辑于2023年，星期三软件过程分类

-

基本过程类是构成软件生存周期主要部分的那些过程,包括：定义、构建、维护等过程.

-支持过程类可穿插到基本过程中提供支持的一系列过程,包括：文档开发、配置管理、质量保证、验证、确认、联合评审、审计、问题解决等程.

-组织过程类一个组织用来建立、实施一种基础结构,并不断改进该基础结构的过程,包括：管理、计划、改进、培训等过程.9第九页，共八十八页，编辑于2023年，星期三工作任务里程碑、交付物SQA（软件质量保证）点任务集合技术性活动公共过程框架支持性活动公共软件过程框架10第十页，共八十八页，编辑于2023年，星期三

一个公共过程框架，是通过定义若干框架活动来建立的，如果不考虑其规模和复杂性，这些活动适用于所有软件项目。

任务集合——每一个集合都由软件工程工作任务、项目里程碑、软件工程产品和交付物以及质量保证点组成——使得框架活动适应于不同软件项目的特征和项目组的需求。

支持性活动——如软件质量保证，软件配置管理和测度，它们贯穿于整个过程模型之中。支持性活动独立于任何一个框架活动，且贯穿于整个过程。11第十一页，共八十八页，编辑于2023年，星期三管理性活动-软件项目跟踪和控制允许项目组根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。-风险管理评估可能对项目成果或者产品质量产生影响的风险。-软件质量保证确定和执行用以保证软件质量的活动。

·正式技术评审:

评估软件工程产品，尽量在错误传播到下一个动作或活动之前，发现并清除错误。

·V&V（VerificationandValidation）：验证与确认。12第十二页，共八十八页，编辑于2023年，星期三-测量定义和收集过程、项目和产品的度量，以帮助团队在发布软件的时候满足客户要求。同时，测量还可与其它框架协同使用。-软件配置管理管理整个软件过程中变更所带来的影响。-可复用管理定义产品复用的标准（包括软件构件），并且建立构件复用机制。-工作产品（WorkProduct）的准备和生产

包括了创建产品所必须的活动如建模、文档、日志、表格和列表等。13第十三页，共八十八页，编辑于2023年，星期三主要的开发和支持过程

1、软件需求分析

任务：收集、分析、理解、确定用户的要求；然后把用户的要求精确、完整地描述表达出来。

目的：要回答“要解决什么问题？”，既系统“做什么？”。

输入：系统需求文档/问题陈述、本过程相关工作计划步骤：可行性研究、需求分析、制定相关开发计划

输出：可行性报告、需求规范、下一过程开发计划

需求说明书是让用户理解:“什么是他们真正需要的”；让开发者理解“什么是他们真正的开发目标”。14第十四页，共八十八页，编辑于2023年，星期三ReviewItemDiscrepancy15第十五页，共八十八页，编辑于2023年，星期三任务：给出实现系统的实施蓝图。目的：要回答“如何解决该问题？”，既系统“怎样做？”。输入：软件需求规范、本过程相关计划步骤：概要设计：解决系统的子系统/模块划分、子系统/模块的层次结构及数据库设计；详细设计：解决每个模块/类内部算法和数据结构；制定下一过程相关计划。输出：体系结构设计说明书、详细设计说明书、下一过程相关计划2、软件设计16第十六页，共八十八页，编辑于2023年，星期三17第十七页，共八十八页，编辑于2023年，星期三18第十八页，共八十八页，编辑于2023年，星期三3、软件构造任务：根据设计说明书中每个模块的控制流程编写出相应的源程序。目的：写出高质量的代码和相应的文档。-构造要注意使系统更易于使用和系统的可重用性。-选择合适的开发工具及系统软件、数据库软件、中间件等。制定编程规范。输入：软件设计文档、本过程相关计划步骤：编程、单元测试、制定下一阶段相关计划、编制用户文档输出：源程序和相关文档、下一过程相关计划19第十九页，共八十八页，编辑于2023年，星期三4、软件测试任务：检查、发现程序中的错误，提高系统可靠性。目的：保证系统的正确性、可靠性和可用性。回答：“该系统是否能实现规定的操作？”。输入：已经完成的代码、本过程相关的计划步骤：集成测试、系统测试、确认测试输出：测试报告和软件修改报告等。20第二十页，共八十八页，编辑于2023年，星期三5、软件维护任务：改正软件系统在使用过程中发现的隐含错误，扩充在使用过程中新的功能要求。目的：维护软件系统的正常运行。回答：系统是否满足用户的应用要求。输入：问题报告步骤：问题报告审批、问题修改、审核输出：软件修改报告。21第二十一页，共八十八页，编辑于2023年，星期三6.软件配置管理软件修改后会发生什么呢？-同步更新——当两个或两个以上的角色各自工作在同一产物上时，最后一个修改者会破坏前者的工作。-通知不达——当被若干开发者共享的产品中的问题被解决时，修改未被通知到一些开发者。-多个版本——软件修改与文档不一致。-新版本公布的管理和监控。配置和变更管理提供了准则管理演化系统中的多个变体，跟踪给定软件创建过程中的版本。22第二十二页，共八十八页，编辑于2023年，星期三SRD23第二十三页，共八十八页，编辑于2023年，星期三7.软件工程管理

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

以上活动均应在软件质量保证计划中列出。27第二十七页，共八十八页，编辑于2023年，星期三28第二十八页，共八十八页，编辑于2023年，星期三传统软件生命周期模型1.瀑布模型

WinstonRoyce在软件生命周期概念的基础上，于1970年提出了著名的“瀑布模型”（waterfallmodel）。29第二十九页，共八十八页，编辑于2023年，星期三瀑布模型中的每一个开发活动具有下列特征：-本活动的工作对象来自于上一项活动的输出，这些输出一般是代表本阶段活动结束的里程碑式的文档。-根据本阶段的活动规程执行相应的任务。-产生本阶段活动相关产出——软件产品，作为下一活动的输入。-对本阶段活动执行情况进行评审。30第三十页，共八十八页，编辑于2023年，星期三瀑布模型的优缺点优点缺点降低了软件开发的复杂程度，而且提高了软件开发过程的透明性，提高了软件开发过程的可管理性。模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。推迟了软件实现，强调在软件实现前必须进行分析和设计工作。模型的风险控制能力较弱。以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量；而且当管理人员以文档的完成情况来评估项目完成进度时，往往会产生错误的结论。31第三十一页，共八十八页，编辑于2023年，星期三2.V模型和W模型

1980年代后期PaulRook提出了V模型32第三十二页，共八十八页，编辑于2023年，星期三Evolutif公司在V模型的基础上提出了W模型33第三十三页，共八十八页，编辑于2023年，星期三3.原型方法原型方法的产生

-瀑布模型、V模型和W模型都将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。

-然而完整而准确的需求规格说明是很难得到的，因为：在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求随着开发工作的推进，用户可能会产生新的要求开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境34第三十四页，共八十八页，编辑于2023年，星期三原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。原型方法主要用于明确需求，但也可以用于软件开发的其它阶段。35第三十五页，共八十八页，编辑于2023年，星期三原型的三种作用类型：（1）探索型：弄清用户对目标系统的要求，确定所期望的特性；探讨多种实现方案的可行性。主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。（2）实验型；用于大规模开发和实现之前，考核技术实现方案是否合适。（3）进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统。它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目。36第三十六页，共八十八页，编辑于2023年，星期三原型方法的特点：（1）从认知论的角度看，原型方法遵循了人们认识事物的规律，因而更容易为人们所普遍接受，这主要表现在：①人们对任何事物的认知都不可能一蹴而就、尽善尽美；②认识和学习的过程都是循序渐进的；③对于事物的描述，往往都是受环境的启发而不断完善的；④人们批评指责一个已有的事物，要比空洞地描述自己的设想容易得多，改进一些事物要比创造一些事物容易得多。37第三十七页，共八十八页，编辑于2023年，星期三⑵原型方法将模拟的手段引入分析的初期阶段，沟通了人们的思想，缩短了用户和开发人员之间的距离。这主要表现在：①所有问题的讨论都是围绕某一个确定原型而进行的，彼此之间不存在误解和答非所问的可能性，为准确认识问题创造了条件。②有了原型才能启发人们对原来想不起来或不易准确描述的问题有一个比较确切的描述；③能够及早地暴露出系统实现后存在的一些问题，促使人们在系统实现之前就加以解决。38第三十八页，共八十八页，编辑于2023年，星期三原型法的适用范围和局限性：-对于一个大型系统，如果不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。-对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。-对于一个批处理系统，由于大部分活动是内部处理的，因此应用原型方法会有一定的困难。39第三十九页，共八十八页，编辑于2023年，星期三原型方法存在的问题：-文档容易被忽略。-建立原型的许多工作会被浪费掉。-项目难以规划和管理。40第四十页，共八十八页，编辑于2023年，星期三原型方法可以支持软件生命周期的不同阶段41第四十一页，共八十八页，编辑于2023年，星期三4.迭代模型(Iterative)使用瀑布模型人们认识到，由于需求很难调研充分，所以很难一次性开发成功。迭代模型提倡两次开发：-第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求；-第二次在此基础上获得较为满意的软件产品。42第四十二页，共八十八页，编辑于2023年，星期三迭代模型分类：-探索式迭代模型-进化型迭代模型迭代模型的特点：-优点：明确用户需求、提高系统质量、降低开发风险；-缺点：难于管理、结构较差、技术不成熟；迭代模型适用范围：-需求不清楚；-小型或中小型系统；-开发周期短43第四十三页，共八十八页，编辑于2023年，星期三5.增量模型Mills等人于1980年提出，指首先对系统最核心或最清晰的需求进行分析、设计、实现、测试并集成到系统中。再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法。44第四十四页，共八十八页，编辑于2023年，星期三45第四十五页，共八十八页，编辑于2023年，星期三增量模型的优点：-有利于增加客户对系统的信心；-降低系统失败风险；-提高系统可靠性；-提高了系统的稳定性和可维护性；增量模型的缺点：-增量粒度难以选择；-确定所有的基本业务服务比较困难。46第四十六页，共八十八页，编辑于2023年，星期三6.螺旋模型Boehm于1988年提出，主要针对大型软件项目的开发。大型软件项目的特点：（1）需求功能复杂，无法一开始就明确；开发周期长，中途需求经常变化；（2）往往存在诸多风险因素，在不同程度上损害软件开发过程和软件产品的质量，所以必须对风险进行管理。螺旋模型最大特点就是引入了明确的风险管理。47第四十七页，共八十八页，编辑于2023年，星期三48第四十八页，共八十八页，编辑于2023年，星期三制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理措施规避这些风险。实施工程：针对每一个开发阶段的任务要求执行本开发阶段的活动。客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。49第四十九页，共八十八页，编辑于2023年，星期三7.喷泉模型喷泉模型认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。优点：-提高开发效率-缩短开发周期缺点：难于管理50第五十页，共八十八页，编辑于2023年，星期三51第五十一页，共八十八页，编辑于2023年，星期三特点：1、各阶段之间的无缝连接；2、箭头表示各阶段内部的迭代；3、维护期圆较小，说明维护时间缩短。52第五十二页，共八十八页，编辑于2023年，星期三8.构件组装模型构件组装模型利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的。构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。53第五十三页，共八十八页，编辑于2023年，星期三54第五十四页，共八十八页，编辑于2023年，星期三优点：-充分利用软件复用，提高了软件开发的效率。-允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。缺点：-缺乏通用的构件组装结构标准，风险较大；-构件可重用性和系统高效性之间不易协调；-由于过分依赖于构件，构件质量影响着最终产品的质量。55第五十五页，共八十八页，编辑于2023年，星期三9.快速应用开发模型快速应用开发（RapidApplicationDevelopment，RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。56第五十六页，共八十八页，编辑于2023年，星期三RAD模型的缺点：-并非所有应用都适合采用RAD，如果一个应用不能被模块化，那么构造应用的构件就无法快速获取；-由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败；-RAD适合于管理信息系统的开发；对于其它类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适。57第五十七页，共八十八页，编辑于2023年，星期三传统方法学的缺点过分强调了分阶段实施，使得开发过程各个阶段之间存在严重的顺序性和依赖性；思维成果的可重用性很差；忽视了人在软件开发过程中的地位和作用。58第五十八页，共八十八页，编辑于2023年，星期三新型软件生命周期模型1.RUPRUP（RationalUnifiedProcess）统一过程模型是由Rational公司（现被IBM公司收购）开发的一种软件工程过程框架，是一个面向对象的基于web的程序开发方法论。RUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件（Workproduct）要素整合在统一的框架中。59第五十九页，共八十八页，编辑于2023年，星期三RUP的基本结构60第六十页，共八十八页，编辑于2023年，星期三RUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑(MajorMilestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。61第六十一页，共八十八页，编辑于2023年，星期三RUP的9个核心工作流

6个核心过程工作流-业务建模（BusinessModeling）-需求（Requirements）-分析和设计（Analysis&Design）-实现（Implementation）-测试（Test）-部署（Deployment）62第六十二页，共八十八页，编辑于2023年，星期三3个核心支持工作流：-配置和变更管理（Configuration&ChangeManagement）-项目管理（ProjectManagement）-环境（Environment）63第六十三页，共八十八页，编辑于2023年，星期三初始阶段-目标是为系统建立商业企划（businesscase）并确定项目的边界。-商业企划包括项目的验收规范、风险评估、所需资源估计、阶段计划等。-要确定项目边界，需识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。64第六十四页，共八十八页，编辑于2023年，星期三-阶段结束里程碑：生命周期目标（LifecycleObjective）里程碑，包括一些重要的文档，如：项目构想（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始商业企划等。需要对这些文档进行评审，以确定：正确理解用例需求、项目风险评估合理、阶段计划可行等。65第六十五页，共八十八页，编辑于2023年，星期三细化阶段-目标是分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。-里程碑：包括：风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定：软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。66第六十六页，共八十八页，编辑于2023年，星期三构造阶段-将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。-里程碑：初始运行能力（InitialOperationalCapability）里程碑。包括：可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。

通过评审确定：软件、环境、用户是否可以开始系统的运行。67第六十七页，共八十八页，编辑于2023年，星期三移交阶段-移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。-里程碑：产品发布(ProductRelease)里程碑。通过评审确定：最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。68第六十八页，共八十八页，编辑于2023年，星期三RUP通过迭代增量建模思想提高了风险控制能力，这体现在：⑴迭代计划安排是风险驱动的，高风险因素集中在前两个阶段解决，特别是体系结构级的风险在细化阶段就得到了解决，及早降低了系统风险；⑵每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的；69第六十九页，共八十八页，编辑于2023年，星期三⑶每一个阶段结束时还有严格的质量评审，保证里程碑文档的质量；⑷由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，所以，可以根据市场竞争的情况适时推出中间版本，降低市场风险。70第七十页，共八十八页，编辑于2023年，星期三RUP的最佳实践：⑴短时间分区式的迭代：2～6周，不鼓励时间推迟；⑵适应性开发：小步骤、快速反馈和调整；⑶在早期迭代中解决高技术风险和高业务价值的问题；⑷不断地让用户参与迭代结果的评估，并及时获取反馈信息，以逐步阐明问题并引导项目进展；⑸在早期迭代中建立内聚的核心架构。71第七十一页，共八十八页，编辑于2023年，星期三⑹不断地验证质量；尽早、经常和实际地测试；⑺使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。⑻可视化软件建模：使用UML（UnifiedModelingLanguage，统一建模语言）进行软件建模。⑼仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪。拙劣的需求管理是项目陷入麻烦的一个常见原因。⑽实行变更请求和配置管理。72第七十二页，共八十八页，编辑于2023年，星期三RUP模型的优点提高了团队生产力，在迭代的开发过程、需求管理、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。RUP模型的缺点RUP在理论上，是比较理想的，但在实际应用上，还需要更多的工具的支持和普及推广工作。73第七十三页，共八十八页，编辑于2023年，星期三2.敏捷模型为了避免许多公司的软件团队陷入过程泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：Scrum，Crystal，特征驱动软件开发（FeatureDrivenDevelopment，简称FDD），自适应软件开发（AdaptiveSoftwareDevelopment，简称ASD），以及极限编程（eXtremeProgramming,简称XP）。敏捷开发过程是对已有生命周期模型的补充，它本身不是一个完整的方法论，在应用传统的生命周期模型时可以借鉴敏捷开发的过程指导思想。74第七十四页，共八十八页，编辑于2023年，星期三敏捷开发的价值观：-个人和交互胜过过程和工具；-实用的软件胜过面面俱到的文档；-客户合作胜过合同谈判；-响应变化胜过遵循计划。75第七十五页，共八十八页，编辑于2023年，星期三敏捷开发原则：(1)优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意；(2)即使到了开发的后期，也欢迎改变需求；(3)敏捷过程利用变化来为客户创造竞争优势；(4)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好；(5)围绕被激励起来的个体来构建项目；(6)给他们提供所需的环境和支持，并且信任他们能够完成工作；76第七十六页，共八十八页，编辑于2023年，星期三(7)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；工作的软件是首要的进度度量标准；敏捷过程提倡可持续的开发速度；(8)负责人、开发者和用户应该能够保持一个长期的、稳定的开发速度；(9)不断地关注优秀的技能和好的设计会增强敏捷能力；(10)简单是最根本的；(11)最好的构架、需求和设计出自于团队；(12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，对自己的行为进行调整。77第七十七页，共八十八页，编辑于2023年，星期三敏捷开发的核心实践-项目相关人员的积极参与-集体所有制-测试性思维（TDD）-创建简单的内容-简单地建模78第七十八页，共八十八页，编辑于2023年，星期三-公开展示模型

-小增量建模

-和他人一起建模

-用代码验证

-使用最简单的工具

79第七十九页，共八十八页，编辑于2023年，星期三极限编程(XP-eXtremeProgramming)是敏捷模型的一种实现过程，由Kent

Beck在1996年提出。80第八十页，共八十八页，编辑于2023年，星期三极限编程的12个实践：（1）小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。（2）项目计划。客户需求以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，设定优先级别，开发人员进行分析，并进行技术实现。当然项目计划可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。81