深入解读GJB 2786A军用软件开发通用要求

 [CAPESE大咖话标准]潘华

非常荣幸，我们邀请到了著名专家潘华研究员为大家解读软件工程标准体系中的顶层核心标准GJB 2786A。

潘华，中国航空综合技术研究所研究员，美国爱荷华州立大学计算机科学系访问学者。担任电子元器件标准化技术委员会委员、GJB 5000A评价员等，长期从事信息技术领域标准技术、规划、政策等研究工作，主编软件工程、数据、通信等信息技术领域标准20余项，作为第一完成人获国家部委级二等奖和三等奖共10余项。

GJB 2786A内容及特点解读（一）

GJB 2786A《军用软件开发通用要求》是军用软件工程标准体系中顶层的、核心的标准，主要是面向项目的，对于软件的开发项目或二次开发项目，它是首选标准。GJB2786A系统而全面的规定了军用软件开发的通用要求, 包括软件开发的12个基本开发活动、6个支持活动和8个管理活动等方面的要求，见图1，并给出了软件开发的一般要求，它的发布与实施对规范军用软件的开发、提高军用软件质量发挥重要的贡献。

图1 GJB2786A主要内容

1 GJB 2786A总体概貌

GJB2786A的基本内容分为5章和7个附录，见图2。

第1章

第2章

第3章

附录

第4章

第5章

范围

引用文件

术语、定义和缩略语

一般要求

详细要求

7个附录

图2 GJB2786A概貌

GJB2786A规定了军用软件开发的通用要求，包括软件开发的基本活动、支持活动和管理活动等方面的要求，并明确提出“本标准适用于需方和开发方获取、开发及维护军用软件(含固件中的软件)。”

这意味着GJB 2786A将适用于各种类型的军用软件，如自动化指挥控制软件、武器系统嵌入式软件以及工具性软件等；同时GJB 2786A的使用对象既包括需方也包括开发方，其中需方通常负责软件获取工作，是软件开发任务提出者；开发方是软件产品制造者，他们要确保按需方要求提交相应的产品。

另外GJB 2786A还适用于软件获取、开发及维护阶段。软件获取时，需方通常可据此标准提出所要开发的软件有关要求，并将有关要求纳入合同或研制任务书中；开发方可据此标准以及合同或研制任务书的要求组织并进行软件开发，当然需方和开发方关注GJB 2786A角度和关注的重点会有所不同。GJB 2786A也适用于军用软件维护，因为进行软件维护活动基本上等同于相应部分的开发活动。

在GJB 2786A第1章还指出，“标准中所涉及的“系统”有两类：一类是硬件－软件系统（例如一个雷达系统），对这种系统，本标准只适用于其软件部分；一类是软件系统（例如一个地理信息系统），对这类系统，本标准适用于其整个开发工作。”GJB 2786A 通过要求开发方参与系统级活动改进软件开发与系统工程的链接。对于“硬件－软件系统”，该标准所述系统层面的开发活动并非软件开发者负责的工作，而是由相应的系统开发者负责完成，软件开发者只是“参加”，与系统开发者协同完成与软件相关的活动；而对于“软件系统”，则所有系统层面的开发活动（包括系统层面的）软件开发者都应负责。

2术语

GJB2786A所用的术语一般按GB/T 11457《软件工程术语》确立的定义含意使用，但在本标准中对如下术语还赋予了一些特殊含意：

2.1构建版(build)

构建版指“软件的一个版本，它满足最终软件将满足的全部需求的一个规定的子集。”构建版是一个比较新的概念，准确掌握构建版的这个概念，对于正确理解和使用GJB2786A十分重要。

构建版与通常所说的软件单元、软件部件不同，能否作为一个构建版看待，应具备如个两个条件：

a)   它是软件的一个版本。这表明构建版是软件，可以是软件的中间版本，也可以是一个交付给用户的最终版本；

b)   它能向用户提供所要求的全部功能或部分功能。这表明构建版可能是提供部分功能的版本，或者是软件的全部功能的完整版本。

例如，型号软件开发通常分为原型、试样和正样，其中原型、试样和正样都可作为一个构建版看待，这也表明型号软件采用的可能是GJB2786A附录G中所说的“演进式”开发策略，按照3个构建版进行开发。GJB2786A中构建版术语的使用，改进了标准对增量式和渐进式等开发模型的适应性。

