配置管理访谈问题和答案

38
试以经典的瀑布软件生命周期为例，说明应该设置哪些基 线？
39 在进行配置管理时，要注意哪三个唯一性？ 40 在配置项状态参数中，什么叫配置项变化率？什么叫同一 配置项的变化次数？为什么要记录这两个参数？
41 QA与CM关系 42 CCB与CM的关系 43 项目经理与CM的关系 44 开发人员与CM的关系 45 测试人员与CM的关系 46 CM与项目组的关系 47 项目组成员什么时间能收到配置状态报告？ 48 项目经理在哪里查看配置备份表？
25 基线变更流程是什么？基线变更是不是需求通过ＣＣＢ？ 26 配置库分为那几个库？ 27 变更申请有没有分析？分析内容包括哪些？变更如何跟 踪，有没有变更申请及跟踪记录？
28 配置状态报告什么时候发布？配置状态报告信息是什么？
29

在什么情况下必须建立基线？什么是基线？基线的分类， 基线与基线之间内容有什么区别？
30 如何做版本控制？ 31 配置管理最关注的是什么 32 配置库的作用是什么？ 33 开发人员如何对配置库进行使用？
34 如何识别配置项
基线中的配置项变更走哪些流程？谁来决定是否变更基 线？基线变更后基线如何处理？变更后如何重新发布？ 36 配置记录包括哪些内容？如何维护管理的？ 35
37
在生命周期的定义中，生命周期的阶段、里程碑和基线的 含义是什么？这三者有什么区别？
问题
10 如何进行CM审计？CM审计由谁来做？
11 怎样审核和授权软件基线的变更的？ 12 CCB由哪些人员组成？
13 基线是怎么建立的？ 14 配置项的变更分析是怎么做的？ 15 如何处理配置项的变更？ 16 在你的项目中，你是如何知道配置项的最新状态的？ 17 项目需要建立哪几个基线？
18 你是如何发布工作产品的？
19 QA人员在你们项目中做些什么？ 20 关于配置管理你受过什么样的培训 21 配置管理的主要活动有哪些？ 22 建立和维护基线完整性的含义是什么？在进行基线完整性 检查时，ＣＭ和ＱＡ要分别作些什么工作？是如何做的？
23 配置项的名称是怎么定义的？
24 为什么有的配置项名称用项目名称有的用合同号
配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是 否具有一致性等等。配置审计分物理审计和功能审计，物理审计是qa和cm一起根据评审报告审计配置 项是否与需求一致。功能审计是项目经理和cm一起根据测试报告审计代码是否和需求设计一致。 审计依据配置管理计划中设定的时间进行，审计的对象是配置管理员。审计依据配置审计报告。审计 结果在配置配置审计报告中追踪确认。 有CCB审批基线的变更 项目经理,配置管理员，QA，测试人员，主要开发人员等，对于重要项目可能会包括项目双方的高层 管理者 基线在指定的里程碑创建，即里程碑通过评审后将相关工件纳入基线。并与项目中的里程碑保持同步 。 需要纳入基线的所有配置项都要经过CCB评审，并解决了评审中提出的问题，由CCB验证后，项目组成 员依据《入库申请表》通知配置管理员纳入受控库的相应的位置；在Label中对基线进行标识。 由项目经理指派人员对变更进行影响分析 按照变更控制过程进行。变更申请---识别变更---评审变更---批准变更---实施变更---验证变更— 配置项重新发布 从配置管理台账和配置状态报告中查询 需要建立三个基线：需求基线，设计基线，交付基线 按公司的发布流程执行: 1、发布基线中的配置项通过测试后，由质量管理部测试人员提供测试报告，并对遗留问题可以放行 进行分析说明。 2、项目经理提出并填写《产品发布审核》；发布的配置项是中产品发布清单列表； 3、由测试部经理填写产品测试环境和产品测试结论，并签字确认； 4、由QA和产品开发部经理根据《产品发布审核》审核发布清单中的发布项； 5、由质量管理部分管副总在《产品发布审核》中签字批准； 6、研发中心评审要发布的配置项，评审通过后由产品开发部分管副总在《产品发布审核》签字批 准； 7、配置管理员按照发布清单，将受控库中的全部配置项提交产品库中的相应位置；发布《配置状态 制定质量保证计划、对过程进行审计、对工件进行评审、对数据进行收集 公司组织外训班，自学 主要包括识别配置项、变更控制、状态记录报告及审计。 含义是保护工作产品的完整性。 CM和QA根据配置审计模板中的审计项检查 配置审计分物理审计和功能审计，物理审计是qa和cm一起根据评审报告审计配置项是否与需求一致。 功能审计是项目经理和cm一起根据测试报告审计代码是否和需求设计一致。 项目名称（或合同号）+文件名称+版本号 代码标识为：合同号-PJcode（项目源码）+版本号 合同号-PDcode（产品源码）+版本号 合同号-APP（应用程序）+版本号 合同号-DB（数据库文件）+版本号 合同号-DZ（定制工具）+版本号 涉密项目中的配置项用合同号+文件名称+版本号，普通项目中的配置项用项目名称+文件名称+版本号
序号 1
2
3
4
5
6
7
8 9
答案 项目经理在项目启动阶段就会指定配置管理员，配置管理员识别配置项，制订配置管理计划； 然后在项目实施过程中，我们根据配置管理计划里程碑时间建立基线，对于纳入基线的配置项需要实 配置管理是怎么做的？ 施变更控制，要走变更流程并在变更跟踪表中进行跟踪。配置管理员会在基线建立、变更和发布时发 布配置项状态报告，让所有人员获知配置项状态信息。QA人员会对项目的配置管理状况实施配置审计 1. 对于产品质量起关键作用的工作产品(例如测试数据和用例) 2. 被两个或多个组共同使用的工作产品（详细设计说明书） 在你的项目中，那些工作产品进行配置管理？为什么？ 3. 它会随着项目的开展而发生变化（例如需求跟踪矩阵） （或者问题方式可能是：配置项是如何识别的？） 4. 工作产品之间的依赖性和制约性强一个工作产品变更会引起另外的工作产品变更（例如需求说明 书）。 可以裁剪。依据系统中的项目过程裁剪报告进行。 在你们项目中是否可以裁剪配置项？如何裁剪？ 可以裁减配置项。根据项目需求、组织标准软件过程库、过程资产库，软件生命周期、过程裁剪指 南，制订项目定义软件过程，对不必要的过程和配置项进行裁剪。 项目经理在项目启动阶段就会指定配置管理员，配置管理员识别配置项，依据项目计划制订配置管理 计划；并和项目计划一起进行评审，配置管理计划是项目计划的子计划。 什么时候准备配置管理计划？并请详细说明配置管理计划 配置管理计划的内容包括：1、目的，2、人员与职责，3、用于配置管理的软硬件资源，4、配置库的 的内容？ 访问和授权，5、识别配置项，6、版本/修订编号，7、配置库的结构，8、基线计划、9、配置库的维 护和备份计划，10、配置审计计划， CM的职责为项目制定配置管理计划确定工作产品的受控时机，维护基线的完整性。控制对配置项的变 CM的职责是什么？CCB的职责是什么？ 更，向开发者提供准确的配置项的状态。创建并维护配置库。 CCB的职责对配置管理各项活动拥有决策权。对基线的建立、发布、变更进行审批。 根据配置库管理规范在配置管理计划中明确分配配置库中配置项的访问权限。在配置库中所有人员没 你是如何确定你的项目的配置项的访问控制的？ 有彻底删除的权限。开发人员根据权限不同访问开发库中的数据项（参考软件开发源代码配置管理指 南）。受控库中的所有人有只读权限，配置管理员权限最大。 1、当配置项变更或其他情况引发基线变更时，变更申请人填写《项目变更申请表》提交项目经理， 由项目经理对变更进行影响分析，提交CCB审批，抄送CM。CM填写《变更跟踪表》。若为需求变更需 要客户的参与评审。 2、变更申请通过CCB审批通过后，开始实施变更。若为需求变更当客户参与评审时还需客户审批通过 方可实施变更。 3、变更申请没有通过CCB审批，该变更申请单作废。 在你的项目中是如何发起变更请求，如何审核变更请求， 4、配置管理员收到CCB审批通过的《项目变更申请表》后，从受控库中取出要变更的配置项，并发布 如何报告变更状况的(如何记录的)？ 《配置状态报告》，通知所有相关人员变更信息。 5、变更实施人执行对配置项的具体变更后，将其发给配置管理员。 6、配置管理员和相关人员对变更后的配置项进行验证，若验证通过，则验证人在变更申请单上记录 验证花费的工作量后提交CCB批准。若验证不通过，则记录验证花费的工作量后返回继续修改。 7、配置管理员做配置审计，配置管理员将所有变更的程序或文档返还放入受控库中，并对其进行变 更标识，例如：V1.0变更为V1.1。最后发布《配置状态报告》通知与变更有关的相关人员变更结束。 8、配置项变更结束后，CM更新《变更跟踪表》。 配置项计划及跟踪表包含哪些内容？CM配置项状态有几种？ 配置管理计划，配置管理备份表，配置审计报告。配置项的状态分为：建立,修改,删除 配置库分为开发库和受控库（详见配置库管理和配置管理计划中的配置库结构）基线库的结构分为计 是否清楚CM库结构、基线库结构？ 划文档、需求文档、设计文档、测试文档、源代码、安装包
经过评审的配置项纳入基线，该配置项发生变更要走的变更办理流程。 所有基线变更要通过CCB评审。 产品库、受控库、产品库 变更申请有项目经理做影响分析，分析内容包括：是否属于基线变更或配置项变更，填写变更申请单 提交CCB评审通过后，执行变更，配置管理员发布状态报告通知项目组成员。 有配置管理员及时维护《变更跟踪表》来记录变更的状态。变更跟踪的状态：待变更,变更中,变更完 毕,作废 配置状态报告在基线的建立、发布、变更时发布。目的是及时、准确的给出软件配置项的当前状态， 供相关人员了解，已加强配置管理工作。 配置状态报告信息包括1.配置项的当前标识 2.已交付软件的配置 3.变更请求或问题报告的状态 4.已获准变更的状态。 当项目里程碑之后，该基线通过评审的配置项已经齐全，建立相应的基线。 如用户需求说明书，需求规格说明书，需求跟踪矩阵在里程碑时间通过评审之后就可以建立需求基线 。 基线是软件文档或源码(或其它产出物)的一个稳定版本，作为下一步开发的基础。 基线分为需求基线，设计基线，交付基线 使用标准版本编号方式（形式是m.n，其中m代码版本号，从0开始，n代表该版本的修订次数，从0开 始。正式发布为1开始） １．版本控制 ２．变更管理 ３．配置数据 ４．配置库的管理 ５．发布管理 ６．流程 1记录与配置相关的所有信息。2利用库中的信息可评价变更的后果。3可利用库中的信息查询 开发人员权限不同访问配置库，详见《软件开发源代码配置管理指南》 识别配置项的原则 1、交付给客户的产品或工作产品 2、内部指定的工作产品(例如各种计划) 3、对于产品质量起关键作用的工作产品(例如测试数据和脚本) 4、从外部获取的产品(例如从外部采购来的工作产品) 5、工具(编译器等) 6、对于组间交互起重要作用的工作产品(例如干系计划) 7、被两个或多个组共同使用的工作产品 走变更流程，CCB决定变更基线。基线变更后的配置项由配置管理员在配置库中进行标识基线版本， 并发布配置状态报告通知项目组成员。 在配置管理状态报告中记录配置项的名称、版本...变更过程、不同基线间的差异。 把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂 的软件开发变的容易控制和管理。通常，软件生存周期包括可行性分析与开发项计划、需求分析、设 计（概要设计和详细设计）、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同的 阶段去完成。 每个阶段结束时间设为该阶段的里程碑。 每个阶段里程碑结束之后，建立基线。基线是软件文档或源码(或其它产出物)的一个稳定版本，作为 下一步开发的基础。 需求基线.设计基线.交付基线