SJ 20778-2000 软件开发与文档编制-检测标准-检测项目-北检院

标准中涉及的相关检测项目

《SJ 20778-2000 软件开发与文档编制》标准主要涉及软件开发过程中的文档编制要求。虽然具体的检测项目、检测方法和涉及产品在公开文本中可能较难详细获取，但一般标准会包括以下几个方面的要求：

检测项目：

软件需求分析文档的完整性、正确性和一致性。
设计文档的详细程度和准确性，包括总体设计和详细设计。
编码规范的遵守情况，包括代码结构、注释等。
测试计划和测试报告的充分性和正确性。
用户手册和维护手册的清晰性和可理解性。
变更和版本控制文档的记录完整性。

检测方法：

文档审查：通过专家或同行评审来检查文档的质量和完整性。
一致性检查：确保文档之间信息的一致性和逻辑性。
规范性检查：对照编制标准和规范进行逐项审核。
测试验证：通过软件测试验证需求满足情况和文档匹配性。

涉及产品：

软件需求规格说明书
软件设计说明书
源代码及注释
测试计划及测试报告
用户手册
维护手册
版本控制文档

如果需要具体条款和详细信息，建议查阅该标准的完整文档。

SJ 20778-2000 软件开发与文档编制的基本信息

标准名：软件开发与文档编制

标准号：SJ 20778-2000

标准类别：电子行业标准(SJ)

发布日期：2000-10-20

实施日期：2000-10-20

标准状态：现行

SJ 20778-2000 软件开发与文档编制的简介

SJ20778-2000软件开发与文档编制SJ20778-2000

SJ 20778-2000 软件开发与文档编制的部分内容

中华人民共和国电子行业军用标准FL0137

SJ 20778--2000

软件开发与文档编制

Software development and documentation连标

程序名称

程序地址

D:牛碰碰

D谷歌翻译（程序控

已．状态

准备打开192.168.5.157:43244

1范围

2引用文件

3定义

4　一般要求

5详细要求

6文档编制详细要求

6.1软件开发计划（SDP）

6.2软件测试计划（STP）

软件安装计划（SIP）

软件移交计划（STrP）

6.5运行概念说明（OCD）

系统/子系统需求规格说明（SSS）6.6

接口需求规格说明（IRS）

6.8系统/子系统设计说明（SSDD）6.9接口设计说明（IDD）

6.10软件需求规格说明（SRS）

6.11软件设计说明（SDD）

6.12．数据库设计说明（DBDD）6.13软件测试说明（STD）

6.14软件测试报告（STR）

6.15软件产品规格说明（SRS）

6.16软件版本说明（SVD）

6.17软件用户手册（SUM）

6.18软件输入/输出手册（SIOM）6.19软件中心操作员手册（SCOM）6.20计算机操作手册（COM）

6.21计算机编程手册（CPM）

6.22固件保障手册（FSM）

附录A缩略词语和术语表（补充件）次

附录B本标准对采用可重用软件产品的解释（补充件）附录C关于问题报告的种类及优先权的划分（补充件）附录D软件产品评价（补充件）

附录E可供选用的联合管理评审（参考件）附录F可供选用的管理指标（参考件）附录G程序策略、裁剪和阶段规划指南（参考件）附录H订购可交付产品的指南（参考件）2

附录I从DOD-STD-2167A和DOD-STD-7953A转换到本标准的指南（参考件）…1499

中华人民共和国电子行业军用标准软件开发与文档编制

Software development and documentation1范围

1.1目的

本标准的目的是为军用软件开发和文档编制制订统一的要求。1.2应用范围

本标准将用于以下四个方面：

1.2.1组织和协议

SJ20778—2000

本标准可用于承制方、从事软件开发的分承制方或政府内部机构。为了统一起见术语“需方”表示对这种技术工作提出要求的组织，“开发方”表示执行这种技术工作的组织，“合同”表示这些组织之间达成的协议，“任务书”（SOW）是指由开发方完成的任务清单，“合同资料需求清单（CDRL）”是指可交付使用的软件产品清单，“分承制方”表示由开发方委托其完成要求的部分任务的组织。“软件开发”是一统称，它包括新软件开发、修改、重用、再工程、维护和其他所有产生软件产品的活动。1.2.2合同具体的应用

