CMM课程笔记及作业

更新时间：2024-01-08 08:09:01 阅读量：教育文库文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

cmm课程推荐度：
相关推荐

思考题（一）：

1、试举例说明过程的各个要素；

2、为什么要进行需求管理，需求管理的主要任务是什么？

3、 CMM 2级的一个关键过程域，为什么不称“软件需求管理”，而称“需求管理”。 4、为什么要作风险管理，要在什么时候作？

5、你是否有在项目中因未作风险管理而遭受孙数的教训？是什么风险，应怎样对

待？

6、你认为在自己的组织中实施软件评审的主要障碍和实际困难是什么？ 7、简要说明软件质量保证工作的主要任务。思考题（二）

8、举出软件配置管理失误的实例、教训在哪里，加以分析。 9、变更管理的要点是什么？ 10、人们普遍认为软件企业实施ISO9000标准不应以是否获证论成败，那么应根

据什么？ 11、八项质量管理原则具有鲜明的实践性和指导性，请结合自己的实践，表明对其

中1－2项原则的体会。 12、软件企业按ISO9000标准监理质量管理体系最难解决的问题是什么？思考题（三）

13、 CMM的KPA为什么要规定五个共同特征？它和目标目标有什么关系？这一

设置方法对其他领域的管理有普遍意义吗？ 14、 SEPG、SQA、SCM、SCCB人员的职责是什么？ 15、在LPA SPE中对软件工程项目要做的工作规定了要求，这些要求必要吗？合

理吗？可行吗？

目标：

1、理解软件过程的概念

2、理解软件过程存在的问题及过程改进的意义 3、掌握软件工程管理的基本概念和方法 4、掌握ISO9000及CMM2、3级的要求基础：

1、先修课－软件工程

掌握软件工程的基础知识和软件开发方法 2、参加过软件开发工作

具有软件开发的实践经验 3、参加过软件管理工作

具有软件项目管理的实践经验教训比经验更可贵

特点：

1、实践性 2、年轻 3、文化

――――――――――――――――――――――――――――――――――――――― 内容：

1、软件工程与软件过程

2、软件工程管理专题

需求管理软件风险管理软件评审

软件质量和质量保证软件配置管理

3、 ISO9000：2000标准

4、软件能力成熟度模型CMM

－问题的提出－能力成熟度－CMM结构

－2、3的关键过程域 RM OPF SPP OPD SPTO TP SSM ISM SQA SPE SCM IC PR －CMM应用－CMM I简介

参考资料：

1、 Carnejie Mellon University, software engineering Institute

The capability Maturity Model guidelines for inprobing the software process reading ma Addison-wesley 1994

(CMM 1．1版文本，网上可见sei.cmu.edu) 2、郑人杰等，课本

3、能力成熟度模型（CMM）：软件过程改进指南，刘孟仁等，电子工业出版社200不 4、郑人杰等，软件工程高级教程，清华大学出版社

―――――――――――――――――――――――――――――――――― 教学形式

1、讲课―――――笔记（*部分）

－重点黄色标记

2、课后阅读 3、思考、讨论 4、作业题考试

1、时间：11月2日上午 9：00－12：00 2、形式：开卷笔试，独立完成，不得交流 3、要求：

a) 在讲课范围内

b) CMM 1.1文本的理解和使用

软件工程和软件过程

内容

一、发展二、焦点

三、软件开发流程四、软件生存期五、软件过程

一、发展 ―――程序设计语言 Programming Language ALGOL60 机器语言 FORTRAN 汇编语言 COBOL BASIC ―――软件 Software 1960 程序、文档、数据 ―――软件危机引出软件工程

1、软件开发工程化 1968 NATO 2、软件开发阶段与瀑布模型 3、软件工程标准

二、焦点 ―――目标少资源、高效益在人力投入、开发期、成本、质量诸方面求得最佳 ―――风险需求：不明与变更人员流动软件知识产权保护不存在绝对缺陷的软件产品 ―――成功的标志如期完成预算内完成达到质量要求（需求和期望）软件业和制造业的差异 §――设计――§――生产――§§运输§§仓储§功能度（缺图例）

三、软件开发流程（图二）

四、软件生存期 Life Cycle ―――软件生存期的概念

―――软件生存期模型瀑布模型计划－需求分析－设计－编码－测试－运行/维护定义阶段―――开发阶段――――运行阶段 XXX XXX

五、软件过程

1、过程思维

―――什么是过程将输入转化为输出的一组彼此相关的资源和活动（资源：人员、资金、设施、设备、技术和方法等）为达到一个预期的目的所实施的一系列不扎欧，例如，软件开发过程－IEEE－SDT－610 一组将输入转化为输出的相互关联或相互作用的活动―――ISO9000

―――过程的作用过程应支持业务目标，服务于目的的要求过程的实施把机构、管理者、人员和技术基础设施汇聚起来

―――过程思维

一个群体为了追求某个目标，把每个人的精力和活动汇聚在一起，用对过程的共同理解去考虑问题

过程思维和传统的任务思维有着本质的差别

―――所有产品的生产都是经历生产过程而得到的 ―――生产的每个阶段可视为生产过程的子过程，它可分为：直接过程：如市场调

研、产品设计、生产制作、检验、包装、储存等；间接错成（支持过程）：如检验手段的控制、不合格品的控制、人员培训、质量审核等

――－过程要素：

输入、输出、

活动、任务（作业）、资源、

测量与验证（☆）、效果：增值

―――过程间的关系包容邻接

交错（部分重叠）并行

2、软件过程

―――对软件过程的认识

尚未摆脱软件危机的困惑 ? 项目大、负责、要求高

? 用户对软件产品不满意；软件开发超支、超期、质量不佳

? 频繁发生软件缺陷引发的系统事故。

―――认识的转变

? 软件产品的质量很大程度上取决于软件过程（人员、技术、过程位于

三角形顶点，质量生产率位于中心） ? 关注点的转移（软件产品－软件过程）

3、ISO /IEC 12207软件生存期过程标准简介 ―――软件生存期过程

－基本过程（获取过程、供应过程、开发过程、运行过程、维护过程）－支持过程（文档编制过程、配置管理过程、质量保证过程、验证过程、确

认过程、联合评审过程、审核过程、问题解决过程）

－组织过程（管理过程、基础设施过程、改进过程、培训过程）

2003年10月12日星期日（第二课）

软件需求和需求管理

内容：

1、软件需求 2、需求工程 3、需求变更

4、需求变更控制要求 5、需求变更控制实施 6、可追溯性管理

一、软件需求

1、系统需求分析（图1、系统需求分配） 2、软件需求

（1）定义（IEEE－STD－610）

用户为解决某个问题，或成为实现某一目标，需求软件必须满足的条件和能力。

（2）软件需求的三个层次

? 业务要求 ? 用户要求

? 功能和非功能要求

非功能需求：

? 过程需求：交付需求，实现需求，遵循的标准 ? 性能需求：速度，容量，可靠性

? 外部需求：互操作性，伦理性，机密性，安全性，使用要求

图2软件需求的层次（参见书P59）

（3）质量功能展开（QFD－Quality Function Development）客户要求：

? 常规需求：客户明确提出

? 期望需求：并未明确提出的潜在需求

? 兴奋需求：客户未想到，若实现客户感到意外

（4）分配需求的实例

（图三）（P58 图）

3、 CMM 2级关键过程域需求管理（KPA RM）中对软件需求的解释：

分配需求（allocated requirements）：分配给软件的系统需求（1）分配需求包括（P57－58）第3点

