软件工程学概述共4学时课件.ppt

1、2022-12-171第第1章章 学习要求：学习要求：1、了解软件危机产生的原因和消除软件危机的根本途径；、了解软件危机产生的原因和消除软件危机的根本途径；2、掌握软件工程掌握软件工程,软件工程学软件工程学,软件生命周期和软件过程的软件生命周期和软件过程的概念；概念；3、理解软件工程的基本原理；、理解软件工程的基本原理；4、掌握常见的几种开发模型掌握常见的几种开发模型(过程过程)；2022-12-172第第1章章 2022-12-1732022-12-1742022-12-1752022-12-1762022-12-1772022-12-1782022-12-1792022-12-171020

2、22-12-17112022-12-17122022-12-17132022-12-17142022-12-17151.4软件过程 软件过程是近十年来人们关注的焦点。软件过程是为开发高质量软件所需要完成的任务的框架。软件工程是有创造力、有知识的人在定义好的、成熟的软件过程框架中进行的。2022-12-1716软件过程软件过程层次图质量焦点质量焦点过程过程方法方法工具工具2022-12-1717软件过程 软件过程提供了一个框架，在该框架下可以建立一个软件开发的综合计划：若干框架活动适用于所有软件项目，而不在乎其规模和复杂性。若干不同任务的集合-每一个集合都由任务、里程碑、交付物以及质量保证点组成

3、-使得框架活动适应于不同软件项目的特征和项目组的需求。若干保护性活动-如软件质量保证、软件配置管理、测试与度量-它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程之中。2022-12-1718软件过程里程碑、交付物SQA点公共过程框架框架活动保护性活动任务集合工作任务2022-12-1719软件过程软件过程可分为三大类：基本过程类：是构成软件生存周期主要部分的那些过程，包括获取、供应、开发、操作、维护等过程。支持过程类：可穿插到基本过程中提供支持的一系列过程，包括文档开发、配置管理、质量保证、验证、确认、联合评审、审计、问题解决等过程。组织过程类：一个组织用来建立、

4、实施一种基础结构、并不断改进该基础结构的过程，包括管理、基础、改进、培训等过程。2022-12-1720软件过程模型 软件过程模型是软件开发的指导思想和全局性框架，软件过程模型的提出和发展反映了人们对软件过程的某种认识观，体现了人们对软件过程认识的提高和飞跃。2022-12-1721什么是过程？软件工程中的目标就是开发和维护软件及相关产品New or changedrequirementsNew or changed systemSoftware EngineeringProcess2022-12-1722当前主流的软件过程CMMRUPMSFXP2022-12-1723过程铁三角过程：把各部分

5、集成在一起 CMM规程人技术和工具2022-12-1724软件过程了解软件过程掌握软件过程模型:瀑布模型、原型模型、增量模型、迭代模型了解RUP了解XP 2022-12-1725过程过程就是针对某一给定目标的一系列运作步骤，IEEE-STD-610 是在过程环境下的一系列有序活动。所谓活动（Activity）就是过程对象一次状态改变，也叫过程步(Step)。活动起始态和活动结果态表征了活动的进行。可以说一切事物的发生、发展、消亡都离不开过程，都寓于过程之中。2022-12-1726过程的一般定义2022-12-1727煮蛋的启示2022-12-1728软件过程 软件过程是将用户的需求转化成有效

6、的软件解决方案的一系列活动。许多软件组织无法正确定义和控制这一过程，但这恰恰是组织改进的关键。2022-12-1729软件过程(Cont.)过程的好坏由结果状态与预期状态的差异决定，也就是目标成果质量的好坏。规程（Procedure）是人们对客观事物运动规律 的理解和掌握，使规范了的过程。软件过程是为了获得高质量软件产品所需要完 成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程必须科学、合理，才能开发出高质量 的软件产品。2022-12-1730软件过程(Cont.)软件过程又称软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。早期：立项、需求分析

