《电力信息化 第一部分：系统建设规范》征求意见稿

T/GDEA001.1—2022

ICS35.240

CCSL77GDEA

团体标准

T/GDEA001.1—2022

电力信息化第1部分：系统建设规范

ElectricPowerInformationpart1:System

ConstructionSpecifications

征求意见稿

2022-XX-XX发布2022-XX-XX实施

广东省能源协会发布

T/GDEA001.1—2022

前言

本文件按照GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》

的规定起草。

本文件由广东省能源协会归口。

本文件起草单位：公诚管理咨询有限公司、广东电网有限责任公司广州供电局、全球能源互

联网研究院有限公司、南方电网科学研究院有限责任公司、南方电网大数据服务有限公司、东莞

市输变电工程建设有限责任公司。

本文件主要起草人：陈伟峰、刘春早、王晔、赵辉、郭经红、陆宏治、郭俊峰、匡晓云、张

鹏、陈卓烽、白金、洪慧君、高宇翔、陈桓、梅永坚、蒋屹新、林龙标、薄永波、刘斯婷、訾永

辉

5

T/GDEA001.1—2022

引言

本标准是从电力信息系统需求管控标准、电力信息系统设计、电力信息系统开发、单元测试、

接口测试、功能验收测试、入网安评测试、等保测试等相关建设，规定了在信息电力信息系统建

设中的规范、原则，本标准适用于电力信息系统建设工作。

——第1部分：术语定义

——第2部分：电力信息系统需求管控标准

第3部分：电力信息系统设计标准

第4部分：电力信息系统开发标准

第5部分：电力信息系统测试标准

第1部分内容中，把电力信息系统建设中的建设过程中运用到的术语进行准确的定义；

第2部分内容中，从需求调研分析、需求规格说明书编制、业务模型说明书编制出发，把电力信

息系统需求环控标准化；

第3部分内容中，从电力信息系统架构设计、用户界面设计、模块设计、数据结构算法设计、数

据库设计方面，对电力信息系统设计进行标准化；

第4部分内容中，从开发设计通用规范、命名规则、前端开发编码、后端开发编码、配置管理、

接口规范进行标准化，规范电力信息系统开发过程；

第5部分内容中，从单元测试、接口测试、功能测试、入网安评测试以及系统等级保护测试等环

节，对电力信息系统测试过程标准化；

通过以上5部分内容，把电力信息系统建设过程的建设进行规范化，有利于电力信息系统建设效

率的提高。

6

T/GDEA001.1—2022

电力信息化第1部分：系统建设规范

1范围

本文件规定了电力行业信息化的总体原则、总体要求、系统开发、系统测试和试运行与验收

的要求。

本文件适用于电力行业各类信息系统的开发。

2规范性引用文件

本文件没有规范性引用文件。

3术语和定义

3.1电力企业

指中华人民共和国电力行业内的包括电力发输变企业和供配电企业。

3.2系统需求方

对电力业务活动过程需要信息化系统辅助支撑的组织机构或个人。

3.3业务人员

负责日常电力业务活动的员工。

3.4原型

原型开发：把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，

及时征求用户意见，从而明确无误地确定用户的需求。

3.5需求分析

研究需求方要求以得到系统或软件需求定义的过程

3.6需求评审

7

T/GDEA001.1—2022

指对需求进行管控审核，提出明确的修改意见和建议，形成评审结论。

3.7业务模型说明书

以软件模型方式描述电网各业务域所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务

建模强调以体系的方式来理解、设计和构架信息系统。包含业务组织架构、业务结构、业务范围、业务

流程、业务规则、业务表单、管理要求、集成模型、关联关系。

3.8需求规格说明书

为了使用户、软件开发者及分析和测试人员对该软件的需求规格有一个共同的理解，包含功能架构、

业务功能需求、非功能性需求、集成需求和界面原型等内容，明确标识各项功能的具体含义，提供一个

度量和遵循的基准。

3.9专业审核

由技术管控组对需求分析、系统设计、系统开发和试点实施阶段提交的重要成果从企业架构、信息

集成、数据、安全、鉴权加密和运维等六个维度进行技术管控审查。

3.10概要设计

