《配置管理手册》

《配置管理手册》
《配置管理手册》

配置管理手册

Version 1.0

北京紫光捷通公司

工程软件部

目录

1引言2

1.1编写目的2

1.2 阅读指导3

2基本约定3

2.1定义3

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

2.2.1文档命名规范5

2.2.2测试用例命名规范5

2.2.3整理9001文件夹6

2.3接口控制6

2.4参考资料7

3配置环境7

3.1公网Common开发库7

3.2部门Deployment受控库7

4基本流程7

4.1总体流程7

4.1.1开发库流程8

4.1.2受控库流程8

4.2岗位工作流程9

4.2.1产品经理工作流程9

4.2.2开发工程师9

4.2.2.1开发工程师工作流程9

4.2.2.2开发工程师文件夹管理9

4.2.3系统工程师工作流程9

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

1引言

1.1编写目的

在软件产品的生命周期中,要经历需求分析,设计,编码,测试,提交,维护等一系列过程。在这个过程中,软件产品要经历无数次的变更,如果不能很好地标识变更,控制变更,确保变更的实现,项目就会陷入混乱,因此,制订本配置管理计划的目的,就是从多个方面描述如何进行配置管理,并通过配置管理保证项目不会陷入混乱。

1.2 阅读指导

本手册主要分为五部分:引言、基本约定、配置环境、基本流程、记录的收集、维护和保存。

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

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

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

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

2基本约定

2.1定义

本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。

配置项(CONFIGURATION ITEM):就是指在开发过程中所有的需要记录历史行为的半成品和成品。在开发过程中,无论文档(开发计划,需求分析,概要设计,详细设计,测试计划,测试用例,测试报告。。。。),源代码(C/PASCAL 源程序,数据库建立脚本,基本代码数据。。。),测试代码,发行版本(可脱离源代码直接运行的程序),支持平台(操作系统,数据库系统),驱动外设,都存在着变化的可能和必然性,这些都被认为是配置项。配置管理的第一步就应当标识出项目中应当管理的配置项。

基线(BASELINE):我们以前称为里程碑(MILESTONE)。基线的含义是软件开发的一个预定义的程度或阶段。定义基线的好处是保证开发能够渐进,可靠的推进。通过基线的划分能够将开发的过程透明化,有利于控制开发的风险(小阶段的进度与资源都比较好控制)。由于基线代表软件开发达到一定的程度,因此通过基线必须通过检查列表(CHECKLIST)。在ISO9001中就是要做阶段评审(立项评审,软件定义评审,需求分析评审,概要设计评审,详细设

计评审,编码测试评审,组装测试评审,安装验收评审,运行维护评审)。在ISO9001中主要明确3种基线(功能基线,指派基线,产品基线),我们可以根据项目的特性在每个阶段插入更多的子基线(如在开发阶段中插入3个子基线)。

软件库(SOFTBANK):指集中保存上述配置项的数据库。应当指出该软件库保存所有配置项的所有历史修改记录,因此通常有相应的配置管理客户端辅助工作。ISO9001规定软件开发必须存在3个不同的软件库,分别用于不同的阶段和目的:研发库,受控库和产品库。

开发库(DEVELOPING SOFTBANK):保存处于开发阶段的所有配置项的历史信息。这个库放在公网上,名称是COMMON。这里用于临时存放所有正在开发的代码和文档等。开发人员可对其进行检入、检出操作。一个阶段的开发工作完毕后,此开发库将被清空。

受控库(UNDERCONTROLLED SOFTBANK):受控库由配置管理员统一管理,主要用于软件版本的维护、升级及改进。一个阶段的开发工作完成后,配置项即转入受控库,开发人员不可自行修改已入库的配置项。

出库登记(CHECK OUT):在配置管理中,为了保证在软件库中的成品/半成品不会因为多人同时开发而变的不一致,同时为了跟踪变化本身,每个开发人员在对软件库中的产品做出改动之前,必须进行CHECK OUT操作。通过这个操作,开发人员就获得了一个中心产品在本地的私有拷贝,随后的所有编辑都是针对本地的私有拷贝进行的。