――影响和确定软件项目活动的非技术性需求（在合同条款中规定），如：

? 要交付的产品 ? 交付日期 ? 里程碑

――软件的技术需求，如：

? 最终用户、操作人员、支持或集成的功绩 ? 性能需求

? 设计的约束条件 ? 编程语言 ? 界面要求

――用于确认软件产品满足分配需求的验收准则

（2）分配的需求应当是

? 以软件来实现是可行的，而且是适合的 ? 已得到清晰二正确的阐述 ? 相互之间是一致的 ? 可以测试的

同时，分配需求应当：

? 被管理和控制（如必要课纳入软件项目配置管理） ? 是制定软件开发计划SDP的基础 ? 是指定软件需求的基础

（3）与分配需求相关的组

? 软件估算组 ? 系统工程组 ? 系统测试组

? 软件质量保证组SQA ? 合同管理组 ? 文档支持组 ? 软件工程组

二、需求工程

1、需求工程＝需求开发＋需求管理

图4需求工程的构成（参见P60 图）

图5需求开发和需求管理（参见P60 图）

2、需求开发（参见P61）

（1）获取需求

? 确定目标用户、服务对象 ? 明确用户代表 ? 用户培训

（2）分析需求

? ? ?

（3）定义需求

? ? ? ?

（4）验证需求

了解实际业务和业务需求

分清功能需求、性能需求、使用需求…… 必要性可行性

编写软件需求规格说明（SRS）作用

要求：完整、正确、可行、无歧意、可验证形式：图表文字

三、需求变更

1、难于完全避免

图6 需求的变更（参见P61 图3.6）

2、需求变更原因分析

1) 单纯的用户因素 2) 市场形式变化 3) 系统因素

4) 工作环境和要求变化 5) 需求开发的缺陷

? 需求分析、定义和评审不充分 ? 与用户沟通不够

3、需求变更对软件开发的影响

1）使变更前开发工作和成果失效 2）返工成为被迫采取的对策

3）工作量及资源投入的增加使开发成本提高 4）项目完成时间后延

4、需求变更失控可能导致的后果

（1）未受控的需求变更引起需求和实现不一致

图P62

（2）受控的需求

变更使需求和实现一致图P62 （3）

5、需求变更风险的策略

（1）与用户充分沟通

? 与用户共同明确确定的需求的意义

表（参见P63表）

? 向用户说明需求不确切或频繁变更对开发工作的冲击 ? 使用户理解过多变更最终对用户不利

（2）与用户共同确定需求，作为合同附件，签字生效（3）合同中含有对需求变更的条款

（4）采用原型方法开发，或螺旋模型开发

（5）项目计划中适当留有余地（时间进度、人力投入、费用等）（6）严格实施变更控制四、需求变更控制要求 1、变更控制的策略

（1）所有需求变更必须遵循需求变更控制规程实施变更

规程：procedure 5W1H

? 什么任务描述 ? 什么目的、目标 ? 何时环节 ? 何处 ? 谁责任人 ? 如何作步骤以上文档化

（2）需求变更提出后是否被接受，应由专门的组织－变更控制委员会（CCB－

Change Control Board）审查决定

（3）不得以任何理由删除和修改需求变更的原是文件（4）应将已接受的需求变更通知到所有相关人员（5）已接受的需求变更应能追溯到批准的变更请求

（6）对项目的需求赋予状态属性，以利于需求变更的控制 2、需求变更影响的控制

按CMM2级RM KPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作：

? 识别 ? 评价 ? 风险分析 ? 编制文档 ? 制定计划

? 传达给受影响的小组和人员 ? 跟踪直至结束

3、变更控制的步骤

（1）提出变更请求

（2）审理变更请求，进行变更影响评估、评估内容包括：

? 变更所需人力投入

? 变更对原计划安排的影响 ? 估计变更引起的成本增加

（3）批准变更请求（4）取得用户的认可

（5）修订项目计划（6）实施变更（7）验证变更

图8（参见P64图3.8）

五、需求变更控制实施 1、需求变更请求

（1）内容

? 申请号 ? 变更说明 ? 变更类别 ? ……..

（2）需求变更请求实例（表三需求变更请求）参见P65表格 2、表四需求变更累积表参见P66表格

3、需求控制流

（1）需求状态及其演变

软件需求在后继阶段开发工作中将逐步展开，加以实现

在不同的开发阶段软件需求以不同的像是进行着状态的演变。例如：

? 需求阶段――从获取的需求到定义的需求

? 建议阶段――指定出项目计划以后演化为承诺的需求 ? 设计阶段――设计工作完成并在验收后成为设计的需求 ? 编码阶段――完成变慢和单元测试后成为实现的需求 ? 测试阶段――完成确认测手后成为完成的需求

图9 生存期各阶段需求状态的演变（参加P67图3.9）

六、可追溯性管理

1、需求可追溯性与需求变更控制

? 随着开发工作的进展需求将逐步扩张和演化 ? 各个开发阶段的工作产品之间存在的集成关系 ? 可追溯性矩阵

2、可追溯性管理的目标

? 使每一项需求均能追溯到 ? 前后继承关系的脉络清晰可见

3、两类不同的追溯 4、可追溯性矩阵

（1）矩阵的应用

? 防止遗漏

? 可为评审提供方便

? 便于进行变更影响追踪、分析和检索

（2）矩阵的建立和维护

表五追溯矩阵实例（参见P69表3.5）

（3）矩阵的应用

完整性检验

? 考察有无需求遗漏的情况 ? 有无冗余代码

? 检查所有性能需求是否已被测试用例测试 ? 对集成测试计划和系统测试计划进行交互检查需求变更控制

? 需求变更后相关的工作产品受影响的部分应随之变更 ? 更新需求规格说明，同时要更新追溯矩阵 ? 每增加一项需求，应在追溯矩阵中得到实现

软件风险管理

（参见P352）

一、什么是软件风险 1、困难和挫折难免

? ? ?

2、风险的特点

? ? ?

完成软件工程项目需有多种因素配合

不利因素会给项目造成困难、挫折甚至失败不以人们的意志为转移，是客观现时

可能发生的不利事件，发生的概率 R （0≤R≤1）会给项目带来损失

人为地加以干预，可以减少损失 “有备无患”、“有备少患”

3、 10种最为常见的软件风险（B.Bcehm）

A. 合格的人员不足

B. 进度家华和预算不切实际 C. 开发的软件功能不复核要求 D. 软件的用户界面不适用 E. 功能有多余的成分 F. 需求频变

G. 外购部件不能及时提供 H. 外包任务出现问题 I. 实时性能达不到要求 J. 过高估计计算机能力

4、风险分类

――依据危害性

? 成本风险：预算不准确造成

? 绩效风险：不恩嫩构实现预期要求，达不到预期效益 ? 进度风险：速度达不到计划要求

――风险涉及范围

? 项目风险：涉及预算、进度、成本、人员等 ? 技术风险 ? 商业风险

――风险可知性

? 已知风险 ? 可预知风险 ? ………

二、风险管理的任务 1、目标

? 识别风险

? 采取措施，降低风险的影响

2、策略

? 回避 ? 转移

? 迎接和接受风险的挑战，但将风险损失控制在项目资源可承受的范围

内

3、风险管理活动

图（参见P358图20.2）

三、风险评估 1、风险识别

? 检查单（Checklist）是识别的有力工具 ? 项目分解，便于识别高风险部分

2、风险分析

? 分析每个风险可能造成的影响 ? 给出可供风险大小比较的量值 ? 模型用于分析（COCOMO模型）

