企业管理信息系统技术平台考察报告文档格式.docx

企业管理信息系统技术平台考察报告文档格式.docx

《企业管理信息系统技术平台考察报告文档格式.docx》由会员分享，可在线阅读，更多相关《企业管理信息系统技术平台考察报告文档格式.docx（66页珍藏版）》请在冰豆网上搜索。

2.开发模式

XX软件公司开发模式基本处于源代码级开发，项目实施具有实施周期长、开发成本较高的特点。

相对公司A和公司B软件平台代表国内勘查设计行业管理系统软件平台一流水平，XX软件公司目前仍然走单纯项目开发的模式，采用部分较先进的开源和商用开发组件保障软件质量和开发效率，没有成形的软件平台，究其主因是由于公司规模、行业经验、资金投入等有限，这是中小型软件公司软件开发模式普遍存在的问题。

由于XX软件公司是代码级开发，没有平台化开发的策略和计划，因此各项目间现有技术的积累和提炼比较缺乏，大量有价值的技术没有充分共享，重复开发工作较多，为用户提供额外附加应用价值少，每个项目的软件功能基本来自用户需求，对用户需求水平要求高。

因此XX软件公司项目实施的周期和成本相对公司A和公司B，将明显加长和上升。

完全源代码开发从理论上讲可实现各种复杂需求，本次考察过程，考察人员提出XX软件公司目前不具备的技术和功能，XX软件公司均表示可专门开发。

但源码开发实施周期长、不易快速适应变化。

管理软件不断动态变化，对于变化，此类软件项目通过不断修改代码适应变化，维护实效较低，并且对维护人员专业技术要求较高，维护成本高。

目前XX软件公司与用户每年签订软件维护合同，客户A仅外部网站一项，每年维护费用数十万，而我单位每年维护费用也有10多万。

3.实施经验

XX软件公司企业管理软件的客户主要为SD行业的企业，主要业务集中在门户系统、OA办公自动化、经营管理、技术质量管理等。

其OA软件、技术质量软件等均得到用户一定程度的好评。

据XX公司介绍，XX软件公司目前的业务系统虽然不少，但尚缺乏为企业全面实施管理信息系统的实际案例，并且其系统用户数一般均不大，据其介绍，客户A的经营管理系统是使其用户访问数最大的一个业务系统。

从我公司X管理系统实施和维护情况看，XX软件公司实际软件服务水平较好，服务响应比较及时，不会因一时费用影响项目实施。

从XX软件公司和总院关系渊源看，其服务质量也能得到一定保障。

从上述情况可知，XX软件公司有一定的技术实力，服务较好，但客户实施经验相比较公司A、公司B尚不足，尤其是全面实施客户信息化的经验仍然不够充分。

4.主要技术特点

XX软件公司没有软件平台，但有自己的框架组件。

软件框架组件与软件平台的根本区别之一在于软件平台面向从开发者到系统用户等多层次人员，框架组件则几乎完全面向开发人员。

XX软件公司的开发组件主要由门户系统组件、用户组织机构组件、权限组件，工作流组件，公开源代码的第三方Structs、Spring、Hibernate技术框架，以及界面组件、Office文档组件等第三方商业软件构成。

XX软件公司门户系统的门户内容定制必须借助代码开发（除基本的链接部件外），门户信息栏目的定制和门户栏目授权和门户结合不紧密，另外门户目前对视频、音频、FLASH等常见等多媒体信息不支持，但其门户系统提供了灵活的界面显示定制，每个用户均可自由定制需要显示的部件、大小、位置等。

XX软件公司权限管理粒度较粗，只能授权到菜单和功能操作，字段级别的权限控制只能针对性定制开发，达不到我公司目前权限管理字段级灵活授权的深度。

其权限管理基于角色管理和用户授权，比公司B灵活，比公司A缺少岗位职务授权和组织机构授权。

XX软件公司工作流引擎属于简单但专业化的开发工具，工作流引擎可灵活支持一般性的工作流定义，但不支持子流程，并发流程必须全部完成才能进入下一汇聚环节，无法设置其它并发条件（XX软件公司称其工作流引擎工作流各项功能均支持，为简单实用，进行了裁剪）。

还存在工作流定义界面定制功能少，流程授权不方便、工作流没有直观灵活的图形化跟踪，数据条件的定义过于专业等问题。

目前较为成熟的工作流系统和表单系统已经做到流程和表单完全分离，表单内容可灵活定制，信息和操作权限可灵活授权，工作流可灵活搭载不同表单。

公司A和公司B此技术表现较好，基本达到上述水平。

XX软件公司的工作流和表单为紧密耦合，没有表单定制，必须完全代码开发，并且表单和流程必须捆绑使用，流程处理均须结合源代码代码开发，普通用户无法掌握。

