计算机软件质量保证计划示例

blueski推荐 [2005-2-10]

出处：51CMM.COM采编

作者：不详

计划名 CADCSC软件质量保证计划

项目名 中国控制系统CAD工程化软件系统

项目委托单位

代 表 签 名 年 月 日

项目承办单位

代 表 签 名 年 月 日

1 引言

1.1 目的

本计划的目的在于对所开发的CADCSC软件规定各种必要的质量保证措施，以保证所交付的CADCSC软件能够满足项目委托书或合同中规定的各项需求，能够满足本项目总体组制定的且经领导小组批准的该软件系统需求规格说明书中规定的各项具体需求。

软件开发单位在开发CADCSC软件系统所属的各个子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经总体组批准。

1.2 定义

本计划用到的一些术语的定义按GB/T 11457和GB/T 12505。

1.3 参考资料

GB/T 11457 软件工程术语

GB 8566 计算机软件开发规范

GB 8567 计算机软件产品开发文件编制指南

GB/T 12504 计算机软件质量保证计划规范

GB/T 12505 计算机软件配置管理计划规范

CADCSC 软件配置管理计划

2 管理

2.1 机构

在本软件系统整个开发期间，必须成立软件质量保证小组负责质量保证工作。软件质量保证小组属总体组领导，由总体组代表、项目的软件工程小组代表、项目的专职质量保证人员、项目的专职配置管理人员以及各个子系统软件质量保证人员等方面的人员组成，由项目的软件工程小组代表任组长。各子系统的软件质量保证人员在业务上受软件质量保证小组领导，在行政上受各子系统负责人领导。

软件质量保证小组和软件质量保证人员必须检查和督促本计划的实施。各子系统的软件质量保证人员有权直接向软件质量保证小组报告子项目的软件质量状况。各子系统的软件质量保证人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划的所有要求。

2.2 任务

软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。因此，对新开发的或正在开发的各子系统，要按照GB 8566与本计划的各项规定进行各项评审工作。软件质量保证小组要派成员参加所有的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在CADCSC软件开发过程中，经总体组研究决定，要进行如下几

类评审与检查工作：

a. 阶段评审：在软件开发过程中，要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。根据总体组研究决定，在CADCSC软件及其所属各子系统的开发过程中，应该进行以下三次评审：第一次评审软件需求、概要设计、验证与确认方法；第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是功能检查、物理检查和综合检查。关于这些评审工作的详细内容见第5章。

阶段评审工作要组织专门的评审小组，原则上由项目总体小组成员或特邀专家担任评审组长，评审小组成员应该包括项目委托单位或用户的代表、质量保证人员、软件开发单位和上级主管部门的代表，其他参加人员视评审内容而定。

每一次评审工作都应填写评审总结报告（RSR）、评审问题记录（RPL）、评审成员签字表（RMT）与软件问题报告单（SPR）等四张表格。这四张阶段评审报表的具体格式应与附录C中的规定相一致。

b. 日常检查：在CADCSC软件的工程化生产过程中，各子系统应该填写项目进展报表，即软件进展报表表头、软件阶段进度表、软件阶段产品完成情况表、软件开发费用表等四张表格。项目总体组杨以通过项目进展季报表发现有关软件质量的问题。项目进展季报表的具体格式应与附录B中的规定相一致。

c. 软件验收：必须组织专门的验收小组对CADCSC软件系统及其所属各个子系统进行验收。验收工作应按照经项目委托单位“国家自然科学基金委员会信息科学部”与CADCSC总体组双方都认可的验收规程正式履行验收手续。验收内容应包括文档验收、程序验收、演示、验收测试与测试结果评审等几项工作。具体的验收规程另行制订。

2.3 职责

在CADCSC项目的软件质量保证小组中，其各方面人员的职责如下：

a. 组长全面负责有关软件质量保证的各项工作；

b. 总体组代表负责有关阶段评审、项目进展报表检查以及软件验收准备等三方面工作中的质量保证工作；

c. 项目的专职配置管理人员负责有关软件配置变动、软件媒体控制以及对供货单位的控制等三方面的质量保证活动；

d. 各子系统的软件质量保证人员负责测试复查和文档的规范化检查工作；

e. 用户代表负责反映用户的质量要求，并协助检查各类人员对软件质量保证计划的执行情况； f. 项目的专职质量保证人员协助组长开展各项软件质量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责汇总、维护和保存有关软件质量保证活动的各项记录。

3 文档