3、风险排序

? 风险概率

表（参见P360表20.2）概率取值范围低 0.0－0.3 中 0.3－0.7 高 0.7－1.0

? 风险影响

表（参见P360表20.3）

? 风险显露

RE（R）＝Prob（R）× Loss（R）式中： RE（R）：风险R发生可能造成的损失 Prob（R）：风险R发生的概率 Loss（R）风险R如果发生将会造成的损失

实例：回归测试的风险露计算图（参见P361图20.3） 4、风险控制

――风险策略

――针对已识别、分析和排序的风险判定风险管理计划 ――风险管理计划包括：

? 对该风险进行管理的必要性 ? 风险管理能提供什么条件 ? 实施风险管理活动的责任人 ? 风险管理采取的措施 ? 所需的资源

――采取的风险管理措施可包括：

? 收集和获取风险信息 ? 风险回避 ? 风险转移 ? 风险减轻

? 各种具体的，有针对性的措施，对人员风险，针对需求风险等

――风险化解措施 Infosys经验 P363 表20.4 ――风险监控

? 在外部影响因素改变时，风险形式与原评估结果不同 ? 实施跟踪监控，可作定期重新评估或在里程碑处重新评估

5、四、

2003年10月15日星期三（第三课）

软件评审（课本21章）目录

一、软件评审方法二、软件项目评审实例三、软件评审的定义

1、软件评审 2、缺陷

四、评审再若干国际标准中的要求五、软件评审的作用

1、及时清楚开发中 2、提高软件生产率 3、

六、正式评审的实施

七、评审实践中所显示的效益八、实施软件评审经常出现的问题九、做好软件评审的建议

一、软件评审方法 ――软件工程过程是一个重要的质量保证手段 ――是软件测试不可替代的 ――最早于1972年IBM公司实施了M.E.Fagan提出的代码检查法 ――时间表明了它的效果，后推广到针对需求、设计以至管理 ――许多软件工程标准都对其做了规范化要求

――被广泛采用后，展开成各种形式和不同的称呼，但本质上无太大区别。入如：

Inspection，Review，Formal Review（正式评审），以下着重介绍正式评审。

二、软件项目评审实例（图略）（图21.2 P376）（实例P376最下）

三、软件评审的定义

1、软件缺陷（Defect）

――对产品规格说明（Specifications）的偏离。如：规格说明规定：a＋b＝>c，而实

际产品不是。

――对客户/用户期望的偏离，客户/用户要求未纳入产品中（可能是规格说明疏漏，

也可能实现有问题）。

――Fault在硬件中称为故障，在软件中它和Defect同义。

2、缺陷有三种

――错误（Wrong）：未将规格说明正确实现（对规格说明的偏离）。 ――遗漏（Missing）：规定的或预期的需求未体现在产品 ――额外的实现（Extra）：规格说明未规定的………………….. 3、缺陷和事故（Failures）

――机械与建筑的比喻

――缺陷是软件内部的“裂痕”，在未影响到用户和系统运行时，并未表现出来。 ――当缺陷引发运行错误（Error）或产生负面影响时，构成事故，对我们造成伤害。 4、评审（Review）

――IEEE定义：评审是软件开发组之外的人员或小组对软件需求，设计或代码进行

详细审查的一种正式评价方法，其目的在于发现其中的缺陷，找出违背执行标准的情况以及其他问题。

――1994年，IEEE在软件评审和审核标准（IEEE Standard for Software Reviews and

Audits）中说：软件评审是一种对软件元素所作的正式的、同行间的评审活动，其目的在于验证软件元素满足其规格说明，并能符合标准的要求。

――与通过评审会来实施的正式评审不同，走遍通常是非正式的，特别是针对程序

而言。

――软件评审通常针对技术产品………………… (参见P379)

四、评审在多干国际标准中的要求

五、软件评审的作用（P383图切记切记。。。。。。）

八、实施软件评审常出现的问题（P398）

九、做好软件评审的建议

软件质量保证目录

一、软件质量的基本概念

二、软件质量的挑战

三、解决软件质量问题的实际困难四、软件质量国标

一、软件质量基本概念

1、质量：产品、体系或过程满足顾客和其他相关防要求的能力的一组固有特性。

要求：明示的、习惯上隐含的或必须履行的需求或期望；相关方：顾客、所有者、员工、供方、银行、行业协会等 2、软件质量：软件产品或软件过程为蛮子顾客和相关方质量管理

质量方针质量目标

质量策划质量控制质量保证质量改进

QP QC QA QI

3、质量管理

指导和控制组织的与质量有关的相互协调的活动。质量管理活动：

? 质量策划：确定质量目标，规定必要的作业过程和相关资源以实现质量目标； ? 质量控制：以大道质量要求为目的（测试、评审）； ? 质量保证：为大道质量要求提供信任（审核）；

? 质量改进：提高有效性（达到预期结果程度的度量）和效率（得到的结果与使用资

源间的关系）

软件质量控制

? 质量控制（J.M.Juran）

一个常规的过程，通过它度量实际的质量特性，并与标准比较，当出现差异时采取行动。 ? 软件质量控制（Donald Reifer）

软件开发过程中开展的一系列验证活动。，在开发的某些点检验所得到的产品在技术上是否符合前阶段指定的规格说明。 ? 质量控制的有效方法

――评审 ――递增式开发 ――根源分析 ――验证和确认（测试）

软件质量保证

? 有计划和系统性的活动，它对部件或产品满足确定的技术需求提供足够的信心（IEEE

软件工程术语标准）

? 基本任务式确保项目履行其对产品和过程的承诺；

? 是对软件质量计划的管理…，SQA并不保证软件的质量，而是确保软件质量计划的有

效性；

? SQA应贯穿于整个开发过程 ? SQA活动：

――为软件开发活动及其产品和所用资源提供独立的视角；

――依据标准来检查产品及其文档的复合型，软件开发流程的符合性； ――评审需求，设计和编码，以减少测试及其消除缺陷的成本。

目的对象做法举例责任人对谁负责质量控制使产品达到质量要求产品通过检测，找出缺陷分析原因，加以纠正测试（评审）质检人员对生产部分负责质量保证对达到质量要求提供信任过程（产品）收集、通报缺陷信息，促进解决评审、审核质保人员（第三方QA）对企业领导和用户负责

4、质量保证的作用

? 要注意区分

――质量保证 ≠ 质量控制，质量控制不能代替质量保证 ――质量保证 ≠ 质量管理

? 质量保证和质量控制互相制约，相辅相成，缺一不可，同样重要

5、影响软件质量的因素

图略

6、质量成本

生产成本：设备、人工......内部失败成本：返工、返修失败成本外部失败成本：退货、索赔、投诉、企业名誉损坏产品价格质量成本坚定成本：测试、评审、审核预成本：员工培训、质量体系监理、质量管理咨询、质量认证审核、过程评估利润

2003年10月16日星期四（第四课）

二、软件质量的挑战 1、软件质量事故的困扰

2、用户对软件工程项目成果评价统计 3、 Y2K的启示

4、软件开发面临的严重问题 5、 “有没有银弹”的争论

6、软件开发面临的严重问题（漫画）

三、解决软件质量问题的实际困难

1、软件开发各环节之间需保持协调一致 2、软件需求

? 用户提不清 ? 需求多变

3、软件质量的量化尚未成熟 4、软件测试技术的局限性

? 传统的测试方法多年来没有突破性进展

? 目前的测试技术现状是：发现一个缺陷便清楚一个缺陷，但无法回答软件中还有多

