第一部分_软件工程与过程(1-3).ppt

1、软件 工程,软件工程是一门什么样的学科？,是指导计算机软件开发与维护的一门工程学科。 工程：将科学及数学原理运用于实际用途的应用手段，如：设计、制造、机器操纵、构架等。 典型的传统工程：建筑工程、机械工程、电力工程等。 概括的说，软件工程即用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及方法，其优点是以较小的代价开发高质量的软件并有效地维护它。,学习软件工程的现实意义,1 为参与软件开发提供理论基础和指导 2 将所学的计算机基础知识与市场需求联系起来 3 对整个软件业的发展趋势的把握 4 各种认证考试的必备知识,一、软件工程与其他学科的关系,1 、软件工程是计算学科 9 个领域之

2、一 算法和数据结构 计算机系统结构 人工智能和机器人学 数据库和信息检索 人一机交互 操作系统 程序设计语言 软件方法学和软件工程 数字和符号计算,计算学科中12个重复出现的基本概念,绑定 概念和形式模型 效率 抽象层次 按时间排序 安全性,大问题的复杂性 一致性和完备性 演化 按空间排序 重用 折衷与决策,软件工程是计算学科的分支，这 12 个概念同样将贯穿软件工程学科，是学科的精髓。,2 、 软件工程的8 个相关学科知识域,计算机工程 计算机科学 数学 管理学 项目管理 质量管理 系统工程学 软件人类工程学 其中：计算机科学、数学是基础工程学科、管理学科也非常重要,二、学习目标(1),掌握

3、软件工程的基础知识和理论，对软件工程学有一个全貌的了解； 熟悉软件项目开发和维护的一般过程； 熟练掌握软件需求分析、设计、编码和测试等阶段的主要思想和技术方法；,二、学习目标(2),通过学习，转变对软件开发的认识：从个人的单纯编程活动转移到进行系统分析与设计方面上来 转变思维定式： 程序员 系统工程师（系统分析员）,三、部分参考资料, 软件需求最佳实践SERU过程框架原理与应用 徐峰著，电子工业出版社， 2008 年 软件工程案例教程 软件项目开发实践 （第2版），韩万江等编著，机械工业出版社， 2013 年 软件工程 实践者的研究方法 原书第7版 ，郑人杰、马素霞等译，Roger S.Pre

4、ssman著，机械工业出版社，2013年 简单之美 软件开发实践者的思考倪健著，机械工业出版社，2010年,四、课程特点和学习的注意事项,1 、知易行难 要将理论知识与实践运用结合，进行对照，以加深理解和掌握。 2 、内容纷杂 软件工程涉及计算机科学、数学、工程科学和管理科学等多个领域。其中： 计算机科学和数学用于构造模型与算法； 工程科学用于制定规范、设计范型、评估成本及确定权衡 管理科学用于计划、资源、质量和成本的管理。,软件工程方法与实践(第2版),窦万峰 计算机科学与技术学院 南京师范大学,第一部分：软件工程基础,什么是软件工程？ 什么是工程化思想？ 什么是软件过程？有哪些过程模型？

5、如何选择与建立过程模型？ 什么是统一过程？ 什么是敏捷过程？有哪些模型？ 什么是软件工程实践？,第1章 软件工程概述（内容提要）,软件的本质 软件工程的基本概念 软件工程化思想 软件工程两大范型 软件工程思想与基本原理 软件工程基本活动,软件,software,soft+ware,软制品 (软体),软件包括程序、数据及其相关文档的完整集合。 三要素： 软件=程序+文档+数据,什么是软件？,1.1 关于软件,软件和软件工程,15,什么是程序,程序: 由程序设计语言所描述的、能为计算机所识别、理解和处理的语句序列 程序例子 Main( ) int i, j; / 变量定义 char Str10;

6、i = i + j ; / 语句说明 ,什么是文档？,文档: 记录软件开发活动和阶段性成果、理解软件所必需的阐述性资料 需求分析文档 软件设计文挡等 编写文档目的 促进对软件的开发,管理和维护； 便于各种人员(用户,设计、开发人员)的交流,软件需求规格说明书,软件特点,. 软件是一种逻辑实体，设计复杂，难以理解和维护,. 软件的生产与硬件不同，生产只需复制,. 在软件的运行和使用期间，没有硬件那样的机械 磨损，有老化问题,磨合调整,磨损用坏,修改点,实际曲线,理想曲线,. 软件的成本相当昂贵，软件的研制工作须要 投入大量的、复杂的、高强度脑力劳动，软件 开发成本、进度等难以估计,软件技术的发展