入库登记(CHECK IN):如果开发人员完成了编辑和调试工作,希望将成果加入或刷新中心库,则需要进行入库登记。通过入库登记,配置管理工具就能够记录产品变化的历史,并以一种高效的方式保存所有的历史记录。

个人工作区(WORKING FOLDER):从中心软件库中通过CHECK OUT操作,开发人员希望的产品代码或文档等,就进入开发人员的个人工作区。

版本控制(VERSION CONTROL):在配置管理中,版本的概念不同与一般(如3.2.0023)。只要进行了一次CHECK IN,就产生了该配置项的一个新的版本。在配置管理工具中,通常以整型值作为版本号。在中心库中,能够保存所有配置项的所有版本,当然首先开发人员必须遵守CHECK IN/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/T 11457 软件工程术语

GB 8566 计算机软件开发规范

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

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

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

CADCSC 软件质量保证计划

3配置环境

3.1公网Common开发库

服务器https://www.360docs.net/doc/aa16632226.html,,端口号60012。

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

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

注:初次使用需导入个人密钥,[Tools]->[Import Encryption Key]导入姓名.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.上述这些软件的各项配置的个性状态、评审记录与修改历史,要作为这些软件的历史记录来保存,目前可用打印硬拷贝一式两份存放,有条件时再转移到在线光学存储媒体中。

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

配置管理规程

配置管理(Configuration Management, CM)的目的是通过执行版本控制、变更控制等规程,以及使用配置管理软件,来保证所有配置项的完整性和可跟踪性。 配置管理过程域的四个主要规程: 制定配置管理计划-配置库管理-配置版本控制-配置变更控制 定义 1.工作成果(Work Product) 项目研发和管理过程中会产生许许多多的工作成果,例如文档、程序和数据等。 2.配置项(Configuration Item, CI) 所有纳入配置管理范畴的工作成果统称为配置项,配置项主要有两大类: (1)属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例等。 (2)项目管理中产生的文档。如计划、报告等。这些文档虽然不是产品的组成部分,但是值得保存。 每个配置项的主要属性有:标识符、名称、文件状态、版本、作者、日期等。所有配置项都须保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 3.基线(Baseline) 基线由一组配置项组成,并且这些配置项已被“冻结”,任何人不能再随意修改(见变更控制规程)。基线通常在里程碑处建立,所以一个产品可以有一个或多个基线。基线的主要属性有:标识符、名称、版本、日期等。通常将交付给客户的基线称为一个“Release”,为内部开发所用的基线则称为一个“Build”。 4.项目配置管理员(Project Configuration Manager) 为了提高配置管理的效率和安全性,项目需要有专人为项目制定《配置管理计划》,创建和维护配置库,在本文档中,该负责人称为项目配置管理员。在公司,项目支持负责人担任项目配置管理员的角色。 5.项目变更控制委员会(Change Control Board, CCB) 项目CCB对项目内配置管理的各项活动拥有决策权(例如审批配置管理计划,审批变更请求等)。对于配置管理而言,项目CCB是决策者,而项目配置管理员是执行者。项目CCB的人数视项目的规模而定。通常项目CCB由项目经理、资深项目成员等人组成,项目经理为项目CCB负责人。CCB的决策采用“少数服从多数”原则。 1.1 配置管理流程介绍 配置管理的流程下图所示:

Solution Manager管理配置手册

模 块:Solution Manager 范 围:BASIS 实施地点:三全 日期:2011/12/27 16:09:00 作者:贾培星 状态: 三全Solution Manager系统 配置手册 V1.0 2011-10-12

模 块:Solution Manager 范 围:BASIS 实施地点:三全 日期:2011/12/27 16:09:00 作者:贾培星 状态: 目录 一、初始配置 (3) 1.1登录配置页面 (3) 1.2 System Preparation (3) 1.3 Basic Configuration (27) 二、ERP 升级STACK文件生成 (50) 2.1注册卫星系统SLD (50) 2.2 Maintenance Optimizer配置 (52) 2.3生成ECC升级XML文件 (52)