在OA应用方面，工作流、权限管理、与Office集成应用是公文管理系统的核心功能。

整体看，XX软件公司公文系统流程定制需要开发人员编程，后台维护不便，但在公文电子印章安全性、公文存储、条件流转、与手机集成等方面有一定特色，可借鉴。

其它具体技术细节，可参见附件《管理信息系统技术水平考察指标表》。

5.数据迁移问题

我公司现有系统积累大量数据，要求数据完整迁移。

其中公文系统信息为非结构化存储，其数据迁移复杂程度非常高，该系统开发商公司A也认为次数据完整迁移难度和工作量均较大。

现实是，由于数据本身类目繁多、数量庞杂，公司间存在技术壁垒，因此数据迁移始终存在不可知风险。

一个现实的例子是，公司B实施某客户数据从公司A平台迁移到公司B平台时，仅迁移部分最终数据，中间数据无法迁移，全部丢弃。

而XX软件公司认为我公司数据迁移在技术上可完全完整平滑迁移，问题主要在于工作量大小。

XX软件公司此前未做过异构软件系统的数据迁移，仅实施过本公司新旧系统间的数据迁移。

尽管XX软件公司承诺可完全实现，但实际风险必然存在，而且由工作量所导致的成本问题亦是风险之一。

6.技术转移

XX软件公司承诺为客户提供为客户定制开发的所有软件源代码，除了不提供工作流引擎代码外，可提供包括其门户管理、权限管理、用户管理等所有基本软件模块的源代码，并表示用户可派人到其公司参与开发，提供详细技术资料，态度较开放。

Dorado界面组件、Office文档组件等第三方软件，XX软件公司承诺授予免费使用权，并免费升级。

由于XX软件公司项目主要基于代码开发的特点，相对于公司A和公司B不开放软件平台，仅开放应用系统源代码而言，XX软件公司向用户开发源码后，其系统未来的可扩充性更强，对用户持续、自主、大范围实施系统改造，提供更为有利的条件。

这也同时要求必须尽快培养或引进我公司的J2EE专业软件开发人员，否则若无法实现技术转移，则相比较公司A和公司B，更受制于人。

六、考察总结

XX软件公司软件开发过程中，缺乏对优秀实现技术的充分积淀和提炼，全面实施企业管理信息化的经验不足，要达到并超出当前系统建设水平的难度和代价较大。

其次，对于系统数据迁移，XX软件公司尽管承诺不存在技术问题，实际问题的复杂性和前车之鉴均表明数据迁移是一个复杂和风险巨大的工作，即便在技术方面理论上可实现，但其可能的实施成本和代价难以估算。

在进度方面，平台化开发的公司A和公司B，其定制部分工作量基本超出40%，实际代码开发不到60%甚至更少。

而XX软件公司几乎全部需要编码实现，其项目实施周期将显著加长，同时软件后期维护的专业技术要求高、时效较低、代价高。

在技术转移方面，XX软件公司软件系统未来持续改造的空间大，受制程度较低，但对于我公司也存在其J2EE技术路线与目前微软.NET技术路线不一致，须要配套建立起一支同时掌握.NET、J2EE两项技术的专业技术队伍的问题。

七、考察结论

综上所述，XX软件公司在质量、进度、成本等方面，相对于平台化开发的公司A和公司B有较大风险和困难；

但在技术转移上，XX软件公司的开放态度，以及J2EE本身的开放性，更有利于我公司掌握未来自主实施系统大范围系统改造的主动性。

信息化首要任务是建设满足实际需要的信息系统，其次是技术转移，因此，综合前期对公司A和公司B的考察结果，建议选择公司A作为行政管理系统升级项目的开发商。

附件：

管理信息系统技术水平考察指标表

2011-6-24

评分标准：

优秀（5分），良好（3分），一般（1分），差（0分）

序号

分类

权重

评价内容

评价指标

公司A

公司B

XX公司

备注

1

技术

10

技术水平

软件开发技术先进

5

公司A、公司B：

都采用了.Net4.0以上版本，

XX公司：

采用J2EE，结合Hibernate、Spring、Structs,Dorado等技术

技术架构设计规范，标准统一

3

2

公司A：

系统复杂灵活，但平台架构较松散，不断补充完善

公司B：

基于整体的规划设计，结构紧凑清晰，不允许采用通用开发平台开发

没有统一平台的约束，其设计、代码的规范性不易保证

开发技术向后兼容

公司A旧版本及对三方软件，影响其兼容性，平台升级工作量大

平台升级工作量小

升级工作量小

系统运行环境的跨平台特性