7、落后于需求,硬、软件成本比例的变化,年份,成本%,软件,硬件,什么是软件.,软件的特性： 复杂性：多种认为因素使得软件难以统一化难以理解、难以维护、难以对生产过程进行管理 一致性：软件依赖硬件，须与运行它的硬件保持一致 退化性 易变性：在生产过程中，甚至运行之后都可以改变 移植性 高成本：涉及大量的人力成本和管理成本,2020/8/14,软件的分类,1）按软件的功能进行划分,2020/8/14,支撑软件,2020/8/14,2）按软件的规模进行划分,微软的windows 2000项目就包含了近3000名工程师，他们被分成几百个小的团队,求伯君开发最初的 WPS,2020/8/14,3）按软件开

8、发划分,软件产品-指的是不局限于特定领域的、可以被广大用户直接使用的软件系统。如微软的 Windows，Office等。这类系统的特点是技术含量高，开发时要考到各种不同的用户需求；,软件项目-也称定制软件，是受某个特定客户（或少数客户）的委托， 这类软件的特点是领域知识所占的比重较大，相对技术而言工程性更强。例如，军用防空指挥系统、卫星控制系统等均为这类软件。,软件技术演化,第一阶段：程序设计阶段。1946年到60年代初，其主要特征是程序生产方式为个体手工方式。 第二阶段：程序系统阶段。60年代初到70年代初，软件工程学科诞生。软件的开发方式由个体生产发展到了小组生产，软件的开发与维护费用以惊

9、人的速度增加，维护困难，导致软件危机。例如：IBM360/370的开发 第三阶段：传统软件工程阶段。20世纪70年代中期至80年代中期，软件工程师把工程化的思想加入到软件的开发过程中，用工程化的原则、方法和标准来开发和维护软件。 第四阶段：面向对象阶段。20世纪80年代中期至今，面向对象的方法学受到了人们的重视，促进了软件业的飞速发展，软件产业在世界经济中已经占有举足轻重的地位。,发展趋势基于internet平台的软件,软件服务 多样性：中间件 开放性：新型中间件平台,1.2 关于软件工程软件危机,软件和软件工程,28,软件危机的表现(1 of 3),成本高 IBM 360 OS, 5000多

10、人年，耗时4年(19631966)，花费2亿多美元 美国空军：1955年软件占总费用(计算机系统)的18%，70年60%，85年达到85 美国全球军事指挥控制系统，硬件1亿美元，软件高达7.2亿美元 计算机软件和硬件费用比,软件和软件工程,29,软件危机的表现(2 of 3),软件质量得不到保证 软件应用面的扩大：科学计算、军事、航空航天、工业控制、企业管理、办公、家庭 软件越来越多的应用于安全犹关(safety critical)的系统，对软件质量提出更高的要求 80年代欧洲亚丽安娜火箭的发射失败，原因是软件错误 美国阿托拉斯火箭的发射失败，原因是软件故障 英国1986年开发的办公室信息系统

11、Folios经4年，因性能达不到要求，1989年取消 日本第5代机因为软件问题在投入50亿美元后于1993年下马 由于软件质量问题导致失败的软件项目非常多,软件和软件工程,30,软件危机的表现(3 of 3),进度难以控制 项目延期比比皆是 由于进度问题而取消的软件项目较常见 只有一小部分的项目能够按期完成 维护非常困难 软件维护的多样性 软件维护的复杂性 软件维护的副作用,如何开发软件？ 如何维护软件？,软件和软件工程,32,产生软件危机的根源,逻辑产品，不同于物理产品 复杂性高 逻辑产品，逻辑复杂性，远高于硬件复杂性 软件的复杂性随规模呈指数级上升 规模大 应用扩大，代码量，1000万行，

12、仍在不断膨胀 影响软件生产率和质量的因素比较复杂 人员的能力和水平 团队合作 缺乏有效、系统原理、原则、方法和工具的指导和辅助,软件和软件工程,33,对软件开发的深层次认识,开发一个具有一定规模和复杂性的软件系统与编写一个简单的程序不一样 正如搭猪窝和建设高楼大厦 大型、复杂软件系统的开发是一项工程，必须按照工程化的方法组织软件的生产和管理，必须经过分析、设计、实现、测试、维护等一系列软件过程和活动,软件和软件工程,34,解决危机的技术途径,软件危机20世纪60年代爆发，然而实际上软件危机随着计算机软件的产生而产生，只是在此之前其问题的严重性没有引起人们的关注和重视 提出有效的方法和工具支持软

