《配置管理手册》.docx

《配置管理手册》.docx

《《配置管理手册》.docx》由会员分享，可在线阅读，更多相关《《配置管理手册》.docx（7页珍藏版）》请在冰豆网上搜索。

《配置管理手册》

配置管理手册

Version1.0

北京紫光捷通公司

工程软件部

1引言

1.1编写目的

在软件产品的生命周期中，要经历需求分析，设计，编码，测试，提交，维护等一系列过程。

在这个过程中，软件产品要经历无数次的变更，如果不能很好地标识变更，控制变更，确保变更的实现，项目就会陷入混乱，因此，制订本配置管理计划的目的，就是从多个方面描述如何进行配置管理，并通过配置管理保证项目不会陷入混乱。

1.2阅读指导

本手册主要分为五部分：

引言、基本约定、配置环境、基本流程、记录的收集、维护和保存。

第二部分基本约定主要介绍了配置管理中一些基本的约定，包括定义、适用标准、接口控制和参考资料。

第三部分配置环境分别对公网和部门的软件库配置信息进行了描述。

第四部分基本流程是本手册的重点，分为总体流程和岗位流程，建议根据具体的岗位有侧重点的进行阅读。

第五部分记录的收集、维护和保存对项目产生的代码、文档等的维护、保存进行了说明。

2基本约定

2.1定义

本计划中用到的一些术语的定义按GB/T11457和GB/T12504。

配置项（CONFIGURATIONITEM）：

就是指在开发过程中所有的需要记录历史行为的半成品和成品。

在开发过程中，无论文档（开发计划，需求分析，概要设计，详细设计，测试计划，测试用例，测试报告。

。

。

。

），源代码（C/PASCAL源程序，数据库建立脚本，基本代码数据。

。

。

），测试代码，发行版本（可脱离源代码直接运行的程序），支持平台（操作系统，数据库系统），驱动外设，都存在着变化的可能和必然性，这些都被认为是配置项。

配置管理的第一步就应当标识出项目中应当管理的配置项。

基线（BASELINE）：

我们以前称为里程碑（MILESTONE）。

基线的含义是软件开发的一个预定义的程度或阶段。

定义基线的好处是保证开发能够渐进，可靠的推进。

通过基线的划分能够将开发的过程透明化，有利于控制开发的风险（小阶段的进度与资源都比较好控制）。

由于基线代表软件开发达到一定的程度，因此通过基线必须通过检查列表（CHECKLIST）。

在ISO9001中就是要做阶段评审（立项评审，软件定义评审，需求分析评审，概要设计评审，详细设计评审，编码测试评审，组装测试评审，安装验收评审，运行维护评审）。

在ISO9001中主要明确3种基线（功能基线，指派基线，产品基线），我们可以根据项目的特性在每个阶段插入更多的子基线（如在开发阶段中插入3个子基线）。

软件库（SOFTBANK）：

指集中保存上述配置项的数据库。

应当指出该软件库保存所有配置项的所有历史修改记录，因此通常有相应的配置管理客户端辅助工作。

ISO9001规定软件开发必须存在3个不同的软件库，分别用于不同的阶段和目的：

研发库，受控库和产品库。

开发库（DEVELOPINGSOFTBANK）：

保存处于开发阶段的所有配置项的历史信息。

这个库放在公网上，名称是COMMON。

这里用于临时存放所有正在开发的代码和文档等。

开发人员可对其进行检入、检出操作。

一个阶段的开发工作完毕后，此开发库将被清空。

受控库（UNDERCONTROLLEDSOFTBANK）：

受控库由配置管理员统一管理，主要用于软件版本的维护、升级及改进。

一个阶段的开发工作完成后，配置项即转入受控库，开发人员不可自行修改已入库的配置项。

出库登记（CHECKOUT）：

在配置管理中，为了保证在软件库中的成品/半成品不会因为多人同时开发而变的不一致，同时为了跟踪变化本身，每个开发人员在对软件库中的产品做出改动之前，必须进行CHECKOUT操作。

通过这个操作，开发人员就获得了一个中心产品在本地的私有拷贝，随后的所有编辑都是针对本地的私有拷贝进行的。