本章给出了在CADCSC软件开发过程各阶段需要编制的文档名称及其要求，并且规定了评审文质量的通用的度量准则。

3.1. 基本文档

为了确保软件的实现满足项目委托单位“国家自然科学基金委员会信息科学部”认可的需求规格说明书中规定的各项需求，CADCSC软件各开发单位至少应该编写以下八个方面内容的文档： a. 软件需求规格说明书（SRS）；

b. 软件设计说明书（SDD），对一些规模较大或复杂性较高的项目，应该把本文档分成概要设计说明书（PDD）与详细设计说明书（DDD）两个文档；

c. 软件测试计划（STP）；

d. 软件测试报告（STR）；

e. 用户手册（SUM）；

f. 源程序清单（SCL）；

g. 项目实施计划（PIP）；

h. 项目开发总结（PDS）。

3.2 其他文档

除了基本文档之外，对于尚在开发中的软件，还应该包括以下四个方面的文档：

a. 软件质量保证计划（SQAP）；

b. 软件配置管理计划（SCMP）；

c. 项目进展报表（PPR）；

d. 阶段评审报表（PRR）。

注：前面两个文档由项目软件工程小组制订，属于管理文档，各个子系统的项目承办单位与软件开发单位都应充分考虑执行计划中规定的条款。后面两类文档属于工作文档，就是本计划的2.2中提到的四张阶段评审表与四张项目进展季报表，各个子系统的项目承办单位或软件开发单位应该按照规定要求认真填写有关内容。

3.3 文档质量的度量准则

文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。验证和确认就是要检查各阶段文档的合适性。评审文档质量的度量准则有以下六条：

a. 完备性：所有承担软件开发任务的单位，都必须按照GB 8567的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的。

b. 正确性：在软件开发各个阶段所编写的文档的内容，必须真实地反映该阶段的工作且与该阶段的需求相一致。

c. 简明性：在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练，适合各种文档的特定读者。

d. 可追踪性： 在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪

性包括纵向可追踪性与横向可追踪性两个方面。前者是指在不同文档的相关内容之间相互检索的难易程度；后者是指确定同一文档某一内容在本文档中的涉及范围的难易程度。

e. 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。 f. 规范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。

4 标准、条例和约定

在CADCSC工程化软件系统的开发过程中，还必须遵守下列标准、条例和约定：

a. 《CADCSC软件配置管理计划》，CADCSC软件工程小组编，19xx年。

b. 《C语言编程格式约定》，CADCSC软件工程小组编，19xx年。

5 评审和检查

本章具体规定了应该进行的阶段评审、阶段评审的内容和评审时间要求。对新开发的或正在开发的各个子系统，都要按照GB 8566的规定认真进行定期的或阶段性的各项评审工作。就整个软件开发过程而言，至少要进行软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。如本计划第

2.2条所述，经总体组研究决定，在CADCSC软件及其所属各个子系统的开发过程中，把前七种评审分成三次进行。在每次评审之后，要对评审结果作出明确的管理决策。下面给出每次评审应该进行的工作。

5.1 第一次评审

第一次评审会对软件需求、概要设计以及验证与确认方法进行评审。

a. 软件需求评审（SRR）应确保在软件需求规格说明书中规定的各项需求的合理性。 b. 概要设计评审（PDR）应评价软件设计说明书中的软件概要设计的技术合适性。

c. 软件验证和确认评审（SV&VR）应评价软件验证和确认计划中确定的验证和确认方法的合适性与完整性。

5.2 第二次评审

第二次评审会要对详细设计、功能测试与演示进行评审，并对第一次评审结果进行复核。如果在软件开发过程中发现需要修改第一次评审结果，则应按照《CADCSC软件配置管理计划》的规定处理。

a. 详细设计评审（DDR）应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。

b. 编程格式评审应确保所有编码采用规定的工作语言，能在规定的运行环境中运行，满足《C语言编程格式约定》，并且符合GB 8566中提倡的编程风格。在满足这些要求之后，方可进行测试工作评审。

c. 测试工作评审应对所有的程序单元进行静态分析，检查其程序结构（即模块和函数的调用关系和调用序列）和变量使用是否正确。在通过静态分析后，再进行结构测试和功能测试。在结构测试中，所有程序单元结构测试的语句覆盖率Co必须等于100%，分支覆盖率C1必须大于或等于85%。要给出每个单元的输入和输出变量的变化范围。各个子系统只进行功能测试，不单独进行结构测试，因而要登录程序单元之间接口的变量值，力图使满足单元测试的C1和Co准则的那此测试用例在子系统功能测试时得到再现。测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测试工作时，不仅要运行变量的等价值，而且要运行变量的（合法的和非法的）边界值；不仅要运行开发单位给出的测试用例，而且要允许运行任务委托单位或用户、评审人员选定的采样用例。

