CreatMap 地理信息共享服务云平台
软件工程标准规范
河北省制图院
2015年1月30日
1. 前言
1.1项目背景
当前，我国国家信息化建设与应用不断深入，网络化地理信息应用如同雨后春笋， 政府部门和社会大众使用地理信息的方式与频率正发生翻天覆地的变化。针对这一重大应用需求，国家测绘局认真学习和贯彻落实科学发展观， 做出了建设国家地理信息公共服务平台（以下简称“公共服务平台”）的战略性决策。 CreatMap 地理信息共享服务云平台是河北省地理信息局下属的河北省制图院自主研发的并拥有自主知识产权的新一代地理信息公共服务平台，平台以促进地理信息服务大局、服务社会、服务民生为目标，为政府、企事业单位、社会公众提供统一、高效的基础地理信息服务。
1.1.1软件系统名称
CreatMap 地理信息共享服务云平台，是依托地理信息数据，通过在线方式满足政府部门、企事业单位和社会公众对地理信息和空间定位、分析的基本需求，具备个性化应用的二次开发接口和可扩展空间，是实现地理信息应用服务功能的数据、软件及其支撑环境的总称。
1.1.2政策依据
1) 《国务院关于加强测绘工作的意见》（国发[2007]30号）：要切实提高测绘保障能力和服务水平，构建基础地理信息公共平台，更好地满足政府、企业及人民生活等方面对基础地理信息公共产品服务的迫切需要。
2) 《全国基础测绘中长期规划纲要》（2006年国务院批准发布）：到2010年，我国形成一批具有影响力的基础测绘公共产品；到2020年，要实现服务网络化社会化。国家测绘局在《测绘事业发展第十一个五年规划纲要》 中指出要以地理信息为基础平台整合社会、经济和人文等信息，促进各类信息资源的共享和高效开发利用，到2010年初步实现基础地理信息服务网络化。
3) 国务院办公厅“关于促进我国国家空间信息基础设施建设和应用若干意见”（国办发2001-53号）：要求各级测绘部门与当地发展计划等有关部门配合， 共同推进本地区地理空间信息协调机制的建设，解决好地理空间信息资源条块分割、封闭管理等问题。注重发挥测绘部门的整体优势，实现与同级政府部门的网上适时数据传输与服务， 促进地理空间信息设施的合理布局和高效利用，避免盲目投资和重复建设。
4) 《中办国办公转发的通知》 （中办发[2006]18号）:要求各部门建设基于广域网络的信息系统， 应首先使用国家统一建设的电子政务网络，不得独自新建或租用商用广域网络链路。
5) 《国家地理信息公共服务平台建设专项规划》（国家测绘局2010年10月）：要求各级测绘部门全力做好“公共服务平台”的建设工作，到2015年初步完成国家级节点和有条件省、市节点的建设，到2020年在全国范围内推广和应用。
6) 国家测绘局《关于推进国家综合减灾和风险管理信息共享平台建设建议的函》（国测函[2008]100号）：向国务院应急办、 国家减灾委办公室提出把地理信息公共平台作为国家综合减灾和风险管理信息共享平台建设的重要内容， 加快推进地理信息公共平台建设。
上述领导讲话和政策性文件与规划均是设计CreatMap 地理信息共享服务云平台的重要依据。
1.1.3遵从的技术标准与管理规定
本设计将遵循和参照国家和有关主管部门制定和发布的一系列与公共信息平台建设有关的技术标准规范与管理规定， 主要分为三类：
1) 计算机信息系统有关标准规范与规定：如电子政务信息系统技术规定、信息安全保密规定等。
2) 国家及行业地理信息技术标准规范：如基础地理信息要素分类与代码、地理元数据标准、OGC服务标准等；
3) 地理信息服务的有关管理规定：如测绘成果密级划分、公开地图发布规
定等。
详见附录。
1.2参考资料
1.2.1纲要类
1) 《关于加强数字中国地理空间框架建设与应用服务的指导意见》国测国字[2006]35号
2) 《国务院关于加强测绘工作的意见》（国发[2007]30号）
3) 《国家地理信息公共服务平台建设专项规划》（国家测绘局2008年10月）
4) 《国家地理信息公共服务平台技术设计指南》（国家测绘局2009年3月）
1.2.2测绘类标准
1) 《基础地理信息要素分类与代码》GB/T 13923-2006
2) 《公共信息标志用图形符号》 GB 1001—1994
3) 《中华人民共和国行政区代码》GB/T 2260-2000
4) 《县以下行政区划代码编制规则》GB/T 12409-1988
5) 《国土基础信息数据分类与代码》 GB 13923—92
6) 《专题地图信息分类与代码》GB/T 18317—2001
7) 《公路路线命名编号与编码规则》 GB 917.1—1989
8) 《地理信息元数据》GB/T 19710—2005
9) 数字测绘成果质量要求GB/T 17941-2008
1.2.3公共服务平台类标准
1) 《数字城市地理空间信息公共平台技术规范》（CH/Z 9001—2007）
2) 《数字城市地理空间信息公共平台地名/地址分类、描述及编码规则》GB/T 23705-2009
3) 《地理空间框架基本规定》CH/T 9003—2009
4) 《地理信息公共平台基本规定》CH/T 9004—2009
5) 《基础地理信息标准数据基本规定》（GB 21139―2007）
6) 《法人基础信息数据元素目录规范》（地方标准征求意见稿）
7) 《政务信息图层建设技术规范》DB11/z 360-2006
8) 《国家地理信息公共服务平台技术设计指南》、《1:400 万～1:5 万地理实体数据整合技术要求（试行）》、《公共地理框架数据-地理实体数据规范（试行）》、《公共地理框架数据-地名地址数据规范（试行）》、《公共地理框架数据-电子地图规范（试行）》
9) 《地理信息公共服务平台 服务节点建设基本技术要求》
10) 地名地址数据规范-试行稿(20100125)
11) 电子地图规范-试行稿(20100730)
1.3术语定义及说明
1.3.1数字城市
数字城市（Digital City）：也可称数字社会（智能社会，信息城市或电子城市）指由宽带基础设施、移动式终端，基于开放式工业标准的面向服务的处理基础设施等组成，为政府部门、企业和社会公众提供创新服务。数字城市，可以是小城也可以数百万人口的大城市。
无线基础网络设施是数字城市的重要组成部分，但它也只不过是数字城市建设的第一步。数字城市也可能需要有线的宽带设施，并且它不限于网络。数字城市提供互操作，和基于网络的政府服务，政府人员、企业和社会公众都可以随时访问政府主要业务。数字城市服务通过无线移动终端访问，而且是面向服务企业架构包括网络服务、XML和移动应用使用软件激活。
数字城市的主要内容是城市设施的数字化、城市网络化、城市的智能化。数字城市的广泛应用，对城市的繁荣稳定及可持续发展都有着巨大的促进和推动作用。
3) 《地理空间框架基本规定》CH/T 9003—2009
4) 《地理信息公共平台基本规定》CH/T 9004—2009
5) 《基础地理信息标准数据基本规定》（GB 21139―2007）
6) 《法人基础信息数据元素目录规范》（地方标准征求意见稿）
7) 《政务信息图层建设技术规范》DB11/z 360-2006
8) 《国家地理信息公共服务平台技术设计指南》、《1:400 万～1:5 万地理实体数据整合技术要求（试行）》、《公共地理框架数据-地理实体数据规范（试行）》、《公共地理框架数据-地名地址数据规范（试行）》、《公共地理框架数据-电子地图规范（试行）》
9) 《地理信息公共服务平台 服务节点建设基本技术要求》
10) 地名地址数据规范-试行稿(20100125)
11) 电子地图规范-试行稿(20100730)
1.3术语定义及说明
1.3.1数字城市
数字城市（Digital City）：也可称数字社会（智能社会，信息城市或电子城市）指由宽带基础设施、移动式终端，基于开放式工业标准的面向服务的处理基础设施等组成，为政府部门、企业和社会公众提供创新服务。数字城市，可以是小城也可以数百万人口的大城市。
无线基础网络设施是数字城市的重要组成部分，但它也只不过是数字城市建设的第一步。数字城市也可能需要有线的宽带设施，并且它不限于网络。数字城市提供互操作，和基于网络的政府服务，政府人员、企业和社会公众都可以随时访问政府主要业务。数字城市服务通过无线移动终端访问，而且是面向服务企业架构包括网络服务、XML和移动应用使用软件激活。
数字城市的主要内容是城市设施的数字化、城市网络化、城市的智能化。数字城市的广泛应用，对城市的繁荣稳定及可持续发展都有着巨大的促进和推动作用。
1.3.2智慧城市
智慧城市通过物联网基础设施、云计算基础设施、地理空间基础设施等新一代信息技术以及维基、社交网络、Fab Lab、Living Lab、综合集成法、网动全媒体融合通信终端等工具和方法的应用，实现全面透彻的感知、宽带泛在的互联、智能融合的应用以及以用户创新、开放创新、大众创新、协同创新为特征的可持续创新。伴随网络帝国的崛起、移动技术的融合发展以及创新的民主化进程，知识社会环境下的智慧城市是继数字城市之后信息化城市发展的高级形态。
1.3.3地理空间框架
是地理信息数据及其采集、加工、交换、服务所涉及的政策、法规、标准、技术、设施、机制和人力资源的总称，由基础地理信息数据体系、目录与交换体系、公共服务体系、政策法规与标准体系和组织运行体系等构成。
1.3.4基础地理信息数据库
是基础地理信息数据及实现其输入、编辑、浏览、查询、统计、分析、表达、输出、更新等管理、维护与分发功能的软件和支撑环境综合。
1.3.5基础地理信息
作为统一的空间定位框架和空间分析基础的地理信息。
1.3.6公共地理框架数据
公共地理框架数据（简称“框架数据”）：针对社会经济信息空间化整合和网络化服务需求，以现有基础地理信息数据为基础，加工形成面向地理实体，分层细化为重要特征的数据，由地理实体数据、电子地图数据、地名地址数据、影像数据与高程数据构成。根据应用范围不同，又细分为政务版公共地理框架
数据和社会公众版公共地理框架数据。
1.3.7政务地理信息图层
是指在政府管理部门规划、管理、决策和服务中所需要的、可共享的政务地理空间信息资源，它按照矢量数据模型及相应的属性数据分层组织，形成与电子政务业务有密切联系，有明确空间定位的，多个部门均需使用且使用频率较高的政务地理空间数据集。他同时具有空间特性和政务管理的权威、标准、现势等政务特性。政务地理信息图层共享维护原则：“权威数据来自权威部门，由权威部门维护共享”。
2. 项目概述
2.1建设目标与意义
2.1.1建设目标
“CreatMap 地理信息共享服务云平台” 是实现全国在线地理信息服务所需的信息数据、服务功能及其运行支撑环境的总称。其建设目标是：建成由多级节点构成的一体化地理信息在线服务体系， 实现全国地理信息资源的纵横联通和有效集成； 建成分布式的地理信息服务系统，形成多级互动的地理信息综合服务能力，提供一站式地理信息综合服务；建成“公共服务平台”服务管理系统，形成有效的运行服务机制，为政府宏观决策、国家应急管理、社会公益服务提供在线地理信息服务， 全面提升信息化条件下国家地理信息公共服务能力和水平。具体包括：
1）实现全国地理信息资源的互联互通：依据统一技术规范，整合全国多尺度地理信息资源，实现基于网络化运行环境的地理信息资源互联互通。
2）提供一站式的地理信息综合服务：建成分布式地理信息服务系统，提供
信息浏览、标图制图、导航定位、信息加载、系统搭建等网络化地理信息服务功能及二次开发接口，为政府、企业、公众提供在线地理信息服务。
3）形成业务化运行维护与管理机制：建立健全“CreatMap 地理信息共享服务云平台”运行维护有关规定和管理办法，建成“CreatMap 地理信息共享服务云平台”服务管理系统，形成不间断运行服务机制，为“CreatMap 地理信息共享服务云平台”的资源管理、服务调度、运行监控及适时更新提供有力的保障。
2.1.2建设意义
“CreatMap 地理信息共享服务云平台”建设项目入贯彻科学发展观、落实《国务院关于加强测绘工作的意见》和《全国基础测绘中长期规划纲要（2006- 2020） 》的重要举措，对于增强我国地理信息公共服务能力、发挥地理信息资源的最大效益、提升全社会地理信息资源开发利用水平、促进国民经济又好又快发展具有十分重要的意义。
1）切实提升我国地理信息公共服务能力：“CreatMap 地理信息共享服务云平台” 建设项目将作为信息化条件下我国地理信息公共服务的主要运行形态与手段，向各类用户提供权威高效的地理信息实时综合服务。这将极大地提升我国地理信息公共服务能力， 有效地缓解地理信息供需矛盾，较好地满足政府、企业、社会大众对地理信息在线服务的需求。
2）有效促进地理信息的深入广泛应用：“CreatMap 地理信息共享服务云平台”将为广大用户阅览地理信息、加载专业信息、搭建业务运行系统提供高效工具，使地理信息服务能无缝地嵌入到各部门、行业的现有业务应用系统中去， 有效解决以往应用系统建设运行中存在的技术难度大、建设成本高、开发周期长、更新维护难等问题，促进地理信息更加深入广泛的应用。
3）充分发挥地理信息资源的最大效益： “CreatMap 地理信息共享服务云平台”将把分散在各地的地理信息数据资源整合为逻辑上集中、 物理上分布的统一地理信息资源， 成为国家信息化的最重要基础设施之一。它的建设与运行将有力促进跨地区地理信息资源共享与应用，有效避免“信息孤岛”现象，充分发挥地理信息在政府宏观决策、国家应急管理、社会公益服务、产业升级拓展、人民生活改善等方面的保障服务作用，发挥我国地理信息资源的最大效益。
４）有力推进地理信息产业的发展。 “公共服务平台”的建设与运行将使测绘从传统纸质地图、 数据提供服务提升为在线地理信息服务，从以往的相对静态服务逐步发展为实时综合服务。这一方面会带动我国地理信息获取实时化、处理自动化、服务网络化和应用社会化等方面的技术创新与系统研发， 另一方面将为一大批企业进行地理信息资源的增值服务提供开发环境， 有力地促进我国地理信息产业的发展。
2.2建设原则
2.2.1采用成熟产品原则
采用在省级、市县级项目中应用实践的、已经商业化的、成熟、稳定、安全的应用支撑平台。既满足本次部、省两级需要，也为后期市、县多级应用打下基础。
2.2.2使系统具备良好的易扩展性、可视化柔性设计原则
CreatMap平台需要支撑省级、市县级应用的快速开发及集成已有系统。因此，系统需要采用组件封装技术、可视化柔性定制设计技术，后期根据系统需要可扩展封装新的组件、扩展表结构、扩展流程设计等。以灵活应对地理信息业务变化过程中对应用系统建设的需求。
2.2.3公共服务组件完善原则
CreatMap平台要全面支撑地理信息的业务系统建设需要，因此，公共服务组件需要完善，包括但不限于流程组件、表单组件、门户组件、数据分析BI组件、应用服务器组件、GIS服务组件、视频服务组件等。
2.2.4通用业务服务组件结合环保实际需求封装
CreatMap平台应该提供通用业务服务组件封装技术及封装开发平台，便于根据地理信息行业特点，将通用性公共服务封装为组件，提高组件的复用性，提高
开发速度。
2.2.5软件开发全生命周期管理原则
软件开发不是交钥匙工程，软件要根据业务需求不断变化而不断完善优化。可见，如何保障软件开发时就能保障其科学性？后期如何对软件不断优化？是软件开发面对的问题。因此，一方面应用支撑平台需要采用“业务模型防真、软件集成开发实现、软件应用监测优化“的开发模式，使业务人员和技术人员一共参与软件的开发，保障软件的适用性。另一方面，CreatMap平台需要对软件开发过程进行全生命周期管理，便于当软件发生问题的时候能找到开发过程中那个环境出了问题，并即时完善、优化。
2.3建设内容
2.3.1地理空间框架总体设计
地理空间框架建设项目是建立在分布式网络基础上的，具有共同的几何参考坐标系统，可支持快速的空间数据集成。框架包括分布式异构的地理空间基础数据库和在不同层次上可实现对空间信息的管理、共享、集成和互操作的功能和接口。地理空间框架数据在物理上是分散的，而在逻辑上是一个整体。框架的基础数据在网络中心节点存储，而各种专题数据和空间处理方法可以在远程节点和其本地存储。各节点地理空间信息的融合是以共同的几何参照系统、数据模型和接口为基础的。地理空间框架数据作为添加新的专题信息的基础，允许各专业部门添加专题应用数据，这些专题数据可以相互融合和集成，为各级组织和部门的应用和决策提供支持。
地理空间框架总体设计是参照建设数字城市地理空间框架相关标准要求，结合各委办局对地理信息共享需求对本项目的建设内容进行总体设计，指导项目的实施。
2.3.2标准规范体系建设
CreatMap平台标准体系是地理空间框架数据服务平台建设与运行服务的基础，项目参照数字城市、智慧城市地理空间框架和国家地理信息公共服务平台建设有关的技术标准规范和管理规定，结合各委办单位实际情况，制订各委办单位地理信息公共平台的技术标准规范，包括数据标准规范、服务规范和应用规范等。
2.3.3应用示范建设
基于所构建的地理信息公共平台，选择国土资源管理系统开发与对接、公众电子地图系统开发与国家天地图对接、供气应用系统开发与对接，以应用部门业务需求为主导建立应用系统，并总结公共平台的应用模式，在政府及其各部门全面推广。
对接国家天地图平台
与国家天地图平台进行对接，实现国家、省、市的互联互通。
按照国家要求成功对接国家“天地图”平台，提供基本的地图浏览，数据查询功能，同时平台支持OGC标准规范的WFS，WMS，WCS及WMTS，REST，WFS-G等标准服务接口，提供基于javascript的二次开发接口。
2.4技术路线
2.4.1 SOA技术
SOA面向服务的体系结构
SOA（面向服务架构，Service Oriented Architecture）是一种软件体系结构范型，可以组织和使用处于不同所有者控制下的分布式功能。从技术角度看，SOA就是一种体系架构，它描述了一种IT基础设施，使得不同的业务服务可以相互交换数据，参与业务流程，通过灵活的互相协作方式来完成具体的业务操作。这些业务服务独立于编程语言，独立于实现方法，独立于运行环境。
2.4.1.1重点关注服务
SOA支持面向服务的开发方法，是对前续的面向过程、面向消息、面向数据库和面向对象开发方法的补充。
服务从更高抽象层次上定义，直接与业务相对应，且其实现可采用面向过程、
面向消息、面向数据库和面向对象等不同开发方法。
与面向对象的调用接口相比，服务一般定义较粗粒度的接口，会接收更多的
数据，消耗更多的计算资源。服务一般是用来解决应用间互操作问题，以及将服务组合成新应用或新的应用系统，而不是为应用创建具体的业务逻辑。
通过SOA，围绕服务构建IT 系统，有利于IT 系统更靠近实际业务要求，使IT 系统更容易适应业务变化的要求，另外，对已有应用系统，通过服务化封装，可以使这些系统得到更好的重用，能有效保护对已有应用系统建设的投资。
2.4.1.2高内聚、低耦合
松耦合是软件设计中一个重要概念，SOA 强调服务间的松耦合。在SOA 中松耦合包括以下几个方面：
接口松耦合
接口耦合是指服务请求者与服务提供者之间的耦合。度量的是请求者与服务提供者的依赖性。接口松耦合强调服务请求者仅需要根据已发布的服务契约和服务水平协议（或称服务等级协议）就可以请求一个服务，任何时候服务请求者都不需要了解服务提供者对内部实现的信息。即服务接口封装了所有的实现细节，使服务请求者看不到这些实现细节。
技术松耦合
技术耦合度量的是服务对特定技术，产品或开发环境的依赖程度。技术松耦合强调服务请求者和服务提供者的实现和运行不需要依赖与特定的某种技术，或某个厂家的解决方案或产品，从而减少对某个厂商的依赖。在SOA 系统中服务请求者和服务提供者可以使用不同技术实现，可以在不同厂商的环境中运行。
流程松耦合
流程松耦合度量的是服务与特定业务流程的依赖程度。强调服务不应与具体的业务流程相关，以便能够被重用于多种不同的业务流程与应用。这一点强调的是服务的可重用性，在SOA 系统中对业务服务的合理规划，使得一个业务服务可以在多个业务流程中得到复用，并且随着业务要求的改变，一个服务可以在变化后的新的业务流程中能够得到继续使用。
2.4.1.3重构的灵活性
在SOA系统建设中，基本的单位是实现业务功能的服务，而不是实现业务逻辑的对象，过程，函数等较小的技术单位。
服务与实际业务功能相关，具有明确的接口。这些服务可在不同的业务流程中得到重用，提高了服务的价值；其次在使用中只需按其接口要求进行访问，屏蔽服务实现细节，服务实现的修改不会影响到服务访问方的逻辑，提高了业务流程的适应性；另外，一旦业务流程变更，仅需对服务进行重新编排，并不修改服务本身，提高了业务流程实现的灵活性。
重构的灵活性，不仅可以使业务服务可以有更好的重用性，也使得业务流程更容易重构，使IT系统具有了更好的灵活性，可以快速面对变化的市场需求。
2.4.2 ESB总线技术
ESB总线技术
ESB是服务交互的核心组件，支持：
面向服务的架构。
消息驱动的架构。
事件驱动的机构。
ESB是一种基于标准的面向服务的骨干，它能够进行可靠连接和协调数百个应用程序端点。ESB为需要连接跨越不同数据中心分布的各种异构系统的企业提供了一种理想的体系结构，同时还保持了绝对的事务完整性。此外，它还提供几个通过部署时构造进行最初配置的高级服务，从而保护了门户应用程序，即不必经常对它进行修订和重新部署来管理后端上的更改。
2.4.3 J2EE技术
作为系统平台的基础，平台必须具有很好的可移植性和可扩充性。为了可移植，平台开发的技术尽可能与操作系统无关。谈到与操作系统无关的开发技术，必然首推JAVA。要使系统具有可扩充性就必须采用通用的组件标准。J2EE是Sun公司所颁布的标准，但已广为工业界所接受，J2EE的出现标志着用Java开发企业级应用系统已变得非常简单。
由于J2EE是多层的分布式体系结构，使系统的操作和运行具有很好的灵活性；先进的 Java计算方案如面向对象、独立于平台、快速集成、代码重用等，使系统具有良好的可移植性和可扩展性，所以我们选择J2EE作为系统的应用服务平台。
J2EE为搭建具有可伸缩性、灵活性、易维护性的业务系统提供了良好的机制。
1）支持异构环境：J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构计算环境中是十分关键的。J2EE标准也允许使用与J2EE兼容的第三方的现成组件，把它们部署到异构环境中，节省了由自己制订整个方案所需的费用。
2）可伸缩性：基于J2EE平台的应用程序可被部署到各种操作系统上，为消除系统中的瓶颈，允许多台服务器集成部署，实现可高度伸缩的系统，满足未来业务系统的需要。
3）稳定的可用性：一个服务器端平台必须能全天候运转以满足业务运行的需要。将J2EE部署到可靠的操作环境中，将支持长期的可用性。
4）强大的应用开发能力：J2EE框架中的多种技术提供了应用开发的手段，如XML、JMS、RMI/IIOP、JCA，从数据级、组件级、应用级等层次支持国资监管信息应用的集成。
2.4.4集成Portal for ArcGIS构建CreatMap平台
Portal for ArcGIS包含在 ArcGIS for Server标准版和高级版中，提供以地图为核心的内容协作，可以部署在自己的基础设施中（内部部署或在云中部署）。Portal for ArcGIS是ArcGIS平台的一个核心组件，提供的功能包括快速创建、组织、授权和管理组织内部的地理资产。
使用Portal for ArcGIS，可以进行：
管理用户单位自己的地理信息资源；
访问ArcGIS Online提供的地理底图、GIS工具和分析服务；
在线创建地图、Web应用；
在用户单位内外，分享地图和Web应用；
将本地、现有的ArcGIS for Server服务注册进来进行管理；
基于群组实现日常工作的协同办公。
2.4.4.1带来全新的GIS应用模式：
Portal使得GIS功能与网络技术结合得更加的紧密，在为用户带来诸多便利
的同时，为组织内资源利用的协同与共享带来了合理的解决方案。
2.4.4.2实现了服务托管的功能
用户无需搭建、维护ArcGIS for Server环境，即可实现GIS服务的发布与管理。
2.4.4.3 Portal可以作为ArcGIS私有云门户：
借助Portal，用户可以实现对云GIS当中资源服务的管理，并能直接使用这些资源服务实现地图浏览、专题图制作以及创建应用等功能。
2.4.5基于WebService服务接口实现与业务系统对接集成
WebService主要是为了使各自孤立的业务系统之间的信息能够相互通信、共享而提出的一种接口。Web Service通过使用Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、WSDL等，实现不同系统之间的信息交换，Web Service可以在任何支持这些标准的环境（Windows，Linux）中使用，主要用于跨网络或跨系统之间的信息互通和共享。WebService应用特点：
（1）跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上大量的开发时间。另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过WebService的方式把应用程序的逻辑和数据公布出来，还可以让其它平台上的客户重用这些应用程序。
（2）应用程序集成
在传统企业级应用中，用户需要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过WebService方式，应用程序可以用标准的方法把功能和数据公布出来，供其它应用程序使用。
例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService，订单执行程序可以把“AddOrder”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
（3）软件和数据重用
软件重用涵盖了许多层面，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。用WebService集成各种应用中的功能，为用户提供一个统一的界面，当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮
政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给使用者。两种情况下，代码及代码背后的数据，都可以得到重用。
从以上论述可以看出，WebService是通过Web进行互操作或远程调用的有效的手段之一。本项目将充分利用WebService等技术手段来实现与各业务系统进行数据同步交换。
3. 软件工程开发实施管理规范标准
3.1总纲
软件工程项目要在满足用户需求的条件下，尽可能做到高可靠、高性能，同时又受到成本和交付期的限制， 成功地完成软件开发工作的一个主要决定因素就是软件管理。本标准参照我国软件工程国家标准（表-1） ，结合具体的实践情况编制而成。
表-1 软件工程国家标准
3.1.1目的
计算机软件由于其固有的特性：
1) 抽象性：没有形体，自然没有一般制造业产品所具有的几何尺寸，
物理性质和化学性质。 2) 复杂性：软件内部结构复杂。 3) 多样性：没有完全相同的软件。
4) 易变性：软件在开发过程以及交付使用后常常会出于各种原因而修
改。
5) 软件需求难于把握：软件开发常常会出现用户弄不清自己的需求、
讲不清自己的需求、开发人员理解不透用户的需求，在开发过程中 再三要变更需求。
因此要保证软件产品的开发质量其标准化是实现软件产业化的最必要的前提，其目的就是按标准规范管理软件开发的每一个生产环节，做到标准化，过程化。让软件开发的所有过程都能按 ISO9000 标准受控，同时使繁琐的标准描述简化成图表描述。
3.1.2任务
在软件生存期中，其主要的任务是：管理过程、获取过程、供应过程、开发过程、操作过程、维护过程和支持过程。将其简化描述成“项目管理过程” 、 “配置管理过程” 、 “主要过程” 、 “质量管理过程” ，使这四部分工作的每一步骤的管理、通信、文档格式、执行过程都标准化是其主要的任务。
3.1.3组织结构
要保证软件开发的质量，其基本前提是有一个合理的组织结构保证软件的实施过程。否则所有的一切都是空中楼阁。
3.2软件工程过程规范
3.2.1目的
本节目的是规范软件工程开发过程的总体任务和实施管理的生存期模型，用现代科学技术知识来设计并构造计算机程序，为开发、运行和维护这些程序建立所必需的相关文件资料， 在成本限额内按时完成开发和修改软件产品所需的管理技术标准。
软件工程的过程是将软件工程的方法和工具综合起来达到合理、 及时地进行软件开发的目的。 方法是要求使用顺序、可交付的文档资料，为保证质量和协调变更建立所需要的管理，以及确定软件开发各个阶段完成的里程碑。
工具为软件工程方法提供的自动或半自动的软件支持环境，可将软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环 境。
基本目标是付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，使开发的软件易于移植，只需要较低的维护费用，能按时完成开发工作
及时交付使用。
3.2.2
软件生存周期模型
3.2.3软件开发过程
3.2.4过程执行中的作用
1) 项目管理：制定计划、监控计划实施、评价计划实施、评估项目风险、可能的技术攻关，涉及到有关过程的产品管理、任务管理。
2) 系统开发：系统需求分析，系统结构设计，软件需求分析，软件结构设计，软件详细设计，软件编码和测试，软件集成，系统集成，系统合格测试，软件安装及验收支持。
3) 质量管理：软件产品质量保证，合同、过程、需求、设计、编码、集成和文档的验证，产品质量测试。
4) 配置管理：配置计划、配置标识、记录配置状态、评价配置、发行管理及交付，文档资料归档管理。
5) 维护管理：问题和变更分析，实施变更，维护评审及维护验收，软件移植及软件退役。
6) 项目经理：定义和分析用户需求，提供招标准备、风险评估、合同准备和验收，评审需求，制订并实施项目计划，评审和评价产品。
3.3需求分析过程标准
3.3.1需求分析任务
通常软件开发项目是要实现目标系统的物理模型， 将功能和数据结构分配到这些系统元素中。目标系统的具体物理模型是由它的逻辑模型经实例化表现出来，需求分析的任务就是借助于目标系统的逻辑模型表现出所需要的问题，即具体的工作为：
目标系统的功能需求（功能描述）
目标系统的业务需求（业务流程）
目标系统的业务优化（业务重构）
目标系统的数据需求（数据流程）
目标系统的功能性约束和非功能性约束需求（性能描述）
3.3.2需求分析过程
需求分析过程分为四过方面：
1）问题识别
功能需求
性能需求
环境需求
可靠性需求
安全保密需求
用户界面需求
2）分析与综合
3）编制需求分析文档
4）需求分析评审
软件需求分析工作流程图
需求开发流程说明
3.3.3需求分析业务关系
3.4系统设计过程标准
3.4.1任务
概要设计，任务包括：
1) 设计系统的物理实现方案，内容：
划分组成系统的物理元素（程序、设备、存储数据结构等） ； 确定数据在组成成份间的流向 ；
系统的边界 ；
2) 设计软件的整体结构，划分程序功能模块，决定模块间的接口关系 ；
3) 设计系统全局的存储数据结构，文件或数据库 ；
4) 设计系统输入输出的方式和格式 ；
5) 设计系统的安全性、出错处理、和代码等 。
详细设计：任务包括上面的内容外，核心任务是进一步把软件的功能模块细分为程序模块，设计每个模块的实现细节，如算法和程序控制逻辑。
1) 系统流程图——表达软件系统处理流程，即数据在系统各结构中的流动关系 ；
2) 模块结构层次图——表达软件总体的模块结构组织 。
描述设计思想的内容：
描述系统概述
系统流程图
程序模块结构图和关系描述
数据存储结构图和关系描述
软件接口设计原则
软件功能需求和数据存储结构，程序交叉引用表
系统安全性设计
3.4.2设计过程流程说明
3.4.3设计流程关系
4. 测试过程标准
4.1目的
为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束前进行严格的技术评审，在编码阶段对软件进行单元测试、组装测试、系统测 试，以确保软件的产品质量，本节的目的就是规范测试过程的标准化，使软件 质量体系得到充分地保证。
4.2任务
在软件质量体系中其主要任务：
1）质量保证体系
2）文档资料技术评审（需求分析和系统设计评审）
3）单元测试（白盒测试）
4）组装测试（黑盒测试）
5）系统测试（验收测试、验收走查）
在软件需求开始后就必须通过对软件功能和需求的情况组织测试计划，确定开发过程的测试点和评审关系。表-2表示了各测试步骤中的测试种类关系。
4.3测试过程关系
4.4质量确认体系
5. 质量评审内容
5.1需求分析评审内容
1) 系统定义的目标是否与用户的要求一致；
2) 系统需求分析阶段提供的文档资料是否齐全；
3) 文档中的所有描述是否完整、清晰、准确反映用户要求；
4) 与所有其他系统成分的重要接口是否都已经描述；
5) 所开发项目的数据流与数据结构是否足够、确定；
6) 所有图表是否清楚，在不补充说明时能否理解；
7) 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
8) 设计的约束条件或限制条件是否符合实际；
9) 开发的技术风险是什么；
10) 是否考虑过软件需求的其他方案；
11) 是否考虑过将来可能会提出的软件需求；
12) 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
13) 有没有遗漏、重复或不一致的地方；
14) 用户是否审查了初步的用户手册；
15) 软件开发计划中的估算是否受到了影响。
5.2设计评审内容
1) 评价软件的规格说明是否合乎用户的需求；
2) 评审可靠性；
3) 评审保密措施实现情况；
4) 评审操作特性实施情况；
5) 评审性能实现情况；
6) 评审软件是否具有可修改性；
7) 评审软件是否具有可扩充性；
8) 评审软件是否具有互换性；
9) 评审软件是否具有可移植性；
10) 评审软件是否具有可测试性；
11) 评审软件是否具有复用性；
12) 评审软件是否具有互连性。
5.3程序质量评审内容
1) 软件结构：
功能结构，数据结构、功能结构、数据与功能结构之间的对应关系 功能的通用性
模块层次、与功能层次的对应关系
模块结构，控制流结构、数据流结构、与功能结构之间的关系
处理过程的结构。
2) 运行环境的接口：
与其他软件的接口
与硬件的接口
与用户的接口
3) 变更的影响范围：
与运行环境的接口
在每项设计工程规格内的影响
在设计工程相互间的影响
4) 软件代码：
可读性，注释说明清楚。
可理解性，逻辑思维清晰。
结构合理性。
技术通用性。
6.配置管理标准
6.1配置管理目的
软件开发过程中随着工作的进展会产生许多信息，如规格说明书、需求说 明书、设计说明、源程序、目标程序、用户手册、各种数据、测试结果；以及 合同、计划书、会议记录、报告等管理文件。一个中大型项目这些信息数量将 达到数百个甚至上千个。如何管理好这些信息，同时在软件开发过程中出现的 变更是不可避免的，对于如此庞大且变动中的信息集合，如何使其有序高效地 产生、存放、查找和利用成为软件工程项目十分突出的问题，配置管理的主要 目的就是建立一套严谨、科学的管理办法。
6.2配置管理内容
软件配置项是软件配置管理的对象，指的是软件工程过程中产生的所有信 息项，包括计算机可执行的源代码、目标码、数据库以及计算机不可执行的文 档资料、源程序清单，测试用例等，主要内容有：
1) 与合同、过程、计划和产品有关的文档及数据；
2) 源代码、目标代码和可执行代码；
3) 相关产品包括软件工具、库内的可复用软件、外购软件及顾客提供的软件等。
6.3配置管理的任务
实施软件配置管理要做的工作：
1) 制订配置管理计划。在软件工程项目制订开发计划时，应使开发计划包括配置管理计划。在配置管理计划中规定配置标识规则，建立怎样的配置数据库及如何将配置项置于配置管理之下，配置管理人员的职责及配置管理活动，以及采用的配制管理工具、技术和方法。
2) 实施变更管理，这是配置管理的一项重要内容，许多软件工程项目没
有变更管理措施导致出现混乱。
3) 实施版本管理和发行管理。
配置管理要做的事是标识变更、控制变更以及发布变更。软件配置管理人员需要解决的问题：
1) 采用什么方式去标识和管理数量巨大的程序、文档等的各种版本。
2) 在软件产品交付用户之前和交付之后如何控制变更，实现有效变更。
3) 谁有权批准变更以及安排变更的优先级
4) 用什么方法估计变更可能引起的其他问题。
具体表现的任务：配置标识、版本管理、变更管理、配置审核及配置报告。
6.4配置过程关系图
7.软件项目管理过程标准
7.1软件项目管理过程目的
软件项目的特殊性使得软件管理的重要性显得更加突出和重要，表现在项 目的延误交货期、产品运行不可靠、实际开发成本上升以及产品的不良性能等。一些中大型项目的问题主要在于管理方法上，管理过程就是实现项目科学的合理化管理目的。
项目管理人员的责任主要在制订开发计划和确定进度要求，监督项目按计 划实施，保证开发活动按规定的标准执行，控制开发进度，保证项目在规定的
期限内，在预算的范围内完成任务。
软件工程项目的特点：
1) 软件产品的不可见，开发的进展以及产品的质量是否符合要求并不是那么明显，因此难于把握。
2) 不存在标准的软件过程，无法预料某一个特定的软件过程可能会引起开发的问题。
3) 大型软件项目往往是一次性项目，无经验可借鉴。
基于以上几个方面的问题，软件的开发管理比其他工程管理更困难。
7.2软件项目管理过程主要任务
软件项目管理的对象是软件工程项目，它所涉及的范围包括了整个软件工 程过程。为使软件项目开发获得成功，必须对软件开发项目的工作范围、可能遇到的风险、需要的资源（人、硬/软件） 、要实现的任务、经历的里程碑、花 费的工作量（成本） ，以及进度的安排等一一计划好，使管理作到心中有数。软件项目管理过程是从软件开始到软件项目终止的一个项目生命周期，主要在如下几个方面：
1) 软件项目的开始启动
确定项目的目标和范围，目标标明软件项目的目的，范围标明软件实现的基本功能，并尽量以定量的方式界定这些功能。从项目管理者角度方面考虑，主要是考虑项目实现的计划性和可管理性，而不必要在具体技术上考虑如何设计实现这些软件功能，和怎样实现这些功能的具体方法手段。
2) 软件开发工作的度量
进行度量工作是为了帮助软件开发人员了解产品开发的技术过程和产品，改进开发过程，提高产品质量。其作用是有效的定量地进行管理，把握软件工 程过程的实际情况和所产生的产品质量。
3) 项目开发的估算
软件项目管理过程中最关键的活动是制定项目计划，在做计划时，必须就需要的人力、项目持续时间、成本作出估算。其主要的内容为：
建立软件的工作范围；以软件度量（以往的度量）为基础作出估算；把项 目分解为可单独进行估算的小块。
4) 风险分析
每一个新建的软件总是存在某些不确定性， 是否能准确地理解用户的要求，在项目最后结束之前要求的功能能否实现，是否存在目前技术上的难题，是否会因某些变更因素造成项目严重延误等等，是项目开发的主要风险。风险分析对于软件项目管理是决定性的，风险分析贯穿在软件工程过程的一系列风险管理中，包括风险识别、风险估计、风险管理策略、风险解决和风险监督。
5) 进度安排
每个软件项目都要制定一个进度安排，对于进度安排，需考虑的是： 预先对进度如何计划
工作怎样就位
如何识别定义好任务
如何识别和监控关键路经
对进展如何度量
如何建立分隔任务的里程碑
6) 追踪与控制
制定了开发进度计划，就可以开始着手追踪和控制活动，项目管理人员负责追踪在进度安排中标明的每一个任务。借助项目管理工具软件可自动对进度安排的变化进行调整和资源重新定位分配。
7.3管理过程的主要职能
软件管理的主要职能包括：
1) 制定计划：规定待完成的任务、要求、资源、人力和进度等。
2) 建立组织：为实施计划、保证任务的完成，需建立分工明确的责任机制。
3) 配备人员：任用各种层次的技术人员和管理人员。
4) 指导：鼓励和动员软件人员完成所分配的工作。
5) 检验：对照计划或标准监督和检查实施的情况。
项目追踪和控制：
1) 定期举行项目状态会议。每位项目成员报告他的进展和遇到的问题。
2) 评价在软件工程过程中所产生的所有评审的结果。
3) 确定由项目的计划进度所安排的可能选择的正式的里程碑。
4) 比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。
5) 非正式地与开发人员交谈， 以得到对开发进展和刚冒头的问题的客观评价。
管理过程制定的计划：
1) 项目实施计划（软件开发计划），包括任务、进度、人力、环境、资源、组织等多个方面。
2) 质量保证计划：把软件开发的质量要求具体规定为在每个开发阶段中可以检查的质量保证活动。
3) 软件测试计划：规定测试活动的任务、测试方法、进度、资源、人员职责。
4) 文档编制计划：规定所开发项目应编制的文档种类、内容、进度、人员职责等。
5) 用户培训计划：规定对用户进行培训的目标、要求、进度、人员职责。
6) 综合支持计划：规定软件开发过程所需要的支持，以及如何获取和利用这些支持。
7) 软件分发计划：软件开发项目完成后，如何提供给用户。
软件的范围：
软件范围包括功能、性能、限制、接口和可靠性。由于成本和进度的估算都是与功能有关，因此常采用某种程度的功能分解。性能的考虑包括处理和系统响应时间的需求。约束条件则标识外部硬件、可用于存储或其他现有系统对软件的限制。接口的性质和复杂性是对开发资源、成本和进度的影响的一个不可忽略的部分。
8.软件维护标准
8.1软件维护目的
软件产品开发完成投入使用后， 常常由于各种理由需要对它作适当的变更，原来的功能和性能可能不在适应用户的要求，需要作变更；软件工作环境可能有变化，经常配合软件工作的硬件有了变动，如添置了新设备等；在软件运行中发现错误，需要改正。通常把软件交付使用后的变更称为维护。
维护的目的归结为：
1) 改正在特定使用条件下暴露出来的一些潜在的程序错误或设计缺陷。
2) 因在软件使用过程中数据环境发生变化，需修改软件以适应这种变化。
3) 用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能的要求，为满足这些要求，需修改软件。
维护活动的内容：
1) 改正性维护：由于开发时测试的不彻底、不完全所留下的隐藏错误。
2) 适应性维护：硬件环境的变化和数据环境的变化，导致软件的修改。
3) 完善性维护：使用过程中提出新的功能与性能要求。
4) 预防性维护：为了提高软件的可维护性、可靠性对软件的修改。
8.2软件维护活动
软件如何进行维护，应当如何组织维护活动，以便有效地完成软件维护任务。为了有效地进行软件维护，应建立维护机构，申明提出维护申请报告，评价过程，规定维护申请的处理步骤，建立维护活动登记制度及评价和评审标准。
1) 对于管理者，其维护活动的具体内容有：
2) 维护机构：建立确保维护可靠的职责关系。
3) 维护申请报告：按规定提交维护意见和处理意见。
4) 维护工作流程规范化：使管理人员和执行者清楚工作的关系。
5) 维护文档记录备案：确认软件系统的变更和软件质量情况的评价。
6) 维护评价。
9.文档编制标准
9.1文档编制目的
软件所包含的文件有两类：
1) 开发过程中填写的各种图表， 称为工作表格；
2) 应编制的技术资料或技术管理资料，称为文档。
一般软件开发过程有可能产生的文挡有14种：
1) 可行性研究报告：目的是说明软件开发项目的实现在技术、经济和社会条件方面的可行性，评述为了合理地达到开发目标而可能选择的各种方案，并论证所选定的方案。
（技术开发文档）
2) 项目开发计划：目的是用文件形式把开发过程中对各项工作负责人员、开发进度、所需经费预算、所需软/硬件条件等问题作出安排，并以此为根据开展和检查项目的开发工作。（管理文档和说明性资料）
3) 软件需求说明书：目的是使用户和软件开发者双方对软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 （技术开发文档）
4) 数据要求说明书：目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。 （技术开发文档）
5) 概要设计说明书：目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为程序详细设计提供原则和基础。（技术开发文档）
6) 详细设计说明书：目的是说明一个软件系统各层次中每一个程序（即每个模块或子程序）的设计考虑（技术开发文档）
7) 数据库设计说明书：目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。 （技术开发文档）
8) 用户手册：目的是使用非专门术语，充分地描述该软件的功能和基本的使用方法，使用户通过手册能够了解软件的用途，以及如何在不同情况下正确使用。（管理文档和说明性资料）
9) 操作手册：目的是向操作员提供该软件的每一个运行的具体过程和相关知识，包括操作方法的细节。（管理文档和说明性资料）
10) 模块开发卷宗：目的是以一个模块或一组密切相关的模块为记录，记录和汇总低层次开发的进度和结果，以便于整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。 （技术开发文档）
11) 测试计划：目的是为程序系统的组装测试和确认测试提供计划，包括每项测试活动的内容、进度安排、设计考虑，测试数据的整理方法及评价准则。（技术开发文档）
12) 测试分析报告：目的是把组装测试和确认测试的结果、发现及分析写成文件加以记载。 （技术开发文档）
13) 开发进度月报：目的是及时向有关部门汇报项目开发的进展和情况，
以便及时发现和处理开发过程中出现的问题。（管理文档和说明性资料）
14) 项目开发总结报告：目的是为了总结本项目软件开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各方面的评价。（管理文档和说明性资料）
CreatMap 地理信息共享服务云平台
软件工程标准规范
河北省制图院
2015年1月30日
1. 前言
1.1项目背景
当前，我国国家信息化建设与应用不断深入，网络化地理信息应用如同雨后春笋， 政府部门和社会大众使用地理信息的方式与频率正发生翻天覆地的变化。针对这一重大应用需求，国家测绘局认真学习和贯彻落实科学发展观， 做出了建设国家地理信息公共服务平台（以下简称“公共服务平台”）的战略性决策。 CreatMap 地理信息共享服务云平台是河北省地理信息局下属的河北省制图院自主研发的并拥有自主知识产权的新一代地理信息公共服务平台，平台以促进地理信息服务大局、服务社会、服务民生为目标，为政府、企事业单位、社会公众提供统一、高效的基础地理信息服务。
1.1.1软件系统名称
CreatMap 地理信息共享服务云平台，是依托地理信息数据，通过在线方式满足政府部门、企事业单位和社会公众对地理信息和空间定位、分析的基本需求，具备个性化应用的二次开发接口和可扩展空间，是实现地理信息应用服务功能的数据、软件及其支撑环境的总称。
1.1.2政策依据
1) 《国务院关于加强测绘工作的意见》（国发[2007]30号）：要切实提高测绘保障能力和服务水平，构建基础地理信息公共平台，更好地满足政府、企业及人民生活等方面对基础地理信息公共产品服务的迫切需要。
2) 《全国基础测绘中长期规划纲要》（2006年国务院批准发布）：到2010年，我国形成一批具有影响力的基础测绘公共产品；到2020年，要实现服务网络化社会化。国家测绘局在《测绘事业发展第十一个五年规划纲要》 中指出要以地理信息为基础平台整合社会、经济和人文等信息，促进各类信息资源的共享和高效开发利用，到2010年初步实现基础地理信息服务网络化。
3) 国务院办公厅“关于促进我国国家空间信息基础设施建设和应用若干意见”（国办发2001-53号）：要求各级测绘部门与当地发展计划等有关部门配合， 共同推进本地区地理空间信息协调机制的建设，解决好地理空间信息资源条块分割、封闭管理等问题。注重发挥测绘部门的整体优势，实现与同级政府部门的网上适时数据传输与服务， 促进地理空间信息设施的合理布局和高效利用，避免盲目投资和重复建设。
4) 《中办国办公转发的通知》 （中办发[2006]18号）:要求各部门建设基于广域网络的信息系统， 应首先使用国家统一建设的电子政务网络，不得独自新建或租用商用广域网络链路。
5) 《国家地理信息公共服务平台建设专项规划》（国家测绘局2010年10月）：要求各级测绘部门全力做好“公共服务平台”的建设工作，到2015年初步完成国家级节点和有条件省、市节点的建设，到2020年在全国范围内推广和应用。
6) 国家测绘局《关于推进国家综合减灾和风险管理信息共享平台建设建议的函》（国测函[2008]100号）：向国务院应急办、 国家减灾委办公室提出把地理信息公共平台作为国家综合减灾和风险管理信息共享平台建设的重要内容， 加快推进地理信息公共平台建设。
上述领导讲话和政策性文件与规划均是设计CreatMap 地理信息共享服务云平台的重要依据。
1.1.3遵从的技术标准与管理规定
本设计将遵循和参照国家和有关主管部门制定和发布的一系列与公共信息平台建设有关的技术标准规范与管理规定， 主要分为三类：
1) 计算机信息系统有关标准规范与规定：如电子政务信息系统技术规定、信息安全保密规定等。
2) 国家及行业地理信息技术标准规范：如基础地理信息要素分类与代码、地理元数据标准、OGC服务标准等；
3) 地理信息服务的有关管理规定：如测绘成果密级划分、公开地图发布规
定等。
详见附录。
1.2参考资料
1.2.1纲要类
1) 《关于加强数字中国地理空间框架建设与应用服务的指导意见》国测国字[2006]35号
2) 《国务院关于加强测绘工作的意见》（国发[2007]30号）
3) 《国家地理信息公共服务平台建设专项规划》（国家测绘局2008年10月）
4) 《国家地理信息公共服务平台技术设计指南》（国家测绘局2009年3月）
1.2.2测绘类标准
1) 《基础地理信息要素分类与代码》GB/T 13923-2006
2) 《公共信息标志用图形符号》 GB 1001—1994
3) 《中华人民共和国行政区代码》GB/T 2260-2000
4) 《县以下行政区划代码编制规则》GB/T 12409-1988
5) 《国土基础信息数据分类与代码》 GB 13923—92
6) 《专题地图信息分类与代码》GB/T 18317—2001
7) 《公路路线命名编号与编码规则》 GB 917.1—1989
8) 《地理信息元数据》GB/T 19710—2005
9) 数字测绘成果质量要求GB/T 17941-2008
1.2.3公共服务平台类标准
1) 《数字城市地理空间信息公共平台技术规范》（CH/Z 9001—2007）
2) 《数字城市地理空间信息公共平台地名/地址分类、描述及编码规则》GB/T 23705-2009
3) 《地理空间框架基本规定》CH/T 9003—2009
4) 《地理信息公共平台基本规定》CH/T 9004—2009
5) 《基础地理信息标准数据基本规定》（GB 21139―2007）
6) 《法人基础信息数据元素目录规范》（地方标准征求意见稿）
7) 《政务信息图层建设技术规范》DB11/z 360-2006
8) 《国家地理信息公共服务平台技术设计指南》、《1:400 万～1:5 万地理实体数据整合技术要求（试行）》、《公共地理框架数据-地理实体数据规范（试行）》、《公共地理框架数据-地名地址数据规范（试行）》、《公共地理框架数据-电子地图规范（试行）》
9) 《地理信息公共服务平台 服务节点建设基本技术要求》
10) 地名地址数据规范-试行稿(20100125)
11) 电子地图规范-试行稿(20100730)
1.3术语定义及说明
1.3.1数字城市
数字城市（Digital City）：也可称数字社会（智能社会，信息城市或电子城市）指由宽带基础设施、移动式终端，基于开放式工业标准的面向服务的处理基础设施等组成，为政府部门、企业和社会公众提供创新服务。数字城市，可以是小城也可以数百万人口的大城市。
无线基础网络设施是数字城市的重要组成部分，但它也只不过是数字城市建设的第一步。数字城市也可能需要有线的宽带设施，并且它不限于网络。数字城市提供互操作，和基于网络的政府服务，政府人员、企业和社会公众都可以随时访问政府主要业务。数字城市服务通过无线移动终端访问，而且是面向服务企业架构包括网络服务、XML和移动应用使用软件激活。
数字城市的主要内容是城市设施的数字化、城市网络化、城市的智能化。数字城市的广泛应用，对城市的繁荣稳定及可持续发展都有着巨大的促进和推动作用。
3) 《地理空间框架基本规定》CH/T 9003—2009
4) 《地理信息公共平台基本规定》CH/T 9004—2009
5) 《基础地理信息标准数据基本规定》（GB 21139―2007）
6) 《法人基础信息数据元素目录规范》（地方标准征求意见稿）
7) 《政务信息图层建设技术规范》DB11/z 360-2006
8) 《国家地理信息公共服务平台技术设计指南》、《1:400 万～1:5 万地理实体数据整合技术要求（试行）》、《公共地理框架数据-地理实体数据规范（试行）》、《公共地理框架数据-地名地址数据规范（试行）》、《公共地理框架数据-电子地图规范（试行）》
9) 《地理信息公共服务平台 服务节点建设基本技术要求》
10) 地名地址数据规范-试行稿(20100125)
11) 电子地图规范-试行稿(20100730)
1.3术语定义及说明
1.3.1数字城市
数字城市（Digital City）：也可称数字社会（智能社会，信息城市或电子城市）指由宽带基础设施、移动式终端，基于开放式工业标准的面向服务的处理基础设施等组成，为政府部门、企业和社会公众提供创新服务。数字城市，可以是小城也可以数百万人口的大城市。
无线基础网络设施是数字城市的重要组成部分，但它也只不过是数字城市建设的第一步。数字城市也可能需要有线的宽带设施，并且它不限于网络。数字城市提供互操作，和基于网络的政府服务，政府人员、企业和社会公众都可以随时访问政府主要业务。数字城市服务通过无线移动终端访问，而且是面向服务企业架构包括网络服务、XML和移动应用使用软件激活。
数字城市的主要内容是城市设施的数字化、城市网络化、城市的智能化。数字城市的广泛应用，对城市的繁荣稳定及可持续发展都有着巨大的促进和推动作用。
1.3.2智慧城市
智慧城市通过物联网基础设施、云计算基础设施、地理空间基础设施等新一代信息技术以及维基、社交网络、Fab Lab、Living Lab、综合集成法、网动全媒体融合通信终端等工具和方法的应用，实现全面透彻的感知、宽带泛在的互联、智能融合的应用以及以用户创新、开放创新、大众创新、协同创新为特征的可持续创新。伴随网络帝国的崛起、移动技术的融合发展以及创新的民主化进程，知识社会环境下的智慧城市是继数字城市之后信息化城市发展的高级形态。
1.3.3地理空间框架
是地理信息数据及其采集、加工、交换、服务所涉及的政策、法规、标准、技术、设施、机制和人力资源的总称，由基础地理信息数据体系、目录与交换体系、公共服务体系、政策法规与标准体系和组织运行体系等构成。
1.3.4基础地理信息数据库
是基础地理信息数据及实现其输入、编辑、浏览、查询、统计、分析、表达、输出、更新等管理、维护与分发功能的软件和支撑环境综合。
1.3.5基础地理信息
作为统一的空间定位框架和空间分析基础的地理信息。
1.3.6公共地理框架数据
公共地理框架数据（简称“框架数据”）：针对社会经济信息空间化整合和网络化服务需求，以现有基础地理信息数据为基础，加工形成面向地理实体，分层细化为重要特征的数据，由地理实体数据、电子地图数据、地名地址数据、影像数据与高程数据构成。根据应用范围不同，又细分为政务版公共地理框架
数据和社会公众版公共地理框架数据。
1.3.7政务地理信息图层
是指在政府管理部门规划、管理、决策和服务中所需要的、可共享的政务地理空间信息资源，它按照矢量数据模型及相应的属性数据分层组织，形成与电子政务业务有密切联系，有明确空间定位的，多个部门均需使用且使用频率较高的政务地理空间数据集。他同时具有空间特性和政务管理的权威、标准、现势等政务特性。政务地理信息图层共享维护原则：“权威数据来自权威部门，由权威部门维护共享”。
2. 项目概述
2.1建设目标与意义
2.1.1建设目标
“CreatMap 地理信息共享服务云平台” 是实现全国在线地理信息服务所需的信息数据、服务功能及其运行支撑环境的总称。其建设目标是：建成由多级节点构成的一体化地理信息在线服务体系， 实现全国地理信息资源的纵横联通和有效集成； 建成分布式的地理信息服务系统，形成多级互动的地理信息综合服务能力，提供一站式地理信息综合服务；建成“公共服务平台”服务管理系统，形成有效的运行服务机制，为政府宏观决策、国家应急管理、社会公益服务提供在线地理信息服务， 全面提升信息化条件下国家地理信息公共服务能力和水平。具体包括：
1）实现全国地理信息资源的互联互通：依据统一技术规范，整合全国多尺度地理信息资源，实现基于网络化运行环境的地理信息资源互联互通。
2）提供一站式的地理信息综合服务：建成分布式地理信息服务系统，提供
信息浏览、标图制图、导航定位、信息加载、系统搭建等网络化地理信息服务功能及二次开发接口，为政府、企业、公众提供在线地理信息服务。
3）形成业务化运行维护与管理机制：建立健全“CreatMap 地理信息共享服务云平台”运行维护有关规定和管理办法，建成“CreatMap 地理信息共享服务云平台”服务管理系统，形成不间断运行服务机制，为“CreatMap 地理信息共享服务云平台”的资源管理、服务调度、运行监控及适时更新提供有力的保障。
2.1.2建设意义
“CreatMap 地理信息共享服务云平台”建设项目入贯彻科学发展观、落实《国务院关于加强测绘工作的意见》和《全国基础测绘中长期规划纲要（2006- 2020） 》的重要举措，对于增强我国地理信息公共服务能力、发挥地理信息资源的最大效益、提升全社会地理信息资源开发利用水平、促进国民经济又好又快发展具有十分重要的意义。
1）切实提升我国地理信息公共服务能力：“CreatMap 地理信息共享服务云平台” 建设项目将作为信息化条件下我国地理信息公共服务的主要运行形态与手段，向各类用户提供权威高效的地理信息实时综合服务。这将极大地提升我国地理信息公共服务能力， 有效地缓解地理信息供需矛盾，较好地满足政府、企业、社会大众对地理信息在线服务的需求。
2）有效促进地理信息的深入广泛应用：“CreatMap 地理信息共享服务云平台”将为广大用户阅览地理信息、加载专业信息、搭建业务运行系统提供高效工具，使地理信息服务能无缝地嵌入到各部门、行业的现有业务应用系统中去， 有效解决以往应用系统建设运行中存在的技术难度大、建设成本高、开发周期长、更新维护难等问题，促进地理信息更加深入广泛的应用。
3）充分发挥地理信息资源的最大效益： “CreatMap 地理信息共享服务云平台”将把分散在各地的地理信息数据资源整合为逻辑上集中、 物理上分布的统一地理信息资源， 成为国家信息化的最重要基础设施之一。它的建设与运行将有力促进跨地区地理信息资源共享与应用，有效避免“信息孤岛”现象，充分发挥地理信息在政府宏观决策、国家应急管理、社会公益服务、产业升级拓展、人民生活改善等方面的保障服务作用，发挥我国地理信息资源的最大效益。
４）有力推进地理信息产业的发展。 “公共服务平台”的建设与运行将使测绘从传统纸质地图、 数据提供服务提升为在线地理信息服务，从以往的相对静态服务逐步发展为实时综合服务。这一方面会带动我国地理信息获取实时化、处理自动化、服务网络化和应用社会化等方面的技术创新与系统研发， 另一方面将为一大批企业进行地理信息资源的增值服务提供开发环境， 有力地促进我国地理信息产业的发展。
2.2建设原则
2.2.1采用成熟产品原则
采用在省级、市县级项目中应用实践的、已经商业化的、成熟、稳定、安全的应用支撑平台。既满足本次部、省两级需要，也为后期市、县多级应用打下基础。
2.2.2使系统具备良好的易扩展性、可视化柔性设计原则
CreatMap平台需要支撑省级、市县级应用的快速开发及集成已有系统。因此，系统需要采用组件封装技术、可视化柔性定制设计技术，后期根据系统需要可扩展封装新的组件、扩展表结构、扩展流程设计等。以灵活应对地理信息业务变化过程中对应用系统建设的需求。
2.2.3公共服务组件完善原则
CreatMap平台要全面支撑地理信息的业务系统建设需要，因此，公共服务组件需要完善，包括但不限于流程组件、表单组件、门户组件、数据分析BI组件、应用服务器组件、GIS服务组件、视频服务组件等。
2.2.4通用业务服务组件结合环保实际需求封装
CreatMap平台应该提供通用业务服务组件封装技术及封装开发平台，便于根据地理信息行业特点，将通用性公共服务封装为组件，提高组件的复用性，提高
开发速度。
2.2.5软件开发全生命周期管理原则
软件开发不是交钥匙工程，软件要根据业务需求不断变化而不断完善优化。可见，如何保障软件开发时就能保障其科学性？后期如何对软件不断优化？是软件开发面对的问题。因此，一方面应用支撑平台需要采用“业务模型防真、软件集成开发实现、软件应用监测优化“的开发模式，使业务人员和技术人员一共参与软件的开发，保障软件的适用性。另一方面，CreatMap平台需要对软件开发过程进行全生命周期管理，便于当软件发生问题的时候能找到开发过程中那个环境出了问题，并即时完善、优化。
2.3建设内容
2.3.1地理空间框架总体设计
地理空间框架建设项目是建立在分布式网络基础上的，具有共同的几何参考坐标系统，可支持快速的空间数据集成。框架包括分布式异构的地理空间基础数据库和在不同层次上可实现对空间信息的管理、共享、集成和互操作的功能和接口。地理空间框架数据在物理上是分散的，而在逻辑上是一个整体。框架的基础数据在网络中心节点存储，而各种专题数据和空间处理方法可以在远程节点和其本地存储。各节点地理空间信息的融合是以共同的几何参照系统、数据模型和接口为基础的。地理空间框架数据作为添加新的专题信息的基础，允许各专业部门添加专题应用数据，这些专题数据可以相互融合和集成，为各级组织和部门的应用和决策提供支持。
地理空间框架总体设计是参照建设数字城市地理空间框架相关标准要求，结合各委办局对地理信息共享需求对本项目的建设内容进行总体设计，指导项目的实施。
2.3.2标准规范体系建设
CreatMap平台标准体系是地理空间框架数据服务平台建设与运行服务的基础，项目参照数字城市、智慧城市地理空间框架和国家地理信息公共服务平台建设有关的技术标准规范和管理规定，结合各委办单位实际情况，制订各委办单位地理信息公共平台的技术标准规范，包括数据标准规范、服务规范和应用规范等。
2.3.3应用示范建设
基于所构建的地理信息公共平台，选择国土资源管理系统开发与对接、公众电子地图系统开发与国家天地图对接、供气应用系统开发与对接，以应用部门业务需求为主导建立应用系统，并总结公共平台的应用模式，在政府及其各部门全面推广。
对接国家天地图平台
与国家天地图平台进行对接，实现国家、省、市的互联互通。
按照国家要求成功对接国家“天地图”平台，提供基本的地图浏览，数据查询功能，同时平台支持OGC标准规范的WFS，WMS，WCS及WMTS，REST，WFS-G等标准服务接口，提供基于javascript的二次开发接口。
2.4技术路线
2.4.1 SOA技术
SOA面向服务的体系结构
SOA（面向服务架构，Service Oriented Architecture）是一种软件体系结构范型，可以组织和使用处于不同所有者控制下的分布式功能。从技术角度看，SOA就是一种体系架构，它描述了一种IT基础设施，使得不同的业务服务可以相互交换数据，参与业务流程，通过灵活的互相协作方式来完成具体的业务操作。这些业务服务独立于编程语言，独立于实现方法，独立于运行环境。
2.4.1.1重点关注服务
SOA支持面向服务的开发方法，是对前续的面向过程、面向消息、面向数据库和面向对象开发方法的补充。
服务从更高抽象层次上定义，直接与业务相对应，且其实现可采用面向过程、
面向消息、面向数据库和面向对象等不同开发方法。
与面向对象的调用接口相比，服务一般定义较粗粒度的接口，会接收更多的
数据，消耗更多的计算资源。服务一般是用来解决应用间互操作问题，以及将服务组合成新应用或新的应用系统，而不是为应用创建具体的业务逻辑。
通过SOA，围绕服务构建IT 系统，有利于IT 系统更靠近实际业务要求，使IT 系统更容易适应业务变化的要求，另外，对已有应用系统，通过服务化封装，可以使这些系统得到更好的重用，能有效保护对已有应用系统建设的投资。
2.4.1.2高内聚、低耦合
松耦合是软件设计中一个重要概念，SOA 强调服务间的松耦合。在SOA 中松耦合包括以下几个方面：
接口松耦合
接口耦合是指服务请求者与服务提供者之间的耦合。度量的是请求者与服务提供者的依赖性。接口松耦合强调服务请求者仅需要根据已发布的服务契约和服务水平协议（或称服务等级协议）就可以请求一个服务，任何时候服务请求者都不需要了解服务提供者对内部实现的信息。即服务接口封装了所有的实现细节，使服务请求者看不到这些实现细节。
技术松耦合
技术耦合度量的是服务对特定技术，产品或开发环境的依赖程度。技术松耦合强调服务请求者和服务提供者的实现和运行不需要依赖与特定的某种技术，或某个厂家的解决方案或产品，从而减少对某个厂商的依赖。在SOA 系统中服务请求者和服务提供者可以使用不同技术实现，可以在不同厂商的环境中运行。
流程松耦合
流程松耦合度量的是服务与特定业务流程的依赖程度。强调服务不应与具体的业务流程相关，以便能够被重用于多种不同的业务流程与应用。这一点强调的是服务的可重用性，在SOA 系统中对业务服务的合理规划，使得一个业务服务可以在多个业务流程中得到复用，并且随着业务要求的改变，一个服务可以在变化后的新的业务流程中能够得到继续使用。
2.4.1.3重构的灵活性
在SOA系统建设中，基本的单位是实现业务功能的服务，而不是实现业务逻辑的对象，过程，函数等较小的技术单位。
服务与实际业务功能相关，具有明确的接口。这些服务可在不同的业务流程中得到重用，提高了服务的价值；其次在使用中只需按其接口要求进行访问，屏蔽服务实现细节，服务实现的修改不会影响到服务访问方的逻辑，提高了业务流程的适应性；另外，一旦业务流程变更，仅需对服务进行重新编排，并不修改服务本身，提高了业务流程实现的灵活性。
重构的灵活性，不仅可以使业务服务可以有更好的重用性，也使得业务流程更容易重构，使IT系统具有了更好的灵活性，可以快速面对变化的市场需求。
2.4.2 ESB总线技术
ESB总线技术
ESB是服务交互的核心组件，支持：
面向服务的架构。
消息驱动的架构。
事件驱动的机构。
ESB是一种基于标准的面向服务的骨干，它能够进行可靠连接和协调数百个应用程序端点。ESB为需要连接跨越不同数据中心分布的各种异构系统的企业提供了一种理想的体系结构，同时还保持了绝对的事务完整性。此外，它还提供几个通过部署时构造进行最初配置的高级服务，从而保护了门户应用程序，即不必经常对它进行修订和重新部署来管理后端上的更改。
2.4.3 J2EE技术
作为系统平台的基础，平台必须具有很好的可移植性和可扩充性。为了可移植，平台开发的技术尽可能与操作系统无关。谈到与操作系统无关的开发技术，必然首推JAVA。要使系统具有可扩充性就必须采用通用的组件标准。J2EE是Sun公司所颁布的标准，但已广为工业界所接受，J2EE的出现标志着用Java开发企业级应用系统已变得非常简单。
由于J2EE是多层的分布式体系结构，使系统的操作和运行具有很好的灵活性；先进的 Java计算方案如面向对象、独立于平台、快速集成、代码重用等，使系统具有良好的可移植性和可扩展性，所以我们选择J2EE作为系统的应用服务平台。
J2EE为搭建具有可伸缩性、灵活性、易维护性的业务系统提供了良好的机制。
1）支持异构环境：J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构计算环境中是十分关键的。J2EE标准也允许使用与J2EE兼容的第三方的现成组件，把它们部署到异构环境中，节省了由自己制订整个方案所需的费用。
2）可伸缩性：基于J2EE平台的应用程序可被部署到各种操作系统上，为消除系统中的瓶颈，允许多台服务器集成部署，实现可高度伸缩的系统，满足未来业务系统的需要。
3）稳定的可用性：一个服务器端平台必须能全天候运转以满足业务运行的需要。将J2EE部署到可靠的操作环境中，将支持长期的可用性。
4）强大的应用开发能力：J2EE框架中的多种技术提供了应用开发的手段，如XML、JMS、RMI/IIOP、JCA，从数据级、组件级、应用级等层次支持国资监管信息应用的集成。
2.4.4集成Portal for ArcGIS构建CreatMap平台
Portal for ArcGIS包含在 ArcGIS for Server标准版和高级版中，提供以地图为核心的内容协作，可以部署在自己的基础设施中（内部部署或在云中部署）。Portal for ArcGIS是ArcGIS平台的一个核心组件，提供的功能包括快速创建、组织、授权和管理组织内部的地理资产。
使用Portal for ArcGIS，可以进行：
管理用户单位自己的地理信息资源；
访问ArcGIS Online提供的地理底图、GIS工具和分析服务；
在线创建地图、Web应用；
在用户单位内外，分享地图和Web应用；
将本地、现有的ArcGIS for Server服务注册进来进行管理；
基于群组实现日常工作的协同办公。
2.4.4.1带来全新的GIS应用模式：
Portal使得GIS功能与网络技术结合得更加的紧密，在为用户带来诸多便利
的同时，为组织内资源利用的协同与共享带来了合理的解决方案。
2.4.4.2实现了服务托管的功能
用户无需搭建、维护ArcGIS for Server环境，即可实现GIS服务的发布与管理。
2.4.4.3 Portal可以作为ArcGIS私有云门户：
借助Portal，用户可以实现对云GIS当中资源服务的管理，并能直接使用这些资源服务实现地图浏览、专题图制作以及创建应用等功能。
2.4.5基于WebService服务接口实现与业务系统对接集成
WebService主要是为了使各自孤立的业务系统之间的信息能够相互通信、共享而提出的一种接口。Web Service通过使用Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、WSDL等，实现不同系统之间的信息交换，Web Service可以在任何支持这些标准的环境（Windows，Linux）中使用，主要用于跨网络或跨系统之间的信息互通和共享。WebService应用特点：
（1）跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上大量的开发时间。另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过WebService的方式把应用程序的逻辑和数据公布出来，还可以让其它平台上的客户重用这些应用程序。
（2）应用程序集成
在传统企业级应用中，用户需要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过WebService方式，应用程序可以用标准的方法把功能和数据公布出来，供其它应用程序使用。
例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService，订单执行程序可以把“AddOrder”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
（3）软件和数据重用
软件重用涵盖了许多层面，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。用WebService集成各种应用中的功能，为用户提供一个统一的界面，当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮
政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给使用者。两种情况下，代码及代码背后的数据，都可以得到重用。
从以上论述可以看出，WebService是通过Web进行互操作或远程调用的有效的手段之一。本项目将充分利用WebService等技术手段来实现与各业务系统进行数据同步交换。
3. 软件工程开发实施管理规范标准
3.1总纲
软件工程项目要在满足用户需求的条件下，尽可能做到高可靠、高性能，同时又受到成本和交付期的限制， 成功地完成软件开发工作的一个主要决定因素就是软件管理。本标准参照我国软件工程国家标准（表-1） ，结合具体的实践情况编制而成。
表-1 软件工程国家标准
3.1.1目的
计算机软件由于其固有的特性：
1) 抽象性：没有形体，自然没有一般制造业产品所具有的几何尺寸，
物理性质和化学性质。 2) 复杂性：软件内部结构复杂。 3) 多样性：没有完全相同的软件。
4) 易变性：软件在开发过程以及交付使用后常常会出于各种原因而修
改。
5) 软件需求难于把握：软件开发常常会出现用户弄不清自己的需求、
讲不清自己的需求、开发人员理解不透用户的需求，在开发过程中 再三要变更需求。
因此要保证软件产品的开发质量其标准化是实现软件产业化的最必要的前提，其目的就是按标准规范管理软件开发的每一个生产环节，做到标准化，过程化。让软件开发的所有过程都能按 ISO9000 标准受控，同时使繁琐的标准描述简化成图表描述。
3.1.2任务
在软件生存期中，其主要的任务是：管理过程、获取过程、供应过程、开发过程、操作过程、维护过程和支持过程。将其简化描述成“项目管理过程” 、 “配置管理过程” 、 “主要过程” 、 “质量管理过程” ，使这四部分工作的每一步骤的管理、通信、文档格式、执行过程都标准化是其主要的任务。
3.1.3组织结构
要保证软件开发的质量，其基本前提是有一个合理的组织结构保证软件的实施过程。否则所有的一切都是空中楼阁。
3.2软件工程过程规范
3.2.1目的
本节目的是规范软件工程开发过程的总体任务和实施管理的生存期模型，用现代科学技术知识来设计并构造计算机程序，为开发、运行和维护这些程序建立所必需的相关文件资料， 在成本限额内按时完成开发和修改软件产品所需的管理技术标准。
软件工程的过程是将软件工程的方法和工具综合起来达到合理、 及时地进行软件开发的目的。 方法是要求使用顺序、可交付的文档资料，为保证质量和协调变更建立所需要的管理，以及确定软件开发各个阶段完成的里程碑。
工具为软件工程方法提供的自动或半自动的软件支持环境，可将软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环 境。
基本目标是付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，使开发的软件易于移植，只需要较低的维护费用，能按时完成开发工作
及时交付使用。
3.2.2
软件生存周期模型
3.2.3软件开发过程
3.2.4过程执行中的作用
1) 项目管理：制定计划、监控计划实施、评价计划实施、评估项目风险、可能的技术攻关，涉及到有关过程的产品管理、任务管理。
2) 系统开发：系统需求分析，系统结构设计，软件需求分析，软件结构设计，软件详细设计，软件编码和测试，软件集成，系统集成，系统合格测试，软件安装及验收支持。
3) 质量管理：软件产品质量保证，合同、过程、需求、设计、编码、集成和文档的验证，产品质量测试。
4) 配置管理：配置计划、配置标识、记录配置状态、评价配置、发行管理及交付，文档资料归档管理。
5) 维护管理：问题和变更分析，实施变更，维护评审及维护验收，软件移植及软件退役。
6) 项目经理：定义和分析用户需求，提供招标准备、风险评估、合同准备和验收，评审需求，制订并实施项目计划，评审和评价产品。
3.3需求分析过程标准
3.3.1需求分析任务
通常软件开发项目是要实现目标系统的物理模型， 将功能和数据结构分配到这些系统元素中。目标系统的具体物理模型是由它的逻辑模型经实例化表现出来，需求分析的任务就是借助于目标系统的逻辑模型表现出所需要的问题，即具体的工作为：
目标系统的功能需求（功能描述）
目标系统的业务需求（业务流程）
目标系统的业务优化（业务重构）
目标系统的数据需求（数据流程）
目标系统的功能性约束和非功能性约束需求（性能描述）
3.3.2需求分析过程
需求分析过程分为四过方面：
1）问题识别
功能需求
性能需求
环境需求
可靠性需求
安全保密需求
用户界面需求
2）分析与综合
3）编制需求分析文档
4）需求分析评审
软件需求分析工作流程图
需求开发流程说明
3.3.3需求分析业务关系
3.4系统设计过程标准
3.4.1任务
概要设计，任务包括：
1) 设计系统的物理实现方案，内容：
划分组成系统的物理元素（程序、设备、存储数据结构等） ； 确定数据在组成成份间的流向 ；
系统的边界 ；
2) 设计软件的整体结构，划分程序功能模块，决定模块间的接口关系 ；
3) 设计系统全局的存储数据结构，文件或数据库 ；
4) 设计系统输入输出的方式和格式 ；
5) 设计系统的安全性、出错处理、和代码等 。
详细设计：任务包括上面的内容外，核心任务是进一步把软件的功能模块细分为程序模块，设计每个模块的实现细节，如算法和程序控制逻辑。
1) 系统流程图——表达软件系统处理流程，即数据在系统各结构中的流动关系 ；
2) 模块结构层次图——表达软件总体的模块结构组织 。
描述设计思想的内容：
描述系统概述
系统流程图
程序模块结构图和关系描述
数据存储结构图和关系描述
软件接口设计原则
软件功能需求和数据存储结构，程序交叉引用表
系统安全性设计
3.4.2设计过程流程说明
3.4.3设计流程关系
4. 测试过程标准
4.1目的
为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束前进行严格的技术评审，在编码阶段对软件进行单元测试、组装测试、系统测 试，以确保软件的产品质量，本节的目的就是规范测试过程的标准化，使软件 质量体系得到充分地保证。
4.2任务
在软件质量体系中其主要任务：
1）质量保证体系
2）文档资料技术评审（需求分析和系统设计评审）
3）单元测试（白盒测试）
4）组装测试（黑盒测试）
5）系统测试（验收测试、验收走查）
在软件需求开始后就必须通过对软件功能和需求的情况组织测试计划，确定开发过程的测试点和评审关系。表-2表示了各测试步骤中的测试种类关系。
4.3测试过程关系
4.4质量确认体系
5. 质量评审内容
5.1需求分析评审内容
1) 系统定义的目标是否与用户的要求一致；
2) 系统需求分析阶段提供的文档资料是否齐全；
3) 文档中的所有描述是否完整、清晰、准确反映用户要求；
4) 与所有其他系统成分的重要接口是否都已经描述；
5) 所开发项目的数据流与数据结构是否足够、确定；
6) 所有图表是否清楚，在不补充说明时能否理解；
7) 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
8) 设计的约束条件或限制条件是否符合实际；
9) 开发的技术风险是什么；
10) 是否考虑过软件需求的其他方案；
11) 是否考虑过将来可能会提出的软件需求；
12) 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
13) 有没有遗漏、重复或不一致的地方；
14) 用户是否审查了初步的用户手册；
15) 软件开发计划中的估算是否受到了影响。
5.2设计评审内容
1) 评价软件的规格说明是否合乎用户的需求；
2) 评审可靠性；
3) 评审保密措施实现情况；
4) 评审操作特性实施情况；
5) 评审性能实现情况；
6) 评审软件是否具有可修改性；
7) 评审软件是否具有可扩充性；
8) 评审软件是否具有互换性；
9) 评审软件是否具有可移植性；
10) 评审软件是否具有可测试性；
11) 评审软件是否具有复用性；
12) 评审软件是否具有互连性。
5.3程序质量评审内容
1) 软件结构：
功能结构，数据结构、功能结构、数据与功能结构之间的对应关系 功能的通用性
模块层次、与功能层次的对应关系
模块结构，控制流结构、数据流结构、与功能结构之间的关系
处理过程的结构。
2) 运行环境的接口：
与其他软件的接口
与硬件的接口
与用户的接口
3) 变更的影响范围：
与运行环境的接口
在每项设计工程规格内的影响
在设计工程相互间的影响
4) 软件代码：
可读性，注释说明清楚。
可理解性，逻辑思维清晰。
结构合理性。
技术通用性。
6.配置管理标准
6.1配置管理目的
软件开发过程中随着工作的进展会产生许多信息，如规格说明书、需求说 明书、设计说明、源程序、目标程序、用户手册、各种数据、测试结果；以及 合同、计划书、会议记录、报告等管理文件。一个中大型项目这些信息数量将 达到数百个甚至上千个。如何管理好这些信息，同时在软件开发过程中出现的 变更是不可避免的，对于如此庞大且变动中的信息集合，如何使其有序高效地 产生、存放、查找和利用成为软件工程项目十分突出的问题，配置管理的主要 目的就是建立一套严谨、科学的管理办法。
6.2配置管理内容
软件配置项是软件配置管理的对象，指的是软件工程过程中产生的所有信 息项，包括计算机可执行的源代码、目标码、数据库以及计算机不可执行的文 档资料、源程序清单，测试用例等，主要内容有：
1) 与合同、过程、计划和产品有关的文档及数据；
2) 源代码、目标代码和可执行代码；
3) 相关产品包括软件工具、库内的可复用软件、外购软件及顾客提供的软件等。
6.3配置管理的任务
实施软件配置管理要做的工作：
1) 制订配置管理计划。在软件工程项目制订开发计划时，应使开发计划包括配置管理计划。在配置管理计划中规定配置标识规则，建立怎样的配置数据库及如何将配置项置于配置管理之下，配置管理人员的职责及配置管理活动，以及采用的配制管理工具、技术和方法。
2) 实施变更管理，这是配置管理的一项重要内容，许多软件工程项目没
有变更管理措施导致出现混乱。
3) 实施版本管理和发行管理。
配置管理要做的事是标识变更、控制变更以及发布变更。软件配置管理人员需要解决的问题：
1) 采用什么方式去标识和管理数量巨大的程序、文档等的各种版本。
2) 在软件产品交付用户之前和交付之后如何控制变更，实现有效变更。
3) 谁有权批准变更以及安排变更的优先级
4) 用什么方法估计变更可能引起的其他问题。
具体表现的任务：配置标识、版本管理、变更管理、配置审核及配置报告。
6.4配置过程关系图
7.软件项目管理过程标准
7.1软件项目管理过程目的
软件项目的特殊性使得软件管理的重要性显得更加突出和重要，表现在项 目的延误交货期、产品运行不可靠、实际开发成本上升以及产品的不良性能等。一些中大型项目的问题主要在于管理方法上，管理过程就是实现项目科学的合理化管理目的。
项目管理人员的责任主要在制订开发计划和确定进度要求，监督项目按计 划实施，保证开发活动按规定的标准执行，控制开发进度，保证项目在规定的
期限内，在预算的范围内完成任务。
软件工程项目的特点：
1) 软件产品的不可见，开发的进展以及产品的质量是否符合要求并不是那么明显，因此难于把握。
2) 不存在标准的软件过程，无法预料某一个特定的软件过程可能会引起开发的问题。
3) 大型软件项目往往是一次性项目，无经验可借鉴。
基于以上几个方面的问题，软件的开发管理比其他工程管理更困难。
7.2软件项目管理过程主要任务
软件项目管理的对象是软件工程项目，它所涉及的范围包括了整个软件工 程过程。为使软件项目开发获得成功，必须对软件开发项目的工作范围、可能遇到的风险、需要的资源（人、硬/软件） 、要实现的任务、经历的里程碑、花 费的工作量（成本） ，以及进度的安排等一一计划好，使管理作到心中有数。软件项目管理过程是从软件开始到软件项目终止的一个项目生命周期，主要在如下几个方面：
1) 软件项目的开始启动
确定项目的目标和范围，目标标明软件项目的目的，范围标明软件实现的基本功能，并尽量以定量的方式界定这些功能。从项目管理者角度方面考虑，主要是考虑项目实现的计划性和可管理性，而不必要在具体技术上考虑如何设计实现这些软件功能，和怎样实现这些功能的具体方法手段。
2) 软件开发工作的度量
进行度量工作是为了帮助软件开发人员了解产品开发的技术过程和产品，改进开发过程，提高产品质量。其作用是有效的定量地进行管理，把握软件工 程过程的实际情况和所产生的产品质量。
3) 项目开发的估算
软件项目管理过程中最关键的活动是制定项目计划，在做计划时，必须就需要的人力、项目持续时间、成本作出估算。其主要的内容为：
建立软件的工作范围；以软件度量（以往的度量）为基础作出估算；把项 目分解为可单独进行估算的小块。
4) 风险分析
每一个新建的软件总是存在某些不确定性， 是否能准确地理解用户的要求，在项目最后结束之前要求的功能能否实现，是否存在目前技术上的难题，是否会因某些变更因素造成项目严重延误等等，是项目开发的主要风险。风险分析对于软件项目管理是决定性的，风险分析贯穿在软件工程过程的一系列风险管理中，包括风险识别、风险估计、风险管理策略、风险解决和风险监督。
5) 进度安排
每个软件项目都要制定一个进度安排，对于进度安排，需考虑的是： 预先对进度如何计划
工作怎样就位
如何识别定义好任务
如何识别和监控关键路经
对进展如何度量
如何建立分隔任务的里程碑
6) 追踪与控制
制定了开发进度计划，就可以开始着手追踪和控制活动，项目管理人员负责追踪在进度安排中标明的每一个任务。借助项目管理工具软件可自动对进度安排的变化进行调整和资源重新定位分配。
7.3管理过程的主要职能
软件管理的主要职能包括：
1) 制定计划：规定待完成的任务、要求、资源、人力和进度等。
2) 建立组织：为实施计划、保证任务的完成，需建立分工明确的责任机制。
3) 配备人员：任用各种层次的技术人员和管理人员。
4) 指导：鼓励和动员软件人员完成所分配的工作。
5) 检验：对照计划或标准监督和检查实施的情况。
项目追踪和控制：
1) 定期举行项目状态会议。每位项目成员报告他的进展和遇到的问题。
2) 评价在软件工程过程中所产生的所有评审的结果。
3) 确定由项目的计划进度所安排的可能选择的正式的里程碑。
4) 比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。
5) 非正式地与开发人员交谈， 以得到对开发进展和刚冒头的问题的客观评价。
管理过程制定的计划：
1) 项目实施计划（软件开发计划），包括任务、进度、人力、环境、资源、组织等多个方面。
2) 质量保证计划：把软件开发的质量要求具体规定为在每个开发阶段中可以检查的质量保证活动。
3) 软件测试计划：规定测试活动的任务、测试方法、进度、资源、人员职责。
4) 文档编制计划：规定所开发项目应编制的文档种类、内容、进度、人员职责等。
5) 用户培训计划：规定对用户进行培训的目标、要求、进度、人员职责。
6) 综合支持计划：规定软件开发过程所需要的支持，以及如何获取和利用这些支持。
7) 软件分发计划：软件开发项目完成后，如何提供给用户。
软件的范围：
软件范围包括功能、性能、限制、接口和可靠性。由于成本和进度的估算都是与功能有关，因此常采用某种程度的功能分解。性能的考虑包括处理和系统响应时间的需求。约束条件则标识外部硬件、可用于存储或其他现有系统对软件的限制。接口的性质和复杂性是对开发资源、成本和进度的影响的一个不可忽略的部分。
8.软件维护标准
8.1软件维护目的
软件产品开发完成投入使用后， 常常由于各种理由需要对它作适当的变更，原来的功能和性能可能不在适应用户的要求，需要作变更；软件工作环境可能有变化，经常配合软件工作的硬件有了变动，如添置了新设备等；在软件运行中发现错误，需要改正。通常把软件交付使用后的变更称为维护。
维护的目的归结为：
1) 改正在特定使用条件下暴露出来的一些潜在的程序错误或设计缺陷。
2) 因在软件使用过程中数据环境发生变化，需修改软件以适应这种变化。
3) 用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能的要求，为满足这些要求，需修改软件。
维护活动的内容：
1) 改正性维护：由于开发时测试的不彻底、不完全所留下的隐藏错误。
2) 适应性维护：硬件环境的变化和数据环境的变化，导致软件的修改。
3) 完善性维护：使用过程中提出新的功能与性能要求。
4) 预防性维护：为了提高软件的可维护性、可靠性对软件的修改。
8.2软件维护活动
软件如何进行维护，应当如何组织维护活动，以便有效地完成软件维护任务。为了有效地进行软件维护，应建立维护机构，申明提出维护申请报告，评价过程，规定维护申请的处理步骤，建立维护活动登记制度及评价和评审标准。
1) 对于管理者，其维护活动的具体内容有：
2) 维护机构：建立确保维护可靠的职责关系。
3) 维护申请报告：按规定提交维护意见和处理意见。
4) 维护工作流程规范化：使管理人员和执行者清楚工作的关系。
5) 维护文档记录备案：确认软件系统的变更和软件质量情况的评价。
6) 维护评价。
9.文档编制标准
9.1文档编制目的
软件所包含的文件有两类：
1) 开发过程中填写的各种图表， 称为工作表格；
2) 应编制的技术资料或技术管理资料，称为文档。
一般软件开发过程有可能产生的文挡有14种：
1) 可行性研究报告：目的是说明软件开发项目的实现在技术、经济和社会条件方面的可行性，评述为了合理地达到开发目标而可能选择的各种方案，并论证所选定的方案。
（技术开发文档）
2) 项目开发计划：目的是用文件形式把开发过程中对各项工作负责人员、开发进度、所需经费预算、所需软/硬件条件等问题作出安排，并以此为根据开展和检查项目的开发工作。（管理文档和说明性资料）
3) 软件需求说明书：目的是使用户和软件开发者双方对软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 （技术开发文档）
4) 数据要求说明书：目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。 （技术开发文档）
5) 概要设计说明书：目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为程序详细设计提供原则和基础。（技术开发文档）
6) 详细设计说明书：目的是说明一个软件系统各层次中每一个程序（即每个模块或子程序）的设计考虑（技术开发文档）
7) 数据库设计说明书：目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。 （技术开发文档）
8) 用户手册：目的是使用非专门术语，充分地描述该软件的功能和基本的使用方法，使用户通过手册能够了解软件的用途，以及如何在不同情况下正确使用。（管理文档和说明性资料）
9) 操作手册：目的是向操作员提供该软件的每一个运行的具体过程和相关知识，包括操作方法的细节。（管理文档和说明性资料）
10) 模块开发卷宗：目的是以一个模块或一组密切相关的模块为记录，记录和汇总低层次开发的进度和结果，以便于整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。 （技术开发文档）
11) 测试计划：目的是为程序系统的组装测试和确认测试提供计划，包括每项测试活动的内容、进度安排、设计考虑，测试数据的整理方法及评价准则。（技术开发文档）
12) 测试分析报告：目的是把组装测试和确认测试的结果、发现及分析写成文件加以记载。 （技术开发文档）
13) 开发进度月报：目的是及时向有关部门汇报项目开发的进展和情况，
以便及时发现和处理开发过程中出现的问题。（管理文档和说明性资料）
14) 项目开发总结报告：目的是为了总结本项目软件开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各方面的评价。（管理文档和说明性资料）