软件配置管理.pdf
软件配置管理
1、简介
软件配置管理，贯穿于整个软件生命周期，它为软件研发提供了一套管理办法和活动原则。软件配置管理无论是对于软件企业管理人员还是研发人员都有着重要的意义。软件配置管理可以提炼为三个方面的内容：
●VersionControl-版本控制
●ChangeControl-变更控制
●ProcessSupport-过程支持
关键活动包括：配置项、工作空间管理、版本控制、变更控制、状态报告、配置审计等。
2、软件配置管理技术
软件配置管理是一组活动,是设计用来标识变更的工作产品、建立它们之间的关系、定义管理这些工作产品不同版本、控制变更以及审计和报告所发生的变更。每一个涉及到软件工程过程的人员均在某种程度上和SCM相关联。一般情况下需要专门的SCM小组或专门的技术人员来管理和支持。下面通过依次介绍配置管理过程中的主要活动来描述配置管理过程。
2.1识别配置项
在项目开发过程中，程序、数据和文档都可以作为配置管理的对象，下面以图的形式来列举可能的配置项，如图2-1所示，由图可以看出配置项之间是组合关系或者相互关系。
图2-1可能的配置项
2.2基于配置项版本控制
版本控制是将规程和工具相结合来管理在软件工程过程中所创建的配置对象的不同版本，通过“属性元组”等其它技术来控制完整版本中的“变体”，采用不同的工具不同的技术，版本控制的机制会有一些不同。
2.3变更控制
变更在软件开发过程中是不可避免的，但过于频繁的变更也会对项目的开发产生负面的影响，如影响项目的进度、浪费人力物力，因此需要对变更进行控制。
变更控制可以依照如下的步骤来进行：
（1）提交变更请求；
（2）审核变更请求；
（3）分配和确定任务；
（4）提取变更项；
（5）执行变更；
（6）审核变更；
（7）更新配置管理库。
整个变更控制的产物主要是变更请求单、变更报告单、工程变更单或变更确认单等。
2.4配置审计
配置审计一般包括两种，一种是正式的技术评审，另一种是软件配置审计。
在正式的技术评审中，将关注已经被修改的配置项的正确性，配置项的评估配置项，以确定它与其他一致性、遗漏及潜在的副作用。正式评审应该针对于所有的变更。
而另外一种软件配置审计，是来评估正式评审中没有考虑的那些特征，可以考虑如下方面：
（1）工程变更单（ECO）中的相关内容是否已经完成；
（2）是否已经进行了正式的技术评审；
（3）变更过程中是否遵循了软件工程标准；
（4）在对配置项修改的同时，是否有相关的详细注释（comments）；
（5）在配置管理工具中是否标注了变更后的配置项状态；
（6）所有与该配置项相关的配置项是否进行了相应的更新。
2.5发布配置状态报告
配置状态报告（Configuration State Report,CSR）是SCM的一个任务，它在中大型项目中扮演着重要的角色，内容可以包括：修改了什么、谁修改的、修改是什么时候发生的以及修改有什么影响，一般情况下，是在一个配置项被
赋上新的或已经修改的标识时，或者一个变更被批准时，或者产生配置审计结果时产生配置状态报告。还可以将CSR放于一个联机数据库中，使得开发者、维护者和管理者可以通过关键词等方式去访问。
2.6发布管理
当项目进行到一定的阶段，可能需要发布一个稳定的或相对比较稳定的版本，这个时候就需要首先制定发布实施计划，然后生成发布准备报告，最后发布完成生成发布报告。
3、软件配置管理工具Rational ClearCase介绍
3.1VOB
VOB（Versioned Object Base），即版本对象库，这是SCM系统的核心，用来存储文件、目录和元数据的永久数据存储池。它能够管理任何表示为文件或目录的对象。它支持的特征包括：
（1）可扩展的。ClearCase VOB中的元素可以从成百上千的文件演变成成千上万的文件和目录，当VOB变得很大时，一个VOB中的文件和目
录可以在多个VOB间移动。一个VOB可以被分成多个VOB，多个VOB
也可以相互连接。
（2）容错性。ClearCase VOB使用内部数据库，不需要进行额外的数据库管理。
（3）分布式。ClearCase VOB可以分布在网络的不同服务器上，对于最终用户是透明的。
（4）可复制。这里的复制是指在不同地理位置上进行完全的复制并保持相互间的同步更新。ClearCase VOB可以在两点或多点进行复制。可
复制是异地分布开发的关键。
ClearCase有两种VOB，一种是标准VOB，另一种是项目VOB（project VOB，简称PVOB），PVOB中包含与项目环境相关的对象。简言之，VOB存储和组织的
对象组成了正在开发的系统，而PVOB存储的对象则用来组织和管理正在开发的项目。
3.2配置规格（config spec）
定义在一个视图中可以看到哪些元素的哪些版本。对于使用UCM模型的项目，ClearCase自动生成配置规格。对于不使用UCM的项目，可以使用默认配置规格，或手工生成配置规格，还可以使用脚本生成配置规格。
3.3工作空间
在ClearCase中，工作空间被称为“视图（view）”，视图的主要目的是为开发者提供一组稳定的、一致的软件内容，在视图中可以进行变更和执行单元测试。视图依据一组配置规格定义从VOB内所有可用版本中选择文件和目录的合适版本。
ClearCase提供了两种视图，快照视图（snapshot）和动态视图(dynamic)。
快照视图将文件的拷贝从VOB中下载到视图中，使用一个数据库跟踪下载到本地工作目录中的版本，可以使用配置规格中的load语句来限制哪些元素从VOB 拷贝到快照视图中。
动态视图通过一个称为“多版本的文件系统（Multiversioned File System，简称MVFS）的虚拟文件系统提供对于元素版本的存取操作，不用将元素拷贝到本地目录中，这个虚拟文件系统直接指向VOB中的元素。当在MVFS文件系统中使用编辑器的工具访问文件时，MVFS会中断文件打开命令，判断用户在什么视图中工作，再判断选择文件的哪个版本正确，然后打开文件的那个版本。动态视图是ClearCase所特有的。
3.4项目管理：项目、工作流和活动
由于软件开发活动的规模和复杂性，项目管理需要自动化和工具来协助组织和管理大型软件项目。ClearCase UCM拥有辅助管理和组织软件项目的对象和自动化功能，包括：项目、工作流和活动。
项目管理研究所（PMI）学院如下定义项目：
在有限资源条件下，人们用于规划、执行和控制活动而付出的努力。项目是为了创建“一个”产品或者服务而付出的“临时性”的努力。“临时性”的含义是每个项目都有明确的开始时间和结束时间。“一个”的含义是该产品或者服务在某些方面与其他的产品或者服务有明确的不同之处。在组织机构的各个层次都在进行着各种项目。项目中可能牵涉一个人或者是成百上千的人。项目可能只花费不足100个小时，也许会耗费超过100000000个小时。项目可能涉及一个机构的一个部门，也可能是跨越组织机构边界的合资或合作伙伴。项目通常是贯彻机构业务策略的要件。
ClearCase UCM中的项目代表一组独立的个人协作生成新的基线，这个基线由一个系统的一个或多个构件组成。使用ClearCase项目，其属性定义了项目范围和工作的对象以及策略，策略包括：项目分配工作的策略，工作空间（工作流和视图）的策略，还有项目成员执行哪些活动的策略。
一个工作流为其关联的一个或多个视图定义了工作配置，它包括为创建视图自动生成配置规格所需要的信息。每个项目有一个集成流（integration stream）和多个开发流（development stream）。
工作流主要有两个作用：
（1）配置与工作流相关联的视图。他们配置视图来选择正确的文件版本，在工作流中从事项目工作。
（2）工作流物理地存储开发人员工作在视图中的活动。
活动用于跟踪完成一项开发任务的工作。它包括一个文本标题，标题描述了任务和变更集，标题还标识了这个活动中所创建或者修改的所有版本。活动对象的主要任务就是跟踪变更集和结果。
3.5版本对象：元素、分支和版本
在ClearCase中，元素（element）就是置于版本控制下的文件和目录。每个元素记录了它所代表的文件或目录的版本。这些元素版本被组织成不同的分支，分支就是版本的序列。
3.6构件管理：构件和基线
将被一起开发、集成、基线和发布的文件和目录聚集在一起就形成了构件，构件通过一个根目录来定义。
构件的一个版本就是一个基线。构件基线标识了构件中包含的每个元素的零或一个版本。每个基线有一个用户定义质量和晋升级别。一个公司可以使用ClearCase定义不同的测试水平并标识基线，表示每个基线已通过的测试水平。
3.7过程：标签、属性、超链、触发器
标签（Label）是一个标签类型的一个实例，并被关联到一个元素的一个版本上。标签类型是一个冠名的标记符，用来标识一组相容的元素版本。在UCM 里不需要自己创建和生成标签。
属性类型由一对数据/值构成，能够把属性（Attribute）实例关联到几乎所有的ClearCase对象上。
超链（Hyperlink）定义对象间的关系。
触发器（Trigger）是用户定义的事件，当某些ClearCase操作发生时被激活。
触发器有两种不同的类型：事前触发和事后触发。事前触发的触发器在ClearCase事件发生前被激活，可以取消触发的事件，它的典型应用是强制制度；事后触发在ClearCase事件发生后被激活，它的典型应用是通知。
4组织和职责
4.1配置管理组（CM）
配置管理组由配置经理和专职配置管理员组成，配置经理可以由技术经理或其他人员担任。配置经理要熟悉机构的配置和变更管理流程，并且要熟悉所采用的SCM工具。在开发人员开始工作之前，配置管理员一定要确立SCM环境，这有两个关键步骤：建立硬件环境和建立开发环境。配置管理员协同系统管理
员评估和分配硬件资源，然后还要在服务器端和客户端安装ClearCase，接下
来就可以建立开发环境了。配置管理员要和系统架构师一起确定实施模型、创建存储池、创建产品的目录结构、创建初始的版本化元素。
总结后可以列出配置经理的主要工作职能包括以下几点：
（1）负责识别项目配置项，形成项目配置项基线计划；
（2）负责确定项目配置项标识规定；
（3）归并集成；
（4）构建系统；
（5）申请基线变更；
（6）建立发布版本。
配置管理员的主要工作职能包括以下几点：
（1）制定与维护项目的配置管理计划；
（2）建立与维护项目配置管理库；
（3）为项目组成员进行配置管理工具与配置库的培训；
（4）对已提交的配置项进行配置审计，并建立相应的基线；
（5）按照配置管理过程、标准、计划等执行配置管理活动，执行基线与其他配置项的变更控制流程。
4.2变更控制委员会（CCB）
项目组设立变更控制委员会CCB，成员一般由项目经理（PM）、技术经理（TM）、质量保证经理、配置经理组成，在处理具体配置项变更时，根据具体情况，CCB成员会做相应的变动。本项目的CCB成员包括：A、B、C、D、E和F。
CCB成员的主要职能为以下几点：
（1）判断变更申请的级别和有效性，并反馈给配置管理员；
（2）对变更后的配置项审核，将审核结果填写至变更单中；
（3）对评审变更的影响范围、工作量等负责；
（4）对变更申请做出裁决；
（5）跟踪变更状态，验证变更并负责；
4.3组评审委员会（GRB）
项目组设立变更控制委员会GRB，成员一般由项目经理、技术经理、质量保证经理、配置经理组成。GRB成员在整个开发过程中，对整个开发的产出物进行评审，具体包括：
（1）制定访问控制和开发策略；
（2）审核配置管理计划；评审并批准基线的建立；
（3）评审在开发阶段所有的产出物；
（4）审核发布版本。
5、项目命名规定
为了管理的规范化，对项目中所使用的标识的命名作出如下规定：
（1）技术文档标识规定：CRM24-文档类型名称
（2）质量记录标识规定：CRM24-文档类型名称–序号
（3）代码标识规定：项目启动阶段，由项目经理或技术经理负责提供，GRB审核。
（4）会议记要：CRM24-文档类型名称–开会日期
（5）项目周报：CRM24-文档类型名称–提交日期
（6）技术讨论记录：CRM24-文档类型名称–讨论日期
6、项目软件配置管理活动
6.1识别项目中的配置项
项目中可以纳入配置管理库的所有配置项如下：
（1）开发文档方面：
表4-1开发文档中的配置项
文档根目录子目录子目录子目录各目录描述
01-开发文档
存放项目开发过程中需要纳
入配置管理的开发文档
01-需求阶段
01-草稿
存放需求阶段中所有文档的
草稿
02-发布文档
存放通过评审的需求规格说
明书，该目录仅由配置管理
员操作，其他人员具有只读
权限
03-参照文档
存放与该阶段相关的参考资
料、规范
04-评审记录
存放需求规格说明书的评审
记录
02-设计阶段
01-架构设计架构设计说明书
02-界面设计系统界面设计说明书
03-数据库设
计
数据库设计相关文档
04-详细设计
01-草稿详细设计所有文档的草稿
02-发布存放通过评审详细设计说明书，该目录仅由配置管理员操作，其他人员具有只读权限
05-参照文档存放与该阶段相关的参考资料、规范
06-评审记录设计阶段GRB产生的评审报告记录
03-编码阶段
01-相关文档编码阶段涉及的资料文档、规范文档、技术文档
02-单元测试
01-测试
用例
测试单元模块设计的用例
02-测试数据测试单元模块所要使用的数据
03-测试工具测试单元模块的工具，以及工具的使用文档
04-测试
报告
单元测试结果报告
04-测试阶段
01-集成测试
01-测试
用例
为集成测试设计的用例文档
02-测试
数据
集成测试所要使用的数据
03-测试集成测试所需工具，以及工
工具具使用文档
04-测试
集成测试结果报告
报告
02-系统测试
01-系统
测试计
划
02-系统
为系统测试设计的用例文档
测试用
例
03-系统
系统测试结果报告
测试报
告
05-实施阶段
01-用户手册
02-系统操作
手册
03-系统维护
手册
06-维护阶段
01-维护记录
07-技术讨论
小结
（2）代码：
表4-2代码中的配置项
文档根目录子目录子目录子目录各目录描述
02-
source_code
common_module共通模块的代码
common_form共通子画面的代码
login登陆模块的代码
customer顾客检索模块的代码
employee社员检索模块的代码
device设备检索模块的代码
repairment修理检索模块的代码
circulation入出库检索模块的代码
quality质量检索模块的代码
examine检查检索模块的代码
information相关资料检索模块的代
码
manage_system社内体制模块的代码
data_maintenance数据维护模块的代码
manage_parameter管理指标模块的代码
（3）项目管理方面：
表4-3项目管理中的配置项
文档根目录子目录子目录子目录各目录描述
03-项目管
理
01-售前文档
报价
标书
建议书02-项目计划
03-验收文档
04-项目报告阶段性提交项目完成情况报告,项目总结报告
05-会议纪要
06-外来文件原有的ASP系统的源代码
07-项目讨论
稿
（4）配置管理文档方面：
表4-4配置管理文档中的配置项
文档根目录子目录子目录子目录各目录描述04-配置管理
01-软件配置管
理计划
02-变更管理变更申请单，变更单
03-配置状态报
告
（5）工具和参考资料方面：
表4-5工具和参考资料中的配置项
文档根目录子目录子目录子目录各目录描述
05-工具和参考
资料
01-工具项目开发过程
中可能用到的
工具软件
02-参考资料对项目开发有
用的参考资料
项目的源代码和文档是项目的最终产品，所以其重要性是可想而知的。另外项目开发过程中需要使用到的各种资料对项目的开发也很重要，管理好这些资料能够大大的方便项目的开发工作。上面我们已经识别出了本项目中的所有的配置项，然后就根据这个结构来建立目录，并把相应的一些文档资料放入对应的目录中，作为项目的初始化。根目录名为CRM24_Java，其余全都作为它的子目录。
此过程的工作主要由配置经理和配置管理员来担当，采用二级评审的方式，最终的工作输出主要包括：配置项基线计划、软件版本发布计划、配置项标识规定。其中确定配置项标识规定的工作流程可以是首先由CM来发起，然后经PM确认，最后提交给CCB和GRB审核；而对于标识配置项，任何人都可以来执行，只是最后要交由CM来审查。
6.2基于配置项版本控制
版本控制是将规程和工具相结合来管理在软件工程过程中所创建的配置对象的不同版本，通过“属性元组”等其它技术来控制完整版本中的“变体”，采用不同的工具不同的技术，版本控制的机制会有一些不同。
这部分的工作也是由配置经理和配置管理员来担当，采用二级评审的方式，这一过程的工作还可以进一步细分为：裁减标准配置管理库结构、配置项纳入配置管理、基线化配置项，最终的工作输出是配置管理库的目录结构。其中的裁减标准配置管理库结构的工作流程可以是首先在PM或测试经理的参与下由CM来发起，然后交给CCB和GRB来确认，最后告知开发人员和测试人员；而对
于配置项纳入配置管理和基线化配置项，都是首先由PM来发起，然后交给PM 来执行，最后仍然是交给CCB和GRB来确认。
6.3变更控制
变更在软件开发过程中是不可避免的，但过于频繁的变更也会对项目的开发产生负面的影响，如影响项目的进度、浪费人力物力，因此需要对变更进行控制。
变更控制可以依照如下的步骤来进行：
（1）提交变更请求，这一操作任何人都可以来执行；
（2）审核变更请求，这是由CCB和GRB来执行的；
（3）分配和确定任务，这一操作是PM在CCB和GRB的授权下来执行；
（4）提取变更项，这一操作CM在CCB和GRB的授权下来执行；
（5）执行变更，此操作任何人都可以作为变更责任人去执行；
（6）审核变更，这自然是由CCB和GRB来执行，但任何人都可能参与本项工作；
（7）更新配置管理库，这是由CM来完成的。
整个变更控制的产物主要是变更请求单、变更报告单、工程变更单或变更确认单等。变更请求单如表4-6所示。[3]
6.4配置审计
配置审计一般包括两种，一种是正式的技术评审，另一种是软件配置审计。
在正式的技术评审中，将关注已经被修改的配置项的正确性，配置项的评估配置项，以确定它与其他一致性、遗漏及潜在的副作用。正式评审应该针对于所有的变更。
而另外一种软件配置审计，是来评估正式评审中没有考虑的那些特征，可以考虑如下方面：
（1）工程变更单（ECO）中的相关内容是否已经完成；
（2）是否已经进行了正式的技术评审；
（3）变更过程中是否遵循了软件工程标准；
（4）在对配置项修改的同时，是否有相关的详细注释（comments）；
（5）在配置管理工具中是否标注了变更后的配置项状态；
（6）所有与该配置项相关的配置项是否进行了相应的更新。
这一过程的工作主要由CM来完成，也可以在PM的协助下完成。
表4-6变更请求单
项目名变更请求标识
变更请求：变更请求人日期变更理由
变更描述
影响范围
变更优先性考虑
评估变更工作量
分析与评估分析人日期分析与评估意见
审批CCB负责人日期CCB审查意见
变更实施实施负责人日期变更实施情况
质量保证审查QA负责人日期审查意见
配置管理审查CM负责人日期审查意见
6.5发布配置状态报告
配置状态报告（Configuration State Report,CSR）是SCM的一个任务，它在中大型项目中扮演着重要的角色，内容可以包括：修改了什么、谁修改的、修改是什么时候发生的以及修改有什么影响，一般情况下，是在一个配置项被赋上新的或已经修改的标识时，或者一个变更被批准时，或者产生配置审计结果时产生配置状态报告。还可以将CSR放于一个联机数据库中，使得开发者、维护者和管理者可以通过关键词等方式去访问。
本过程是由CM来完成的。
6.6发布管理
当项目进行到一定的阶段，可能需要发布一个稳定的或相对比较稳定的版本，这个时候就需要首先制定发布实施计划，然后生成发布准备报告，最后发布完成生成发布报告。此过程主要由项目经理、CCB和配置管理员来完成，采用二级评审的方式。
7、项目相关环境
7.1软件环境（看具体的项目情况）
7.2硬件环境
根据软件环境的配置，就可以搭建硬件环境了，其中主要考虑的关键资源是：内存、磁盘I/O、网络带宽和CPU，据此，可以设置每台计算机的最小内存为512M，尽量使每个磁盘有一个专门的控制器和通道，使所有项目组成员处于同一个子网内，采用的CPU可以为P41.8G以上。
7.3配置管理环境
为了方便开发管理，每个人的计算机都安装了Windows2000server，并且建立一个名为ss的域，每台计算机都登陆到ss域中。同时为了方便管理代码
的安全性，设立一个clearcase_mng组，将项目经理、技术经理、质量保证经理、配置经理和配置管理员添加到clearcase_mng组内，这个组可以拥有较大的权限，本项目中加入到clearcase_mng组的成员有：A、B、C、D、E、F、F1。为clearcase_mng组的成员安装ClearCase服务器端的程序，为其他成员安装客户端的程序。
对于ClearCase，整个团队需要一台专门的服务器clearcase_server作为VOB服务器，因为该项目的规模并不是非常庞大，所以该服务器可以兼作许可证服务器（License Server）和注册服务器（Registry Server）。为了保证ClearCase的效率，我们确保clearcase_server这台服务器是专用的，即只作ClearCase的用途，不安装其它的应用软件。
此外，为了使用UCM技术，还需要安装Rational ClearQuest软件。8、记录的维护和保存
在项目的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。
下面对记录的维护和保存作如下规定：
（1）各类基线要保存到硬盘或光盘上，而且要一式两份保存在不同地点，
这些记录应该每6个月拷贝一次，以免意外损伤与自然老化。
（2）软件的文档也应保存到硬盘或光盘，而且要一式两份保存在不同地
点，并应有一份打印的硬拷贝。每隔6个月拷贝一次，以免意外损
伤与自然老化。
（3）软件产品的源程序、测试数据、测试报告及其他有关文档，除了按
上述规定妥善存放外，要在项目结束后再保存2年，或在条件成熟
时转交给这些软件产品的生产系统。
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
软件配置管理过程指导说明书(超级实用)
软件配置管理过程指导说明书
目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)
1 前言 1.1 目的 用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。 软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。 软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。 软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。 变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。
软件配置管理规定
软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程，制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则，不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1)。 ２、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用，综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2）。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得，编制《软件采购计划表》（附件3）。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年
限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得，需经过信息化部门鉴定,严格履行资产处置报批手续：?(１）已经达到规定得最低使用年限,且无法继续使用得.?（２）未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?（3）未达到规定得最低使用年限,因计算机硬件报废，且无法迁移到其她计算机上继续使用得. ８、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4)。
配置管理工具简介
配置管理工具简介 要说配置管理工具，就要说到配置管理，因为配置管理工具是软件配置管理过程中所使用的一些工具，要了解配置管理工具，首先就必须了解配置管理。 一、配置管理工具的定义：软件配置管理的定义有很多，现在我只说一个我 觉得定义的必要好的定义。它是：“协调软件开发使得混乱减到最小的技术叫做软件配置管理，它是一种标识、组织和控制修改的技术，目的是使错误达到最小并有效地提高生产效率。”它贯穿整个软件生命周期并应用于整个软件工程过程，是软件工程中用来管理软件开发的规范，也是CMM（软件能力成熟度模型）二级中关键过程域。软件配置管理是软件质量改进的核心环节，它贯穿于整个软件生命周期，为软件改进提供了一套解决办法与活动原则。 二、软件配置管理的目标： 软件配置管理的目标是标识变更、控制变更、确保变更、和报告变更，它主要完成以下几种任务：标识、版本管理、变更控制、配置审计和配置报告。 三、配置管理工具的主要功能： 配置管理工具作为配置管理过程中使用的工具就理所当然的具有以下功能： 1).并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同 一个软件模块上工作，同时对一个代码部分做不同的修改，即使是跨地域 分布的开发团队也能互不干扰，协同工作，而又不失去控制。 2).修订版管理：跟踪一个变更的创造者、时间和原因，从而加快问题和缺 陷的确定。 3).版本控制：能够简单、明确地重现软件系统的任何一个历史版本。 4).产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制 好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了解 项目的状态。 5).建立管理：基于软件存储库的版本控制功能，实现建立过程自动化。 6).过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等。 7).变更请求管理：跟踪、管理开发过程中出现的缺陷、功能增强请求或任 务，加强沟通和协作，能够随时了解变更的状态。 8).代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发 资源。 四、常见配置管理工具简介： 配置管理工具有很多，一下我对一些常见的配置管理工具做一简单的介绍。 1.元老：CCC、SCCS、RCS 上个世纪七十年代初期加利福利亚大学的Leon Presser教授撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为Soft Tool的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。 在软件配置管理工具发展史上，继CCC之后，最具有里程碑式的是两个自由软件：Marc Rochkind 的SCCS (Source Code Control System) 和Walter Tichy 的RCS (Revision Control System)，它们对配置管理工具的发展做出了重大的贡献，直到现在绝大多数配置管理工具基本上都源于它们的设计思想和体系架构。 2.中坚：Rational Clear Case
软件配置管理报告
份号：001密级: XXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX 公司 XXXX 年XX月XX日
辑要页
摘要: 主题词:
文档修改记录
1范围............................................................................................... 1.1标识.......................................................................................... 1.2系统概述...................................................................................... 1.3文档概述......................................................................... 1........... 2引用文挡........................................................................................... 3软件配置管理情况综述............................................................................. 4软件配置管理基本信息............................................................................. 5专业组划分及权限分酉己.......................................................................... 6配置项记录......................................................................................... 7变更记录........................................................................................... 8基线记录........................................................................................... 9入库记录...........................................................................................
软件配置管理流程
配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________
目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)
1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图
1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员
16软件配置管理报告
份号：001 密级： XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日
辑要页
文档修改记录
目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)
1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容，并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展，与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息，包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配，如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等，权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项，包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。
软件项目配置管理系统计划清单指导应用清单
中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)
配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责
(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
SCMS软件配置管理过程
C M M文件软件配置管理过程 XXXXXXXXXXXX (版权所有,翻版必究)
文档变更请求(DCR)
文档变更记录
目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A ：软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B ：配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C ：软件配置管理测量报告 (11)
1概述 1.1目的 软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围 本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、 计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一 个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人 工可读）和各种版本的文档、程序及其数据。 1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任 人”）。 1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对 软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for Software （Version 1.1） 1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90
软件配置管理规范.doc
软件配置管理规范1 1．简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退
出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能 通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1
配置管理系统
配置管理系统（北大软件 010 - 61137666） 配置管理系统，采用基于构件等先进思想和技术，支持软件全生命周期的资源管理需求，确保软件工作产品的完整性、可追溯性。 配置管理系统支持对软件的配置标识、变更控制、状态纪实、配置审核、产品发布管理等功能，实现核心知识产权的积累和开发成果的复用。 1.1.1 组成结构（北大软件 010 - 61137666） 配置管理系统支持建立和维护三库：开发库、受控库、产品库。 根据企业安全管理策略设定分级控制方式，支持建立多级库，并建立相关控制关系；每级可设置若干个库；配置库可集中部署或分布式部署，即多库可以部署在一台服务器上，也可以部署在单独的多个服务器上。 1. 典型的三库管理，支持独立设置产品库、受控库、开发库，如下图所示。 图表1三库结构 2. 典型的四库管理，支持独立设置部门开发库、部门受控库、所级受控库、所级产品库等，如下图所示。
图表2四级库结构配置管理各库功能描述如下：
以“三库”结构为例，系统覆盖配置管理计划、配置标识、基线建立、入库、产品交付、配置变更、配置审核等环节，其演进及控制关系如下图。 图表3 配置管理工作流程 1.1.2主要特点（北大软件010 - 61137666） 3.独立灵活的多级库配置 支持国军标要求的独立设置产品库、受控库、开发库的要求，满足对配置资源的分级控制要求，支持软件开发库、受控库和产品库三库的独立管理，实现对受控库和产品库的入库、出库、变更控制和版本管理。
系统具有三库无限级联合与分布部署特性，可根据企业管理策略建立多控制级别的配置库，设定每级配置库的数量和上下级库间的控制关系，并支持开发库、受控库和产品库的统一管理。 4.产品生存全过程管理 支持软件配置管理全研发过程的活动和产品控制，即支持“用户严格按照配置管理计划实施配置管理—基于配置库的实际状况客观报告配置状态”的全过程的活动。 5.灵活的流程定制 可根据用户实际情况定制流程及表单。 6.支持线上线下审批方式 支持配置控制表单的网上在线审批（网上流转审批）和网下脱机审批两种工作模式，两种模式可以在同一项目中由配置管理人员根据实际情况灵活选用。 7.文档管理功能 实现软件文档的全生命周期管理，包括创建、审签、归档、发布、打印、作废等，能够按照项目策划的软件文档清单和归档计划实施自动检查，并产生定期报表。 8.丰富的统计查询功能，支持过程的测量和监控 支持相关人员对配置管理状态的查询和追溯。能够为领导层的管理和决策提供准确一致的决策支持信息，包括配置项和基线提交偏差情况、基线状态、一致性关系、产品出入库状况、变更状况、问题追踪、配置记实、配置审核的等重要信息； 9.配置库资源的安全控制 1)系统采用三员管理机制，分权管理系统的用户管理、权限分配、系统操 作日志管理。 2)系统基于角色的授权机制，支持权限最小化的策略； 3)系统可采用多种数据备份机制，提高系统的数据的抗毁性。 10.支持并行开发 系统采用文件共享锁机制实现多人对相同配置资源的并行开发控制。在系统共享文件修改控制机制的基础上，采用三种配置资源锁以实现对并行开发的
软件配置管理流程
软件配置管理流程
目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)
1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图
软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项
软件配置管理计划示例
软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理
2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
软件配置管理规定
软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则，不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关的各类软件。 3.优先采用场地授权（许可）方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1）。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》，对软件使用部门需要的相关软件进行统一测试和试用，综合考虑软件的价格、兼容性、安全性和售后服务等因素，确定软件选型，明确软件名称和版本。涉及使用免费软件的，更新《可使用免费软件清单》（附件2）。 3.信息化部门依据单位软件使用管理台账，梳理单位软件需求与现有软件许可的差异。单位软件许可不足的，编制《软件采购计划表》（附件3）。
4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件，因以下情况申请报废的，需经过信息化部门鉴定，严格履行资产处置报批手续：（1）已经达到规定的最低使用年限，且无法继续使用的。 （2）未达到规定的最低使用年限，因技术进步等原因无法继续使用的。 （3）未达到规定的最低使用年限，因计算机硬件报废，且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4）。
校务通管理系统软件项目配置管理计划案例
软件项目配置管理计划案例 本案例选自《软件项目管理案例教程》（韩万江，机械工业出版社）一书，项目案例为《校务通管理系统》，该项目的配置管理计划如下： 1. 引言 包括目的、缩写词和参考资料，具体内容略。 2．组织及职责 配置管理的角色和职责见表1。 表1：配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。 3.1配置库目录结构
3.2用户及权限 4．配置管理活动 4.1 配置项标志 4.1.1 命名规范 本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。
图1：配置项命名规范 4.1.2 主要配置项 QTD-School –RM –SRS-v1.0 公司：3个字符 项目：最长10个字符 类型：最长5个字符 编号：最长8位数字/字符 版本号：V m.n
4.1.3 项目基线 在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。 表5 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。 这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 对配置项的版本管理在不同分支具有不同的策略： （1）主干分支 系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。 （2）私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。 （3）小组分支 如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。
软件配置管理规范流程
1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理（Software Configuration Management，SCM） 软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项（Configuration Item，CI） 凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线（Baseline） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一
软件配置管理规范标准
页眉 软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline)
己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 页脚 页眉 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范 项目计划与控制规范 1.5.4 指南 配置管理计划指南 基线策略指南 配置状态报告编制指南 配置审计工作活动指南 配置管理工具指南 VSS 使用指南 组织管理配置库使用指南 软件开发文档命名约定 1.5.5模板 配置管理计划 配置状态报告 配置审计报告 文档变更请求 1.5.6 检查表 无 1.5.7 培训 《软件配置管理教材》 《软件变更控制管理教材》 《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop