过程与改进考点整理

1、考点整理：第一章 过程基础休哈特（Shewhart）（sqc之父）20世纪20年代是AT&T Bell实验室的一名统计员，被认为是质量改进的奠基人，现代过程改进都建立在Shewhart所提出的过程控制概念的基础上。 贡献a) 最早提出“计划-执行-检查（Plan-Do-See）”的概念 ，后来戴明进一步将其发展为PDCA【计划(Plan)、实施(Do)、检查(Check)、行动(Action) 】。戴明（Deming）将一系列统计学方法引入美国产业界，以检测和改进多种生产模式，从而为后来杰克·韦尔奇等人的六个西格马管理法奠定了基础。质量运动的主要人物之一， PDCA循环 PD

2、CA- Plan, Do, Check, Action 十四点原则朱兰(Juran)w 质量控制手册（Quality Control Handbook）被称为当今世界质量控制科学的“圣经”，为奠定全面质量管理（TQM）的理论基础和基本方法做出了卓越的贡献。w 1) 适用性质量w 2) 质量三步曲w 3) Juran质量螺旋（Quality Loop）w 4) 80/20原则 克劳士比(Crosby)Crosby提出了“零缺陷”的概念，即第一次就把事情做对ü 1) 质量管理的绝对性ü 2) 质量改进的基本要素 6Cü 6C “变革管理的六个阶段”：ü 领悟

3、（comprehension）理解质量真谛ü 承诺（commitment）制定质量策略的决心ü 能力（capability）教育与培训ü 沟通（communication）成功的经验文档化、制 度 化ü 改正（correction）预防与提高绩效ü 坚持（continuance）强调质量管理成为一种工作方式Watts Humphrey 软件质量之父、CMM之父w 提出CMM理论，在IBM工作27年，负责管理产品研发，1986年从IBM辞 职加入SEI，受美国国防部委托，提出了软件能力成熟度模型(CMM)w 将TQM（Total Quality

4、Management，全面质量管理）的思想运用到软件过程改进中，并根据软件的特殊性提出适合软件开发的成熟度模型，是传统行业质量管理思想的深入运用w 力推个体软件过程（Personal Software Process，PSP）和团队软件过程（Team Software Process，TSP），这两个过程理论在解决软件零缺陷方面取得了令人瞩目的成绩 质量运动w Shewhart20世纪30年代发表统计学质量控制原理w Deming 1956, Juran 1956进一步发展并成功证明Shewhart的原理w Crosby 1960发展质量成熟度的量化w Humphrey 1986软件过程中采用