13、件开发 1968年提出软件工程概念和思想 20世纪70年代的结构化软件开发方法 20世纪80年代的面向对象的软件开发方法 新的技术: 软件重用、快速原型、需求工程 典型技术: COM, Java, C+, J2EE, .Net, . 支撑工具和环境：Jbuilder, Visual Studio, WebLogic, ,软件和软件工程,35,技术手段不能完全解决软件危机,到了20世纪90年代，软件危机依然存在，甚至更为严重 应用技术的发展 瀑布模型 结构化软件开发方法 OO软件开发方法 应用变得越来越大和复杂，技术变得更加力不从心 错误的观念“只要有好的软件开发方法和工具就能高效率地开发出高质

14、量的软件”,软件和软件工程,36,解决危机的管理途径,问题出在哪里？ 20世纪80年代末，美国DoD和工业界开始认识到管理的重要性 美国DoD的一项研究表明，70%的项目由于管理不善导致难以控制进步、成本和质量； 进一步的研究发现：管理是影响软件项目成功开发的全局性因素，而技术只影响局部 如果软件开发组织不能对软件项目进行有效管理，就不能充分发挥软件开发方法和工具的潜力，也就不能高效率地开发出高质量的软件产品,软件危机解决途径,重视需求分析，明确与确切表达需求 重视与客户沟通与交流 统一的、公认的方法论和规范指导 重视设计和实现过程的资料 充分的检测工作,软件和软件工程,38,软件工程,软件危

15、机-根源-解决途径:软件工程 产生：1968年 NATO 计算机科学会议 软件工程是运用工程的、数学的、计算机等科学概念、方法和原理来指导软件开发和管理和维护的一门学科,软件工程定义,B.W.Boehm的定义：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必须的相关文件资料。 Fritz Bauer的定义：软件工程是为了经济地获得能够在实际机器上有效运行的可靠软件而建立和使用的一系列完善的工程化原则。 1983年美国IEEE软件工程标准术语的定义为：软件工程是开发、运行、维护和修复软件的系统方法，其中“软件”的定义为：计算机程序、方法、规则、相关的文档资料以及在计事机

16、上运行时所必需的数据。,软件工程三段论,软件开发,项目管理,过程改进,软件开发,开发过程是软件人员生产软件的过程，例如需求分析、设计、编码、测试等,相当于生产线上的生产过程。,软件项目管理,管理过程是项目管理者规划软件开发、控制软件开发的过程，相当于生产线上的管理过程，管理过程是伴随开发过程进行的过程。,软件项目管理路线图,软件过程改进,过程改进相当于对软件开发过程和软件管理过程的“工艺流程”进行管理和改进，如果没有好的工艺生产不出好的产品，它包括对开发过程和管理过程的定义和改进。,软件过程改进路线图,软件工程化思想,把软件看作是一个工程产品 两个方面： 软件开发技术：软件开发不同于一般的产品

17、开发，产品是逻辑的，需要的资源主要是人力资源，软件过程更多的是设计过程（没有制造过程） 软件工程管理：工程化思想主要体现在此 缺乏软件过程控制能力 能力成熟模型（Capability Maturity Model）：强调企业软件开发能力取决于企业的过程能力而不是个人能力,软件工程要达到的基本目标包括： 达到要求的软件功能； 取得较好的软件性能； 开发出高质量的软件； 付出较低的开发成本； 需要较低的维护费用； 能按时完成开发工作，及时交付使用。,为了达到上述目标，软件工程设计、工程支持以及工程管理在软件开发过程中必须遵循一些基本原则。,1.3 软件工程原理与原则 基本原理 逐层分解、逐步求精,

18、推迟实现原理 逐步求精原理：基于人类思维能力的局限性 分解与抽象原理 信息隐蔽原理 质量保证原理：预防而不是事后补救，全过程控制,2020/8/14,C(P1+P2)C(P1)+C(P2) E(P1+P2)E(P1)+E(P2),软件工程基本定理,软件工程基本原则,用分阶段的生存周期计划进行严格的管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 软件工程结果应能清楚地审查 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性,著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，提出了软件工程的七条基本原则：,B.Boehm指出，遵循前六条基

19、本原则，能够实现软件的工程化生产；按照第七条原则，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。,1.4 软件工程两大范型/模型,结构化开发范型 特征：结构化技术要么面向行为，要么面向数据 构成结构化开发范型的技术包括： 结构化分析 结构化设计 结构化编程 结构化测试 结构化维护,软件工程两大范型,面向对象范型 特征：将对象视作一个融合了数据及在其上操作的行为的、统一的软件组件。 技术包括： 面向对象分析 面向对象设计 面向对象编程 面向对象测试 面向对象维护 优势： 对象的概念符合业务或领域的客观实际 维护容易,重型与轻型软件工程,重型软件工程 文档齐全 规范化和程式化 周期长