模 块:Solution Manager 范 围:BASIS 实施地点:三全 日期:2011/12/27 16:09:00 作者:贾培星 状态: 一、 初始配置 1.1 登录配置页面 登录Solution Manager 开发系统,运行T-CODE :solman_setup ,然后会跳转到IE 页面(如下图),接着就可以开始初始与基本配置。 1.2System Preparation:

模 块:Solution Manager 范 围:BASIS 实施地点:三全 日期:2011/12/27 16:09:00 作者:贾培星 状态: Next

模 块:Solution Manager 范 围:BASIS 实施地点:三全 日期:2011/12/27 16:09:00 作者:贾培星 状态: Next

软件配置管理规范.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

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报…… 每一个软件项目,无论是工程类项目,还是产品类项目,都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中,将生成各种各样不同的工件,包括文档、源程序、可执行代码、支持库。更可怕的是,频繁出现的变更是不可避免的,因此面向如此庞大且不断变动的信息集,如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题,最早的开发人员尝试过的解决办法是通过手工来实现: 1)文档:每次修改时都另存为一个新的文件,然后通过文件名进行区分,例如"XXX 软件需求说明书V1.0,XXX软件需求说明书V1.1,XXX 软件需求说明书V2.0.",并且在文件中注明每次版本变化的内容; 2) 源代码:每次要修改时就将整个工程目录复制一份,将原来的文件夹进行改名,例如"XX 项目V1.0、XX 项目1.01、.",然后在新的目录中进行修改; 但是这种方法,不仅十分繁琐,容易出错,而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时,还是会造成很大的混乱。很显然,这样简陋的方法是无法应对这一问题的。后来,有人尝试从制造工业领域引入了"配置管理"这一概念,通过不懈的研究与实践,最终形成了一套管理办法和活动原则,这也就是软件配置管理。 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报。 常见的配置管理工具 正如前面所述,由于软件配置管理过程十分繁杂,管理对象错综复杂,如果是采用人工的办法不仅费时费力,还容易出错,产生大量的废品。因此,引入一些自动化工具是十分有裨益的,这也是做好配置管理的必要条件。 正是因为如此,市场上出现了大量的自动化配置管理工具,这些工具的实现原理与基本机制

操作系统安全配置管理办法

编号:SM-ZD-96562 操作系统安全配置管理办 法 Through the process agreement to achieve a unified action policy for different people, so as to coordinate action, reduce blindness, and make the work orderly. 编制:____________________ 审核:____________________ 批准:____________________ 本文档下载后可任意修改

操作系统安全配置管理办法 简介:该制度资料适用于公司或组织通过程序化、标准化的流程约定,达成上下级或不同的人员之间形成统一的行动方针,从而协调行动,增强主动性,减少盲目性,使工作有条不紊地进行。文档可直接下载或修改,使用时请详细阅读内容。 1范围 1.1为了指导、规范海南电网公司信息通信分公司信息系统的操作系统安全配置方法和日常系统操作管理,提高重要信息系统的安全运行维护水平,规范化操作,确保信息系统安全稳定可靠运行,特制定本管理办法。 1.2本办法适用公司信息大区所有信息系统操作系统安全配置管理。主要操作系统包括:AIX系统、Windows系统、Linux系统及HP UNIX系统等。 2规范性引用文件 下列文件对于本规范的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本规范。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本规范。 --中华人民共和国计算机信息系统安全保护条例 --中华人民共和国国家安全法

曙光作业管理-调度系统安装配置手册