少缺陷

? 何时停止测试是个难题

5、我国软件企业在质量管理方面的弱点

? 工程化意识不足

? 管理意识差，认为管理束缚创造性 ? 重视编程（但不注意可读性），忽视文档编址，不愿作测试

? 标准意识薄弱，缺乏规程，许多工作因人而异，眉头统一的要求 ? 项目中不注意收集数据，经验难于积累

? 不注意工具的建设，不理解软件工具在软件开发中的作用

四、软件质量国际/国家标准（第18章）

1、 GB/T16260（idt.ISO/IEC 9126：1991）

软件产品评价――质量特性及其使用指南

? 该标准制定了―――6各质量特性和21个子特性 ? 评价方法可操作性不理想

质量特性子特性（P306两个表格） 2、 ISO / IEC FDIS 9126 （1－4）：1997－2001

信息技术软件产品质量质量模型内部质量外部质量使用质量

（P311 ，图）

图中×为新的ISO/IEC 9126增加的质量子特性 ×吸引行：软件产品吸引用户的能力

×***符合性：软件产品符合***相关的标准或约定（或法规）的能力 ×共存性：软件产品（P313，图）（P314，图）（P315，图）

3、 ISO/IEC 14598(1-6):1998－2000 软件产品的评价

（P326页图和文字）（P327页图和文字）

? 评价过程框架适用于上述：

――开发方的过程 ――获取方的过程 ――评价方的过程

? 差异：鉴于三种评价

五、软件质量保证的基本概念

1、质量保证QA――Quality Assurance

2、验证（Verification）

? 通过提供客观证据对规定要求已取得满足的认定（ISO2000：2000）

? 确定开展某项活动的软件产品能否满足此前一些活动对其提出的要求和条件 ? 确定软件开发周期中的一个给定阶段的产品是否达到前阶段确定的需求的过程

3、确认（Validation）

? 通过提供客观证据对特定的预期用途或应用要求已得到满足的认定

? 确定需求和最终的、已建成的系统或软件产品是否满足其特定的预期用途 ? 在软件开发过程结束时，对软件进行评价，以确认它和软件需求是否相一致的过程。

（图：验证与确认的关系）

4、评审（Review）

? 确定主题事项达到规定目标的适宜性，充分行有效性所进行的活动 ? 评价项目活动的状态和产品是否适合

4、审核（Audit）

? 获得客观证据并对其进行客观的评价，以确定满足审核准则（作为依据的一组方针、

规程或要求）的程度所进行的系统的、独立的、并形成文件的过程。ISO9000：2000 ? 确定与需求、计划和合同符合性（ISO/IEC12207：1995）

? 为评估是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和

特殊要求而进行的一种独立的检查。（GB/T11475：1995）

? 通过调查研究确定已指定的过程、指令、规格说明、代码和标准或其他的合同及特

殊要求是否恰当和被遵守，以及其实现是否有效而进行的活动。

六、软件质量保证过程（第7章）（ISO/IEC12207：1995 即GB8566：2001）

? 为软件产品和过程在项目生存期中符合规定的要求，并遵循已指定的计划提供足够

的保证

? 软件质量保证人员应有相应的授权，且不带偏见

? 可以是内部的，也可以是外部的。差别在于向谁提供信任。

七、软件质量保证方法（P128）

1、指定SQA计划，作为软件项目开发计划的一部分 2、按PDCA开展工作

3、在软件生存期的适当阶段

评审项目活动审核工作产品

以验证对使用规程和标准的符合情况 4、充分利用

其他过程，如测试过程

其他组织，如SCM组的评审、验证、确认、审核等活动结果 5、将评审和审核结果通报给项目经理或其他相关经理

6、评审和审核发现的问题无法在项目内解决时，上报给高层主管以求解决 7、 SQA各种活动讲求实效，切忌走过场

8、定期请有关方面平评审SQA工作，或是向有关方面征求对SQA工作的意见

软件配置管理（第8章）

配置（Configuration）－词其他领域中已有广泛的应用，只不过称呼有所不同，但都有其确切的含义。如原子结构的形态和组态…..

1、什么是配置管理

1）几种说法

? ISO 900－3的4.8中给出：配置管理是一个管理学科，它对配置项（包括软件

? ? 2） 2、

项）的开发和支持生存期给予技术上和管理上的指导。配置管理的应用取决于项目的规模，复杂程度和风险大小。

W.Babich认为，软件配置管理能协调软件开发，使得混乱减少到最小、软件

配置管理是一个标识、组织和控制修改的技术，目的是最有效地提高生产率。GB/T 11457：1995（软件工程术语）对配置管理的解释：

A．标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投

放和更动。记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 B．对下列工作进行技术和行政指导与监督的一套规范

一对一配置项的功能和物理特性进行标识和文件编制工作；一控制这些特性的更动情况；一记录

一含意：配置管理的对象，软件工程过程产生的所有信息项。一包括：计算机可执行的源代码。目标马等。

2003年10月17日星期五（第五课）

2、软件配置管理计划

――项目开始制定，作为软件开发计划SDP的一部分

――国家标准GB/T /2505－90 计算机软件配置管理计划中的主要内容

1）负责软件配置管理的组织及其任务、职责及其有关接口的控制 2）软件配置管理活动

? 配置标识

? 配置控制（即变更控制） ? 配置状态记录和报告 ? 配置审核及其评审

3）配置管理采用的工具、技术和方法

4）附：软件配置管理计划示例及其配置管理报表示例

3、软件配置标识（Configuration Identification）

――确定配置项（Configuration Item）

? 在软件生存期中需要管理起来的（或称需要受控的）软件项

（图2软件配置项：见课本，5个大圆圈，中间是“目标代码”）

? 配置项的多少因项目而异，项目大、负责、其数量可达数百、以至上千 ? 配置项分类

1）技术性：规格说明，源代码清单、测试用例；非技术性（管理性）：计划、

报告等

2）组织内或项目开发的；外购的

···（表2软件配置项清单：见课本） ――指定命名规则

? 原则

1）唯一性 2）可追溯性

? 树状层次式命名规则

（图3 树状结构命名示例）

4、变更管理（Change Managemnet）

1）配置数据库

――作用

? 记录与配置相关的信息 ? 评价系统变更的后果 ? 提供配置管理信息 ――三类库

? 开发库 Development Library

a、专供开发人员使用

b、库中信息可能频繁修改、更动 c、控制宽松

? 受控库 Controlled Library

d、存放开发阶段结束时的工作后果

e、也称软件配置管理库

? 产品库 Product Library

f、存放系统测试后的最终产品 g、等待交付

――典型的数据库查询问题

1）哪些客户已提取了某个特定的系统版本运行一个给定的系统版本需要什么硬件和操作系统一个系统已生长了多少个版本，核实生成的

若某个特定的组建变更了，回影响到系统的哪些版本一个特定的版本有那几个变更请求是最为重要的一个特定的版本有多少已报告的错误

2）基线与变更控制

――开发中的变更不可能完全避免 ? 变更来源

A、用户的需求变更 B、开发人员对技术方案或设计细部的变更 C、管理人员提出的方案，设计变更

? 变更的原因

D、开发人员掌握了更多的信息 E、对问题或方案有了更深刻的认识

? 变更管理的任务

F、分析变更

G、记录、追踪变更

H、使变更在受控状态下进行

必要性、经济可行性、技术可行性 ――基线（BaseLine）

? 软件生存期开发阶段末尾的特定点，也成为里程碑（milestone）