5.3 第三次评审

第三次评审会要进行功能检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。

a. 功能检查（FA）应验证所开发的软件已经满足在软件需求规格说明书中规定的所有需求。 b. 物理检查（PA）应对软件进行物理检查，以验证程序和文档已经一致、并已做好了交付的准备。

c. 综合检查（CA）应验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

6 软件配置管理

对CADCSC工程化软件系统的各项配置进行及时、合理的管理，是确保软件质量的重要手段，也是确保该软件具有强大生命力的重要措施。有关CADCSC工程化软件的配置管理工作，可按CADCSC软件工程小组编写的《CADCSC软件配置管理计划》。在软件配置管理工作中，要特别注意规定对软件问题报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

7 工具、技术和方法

在CADCSC项目所属的各个子系统（其中包括有关的支持软件）的研制与开发过程中，都应该在各自的软件质量保证活动中合理地使用软件质量活动的支持工具、技术和方法。这些工具主要有下列三种：

a. C软件测试工具。它支持用C语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖率Co和分支覆盖率C1的值，并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。

b. 软件配置管理工具。它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的

涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

c. 文档辅助生成工具与图形编辑工具。它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述控制系统特性的一些其他图形，同时还可生成若干与CADCSC软件文档编制大纲相适应的文档模块板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，还有助于提高文档的编制质量。

8 媒体控制

为了保护计算机程序的物理媒体，以免非法存取、意外损坏或自然老化，CADCSC工程化软件系统的各个子系统（包括支持软件）都必须设立软件配置管理人员，并按照CADCSC软件工程小组制订的、且经CADCSC总体组批准的《CADCSC软件配置管理计划》妥善管理和存放各个子系统及其专用支持软件的媒体。

9 对供货单位的控制

CADCSC项目所属的各个子系统开发组，如果需要从软件销售单位购买、委托其他开发单位开发、从开发单位现存软件库中选用或从项目委托单位或用户的现有软件库中选用软部件时，则在选用前应向CADCSC总体组报告，然后由CADCSC总体组组织“软件选用评审小组”进行评审、测试与检查，只有当演示成功、测试合格后才能批准选用。如果只选用其中部分内容，则按待开发软件的处理过程办理，此时CADCSC总体组不作干预。

10 记录收集、维护和保存

在CADCSC项目及其所属的各个子系统的研制与开发期间，要进行各种软件质量保证活动，准确记录、及时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。在软件质量保证小组中，应有专人负责收集、汇总与保存有关软件质量保证活动的记录。要收集、汇总与保存的记录名字及其保存期限见表1。

表1 记录名称及其保存的期限

附录B 项目进展报表（参考件）

B1 项目进展报表（月报表或季报表）由一个项目进展报表表头（表B1）和另外三个表格（表B2、表B3、表B4）组成。在表B2“软件阶段进度表中”中，要填写各个阶段的开工日期与结束日期。其中计划进度是指在项目实施计划中确定的计划进度，因此可以由管理人员事先填好，而不必由开发人员填写。实际进度是指该项目实际的开工日期与结束日期，它将随着该项目的不断进展填写。其中调整进度是指项目组长发现实际进度与计划进度不符时提出的进度修改建议；但经项目管理人员研究后，可能对此修改建议作某些更改。此外，在相继的若干次报表中，项目组长提出的建议修改日期也可能是不相同的。在此我们规定，最终的调整进度由项目经理来确定。在表B3“软件阶段产品完成情况表”中，要填写各个文档的开始编写日期与完成日期。其中关于对计划进度、调整进度与实际进度的含义的解释与上相同。表B4是关于统计软件开发费用的表格。

表B1 项目进展报表表头

第二篇：GBT 12504计算机软件质量保证计划规范

GB/T 12505-90

中华人民共和国国家标准

计算机软件配置管理计划规范 GB/T 12505-90

Specification for computer software configuration management plan

1． 主题内容与适用范围

本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。

本规范适用于软件特别是重要软件的配置管理计划的制订工作。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。

2． 引用标准

GB/T 11457 软件工程术语

GB 8566 计算机软件开发规范

GB 8567 计算机软件产品开发文件编制指南

GB/T 12504 计算机软件质量保证计划规范