入库登记（CHECKIN）：

如果开发人员完成了编辑和调试工作，希望将成果加入或刷新中心库，则需要进行入库登记。

通过入库登记，配置管理工具就能够记录产品变化的历史，并以一种高效的方式保存所有的历史记录。

个人工作区（WORKINGFOLDER）：

从中心软件库中通过CHECKOUT操作，开发人员希望的产品代码或文档等，就进入开发人员的个人工作区。

版本控制（VERSIONCONTROL）：

在配置管理中，版本的概念不同与一般（如3.2.0023）。

只要进行了一次CHECKIN，就产生了该配置项的一个新的版本。

在配置管理工具中，通常以整型值作为版本号。

在中心库中，能够保存所有配置项的所有版本，当然首先开发人员必须遵守CHECKIN/OUT的规范。

我们通常所说的版本，可以使用给某个配置项版本加标签的方法标识。

标签（LABEL）：

在配置管理工具中，使用标签来标明配置项或项目的一个有意义的名称，如版本3.1.2，这个标签并不一定代表其中文件的真实版本号。

2.2适用的标准、条例和约定

在配置管理过程中应该遵守如下标准、条例和约定：

A．软件开发库、软件受控库与软件产品库的操作规程与管理规程；

B．系统、子系统、模块和程序单元的命名约定；

C．文档和测试用例的命名和管理规程。

这引起命名约定、操作规程与管理规程应由项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目核心组审批。

在执行过程中，如果发现某些条款需要修改，必须经项目核心组批准，同时进行修改记录。

2.2.1文档命名规范

文档命名采用如右方式：

A-B-C-XX。

A部分表示公司名称（紫光捷通即用JT表示）；

B部分表示部门名称（工程软件部用SYF表示）；

C部分用项目汉语拼音打头字母表示（如：

菏关项目用HG表示）；

XX部分为文档编号，可参考具体项目的《软件质量保证计划》，里面详细列出编号与文档的对应关系。

（如：

JT-SYF-HG-01可以用来表示菏关项目的需求分析文件）

2.2.2测试用例命名规范

测试用例命名采用如下方式：

A-B-CS-D-XX。

A部分表示公司名称（紫光捷通即用JT表示）；

B部分表示部门名称（工程软件部用SYF表示）；

CS代码表示测试用例；

D部分用项目汉语拼音打头字母表示（如：

菏关项目用HG表示）；

XX部分为测试用例编号，测试主管负责对测试用例进行编号，并整理出测试用例编号与名称对应表。

（如：

JT-SYF-CS-HG-01可以用来表示菏关项目的第一个测试用例）

2.2.3整理9001文件夹

在整理9001文档夹时,可以不必打印出来，只打印封皮，在封皮上标明对应文档的最新版本号和在软件库中的编号就可以。

如：

\\COMMON\山东菏关\公共\需求分析\软件需求规格书.DOC

2.3接口控制

对各类接口进行严格、合理的控制，是软件配置管理中最重要的任务之一。

整个软件项目及其各子系统都必须进行严格的控制。

在工程化软件系统中，主要的接口有如下五类：

A．用户界面：

用户界面是指各子系统与设计人员、用户或维护人员之间的操作约定。

同时还指实现这些操作约定的物理部件的功能与性能特性。

B．系统内部接口：

系统内部接口是指各子系统在集成为一个总的软件系统时的各种连接约定。

C．标准程序接口：

标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机系统已有的库程序）之间的调用约定。

D．设备接口：

设备接口是指各子系统与各种设备（包括终端和其他各种输入/输出设备）之间的连接约定。

E．软件接口：

软件接口是指各个子系统与宿主计算机上的系统软件以及与调用本软件的其它软件系统之间的连接约定。

以上五类接口是一个软件系统各项配置的重要组成部分。

对接口修改进行合理的控制，是软件配置管理的重要任务之一。

这五类接口都涉及到监控软件系统的全局，因此，当要求对这五类接口中的任一类接口进行修改时，必须经项目核心组批准，同时进行修改记录。

2.4参考资料