20、推迟实现 轻型软件工程 非正式交流 重视代码 重视测试 响应需求变化,1.5 软件工程活动,沟通活动 计划活动：定义和描述软件工程工作，包括计划执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。如同定义一个旅行地图 建模活动：利用模型来更好的理解软件需求并进行设计，相当于工程设计图纸、模型 实现活动：编码、测试 部署活动：软件交付到用户，用户对其进行评测 维护活动 管理活动：如风险评估、技术评审、软件配置管理 过程改进活动,建模的目的和必要性,售楼处的模型。,1.1 什么是模型,售楼处的模型。,建模的目的和必要性,建模的目的和必要性,每一种模型可以在不同的精度级别上表示。 最好的模

21、型可以让你根据观察的角色及原因选择它的详细程度。,建模的目的和必要性,软件开发也是一个很复杂的工程，需要让客户和开发人员快速的、清楚的理解这个复杂工程，使他们在开发过程中更好的协作和沟通，提高工作效率。-建立模型 软件建模的目的是表示软件的体系和组成，方便软件设计人员理解和修改软件方案，确保软件设计和计划能正确地实现，保证系统不会因为修改而崩溃。,为什么软件建模,建模的目的和必要性,为什么一些专业人员要费心去创建模型呢？为什么他们不直接构建具体事物呢？答案在于复杂性和风险。 如果不先创建一项设计、一个蓝图或者另一个抽象表示，就直接构建某种复杂系统，在技术上是不明智的、在经济上也是行不通的。尽管

22、专业建筑师无需设计图就可以建造一间犬舍，但是如果他们不首先开发一批计划、图和某种可视化实物模型，那么就不能建造一幢15层的办公大楼。,建模的目的和必要性,小结,软件工程的是主旨以工程化的思想进行软件开发，以生产高质量和高效率的软件。 软件工程化思想的核心是，把软件看作是一个工程产品。 软件工程方法学分别是传统结构化范型和面向对象范型。 软件工程活动包括开发活动、管理活动和过程改进活动。,第2章 软件过程（内容提要）,什么是软件过程？ 什么软件生命周期？ 能力成熟度模型 敏捷过程 结对编程,2.1 软件过程,定义： 软件过程是为了开发出软件产品，或者是为了完成软件工程项目而需要完成的一系列活动的

23、集合 过程是可调整的，工作人员可以挑选合适的活动集合，目标通常是及时、高质量的交付软件灵活 通常使用生命周期模型简洁地描述软件过程 重要性 软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。,软件过程框架,定义： 框架定义了若干个框架活动，这些活动可广泛应用于所有软件开发项目 两个方面的内容 组织及管理框架 技术及工具框架 软件过程环境 组织、管理的角色和职责 技术环境,软件过程框架,组织与管理框架：过程改进活动及角色与职责 技术与工具框架：技术及自动化活动工具 框架活动： 沟通 策划 建模 构建 部署,软件生存周期过程（表2-1）,系统语境的过

24、程 协议过程组（2个过程，13个活动，52个任务） 项目过程组（7个过程，23个活动，72个任务） 技术过程组（11个过程，26个活动，64个任务） 组织上项目使能过程组（5个过程，15个活动，48个任务） 针对软件开发的过程 软件实现过程组（7个过程，7个活动，39个任务） 软件支持过程组（8个过程，25个活动，68个任务） 软件复用过程组（3个过程，14个活动，62个任务）,软件过程模型,把软件生命周期中各项开发活动的流程用一个合理的框架开发模型来规范描述，这就是软件过程模型,也称为软件生命周期模型。 软件过程模型是从一个特定的角度表现一个过程，一般使用直观的图形标识软件开发的过程，主要根

25、据软件的类型、规模，特别是软件的开发方法、开发环境等多种因素确立过程模型。,2.2 软件过程技术,产品与过程 选择软件过程 过程评估 CMMI/CMM ISO9001:2000 个人软件过程（PSP）：是一种可用于控制、管理和改进个人工作方式的自我持续改进过程，是一个包括软件开发表格、指南和规程的结构化框架。 团队软件过程(TSP)：帮助软件开发组织建立成熟和纪律性的工程实践，生产安全和可信的软件,个人软件过程（PSP）内容,PSP0是PSP的个人度量过程，其目的是建立个体过程基线。 PSP1是个人规划过程，引入了基于估计的计划方法PROBE，用自己的历史数据来预测新程序大小和开发时间，并使用

26、线性回归方法估计参数，确定置信区间以评价预测的可信程度。 PSP2是个人质量管理，根据程序的缺陷建立检测表，按照检测表进行设计复查和代码复查，以便及早发现缺陷，使修复缺陷的代价最小。 PSP3的目标是把个体开发小程序所能达到的生产效率和生产质量，延伸到大型程序。,团队软件过程(TSP),TSP 采用了循环递增的开发策略，整个软件生产过程由多个循环出现的开发周期组成，每个开发周期划分出若干个相对独立的阶段。 TSP 提供了如下方法： 计划评审 设计和编码标准 设计和代码评审方法 缺陷评审 质量分析,能力成熟度模型,CMM(Capability Maturity Model)是指“能力成熟度模型”