3． 术语

下面给出在本规范中用到的一些术语的定义，其它术语的定义按GB/T 11457。在引用时，特别要注意线（baseline）、配置控制(configuration)、配置控制组(configuration control board)、配置检查(configuration audit)、配置标识(configurationidentification)和配置状态记录(configuration status accounting)等术语的定义。

3．1项目委托单位 project entrust organization

项目委托单位是指为产品开发提供资金并通常也是（但有时也未必）确定产品需求的单位或个人。

3．2 项目承办单位 project undertaking organization

项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。

3．3 软件开发单位 software development organization

软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。

3．4 用户 user

用户是指实际全胜软件来完成某项计算、控制或数据处理等任务的单位或个人。

3．5 软件 software

软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。

3．6 重要软件 critical software

重要软件是指其故障会影响到人身安全、会导致重大经济损失或社会损失的软件。

3．7 软件生存周期 software life cycle

软件生存周期是指从软件系统设计对软件系统提出应用需求开始，经过开发，产生出一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护等三个阶段。其中软件开发阶段一般又分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。

3．8 软件开发库 software development library

软件开发库是指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。

3．9 软件受控库 software sontrolled library

软件受控库是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息一人工可读信息的库。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。

3．10 软件产品库 software product libary

软件产品库是指在软件生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件的库。

3．11 接口控制 interface control

接口控制是指描述有关由一个或多个部门提供的两个或两个以上的配置项接口的所有功能特性和物理特性的过程。在实现之前，要确保对这些功能特性和物理特性所建议的修改已经过评审和批准。

3．12 功能基线 functional baseline

功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。

3．13 指派基线 allocated baseline

指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。

3．14 产品基线 product baseline

产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。

3．15 软件配置 software configuration

软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项(configuration item)。

3．16 释放 release

释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也中做交付(delivery)。

4． 软件配置管理计划编制大纲

项目承办单位（或软件开发单位）中负责软件配置管理的机构或个人，必须制订一个包括下面各章内容的的软件配置管理计划（以下简称计划）。各章必须按所描述的顺序排列。如果某章中没有相应的内容，则在该章标题之后必须说明"本章无内容"的字样，并附上相应的理由。如果需要，可以在后面增加章条。如果某些材料已经出现在其它文件中，则在该计划中应引用那些文件。计划的封面必须标明计划名和该计划所属的项目名，并必须经项目委托单位和项目承办单位（或软件开发单位）的代表共同签字、批准。计划的目次是：

引言

管理

软件配置管理活动

工具、技术和方法

对供货单位的控制

记录的收集、维护和保存

下面给出软件配置管理计划的各个章条必须具有的内容。

4．1 引言

4．1．1 目的

本条必须指明特定的软件配置管理计划的具体目的，还必须描述该计划所针对的软件项目及其所属的各个子项目的名称和用途。

4．1．2 定义和缩写词

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

4．1．3 参考资料

本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。

4．2 管理

本章必须描述负责软件配置管理的机构、任务、职责及其有关的接口控制。

4．2．1 机构

本条必须描述在各阶段中负责软件配置管理的机构。描述的内容如下：

A． 描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构；

B． 说明项目和子项目与其他有关项目之间的关系；

C． 指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的相互关系。

4．2．2 任务

本条必须描述在软件生存周期各个阶段中的配置管理任务以及要进行评审的检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控库或软件产品库）。

4．2．3 职责

本条必须描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系。

A． 指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责；

B． 指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系；

C． 说明由本计划第4.2.2条指明的生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动；

D． 指出与项目开发有关的各个机构的代表的软件配置管理职责；

E． 指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。

4．2．4 接口控制

本条应该描述：

A． 接口规格说明标识和文档控制的方法；

B． 对已交付的接口规格说明和文档进行修改的方法；

C． 对要完成的软件配置管理活动进行跟踪的方法；

D． 记录和报告接口规格说明和文档控制状态的方法；

E． 控制软件和劫持它运行的硬件之间的接口的方法。

4．2．5 实现

本条应该规定实现软件配置管理计划的主要里程碑，例如：

A． 建立配置控制组；

B． 确定各个配置基线；

C． 建立接口控制协议；

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

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

4．2．6 适用的标准、条例和约定

4．2．6．1 本条必须指明所适用的软件配置管理标准、条例和约定，并把它们作为本计划要实现的一部分；还必须说明这些标准、条例和约定要实现的程度。

4．2．6．2 本条必须描述要在本项目中编写和实现的软件配置管理标准、条例和约定。

