某系统集成公司的变更管理程序中有如下规定：&ldquo变更控制委员会由公司管理人员、甲..

免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2013年上半年信息系统项目管理师上午试卷综合知识

第30题

知识点：变更管理变更控制变更控制委员会测试人员基线开发人员配置管理配置项质量保证

关键词：变更管理变更控制委员会测试基线开发配置管理配置项系统集成项目经理质量保证变更变更控制章/节：配置管理基础

某系统集成公司的变更管理程序中有如下规定：“变更控制委员会由公司管理人员、甲方主管、项目经理、关键开发人员、关键测试人员、质量保证代表和配置管理代表组成。变更控制委员会的职责为：批准基线的建立和配置项的确定；代表项目经理和所有可能因基线变更而受到影响的团体利益；审批对基线的变更；批准基线库产品的建立”。下面说法正确的是（30）。

A. 质量保证代表应负责独立监督项目的质量过程，不应加入变更控制委员会

B. 变更应由项目组以外的组织负责审批，项目经理、开发人员和测试人员不应加入变更控制委员会

C. 变更控制委员会只应代表公司领导和项目经理的利益，不应代表所有可能因基线变更而受到影响的团体利益

D. 该公司的上述规定是根据公司的实际情况制定的，可以有效运转

相关试题：配置管理基础

更多>

第62题 2017年下半年

64%

某项目进行到系统集成阶段，由于政策发生变化，需要将原互联网用户扩展到手机移动用户，于是项目经理提出变更请求，CCB审批通过后..

第65题 2012年下半年

54%

关于配置管理计划的制订和审批，下面说法正确的是(65).

第56题 2023年下半年

100%

关于审计流程的描述,不正确的是:（）


知识点讲解
· 变更管理 · 变更控制 · 变更控制委员会 · 测试人员 · 基线 · 开发人员 · 配置管理 · 配置项 · 质量保证

变更管理

信息系统开发项目的变更

信息系统开发项目的变更有如下特点：

.变更的不可避免性。

.变更的复杂性。

项目变更常见的原因如下：

.产品范围定义的过失或疏忽。

.项目范围定义的过失或疏忽。

.增值变更。

.应对风险的紧急计划或回避计划。

.项目执行过程与项目基准要求不一致。

.外部事件。

变更管理的任务

变更管理的主要任务如下：

.分析变更：研究变更的必要性、经济可行性和技术可行性。

.记录和追踪变更。

.采取措施保证变更在受控状态下进行。

变更管理流程

变更管理过程的一般程序如下：

（1）提出与接收变更申请。

变更提出应当以正式的方式进行，并留下书面记录。

（2）对变更进行初审。

变更初审的目的如下：

.对变更提出方施加影响，确认变更的必要性。

.格式校验，完整性校验，确保评估所需信息准备充分。

.在干系人间就提出供评估的变更信息达成共识。

变更初审常见方式为变更申请文档的审核流转。

（3）变更方案论证。

对变更申请进行技术评估和经济评估，以供CCB决策。

（4）项目变更控制委员会审查。

变更控制委员会（CCB）决定是否批准变更申请。

（5）对否决的变更申请进行记录并通知相关人员，对批准的变更申请发出变更通知并开始实施。

（6）对变更实施进行监控。

（7）对变更效果进行评估。

变更控制

变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。

变更控制委员会

变更控制委员会（Change Control Board，CCB）也称配置控制委员会（Configuration Control Board），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以全职的，也可以是兼职的。

如果CCB除控制变更以外，还要承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。

变更控制的流程

变更管理的基本流程如下：

①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。

②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。

③变更决策。由具有相应权限的人员或机构决定是否实施变更。

④变更实施。由管理者指定的工作人员在受控状态下实施变更。

⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。

⑥沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。

变更申请需要采用书面的形式提出，主要内容有如下3个方面：

①变更描述。包括变更理由、变更的影响、变更的优先级等，就是要描述做什么变更，为什么要做，以及打算怎么做的问题。

②对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。

③变更实施的信息。

利用配置库实现变更控制

配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。

配置项的状态变化过程

处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。

变更控制委员会

变更控制委员会（Change Control Board, CCB）也称为配置控制委员会（Configuration Control BoarD），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以是全职的，也可以是兼职的。

如果CCB不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。

测试人员

测试人员的选择

测试人员的能力包括以下几项。

①一般能力：包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；

②测试技能及方法：包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等；