公司A、公司B基于.NET，对Linux、Unix不兼容

XX公司采用J2EE，跨平台部署应用良好

数据库系统的跨平台特性

公司A、公司B两个平台均能同时支持SQLServer和Oracle

XX公司开发框架支持跨SQLServer和Oracle平台

平台可灵活配置

可细致配置到字段、节点，几乎考虑到每一钟可能性

配置功能较粗，如：

无权限、门户、及一些基本配置无定制界面，输入检查依赖代码编程，缓存信息无同步设置等等

开发框架配置功能非常弱，仅门户样式、用户、信息发布、文件存储有些初级配置功能，公司A、公司B的配置功能在XX公司开发框架中要靠代码开发实现

支持复杂灵活的应用

4

框架页面的灵活定制，支持图形界面的交互，树状界面的灵活配置，可任意扩展应用；

复杂界面需平台部专门开发，用户扩展受限制较多；

定制开发方式能够适应复杂业务，但做不到灵活复用，灵活全靠代码调整，工作量大，效率比较低

数据完整性保证

基本通过数据库约束和程序代码实现；

通过主从视图、建立数据关联，统一进行事务处理

框架已经封装好事务处理，所有业务都是自动处理事务

系统部署

服务端分布式部署和应用

可否进行数据库分布布署

服务端部署及维护简单

润乾报表部署Tomcat应用服务，文件传输采用FTP站点，安全问题

客户端非接触无安装部署

B/S系统集中部署，已逐步淘汰AcitiveX控件

安装.netFramework；

升级时客户端会出现版本冲突

B/S系统集中部署，公文系统使用AcitiveX控件

客户端维护工作量小

7.8

7.7

功能

25

集成和共享

第三方信息系统集成能力

对B/S系统的集成，大致相同；

对C/S暂无方案

单点登录功能

方案基本相同

门户定制和信息组织、发布和展示

采用B/S，展现方式更灵活丰富；

门户信息展示方式简单，可配置性不强

B/S门户，最终用户可自定义样式展现内容，门户栏目内容定制全部依靠代码开发实现，仅能自定义链接部件；

不支持文档浏览、视频播放

全文检索技术成熟度

采用开源全文检索引擎，正在做技术研究，检索仅支持文本文件

采用AV提取文件（Office、dwg等）文本内容，存入数据库，利用SQLServer本身的全文检索功能进行检索

在总院知识管理中应用了全文检索技术（采购商业软件），已经研究了Lucene技术（公司A正在研究应用）

流程管理

业务流程建模灵活性

条件处理丰富、使用流程数据字典、表达式、跨流程环节的回退处理

业务流程跟踪管理

图形化流程跟踪界面提供数据穿透，公司B仅支持图形跟踪界面

仅有简单记录

流程的灵活调整和应变能力

两者都可随时调整流程，并具备历史版本功能

工作流定制工具易用程度

皆为图形化界面、用鼠标拖动

流程的历史版本管理

两者都有此功能，处理中流程仍可按原版本流程处理

变更业务流程的简便性和及时性

公司A、XX公司：

集中式部署，变更迅速体现

登录时检查，

多表单业务信息承载

多表单操作更为灵活，可给每个流程环节设置不同的表单

多表单间难以协同办理

必须开发单独的页面，将多表单连接起来；

一个表单有多人编辑时，需要单独编写多个不同的编辑界面

流程环节权限设置

没有友好的配置界面，人员和角色需要按特殊编码规则手工输入

工作流功能丰富

仅有较简单的流程定义，不支持子流程，分支流程关系仅有与的关系，表单和流程在代码层次上进行绑定，表单和流程不能脱离；

通用表单

集成化多数据源信息展示和操作

两者都可附加多数据源，但公司B必须为主从视图（数据源）

完全代码开发

表单样式可灵活定制

公司A采用B/S，样式更加灵活

表单权限可灵活控制

对表单控件的权限更加细化，可设可见/不可见；

暂时没有，承诺可做

组织机构

组织机构变动时，变更操作的简便性

两者都无历史数据管理功能，组织机构发生变化，历史数据需手工修改；

组织机构修改时，可用鼠标拖动

业务过程跟踪

业务过程监控、跟踪

甘特图、时序图、关键路径、里程碑；

业务执行过程的数据通讯、数据库访问跟踪

业务系统工作日志记录和跟踪

业务日志、运行错误日志、Trace跟踪

业务日志

登录日志

决策支持

驾驶舱统计图表支持

均提供丰富的图表展示方式

决策信息立体化展现

数据列表、图表均支持数据穿透功能，提供数据列表字段级的关联信息提取和展示

未看到图表的数据穿透，数据列表不支持字段级的信息提取