Torque + Maui配置手册之抛砖引玉篇 本文将以应用于实际案例(南航理学院、复旦大学物理系、宁波气象局)中的作业调度系统为例,简单介绍一下免费开源又好用的Torque+Maui如何在曙光服务器上进行安装和配置,以及针对用户特定需求的常用调度策略的设定情况,以便可以起到抛砖引玉的作用,使更多的人关注MAUI这个功能强大的集群调度器(后期将推出SGE+MAUI版本)。本文中的涉及的软件版本Torque 版本:2.1.7 maui版本:3.2.6p17。 1. 集群资源管理器Torque 1.1.从源代码安装Torque 其中pbs_server安装在node33上,TORQUE有两个主要的可执行文件,一个是主节点上的pbs_server,一个是计算节点上的pbs_mom,机群中每一个计算节点(node1~node16)都有一个pbs_mom负责与pbs_server通信,告诉pbs_server该节点上的可用资源数以及作业的状态。机群的NFS共享存储位置为/home,所有用户目录都在该目录下。 1.1.1.解压源文件包 在共享目录下解压缩torque # tar -zxf torque-2.1.17.tar.gz 假设解压的文件夹名字为: /home/dawning/torque-2.1.7 1.1. 2.编译设置 #./configure --enable-docs --with-scp --enable-syslog 其中, 默认情况下,TORQUE将可执行文件安装在/usr/local/bin和/usr/local/sbin下。其余的配置文件将安装在/var/spool/torque下 默认情况下,TORQUE不安装管理员手册,这里指定要安装。 默认情况下,TORQUE使用rcp来copy数据文件,官方强烈推荐使用scp,所以这里设定--with-scp. 默认情况下,TORQUE不允许使用syslog,我们这里使用syslog。 1.1.3.编译安装 # make # make install Server端安装设置: 在torque的安装源文件根目录中,执行 #./torque.setup root 以root作为torque的管理员账号创建作业队列。 计算节点(Client端)的安装: 由于计算节点节点系统相同,因而可以用如下SHELL script (脚本名字为torque.install.sh)在

软件配置管理报告

份号: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入库记录...........................................................................................

配置管理计划-xxxxxx系统

. 配置管理计划******系统

修订页版本控制

目录 目录 ........................................................................................................................................... - 3 -1.引言............................................................................................................................................ - 4 - 1.1编写目的 (4) 1.2适用范围 (4) 1.3参考资料 (4) 1.4术语表 (4) 2.配置管理人员与责任 ................................................................................................................. - 5 - 3.用于配置管理的软硬件资源...................................................................................................... - 6 - 4.配置库结构与权限 ..................................................................................................................... - 6 - 4.1配置库列表 (6) 4.2配置库结构 (6) 4.3配置库操作权限 (6) 5.配置项计划 ................................................................................................................................ - 7 - 6.基线计划 .................................................................................................................................... - 7 - 7.配置库备份计划......................................................................................................................... - 7 -

配置管理指南

配置管理指南本页仅作为文档页封面,使用时可以删除 This document is for reference only-rar21year.March

配置管理指南有限公司

变更记录 修改点说明的内容有如下几种:创建、修改(+修改说明)、删除(+删除说明)

目录 1. 过程概述 ...................................................................................................................... 错误!未定义书签。 2. 过程目标 ...................................................................................................................... 错误!未定义书签。 3. 必要条件 ...................................................................................................................... 错误!未定义书签。 4. 应执行活动 .................................................................................................................. 错误!未定义书签。 5. 验证与监督 .................................................................................................................. 错误!未定义书签。 6. 裁剪指南 ...................................................................................................................... 错误!未定义书签。 7. 附件说明 ...................................................................................................................... 错误!未定义书签。 8. 相关过程 ...................................................................................................................... 错误!未定义书签。

软件项目配置管理系统计划清单指导应用清单

中国核电集团 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默认设置为与域的设置相同。 若个人要求另行设置的,由项目组配置管理员负责汇总后,提交给高级配置管理员调整设置。

(五)配置项计划 填写上面表格过程中,需要对照成果物列表逐项填写。

软件配置管理计划示例

软件配置管理计划示例 作者:赵文锋计划名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 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

软件配置管理工具+Vss+60实用指南

