ipd-cmm 3.0 快速参考手册 - pudn.comread.pudn.com/downloads155/ebook/688936/ipd-cmm.pdf ·...

IPD-CMM 3.0 快速参考手册

仅供内部使用

中研运作及质量管理部

华为技术有限公司

版权所有侵权必究

IPD-CMM 3.0 快速参考手册 Ver: 1.0

特别鸣谢

本快速参考手册的最初版本由原商业网络质量部编制完成

在此特别鸣谢原商业网络质量部对质量体系所做出的贡献

IPD-CMM 3.0 快速参考手册 Ver: 1.0

前言

为了帮助项目相关人员更好地理解IPD-CMM 3.0 规范体系依据IPD-CMM 3.0 流程文件

结合我们推行CMM的体会和在过程中遇到一些典型问题我们使用问与答的方式在这个手册

中对IPD-CMM 3.0 流程体系中的关键活动进行描述和解答目的是帮助项目经理和项目相关人

员在较短的时间内全面系统地理解IPD-CMM 3.0 使它在我们的产品开发项目管理质量

保证过程中更好发挥作用

对每个条目我们都力争阐述清楚以下的内容

� 是什么

� 为什么

What

Why

� 什么人在什么时间如何做 HowWhenWho

� 必要时给出进一步的索引读者可以据此在IPD-CMM 3.0 流程规范或其他文献

中找到更详尽的信息或说明

在条目组织上我们对内容进行了分类通用类包括项目管理配置管理软件度量风

险管理等这些活动将贯彻整个项目执行过程中另外按通用的V模型分阶段描述各阶段的关

键活动这样你可以方便地找到你当前感兴趣的条目进行参考

看了这本手册你会发现实施IPD-CMM 3.0 原来是如此行之有效而且轻松简单自己的

职业化水平在不知不觉中已经迈入了新的境界

欢迎结合实践给我们提出改进意见以便我们共同进步

中研运作及质量管理部

目录

28什么是文档生产率它有什么参考价值 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27IPD-CMM 定义收集哪些度量数据各自代表什么含义 . . . . . . . . . . . . . . . . . .

26为什么要实施软件度量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26软件度量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26项目组如何标识和管理风险 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25为什么要进行风险管理项目风险有哪些属性 . . . . . . . . . . . . . . . . . . . . . . . .25风险管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24配置管理如何管理代码 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23配置管理如何管理文档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22配置库备份要注意哪些原则 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22CCB是什么组织变更控制过程是如何操作的 . . . . . . . . . . . . . . . . . . . . . . . .22什么是配置状态发布 CMO如何进行配置状态发布 . . . . . . . . . . . . . . . . . . . .

20配置库目录与项目文件夹目录结构的关系是怎样的 . . . . . . . . . . . . . . . . . . . . .20CMO如何建立配置库 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19为什么要制定配置项命名规范如何制定配置项命名规范 . . . . . . . . . . . . . . . .18配置管理计划的作用是什么如何写作配置管理计划 . . . . . . . . . . . . . . . . . . .18配置管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17如何控制和处理开发阶段的重叠 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15什么是项目文件夹如何使用项目文件夹有效管理项目 . . . . . . . . . . . . . . . . . .

15IPD-CMM 3.0中定义了哪些项目报告分别在什么场合使用 . . . . . . . . . . . . . .12IPD-CMM 3.0中定义了哪些项目会议 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8批准签发是什么寓意批准签发是怎样进行的 . . . . . . . . . . . . . . . .7项目组与QA如何密切配合保证过程质量和产品质量 . . . . . . . . . . . . . . . . . .6项目管理要注意哪些要点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6项目管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6什么是MINI Project 培训 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5实施IPD-CMM流程有哪些特殊角色他们的职责和义务是哪些 . . . . . . . . . . . .4IPD-CMM和SW-CMM是什么对应关系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1CMM的基本框架是怎样的 CMM保证质量的基本原理是什么 . . . . . . . . . . . .

1CMM 概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1第一部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ver: 1.0IPD-CMM 3.0快速参考手册

内部使用第i页

48MC在HLD阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47CMO在HLD阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47如何控制概要设计和详细设计的分解粒度 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45概要设计阶段有哪些主要活动主要的输出是什么 . . . . . . . . . . . . . . . . . . . . .45项目概要设计阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44QA在SRS阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44MC在SRS阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43CMO在SRS阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43为什么要进行需求跟踪可以使用哪些工具进行需求跟踪 . . . . . . . . . . . . . . . .42如何组织项目组输出一篇优质的需求规格说明书 . . . . . . . . . . . . . . . . . . . . . . .

41需求阶段有哪些主要活动主要的输出是什么 . . . . . . . . . . . . . . . . . . . . . . . .41项目需求阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40如何召开项目开工会会议内容有哪些 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40项目经理如何写作项目计划 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39什么是项目过程手册 PHB 如何裁剪过程制作项目过程手册 . . . . . . . . .

37什么是项目估计如何进行项目估计 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36什么是项目计划PPL 它和WBS 是什么关系 . . . . . . . . . . . . . . . . . . . . . . . . . .

36项目组对SOW/AR进行Review 着重注意什么问题 . . . . . . . . . . . . . . . . . . . . .36什么是SOW 什么是AR 从哪里获得这些项目输入 . . . . . . . . . . . . . . . . . . . .35计划阶段有哪些主要活动主要的输出是什么 . . . . . . . . . . . . . . . . . . . . . . . .

35项目计划阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35第二部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34什么是内部质量审计内部质量审计如何进行 . . . . . . . . . . . . . . . . . . . . . . . .34什么是基线审计基线审计如何进行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33什么是交付审计交付审计如何进行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33重用代码是否会提高产品质量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31走读检视评审审计的区别是什么我们具体如何操作 . . . . . . . . . . . . . .

31质量保证 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30项目组在什么时间如何进行缺陷预防活动 . . . . . . . . . . . . . . . . . . . . . . . . . .30缺陷预防 DP 的基本技术有哪些 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30什么是缺陷预防 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30缺陷预防 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29什么部门发布度量分析报告它包括哪些方面的内容 . . . . . . . . . . . . . . . . . . .


内部使用第ii页

59附录2 CMM 及软件工程文献参考 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56附录1 IPD-CMM 常用缩写词 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56第三部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55IPD - CMM 规定项目关闭有哪些操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55项目关闭 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54QA在测试阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54MC在测试阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53CMO在测试阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53软件测试过程包括哪些活动项目经理如何控制测试的有效性 . . . . . . . . . . . .53项目测试阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52QA在编码阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51MC在编码阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51CMO在编码阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50编码阶段有哪些主要活动主要的输出是什么 . . . . . . . . . . . . . . . . . . . . . . . .50项目编码阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49详细设计阶段有哪些主要活动主要的输出是什么 . . . . . . . . . . . . . . . . . . . . .49项目详细设计阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49QA在HLD阶段要完成哪些活动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


内部使用第iii页

第一部分

CMM 概述

CMM的基本框架是怎样的 CMM保证质量的基本原理是什么

CMM是Capability Maturity Model 的缩写即过程能力成熟度模型 CMM 作为一种模

型被用于很多方面这里讲的CMM指SW-CMM 即软件CMM

CMM是美国卡麦隆大学软件工程研究院组织开发的当初的目的是

� 帮助美国国防部认证软件承包商的过程成熟程度

� 帮助软件开发公司评估自己的过程成熟度

� 帮助软件开发公司分步骤改进自己的开发过程

CMM把一个软件公司的过程成熟度分为5个级别

� 初始级 1 级开发过程处于无序状态

� 可重复级 2 级建立起了基本的项目层次的管理过程

� 定义级 3 级建立起了整个公司范围的标准的开发过程 2级的管理过程进一

步得到系统化和细化

� 管理级 4 级开始对过程和产品质量进行定量化管理

� 优化级 5 级公司建立起过程优化机制过程得以不断改进并且这种改进是

受控的

CMM把开发过程划分为KPA进行描述 KPA即Key Process Area 关键过程域比如配

置管理就是一个关键过程域

对每个KPA CMM模型先定义其总体目标然后使用通用的5个共同特征 Common

Feature 细分成关键实践 Key Practice 5类共同特征是

� 承诺执行

� 有能力执行

� 实际执行

� 度量与分析


内部使用第1页

� 执行验证

因此整个CMM模型的内容组织方式如上图所示

CMM 各级定义的KPA及简单说明如下表格所示

向管理层提供软件实际执行效果的足够透明性以便在软件项目跟踪与监控

制定执行项目工程活动和管理活动的合理计划软件项目计划

项目和客户可能是内部客户就软件的需求达成共

识需求管理2

目的KPA成熟级


内部使用第2页

持续改进过程过程变更管理

发现新的工具方法过程并在一种受控的状态下进

行评估试用引进和推广技术变更管理

发现引入问题的根本原因并防止此类问题的再次发生错误预防5

对产品质量进行定量化管理软件质量管理

对项目的执行过程和效果进行量化管理量化过程管理4

有效发现并排除软件产品中的缺陷和错误同行评审

建立与其他软件工程组的有效勾通渠道组间协调

坚持使用定义的软件工程过程保证开发产品的正确性

和过程的有效性软件产品工程

项目组以组织的标准过程为基础通过裁剪制定并实

施工程活动和管理活动协调一致的项目开发过程集成软件管理

提高人员的技能和认识度以便他们更有效履行职责培训工程

定义并维护过程资产改进过程执行效果保证组织从

长远的角度受益组织过程定义

在组织范围内建立过程改进的责任主体组织过程关注3

在软件开发过程中建立并保证工作产品的完整性和一致

性软件配置管理

保证项目过程和工作产品质量并向管理层提供此方面

的可视性软件质量保证

选择合格的成本商有效管理他们的过程和质量软件子合同管理外包

管理

项目执行出现较大偏差时采取有效的更正活动

按SEI的观点软件项目的成功取决于人技术过程三方面的成熟程度 CMM 的主要创

始人之一Watts S. Humphrey 在他的经典著作 Managing the Software Process 中首先强调人的决


内部使用第3页

定性作用 Boehm 在 Software Engineering Economics 中提到项目组人员的经验越高输出

一流结果的可能性越大

在项目组人员不如人愿的情况下项目经理只能通过加强管理和培训进行弥补

技术对项目成功的影响显而易见使用过时的或尚未成熟的技术拙劣的系统框架设计等

都可能导致项目的根本失败

但即使拥有一流的人才和技术没有成熟过程的保证软件项目的成功仍然面临严重威

胁 Frederick Brooks 在 The Mythical Man-Month 中对软件过程的重要性有很多发现和感

慨比如如果一个软件项目由于过程原因而导致进度和质量失控继续投入新的人力进行补

救效果往往是适得其反

一个好的开发过程不能保证输出一个好的工作产品但一个坏的开发过程必然不能输出

一个好的工作产品

要进一步学习熟悉CMM的理论体系可以到SEI的站点 http://www.sei.cmu.edu/

Download 有关的文档 TR24.93.pdf 和TR25.93.pdf是正式的CMM描述文档本手册附录有一些

CMM经典文献推荐当然实践是最好的老师

IPD-CMM和SW-CMM是什么对应关系

SEI 的 SW-CMM 本身并不是一套软件开发流程为了力争放之四海而皆准 CMM只对软

件工程过程中的一些通用原则进行抽象和总结由于每个公司的文化不同商业模式不同各

公司必须根据CMM描述的原则结合公司实际具体定义自己的流程比如华为印度所的软件

开发流程被命名为QMS Quality Management System

IPD-CMM 3.0 是公司结合业界先进实践经验印度所质量流程国内各产品线多年的实践

经验和CMM 五级要求而定义的软件开发流程公司规定所有新开发和增强项目的软件开发必须

遵循该流程

IPD-CMM 3.0 以Web方式发布在质量部的PAL Process Asset Library 站点上站点地址

