过程与改进考点整理.docx

考点整理：第一章过程基础休哈特(Shewhart)(sqc之父)20世纪20年代是AT&T Bell实验室的一名统计员，被认为是质量改进的奠基人， 现代过程改进都建立在Shewhart所提出的过程控制概念的基础上贡献a)最早提出“计划-执行-检査(Plan-Do-See)"的概念，后来戴明进一步将其发展为PDCA【计划(Plan)、实施(Do)、检査(Check)、行动(Action)】戴明(Deming)将一系列统计学方法引入美国产业界，以检测和改进多种生产模式，从而为后来 杰克•韦尔奇等人的六个西格马管理法奠定了基础质量运动的主要人物之一，• PDCA 循环 PDCA- Plan, Do, Check, Action・十四点原则朱兰(Juran)♦《质量控制手册》(Quality Control Handbook)被称为当今世界质量 控制科学的“圣经”为奠定全面质量管理(TQM)的理论基础和基本方法做出了 卓越的贡献♦ 1) 适用性质量♦ 2) 质量三步曲♦ 3) Juran 质量螺旋(Quality Loop)♦ 4) 80/20 原则克劳士比(Crosby)Crosby提出了“零缺陷”的概念，即第一次就把事情做对/ 1)质量管理的绝对性/ 2)质量改进的基本要素6C/ 6C “变革管理的六个阶段”/①领悟(comprehension) 理解质量真谛/②承诺(commitment) 制定质量策略的决心/③能力(capability) 教育与培训/④沟通(communication) 成功的经验文档化、制 度化/⑤改正(correction) 预防与提高绩效/⑥坚持(continuance) 强调质量管理成为一种工作方式Watts Humphrey软件质量之父、CMM之父♦ 提出CMM理论,在IBM工作27年,负责管理产品研发,1986年从IBM辞 职 加入SEI,受美国国防部委托，提出了软件能力成熟度模型（CMM）♦ 将TQM（Total Quality Management全面质量管理）的思想运用到软件过程改进中， 并根据软件的特殊性提出适合软件开发的成熟度模型,是传统行业质量管理思想的 深入运用♦ 力推个体软件过程（Personal Software Process, PSP）和团队软件过程（Team Software Process，TSP）,这两个过程理论在解决软件零缺陷方面取得了令人瞩目的成绩质量运动♦ Shewhart——20 世纪 30 年代发表统计学质量控制原理♦ Deming 1956, Juran 1956 进一步发展并成功证明Shewhart的原理♦ Crosby 1960——发展质量成熟度的量化♦ Humphrey 1986 软件过程中采用Crosby的成熟度量化，加入成熟度等级的概念♦ SEI 1987-97一一发展成熟度框架，成熟度问卷，SPA（软件过程评估），SCE（软件能力 评估），CMM（能力成熟度模型软件过程描述。

第二章 PSP♦ PSP 基本度量项♦ 时间♦ 缺陷♦ 规模时间日志日志内容注释该条记录的序号；所属阶段该条记录所属的P5P阶段，如策划、设计、编 码、编译、单元测试、总结等;开始时间该条记录的刑台时间，米誡到分^? 时1可该条记录的结束时间，米斓到分饰中断时间该条记录的计时过程中，需要中断的时间，精 确到分钟，典型的中断如等；净时间结束时间-开始时间冲断时间，用L怎帚个 阶段任务眇肛作时间；1备注信息如果有中断事件，往往需要在备注信息中简单 记录，用以帮助i歸者了解时间谕肖耗的原因；♦ PSP度量缺陷/缺陷：任何会引起交付产物变化所必要的修改/包括文档描述错误、拼写错误、语法错误、逻辑错误等/ PSP：缺陷类型标准，10个典型的缺陷类型【Humphrey, 2005】缺陷类型#i£1Documentation注释、扌星示信息等2Synta^拼写错误、指令格式错误等3Build7 Package组件版本、调用库方面的错误4Assignment申明、变量影响氾围等方面的错误1 §Interfa 匚 e调用接口错误6匚 hecking岀错信息、未充分检验等错误7Data数据结构、内容错误8Function速h错误、指针、循环、计算、递 归等方面的错误9System配置、计时、内存方面的错误| WEnvironment设计、编译、测试或者其他支持系 统的错误缺陷日志日志内容注释序号该条记录的序号发现日期该缺陷被发现的日期注入阶段经过分析，确定该缺陷被引入的阶段，典型引入阶 段如设计、编码、编译、单元测试等消除阶段该缺陷被消除的阶段，在引入阶段之后消除时间为了修正该缺陷所消耗的时间关联缺陷如果缺陷的引入阶段是编译或者单元测试等通常用 以消除缺陷的这些阶段，那么往往意味着，该缺陷是 在消除另外的一个缺陷时被引入因此，需要建1 种关联关系简要描述对于缺陷严生根楚賈邂描述常用规模度量方式：/ 代码行(LOC):可以精确地度量软件产品的规模，也方便开发相应的规模统计工具，但是在项目初始阶段，很难直接估算出程序的代码行/功能点(FP):在项目早期容易识别，但是功能点的度量比较粗略且对于功能点的粒度缺乏一致的理解，不存在可以对功能点进行自动化统计的方法PROBE(PROxy Based Estimation)PROBE 估算流程♦ PROBE估算方法主要用来估算待开发程序的规模和所需资源♦ 一个典型的PROBE流程包括概要设计、代理识别、估算并调整程序规模(时间)、/ E代表代理规模，其中B0.和是对已有的历史数据中代理规模估算值0size 1size与程序规模实际值采用最小二乘法计算出来的系数规模估算公式：Plan SizeBo size+ Pl size(E)计算预测区间其中，t(p,df)表示自由度为df、概率为p的t分布，通常，p取70%，即估算的结果有70% 的可能在该公式计算出来的范围中；自由度df取值为n-2。