分析各种设计方案和定义软件体系结构的过程。将一个复杂系统按功能进行模块划分、建立模块的

层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据

的结构特性、以及数据库的设计。典型的概要设计包括计算机程序组成成分和数据的定义及结构、界面

的定义、并提出时间和规模方面的估计。

3.11详细设计

推敲并扩充概要设计，以获得关于处理逻辑、算法、数据结构和数据定义的更加详尽的描述，直到

设计完善到足以实现的地步。

3.12软件开发

是根据用户需求建造出软件系统的过程，包括程序代码编写和测试。

3.13开发人员

8

T/GDEA001.1—2022

指为客户生产某种软件产品的个人或集团在本指南中客户和开发者可能是同一个组织的成员。

3.14用户

指运行系统或者直接与系统发生交互作用的个人或集团用户和客户通常不是同一些人。

3.15软件特征

软件项的显著特征（如功能、性能或可移植性）。

3.16软件项

源代码、目标代码、作业控制代码、控制数据或这些项的集合。

3.17通用准则

判断一个软件项或软件特征的测试是否通过的判别依据。

3.18验证

验证是指确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求过程。

3.19确认

确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。

3.20生存周期模型

一个包含过程、活动和任务的框架，这些过程、活动和任务涉及软件产品的开发、运行和维护，跨

越从需求定义到终止使用的系统生存周期。

3.21数据

在流程中处理的各种信息对象，数据可以有多种存储方式。

3.22模块

9

T/GDEA001.1—2022

按照业务功能划分的各个子业务系统，如台区、仓储、领料、带电作业等子业务。

3.23软件验证与确认评审

在制订软件验证与确认计划之后要对它进行评审，以评价软件验证与确认计划中所规定的验证与确

认方法的合适性与完整性。

3.24功能检查

在软件释放前，要对软件进行功能检查，以确认已经满足在软件需求规格说明书中规定的所有需求。

3.25配置项

项目开发或系统集成实施过程中所需要或所产生的软件、硬件、工具、释放产品、文档，包括基准

配置项与非基准配置项。

3.26基准配置项

通过正式评审成为下一步开发或实施基础的配置项，只有通过规范要求的变更控制程序才能被更

改。

3.27软件配置管理库

软件配置管理库又称软件受控库，是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而

释放的、与软件开发工作有关的计算机可读信息和人工可读信息的库。软件配置管理就是对软件受控库

中的各软件项进行管理。

3.28更改

配置项的变更与更改统称为更改。

3.29测试

（1）由一个或多个测试用例组成的集合；

（2）由一个或多个测试规程组成的集合；

（3）由一个或多个测试用例和规程组成的集合；

10

T/GDEA001.1—2022

3.30测试用例说明

对于一个测试项，用来指定输入、预期结果和一组执行条件的文档。

3.31测试（活动）

一个过程，该过程分析软件项，以检测现有条件和要求条件之间的差异（即，缺陷）并评估软件项

的特征。

3.32测试项

作为测试对象的软件项。

3.33测试覆盖率

测试用例测试系统或软件产品的需求的程度。

3.34可测试性

为了确定一项需求是否满足，能够设计一个客观且可行的测试的程度。

3.35测试计划

描述预定测试活动的范围、方法、资源和进度的一种文档，它确定测试项、要测试的特征、测试任

务、执行每一任务的人员以及需要应急对策的任何风险。

3.36测试总结报告

用来总结测试活动和结果的一种文档，它还包括对相应测试项的评估。

3.37上线

让设备或者是软件系统正式运行。

3.38验收

需方对开发方提交的软件系统，按照合同或双方的约定进行测试、审查与评审，决定接收或拒收的

11

T/GDEA001.1—2022

活动。

3.39验收测试

确定一软件系统是否符合其验收准则，使需方能确定是否接收此系统的正式测试。

3.40软件系统

由自主开发的软件集成或由定制软件和商业现货软件集成的软件，通常由系统软件、支持软件和应

用软件组成。

3.41交付项

按照合同要求交付，可以在软件产品开发中产生出软件产品或文档等材料。

3.42版本

某一配置项的已标识的实例。对软件产品的某个版本进行修改会产生一个新的版本，需要对这种修

