过程与改进考点整理_过程改进流程

过程与改进考点整理由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“过程改进流程”。

考点整理：

第一章 过程基础

休哈特（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 Proce，PSP）和团队软件过程（Team Software Proce，TSP），这两个过程理论在解决软件零缺陷方面取得了令人瞩目的成绩

质量运动

 Shewhart——20世纪30年代发表统计学质量控制原理

 Deming 1956, Juran 1956——进一步发展并成功证明Shewhart的原理  Crosby 1960——发展质量成熟度的量化

 Humphrey 1986——软件过程中采用Crosby的成熟度量化，加入成熟度等级的概念  SEI 1987-97——发展成熟度框架，成熟度问卷，SPA(软件过程评估)，SCE(软件能力评估)，CMM(能力成熟度模型

软件过程描述。。

第二章 PSP

 PSP基本度量项

 时间  缺陷  规模

时间日志

 PSP度量缺陷

 缺陷：任何会引起交付产物变化所必要的修改

 包括文档描述错误、拼写错误、语法错误、逻辑错误等

 PSP：缺陷类型标准，10个典型的缺陷类型【Humphrey, 2005】

缺陷日志

常用规模度量方式：

 代码行(LOC)：可以精确地度量软件产品的规模，也方便开发相应的规模统计工具，但是在项目初始阶段，很难直接估算出程序的代码行

 功能点(FP)：在项目早期容易识别，但是功能点的度量比较粗略且对于功能点的粒度缺乏一致的理解，不存在可以对功能点进行自动化统计的方法

PROBE(PROxy Based Estimation)PROBE估算流程

 PROBE估算方法主要用来估算待开发程序的规模和所需资源

 一个典型的PROBE流程包括概要设计、代理识别、估算并调整程序规模（时间）、计算预测区间等步骤

概要设计代理识别估算并调整程序规模估算并调整资源计算预测区间

计算预测区间  E代表代理规模，其中β0size和β1size是对已有的历史数据中代理规模估算值与程序规模实际值采用最小二乘法计算出来的系数

规模估算公式：

 对于n(n>=3)组历史数据，β0size和β1size的计算方法如下：

X 代理规模，Y 程序规模

在获得了调整后的估算结果之后，还需要对估算结果进行评价

计算预测区间

其中，t(p,df)表示自由度为df、概率为p的t分布，通常，p取70%，即估算的结果有70%的可能在该公式计算出来的范围中；自由度df取值为n-2 σ的计算公式如下

对历史数据的处理：三种方法比较

 简单方法

 计算简单，但不稳定，随着新数据的加入会造成相对大小矩阵数据的大幅度调整

 正态分布法

 相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵，但实际上程序规模的分布并不是正态的 对数正态分布法  更加符合人们对于程序规模的直观感觉，PSP中大部分情况下都使用对数正态分布法来对历史数据进行整理，进而获得相对大小矩阵；需要经常维护和更新相对大小矩阵

质量指标

 为了保证评审过程的质量，PSP定义了一系列过程质量的度量指标

 Yield  A/FR  PQI

 评审速度  DRL

 Yield指标用以度量每个阶段在消除缺陷方面的效率。

 Phase Yield = 100 *(某阶段发现的缺陷个数)/(某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数)

 Proce Yield = 100 *(第一次编译前发现的缺陷个数)/(第一次编译前注入的缺陷个数)

 Yield指标越高越好

 整个过程的Proce Yield，期望值在80以上  Yield是一种事后的质量控制手段

 无历史数据估算：

 将单元测试阶段的Phase Yield设定为50  资料表明：在测试中每发现一个缺陷，往往意味着还有一个缺陷没有被发现

调整缺陷数，将多的缺陷数按比例添加到注入缺陷当中去

质量指标 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(Proce 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)度量的是不同缺陷消除手段消除缺陷的效率

 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL

 打印后评审

 大量实践经验表明：将评审对象打印出来可以获得更好的评审效率

PSP设计模板

 操作规格模板（Operational Specification Template，简称OST） 功能规格模板（Functional Specification Template，简称FST） 状态规格模板（State Specification Template，简称SST） 逻辑规格模板（Logical Specification Template，简称LST）

 OST（操作规格模板）：描述系统与外界的交互情形  FST（功能规格模板）：描述系统对外的静态接口  SST（状态规格模板）：描述系统的状态信息  LST（逻辑规格模板）：描述系统的静态逻辑

UML是一种业界广泛认可和使用的描述软件系统设计的方式

 描述系统结构的图

 类图、组件图、复合结构图、部署图、对象图、包图

 描述系统行为的图

 活动图、状态机图、用例图、通信图、交互概览图、顺序图、定时图 UML与PSP设计模板的关系

 UML的用例图和顺序图提供了与PSP中OST同样的信息

 UML中的顺序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP4个设计模板中没有对应的内容

 UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容

 PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法

 UML中的状态机图与SST描述的状态图类似，但是SST中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的UML图示方法

第三章 TSP  团队工程开发中的实现策略，验证以及确认活动。

团队实现过程中，应该与设计策略保持一致  三个关注点：

 评审的考虑  复用策略

 可测试性考虑

 评审的考虑

 设计过程：自顶向下、逐层精化  实现过程：自底向上

 复用策略

 自底向上实现策略  代码注释的应用

 可测试性考虑

 实现阶段对于可测试性的考虑主要体现在实现的计划必须与测试计划一致，以避免进行集成测试的时候因部分模块没有实现带来不便

 验证(Verification)和确认(Validation)都是为了提升最终产品的质量而采取的措施  验证和确认的目的不同：

 验证的目的是确保选定的工作产品与事先指定给该工作产品的需求一致。 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中正常工作。

验证与确认活动、 环境准备  对象选择  活动实施  结果分析

WBS定义

 工作分解结构(Work Breakdown Structure，简称WBS)是以可交付成果为导向的对满足项目目标和开发交付产物的项目相关工作进行的分解。 WBS处于计划过程的中心，是控制项目范围以及制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义

WBS作用

       提供项目范围基线 可以展现项目整体观

提供一个整体架构，防止遗漏项目的可交付成果 明确各个角色的责任 提供具体的工作包定义

估算和编制项目日程计划的基础

帮助项目团队理解工作内容，分析项目的风险

WBS基本要求

 最底层要素不能重复，即任何一个工作包应该在WBS中的一个地方且只应该在WBS中的一个地方出现

 所有要素必须清晰、完整定义，即相应的数据词典必须完整定义

 最底层要素必须有定义清晰的责任人/团队，可以支持成本估算和进度安排  最底层的要素是实现目标的充分必要条件，即项目的工作范围得到完整体现

风险识别

 识别可能会给项目目标的实现带来负面影响的潜在问题，是成功进行风险管理的基础

 典型的识别方法：

 检查WBS的每个组件以找出相应的风险  使用定义好的风险分类表来评估风险  访谈相关的领域专家

 与类似项目进行比较来审查风险管理  检查以往项目的总结报告  检查设计规格和需求规格

风险应对

 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险  典型的策略包括：

 风险转嫁  风险解决  风险缓解

 风险转嫁

 通过某种安排，在放弃部分利益的同时，将部分项目风险转嫁到其他的团队或者组织（如：外包） 风险解决

 采取一些有效措施，使得风险的来源不再存在 风险缓解

 是指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响  一般情况下，对于风险暴露系数较高的风险，都应当制定相应的风险缓解计划

挣值分析

 项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法

 EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量

 PV: Planned Value, 计划价值  EV: Earned Value, 挣值  AC: Actual Cost，实际成本

 BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间

 成本差异CV = EV-AC，表示的是已经完成的工作与所消耗的成本的差异  成本差异指数CPI = EV/AC，表示单位成本创造的价值  日程偏差SV = EV – PV，表示进度偏差  日程偏差指数SPI = EV/PV  预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展以及成本消耗情况，整个项目完成的时候所需消耗的成本

--------要尽量回忆起来…

纠偏活动的管理

 偏差原因分析

 收集偏差相关的各种信息，例如质量相关的缺陷数据、估算参数的偏离、不能满足的承诺、风险的变更、数据的缺乏以及项目干系人的参与情况等  基于收集到的信息，开展充分的分析工作，找出偏差的根本原因

 纠偏措施定义

 有针对性地定义纠偏的措施

 项目小组应当决定并记录须采取的适当行动来解决已识别的问题

 典型措施：修改工作说明书、修改需求、修改估计值与计划、再协商承诺事项、增加资源、变更过程以及修订项目风险计划等

 所有的纠偏措施除了进行文档化，还需要与相关干系人一起审查这些措施，并取得相关干系人的承诺

 纠偏措施管理

 管理纠偏措施直到结项

 对纠偏措施的实施情况进行跟踪，需要项目小组监控纠偏措施直到完成纠偏  需要项目小组分析纠偏措施的结果，以决定纠偏措施的有效性  供项目小组学习，作为项目小组以后进行项目开发时的计划和风险管理的参考

项目总结的意义

 软件项目的特点决定了持续改善对于软件工程师的重要性  项目总结的目的和意义：

 提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等，给项目团队成员提供持续学习和改进的机会

项目总结过程

 项目总结需要系统化地、有条理地进行，以免遗漏重要的内容。因此，需要事先定义总结过程，然后按部就班地开展总结工作。 一般情况下，项目总结包括：

 准备阶段  总结阶段  报告阶段

典型TSP角色以及主要工作内容

 典型TSP团队包括多个角色，例如项目组长、计划经理、开发经理、质量经理、过程经理和支持经理等

人员角色评价阶段-项目组长

 项目组长的角色评价应当从领导力角度来考察团队的表现  重点关注团队受激励的水平和团队承诺履行方面的状况

 项目会议的组织情况也需要总结。比如，会议效果、讨论技巧等  还应当就如何在下一周期做得更好提出改进建议

人员角色评价-计划经理

 计划经理主要关注项目进度，因此，在总结阶段需要就估算、生产效率、里程碑等话题进行总结。例如：

 项目产品规模的估算值和实际值有多大的偏差？为什么有这些偏差？  项目的计划开发时间以实际开发时间有没有偏差？原因是什么？  项目整体的生产效率是多少？  人均资源水平有多少？

 项目的PV与EV趋势是什么？为什么有偏差？

 跟以前的开发周期相比，生产效率有没有提升？为什么？  下一个开发周期需要如何改进？

人员角色评价-开发经理

 开发经理进行总结的时候，应当从开发内容（例如需求、设计和实现等）和开发策略角度出发，总结得失。例如：

 将实际开发结果与计划开发内容进行对比，看看是否完全实现需求？  从开发策略角度考察，看看事先定义的开发策略是否有效？如何改进？

 开发经理也应当就质量话题提出见解。比如:  现有的设计和实现步骤是否有助于质量目标的实现？  对于可用性、性能以及兼容性等其他高层次质量要求，现有的设计方法和实现平台是否可以支持？

 现有的质量度量方式效果如何？未来怎样改进？

人员角色评价-质量经理

 质量经理的总结则应该从项目整体质量状况出发，总结质量目标的实现过程，并找出改进机会。因此，可以就如下一些问题开展讨论：

 项目整体质量状况如何？质量目标实现了吗？为什么？

 是否所有预定的质量管理活动都开展了？如果没有，为什么？  项目进展过程中，质量趋势是什么？

 每个阶段的Yield分别是什么？为什么有的过低？

 测试开始之后有多少缺陷？哪些缺陷可以通过什么样的方式在前期排除？  现有的质量管理手段的效果如何？有哪些需要改进？

人员角色评价-支持经理

 支持经理主要关注配置管理状况、问题和风险跟踪机制以及复用策略的支持等话题。因此，在项目总结阶段，支持经理需要总结的问题为：

 项目团队开发环境是否合用？

 项目过程中，对于配置项出现了几次变更？原因分别是什么？未来如何改进？

 配置管理活动开展情况如何？是否有未经授权的配置项修改现象出现？  风险和问题跟踪机制是否有效？是否所有问题都得到处理？  风险有没有导致对项目的负面影响？  哪些风险一开始没有被识别出来？  复用策略是否有效？

 对比上一阶段，复用比例是否上升？为什么？怎么改进？

人员角色评价-工程师

 由于大部分角色经理同时充当着软件工程师的角色，因此，还需要就工程师角色的工作状况进行总结。工程师重点关注的是个人的绩效（生产效率、质量水平等）。因此，需要总结的问题包括：

 个人计划的绩效与实际的绩效有没有差别？为什么有偏差？  对比上个周期有没有进步？为什么？  下个开发周期将如何改进？

 根据个人总结的PIP，你觉得最值得改进的有哪些内容？

CMM基本概念，以及基本用途

CMM的基本概念

 软件过程(software proce)：人们在开发和维护软件及其相关产品时

所涉及的各种活动、方法、实践和改革等。其中软件相关产品包括软件项目计划、设计文档、程序代码、测试用例和用户手册等。

 软件过程能力(software proce capability)：当遵循某个软件过程时所能达到的期望效果，它可以有效预测企业接收新的软件项目时可能得到的结果。

 软件过程效能(software proce performance)：当遵循某个软件过程时所达到的实际效果，它可以用于验证软件过程能力。

 软件过程成熟度(software proce maturity)：指一个特定的软件过程被明确定义、管理、度量、控制以及有效的程度。

成熟度可以用于指示企业加强其软件过程能力的潜力

 CMM的主要用途

(1)用于软件过程评估(SPA, Software Proce Aement)：在评估中，一组经过培训的软件专业人员确定出一个企业软件过程的状况，找出该企业所面对的与软件过程有关的、最急需解决的所有问题，以便取得企业领导层对软件过程改进的支持。

(2)用于软件过程改进(SPI, Software Proce Improvement)：帮助软件企业对其软件过程向更好的方向的改变，进行计划、制定以及实施(3)用于软件能力评价(SCE, Software Capability Evaluation)：在能力评价中，一组经过培训的专业人员鉴别出软件承包者的能力资格；检查和监察正用于软件开发的软件过程的状况。

 软件工程过程组(Software Engineering Proce Group, SEPG)是一个由专家组成的小组，他们推进组织所采用的软件过程的定义、维护和改进工作。在关键实践中，这个组织通常指“负责组织的软件过程活动的小组”。

CMM 五个级别

初始级—》可重复级—》已定义级—》已管理级—》优化级

 成熟度的行为刻画-第1级

 初始级：

 成功来源于个人英雄主义而非机构行为，因此它不可重复  更换人员后成功便难以维持

 初始级组织一般不提供开发和维护软件的稳定环境

 成熟度的行为刻画-第2级  可重复级：

 过程已经建立，项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的(1)建立过程－－机构已建立管理软件项目的策略和实现这

些策略的过程

(2)经验利用－－新项目的计划和管理基于类似项目的经验 (3)具体项目－－通过建立基本的过程管理纪律来提高过程

能力

(4)项目执行－－经过定义的、文档化的、曾经实施过的、人员经培训的、可测量的、强制的以及可改进的有效过程



可重复级：

(5)项目跟踪－－项目的软件负责人随时跟踪软件成本、进

度和项目实现

(6)问题确定－－在实现约定的过程中，一旦出现问题就能

很快确定

(7)基线完整－－对软件需求和实现需求而开发的工作产品

建立了基线，并近控制其完整性

(8)遵循标准－－项目的软件标准均已确定，并且机构保证

能准确地遵循这些标准

(9)分承制方－－如果软件有分承制方，软件项目与分承制

方要建立一种有效的的客户－供应商关系

 成熟度的行为刻画-第3级

 已定义级：

 机构标准软件过程－－有一个机构范围内标准的软件过程，软件工程活动和管理活动被集成为一个有机的整体。标准化的目的是使高层管理者和软件技术人员能够有效合作

 SEPG组－－有一个小组例如软件工程组（SEPG）专门负责订立机构的标准软件过程，并且在机构中制定培训计划来确保相关人员和管理者有足够的知识和技能完成标准过程所赋予的角色

 已定义级：

 项目标准软件过程－－标准的软件过程结合具体项目的特点经过裁剪即形成项目定义软件过程，它是一组集成的完善定义的软件工程和管理过程。

 过程内容－－一个完善定义的软件过程应包括就绪准则、输入、工作过程、验证机制、输出和完成准则。

 跟踪和控制－－对于已建立的产品生产线，其成本、时间表和实现功能均可跟踪和控制，软件产品的质量可以得到保证。

 已定义级：

 共同理解－－软件过程能力的实现主要基于在机构范围内对一个定义软件过程的活动、角色和责任的共同理解。

 主要特征－－在于软件过程已被提升成标准化过程，从而更加具有稳定性、重复性和可控性。

 已管理级：  主要特征是定量化、可预测、异常控制和高质量  1.软件的过程和产品有定量的质量指标

 2.软件项目的产品和生产过程的控制具有可预测性

 成熟度的行为刻画-第5级

 优化级：

 主要特征是新技术的采用和软件过程的改进被作为日常的业务活动来加以计划和管理

 1.机构集中于持续的过程改进

 2.改进的途径

 对已有过程的渐进式改进

 有选择地使用新技术和新方法所带来的革新

 优化级：

 在优化级，整个组织集中精力进行不断的过程改进。为了预防缺陷出现，组织有办法识别出弱点并预先针对性地加强过程。 利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息，使持续过程改进成为可能。

各级别特征。。：总结

 CMM各级的主要特征

 初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇。

 可重复级：已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。 已定义级：用于管理和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。

 已管理级：软件过程和产品质量均有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。

 优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续性地对过程进行改进。

 关键过程域(KPAs, Key Proce Areas) 每个成熟度等级被分解成几个关键过程域，指明为了改进其软件过程组织应关注的区域。关键过程域识别出为了达到基本成熟度等级所必须着手解决的问题。

 每个关键过程域识别出一串相关活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标。

 KPAs  CMM 2:可重复级(Repeatable)

 需求管理：requirement management  软件项目计划：software project planning  软件项目跟踪和监控：software project tracking oversight  软件子合同管理：software subcontract management  软件质量保证：software quality aurance  软件配置管理：software configuration management  CMM 3:已定义级(Defined)

 组织过程焦点：organization proce focus  组织过程定义：organization proce definition  培训大纲：training program  集成软件管理：integratedsoftware management  软件产品工程：software product engineering  组间协调：intergroup coordination  同行评审：peer review  CMM 4:已管理级(Managed)

 定量管理过程：quantitative proce management  软件质量管理：software quality management  CMM 5:优化级(Optimizing)

 缺陷预防：defect prevention  技术改革管理：technology change management  过程更改管理：proce change management