2.2软件 ( software)

   GJB2786A采用了与GB/T 11457相同的定义，软件是指“与计算机系统的操作有关的计算机程序、规程和可能相关的文档。”只是在GJB2786A中增加了一个注，以说明软件这一术语在GJB2786A中只限于计算机程序和计算机数据库，不包括文档，但是这并不表示GJB2786A忽视文档的编制，而仅仅是为了更准确表达与“软件”直接相关的要求。

2．3软件开发文件 (software development file)

软件开发文件是指“与特定软件开发有关的资料库。”实际上软件开发文件并不是一个特定文档，通常为由多个电子文件组成的文件夹，包括有关需求分析、设计和实现的考虑、理由和约束条件；开发方内部的测试信息；以及进度和状态信息等。在GJB2786A中软件开发文件特指与软件开发有关的资料库，并不是软件开发文档的通称，是软件工程环境的一部分。通常开发方应为每个软件单元（或一组逻辑上相关的软件单元）和每个CSCI建立、控制并维护软件开发文件（SDF）。

2．4软件产品 (software product)

GJB2786A采用了与GB/T 11457相同的定义，软件产品是指“作为定义、维护或实施软件过程的一部分而生成的任何制品，包括过程说明、计划、规程、计算机程序和相关的文档等，无论是否打算将它们交付给顾客或者最终用户。”软件产品并不是专指我们通常理解的交付给顾客或者最终用户那部分，软件过程中生成的任何制品都称可为软件产品。为保证与GJB5000A中概念的衔接，特地增加了说明“软件产品在开发过程中也称软件工作产品。”

2．5软件单元 (software unit)

GJB2786A对软件单元赋予了一个新的含义，软件单元是指“计算机软件配置项(CSCI)设计中的一个元素”，可以是CSCI的一个主要构成部分、构成部分的一个部件，也可以是一个类、对象、模块、函数、子程序或者数据库。这与GB/T 11457对软件单元的定义差别很大。在GB/T 11457中，软件单元的定义为“一段可分开编译的代码”，软件单元仅是指实现的结果中的一部分。

GJB2786A中定义的软件单元可大可小，十分灵活，可以出现在层次结构的不同层上，也可以出现在非层次结构的不同构成部分。GJB2786A对软件单元赋予的新的含义，改进了标准与非层次设计方法的兼容性。

3．一般要求

GJB2786A在第4章中规定了军用软件开发的一般要求，主要包括两个方面内容。

a)        建立软件开发过程

GJB2786A要求开发方应建立与合同要求一致的软件开发过程，可以包括该标准中所述26个主要活动。这些活动可以重叠或迭代应用，对不同的软件单元可以应用不同的活动，并且不必按该标准中列出的次序执行。针对具体软件,可对这些活动进行剪裁。开发方的软件开发过程应在软件开发计划中描述。

这表明软件开发方是可根据需方的合同（或软件研制任务书等相应文件）的要求，对标准所述26个活动进行相应的剪裁，并按照软件的具体情况进行组织，形成特定的软件的开发过程；对于软件中的不同部分，开发过程是可以不同的。另外，GJB2786A强调所确定的软件开发过程应纳入软件开发计划，并作为随后整个软件开发工作的依据。

b)        软件开发过程的一般要求