7、、设计、编码、测试、交付、维护、退役2022-12-1731软件过程(Cont.)项目计划就是安排实际的过程，制作项目计划首先要定义过程。项目计划是某个软件过程模型的实例。软件过程是人类制作产物的一系列活动，而过去的软件工程师把产物和人分离，只研究产品过程及其质量，假定人力、物力资源是无限大、无限好。现在认识到面对实际资源实施软件过程学，求相对最佳质量才是有效的。2022-12-1732软件过程(Cont.)现在的软件生命周期过程包括：早期：立项、需求分析、设计、编码、测试、交付、维护、退役又加入了：管理各种活动、质量保证环境基础设施配置、文档管理等。2022-12-1733软件开发问题的循环

8、解决过程状态描述问题定义技术开发方案综述2022-12-1734软件开发过程为开发小组的活动顺序提供向导详细说明那些制品将被开发，以及什么时候开发指导每一个开发人员和整个开发组的工作为监控和度量项目的产品和活动提供准则2022-12-1735软件工程 方法学传统方法学面向对象的方法学2022-12-1736传统方法学(生命周期方法学)仍然是使用十分广泛的软件工程方法学。采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。从上而下，顺序地完成软件开发的各阶段任务。2022-12-1737软件过程模型 瀑布模型（Waterfall）原型模型（Proto

9、type）增量模型（Incremental）螺旋模型（Spiral）迭代模型（Iterative）2022-12-1738瀑布模型瀑布模型(线性顺序模型线性顺序模型)瀑布式模型包含以下活动：系统/信息工程和建模软件需求分析设计代码生成测试维护2022-12-1739基本概念软件生存期（过程）模型：软件生存期是软件产品或系统一系列相关活动的全周期。从形成概念开始，经过研制，交付使用，在使用中不断增补修订，直到最后被淘汰，让位于新的软件产品的过程。对软件生存期的不同划分，形成了不同的软件生存期模型。2022-12-1740软件工程的传统途径生命周期方法学 生命周期方法学的基本内容生命周期方法学的基

10、本内容 从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周 期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶 段的任务。段的任务。生命周期方法学的应用方法生命周期方法学的应用方法 从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发；前一个阶段任从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发；前一个阶段任 务的完成是后一个阶段工作的前提和基础，而后一个阶段任务通常是使前一阶务的完成是后一个阶段工作的前提和基础，而后一个阶

11、段任务通常是使前一阶 段提出的解法更进一步的具体化，加进了更多的实现细节。段提出的解法更进一步的具体化，加进了更多的实现细节。阶段过渡方法阶段过渡方法 每一个阶段的开始和结束都有严格标准，前一阶段结束的标准是后一阶段工作每一个阶段的开始和结束都有严格标准，前一阶段结束的标准是后一阶段工作 开始的标准。开始的标准。技术审查和管理复审。技术审查和管理复审。基本概念基本概念 文档及其作用。文档及其作用。生命周期各阶段的基本任务生命周期各阶段的基本任务 问题定义问题定义可行性研究可行性研究 需求分析需求分析 总体设计（概要设计）总体设计（概要设计）详细设计详细设计 编码和单元测试编码和单元测试 综合测

12、试综合测试 软件维护。软件维护。软件工程（生命周期各阶段的基本任务）问题定义可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护要解决的问题是什么？问题性质、工程目标和规模的报告分析员：实际用户+负责人是否有解决办法？分析员 高层逻辑模型，准确和具体的工程规模和目标，成本/效益分析等可行性报告为了解决的问题，目标系统必须做什么？准确确定系统的功能系统的逻辑模型（数据流图+数据字典+简要算法）如何解决这些问题模块划分软件结构如何具体地实现系统：每个模块的流程图（程序的详细规格说明）通过各种类型的测试，使软件达到预定的要求写出正确的容易理解和容易维护的程序模块 通过各种必要的维护活动使

