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

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

《软件项目设计和开发控制管理规范.doc》由会员分享，可在线阅读，更多相关《软件项目设计和开发控制管理规范.doc（19页珍藏版）》请在冰点文库上搜索。

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

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

ii

1引言

1.1目的

本条必须指出特定的软件配置管理计划的具体目的。

还必须描述该计划所针对的软件项目（及其所属的各个子项目）的名称和用途。

1.2定义和缩写词

应该列出计划正文中需要解释的而在GB/T11457中尚未包含的术语的定义，必要时，还要给出这些定义的英文单词及其缩写词。

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）

对软件产品或其阶段产品的任何修改，都必须经过评审、批准后才能重新投入运行或作为阶段产品释放。

这一过程用软件修改报告单（softwarechangereport）给以记录。

软件修改报告单的格式表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

改动：

语句类型：

KI/O□计算□逻辑□数据处理□

程序名：

L

老版本号：

M

新版本号：

N

数据库：

O

DBCR：

P

文档：

Q

DUT：

R

修改已测试否：

S

单元

子系统

组装

确认

运行

成功否：

S

SPR的问题叙述准确否？

T是□否□

附注：

U

问题来自：

V系统设计规格说明书□需求规格说明书□设计说明书□数据库□程序□

资源来自：

W人工数：

（单位：

人日）计算机时间：

（单位：

小时）

16