武汉市建设委员会
电子政务总体设计及实施方案
评估报告
软件工程是一套关于软件开发各阶段的定义、任务、作用的建立在理论上的一门工程学科。它为解决软件危机，指导人们利用科学、有效的方法来开发软件，提高及保证软件开发的效率和质量取到了一定的作用。
软件开发过程具体可分为：
需求分析--概要设计（静态结构）--详细设计（动态结构） --编码-测试-维护
下面从软件工程实施的角度来看《方案》中所述的需求分析、总体方案、本期建设内容和实施进度几个方面。并将《方案》中提出的需求、设计和工程实施过程中需要的需求分析，设计内容做比较。
《武汉市建设委员会电子政务总体设计及实施方案》(下简称《方案》)从建委概况，建委现状、电子政务发展趋势、经济和社会效益几个方面概要的介绍了本次项目，对建设目标、规模、内容和周期做了说明，并说明了项目实施的必要性。
项目的建设目标和可行性分析
建委概况
武汉市建设委员会是武汉市建设行政管理工作政府部门，其主要职责可分为：
? 计划职能
? 行业管理和监管职能
? 综合协调职能
其内部组织机构可分为：（详见第三章第一节单位简况）
? 局机关
? 十六个委直属单位
? 9个区所属建设局
建委各机构职责见《方案》第三章第二节说明
建委在日常工作中，会与下列市局和省厅以及中央机构有工作往来：
应用系统现状
武汉城建委目前的系统有在用、在建和计划建设的系统。下面是目前系统的情况说明：
网络现状
网络基础设施现状
l 市建委机关及直属单位已进行了综合布线，建成了局域网
l 武汉市电子政务外网平台已建成
l 市建委机关、建设信息中心、设计审查办公室已通过光纤和无线接入市电子政务外网
l 市交易中心通过VPN方式与市建委机关实现网络互联互通。
政府门户网站及办公系统建设
l 武汉市电子政务外网平台――“中国武汉建设网”已完成第一阶段建设，实现政务公开
l 中国武汉建设网（交易中心）、勘察设计网、武汉市城市建设档案馆初具规模，且与“武汉建设委员会”政府网站相连
l 中国武汉建设信息网能实现市建设工程交易中心的网上招投标。
l 市建委机关及设计审查办公室、市城建档案馆（市建设信息中心）已开发建设了办公自动化系统在试用、推广
电子政务发展趋势
电子政务的最终目标是要建立网上服务型政府。但其建设一般可以分为四个阶段：
l 信息发布阶段
l 市民与政府单向互动阶段（网站表格下载等）
l 市民与政府双向互动阶段（市民通过各部门网站进行申请、证件办理、网上通知）
l 一站式的网上分布式协同办公阶段
我国大多数政府部门的建设都处于二、三阶段；而武汉市建委的电子政务建设还处于一、二阶段。
新项目建设的必要性，可行性
从电子政务的发展趋势，以及武汉市建委目前的基础设施现状，武汉建委的电子政务建设处于第一、二阶段，所以建设电子政务可说是刻不容缓的事情。同时，各种法律，基础设施的建设，都为武汉建委建立电子政务奠定了坚实的基础。
建成后的效益
建委电子政务的实施会给武汉市城市建设带来的效益表现在：
l 规范管理制度和办法，极大地提高办事效率，法定的办事周期可以合理的缩短。
l 利用GIS会大大提高质监安全、安检检查、执法检查的效率与科学性。
l 利用信息技术把工程的生命周期至于全委和市民的监督下，工程的造价、质量会更合理，更有保障。
l 市内多局委的联合办公对于税收征管、建材市场的管理都有很大的提高。
l 把城市的房屋建设置于市民的监督下，让老百姓住上放心房，这是政府执政为民的重要方面之一。
l 把建筑企业的行为置于网上，这对于规范企业的行为由很大的帮助。
l 把工程全生命周期的数据、企业的相关数据放在网上保存，可以保证数据的可靠和真实性，也可以方便企业办事，办证。
l 城市建设的规模直接关系着武汉经济的发展速度，武汉招商引资条件和整个武汉市的社会运行效率
《方案》在概要的说明了本项目情况后，随即从需求分析、总体设计思路、本期建设内容设计思路及实施进度、投资估算方面说明了本次项目如何实施。
下面从施工可行性方面来看需求分析和总体设计
工程实施可行性
需求分析
业务流程分析
首先看需求分析方面，《方案》在需求分析中，概要的说明了建委的职责，及在政务网上实现的需求描述：
接下来，《方案》描述了城市建设的主要业务----建设工程----的全生命周期，
并对该生命周期中，行政管理事项及流程做了分析，把流程中涉及的相关单位，传送的文件，存储的文件做了详细说明。行政管理事项及流程的最后，对流程图中文件做了归类，统计了工作项目中交换的文件数、存储的文件数。并给出了备注。
详细资料参看第四章第三节—行政管理事项及流程分析。
在需求分析的后面，指出了现行行政管理事项及流程中存在的问题，总结出了结论：
1． 协同工作(委内、委外)
协同性：工作的时序性，工作结果的因果性，信息的共享性
问题：各单位自成系统，缺乏协同工作方式和观念。靠上级领导协调才能协同工作
解决办法：实现跨局、委、办的协同办公
2． 对外服务的多样性
问题：对建筑企业，从业人员的服务呈多元化
3． 数据存储的分不行和数据使用的集中性
问题：
? 工程数据、企业数据、从业人员数据存放时分散的
? 数据的使用是集中的，有序的，综合的
解决办法：建立权威、统一的企业信息库、从业人员数据库、工程数据库
4． 现有管理信息系统的问题及解决办法
问题：
? 业务系统的开发只考虑了本单位的需求，没有从全委的角度考虑
? 数据模型设计只为本单位服务
? 功能设计没有体现事务流动性
解决办法：基于统一平台进行整合
下面对行政管理事项及流程做个具体的分析。
从其中抽取的一个行政管理事项及其流程：
建筑业企业资质申请办理单位、文件关联图
数据业务属性：
在流程分析中，对发起单位，业务处理相关单位，传送的文件，存储的文件做了较为详细的描述。从业务上比较详细的说明了“建筑业企业资质申请办理”的流程。
但从以下方面来看：
l ?具体的业务怎么走(企业递交申请后的一步是什么流程)
l ?企业递交申请书和企业相关资料后，文件是直接交给建管办，还是交给工商局，抑或是会计事务所？
l ?流程的每一步具体存储哪些文件？
l ?流程的每一步的参与人是谁，也就是权限的定义，没有明确的指出。
这些细节，在流程中并没有体现出来。而如果没有这些细节，在项目实施过程中，实施人员无法根据详细的业务规则来定义计算机处理的流程，因为无法用准确的计算机语言来描述这个流程。
所以，在业务流程的定义中，详细的流程定义要补充进来。
这些详细的流程用当前软件工程中标准的统一建模语言UML描述出来，实施过程中才可以明确地用计算机语言来定义该业务流程。
如下图，就定义出了上面缺乏的步骤，若能以UML来定义，会有更好的效果，也可以在每一步后定义输入的文件，处理后存储的文件：
数据分析
在第二章第一节第二小节里，对数据的容量做了详述。
在行政管理事项及流程分析之后，紧接着《方案》从下面几个方面说明了对数据属性的需求（属性的详细说明见第四章第四节）：
数据业务属性
l 基础性
l 事务性
l 规范性
l 计划性与统计性
数据分类属性
l 基础数据
l 管理数据
l 过程数据
l 存档数据
数据逻辑属性
l 元数据特性
l 数据派生属性
l 数据的连续性、完整性
l 数据的判定性特性
数据管理属性
l 数据集中与分级管理
l 数据的保密性与安全性
l 数据的一致性
l 数据的交换与备份、恢复
我们非常欣赏在设计方案上将软件系统中的数据按照业务、分类、逻辑和管理属性来分类，这是非常正确地也是非常必要的。这样，能够使实施方对不同属性的数据的作用范围有一个清晰的认识。
很遗憾的是，我们没有看见设计方案中对数据状态变化的生命周期的描饰过程，这将使施工方因无法了解数据状态变化对系统产生的影响。
功能需求
方案中，对建委电子政务系统的功能，从逻辑上归纳为：
1． 政策、法规的只能查询
2． 网上受理与实时发布
3． 行政管理事项和行政处罚管理
4． 工程数据的动态采集
5． 建筑企业、从业人员的信息与资信管理
6． 办公事务管理
从业务部门分类为：
公共业务系统：
1． 资质、资格的申报、审批和查询管理
2． 企业资信、从业人员资信管理系统
3． 基于GIS的工程监控管理系统
4． 法律、法规智能查询系统
各部门业务系统：
1． 建筑业管理办公室
2． 安全生产管理站
3． 建筑工程质量监督站
4． 市政工程质量监督站
5． 招标办信息管理
6． 市场管理站信息管理
7． 商品混凝土管理站
8． 墙体材料改革与建筑节能管理
9． 建筑工程交易中心管理
10． 市建设工程设计审查管理
11． 城建档案管理
在上述的各逻辑划分，或者业务部门分类划分中，均只提到了系统大概的目的，没有说明什么是系统的明确功能。
我们认为明确的系统功能应该采用用例的方式来描述，这样可以明确实施方的工作，并量化其工作量。
明确的功能该是像下面的业务用例描述，以建筑企业、从业人员的信息与资信管理为例：
建筑企业、从业人员的信息与资信管理：
l 建立建筑企业的信息库
l 对建筑企业提出明确的资信评定等级
l 。。。
更进一步的描述应该采用系统用例的方式，如
如果没有上面的详细规定，将无法明确实施方的工作，也无法量化实施方的工作。同时双方没有办法来制定一个可以参照的验收标准。
性能需求
l 工程项目管理的事务性
n 规划，设计，招标，施工，竣工，验收，维护
n 不可中断，顺序严格
n 过程监控，全程可追踪
l 网上协同与同步/异步处理
n 建委的业务以工程项目为单位
n 对每一个项目的各个阶段的处理功能，有一些有同步的要求：比如施工许可证的办理和发放，只有在若干手续办理完毕，才能处理发放手续
n 有一些功能如监督登记，则是可以异步的
l 数据的分布存储与逻辑整体性
n 以工程为线索，工程全过程的数据在逻辑上是一个整体
n 但是按照业务性质，数据可以分不存储在各个单位
n 最终可以按照工程标志统一查询
l 系统的可扩充性、可维护性
项目的第一期任务主要是：总体设计、制定标准、建立数据中心，数据交换中心、整合开发的系统；但是建委电子政府的建设是一个较长时间的过程，所以系统要采用增量开发的方式，这就要求系统的可扩展性、可维护性要好。
l 数据处理的安全性
建委的数据是要长时间保存的，所以数据的安全、维护、恢复功能都必须具备。
l 操作的实时性和友好性
n 建委的工作人员操作相应时间要小于5秒
n 到达页面的击键次数应小于等于3秒
n 建委门户对外服务时间为7*24小时
总体设计思路
第五章“总体方案”部分从总体目标，本期目标这一远一近两个方面阐述了建委电子政务平台要完成的目标。
总体目标
建立“一站式”的、以服务对象为中心的网上受理与办事模式，实现“一网式”(建委电子政务专网+市政府电子政务外网)的部门间分布式协同办公模式。
本期目标
建设
l 建委电子政务制成平台
l 数据交换平台
l 共享数据库
l 相应的各项标准
l 整合遗留系统
l 确定新系统得开发原则
使建委的电子政务建设进入系统建设、增量建设阶段；为各类应用系统的全面开发、整合提供统一的运行和开发平台。
应用系统设计策略
已有系统的整合要求
《方案》列出了需要整合进电子政务平台的已有系统(即目前建委各单位在用的三个，在建的五个系统，见本文“应用系统现状”一节)；对已有系统的整合，提出了如下要求：
l 数据库层整合，建立统一的数据字典
l 采用适配器函数，开发接口，实现异构系统的互联互通
l 在B/S方式下开发的应用系统，适当调整网页形式，进行深层链接
l 应用系统共享数据库，利用适配器、JDBC、ODBC、适当修改SQL语句
l 有些应用系统不能满足要求，如软件结构、事务处理的起始点、事务性的控制不到位等，要在统一的标准下重新开发
已有系统整合的策略
l 采用C/S结构的系统，若是在部门内使用，功能不足或者不能完全提供其他部门、委机关所要的信息，要改造升级。一是继续用C/S结构，若改造任务较大，可考虑用B/S结构。
l 跨单位使用的系统，原则上用B/S结构
l 对于正在开发施工的业务系统应该采用B/S结构。要从建委整体集成方向考虑流程的定义。
新建业务系统有：
l 企业资质、资信管理系统
l 执业人员资格、信用管理系统
l 基于GIS的工程监督系统
l 各单位自行开发的系统
n 业务功能不需要整合到内外门户上
n 不访问其他单位的数据库
n 不提供数据给其他单位使用
l 联合审批系统设计
实现一门式受理，一网式协同办公
要实现的办公流程的规划：
对委内的联合审批要去基于委电子政务中心的工作流平台和数据交换平台实现框架：
n 对流程进行设计，有一些可能要重组，确定流程的逻辑顺序、处理节点
n 对流程处理的文件进行一致性设计
n 定义流程的处理角色、权限
n 制定在Windows、B/S方式的人机会话模版
n 设计处理模块流程图，并进行软件开发
n 定义流程流动路径
n 与内门户(或外门户)进行整合
n 组织流程相关单位，确定上线计划，上线试运行
n 建委统一发文，丢掉手工、纸质方式，正式投入运行
数据库设计策略
建立全委的数据字典，保证数据的一致性和完整性。在数据字典的基础上采用原数据库的思想保证结构数据的一致性和可交换性
全局共享的数据集中管理，采用分布――集中的方式进行数据集成
共享数据库：
企业数据库，从业人员数据库，工程数据库，法律法规数据库
建立全委数据库逻辑结构图
详细的数据库设计见第五章第四节“数据库设计”。
建立全局的数据交换标准，进行异构系统的数据交换
引进“本体知识管理”
n 实现建筑行业的基础知识的深层集成和互联互通
n 同其他局的协同办公。
在市电子政务平台建成前，可用电子邮件的方法进行文件的传送；市电子政务平台建成后，利用统一的工作流平台实现。
对于系统设计方面我们只看见了系统规划和策略，《方案》中的只能说是概要设计。
而对于实施方来说，更需要的是详细设计，这样，实施编码会更顺利地进行。
同时，系统设计中的测试设计在《方案》中也没有体现出来。
本期建设内容设计思路
本期建设内容包括：
l 应用系统设计
l 数据库设计
l 标准设计(信息交换标准)
l 软件平台设计
l 网络设计和设备选型
网络设计
l 采用星型网络拓扑结构。
l 对关键设备，如核心路由器和物理链路实现冗余备份
数据库设计
数据库的设计从下列方面说明了要设计的数据库内容：（详见《方案》第六章第三节）
l 数据标准设计
l 数据字典设计
l 数据编码规则设计
l 数据交换设计
l 数据交换标准设计
l 数据的分布设计
数据库设计应该将现实里的实体—关系，以及数据流图描述清楚。
在“数据库设计”一节中，对分散在各单位中的数据，与电子政务中心共享数据库里的数据中的流向做了一个简单描述。
方案中的“数据库的设计”中对下列内容没有做出说明：
l 有哪些数据库
l 数据库的使用者是谁
l 各个实体（对应到数据库中是具体的表或者视图）的确切属性
l 各个实体间的关系
l 数据的访问权限
l 各功能模块中的数据流程
应用支撑平台设计
《方案》分析了建委的信息系统特点，对应用支撑平台在电子政务系统中的作用做了如下的描述：
应用支撑平台的组成：
l 数据交换平台
n 数据交换平台主要实现各单位、不同业务系统之间的信息交流。
n 提供集成器，对数据信息解析后，按照制定信息包标准，从局委信息中心发送到相应单位的发送端口处
n 提供适配器，将交换数据库中的数据转化成XML格式与平台系统进行数据交换
n 信息交换规范：包括所有系统接收、发送数据的XML规范，分技术规范(消息头)和数据规范(局委和下属单位交换数据的规范)
n 有异构系统数据信息要交换时，发送系统的应用程序通过适配器接口函数把数据打包发送给信息交换平台，数据格式在平台中通过集成器进行相应的转换，成为下一个系统可以识别、接收的形式，接受部门使用适配器接口函数获得数据。
l 工作流平台
支持网上协同办公的平台，功能：
n 流程建模――可视化的流程定义
n 流程模拟――对设计完的业务流程模拟运行
n 刘琛国运行环境――跨平台、跨应用的工作流引擎
n 流程仓库管理――流程定义管理、流程服务管理、流程服务接口管理
n 流程部署――发布到业务流程仓库，供流程运行环境用
n 流程管理与监控――性能监视、业务流程调整、异常处理
n 流程审计――对创建、资源应用、执行日期及人员、结果
n 流程分析与优化――提供统计表、分析流程中的数据，对影响性能的节点优化
应用系统设计
应用系统设计部分，对下面几个系统做了设计上的说明，说明了如何整合现有的应用系统及在统一平台下开发新的应用系统：(详细内容见《方案》第六章第五节“应用系统设计”)
l 办公自动化系统整合设计
l GIS系统设计
l 基于知识只能查询系统设计
l 建委统一开发的应用系统
l 直属单位应用系统
建立全局的数据交换标准
进行异构系统的数据交换
系统安全设计
在安全设计部分里，就建委处于的安全级别，从行政管理手段、设备技术、容灾备份、安全认证等方面，对系统的整体安全做了设计说明。
详细的设计说明，参考《方案》第六章第七节
设备与软件配置
l Oracle9i数据库一套
l 数据交换平台一套
l 数据交换接口：接口数（预计10个）十套
l 工作流平台一套
l 操作系统Windows或Linux
l 中间件WebSphere或WebLogic
GIS平台一套
已有下列设备：
l 网络设备已具备(哪些网络设备)
l 计算机设备：两台数据库PC服务器、一台数据交换服务器、磁盘阵列设备
项目实施进度
分为：
l 总体设计阶段（20##-3------20##-5）
n 现状及需求调查 15个工作日
n 现状与需求调查资料整理，产生需求分析文档 10工作日
n 用户审查需求分析文档 5工作日
n 需求文档修改5工作日
n 制定电子政务整体设计与实施方案25工作日
n 用户审查方案5工作日
n 方案修改5工作日-----时间偏紧，特别是缠身工序秋风恩西文档加用户审查的时间
l 平台及数据交换中心建立阶段（20##-6------20##-10）
n 设备采购 15个工作日
n 设备安装及调试 20工作日
n 接口开发，模型建立 20工作日
n 数据采集 10工作日
n 办公自动化系统集成，内门户集成 5工作日
n GIS数据采集、整理、输入 60工作日---时间偏紧，特别是借口、模型的设计和GIS数据录入的时间
l 各个应用系统开发阶段（20##-8------20##-8） 200工作日
n 对已有的业务系统在统一平台上整合
n 对尚未开发应用系统的二级单位在平台上统一开发
缺乏系统测试和调整，优化的时间。
l 全面整合阶段（20##------2007）（200个工作日）
n 对建委个流程优化，在全委实施。同市政府各局委办系统进行全面整合。
详细的阶段内容说明参考《方案》第七章第一节“项目建设期”
综合《方案》中对需求分析、系统设计里提到的内容，对大致的系统结构，功能模块做了一个较为详尽的描述。
但是，系统地概要设计和详细设计都没有明确的定义，一方面是需求分析中，对行政管理事项及流程里，没有以科学的面向对象分析方法来描述，导致无法提取实际流程里的具体参与对象，比如参与者，可能发生的事件，可能的异常事件等等。
若在需求分析里，以标准的面向对象的方法将需求做一个好的分析，用“用例图”的方法描述流程，那么在接下来的概要设计里，会很容易提取各种用例图中的各种对象，分析这些对象中的属性，操作，以及对象间的关系，就非常容易了。
就像下面的用例图，描述了用户能够处理的各种事情，用户与系统交互的事情也关联起来。
接下来用顺序图，按时间先后顺序，从上到下分析事件，确定事件的处理流程；或者用协作图来细化用例图。下面以顺序图为例说明：
而随着概要设计中细化了各种对象，在详细设计中，细化类的操作，对象之间的消息对应，填充参数以及复杂的类设计，也会较为容易了。
投资估算
对电子政府建设的总投资在总体设计方案中进行概算。
因为有多个应用系统要统一开发，各应用系统的开发量、GIS系统建设的方式还未确定，所以只对第一阶段做概算。详细见《方案》第八章。