（图4软件配置基线，见课本）

? 开发阶段末尾，已经过验证的开发成果，不应作任意变更，将其“冻结”起来 ? 三种常用的基线

（1）功能基线

? 经过正式评审和批准的系统设计说明中对待开发软件提出的规格说

明

? 经过项目委托单位和项目承担单位双方签字同意的合同中规定的待

开发软件的规格说明 ? 由下级申请及上级同意，或直接上级下达的项目任务书中规定的待开

发软件的规格说明

（2）分配基线

软件需求阶段结束时，经过正式评审和批准的软件需求规格说明SRS－Software Requirement

（3）产品基线

软件集成……………………………

3）变更控制

――变更请求：提出变更请求表 Change Request Form（CRF）表3 变更控制表

项目名———— 变更请求人———— 日期———— 编号———— 要求的变更描述———— 变更分析员———— 分析日期———— 受影响模块———— 变更评估———— 变更优先性———— 变更实现———— 估计工作量———— CCB收到日期————

CCB决定———————————————————————— 变更实施负责人———— 变更日期———— 递交QA日期———— QA决定———— 递交CM日期————

表中：CCB是变更控制委员会（Change Control Board） QA质量保证组（Quality Assuranme） CM是配置管理组（）

――变更管理过程（表4） ――记录变更

A、将CRF作为配置项在数据库中登录 B、在变更了的模块代码上变更记录

（表5变更记录示例）

5、版本管理和发行管理

1）版本管理是对系统不同版本进行标识和跟踪的过程

――版本标识的目的是便于对版本进行检索和跟踪，显示各版本的关系

――个版本是软件系统的一个实例，在功能和性能上与其他版本有所差别，或是修

正了前一版本的不足

――有些版本在功能上是等价，但分别适用于不同的硬件配置 ――如果两个版本 2）

3）版本标识――版本的命名规格

――

（图7 非线形版本顺序） ――符号命名版本标识 ? 不用V1.1.2形式，而用VI/DB Server表示一个在VMS操作系统上运行的数据

库服务器版本

――属性版本标识

? 好处：容易加入新版本、版本间关系容易保持…..

6、配置审核（Configuration Audit）

1）什么是配置审核

――为发现和解法配置标识、变更控制、版本控制查错，而开展的验证活动 ――例如，变更评审是针对每一变更检查一致性、遗漏和肯那嘎的副作用 2）配置审核提出的问题

――已确定的变更完成了吗？有没有作任意附加的修改？ ――是否进行了正式的技术评审，以便评估技术的正确性？ ――是否遵循了软件工程标准？

――变更是否指明了日期、变更者信息？

――所作的变更是否遵循了软件配置管理规程？

――任一变更可能涉及到其他软件配置项，是否也相应作了变更？

7、配置状态报告（Configuration Status Reporting）

1）什么是配置状态报告

――配置状态报告（也称Status Accounting）的目的是及时、准确地给出软件配置项的当前状态，供相关人员了解，以加强 ――配置状态报告肯那嘎提供的信息包括 ? 但前做了哪些变更 ? 谁参加了这些变更 ? 何时做的变更

? 可能的影响范围是哪些

――报告可以定期提供，也可以放入联机数据库中 2） …. 3） ….

8、软件配置管理工具

1）手工实施软件配置管理存在的问题

――负责配置管理的人员对配置管理的理解、经验、坚定性都是制约因素 ――配置管理规程指定得应有适用性、可操作性、否则效果不佳 ――人员可能有失误，如疏忽、遗忘

――个别人对其可能不理解，甚至有抵触情绪、培训是十分必要的 ――人员流动可能有影响 2）采用配置管理工具支持的好处

――排除了上述认为因素的影响，避免了人员主观失误或不坚定实施等现象 ――节省了人员管理的时间，但不能免除责任人的责任 ――项目开发中出现配置管理问题的机会少了 3）采用配置管理工具需考虑的问题

――工具价格的付出

――工具使用的培训不可少

――工具的适用性（而不是多功能性）必须作为选购的条件 4）市场上已有的配置管理工具（P171）

ISO 9000 国际质量标准和管理体系

内容

1、质量管理、质量体系与质量认证的概念

1）质量管理

（1）什么是质量管理

－质量活动：

质量方针、目标；职责、权限；质量体系。

－包括：

质量策划；质量控制QC；质量保证QA；质量改进

（2）质量管理的类型：质量检验型、全面质量管理、质量认证 2）质量体系

（1）质量体系的概念

――质量管理制度 ――过程、活动和任务

（2）质量体系的构成

――组织结构 ――资源

――工作程序（规程） Procedure

（3）质量体系文件

――质量手册 ――程序文件 ――作业指导书 ――质量记录

3）质量认证

（1）什么是之赖宁嘎认证（2）质量认证的特点

――质量认证的对象是产品或服务，主要是针对产品 ――认证的基础是标准

――经审核符合标准的机构可获得质量认证证书，并允许使用认证标志 ――质量认证是第三方展开的活动

图1－2质量认证各方之间的关系（略）

4）实施质量认证制度的意义

（1）指导用户选择生产厂家和产品（2）促进产品提高质量，达到标准要求

（3）为生产厂家带来经济效益（4）借阅社会检验产品的费用（5）有利于走向国际市场

2、 ISO9000 国际标准

1）质量管理体系标准

（1） ISO9000：2000，GB/T 19000－2000

质量管理体系基础和术语

（2） ISO9001：2000，GB/T 19001－2000

质量管理体系要求

（3） ISO9004：2000，GB/T 19004－2000

质量管理体系业绩改进指南

八项质量管理原则

1、以顾客为中心

主要措施

（1）了解并掌握顾客的要求和期望

（2）确保组织的目标与顾客的需求和期望相结合（3）确保在整个组织内沟通顾客的需求和期望

（4）测量顾客的满意程度并根据结果采取相应的活动或措施（5）管理好与顾客的关系

（6）兼顾顾客与其它相关方之间的利益获益

（1）市场机遇作出快速而灵活的反应，扩大市场占有率并增加效益（2）获得顾客的青睐，追加订单，招来回头客

2、领导作用

主要措施：

（1）考虑所有相关方的需求和期望（2）为本组织的未来描述清晰的远景（3）确定富有挑战性的目标

（4）在组织的所有管理层次上建立价值共享和道德伦理观念（5）建立信任，清除忧虑

（6）为员工提供所需的资源、培训、并赋予其职责范围内的自主权（7）鼓舞和激励员工并承认员工的贡献获益

（8）使员工理解组织的目标，并自觉地实现这些目标

（9）评估所有的活动、统一协调，并能按要求的方法予以实施（10）领导者以身作则，促进持续改进 3、全员参与

主要措施

（1）了解自身贡献的重要性及其在组织中的角色（2）识别对其活动的约束

（3）接受所赋予的权利和职责并解决各种问题（4）每人根据自己应承担的目标评估其业绩（5）主动寻找机会增强员工的能力、知识和经验（6）自由地分享知识和经验获益

（1）积极努力，全身心投入工作（2）人人树立总作责任感

（3）人人渴望参与持续改进并作出贡献

4、过程方法

主要措施：

（1）为取得预期结果，使用已监理的方法并确定关键的活动（2）为管理这些关键的活动需明确职责和权限（3）了解并测定关键活动的能力

（4）识别组织只能内部和只能之间关键活动的结构

（5）重点管理能改进组织的关键活动的各种因素（资源、方法、材料）（6）评估风险及对顾客，供方和其他相关方产生的后果和影响

获益：

