配置管理计划.docx

资源描述

配置管理计划.docx

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

配置管理计划.docx

配置管理计划

<项目名称>项目

配置管理计划

京东世纪贸易有限公司

XXXX年XX月XX日

文档编号：

版本号：

产品名称：

XXXX项目

文档名称：

配置管理计划

版本号

修改内容描述

修改人

日期

变更请求号

批准人：

日期：

审核人：

日期：

1引言

1.1目的

本文档目的在于对XXXX项目进行软件配置管理，提高软件质量，降低软件开发成本。

本文档内容主要参考研发中心相关ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。

1.2术语定义

软件配置管理：

简称SCM（SoftwareConfigurationManagement的缩写），是在项目开发中，标示、控制和管理软件变更的一种管理。

配置管理的使用取决于项目规模和复杂性以及风险水平。

软件的规模越大，配置管理就显得越重要。

基线：

（BaseLine）是项目存储库中每个工作版本在特定时期的一个“快照”。

它提供一个正式标准，随后的工作基于此标准，并且只有授权后才能变更这个标准。

建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。

配置管理员：

项目组中负责配置管理工作的角色。

在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。

SCCB：

（SoftwareConfigurationControlBoard,软件配置控制委员会）一般由项目经理、各功能组代表（包括产品组、系统分析组、设计组、开发组、测试组、SCM组）、中高层管理者代表等组成，也即SCCB可以由项目经理、产品管理、程序管理、SCM人员、测试经理、部门主管、总经理室代表组成。

组织也可以指派管理者或专家参与。

SCCB组长由固定人员承担，可以是项目经理，也可以是组织指派的管理者或专家。

）代表项目经理和所有可能受到软件基线的更改影响的组的利益；批准设置基线产品；审查并批准对基线产品的更改并确保批准的更改得到实施；批准软件基线库生成的产品库。

配置标识：

（ConfigurationIdentification,CI）对软件项目在开发过程中的资源进行标识，以便识别。

配置项：

（ConfigurationItems,CIs）软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。

软件配置项包括：

与合同、过程、计划和产品有关的文档和资料；源代码、目标代码和可执行代码；相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。

配置检查：

（ConfigurationAudit）对软件配置管理过程中的行动进行检查。

1.3参考资料

列出要用到的参考资料，如:

a.计划任务书

b.本项目已发表的文件

c.需要引用的文件，资料，包括所用到的软件开发标准

2软件配置

2.1软件配置环境

2.1.1服务器软件环境

软件名称

作用

CentOS5

操作系统

Win2003

操作系统

2.1.2硬件环境

名称

规格

说明

网络

局域网

服务器

PC服务器

客户机

普通PC机

项目组成员各自的计算机

2.1.3配置管理工具

名称

说明

hudson

持续集成工具，测试构建工具

subversion

源代码管理工具

sharepoint

文档管理工具

confluence

文档管理工具

jira

缺陷跟踪管理工具

2.1.4配置管理客户端

项目成员在各自的计算机安装TortoiseSVN客户端，项目组成员以分配的账号登陆和访问配置服务器，根据配置管理员设定的用户权限进行配置管理活动。

2.2软件配置项

在本项目的实施过程中，将配置库分为受控配置制库和非受控配置库两种。

2.2.1受控配置库

在本项目开发实施的整个过程中，根据不同阶段的配置管理划分12个受控配置目录，只有配置管理员拥有增加和修改的权限，其他用户只有只读权限。

受控配置库的目录为：

00初始配置：

包含配置文件清单，项目组人员清单，SCCB人员组成清单，也可放置旧的范例文档或文档模版

01启动：

包含立项文档、项目计划等初始项目文档

02需求分析：

包含业务需求、系统需求和产品需求等

03设计：

包含产品设计，如：

概要设计，数据库设计，架构设计，详细设计，模型设计，原型设计，安全设计

04编码：

包含源代码和安装包管理