改实施配置管理活动。

3.43退役

运行和维护组织撤出现有的支持，部分或全部由一个新的系统代替或者安装一个升级的系统。

4总体原则

4.1用户界面设计规范

4.1.1风格一致性

（1）系统用户界面各层级、页面切换方式、按钮样式等应保持风格一致。

（2）系统用户功能命名规则、业务术语等应保持风格一致性

（3）针对电力信息系统界面，对于在同一业务域或者业务分类的用户界面应保持一定的相似性。

（4）针对电力信息系统的操作行为上应保持一定的一致性，例如：复制、粘贴、截图等快捷键操

作均应统一。

4.1.2适用性

12

T/GDEA001.1—2022

（1）用户界面与系统功能的相融洽程度。

4.1.3可理解性

（1）用户界面设计的所有元素（包括菜单、工具条等）描述不能相互矛盾；

（2）用户界面设计的所有元素（包括菜单、工具条等）避免出现让用户难以理解的词汇、描述方

式等；

（3）用户界面设计的所有元素（包括菜单、工具条等）避免出现造成用户误解的词汇、描述。

（4）用户界面元素在设计过程应充分考虑引入必要提示，例如鼠标移动选择、高亮、阴影变化等

动态效果。提升用户在与系统交互时的感知。

（5）用户界面结构应能清晰充分地翻阅业务流程，以便能让用户可以快速理解按部就班操作。

（6）对于复杂的用户界面，应有界面操作“向导”功能，及时让用户感知到自己在系统操作过程

的步骤、流程位置等。

4.1.4及时信息反馈

信息系统应在与用户的交互操作时，向用户反馈系统处理过程的提示信息，或是系统处理过程的可

视化提示。例如：弹出“正在加载”等浮窗提示。

4.1.5出错处理

（1）应具备对输入数据进行校验的功能，及时提醒用户修正录入错误的数据；

（2）在业务流程流转过程，对不应在当前环节使用的功能按钮需要进行屏蔽；

（3）通过多层级用户界面切换，让用户在使用过程不会出现功能误操作的现象；

（4）通过用户权限配置，避免不同权限用户越权操作；

（5）提供Undo功能，用以撤销不期望的操作。

（6）系统应具备操作确认功能，对用户执行破坏性的操作之前，应当获得用户的确认。

4.1.6布局合理性

（1）系统界面和元素布局应该在水平或者垂直方向对齐；

（2）系统界面元素的行、列间距保持一致。

（3）窗体规格尺寸应按照不同的显示像素和显示比例制定响应尺寸标准。

13

T/GDEA001.1—2022

4.2模块设计规范

4.2.1信息隐藏

（1）通过接口来隐藏模块内部的数据结构、算法、实现体等内部特征。

（2）一个模块仅提供有限个接口，执行模块的功能或与模块交流信息必须且只须通过调用公有接

口来实现。

（3）如果模块是一个C++对象，那么该模块的公有接口就对应于对象的公有函数。如果模块是一

个COM对象，那么该模块的公有接口就是COM对象的接口。

（4）一个COM对象可以有多个接口，而每个接口实质上是一些函数的集合。

4.2.2高内聚

首先模块设计应考虑高内聚，从业务功能实现角度上分析，但和业务无实际关系，应从技术架构上

着手。下列内聚属性可以作为在模块设计中的不同角度实现高内聚，但不需要过分追求内聚的精准级别。

内聚级别内聚类型定义

如果模块内的某个成分输出作为下一个成分的输入，则应以

顺序性内聚

高（提倡）顺序内聚整合成同一个模块

功能性内聚指模块内所有处理成分都针对完成单一一个功能

针对多个功能需要在同一时间内执行，前提是这些功能是基

时序性内聚

于时间因素关联在一起的，则可以整合一个模块内

针对多个功能所执行的处理成分是相关的，且必须按照特定

中（限制）过程性内聚

次序执行，则应整合在一个模块内

对于所有输出或操作都针对同一数据集时，应整合在同一模

通信内聚

块内

偶然性内聚一个模块的各成分之间的关系批次松散（几乎无关联性）

