电子政务系统总体设计要求内容文档格式.docx

电子政务系统总体设计要求内容文档格式.docx

《电子政务系统总体设计要求内容文档格式.docx》由会员分享，可在线阅读，更多相关《电子政务系统总体设计要求内容文档格式.docx（36页珍藏版）》请在冰豆网上搜索。

1）业务组织结构；

2）系统业务功能；

3）部门业务关系；

4）系统信息资源；

5）安全保密要求；

6）系统性能要求；

7）系统设施与环境要求；

8）系统质量要求；

9）标准与规范要求；

10）系统验收要求。

b）电子政务系统总体设计的系统体系结构设计要素

1）技术体系框架；

2）系统设计策略；

3）系统构成；

4）系统运行模式；

5）构件接口关系；

6）系统部署形式．

4.4与系统总体设计相关的电子政务特点

电子政务系统建设应充分考虑下述特点，以便在系统投入使用后能够发挥其应有的作用：

a）整体性：

电子政务是一个复杂的系统工程，需要从整体出发提出解决方案，系统的建设需遵循整体规划要求，注重整体效能的发挥。

b）协同性；

电子致务需要不同部门的协同配合，需要跨域运作和资源整合。

进行系统总体设计时应具有系统的集成能力、信息共享和交换能力、外部接口能力以及对标准规范的支持能力。

c）阶段性：

电子攻务工程的建设是一个持续不断的过程，其系统总体设计需注重总体目标的实现，并合理规划阶段的建设目标，为后续建设奠定可延续的基础。

d）继承性：

电子政务工程应在完成阶段性目标的基础上逐步实现总体目标，充分利用已有的成果，为公众提供连续的服务。

e）安全性：

电子政务的信息安全至关重要，影响到政治安全、国家安全、经济安全和社会安全。

进行系统总体设计时应注重信息的保密、完整、可用的需求及实现。

f）服务性：

电子政务服务主要包括面向公众、企事业单位和政府的各种服务。

进行系统总体设计时应注重服务的能力、服务的方式以及服务的实现原则。

5 

系统总体设计要素

5.1需求分析

5.1.1业务组织结构

业务组织结构将标识出系统的使用者，是业务功能的部署单位。

对业务系统中所涉及的组织结构的分析应包括组成范围、工作职责及各组织单元之间的关系。

5.1.2系统业黄功能

系统业务功能是系统能力的重要体现，是用户直接可见的部分，也是系统分析设计的基础。

系统业务功能要素中包括系统应具有的各项功能要求、业务流程以及系统的处理范围，说明如下：

a）将功能分类，形成功能集合或功能子系统，并逐项整理各项功能，分类方法可以组织结构或功能的关联性为依据；

b）按业务流程表述业务输入的信息、处理的过程、所需的数据、涉及的角色以及输出的结果；

c）通过上述分析，确定系统的处理范围，标识出系统具有的功能以及涉及的外部角色，外部角色可以是外部系统、各种类型用户或外部设备。

5.1.3部门业务关系

通过对业务流程的分析，明确部门间的业务协同关系。

部门间的协同关系主要表现为指示与汇报、请求与服务、信息共享与交换。

应给出协同业务名称、协同类型、协同发起部门、协同响应部门及协同描述等，说明如下：

a）协同业务名称，标识各协同关系；

b）协同类型，如指示与汇报、请求与服务、信息共享与交换等；

c）协同发起部门，即服务的请求方、信息的发送或提供方；

d）协同响应部门，即服务的响应方、信息的接收或读取方；

e）协同描述．从业务应用的角度简要描述服务的内容或共享信息的作用。

5.1.4系统信息资源

全面分析系统引入或产生的信息资源，包括信息资源清单、数据描述、接口要求、数据流程及信息管理要求等，说明如下：

a）信息资源清单，包括信息资源名称、分类、来源及主要用途等；

b）数据描述，对主要数据内容进行简要描述，包括名称、数据类型、格式、单位、范围等，可引用其他文档（如；

数据字典、通信协议标准、用户接口标准）；

