一种面向多种系统构型的技术状态管理方法与流程

本发明属于复杂系统设计制造领域，涉及一种面向多种系统构型的技术状态管理方法。

背景技术：

随着工业系统、航空装备信息化水平的不断提高，在航空装备型号研制过程中复杂系统的特征逐渐凸显出来，飞机系统中子系统/软件的特征对整个系统功能、性能的影响变得越来越复杂，为控制复杂系统特征的涌现，技术状态管理以子系统/软件配置项单一有效的状态作为系统有效状态，也就是说在构建一个系统基线时，子系统/软件配置项的状态有且仅有一种状态与之对应。

分析传统技术状态管理的方式我们发现，这种管理方式较好的控制了复杂系统的涌现效应但是有以下方面的缺陷：

(1)在系统设计阶段，在航空装备军贸市场中，同一型号航空装备将面向多种用户需求，传统技术状态管理方法使用面向单一设计状态管理方式，在构建不同基线状态时，针对多用户需求的开发在传统配置管理中是以独立开发分支管理，造成开发冗余，共性问题也难以追溯；

(2)在系统交付阶段，面对用户快速变化的需求，难以通过系统构型调整而不是设计变更快速实现系统交付技术状态；

(3)在系统使用阶段，传统技术状态管理的定义方式在实际使用过程中子系统/软件配置项的适配范围狭隘，针对系统不同状态，软件基线状态不一致，且无法快速分析构型影响关系，在实际使用环境中，难以作出替换或者重构的决策。

技术实现要素：

本发明的目的：从系统可以同时构建多种有效构型的实际应用角度，提出一种新的技术状态管理方法，它可以克服传统的单一设计状态管理方式的局限性，同时实现对不同用户多种系统构型的快速适配，可以向用户提供更加清晰的系统构型数据，协助用户在使用过程中实现快速重构，从而解决复杂系统技术状态管理的灵活性问题。

本发明的技术方案：一种面向多种系统构型的技术状态管理方法，基于子系统/软件的接口特征，主要步骤如下：

1)建立系统接口规范，接口规范包括但不限于物理接口规范和逻辑接口规范；

2)按照需求设计要求完成子系统/软件配置项设计活动并提供工作产品；

3)根据用户需求和系统需求建立系统最小运行条件；

4)对照接口规范建立配置项的接口规格，并进行相应等级的验证，保证其获得有效实现；

5)根据子系统/软件接口规范确定接口特征，建立系统内部接口映射关系；

6)依据系统最小运行条件建立子系统/软件配置项适配性评价准则，分析子系统/软件配置项的接口特征与多种系统构型的匹配性；

7)根据子系统/软件配置项的接口特征与系统构型的匹配性，选择符合条件的子系统/软件配置项开展系统综合并进行风险评估；通过系统综合过程验证用户需求、系统需求和相关质量特性完成情况，通过风险评估过程评价子系统/软件配置项对系统使用过程产生的影响。

本发明的积极效果：该方法与传统技术状态方法相比，可以有效提高系统构建的灵活性，减少技术状态分支开发的冗余，实现快速重构系统。对于子系统/软件开发者不必考虑系统架构与兼容性问题，可以专注于已知需求的设计实现，促进子系统/软件的构件化开发，实现更多的复用。通过定义接口规范，可以有效识别子系统/软件之间的详细关系并通过技术状态管理过程完整确认其实现性，及时识别系统构建过程中的接口完整性、一致性风险。

针对复杂系统便于统一接口规范，预防涌现效应的出现。结合系统架构设计技术，可以通过接口规范分析，优化架构设计，提高系统可靠性水平。

附图说明

图1为传统技术状态管理方式示意图；

图2为本发明面向多种系统构型的技术状态管理方法示意图。

具体实施方式

下面结合附图对本发明的具体实施方式做进一步详细说明。

本发明一种面向多种系统构型的技术状态管理方法，基于子系统/软件的接口特征，主要步骤如下：

(1)根据对象系统的特征建立接口规范，可根据系统设计、系统接口设计、软件需求规格、软件概要设计等过程的结果，每一个识别的接口应给出唯一标识，接口特征应具有可验证性；建立系统接口规范，接口特征包括但不限于物理接口规范和逻辑接口规范；

a)物理接口规范

物理接口规范包括但不限于以下内容：

a.接口实体分配给接口的优先级别；

b.要实现的接口的类型(如实时数据传送、数据的存储和检索等)；

c.接口实体将提供、存储、发送、访问、接收的单个数据元素的特性，如：

1)名称/标识符：

1.a)项目唯一标识符；

1.b)非技术(自然语言)名称；

1.c)数据元素名称；

1.d)技术名称(如代码或数据库中变量或字段名)；

1.e)缩写名或同义名；

2)数据类型(字母、数字、整数等)；

3)大小和格式(如：字符串长度和标点符号)；

4)计量单位(如：m)；

5)可能值的范围或枚举(如：0----99)；

6)准确度(正确程度)和精度(有效数字位数)；

7)优先级别、时序、频率、容量、序列、其它约束，如：数据元素是否可被更新、业务规则是否适用；

8)保密性约束；

9)来源(设置/发送实体)和接收者(使用/接收实体)。

d.接口实体必须提供、存储、发送、访问、接收的数据元素组合体(记录、消息、文件、数组、显示、报告等)的特征，如：