这些标准、条例和约定可以包括如下内容：

A． 软件结构层次树中软件位置的标识方法；

B． 程序和模块的命名约定；

C． 版本级别的命名约定；

D． 软件产品的标识约定；

E． 规格说明、测试计划与测试规程、程序设计手册及其他文档的标识方法； F． 媒体和文档管理的标识方法；

G． 文档交付过程；

H． 软件产品库中软件产品入库、移交或交付的过程；

I． 问题报告、修改请求和修改次序的处理过程；

J． 配置控制组的结构和作用；

K． 软件产品交付给用户的验收规程；

L． 软件库的操作，包括准备、存储和更新模块的方法；

M． 软件配置管理活动的检查；

N． 问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响； O． 软件进入配置管理之前的测试级别；

P． 质量保证级别，例如，在进入配置管理之前，验证软件满足有关基线的程序。

4．3 软件配置管理活动

本章必须描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。

4．3．1 配置标识

4．3．1．1 本条必须详细说明软件项目的基线（即最初批准的配置标识），并把它们与本计划第4.2.2条描述的生存周期的特定阶段相联系。在软件生存周期中，主要有三种基线，它们是功能基线、指派基线和产品基线。对于每个基线，必须描述下列内容：

A． 每个基线的项（包括应交付的文档和程序）；

B． 与每个基线有关的评审与批准事项以及验收标准；

C． 在建立基线的过程中用户和开发者可的参与情况。

例如，在产品基线中，要定义的元素可以包括：

A． 产品的名字和命名规则；

B． 产品标识编号；

C． 对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方

法、对支持软件的修改要求以及有关文档的修改要求；

D． 安装说明；

E． 已知的缺陷和故障；

F． 软件媒体和媒体标识。

4．3．1．2 本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程。例如，对代码来说：

A． 编译日期可以作为每个交付模块标识的一部分；

B． 在构造模块源代码的顺序行号时，应使它适合于对模块作进一步子修改。

4．3．2 配置控制

4．3．2．1 本条必须描述在本计划第4.2.2条描述的软件生存周期中各个阶段使用的修改批准权限的级别。

4．3．2．2 本条必须定义对已有配置的修改建议进行处理的方法，其中包括：

A． 详细说明书在本计划第4.2.2条描述的软件生存周期各个阶段中提出建议的程序（可以用注上自然语言的流程图来表达）；

B． 描述实现已批准的修改建议（包括源代码、目标代码和文档的修改）的方法；

C． 描述软件库控制的规程，其中包括存取控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程；

D． 如果有必要修补目标代码，则要描述其标识和控制的方法。

4．3．2．3 对于各个不同层次的配置控制组和其他修改管理机构，本条必须：

A． 定义其作用，并规定其权限和职责；

B． 如果已组成机构，则指明该机构的领导人员及其成员；

C． 如果还没有组成机构，则说明怎样任命该机构的领导人、成员及代理人；

D． 说明开发者和用户与配置控制组的关系。

4．3．2．4 当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，本条必须说明对其进行配置控制的方法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则本条必须描述这些机构的组成、它们与配置控制组的关系以及它们之间的相互关系。

4．3．2．5 本条必须说明与特殊产品（如非交付的软件、现存软件、用户提供的软件和内部支持软件）有关的配置控制规程。

4．3．3 配置状态的记录和报告

本条必须：

A． 指明怎样收集、验证、存储、处理和报告配置项的状态信息；

B． 详细说明要定期提供的报告及其分发办法；

C． 如果有动态查询，要指出所动态查询的能力；

D． 如果要求记录用户说明的特殊状态时，要描述其实现手段。

例如，在配置状态记录和报告中，通常要描述的信息有：

A． 规格说明的状态；

B． 修改建议的状态；

C． 修改批准的报告；

D． 产品版本或其修改版的状态；

E． 安装、更新或交付的实现报告；

F． 用户提供的产品（如操作系统）的状态；

G． 有关开发项目历史的报告。

4．3．4 配置的检查和评审

本条必须：

A． 定义在软件配置计划的第4.2.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用；

B． 规定每次检查和评审所包含的配置项；

C． 指出用于标识和解决在检查和评审期间所发现的问题的工作规程。

4．4 工具、技术和方法

本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具、技术和方法：

A． 软件媒体和媒体的标识。

B． 把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。

C． 编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术和方法。

4．5 对供货单位的控制

供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法；还应解释用于确定供货单位的软件配置管理能力的方法以及监督他们遵循本软件配置管理计划需求的方法。

