软件过程管理 Ch.9 软件过程的评估和改进

软件过程的评估和改进 软件过程改进不是目标，而是一条漫漫长路。如果你不知道身在何处, 任何地图都与事无补。 －瓦特·汉弗莱（Watt Humphrey）

本章提纲 9.1 过程模型的剪裁 9.2 软件过程度量 9.3 过程评估参考模型 9.4 过程评估 9.5 过程改进的模型和方法 9.6 组织和技术革新 9.7 软件过程改进的实施

9.1 过程模型的剪裁 9.1.1 软件开发组织的类型 9.1.2 CMMI表示方法 9.1.3 模型剪裁的用途 9.1.4 连续式表示模型的剪裁

9.1.1 软件开发组织的类型 组织独立承担某项新产品的全程开发和维护，开发过程不受外部因素影响。 组织完成所开发的软件产品的主体部分，但要将次要部分交给第三者完成或集成第三方的软件产品。 组织缺乏独立完成软件产品开发的能力，从软件承包商接受软件产品开发的子项目，接受指导下完成项目。

9.1.2 CMMI表示方法

9.1.3 模型剪裁的用途 对过程模型的剪裁，其基本用途不外乎为两类： 将剪裁模型用于内部过程改进。 将剪裁模型用于建立评估基线。 有的组织将剪裁模型用于两者，既用于过程改进，也用于建立评估基线。

9.1.4 连续式表示模型的剪裁 模型的剪裁应侧重于那些支持核心业务目标的过程域和实践。 作为基础的过程域和实践\应该要保留下来，不能舍弃。 过程改进是一种自主行为，所以过程改进的模型剪裁基本可以由组织自行确定，相对灵活。 一个组织或项目，从单个过程域或有限的几个过程域实施评估和改进，可以获得过程能力的提高，虽然其提高的程度要低于全面实施整个模型的结果,因为我们知道，各个过程域之间是相辅相成的。 从执行评估的角度看，模型剪裁的程度将直接影响评估结果的可比较程度，所以，一般要求使用相对稳定的几个剪裁版本。

9.2 软件过程度量 9.2.1 过程度量的内容 9.2.2 过程度量的流程 9.2.3 过程度量的方法 9.2.4 过程度量技术 9.2.5 过程能力度量 9.2.6 软件过程生产率的度量

9.2.1 过程度量的内容 软件过程能力度量 软件过程性能的度量 需求管理和需求开发能力；技术解决能力、因果分析能力和决策分析能力；项目计划能力、项目监督和控制能力、合同管理能力和集成化项目管理能力；质量管理能力、配置管理能力和风险管理能力；组织级过程定义能力、组织级培训能力、组织级改革能力和产品集成能力。 软件过程性能的度量

过程效率和质量度量的结合 好 差 高 —— 低 工作量（测试效率） 结果（缺陷发现） 效率好/缺陷高 （较好）2 效率好/缺陷低 高 —— 低 好 差 效率好/缺陷高 （较好）2 效率好/缺陷低 （最好）1 效率低/缺陷低 （不确定）3 效率低/缺陷高 （最差）4

9.2.2 过程度量的流程

9.2.3 过程度量的方法 建立软件开发过程度量的基线，然后将获得的实际测量值与基线进行比较分析，例如获得度量值的平均值和分布情况，平均值反映了组织的整体水平或程度，而分布情况反映了组织的过程能力和执行的稳定性

9.2.4 过程度量技术 2．基准技术 1．分析性技术: 量化证据以确定什么地方需要改进和改进工作是否成功 对比实验研究。 模拟实验研究。 过程定义评审。 正交缺陷分类。 根本原因分析。 统计过程控制。 个体软件过程。 2．基准技术

9.2.5 过程能力度量 Cp = σ/ P k = (M1 - M2) / (σ/2) Cpk ＝ (1-k) x Cp 过程能力的度量，3个参数： Cp指数—— 过程变更程度指数。 K指数—— 过程均值和制定值的吻合程度。 Cpk指数—— 过程能力的综合指数。 Cp = σ/ P k = (M1 - M2) / (σ/2) Cpk ＝ (1-k) x Cp Cpk<1 过程没有达到执行能力的最低标准。 Cpk =1 过程恰好达到最低要求。 Cpk >1 过程超过了预定的最低标准。

Cp值 vs.σ值、k值 vs. 准确性 Cp  概率 K 值范围 准确性 1.00 1.33 1.50 1.67 1.83 2.00 3.0 4.0 4.5 5.0 5.5 6.0 99.73 99.9937 99.9999943 99.9999998 k≤0.125 0.125<k≤0.250 0.250<k≤0.500 0.500<k≤0.750 k>0.750 优秀 良好 一般 较差 很差

9.2.6 软件过程生产率的度量 在现有人员的能力和历史数据分析基础之上，来测量人员的生产力水平，包括软件开发过程整体生产率（成本核算模型）、软件编程效率和软件测试效率等,例如每人日代码行、每人月功能点、每人年类数或每个类平均人天数等。