27、 CMM是由美国卡内基梅隆大学的软件工程研究所（SEI）开发的软件成熟度模型。 思想：管理软件过程的方法不当引起的问题，导致新软件技术的运用并不会自动提高软件的生产率和质量。 CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架。 能力成熟度模型集成（CMMI-Capability Maturity Model Integration）是CMM模型的最新版本。,CMM概述,为企业的发展规定过程成熟级别，分为5级（Version 1.0）： 初始级（Initial）：一般企业皆具有 可重复级（Rep

28、eatable）：成功经验可以重复 定义级（Defined）：一套完整的企业过程，人员自觉遵守（培训） 管理级（Managed）：过程&产品可度量和控制 优化级（Optimizing）：过程持续改进 从无序到有序、从特殊到一般、从定性管理到定量管理、最终达到动态优化,CMM概述（续）,2. Repeatable,1. Initial,3. Defined,4. Managed,Disciplined Process,Standard, Consistent Process,Predictable Process,Continuously Improving Process,Unpredicta

29、ble and poorly controlled,Can repeat previously mastered tasks,Process characterized, fairly well understood,Process measured and controlled,Focus on process improvement,5.Optimizing,Project Management,Integrated Engineering Process,Product and Process Quality,Managing Change,Disorder,Disciplined,Pr

30、edictable,Immature,Mature,CMM的概念模型,关键过程域KPA：代表一组相关的工作（活动）。每个KPA都有一个确定的目标，完成该目标即认为过程能力的提高。 一般特性CF（Common Features）：进一步细分KPA的工作。五个特性： 承诺（commitment） 准备（ability） 执行（activity） 度量分析（measurement & analysis） 验证（verifying implementation）,CMM的五个级别,Level 1：初始级 过程无序且不可见,CMM的五个级别,Level 2：可重复级 里程碑Milestone可见，按计划

31、开发,CMM的五个级别,Level 2的6个KPA：侧重于管理 需求管理（Requirements Management） 软件项目计划（Software Project Planning） 软件项目的跟踪和监控（Software Project Tacking and Oversight） 软件子合同管理（Software Subcontract Management） 软件质量保证（Software Quality Assurance） 软件配置管理（Software Configuration Management）,CMM的五个级别,Level 3：定义级 每个阶段的内部活动可见 标准

32、过程和项目定义过程裁剪,CMM的五个级别,Level 3的7个KPA：工程过程企业理念 机构过程关注（Organization Process Focus） 机构过程定义（Organization Process Definition） 培训计划（Training Program） 集成软件管理（Integrated Software Management）过程裁剪和定义 软件产品工程（Software Product Engineering）过程执行 组间协调（Intergroup Coordination） 对等审查（Peer Reviews）,CMM的五个级别,Level 4 管理级 过

33、程可度量，预测值与结果之间的偏差可控,CMM的五个级别,Level 4的2个KPA：预测量化管理 定量过程管理（Quantitative Process Management）过程度量 软件质量管理（Software Quality Management）产品度量,CMM的五个级别,Level 5 优化级 过程动态调整、新技术的采用,CMM的五个级别,Level 5的3个KPA：动态优化 缺陷预防（Defect Prevention） 技术改变管理（Technology Change Management） 过程改变管理（Process Change Management）,能力成熟度模型集成

34、,CMMI-Capability Maturity Model Integration是CMM模型的最新版本。 CMMI有两种表示方法： 和软件CMM一样的阶段式表现方法 连续式的表现方法 过程管理 项目管理 工程 支持 CMMI的目标是质量、时间表和最低的成本,关键实践,CMM结构,CMM标准的使用,软件过程的改进(SPI，Software Process Improvement) 软件过程评估(SPA，Software Process Assessment) 软件能力评价(SCE Software Capability Evaluation),2.4 敏捷过程,敏捷不是一个过程，是一类过程

35、的统称。 敏捷方法的两大主要特征： 强调“适应性”：对变化快速响应 对“人”的关注：人不再是可以替换的零件 做法： 快速响应:引入迭代式的开发手段 将整个软件生命周期分解为若干个小的迭代周期 获取切实有效的客户反馈 提出12条基本原则,敏捷开发12条原则,我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 围绕被激励起来的个体来构建项目，给他们提供所需的环

36、境和支持，并且信任他们能够完成工作。,敏捷开发12条原则(续),在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单是最根本的。 最好的构架、需求和设计出于自组织团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。,极限编程,极限编程（eXtreme Programming，XP）是一种软件工程方法学，是敏捷开发中最富有成效的方法学之一 由KentBeck在