5、Crosby的成熟度量化，加入成熟度等级的概念w SEI 1987-97发展成熟度框架，成熟度问卷，SPA(软件过程评估)，SCE(软件能力评估)，CMM(能力成熟度模型软件过程描述。第二章 PSPw PSP基本度量项w 时间w 缺陷w 规模 时间日志w PSP度量缺陷ü 缺陷：任何会引起交付产物变化所必要的修改ü 包括文档描述错误、拼写错误、语法错误、逻辑错误等ü PSP：缺陷类型标准，10个典型的缺陷类型【Humphrey, 2005】缺陷日志常用规模度量方式：ü 代码行(LOC)：可以精确地度量软件产品的规模，也方便开发相应的规模统计工具，但是在项

6、目初始阶段，很难直接估算出程序的代码行ü 功能点(FP)：在项目早期容易识别，但是功能点的度量比较粗略且对于功能点的粒度缺乏一致的理解，不存在可以对功能点进行自动化统计的方法PROBE(PROxy Based Estimation)PROBE估算流程w PROBE估算方法主要用来估算待开发程序的规模和所需资源w 一个典型的PROBE流程包括概要设计、代理识别、估算并调整程序规模（时间）、计算预测区间等步骤ü E代表代理规模，其中0size和1size是对已有的历史数据中代理规模估算值与程序规模实际值采用最小二乘法计算出来的系数规模估算公式：ü 对于n(n>=

7、3)组历史数据， 0size和1size的计算方法如下： X 代理规模， Y 程序规模在获得了调整后的估算结果之后，还需要对估算结果进行评价计算预测区间其中，t(p,df)表示自由度为df、概率为p的t分布，通常，p取70%，即估算的结果有70%的可能在该公式计算出来的范围中；自由度df取值为n-2的计算公式如下对历史数据的处理：三种方法比较w 简单方法ü 计算简单，但不稳定，随着新数据的加入会造成相对大小矩阵数据的大幅度调整w 正态分布法ü 相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵，但实际上程序规模的分布并不是正态的w 对数正态分布法&#

8、252; 更加符合人们对于程序规模的直观感觉，PSP中大部分情况下都使用对数正态分布法来对历史数据进行整理，进而获得相对大小矩阵；需要经常维护和更新相对大小矩阵质量指标w 为了保证评审过程的质量，PSP定义了一系列过程质量的度量指标ü Yieldü A/FRü PQIü 评审速度ü DRLw Yield指标用以度量每个阶段在消除缺陷方面的效率。ü Phase Yield = 100 * (某阶段发现的缺陷个数)/(某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数)ü Process Yield = 100 * (第一次编译前

9、发现的缺陷个数)/(第一次编译前注入的缺陷个数)w Yield指标越高越好w 整个过程的Process Yield，期望值在80以上w Yield是一种事后的质量控制手段w 无历史数据估算：ü 将单元测试阶段的Phase Yield设定为50ü 资料表明：在测试中每发现一个缺陷，往往意味着还有一个缺陷没有被发现调整缺陷数，将多的缺陷数按比例添加到注入缺陷当中去质量指标 A/FR appraisal of failure ratiow 质检失效比w 质量成本(Cost Of Quality, COQ)：用来量化质量问题所带来的成本消耗w COQ的三个主要组成部分：ü

10、 失效成本：分析失效现象，查找原因、做必要的修改所消耗的成本ü 质检成本：评价软件产品，确定其质量状况所消耗的成本ü 预防成本：识别缺陷根本原因、采取措施预防其再次发生所消耗的成本A/FR = PSP质检成本/PSP失效成本w PSP中定义的失效成本为编译时间和单元测试时间之和w PSP中定义的质检成本为设计评审时间与代码评审时间之和w 当A/FR小于2.0时，测试阶段发现的缺陷数目较多w 当A/FR大于或者等于2.0时，测试阶段发现的缺陷数目较少w 理论上，A/FR的值越大，往往意味着越高的质量w 过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降w 作为指

11、南，在PSP中A/FR的期望值为2.0w 为了确保较高的质量水平，软件工程师应当花费两倍于编译加测试的时间进行评审工作，评审的对象为设计和代码w PQI (Process Quality Index)：过程质量指标ü 用以度量PSP过程的整体质量 ü PQI用来全面刻画软件过程质量ü 它是5个过程质量指标的乘积 设计质量 设计评审质量 代码质量 代码评审质量 程序质量具体要求：ü 设计质量：设计时间应该大于编码的时间ü 设计评审质量：设计评审时间应该大于设计时间的50%ü 代码评审质量：代码评审时间应该大于编码时间的50%ü

12、 代码质量：代码的编译缺陷密度应当小于10个/千行ü 程序质量：代码的单元测试缺陷密度应当小于5个/千行w 通过适当处理，将5个指标定义成之间的某个数值，PQI为这5个数值的乘积，其范围也是从w PQI超过0.4，组件质量往往比较高评审速度(Review Rate)是一个用以指导软件工程师开展有效评审的指标w 高质量的评审需要软件工程师投入足够的时间进行评审w 大量统计数据表明，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时缺陷消除效率比(Defect-Removal Leverage) 度量的是不同缺陷消除手段消除缺陷的效率w 其计算方式是以某个测试阶段（

13、一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRLw 打印后评审ü 大量实践经验表明：将评审对象打印出来可以获得更好的评审效率PSP设计模板w 操作规格模板（Operational Specification Template， 简称OST）w 功能规格模板（Functional Specification Template， 简称FST）w 状态规格模板（State Specification Template，简称SST）w 逻辑规格模板（Logical Specification Template，简称LST）w OS

14、T（操作规格模板）：描述系统与外界的交互情形w FST（功能规格模板）：描述系统对外的静态接口w SST（状态规格模板）：描述系统的状态信息w LST（逻辑规格模板）：描述系统的静态逻辑UML是一种业界广泛认可和使用的描述软件系统设计的方式w 描述系统结构的图ü 类图、组件图、复合结构图、部署图、对象图、包图w 描述系统行为的图ü 活动图、状态机图、用例图、通信图、交互概览图、顺序图、定时图UML与PSP设计模板的关系w UML的用例图和顺序图提供了与PSP中OST同样的信息w UML中的顺序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP4个设计模板中没有对应的

15、内容w UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容w PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法w UML中的状态机图与SST描述的状态图类似，但是SST中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的UML图示方法第三章 TSPw 团队工程开发中的实现策略，验证以及确认活动。团队实现过程中，应该与设计策略保持一致w 三个关注点：ü 评审的考虑ü 复用策略ü 可测试性考虑w 评审的考虑ü 设计过程：自顶向下、逐层精化ü 实现过程：自底向上w 复用策略ü

16、; 自底向上实现策略ü 代码注释的应用w 可测试性考虑ü 实现阶段对于可测试性的考虑主要体现在实现的计划必须与测试计划一致，以避免进行集成测试的时候因部分模块没有实现带来不便w 验证(Verification)和确认(Validation)都是为了提升最终产品的质量而采取的措施w 验证和确认的目的不同：ü 验证的目的是确保选定的工作产品与事先指定给该工作产品的需求一致。ü 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中正常工作。验证与确认活动、w 环境准备w 对象选择w 活动实施w 结果分析WBS定义ü 工作

17、分解结构(Work Breakdown Structure，简称WBS)是以可交付成果为导向的对满足项目目标和开发交付产物的项目相关工作进行的分解。ü WBS处于计划过程的中心，是控制项目范围以及制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义WBS作用ü 提供项目范围基线ü 可以展现项目整体观ü 提供一个整体架构，防止遗漏项目的可交付成果ü 明确各个角色的责任ü 提供具体的工作包定义ü 估算和编制项目日程计划的基础ü 帮助

18、项目团队理解工作内容，分析项目的风险WBS基本要求w 最底层要素不能重复，即任何一个工作包应该在WBS中的一个地方且只应该在WBS中的一个地方出现w 所有要素必须清晰、完整定义，即相应的数据词典必须完整定义w 最底层要素必须有定义清晰的责任人/团队，可以支持成本估算和进度安排w 最底层的要素是实现目标的充分必要条件，即项目的工作范围得到完整体现风险识别w 识别可能会给项目目标的实现带来负面影响的潜在问题，是成功进行风险管理的基础w 典型的识别方法：ü 检查WBS的每个组件以找出相应的风险ü 使用定义好的风险分类表来评估风险ü 访谈相关的领域专家ü 与类似

19、项目进行比较来审查风险管理ü 检查以往项目的总结报告ü 检查设计规格和需求规格风险应对w 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险w 典型的策略包括：ü 风险转嫁ü 风险解决ü 风险缓解w 风险转嫁ü 通过某种安排，在放弃部分利益的同时，将部分项目风险转嫁到其他的团队或者组织（如：外包）w 风险解决ü 采取一些有效措施，使得风险的来源不再存在w 风险缓解ü 是指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响ü 一般情况下，对于风险暴露系数较高的风险，都应当

20、制定相应的风险缓解计划挣值分析w 项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法w EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量w PV: Planned Value, 计划价值w EV: Earned Value, 挣值w AC: Actual Cost，实际成本w BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间w 成本差异CV = EV-AC，表示的是已经完成的工作与所消耗的成本的差异w 成本差异指数CPI = EV/AC，表示单位成本创造的价值w 日程偏差SV =

21、EV PV，表示进度偏差w 日程偏差指数SPI = EV/PVw 预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展以及成本消耗情况，整个项目完成的时候所需消耗的成本-要尽量回忆起来纠偏活动的管理w 偏差原因分析ü 收集偏差相关的各种信息，例如质量相关的缺陷数据、估算参数的偏离、不能满足的承诺、风险的变更、数据的缺乏以及项目干系人的参与情况等ü 基于收集到的信息，开展充分的分析工作，找出偏差的根本原因w 纠偏措施定义ü 有针对性地定义纠偏的措施ü 项目小组应当决定并记录须采取的适当行动来解决已识别的问题&#

22、252; 典型措施：修改工作说明书、修改需求、修改估计值与计划、再协商承诺事项、增加资源、变更过程以及修订项目风险计划等ü 所有的纠偏措施除了进行文档化，还需要与相关干系人一起审查这些措施，并取得相关干系人的承诺w 纠偏措施管理ü 管理纠偏措施直到结项ü 对纠偏措施的实施情况进行跟踪，需要项目小组监控纠偏措施直到完成纠偏ü 需要项目小组分析纠偏措施的结果，以决定纠偏措施的有效性ü 供项目小组学习，作为项目小组以后进行项目开发时的计划和风险管理的参考项目总结的意义w 软件项目的特点决定了持续改善对于软件工程师的重要性w 项目总结的目的和意义：w

23、提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等，给项目团队成员提供持续学习和改进的机会项目总结过程w 项目总结需要系统化地、有条理地进行，以免遗漏重要的内容。因此，需要事先定义总结过程，然后按部就班地开展总结工作。w 一般情况下，项目总结包括：ü 准备阶段ü 总结阶段ü 报告阶段典型TSP角色以及主要工作内容w 典型TSP团队包括多个角色，例如项目组长、计划经理、开发经理、质量经理、过程经理和支持经理等人员角色评价阶段-项目组长w 项目组长的角色评价应当从领导力角度来考察团队的表现w 重点关注团队受激励的水平和团队承诺履行方

24、面的状况w 项目会议的组织情况也需要总结。比如，会议效果、讨论技巧等w 还应当就如何在下一周期做得更好提出改进建议人员角色评价-计划经理w 计划经理主要关注项目进度，因此，在总结阶段需要就估算、生产效率、里程碑等话题进行总结。例如：ü 项目产品规模的估算值和实际值有多大的偏差？为什么有这些偏差？ü 项目的计划开发时间以实际开发时间有没有偏差？原因是什么？ü 项目整体的生产效率是多少？ü 人均资源水平有多少？ü 项目的PV与EV趋势是什么？为什么有偏差？ü 跟以前的开发周期相比，生产效率有没有提升？为什么？ü 下一个开发周期需

25、要如何改进？人员角色评价-开发经理w 开发经理进行总结的时候，应当从开发内容（例如需求、设计和实现等）和开发策略角度出发，总结得失。例如：ü 将实际开发结果与计划开发内容进行对比，看看是否完全实现需求？ü 从开发策略角度考察，看看事先定义的开发策略是否有效？如何改进？w 开发经理也应当就质量话题提出见解。比如:ü 现有的设计和实现步骤是否有助于质量目标的实现？ü 对于可用性、性能以及兼容性等其他高层次质量要求，现有的设计方法和实现平台是否可以支持？ü 现有的质量度量方式效果如何？未来怎样改进？人员角色评价-质量经理w 质量经理的总结则应该从项目

26、整体质量状况出发，总结质量目标的实现过程，并找出改进机会。因此，可以就如下一些问题开展讨论：ü 项目整体质量状况如何？质量目标实现了吗？为什么？ü 是否所有预定的质量管理活动都开展了？如果没有，为什么？ü 项目进展过程中，质量趋势是什么？ü 每个阶段的Yield分别是什么？为什么有的过低？ü 测试开始之后有多少缺陷？哪些缺陷可以通过什么样的方式在前期排除？ü 现有的质量管理手段的效果如何？有哪些需要改进？人员角色评价-支持经理w 支持经理主要关注配置管理状况、问题和风险跟踪机制以及复用策略的支持等话题。因此，在项目总结阶段，支持经理需

27、要总结的问题为：ü 项目团队开发环境是否合用？ü 项目过程中，对于配置项出现了几次变更？原因分别是什么？未来如何改进？ü 配置管理活动开展情况如何？是否有未经授权的配置项修改现象出现？ü 风险和问题跟踪机制是否有效？是否所有问题都得到处理？ü 风险有没有导致对项目的负面影响？ü 哪些风险一开始没有被识别出来？ü 复用策略是否有效？ü 对比上一阶段，复用比例是否上升？为什么？怎么改进？人员角色评价-工程师w 由于大部分角色经理同时充当着软件工程师的角色，因此，还需要就工程师角色的工作状况进行总结。工程师重点关注的是个

28、人的绩效（生产效率、质量水平等）。因此，需要总结的问题包括：ü 个人计划的绩效与实际的绩效有没有差别？为什么有偏差？ü 对比上个周期有没有进步？为什么？ü 下个开发周期将如何改进？ü 根据个人总结的PIP，你觉得最值得改进的有哪些内容？CMM基本概念，以及基本用途CMM的基本概念w 软件过程(software process)：人们在开发和维护软件及其相关产品时 所涉及的各种活动、方法、实践和改革等。其中软件相关产品包括软件项目计划、 设计文档、程序代码、测试用例和用户手册等。w 软件过程能力(software process capability)：当

29、遵循某个软件过程时所能达到的期望效果，它可以有效预测企业接收新的软件项目时可能得到的结果。w 软件过程效能(software process performance)：当遵循某个软件过程时所达到的实际效果，它可以用于验证软件过程能力。w 软件过程成熟度(software process maturity)：指一个特定的软件过程被明确定义、管理、度量、控制以及有效的程度。成熟度可以用于指示企业加强其软件过程能力的潜力w CMM的主要用途ü (1) 用于软件过程评估(SPA, Software Process Assessment)：在评估中，一组经过培训的软件专业人员确定出一个企业软件

30、过程的状况，找出该企业所面对的与软件过程有关的、最急需解决的所有问题，以便取得企业领导层对软件过程改进的支持。(2) 用于软件过程改进(SPI, Software Process Improvement)：帮助软件企业对其软件过程向更好的方向的改变，进行计划、制定以及实施(3) 用于软件能力评价(SCE, Software Capability Evaluation)：在能力评价中，一组经过培训的专业人员鉴别出软件承包者的能力资格；检查和监察正用于软件开发的软件过程的状况。w 软件工程过程组(Software Engineering Process Group, SEPG)是一个由专家组成的小

31、组，他们推进组织所采用的软件过程的定义、维护和改进工作。在关键实践中，这个组织通常指“负责组织的软件过程活动的小组”。CMM 五个级别初始级可重复级已定义级已管理级优化级w 成熟度的行为刻画-第1级ü 初始级： 成功来源于个人英雄主义而非机构行为，因此它不可重复 更换人员后成功便难以维持 初始级组织一般不提供开发和维护软件的稳定环境w 成熟度的行为刻画-第2级ü 可重复级： 过程已经建立，项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的w (1) 建立过程机构已建立管理软件项目的策略和实现这些策略的过程w (2) 经验利用新项目的计划和管理

32、基于类似项目的经验w (3) 具体项目通过建立基本的过程管理纪律来提高过程能力w (4) 项目执行经过定义的、文档化的、曾经实施过的、人员经培训的、可测量的、强制的以及可改进的有效过程ü 可重复级：w (5) 项目跟踪项目的软件负责人随时跟踪软件成本、进度和项目实现w (6) 问题确定在实现约定的过程中，一旦出现问题就能很快确定w (7) 基线完整对软件需求和实现需求而开发的工作产品建立了基线，并近控制其完整性w (8) 遵循标准项目的软件标准均已确定，并且机构保证能准确地遵循这些标准w (9) 分承制方如果软件有分承制方，软件项目与分承制方要建立一种有效的的客户供应商关系w 成熟度

33、的行为刻画-第3级ü 已定义级： 机构标准软件过程有一个机构范围内标准的软件过程，软件工程活动和管理活动被集成为一个有机的整体。标准化的目的是使高层管理者和软件技术人员能够有效合作 SEPG组有一个小组例如软件工程组（SEPG）专门负责订立机构的标准软件过程，并且在机构中制定培训计划来确保相关人员和管理者有足够的知识和技能完成标准过程所赋予的角色ü 已定义级： 项目标准软件过程标准的软件过程结合具体项目的特点经过裁剪即形成项目定义软件过程，它是一组集成的完善定义的软件工程和管理过程。 过程内容一个完善定义的软件过程应包括就绪准则、输入、工作过程、验证机制、输出和完成准则。

34、跟踪和控制对于已建立的产品生产线，其成本、时间表和实现功能均可跟踪和控制，软件产品的质量可以得到保证。 ü 已定义级： 共同理解软件过程能力的实现主要基于在机构范围内对一个定义软件过程的活动、角色和责任的共同理解。 主要特征在于软件过程已被提升成标准化过程，从而更加具有稳定性、重复性和可控性。ü 已管理级： 主要特征是定量化、可预测、异常控制和高质量 1. 软件的过程和产品有定量的质量指标 2. 软件项目的产品和生产过程的控制具有可预测性 w 成熟度的行为刻画-第5级ü 优化级： 主要特征是新技术的采用和软件过程的改进被作为日常的业务活动来加以计划和管理 1. 机构集中于持续的过程改进 2. 改进的途径w 对已有过程的渐进式改进w 有选择地使用新技术和新方法所带来的革新ü 优化级： 在优化级，整个组织集中精力进行不断的过程改进。为了预防缺陷出现，组织有办法识别出弱点并预先针对性地加强过程。 利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息，使持续过程改进成为可能。各级别特征。：总结w CMM各级的主要特征ü 初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极