9.3 过程评估参考模型 9.3.1 ISO/IEC 15504评估模型 9.3.2 Bootstrap评估模型 9.3.3 Trillium评估模型 9.3.4 CMM/CMMI的评估体系

9.3.1 ISO/IEC 15504评估模型

ISO/IEC 15504评估模型（2）

15504评估方法 过程尺度，最基础的可度量的过程目标，也可用于标识过程成功与否的预期结果。 过程能力尺度，是具有一系列过程属性、对任何过程的适用性、管理过程和提高过程能力时所必需的可度量特征。 能力确定模式，帮助评估并确定一个潜在软件供应商的能力。 过程改进模式，帮助提高软件开发过程的水平。 自我评估模式，帮助判断是否有能力承接新项目的开发。

15504评估等级 级别 （详见表9-2） 第0级，不完善的过程 第1级，已实施的过程 第2级，已管理的（已计划和已跟踪的）过程 第3级，已建立的过程 第4级，可预测的过程 第5级，优化的过程

9.3.2 Bootstrap评估模型 它是过程改进的先决条件，用以判断软件过程的当前实施情况并且对改进的方法加以约束。 Bootstrap方法是欧洲共同体项目(ESPRIT项目5441)产生的结果 Bootstrap过程体系由过程分类、过程领域、过程和最佳实践组成。过程域由出多个过程类别组成，涵盖组织、方法和技术等3个领域,每个过程最终分解为活动和基本实践。 也分为两个层次——组织和项目 采用CMM的5个成熟度等级作为自己的能力等级，但是它们之间存在一些差异

9.3.3 Trillium评估模型 Trillium模型是由电信公司联盟基于CMM1.1版本、考虑了电信业的特殊需求而开发的，其目标是提供指导持续改进计划的方法，呈现大量的工业实践以帮助改进现有的软件过程和生命周期，即作为在竞争性商业环境中改进组织能力的指南 依照行业内最佳实践，建立组织的产品开发和支持进程能力的基准。 作为自我评估模型，帮助软件组织在产品开发过程中识别改进的机会。 在合同的谈判阶段，帮助选择供应商。

Trillium评估模型的等级和结构 没有系统化。 可重复和面向项目的。 已定义的和面向过程的。 已管理和一体化的。 合成整体

9.3.4 CMM/CMMI的评估体系 1．基于CMM的内部过程改进评估 2．基于CMM的软件能力评估 3．SCAMPI评估方法 4．组织过程的预评估

9.4 过程评估 9.4.1 软件过程评估的目标和期望 9.4.2 软件过程评估的内容和范围 9.4.3 软件过程评估的方式和类型 9.4.4 软件过程评估的方法

9.4.1 评估的目标和期望 能充分和各个层面、各个方面的人员沟通，获得全面的、第一手数据，确保可靠的、准确的评估结果。 软件过程评估的目的是对当前组织内部所运行的软件过程能力和性能等状态进行准确的、客观的描述，试图发现当前过程实施的特点，标识出其中的强项与弱项，使将来发挥强项、克服弱项，更好地控制过程、改进过程，避免在质量、成本以及进度方面出现重大的问题。 能充分和各个层面、各个方面的人员沟通，获得全面的、第一手数据，确保可靠的、准确的评估结果。 评估的结果被应用于过程改进，或有助于第3方组织对本组织的认可。

评估输入和输出 输入 输出 评估发起方、被评估组织单位及其之间的关系。 过程评估的背景、目的。 评估参考模型范围以及模型对应的表示。 评估约束、评估小组构成和收集的任何附加信息。 输出 评估最终报告：每个被评估过程域的强项和弱项的文字陈述； 对相应评估对象的定级描述。 是否达到评估输出的决定，可能要求附加的定级输出来作为评估的结果。 基于评估结果，采取行动的建议或过程改进活动计

9.4.2 评估的内容和范围 软件需求获取、分析、开发、变更控制和管理等能力 项目计划能力 项目监督和控制能力 合同管理能力 软件度量能力 软件质量保证和管理流程、手段和方法等 技术开发、革新，产品的定义、设计、实现 产品集成，项目集成管理 配置管理、维护 风险识别、控制和管理 原因分析、决策、问题解决的能力 组织变革，改进过程，建立组织商业目标 组织培训的计划和实施能力

9.4.3 评估的方式和类型 评估方式 评估类型 自我评估是指由软件开发组织内部进行的评估，主要是由成员个人进行的评估行为。 第三方评估,也称为能力检测。 综合方式。 评估类型 A类评估。全面综合的评估方法，要求全面覆盖评估中所使用的模型。 B类评估。评估范围缩小，集中于需要关注的过程域。 C类评估，也称为快估。主要是检查特定的风险域，找出过程中的问题所在。