低（避免）逻辑上相关的功能可以放在同一个模块中，例如读取不同类

逻辑性内聚

型外设设备的输入数据。

4.2.3低耦合

在系统建设过程充分做到高内聚的情况下，相应就能做到低耦合。按如下划分耦合的强度，可在模

块设计过程考虑耦合的强度：

14

T/GDEA001.1—2022

耦合强度耦合类型定义

两个模块之间没有直接关系，他们之间的联系完全是通过主

非直接耦合

模块的控制和调用来实现的

低（提倡）

模块之间通过参数来传递数据，那么被称为数据耦合。数据

数据耦合

耦合是最低的一种形式

模块A通过接口向模块B和模块C传递一个公告参数，那么

标记耦合

模块B和C之间存在一个标记耦合

一个模块通过接口向另一个模块传递控制信号，接受信号的

控制耦合模块根据信号值而进行适当的动作，这种耦合被称为控制耦

中（限制）

合

一组模块都访问同一全局简单变量而不是同一全局数据结

外部耦合构，而且不是通过参数表传递该全局变量的信息，则称之为

外部耦合。

一组模块都访问同一个公共数据环境，则它们之间的耦合就

公共耦合称为公共耦合。公共的数据环境可以是全局数据结构、共享

的通信区、内存的公共覆盖区等。

如下形式都属于两个模块之间就发生了内容耦合。

高（避免）1、一个模块直接访问另一个模块的内部数据；

2、一个模块不通过正常入口转到另一模块内部；

内容耦合

3、两个模块有一部分程序代码重叠（只可能出现在汇编

语言中）；

4、一个模块有多个入口。

4.3数据结构和算法设计规范

数据结构影响的是系统业务数据在各种存储介质的增删查改，包括在运算数组中。而算法所影响的

系统运算过程对数据结构施加的操作。

针对电力信息化系统具有复杂的业务流程和庞大的数据量，因此在设计过程从时间和空间角度对应

算法和数据结构应参照下述原则：

（1）数据结构和算法的按照空间、时间所占有的开销和收益。应从物理介质特性上考虑其效率，

15

T/GDEA001.1—2022

以及从算法分析的原理上入手。

从物理层面应根据存储介质特点来进行判断，如机械磁盘、闪存、内存、固态硬盘等存储介质的读

写效率、稳定性等。

从系统部署架构上，应综合考虑I/O的性能和效率，对代码算法进行充分优化，避免过多无效的循

环，或是一些无意义的I/O。

从网络架构，应综合考虑到系统读取信号的时延、损耗等情况，做好链路损耗预算。

（3）结合软件开发的各个模块功能所处理的任务相应地考虑时间和空间的开销/收益，应该结合不

同数据结构的优缺点来设计相应的算法。

（3）应根据实际的电力业务场景需求，先完成算法的代码编写后，不断调整数据结构和优化算法

来验证最高效的数据结构和算法。从设计流程上应该先完成全局数据结构和算法设计，再进行局部设计。

（4）基于电力业务的复杂性，对性能和效率都有极高追求的情况下，应选择最合适的算法，不一

定是最先进的，更多的应该结合实际业务场景自行设计。

4.4视图设计原则

4.4.1视图简单性原则

视图设计尽量保证其简单性，针对经被使用的查询应定义为视图，避免每次操作都反复指定所有条

件。

4.4.2视图安全性原则

能访问视图的用户应只能查询和修改授权所能见到的数据，应把用户限制在不同的子集上：

（1）基表的行的子集上。

（2）基表的列的子集上。

（3）基表的行和列的子集上。

（4）多个基表的连接所限定的行上。

（5）基表的数据的统计汇总上。

（6）另一行视图的一个子集上，或是一些视图和基表合并后的子集上。

4.4.3逻辑数据独立性

视图可以在以下几个方面使程序与数据独立：

（1）应用建立在数据库表上，当数据库表发生变化时，应表上建立视图，通过视图屏蔽表的变化，

16

T/GDEA001.1—2022

从而应用程序可以不动。

（2）应用建立在数据库表上，当应用发生变化时，应表上建立视图，通过视图屏蔽应用的变化，

从而使数据库表不动。

