<项目名称>项目
配置管理计划
京东世纪贸易有限公司
XXXX年XX月XX日
文档编号：
版本号：
产品名称：XXXX项目
文档名称：配置管理计划
版本号修改内容描述修改人日期变更请求号批准人：日期：审核人：日期：
目录
1引言 (4)
1.1 目的 (4)
1.2 术语定义 (4)
1.3 参考资料 (5)
2软件配置 (5)
2.1 软件配置环境 (5)
2.2 软件配置项 (5)
2.3 组织、职责和接口 (7)
2.4 配置管理过程 (7)
3软件配置管理计划 (8)
3.1 建立示例配置库 (8)
3.2 配置标识管理 (9)
3.3 配置库控制 (9)
3.4 配置的审查和评审 (11)
3.5 配置库的备份 (12)
3.6 配置管理计划的修订 (12)
3.7 配置管理计划附属文档 (12)
4. 里程碑 (13)
附录1 文档命名规则 (14)
受配置库文件命名规则 (14)
非受控配置库文件命名规则 (14)
提交文档文件命名规则 (14)
附录2 账号及权限管理 (15)
账号管理 (15)
权限管理 (15)
附录3 配置库使用规定 (16)
1引言
1.1目的
本文档目的在于对XXXX项目进行软件配置管理，提高软件质量，降低软件开发成本。
本文档内容主要参考研发中心相关ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。
1.2 术语定义
软件配置管理：简称SCM（Software Configuration Management 的缩写），是在项目开发中，标示、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。
基线：（BaseLine）是项目存储库中每个工作版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
配置管理员：项目组中负责配置管理工作的角色。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。
SCCB：（Software Configuration Control Board ,软件配置控制委员会）一般由项目经理、各功能组代表（包括产品组、系统分析组、设计组、开发组、测试组、SCM组）、中高层管理者代表等组成，也即SCCB可以由项目经理、产品管理、程序管理、SCM人员、测试经理、部门主管、总经理室代表组成。组织也可以指派管理者或专家参与。SCCB组长由固定人员承担，可以是项目经理，也可以是组织指派的管理者或专家。）代表项目经理和所有可能受到软件基线的更改影响的组的利益；批准设置基线产品；审查并批准对基线产品的更改并确保批准的更改得到实施；批准软件基线库生成的产品库。
配置标识：（Configuration Identification,CI）对软件项目在开发过程中的资源进行标识，以便识别。
配置项：（Configuration Items,CIs）软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。软件配置项包括：与合同、过程、计划和产品有关的文档和资料；源代码、目标代码和可执行代码；相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。
配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。
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检查和批准/不批准该变更请求。
变更审定配置项的基线建立。
定期举行工作会议。
项目经理
人员：
职责：负责审批项目配置管理计划，支持项目配置管理人员工作。
QA
人员：
职责：负责检查项目配置管理过程执行的有效性。
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 配置的审查和评审
配置的检查和评审可通过研发中心配置管理制度的审核内容来进行检查。相关的审核内容如下表：
审核分类审核内容检查情况发布审核发布文档是否清楚地定义发布的范围，包括应被纳入的更改
请求？
所有已知缺陷/毛病(bug)是否已文档化？
是否有适当的文档，它标识重建该发布所需的环境（编译器
版本、OS 版本、compilation flags，等等）？
是否有适当的文档，它说明构成该发布的成分及成分的版
本？
发布的所有项是否彼此同步（在时间上一致）？
是否采用正确存储库中的正确成分的正确版本生成发布？
存储库/配置项审核存储库是否按SCM 计划定义？
配置项是否已经进入正确的库？
是否按SCM计划中规定的命名约定项命名？
是否按照SCM 计划，规定项的版本号？
是否按照SCM 计划中规定的事件已经将所有项入库？例如：测试完成、客户的评审意见已采纳
是否有所要求的文档以识别项、版本和更改历史？
更改实施审核是否全部所要求的更改请求均已结束？
是否更改请求标识出全部拟更改的项？
更改请求中所标识的全部要更改的配置项均已更改，被QC 和在所要求的QC 后入库？
是否可能在项的任何两个版本中间区分更改？
配置项的文档是否足够，能向后追踪更改到相应的更改请求？
是否有恰当方法能回到以前的版本？
审核的其他方面是否对库作了恰当的备份？
是否已测试过从备份中恢复？
在群组成员的工作目录中是否有任何未经许可的成分？
是否有恰当的保密/批准手续以保证只有经授权的群组成员才能进行入库/出库？
配置管理员应配合研发中心产品管理部定期对项目进行配置管理的审核。在审核过程中，提供所需要的配置管理计划及相关资料，在项目开发结束后，需提交所有关于项目的软件配置库。
3.5 配置库的备份
在项目开发实施过程的各个阶段，配置管理员应定期做好软件配置库的备份，以防造成劳动成果的丢失而给整个项目及公司带来的严重损失。
备份可按照公司的要求定期（按周或月）进行。在每个阶段或里程碑处在做完基线工作后应进行备份。备份文件应存放在不同的地方。
本项目的备份按如下方式进行：
?定期备份时间为每个月备份一次，备份方式同公司研发中心一致，定于每个月的最后一个星期二；
?当在月末（大于当月20 日）达到一个里程碑时，对配置库进行一次备份，取消当月月备份；
?当在月中（大于当月10 日，小于等于当月20 日）达到一个里程碑时，对配置库进行一次备份，当月月备份不变；
?当在月初（小于当月10 日）达到一个里程碑时，不需要对配置库再进行一次备份，当月月备份不变；
?备份的文件要明确标明备份日期，刻录成光盘，在外地封闭开发，现场尚未配备刻录机时，应保存在可靠的计算机中；
3.6 配置管理计划的修订
初始的配置管理计划在项目开始的初期进行制定，由于此时只能大致确定整个开发过程中的一些活动及其会产生的文档，在实际开发过程中，可能会与此有些差异，因此，配置管理计划也需要根据开发过程的实际情况，及时进行修订，使之能够有效地对本项目的配置管理活动进行指导。
在一般情况下，进行配置管理计划修订的时机选在到达各个阶段的里程碑时。如果在一个阶段的实施过程中，配置管理计划不能适应实际过程的变更，则由配置管理员与项目管理人员一起根据实际情况修订配置管理计划。
配置管理计划的修订，需要通过XXXX 项目项目的项目负责任、软件配置控制委员会成员、配置管理员的共同审核，一致签字同意后方能作为此后阶段的配置管理计划。
3.7 配置管理计划附属文档
《配置文件清单》：记录项目开发过程中应该产生的一些文档、描述及其提交计划等内容，是执行配置管理及检查的重要依据。该文档在项目开始的初期建立，确定开发过程中需要提交的大部分文档，并在项目开发过程中根据实际情况稍做更新。
《模块清单》：模块清单记录了系统各个子系统、程序模块的名称并分别进行项目内的唯一编号，是所有模块的源代码需记录模块编号的依据。《模块清单》在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。
《文档命名规定》：参加附录1 《文档命名规定》
《账号及权限管理》：参加附录2 《账号及权限管理》
《配置库日常使用规定》：参加附录3 《配置库日常使用规定》
4. 里程碑
本项目主要分为以下几个里程碑：
里程碑特点
1，需求分析已确立?系统（或所有已确定子系统）的需求分析全部完成
?已形成相应的需求分析说明书及其它附属文档
?需求分析说明书已通过公司评审或与客户一致认为
需求分析阶段已结束，可以进入设计阶段
2. 概要设计完成?系统（或所有已确定子系统）的概要设计全部完成
?已形成相应的概要设计说明书及其它附属文档
?概要设计说明书已通过公司评审或与客户一致认为
概要设计阶段已结束，可以进入详细设计阶段
3. 详细设计完成?系统（或所有已确定子系统）的详细设计全部完成
?已形成相应的详细设计说明书及其它附属文档
?详细设计说明书已通过公司评审或与客户一致认为
详细设计阶段已结束，可以进入编码阶段
4. 编码完成?系统（或所有已确定子系统）的编码全部完成
?系统所有程序已经经过调试并确定可以运行
?已通过公司评审或与客户一致认为编码阶段已结束，
可以进入系统测试阶段
5. 测试计划完成?测试需求已经确定并完成；
?已形成相应的测试计划说明书及其它附属文档
6. 测试设计完成?测试用例已经覆盖所有测试需求
?已形成相应的测试用例说明书及其它附属文档
7. 系统测试完成?系统测试完成，所发现的所有缺陷已得到妥善处理
?符合系统测试退出条件
?已完成测试分析报告
8. 项目结束?上线成功
?已得到客户的确认并通过验收测试
?与客户一致认为该项目已结束
附录1 文档命名规则
本命名规定主要是针对文档的，不包含源代码文件和最终程序的命名规则。本规定主要
包含以下三个方面的命名规则：
1. 受控配置库文件命名规则
2. 非受控配置库文件命名规则
3. 提交文档文件命名规则
受配置库文件命名规则
受控配置库中的配置项文档（不含源代码和最终工作产品）名称应该按照如下格式命名：项目编号+ 文档名称+ V<发布版本号>[.扩展名]
项说明
项目名称XXXX项目
项目编号XXXXXX
资料名称开发计划书
系统方案书
需求分析说明书
概要设计说明书
详细设计说明书
测试计划
模块清单
……
撰写或修改日期第一次撰写完成日期或修改完成日期
例如：
2012年7月23日定稿开发计划书：
XXXXXX--软件开发计划书V1.0.doc。
2012年7月28日定稿的子系统一需求分析说明书：
XXXXXX--子系统一需求分析说明书V1.0.doc。
非受控配置库文件命名规则
非受控配置库主要用于存放项目成员工作时产生的临时文档等，只要求提交时不致出错，对命名规则没有其它限制，由项目成员根据自己习惯对文档命名。
推荐命名方式：文件名+ 日期[.扩展名]
提交文档文件命名规则
同受控配置库的文件命名规则。
项目成员提交文档到文档提交区前，应该按照受控配置库的文件命名规则对文档命名，然后才提交道文档提交区中。
附录2 账号及权限管理
账号管理
根据公司的erp账户建立用户账号
权限管理
权限管理分为两大部分的权限管理：
1，受控配置库的权限管理
2，非受控配置库的权限管理
1、111、、、受控配
配置管理员对受控配置库拥有所有权限；
项目组其他成员对受控配置库拥有只读权限；
非项目组成员未经允许对整个配置库没有任何权限；
2、222、、、非受控配置库
非受控配置库主要包含以下三个目录：
个人工作区
小组工作区
文档提交区
在SourceSafe 上的个人工作区目录下为项目组的每个项目成员都建立了一
个与本人的中文名字一样的目录；
每人对与自己同名的目录拥有所有权限，对其它的目录拥有只读权限；XXXX 项目配置管理计划分为子系统一、子系统二、子系统三个目录；
各小组的成员对所属小组目录拥有所有权限，对其它小组目录只有只读权限；
项目管理人员和配置管理员对所有小组目录拥有所有权限；
用于文档和代码提交；
所有人对其拥有只读／修改／删除和签入／签出权限；
配置管理员对其拥有所有权限；
附录3 配置库使用规定
1、项目组成员编写的与本项目有关文档、程序代码等，应该保存在配置库中；
2、文档在编写过程中，保存在配置库的非受控目录中，其中个人文档和代码保存在“个人工作区”的项目成员本人的目录下，小组文档保存在“小组工作区”的所属小组目
录下；
3、每周第一个工作日开始，项目成员从非受控配置库中签出要编写、修改的文档或代码到本人的计算机，进行编写、修改工作；
4、每周最后一个工作日结束时，项目成员必须将签出的文档保存后签入到配置库中；
5、文档和代码要提交到受控配置库中时，必须先提交给配置管理员，由配置管理员提交到受控配置库中；
6、当文档或代码通过评审或得到项目管理人员及客户的一致认为可以提交时，提交到“文档提交区”的目录中；
7、文档提交前应该按照附录1《文档命名规定》中的规定进行命名，文档编码应该符合附录2《文档编码规范》中的规定；
8、项目组成员未经项目组允许不得更改他人的文档和代码；
9、任何文档、代码等，不能以压缩文件的方式签入配置库中；
10、每次评审结束，相关文档的批准人电子签名由批准人签写或经批准人授权配置管理员填写，然后由配置管理员负责签入配置库；
11、如果需要对受控配置库中的文档、代码进行变更，需得到项目负责人批准方能从受控配置库中取出更改；
12、更改完成后的文档，需得到项目负责人认可，提交给配置管理员后，由配置管理员签入受控配置库。
配置管理员个人简历模板下载 王朋 两年以上工作经验|男|27岁（1989年7月27日） 居住地：广州 电话：152******（手机） 最近工作[1年5个月] 公司：XX有限公司 行业：计算机软件 职位：配置管理员 学历 学历：本科 专业：计算机科学与技术 学校：广州大学 自我评价 为人稳重、大方，认真对待工作，开朗自信，待人真诚，有优良的团队精神，强烈的责任心，良好的沟通协调水平。在责任心、事业心、亲和力、决策水平、计划水平、谈判水平强，具备良好的敬业精神和职业道德操守，有很强的感召力和凝聚力。 求职意向 到岗时间：一个月之内 工作性质：全职
希望行业：计算机软件 目标地点：广州 期望月薪：面议/月 目标职能：配置管理员 工作经验 2020/4 — 2020/9：XX有限公司[1年5个月] 所属行业：计算机软件 项目部配置管理员 1. 负责项目发布和维护工作，编写发布报告和问题报告，提供项目版本发布信息； 2. 负责项目开发任务，系统问题修复，负责代码管理、分支策略相关流程； 3. 负责项目测试，编写测试用例，提供测试报告，实行回归测试及系统测试。 2020/8 — 2020/2：XX有限公司[1年6个月] 所属行业：计算机软件 项目部配置管理员 1. 负责软件配置管理工具（SVN）的日常管理和项目代码分支合并； 2. 编写软件发布流程文档，项目代码编译打包，软件发布； 3. 负责项目各种环境（Trail run，UAT，CRP）的搭建和维护。 教育经历
2008/9— 2020/6 广州大学计算机科学与技术本科证书 2009/12 大学英语四级 语言水平 英语（良好）听说（良好），读写（良好）
软件配置管理计划示例 作者：赵文锋计划名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．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门：java第四组 撰写人（签名）：区允文 完成日期：2010年8月4日 本文档使用部门：■主管领导■项目组 □客户（市场）□维护人员□用户 评审负责人（签名）：江威龙 评审日期：2010/8/4
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6
3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明：8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15
配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。 1.3定义、首字母缩写词和缩略语 CM：配置管理。 CCB：变更控制委员会。 CI：配置项。包含文档、程序。 Baseline：基线。 CR：变更请求。 PCA：物理审计。 FCA：功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构
机电管理系统性能测试系统 配置管理计划
这里填写公司名称 文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 产品名称:机电管理系统性能测试系统 文档名称:配置管理计划 这里填写公司地址、联系方式等
目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.3 参考资料 (1) 2. 软件配置 (2) 2.1 软件配置环境 (2) 2.2 软件配置项 (2) 2.3 配置管理员 (3) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.3 配置库控制 (7) 3.4 配置的检查和评审 (8) 3.5 配置库的备份 (9) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (11) 附录1 文档命名规定 (12) 1、受控配置库文件命名规则 (12) 2、非受控配置库文件命名规则 (12) 3、提交文档文件命名规则 (12) 附录2文档编码规范 (13) 附录3 帐号及权限管理 (14) 附录4 配置库使用规定 (16) 文档修改记录 (17)
1. 引言 1.1 目的 本文档目的在于机电管理系统性能测试系统进行软件配置管理，提高软件质量，降低软件开发成本。 本文档内容主要参考研发中心相关的ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2 术语定义 软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。 基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。 配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。 配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。 1.3 参考资料 《研发中心配置管理制度》 《产品的标识与可追溯性程序》 《开发手册》
配置管理计划配置管理计划的案例 配置管理计划来自：://.chinaspis. 作者：林锐电子工业出版社出版发行 { 项目名称 } 配置管理计划文状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文标识： pany-Project-CM-PLAN 当前版本： X.Y 作者： 完成日期： Year-Month-Day 版本历史版本/状态作者参与者起止日期备注 目录 1.人员及职责 2.配置管理软硬资源 3.配置项计划 4.基线计划 5.配置库备份计划 附录：本计划审批意见 1.人员及职责 提示： （1）根据《项目计划》中的角色分配，确定配置管理员，CCB（配置控制委员会）成员。
（2）CCB的人数根据项目规模而定。一般地，项目经理是CCB的负责人。 角色人员职责、工作范围 配置管理员 （1）制定《配置管理计划》 （2）创建和维护配置库 CCB负责人 （1）审批《配置管理计划》 （2）审批重大的变更 CCB成员例如：审批某些配置项或基线的变更… 2.用于配置管理的软硬资源 提示： （1）配置管理员确定本项目的配置管理软。例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。 （2）配置管理员根据所采用的配置管理软，确定计算机资源（考虑内存、外存、CPU等）。 配置管理软硬资源说明配置管理软名称公司，软版本等计算机名称内存、外存、CPU等3.配置项计划 提示：配置管理员标识配置项，估计每个配置项的正式发布时间。标识符的参考格式为Project-Type…Type-Number。例如：类型主要配置项标识符预计正式发表时间计划 《项目计划》
软件配置管理规范 流程 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 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料
◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务
XXX项目 配置管理计划
文档修订记录 *变化状态：A 增加，M- 修改，D—一删除
概迷 ............... 1.1 项目基本倚息 1?2 参考文档 2 术语表 3 资源...， 」 配1^项标识规则 44 4.5 目录 46 《配置管理报告》il ?划 3?2 软件要求 3?3 硬件要求 14 4 配置管理活动 网络要求 配置管理培训要求 <2 基线标识规则 43 识别配置项与基线
1概述 1.1项目基本信息 1.2参考文档 文件编号：QG17RK 15.14.003-2013 文件编号：QGI7RK 15.14.004-2013 2术语表 3资源 3.1配置管理培训要求 项目组成员对配置皆理工具使用熟练，有用配背^管理工具进行项目过程管理的经验。 3.2软件要求 《配登管理办法》 《配置管理规程》
3.3硬件要求 最低配置建议配置CPU IGHz 主频单核Intel,? CPU 1.5GHZ主频以上双核Intel, AMD CPU 内存512 MB IGB或更高 显示分辨率1,024x768 像素1280x1024像素或更高 硬盘*安装驱动器上要有2 GB可用空间 *系统驱动器上要有1 GB可用空间 *安装驱动器上要有4 GB叮用空间 *系统驱动器上要有2 GB叮用空间 3.4网络要求 公司总部办公：使用客户端连接公司内部网络环境。 出差：使用公司为出差人员配发的Ukcy连接公司内部网络环境。注：Ukcy在组织级配置管理员处领取和配置。 4配置管理活动 4.1配置项标识规则 根据《配置管理办法九确定本项目配這项的命名及版本标识规则如下: 配置项命名: 文档类配置项的命名规则应当为：“贵州轮胎GZLT密炼MES三期-研发项目-文档简称软 件类配置项的命名规则应当为：“赍州轮胎GZLT密炼MES三期-版本”。 配置项版本： 版本的形式应由3位组成:［V C版本标识符）］［主版本号］?［次版本号］,初始值为VI. 0； 只有通过《变更笛理规程》进行变更后的配置项才对主版本号升级，貝他情况只对次版本号升级。 4.2基线标识规则 根据《配置管理办法九确定本项目的基线的命名规则和版本升级规则如下: 基线命名规则〈产品名称〉/＜项目简称＞_＜基线简称＞_＜版本＞，日期九 幷中，本项目简称为G2LTMES：基线简称如下表所示: 开发人员Microsoft Visual Sourcesafe 2005
. 软件项目管理计划 Version 1.2专业资料word . Revision 专业资料word . 录目 1. 简介1 项目概述1.1 1.2 项目交付产品1 SPMP 的演化1.3 1 参考资料1.4 1 1.5
术语与缩写1 1 2. 项目组织 1 2.1 过程模型2. 2 组织结构1 2. 3 组织接口1 2.4 项目职责2 2 管理过程3. 3 3.1 管理目标和优先级3.2 假设、依赖关系和限制3 风险管理3.3 3 监督和控制机制3.4 3 3.5 人员计划3 3 4. 技术过程 4 方法、工具和技术4.1 软件文档4.2 4 用户文档4.3 4 4.4 项目支持功能4 4 工作包、进度表和预算5. 4 工作包5.1 依赖关系5.2 4 资源需求5.3 4 预算和资源分配5.4 4 5.5 进度表4 6. 其他索引 6.1 4 6.2 附录 4 专业资料word . 1. 简介 1.1 项目概述 说明：简要综述项目的目标、发布的产品、主要工作活动、主要工作制品、关键里程碑、所需资源、进［度和预算等。必要的情况下，还应描述该项目与其他项目的关系。］ 1.2 项目交付产品
说明：列出主要的可交付产品、交付日期、交付地点和满足项目协议条款所需的质量。］［的演化SPMP1.3 说明：描述如何以及由谁负责维护本文档，应指明更新内容的传播方式以及在变更控制下更新文档版本[ 的机制。］ 1.4 参考资料 说明：提供项目计划中所引用的所有文档和其他信息资源的完整清单，包括标题、报告编号、日期、作[ 者以及发布机构。］ 1.5 术语与缩写 说明：定义SPMP 所应用的全部术语和缩写词。］［ 2. 项目组织 2.1 过程模型 说明：描述该项目所使用的软件过程模型，或者是所遵循的组织标准模型。过程模型需要指明［里程碑的时间、基线、评审、工作制品、项目交付产品、结束标志等。］ 2.2 组织结构 说明：描述项目的内部组织结构，可以参考如下的层次结构图形式。］［专业资料word .
<项目名称> 配置管理计划 版本 <1.0> [注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应 该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=正文）。]
修订版历史
目录 1.简介 1.1目的 1.2范围 1.3定义、首字母缩写词和缩略语 1.4参考资料 1.5概述 2.软件配置管理 2.1组织、职责和接口 2.2工具、环境和基础设施 3.配置管理活动 3.1配置标识 3.1.1标识方法 3.1.2项目基线 3.2配置和变更控制 3.2.1变更请求的处理和审批 3.2.2变更控制委员会 (CCB) 3.3配置状态统计 3.3.1项目介质存储和发布进程 3.3.2报告和审核 4.里程碑 5.培训和资源 6.分包商和厂商软件控制
配置管理计划 1.简介 [配置管理计划的简介应提供整个文档的概述。它应包括此配置管理计划的目的、范 围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1目的 [阐明此配置管理计划的目的。] 1.2范围 [简要说明此配置管理计划的范围：它的相关模型，以及受到此文档影响的任何其他事物。] 1.3定义、首字母缩写词和缩略语 [本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。这些信息可以通过引用项目词汇表来提供。] 1.4参考资料 [本小节应完整地列出此配置管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和发布组织。列出可从中获取这些引用的来源。这 些信息可以通过引用附录或其他文档来提供。] 1.5概述 [本小节应说明此配置管理计划中其他部分所包含的内容，并解释文档的组织方式。] 2.软件配置管理 2.1组织、职责和接口 [说明谁将负责执行 CM 工作流程中所述的各种配置管理 (CM) 活动。] 2.2工具、环境和基础设施 [说明在整个项目过程或产品生命周期中为实现 CM 功能而使用的计算环境和软件工 具。 说明对整个项目过程或产品生命周期中生成的配置项进行版本控制时所需的工具和过 程。 建立 CM 环境时所涉及的问题有： ?产品数据量的预期大小 ?产品团队的分配 ?服务器和客户机的实际位置] 3.配置管理活动 3.1配置标识 3.1.1标识方法 [说明项目工件或产品工件的命名、标记和编号方法。标识方案中需包括硬件、系统软件、市售 (COTS) 产品以及产品目录结构中所列的所有应用程序开发工件，例如计划、模型、构件、测试软件、结果与数据、可执行文件等。] 3.1.2项目基线 [基线提供一项正式标准，随后的工作都基于此标准，并且只有经过授权后才能对此标准进行变更。
项目配置管理计划模板 【项目名称】 项目配置管理计划模板 日期： 版本号：
文件变更记录 *A–增加M–修订D–删除 变更 日期变更类型 修改人摘要备注 版本号（A*M*D）
目录 项目配置管理计划 (1) 文件变更记录 (2) 目录 (3) 1. 概述 (4) 编写目的 (4) 参考资料 (4) 2. 配置管理约定 (4) 3. 配置项/单元列表 (6) 4. 软件配置列表 (8) 5. 配置管理活动策划列表 (8)
1.概述 1.1 编写目的 指导项目的配置管理活动。 1.2 参考资料 《项目主计划》 《项目自定义过程说明》 2.配置管理约定 1)项目组所有成员的工作产品都要放入配置库，本项目配置库的目录如下：
项目配置管理计划模板 图 2.1项目配置库目录 2)使用的配置管理工具： 服务器端：SVN1.8 客户端：TortoiseSVN-1.8.4.24972-win32-svn-1.8.5 3)权限分配 表 2.1项目配置库权限分配表 目录PM RAE SE PG TE QA CE \01-项目管理库\01-售前rw rw r r r r rw \01-项目管理库\02-项目 rw r r r r r rw 策划 Page 5/9
项目配置管理计划模板 \01-项目管理库\03-项目 rw r r r r rw rw 监控 \01-项目管理库\04-项目 rw r r r r r rw 结项 \01-项目管理库\05-风险 rw r r r r rw rw 库 \02-开发工程库\01-需求r rw r r r r rw \02-开发工程库\02-设计r r rw r r R rw \02-开发工程库\03-编码r r r rw r r rw \02-开发工程库\04-测试r r r r rw r rw \02-开发工程库\05-发布rw r r r r r rw \02-开发工程库\06-验收rw r r r r rw rw \02-开发工程库\07-维护r r r rw rw r rw \02-开发工程库\08-个人 rw rw rw rw rw rw rw 使用 \03-支持\01-配置管理r r r r r r rw \03-支持\02-质量保证管 r r r r r rw rw 理 \03-支持\03-培训记录rw r r r r r rw \03-支持\04-决策分析rw r r r r r rw \04-基线库r r r r r r rw \05-参考资料rw rw rw rw rw rw rw \06-其他rw rw rw rw rw rw rw 3.配置项/单元列表 表3.1配置项/单元列表 过程阶段编配置项/单元计划提交计划基线 负责人备注（基线名称）号名称时间时间 启动 1 项目立项报告
XXX有限公司 组织级配置管理计划
*变化状态：A——增加，M——修改，D——删除
1 前言 1.1 目的 本计划是组织级配置项目计划的组成部分，它规定了在组织级配置项目中如何开展配置管理工作，以便在项目的整个生存周期中，建立和维护软件工作产品的完整性和一致性。 1.2 适用范围 本计划是遵照组织级的《配置管理过程》、《配置管理计划》等标准规范和《裁剪指南》，结合本项目的实际情况制订；适用于整个产品生命周期的配置管理相关活动。 1.3 读者对象 EPG组成员 2组织级配置项管理 2.1配置结构 2.2配置项管理 01-OSSP目录下文档为组织过程改进的知识库，作为组织改进的指导性文件：放入SVN库
中归档管理，全体人员有可读权限。当OSSP中文档需要修改时需要走正式的变更流程。 02-EPG 目录下文档为改进组活动产生的文档：放入SVN库中归档管理。 ‘01-组织方针’全体可读，当‘01-组织方针’中文档需要修改时需要走正式的变更流程。 ‘02-组织培训’中的文档培训人员（顾晓丹）在有培训需求进入的情况下定期进行更新，配置管理人员定期（每月）检查培训中产出的文档做配置审计。 ‘03-EPG活动管理’改进组可写，配置管理人员定期（每月）检查组织月报、质量保证报告、配置项状态的提交情况并做配置审计，EPG组定期更新。 03-PAL目录下存放改进中优秀的资产，当有新资产加入的时候，及时更新并做配置审计。 变更流程： 对配置管理下的工作产品作变更（如：OSSP标准文档的改变、新资产入库等），都需要被跟踪和控制，用来保证工作产品配置信息的完整性和可跟踪性。对标准文档与资产文档配置改动需要填写申请。如《过程资产提交申请单》。 2.3配置项列表 ├─01-OSSP │├─01-工程过程 │├─02-项目过程 │├─03-支持过程 │├─04-组织过程 │└─05-基线库 ├─02-EPG │├─01-方针计划 │├─02-组织培训 ││├─人力资源 │││└─各个过程能力要求 ││├─培训反馈 ││├─培训材料 │││├─CMMI │││└─Introduction ││├─培训计划 ││├─培训记录 ││├─培训通知 ││└─培训需求 │└─03-EPG活动管理 │├─01-组织月报 ││└─会议记录 │├─02-质保监管 ││└─月检查清单 │├─03-配置监管 │└─04-发布公告 └─03-PAL
项目可行性研究（模版） 一、项目基本情况 项目名称：制作日期：年月日 制作人：签发人： 二、项目背景 1．目前状态 （简要描述目前的商业环境和项目产生背景。） 2．拟解决的商业问题 （简要说明需要项目解决的商业问题，以表明项目存在的理由。） 3．影响范围 （简要说明项目问题及问题的解决将对企业哪些方面产生影响，包括影响的组织范围。）4．项目预期的结束日期 （尽可能对项目的完成日期做出准确推断。） 三、可能的项目方案 方案2： 四、初步评估意见 （对第三部分提出的若干项目方案进行评估，并提出推荐意见。在一件重要说明各种方案可能的风险以及修正或调节意见。） 对各方案的结论：□接受□拒绝□修改□暂缓决定 五、签字 （由项目可行性论证小组成员签字，项目组成员至少需要包含商业/管理、财务、技术三方面的人员。）
一、项目基本情况 项目名称：制作日期：年月日 制作人：签发人： 二、项目目的 1．项目需解决的商业问题 （所有的项目均起始于某个商业问题，该部分简要描述这些问题。） 2．项目工作内容 （对项目范围的限定，以及对完成项目的主要工作内容和方法的陈述。） 3．项目目标 （包含工期目标、费用目标和交付产品特征与特征的主要描述。） 三、项目的关键成功要素 （对确保项目成功的关键环节和关键资源、关键方法、度量标准等进行概念性地简要描述。） 四、项目影响范围 （包含对企业战略的影响、对技术的影响和对财务的影响。） 五、项目主要里程碑计划 （包含主要里程碑的时间、费用和成果目标。） 六、项目假设 （说明项目的主要假设条件。） 七、项目约束条件 （说明项目启动和实施过程中的限制性条件。） 八、项目评价标准 （说明项目成果在何种情况下将被接受，何时项目将被终止或取消，项目成功标准的度量或验收规程。） 九、项目主要利益相关者 （包括项目发起人，项目经理，项目团队主要成员，相关职能部门负责人，客户等的头衔、签字和签字日期。）
配置管理控制程序 历史记录
目录
1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程，目的是规范公司的软件配置管理活动，使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品（Work Products）：项目技术开发和管理工作中产生的有价值的成果，例如源代码、数据和各种文档。 配置项（Configuration Item, CI）：纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ]；配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理。 基线（Baseline）：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。 2角色与职责 2.1软件配置管理组（CM） CM组是项目里的一个小组，根据项目大小，可以由一个人，或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排，加入到项目组，由项目经理领导。 CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级，通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、
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 可追溯性
软件配置管理规范 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参考信息
软件配置管理计划 SANY GROUP system office room 【SANYUA16H-
软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的国势通多媒体网络传输加速系统软件规定各种必要的配置管理条款，以保证所交付的国势通多媒体网络传输加速系统软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义
本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务
文件编号：PTS - PDP - SCMP 软件配置管理计划 拟制：____________________ 日期：____________________ 审核：____________________ 日期：____________________ 批准：____________________ 日期：____________________ 太平洋软件（中国）有限公司
变更记录页
目录 1介绍 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 缩写和定义 (1) 2SCM管理 (2) 2.1 组织 (2) 2.2 SCM责任 (2) 2.3 可用的策略、指令和程序 (2) 3SCM 活动 (3) 3.1 配置标识 (3) 3.1.1 配置项的标识 (3) 3.1.2 配置项的命名 (3) 3.1.3 配置项的获取 (3) 3.2 配置控制 (4) 3.2.1 请求变更 (4) 3.2.2 评估变更 (4) 3.2.3 批准或拒绝变更 (5) 3.2.4 实施变更 (5) 3.3 配置状态统计 (5) 3.4 配置审核和审计 (6) 3.5 接口控制 (6) 3.6 转包商/供应商控制 (6) 4进度安排 (8) 5SCM 资源 (8) 6SCM计划维护 (8)
软件配置管理计划1介绍 1.1目的 1.2范围 1.3缩写和定义
2SCM管理 SCM管理信息描述了组织和个人在项目的SCM活动中的责任和权限。 SCM管理信息必须包括三个主题：应用SCM的项目组织，这些组织的SCM责任，以及应用在这个项目中的SCM政策和指令。 2.1组织 组织结构包括技术和管理两方面，计划中的并将要被实施的SCM活动必须被描述。计划必须说明以下问题： a)在项目中，参与或对任何SCM活动负责的组织单位； b)在项目结构中，组织单位的功能角色； c)各组织单位之间的关系。 组织单位可能包括供应商和客户，主承包商和分承包商，或在组织中的其他团队。组织图表、功能和关系的状态的补充可以成为表现信息的有效途径。 2.2SCM责任 对组织单位SCM活动的分配必须被详细说明。对每个在SCM中列出的活动，必须提供执行活动的组织单位或工作标题的名字。可以使用矩阵清楚地表示和说明以上定义的组织和SCM功能、活动和任务之间的关系。 对于那些在项目中为执行SCM活动而建立的任何审查委员会或特定组织，计划中必须描述有关它们的以下方面： a)目的和目标； b)成员和联系； c)有效期； d)权限范围； e)操作程序。 2.3可用的策略、指令和程序 由其它政策、指令和过程附加在计划上的限制必须被定义。对每一个限制来说，它的影响和效果必须被声明。
软件配置管理计划模板 文档标识：当前版本：当前状态：发布日期：
目录 1概述 (4) 1.1目的和范围 (4) 1.2软件配置管理计划维护 (4) 1.3参考资料 (4) 2角色和职责 (4) 2.1软件配置管理代表 (4) 2.2配置控制委员会 (4) 2.3项目开发组 (4) 2.4项目经理 (5) 3配置管理环境 (5) 3.1文档工具 (5) 3.2软件配置管理工具 (5) 3.3配置管理服务器 (5) 4配置管理活动 (5) 4.1配置标识 (5) 4.1.1标识方法 (5) 4.1.2配置项标识及存储 (6) 4.1.3软件产品 (6) 4.1.4配置基线定义及存储 (6) 4.2配置库管理 (7) 4.2.1配置库结构 (7) 4.2.2权限层次 (7) 4.2.3注册用户 (7) 4.2.4备份机制 (7) 4.3配置控制 (8) 4.4配置状态统计 (8) 4.4.1配置控制委员会会议记录 (8) 4.4.2变更请求状态 (8) 4.4.3配置项状态 (8) 4.5基线审核 (9) 5配置管理审核 (9) 6配置管理代表主要活动时间表 (9) 7配置控制委员会主要活动时间表 (9)
1 概述 1.1 目的和范围 本节描述软件配置管理计划的目的和范围。 1.2 软件配置管理计划维护 本节将描述该计划在何种情况下需要被更新，以及如何更新。例如:此软件配置管理计划由{项目组}负责开发和维护。当出现新的问题或需要更改已存在问题时，需按《变更控制规程》进行更新，并由{项目组}负责完成。 1.3 参考资料 用实际引用的文档替代/添加在下面的文档后。例如： 1.软件配置管理过程 2 角色和职责 2.1 软件配置管理代表 2.2 配置控制委员会 在此处写配置控制委员会主席和成员的名字。 2.3 项目开发组