软件配置管理工具Vss6.0实用指南 一、版本管理的必要性 如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展,那么80~90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现,这就是软件的版本管理。 只要参加过软件开发的人都清楚,现在的软件项目完全由一个人来完成是难以想象而且也是不可能的,通常是有一个研发小组来共同分析、设计、编码和维护,并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中,需要涉及到各个方面的人员,信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间,还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改,小的可能只是对某个源文件中的某个变量的定义改动,大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中,由于软件开发所固有的特征,可能会形成众多的软件版本,而且我们并不能保证不出现错误的修改,而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前,他/她该如何有效地解决这些问题,具体地说就是如下一些问题: 1.怎样对研发项目进行整体管理; 2.项目开发小组的成员之间如何以一种有效的机制进行协调; 3.如何进行对小组成员各自承担的子项目的统一管理; 4.如何对研发小组各成员所作的修改进行统一汇总; 5.如何保留修改的轨迹,以便撤销错误的改动; 6.对在研发过程中形成的软件的各个版本如何进行标识,管理及差异识辨等等。 一个非常直接的反应,我们必须要引进一种管理机制,一个版本管理机制,而且是广义上的版本管理,它不仅需要对源代码的版本进行管理,而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法,诸如在对他人的源程序进行修改时注释修改原因,修改人和日期,如果是多个成员同时进行了修改,那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了,可以说是一种以小作坊的形式来面对软件的社会化大生产,再也不可能行得通了。 其实,版本管理的思想很早就存在于软件开发者的头脑之中,只是以往的认识没有现在人们所意识到的那样迫切。UNIX 的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具,现在的Linux更是提供功能强大的能够跨平台的版本管理器,国外公司的基于Windows的版本管理器也已经有了比较成熟的产品,国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中,这里只将对使用比较广泛,有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe6.0进行详细的介绍,针对普通的研发小组的解决方案,及具体的实现。 二、Visual SourceSafe6.0(VSS6.0)简介 VSS6.0现在是作为Microsoft Visual Studio6.0这个开发产品家族的一员,如Visual C++6.0和Visual J++6.0一样。 1.VSS的简单工作原理 Microsoft的VSS6.0解决了软件开发小组长期所面临的版本管理问题,它可能有效地帮助项目开发组的负责人对项目程序进行管理,将所有的项目源文件(包括各种文件类型)以特有的方式存入数据库。开发组的成员不能对该数据库中的

配置管理系统

配置管理系统(北大软件 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 总则 1.1概述 在项目整个生命周期中项目管理员应对研发工作产品进行标识,跟踪完成有关基线变更处理。 1.2基本原则 项目配置管理的目的是建立和维护项目在整个生命周期产品的统一性、完整性和可追溯性。应遵循的原则: 项目管理员负责项目配置管理。 项目配置管理工作贯穿项目的整个生命周期。 项目管理员应定期检查配置管理工作。 项目结项时应提交配置状态记录表。 1.3人员要求及岗位职责 1.3.1项目管理员 1.3.1.1职责 建立基线库,实施版本控制;收到或更改某个配置项时,应及时通知有关人员;记录并维护配置状态信息,配合项目管理员及领导对项目配置管理的定期检查工作。项目结项时,应对项目的配置情况进行总结,最终提交配置状态记录表并存档。 1.3.1.2岗位要求 接受相关配置管理规范、变更管理规程的培训。

1.3.2项目经理、开发部经理 1.3. 2.1职责 定期或在事件驱动下检查配置管理工作。 1.3. 2.2岗位要求 接受相关配置管理规范、变更管理规程的培训。 1.4资源保证 公司研发部门保证提供完成项目配置管理工作所需的资源、工具和人力。 2 规范流程 2.1.1配置管理规范 2.1.1.1目的 指导项目管理员进行配置管理工作。 2.1.1.2适用范围 公司研发部门所有开发项目 2.1.1.3配置管理过程 2.1.1. 3.1制定配置管理计划 项目管理员负责制定项目配置管理计划,内容包括项目中将要进行的配置管理活动、时间安排、相关资源,职责分配等。 对于配置项变更应按照“变更请求流程”来进行。 配置管理计划应经项目经理审核 配置管理计划由项目管理员负责管理和控制,由项目组遵照实施。

配置管理制度

信息系统配置管理规范

目录 1 概述 (3) 1.1.目的 (3) 1.2.范围 (3) 1.3.术语 (3) 1.4.角色与职责 (3) 2 配置管理范围 (4) 3 项目配置库建立与使用 (4) 3.1项目配置库建立 (4) 3.2项目配置库使用 (4) 4 权限变更 (5) 5 配置库安全 (5) 6 配置库使用规范 (6) 附录一:配置项命名规则 (7) 附录二:配置库目录结构管理规定 (8) 附录三:基线库产品清单 (9)

1 概述 1.1.目的 为了保证XXXX研发项目文件的安全性、机密性;保证信息系统的完整性、有效性及可追溯性,以及加强研发项目的协同能力,特制订本制度。 1.2.范围 适用于本行所有信息系统。 1.3.术语 1.4.角色与职责

2 配置管理范围 研发项目过程中产生的所有文档,包括:研发项目管理文档、研发设计及技术文档、源代码、可执行程序,工具及相关资料等。 ◆项目文档主要:立项书、项目计划、例会会议记录及项目过程中管理类文档等。 ◆设计及技术文档主要:需求,需求分析报告、概要设计说明书、详细设计说明书、数据库表结构、 测试文档、使用说明书、技术说明书等。 ◆工具及其相关资料:开发或测试过程中的工具,以及其使用文档等,如觉得有必要也纳入配置库的 管理。 3 项目配置库建立与使用 3.1 项目配置库建立 1.项目立项时,由项目经理申请建立项目配置库(附录二X《配置库申请单》) 2.配置管理员与项目经理根据《配置管理的流程》确定《配置管理计划》。 3.配置项:项目经理与配置管理员共同确认研发项目的配置库目录结构,并建立配置库目录结构;所建配 置库目录结构必需按本文规定目录结构执行(目录结构参考附录二)。 4.项目小组:项目经理提供项目小组成员名单及联系方式,配置库权限清单(内容应包括员工姓名、目录 权限等) 5.权限分配:配置管理员为相关人员的设置配置权限。配置库权限设置完成之后,由配置管理员将配置库 名称、访问路径、访问权限等信息以邮件方式通知各相关人员;配置库使用人员以各自的用户名和密码进行访问配置库。 6.配置库密码只能在服务器上设置,如配置库使用人员密码遗忘或需要修改,可以与配置管理员取得联系, 进行修改密码。 3.2 项目配置库使用 1.配置库目录说明 配置库基本结构如“附录二”所示,以项目名称作为一级目录,二级目录包括:devlib、testlib、PMlib、

软件配置管理规范流程

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) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一