是 http://cmm.huawei.com/ 请向所在部门的研发质量部申请访问密码

本手册以下提到要参考的任何流程文件模板 Checklist 表格指导书等都可以在这个

站点找到


内部使用第4页

产品开发按IPD启动如何切入CMM流程

IPD是端到端的产品开发流程 IPD-CMM 3.0是软件产品开发子流程是对IPD流程在软件

开发过程部分的细化因此是IPD实施的一个支撑流程这也是我们为什么命名它为

IPD-CMM的原因

一般地 IPD以产品或PDT为单位实施 IPD-CMM 以项目组为单位实施 PDT开发团队在

TR2完成后产品包需求和系统设计规格完成开发团队分解成若干软件项目组和硬件项目组

然后每个软件项目组以分配的需求 SOW/AR 为输入切入IPD-CMM 3.0 流程

Design specification

S/W HLD H/W HLD

IPD

LLD LLD

Coding Coding

UT UT

Build1 Build2

Build3

IPD-CMM

SRS

HLD(0-2)

LLD(3)

Coding

UT

IT

ST

BBIT Supporting

TR3

TR4

TR2

BBIT

Build1

Build3

Build2

上图是IPD-CMM Design Flow对IPD 与IPD-CMM流程的关系描述

参考 IPD-CMM Design Flow 其中有各阶段的活动输入输出描述包括与IPD技术

评审点的对应关系

参考 IPD&CMM Alignment Manual 其中有IPD与CMM对应关系的更详细描述两篇

