内容发布更新时间 : 2024/5/18 15:46:05星期一 下面是文章的全部内容请认真阅读。
CMMI访谈提问单
依据审计结果，你有没有向组织级提供过改进或防止的行动？PPQA2.2 自由发挥
第 26 页/共 35 页
CMMI访谈提问单
1. QA怎样确保度量目标与商业需求的一致性？MA1.1 依据组织的质量目标定义 依据客户对产品的质量要求
2. 为项目定义的度量项有哪些？MA1.2 (1) 需求（变更数、变更比例、实现率） (2) 项目（规模、进度、工作量） (3) 风险（识别、转化、总数）
(4) 质量保证（不符合项、延迟时间、解决问题工作量）
(5) 验证和确认（评审工作量、评审效率、测试工作量、测试效率、测试返工工作量） (6) 技术解决和产品集成代码行(计划的产品组件代码行、已执行的产品组件代码行) (7) 配置管理（配置项变更的数量、配置审核次数）
3. QA怎样收集和保存组织级的度量数据MA1.3,MA2.1,GP2.6,OPD1.4
在项目的每个阶段，由QA从项目周报中收集项目级数据上报到组织度量库，由组织级QA（EPG）分析公司的整体进度、工作量、质量状况
(1)项目级QA从项目周报中收集并记录到度量分析报告汇报给组织级QA (2)工期每阶段记录到度量分析报告中
(3)项目缺陷从评审问题单和缺陷管理工具TD中收集并记录到度量分析报告中 (4)数据存放位置：配置库VSS 中;具体分为：实施类/技术类文档，报告类文档 4. 你怎样交流和利用度量结果的？MA2.4，GP2.5
(1)项目组内部主要通过配置管理工具VSS将度量结果提交到配置库，所有项目组成员可以访问
(2)中高层主要通过发布里程碑报告
(3)通过公司体系培训，技术类培训，项目组内培训来交流度量结果
第 27 页/共 35 页
1. QA怎样确保度量目标与商业需求的一致性？MA1.1 依据组织的质量目标定义 依据客户对产品的质量要求
2. 为项目定义的度量项有哪些？MA1.2 (1) 需求（变更数、变更比例、实现率） (2) 项目（规模、进度、工作量） (3) 风险（识别、转化、总数）
(4) 质量保证（不符合项、延迟时间、解决问题工作量）
(5) 验证和确认（评审工作量、评审效率、测试工作量、测试效率、测试返工工作量） (6) 技术解决和产品集成代码行(计划的产品组件代码行、已执行的产品组件代码行) (7) 配置管理（配置项变更的数量、配置审核次数）
3. QA怎样收集和保存组织级的度量数据MA1.3,MA2.1,GP2.6,OPD1.4
在项目的每个阶段，由QA从项目周报中收集项目级数据上报到组织度量库，由组织级QA（EPG）分析公司的整体进度、工作量、质量状况
(1)项目级QA从项目周报中收集并记录到度量分析报告汇报给组织级QA (2)工期每阶段记录到度量分析报告中
(3)项目缺陷从评审问题单和缺陷管理工具TD中收集并记录到度量分析报告中 (4)数据存放位置：配置库VSS 中;具体分为：实施类/技术类文档，报告类文档 4. 你怎样交流和利用度量结果的？MA2.4，GP2.5
(1)项目组内部主要通过配置管理工具VSS将度量结果提交到配置库，所有项目组成员可以访问
(2)中高层主要通过发布里程碑报告
(3)通过公司体系培训，技术类培训，项目组内培训来交流度量结果
5．项目中建立了哪几条基线，如何建立基线？CM SP1.1,SP1.2,SP1.3
(1) 需求开发基线、设计基线、编码基线、测试基线、产品基线。 (2) 项目经理根据配置管理计划提出基线建立申请，安排项目组成员填写《基线发布报 告》的申请部分；
基线建立申请人组织相关人员（至少包括：项目经理、技术组），对基线所属的配 置项进行评审，根据评审情况，评审组长（一般为项目经理）填写《基线发布报告》 中的“检验”部分；
评审通过后，基线建立申请人将《基线发布报告》提交给CCB负责人审批； 配置管理员在受控库中对组成基线的配置项进行标识，并在《配置项状态记录》、 《基线发布记录》做相应记录。
6．如何进行配置审计？CM SP3.1,SP3.2
(1) 对配置库状况进行审计，确定配置库中的配置项和建立的基线的正确性和完整 性，并且记录审计结果。配置审计的频度与QA检查频率保持一致。
(2) 审查包含的内容有：
——评估基线的完整性。
——检查配置记录是否正确反映了配置项的配置情况。 ——审查配置管理系统中配置项的结构完整性。 ——验证配置管理系统中配置项的完备性和正确性。
第 28 页/共 35 页
——验证是否符合使用的配置管理标准和规程。 ——对审计后提出的各项行动进行跟踪，直到结束。 (14) 审计工作分为功能审计和物理审计。
功能审计中对代码的审计由测试人员(QC)和配置管理员 共同完成。对于文档和代码 的审计依据分别为评审报告和测试报告，物理审计由配置管理员和QA共同完成， 以质量保证报告为依据。配置审计结果记录在《配置审计报告》中。
7．基线变更的流程？CM SP2.1、SP2.2
(1) 基线变更控制过程：
项目经理提出基线变更申请，填写《配置项变更申请表》。 ——CCB评估此次基线变更，批准《配置项变更申请表》。
——配置管理员对该基线进行变更标识，例如：BMJ_SRA_V1.0变更为BMJ_ SRA_V2.0。
——配置管理员将其记录于《基线发布记录》，并将变更情况通知项目经理和项目 组成员。
8．CCB的职责是什么？CM SP1.3,GP2.4,GP2.7、GP2.10
(1) 负责评审项目变更申请（如需求变更），决定采纳和拒绝变更请求；对项目变更的
决策结果进行确认工作。
9．你收到CM那些方面的报告？CM SP3.1,GP2.8
(1) 基线发布报告、配置审计报告、产品发布报告。
CM 配置管理
如何发布内部测试版本？CM SP1.3
首先由构造人员在本地机器上（可是构造人员自已的机器也可是其他机器，如其他服务器）为产品建立一个目录。
再从配置库上的基线库的代码基线中提取源代码到本地目录中，进行编译（编译的方法需根据开发语言的不同而有所分别，各项目的SCM人员根据实际情况在计划中详细描述）。 形成的可执行文件暂存放在本地目录下，批准之后将形成的可执行文件放入到配置库中更新测试基线。
从测试基线中提取可执行文件到测试域并进行测试。
通过一定的测试，经过CCB批准可以将形成的可执行文件放入到配置库的产品基线下。 “建立对应目录—>从配置库上提取文件—>编译—>测试—>修改—>重新编译”，其中“编译—>测试—>修改—>重新编译”是一个反复的过程，直至最后测试通过，提交最终产品。
如何获取需求变更的状态？CM SP2.1
(1) 需求变更申请需要CM开放权限，获取需求申请的状态
(2) 需求变更后重新基线需要向CCB申请，获取需求变更结束的状态
第 29 页/共 35 页
如何跟踪和维护项目的变更请求？CM SP2.1
配置管理员记录变更所产生的问题到《变更与问题日志》 (2) 配置管理员定期监督问题的状态
你如何控制配置项的变更？CM SP2.2 (1) 申请 (2) 开放权限 (3) 重新基线 (4) 收回权限
(5) 检查变更单记录 (6) 记录配置项变更记录
配置过程中主要维护哪些配置记录？在哪记录？CM SP3.1；GP2.6 (1) 配置管理计划 (2) 基线发布报告 配置项变更记录 配置项状态报告 配置审计报告
如何检查配置审计是否依据计划得到执行？谁执行配置审计？频度多高？CM SP3.2 (1) 依据配置管理计划定义配置审计计划，配置审计后发出配置审计结果，CM的配置 状态报告中须提供配置审计结果
(2) 如果有项目级和组织级CM，则配置审计由组织级CM执行，如果只有组织级CM， 则由QA执行，如果QA和CM同一个人，则由其他EPG执行 (3) 每阶段执行配置审计
接受过哪些关于配置管理的培训？CM GP2.5 配置系统客户端的使用(Visual Source Safe) 配置管理过程培训
配置管理工作有哪些度量？ GP2.8
(1) 配置项变更的数量、配置审核次数
高层如何了解配置管理的工作情况？ GP2.7、GP2.8、GP2.10
《度量分析报告》中关于配置（配置项的变更数量、配置审计次数）的度量情况 《配置审计报告》、《基线发布报告》、《产品发布报告》
备份工作是如何开展的？ CM SP1.2，IPM SP1.6，OPD SP1.6 (1) 按配置管理计划中的备份计划执行。
第 30 页/共 35 页