13、系统持久地满足用户的需要生命周期法各阶段的工作小结阶阶段段关关键键问问题题结结束束标标准准问问题题 定定义义问题是什么？关 于 规 模 和 目 标 的 报 告 书可可 行行 性性 研研究究有 可 行 的 解吗？系 统 的 高 层 逻 辑 模 型：数 据流 图、成 本/效 益 分 析需需求求分分析析系 统 必 须 做什 么？系 统 的 逻 辑 模 型：数 据 流 图、数 据 字 典、算 法 描 述总总体体设设计计如 何 解 决 已提出的问题？可 能 的 解 法：系 统 流 程 图、成 本/效 益 分 析；推 荐 的 系 统结 构：层 次 图 或 结 构 图生命周期法各阶段的工作小结阶阶段段关关键

14、键问问题题结结束束标标准准详详细细 设设计计怎 样 具 体 地实 现 这 个 系统？编 码 规 格 说 明：HIPO图 或PDL编编 码码 和和 单单元元测测 试试正 确 的 程 序模 块原 程 序 清 单：单 元 测 试 方 案和 结 果综综合合测测试试符 合 要 求 的软 件综 合 测 试 方 案 和 结 果；完 整一 致 的 软 件 配 置维维护护持 久 地 满 足需 要 的 软 件完 整 准 确 的 维 护 记 录2022-12-1744“生命周期法”的特点w阶段具有顺序性和依赖性w推迟实现的观点w质量保证的观点n每个阶段都必须完成规定的文档n每个阶段结束前都要对所完成的文档进行评审，

15、以便尽早发现问题，改正错误。2022-12-1745软件工程瀑布模型瀑布模型 问题定义特点：1）阶段间具有顺序性和依赖性 2）推迟实现的观点 3）质量保证的观点。可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护软件定义时期软件开发时期软件维护时期2022-12-1746软件开发过程模型n瀑布模型的特征从上一项活动中接受该项活动的工作对象，作为输入。利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，作为输出传给下一项活动对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。2022-12-1747瀑布模型 特点文档驱动文档驱动的模型 阶段间具有顺序性和依赖性

16、推迟实现的观点质量保证的观点2022-12-1748思考？传统瀑布模型存在什么问题？2022-12-1749传统的瀑布模型 存在什么问题？传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的错误。而设计上的缺陷或错误可能在实现过程中显现出 来。在综合测试阶段将发现需求分析、设计或编码阶段 的许多错误。2022-12-1750Tom Gilb：“假如你不积极地解决你项目中存在的风险，它们就会积极地解决掉你”瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时已无济于事。2022-12-1751瀑布模型 问题实际项目很少按照该模型给出的顺序进行用户常常

17、难以清楚地给出所有需求用户必须有耐心开发者常常被不必要地耽搁2022-12-1752软件开发过程模型n瀑布模型的缺点：从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。2022-12-1753瀑布模型 实际的瀑布模型 需求分析验证规格说明验证设计验证编码测试综合测试维护变化的需求验证2022-12-1754软件开发过程模型具有维护循环的软件生存期的瀑布模型2022-12-1755软件开发过程模型原型模型n基本思想基本思想n在获取一组基本的需

18、求定义后，利用高级软件工具的可开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。2022-12-1756原型模型快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。2022-12-1757原型模型 适用情况用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；原型模型可能是最好的选择

19、2022-12-1758原型模型(Cont.)原型模型从需求收集开始。开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解，这个过程是迭代的。2022-12-1759原型模型(Cont.)快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程2022-12-1760原型模型存在的问题用户似乎看到的是软件的工作版本，其实开发者常常需要实

20、现上的折衷，以使原型能够尽快工作2022-12-1761原型模型n在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。2022-12-1762原型模型n在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用

21、户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。2022-12-1763原型模型特征原型特征n软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征：n(1)它是一个可实际运行的系统。2022-12-1764原型模型特征n(2)它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一

22、点，增加一点，逐步完善至最终产品）。2022-12-1765原型模型特征(3)从需求分析到最终产品都可作原型，即可为不同目标作原型。(4)它必须快速、廉价。(5)它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。2022-12-1766原型模型评价原型法的评价n优点优点n1.原型法在得到良好的需求定义上比传统生存周期法好得多，可处理模糊需求，开发者和用户可充分通信。n2.原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。n3.原型给用户以机会更改心中原先设想的、不尽合理的最终系统。n4.原型可低风险开发柔性较大的计算机系统。n5.原型增加使系统更易维