（1）有效地使用资源，降低成本，缩短周期（2）可获得能预测的，具有一致的已改进的结果（3）给予可被关注的按优先次序进行的改进机会

5、管理的系统方法

主要措施

（1）建立一个体系并以最有效的方法实现组织的目标（2）了解系统过程之间的相互关系…

（3）确定体系内特定活动的目标，以及这些特定活动应如何运作（4）用过测量和评估并持续改进体系获益：

（1）使所有的过程相互协调，最大限度地实现预期的结果

（2）增强了把注意力集中于关键过程的能力，使关键的相关方对组织

有效性和效率建立信心

6、持续改进

主要措施：

（1）在整个组织内部使用某一种一致的方法推行持续改进（2）为员工提供有关（3） a

（4）确定目标以指导、测量、追踪持续改进（5）识别并通报持续性改进情况

获益

（1）提高组织的实例，并增强竞争的优势

（2）增强对改进机柜的快速而灵活的反应能力，使组织的质量管理体系能动态地适

应内外环境的变化并成为组织发展的动力

7、基于事实的决策方法

主要措施：

（1）依据分析确保数据和信息足够、精确、可靠（2）让数据和信息需要者能得到数据和信息

（3）基于事实分析、权衡经验与直觉，作出决策并采取措施获益：

（1）决策以数据信息为依据

（2）有能力通过历史事实证实过去决策的有效性，有能力评估、挑战和改变判断与决

策

8、互利的供方关系

主要措施：

（1）识别与选择关键供方

（2）权衡短期利益和长期利益，确立与供方的关系（3）与关键的供方或合作伙伴共享专门技术和资源（4）监理清晰和开放的沟通渠道（5）确定联合改进活动

（6）鼓励、机房改进和成人成果获益：

（1）增强供需双方传造价值的能力

（2）灵活、迅速、联合一致地对市场变化作出反应（3）优化成本与资源

3、质量管理体系的四项要求

（1）管理职责

A、管理承诺 B、以顾客为关注焦点 C、质量方针 D、策划

E、职责、权限与沟通 F、管理评审

（2）资源管理

A、资源提供 B、人力资源 C、基础设施 D、工作环境

（3）产品实现

A、产品实现的策划 B、与顾客有关的过程

? 与产品有关的要求的确定 ? 与产品有关的要求的评审 ? 顾客沟通 C、设计和开发

? 策划 ? 输入 ? 输出 ? 评审 ? 验证 ? 确认

? 更改的控制

（4）采购

4、生产和服务的提供

? 提供的控制 ? 提供的确认 ? 标识和可追溯性 ? 顾客财产 ? 产品防护

5、监视和测量装置的控制

? 目的、监视和测量结果有效 ? 6、

2003年10月19日星期日（第六课）

4、 ISO9000 国际标准的特点和科学依据

（1） ISO9000国际标准的特点

? 国际性 ? 完整性 ? 兼容性 ? 主动性 ? 可信性 ? 指导性 ? 科学性 ? 实践性

（2） ISO9000国际标准的科学依据

? 质量形成于生产全过程

? 必须使影响产品质量的全部因素在生产全过程中始终处于受控状态 ? 应使企业具有持续提供符合要求产品的能力 ? 质量管理必须坚持进行质量改进 ? 质量管理体现PDCA循环

? 质量管理的核心是预防而不是补救

（3）

5、企业领导在质量管理体系监理中的责任

（1）制定质量方针

? 什么是质量方针 ? 质量方针的特点 ? 举例

? 质量方针的作用 ? 领导人的责任

（2）规定企业内与质量相关的重要岗位人员的职责、权限和沟通（3）提供必要的资源：人员、预算、工作量投入（4）指定管理真代表

? 目的 ? 责任 ? 条件

（5）管理评审

? 目的 ? 实施

（6）

CMM

内容提要

一、问题的提出二、概述

三、 CMM的成熟度四、 CMM结构

五、关键过程域及关键实践详述六、 CMM应用

一、问题的提出

? 市场竞争的迫切需要

市场竞争（人才、管理）《能力、水平》

粗放型（规模、数量、投入）――》集约型（效益、质量、水平、生产力） ? 质量与人品

人品――教育－培训――技能、纪律、精神….. 质量――管理――规范、标准……

软件危机事实（1）美国政府清算局部GAO于1983年统计的软件项目

? 3%交付给政府的软件产品可用 ? 49%完全不可用 ? 48%修改后才能使用

今年统计数据如下：

软件危机事实（2）

? 每100各IT项目立项启动后，有94个返工 ? 大公司的IT项目

――矛盾：

――设想可能的出路

――争论

软件项目出现的典型问题：

? 缺少用户的参与

? 需求及其说明不完整获经常变更 ? 项目得不到高层管理者的支持 ? 技术能力不足或对技术部署西 ? 资源投入不足 ? 预期要求过高 ? 项目目标不清晰

? 人员配合存在问题

不同成熟度的过程管理特征

不成熟的（幼稚的）无序、个人英雄注意无法预测个人经验主义经常管理失控、救火没有或很少有量化指标成熟的有序、有组织的过程有可见性、可预测被业界的时实践证实可管理、可分析拥有量化数据：质量、进度、生产率、功能度

项目成功的原因：

? 用户参与或与用户有良好的沟通 ? 高层管理者支持和主动关心 ? 需求得到清晰的描述 ? 计划符合实际

? 项目进行具有可见性 ? 人员能够胜任工作

? 有明确的目标并且是可以达到的

? 对可能遇到的风险做了分析，采取了有效的应对措施

二、概述（P33）

（1）什么是CMM

? CMM：Capability Maturity Model ? CMM提供了5个等级构成的模型

? 软件组织可通过它去定义、实施、度量、控制和改进他们的软件工程

（Paulk等，1994）

（2）SEI与CMM

――SEI－Software Engineering Institute软件工程研究所

? 隶属于美国Pennsylvania州Pittsburgh的Camegie Mellon大学 ? 成立于1984年

? 由美国空军电子系统中心和ARPA共同管理

? 任务是在软件工程领域中努力提高依赖软件的系统质量，促进软件开

发和维护的工程化管理，为军方服务。

－SEI最初应国防部要求提出一种评估软件承包商能力的办法

－1986年SEI开始研究协助软件组织改进过程的框架，以解决面临的问题

? 软件开发和维护成本不断提高 ? 软件产品质量不能令人满意 ? 软件项目常常是延误交付期

－CMM项目的主要负责人是：Mark Paulk，Watts Humphrey （3）CMM的演化（P34）

CMM：优秀软件企业实践的总结

? SEI考察哪些能如期、在预算内提供高质量的软件产品 ? 由78个公司列入考察对象清单，进行筛选 ? 总结优秀企业的成功经验

――理出关键实践经验 ――组合成关键过程域

? 将KPA分成4个能力成熟度等级

? 吸收了全面质量管理和某些重要标准的丝线

CMM模型在软件实际生产过程中的位置

（4）CMM族（P34）

Konrad.M于1996年描述了SEI开发的5种CMM－Based模型，

CMM是什么

? CMM是一个模型，人称“事实上的标准”

? CMM描述了软件项目希望成功应作的事（What） ? CMM并未描述这些事应怎么作（How），这应由组织在规程（Procedure）中回答 ? CMM较少，甚至没有说明为什么这样做（Why） ? CMM针对的是大型、负责的软件项目

CMM并不涉及的问题用户要求（needs）分析需求定义系统需求系统设计风险管理系统测试实现支持用户支持客户培训