（3）应用建立在视图上，当数据库表发生变化时，应表上修改视图，通过视图屏蔽表的变化，从

而应用程序可以不动。

（4）应用建立在视图上，当应用发生变化时，应表上修改视图，通过视图屏蔽应用的变化，从而

使数据库表不动。

4.5信息系统安全设计规范

在信息系统设计过程中，应根据安全目标进行安全设计，在符合信息化架构规划的基础上，确保安

全功能的完整实现，在安全设计中应遵循原则：

（1）保护最薄弱环节原则，保护最易受攻击影响的部分；

（2）纵深防御原则，不同层面，不同角度之间需要最小权限；

（3）最小权限原则，只授予执行操作所需的最小权限；

（4）权限分离原则，授予不同用户所需的最小权限，并在不同用户之间形成相互制约的关系；

（5）安全设计中应确定安全体系架构，设计安全协议和安全接口；

（6）安全设计中应确定访问控制与身份鉴别机制，定义主体角色和权限；

（7）安全设计中应包含数据结构安全设计，选择加密方法和算法；

（8）安全设计中应确定敏感数据保护方法；

（9）安全设计中应设计内部处理逻辑安全；

（10）安全设计中应评估内部通信机制，确定完整机制；

（11）安全设计中应评估内部通信机制，确定完整机制；

5总体要求

5.1总体需求

5.1.1需求调研标准

基本要求

（1）业务流程中的每个环节应细化至无法再分解。

（2）业务流程中的每个环节主要角色对象应明确出来。

17

T/GDEA001.1—2022

（3）业务流程中的每个输入（业务单元、格式、方式）和输出（业务单元、格式、方式）方式应

详细列出。

（4）业务流程中的每个输入、输出之间的变化或关系需要一一对应。

（5）业务流程中的每个输入应有明确数据源。

（6）业务流程中的每个输出应有明确数据流向。

（7）明确业务流程中的每个数据元应遵循的国家标准等。

（8）明确业务流程中每个数据元的类型。

（9）业务流程中的每个环节主要角色应有明确权限配置（如：可新建、可删除、可修改、只读）。

（10）业务流程中的每个环节数据输入应一一对应有校验规则。

（11）明确业务流程中每个环节流转的触发条件。

（12）明确业务流程中每个环节流转的时间约束条件及指标值。

（13）明确业务表单和业务流程的对应关系。

（14）明确业务表单之间的关联和继承关系。

5.1.2需求分析标准

基本要求

（1）定义需求基线，确定必须实现的功能。

（2）每一项需求应有与其对应的设计、源代码和测试用例，并且可追踪。

（3）系统建设计划与需求保持一致。

（4）需求分析过程发生的变更，应有其所产生的影响提出新的需求约定。即对需求可能造成的不

稳定变化有相应的判断和管理机制。

（5）对于需求变更申请，应有每项变更所产生的影响评估分析，有相应的需求变更管控流程对变

更进行约束。

（6）需求变更融入原有需求基线中时，要有控制方式。

（7）应建立系统建设过程的需求变化追踪机制。

（8）目标方案下发征求意见稿至各级、各专业域。经各级、各专业域确认后纳入电力信息化建设

需求库。

（9）有明确的软硬件资源需求。

5.1.3需求规格说明书编制标准

18

T/GDEA001.1—2022

详见8.1附录一

5.1.4业务模型说明书编制标准

详见8.2附录二

5.2系统设计要求

5.2.1电力信息系统架构设计标准

电力信息系统建设的架构设计及涉及了业务架构和应用架构两部分，目前电力信息系统均有自己的

企业架构（EA），本标准着重于对电力信息系统架构设计过程提供参考依据和设计原则。

电力信息系统架构设计模型

对电力信息系统的系统架构设计应参照如下模型。参考《信息系统架构框架》Zachman框架；

数据功能网络角色时间原因

对业务最关业务活动流业务运行所业务组织业务活动时业务目标

范围

键的元素程在地点架构间周期和战略

基于角色

业务流程模

的组织层业务主进度

业务模型实体关系图型（物理数业务网络业务规划

次图、工表

据模型图）

作流模型

关应用架相依关系

信息系统构、分布系统架人机接口图、业务标准