本标准通过在合同中引用它而起作用。本标准可用于合同所覆盖的每个软件产品和每种类型的软件（不考患其储存的媒体），要求适用到合同所规定的程度。软件类型的例子包括可交付的与非交付的，为满足用户需要而设计的软件与在工程及测试环境中用到的软件。需方应说明软件类型，并对每一类软件采用本标准或适当地裁剪本标准。如果在不作这种选择性应用说明的情况下而引用本标准，则将被认为对所有可交付软件完整地采用本标准。关于软件开发环境需求本标准也适用于可交付软件开发环境。虽然本标准是针对计算机软件配置项（CSCI）编制的，但也可用于未被指明为CSCI的软件，只要对术语“CSCI\作适当解释。装在固件中的软件也遵守上述所有规定。本标准不适用于固件中的硬件成分。

1.2.3裁剪

引用本标准及其资料项目说明的各类软件，对本标准可以进行裁剪。虽然裁剪是需方的责任，但预期的或已经选定的开发方可以提出裁剪建议。对本标准的裁剪指南可在附录G和H中找到。1.2.4所选用术语的解释

下列术语用在本标准时有专门的解释。1中华人民共和国信奥产业部2000-10-20发布AAA_tA n h

1.2.4.1系统

SJ 20778--2000

a．本标准中的“系统”可以指：（1）一个硬件一软件系统（例如一个雷达系统），对这种系统，本标准只适用其软件部分；（2）个软件系统（例如一个工资计算系统），对这类系统，本标准适用于其整个开发工作：b．若系统由若干个子系统组成，则本标准中涉及系统的全部要求也均适用于这些子系统。如果一个合同是以系统和子系统的替代物为依据，如复合项目，那么本标准中涉及系统的要求及其说明也适用于这些替代物及其说明。1.2.4.2系统开发中的参与

在涉及系统级活动的章条中，“参与”一词解释如下：如果本标准所覆盖的软件是一个硬件一软件系统的一部分，而本标准只适用于其软件部分，那么“参与”指的是“参加”，如同在软件开发计划中描述的那样。如果该软件（可能和它的计算机一起）构成个系统，那么“参与”指的是“负责”。1.2.4.3开发、定义等

通常本标准对“开发”、“定义”、“建立”或“标识”等的要求都解释成包括新开发，修改、重用、再工程、维护或能产生软件产品的任何其他活动或活动组合。1.2.4.4记录

通常本标准对“记录”的要求被解释为“用一种能被检索或查阅的方式记下来”，其结果可以采用多种形式，包括，但不限于，手写记录、硬拷贝或电子文档，以及利用计算机辅助软件工程（CASE）工具和项目管理工具记录的资料。t.3优先次序

当本标准的要求和其他可采用的标准化文档出现矛盾时，由需方负责解决此矛盾。2引用文件

GB/T11457-1995软件工程术语

3定义

本标准采用下列定义。除了下列定义外，其他术语定义见GB/T11457。注：除了这里提供的定义外，第1章给出了本标准关于下列术语的特定的用法：需方、合同、合同资料需求清单、定义、开发和开发方、建立、标识、参与、记录、软件开发、任务书、分承制方、子系统和系统。

3.1验收acceptance

需方授权代表的一项活动，通过该活动，需方接受履行合同的部分或全部的软件产品的所有权。

3.2需方acquirer

为自已或为另一个组织采购软件产品的组织。3.3批准approval

需方的授权代表对开发方的项目计划、设计或其他方面表示满意并可能作为下阶段工作基础而签署的书面文件。这种批准并不能解除开发方对满足合同要求的责任。3.4体系结构architecture

SJ 20778-2000

一个系统或CSCI的组织结构，标明它的组成，这些组成的接口和它们之间的操作概念。

3.5相关开发方associatedeveloper一个既不是主承制方也不是开发方的分承制方的组织，但它在同一个或相关的系统或项目中承担开发工作。

3. 6 行为设计 behavioral design从用户观点出发，对整个系统或CSCI的行为进行的设计，它只考虑满足用户需求而不考虑系统或CSCI的内部实现。这种设计与体系结构设计不同，后者要标明系统或CSCI的内部部件，并有这些部件的详细设计。3.7开发阶段build

（1）软件的个版本，它满足完整的软件所要满足的全部需求的一个特定的子集，（2）开发满足特定需求子集的软件版本所经历的时间。注：术语“开发阶段”和“版本”之间的关系依赖于开发方；例如，可以通过几个版本来实现一个开发阶段，一个开发阶段也可以发行几个并行的版本（如在不同的地点），或者将它们用作为同义词。

3.8计算机数据库computerdatabase见数据库。

3.9计算机硬件computerhardware能接收和存储计算机数据的，对计算机数据执行一系列系统性的操作的，或能产生控制输出的设备。这类设备能实现基本的解释、计算、通信、控制或其他逻辑功能。3.10计算机程序computerprogram能使计算机硬件实现计算或控制功能的计算机指令和数据定义的集合。3.11计算机软件computer software见软件。