37、1996年提出 具有强沟通、简化设计、迅速反馈等特点 适合于规模小、进度紧、需求不稳定、开发小项目的小团队。,极限编程,特点： XP模型是“轻量型”或“灵活”的软件过程模型 与面向对象语言结合的开发方案 “专家协作”的开发方式，解决难点问题 重视客户反馈 核心有四个要点(价值观)： 交流 简单 反馈 勇气,交流,开发人员与客户的交流 开发人员之间的交流 使用结对编程 开发人员与管理人员的交流,简单,设计的简单 编码的简单 注释的简单 测试的简单,反馈,客户对软件的反馈 测试代码对功能代码的反馈 先测试，后编程,勇气,开发人员有接受挑战性任务的勇气,XP 12个实践,1、完整团队 XP项目的所有

38、参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 2、计划游戏 计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 3、客户测试 作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。 4、简单设计 团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 5、结对编程 所有的产品软件都是由两个程

39、序员、并排坐在一起在同一台机器上构建的。 6、测试驱动开发 编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。,7、改进设计 随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。 8、持续集成 团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。 9、集体代码所有权 任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任

40、何其它方面的开发。 10、编码标准 系统中所有的代码看起来就好像是被单独一人编写的。 11、隐喻 将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。 12、可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。,XP 12个实践,XP的核心实践,9、集体代码所有权,在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。因此，即使可能有相应的比较详细的开发文档，但一个程序员却很

41、少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。 因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。 针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。 为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序,XP常见问题,XP适合于小型项目（10人左右）? 结对编

42、程，搭档如何安排? 实施结对编程、集体代码所有权之后，如何考核单个开发人员？,103,Pair Programming( 结对编程 ),结对编程,结对编程(Pair-Programming) 是XP中非常重要的实践之一。 定义：两个人坐在同一台计算机前面，使用相同的键盘和鼠标来开发同样的一个模块，一个称为驾驶者(Driver)，负责代码的键入，另外一个称为领航员(Navigator)，负责监看与决策，包括低级错误和方向性的错误。当出现的一个问题对其中一个人来说，难以解决，而恰好是另外一个人的强项的时候，那么角色就会发生转换。,Pair Programming的角色(Role),Driver T

43、he one who types Navigator The one who watches the back 角色可以互换的,疑问： 一个程序两个人写是不是一种浪费（可是两份工资，双倍资源哦）？ 编程从来是一个人的活动。学校里这么教的，一直以来也是做么做的。 我不喜欢被人盯着工作，这样我不自在，无法工作。 这个笨家伙老是问问题，他/她不会看书么？我都无法专心工作了。 另一方面： Pair Programming被很多的大师级程序员推崇； 不少大学都展开对Pair Programming的研究，并得到正面的结论； 很多尝试过的Developer都开始喜欢Pair Programming。 “三

44、个臭皮匠，胜过一个诸葛亮”,Pair Programming的疑问,Pair Programming和Solo Programming的比较,一些研究数据： 1999年，University of Uath.两组学生，一组独自工作，一组Pair Programming。,Pair Programming和Solo Programming的比较,虽然Pair Programming的学生在刚开始的阶段比独自工作的学生花在同样Task的时间较多，但很快Pair Programming的学生的时间开始大幅度的下降。而独立工作的学生需要花费比Pairs更多的时间来达到接近的代码质量。,Pair Pro

45、gramming和Solo Programming的比较,比较研究项目后的问卷调查发现： Pair Programming能用较少的时间生产更高质量的代码。 Pair Programming的学生们认为自己比一个人的时候更勤奋和更聪明的工作，因为不想让自己的partner失望。 Pair Programming的学生认为自己比一个人的时候更专注,紧凑和有纪律的工作，而且是持续的（因为来自Partner的Pair-Pressure）。而独立工作的学生也可以专注和紧凑的工作，但往往不持续。 Pair Programming的学生对自己的工作更有信心和成就感。 Pair Programming的学生

46、觉得工作很愉快，很愿意很partner一起工作。 在紧张时间安排和繁重的工作压力下，独自工作的学生很容易蜕变为没有纪律的Programmer。,成功的模式,1. 流模式（Flow）两个程序员共同从事一个有趣又有挑战性的问题。他们会有不同的技术、遇到不同的挑战，但是它们都善于找到好的解决方法。例如，其中 一个人可能是javascript专家，另一个人可能是强大的后台程序员。他们能够结合彼此的脑力、知识及经验来共同处理复杂的AJAX任务，从而创造出 最好的解决方案。 2. 指导模式（Coaching）老练的程序员在解决问题方面有经验和知识，可以与其他不能有效地独自解决问题的程序员分享。后来加入的程