数据模型

模型关键数据流构架构数据实体生模型

程图命历程

系统设计、用户界“控制流”

数据架构、系统架构业务标准

技术模型结构图、伪面、安全图（控制结

遗产数据图（软硬件）设计

代码设计构）

数据设计屏幕显

详细程序设时间、周期程序逻辑

详细展现（反规范网络架构示、安全

计定义的角色说明

化）、物流机构

19

T/GDEA001.1—2022

存储器设计

转化后的数受训的人

功能系统可执行程序通信设备企业业务强制标准

据员

电力信息系统架构设计参照上述模型，从业务范围开始逐步梳理，先构建好业务架构再逐步向技术

架构一层层递进；且在系统架构搭建过程应坚持使用业务架构做需求管控，避免在此过程的熵增把已经

构建好的架构秩序回归混沌。

电力信息系统架构设计流程标准

基于电力信息系统架构设计模型，系统架构设计应参照如下流程开展每个环节的设计工作。但不能

局限于需求调研分析，应在需求调研分析的结果基础上深入设计业务架构；业务架构只受根本的电力业

务体系变化干扰，因此业务架构设计人员应具备识别出不断新增引入的业务需求是属于根本业务变更

还是由业务分支变化产生的；

系统架构设计贯穿项目的业务模型设计和系统设计阶段。系统架构设计工作包括业务架构、应用架

构、数据架构和技术架构的设计四个方面，输出《业务模型设计说明书》、《需求规格说明书》、《概

要设计》和《数据库设计说明书》。

系统架构设计

需求调研需求分析系统设计系统开发或

实施

编制业务需设计业务模型概要设计、详细设计

求报告分析信息化需求

业务模型设计概要设计

说明书

业务需求需求规格详细设计（数

调研报告说明书据库设计部分）

应用架构设计

业务架构设计数据架构设计

技术架构设计

系统架构设计的具体内容如下：

（1）业务架构：遵从总体架构业务架构设计成果，确定业务域、业务分类及业务流程及其协作关

系；并设计业务活动、需求规格。

（2）应用架构：遵从总体应用架构设计成果，确定业务域、应用、应用模块和交互关系；设计应

用功能、应用组件及应用集成。

20

T/GDEA001.1—2022

（3）数据架构：遵从总体数据架构设计成果，确定数据域、数据主题、概念实体和数据分布关系；

设计逻辑实体、物理实体和数据流转关系。

（4）技术架构：确定对技术平台及基础设施的需求，设计部署单元和部署节点。

电力信息系统架构设计管理组织标准

管理角色角色定位管理职责

由电力业务战

略管理和信息（1）决策企业架构管理中的重大事项；

业务归口管

系统建设的决（2）协调企业架构管理中的重大问题；

理

策者共同担任（3）审批架构资产。

此角色

由熟悉电力业（1）建设企业架构管理队伍；

务体系、职能（2）组织开展企业架构设计和企业架构管控工作；

架构管理决

体系、技术体（3）组织协调解决跨业务领域的协同问题；

策

系的管理人员（4）组织协调跨系统的集成问题；

担任（5）审核架构资产。

（1）设计业务架构；

（2）提出业务架构更新需求。

（3）归集业务架构成果，设计应用架构、数据架构、技术架构，

更新业务架构、应用架构、数据架构和技术架构；

由熟悉电力业

架构管理实（4）设计企业架构管控体系；

务活动、技术

施（5）审查系统架构；

架构的

（6）组织应用系统、平台系统建设项目组归集系统架构设计成

果；

（7）组织企业架构宣贯和培训；

（8）组织各分子公司开展本单位总体架构现状的梳理、更新。

熟悉总体业务

架构现状，熟（1）参与企业架构培训和架构人才团队建设

分支业务

悉电力业务活（2）依照总体架构蓝图和现状编写企业架构差异分析报告。

动

系统运维系统运维人员（1）按照系统架构设计业务指导书设计、归集和更新系统架构；

21

T/GDEA001.1—2022

（2）配合系统架构合规性管控

系统架构关键输入遵从形态

业务模型设计-业务域总体架构-业务域遵从

业务模型设计-业务分类总体架构-业务分类遵从