CMM间接或隐含涉及的问题 ? 特定的工具、方法和技术

? 并行工程、联合应用开发和协调

? 系统工程、系统营销、系统测试与系统交付 ? 人力资源

? 组织行为和文化

三、 CMM成熟度

1、 5个成熟度等级（P36）

CMM5个成熟度等级是由低到高逐渐成熟的演进框架 ――衡量软件组织成熟度的尺度

――引导软件组织进行过程持续改进的目标

――成熟度高的登记有着较高的生产率、较高的质量和较低的风险

（表一：P37表）

2、各成熟度等级的特征（P37）

成熟度等级的顺序

? 过程能力按等级划分

――形似阶梯，但不排斥处于低级的组织部分地实施高等级的KPA要求。

如部分实施量化过程。同行评审

? 每一等级的实践为达到高等级要求打下基础

――在没有管理纪律的情况下，工程过程很难坚持 ――没有定义好过程，进行的具体测量可能发生矛盾

――对一个混论无序的过程所作的过程创新努力是毫无意义的

各成熟度等级的特征

（1）组织特征 5 4 3 2 1 过程式产品的数据均用于商务策略的改进实现了量化过程管理和量化质量管理整个组织采用统一的过程将可重复过程文档化，并付诸实施过程无序，无文档

――――――――――――――――――――――――――――――――― （2）过程特征 5 4 3 2 1 过程得到持续的系统地改进发生问题的共同原因已弄清并已清楚过程得到量化理解，过程已稳定组织级的过程（3）人员特征

CMM1.1虽未涉及到人员，但在按CMM实施过程改进中人员会有所感受 5 4 3 2 1 （4）技术特征 5 4 3 主动寻求和开发新技术新技术在量化基础上得到评价所需技术在工程人员中普及整个组织充满很强的协同工作精神每个人 2 1 （5）测量特征 5 4 3 2 1 已有技术支持和稳定的技术活动数据用以评价和选择过程改进活动，注重过程优化在组织内图：管理者对过程的可视性

2003年10月19日星期日（第七课）

3、过程能力

（1）什么是过程能力

――高的过程成熟度，其过程能力也较强

过程不成熟意味着：过程不稳定、无章可循 ――Paulk等1994定义过程能力为：

遵循某一过程，可能达到预期结果的程度 ――Trillium，1994定义过程能力：

开发结构以最低成本，在最短时间内，稳定地提交最少缺陷的产品，

以满足顾客期望的能力。

（2）为什么要提高过程能力

――对于顾客，较高的过程能力意味着： ? 开发组织能够更好地相应自己的要求 ? 软件产品的成本更低

? 能更好地满足最终用户要求

――对开发组织，高的过程能力表示： ? 软件产品开发和维护成本较低 ? 开发周期短

? 由于有效的项目风险分析和工作量投入估计，增强了达到成本和

进度目标的能力

? 提高了满足量化设计和质量目标的能力

能力和性能

? 过程能力Process Capability

遵循一个在组织层监理的过程，可能达到的预期结果程度 ? 过程性能Process Performance

遵循过程对已达到的实际结果的测量 ?

4、过程成熟度

? 过程成熟度对软件开发进度、成本和质量有很大影响

? 除项目完成时间外，项目成本和项目预期指标和项目完成情况也与此曲线

分布类似

SEI软件开发过程成熟度等级图表

软件缺陷随着软件开发过程改进而减少

5、

四、关键过程域 KPA－Key Process Area 除1级外，每个成熟度等级均有若干各关键过程域； KPA表明，这一级的组织应该从这些方面去改进软件过程。

图6，关键过程域 P47图

各级KPA及他们的分类如图6和图7所示 KPA给出了表达组织成熟度的一种方法

这些KPA的定义基于多年来软件工程和软件管理的实践以及5年以上过程评估和软件能力评价

每一KPA对应了一组相关的活动，这些活动的实施对于认定的目标是十分必要的 CMM并未提及软件开发和软件维护的所有过程域，而只是提到“关键的”，因为这些过程对于提高机构的过程能力最为有效，也可八这些KPA看作是达到某个等级的要求。

2、目标 ――CMM为每个KPA规定了一组目标 ――目标表明了满足该KPA必须达到的范围、边界和意图 ――可以把目标来判定组织或项目是否已有效地实现了这个KPA。 2级关键过程域的目标：表格见P43，之表格 3级关键过程域的目标：表格见P43，之表格

3、关键实践：包含5各共同特征，见图8

――执行的承诺：表示组织监理和保持过程需保证到的。

? 方针描述：强调组织承诺与过程的联系，例如

建立OPF（组织过程关注）、OPD（组织过程定义）分别要求：

――执行的能力：为实施软件过程组织或项目应具备的条件

? 组织机构： ? 资源和资金 ? 培训 ? 定向讲座 ? 先决条件

――要执行的活动

? 活动、角色和规程：实现KPA达到七目标所必须的

? 计划和规程：若需要指定计划、跟踪其实施，采取必要的措施

――度量和分析

? 基本度量：指与确定与过程相关的状态相关的最必要的度量

? 其他度量：如培训质量、管理的有效性，软件产品的功能性和质量

――验证实施

5、总体结构

2003年10月22日星期三（第八课）

六、CMM的应用

1、软件过程评估与软件能力评价 2、软件过程改进 3、 CMM应用现状

1、软件过程评估与软件能力评价

――软件评估过程

由受过培训的软件专业人员小组对某个组织中软件过程进行的鉴定，其目的在于：

? 确定组织中当前软件过程的状态

? 确定组织中与过程相关的最为紧迫的问题 ? 获得组织对于软件过程改进的支持

――软件能力评价

由受过培训的专业人员小组对组织的软件过程能力进行的鉴定，其目的在于：

? 识别有资格完成软件工作的承包商

? 监控一项现有软件工作所用软件过程的状态

――估价

评估与评价的总称

两者的区别

注重对象结论使用过程评估找出组织自身软件过程需优先改进处组织自身结论提交组织用于策划改进能力评价弄清在规定的进度、预算内提供高质量软件的项目、合同的风险投标者结论不提供投标者选择承包商监控承包商，特别是薄弱环节

两者共同处

――均采用成熟度提问单位作为访谈、了解情况的工具 ――均以CMM作为现场调查的导引

――围绕CMM的KPA提出发现的强项和弱项

――把调查发现的问题和KPA目标满足情况表作出结论

过程评估与能力评价步骤组建评估/评价小组培训成熟度提问单回答分析现场访谈文档评审调查结果 KPA满足情况表评估过程：

? ? ? ? ? ?

评估组由6－10名有经验的软件专业人员组成评估组成员接受SEI授权的主任评估师培训评估前做好充分准备，包括制定计划收集的数据进行分析

在完成现场评估侯向组织的高层管理者提交评估结论最终评估报告应是书面形式的，有主任评估师的签字

评估安排方案：（1）正式评估

? 时间：3个月（实际15各总作日）

――签订合同，确定评估范围 ――指定评估计划 ――培训评估组

? 安排

A、准备及预评估（2个月） B、现场评估（1个月）

（2）小型评估

? 时间：

（3）评估组

? 人数：4－10人 ? 角色

主任评估师

――对整个评估工作负责 ――已得到SEI授权

――对评估工作有丰富的经验

评估组成员

――评估现场协调 ――记录并保管文件

――组那所有成员软件工程工作年限之和>25年

主任评估师职责：

? 确保所策划的评估活动完成 ? 分配评估组人员的工作 ? 保证遵循CBA IPI*的流程