3.12计算机软件配置项computer software configuration item（CSCI）满足最终使用功能的软件集合，而且它由需方指定进行单独的配置管理。CSCI应从下列诸因素中进行折衷选择：软件功能、规模、宿主机或目标计算机、开发方、支持概念、重用计划、关键性、接口考虑、需要单独编写文档和控制以及其他因素。3.13配置项configurationitem

能满足最终使用功能的硬件集合、软件集合或者软、硬件两者的集合，且由需方指定进行单独的配置管理。

3.14数据库database

以一种能被用户或计算机程序通过一个数据库管理系统进行访问的方式，存储在一个或多个计算机文件中的相关数据的集合。3.15数据库管理系统databasemanagementsystem是一整套计算机程序，它提供为建立、修改、使用和完整性维护一个数据库所需的功能。

SJ 20778--2000

3.16可交付的软件产品deliverablesoftwareproduct合同要求交付给需方或其他指定的接受方的软件产品。3.17设计design

开发方为响应一定的需求而对~个系统或CSCI 选取的一些性能/规格。这些特性中有些是与需求相匹配的；有一些是需求的精细化。如为了响应显示错误信息这一需求而定义所有的错误信息；有一些则是有关的实现，如为满足需求，决定选用哪些软件单元和逻辑。

3.18开发方developer

开发软件产品的组织（“开发”包括新的软件开发、修改、重用、再工程、维护或产生软件产品的任何其他活动）。开发方可以是一个承制方或者政府机构。3.19文档/文档编制document/documentation能供人或机器阅读的，一般具有永久性的一套资料（不管它们记录在什么媒体上）。3.20评价evaluation

确定一个项目或一项活动是否满足指定准则的过程。3.21固件firmware

硬件设备和以只读软件的形式驻留在硬件设备上的计算机指令和/或计算机数据的组合。

3.22硬件配置项hardwareconfigurationitem（HWCI）满足最终使用功能并由需方指定进行单独配置管理的一套硬件。3.23独立验证与确认independentverificationandvalidation（IV&V）由一个机构对软件产品和活动所作的系统的评审；这个机构不负责该产品的开发或被评审的活动。IV&V不在本标准的范围内。3.24接口interface

在软件开发中，两个或多个实体（如CSCI-CSCI，CSCI-HWCI，CSCI-用户，或软件单元软件单元）之间的关系。这些实体依据这种关系共享、提供或交换数据。接口不是CSCI、软件单元或其他的系统部件；接口是这些实体间的一种关系，而不是接口的实现。

3.25联合评审jointreview

由需方和开发方双方的代表参加的对项目状态、软件产品和/或项目中的问题进行检查和讨论的活动或会议。

3.26非交付的软件产品Non-deliverablesoftwareproduc不是合同中要求交付给需方或其他指定接受方的软件产品。3. 27 过程 process

为实现某个既定目的而进行的一组有组织的活动，例如，软件开发过程。3.28合格性测试qualificationtesting为了向需方表明一个CSCI或系统满足其指定的需求而进行的测试。3.29再工程reengineering

为了以一种渐的形式重组一个现有的系终而对甘进行检查和改造的过程。重T程可ome

SJ20778-2000

包括逆向工程（分析一个系统并产生更高一级的抽象来表示它，如从代码到设计），重构（在同一个抽象级上把系统从一种表示形式转换到另一种表示形式），重编文档（分析个系统并产生用户文档或支持文档），正向.L程（从现有的系统的软件产品结合新的需求，产生新系统），重定目标系统（对系统进行转换以便将其安装到不同的目标系统上）和翻译（将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换成另一种版本）。

3.30需求requirement

（1）为了使需方能够接受一个系统或CSCI所必需具备的特性。（2）本标准或合同中规定的必须遵守的陈述。

3.31可重用的软件产品reusablesoftware product是种用于开发的软件产品，但还具有别的用途，或者专门为了用于多个项目而开发的软件产品，或者在一个项目中有多种作用的软件产品。例子包括（但不限于）上市的商用软件产品，需方已装备的软件产品，重用库中的软件产品和开发方现存的软件产品。每一次使用可以包括这些软件产品的全部或部分，也可以涉及到它的修改部分。这个术语可以应用于任何软件产品（例如需求，体系结构等）而不只限于软件本身。3.32软件software

计算机程序和计算机数据库。