23、护、对用户更友好的机会。n6.原型使总的开发费用降低，时间缩短。2022-12-1767n缺点缺点n1.“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。n2.原型迭代不收敛于开发者预先的目标。即每次更改，为了消除错误，次要部分越来越大，“淹没”了主要部分。n3.原型过快收敛于需求集合，而忽略了一些基本点。n4.资源规划和管理较为困难，随时更新文档也带来麻烦。n5.长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。原型模型评价2022-12-1768n适用范围：适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替

24、代生存期的部分或全部阶段，具体可以用于以下领域：n1.辅助分析和确定用户需求的任务。n2.作为软件设计的一种工具。例如：研究系统设计的可行性和适应性。n3.作为一种解决不确定性的工具。例如：研究一种新技术的效果，逐步使其适应预定的环境。n4.作为一种实验工具。n5.充作同步培训工具。n6.“一次性”的应用。例如写一个能运行的程序，一旦得到答案，该程序将不再使用。n7.作为软件维护的辅助工具。特别是在用户需求不稳定，维护工作量很大的情况下，要求大量的重新设计工作。原型模型评价2022-12-1769增量模型融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。2022

25、-12-1770增量模型(Cont.)需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户2022-12-1771增量模型(Cont.)分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2 增量3增量4 2022-12-1772增量模型(Cont.)增量模型融合了瀑布模型的基本成分和原型的迭代特性。例如，使用增量模型开发字处理软件l基本的文件管理、编辑和文档生成功能。l更完善的编辑和文档生成能力。l实现拼写和文法检查功能。l完成高级的页面布局功能。2022-12-1773增量模型(Cont.)第一个增量往往是核心产品每一个增量均发

26、布一个可操作产品早期的增量是最终产品的“可拆卸”版本2022-12-1774软件开发过程模型喷泉模型n喷泉模型认为软件生命周期的各个阶段是相互重叠和多次反复的。n主要用于面向对象方法中2022-12-1775软件开发过程模型螺旋模型n在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型。2022-12-1776软件开发过程模型螺旋模型2022-12-1777软件开发过程模型螺旋模型2022-12-1778n螺旋模型分析w在螺旋模型结构中，维护只是螺旋模型的另一个周期，在维护和开发之间本质上并没有区别，从而解决了做太多测试或未作足够测试所带来的风险。w适用条件n内部的大规模软件的开发，不太

27、适合合同软件。n一般只适用于大规模软件的开发软件开发过程模型螺旋模型2022-12-1779迭代模型建立在Barry Boehm 的螺旋模型基础上的。2022-12-1780迭代模型(Cont.)2022-12-1781迭代模型(Cont.)PlanningRequirementsAnalysis&DesignImplementationDeploymentTestEvaluationManagementEnvironmentEach iteration results in an executable release.2022-12-17822022-12-1783TimeRiskWater

28、fall RiskIterative RiskRisk Profiles2022-12-1784特点这种方法可以在生命周期早期强制性的确定项目中存在的风险。这种方法是一个连续地发现、创造和实现的过程。在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动项目制品的生产和制作。2022-12-1785提供解决方案：在生命周期的早期，这种方法可以及时地发现一些严重的需求理解错误，此时还可能修正这些错误。允许并鼓励用户反馈信息，以明确系统的真实需求。这种方法使开发小组重视项目中最关键的问题，而屏蔽掉那些使他们远离项目真实风险的问题。不断地迭代测试能够给出项目状况的客观评价。2022-12-17

