| 标题 | 军用嵌入式软件技术状态管理思索 |
| 范文 | 尹治华 摘 要：介绍了军用嵌入式产品技术状态管理和软件配置管理的基本概念，分析了软件技术状态管理过程中存在的问题，给出了解决思路，并从软硬件融合的角度阐述了如何对军用嵌入式软件进行技术状态管理。 关键词：软件配置管理；技术状态管理；技术状态控制；技术状态标识；技术状态项 0 引言 目前国内军用嵌入式软件研制相关单位对硬件技术状态管理主要依据GJB3206A-2010《技术状态管理》（其中GJB3206A-2010中明确说明软件按照GJB5235-2004《军用软件配置管理》进行管理），目前军用嵌入式软件研制相关单位对软件技术状态管理主要依据GJB5235-2004。其中Configuration Management被翻译为技术状态管理（用于硬件技术状态管理）和配置管理（用于软件技术状态管理）。因此，从本质上说，两个标准的含义是一样的，只是翻译的不同。鉴于软件属于系统的一部分，因此在软件研制的过程中，可以借鉴硬件技术状态管理的相关要求并应用到软件配置管理过程中，并最终达到两者融合，以一个标准的形式对软硬件技术状态进行管理（目前国内基本上没有两者融合的相关文章）。 1 技术状态管理与软件配置管理基本概念解读 （一）Configuration Configuration在相关标准中的定义为： （1）在MIL-STD-2549中被翻译为技术状态。现有或计划产品，或产品组合的特性、功能和物理属性； （2）在GB/T 11457-2006中：在配置管理中，在档中制定的并在产品中体现的硬件、软件的功能和（或）物理特性； （3）在GJB3206A-2010中，被翻译为技术状态。在件中规定的并且在产品中达到的功能特性和物理特性； （4）在GJB5235-2004中，被翻译为配置。在软件生存周期中各阶段产生的各种形式和各种版本的文档、程序、数据和环境的集合。 在GJB5000A-2008《军用软件研制能力成熟度模型》中指定每个配置项的重要特性主要指的是作者、文档或文件的类型、以及软件代码、文件的编程语言等。 通过GJB5000A对配置项重要特性的描述，我们可以将这些重要特性定为软件的物理特性。也就是说，软件是有功能特性和物理特性的。 鉴于GJB5235引用了GB/T 11457，因此在软件配置管理中对Configuration的定义应参照MIL-STD-2549、GJB3206A或GB/T 11457的定义较合适。 （二）Configuration management（CM） Configuration management（CM）在相关标准中的定义为： （1）在MIL-STD-2549中，被翻译为技术状态管理。建立并维持产品特性、功能和物理属性一致性的管理过程； （2）在GB/T 11457-2006中被定义为：应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性； （3）在GJB3206A中，被翻译为技术状态管理。在产品寿命周期内，为确立和维持产品的功能特性、物理特性与产品需求、技术状态文件规定保持一致的管理活动； （4）在GJB5235中，被翻译为配置管理。为保证软件配置项的完整性和正确性，在整个软件生存周期内应用配置管理的过程； GJB5235中对配置管理定义的最后使用了"应用配置管理"这几个字，其并未说明配置管理具体指什么，该标准对Configuration management的定义是不准确的。因此，Configuration management在软件中的定义采用GB/T 11457-2006或GJB3206A等的定义比较妥当。 （三）Configuration item（CI） Configuration item（CI）在相关标准中的定义为： （1）在MIL-STD-2549中，被翻译为技术状态项。技术状态项是指为单独的技术状态管理所指派的、能满足某一最终功能的任何硬件、软件或两者的组合； （2）在GB/T11457中，被定义为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一单个实体来对待； （3）在GJB3206A中，被翻译为技术状态项。能满足最终使用功能，并被指定作为单个实体进行技术状态管理的硬件、软件或其集合体； （4）在GJB5235中，被翻译为配置项。为了配置管理的目的而作为一个单位来看待的软件成分，通常为软件配置中的一个元素。 在GJB5000A中，工作产品的配置管理可按多个粒度级实施。配置项可以分为配置部件和配置单元。适时可解释为"配置部件"和"配置单元"。 从以上几个概念对Configuration item的解释，再结合对Configuration的解释，在软件中使用MIL-STD-2549、GB/T11457、GJB3206A的定义来描述Configuration item比较合适。 （四）Baseline Baseline在相关标准中的定义为： （1）在GB/T11457中基线（baseline）的概念为业已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理过程方能加以修改的规格说明或产品。其中功能基线的概念为：在配置管理中，一配置项的初始批准的档，相对于分配基线、开发基线、产品基线；分配基线的概念为在配置管理中，初始批准的规格说明，它支配作为较高级配置项的一部分的配置项的开发，相对于开发配置、功能基线、产品基线；产品基线的概念为在配置管理中，在它的生存周期的生产、操作、维护和后期支持期间，定义一配置项的初始的经批准的档（对于软件，包括源代码清单）。 （2）在GJB3206A中，技术状态基线（configuration baseline）的概念为在产品寿命周期内的某一特定时刻，被正式确认并作为今后研制生产、使用保障活动基准，以及技术状态改变判定基准的技术状态文件。一般包括三种技术状态基线：功能基线（经正式确认的功能技术状态文件）、分配基线（经正式确认的分配技术状态文件）和产品基线（经正式确认的产品技术状态文件）； 鉴于嵌入式软件属于整个产品的一部分，因此从系统融合、控制和易用的角度看，可以只保留技术状态管理概念上基线的概念：即功能基线、分配基线和产品基线，将软件配置管理中的功能基线修改为任务基线（主要包含软件研制任务书）、分配基线修改为需求基线（主要包含软件需求规格说明），将配置管理中产品基线的内容合并到技术状态管理概念上产品基线中。即系统分配基线包含软件任务基线、需求基线的内容，产品基线包含软件任务基线、分配基线和其他软件技术状态项文件。 （五）Configuration identification Configuration identification在相关标准中的定义： （1）在MIL-STD-2549中，被翻译为技术状态标识。与CI的选用、每个CI必需的技术状态文件类型的确定、CI发布号与其它附属于CI和定义其技术状态的件的标识符、CI的发放和与其关联的技术状态文件，以及技术状态基线的建立有关的技术状态管理要素； （2）在GB/T11457中，被翻译为配置标识。配置管理的元素，它由为系统选择配置项并在档中记录它们的功能和物理特征组成； （3）在GJB3206A中，被翻译为技术状态标识。确定技术状态项及其所需技术状态文件，标识技术状态项及其技术状态文件，发放和保持技术状态文件，建立技术状态基线的活动。 两个标准中概念基本一样。 （六）Configuration control Configuration control在相关标准中的定义为： （1）在MIL-STD-2549中，被翻译为技术状态控制。在某一CI的配置中，有关系统的建议、判断、评估、协调、建议更改的处置，以及所有批准/发放的更改实施的技术状态控制要素； （2）在GB/T11457中，被翻译为配置控制。配置管理的元素，它由评价、协调、批准或不批准和在配置项的配置标识正式建立以后，配置项变更的实现组成； （3）在GJB3206A中，被翻译为技术状态控制。技术状态基线建立后，对提出的技术状态更改申请、偏离许可申请和让步申请所进行的论证、评定、协调、审批和实施活动。 两个标准中对该概念解释基本一样。 （七）Engineering Change Engineering Change在相关标准中的定义为： （1）在MIL-STD-2549中被翻译为工程更改。对某个技术状态项的现行已批准技术状态文档的更改； （2）在GB/T11457中被翻译为工程更改。在配置管理中，配置项或其他指定的项在正式建立它的配置标识后在配置中的变更； （3）在GJB3206-1998中原术语为工程更改，在GJB3206A中术语被修改为技术状态更改。在产品寿命周期内，对已正式确认的现行技术状态所做的更改。 两者概念基本一致。 （八）Configuration status accounting Configuration status accounting在相关标准中的定义为： （1）在MIL-STD-2549中被翻译为技术状态的状况记实。有关获得、存储和授权使用技术状态信息的技术状态管理活动，这些技术状态信息是有效管理产品和产品信息所必需的； （2）在GB/T11457中被翻译为配置状态记录。一种配置管理的元素，它由记录和报告为有效地管理某一配置所需的信息组成。此信息包括列出经批准的配置标识表、建议变更的配置状态和经批准变更的实现状态； （3）在GJB3206A中被翻译为技术状态记实。在产品寿命周期内，为说明产品的技术状态所进行的记录、报告活动。 两者概念基本一致。 （九） Configuration audit Configuration audit在相关标准中的定义为： （1）在MIL-STD-2549中被翻译为技术状态审核，见功能技术状态审核和物理技术状态审核； （2）在GB/T11457中被翻译为配置审核。对所要求的全部配置项均已产生出来，当前的配置与规定的需求相符所作的证明； （3）在GJB3206A中被翻译为技术状态审核。为确定技术状态项与其技术状态文件的一致程度而进行的正式检查。包括功能技术状态审核和物理技术状态审核。 两者概念基本一致。 （十）Functional configuration audit Functional configuration audit在相关标准中的定义为： （1）在MIL-STD-2549中，被翻译功能技术状态审核。为了验证项目已经达到其功能和/或分配技术状态文件中规定的要求，在设计能力、专用工装或研制试验验收之前，对系统或某一技术状态项的功能特性的正式检查； （2）在GB/T11457中被翻译为功能配置审核。一种审核，它指导验证：配置项的开发已经满意完成、配置项已达到在功能的或分配的配置标识中规定的性能和功能特征并且它的操作的和支持的文档已满意地完成； （3）在GJB3206A中被翻译功能技术状态审核。为验证技术状态项的功能特性达到功能基线、分配基线规定的要求所进行的技术状态审核。 两者概念基本一致。 （十一）Physical configuration audit Physical configuration audit在相关标准中定义为： （1）在MIL-STD-2549中被翻译为物理技术状态审核。根据档对技术状态项的"即成"技术状态进行的正式检查，以建立或证实该技术状态项的产品基线； （2）在GB/T11457中被翻译为物理配置审核。验证已建立的某个配置项遵循定义它的档的审核行为； （3）在GJB3206A中被翻译为物理技术状态审核。为建立或验证产品基线，对技术状态项试制试产样品的完工状态、所依据的技术状态文件而进行的技术状态审核。 对于软件研制过程中的物理配置审核，目前通用的做法是检查是否文文一致、文实相符、是否可用等。而在系统研制的过程中，对系统技术状态文件的审核过程中也会检查文文一致、文实相符、是否可用等内容。因此从软硬件系统融合的角度，可以删除软件配置管理过程中物理配置审核的概念，只需将这些实际工作体现到日常工作中即可，在系统产品基线建立之前/后对整个系统（包含软件）进行物理技术状态审核。 （十二）配置管理审核（CMA） 在GJB5000A中对配置管理审核的描述为：目的是确认配置状态记录和配置项是否完备、一致和准确。 但在日常的系统技术状态审查或检查等中进行的就是软件配置管理审核的工作。因此可以删除此概念，直接用技术状态审核的概念即可，以便达到两者的融合。 （十三）配置库 （1）Product library Product library在相关标准中定义为： ①在GB/T11457中被翻译为产品库。一种软件库，其中含有已被批准供当前运行使用的软件； ②在GJB5716中对产品库的定义为在软件生存周期中，存放已定型（鉴定）且供交付、生产、检验验收的软件配置项的集合。 （2）Software development library Software development library在相关标准中定义为： ①在GB/T11457中被翻译为软件开发库。存放与软件开发工作有关的计算机可读信息和人们可读信息的软件库。 ②在GJB5716中对开发库的定义为在软件生存周期中，存放软件配置项的集合。 （3）Software controlled library 在GJB5716中被翻译为软件受控库。在软件生存周期中，存放已通过测试或评审且作为阶段性产品的软件配置项的集合。 从以上三点可以看出： ①按照国标的定义，在软件配置管理过程中，有开发库的定义； ②按照国标的定义，在软件配置管理过程中，有产品库的定义（其中该产品库包含GJB5716的受控库）； ③软件配置管理过程设置2个库（或者3个库等）是从使用的目的出发而增加了控制时机的存储库，因此在实际的软件技术状态管理过程中，即使是一个库，如果增加了相应的控制时机，也是可以的。 （十四）概念解读小结 通过以上概念解读，从军用产品系统技术状态控制的角度出发，硬件技术状态管理和软件配置管理相关概念与做法在本质上是一致的，因此我们不应人为将软件配置管理从大系统的技术状态管理中分割出去，我们应在标准编制和实践过程中将两者融合统一，避免在错误的路线上越走越远。 为了方面进行描述，以下内容统一软硬件技术状态管理相关概念： （1）统称为技术状态管理； （2）统称为技术状态项，技术状态项由技术状态文件和件构成； （3）统称为技术状态标识； （4）统称为技术状态控制； （5）统称为技术状态记实； （6）统称为技术状态审核。 2 软件技术状态管理中存在问题与解决思路 （1）技术状态项的选择 目前军工行业及相关行业大多数单位，在选择软件技术状态项时，将软件技术状态文件和件选取为技术状态项，没有从系统的角度选取配置项，导致软件技术状态管理与硬件技术状态管理脱节。造成该现象的主要原因为：硬件技术状态管理主要依据GJB3206A-2010《技术状态管理》，软件按照GJB5235-2004《军用软件配置管理》进行技术状态管理。 因此我们应该将硬件技术状态管理相关标准和软件技术状态管理相关标准融合统一，避免相关单位在软件技术状态项的选取上犯错误，导致不必要的麻烦。 （2）技术状态项标识 目前军工行业及相关行业大多数单位，在对软件技术状态文件或件进行标识（特别是对文档进行标识）时，往往同时存在着标准化管理部门提供的文档编号及版本号、配置管理部门提供的配置标识及版本号，导致软件技术状态项的标识不唯一。因此需要从大系统技术状态项标识的角度融合这两个部门提供的标识号，确保唯一。 （3）软件技术状态控制 目前军工行业及相关行业大多数单位，制定了软件入库控制、出库控制以及更改控制相关要求。但往往对入库与出库控制太严，忽略了最应重视的更改控制，且更改控制级别等划分较粗，同时还存在着重复办理更改手续（如在软件配置管理业务中办理一次更改，在大系统技术状态管理过程中对软件文档又办理一次更改），软件档的源头不唯一（同时采用软件配置管理工具（如ClearCase＼SVN等）和产品数据管理工具（如西门子公司的TeamCenter）对软件文档进行管理）等问题。 （4）软件更改等级划分建议 可以从以下方面对软件更改进行控制，划分软件等级： ①对属于系统分配基线、产品基线的技术状态文件（如软件研制任务书、软件需求规格说明）的功能、性能、接口等的更改定为I类更改，对不属于系统分配基线的技术状态文件（如软件设计说明）或产品基线中非功能、性能、接口等的更改定为II类更改，对不属于技术状态文件的件及属于技术状态文件的其他更改定为III类更改（如过程域中支持过程、项目管理过程产生的软件开发计划、软件配置管理计划、软件质量保证计划等）。 ②在更改级别的划分中还可以考虑系统所处阶段（如初样阶段、试样阶段等）、状态、主干与分支等情况。 （5）软件技术状态更改重复审批改进建议 对于重复办理更改手续的问题，原因是相关单位未意识到软件配置管理相关国军标作用下的技术状态更改与大系统技术状态相关国军标作用下的技术状态更改是同一个概念，从而导致重复办理更改手续的问题。因此需要重新梳理整合更改流程，确保软件技术状态更改流程只有一个。 （6）软件件源头不唯一改进建议 软件作为产品的一部分，采用产品数据管理工具对其进行状态进行管理从本质上没有错，但目前业界内很多单位同时使用配置管理工具和产品数据管理工具对文档进行管理，导致软件技术状态不唯一。因此应控制软件的源头，可以以配置管理工具作为源头，当软件技术状态固化之后，将软件文档等传递到产品数据管理系统中，以保证产品数据的齐套性；或者直接以产品数据管理系统等工具直接管理光、机、电、软的相关件。 3 软件技术状态管理发展趋势 软件作为系统中的一部分，其技术状态管理从长远来看，将与硬件技术状态管理融合统一（对于以上概念解读中不互相冲突的，在此不再进行描述）： （1）软硬件技术状态标识的融合； 在整个系统中，整合标准化部门提供的文档编号和软件配置管理部门提供的配置标识，确保软件技术状态项具有唯一标识，并将其标识增加部分标识符之后扩展到技术状态文件和件。 （2）软件三库不再是传统意义上的三库，是软硬件综合大系统层次上的三库，且三库数据源唯一； 如在嵌入式产品设计平台中将通过正式评审之前（如审查、配置项测试前）的内容作为开发库进行控制，只需要在平台中记录软件需求更动历史信息，没有必要专门使用配置管理工具作为开发库；将通过正式评审或配置项测试后的技术状态文件存放在嵌入式产品平台的"受控库"（可以是加了相关标记的受控库，不一定是严格意义上的传统受控库）中进行管理，对于非技术状态文件（如软件计划类文档）可以只进行开发库级管理；软件设计定型后，将技术状态文件纳入产品库管理（该产品库内容一定属于档案管理部门管理内容的一部分，产品库也可以同时是档案库），原则上产品库与档案库数据源应唯一。 （3）软件技术状态更改流程唯一； 应整合软件配置管理标准作用下的软件更改流程与大系统技术状态标准作用下的更改流程，确保软件技术状态更改流程唯一。 （4）软件设计定型后，将以发放的形式代替目前的出库审批形式供生产现场使用； 目前相关软件国军标中明确规定了软件设计定型后需要办理软件出库手续从产品库中提取软件，这增加了部分管理成本，因此最好的方法是借用大系统技术状态管理标准下的发放方式（目前软件采用发放的方式还暂时不被顾客代表等认可），以提高效率。 （5）软件技术状态审核的融合； 在软件设计定型之前，从大系统技术状态审核角度，对整个产品进行审核时，软件与整个产品一起事件或定期进行功能技术状态审核（可以结合评审、测试、专项检查等方式）。 在产品基线建立之前或为了验证产品基线，软件随系统进行物理技术状态审核（可以通过评审、验收、靶场等方式进行）。 日常情况下，软件与大系统一起做好软件件产生、存储、使用、废弃及销毁过程中物理配置管理审核（即文文一致、文实相符、是否可用审查等）。 （6）基线的融合； 从大系统的角度，设置系统功能基线、分配基线（将软件研制任务书、软件需求规格说明纳入到系统分配基线中）、产品基线（将软件相关技术状态文件纳入产品基线中）。取消软件功能基线或改名为任务基线；取消软件分配基线或改名为需求基线；取消软件产品基线，使之融合到系统产品基线中。 参考文献： [1]United States Department of Defense. MIL-STD-2549 Configuration Management Data Interface [S]. [2]中华人民共和国国家质量监督检验检疫总局，中国国家标准化管理委员会. GB/T 11457-2006 信息技术软件工程术语[S]. [3]中国人民解放军总装备部.GJB3206A-2010 技术状态管理[S]. [4]中国人民解放军总装备部.GJB5235-2004 军用软件配置管理[S]. [5]中国人民解放军总装备部.GJB5000A-2008军用软件研制能力成熟度模型[S]. [6]中国人民解放军总装备部.GJB 5716-2006 军用软件开发库、受控库和产品库通用要求[S]. |
| 随便看 |
|
科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。