注：虽然有些软件的定义中包括文档，本标准把这个定义只限于计算机程序和计算机数据库。3.33．软件开发softwaredevelopment产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件产品的其他活动。3.34软作开发文件：softwaredevelopmentfile（SDF）与特定软件实体开发有关的资料库。其内容一般包括（直接的或引用的）有关需求分析、设计和实现的考虑、原理和约束条件：开发方内部的测试资料；进度和状态资料。3.35软件开发库softwaredevelopmentlibrary（SDL）一套受控的软件、文档、其他中间的和最终的软件产品，以及相关的用以促进软件的有序开发和后续支持的工具和方法。3.36软件开发过程softwaredevelopmentprocess为了把用户的需求转换成软件产品而进行的一系列有组织的活动。3.37软件.工程 software engineering一般情况下，它是软件开发的同义词。在本标准中，软件.I程是软件开发全部活动（合格性测试除外）的一个子集。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命名。

3.38软件E程环境software engineering environment实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括（但不限于）计算机辅助软件工程（CASE）的工具、编译程序、汇编程序、连接程序、装载程序、操作系统、排错程序、仿真程序、模拟程序、文档工具利数据库管理系统。9

SJ20778—2000

为了满足一个合同而建立、修改或组合成的软件或相应的资料。例子包括计划、需求、设计、代码、数据库、测试资料和手册。3.40软件质量softwarequality

软件满足所规定的需求的能力。3.41软件支持softwaresupport

为保证软件安装后能继续按既定目标运行而且在系统的运行中能起到既定的作用而发生的一系列活动。软件支持包括软件维护、用户支持和有关的活动。3.42软件系统software system

只由软件组成的系统，有时可能还包括该软件赖以运行的计算机设备。3.43软件测试环境softwaretestenvironment为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括（但不限于）仿真程序、代码分析程序、测试用例产生程序和路径分析程序，还可能包括在软件工程环境下用到的要素。3.44软件移交software transition能使软件开发的责任从一个组织转交给另一个组织的一系列活动。一般说，前一个组织是实现初期软件开发，而后一个组织是进行软件支持。3.45软件单元softwareunit

CSCI设计中的个基本单位；例如，CSCI的一个主要构成部分，这种构成部分的一个组成部分、一个类、对象、模块、函数、子程序或者数据库。软件单元可以出现在层次机构的不同层上并可以由其他的软件单元组成。设计中的软件单元与实现它们的代码和数据实体（子程序、过程、数据库、数据文件等）之间有也可以没有一一对应的关系，或包含这些实体的计算机文件之间的关系也是这样。3.46（软件的）支持support（of software）见软件支持。

3.47（软件的）移交transition（ofsoftware）见软件移交。

4般要求

4.1软件开发过程

开发方应建立一个与合同要求一致的软件开发过程。软件开发过程应该包括下列主要活动，这些活动可以重叠、可被反复地应用，对不向的软件成份可以采用不同的活动，不必按下面列出的次序执行。开发方的软件开发过程应该用软件开发计划来描述。a.项目规划和监督（5.1)；

b.建立软件开发环境（5.2；）

c．系统需求分析（5.3)；

d.系统设计（5.4)；

e.软件需求分析（5.5)；

f.软件设计(5.6)

SJ 20778-2000

g．软件实现与单元测试（5.7)；h.单元集成与测试（5.8);

i.CSCI合格性测试（5.9)；

j.CSCI/HWCI集成与测试（5.10)；k.系统合格性测试（5.11);

1．软件使用的准备（5.12);

m。软件移交的准备（5.13)；

综合过程：

n.软件配置管理（5.14);

0.软件产品评价（5.15)；

p.软件质量保证（5.16);

q．纠正活动（5.17);

r．联合技术和管理评审（5.18)；s．其他活动（5.19)。

4.2软件开发的总体要求

开发方在实现本标准第5章的详细要求时应满足下列总要求。4.2.1软件开发方法

对软件开发的全部活动，开发方应采用系统的、文档化的方法。这些方法应该在软件开发计划中给予描述或引用。4.2.2软件产品标准

开发方应该制定和应用用于描述需求、设计、编码、测试用例、测试过程和测试结果的各种标准。这些标准应在软件开发计划中给予描述或引用。4.2.3可重用的软件产品

开发方应满足下列要求：

4.2.3.1加入可重用软件产品

对为满足合同需求而采用的可重用软件产品，开发方应加以标识和评估。对产品的调查范围和用以评估的准则应与在软件开发计划中描述的一致。满足准则的可重用软件产品应该是实际应用过的。在附录B中给出了关于采用可重用软件产品所要求的及可供选择的准则，以及本标准对其所作的解释。采用的软件产品应满足合同中所规定资料权的要求。