4．6 记录的收集、维护和保存

本章必须指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施（其中包括要使用的后备设施），并指明要保存的期限。

GB/T 12505-90

附录A

软件配置管理计划示例

（参考件）

计划名 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 任务

在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第3.2条中详细规定。

2．3 职责

在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下：

A． 组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责；

B． 软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范；

C． 项目的专职配置管理人员检查在作配置更改时的质量保证措施；

D． 各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

E． 用户代表负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况；

F． 项目专职的配置管理人员协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。

2．4接口控制

对各类接口进行严格、合理的控制，是软件配置管理中最重要的任务之一。整个软件项目及其各子系统都必须对进行严格的控制。在工程化软件系统中，主要的接口有如下五类：

A． 用户界面：用户界面是指各子系统与设计人员、用户或维护人员之间的操作约定。同时还指实现这些操作约定的物理部件的功能与性能特性。

B． 系统内部接口：系统内部接口是指各子系统在集成为一个总的软件系统时的各种连接约定。

C． 标准程序接口：标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机系统已有的库程序）之间的调用约定。

D． 设备接口：设备接口是指各子系统与各种设备（包括终端和其他各种输入/输出设备）之间的连接约定。

E． 软件接口：软件接口是指各个子系统与宿主计算机上的系统软件以及与调用本软件的其它软件系统之间的连接约定。

以上五类接口是一个软件系统各项配置的重要组成部分。对接口修改进行合理的控制，是软件配置管理的重要任务之一。这五类接口都涉及到CADCSC软件系统的全局，因此，当要求对这五类接口中的任一类接口进行修改时，都必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第3.2条中规定（可参阅表1）。

表1 两类修改的审批程序

步骤 A类修改的审批程序 B类修改的审批程序

1 发现问题，填写软件问题报告单 发现问题，填写软件问题报告单

2 项目组长评审 项目组长评审

3 软件配置管理小组评审 子系统配置管理人员评审

4 项目总体组批准 子系统负责人批准

5 修改配置并填写软件修改报告单 修改配置并填写软件修改报告单

6 项目组长评审 项目组长评审

7 软件质量保证小组评审 子系统质量保证人员评审

8 总体组批准 项目的软件配置管理小组与子系统负责人共同批准并报项目总体组备索

2．5 软件配置管理计划的实现

在实现软件配置管理计划的过程中，要特别注意实现以下三个里程碑：

A． 建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组；

B． 建立各阶段的配置基线：随着CADCSC软件系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的《CADCSC软件需求规格说明书》的批准，建立起指派基线；随着CADCSC工程化软件系统的集成与系统测试的完成，建立起产品基线。

C． 建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。

2．6 适用的标准、条例和约定

除应奠定本计划第1.3条中指出的参考资料以及本计划中的其他章条所作的各项规定外，还应该遵守如下标准、条例和约定：

A． 软件开发库、软件受控库与软件产品库的操作规程与管理规程；

B． 系统、子系统、模块和程序单元的命名约定；

C． 文档和测试用例的命名和管理规程。

这引起命名约定、操作规程与管理规程应由CADCSC项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第3.2条中规定。

3 软件配置管理活动

3．1 配置标识

3．1．1 文档

所有为本项目编制的文档，都要符合GB 8567中的规定。CADCSC软件系统及其所属的各个子系统所编写的文档数目，可根据GB 8567的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。

3．1．2 程序

所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。

3．1．3 各类基线

所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。

3．2 配置控制

软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下：

A． 修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为A类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为B类修改），都必须通过本项目各个子系统的配

置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。

B． 修改审批程序：上述两类修改的审批程序如表1。

C． 修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的有效手段。

3．3 配置状态审计

利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。

注：本计划在此处应给出软件问题报告单与软件修改报告单的具体格式，并作出必要的说明。鉴于本计划拟采用附录B（参考件）中建议的格式，因而这两个报告单的格式及其说明可参阅附录B。

3．4 配置的检查和评审

项目软件配置管理小组要对所有由第三方提供的软件进行物理配置检查；对本项目及其各个子系统的每一个新的释放进行功能配置检查和物理配置检查；对宿主计算机系统所提供的软件和硬件配置要每隔半年检查一次；在软件验收前要对宿主计算机系统、各个子系统及其专用支持软件的配置进行综合检查。

在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要的评审和检查。应该进行评审与检查的内容与次数，由CADCSC软件质量计划规定。配置修改的审批程序按本计划第3.2条的规定处理（见表1）。 4 工具、技术和方法