③测试规划能力：包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；

④测试执行能力：包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；

⑤测试分析、报告和改进能力：包括测试度量、统计技术、测试报告、过程监测及持续改进。

测试人员的激励

X理论＋Y理论

. X理论：胡萝卜＋大棒——迫使人们工作；

. Y理论：经理的职能不是督促人们工作，而是使人们有可能工作。

需要的层次（Maslow模型）

. 生存需要——工作职位、工资奖金、休息时间；

. 安全需要——公正待遇、应付工作的能力和信心；

. 社会需要——团队归属感，互相认同、理解和支持；

. 自尊需要——具有受人尊重/赏识的能力或/和业绩；

. 自我实现需要——成为自己期望的人物。

人员激励的关键点

. 管理者习惯用对自己有效的因素激励测试人员，很可能发现无效；

. 过多使用权力、资金或处罚手段很可能导致项目失败；

. 行业领先企业采取卓有成效的非货币形式的激励措施；

. 在项目进行过程中，而不仅是在项目结束时实施激励措施；

. 奖励应该在工作获得认同后尽快兑现；

. 对人员的工作表现出真诚的兴趣是对他们最好的奖励；

. 激励因素是因人而异、因时而异的。已经满足的需要很可能不再成为激励因素。

人员自我激励

测试工作的快乐哲学：选择积极的态度，把工作当作游戏，让别人快乐，全身心投入工作。

注意测试工作的7条效率原则：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1＋1>2；终生学习，自我更新，不断进步。

测试职业发展

国际推荐的软件测试职业发展计划如下。

. 1~2年，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动测试工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；掌握编程语言、操作系统、网络与数据库方面的技能。

. 3~4年，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术；能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。

. 4~5年，测试组织工作：管理1~3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。

. 5~6年，技术管理：管理4~8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；研究测试的技术手段，保持使用项目管理及支持工具的技能；用大量时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。

. 6~12年，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。

人员的培训

软件测试培训内容分类

. 测试基础知识和技能培训。

. 测试设计培训、测试工具培训。

. 测试对象——软件产品培训。

. 测试过程培训。

. 测试管理培训。

制定测试人员培训计划

. 是测试计划的一个重要组成部分。

. 需要管理层的重视，在时间和资源上予以保证。

. 认真调查和分析测试人员的培训需求。

. 将培训活动安排在测试任务开始前。

. “边干边学”模式很可能牺牲质量和效率。

. 软件测试实习活动在整个培训中占较大比例。

. 鼓励合作学习，团队演练。

. 对培训效果要及时评价，发现不足进行改进。

基线

基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。

建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。

作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。

如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。

（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。

（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。

（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。

另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。

：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。

开发人员

①多媒体软件：项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。

②多媒体电子出版物：策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。

配置管理

随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。

信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。

配置管理计划

根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。

（1）该项目对配置管理的要求。

（2）实施配置管理的责任人、组织及其职责。

（3）需要开展的配置管理活动及其进度安排。

（4）采用的方法和工具等。

配置与配置项

“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。

为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。

版本控制

版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。

变更控制

变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。

配置审计

配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。

（1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。

（2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。

状态报告

状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。

配置项

GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。

在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。

质量保证

系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是开发高质量的系统。

质量特性

讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性，目前较多采用的如ISO/IEC 9126软件质量模型和Mc Call软件质量模型。ISO/IEC 9126已经被ISO/ICE 25010系统和软件质量模型所取代，其主要改进包括将兼容性作和安全性作为质量特性，ISO/IEC 25012数据质量模型与ISO/IEC 25030使用质量模型作为补充。

ISO/ICE 25010系统和软件质量模型

ISO/ICE 25010系统和软件质量模型包含8个质量特性，每个特性由一组相关的质量子特性组成，如下图所示。该产品质量模型既可以用于软件，又可以用于任何包含软件的计算机系统。

产品质量模型

其中，各质量特性和质量子特性的含义如下。

（1）功能适合性（functional suitability）。与一组功能及其指定的性质的存在有关的一组属性。功能是指满足规定或隐含需求的那些功能。

.功能完整性（functional completeness）：与对规定任务和用户目标加以实现的功能是否完整有关的属性。

.功能适当性（functional appropriateness）：与对规定任务和用户目标能否提供一组功能以及这组功能是否适合有关的属性。

.功能正确性（functional correctness）：与能够得到正确或相符的结果或效果有关的产品或系统属性。