4.2.3.2开发可重用软件产品

在履行合同期间，开发方应确定开发重用软件产品的机会，并对这些机会的收益和成本加以评估。应向需方标明提供成本收益情况和与计划日标一致的机会。注：另外，合同可以要求开发方专为重用目的而开发一些软件产品。4.2.4关键性需求的处理

开发方应满足下列要求：

4.2.4.1安全保证

SJ20778—2000

故障可导致危险的系统状态（即导致意外死亡、伤害、财产损失或危害环境的状态）。如果有这样的软件的话，开发方应该制订一种安全保证的策略。包括测试和分析，以保证软件的需求、设计、实现和运行过程中的潜在危险情况得以排除或减到最小程度。这种策略应包括一个软件安全计划。并和系统安全计划（若已有）结合起来。开发方应该在软件开发计划中记录这个策略。实现这个策略，并提供证据说明这个安全保证策略被实现，这部分工作要作为所要求的软件产品的一部分。4.2.4.2保密性保证

开发方应该标明那些对保密起关键作用的一些CSCI或它们的一部分，它们的故障可能会导致系统保密性的破坏。如果有这种软件，开发方应制订一种保密性保证策略，用以保证由这种软件的需求、设计、实现和运行过程所引起的破坏系统保密性的可能性最小或得以排除。开发方应在软件开发计划中记录这个策略。实现这个策略，并提供证据证明这个保密性保证策略已被实现。这些工作要作为所要求的软件产品的一一部分。4.2.4.3私密性保证

开发方应该标明那些对私密性起关键作用的一些CSCI或它们的一部分，它们的故障可能会导致系统私密性的破坏。如有这种软件，开发方应制订一种私密性保证策略，用以保证由这种软件的需求、设计、实现和运行过程所引起的破坏系统私密性的可能性最小或得以排除。开发方在软件开发计划中记录这个策略。实现这个策略，并提供证据证明这个私密性保证策略已被实现，这些工作要作为所要求的软件产品的一部分4.2.4.4其他关键性需求的保证

如果个系统是靠软件来满足合同或系统规格说明中认为是关键性的需求的话，开发方应标明这些CSCI或它们的一部分，它们的故障可能会导致妨碍这些关键性需求的实现。开发方应制订一种策略以保证由于软件的需求、设计、实现和运行过程所引起的这种妨碍减至最小或得以消除。开发方应在软件开发计划中记录这种策略。实现这种策略，并提供证据证明这种保证策略已被实现，这种工作要作为所要求的软件产品的一部分。

4.2.5计算机硬件资源的利用

：开发方应分析合同中关于计算机硬件资源利用方面的要求（如最大限度地利用处理机能力、主存容量、输入/输出设备能力、辅助设备容量和通信/网络设备能力）。开发方应在诸个CSCI之间分配计算机硬件资源，在合同期间监督这些资源的利用，为了满足合同要求所必需的对附加资源的需要进行标识或重新分配。4.2.6记录原理

开发方应记载那些对保障机构在对软件的规格说明、设计、实现和测试作重要决策时用得着的原则。这些原则应包括考虑问题的折衷方法、分析方法和决策准则。这些原则应记载在文档、代码说明或其他将移交给保障机构的媒体中。“重要决策”的含义和提供这些原则的方法应在软件开发计划中加以描述。4.2.7便于需方评审

为了对合同所要求的软件产品及各项活动进行评审，开发方应为需方或其授权代表tijpg

5详细要求

SJ 20778—2000

本章中列出的各项要求的次序并不意味着一定要按这种次序来执行。许多活动可以同时进行；不同的软件产品，其进展的速度可以不同；前面几条说明的一些活动可能与来自后面几条中给出的一些活动的输入有关系。如果软件是在多个开发阶段中开发的，那么某些活动可能在每个阶段中都要完成，另一些活动可能只在一些选定的阶段中才完成，这些活动和软件产品在几个阶段或所有阶段完成之前是不可能完成的。图1提供了每一个活动如何可被应用到一个或多个阶段的例子。第5章中的非强制性说明将给出个涉及多开发阶段的项目的每一个活动的解释。只含单个阶段的项目将完成该阶段中所有要求的活动。附录G提供了规划开发阶段的指南，确定每个阶段有哪些活动以及如何安排这些活动。

项目规划和监督

建立软件开发环境

系统需求分析

系统设计

软件需求分析

软件设计

软件实现与单元测试

单元集成与测试

CSCI合格性测试

CSCI/HWCI集成与测试

系统合格性测试

软件使用准备