05测试：

包含测试计划，测试用例，测试报告

06发布：

包含发布计划，发布版本控制表

07总结：

包含会议纪要，项目周报，结项报告等

08变更：

包含变更申请表，变更跟踪统计表

09项目管理：

包含项目管理相关文档，如评审报告，项目状态报告，支持资源调整计划，立项申请，立项通知等

10环境配置：

包含开发环境，测试环境，线上环境配置清单

11开发工具：

包含开发过程中使用到的全部工具

初始配置库的根目录中包含XXXX项目的配置文件清单，该文档包括本项目开发过程中应该提交的文档和清单，在实际开发过程中，根据实际情况，可以在清单中酌情修改、增加和删除需要提交的文档。

具体内容参见本文3.3的“配置文件清单的维护”。

各个配置目录内应该包含的文档，请参见“XXXX项目配置文件清单.xls”

在根据项目开发过程中，根据实际需要，可以酌情修改非受控配置目录。

2.2.2非受控配置目录

在本项目开发过程中，设立了非受控配置目录。

设立非受控配置目录的是为了统一管理和存放开发过程中产生的临时文档和过程性文档，没有格式及命名上的严格要求，使项目组成人员在思考、设计时不受太多的限制和约束，能够有效的发挥个人能力，符合以人为本的原则。

在项目的初期设立了以下两个目录：

目录名称

用途及说明

小组工作区

用于保存小组成员协作编写的文档，每个小组都有自己独立的工作目录

文档提交区

作为非受控配置库和受控配置库之间的缓冲，用于提交已经定稿的文档和代码，在评审通过后，再由配置管理员取出并提交到受控制配置库中

在根据项目开发过程中，根据实际需要，可以酌情增加非受控配置目录。

2.3组织、职责和接口

项目配置管理员

人员：

职责：

负责制定项目配置管理计划；

按照计划实施项目配置管理活动；

将配置状态报告及时提交给相关人员。

SCCB

人员：

成员1、成员2、成员3、…。

负责人:

职责：

在配置管理员提交配置项后，CCB检查并批准/不批准配置项。

检查和批准项目基线。

在得到变更请求的影响分析后，CCB检查和批准/不批准该变更请求。

变更审定配置项的基线建立。

定期举行工作会议。

项目经理

人员：

职责：

负责审批项目配置管理计划，支持项目配置管理人员工作。

人员：

职责：

负责检查项目配置管理过程执行的有效性。

2.4配置管理过程

a．建立配置控制组（SCCB）；

b．确定各个配置基线；

c．制订评审与检查软件配置管理计划和规程；

d．制订相关的软件开发、测试和支持工具的配置管理计划和规程；

e.严格按照配置管理计划执行。

3软件配置管理计划

关于XXXX项目软件配置管理的文档提交计划请参见《XXXX项目配置文件清单.xls》。

关于配置库的日常使用的规定参见附件4《配置库使用规定》。

3.1建立示例配置库

配置管理员在制定完计划后，根据公司建议的配置库建立符合本项目的配置管理库。

配置库建立在sharepoint、subversion上，目录结构可按照示例的配置库提供的目录。

对于本项目来说，需要划分多个子系统，因此要在确定子系统的划分后，在不同阶段下分别建立各自系统的配置目录。

源代码管理参见源代码策略。

XXXX项目其配置管理（文档）目录结构如下图所示：

配置管理库建立完毕后，可根据配置管理库的人员计划建立相应的用户权限，并将这些用户分发给指定的开发人员或用户。

具体的账号及权限管理参加附录3《账号及权限管理》。

配置管理员应该保管好配置管理工具的管理权限。

3.2配置标识管理

1.文档

根据配置管理计划和配置库中的文档清单，配置管理员要检查需要提交的文档是否都按时提交，文档数目是否符合，文档的标识、命名以及版本等是否符合程序规定。