47、序员有足够的理论基础来理解这些解决方法和程序的实现。他会在学习中慢慢进步，成为更优秀的程序员。,失败的模式,3. 浪费专家时间（Wasting expert time）问题太简单，以致专家的经验无指导意义。 4. 不知所措的新手（Overwhelmed novice）问题太过复杂或者需要太多新知识，使程序员学不到任何有用的东西。,有疑问的模式,5. 两个专家共事一个易管理的任务若两个程序员都了解如何实现任务并且之前都成功地解决过相似的问题，那么结对编程就没有太多的用处了。 6. 一个程序员处于流模式（Flow），另一个在一旁学习（Learning）若另一个程序员时不时地打断他，并要求对一些基本

48、的但与挑战性问题没有直接关系的事情做出解释，那么他很难专注于解决挑战性的问题。 7. 一个程序员处于流模式，另一个专注于指导（Coaching）如果想让这种模式获得成功，指导者应该思想开放，避免指导过多，同时也可以给另一个程序员想出自己的（甚至是更好的）解决方法的机会。,以人为本,Pair Programming的过程也是一个互相督促的过程。由于这种督促的压力，使得程序员更认真的工作。 每个人每天的有效工作时段不超过3-4个小时。 Pair Programming中Driver和Navigator的互换可以让程序员轮流工作，从而避免出现过度思考而导致观察力和判断力出现偏差。 潜意识的有利竞争。

49、当人在一个团队中工作，总是下意识的努力展现自己的优点。 工作及时得到同伴的肯定，自信心和成就感(Self-Satisfaction)增强。 觉得工作是一件愉快( Enjoyable )的事情。,结对建议,Extreme Programming对实施的程序员提出了更高的要求。这种要求不是技术水平，也不是学历水平也不是工作经验。这种要求是对一个人的心智，道德，修养的更高要求。 程序员的四怕： 1) 怕自己看上去傻 2) 怕被认为是没用的 3) 怕自己变的不重要（过时） 4) 怕自己不够好 Pair Programming中，编码不再是私人的工作，而是一种公开的“表演”。程序员的代码，工作方式，技术

50、水平都变得公开和透明。,XP开发人员素质,一个XP开发人员具备这样一些基本素质：诚实，公正，开明，勇敢和谦卑！在这些素质的基础之上，才是对技术水平，能力和天分等的要求。 诚实 公正 开明 勇气 谦卑 具备这些素质才能克服“四怕”，才能成为一个成熟和专业的Developer。,如何结对编程,Driver 写设计文档(Class diagram等)，进行编码(Unit Test and Business Object)等XP开发流程。 Navigator 审阅Driver的文档、Driver对编码等开发流程的执行；考虑Unit Test的覆盖程度；是否需要和如何Refactoring；帮助Driv

51、er解决具体的技术问题。 Driver和Navigator不断轮换角色，不要连续工作超过一小时，每一小时休息15分钟。Navigator要控制开发时间。 主动参与 虽然每个Engineering Task都有owner，但不能以旁观者的心态来做。任何一个Task都首先是两个人的责任，也是所有人的责任。没有“我的Code”、”你的Code”或“她的Code”，只有“我们的Code”。,如何结对编程,只有水平上的差距，没有级别上的差异。一个Pair,尽管可能大家的级别资历不同，但不管在分析，设计或编码，双方都拥有平等的决策权利。 Pairs之间互换Partner。每个Task都应该和不同的Deve

52、loper配对。 每隔一天，甚至是半天，互换Partners。但Task的owner因该继续留该Task的Pair中。 如果Pair中的一人请假，另一人应尽量不要写Production Code。 Pair一起加班,结对编程的误区,一、领航员误区1. 发号施令者喜欢发号施令的人总是对敲键盘的人说：“到末行，加个反括号，然后”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。事实上，他希望他自己来掌控键盘。所以当你碰到一个喜欢发号施令的人，那么将键盘交给他吧，转换领航员的角色。 2. 拼写纠错者拼写纠错者坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正的进行导航。和纠错者

53、商量一下，当他给你纠错的时候让他请你喝一杯咖啡（或者任何你想要的东西）。,3. 吹毛求疵者吹毛求疵者会指责你写的每行代码。当他的意见正确时，他会一意孤行，不用你已经写好的代码，而完全照着他的想法。 4. 默不作声者默不作声者是那些几乎不发表意见的人。他仅仅坐在那里看着你工作。试着问下他对你的方法有什么意见，或者问他下一步该写什么测试代码。 5. 心不在焉者心不在焉的人企图让你分心，而不是提供给你有建设性的意见，帮你解决问题。那么让他离开吧，比起一个让自己分心的人而言，不如一个人编程。,二、实施者误区1. 深藏不露者 深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码

