配置管理、质量与风险管理

本文由课件自动整理，页内文字按原始讲义阅读顺序还原；[图] 表示该位置存在图示，

图示内容请对照原始课件查看。

目录

• 第 1 页 · N E W P L A
• 第 2 页 · 目录
• 第 3 页 · 03
• 第 4 页 · 软件配置管理
• 第 5 页 · 软件配置管理
• 第 6 页 · 软件配置管理
• 第 7 页 · [图]
• 第 8 页 · 软件配置管理
• 第 9 页 · 04
• 第 10 页 · 质量与风险管理
• 第 11 页 · 质量与风险管理
• 第 12 页 · 质量与风险管理
• 第 13 页 · T H E E N D

第 1 页 · N E W P L A

N

软考高级架构师

项

目

管

理

第 2 页 · 目录

CONTENTS

[图]

[图]

[图]

[图]

01

02

2

03

04

考点分析

进度管理

软件配置管理

质量与风险管理

……

……

……

……

第 3 页 · 03

软件配置管理

C

o

u

r

s

e

S

c

h

e

d

u

l

e

第 4 页 · 软件配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，从而

标识系统在不同时间点上配置的学科。

在GB/T11457-2006中将“配置管理"正式定义为："应用技术的和管理的指导和监控方法以标识和说明

配置项的功能和物理特征，控制这些特征的变更， 记录和报告变更处理和实现状态并验证与规定的需

求的遵循性。”

配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、

发布管理和交付。

第 5 页 · 软件配置管理

配置项:GB/T11457-2006对配置项的定义为:“为配置管理设计的硬件、软件或二者的集合，在配置管

理过程中作为一个单个实体来对待”。

以下内容都可以作为配置项进行管理:外部交付的软件产品和数据、指定的内部软件工作产品和数据、

指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。

典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需

的各种数据，它们经评审和检查通过后进入配置管理。

每个配置项的主要属性有: 名称、标识符、文件状态、版本、作者、日期等.

配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程

序等，非基线配置项可能包括项目的各类计划和报告等。

所有配置项的操作权限应由CMO (配置管理员)严格管理，基本原则是:基线配置项向开发人员开放读

取的权限;非基线配置项向PM、CCB（变更控制委员会）及相关人员开放。

第 6 页 · 软件配置管理

配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时其状态为“草稿”。配置项

通过评审后其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕

并重新通过评审时，其状态又变为“正式”。如图所示

[图]

第 7 页 · [图]

软件配置管理

配置项版本号

处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的

取值应递增。Y的初值和增幅由用户自己把握。

处于“正式”状态的配置项的版本号格式为XY，X为主版本号，取值范围为1～9。Y为次版本号，取

值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以

将变动部分制作成配置项的附件，附件版本依次为1.0，1.1...。

当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时X值将适量增加。当

配置项升级幅度比较大时，才允许直接增大X值。

处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值X.Y值保持不变

。当配置项修改完毕，状态成为“正式”时，将Z 值设置为0，增加X.Y值。参见上述规则 。

配置项版本管理:在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配

置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧

版本。版本管理的目的是按照一定的规则保存配置项的所有版本避免发生版本丢失或混淆等现象，并

且可以快速准确地查找到配置项的任何版本.

第 8 页 · 软件配置管理

配置项版本管理:在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配

置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧

版本。版本管理的目的是按照一定的规则保存配置项的所有版本避免发生版本丢失或混淆等现象，并

且可以快速准确地查找到配置项的任何版本.

第 9 页 · 04

质量与风险管理

C

o

u

r

s

e

S

c

h

e

d

u

l

e

第 10 页 · 质量与风险管理

质量是软件产品特性的综合，表示软件产品满足明确(基本需求)或隐含(期望需求)要求的能力。质量管

理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进

来使其实现的所有管理职能的全部活动;

主要包括以下过程:

质量规划:识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。

质量保证:一般是每隔一定时间 (例如，每个阶段未) 进行的，主要通过系统的质量审计 (软件评审) 和

过程分析来保证项目的质量

质量控制:实时监控项目的具体结果，以判断它们是否符合相关质量标全制订有效方案，以消除产生

质量问题的原因

第 11 页 · 质量与风险管理

风险管理就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损失、

取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，

完全避开或消除风险，或者只享受权益而不承担风险是不可能的

风险管理计划编制:如何安排与实施项目的风险管理，制定下列各步的计划.

风险识别: 识别出项目中已知和可预测的风险确定风险的来源、产生的条件、描述风险的特征以及哪

些项目可以产生风险，形成一个风险列表。

风险定性分析:对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。

风险定量分析: 进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析期望

货币价值分析、决策树分析、蒙特卡罗模拟。

风险应对计划编制: 对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应

对计划。包括消极风险(避免策略、转移策略、减策略) ;积极风险(开拓、分享、强大)。

风险监控:监控风险计划的执行，检测残余风险，识别新的风险，保证风险并评价这些计划对减少风险的

有效性计划的执行。

第 12 页 · 质量与风险管理

在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险

。

项目风险是指潜在的预算、进度、个人 (包括人员和组织)、资源、用户和需求方面的问题，以及它们

对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。项目风险威胁到

项目计划，一但项目风险成为现实，可能会拖延项目进度，增加项目的成本

技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上

的不确定性、技术陈旧、最新技术 (不成熟)也是风险因素。技术风险威胁到待开发系统的质量和预定

的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能

商业风险威胁到待开发系统的生存能力，主要有以下5 种不同的商业风险

市场风险。开发的系统虽然很优秀但不是市场真正所想要的。

策略风险。开发的系统不再符合企业的信息系统战略。

销售风险。开发了销售部门不清楚如何推销的系统。

管理风险。由于重点转移或人员变动而失去上级管理部门的支持.

预算风险。开发过程没有得到预算或人员的保证

第 13 页 · T H E E N D

功不唐捐，玉汝于成!

开

启

新

征

程