配置管理计划
iSoftStone IT Co., Ltd.
北京软通动力信息技术有限公司
All rights reserved
版权所有 侵权必究
文档修订记录
目 录
1. 引言... 4
1.1. 编写目的... 4
1.2. 适用范围... 4
1.3. 背景描述... 4
1.4. 缩略语... 4
1.5. 参考资料... 4
2. 命名规则... 5
2.1. 工程类文档... 5
2.2. 过程类文档... 5
2.3. Code代码... 5
2.4. Tools工具... 6
3. 配置库... 6
3.1. 配置库结构... 6
3.2. 文档... 6
4. 非配置项... 7
5. 基线计划... 8
6. 变更控制... 9
6.1. 基线更改... 9
6.2. 变更请求流程... 9
6.3. CCB会议:... 10
7. 版本控制和发布... 10
7.1. 版本控制... 10
7.2. 发布策略和计划... 10
8. 备份及归档... 10
8.1. 配置库的备份... 10
8.2. 项目文件夹备份... 10
8.3. 长假期间的备份... 10
8.4. 归档... 10
1. 引言
1.1. 编写目的
本计划描述了贯穿本项目软件生命周期的由SCM组织识别并定义的一系列的软件配置项的实践过程。
描述项目的配置管理计划
标识项目的配置项
定义项目配置库及其特征
定义项目组遵循的变更控制过程
1.2. 适用范围
本计划适用于《MDCC项目》的软件配置管理活动。
1.3. 背景描述
为保证软件的质量与进度,指导软件过程中出现的变更,提供一个规范的流程使得软件过程中的所有活动都有据可寻;并且通过识别配置项和将要建立基线的点,来确定SCM工作的需求范围和时间。在此背景之下,制定本软件配置管理计划。
1.4. 缩略语
1.5. 参考资料
《软件开发计划(ISS_MDCC _PPL)》
《MDCC项目开发工作任务书》
《MDCC项目设计规格》
2. 命名规则
每个配置项都必需被唯一地标识,这个唯一的标识被用于与其它配置项进行区分,跟踪和报告该配置项的状态。一般地,每个配置项被赋予一个标识符。
2.1. 工程类文档
对于工程类文档命名格式采用如下命名:
<产品名称>+<文档类型>
举例:MDCC 软件需求规格说明书
文档类型参见如下定义:
2.2. 过程类文档
对于资料命令管理系统项目采用的过程文档的命名方式:
<项目名称>-<文档助记符>.<扩展名>
举例:MDCC项目-PPL.doc
下面是一些重要过程文档的助记符。
2.3. Code代码
源代码各个文件的命名规范,请项目组讨论确定。
在项目中,整个代码作为一个配置项,使用“项目名称-CODE”作为配置项标识。
2.4. Tools工具
以工具本身的名称命名。
3. 配置库
配置库中存放所有配置项,由配置管理员负责维护。配置管理工具采用VSS6.0。配置库位置在\\server2003
3.1. 配置库结构
配置库结构列表
3.2. 文档
文档配置项列表
4. 非配置项
非配置项列表
5. 基线计划
在配置管理系统中,基线就是配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,而这个过程被称为“基线化”。每一个基线都是其下一步开发的基准。
每个基线都将接受配置管理的严格控制,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的内容形成下一个基线。
基线具有以下属性:
通过正式的评审过程建立。
基线存在于配置库中,基线的变更由CCB控制。
基线是进一步开发和修改的基准。
基线计划:
1)计划阶段文档批准、签发后基线化;
2)需求阶段:需求规格说明书初稿文档完成,放入项目文件夹中,同时提交评审。文档评审完成,输出评审报告,完成需求跟踪矩阵,并由部门经理批准签发后,建立SRS基线。
3)设计阶段:软件设计文档初稿完成后,存放在项目文件夹中,必须提交评审、输出评审报告、完成需求跟踪矩阵的更新,然后项目经理批准,此时基线化完成。
4)代码基线化:当代码完成时,在完成代码Review,项目经理批准以后,进行代码基线化。
5)测试阶段在测试报告被批准后代码重新基线化;
6)从需求阶段开始,各阶段文档基线化后,需求跟踪距阵同时也要基线化。
7)对已基线化配置项的更改将遵循基线变更操作,更改后的配置项获得批准签发后, 将形成新的基线。
6. 变更控制
6.1. 基线更改
配置项的基线通常只在下述事件发生时才进行更改:
评审发现的问题所导致的前面阶段的修改,如由SD评审导致的SRS更改
单元测试、系统测试检测到的错误引起的前面阶段的修改
内部/外部审计发现引起的修改
维护活动产生的问题报告引起的修改
内部或客户产生的需求变更
由于某种原因引起的计划文档的修改。
任何与已基线化的工作产品相关的变更必须以变更申请表的形式提出,由项目组成员填写。发生分配需求变更必须召开CCB会议。除分配需求外的其它变更,CCB会议是可选的,但需要由PM批准。
CR的状态包括“已提交”、“已批准”、“已拒绝”、“挂起”、“已验证”及“关闭”。
填写CR的项目组成员应是CR的提交人,提交人要确保提供了充分的信息。如可能,提交人应提供一个推荐的解决方案。
6.2. 变更请求流程
变更请求 ――> 填写CR ――> CCB会议讨论批准(分配需求变更)或PM批准 ――> CMO授权修改相关配置项 ――> 更改验证 ――> CMO批准验证后的配置项 ――> 关闭。
特别说明:
代码在编码完成后,代码review前,由配置项责任人提交后,受控。
在每个开发阶段后,为了维护文档与文档之间、文档与代码之间的一致性,对前各阶段的文档进行集中修改。
6.3. CCB会议:
CCB组长根据更改请求的情况事件驱动地召集CCB会议。CCB也可以批量处理更改请求或采用定期的方式进行处理。 根据修改的影响范围,CCB召开相应的评估会议,并邀请相关人员参加。
7. 版本控制和发布
7.1. 版本控制
单个配置项在每一次修改后都会发生变化,为了标识配置项在两次修改之间的不同,需要对配置项的版本进行标识。
文档评审以前放在单独的目录中,当文档在基线化后,保存在文件夹baselineXXX中,其中XXX为从1.0开始编号,号码最大的文件夹中的文档为最新的基线文档;
每次对基线化的文档进行修改都不在原来基线的文档上进行修改,而是在最新基线的文档的COPY上进行修改,修改后的文档通过评审,创建新的基线文档文件夹保存最新的基线文档。
7.2. 发布策略和计划
发布版本时,PM提交发布申请给部门经理批准,批准后CMO收集相关信息,整理项目的相关文档。
发布日期:时间点参考《MDCC项目计划》。
发布物列表:参考《MDCC项目计划》。
8. 备份及归档
8.1. 配置库的备份
配置库的备份由CMO进行,CMO不在,由备份CMO进行。
备份频率为每个星期的周一进行。编码阶段以后建议改为每周两次。
8.2. 项目文件夹备份
项目文件夹的备份由CMO进行,CMO不在,由备份CMO进行。
项目文件夹每个星期的周一进行。
8.3. 长假期间的备份
十一放假前进行完全备份。
8.4. 归档
项目结束时。
第二篇:软件配置管理计划书
<项目名称>
软件配置管理计划
作 者:
完成日期:
签 收 人:
签收日期:
修改情况记录:
目录
1 引言........................................................................................................................ 1
1.1 目的........................................................................................................................................................... 1
1.2 定义和缩写词.......................................................................................................................................... 1
1.3 参考资料................................................................................................................................................... 1
2 管理........................................................................................................................ 1
2.1 机构........................................................................................................................................................... 1
2.2 任务........................................................................................................................................................... 2
2.3 职责........................................................................................................................................................... 2
2.4 接口控制................................................................................................................................................... 2
2.5 实现........................................................................................................................................................... 2
2.6 适用的标准、条例和约定.................................................................................................................... 3
2.6.1 指明................................................................................................................................................... 3
2.6.2 内容................................................................................................................................................... 3
3 软件配置管理活动................................................................................................ 4
3.1 配置标识................................................................................................................................................... 4
3.1.1 基线................................................................................................................................................... 4
3.1.2 代码、文档...................................................................................................................................... 4
3.2 配置控制................................................................................................................................................... 5
3.3 配置状态的记录和报告......................................................................................................................... 5
3.4 配置的检查和评审................................................................................................................................. 6
4工具、技术和方法................................................................................................. 6
5 对供货单位的控制................................................................................................ 7
6 记录的收集、维护和保存.................................................................................... 7
7 附录:配置管理报表及其格式............................................................................ 7
7.1 软件问题报告单(SPR)..................................................................................................................... 7
7.1.1 配置管理人员填写内容................................................................................................................. 7
7.1.2 配置管理状态.................................................................................................................................. 8
7.1.3 配置管理申请人员填写的内容.................................................................................................... 8
7.2 软件修改报告单(SCR)..................................................................................................................... 8
1 引言
1.1 目的
本条必须指出特定的软件配置管理计划的具体目的。还必须描述该计划所针对的软件项目(及其所属的各个子项目)的名称和用途。
1.2 定义和缩写词
应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义,必要时,还要给出这些定义的英文单词及其缩写词。
1.3 参考资料
列出要用到的参考资料,如:
a.本项目的经核准的计划任务书或合同、上级机关的批文;
b. 属于本项目的其他已发表的文件;
c.本文件中各处引用的文件、资料,包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
2 管理
必须描述负责软件配置管理的机构、任务及其有关的接口控制。
2.1 机构
必须描述在各阶段中负责软件配置管理的机构。描述内容如下:
a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构;
b. 说明项目和子项目与其他有关项目之间的关系;
c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的相互关系。
2.2 任务
描述在软件生存周期各个阶段中的配置管理任务以及要进行的评审和检查工作,并指出各个阶段的阶段产品应存放在哪一类软件库中(软件开发库、软件受控库或软件产品库)。
2.3 职责
必须描述与软件配置管理有关的各类机构或成员的职责,并指出这些机构或成员相互之间的关系。
A. 指出负责各项软件配置管理任务(如配置标识、配置控制、配置状态记录以及配置的评审与检查)的机构的职责;
B.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系;
C.说明由本计划第2.2条指明的生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动;
D. 指出与项目开发有关的各个机构的代表的软件配置管理职责;
E.指出其他特殊职责,例如为满足软件配置管理要求所必要的批准要求。
2.4 接口控制
本条应该描述:
a.接口规格说明标识和文档控制的方法;
b. 对已交付的接口规格说明和文档进行修改的方法;
c.对要完成的软件配置管理活动进行跟踪的方法;
d. 记录和报告接口规格说明和文档控制状态的方法;
e.控制软件和支持它运行的硬件之间的接口的方法。
2.5 实现
应该规定实现软件配置管理计划的主要里程碑,例如:
a.建立配置控制组;
b. 确定各个配置基线;
c.建立接口控制协议;
d. 制订评审与检查软件配置管理计划和规程;
e.制订相关的软件开发、测试和支持工具的配置管理计划和规程。
2.6 适用的标准、条例和约定
2.6.1 指明
本条必须指明所适用的软件配置管理标准、条例和约定,并把它们作为本计划要实现的一部分;还必须说明这些标准、条例和约定要实现的程度。
2.6.2 内容
必须描述要在本项目中编写和实现的软件配置管理标准、条例和约定,内容可如下:
a.软件结构层次树中软件位置的标识方法;
b. 程序和模块的命名约定;
c.版本级别的命名约定;
d. 软件产品的标识方法;
e.规格说明、测试计划与测试规程、程序设计手册及其他文档的标识方法;
f. 媒体和文档管理的标识方法;
g. 文档交付过程;
h. 软件产品库中软件产品入库移交或交付的过程;
i. 问题报告、修改请求和修改次序的处理过程;
j. 配置控制组的结构和作用;
k. 软件产品交付给用户的验收规程;
l. 软件库的操作,包括准备、存储和更新模块的方法;
m. 软件配置管理活动的检查;
n. 问题报告、修改请求或修改次序的文档要求,指出配置修改的目的和影响;
o. 软件进入配置管理之前的测试级别;
p. 质量保证级别,例如,在进入配置管理之前,验证软件满足有关基线的程度。
3 软件配置管理活动
本章必须描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活动的需求。
3.1 配置标识
3.1.1 基线
本条必须详细说明软件项目的基线(即最初批准的配置标识),并把它们与本计划第2.2条描述的生存周期的特定阶段相联系。在软件生存周期中,主要有三种基线,它们是功能基线、指派基线和产品基线。对于每个基线,必须描述下列内容:
a.每个基线的项(包括应交付的文档和程序);
b. 与每个基线有关的评审与批准事项以及验收标准;
c.在建立基线的过程中用户和开发者的参与情况。
例如,在产品基线中,要定义的元素可以包括:
a.产品的名字和规则;
b. 产品标识编号;
c.对每一个新交付的版本,要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的修改要求以及对有关文档的修改要求;
d. 安装说明;
e.已知的缺陷和故障;
f. 软件媒体和媒体标识。
3.1.2 代码、文档
本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程。例如,对代码来说:
a.编译日期可以作为每个交付模块标识的一部分;
b. 在构造模块源代码的顺序行号时,应使它适合于对模块作进一步的修改。
3.2 配置控制
必须描述在本计划第2.2条描述的软件生存周期中各个阶段使用的修改批准权限的级别;
必须定义对已有配置的修改建议进行处理的方法,其中包括:
a. 详细说明在本计划第2.2条描述的软件生存周期各个阶段中提出修改建议的程序(可以用注上自然语言的流程图来表达);
b. 描述实现已批准的修改建议(包括源代码、目标代码和文档的修改)的方法;
c. 描述软件库控制的规程,其中包括存取控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程;
d. 如果有必要修补目标代码,则要描述其标识和控制的方法。
对于各个不同层次的配置控制组和其他修改管理机构,本条必须:
a.定义其作用,并规定其权限和职责;
b. 如果已组成机构,则指明该机构的领导人及其成员;
c.如果还没有组成机构,则说明怎样任命该机构的领导人、成员及代理人;
d. 说明开发者和用户与配置控制组的关系。
当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时,本条必须说明对其进行配置控制的方法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审,则本条必须描述这些机构的组成、它们与配置控制组的关系以及它们之间的相互关系;
本条必须说明与特殊产品(如非交付的软件、现存软件、用户提供的软件和内部支持软件)有关的配置控制规程。
3.3 配置状态的记录和报告
本条必须:
a.指明怎样收集、验证、存储、处理和报告配置项的状态信息;
b. 详细说明要定期提供的报告及其分发办法;
c.如果有动态查询,要指出所提供的动态查询的能力;
d. 如果要求记录用户说明的特殊状态时,要描述其实现手段。
例如,在配置状态记录和报告中,通常要描述的信息有:
a.规格说明的状态;
b. 修改建议的状态;
c.修改批准的报告;
d. 产品版本或其修改版的状态;
e.安装、更新或交付的实现报告;
f. 用户提供的产品(如操作系统)的状态;
g. 有关开发项目历史的报告。
3.4 配置的检查和评审
本条必须:
a.定义在软件配置管理计划的第2.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用;
b. 规定每次检查和评审所包含的配置项;
c.指出用于标识和解决在检查和评审期间所发现的问题的工作规程。
4工具、技术和方法
必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法,指明它们的目的,并在开发者所有权的范围内描述其用法。例如,可以包括用于下列任务的工具、技术和方法:
a.软件媒体和媒体文档的标识;
b. 把文档和媒体置于软件配置管理的控制之下,并把它正式地交付给用户。例如,要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述;如果用到数据库管理系统,则还要对该系统进行描述。又如,要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。
c.编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别(如项目负责人、配置控制小组、软件配置管理人员和用户)的管理报告的工具、技术和方法。
5 对供货单位的控制
供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程,从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法;还应解释用于确定供货单位的软件配置管理能力的方法以及监督他们遵循本软件配置管理计划需求的方法。
6 记录的收集、维护和保存
本章必须指明要保存的软件配置管理文档,指明用于汇总、保护和维护这些文档的方法和设施(其中包括要使用的后备设施),并指明要保存的期限。
7 附录:配置管理报表及其格式
7.1 软件问题报告单(SPR)
在系统的运行与维护阶段对软件产品的任何修改建议,或在软件开发的任一阶段中对前面各个阶段的阶段产品的任何修改建议,都应填入软件软件问题报告单。软件问题报告单位的格式见表1。
7.1.1 配置管理人员填写内容
表中A、B、C、P和状态等项目是由负责修改控制的配置管理人员填写的。表中其他各项即D、E、F、G、H、I、K、N和O各项是由发现问题的人或申请配置管理的人填写的,他可能还要填写J、L和M三项内容。前四项内容的意义如下:
A是由配置管理人员确定的登记号,一般按报告问题的先后顺序编号;
B是由配置管理人员登记问题报告的日期;
C是发现软件问题的日期;
P是填写若干补充信息和修改建议。
关于配置管理七种状态的含义在下面解释。
7.1.2 配置管理状态
状态一栏分成七种情况,现分别说明如下:1表示软件问题报告正被评审,已确定采取什么行动;2表示软件问题报告已由指定的开发人员去进行维护工作;3表示修改已经完成、测试好,正准备释放给主程序库;4表示主程序库已经更新,主程序库修改的重新测试尚未完成;5表示已经进行了复测,但发现问题仍然存在;6表示已经进行了复测,已经顺利完成所做的修改,软件问题报告单被关闭(维护已完成);7表示留待以后关闭,因问题不是可重产生的,或者是属于产品改善方面的,或者只具有很低的优先级等等。
7.1.3 配置管理申请人员填写的内容
在软件问题报告单中,属于配置管理申请人填写的各项内容的意义如下:
D、E两项是项目和子项目的名称,F是该子项目的代号,这应按配置标识的规定来命名代号;
阶段名和报告人的姓名、住址和电话等的含义是显而易见的;
G表示问题属于哪一方面的,是程序的问题还是例行程序的问题,是数据库的问题还是文档的问题,是功能性修改还是性能改进性修改问题,也可能是它们的某种组合;
H表示子例行程序/子系统,即要指出出现问题的子例行程序名字,如果不知是哪个子例行程序,可标出子系统名,总之,尽可能给出细节;
I是修订版本号,指出出现问题的子例行程序版本号;
J是媒体,表示包含有问题的子例行程序的主程序库存储媒体的标识符;
K是数据库,表示当发现问题时所使用的数据库标识符;
L是文档号,表示有错误的文档的编号;
M表示出现错误的主要测试实例的标识符;
N是硬件,表示发现问题时所使用的计算机系统的标识;
O是问题描述/影响,填写问题征候的详细描述,如果可能则写明实际问题所在,还要给出该问题对将来测试、界面软件和文档等的影响。
7.2 软件修改报告单(SCR)
对软件产品或其阶段产品的任何修改,都必须经过评审、批准后才能重新投入运行或作为阶段产品释放。这一过程用软件修改报告单(software change report)给以记录。软件修改报告单的格式表2。当收到了软件问题报告单之后,配置管理人员便填写软件修改报告单。软件修改报告单要指出修改类型、修改策略和配置状态,它是供配置控制小组进行审批的修改申请报告。表中各项内容的意义如下:
A是登记号,它是配置修改小组收到软件修改报告单时所作的编号;
B是配置管理人员登记软件修改报告单的日期;
C是已经准备好软件修改报告单、可以对它进行评审的时间;
D、E和F的意义与软件问题报告单中的D、E和F的意义相同;
G填写被处理的软件问题报告单的编号,如该编号中提出的问题只是部分解决,则在填写时要在该编号后附以字母P(Part表示部分之意);
H指出是程序修改、文档更新、数据库修改还是它们的组合,如果仅是指出用户文档的缺陷则在解释处作上记号;
I是修改的详细描述,如果是文档更新,则要列出文档更新通知单的编号;如果是数据库修改,则要列出数据库修改申请的标识号;
J是批准人,经批准人签字、批准后才能进行修改;
K是语句类型,程序修改中涉及到的语句类型包括:输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类(如数据传送、存放语句);
L是程序名,指被修改注程序、文档或数据库注名字。如果只要求软件修改报告单做解释性工作,则注重复软件问题报告单给出的名字;
M指当前注版本/修订本标识;
N指修改后的新版本/修订本标识;
O指数据库,如果申请数据库修改,这里给出数据库的标识符;
P是数据库修改申请号DBCR;
Q指文档,即如果要求文档修改,则在这里给出文档的名字;
R是文档更新通知单编号DUT;
S表示修改是否已经测试,指出已对修改做了哪些测试,如单元、子系统、组装、确认和运行测试等,并注明测试成功与否;
T指出在软件问题报告单中给出的问题描述是否准确,并回答是或否;
U是问题注释,准确地重新叙述要修改的问题;
V指明问题来自哪里,如系统设计规格说明书、软件需求规格说明书、概要设计说明书、详细设计说明书、数据库、源程序等;
W说明完成修改所需要的资源估计,即所需要的人月数和计算机终端时数;
X指出所要进行修改的类型,由执行修改的人最后填写。修改类型主要有适应性修改、改进性修改以及计算错误、逻辑错误、输入和输出错误、接口错误、数据库错误、文档错误以及配置错误等的修改;
Y是提出对软件问题进行修改的人员或单位;
Z是完成软件问题修改的人员或单位。
表1 软件问题报告单(SPR)
表2 软件修改报告单(SCR)