在软件的开发过程中，与软件配置有关的工具有软件测试工具、软件配置管理工具、文档辅助生成工具与图形编辑工具等到三种。

A． C软件测试工具：它支持用C语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖C0和分支覆盖率C1的值、并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。

B． 软件配置管理工具：它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

C． 文档辅助生成工具与图形编辑工具：它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与CADCSC软件文档编制大纲适应的文档模板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，这有助于提高文档的编制质量。

有关这些工具的详细需求可参阅这三项工具的需求规格说明书中的规定。 5 对供货单位的控制

CADCSC项目所属的各个子系统开发组如果需要从软件销售单位购买、委托其他开发单位、从开发单位现存软件库选用或从项目委托单位或用户的现有连锁反应加中选用软件时，则在选用前应向CADCSC总体组报告，然后由CADCSC总体组组织"软件选用评审小组"进行评审、测试与检查，只有当演示成功、测试合格后才

能批准使用。如果只选用其中部分内容，则按等待开发软件的处理过程办理，此时CADCSC总体组不予预。在进行上述工作过程中，软件配置管理人员要进行下列工作：

A． 项目的软件配置管理小组要参加对上述四类由间接供货单位提供的软件的物理配置检查； 这些软件的功能配置检查由项目的软件质量保证小组负责。

B． 在这些软件送入软件受控库与其他软件成分进行组装之前，软件配置管理小组要对其存放媒体和配置标识进行认真的审查。

C． 由软件质量保证小组审查选用的上述四类软件，必须经过正式的验收手续，并由项目技术管理小组负责人批准，然后置于软件配置管理小组的控制之下。 6 记录的惧维护和保存

在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。

A． 基础上组装系统、各个子系统、专用支持软件及选用软件的功能基线、指派基线与产品基线要送入软盘或磁带，至少必须一式两份且存放在两个不同的地点。这些记录应该每6个月拷贝一次，以免意外损伤与自然老化。

B． 上述这些软件的文档也应送入软盘或磁带，至少必须工式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。磁媒体应该每隔6个月拷贝一次，以免意外损伤与自然老化。

C． 软件产品的源程序、测试数据、测试报告及其他有关文档，除了按A、B规定妥善存放外，要在项目结束后再保存2年，或在条件成熟时转交给这些软件产品的生产系统。

注：具体保存年限要根据项目的性质与开发单位的任务来确定，此处仅作为一个示例。

D． 上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。

E． 鉴于处理版权或清理财务的需要，本软件系统的各项配置可能要求存放5~7年，但由于我国对这些问题尚无明确的规定，因此，有关本条款的具体规定待将来有必要与可能时再作修改与补充。

附录B

配置管理报表及其格式

（参考件）

B1 软件问题报告单（SPR）

在系统的运行与维护阶段对软件产品的任何修改建议，或在软件开发的任一阶段中对前面各个阶段的阶段产品的任何修改建议，都应填入软件问题报告单。软件问题报告单的格式见表B1。

B1．1 配置管理人员填写内容

表中A、B、C、P和状态等项目是由负责修改控制的配置管理人员填写的。表中其他各项即D、E、F、G、H、I、J、K、N和O各项是由发现问题的人或申请配置

管理的人填写的，他可能还要填写J、L和M三项内容。前四项内容的意义如下： A是由配置管理人员确定的登记号，一般按报告问题的先后顺序编号； B是由配置管理人员登记问题报告的日期；

C是发现软件问题的日期；

P是填写若干补充信息和修改建议。

关于配置管理七种状态的含义在下面解释。

B1．2 配置管理状态

状态一栏分成七种情况，现分别说明如下：1表示软件问题报告正被评审，已确定采取什么行动；2表示软件问题报告已由指定的开发人员去进行维护工作；3表示修改已经完成、测试好，正准备释放给主程序库；4表示主程序库已更新，主程序库修改的重新测试尚未完成；5表示已经进行了复测，但发现问题仍然存在；6表示已经进行了复测，已经顺利完成所做的修改，软件问题报告单被关闭（维护已完成）；7表示留待以后关闭，因问题不是可重产生的，或者是属于产品改善方面的，或者只具有很低的优先级等等。

B1．3配置管理申请人员填写的内容

在软件问题报告单中，属于配置管理申请人填写的各项内容的意义如下：

D、E两项是项目和子项目的名称，F是该子项目的代号，这应按配置标识的规定来命名代号；