文档都可以从PAL站点(http://cmm.huawei.com)上找到或向QA查询

实施IPD-CMM流程有哪些特殊角色他们的职责和义务是哪些


内部使用第5页

实施IPD-CMM的责任人是项目经理 PL 项目组全员参与下面是一些特别定义的角

色

QA: 专职质量部指派负责流程引导培训和质量过程监控

CMO: CM Operator 配置管理员项目成员兼职或专职负责项目的配置管理工作

MC: Metrics Coordinator 度量协调员项目成员兼职负责过程数据收集维护度量表

TC: Test Coordinator 负责引导和支持项目组测试活动

另外在必要时项目经理还可以指定

风险管理员负责监控项目风险状态更新风险跟踪表也可以由项目经理本人负责风险

管理

什么是MINI Project 培训

MINI Project 培训是研发质量部制作安排的针对IPD-CMM 3.0的一种培训它使用一个虚

拟项目让学员对IPD-CMM 3.0中的重要活动进行实际操练包括从项目组的组建项目输入

各类角色的任命项目估计项目计划开发测试到项目关闭的全部过程在每项活动之

前穿插相关的专项培训一项活动结束后有培训教师对各模拟项目组工作成果的点评以保

证培训效果

MINI Project 培训课程为5~7天由培训体系组织公司要求所有软件类工程师必须参加

项目管理

项目管理要注意哪些要点

项目管理是一个大的课题软件项目管理涉及的需求管理计划管理风险管理配置管

理质量管理等在IPD-CMM 的不同KPA中穿插描述这里给出一些其他要点供项目经理参考

人员使用

� 精英原则使用少而精的顶尖人才有数据表明缺陷率与人员规模成正比因此

在可能的情况下项目组规模越小越好


内部使用第6页

� 工作匹配原则即我们讲的用人所长容人之短

� 职业生涯原则理解并帮助实现员工的职业生涯理想有利于激励员工的工作积

极性

� 平衡原则要善用能与大家和睦相处营造良好工作气氛的员工

� 淘汰原则清除害群之马


内部使用第7页

使用2-8原理把握重点

� 20% 的任务消耗 80% 的CPU时间

� 20% 的代码引入了 80% 的缺陷

� 20% 的人完成了 80% 的工作等

计划与变化

不要使用计划不如变化快作为忽视或嘲笑计划的理由计划调整是正常的目的

是适应变化没有计划和监控项目会很快陷入失控状态

风险管理

一位管理大师曾提到没有风险管理就是没有管理参见风险管理一节实施

项目风险管理

把握客户心理控制成本质量功能和进度的平衡

客户总是希望在成本质量功能和交货期方面都是完美的但同时他们也明白这些

是不可能同时被满足的并在不同的场景有不同的倾向

� 所有客户都不想得到一个坏的产品即使能及时交货质量第一

� 大部分客户希望得到一个质量相对高的产品即使是付出相对高昂一点的价格

成本已不是唯一的决胜因素

� 如果及时交货有困难客户往往希望先拿到一个已实现基本功能的产品版本策

略

� 可怕的最坏的情况是客户等了很长时间花了很多的钱得到很多无用的功

能并存在很多的Bug

项目组与QA如何密切配合保证过程质量和产品质量


内部使用第8页

单纯地讲QA是警察是培训教师或是检查员都是不完整的要有效实施IPD-CMM流

程保证过程质量和产品质量必须实现两者的互动项目经理可以参考以下要点充分发挥

QA和质量部的作用

� 在项目初始阶段就向质量部申请专职QA 保证QA尽早介入

� 在初始阶段与QA就整个项目的流程和质量保证措施进行讨论并达成一致

� 只要是牵扯到流程模板表格之类的事情就向QA咨询避免事后被判定为不符

合项

� 多向QA申请培训即使有些培训不是QA亲自做 QA也可以协调安排

� 对于过程文档不但要使用标准模板还要向QA索要样例 QA一般引导过很多

项目也常常是同时引导多个项目 QA那里有很好的样例

� 如果QA不是很投入应大胆向质量部反映

� 相信流程不是生硬的每个项目也各有特点只要有自认为更好的方法更好的

模板等都可以同QA协商使用 QA从各项目组收集的好的实践就是从这里

来的

批准签发是什么寓意批准签发是怎样进行的

在IPD-CMM 3.0 批准是一个审核和认可的过程被批准表明相关的文档或工作产品已经

完成Review并符合流程要求在技术方面已经没有问题它近似是一个工程过程

签发是一个发布的过程一个文档比如项目计划被签发标志着这个文档被领导层认

可可以正式投入使用它近似是一个管理过程

基于以上原因只有部分管理类文档 PHB PPL 项目偏差申请等才需要签发其他

文档 SRS, STP HLD ITP LLD UTP WBS等只需经过批准


内部使用第9页

下表列出了项目主要文档的批准签发责任人供参考

QA和PDT开发

代表

QA TC TDC

CMO 受影响的组

支持组

PLWBS

NAQA和PDT开发

代表

QA TC TDC

CMO 受影响的组

支持组

PLDPP缺陷预防计

划

NAQA和PDT开发

代表

QA TC TDC

CMO 受影响的组

支持组

PLRMP 风险管理

计划

NAQA和PDT开发

代表

QA TC TDC

CMO 受影响的组

支持组

PLCMP 配置管理

计划

PDT开发代表QAQA TC TDC

CMO 受影响的组

支持组

PLPPL 项目计划

PDT开发代表MDG的代表QA MDG 的代表PLPHB 过程手册

NAPDT开发代表SE PDT开发代表项目经理估计

组如果项目经理

要求 TC要参加初

始估计和重估计

估计与重估计

PDT 开发代

表和PL一起

在工作任务

书上签字

NAPDT开发代表 QA

PL TC 其中PDT开

发代表负责

PDTSOW 工作任务

书

签发批准Review拟制文档


内部使用第10页

NATCPL SWE TC PL制定系统测试日

程表 PL指定人员

负责设计测试组网

图 SWE负责准备

STP 系统测试计

划包括系统测

试用例

NAPL负责HLD和编码的工

程师

项目设计人员LLD 详细设计

NAPLSE和其他相关项目组

专家以及负责编码的

人员

项目设计人员HLD 概要设计

SESE PDT PL 负责

设计的项目组成员

负责编码的项目组成

员 QA 测试协调员

TC TDC 其它一些

同事及其它相关组成

员 PL指定人员

PL SE 项目组SRS

PDT开发代表

(人力资源发

生变化, 交付

时间发生变

化里程碑

更改等

QAQA 项目组受影响

的组支持组

PL计划更新

NATC 测试协调员

和PDT开发代表

QA TC TDC

CMO 受影响的组

支持组

PLTS 测试策略




NANA项目组成员 PDT 开PL项目结束报告

NANAPDT 开发代表 QA

EPG

PL阶段/月度评估

报告

NANAPDT开发代表和QA

以及相关经理和受影

响组

PL项目状态报告

NANAPL每个项目成员项目进展报告

NAPLNAPL 指定人员UT/IT Test

Report

NANANASWEUT/IT Test

Record

NATCNAPL 指定人员ST Test Report

NANANASWEST Test Record

NAPLPL&SWEPL制定单元测试日

程表 SWE负责准

备所分配单元的单

元测试用例

UTP 单元测试

计划包括单元

测试用例

NAPLPL SWE TC PL制定集成测试日

程表 PL指定人员

设计测试组网图

SWE负责所分配模

块/接口的集成测试

用例

ITP 集成测试计

划包括集成测

试用例

所分配特性的系统

测试用例




NANAQA PL MGMC度量表

NANA项目组成员 QA 开

发代表缺陷预防协

调员受影响组以及

软件工程过程组

PL根源分析报告

高级经理

PDT 开发代表

质量部经理

PDT 开发代表质量

部经理

PL项目例外报告

PDT开发代表MDGQA PDT开发代表PL项目偏差申请表

发代表 QA EPG


现在的批准签发过程可以采用Notes系统上的CMM助手之批准与签发电子流来完成也

可以使用电子签名的方式就是授权人发送邮件 email邮件或Notes邮件表示同意批准或签

发配置管理员或项目经理需要将该邮件保存为文档与被批准或签发文件一起存放在项目文

件夹的相应目录下这样就完成了批准签发过程

IPD-CMM 3.0中定义了哪些项目会议

以下只列出管理类会议工程类会议项目估计会议 Review会议 CCB会议缺陷预防

会议等请参考相关条目的说明

开工会

请参考项目计划阶段一节

阶段启动会议



在项目正式完成一个阶段的工作进入下一阶段时项目经理应该召开一个阶段启动会

议对该阶段的工作进行一个总体的部署

阶段启动会议可以和上一阶段的阶段结束会议一起召开如果中间没有其他处理事项

IPD-CMM 3.0 没有提供专门的模板项目经理可以参考以下列表制作一个会议胶片来组

织阶段启动会议在会议上讨论或确认

� 参考项目的PHB 检查确认阶段的入口条件是否已经得到满足

� 参考项目的PHB 明确阶段的主要活动和工作交付物

� 参考项目的PHB 明确要使用的流程模板方法 Checklist等

� 参照风险管理计划明确阶段可能发生的风险落实规避措施和跟踪责任人

� 明确调整之后的阶段进度计划

� 明确阶段工作产品的质量目标相关的质量保证措施

� 参照项目的PHB和项目计划明确阶段结束的出口条件

� 明确人员分工

� 制定阶段的培训需求计划

� 项目组成员提出的其他问题

� 其他动员激励措施的公布等

阶段结束会议

阶段结束会议的目的是对项目阶段执行的效果进行评判总结经验教训与下阶段起到承

上启下的作用

如果一个阶段的跨度超过1个月建议项目经理在每个月召开一个月度总结会议对项目进行

总结

在召开阶段结束会议之前项目经理使用PJMCHK05 作为Checklist 使用PJM03F03作为模

板准备阶段结束项目评估报告在会议上对报告中罗列的事项进行Review和讨论确认

参照阶段结束/月度项目评估报告 PL在会议上要检查的事项包括

� 检查阶段工作产品完成情况

� 检查质量目标完成情况使用度量表填写结束报告第5节

� 检查资源状况 IT资源人力资源

� 检查风险状态使用风险管理表格填写结束报告第9节



� 检查阶段培训工作完成情况

� 缺陷预防活动标识本阶段遇到的典型错误流程方法和工作产品中的缺陷

分析根本原因制定纠正和预防措施检查已经定义的预防措施的执行效

果

� 总结本阶段好的经验和教训

� 总结项目遇到的其他问题

周例会

周例会是我们最熟悉的项目会议项目组每周在固定的时间召开项目周例会

IPD-CMM 3.0 没有定义专门的周例会纪要模板项目组可以使用IPD-CMM 3.0 定义的通用

会议纪要模板PJM03F11作为周例会纪要模板

周例会的议程和注意事项包括

� 检查上周纪要跟踪问题的完成情况

� 检查一周项目工程活动的完成情况

� QA CMO MC RM SE TC等分别汇报各自专项工作的特殊问题或进展

� 项目组成员汇报其他问题

� 标识新的需要跟踪的问题纳入会议纪要进行跟踪

� 新一周的工作计划等

项目审计会议

审计会议只在质量部对项目进行内部质量审计时举行按IPD-CMM 3.0的定义一个

实施CMM流程的项目应保证在其生命周期中至少接受一次内部质量审计

内部质量审计按QAM02 内部审计流程的方法进行项目经理和项目QA将参加

审计启动会议审计之前举行审计经理对审计的目的审计范围审计重点人员分工

和配合要求项目的配合事项审计时间和方式使用的Checklist 审计输出方式等进行说明

审计结束会议现场检查完成后进行审计经理对审计发现的问题进行说明并与项目经

理和QA进行确认确定审计发现问题的关闭方式包括责任人和建议关闭时间共享各项目

的好的实践就纠正和预防措施取得项目组和其他方面的承诺



项目结束会议

参考项目关闭一节的说明



IPD-CMM 3.0中定义了哪些项目报告分别在什么场合使用

下表列出IPD-CMM 3.0定义的各类报告包括模板索引请选择使用

PJM03F02PDT开发代表 QAEPG

项目结束项目经理项目关闭报

告

QAM02F06PDT开发代表 PL每周QASQA周报告

QAM02F03

QAM02F04

QAM02F05

业务部领导开发代

表项目经理

内部审计计划定

义

质量部内部

审计组

内部审计报

告

PJM03F04PDT开发代表质量部

经理

当项目发生例外

时

项目经理项目例外报

告

PJM03F03PDT开发代表 QA EPG

阶段结束/每月项目经理阶段结束评

估报告

PJM03F07项目经理每周项目组成员进展报告/工作日志

PJM03F01PDT开发代表 QA 以及相关经理和受影响组

每周项目经理项目状态报

告周报

模板向谁汇报频度准备人报告

什么是项目文件夹如何使用项目文件夹有效管理项目

项目文件夹 Project Folder 是IPD-CMM 3.0提供给项目经理的重要项目管理工具

项目文件夹实际上是一个推荐的项目组的工作目录结构其中为各类项目文档分门别类建

立了存放目录

以下是它的典型结构

估计记录和估计结果1.2.1 Estimation1.2 Project Plan

客户提供物1.1.3 Customers Supplied

分配需求1.1.2 AllocatedRequirement

工作任务书1.1.1 SOW1.1 Business01.CI



发布记录3.5 Release Record

归档/删除表格3.4 Archive or DeleteForm

配置状态发布3.3 Configuration StatusAccounting

变更请求3.2 Change Request

CCB会议纪要3.1 CCB MeetingMinutes

03.CM

签发批准记录2.3.Approval Record

偏差报告2.2.6 Deviation Report

项目结束报告2.2.5 Closure Report

例外报告2.2.4 Exception Report

阶段结束报告2.2.3 End Phase Report

项目状态报告2.2.2 Project Status Report

项目组成员周进展报告2.2.1 Team MemberWeekly Report

2.2 Project Report

其它会议2.1.8 Other Meeting

项目结束会议纪要2.1.7 Closure Meeting

根源分析会议纪要2.1.6 Root Cause AnalysisMeeting

月度会议纪要2.1.5 Monthly Meeting

阶段结束会议纪要2.1.4 End Phase Meeting

技术讨论记录2.1.3 Technical Discussionmeeting

周例会纪要2.1.2 Weekly Meeting

开工会纪要2.1.1 Kick-off Meeting2.1 Meeting Mom02.PL

用户手册1.7 User Manual

需求跟踪矩阵1.6 RTM

系统测试计划和用例1.5.3 STP & STC

集成测试计划和用例1.5.2 ITP & ITC

单元测试计划和用例1.5.1 UTP & UTC1.5 Test

详细设计文档1.4.2 LLD

概要设计文档1.4.1 HLD1.4 Design

需求文档1.3 SRS

测试策略1.2.6 Test Strategy

项目进度表1.2.5 WBS

配置管理计划1.2.4 CM Plan

项目计划PPL1.2.3 Project Plan

项目过程手册1.2.2 PHB



培训记录9.3 Training Record

培训反馈表9.2 Feedback

培训教材9.1 Material09.Training

项目参考的指导书8.4 Guideline

项目参考的管理文档8.3 Management

项目参考的产品文档8.2 Product

项目参照的过程文档8.1 Process08.Reference

系统测试记录包括测试记录

和测试报告

7.3 ST

集成测试记录包括测试记录

和测试报告

7.2 IT

单元测试记录包括测试记录

和测试报告

7.1 UT07.TestRecord

内部审计记录6.3 Internal Audit

基线审计记录6.2 Baseline Audit

交付审计的记录6.1 Deliverable Audit06.AuditRecord

其它review记录5.12 Other review

工作任务书review记录5.11 SOW review

系统测试计划的review记录5.10 STP review

集成测试计划的review记录5.09 ITP review

单元测试计划的review记录5.08 UTP review

代码的review记录5.07 Code Review

详细设计的review记录5.06 LLD Review

概要设计的review记录5.05 HLD Review

需求文档的review记录5.04 SRS review

配置管理计划的review记录5.03 CM plan review

项目计划的review记录5.02 PPL review

项目过程手册的review记录5.01 PHB review05.ReviewRecord

度量分析4.3 Metrics Analysis

度量表4.2 Metrics Sheet

项目组成员的时间表4.1 Time sheet04.Metrics

备份日志3.6 Backup Log

项目文件夹就是项目档案如果整个项目是一盘棋我们应可以利用项目文件夹重演项目

的执行过程 QA对项目进行内部质量审计主要就是检查项目文件夹中相关工作产物过程记

录质量记录是否存在等所以项目经理一定要使用项目文件夹管理项目



到华为CMM PAL站点上 http://cmm.huawei.com 下载或向QA索要项目文件夹的压缩文

件解压后就可以使用这个标准的目录结构管理项目了继续参考配置库目录与项目文件夹

目录结构的关系一节

如何控制和处理开发阶段的重叠

IPD-CMM 3.0 主要依据V模型对开发过程进行阐述 V模型比较成熟其他的开发模型比

如叠代螺旋等模型都以V模型或瀑布模型为基础

V模型的产品开发是按阶段进行的但实际操作过程中阶段重叠是经常发生以下是处

理阶段重叠的以下原则

� 阶段重叠容易导致开发节奏不可控应尽量避免

� 只在某些模块的阶段任务已经完成比如设计完成写作和评审才允许部分人

员开始下阶段的任务如编码从整个项目的进度来看发生阶段重叠

� 在发生阶段重叠的情况下项目经理要保证没有完成的现阶段工作一旦完成

不会或较少影响己经启动的下阶段工作比如要避免最终的设计影响到编码导

致编码框架要修改甚至完全重新开始

� 开始的下阶段工作要按流程执行比如召开开工会提前进行相关的培训使用

正确的模板或规范等

� 项目经理应该缩短阶段重叠的时间

� 对于现阶段的结束时间和下阶段的开始时间记录项目经理应以现阶段工作正式

结束为准或者按比率进行计算

配置管理

配置管理计划的作用是什么如何写作配置管理计划

配置管理计划对项目的配置管理活动进行总体规划编写配置管理计划是IPD-CMM对配置

管理过程域的基本要求

配置管理计划一般由项目经理编写 CMO协助



配置管理计划中将明确项目配置管理的以下细节

� 配置项列表罗列项目所有要纳入配置管理的文档代码库工具等

� 配置项的命名规范

� 使用什么工具建立配置库现在公司有Microsoft VSS 和Rational ClearCase可选

一般的项目使用VSS就足够了

� 配置库的目录结构明确哪些文档放在哪些目录中

� 版本方案即如何给配置项特别是源代码赋予版本号

� 变更流程明确因需求更改设计更改改正错误需对已经基线化的配置项进行

改变时应该走什么流程

� 配置状态发布明确CMO应使用什么方式在什么时间向项目组成员和相关部门

发布配置状态报告

� 明确发布 Release 流程

� 明确配置库的备份机制应以什么周期在哪里进行配置库的备份以防配置库

崩溃

� 明确基线审计如何进行频度职责等

请使用IPD-CMM 3.0 规定的标准模板写作配置管理计划并可向QA索要样例作为参考

为什么要制定配置项命名规范如何制定配置项命名规范

制定配置项命名规范是进行配置管理的基础不然文档和代码的命名就会出现混乱使配

置管理无从做起

参考 IPD-CMM PJM01- 项目文档控制规程制定配置项命名规范

文档命名

项目文档的命名格式为XXXX.tttnn.yyy

XXXX = <产品名称缩写> 项目编码的定义要使用项目编码定义规程由字母和数字

串构成最大长度为20

tttnn = 唯一的标识符

yyy = 文件扩展名如 doc xlt等

标识符的格式 tttnn



ttt 如下定义的文档类型 Mnemonic

nn 索引号码适用于同类文档由多篇文档构成的情况从01开始由CMO分配

User Guide (basic instructions) 用户指南UGD

System Test Plan 系统测试计划STP

Integration Test Plan 集成测试计划ITP

Unit Test Plan 单元测试计划UTP

Low Level Design Specification 详细设计LLD

High Level Design Specification 概要设计HLD

Software Requirements Specification 需求规格说明书SRS

Risk Management Plan 风险管理计划RMP

Configuration Management Plan 配置管理计划CMP

Project Plan 项目计划PPL

Statement of Work 工作任务书SOW

Process Handbook 项目过程手册PHB

Document type文档类型

Mnemonic助记符

代码命名

代码文件名的命名规范各项目组自行确定即可

CMO如何建立配置库

由PL安排CMO建立配置库并应该在配置管理计划制定完毕之后进行因为配置管理计划

包括对配置库的规划

� 选定配置管理工具 VSS或Clear Case Clear Case 功能强大数据库稳定但安装

和维护工作量大建议只在代码量大的项目中使用

� 服务器选型可以使用专用服务器或高档PC作为配置库服务器关键是要保证其

运行稳定性和安全性不要与开发人员共用一台PC做配置库服务器一般目前公

司统一由管理工程部提供由产品CMO分配

� 安装操作系统软件和配置库软件

� 按照配置管理计划中定义的目录结构建立配置库结构



� 给项目组人员分配访问权限

� 向项目组发布配置库启用公告

配置库目录与项目文件夹目录结构的关系是怎样的

IPD-CMM 定义项目文件夹为项目组的工作目录有些项目组将整个项目文件夹作为配置

库目录并由CMO进行维护的方式是错误的

按照IPD-CMM 3.0 项目文件夹的使用说明对项目文件夹和配置库的目录关系说明如下

� 项目文件夹由项目经理维护使用项目经理应在自己的机器上建立项目文件夹

并只在其中的相关目录下存放项目文档项目经理应给项目组成员开发代表

QA等人员开放该目录的读权限

� 考虑到项目文件夹中的CI目录是项目的文档配置项 CM目录是配置管理相关的文

档或记录项目经理可以将这两个目录授权CMO维护具体方式是这两个目录

Check-In 到配置库 CMO在自己的机器上建立这两个目录的工作目录并负责文

档的创建和维护当文档有变化时项目经理可以使用Get命令刷新自己的工作目

录

� 项目配置库的目录参见Project Folder Introduction

� 代码的配置库目录结构由项目组自定按多子项目多模块头文件源文件

共用库的不同建立合理的目录结构

� 如果项目任命了度量管理员项目经理可以把Metrics目录对度量管理员开放写权

限由他负责度量表格的更新

� 项目经理可以将整个文件夹以文件目录的方式定期备份到配置服务器或其他服务

器上

在建立之初项目经理可以对项目文件夹目录进行增删改但需与QA协商对配

置库目录的设置在满足上述原则的基础上可以与QA协商进行优化



什么是配置状态发布 CMO如何进行配置状态发布

配置状态发布是指CMO维护配置项列表维护CR列表并将统计结果通报给项目组和相

关组织的过程

通过配置状态报告项目相关人员可以清楚地知道项目有哪些配置项已归档当前版本号

是什么存放在什么地方如果配置项发生过变化还可以找到配置项发生变化的原因和位

置

按照IPD-CMM的定义 CMO使用CMP01F01 配置状态报告表格和CMP01F07 变更请求

记录表格进行配置状态发布

CMO应该在每次配置库发生变更新的配置项基线化 CR实施结束等情况下进行一次

配置状态发布并保证至少2周一次

CCB是什么组织变更控制过程是如何操作的

CCB 即 Change Control Board 也有文献中作Configuration Control Board 即配置变更

控制委员会

一般在配置管理计划中定义项目的CCB 设立CCB的目的是保证配置的变更特别是需求

变更一定要经过评审并且不能由PL一人决定是否接受

CCB一般由开发代表 PL SE 市场代表技术专家配置管理员 QA等相关人员组

成

CCB的工作方式一般问题如果走变更电子流 CCB成员可以在Notes上直接发表意见

对较大的更改 PL应该召集CCB会议进行讨论决议另外 CCB应该周期性召开会议对一段

时间内的更改进行集中评审或评估

CCB会议纪要请放入项目文件夹中备查

配置库备份要注意哪些原则



在我公司配置管理服务器一般由管理工程部集中管理因此备份工作也由管理工程部进

行各项目组不需再进行备份工作但如果配置管理服务器未接受公司管理工程部集中管理

那么需要遵循以下原则

备份的目的是要保证安全符合如下原则

� 增量备份这样可以节省存贮空间从而增加备份的频度 VSS支持增量备份

� 异地备份备份库要放在另外一个地方如果把备份文件放在同一台计算机上

几乎等于没有备份因此备份文件要放在另一个地方的机器磁带或光盘上

� 多备份应在一个时间段内保留多个备份建议至少保留最近的3次备份

� 物理安全性如果使用磁带备份要考虑磁带存放地的物理安全如防火防磁

等其他形式的备份做相应考虑

� 维护备份记录使用CMP01F09为模板写作备份记录与备份文件一起存档

配置管理如何管理文档

文档配置项包括SOW/AR 过程手册项目计划配置管理计划风险管理计划 SRS文

档 HLD文档 LLD文档测试计划包括测试用例等

CMO可以分3个阶段对文档进行不同力度的配置管理

� 初始状态

文档在写作过程中属初始状态文档作者控制即使作者这时请别人帮助内部Review

也属于这种状态

� 管理与受控状态

文档作者完成文档应在更改历史一栏写上初稿完成附作者名和日期然后提

交正式的评审或检视这时文档应提交主审人或CMO控制文档作者不应再随意更改或提供

版本否则别人就可能Review错误的版本即使作者本身再有更改的需求也应在Review会上

提出统一修改

� 基线化状态

文档完成Review和修改经批准和签发就进入基线状态文档应提交给CMO纳入配置库

进行管理在文档修改历史列表中应增加两栏分别是Review修改记录和基线化记录

CMO应给出不同的版本号建议为1.0



这时所有人员应删除文档的本地版本包括文档作者以后对文档的修改由CMO 从

基线库中Check-Out 统一修改并维护修改历史列表并视情况给出不同的版本号



配置管理如何管理代码

根据经验将单个源文件作为配置项维护比较困难建议把整个项目或一个模块的全部代

码作为一个配置项统一打版本号标签进行版本管理 VSS的项目标签 Label 就可以完成这

种功能

CMO可以参考以下方法管理代码

� 编码阶段

CMO为各开发组和开发人员建立各自的开发库目录目录可以每个模块一个子目录

每个目录下分代码子目录头文件子目录配置 Make文件子目录等源文件的命名

应要求他们按配置管理计划确定的原则进行开放VSS写权限给开发人员以便他们

每天的Check-In/Check-Out 操作 CMO应检查开发人员的工作目录与配置库一致

这个阶段开发人员控制开发库目的主要是每日的备份以及万一出错的版本滚动

开发人员可以使用 0.x (x=1~8)标志阶段版本

� 代码检视阶段

开发人员完成编码使用工具进行静态检查自检提交正式Review时代码应交

CMO管理 CMO可以为代码标识一个版本号 0.9 并关闭开发人员的写权限组

织代码Review Review发现的问题应填写到Review表格修改由CMO组织有控制地

Check-Out给开发人员进行修改 Check-Out/Check-In要在VSS的Comment域填写注释

代码Review完成发现的问题修改完成后 CMO为整个代码打另一个版本号 1.0

代码第一次基线化代码移入基线库进行管理

� 单元测试阶段

CMO参考代码检视阶段的控制方法对单元测试阶段的代码进行管理中间的修改

可以使用版本号 1.x (x=1~9)进行标识单元测试完成后 CMO为整个代码打另一

个版本号 2.0 这是第二个代码基线作为集成测试的输入

� 集成测试阶段

CMO参考单元测试阶段的控制方法对集成测试阶段的代码进行管理中间的修改

可以使用版本号 2.x (x=1~9)进行标识集成测试完成后 CMO为整个代码打另一

个版本号 3.0 这是第三个代码基线作为系统测试的输入



� 系统测试阶段

CMO参考集成测试阶段的控制方法对系统测试阶段的代码进行管理中间的修改

可以使用版本号 3.x (x=1~9)进行标识系统测试完成后 CMO为整个代码打另一

个版本号 4.0 这是第四个代码基线理论上应是一个可发布的版本

如果版本被发布拷贝一个备份到产品库并附相应的版本描述文件 DVP12F01

注意以上的版本编号是释义性的项目组可以使用更适合自己的版本编号并在VSS打

标签时在 Comments 域给出清晰的注释

风险管理

为什么要进行风险管理项目风险有哪些属性

风险是指不希望发生而可能发生一旦发生将对项目执行产生负面影响的一些事项

如果一些事项肯定发生就不属于风险的范畴

如果仔细分析每个项目的执行都有很多潜在的风险进行正式的风险管理可以防患于

未然或在风险转化为问题时从容应付将损失减少到最小避免项目失控

按IPD-CMM 3.0的定义我们从以下方面对一个风险进行标识使用PJM05F01 项目风险

管理表格

� 风险库中风险ID 对应组织级风险库中该风险的唯一编号便于分析和跟踪

� 风险描述对风险可能发生的时间形态危害和其他特征的详细描述

� 规避措施阻止风险发生的方法描述

� 应急措施一旦风险发生相关的减少或避免损失的方法步骤

� 发生几率用高中低或百分比表示

� 影响程度用高中低表示

� 风险指数发生几率和影响程度的乘积

� 风险分类分主类和子类见PJM05F01的分类列表

� 当前状态 Open 或 Close

� 有效期风险只在一段时间内存在



为了便于风险的管理表格中还建议确定风险的监视责任人风险管理员专门监控风险

的状态



项目组如何标识和管理风险

标识风险

在项目计划阶段和项目进行过程中项目经理可以采用浏览组织级风险库风险查检表和

头脑风暴会议等方法标识项目风险

浏览组织级风险库是指项目经理可以浏览质量部收集和分析的组织级风险库中已经标识

的风险这些是在已经关闭的项目中收集的项目常见的典型风险如果项目经理认为项目存在

类似的情况就可以作为一个项目风险纳入管理

风险查检表是指项目经理浏览质量部过程库中的风险提问单 PJM05G01 软件风险分

析工具指导书附录每一个问题都是一个可能存在风险的提示项目经理据此发现项目风险

并纳入管理

头脑风暴会议是召开项目会议集思广益项目组成员根据经验和项目的特点向项目经

理提出可能存在的风险

项目经理将以上方法标识的风险填入PJM05F01 风险跟踪表格过程中要确定相关的规避

措施和应急计划等

标识风险是制定项目计划的一部分在项目计划文档的风险管理一节引用该表格即

可

风险管理

项目经理可以任命兼职的风险管理员负责维护风险表格监控风险的状态监督相关规

避措施的实施

在周例会阶段结束会议项目评估会议上要对风险的状态进行Review 必要时更新风险

的状态在风险发生时启动应急计划减少风险对项目的影响保证项目的受控执行

软件度量

为什么要实施软件度量



收集度量数据是实施定量化管理 Quantitative Management 的基础

关于度量可以先体会一下谚语的寓意

If you don’t know where you are , a map won’t help 如果你不知道你的位置地图也帮

不了你

You can’t control what you can’t measure 你无法控制你无法度量的东西控制论告

诉我们没有传感器提示的偏差就无法控制

Without data, you are just a person with another opinion 不要人云亦云用事实说话

以上主要是在组织级对度量的重要性进行描述一个软件开发组织只有在收集度量数据

的前提下才可能与业界最佳或基准值进行比较找到自己的薄弱环节和改进方向

收集和积累度量数据也是提高我们职业化水平的重要方法比如有些已有多年开发经验的

软件工程师对自己已开发项目的软件规模缺陷密度等并没有量的概念项目经理对组织的生

产率软件开发周期各阶段的工作量分布等也没有量的认识这些都会影响他们在未来的项目

中发挥领导者的作用

度量数据对项目组同样重要只有收集过程和工作产品的度量数据项目经理才可以对过

程质量和工作产品质量有一个量的认识通过与历史数据和质量目标进行比较项目经理可以

识别过程中的薄弱环节和过程产品可能存在的问题并及时实施相关的补救措施

鉴于软件度量的重要性 IPD-CMM 流程要求任命兼职的度量协调员 MC 使用度量数

据收集表格 QAM05F01 收集并分析项目度量数据

IPD-CMM 定义收集哪些度量数据各自代表什么含义

从一个角度讲度量数据可以分为过程度量数据和产品度量数据比如进度偏差工作量

分布属于过程度量数据而缺陷密度属于产品度量数据

从另一个角度讲度量数据又分为直接度量数据和派生度量数据比如代码行和Review发

现的缺陷数是直接度量数据而两者的比率缺陷数/ 代码行是缺陷密度属于派生度量数

据

MC的职责是在过程中把直接度量数据收集进度量表格派生度量数据由度量表格自动计

算生成



要了解IPD-CMM 3.0收集和派生的度量数据的详细定义可以参考QAM05F01开发项目度

量模板中的说明主要有以下内容

进度类

� 初始的计划时间

� 更新的计划时间

� 实际的完成时间

工作量类

� 各类活动估计实际的工作量花费

软件规模类

� 文档 SRS, HLD, LLD等页数

� 测试用例数

� 有效代码行数非空非注释

缺陷类

� 文档和代码Review发现的总缺陷数

� 各类测试发现的总缺陷数

需求类

� 总需求个数分配需求和软件需求

� 需求变更个数修改删除增加

派生的度量数据包括

� 进度偏差包括持续时间偏差和拖延偏差

� 工作量偏差与计划相比

� 缺陷密度过程缺陷密度和遗留缺陷密度

� 需求稳定度指数

� Review效率

� 测试效率

� 生产率

� 文档生产率等

关于各类度量数据的收集时间和来源请参考各阶段MC的职责描述



什么是文档生产率它有什么参考价值

IPD-CMM 3.0 中还没有正式使用文档生产率的概念但它有较高的参加价值文档生产率

就是文档页数与代码行的比值比如一页SRS文档对应多少行代码这可以反映SRS文档的详细

程度和信息量

待质量部积累了足够的数据就可以给一个经验值供大家参考



什么部门发布度量分析报告它包括哪些方面的内容

在组织级业务部质量部的EPG周期性收集全部项目的度量表格进行综合分析并按

QAM05T01模板的格式发布度量分析报告度量分析报告主要包括以下方面的内容

� 各类度量数据的平均值标准偏差和控制图表下图是一个进度偏差分析表的

示例

-100.0%

-50.0%

0.0%

50.0%

100.0%

150.0%

200.0%

Projects

UCL

LCL

Mean

� 对超出控制上限和下限的项目比如上图中的S14和S23 调查收集原因并进行

RCA Root Cause Analysis 比如一个签发的延迟是因为签发人员不熟悉相关流

程而不熟悉流程的原因是缺乏培训

� 对所有Root Cause进行归纳整理标识出典型的Root Cause 并给出建议的纠正和

预防措施

� 分析总结度量数据平均值的变化趋势与上一次分析报告比较发散还是收敛

改善还是恶化并给出走势图和原因分析纠正措施等

� 根据度量数据平均值的变化对修改组织级的能力基线给出建议

度量分析报告要由EPG向业务部领导各项目组主管和质量部进行汇报并就改进措施达

成共识取得管理层的支持和承诺



不断的数据收集分析改进再分析的过程形成一个闭环组织的过程就会不断得以改

进走向成熟

缺陷预防

什么是缺陷预防

缺陷预防 Defect Prevention 是CMM 5级的PKA 缺陷预防的基本原理是检查发现的问

题找出问题发生的根本原因并采取措施阻止这类问题的再发生

相对于Review和测试缺陷预防是一种保证产品质量的更积极更有效的方法建议所有

项目组都要进行这方面的活动

缺陷预防 DP 的基本技术有哪些

DP的基本技术可以概括为

� 建立缺陷分类方法这是整个DP活动的基础分类要尽量避免相关性比如正交

分类法等

� 从Review表格评审报告测试报告中收集缺陷数据

� 使用统计技术对数据进行分析

� 使用鱼骨图等方法查找多发问题典型问题的根本原因

� 针对根本原因采取措施防止缺陷的再次发生

大范围的DP活动是一个系统工程还包括对各类措施的实施效果进行分析跟踪等活动是

一个质量闭环控制过程

项目组在什么时间如何进行缺陷预防活动

DP的实施是分级的有项目级的行为部门级的行为以及整个公司的行为除积极配合部

门以及公司总体的DP活动之外项目组还可以参考以下方式开展项目范围的DP活动



在进行项目计划时参考PAL上的缺陷库在项目计划中明确DP活动的开展方法

在每个阶段的结束会议上在阶段结束报告中的纠正与预防措施一节对本阶段发现的问

题进行分析找出原因并避免在将来的阶段中重犯

必要时比如在编码阶段定期召开DP会议分析发现的缺陷及引入原因制定相关的改

进措施减少编码的错误发生

质量保证

走读检视评审审计的区别是什么我们具体如何操作

在软件开发过程改进的过程中我们引进了走读 Walk-through 检视 Inspection 评

审 Review 审计 Audit 的概念在IEEE Std 1028-1997 中有对这些概念和过程的标准定

义摘录如下

走读 A static analysis technique in which a designer or programmer leads members of the

development team and other interested parties through a software product, and the participants ask

questions and make comments about possible errors, violation of development standards, and other

problems.

一种静态分析技术设计者或程序员引导开发组成员和其他相关组成员浏览一个软件工作

产品与会者可以提问或提出可能是错误开发过程偏差或其他问题的意见

检视 A visual examination of a software product to detect and identify software anomalies,

including errors and deviations from standards and specifications. Inspections are peer examinations led

by impartial facilitators who are trained in inspection techniques. Determination of remedial or

investigative action for an anomaly is a mandatory element of a software inspection, although the solution

should not be determined in the inspection meeting.

对软件工作产品的一种检查用于发现或标记软件异常包括错误和与标准规格的偏

差检视由公正的接受过检视技巧训练的引导者引导进行会议上必须决定对发现的异常进

行更正还是进一步确认但解决方法不应在会上讨论和确定



评审 A process or meeting during which a software product is presented to project personnel,

managers, users, customers, user representatives, or other interested parties for comment or approval.

过程或一个会议软件工作产品被演示给项目人员用户客户代表或其他相关组织

争取他们的意见或批准

审计 An independent examination of a software product, software process, or set of software

processes to assess compliance with specifications, standards, contractual agreements, or other criteria.

对软件工作产品过程的第三方独立检查确定与规格标准合同或其他规范的一

致性

可以看出除审计以外其他三者虽各有侧重点但功能有所重叠在IPD-CMM 3.0 体系

规范中我们统一使用Review来描述这类活动泛指标识和发现问题和缺陷的工程过程

Review是十分重要的质量保证活动关于如何组织有效的Review 请参考QAM01

Review 流程和QAM01G01 Review 指导书的详细说明相关要点提示如下

� 组织正式的评审评审组织的散漫会严重影响评审人员的重视程度从而影响评

审效果甚至变成走过场正式的评审过程包括以下要点

ü PL确定进入Review阶段指定评审组织者 Moderator 安排评审评审组织

者应熟悉Review流程必要时请QA协助一般作者不能担任组织者

ü 评审组织者与作者和CMO一起确定Review的工作产品文档或代码等确

定Review重点

ü 评审组织者确定评审专家包括指派讲解员记录员等

ü 记录员准备问题记录表格Review Form 并熟悉问题严重程度分类方法参考

QAM01G01

ü 评审组织者将待Review的工作产品 Review说明问题记录表格 Checklist

发送给所有Review专家建议应提前两天并提醒Review专家进行预审

发现的问题录入Prereview Form QAM01F03

ü 必要时要召开Review介绍会议帮助Review专家熟悉工作产品和流程

ü 在参加正式Review会议之前 Review专家将发现的问题反馈给评审组织者

评审组织者使用Review Summary Form(QAM01F04)将问题进行汇总在会上

对汇总的问题进行确认



ü 召开Review会议讲解员对工作产品进行讲解 Review专家根据预审结果或

新发现的问题提出意见记录员将确认后的问题和问题的严重程度分类等

信息记录进Review Summary Form

ü 作者在会后对发现的错误和问题进行统一修改并刷新Review Summary

Form 作者修改说明栏

ü 组织者检查作者对工作产品的修改并更新Review Summary Form 是否已更

正栏确定是否召开附加会议可选以便对疑问进一步确认

ü 工作产品和Review Summary Form 发送批准签发并归档

� Review不一定要走电子流 CMM流程没有规定Review一定要走Review电子流有

些项目组发现走电子流的方式效果并不好

� 注意使用Review Form 而不是使用会议纪要来记录Review中发现的问题

� 组织者应控制Review会议的时间和工作量 Review会议如果超过两小时应安排中

间休息 QAM01G01建议一次Review工程文档不超过40页代码不超过500行否

则应分多次Review来进行

� 不要把Review会议开成学习会议学习可以用其他方式进行

� 不要把Review会议开成讨论方案的会议对错误的修改建议新方案的建议

等应在会后其他时间进行要明确Review会议的目的是发现问题

� 组织者要引导Review人员踊跃发现问题对好的Review人员提出表扬对一言不

发的要主动引导必要时提出批评

� 提出问题要对事不对人不要对作者进行人身攻击

重用代码是否会提高产品质量

现在代码重用越来越多可重用代码包括公司重用代码库网上的公开源码等

从流程和质量的角度看一种观点是重用代码不会减少多少工作量但可能提高产品质

量



要重用代码开发人员要熟悉被重用的代码检查它与新系统设计的一致性与新代码的

接口关系等还要与新代码一起进行测试这些工作都必须仔细进行所以在一种软件工作量

估计模型中定义对代码的重用甚至比编写新代码的工作量还要大

但重新编写代码是一个创造性的过程包括对新技术新算法新的数据结构的尝试这

些都可能引入错误而可重用代码往往已经过详细的设计和验证包括在被他人重用的过程中

发现和纠正了存在的错误这些因素决定被重用代码本身的缺陷相对较低从这个意义上重

用代码可以提高产品质量

什么是交付审计交付审计如何进行

交付审计即Deliverable Audit DA 这里的交付物指文档代码或一个版本发布 DA的

目的是在基线化之前由QA对交付物与需求或相关标准的一致性产出过程的有效性质量目标

的达标程度等进行验证

QA使用QAMCHK02 项目交付审计查检表对以下各类交付物进行审计

文档在完成Review并获批准后提交QA进行交付审计

代码在完成代码Review并经PL批准后提交QA进行交付审计

版本在版本开发完成和交付给客户前提交QA进行交付审计

QA完成审计验证提交审计报告模板 QAM02F07 给项目经理项目经理应对审计发

现的问题进行更正处理并关闭问题

什么是基线审计基线审计如何进行

基线审计即Baseline Audit BA 属于配置管理的范畴目的是检查项目配置管理的有效

性配置管理流程的一致性和基线建立的质量

BA由QA和项目备份CMO或其他项目的CMO一起在DA问题关闭而且交付物基线化之后

项目阶段结束之前进行审计使用CMPCHK01 基线审计查检表为参考进行检查

QA完成审计验证提交审计报告模板同DA使用QAM02F07 给项目经理项目经理

应对发现的问题进行更正并关闭问题



什么是内部质量审计内部质量审计如何进行

内部质量审计是质量部的内部审计组 IAG 对项目过程质量工作产品质量的综合审

计这种审计一般一次审计多个项目结果要通报到管理层

内部质量审计按QAMCHK01 内部质量审计检查单主要对项目文件夹配置库的内容

进行检查包括审计准备会议现场访谈审计总结会议等过程参考项目会议审计会

议了解会议的主要内容和过程

通过审计 >改进的不断循环项目的过程质量和产品质量得到切实保证



第二部分

项目计划阶段

计划阶段有哪些主要活动主要的输出是什么

IPD-CMM的计划阶段是对软件项目执行的规划部署过程

计划阶段要完成的工作包括

� 对SOW/AR进行Review

� 根据SOW/AR进行项目估计预测

� 根据与QA的协商结果制定项目过程手册PHB

� 根据项目估计 PHB SOW制定项目计划PPL 内含质量保证计划 WBS

� 制定项目的配置管理计划CMP 可由PL在CMO协助下写作完成

� 建立项目文件夹和VSS配置库

� 标识项目风险制定风险管理计划风险管理表格

� 制定项目的缺陷预防计划 DPP

� 组织对PHB PPL CMP DPP的评审

� 项目度量表格的初始化项目信息分配需求数估计规模估计工作质量指

标初始计划等

� 召开项目开工会项目正式启动

计划阶段的主要输出包括

� 项目估计结果

� 项目过程手册

� 配置管理计划

� 缺陷预防计划

� 项目计划包括质量保证计划和风险管理计划

� WBS



什么是SOW 什么是AR 从哪里获得这些项目输入

SOW即Statement of Work, 工作任务书 AR即Allocated Requirement, 分配需求两者是

IPD向软件开发项目组的工作输入是项目组成立和开发活动的依据 AR可以是独立的文

档或附在SOW中

PDT负责完成SOW 通常指派系统工程师或者PDT开发代表完成并下发到项目组

SOW的模板在IPD-RDM 中可从http://cmm.huawei.com 站点下载或向QA索取

项目组对SOW/AR进行Review 着重注意什么问题

SOW/AR是软件项目的工作输入因此项目组的第一件事情就应该是对其进行详细

Review 检查任务工作范围是否明确界定分配的需求是否清晰是否存在风险有没有显

式或隐式的错误进度要求是否合理等如果发现问题在这个阶段就应该与PDT澄清

请对照PJMCHK13 工作任务书查检表完成对SOW的Review

项目组完成对SOW的Review 发现的问题全部澄清后请PDT开发代表签发SOW PL将

SOW / AR和PDT开发代表的签发记录存放在项目文件夹\CI\Business\SOW 和AR目录下项目进

入计划阶段

在初始阶段还应完成的工作包括PDT开发代表向质量部 EPG申请项目ID 向质量部申请专

职QA PL与QA召开一次流程讨论会讨论确定项目执行IPD-CMM流程的方法包括是否有过

程裁剪要突出哪些重点培训需求和策略由QA协助初步确定IPD-CMM相关角色的任命

在QA的指导下建立项目文件夹等

什么是项目计划PPL 它和WBS 是什么关系

制定项目计划是计划阶段的核心工作所以先要明白什么是项目计划PPL 什么是WBS

PPL是Project Plan的缩写 WBS是Work Breakdown Structure的缩写



我们倾向把WBS简单理解成那个MS Project 文件它实际上包括两方面的信息任务的逐

层分解和任务执行进度的定义

而在IPD-CMM 流程体系中项目计划PPL是另一篇Word文档

如果出现混淆是因为有时候我们将两者都翻译成项目计划

如果将WBS理解成进度表它更准确地讲是项目执行的Schedule.

而 Plan 包括了规划的内涵

美国传统词典 Plan

A scheme, program, or method worked out beforehand for the accomplishment of an

objective:

计划是完成某一目标之前订立的框架程序或方法

a plan of attack.

进攻的计划当然不应仅仅包括时间表

IPD-CMM 的项目计划 PPL 是对项目执行过程的总体规划是项目实施的基础它包

括

� 项目工作任务工作范围的定义

� 项目人员组成职责汇报关系的定义

� 项目工程过程的定义

� 项目的配置管理质量保证过程定义

� 项目的管理过程定义

� 项目资源需求的文档化

� 项目外包需求和外包管理策略

� 项目的培训需求定义

� 项目的风险管理策略

等方面的内容是项目执行的纲领性文件因此项目经理必须认真制定完成PPL

PPL中包括简单的阶段里程碑完成时间表定义更详细的进度表引用项目的WBS即可

IPD-CMM 3.0 项目计划的模板是PJM03T06 WBS 模板是PJM03T10 请从CMM站点下载

或向QA索要相关的模板制定项目计划和项目WBS.

要制定一个科学的切实可行的项目计划应该从对项目的规模工作量估计开始



什么是项目估计如何进行项目估计

软件估计预测是指依据历史数据和估计者的经验按照一定的程序对软件项目的规

模工作量资源需求进行预测和推算的过程项目估计是制定/更新项目计划的基础

要进行软件估计先应打消几个疑问

� 软件估计是否准确

既然是估计就是一种近似目前业界对软件估计没有统一的做法 CoCoMo和

Wide Delphi是最常用的方法实际上业界对一些概念也没有统一的定义比如

要估计的软件的规模通常使用有效代码行但没有一个可以普遍接受的对C的有

效代码行的定义况且还有层出不穷的其他编程语言进度虽然可以用日期来衡

量但就象Frederick在神秘的人月中提到的进度也是一个模糊的概念给项

目组两周的时间他们有两周的做法给三周的时间他们有三周的做法

这里解决方法是走自己的路建立自己的标准包括统一代码行统计工具和估

计流程并在可能的情况下取得最接近的估计值通过不断的经验积累软件估

计的精度就会不断提高

� 项目进度表高层已经确定估计还有没有必要

有必要

由最熟悉系统的人参加的按照流程得到的估计是我们当前能得到的对软件规

模工作量和进度的最好近似如果没有这个过程我们对高层进度要求的承诺

就是盲目承诺

估计与既定进度之间存在偏差是正常的如果是这样项目经理可以

w 依据估计结果与高层勾通协商更改进度安排

w 要求增加项目组人员投入

w 调整版本计划减少当前版本实现的功能分多版本开发

w 裁剪开发过程降低质量指标

w 寻求使用中间件等技术提高生产率等

不管使用了什么办法通过软件估计和协商项目组对项目进度和资源需求等做到了心中

有数对进度的承诺更严肃项目实施更有信心



IPD-CMM 3.0流程中提供了Pert sizing和WideBand Delphi两种估计工具 Pert Size估计方法

相对比较简单估计的准确性较低 Wideband Delphi估计比较准确建议项目组使用后者进行

项目估计

软件估计有一定的技术性 PL应要求QA参与完成软件估计过程估计一般以软件估计会

议的形式进行

� 项目经理从项目组中挑选至少4名专家参加估计他们应是项目组中对系统了解最

深刻人员并有软件开发实际经验

� 估计协调员或PL 准备WideBand Delphi PJM04F01 估计表格包括汇总表格

和打印的工作表格

� 协调员进行估计过程介绍

� 估计小组介绍软件系统模块划分应于会前准备和假设约束条件比如编程

语言代码重用等注意模块划分越详细具体估计结果越准确

� PL指定各模块小组负责人在白板上列出模块主要功能并向小组进行讲解

� 协调员将模块划分模块功能录入估计表格并要求4名估计专家按模块进行软件

规模的第一轮估计代码行

� 协调员将估计结果录入估计表格并公布偏差情况使用便携机和投影仪

� 根据偏差情况协调员确定是否进行下一轮估计或规模估计结束建议偏差不超

过20 项目组可以调整并不超过3轮

� 协调员将在估计过程中使用的假设约束和历史数据录入估计表格

� 协调员录入标准生产率数据 Excel表格自动计算总的工作量

� 协调员根据选定的生命周期模型录入标准的阶段工作量分布比例质量部有标

准分布数据供参考 Excel表格自动计算各阶段的工作量分布

� PL和协调员根据目前计划的人员投入计算项目进度

� 与PDT要求的进度计划若有比较如果存在偏差按上一节所述的方法进行

调整

当各方对估计结果达成一致后请PDT开发代表批准项目估计表格 PL将其存档到项目文

件夹并开始以此为基础制定项目计划



什么是项目过程手册 PHB 如何裁剪过程制作项目过程手册

PHB即Process Hand Book的缩写是项目要遵循的软件开发过程的文档化

既然IPD-CMM推荐使用的都是V模型为什么还要写PHB

IPD-CMM 的PHB模板不是对V模型的重复描述它使用表格的方式对软件开发各阶段进行

详细定义包括对各阶段的

� 入口条件

� 活动

� 阶段输出产物

� 验证方法等

PHB还列出项目各阶段对应的IPD-CMM 3.0 中过程文档表格模板 Checklist等

由于项目的大小和环境不同项目可能需要对过程进行裁剪项目组首先必须与QA或

EPG进行裁剪过程的讨论在达成过程裁剪一致意见之后在PHB中清楚描述

项目经理使用PJM03T08作为模板来写作项目的过程手册

PL 完成PHB初稿发送包括QA在内的相关人员Review, Review问题关闭后将PHB发给质

量部EPG批准并备案然后请PDT开发代表签发PHB

项目经理如何写作项目计划

参考什么是项目计划PPL 它和 WBS 是什么关系一节了解项目计划的内容和作用

PL按以下步骤完成软件项目开发计划

� Download PPL模板或向QA索要最好再有一个样例

� 熟悉模板有不清楚的地方向QA求助同时可以对模板进行补充或修改但需与

QA协商

� 项目估计是项目计划写作的重要输入之一因此项目计划写作之前项目组必须

先完成项目估计

� 应先完成PHB 确定项目的生命周期模型

� 确定项目组的质量目标可以根据所在部门的能力基线向QA索要以及

SOW中的质量要求确定项目组的质量目标



� 确定项目各个角色及其职责关键人员要考虑备份

� 质量保证活动方面请参考PPL模板或请QA协助制定

� 按确定的模板写作项目计划PPL

项目计划写作完成之后 PL需要组织包括PDT开发代表 QA TC CMO 项目组成员进

行Review 使用PJMCHK10 作为检查单澄清关闭Review发现的所有问题

如何召开项目开工会会议内容有哪些

项目开工会的主要作用是审议通过项目计划文档取得项目组成员和相关支持部门的承

诺项目计划文档正式基线化项目正式开工

这里提到的项目计划文档包括

� 项目过程手册

� 项目计划文档PPL 内含质量保证计划

� 项目WBS

� 配置管理计划

� 风险管理计划

� 缺陷预防计划

� 测试策略等

项目开工会作为计划阶段的最后一项活动在以上文档就绪后由项目经理主持召开参加

人员要包括

� 项目组成员

� QA

� PDT开发代表

� 测试协调员

� 文档开发协调员

� 其他相关组代表比如培训组物料组对外合作部系统部测试部有依

赖关系的项目组代表等



项目计划 WBS CMP 风险管理计划缺陷预防计划在项目开工会上进行确认得到项

目组成员和相关支持组的承诺

开工会后 PL把PPL发给QA和PDT开发代表批准 C.O.O签发发送测试策略给PDT开发

代表和TC批准其他项目计划包括配置管理计划风险管理计划缺陷预防计划 WBS 发送

给QA和PDT开发代表批准然后 PL将各计划文档放在项目文件夹相应目录下基线化

PJMCHK04 项目开工会检查单可以用来在会前使用检查是否有遗漏事项

项目需求阶段

需求阶段有哪些主要活动主要的输出是什么

需求阶段是软件生命周期的一个重要阶段也是决定性的一个阶段一份清晰准确的软件

需求规格说明书是项目成功的基础而与之对应的系统测试计划实际上是确定了系统的验证标

准这些都是这个阶段的产物

需求阶段的活动可以分为两种类型需求工程活动和需求管理活动

需求工程活动包括需求的收集需求的理解需求的分析需求的描述输出是需求规格

说明书

需求管理活动主要是需求的跟踪和变更管理包括制定和实施需求变更流程建立和维护

需求跟踪矩阵保证需求变更的有序进行并保证需求在后续的设计实现验证过程中的可回

溯性

IPD-CMM 定义项目需求阶段的活动包括

� 召开阶段开工会项目经理对阶段任务进行介绍和动员 QA给项目组进行需求阶

段相关流程模板方法等方面的培训

� 项目组学习讨论SRS 和系统测试计划模板必要时进行修改和补充确定项目

组统一使用的模板包括使用统一的需求标号方法统一的描述风格等

� 在充分理解产品级需求或开发合同的基础上写作软件需求规格说明书

� 组织SRS评审注意使用正确的Review表格记录Review发现并跟踪关闭

� 根据SRS写作系统测试计划和用例 TC指导

� 系统测试计划和用例评审



� SRS STP 包括用例批准基线化

� PL组织召开阶段结束会议

需求阶段的输出

� 软件需求规格说明书SRS

� 系统测试计划STP 包括系统测试用例

� 更新的需求跟踪矩阵

� 更新后的项目度量表格等

如何组织项目组输出一篇优质的需求规格说明书

完整描述需求工程超出本手册的范围这里给出以下要点提示

� 召开技术讨论会不要急于写作SRS文档之前多组织技术讨论对系统需求或

收集到的需求进行理解分析分类和确认

� 确定模板认真研究IPD-CMM 提供的SRS模板并参考样例明确各章节的写作

方法如果必要可以对模板进行裁剪补充及进一步细化

� 统一编码方案如果不对每个需求进行编号命名后续的需求稳定度计算需求

跟踪就无法进行每个需求都应有一个唯一的ID IPD-CMM给出的需求标识方法

是 SRS.TYPE.FI.NNN :

ü SRS 前缀

ü TYPE 需求类型

ü FI: 需求功能缩写

ü NNN 编号

比如 SRS.INTF.PRN.001 一个打印接口需求

参考REP01 - “软件需求管理规程”得到更详细的信息

� 好的需求标准包括

ü 清晰性描述要准确不要有二义性

ü 唯一性不要有隐含的重复



ü 完整性描述要完备

ü 一致性各需求之间不要有冲突和不一致的地方

ü 可实现性

ü 可验证性或可测试性

ü 可跟踪性

� 原型开发如果需求不是很确定可以在项目生命周期中安排一个原型开发阶段

Prototype 向QA索要原型开发方法的指导

� What 注意需求阶段只关注What 不要关注How 如何实现在HLD和LLD考虑

为什么要进行需求跟踪可以使用哪些工具进行需求跟踪

实施需求跟踪可以保证分配给项目组的所有需求在设计编码测试各阶段都得到覆盖

并有清晰的可回溯性帮助发现可能发生的遗漏和冲突

IPD-CMM 推荐使用RTM表格或rManager需求管理工具进行需求跟踪 RTM是一个Excel表

格模板 REP01F01 使用相对方便 rManager是质量部基于SQL Server 开发的一个需求管

理工具功能完善项目组可以选择使用

每个阶段的工程文档在提交Review之前都应该进行需求跟踪矩阵或rManager数据库的更

新以提前检查是否有遗漏或冲突

CMO在SRS阶段要完成哪些活动

CMO在SRS阶段的主要任务是对SRS文档和系统测试计划文档的配置管理

� 参考PJM01 项目文档控制流程给SRS文档和系统测试计划文档分配文档

ID 并通知相关人员使用特别是SRS分离成多篇文档时 CMO应统一给出编号

� 保证项目组使用正确的SRS模板

� 参照配置管理如何管理文档一节对SRS和STP进行配置管理

� 将批准和签发后的SRS和STP纳入配置库并进行一次配置状态发布

CMP01F01



� 配合QA进行交付审计和基线审计 DA&BA 并关闭问题

� 进行一次配置库备份

� 在阶段结束会议上向项目组通报配置管理的执行情况

MC在SRS阶段要完成哪些活动

度量协调员 MC 的职责是在项目执行过程中及时收集度量数据这里讲的及时很

重要否则数据就有可能丢失或失准

MC在SRS阶段要收集的数据包括

� SRS阶段的实际开始和结束时间在SRS阶段结束会议之前收集

� SRS和STP文档的规模页数测试用例数

� SRS阶段的实际工作量从Time Sheet 工作日志或其他使用的工具中导入

� SRS 和STP Review发现的总缺陷数包括严重级别在Review正式结束后马上收

集并向PL和QA报告相关的缺陷密度与质量目标的差距情况

� 如果项目在SRS后期进行了软件重估计把重估计的软件规模工作量进度数

据填入度量表

� 如果项目的计划进行了更新把刷新后的计划时间录入度量表 Re-Plan 区域

� 向PL提供度量数据 PL将要用到这些数据准备阶段结束报告

� 配合QA的审计活动

� 在SRS阶段结束会议上协助PL说明度量工作执行情况质量目标完成情况进

度偏差缺陷密度等

QA在SRS阶段要完成哪些活动

QA在SRS阶段的质量保证活动包括

� 在阶段开始向项目组提供SRS STP流程模板方法论等方面的培训 STP培

训也可在STP写作真正启动前在进行

� 向项目组提供SRS STP模板和样例



� 引导确保项目组制定统一的SRS编码方案符合流程要求

� 提醒PL组织相关的需求分析活动

� 在SRS STP 的写作过程中选择抽查模板编码方案写作格式的遵守情况

� 在Review之前提醒CMO暂时冻结版本并提供Review Form 必要时进行Review过

程的培训

� 提醒PL指定专人负责需求跟踪矩阵的更新 RTM或rManager工具

� 参加Review过程重点监督参加人员的参与度问题记录过程和评审覆盖率

� Review完成后监督发现问题的关闭和文档的更新要适当抽检

� 提醒CMO完成相关的配置管理和基线化工作

� 提醒MC收集有关的度量数据

� 阶段结束前进行DA&BA审计

� 提醒PL使用正确的模板准备阶段结束报告

� 参加阶段结束会议分析度量数据对整个过程的质量保证活动进行评价协助

项目组分析过程中遇到的问题并确定纠正和预防措施

项目概要设计阶段

概要设计阶段有哪些主要活动主要的输出是什么

概要设计阶段主要完成概要设计文档集成测试计划文档的写作

设计阶段特别是概要设计将确定系统的实现框架软件产品的设计缺陷将根本决定产品的

性能和质量并且很难修正

著名的软件工程大师Booch在他的经典著作面向对象的分析与设计一书中有近似如下

的描述如果你是要给你的宠物搭一个Dog House 你可以马上动手但如果你是要建一个高

楼大厦没有人会反对要先有一个设计蓝图形象地说明了系统设计的重要性

为了保证设计质量 IPD-CMM 定义概要设计阶段的活动包括



� 召开阶段开工会项目经理对阶段任务进行介绍和动员 QA给项目组进行概要阶

段相关流程模板方法方面的培训如果使用了专门的工具比如使用Rational

Rose进行面向对象的系统设计 QA还要协调组织相关的专项培训

� 项目组学习讨论HLD 和集成测试计划模板必要时进行修改和补充确定项目

组统一使用的模板注意

ü 项目组可以根据使用语言与设计方法的不同选用不同的设计文档模板包

括IPD-CMM推荐的面向过程的模板 IEEE的模板工具配套的模板等或对

模板进行裁剪只要经QA认可就可以使用

ü 在设计文档的写作过程中要注意对需求的映射即一个模块或类实现哪些

需求要写清楚可能重叠这样才可能进行需求跟踪矩阵的维护

� 确定方法和模板后 PL要组织技术讨论会对设计方案进行反复论证

� HLD写作

� 集成测试计划和用例写作在HLD完成初稿后就可以开始

� 组织对HLD 集成测试计划和用例的正式Review

� HLD 集成测试计划和用例批准基线化

� PL组织召开阶段结束会议

概要设计阶段的主要输出物有

� 软件概要设计说明书HLD

� 集成测试计划ITP 包括集成测试用例

� 更新后的需求跟踪矩阵

� 更新后的度量表等



如何控制概要设计和详细设计的分解粒度

IPD-CMM目前的概要设计文档模板是面向结构化设计的在设计过程对系统进行自顶向下

的3层分解

概要设计的3层

子模块的分解描述子模块功能接口2层

系统的模块分解描述模块功能模块之间的接口1层

主要描述设计的系统与外部系统的关系0层

主要内容层次

设计模块分解粒度

整个做HLD的子系统模块的规模应该在4,000 20,000行之间模块的规模

每个函数的规模不要大于200行否则将来的单元测试和函数集成工作量

比较大函数大小

概要设计划分的最低一级模块就是单元测试的对象也就是我们所说的

单元函数组从单元测试角度来考虑希望划分的模块内函数的调用层

次不超过3层整个HLD的分解不应该超过3层

模块层次

概要设计中模块要分解到单元测试模块单元模块的接口交互关系需要

在HLD中明确描述出来单元模块到函数的分解函数的具体实现细节在

LLD中描述

模块分解

请参考软件设计指导书 DVP05G01 得到更详细的指导信息

CMO在HLD阶段要完成哪些活动



CMO在HLD阶段的主要任务是HLD文档和ITP文档的配置管理

� 参考PJM01 项目文档控制流程给HLD文档和ITP分配文档ID 并通知有关

人员使用特别是HLD分离成多篇文档时 CMO应统一给出编号

� 参照配置管理如何管理文档一节对HLD和ITP进行不同阶段的配置管理

� 将批准后的HLD和ITP 包括用例纳入配置库并进行一次配置状态发布

� 配合QA进行交付审计和基线审计 DA&BA 并关闭问题

� 进行配置库备份

� 如果在该阶段发生变更申请负责提供CR模板 CMP01F04 并监控CR填写的

规范性和实施过程必要时提醒PL召开CCB会议进行论证

� 在阶段结束会议上向项目组成员通报配置管理的执行情况

MC在HLD阶段要完成哪些活动

MC在HLD阶段要收集的以下数据并填入项目度量表

� HLD阶段的实际开始和结束时间在HLD阶段结束会议之前收集

� HLD ITP文档的规模页数集成测试用例数

� HLD阶段的实际工作量从Time Sheet 工作日志或其他使用的工具中导入

� HLD 和ITP Review发现的总缺陷数包括严重级别在Review正式结束后马上收

集并向PL和QA报告相关的缺陷密度与质量目标的差距情况

� 如果项目计划进行了更新将刷新的项目计划时间录入度量表 Re-Plan 区域

� CR数目向CMO索要有关数据并录入度量表需求变更删除修改数量

� 向PL提供度量数据 PL将要用到这些数据准备项目结束报告

� 配合QA开展对度量活动的审计

� 在HLD阶段结束会议上协助PL说明度量工作执行情况质量目标完成情况进

度偏差 HLD缺陷密度需求稳定度等



QA在HLD阶段要完成哪些活动

QA在HLD阶段的质量保证活动包括

� 在阶段开始向项目组提供HLD ITP流程模板方法论等方面的培训 ITP培

训也可在ITP写作真正启动前在进行

� 向项目组提供正确的HLD ITP模板和样例

� 提醒PL组织相关设计方案的讨论和论证

� 在HLD ITP 的写作过程中选择抽查模板写作格式的遵守情况

� 在评审之前提醒CMO暂时冻结版本并提供Review 问题发现表单必要时进行

Review过程的培训

� 提醒PL安排需求跟踪矩阵的更新

� 参加Review过程重点监督参加人员的参与程度问题记录过程评审覆盖率

� Review完成后监督发现问题的关闭和文档的更新要适当抽检

� 提醒CMO完成相关的配置管理和基线化工作

� 提醒MC收集记录有关的度量数据




项目组分析过程中遇到的问题并确定预防措施

项目详细设计阶段

详细设计阶段有哪些主要活动主要的输出是什么

详细设计阶段相对比概要设计阶段的技术难度低因为详细设计是对已经划分的模块进行

实现设计有些情况下可以使用伪代码描述语言进行主要输出是详细设计说明和单元测试计

划

IPD-CMM 3.0 推荐的详细设计说明书模板是DVP05T03



有些项目将概要设计和详细设计合并在这种情况下该阶段应覆盖两个阶段的工程活

动并使用DVP05T04作为设计说明书的模板

依照V模型对应详细设计的是单元测试计划无论是系统测试计划集成测试计划还是

单元测试计划 IPD-CMM 3.0 使用统一的模板DVP02T04编写测试计划文档并使用DVP02F04

的 Test Case 工作表作为模板设计测试用例

除了这些区别详细设计与概要设计的操作方法类似请参考概要设计一节完成本阶

段的活动

项目编码阶段

编码阶段有哪些主要活动主要的输出是什么

编码是对系统的实现是我们软件开发人员最熟悉的活动编码阶段的输出是经过

Review的代码更新的需求跟踪矩阵更新的度量表等

为在编码阶段保证代码质量除了与其他阶段类似的管理活动以外 IPD-CMM 规定的其

他质量保证活动还包括

� 使用编码规范统一编码风格 IPD-CMM 现在建议的编码规范包括

ü 软件编码规范总则

ü 单板编码规范

ü 数据库编码规范

ü 主机编码规范

ü 终端编码规范

请从IPD-CMM 站点下载或向QA索要相关编码规范必要时请QA进行相关的培

训

一个好的实践是让项目组所有编码人员先各自编写一个简单函数然后PL组织点

评并确定项目组最终须遵守的规则

� 技能培训如果项目编码使用了新的或特殊的技术 PL应协调组织相关的培训

比如JAVA编码技术培训 J2EE培训等使所有人员掌握相关工具的精髓和技巧



� 使用工具提高效率和统一编码风格质量部现在有一些公司开发的小工具 Source

Insight 是功能强大的代码编辑工具并支持宏北研基于此工具开发的Quicker 可

以支持自动生成函数头自动产生注释等很多功能推荐使用

� 在编码过程中开展PSP自检活动即每天开发人员确定固定的时间一般在下班

前对自己的代码进行检视如必要请QA进行PSP方面的培训

� 使用静态检查工具对代码进行检查 C和C 使用PC-LINT JAVA使用JTest

这些工具虽然比较死板但往往可以引导开发人员发现代码中的错误请在代码

提交正式Review之前使用并对所有错误和告警进行检查

� 组织严格的代码Review 项目经理和编码人员必须认识到代码中隐藏的问题是

不可能通过测试来全部发现的代码Review是IPD-CMM中控制软件质量的核心手

段请在QA的协助下组织对代码的正式Review 保证100 的覆盖率和过程有效

性使用Checklist 帮助发现问题

CMO在编码阶段要完成哪些活动

CMO 在编码阶段的主要任务是进行代码的配置管理

� 按配置管理计划的规定建立代码的配置库结构

� 参照配置管理如何管理代码一节的提示管理Review之前 Review过程

Review之后的代码

� 如果在编码过程中发生对SRS HLD LLD的更改提醒填写相应的CR单并监

控更改过程

� 在Review完成后建立第一个代码基线如果之后再发生代码更改必须要求编

码人员先申请Check-Out 说明更改原因和修改涉及的源文件用VSS的Difference

功能检查代码的更改再Check-In

� 如果存在多人公用一个代码文件的情况如头文件等做好权限控制和协调

� 按更频繁的周期进行配置库的备份

MC在编码阶段要完成哪些活动



MC在编码阶段要收集以下数据并填入项目度量表格

� 编码阶段的实际开始和结束时间在编码阶段结束会议之前收集

� 代码的实际规模请使用QA提供的代码行统计工具对基线化之后的代码进行统

计

� 编码阶段的实际工作量从Time Sheet 工作日志或其他使用的工具中导入

� 代码Review发现的总缺陷数包括严重级别在Review正式结束后马上收集

并向PL和QA报告相关的缺陷密度与质量目标的差距情况

� 如果项目的计划进行了更新把刷新的后阶段项目计划时间录入度量表

Re-Plan 一节

� CR数目向CMO索要有关数据并录入度量表需求变更删除修改的数量

� 向PL提供度量数据他将要用到这些数据准备项目结束报告


� 在编码阶段结束会议上协助PL说明度量工作执行情况质量目标完成情况进

度偏差代码缺陷密度需求稳定度等

QA在编码阶段要完成哪些活动

QA在编码阶段的质量保证活动包括

� 在阶段开始向项目组提供编码规范培训

� 必要时协助PL为项目组提供其他专项培训比如编程技巧等

� 监控并协助CMO做好代码的配置管理

� 如果需要在Review之前为项目组提供Review流程的培训包括流程要使用

的表格过程控制方法等

� 监控在Review之前对代码的静态检查使用静态检查工具

� 在正式Review之前提醒CMO暂时冻结版本

� 提醒PL安排需求跟踪矩阵的更新

� 参加Review过程重点监督参加人员的参与程度问题记录过程和Review覆盖

率

� 监控对Review发现问题的更改和版本控制要抽检



� 提醒MC收集记录有关的度量数据




项目组分析过程中遇到的问题并确定预防措施



项目测试阶段

软件测试过程包括哪些活动项目经理如何控制测试的有效性

软件项目测试包括三种类型或阶段单元测试集成测试系统测试在本节集中描述

IPD-CMM 3.0对测试的过程要求包括

� 请QA进行有关测试流程和三类测试方法的专项培训

� 一定要有测试计划作为指导使用DVP02T04作为模板参照需求规格概要设

计详细设计分别制定系统测试计划集成测试计划单元测试计划并使用

DVP02F04的 Test Case 工作表作为模板分别设计系统测试用例集成测试用

例单元测试用例测试计划和测试用例必须经过项目组的Review 使用

DVPCHK03作为查检表和批准才可以被用来指导测试过程

� 尽可能使用工具辅助测试过程特别是单元测试工具可以保证覆盖率确保对

所有逻辑分支进行遍历

� 详细记录测试过程包括

ü 缺陷报告对测试过程中发现的问题使用CMM 过程库缺陷跟踪电子流

进行缺陷跟踪或使用DVP02F04的 Fault Report 工作表为模板提交缺陷报

告

ü 测试记录对每个测试用例使用DVP02F04的 Test Record 工作表记录执

行情况对于没有通过的测试用例要同时记录问题号

ü 测试报告一轮测试完成后使用DVP02F04的 Test Status Report 工作表

作为模板完成本轮测试状态报告各轮测试都完成后使用DVP02F04的

Test Report 工作表作为模板对整个测试过程进行总结报告

� 除非导致测试无法进行否则不要边测试边修改 CMO应全权控制代码否则

可能导致代码版本混乱一轮测试完成后 PL组织对发现问题进行集中修改修

改完成后才可以启动下一轮测试或回归测试

� 所有测试用例都一次性通过测试才可以结束



CMO在测试阶段要完成哪些活动

CMO在测试阶段阶段的主要任务是对代码进行版本控制

� 为测试提供一个完整的版本这应该是前一阶段编码阶段单元测试集成测

试输出的一个代码基线

� 在错误修改的过程中确保开发人员有权进行Check-In/Check-Out 操作并检查开发

人员是否添加注释添加注释的一个好的办法是在VSS的 Comments 域列出缺

陷编号和简要说明

� 如果有内部发布版本以DVP12F01为模板写作版本说明书完成版本发布

� 如果有对需求和设计的更改操作变更过程 CR

� 在每个阶段点比如一轮测试完成进行配置状态发布

� 按照配置管理计划中制定的备份频率进行配置库的备份

MC在测试阶段要完成哪些活动

MC在测试阶段主要的活动包括

� 测试阶段的实际开始和结束时间在测试阶段结束会议之前收集

� 代码的实际规模代码有变化时需进行再统计

� 测试阶段的实际工作量从Time Sheet 工作日志或其他使用的工具中导入

� 各类测试发现的总缺陷数包括严重级别在测试正式结束后马上收集并向

PL和QA报告相关的缺陷密度与质量目标的差距情况

� CR数目向CMO索要有关数据并录入度量表需求变更删除修改的数量

� 向PL提供度量数据他将要用到这些数据准备阶段结束报告


QA在测试阶段要完成哪些活动

QA 在测试阶段的活动包括

� 给项目组提供测试流程方法工具模板等方面的培训



� 确保测试执行活动是在测试计划包括测试用例获得批准之后进行

� 监督确保测试过程中缺陷的记录和跟踪关闭抽查

� 监督CMO做好对代码的配置管理

� 提醒MC收集缺陷度量数据综合检查项目度量数据的完整性


� 在过程中和阶段结束会议上协助PL对质量目标完成情况进行分析并建议相关

的纠正和预防措施

项目关闭

IPD - CMM 规定项目关闭有哪些操作

项目组完成系统测试的问题修改按发布流程发布版本后软件开发生命周期完成软件

项目关闭如果必要项目组可以转型为维护项目组或以其他方式继续IPD的后续活动

按IPD-CMM 3.0流程要求项目关闭操作主要包括版本的发布配置库和项目文件夹的归

档写作项目结束报告召开项目结束会议等活动

项目经理首先对照PJMCHK07 查检表对相关项目关闭事项进行检查然后以PJM03F02

为模板写作项目结束报告

项目经理召开由项目组成员 PDT开发代表 QA EPG代表其他功能部门代表参加的项

目结束会议会议主要以项目结束报告为线索对以下事项进行总结

� 项目范围任务的回顾

� 项目成绩的总结完成的工作产品包括最终产品的性能指标完成情况等

� 对项目执行的流程进行总结如果有流程偏差请特别说明

� 项目质量目标的完成情况对没有达到的质量目标进行原因说明和确认

� 总结项目执行过程中好的实践以及经验教训

� 对项目使用的重用部件的反馈信息

� 项目新提供的重用部件

� 项目对公共缺陷库的补充

� 项目对组织风险管理库的补充



� 配置库项目文件夹的归档情况确认

� 资源释放情况的说明人力 IT资源等

� 项目的遗留问题和建议的解决措施明确解决时间及责任人

� 对未来项目和流程改进的建议



第三部分

附录1 IPD-CMM 常用缩写词

AR Allocated Requirement 分配需求

BA Baseline Audit 基线审计

C.O.O. Chief Operating Officer 产品线总监/资源线总监

CCB Change Control Board 变更控制小组

CI Configuration Item 配置项

CMM Capability Maturity Model 能力成熟度模型

CMO Configuration Management Officer 配置管理员

CMP Configuration Management Plan 配置管理计划

CR Change Request 变更请求

CSA Configuration Status Accounting 配置状态发布

DA Deliverable Audit 交付审计

DP Defect Prevention 缺陷预防

DPP Defect Prevention Plan 缺陷预防计划

EST Estimation 估计

HLD High Level Design 概要设计

IAG Internal Audit Group 内部审计组

IPD Integration Product Development 集成产品开发

IT Integration Test 集成测试

ITP Integration Test Plan 集成测试计划



ITR Integration Test Report 集成测试报告

KPA Key Process Area 关键过程域

LCL Lower Control Limit 控制下限

LLD Low Level Design Specification 详细设计

MC Metric Coordinator 度量协调员

MDG Method Development Group 方法开发组

NA Not Applicable 不适用

NBNC Non Blank Non Comments 非空非注释

PAL Process Asset Library 过程资产库

PCB Process Capability Baseline 过程能力基线

PDB Process DataBase 过程数据库

PDT Product Development Team 产品开发团队

PHB Process Handbook 项目过程手册

PJM Project Management 项目管理

PL Project Leader 项目经理

PM Project Manager 项目经理

PPL Project Plan 项目计划

QA Quality Assurance Engineer 质量工程师

QMS Quality Management System 质量管理系统

R&D Research & Development 开发

RCA Root Cause Analysis 根本原因分析

RMP Risk Management Plan 风险管理计划

RTM Requirement Traceability Matrix 需求跟踪矩阵

SE System Engineer 系统工程师



SEI Software Engineering Institute 软件工程研究院

EPG Engineering Process Group软件工程过程组

SOW Statement of Work 工作任务书

SQA Software Quality Assurance 软件质量保证

SRS Software Requirement Specification 软件需求规格书

ST System Test 系统测试

STP System Test Plan 系统测试计划

STR System Test Report 系统测试报告

SW-CMM CMM for Software 软件CMM

SWE Software Engineer 软件工程师

TC Test Coordinator 测试协调员

TDC Technical Documentation Coordinator 资料开发协调员

TS Test Strategy 测试策略

UCL Upper Control Limit 控制上限

UGD User Guide (basic instructions) 用户指南

UT Unit Test 单元测试

UTP Unit Test Plan 单元测试计划

UTR Unit Test Report 单元测试报告

WBS Work Breakdown Structure 工作任务分解



附录2 CMM 及软件工程文献参考

TR24.93 SEI

TR25.93 SEI

CMM in practice Infosys

Software Project Management in Practice Infosys

Managing the Software Process Watts S. Humphrey

A Guide to the CMM Kenneth M . Dymond

Software Engineering Economics Boehm, B.W.

The Mythical Man-Month Brooks, F. P.

Object-Oriented analysis & design Rational, Booch



ipd-cmm 3.0 快速参考手册 - pudn.comread.pudn.com/downloads155/ebook/688936/ipd-cmm.pdf ·...

Documents