某公司有自己的质量管理体系，其中配置管理程序已运行多年，由项目经理牵头组建变更控..

免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2023年上半年系统集成项目管理工程师下午试卷案例

第3题

知识点：配置管理配置管理员配置基线质量管理变更控制变更控制委员会测试人员管理体系基线评估

某公司有自己的质量管理体系，其中配置管理程序已运行多年，由项目经理牵头组建变更控制委员会(CCB)，在创建配置管理环境后，并经过变更申请、变更评估、变更实施后，方可发布配置基线的变化。
通常公司项目在软件封版后，再做一次发布验证，通过后即可上线。近日，项目A已封版。版本号为10.5.0。但项目经理收到测试人员的反馈，封版软件上发现多个问题，其中有两个问题严重影响用户体验。于是项目经理安排研发人员紧急解决。并向配置管理员提出变更申请。研发人员在10.5.0版本上导入问题1的修改后，将版本号更新为10.6.0;在10.5.0版本上导入问题2的修改后，将版本更新为11.0.0。新版本由项目经理发布给项目组。

问题：3.1 结合案例，请指出项目A在配置管理中存在的问题。

问题：3.2 (6分)
结合案例填写下表，为每个角色指派合适的工作职责(用“√”表示负责对应工作)。

问题：3.3 (4分)
判断下列说法的正误(填写在答题纸的对应栏内，正确的填写“√”，错误的填写“×”)
(1)信息系统相关信息(文档)具有永久性()。
(2)按开发任务建立相应的配置库，适用于通用软件的开发组织()。
(3)配置控制是配置管理过程的基础()。
(4)每个产品都有配置基线，一个产品只有一个配置基线()。


知识点讲解
· 配置管理 · 配置管理员 · 配置基线 · 质量管理 · 变更控制 · 变更控制委员会 · 测试人员 · 管理体系 · 基线 · 评估

配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。

GB/T 11457—2006中，对“配置管理”的正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”

配置管理员

配置管理员（Configuration Management Officer, CMO）负责在项目的整个生命周期中进行配置管理活动，包括：

.编写配置管理计划。

.建立和维护配置管理系统。

.建立和维护配置库。

.配置项识别。

.建立和管理基线。

.版本管理和配置控制。

.配置状态报告。

.配置审计。

.发布管理和交付。

.对项目成员进行配置管理培训。

配置基线

配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项不能随意修改，对基线的变更必须遵循正式的变更控制程序。

基线可以是一组拥有唯一标识号的需求、设计、源代码文件以及相应的可执行代码、构造文件和用户文档构成的产品，也可以是产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例与使用手册等）。基线需要定义的内容包括建立基线的事件，受控的配置项，建立和变更基线的程序，批准变更基线所需的权限。

基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线（Release Baseline），内部开发使用的基线一般称为构造基线（Build Baseline）。

建立基线有如下好处：

.基线为开发工作提供了一个定点和快照。

.新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。

.当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。

.可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

质量管理

质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量规划、质量保证和质量控制以及质量改进来使其实现所有管理职能的全部活动。

变更控制

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

变更控制委员会

变更控制委员会（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名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。

人员的培训

软件测试培训内容分类

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

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

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

. 测试过程培训。

. 测试管理培训。

制定测试人员培训计划

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

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

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

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

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

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

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

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

管理体系

灾备管理体系主要是指组织机构的各个层面，在日常状态和灾难状态下的各种管理工作，至少包括以下5个方面。

（1）灾难恢复组织机构。商业银行应结合本行机构设置的具体情况，设立灾难恢复组织机构，包括灾难恢复规划建设、运行维护、应急响应和灾难恢复等各阶段工作所需的人员，有关人员可为专职，也可为兼职，关键岗位的人员应有备份。商业银行可以参考《JR/T0044 2008银行业信息系统灾难恢复管理规范》，设置灾难恢复组织机构，包括决策层、管理层和执行层，各层之间分工明确、职责清晰。

（2）岗位与培训管理。灾备中心的应急生产岗位应与生产中心对等，只不过可以按照人员复用的原则，由灾备管理人员、开发测试人员或系统运维人员专职或兼职担任。对不同层次、不同部门的岗位，在灾难恢复策略规划、系统建设与运维、预案制定、演练和更新维护等不同阶段，应按照不同的培训目标，安排不同的培训计划。

（3）灾难恢复预案管理与演练。灾难恢复预案要长期保持有效性，必须在灾难恢复策略发生变化、演练发现问题、生产系统发生变更、人员出现调整等情况下，及时修订维护预案，做好变更管理、版本管理，以及发布管理等，确保合适的人员及时获得最准确、最合适的信息。演练验证灾难恢复预案有效性的最佳手段。演练管理就是要对演练的计划、场景、人员、过程、总结评估和后续完善调整等进行全面管理，通过演练来培养灾难恢复团队面对复杂环境的信心和冷静心态，验证灾难恢复能力，改进灾难恢复流程，发现并纠正灾备体系中的缺陷。

（4）灾备中心日常运维、灾难响应与重续运行管理。灾备中心应随时做好接替生产中心的准备，因此，必须像生产中心一样，对灾备中心的系统、网络和环境等基础资源进行运行维护，按照备份策略按时完成数据备份，完成灾备系统与生产系统的同步。当灾难发生后，灾难恢复组织机构的各层人员立即响应，在指挥报告、协调、联络、保障等工作机制的保障下，按照灾难恢复流程步骤，一步步地恢复信息系统及其支撑的关键业务功能。在生产系统成功切换到灾备中心运行后，要按照生产中心的规章制度、操作流程、技术规范来管理，保障生产系统安全稳定运行，直至生产中心重建并恢复了生产运行能力。

（5）外部资源管理。外部资源主要指商业银行的合作伙伴、服务商、设备商和外协人员等。当发生灾难时，可能需要这些外部资源的支持才能完成灾难恢复，比如，从设备供应商紧急采购灾备生产设备，从电信运营服务商紧急租用通信线路，从银联借调交易流水等。因此，需要与这些外部资源建立日常联系或签订协议，并不定期地测试其支持能力，以保证在灾难恢复期间，外部资源可以提供有效的支持。

基线

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

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

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

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

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

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

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

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

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

评估

评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。

很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。

在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。

评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。

评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。

评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。

用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。

工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。

所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。

在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。

进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。

网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。

需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。

制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。

最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。

题号导航 2023年上半年系统集成项目管理工程师下午试卷案例

本试卷我的完整做题情况



	第3题在手机中做本题