29、86提供解决方案:(Cont.)尽早地发现需求、设计和实现中的不一致。在整个项目生命周期中更加平均地分配开发组的工作量，特别是测试小组的工作量。开发组可以不断打在开发中进行学习从而改进过程。在整个生命周期中，项目相关人员可以通过具体证据了解项目状况。2022-12-1787Review:软件过程模型 瀑布模型原型模型增量模型螺旋模型迭代模型2022-12-1788软件开发问题的症状对于最终用户的需要理解得不够精确对需求的改变束手无策程序块不兼容软件不易维护或不易扩展对项目严重缺陷的发现较晚软件质量低劣软件性能令人无法接受开发组的人员按各自的方式进行开发，如果有人改变可部分软件，将很难进行重组一

30、个不可靠的构造和发布过程2022-12-1789Symptoms of SW Development ProblemsUser or business needs not metRequirements churnModules dont integrateHard to maintainLate discovery of flawsPoor quality or end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues2022-12-1790失败原因特别的需

31、求管理模糊和不精确的交流脆弱的构架过度复杂未检测出需求、设计和实现之间的不一致测试的不足对于项目状况的评估过于主观未解决存在的风险无法控制变化的产生和传播自动控制不足2022-12-1791RUP现在软件产业界普遍认为，开发复杂软件项目必须采用基于UML的、以构架为中心、用例驱动与风险驱动相结合的迭代式增量开发过程，他是世界公认的开发复杂软件项目的最好过程，已经成为软件界的“圣经”。这一开发过程目前已经稳定、成熟。这就是：2022-12-1792RUPRUPRational Unified Process2022-12-1793Rational Unified ProcessRUP Ratio

32、nal 统一过程是由Rational 软件公司开发和营销的一种软件工程过程，是开发组织用以分配与管理任务和职责的一种规范化方法。这个过程的目的是在预定的进度和预算范围内，开发出满足最终用户需要的高质量软件。2022-12-1794RUP捕获的6项最佳商业实践 被证明是解决软件开发过程中根本问题的方法2022-12-1795最佳软件开发实践 Best Practices迭代地开发软件 Develop Iteratively管理需求 Manage Requirements应用基于构件的构架 Use Component Architectures为软件建立可视化的模型 Model Visually(

33、UML)不断地验证软件质量 Continuously Verify Quality控制软件的变更 Manage Change2022-12-1796RUP的目标按照预先制定的时间计划和经费预算，开发出高质量的软件产品以满足最终用户的需求2022-12-1797RUP是什么？是一种软件工程过程是一个过程产品有自己的过程框架捕获了现代软件开发中的最佳实践2022-12-1798RUP的三大特点用例驱动以架构为中心迭代和增量开发2022-12-1799用例驱动用Use Case作为划分问题的组织单元，分析和设计活动的局部粒度都遵循这一划分原则。Use Case的定义反映可系统外部要素根据特定目标使用

34、拟建系统的状况，能确保问题的局部划分粒度适当，保持了全局与局部的平衡。2022-12-171002022-12-17101RUP的整体架构2022-12-17102RUP的迭代模型2022-12-17103RUP的关键概念2022-12-17104RUPRUP将这些最佳实践活动以一种适当的形式结合起来，从而适应了广泛的项目和开发组织。RUP 是一个过程产品(process product)。Rational(IBM)软件公司开发并维护着这个产品，并将其与Rational 软件公司自己的一系列软件开发工具集成。2022-12-17105RUPRUP 有自己的过程框架(process framew

35、ork),这个框架可以被改造和扩展以适应采纳此方法的组织。软件过程也是软件设计、开发、交付和维护2022-12-17106RUP 简要历史RUP 2000RUP 5.5RUP 5.0ROP 4.1ROP 4.0Rational 方法Objective 过程3.8200019991998199719961995实时ROOM业务工程配置和变更管理需求学院Booch 方法OMT UML 0.8SQA 过程UML 1.1数据工程UI 设计UML 1.2基于WEB的开发UML1.32022-12-17107谁在使用RUP?电信业nEricsson、Alcatel、MCI 交通、航空、国防nLockhee