阶段名和报告人的姓名、住址和电话等的含义是显而易见的；

G表示问题属于哪一方面，是程序的问题还是例行程序的问题，是数据库的问题还是文档的问题，是功能适应性修改还是性能改进性修改问题，也可能是它们的某种组合；

H表示子例行程序/子系统，即要指出出现问题的子例行程序名字，如果不知是哪个了例行程序，可标出子系统名，总之，尽可能给出细节；

I是修订版本号，指出出现问题的子例和程序版本号；

J是媒体，表示包含有问题的子例行程序的主程序库存储媒体的标识符； K是数据库，表示当发现问题时所使用的数据库标识符；

L是文档号，表示有错误的文档的编号；

M表示出现错误的主要测试实例的标识符；

N是硬件，表示发现问题时所使用的计算机系统的标识；

O是问题描述/影响，填写问题征候的详细描述，如果可能则写明实际问题所在，还要给出该问题对将来测试、界面软件和文档等的影响。

B2 软件修改报告单（SCR）

对软件产品或其阶段产品的任何修改，都必须经过评审、批准后才能重新投入运行或作为阶段产品释放。这一过程用软件修改报告单（software change report）给以记录。软件修改报告单的格式见表B2。当收到了软件问题报告单之后，配置管理人员便填写软件修改报告单。软件修改报告单要指出修改类型、修改策略和配置管理状态，它是供配置控制小组进行审批的修改申请报告。表中各项内容的意义如下：

A是登记号，它是配置修改小组收到软件修改报告单时所作的编号； B是配置管理人员登记软件修改报告单的日期；

C是已经准备好软件修改报告单、可以对它进行评审的时间；

D、E和F的意义与软件修改报告单的编号，如该编号中提出的问题只是部分解决，则在填写时要在该编号后附以字母P（PAET表示部分之意）；

H指出是程序修改、文档更新、数据库修改还是它们的组合，如果仅是指出用户文档的缺陷则在解释处作上记号；

I是修改的详细描述，如果是文档更新，则要列出文档更新通知单的编号；如果是数据库修改，则要列出数据库修改申请的标识号；

J是批准人，经批准人签字、批准后才能进行修改；

K是语句类型，程序修改中涉及到的语句类型包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存放语句）；

L是程序名，批被修改的程序、文档或数据库的名字。如果只要求软件修改报告单做解释性工作，则是重复软件问题报告单中给出的名字；

M指当前的版本/修订标识；

N指修改后的新版本/修订本标识；

O指数据库，如果申请数据库修改，这里给出数据库的标识符；

P是数据库修改申请号DBCR；

Q指文档，即如果要求文档修改，这里给出文档的名字；

R是文档更新通知单编号DUT；

S表示修改是否已经测试，指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否；

T指出在软件问题报告单中给出问题描述是否准确，并回答是或否； U是问题注释，准确地重新叙述要修改的问题；

表B1 软件问题报告单（SPR）

登记号 （A）

软件问题报告单 登记日期 （B） 年 月 日

发现日期 （C） 年 月 日

项目名 （D） 子项目名 （E） 代号 （F）

软件 需求 概要 详细 编码 组装 安装 运行 1 2 3 4 5 6 7

阶段名 定义 分析 设计 设计 测试 测试 验收 维护 状态

□ □ □ □ □ □ □ □ □

姓名 电话

报告人 地址

问题（G） 例行程序□ 程序□ 数据库□ 文档□ 改进□

子例行程序/子系统：（H） 修改版本号：（I） 媒体：（J）

数据库：（K） 文档：（L）

测试实例：（M） 硬件：（N）

问题描述/影响：（O）

附注及修改建议：（P）

表B2 软件个性报告单（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）人工数：（单位：人日） 计算机时间：（单位：小时）

V指明问题来自哪里，如系统设计规格说明书、软件需求规格说明书、概要设计说明、详细设计说明书、数据库、源程序等；

W说明完成修改所需要的资源估计，即所需要的人月数和计算机终端时数； X 指出所要进行修改的类型，由执行修改的人最后填写。修改类型主要有适应性修改、改进性修改以及计算错误、逻辑错误、输入和输出错误、接口错误、数据库错误、文档错误以及配置错误等的修改；

Y是提出对软件问题进行修改的人员或单位；

Z是完成软件问题修改的人员或单位。

附加说明：

本标准由中华人民共和国机械电子工业部提出。

本标准由北京航空天大学计算机软件工程研究所负责起草。

本标准主要起草人张子让、周伯生、黄征、张社英。