的计算公式如下对历史数据的处理：三种方法比较♦简单方法/计算简单，但不稳定，随着新数据的加入会造成相对大小矩阵数据的大幅度 调整♦ 正态分布法/相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对 大小矩阵，但实际上程序规模的分布并不是正态的♦ 对数正态分布法/更加符合人们对于程序规模的直观感觉，PSP中大部分情况下都使用对数正 态分布法来对历史数据进行整理，进而获得相对大小矩阵；需要经常维护和 更新相对大小矩阵质量指标♦为了保证评审过程的质量，PSP定义了一系列过程质量的度量指标YieldA/FRPQI评审速度DRL♦ Yield指标用以度量每个阶段在消除缺陷方面的效率/ Phase Yield = 100 * （某阶段发现的缺陷个数）/（某阶段注入的缺陷个数+进入 该阶段前遗留的缺陷个数）/ Process Yield = 100 * （第一次编译前发现的缺陷个数）/（第一次编译前注入的缺陷个数）阶段名称注入缺陷 数消除缺陷 数遗留缺陷 数PhaseYield1跖十100100跖十评审06460片编码1621810编码评审09950II编译05455.6单元测试150100♦ Yield 指标越高越好♦ 整个过程的Process Yield，期望值在80以上♦ Yield 是一种事后的质量控制手段♦ 无历史数据估算：/将单元测试阶段的Phase Yield设定为50/资料表明：在测试中每发现一个缺陷，往往意味着还有一个缺陷没有被发现阶段名称注入缺陷数消除缺翩遗留缺陷数Phase Yie100100爲十评审064601621810编码评审09950编译05455.6单元测试150100[ 调整缺陷数，将多的缺陷数按比例添加到注入缺陷当中去1*阶段名称调整后注入 缺陷数调整后肖除 缺翩调整宕遗留 缺陷数|phase Yield 估算值IL设计11.85011850设讯平审065.8550.5编码19222„858编砂平审0913.8541编译058.8538.9单币则试1.155550质量扌旨标 A/FR appraisal of failure ratio♦质检失效比♦质量成本(Cost Of Quality, COQ)：用来量化质量问题所带来的成本消耗♦ COQ的三个主要组成部分：/失效成本：分析失效现象，査找原因、做必要的修改所消耗的成本/质检成本：评价软件产品，确定其质量状况所消耗的成本/预防成本：识别缺陷根本原因、采取措施预防其再次发生所消耗的成本A/FR = PSP质检成本/PSP失效成本♦ PSP中定义的失效成本为编译时间和单元测试时间之和♦ PSP中定义的质检成本为设计评审时间与代码评审时间之和♦当A/FR小于2.0时，测试阶段发现的缺陷数目较多♦当A/FR大于或者等于2.0时，测试阶段发现的缺陷数目较少♦理论上，A/FR的值越大，往往意味着越咼的质量♦过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降♦作为指南，在PSP中A/FR的期望值为2.0♦为了确保较高的质量水平，软件工程师应当花费两倍于编译加测试的时间进行评审 工作，评审的对象为设计和代码♦ PQI (Process Quality Index)：过程质量指标 /用以度量PSP过程的整体质量 / PQI用来全面刻画软件过程质量 /它是5个过程质量指标的乘积• 设计质量•设计评审质量•代码质量•代码评审质量•程序质量具体要求：/设计质量：设计时间应该大于编码的时间/设计评审质量：设计评审时间应该大于设计时间的50%/代码评审质量：代码评审时间应该大于编码时间的50%/代码质量：代码的编译缺陷密度应当小于10个/千行/程序质量：代码的单元测试缺陷密度应当小于5个/千行♦通过适当处理，将5个指标定义成0.0-1.0之间的某个数值，PQI为这5个数值的乘 积，其范围也是从 0.0-1.0♦ PQI 超过 0.4，组件质量往往比较高评审速度（Review Rate）是一个用以指导软件工程师开展有效评审的指标♦高质量的评审需要软件工程师投入足够的时间进行评审♦大量统计数据表明，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小 时缺陷消除效率比（Defect-Removal Leverage）度量的是不同缺陷消除手段消除缺陷的效率♦其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其 他阶段每小时发现缺陷数与该测试阶段每小时发现的。