36、d-Martin、British Aerospace制造业nXerox、Volvo、Intel金融业nVisa、Merrill Lynch、Schwab 系统集成业nErnst&Young、Oracle、Deloitte&Touche 2022-12-17108RUP RUP核心是解决可操作性问题，帮助开发人员尽可能少地依赖那些“不可描述的经验”。他详细给出了每个阶段参与该过程的各种焦色，然后表示在过程中，该角色创建的制品。2022-12-17109Rational Unified Process 的主要工件，及这些工件间的信息流2022-12-171102022-12-171112022-1

37、2-171122022-12-171132022-12-171142022-12-171152022-12-17116增量和迭代开发基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。2022-12-17117RUP 二维过程结构沿时间轴的组织结构沿内容轴的组织结构2022-12-17118RUP的生命开发周期2022-12-17119RUP的生命开发周期2022-12-17120RUP的生命开发周期2022-12-17121RUP的生命开发周期2022-12-17122主要困难多层次持续的规划与评估判断架构中关键风险的经验高效率的

38、验证和评价手段多工种之间的频繁沟通多版本工作产品的管理2022-12-17123基础保障核心人员必要的管理与技术经验自动化的验证和评价工具团队成员之间有高效的沟通工具软件配置与变更管理工具2022-12-17124RUP 的裁减RUP 仅仅是一个通用的过程框架，需要根据实际情况裁减。2022-12-17125A Process is not Enough to Build a System2022-12-17126 XPXP（Extreme Programming），它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的

39、成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。2022-12-17127XP是什么？敏捷方法的代表。Kent Beck在他的开篇之作Extreme Programming Explained Embrace Change中提出97年一种高度动态的过程，它通过非常短的迭代周期来应对软件开发中的变化强调有效测试和演化设计fowler2022-12-17128XP的目标在

40、规定的时间生产出满足客户需要的软件 2022-12-17129什么时候需要XP？需求不明确、变化快高风险：在特定的时间内，面对一个相当难开发的系统 中小型团队（人数不超过10 个）2022-12-17130XP的系统隐喻 过程顺利完成发扬4个价值准则实现12个实践依赖于平衡短期利益与长期利益的冲突依赖于构造XP开发规范中的四项活动：编码测试聆听设计2022-12-17131XP体现四个价值目标沟通（communication）简化（simlicity）反馈（feedback）勇气（courage）2022-12-17132XP的12个核心实践规划策略(Planning game)系统隐喻(Sy

41、stem Metaphor)简单设计(Simple design)配对编程(pair programming)编码标准(Coding standards)测试驱动(Test-driven)重构（Refactoring）持续集成(Continuous integration)小发行版(Small releases)现场客户(On-site customer)集体代码所有权(Collective ownership)一周40小时(40-hour week)2022-12-17133实践之间的互相支持现场客户规划策略一周40小时小发行版简单设计测试驱动配对编程系统隐喻重构编码标准集体所有权持续集成2

42、022-12-17134XP项目的状态图 2022-12-17135XP的计划/反馈循环2022-12-17136从CMM角度看XP XP部分满足或大部分满足了CMM 2-3 级KPA 的要求，而基本上没有涉及CMM 4-5 级的KPAXP 侧重于具体的过程和开发技术，而CMM 更关注组织和管理上的问题 XP 缺少的一个重要内容是“institutionalization”-Mark Paulk,SEI2022-12-17137XP vs.RUPw面向对象 w风险驱动 w需求导向 w迭代，增量开发 软件开发方法学 过程框架 小巧灵活 巨大复杂 变化是不变的 控制变化 文档将成为制品 文档就是代码和测试 计划设计 演化设计以代码为中心，自底向上 以架构为中心，自顶向下 从开发者的角度 从机构的角度 2022-12-17138对XP的置疑技术前提：对变化成本曲线的置疑 技艺前提：对于有经验的人是简单的代码，对没有经验的人是复杂的 社会结构前提：程序员可以能否对自己的开发过程承担责任 2022-12-17139不适用于XP的场合不能接受XP 文化的组织 中大型（超过10 个人）的团队 重构会导致大量开销的应用 需要很长的编译或测试周期的系统 不太容易测试的应用 人员异地分布的物理环境 Beck