GJB2786A规定了如下7个方面的一般要求：

    `软件开发方法

    `软件产品标准

    `可重用软件产品

    `关键需求的处理

    `计算机硬件资源的利用

    `决策理由的记录

    `便于需方评审

需要进一步说明是：这里规定的软件开发过程的一般要求都是影响到软件项目的全局、多个方面或软件开发的多个活动，GJB2786A规定所有软件开发活动的方法都不应是随意的，而应使用经过实践证明行之有效的系统化的方法，GJB2786A还隐含了对软件开发计划的要求，要求在软件开发计划中应明确：软件开发方法（可以直接描述，也可以借助于引用）；信息描述标准,如GJB438B；以及什么是“重要决策”，以便记录这些决策的理由。

GJB2786A强调了软件的重用，为提高软件产品质量、加速软件开发和降低软件成本，需方和开发方均应关注重用软件产品。GJB2786A关注关键需求的处理。通常关键需求的处理由开发方负责，但什么是关键需求主要由系统需求决定。系统的使用特征决定了哪些计算机软件配置项需求是关键的，所以具体计算机软件配置项的关键需求一般自上而下地确定，软件开发人员可以参与其中，而对计算机软件配置项所属组成部分的关键性则由软件开发人员为主进行标识。

4详细要求

GJB2786A第5章对军用软件开发过程中的26个活动给出了详细要求。按照GB/T8566对软件生存周期过程活动分类的方法，可将这26个活动分为基本活动、支持活动和管理活动。支持活动和管理活动贯穿于各基本活动，也即是与各基本活动同时进行。

基本活动包括如下12个活动：

    `系统需求分析；

    `系统设计；

    `软件需求分析；

    `软件设计；

    `软件实现和单元测试；

    `单元集成和测试；

    `CSCI合格性测试；

    `CSCI/HWCI集成和测试；

    `系统合格性测试；

    `软件使用准备；

    `软件移交准备；

    `软件验收支持。

其中系统需求分析、系统设计、CSCI/HWCI集成和测试以及系统合格性测试为系统层面的活动。对于这些系统层面的活动，如前所述，若开发的系统是硬件－软件系统，GJB2786A 中所说的“参与”应理解为软件开发者“参加”；若开发的系统是软件系统，GJB2786A 中所说的应理解为软件开发者“负责”。

支持活动包括如下6个活动：

    `软件配置管理；

    `软件产品评价；

    `软件质量保证；

    `纠正措施；

    `联合评审；

    `测量与分析。

管理活动包括如下8个活动：

    `项目策划和监控；

    `软件开发环境建立；

    `风险管理；

    `保密性有关活动；

    `分承制方管理；

    `与软件独立验证和确认(IV&V)机构的联系；

    `与相关开发方的协调；

    `项目过程的改进。

其中软件开发环境建立和项目过程的改进为组织层面的管理活动，应站在整个组织层面开展相应的工作，其余则为项目层面的管理活动，主要是面向本项目，即软件的开发。

GJB2786A又进一步强调这26个活动是可以剪裁，每个活动的要求也是可以剪裁的。如果软件是按多个构建版开发，那么某些活动可能在每个构建版中都要执行，另一些活动可能只在一些选定的构建版中执行，并且这些活动和软件产品只有在若干构建版或所有构建版完成之后才完成。对软件开发过程中各活动的具体安排依赖于所选择的软件生存周期模型。

5附录

GJB2786A中有7个附录，其中有3个是规范性附录，是强制执行的；其余为资料性附录。这些附录对如何应用该标准提供指导或说明。

a)        附录A为资料性附录，提供了活动如何应用到多个构建版的例子。如何策划构建版，确定每个构建版有哪些活动，以及如何安排这些活动，在附录G中给出了指南。

b)   附录B为规范性附录，给出了采用可重用软件产品时对GJB2786A相关内容的解释，可有效指导对GJB2786A的剪裁。

c)   附录 C为资料性附录，提供了一个系统或CSCI按多个构建版开发时各项活动的实施建议；

d)       附录D为规范性附录，给出了问题报告的种类（9个）及严重性等级（4个）的划分。

e)        附录E为规范性附录，定义了软件工作产品评价的14条准则，并给出了GJB2786A中各软件工作产品的评价准则。

f)         附录F为资料性附录，提供了进行项目跟踪和监督时可选择使用的测度；

g)        附录G为资料性附录，提供关于项目策略、剪裁和构建版策划的指南。

6 GJB2786A的特点

为了更好地从采用GJB 2786过渡到采用GJB 2786A,除上述分析和说明外，下面GJB 2786A的一些主要特点和设计思想对于理解和应用GJB 2786A十分有帮助。

6．1适应渐增式和演进式开发

大型项目的研制和其中所需软件通常不能在一个研制周期全部完成，往往需要根据实际情况采用不同的项目策略，例如“一次完成设计”、“渐增式”和“演进式”策略。为了适应渐增式和演进式开发，GJB 2786A提出了“构建版”的概念。项目可以采用以多“构建版”方式开发软件。构建版可能是原型，也可能是提供部分功能的版本，或者是软件的全部功能的完整版本。GJB 2786A的附录C和附录G中的图说明了如何对包括多构建版的项目解释本标准。

6．2 正式评审和审核的替代方案

软件开发 “实际工作”中的最大困惑之一是准备正式评审和审核。以往一个普遍“令人厌恶的经历“是在正式评审之前相当长时间就停止“实际工作”，开始生成评审用的资料。开发方可能花费大量人时进行准备，而需方则被大量信息淹没，并且这种正式的评审和审核的会议常常不能深入解决实际问题，甚至是“认认真真走过场”。

GJB2786A采用了另一种方法，要求在低关键点进行更频繁的（需方/开发方）技术和管理评审，聚焦在自然的工作产品上，而不是在专为评审准备的资料上。这些评审包括对状态、思想、途径、风险等等非正式的讨论。进行这些评审的意图是在需方和开发方之间常进行沟通，可使花费的时间最少，同时又最能深入了解和解决实际问题。如果希望，可以使用正式评审来补充联合评审；但补充的正式评审应聚焦在联合评审提出的问题上，而不应重复联合评审已进行的工作。

6．3 降低对文档编制的强调

常听到一种抱怨说，军用软件开发标准规定的软件开发过程是文档驱动的。这种软件开发方式要求开发方必须生成一系列文档，其中有些对完成工作几乎无用。为此开发方可能不得不将实际工作产品，如在计算机辅助软件工程（CASE）工具中的数据，转换成纸质文档或将工作产品从完成该工作时的格式转换成文档所强加的人为格式；有时为了应付（如评审需要）而临时编写，产生大量无用的文档。GJB 2786A摈弃这种做法，强调自然工作产品，强调应关注“实际工作”，而不是在对项目目标不作任何贡献的非生产性任务上。这表现在：

a)   聚焦在自然工作产品上而不是在文档上。GJB 2786A 的各个生成信息的活动要求开发方“定义和记录”信息，而不是去“编写给定的文档”。该标准始终强调，以所产生信息的自然形式提供工作产品，例如，在CASE工具中的形式，而不要求开发方编写“传统的文档”。

b)   聚焦在正常工作项目上，而不是在可交付产品上。GJB 2786A 将策划和工程工作与编写可交付产品的活动区别开来。在没有必要的情况下不要使工作产品（无论它们的形式如何）变成可交付产品。GJB 2786A要求工作按计划进行，并要求为需方提供访问存放在开发方设施中的工作产品的方便。当有必要将某个工作产品变成可交付产品时，需方可在合同或任务书中提出要求。

c)   使用GJB 438B中相应的文档作为对应活动的检查单。GJB 2786A中的许多活动依靠GJB 438B中的相应文档来充分定义该活动的要求。例如，制定软件开发计划（SDP）的活动包含定义和记录GJB 438B中软件开发计划所规定的全部适用项。使用GJB 438B的相应文档作为活动中要定义的信息的检查单，这是GJB 2786A的一个重要思想。

6.4 改进对修改、重用和再工程的覆盖

软件工程技术的发展使人们越来越强调通过修改、重用和再工程现有软件产品，而不是全部“从零开始”进行软件开发。GJB 2786A为适应这种发展趋势而给出相应的规定，如：

a)   要求开发方标识和评价用于完成合同要求的可重用软件产品，并采纳满足该项目准则的可重用软件产品。

b)   提供在重用方面评价软件产品的准则，并说明用于重用项时如何解释标准中的要求。

c)   要求开发方标识和分析开发用于重用的软件产品的机遇，并将费用效益好并与工程项目目标兼容的机遇通知需方。

6．5 增强对软件保障性的强调

保障性是GJB 2786A中许多要求提出的原因，如：

a)     标识在软件开发期间使用或生成的保障机构需要的所有资源。

b)     制定软件移交计划，其中标识这些资源，并规定可交付项将如何移交到保障机构。

c)     证实有了这些资源就能够支持所交付的软件。

d)     记录可能对保障机构有用的关键决策的理由。

e)     记录编译和构建过程，供必须修改该软件的人员使用。

f)      编写要用于软件保障的手册。

6．6 改进与非层次化方法的兼容性

GJB2786A重新定义软件体系结构，简单地要求将CSCI分解为软件单元，软件单元不一定以层次方式与每个其他软件单元相关。GJB2786A进一步认为设计中的软件单元与实现它们的代码和数据实体或包含这些实体的计算机文件可以不一定有一对一的关系。软件单元的这种一般化和逻辑实体与物理实体的分离，如图3所示，提供了更大的灵活性，便于采用多种多样的软件开发方法。

    在军用软件工程标准体系中，GJB 2786A作为顶层标准，与其他很多标准都有接口。GJB 2786A的发布，标志着军用软件工程标准将进入一个新的时期，同时也预示着与GJB 2786配套的多个标准将面临着更新换代。GJB 2786A也是一个对装备质量、费用、进度等影响巨大的标准，深刻理解标准的精髓，对于合理实施标准具有重要的作用。

文章转自：公众号“软件工程标准化”