|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。
|
|
|
|
（2）控制承建单位依据书面规程，为应用软件系统建设项目制定软件配置管理计划。
|
|
|
|
（3）监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础。
|
|
|
|
（4）控制承建单位依据的书面规程，对所有配置项／单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。
|
|
|
|
（5）监督承建单位依据书面规程，控制对基线的更改。
|
|
|
|
（6）控制承建单位编制软件配置管理报告，证明软件配置管理活动和软件基线库的内容，并提供给建设单位。
|
|
|
|
（7）监督承建单位依据书面规程进行软件基线库的审核，进行软件配置管理活动状态的跟踪和记录。
|
|
|
|
（8）定期审查软件配置管理活动和软件配置管理基线，以验证它们与文档定义的一致性。
|
|
|
|
（9）审核软件配置管理活动及其工作产品，并给出软件配置管理监理报告。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
|
|
|
|
信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
|
|
|
|
|
|
根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
|
|
|
|
为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
|
|
|
|
|
|
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
|
|
|
|
|
|
变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
|
|
|
|
|
|
配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
|
|
|
|
（1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
|
|
|
|
（2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
|
|
|
|
|
|
状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置控制即配置项和基线的变更控制，配置控制包括如下活动：
|
|
|
|
.变更申请：相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给CCB。
|
|
|
|
.变更评估：CCB对变更申请进行评估并确定变更对项目的影响、变更的内容是否必要、变更的范围是否考虑周全、变更的实施方案是否可行、变更工作量估计是否合理。CCB对变更申请作出决定。
|
|
|
|
.通告评估结果：CCB把关于变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
|
|
|
|
.变更实施：项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。
|
|
|
|
.变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。
|
|
|
|
.变更的发布：配置管理员将变更后的配置项纳入基线并将变更内容和结果通知相关人员，并做好记录。
|
|
|
|
为了解决一个文档的变更引起多个相关文档的变更时文档修改不全面，以及多个开发人员对同一部件进行修改引起版本混乱等问题，可以基于配置库进行变更控制。
|
|
|
|
|
|
|
|
|
|
下面以某软件产品的升级为例，说明基于配置库变更的流程：
|
|
|
|
（1）将待升级的基线（假设版本号为V1.0）从产品库中复制到受控库。
|
|
|
|
（2）程序员甲将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被检出后即被“锁定”，其他程序员无法检出，以保证同一段代码只能同时被一个程序员修改。
|
|
|
|
（3）程序员甲将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定”被解除，其他程序员可以检出该段代码了。
|
|
|
|
（4）软件产品的升级修改工作全部完成后，将受控库中的新基线更新到产品库中（软件产品的版本号更新为V1.1，旧的V1.0版并不删除，继续在产品库中保存）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置控制委员会（Configuration Control Board, CCB）负责对配置变更做出评估、审批以及监督已批准变更的实施。
|
|
|
|
CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员和配置管理员等。CCB不必是常设机构，可以根据工作需要组建。小的项目CCB可以只有一个人，甚至只是兼职人员。通常，CCB不只控制配置变更，还负有更多的配置管理任务，如配置管理计划审批、基线设立审批和产品发布审批等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读和人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
|
|
|
|
|
|
|
|
|
|
|
|
|