软件正版化工作指南

附件: 正版软件管理工作指南 推进使用正版软件工作部际联席会议办公室 2016年7月11日

前言 为推进各级政府机关和企事业单位落实软件正版化工作主体责任,加强正版软件管理,保障信息安全,提高使用效率,降低使用成本,推进软件正版化工作规范化标准化,制定《正版软件管理工作指南》(以下简称《指南》)。 《指南》主要包括责任制度、日常管理、软件配置、软件台账、安装维护等五项软件使用管理制度范本和台账范本,供各单位开展正版软件管理工作参考。各单位可根据本单位实际情况对《指南》相关内容进行修改完善,建立本单位正版软件管理办法。 《指南》主要内容如下: 一、软件正版化工作责任制度。明确软件正版化工作领导小组人员组成和工作职责,以及软件使用部门和工作人员职责。 二、软件日常使用管理规定。明确软件日常使用管理涉及的工作计划、预算编制、软件采购、软件维护、宣传培训、检查考核、总结报告等工作流程和要求。

三、软件配置管理规定。明确软件配置原则和配置流程。 四、软件台账管理规定。明确软件使用管理台账种类和管理办法。 五、软件安装维护管理规定。明确软件安装、卸载及升级维护流程。 《指南》由推进使用正版软件工作部际联席会议办公室负责解释。

目录 一、软件正版化工作责任制度 (8) 二、软件日常使用管理规定 (11) 三、软件配置管理规定 (13) 四、软件台账管理规定 (15) 五、软件安装维护管理规定 (18) 六、附件: 1.软件正版化工作领导小组成员信息表 (20) 2.使用正版软件承诺书 (21) 3.软件使用需求申请表 (22) 4.软件采购计划表 (23) 5.软件正版化工作信息统计表 (24) 6.可使用免费软件清单 (25) 7.软件使用情况汇总表 (26) 8.软件使用情况明细表 (27)

相关文档
最新文档