c）接口要求，包括信息传输、WEB页面、API调用等接口方式及限定条件；

d）数据流程，包括系统对引入信息的数据使用过程，以及系统产生信息的数据加工过程；

e）信息管理要求，包括信息的采集、更新，管理的职责、方式和要求。

5.1.5安全保密要求

系统的安全保密遵循电子政务保密标准体系的要求，应包括以下几个方面：

a）系统安全要求；

b）信息安全等级要求；

c）系统容灾备份要求；

d）系统应急使用要求；

e）系统使用限定；

f）效据存储与传输的保密约束。

5.1.6系统性能要求

5.1.6.1性能指标

系统性能将影响系统使用的效果、系统资源的需求和系统设计的策略，应给出明确的性能指标规定．系统性能包括系统工作效率指标、信息共享能力、信息维护能力、系统使用能力等，说明如下：

a）系统工作效率指标，可包括系统启动时间、各种响应时间、业务周转时间等；

b）信息访问能力，可包括信息访问最大用户数、信息交互用户数等；

c）信息维护能力，可包括信息的准确率、完整率、更新周期、更新及时率等；

d）系统使用能力，可包括可持续使用时间、容量、吞吐量或速率等。

5.1.6.2性能指标详细说明

性能指标的详细说明如下：

a）启动时间，即启动系统或应用所需的时间；

b）响应时间，即系统响应一项规定的操作所需的时间，可包括平均响应时间和最大响应时间；

c）周转时间，即从发出一条指令开始到一组相关的功能完成，所经历的等待时间，可包括平均周转时间和最大周转时间；

d）信息访问最大用户数，即允许对系统同时进行信息访问的最大用户数量；

e）信息交互用户数，即发生信息交互关系的用户数量；

f）信息准确率，即信息正确的项效与信息总项数之比；

g）信息完整率，即信息已采集项数与应采集项数之比；

h）信息更新周期，即需随时间变化的信息对其进行修改的时间间隔；

i）信息更新及时率，即在规定的周期内及时更新的项数与需更新总项数之比；

j）可持续使用时间，即保持连续不间断使用的最短时间；

k）容量，如允许用户效、数据存储量、信道容量等；

1）吞吐量或速率，即在给定的时间周期内成功执行的数量。

5.1.7系统设施与环境要求

5.1.7.1系统设施要求

系统设旅要求包括使用或引入蓟系统中的硬件、软件及系统设备连接方式要求。

对系统设施进行规划的依据是系统业务功能、系统信息资源、安全保密要求及系统性能要求，应指明它们之间的导出关系．

a）系统使用或引入到系统中的硬件要求，包括：

1）计算机与服务器；

2）输入／输出及存储设备；

3）网络与通信设备；

4）自动服务设备；

5）其他所需的设备．

应给出每种设备的类型、数量、特征及能力要求。

b）系统使用或引入到系统中的软件要求，包括：

1）操作系统、数据库管理系统；

2）通信及同络软件；

3）实用软件，

4）输入和设备模拟器；

5）测试软件等。

需要时可提出系统物理连接方式要求，包括连接的地理位置、设备配置和网络拓扑结构、网关等。

5.1.7.2系统环境要求

系统运行必须的环境要求包括系统在运输、存储、操作过程中必须经受的环境条件，如：

a）自然环境条件，风、雨、温度、湿度、盐雾等；

b）诱导环境，运动、撞击、噪音、电磁辐射等，

对于车载式、活动式系统或基础设施类系统必须提出系统环境要求。

5.1.8系统质量要求

系统质量方面的要求包括以下内容：

a）适应性要求，系统运行所依赖的数据环境（如现场的位置、数据记录的参数等）；

b）可重用性要求，可被多个应用使用的要求；

c）可靠性要求，系统不发生故障及故障发生后的处置要求；

d）维护性要求，发生问题后易于改正的要求；

e）可移植性要求，易于改进以适应新环境的要求；

f）易用性要求，易于学习和使用的要求。

5.1.9标准与规范要求