54、。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。 领航员需要问问深藏不露者关于他的计划或想法。2. 目中无人的人 目中无人的人通常忽略领航员的所有建议，大多数是因为他们觉得自己的想法或编程技能更胜一筹。 当碰到一个目中无人的人时，立即停止结对编程吧，开始下一个任务吧。自大的人往往也不会是个好的领航员。他们很可能变成发号施令者或是吹毛求疵者。,3. 不知所措的人 不知所措的的人往往不习惯结对编程，非常紧张，不能掌控全局。 确保自己的领航员角色做到最好。小心的提出意见，对于不知所措的人主要给予鼓励。 但是，大多数程序员开始都是这种情况。所以，不要对他们的结对编程期望太高。让他们

55、首先成为一个领航员，或者让能够很好的处理人际交往问题的领航员在他们旁边。 4. 跳跃性很大的人 跳跃很大的人喜欢在代码中进行大范围的跳跃，这样领航员不知道进行到哪里了。 领航员需要让他慢下来，问他关于他的计划，并确保自己比他知道更多的快捷键。5. 不熟悉工具的人 不熟悉工具的人不知道开发环境的快捷键，效率非常低。 交换角色吧，让他看看你的技巧。,Pair Programming是个渐进的过程,有效率的Pair Programming不是一天就能做到的。 Pair Programming是一个相互学习，相互磨合的一个渐进过程。 Developers需要时间来适应这种新的开发模式。 刚开始的Pai

56、r Programming很可能不比Solo Programming有更高的效率。但适应后的Pairs的开发质量和开发时间都比Solo Programming有大幅度的改善。,124,没有结对编程就没有XP,这是引进XP时最难被接受的规则。但如果在采用其它XP的惯例和规则时，抛弃Pair Programming，那么会面对以下问题： 如何进行有效的Design Review 如何进行有效的Code Review 如何保证代码质量 如何保证流程的执行 如何增进Communication 如何进行Cross-Training 如何增强Teamwork,结对编程方法,面对面结对编程 分布式结对编程,

57、Distributed Pair Programming,分布式的Pair Programming: 两个Programmers身处不同的物理位置，通过Sharing 软件来实现Pair Programming。需要Sharing软件能提供 桌面共享，文字交谈，语音交谈，甚至是视频交流。 目前这种方法还没有被认可，主要出现在学校的关于XP的研究项目中. 面临的问题： Internet的网路延迟 工作时段的约定,结对编程,优势： 可以减少风险 可以使团队生产效率更高 是知识传播的最好途径 可以打造出最佳的合作团队。 可以生成更好的代码 三个方面的应用： 教育学结对学习 工业界结对开发与编程 分布

58、式结对编程环境,结对编程研究,教育学研究 结对编程学习效果研究 结对双方的相容性研究 结对编程过程研究 软件工业界 结对编程实践方式 社会动力学研究 个人编程能力的增强 分布式结对编程 结对编程开发环境研究 开发结对编程工具的需求 适合开展分布式结对编程的工具研究,结对编程与测试驱动开发,测试驱动开发（Test Driven Development,TDD） 思想：开发之前首先完成测试用例编写；然后编写代码和测试；测试通过后即需增加新功能。 优势： 测试优先，保证质量 结合结对编程,结对编程与代码重构,重构就是代码的重新设计。 目的： 得到好的代码和架构，易修改、易理解 适应需求 结对编程：

59、审查代码 理解代码 反馈,结对编程与简单设计,简单设计：达到目前需求即可 结对编程可以达到简单,软件工程实践,软件工程实践的精髓是理解问题、计划解决方案、实施计划和检查结果的精确度等方面 通用的框架活动包括： 沟通 计划 建模 部署 普适性活动,软件工程实践,核心原则： 存在价值 保持简洁 维护视图 生产者要让消费者理解 面向未来 计划复用 认真思考,软件工程实践,沟通实践：包括决定项目涉及人的信息和沟通需求 计划实践：是软件开发过程的准备阶段，包括定义问题、可行性分析、制定计划 模型实践：创建分析模型和设计模型,小结,软件工程是一种层次化技术，包括过程、技术和工具。 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 软件过程框架定义了若干个小的框架活动，为完整的软件开发过程建立了基础。软件过程框架的通用过程框架活动包括沟通、计划、建模、构建和部署。 能力成熟度模型（CMM）是改进软件过程的有效策略。它的基本思想是通过改进对软件过程的管理来提高软件生产率和软件质量。 敏捷方法是一组敏捷实践技术的总称，包括极限编程、自适应软件开发、动态系统开发和特征驱动开发