――顺利完成访谈活动 ――提交评估结果报告 ? 监控评估进度 ? 保证评估有效

? 解决可能出现的冲突和突破僵局 ? 与组织负责人沟通

? 将评估结果报告SEI备案

CBA IPI－CMM Based Appraisal Internal Process Improvement

评估目标：

? 对实施CMM后过程的状况作出评价

－收集过程数据，以了解当前过程的情况－弄清过程的强项以及需进一步改进的方面－确定过程能达到CMM哪些KPA的要求 ? 推动软件过程继续改进

－获得继续改进的能力

－为下一步采取纠正措施提供思路

－使过程改进工作继续得到发起者的承诺

评估原则：

? ? ? ? ?

从过程框架开始严格遵守保密要求应有高层管理者参与双方应有良好的合作评审活动中有计划地进行

2、软件过程改进

过程改进要求：

? 要集中精力考虑过程，而不是职责人员 ? 要收集数据，定期强化过程实施 ? 要有投资、培训和工作量投入

? 坚持持续改进

? 要有动力（市场竞争、产品质量问题……）

SEI所作过程改进的效果统计：统计项目提高生产率缩短产品开发期减少交付后产品的缺陷投资汇报率提前查出缺陷

过程改进使企业受益

? 加强了与顾客的交流，改进了顾客关系 ? 可从顾客那里获得更多有关产品的信息

? 员工对企业的满意度提高，对工作更加投入，人员流失率降低 ? 减低了商业风险

? 提高了产品质量和生产率，产品受欢迎，市场上享有的份额提高

过程改进也会使员工受益

? 减少了为完成本职工作的加班

? 改善了和顾客的关系，提高了顾客的满意度

? 在组织内部形成了协调的合作关系，员工之间增强了信任感 ? 任何人均可从别人的经验中获益

? 培训的制度化使员工专业技能的提高有了保证

过程改进在赢得顾客方面的好处：

? 能按时提交产品 ? 降低软件开发的成本 ? 缩短产品开发周期 ? 提高产品质量

? 项目风险降低，计划更接近实际 ? 取得顾客的信任

现金企业追求的目标：

? 产品质量不良付出的代价站生产成本的2.5－5％ ? 80-90%的缺陷可早期排除 ? 多数缺陷可预防

? 生产率能在3－5年内翻翻 ? 产品开发周期逐步缩短 ? 进度和成本准确预测 ? 客户满意

? 员工以企业为荣 ? 新技术支持过程

19％ 39 5：1 22％ 23 94 8.8：1 25％

小型企业过程改进建议

? 不必一步一个级别，可考虑连续式改进 ? 列举出企业面临的，受到困扰的问题

? 分析上述问题带来的影响，如成本、声誉、效率 ? 排除优先解决问题的顺序，着手逐个解决 ? 找出问题解决的对策

? 估计可能取得的效果和效益

? 不宜作过场时间的改进计划，希望在6个月内见到实效

监理过程改进的组织文化

? 持续改进需要有管理者始终如一的关心、支持和推动，定期评审不可

少

? 在改进计划拟定、批准以及实施人员选定后，管理者必须考虑必要的

资源投入，包括工程量和预算

? 管理者适当参SEPG组活动，及时解决所遇到的问题 ? 制度化意味着要坚持，切忌虎头蛇尾

SEI推荐的软件过程改进层次

? 战略计划 ? 战术计划 ? 指导性计划

着手过程改进的几种作法

? 进行SW－CMM2级评估（CBA－IPI） ? 小型评估（Mini Assessment） ? CMMI分级式评估

? 对照CMM，由主任评估师评审现行文件 ? 集中力量实施若干个特定关键过程域

? 实施个人软件过程PSP或小组软件过程TSP ? SW－CMM研讨或培训

? 借助成熟度提问单发现过程存在的问题

过程改进与变革

? 过程改进要求变革

? 新的过程和新技术不可避免地导致组织中的变革 ? 组织的变更需要策划，并对可能的结果及风险有估计 ? 较大的变革必定会遇到阻力 ? 进行变革必须 ? ??

人们接受新事务的过程 Y认识程度接受阶段信奉认识阶段制度化

3－5年 1－2年半年

了解阶段

采用确信试用理解知道借出

软件过程改进的SEI IDEAL模型吸取经验教训

10 9

1 2 3 8

启动 4 5 7 6

诊断策划启动

（1）明确过程改进动因

（2）明确发起人，得到高层领导的支持（3）监理过程改进所需的基础设施

诊断

（4）分析、评估当前作法（5）提出改进建议

策划

（6）指定过程改进策略（7）监理过程改进行动组织

行动

（8）定义过程、确定测试点（9）计划执行和跟踪

吸取经验教训

（10）分析经验教训

过程改进的角色 1、发起者

? 组织的高层管理者、中层管理者

? 项目经理（需得到高层管理者的充分支持）? 发挥权威和指导作用

行动

2、组织者

? SEPG

? 得到授权，负有组织和推动过程改进活动的职责 ? 得到高层管理者的支持

3、实施者

? ? ? ?

软件工程过程组（SPEG）的要求

? 组织和协助确定组织的软件过程 ? 支持过程的实施 ? 协助确定过程的测量

? 负责过程的维护，解决其中的阻力 ? 组织对过程实施情况的专家评议活动 ? 是组织软件过程的主人

? 组织需为其投入1－3%的人力和资源

客服过程改进阻力的措施

? 充分交流

? 让人们理解改进的目标 ? 组织人员参与改进活动 ? 指定切实的过程改进计划 ? 发起人要成为直接参与者 ? 开展必要的培训活动

? 坚持不懈、坚定不宜，组织者客服阻力和困难的思想准备（不付出代

价，甚至没有痛苦，不可能成功）

过程改进的基本原则 ――1989年Humphrey提出的六项原则

? 软件过程的重大变更必须是自上而下的 ? 过程改进涉及到各个岗位，每个人都要参与

? 有效的过程必须确定目标作为导引，并使员工对其有深入的理解 ? 过程改进需要持续进行

? 持续的过程改进需有自觉的努力和定期的强化 ? 应有必要的投入

第一线工作人员，各项改革活动的实际参与者试点项目人员或试点组织是首批实施者改进活动可能涉及到工作方法、规程和操作更为重要的是会涉及…….

过程制度化

? 过程思维已渗入整个组织的日常活动

? 过程制度化的两个支持（过渡文化和过程基础设施）

过程制度化过程文化过程基础设施组织基础设施技术基础设施过程资产过程支持工具过程数据库 ISO9000和CMM的差别（1） ISO9000和CMM的差别（2）文本特点表1（略）表2（略）具体、详尽 ――CMM1.1 550多页 ――CMM1.2 700多页简明、概括－ISO9001仅9页－ISO9004仅38页规定的口气，“要求作” 要求必须作什么，由谁负责图略图略

评估与认证（1）评估与认证（2）

CMM评估的组织：表略

我国引入和实施CMM的步伐（1）

? 1996年航天工业总公司汪伟、蔡愉祖翻译CMM1.1，名为《评价??》目前国内企业实施CMM遇到的实际问题：

软件企业实施CMM的首要工作（1）

? 企业的负责人和主要管理者认清实施CMM的必要性，统一认识作出

决策

? 企业的技术人员和管理人员掌握必要的软件工程知识，并在工作中取

得一定的实践经验

? 消化理解CMM文本中关键实践部分的要求，可以首先熟悉2级和3

级的要求

? 请评估师或咨询师对本期也正在实施的过程进行诊断，明确薄弱环节