为了使系统符合电子政务整体框架的要求并能有机集成，必须规定应遵循的技术标准体系，如工程管理、冈络建设、信息共享、支撑技术、信息安全等方面的标准化要求。

在规定通用标准和规范的同时还需规定特殊体系结构的约束（必须采用标准构件、已有构件或用户提供的构件）、特殊设计或实现标准的使用要求。

5.1.10系统验收要求

应规定系统验收时的接收条件和检验方法，确保系统建设的质量．

a） 

系统接收条件可包括：

1）通过具有认证资格的第三方测评；

2）通过一定周期的典型用户试用；

3）通过规定周期的系统试运行；

4）通过指定级别的评审或审查。

b）在进行测评、试用、试运行、评审或审查时，可采用以下检验方法：

1）演示：

运行依赖于可见的功能操作的系统或部分系统，不需要使用仪器、特殊的测试设备或进行事后分析；

2）检测：

使用仪器或其他特殊的检测设备运行系统或系统的组成部分，以便采集数据供事后分析使用；

3）分析：

对从其他检验方法中获得的积累数据进行处理，例如测试结果的归纳、解释、推断；

4）审查：

对系统构件、文档等进行可视化检查；

5）特殊的检验方法：

系统的任何特殊合格性方法，如特殊工具、技术、过程、设施、验收限制及标准样例的使用。

5.2系统体系结构设计

5.2.1技术体系框架

信息系统涉及网络、通信、计算机、系统软件、应用软件等各种相关技术，技术体系框架将从总体上描述不同类型技术构建信息系统的规则和方法，标识出各服务领域及其接口，实现开放系统的分离原则．技术体系框架需要反映以下一些共性内容：

a）服务领域的层次结构；

b）服务领域的主题内容与组成；

c）服务领域之同的相互关系；

d）与外部的接口．

5.2.2系统设计策略

系统设计策略指为达到系统性能、安全保密能力以及为提供所需的可靠性、可重用性、维护性和可移植性等质量特性而选择的方法，或关键技术实现及其他影响系统组成成分的设计决策。

这些策略是系统设计必须遵循的原则，在进行系统总体设计时应首先确定。

给出设计策略的同时还需说明设计策略与依据的需求之间的符合性。

系统设计策略一般应包括：

a）性能实现设计策略，

b）安全保密设计策略；

c）可靠性设计策略；

d）质量特性实现设计策略；

e）关键技术设计策略等。

5.2.3系统构成

对系统进行分解，划分为若干子系统或硬件构件和软件构件，并将系统功能、性能等需求逐步落实到每个子系统或构件中，分解后的构件存在着关联关系，确定系统组成时应明确以下内容：

a）子系统或硬件构件和软件构件的构成及其功能；

b）构件间的静态关系、关系的种类及必要说明；

c）系统构件的获取途径，如新开发的构件、重用的构件、集成的构件、采购的构件等。

5.2.4系统运行模式

系统运行模式从技术角度反映目标系统的运转方式．构件之间的运行模式是构件之间的动态关系，如执行控制漉、数据流、动态控镧序列、状态转换、时序关系、中断处理、异常处理、并发执行等。

运行模式可包含以下内容。

a）系统初始化模式；

b）系统管理模式；

c）系统维护模式；

d）系统服务模式；

e）关键性业务处理模式．

5.2.5构件接口关系

构件接口关系确定构件为其他构件提供的服务是构件静态关系的具体化，重点描述技术体系框架中各层为上层应用提供服务的内容和方式，以及同层业务中交互的信息及交互方式。

应明确接口的信息内容、信息流向、信息用途、接口实体、接口类型、接口特性及遵循的标准或协议，说明如下：

a）接口关系，可按照信息种类或接口类型分类整理；

b）信息种类，可按业务类型或载体形式进行区分；

c）信息内容，包括名称／标识符、类型、格式、单位、范围等，可引用其他文档（如：

d）信息流向，表明信息的发送者／产生者和接收者／使用者；

e）接口实体，即交换信息的实体，包括外部系统、各种类型用户或组成构件；