业务模型设计-业务流程总体架构-业务流程遵从

业务架构

业务模型设计-业务活动系统架构-业务流程细化

业务模型设计-业务对象总体架构-业务对象细化

业务模型设计-需求规格业务模型设计-业务活动参照

系统设计-应用域总体架构-应用域遵从

系统设计-应用总体架构-应用遵从

系统设计-应用系统总体架构-应用系统遵从

系统设计-应用模块总体架构-应用模块遵从

应用架构系统设计-应用功能系统架构-应用模块细化

系统设计-应用组件系统设计-应用功能细化

系统设计-角色总体架构-组织单元参照

系统设计-交互总体架构-交互遵从

系统设计-集成场景系统设计-交互细化

系统设计-数据域总体架构-数据域遵从

系统设计-数据主题总体架构-数据主题遵从

系统设计-概念实体总体架构-概念实体遵从

数据架构系统设计-逻辑实体系统架构-概念实体细化

系统设计-物理实体系统设计-逻辑实体细化

系统设计-数据分布总体架构-数据分布遵从

系统设计-数据流转系统架构-数据分布细化

系统架构-部署单元系统架构-应用组件参照

技术架构

系统架构-部署节点系统架构-硬件参照

5.2.2电力信息系统架构设计流程及规范

22

T/GDEA001.1—2022

业务架构设计规范

设计环节输入过程输出

业务发展战略形成全面完善的业务域业务域架构体系

业务域

职能战略形成全面完善的职能体系职能架构体系

业务域架构体系形成一级、二级业务分类一级、二级业务分类

业务分类电力行业业务分类模基于电力业务模型梳理业务业务分类协作对应

型协作关系表

一级、二级业务分类梳理业务流程细化后的业务流程

业务流程国家、行业标准、规范

梳理业务流程协作关系业务流程协作关系

业务分类协作对应表

组织架构业务组织架构梳理组织架构中的岗位职责组织架构职能

角色分工架构角色梳理组织架构中的角色分工角色职责分工

应用架构设计规范

设计环节输入过程输出

根据业务耦合程度划分应用

业务架构

域

应用域应用域架构体系

根据规划对应用域划分进行

电力信息化规划

完善

业务架构根据业务架构和应用域，设

应用业务应用体系

应用域计对应的支撑应用

分析一级、二级业务分类及

业务架构

业务流程

应用模块业务应用模块

对应上述业务流程设计一

应用

级、二级应用模块

根据应用间耦合关系，设计

应用应用系统体系

应用系统

应用系统

设计应用系统所需的应用模

应用模块应用模块集成体系

块集成

应用交互业务分类基于业务分类梳理业务间的应用交互体系

23

T/GDEA001.1—2022

协作交互点

根据业务协作交互点确认应

业务流程

用交互点

分析应用交互点的源头和目

应用功能

标信息

把应用交互点转化为概念实

概念实体

体

角色分工架构角色梳理组织架构中的角色分工角色职责分工

数据架构设计规范

设计环节输入过程输出

继承业务架构，梳理跨业务

业务架构

域的数据域覆盖面

数据域参照IEC-CIM模型的数据分通用数据域表

IEC-CIM模型类方式区分电力设备、电网、

客户等数据域分类

针对业务分类下所涉及的业

数据域务对象唯一的情况，数据主题数据主题表

的划分与业务分类一致

数据主题

针对业务分类下所涉及的业

业务分类对应的

业务架构务对象不唯一的情况，按照业

数据主题

务耦合度划分数据主题

数据主题出发，识别业务流

业务架构程中的业务对象，设计概念实概念数据实体

体

概念实体设计遵循以下指导

概念实体准则：

1）业务输入：遵循业务对象

IEC-CIM模型概念实体表

的设计成果，识别支撑每个业

务对象的概念数据实体。

2）数据抽象：概念数据实体

24

T/GDEA001.1—2022

只包含最核心、最重要的业务

概念。

3）技术过滤：筛选定义出具

备业务性的概念数据实体，过

滤掉属于技术特性的数据实

体。

4）唯一性：概念数据实体只

能出现一次。

借鉴成熟模型：借鉴IEC-