1)名称/标识符：

1.a)供追踪用的项目唯一标识符；

1.b)非技术(自然语言)名称；

1.c)技术名称(如代码或数据库的记录或数据结构)；

1.d)缩写名或同义名；

2)数据元素集合体中的数据元素及其结构(编号、次序、分组)；

3)媒体和媒体中数据元素/集合体的结构；

4)显示和其它输出的视听特性(如：颜色、版面设计、字体、图标和其它显示元素、蜂鸣声、亮度)；

5)数据元素集合体之间的关系，如排序/访问特性。

6)优先级别、时序、频率、容量、序列、其它约束，如：集合体是否可被修改、业务规则是否适用；

7)保密性约束；

8)来源(设置/发送实体)和接收者(使用/接收实体)。

e.接口实体为该接口使用通信方法的特征。如：

1)项目唯一标识符；

2)通信链路/带宽/频率/媒体及其特性；

3)消息格式化；

4)流控制(如：序列编号和缓冲区分配)；

5)数据传送速率，周期性/非周期性，传输间隔；

6)路由、寻址、命名约定；

7)传输服务，包括：优先级别和等级；

8)安全性/保密性方面的考虑，如：加密、用户鉴别、隔离、审计。

f.接口实体为该接口使用的协议的特性，如：

1)项目唯一标识符；

2)协议的优先级别/层次；

3)打包，包括：分段和重组、路由、寻址；

4)合法性检查、错误控制和恢复过程；

5)同步，包括：连接的建立、维护、终止；

6)状态、标识和其它的报告特征。

g.其它特征，如接口实体的物理兼容性(尺寸、公差、负荷、电压和接插件兼容性等)。

b)逻辑接口规范

逻辑接口规范包括但不限于以下内容：

a.内容耦合逻辑

1)逻辑起点

2)入口条件

3)逻辑行为

4)终止条件

5)逻辑终点

6)约束

b.公共耦合逻辑

1)全局数据定义

2)全局数据引用

c.外部耦合逻辑

1)共用外部环境定义(数据格式、通讯协议或设备界面)

2)共用外部环境引用

d.控制耦合逻辑

1)控制起点

2)入口条件

3)控制行为

4)终止条件

5)控制终点

6)约束

e.标记耦合逻辑

1)数据结构定义

2)数据结构引用

f.数据耦合逻辑

1)数据定义

2)数据引用

g.消息耦合逻辑

1)消息定义

2)消息引用

h.并发逻辑

1)并发条件

2)并发范围

i.继承逻辑

1)父类

2)继承特征

j.无耦合逻辑

(2)按照需求设计要求完成子系统/软件配置项设计活动并提供工作产品，工作产品应包含但不局限于系统需求规格说明、软件需求规格说明、接口规范说明等；

(3)根据用户系统需求建立系统最小运行条件，系统最小运行条件是系统对于自身运行状态的最小条件，该条件是分析评价子系统/软件适配性的刚性约束，系统最小运行条件的考虑涵盖系统主要功能、关键性能、安全性、保密性、可靠性等特征，应考虑系统运行的所有强制约束条件，明确系统最小运行边界；

(4)对照接口规范建立配置项的接口规格，并进行相应等级的验证，保证其获得有效实现；子系统/软件配置项进行合格性验证，按照接口规范要求根据接口验证的实际结果标识子系统/软件配置项接口规格，所有通过合格性验证的配置项均纳入技术状态主干管理，主干的版本路径分为维护路径和开发路径，主要针对不同需求来源，保证多种用户需求均能同时得到响应，该种技术状态管理方式支持多种子系统/软件配置项技术状态均处于有效状态，以便于系统构建的灵活性；

(5)根据子系统/软件接口规范确定接口特征，建立系统内部接口映射关系，接口映射关系包括但不限于统一的数据字典、复杂数据结构定义、通讯协议、消息机制、调用关系矩阵、任务优先级等；

(6)分析子系统/软件配置项的接口特征与多种系统构型的匹配性，依据系统最小运行条件建立子系统/软件配置项适配性评价准则；完成配置项接口规格之间的完整性、一致性审查，首先检查规格说明与系统接口规范的一致性，之后检查接口间交互关系的一致性，这种一致性检查可以使用静态分析工具、运行时分析工具、时序分析检查工具等专用工具；

(7)根据子系统/软件配置项的接口特征与系统构型的匹配性，选择符合条件的子系统/软件配置项开展系统综合并进行风险评估；通过系统综合过程验证用户系统需求和相关质量特性完成情况，通过风险评估过程评价子系统/软件配置项对系统使用过程产生的影响；分析不一致的影响，对照系统最小运行条件，对不一致的子系统/软件配置项接口特征进行影响分析，确认是否影响系统最小运行条件，如果不影响，可以建议作为集成备选配置项，否则就不具备构建系统构型的条件。

本发明中的“/”表示或和与的关系。

图2中ci001-005为子系统/软件配置项，v0.1、v1.0、v1.1、v1.2、v2.0等为各配置项的开发状态，根据系统最小运行状态分析各配置项的开发状态得出针对不同构型状态的基线有效性，由此确定其系统综合的可能性，根据用户需求、系统需求和风险评估的结果选择最佳的集成路径得出最终的系统构型基线。