GB/T11457软件工程术语

GB8566计算机软件开发规范

GB8567计算机软件产品开发文件编制指南

GB/T12504计算机软件质量保证计划规范

GB/T12505计算机软件配置管理计划规范

CADCSC软件质量保证计划

3配置环境

3.1公网Common开发库

服务器，端口号60012。

用户名/密码：

均为本人姓名汉语拼音全称，建议登陆后及时修改密码。

权限：

部门成员拥有本人工作目录的读写及修改权限，对公共文件夹可读，其他人的目录不可访问。

注：

初次使用需导入个人密钥，[Tools]->[ImportEncryptionKey]导入姓名.iky。

3.2部门Deployment受控库

IP192.168.1.9，端口号8888。

用户名/密码：

均为本人姓名汉语拼音全称，建议登陆后及时修改密码。

权限：

产品经理及配置管理员拥有读写权限。

其他人员对该数据库只读。

4基本流程

4.1总体流程

配置管理工作贯穿于各项目组成员，为方便各项目组成员团队合作以及配合，对本地系统文件夹以及软件库进行统一约定。

在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。

在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要更新前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。

因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。

软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目核心组组长批准，并同步进行修改记录。

4.1.1开发库流程

公网开发库（COMMON）数据库的为临时文件夹，下设两个目录：

分别是[WORK]以及[公共文件夹]。

[公共文件夹]只用于临时存放项目文档（任何人提出对项目文档的需求后，配置管理员会将把该文档放至此文件夹，供大家下载取用）；WORK目录下设以开发工程师姓名命名的文件夹，开发工程师将代码和文档放在里面，专职配置管理员会对大家的代码提交情况进行记录及考核。

（详见开发工程师工作流程）

4.1.2受控库流程

部门内部受控库（Deployment）主要由配置管理员进行管理。

产品经理及配置管理员可以访问。

开发工作完毕后，配置管理员把开发库内容移至受控库，并下载数据到测试计算机交由测试人员进行测试。

由测试主管提交测试结果给开发工程师并对开发过程进行跟踪。

测试完成后，将代码存入受控库进行版本管理。

4.2岗位工作流程

4.2.1产品经理工作流程

产品经理的工作流程见下图：

4.2.2开发工程师

4.2.2.1开发工程师工作流程

开发工程师出库入库工作流程如下图，分别在公网（Common）和本地建立工作文件夹，建立本项目目录树，建立须严格按照个人文件夹管理规范执行。

每个项目开始之前，应对本人工作进行计划，主要包括本人工作推进时间安排，将本项目计划一并放入该项目文件夹中。

开发过程中，需每天进行代码提交工作（相邻两次提交时间最长不得超过3天），专职配置管理员将不定期提醒开发工程师及时提交工作成果，并对提交情况进行记录、统计，此统计结果将作为年终考核重点之一。

开发工程师可随时向配置管理员索要本人本年度代码、文档提交情况记录。

4.2.2.2开发工程师文件夹管理

公网（COMMON）库中，个人文件夹内目录须按照下图建立：

4.2.3系统工程师工作流程

系统工程师主要负责软件测试、安装调试及后期维护工作。

基本工作流程见下图：

5记录的收集、维护和保存

在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。

准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。

在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。

A．基础上组装系统、各个子系统、专用支持软件及选用软件的功能基线、指派基线与产品基线要送入硬盘或磁带，至少必须一式两份且存放在两个不同的地点。

这些记录应该每6个月拷贝一次，以免意外损伤与自然老化。

B．上述这些软件的文档也应送入硬盘或磁盘，至少必须工式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。

磁媒体应该每隔6个月拷贝一次，以免意外损伤与自然老化。

C．软件产品的源程序、测试数据、测试报告及其他有关文档，除了按A、B规定妥善存放外，要在项目结束后再保存1年，或在条件成熟时转交给这些软件产品的生产系统。

注：

具体保存年限要根据项目的性质与开发单位的任务来确定，此处仅作为一个示例。

D．上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。

太多毒鸡汤告诉你，你想要的岁月都会给你，可它没告诉你，你想要的，岁月凭什么给你！