关于文档的命名请参见附件1《文件命名规定》，文档标示及版本参见附件2《文档编码规范》

2．程序

所有属于该项目的程序、分程序、模块和程序单元，都要按照由项目组和配置管理员制

订的软件系统的命名约定的规定来标识。

要求所有模块的源代码都需记录模块编号，且模块编号在整个系统中是唯一的。

模块编

号在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。

3．基线

所有属于本项目及其各子系统的各类基线，首先要按照计划书、软件需求规格说明书、

软件项目详细分析设计说明书的规定确定其技术内容，在整个软件项目开发过程中定义以下

三类基线：

文档基线：

本项目的文档基线的定义以里程碑的定义为准，将到达各阶段的里程碑时的文档

作为基线，具体里程碑的定义参见第4节“里程碑”。

代码基线：

依据公司源代码策略和开发计划设立源代码基线。

（我的策略：

分为三个步骤，第一是现在没有实现配置管理阶段：

最初的开发在主干上，新特性的开发在分支上，如果新特性是有完整的阶段性，及这一新特性阶段完成才开始下一阶段开发，则可以设立固定分支，如果是同步开发，则需要开多分支，主干的合并最好由配置管理员定期或根据计划操作，测试可以在分支上进行，版本稳定后可拉发布版本基线，然后再合并到主干上，及发布不一定非要从主干上提取代码，分支上的代码要与主干保持一致，分支和主干的持续集成计划可不同，比如主干是定期，分支是按开发需求或测试发布需求集成（对于测试部分，需要跟测试组了解下，包括测试流程，使用工具，测试环境）；第二是配置管理推广过程中依据推广计划和项目计划确立项目的源码基线，期间完善成熟期的源码策略；第三是配置管理成熟期：

公司研发部使用统一的成熟的源码策略，实现对源码和程序包的配置管理）。

产品基线：

产品基线包含两个，一个是系统上线时，一个是系统经过客户验证测试时，基线

包含那时的所有程序代码和文档。

配置管理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个

配置库设立书签，划定配置管理基线，并以文档的方式记录下这些书签的定义

3.3配置库控制

权限控制

配置管理员根据《账号及权限管理.xls》设置和调整项目组成员对配置项的权限。

配置库的控制

在项目的各个开发阶段，应建立起各阶段各子系统的软件开发库（软件开发工作区），

同时建立起想对应的有关该系统及其子系统的软件受控库。

在每个阶段结束或里程碑，需让

各子系统提交相关的产品并送入软件受控库，由配置管理员统一管理，以后再有对产品的变

更需求，应按照正常的变更程序来控制并检查相关的变更文档。

当全部开发工作结束，需建

立起软件产品库，将所有可交付的产品都送入软件产品库。

软件配置更改

软件配置的更改管理适用于全部项目的所有文档和代码，其中包括整个项目的各个运行

软件，也包括为项目专门开发的支持软件。

●对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改，必须得到项目负责人的批准并在本项目软件质量管理专员处备案才能进行配置更改；

●更改完成后的文档和代码等，需得到项目负责人认可，提交给配置管理员后，由配置管理员签入受控配置库；

●受控配置库中的文档，在文档末尾必须有修改记录部分，包括修改人、修改日期、修改内容等项，每次对于受控配置库中文档的修改，必须填写这些项。

配置文件清单的维护

●配置文件清单的维护由配置管理员维护；

●项目初期，配置管理员与项目组成员一起对开发过程中可能产生的文档的进行预计，并在配置文件清单中列出这些文档及其大致的计划提交时间；

●在实际开发过程中，文档提交可能会产生一些变化，如新增某些文档、原计划的一些文档不再单独产生、文档计划提交日期的变更等，项目组应该及时通知配置管理员，由配置管理员及时更改配置文件清单中的相应项。

3.4配置的审查和评审

配置的检查和评审可通过研发中心配置管理制度的审核内容来进行检查。