A、标识配置项
B、控制配置项的变更
C、对工作结果的审核
D、缺陷分析
【解析】配置管理的工作任务:制定配置管理计划、确定配置标识规则、实施变更控制、报告配置状态、进行配置审核、进行版本管理和发行管理。
缺陷分析是指当发现产品或生产过程中存在缺陷后对其进行原因分析,跟配置工作不相关。
A、开发库
B、知识库
C、受控库
D、产品库
【解析】配置库:包括动态库(开发库)、受控库(主库)、静态库(产品库)和备份库。没有 B 知识库。开发库(动态库):存放开发过程中需要保留的各种信息。
受控库(主库):存放某个阶段的成果,库内信息的读写和修改都受限。
产品库(静态库):形成最终产品,等待交付或现场安装。库内信息严格受限。备份库:重要配置信息的备份,应急时恢复受损的配置库数据。
A、版本管理
B、发行管理
C、检测配置
D、变更控制
【解析】配置管理的工作任务:制定配置管理计划、确定配置标识规则、实施变更控制、报告配置状态、进行配置审核、进行版本管理和发行管理。没有检测配置。
A、动态库、静态库和产品库
B、开发库、备份库和产品库
C、动态库、主库和产品库
D、主库、受控库和产品库
【解析】配置库:包括动态库(开发库)、受控库(主库)、静态库(产品库)和备份库, A 是静态库和产品库重复了;B 虽然没重复,但一般来说,配置管理系统主要是动态库、主库和产品库,备份库不是主要的配置过程库;C 是对的。D 主库和受控库重复了。
(52)
A、开发库
B、服务器
C、受控库
D、产品库
(53)
A、开发库
B、服务器
C、受控库
D、产品库
【解析】开发库(动态库):存放开发过程中需要保留的各种信息。
受控库(主库):存放某个阶段的成果,库内信息的读写和修改都受限。
产品库(静态库):形成最终产品,等待交付或现场安装。库内信息严格受限。备份库:重要配置信息的备份,应急时恢复受损的配置库数据。
最终产品放入产品库,所以第 1 小题是D;注意要进行后续开发时,应转移到受控库,进行配置控制,第 2
小题是 C。
A、基线由一组配置项组成
B、基线不能再被任何人任意修改
C、基线是一组经过正式审查并且达成一致的范围或工作产品
D、产品的测试版本不能被看作基线
【解析】基线由一组配置项组成,A 正确;
要改基线中的项目,必须经过变更流程,不能任意修改,B 正确。
基线是一组经过正式审查并且达成一致的范围或工作产品,相对稳定,只能由指定的配置管理员通过配置变更 控 制 流 程 进 行 修 改 。 C 正 确 。 D 错误。测试版本即 BETA 版,接近于正式发版产品了,须看作基线。
A、目前配置项处于正式发布状态,配置项版本升级幅度较大
B、目前配置项处于正式发布状态,配置项版本升级幅度较小
C、目前配置项处于正在修改状态,配置项版本升级幅度较大
D、目前配置项处于正在修改状态,配置项版本升级幅度较小
【解析】版本号说明如下:
1.处于“草稿”状态的配置项的版本号格式为:0.YZ。
2.YZ 数字范围为 01~99。
3.随着草稿的不断完善,YZ 的取值应递增。YZ 的初值和增幅由开发者自己把握。
4.处于“正式发布”状态的配置项的版本号格式为:X.Y。
5.X 为主版本号.取值范围为 1~9。Y 为次版本号,取值范围为 1~9。6.配置项第一次“正式发布”时,版本号为 1.0。
7.如果配置项的版本升级幅度比较小,一般只增大Y 值,X 值保持不变。只有当配置项版本升级幅度比较大时.才允许增大X 值。
8.处于“正在修改”状态的配置项的版本号格式为:X.YZ。
9.配置项在修改时,一般只增大 Z 值,XY 值保持不变。
当配置项修改完毕,状态重新成为“正式发布”时,将 Z 值设置为 0,增加 X.Y 值。 根据题意,首先 2.0 是正式发布状态,然后 1.0 升到 2.0 是幅度较大的升级。所以答案 A。
A、防止向用户提交不适合的产品
B、确保项目范围的正确
C、确保变更遵循变更控制规程
D、找出各配置项间不匹配的现象
【解析】实施配置审核的意义:配置审核的实施是为了确保项目配置管理的有效性,体现配置管理的最根本要求,不允许出现任何混乱现象,例如:
•防止出现向用户提交不适合的产品,如交付了用户手册的不正确版本。
•发现不完善的实现,如开发出不符合初始规格说明或未按变更请求实施变更。
•找出各配置项间不匹配或不相容的现象。
•确认配置项已在所要求的质量控制审查之后作为基线入库保存。
•确认记录和文档保持着可追溯性。
所以B 不属于配置审核的作用。B 应该是确认范围。
A、知识库
B、开发库
C、受控库
D、产品库
【解析】最终产品入产品库。
受控库(主库):存放某个阶段的成果,库内信息的读写和修改都受限。
产品库(静态库):形成最终产品,等待交付或现场安装。库内信息严格受限。备份库:重要配置信息的备份,应急时恢复受损的配置库数据。
开发阶段中,工作产品信息信息存入受控库。
A、设计文件评审已通过,直接变更即可
B、设计基线已经建立,不允许变更
C、设计基线已经建立,若变更必须走变更控制流程
D、详细设计与设计基线无关,直接变更即可
【解析】基线是可以变更的,但必须遵循变更控制流程;任何变更,都应该执行变更控制流程。
A、目前配置项处于正在修改状态,配置项版本升级幅度较大
B、目前配置项处于正在修改状态,配置项版本升级幅度较小
C、目前配置项处于正式发布状态,配置项版本升级幅度较小
D、目前配置项处于正式发布状态,配置项版本升级幅度较大
【解析】1.11 和 1.12 说明正在修改,是小幅度升级。答案 B、版本号说明如下:
1.处于“草稿”状态的配置项的版本号格式为:0.YZ。
2.YZ 数字范围为 01~99。
3.随着草稿的不断完善,YZ 的取值应递增。YZ 的初值和增幅由开发者自己把握。
4.处于“正式发布”状态的配置项的版本号格式为:X.Y。
5.X 为主版本号.取值范围为 1~9。Y 为次版本号,取值范围为 1~9。6.配置项第一次“正式发布”时,版本号为 1.0。
7.如果配置项的版本升级幅度比较小,一般只增大Y 值,X 值保持不变。只有当配置项版本升级幅度比较大时.才允许增大X 值。
8.处于“正在修改”状态的配置项的版本号格式为:X.YZ。
9.配置项在修改时,一般只增大 Z 值,XY 值保持不变。
10.当配置项修改完毕,状态重新成为“正式发布”时,将 Z 值设置为 0,增加 X.Y 值。
A、代码走查
B、变更过程的规范性审核
C、介质齐备性检查
D、配置项齐全性审核
【解析】配置审计:配置审计的主要作用是作为变更控制的补充手段,来确保某一变更需求已被切实实现。包括:
一、功能配置审计 功能配置审计是进行审计以验证以下几个方面。
1.配置项的开发已圆满完成。
2.配置项已达到规定的性能和功能特定特性。
3.配置项的运行和支持文档已完成并且是符合要求的。
功能配置审计可以包括按测试数据审计正式测试文档、审计验证和确认报告、评审所有批准的变更、评审对以前交付的文档的更新、抽查设计评审的输出、对比代码和文档化的需求、进行评审以确保所有测试已执行。功能配置审计还可以包括依据功能和性能需求进行额外的和抽样的测试。
二、物理配置审计 物理配置审计是进行审计以验证如下方面:
1.每个构建的配置项符合相应的技术文档。
2.配置项与配置状态报告中的信息相对应。
物理配置审计可以包括审计系统规格说明书的完整性、审计功能和审计报告、了解不符合采取的措施、对比架构设计和详细设计组件的一致性、评审模块列表以确定符合己批准的编码标准、审计手册(如用户手册、操作手册)的格式、完整性和与系统功能描述的符合性等。
综上,A 是属于功能审计(对比代码和文档化的需求);BCD 与功能无关,是物理配置审计。
A、配置管理适合软件开发过程,集成过程无法建立配置管理
B、配置管理必须要有配置工具,否则无法建立
C、如果没有专用工具,用手工方式也可以进行配置管理
D、配置库中把各设施登记清楚就可以
【解析】A 错误,集成过程一样可以建立配置管理,也需要建立配置管理。如集成过程调研、及技术文档和成果、项目文档等等,都可以也需要建立配置管理。
B 错误,配置管理不一定要有配置工具,如简单的项目可以把文档及成果存在统一地方,通过规定的方法和流程来进行变更控制等也是可以的。不一定要有专门的配置工具。实际中配置可以是比较简单的。
C 和B 是相反的说法,C 是正确的。这里说的手工方式,应该是相对于专门配置系统而言的。
D 错误,不过再简单的配置库也要进行配置管理、配置控制等活动,而不是登记清楚就可以了。
用户 1:采用A、B、C、D、E 和 F 模块
用户 2:采用A、B、C、D、E、G 和 H 模块
根据配置管理要求,以下做法正确的是(C )。
A、在设计阶段用户 1 和用户 2 对应的相同模块的配置项可以合并为一个配置项
B、在设计阶段只需分别建立模块 F、G、H 的配置项,形成不同的基线
C、在设计阶段就要对两个用户所要求的所有模块分别建立配置项并形成基线
D、在后续开发阶段两个用户所要求的所有模块都要作为不同的分配置进行管理
【解析】两者的差别不仅表现在一个含有 F,另一个含有G 和 H ,而且即使两者的 A 在逻辑上是同一个内容,但在物理上仍然可能因两类用户需求的不同而有差异,例如,两个 A 分别以不同的媒体出现。为实现这两种不同的软件配置,在实际工作中,我们完全可以将各个配置项分别开发出来,再根据需要,组合成计对不同用户使用需求的不同产品。
所以C 是正确答案,在设计阶段就要对两个用户所要求的所有模块分别建立配置项并形成基线(包括后续开发和测试阶段都分别建立)
A、电子版文件可通过授权系统来控制收发
B、对于纸制文件可以采用编号、盖章等方法控制文件的有效性
C、发给客户的文件可以不进行文件回收管理
D、对现场使用的外来文件可不进行文件收发管理
【解析】这是考的文件管理常识。A 和 B 是常规作法,正确。C 因为发给客户了,所以可以不进行文件回收管理,很多也回收不了的。比如发给客户的方案,纸质文件等,客户也需要保存,所以可以不做文件回收管理。D 现场使用的文件,不管是内部的还是外来的,都需要进行收发管理。
①评估基线的完整性②检查配置记录是否正确反映了配置项的配置情况③审查配置项的结
构完整性④对配置项进行技术评审⑤验证配置项的完备性和正确性⑥验证是否符合配置管理标准和规程⑦ 对审计后提出的各项行动进行跟踪,直到结束
A、①②③④⑤⑥
B、①③⑤⑥⑦
C、②④⑤⑥⑦
D、①②③④⑦
【解析】配置审计:配置审计的主要作用是作为变更控制的补充手段,来确保某一变更需求已被切实实现。包括:
一、功能配置审计 功能配置审计是进行审计以验证以下几个方面。
1.配置项的开发已圆满完成。
2.配置项已达到规定的性能和功能特定特性。
3.配置项的运行和支持文档已完成并且是符合要求的。
功能配置审计可以包括按测试数据审计正式测试文档、审计验证和确认报告、评审所有批准的变更、评审对以前交付的文档的更新、抽查设计评审的输出、对比代码和文档化的需求、进行评审以确保所有测试已执行。功能配置审计还可以包括依据功能和性能需求进行额外的和抽样的测试。
二、物理配置审计 物理配置审计是进行审计以验证如下方面:
1.每个构建的配置项符合相应的技术文档。
2.配置项与配置状态报告中的信息相对应。
物理配置审计可以包括审计系统规格说明书的完整性、审计功能和审计报告、了解不符合采取的措施、对比架构设计和详细设计组件的一致性、评审模块列表以确定符合己批准的编码标准、审计手册(如用户手册、操作手册)的格式、完整性和与系统功能描述的符合性等。
综上来看,配置审计可以包括配置管理过程的各种活动和过程及管理的审计,注重过程。但审计后提出的各项行动跟踪,则不属于配置审计的内容。
A、工作状态、受控状态、评审状态
B、评审状态、工作状态、受控状态
C、工作状态、评审状态、受控状态
D、受控状态、评审状态、工作状态
【解析】(1)是工作状态,(2)是准备评审的,(3)是受控状态。
A、0.YZ
B、X.Y
C、X.Y.Z
D、X.YZ
【解析】送分题,正式发布就是 X.Y,如 1.0,2.0 等。
A、动态库
B、备份库
C、受控库
D、静态库
【解析】开发库(动态库):存放开发过程中需要保留的各种信息。
受控库(主库):存放某个阶段的成果,库内信息的读写和修改都受限。 用于管理当前基线和控制对基线的变更的配置库
产品库(静态库):形成最终产品,等待交付或现场安装。库内信息严格受限。备份库:重要配置信息的备份,应急时恢复受损的配置库数据。
A、重要版本
B、基线版本
C、所有版本
D、需要的版本
【解析】版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。
A、配置管理计划应由配置管理人员制订,由项目经理审批
B、配置管理计划应由项目经理制订,由配置控制委员会审批
C、配置管理计划应由项目经理制订,由 QA 人员审批
D、配置管理计划应由配置管理人员制订,由配置控制委员会审批
【解析】配置管理计划应由由配置控制委员会审批,先锁定 B 和 D 答案。配置管理计划当然应由配置管理人员来制订,而不是项目经理。所以答案 D 是正确的。
A、CM 的访问权限应由 PM 分配,且应得到 QA 的批准。
B、QA 的访问权限应由 PM 分配,其不参与项目时应将其权限转给 CM
C、分析人员、设计人员、开发人员的访问权限应由CM 分配,且应得到 QA 的批准
D、PM 的访问权限由其自己分配,且 PM 不在时其权限不能转给 QA 和CM
【解析】答案A:CM 是配置管理员,应有最高(或绝大部分吧)权限,PM 分配后也没必要 QA 来批准。所以 A 不对。
答案B:QA 的权限不能,也不需要转给 CM。不对。基于角色的访问控制:用户也不能自主地将访问权限传给他人,这是一种非自主型访问控制。
答案 C:这里说了项目经理才是系统管理员,所以访问权限应由项目经理分配,而不是 CM。
答案 D:正确,PM 是系统管理员,所以其防问权限由自己分配,系统管理员的权限不能转给 QA 和 CM。综上,答案为D,是基于角色的访问控制的规则来说的。
A、内部或外部
B、设计或构造
C、计划或发行
D、构造或发行
【解析】配置管理员根据《项目计划文档》、《配置管理计划》、《配置项管理表》等文档,创建构造或发行基线,供内部使用和交付给顾客。
A、第一次正式发布
B、修改后重新正式发布
C、正在修改
D、草稿
【解析】处于“正在修改”状态的配置项的版本号格式为:X.YZ。
A、用户
B、配置管理员
C、配置管理委员会
D、专家组
【解析】基线由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体,是一组经过配置管理委员会正式审查,批准,达成一致的范围或工作产品。或排除法:AB 都审批不了,D 专家不相干。
A、目前配置项处理第一次“正在修改”状态
B、目前配置项处于第一次“正式发布”状态
C、目前配置项处于“草稿”状态
D、目前配置项处于“不可变更”状态
【解析】处于正在修改状态的配置项的版本号格式为:X.YZ。处于“草稿”状态的配置项的版本号格式为 O.YZ。
处于“正式”状态的配置项的版本号格式为X.Y。
A、防止向用户交付用户手册的不正确版本
B、确保项目进度的合理性
C、确认项目分解结构的合理性
D、确保活动资源的可用性
【解析】实施配置审核的意义:配置审核的实施是为了确保项目配置管理的有效性,体现配置管理的最根本要求,不允许出现任何混乱现象,例如:
•防止出现向用户提交不适合的产品,如交付了用户手册的不正确版本。
•发现不完善的实现,如开发出不符合初始规格说明或未按变更请求实施变更。
•找出各配置项间不匹配或不相容的现象。
•确认配置项已在所要求的质量控制审查之后作为基线入库保存。
•确认记录和文档保持着可追溯性。
综上来看,只有答案A 正确。BCD 是项目管理里进度或范围管理的内容。
(64)
A、软件元素
B、软件项目
C、软件配置项
D、软件过程
(65)
A、配置项标识
B、配置项优化
C、配置状态报告
D、配置审计
【解析】配置项才配置管理的对象,ABD 都不是配置管理的内容。
配置管理的四个活动:配置标识、配置控制、配置状态统计、配置审计。
补充:配置项的内容主要包括两大类:一是属于产品组成部分的工作成果,包括:需求文档、设计文档、源代码、测试用例、运行软件所需的各种数据等;二是项目管理和过程域产生的各种文档,包括:工作计划、项目计划、质量报告、项目跟踪报告等。
A、V1.3
B、V1.5
C、V2.0
D、V3.0
【解析】C 配置项版本格式 X.Y,如果改动较小则增大 Y 值;如果有较大修改,则增大 X 值。题目中,项目进行了较大的改动并通过评审。所以版本号应升级为 v2.0。
(62)
A、用户
B、配置管理员
C、配置控制委员会
D、专家组
(63)
A、配置项、标识符、版本、流程
B、配置项、名称、流程、日期
C、名称、标识符、版本、日期
D、配置计划、版本、状态、流程
【解析】记住:配置管理计划、基线等重要配置管理事项,都是由配置控制委员会(或配置管理委员会)来审批。
基线(Baseline)由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了,不能再被任何人随意修改(例如,跟踪和控制变更)。基线通常对应于开发过程中的里程碑(Milestone),
—个产品可以有多个基线,也可以只有一个基线。基线的主要属性有:名称、标识符、版本、日期等。通常将总价值给客户的基线称为一个“Release”,为内部开发用的基线则称为一个“Build”。产品的一个测试版本
(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。
A、目前配置项处于“不可变更”状态
B、目前配置项处于“正式发布”状态
C、目前配置项处于“草稿”状态
D、目前配置项处于“正在修改”状态
【解析】处于正在修改状态的配置项的版本号格式为:X.YZ。
A、获取 CCB 的授权、创建构造基线或发行基线、形成文件、使基线可用
B、形成文件、获取 CCB 的授权、创建构造基线或发现基线、使基线可用
C、使基线可用、获取 CCB 的授权、形成文件、创建构造基线或发行基线
D、获取 CCB 的授权、创建构造基线或发行基线、使基线可用、形成文件
【解析】创建基线或发行基线的主要步骤如下:获取 CCB 的授权、创建构造基线或发行基线、形成文件、使基线可用等。
A、目前配置项处于“不可变更”状态
B、目前配置项处于“正式发布”状态
C、目前配置项处于“草稿”状态
D、目前配置项处于“正在修改”状态
【解析】 “正式发布”时,版本号为 X.Y,1.0 即为正式发布状态。
(62)
A、软件元素
B、软件项目
C、软件配罝项
D、软件过程
(63)
A、配置项标识
B、配置项优化
C、配置状态报告
D、配置审计
A、②③⑤⑦
B、①③⑤⑥
C、①③⑤⑦
D、②④⑥⑦
【解析】参见GB/T8566-2007《信息技术软件生存周期过程》标准 6.2.3节。(标准PDF可在云盘里-国家及行业标准中下载)。如果没有有看过此标准,大家以通过这个思路来做题:首先明确配置控制其实主要内容就是变更控制,所以②③⑤是变更控制的内容,可以锁定答案A。
①技术评审或领导审批②正式发布③修改处于“草稿”状态的配置项④创建配置项
A、①④③②
B、③②①④
C、④③①②
D、④③②①
【解析】配置项版本控制流程:创建配置项——修改处于“草稿”状态的配置项——技术评审或领导审批
——正式发布——变更。这个步骤用猜其实也猜的出来。
A、建立基线的条件
B、基线识别
C、受控制项
D、批准基线变更的权限
【解析】基线定义的内容,对于每一个基线,要定义下列内容:建立基线的事件、受控的项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中,每个配置项的基线都要纳入配置控制,对这些基线的更新只能采用正式的变更管理过程。这确保了基线的变更只反映已批准的组件部分的变更。不包括B基线识别。
A、详细设计
B、概要设计
C、进度计划
D、源代码
【解析】进度计划属于项目管理计划,也可以是配置项。但题目问的是基线配置项,相比较而言,详细设计、概要设计和源代码的成果是一定要进入基线配置项的,因为这些是软件开发的产品过程成果,必须纳入基线严格管理。进度计划则不一定需要纳入基线,在软件研发的实际中,进度计划一般不会纳入基线来管理,没必要。
(62)
A、项目经理
B、技术负责人
C、配置管理员
D、变更控制委员会
(63)
A、“草稿”变迁为“正在修改”
B、“正式发布”变迁为“正在修改”
C、“Check in”变迁为“Check out”
D、“Check out”变迁为“Check in”
【解析】变更由变更控制委员会审批,第一小题答案为 D。
配置项的状态有三种:草稿(Draft)、正式发布(Released)和正在修改(Changing)。
配置项刚建立时其状态为“草稿”。配置项通过评审(或审批)后,其状态变为“正式发布”。此后若更改配置项,必须依照“变更控制规程”执行,其状态变为“正在修改”。当配置项修改完毕并重新通过评审(或审批)时,其状态又变为“正式发布”,如此循环。
A、软件开发人员对源文件的修改在配置库中进行
B、受控库用于管理当前基线和控制对基线的变更
C、版本管理与发布由 CCB 执行
D、软件版本升级后,新基线存入产品库且版本号更新,旧版本可删除
**【解析】A 答案说法不准确,配置库也包括受控库和产品库等,这些都是严格受控的。源文件一旦评审通过做为基线入配置库,即“冻结”,不允许对其任意修改。
B 答案是正确的,受控库,也称为主库或系统库,是用于管理当前基线和控制对基线的变更。受控库包括配置单元和被提升并集成到配置项中的组件。
C 答案不正确,版本管理与发布应由 CMO 配置管理人员来执行。
D 答案不正确。配置管理需保留所有版本,旧版本不可删除。 **
A、配置控制委员会成员必须是专职人员
B、配置库包括动态库(开发库),受控库(主库)、静态库(产品库)
C、常用的配置管理工具有 SVN、GIT 等
D、配置项的状态分为草稿、正式和修改三种
【解析】高级教材第三版 P474:配置控制委员会负责对配置变更做出评估、 审抽以及监督巳批准变更的实施。建立在项目级,其成员可以包括项目经理、用户代表、产品经理、开发工程师、 测试工程师、质量控制人员、配置管理员等。不必是常设机构,完全可以根据工作的需要组成,小的项目可以只有一个人,甚至只是兼职人员。A 是错误的。
A、确定受变更影响的关联配置项和有关基线
B、将变更申请的决议通知受此变更影响的每个干系人
C、组织修改配置项,并在相应的文档或程序代码中记录变更信息
D、将变更后的配置纳入基线,并将变更内容和结果通知相关人员
【解析】高级教材第三版P477:6 )变更的发布:
配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员,并做好记录。D 是正确答案。
答案 A 参见 P476:变更申请的相关人员,如项目经理填写变更申请表等,并说明受变更影响的关联配置项和有关基线。这个不是 CMO 的工作。
答案B 参见 P477:通告评估结果是 CCB 的责任。答案C 参见 P477:项目经理组织修改配置项。
A、配置状态报告
B、配置审计
C、配置控制
D、配置标识
【解析】参考高级教材第三版 P476,确定配置项的所有者及其责任,确定配置项进入配置管理的时间和条件是配置标识的工作。
A、CCB 负责分配配置库的操作权限
B、CCB 负责制定配置管理计划
C、CCB 必须是常设机构
D、CCB 可以是兼职人员
【解析】参考高级教材第三版 P473-475:
A 是错误的,配置管理员分配置库的操作权限;
B 错误,配置管理员制定配置管理计划
C 错误,CCB 不必是常设机构。
D 正确,CCB 成员可以兼职
A、产品库 开发库 受控库
B、受控库 开发库 产品库
C、受控库 产品库 开发库
D、产品库 受控库 开发库
【解析】高级教材第三版P477:
(1)将待升级的基线(假设版本号 V2.1)从产品库中取出,放入受控库。
(2)程序员将欲修改的代码段从受控库中检出(Checkout),放入自己的开发库中进行修改。代码被 Check
out 后即被“锁定”,以保证同一段代码只能同时被一个程序员修改,如果甲对其修改,乙就无法。
(3)程序员将开发库中修改好的代码段检入(Checkin)受控库。 Checkin 后,代码的锁定被解除,其他程序员可以 Checkout 该段代码了。
(4)软件户品的升级修改工作全部芫成后,讲受控库中的新基线存入产品库中。
(软件产品的版本号更新为V2.2,旧的 V2.1 版并不删除,继续在产品库中保存)。
A、某个配置项的版本号为 0.91,该配置项的状态为“正式”
B、配置项版本管理的目的是保留配置项的最新版本,删除所有旧的,避免发生混淆
C、一个产品只能有一个基线,因此,对基线的变更必须遵循正式的变更控制程序
D、开发库中的信息可能频繁修改,因此可以由开发人自行控制
**【解析】开发库不受控,可以自行控制,D 正确。
一个产品可以有多个基线,也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release),内部开发使用的基线一般称为构造基线(Build)。C 是错误的。 **
A、基线设立审批
B、版本管理和配置控制
C、建立和维护配置库
D、配置状态报告
【解析】基线设立审批是配置控制委员会的工作职责。
A.产品库 开发库
B.受控库 开发库
C.产品库 受控库
D.受控库 产品库
【解析】待修改的代码段从受控检出,在开发库中修改。
A.开发库、受控库
B.受控库、开发库
C.受控库、产品库
D.产品库、开发库
【解析】受控库中检出,开发库里修改。