（2）性能效率（performance efficiency）。在规定条件下，系统的性能水平与所用资源量之间的关系有关的一组属性。

.时间特性（time behavior）：与响应和处理时间以及软件执行其功能时的吞吐量有关的属性。

.资源利用率（resource utilization）：与系统执行其功能时所使用的资源量以及使用资源的类型有关的属性。

.容量（capacity）：与系统满足特定需求时指标参数的最大限制有关的属性。

（3）兼容性（compatibility）。与系统或组件与其他系统或组件进行信息交换，或在不同软硬件环境中执行所需功能有关的一组属性。

.共存性（co-existence）：与同其他系统运行在同一环境使用相同的资源而不相互影响的能力相关的属性。

.互操作性（interoperability）：与同其他指定系统进行交互操作的能力相关的属性。

（4）易用性（usability）。与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性。

.可识别性（appropriateness recognizability）：与用户识别系统是否满足需求有关的属性。

.易学性（learnability）：与用户为学习使用产品（例如操作控制、输入、输出）的有效性、效率、风险和满意度相关的属性。

.易操作性（operability）：与用户为进行操作和操作控制所付出的努力有关的属性。

.错误防御（user error protection）：与阻止用户错误输入有关的属性。

.界面美观性（user interface aesthetics）：与系统用户界面使用户进行愉快满意交互有关的属性。

.可访问性（accessibility）：与用户可访问系统完成特定目标的范围和能力有关的属性。

（5）可靠性（reliability）。与在规定的一段时间内和规定的条件下，系统维持在其性能水平有关的能力。

.成熟性（maturity）：与正常操作情况下满足可靠性需求有关的属性。

.可用性（availability）：与系统运行可用使用能力有关的属性。

.容错性（fault tolerance）：与在系统错误或违反指定接口的情况下，维持指定的性能水平的能力有关的属性。

.易恢复性（recoverability）：与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的属性。

（6）安全性（security）。与避免对程序及数据的非授权故意或意外访问的能力有关的系统属性。

.机密性（confidentiality）：与系统确保只有授权才能访问其数据能力有关的属性。

.完整性（integrity）：与系统防止未经授权对数据和程序进行访问和修改能力有关的属性。

.不可抵赖性（non-repudiation）：与对系统使用行为及发生时间真实性有关的属性。

.可审计性（accountability）：与对系统使用行为进行追踪有关的属性。

.真实性（authenticity）：与证明主体或资源身份是所声称的身份有关的属性。

（7）可维护性（maintainability）。与进行规定的修改所需要的努力有关的一组属性。

.模块性（modularity）：与所组成系统的模块独立性有关的属性。

.可复用性（reusability）：与模块用于其他系统有关的属性。

.易分析性（analyzability）：与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的属性。

.易修改性（modifiability）：与进行修改、排错或适应环境变换所需努力有关的属性。

.易测试性（testability）：为确认经修改系统所需努力有关的属性。

（8）可移植性（portability）。与系统可从某一环境转移到另一环境的能力有关的一组属性。

.适应性（adaptability）：与系统转移到不同环境时的处理或手段有关的属性。

.易安装性（installability）：与在指定环境下对系统进行安装／卸载所需努力有关的属性。

.易替换性（replaceability）：与一产品在该软件环境中用来替代指定的其他软件的可能和努力有关的属性。

Mc Call软件质量模型

Mc Call软件质量模型从软件产品的运行、修正、转移三个方面确定了11个质量特性，如下图所示。Mc Call也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则，第三层是度量指标。

Mc Call软件质量模型

质量保证

质量保证是指为保证系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的产品。在系统质量方面强调三个要点：首先系统必须满足用户规定的需求，与用户需求不一致的系统，就无质量可言；其次系统应遵循规定标准所定义的一系列开发准则，不遵循这些准则的系统，其质量难以得到保证；最后系统还应满足某些隐含的需求，例如希望有好的可理解性、可维护性等，而这些隐含的需求可能未被明确地写在用户规定的需求中，如果系统只满足它的显性需求而不满足其隐含需求，那么该系统的质量是令人担忧的。

质量保证包括7个主要活动相关的各种任务，分别是应用技术方法、进行正式的技术评审、测试系统、标准的实施、控制变更、度量（metrics）、记录保存和报告。

题号导航 2013年上半年信息系统项目管理师上午试卷综合知识

本试卷我的完整做题情况



	第30题在手机中做本题