CMMI 3种评估类型的对比 特征 A类 B类 C类 用途模式 优点 缺点 评估发起人 评估组组成 评估组规模 评估组资格 对评估组长的要求 全面综合的评估方法。 组织的成熟度等级的评定。 自我评估。 范围小，集中于关注的过程域。 快估。 检查特定的风险域 优点 覆盖全面、结果客观，能整体把握组织过程能力和清楚过程中的优势和弱势，评定等级。 发现过程问题并启动组织的过程改进，提高过程洞察力，风险小。 投入小、反馈及时、见效快。 缺点 投入大、资源需求很多、风险大。 严格性和规范性低、不够全面，不能评定等级。 深度和广度都不够，结果可信度低。 评估发起人 组织的最高管理层。 过程改进组织或质量管理部门。 任何组织内部的经理。 评估组组成 内部和外部人员。 内部或外部人员。 评估组规模 4 ～ 10人＋评估组长。 2 ～ 6人＋评估组长。 1 ～ 3人＋评估组长。 评估组资格 有经验。 有适当经验。 对评估组长的要求 主评估师。 主评估师或受过专业过程评估培训的人员。 有过程评估经验的人员

9.4.4 软件过程评估的方法 1．评估方法准则 2．选择评估时机 3．评估步骤 4．软件过程评估注意的要点

9.5 过程改进的模型和方法 9.5.1质量改进范例 9.5.2 过程改进的 IDEAL模型 9.5.3 过程改进的 Raytheon方法 9.5.4 过程改进的 6 Sigma方法

9.5.1质量改进范例

9.5.2 过程改进的IDEAL模型

IDEAL模型的两维结构 启动阶段 诊断阶段 建立阶段 行动阶段 学习阶段 管理软件过程改进程序 战略层 沟通、约定和影响 战术层

9.5.3 过程改进的Raytheon方法

9.5.4 过程改进的6 Sigma方法 DMAIC 定义(Define)测量(Measure)分析(Analyze)改进(Improve)控制(Control) 阶段 活动要点 常用工具和技术 定义 项目启动、确定CTQ。 QFD，FMEA 流程图，亲和图。 头脑风暴法，树图 排列图，CT 分解 测量 测量输出、确定项目基线。 运行图，分层法 FMEA，散布图，直方图 测量系统分析，过程能力分析 水平对比法，抽样计划 分析 确定关键影响因素。 散布图，因果图 多变量图 假设检验，回归分析 方差分析，抽样计划 改进 设计并验证改进方案。 FMEA，试验设计 田口方法 响应面法，过程仿真 过程能力分析 控制 保持成果。 控制计划，SPC控制图 标准操作SOP 防错方法，目标管理

DMADV方法 表9-8 “DMADV”和“PIDOV”的比较

9.6 组织和技术革新 1．组织和技术革新的理念和原则 2．组织和技术革新的计划 3．先导性试验的重要性 4．组织和技术革新所需要的环境和支持 5．组织和技术革新的工具 6．概念培训和专题培训 7．组织和技术革新的实施步骤 8．技术革新关联的全过程活动 表9-9 技术革新管理的全过程活动

9.7 软件过程改进的实施 9.7.1 过程改进的原则和策略 9.7.2 过程改进的组织支持 9.7.3 过程改进计划 9.7.4 过程改进的具体实施步骤 9.7.5 软件过程改进的自动化实现

9.7.1过程改进的原则和策略 组织过程改进实施的原则可以概括为以下8点。 软件过程改进的组织应设定切实可行的目标。 过程改进是一个持续进行的活动，而不是一次性的活动。 软件过程改进需要得到组织管理层足够的支持。 软件过程改进不只是单个组织单元)的事，而应包括软件开发过程涉及的所有团队和成员。 过程改进活动应被视为一个一个的项目，从而获得必要的预算和资源。 坚持适当的监控机制。 过程改进的成功与否取决于过程实施效果。 对改进活动的过程进行监控，鼓励创新，及时获得反馈，及时进行纠正或调整。

过程改进的策略 1．自顶向下与自底向上相结合 2．循序渐进、持续改进 3．文化变革先行 4．内外结合，以内为主 5． 切合实际、区别对待 6． 充分利用管理工具

9.7.2 过程改进的组织支持 管理指导委员会（MSC） 软件工程过程组（SEPG） 软件质量保证组（Software Quality Assurance Group，SQAG） 软件配置管理组（Software Configuration Management Group，SCMG） 技术工作组（TWG）和过程行动组（PAG）

9.7.3 过程改进计划 除了设定软件改进目标之外，还应包括SPI的领域、方法和策略等，并综合下列因素： 基础设施能够满足需求，及时提供资源。 对过程改进工作的方向、范围和进度提供建议。 如何识别SPI程序推进过程中的障碍和风险。 如何维持SPI程序实施的可视性。 如何鼓励信息共享或提供信息共享的方便快捷的渠道。 如何抓住和保存过程改进中的经验、教训，并改善计划本身

9.7.4 过程改进的具体实施步骤 过程改进组织的建立 确定目标 评估状态 制定计划 制定规范 过程试点 实施监控 反馈修正 过程改进成果推广

9.7.5 软件过程改进的自动化实现 TOSSP软件过程系统的内容和层次结构

作业 第9章 1、2、4