f）接口类塑，如消息传递、数据传输、查询服务、WEB页面、中间件等；

g）接口特性，包括优先级别、时序、频率、容量、序列及其他约束条件，如：

是否能更新、是否应用业务规则。

5.2.6系统部署形式

系统部署是确定其组成部分的物理位置及连接关系，包括硬件部署和软件部署．系统部署与业务组织结构和应用模式密切相关．

硬件部署是对系统所涉及到的硬件设备进行物理布局的规划，并给出网络拓扑结构．

软件部署是对系统所涉及蓟的各类软件构件进行物理配置的规划．

6系统总体设计实施方法 

6.1 

系统总体设计过程

为了确定系统总体设计要素-需开展相应的活动，这些活动的有序开展构成了系统总体设计过程．本标准的附录A给出了电子敢务系统总体设计中推荐使用的过程。

系统可根据实际情况对活动进行选用。

6.2系统总体设计中使用的方法

在系统总体设计过程中，各相关要素的分析可使用多种方法。

本标准的附录B给出了电子政务系统总体设计过程中推荐使用的一些分析方法，并给出了重点要素的描述模型。

描述模型只规定了应具有的基本特征，可以在此基础上扩展和演变．

6.3系统总体设计要素选用

对于不同类奎的电子致务系统以及不同阶段的总体设计，其涵盏的要素可不同．系统总体设计要素选用的推荐方法参见附录C．

6.4 

系统总体设计方案

电子政务系统总体设计的结果应形成系统总体设计方案文档，其内容要求参见附录D．

系统需求的描述应全面、完整和准确．体系结构设计应描述目标系统的组成结构和实现方法，充分体现与需求的符合性．设计结构应合理，实现方法应可行，并符合相关技术标准的要求。

附录A

（资料性附录）

系统总体设计过程

系统总体设计过程可以根据情况采用不同的过程，本标准中推荐以下三种过程：

a）完整过程，包括立项阶段系统总体设计和实施阶段系统总体设计两个组成部分，需求分析过程包含在其中，此过程适合于大中型、综合性或复杂系统；

b）单步过程，只进行一次总体设计，此过程适合于小型的、简单的或需求明确、实现方案确定的系统；

c）分步过程，包括立项阶段系统总体设计和实施阶段系统总体设计两个组成部分，需求分析过程作为独立的过程开展，此过程适合于大中型、综合性或复杂系统。

上述三种系统总体设计过程所包含的活动见表A．1。

项目可根据具体情况选择其中的过程。

过程中各项活动可以是顺序的，也允许局部反复或循环反复。

表A.1中．“立项阶段系统总体设计”未详细展开，其过程可参见“实施阶段系统总体设计”部分。

衰A．1 

系统总体设计活动

完整过程

单步过程

分步过程

立项阶段

系统总体

设计

确定系统（初步）需求

确定系统初步需求

确定系统需求

确定系统（初步）体系结构

确定系统初步体系结构

确定系统体系结构

形成（初步）总体设计文档

系统初步总体设计方案

系统总体设计方案

实施阶段

设计

系

统

需

求

分

析

明确业务组织结构

√

（通过独立的系统需求分析过程形成了《系统需求规格说明》或等同文档）

确定业务功能要求

梳理业务流程

界定业务功能范围

明确部门业务关系

确定系统信息资源

给出安全保密要求

给出系统性能要求

给出系统设施与环境要求

给出系统质量要求

√ 

给出标准与规范要求

给出系统验收要求

体

结

构

确定技术体系框架

确定系统设计策略

确定系统构成

确定系统运行模式

确定构件接口关系

确定系统部署形式

形成系统总体设计文档

注：

√表示在过程中可包含该活动，但对于不同类墨的系统是否需要该活动参见附录B．

附录B

系统总体设计中使用的方法

B．1概述

系统总体设计过程中，各相关要素的分析可采用多种方法，如GB/T19487--2004、UML、IDEFO中的描述模型均适用。

