【国家标准(GB)】 电子政务系统总体设计要求

ICS35.240.01
中华人民共和国国家标准
GB/T21064—2007
电子政务系统总体设计要求
System general design requirements for electronic government2007-09-10发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2008-03-01实施
GB/T21064—2007
1范围
2规范性引用文件
3术语和定义
一般要求
4.1系统总体设计目标
4.2系统总体设计开展时机
4.3系统总体设计范围
4.4与系统总体设计相关的电子政务特点5系统总体设计要素
5.1需求分析
5.2系统体系结构设计
6系统总体设计实施方法
6.1系统总体设计过程
6.2系统总体设计中使用的方法
6.3系统总体设计要素选用
6.4系统总体设计方案
附录A（资料性附录）
附录B（资料性附录）
业务组织结构
系统业务功能
部门业务关系
系统信息资源
技术体系框架
系统构成
系统运行模式
构件接口关系
B.10系统部署形式
附录C（资料性附录）
附录D（资料性附录）
参考文献
系统总体设计过程
系统总体设计中使用的方法
系统总体设计要素选用指南
《系统总体设计方案》编写要求10
本标准的附录A、附录B、附录C和附录D是资料性附录。本标准由国家电子政务标准化总体组提出。本标准由国家电子政务标准化总体组归口。GB/T21064—2007
本标准的主要起草单位：中国电子科技集团公司信息化工程总体研究中心、中国电子技术标准化研究所、中国科学院沈阳自动化研究所、太极软件有限公司和华迪计算机有限公司。本标准主要起草人：夏耘、林华、张春晖、吴志刚、高展、于跃、吴兵峰、高栋、傅智杰、姜瑜涛。I
GB/T21064—2007
电子政务系统已在全国范围内大量建设，但还没有完整的、规范的电子政务系统总体设计作为系统建设的依据，为此提出了制定本标准的要求。电子政务系统总体设计是顶层框架性设计，对于电子政务系统的一体化方案设计至关重要，它将限定和约束其组成部分的实现，是使其形成一个有机整体的必要保证，也是电子政务系统集成和验收的依据。
制定本标准的目的是：规范总体设计活动，提高总体设计的质量与效率，规范总体设计的结果表现，使相关业务和技术人员用共同的方式表达和理解系统；明确系统的总体结构，便于系统的分阶段建设，以及各组成部分的实施与集成。从而支撑政务活动的信息化，提高业务协同和信息共享程度。1范围
电子政务系统总体设计要求
本标准规定了电子政务系统总体设计的要素构成，本标准对总体设计要索选用以及总体设计中使用的方法给出了指导性意见GB/T21064—2007
本标准适用于电子政务系统的总体设计，包括系统顶层需求分析和系统体系结构设计。其他信息系统的总体设计可参照使用。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注目期的引用文件，其最新版本适用于本标准。GB/T8567—2006计算机软件文档编制规范GB/T19487—2004电子政务业务流程设计方法通用规范3术语和定义
下列术语和定义适用于本标准。3.1
gsystemarchitecture
系统体系结构
一个系统的基本组织，表现为系统的构件、构件之间的相互关系、构件与环境之间的相互关系以及设计和进化的原理。
构件component
系统的组成部分，可以是子系统、硬件部分或软件部分。4一般要求
4.1系统总体设计目标
电子政务系统总体设计的自标是：确定系统所支撑的政务活动的范畴，明确系统在其所属电子政务框架中的位置与作用，给出满足系统需求的一种解决方案，确保电子政务系统的无缝集成和预期目标的实现。
4.2系统总体设计开展时机
在进行大中型或综合性（含多种软件和/或硬件成分）电子政务系统建设时，应按照业务应用的要求，在下述时机开展系统总体设计：a）在编制项目建议书和可行性研究报告时进行立项阶段系统总体设计：b）在批准立项后进行实施阶段系统总体设计。立项阶段系统总体设计与实施阶段系统总体设计应具有连续性和继承性。根据实际情况，可将其简化为一个过程。
4.3系统总体设计范围
系统总体设计范围包括系统需求分析和系统体系结构设计两方面：a）系统需求分析要素
GB/T21064—2007
业务组织结构；
2）系统业务功能；
部门业务关系；
系统信息资源；
安全保密要求；
系统性能要求；
7）系统设施与环境要求；
系统质量要求；
标准与规范要求；
10）系统验收要求。
b）电子政务系统总体设计的系统体系结构设计要素技术体系框架；
2）系统设计策略；
3）系统构成；
4）系统运行模式；
构件接口关系；
6）系统部署形式。
4.4与系统总体设计相关的电子政务特点电子政务系统建设应充分考虑下述特点，以便在系统投人使用后能够发挥其应有的作用：a）
整体性：电子政务是一个复杂的系统工程，需要从整体出发提出解决方案，系统的建设需遵循整体规划要求，注重整体效能的发挥。协同性：电子政务需要不同部门的协同配合，需要跨域运作和资源整合。进行系统总体设计b）
时应具有系统的集成能力、信息共享和交换能力、外部接口能力以及对标准规范的支持能力。阶段性：电子政务工程的建设是一个持续不断的过程，其系统总体设计需注重总体目标的实c）
现，并合理规划阶段的建设目标，为后续建设奠定可延续的基础。d)
继承性：电子政务工程应在完成阶段性目标的基础上逐步实现总体目标，充分利用已有的成果，为公众提供连续的服务。
安全性：电子政务的信息安全至关重要，影响到政治安全、国家安全、经济安全和社会安全。进e)
行系统总体设计时应注重信息的保密、完整、可用的需求及实现。服务性：电子政务服务主要包括面向公众、企事业单位和政府的各种服务。进行系统总体设计f
时应注重服务的能力、服务的方式以及服务的实现原则。5系统总体设计要素
5.1需求分析
5.1.1业务组织结构
业务组织结构将标识出系统的使用者，是业务功能的部署单位。对业务系统中所涉及的组织结构的分析应包括组成范围、工作职责及各组织单元之间的关系。5.1.2系统业务功能
系统业务功能是系统能力的重要体现，是用户直接可见的部分，也是系统分析设计的基础。系统业务功能要素中包括系统应具有的各项功能要求、业务流程以及系统的处理范围，说明如下：a）将功能分类，形成功能集合或功能子系统，并逐项整理各项功能，分类方法可以组织结构或功能的关联性为依据；
按业务流程表述业务输入的信息、处理的过程、所需的数据、涉及的角色以及输出的结果；2
GB/T21064—2007
）通过上述分析，确定系统的处理范围，标识出系统具有的功能以及涉及的外部角色，外部角色可以是外部系统、各种类型用户或外部设备5.1.3部门业务关系
通过对业务流程的分析，明确部门间的业务协同关系。部门间的协同关系主要表现为指示与汇报、请求与服务、信息共享与交换。应给出协同业务名称、协同类型、协同发起部门、协同响应部门及协同描述等，说明如下：
a）协同业务名称，标识各协同关系；b）协同类型，如指示与汇报、请求与服务、信息共享与交换等；c）协同发起部门，即服务的请求方、信息的发送或提供方；d)t
协同应部门，即服务的响应方、信息的接收或读最方；e）协同描述，从业务应用的角度简要描述服务的内容或共享信息的作用。5.1.4系统信息资源
全面分析系统引入或产生的信息资源，包括信息资源清单、数据描述，接口要求、数据流程及信息管理要求等，说明如下：
a）信息资源清单，包括信息资源名称、分类、来源及主要用途等；b）数据描述，对主要数据内容进行简要描述，包括名称、数据类型、格式、单位、范围等，可引用其他文档（如：数据字典、通信协议标准、用户接口标准）；e)
接口要求，包括信息传输、WEB页面、API调用等接口方式及限定条件：d）数据流程，包括系统对引入信息的数据使用过程，以及系统产生信息的数据加工过程；e）信息管理要求，包括信息的采集、更新，管理的职责、方式和要求，5.1.5
安全保密要求
系统的安全保密遵循电子政务保密标准体系的要求，应包括以下几个方面：a）系统安全要求；
b）信息安全等级要求；
c）系统容灾备份要求；
d）系统应急使用要求，
e）系统使用限定；
数据存储与传输的保密约束。
5.1.6系统性能要求
5.1.6.1性能指标
系统性能将影响系统使用的效果、系统资源的需求和系统设计的策略，应给出明确的性能指标规定。系统性能包括系统工作效率指标、信息共享能力、信息维护能力、系统使用能力等，说明如下：a）系统工作效率指标，可包括系统启动时间、各种响应时间、业务周转时间等；b）信息访问能力，可包括信息访问最大用户数、信息交互用户数等；c）信息维护能力，可包括信息的准确率、完整率、更新周期、更新及时率等；d）系统使用能力，可包括可持续使用时间、容量、吞吐量或速率等。5.1.6.2性能指标详细说明
性能指标的详细说明如下：
a）启动时间，即启动系统或应用所需的时间；b）响应时间，即系统响应一项规定的操作所需的时间，可包括平均响应时间和最大响应时间；周转时间，即从发出一条指令开始到一组相关的功能完成，所经历的等待时间，可包括平均周转时间和最大周转时间；
d）信息访问最大用户数，即允许对系统同时进行信息访问的最大用户数量；3
GB/T21064—2007
信息交互用户数，即发生信息交互关系的用户数量；信息准确率，即信息正确的项数与信息总项数之比；信息完整率，即信息已采集项数与应采集项数之比；信息更新周期，即需随时间变化的信息对其进行修改的时间间隔；信息更新及时率，即在规定的周期内及时更新的项数与需更新总项数之比；i）
可持续使用时间，即保持连续不间断使用的最短时间；k）
容量，如允许用户数、数据存储量、信道容量等：1)
吞吐量或速率，即在给定的时间周期内成功执行的数量。5.1.7系统设施与环境要求
5.1.7.1系统设施要求
系统设施要求包括使用或引人到系统中的硬件、软件及系统设备连接方式要求。对系统设施进行规划的依据是系统业务功能、系统信息资源、安全保密要求及系统性能要求，应指明它们之间的导出关系。
a）系统使用或引人到系统中的硬件要求，包括：1）计算机与服务器；
输入/输出及存储设备；
网络与通信设备；
4）自动服务设备；
5）其他所需的设备。
应给出每种设备的类型、数量、特征及能力要求。b）系统使用或引入到系统中的软件要求，包括：1）操作系统、数据库管理系统；2）
通信及网络软件；
实用软件；
4）输入和设备模拟器；
5）测试软件等。
需要时可提出系统物理连接方式要求，包括连接的地理位置、设备配置和网络拓扑结构、网关等。5.1.7.2系统环境要求
系统运行必须的环境要求包括系统在运输、存储、操作过程中必须经受的环境条件，如：自然环境条件，风、雨、温度、湿度、盐雾等；a)
b）诱导环境，运动、撞击、噪音、电磁辐射等。对于车载式、活动式系统或基础设施类系统必须提出系统环境要求。5.1.8系统质量要求
系统质量方面的要求包括以下内容：适应性要求，系统运行所依赖的数据环境（如现场的位置、数据记录的参数等）；a
可重用性要求，可被多个应用使用的要求；b)
可靠性要求，系统不发生故障及故障发生后的处置要求；c
维护性要求，发生问题后易于改正的要求；可移植性要求，易于改进以适应新环境的要求；e
易用性要求，易于学习和使用的要求。5.1.9
标准与规范要求
为了使系统符合电子政务整体框架的要求并能有机集成，必须规定应遵循的技术标准体系，如工程管理、网络建设、信息共享、支撑技术、信息安全等方面的标准化要求。4
GB/T21064--2007
在规定通用标准和规范的同时还需规定特殊体系结构的约束（必须采用标准构件、已有构件或用户提供的构件）、特殊设计或实现标准的使用要求。5.1.10系统验收要求
应规定系统验收时的接收条件和检验方法，确保系统建设的质量。a）系统接收条件可包括：
通过具有认证资格的第三方测评；1
通过一定周期的典型用户试用；3）
通过规定周期的系统试运行；
通过指定级别的评审或审查。
b）在进行测评、试用、试运行、评审或审查时，可采用以下检验方法：1）演示：运行依赖于可见的功能操作的系统或部分系统，不需要使用仪器、特殊的测试设备或进行事后分析；
检测：使用仪器或其他特殊的检测设备运行系统或系统的组成部分，以便采集数据供事2）
后分析使用；
分析：对从其他检验方法中获得的积累数据进行处理，例如测试结果的归纳、解释、推断；3）
审查：对系统构件、文档等进行可视化检查；4）
特殊的检验方法：系统的任何特殊合格性方法，如特殊工具、技术、过程、设施、验收限制52
及标准样例的使用。
5.2系统体系结构设计
5.2.1技术体系框架
信息系统涉及网络、通信、计算机、系统软件、应用软件等各种相关技术，技术体系框架将从总体上描述不同类型技术构建信息系统的规则和方法，标识出各服务领域及其接口，实现开放系统的分离原则。技术体系框架需要反映以下一些共性内容：a）服务领域的层次结构；
b）服务领域的主题内容与组成；c）服务领域之间的相互关系；
d）与外部的接口。
5.2.2系统设计策略
系统设计策略指为达到系统性能、安全保密能力以及为提供所需的可靠性、可重用性、维护性和可移植性等质量特性而选择的方法，或关键技术实现及其他影响系统组成成分的设计决策。这些策略是系统设计必须遵循的原则，在进行系统总体设计时应首先确定。给出设计策略的同时还需说明设计策略与依据的需求之间的符合性。系统设计策略一般应包括：
a）性能实现设计策略；
b）安全保密设计策略；
c）可靠性设计策略；
d）质量特性实现设计策略；
e）关键技术设计策略等。
5.2.3系统构成
对系统进行分解，划分为若干子系统或硬件构件和软件构件，并将系统功能、性能等需求逐步落实到每个子系统或构件中，分解后的构件存在着关联关系，确定系统组成时应明确以下内容：a）子系统或硬件构件和软件构件的构成及其功能；b）构件间的静态关系、关系的种类及必要说明；系统构件的获取途径，如新开发的构件、重用的构件、集成的构件、采购的构件等。5
GB/T21064—2007
5.2.4系统运行模式
系统运行模式从技术角度反映目标系统的运转方式。构件之间的运行模式是构件之间的动态关系，如执行控制流、数据流、动态控制序列、状态转换、时序关系、中断处理、异常处理、并发执行等。运行模式可包含以下内容：
a）系统初始化模式；
b）系统管理模式；
系统维护模式；
d）系统服务模式；
关键性业务处理模式。
5.2.5构件接口关系
构件接口关系确定构件为其他构件提供的服务是构件静态关系的具体化，重点描述技术体系框架中各层为上层应用提供服务的内容和方式，以及同层业务中交互的信息及交互方式。应明确接口的信息内容、信息流向、信息用途、接口实体、接口类型、接口特性及遵循的标准或协议，说明如下：接口关系，可按照信息种类或接口类型分类整理；a)
信息种类，可按业务类型或载体形式进行区分；b）
信息内容，包括名称/标识符、类型、格式、单位、范围等，可引用其他文档（如：数据字典、通信协c）
议标准、用户接口标准）；
信息流向，表明信息的发送者/产生者和接收者/使用者；d)
接口实体，即交换信息的实体，包括外部系统、各种类型用户或组成构件：e
接口类型，如消息传递、数据传输、查询服务、WEB页面、中间件等；f)
接口特性，包括优先级别、时序、频率、容量、序列及其他约束条件，如：是否能更新、是否应用g）
业务规则。
5.2.6系统部署形式
系统部署是确定其组成部分的物理位置及连接关系，包括硬件部署和软件部署。系统部署与业务组织结构和应用模式密切相关。硬件部署是对系统所涉及到的硬件设备进行物理布局的规划，并给出网络拓扑结构。软件部署是对系统所涉及到的各类软件构件进行物理配置的规划。6系统总体设计实施方法
6.1系统总体设计过程
为了确定系统总体设计要素，需开展相应的活动，这些活动的有序开展构成了系统总体设计过程。本标准的附录A给出了电子政务系统总体设计中推荐使用的过程。系统可根据实际情况对活动进行选用。6.2系统总体设计中使用的方法
在系统总体设计过程中，各相关要素的分析可使用多种方法。本标准的附录B给出了电子政务系统总体设计过程中推荐使用的一些分析方法，并给出了重点要索的描述模型。描述模型只规定了应具有的基本特征，可以在此基础上扩展和演变。6.3系统总体设计要素选用
对于不同类型的电子政务系统以及不同阶段的总体设计，其涵盖的要素可不同。系统总体设计要素选用的推荐方法参见附录C。
6.4系统总体设计方案
电子政务系统总体设计的结果应形成系统总体设计方案文档，其内容要求参见附录D。系统需求的描述应全面、完整和准确。体系结构设计应描述目标系统的组成结构和实现方法，充分体现与需求的符合性。设计结构应合理，实现方法应可行，并符合相关技术标准的要求。6
附录A
（资料性附录）
系统总体设计过程
GB/T21064—2007
系统总体设计过程可以根据情况采用不同的过程，本标准中推荐以下三种过程：完整过程，包括立项阶段系统总体设计和实施阶段系统总体设计两个组成部分，需求分析过程a
包含在其中，此过程适合于大中型、综合性或复杂系统；b)
单步过程，只进行一次总体设计，此过程适合于小型的、简单的或需求明确、实现方案确定的系统；分步过程，包括立项阶段系统总体设计和实施阶段系统总体设计两个组成部分，需求分析过程作为独立的过程开展，此过程适合于大中型、综合性或复杂系统。上述三种系统总体设计过程所包含的活动见表A1。项目可根据具体情况选择其中的过程。过程中各项活动可以是顺序的，也允许局部反复或循环反复。表A，1中，“立项阶段系统总体设计”未详细展开，其过程可参见“实施阶段系统总体设计”部分。表A.1系统总体设计过程
系统总体设计活动
立项阶段
系统总体
实施阶段
系统总体
实施阶段wwW.bzxz.Net
系统总体
确定系统（初步）需求
确定系统(初步)体系结构
形成(初步)总体设计文档
明确业务组织结构
确定业务功能要求
梳理业务流程
界定业务功能范围
明确部门业务关系
确定系统信息资源
给出安全保密要求
给出系统性能要求
给出系统设施与环境
给出系统质量要求
给出标准与规范要求
给出系统验收要求
确定技术体系框架
确定系统设计策略
确定系统构成
确定系统运行模式
确定构件接口关系
确定系统部署形式
形成系统总体设计文档
完整过程
确定系统初步需求
确定系统初步体系结构
系统初步总体设计方案
系统总体设计方案
单步过程
确定系统需求
确定系统体系结构
系统总体设计方案
分步过程
确定系统初步需求
确定系统初步体系结构
系统初步总体设计方案
（通过独立的系统需求
分析过程形成了《系统
需求规格说明》或等同
文档）
系统总体设计方案
注：“/\表示在过程中可包含该活动，但对于不同类型的系统是否需要该活动参见附录B。7
GB/T21064—2007
B.1概述
附录B
（资料性附录）
系统总体设计中使用的方法
系统总体设计过程中，各相关要素的分析可采用多种方法，如GB/T19487—2004、UML、IDEF0中的描述模型均适用。本附录将给出重点要素的分析方法和描述模型，使用时可对措述模型中的图形表现进行演变，对于这些描述模型可选择相应的支持工具。重点要素包括业务组织结构、系统业务功能、部门业务关系、系统信息资源、技术体系框架、系统构成、系统运行模式、构件接口关系和系统部署。B.2业务组织结构
B.2.1分析方法
组织具有名称标识、工作职责和关系属性。根据目标系统拟采用的组织形式，寻找出所有可能涉及的部门，确定每个组织部门的岗位及其工作职责，梳理这些部门间的关系。部门间的关系可以为从属关系、协同关系或其他特定关系。各组织部门的岗位在功能描述中应作为系统的外部角色或内部角色出现，所具有的工作职责应反映在与之接口的对象中；在系统部署中应作为其组成单元的部署实体。B.2.2描述模型
业务组织结构的组成和关系可通过组织结构图直观地描述，工作职责和关系以配属文字进行说明。组织结构图模板见图B.1。
X组织机构
部门1
岗位1
图中：
岗位n
部门m
方框表示组织部门；
方框间的连线表示组织间的关系，可使用不同颜色或线型表示不同的关系类型。图B.1组织结构图模板
B.3系统业务功能
B.3.1分析方法
系统业务功能分析时，需确定系统应具有的业务功能和处理范围，同时还需对系统业务流程进行梳理。系统业务功能是系统实现特定业务目的的能力。功能是可分解的，为了不同目的所描述的粒度和角度也不同。功能具有名称标识、内容描述和关系等属性。需求分析过程中，从用户使用角度描述所具有的各项功能，一般可将功能分解为2～3个层次，功能与部门和角色直接关联。在需求分析过程中功能间的关系无需定义类型，只表示存在关系，在后续的体系结构设计过程中再确定关系的类型。系统业务功能的全集构成系统的业务功能范围。8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。