统计报表多样性、灵活性

采用润乾报表商业软件，满足中国式报表设计

采用的报表系统不如润乾实用

采用皕杰商业报表组件

统计报表最终用户的灵活定制

公司B支持在客户端指定显示项目、统计项目、行列转换等功能，并可将指定的个性化保存于客户端

移动（手机）办公

手机流程审批和办公

可审批表单

采用短回复方式

专门开发手机浏览网页，可办理批复

广域网信息传递的性能

传输数据和界面

仅传输数据，数据二进制

及时通信工具

广域网上的稳定性和易用性

自主开发的软件，正在试用阶段

腾讯RTX商业软件产品

采用开源的Web即时消息，传输采用HTTP协议

大文件传输的稳定性和性能

采用FTP协议传输，传输稳定

功能丰富，简单易操作

腾讯RTX商业软件产品提供会议、视频等多项功能

与信息系统集成程度

拥有自主知识产权，紧密集成，基础数据共享，集成业务工具条

第三方系统，做不到无缝集成

基础工具软件整合

与基础工具软件双向整合（CAD、Office）

可将信息管理系统与CAD、Office整合

目前还未实现与Office的整合

与Office作了单向集成，主要用于OA，

与基础工具软件的深入整合程度

能够做到XX软件数据的自动采集和定位

能够做到XX软件数据的自动采集

存储空间管理

优化的文件存储方式

基本一致，均无压缩存储

磁盘空间易管理

存储目录超出限定，自动创建新目录

支持分布式存储空间

可设置多个数据存储位置（FTP、共享文件夹）

部署文件服务器站点

无分布式存储

系统易用性

简洁细致的界面交互

用户界面较灵活精细，支持丰富的用户界面展现形式；

界面设计相对较粗，如：

不支持界面多层嵌套，无默认的输入检查，参数信息没有分类组织；

单选按钮采用复选框

界面效果较好，属于纯代码级开发，不可配置

丰富的用户体验

B/S界面用户体验丰富；

浮动菜单、图形交互、框架界面等，通过构建样式多样的交互界面，提供简便的操作

系统维护

提供系统维护工具

公司A未提供系统维护工具，规划中有；

公司B的建模工具可以作为工具使用

没有维护工具

数据库维护的工具

公司A提供的数据工具功能相对强大；

公司B可用建模工具对DB维护

其它

OA公文收发系统技术成熟度

OA系统深入集成Office的应用

有较为成熟的技术和应用

没有看到此类技术应用

采用重庆软航Office文档控件，能够实现套红、盖章、电子签章方面

小计

19.2

16.7

11.0

性能

海量信息的处理能力

服务器业务信息会全部推送客户端，数据量大时，可造成客户端崩溃（公司B客户是否多中小客户，数据量不大）

用户访问并发能力

业务逻辑发生在客户端，应用服务期压力小；

可能有数据库瓶颈；

应用服务器和数据库服务器均会产生瓶颈

服务器关键资源利用能力

采用了缓存技术，可自动/手动释放内存；

公司A、公司B、XX公司都可进行CPU负载均衡

客户端计算资源利用能力

业务逻辑在客户端处理，业务在客户端缓存

数据访问层性能

底层数据访问基本靠HinernateORM技术实现，规模较大的并发访问性能相对较差

数据库存取访问技术

采取了分页技术，但其SQL、存储过程的规范标准化方面更依赖于开发人员；

规范、标准化较好

采取了数据库级别的分页技术

6.7

8.3

6.0

安全

安全性

权限控制灵活精细

公司A在权限管理上做的较细，基本涵盖了所有可能

有字段级权限控制（不支持字段隐藏），没有列表、工具条的权限控制

没有字段级的权限控制，没有列表、工具条的权限

权限系统方便管理

完全基于角色管理，冗余大；

用户扩展功能的权限不能配置，代码实现；

类似公司B，字段级权限完全依靠编写代码控制

集团化权限管控

公司B有相应的功能，但使用不广泛

数字证书

可通过浏览器绑定数字证书,加密通讯

有自己的数字证书服务，可使用数字证书加密通讯

广域网信息传递安全性

公司A可采取SSL，但会加重服务端的负载；

公司B可采用客户端数据加密再传输，并可提供文件的加密

3.6

3.2

2.4

二次开发

20

开发效率和成本

高效率的设计和开发

平台复杂灵活，须同时掌握JS和C#，开发难度高，周期较长

平台规范一致简单清晰，仅须掌握C#，开发难度较低，开发效率较高

高效率的应用和维护

提供较为友好的用户界面设计，易于用户使用

比较低的开发成本和维护成本

系统开发难度较高，人员要求较高，开发周期较长

开发难度

开