软件项目设计和开发控制管理规范.doc

软件项目设计和开发控制管理规范

XXXXXXXXX科技有限公司

目 录

1 引言 1
1.1 目的 1
1.2 定义和缩写词 1
1.3 参考资料 1
2 管理 1
2.1 机构 2
2.2 任务 2
2.3 职责 2
2.4 接口控制 3
2.5 实现 3
2.6 合用的标准、条例和约定 4
2.6.1 指明 4
2.6.2 内容 4
3 软件配置管理活动 5
3.1 配置标记 5
3.1.1 基线 5
3.1.2 代码、文档 6
3.2 配置控制 6
3.3 配置状态的记录和报告 8
3.4 配置的检查和评审 8
4工具、技术和方法 9
5 对供货单位的控制 9
6 记录的收集、维护和保存 10
7 附录：配置管理报表及其格式 10
7.1 软件问题报告单（SPR） 10
7.1.1 配置管理人员填写内容 10
7.1.2 配置管理状态 11
7.1.3 配置管理申请人员填写的内容 11
7.2 软件修改报告单（SCR） 12

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）
软件问题报告单
登记号
A
登记日期
B 年 月 日
发现日期
C 年 月 日
项目名
D
子项目
E
代号
F
阶段名
软件定义□
需求分析□
概要设计□
具体设计□
编码测试□
组装测试□
安装验收□
运营维护□
状态
1
2
3
4
5
6
7
报告人
姓名

电话

地址

问题：G 例行程序□ 程序□ 数据库□ 文档□ 改善□

子例行程序/子系统：H

修改版本号：I
媒体：J

数据库：K
文档：L

测试实例：M
硬件：N

问题描述/影响：O

附注及修改建议：P

表2 软件修改报告单（SCR）
软件修改报告单
登记号
A
登记日期
B 年 月 日
发现日期
C 年 月 日
项目名
D
子项目
E
代号
F
响应哪些SPR： G
修改类型
X
修改申请人
Y
修改人
Z
修改： H 程序□ 数据库□ 文档□ 解释□
修改描述： I

批准人： J
改动：

语句类型： K I/O □ 计算 □ 逻辑 □ 数据解决 □

程序名：L
老版本号：M
新版本号：N

数据库：O
DBCR：P
文档：Q
DUT：R

修改已测试否：S
单元
子系统
组装
确认
运营

成功否：S

SPR的问题叙述准确否？ T 是 □ 否 □

附注：U

问题来自：V 系统设计规格说明书□ 需求规格说明书□ 设计说明书□ 数据库□ 程序□
资源来自：W 人工数：（单位：人日） 计算机时间：（单位：小时）