本附录将给出重点要素的分析方法和描述模型，使用时可对描述模型中的图形表现进行演变，对于这些描述模型可选择相应的支持工具。

重点要素包括业务组织结构、系统业务功能、

部门业务关系、系统信息资源、技术体系框架、系统构成、系统运行模式、构件接口关系和系统部署。

B．2业务组织结构

B．2.1分析方法

组织具有名称标识、工作职责和关系属性。

根据目标系统拟采用的组织形式，寻找出所有可能涉及的部门，确定每个组织部门的岗位及其工作职责，梳理这些部门间的关系。

部门间的关系可以为从属关系、协同关系或其他特定关系．

各组织部门的岗位在功能描述中应作为系统的外部角色或内部角色出现，所具有的工作职责应反映在与之接口的对象中，在系统部署中应作为其组成单元的部署实体。

B．2.2描述模型

业务组织结构的组成和关系可通过组织结构图直观地描述，工作职责和关系以配属文字进行说明。

组织结构图模板见图B1．

图中：

·

方框表示组织部门；

方框同的连线表示组织同的关系，可使用不同颜色或线型表示不同的关系类型

图B．1组织结构图模板

B．3系统业务功能

B．3.1 

分析方法

系统业务功能分析时，需确定系统应具有的业务功能和处理范围，同时还需对系统业务流程进行梳理．

系统业务功能是系统实现特定业务目的的能力。

功能是可分解的，为了不同目的所描述的粒度和角度也不同．功能具有名称标识、内容描述和关系等属性．需求分析过程中，从用户使用角度描述所具有的各项功能，一般可将功能分解为2～3个层次，功能与部门和角色直接关联。

在需求分析过程中功能间的关系无需定义类型，只表示存在关系，在后续的体系结构设计过程中再确定关系的类型．

系统业务功能的全集构成系统的业务功能范围．

系统业务流程指进行业务处理的过程，具有名称标识、输入、处理、传递数据、参与角色和输出等属性。

系统业务流程体现对于一种输入进行处理并产生输出的过程。

对于系统的所有外部输入都需给出业务流程，但可对输入进行分类，处理过程相同的归纳为一类进行描述。

业务流程中的处理能力应包含在系统功能中。

B．3.2 

系统业务功能描述模型

系统业务功能可通过功能分解图直观地描述，并以文本的方式分类描述功能的内容。

功能分解图模板见图B．2。

图中：

·

方框表示功能；

方框问的连线表示功能的分解关系，一次分解形成一个层次．

图B．2功能分解图模板

B．3.3业务功能范围描述模型

系统处理范围使用功能组成图直观地描述，其中的功能可使用功能分解图中的第2或3层功能，在描述时需使用同一层次的分解功能。

功能组成图模板参见图B．3。

椭圆框表示系统功能；

方框表示系统处理边界；

椭圆框问的连线表示功能间的关系；

小人图形表示系统角色；

圆角方框表示外部单位；

小人图形与椭圆框间的连线表示操作使用关系；

圆角方框与椭圆框向的连线表示信息交互或共享关系．

图B．3功能组成图模板

B．3.4 

系统业务流程描述模型

系统业务流程通过业务流程图直观描述，表示出流程的开始事件及后续的连贯事件，明确事件的触发者、处置者及处置活动，并标明事件携带的业务信息．业务流程还应以文字形式进行说明。

业务流程图模板见图B．4。

小人图形表示事件的触发者或处置者，是外部单位或系统角色；

箭头表示事件，需绘出顺序号，事件名称及传送的业务信息；

竖条表示处置活动，需给出顺序号、活动名称及涉及的业务信息．

图B.4业务流程图模板

B．4部门业务关系

B．4.1分析方法

部门业务关系表现为部门间的指示与汇报、请求与服务、信息共事与交换等协同关系。

对部门业务关系的分析是对部门开展业务活动时所涉及的领导部f1、下属部门、合作部门以及协同的业务，协同方式等进行梳理，并给出明确的分类与定义。

B．4.2描述模型

部门业务关系可使用业务关系描