----------------------------------招标机构发布信息原文:-----------------------
标题:2018年02月08日黑龙江八一农垦大学于下午发布大庆市政府采购中心关于黑龙江八一农垦大学高校建设项目软件及设备采购A项目采购招标公告2月8日
大庆市政府采购中心关于黑龙江八一农垦大学高校建设项目软件及设备采购A项目采购招标公告 大庆市政府采购中心关于黑龙江八一农垦大学高校建设项目软件及设备采购A项目采购招标公告 黑龙江省大庆市政府采购中心对黑龙江八一农垦大学高校建设项目软件及设备采购A项目进行采购,本项目面向各类企业进行采购,欢迎有能力的国内供应商报名参加。 《==招标投标法 第四十五条中标通知书对招标人和中标人具有法律效力。中标通知书发出后,招标人改变中标结果的,或者中标人放弃中标项目的,应当依法承担法律责任。==来源:十环网==》 一、项目编号:DZC20180020 二、项目名称:黑龙江八一农垦大学高校建设项目软件及设备采购A项目 三、采购方式:公开招标 本项目要求以电子标书参与投标,不接受纸质投标文件(除《原件(样品)检验登记表》要求提供的资料外),否则投标无效。具体报名及制作文件的步骤请参考http://ggzyjyzx.daqing.gov.cn/bsznTbr/20199.htm?pa=2221 咨询电话:0459-6375655 四、技术需求及数量:黑龙江八一农垦大学高校建设项目软件及设备采购A项目,第二标段控制价:4,493,700.00元,参与投标供应商投标最终报价超出控制价的投标无效。详细需求见大庆市公共资源交易中心网(http://ggzyjyzx.daqing.gov.cn/)《招标公告》。 《==招标投标法 第二十七条 投标人应当按照招标文件的要求编制投标文件。投标文件应当对招标文件提出的实质性要求和条件作出响应。==来源:十环网==》 五、供应商资格条件:除符合《中华人民共和国政府采购法》中有关供应商申请取得政府采购资格的相关条件外,还应符合下述资格条件: 二标段: 1、提供参与投标供应商有效的企业法人营业执照副本。 2、提供参与投标供应商有效的税务登记证。 3、提供参与投标供应商的检查机关出具的无行贿记录证明。 4、本项目不接受联合体参与竞争。 六、本项目面向各类企业进行采购,本项目对第二标段智慧校园融合中心,执行政府采购扶持中小企业的相关政策。详见《政府采购促进中小企业发展暂行办法》。 参与本项目供应商如属于小、微企业,则须提供“小微企业声明函”,格式详见招标文件第七部分。 (1)根据相关政策,参与本项目供应商为小型或微型企业的,且所投第二标段智慧校园融合中心产品为参与本项目供应商制造的货物,则对所投第二标段智慧校园融合中心,产品的价格给予6%的扣除,用扣除后的价格参与评审。参与本项目供应商需提供本企业的小微企业声明函(须按规定格式填写声明函一),未提供单项产品声明函的,则该项产品不享受价格扣除。 (2)根据相关政策,参与本项目供应商为小型或微型企业的,且所投第二标段智慧校园融合中心产品为其他小型或微型企业制造的货物,则对所投第二标段智慧校园融合中心产品的价格给予6%的扣除,用扣除后的价格参与评审。供应商需提供本企业的小微企业声明函(按规定格式填写声明函一),同时提供所投第二标段智慧校园融合中心产品生产厂家出具的小微企业声明函(须按规定格式填写声明函二),提供单项产品声明函不齐不全的,则该项产品不享受价格扣除。 注:以上“用扣除后的价格参与评审”是指开标现场,依据供应商所投第二标段智慧校园融合中心产品投标报价进行6%的扣除。如所投第二标段智慧校园融合中心产品的供应商投标单价超出该产品控制单价的,则该产品不享受政府采购扶持中小企业的相关政策。 七、报名须知 1、报名时间:公告之日起至2018年2月15日0时0分。 注:请参与本项目投标的供应商在2018年2月15日0时0 分前自助报名并下载招标文件,逾期则无法报名和下载招标文件,由此造成的后果由供应商自行承担。 2、该项目采取供应商网上自助报名方式。 在大庆市政府采购网或黑龙江省政府采购网注册的供应商且供应商注册信息审核状态达到“有效”或“入库”或“合格”状态,可网上自助报名。未注册的供应商请注册后,按照网站中“办事指南”中的说明网上自助报名。 3、咨询电话:0459-4671753(王海枫) 七、申请退出投标程序及注意事项: 1、报名参与本项目投标的供应商应严格遵守《诚信竞争承诺书》,如果供应商报名投标或下载招标文件后因自身原因需要退出投标,必须在投标截止时间72小时前,在大庆市电子政府采购交易管理平台提出退标申请,并说明合理退标理由。否则,计入不良行为记录名单一次。 供应商报名后无故未参与竞争或未按规定程序申请退出竞争的,将被计入不良行为记录名单。12个月内:供应商被计入不良行为记录1次的,我中心将限制其1个月内报名参与大庆市政府采购竞争;供应商被计入不良行为记录累计2次的,我中心将限制其3个月内报名参与大庆市政府采购竞争;供应商被计入不良行为记录累计3次的,我中心将限制其6个月内报名参与大庆市政府采购竞争。同时1年内不能被推荐为诚信供应商。 退出竞争事宜联系人:王海枫 联系电话: 0459-4671753 2、通过大庆市电子政府采购交易管理平台提出退标申请,并经我中心受理备案的,可在大庆市电子政府采购交易管理平台办理退还保证金事宜。 3、未按规定程序申请退出投标的,无权向大庆市政府采购中心申请退还投标保证金。 4、未按规定程序申请退出投标的,我中心将视情况作出相应处理。 5、已经在大庆市电子政府采购交易管理平台提出退出申请的供应商或擅自不参加本项目投标的供应商,不得再参与该项目后期的采购活动。 八、投标保证金: (具体交纳方式见 http://ggzyjyzx.daqing.gov.cn/bsznTbr/20199.htm?pa=9543,流程中的第4条) 1、参与本项目的投标方,须按相关规定向大庆市政府采购中心账户预交投标保证金:二标段50,000.00元,投标保证金必须由参与本项目投标的投标方以本单位对公账户名义,且以转帐方式交纳,不接受企业或个人以现金方式交纳投标保证金(包括直接将现金存到大庆市政府采购中心账户上的行为),不得以其他单位或以个人名义代交。投标保证金缴纳证明须扫描上传到大庆市政府采购中心管理平台投标文件中,否则,投标无效。 2、以担保保函方式提交投标保证金的,应提交经财政部认定的中国投资担保有限公司或经黑龙江省财政厅认定的黑龙江省鑫正担保集团有限公司或大庆市财政局认定的大庆市工商业担保有限公司、大庆市国盛融资担保有限公司出具的投标保函,或本单位对公账户开户银行出具的投标保函。投标保函应按招标文件中规定的“政府采购投标保函”样式出具,不按招标文件规定的“政府采购投标保函”样式出具的投标保函,大庆市政府采购中心不予接受。同时应将投标保函原件带到开标现场,并提供投标保函复印件一份,否则投标无效。 对投标担保保函咨询请与中国投资担保有限公司、黑龙江省鑫正担保集团有限公司、大庆市工商业担保有限公司、大庆市国盛融资担保有限公司联系,联系电话: 中国投资担保有限公司:010-88822574 黑龙江省鑫正担保集团有限公司:0451-87193058/87193059 大庆市工商业担保有限公司:0459-6621159 大庆市国盛融资担保有限公司:0459-6286075 3、大庆市政府采购中心账户信息: 户 名:大庆市公共资源交易中心 开户银行:中国建设银行股份有限公司大庆市直支行 账号:23050166930000000031 行号:105265000553 注:填写汇款单时,需要标注平台给予的订单编码,只需填写编码号,无需填写文字内容,否则谈判无效。款项须转账到户后,方可报名。 4、投标保证金不允许串项目使用,交纳其他项目的保证金不能用作本项目,其他项目的保证金如要用作本项目,必须在距投标截止时间一天前到我中心财务办理好调转手续,并要在保证金票据上注明所投项目的项目编号及用途,否则投标无效。 5、使用保证金年卡的供应商须将保证金年卡扫描上传到大庆市政府采购中心平台投标文件中,保证扫描内容清晰可查,否则投标无效。建议参与政府采购活动频率高的供应商办理保证金年卡,年卡可在投标(履约)保证金上限内重复使用,超出部分补差即可。保证金年卡可同时用作投标和履约保证金。 6、中标方的投标保证金可转为履约保证金(多退少补)。 7、投标保证金的退还:投标保证金一律采取转账方式无息退还至原汇款账户。未中标供应商请在中标通知书(中标公告)发出后主动在大庆市政府采购中心管理平台提出保证金退还申请。退款申请详细内容:未成交供应商全称、开户行、账号、金额、项目编号、联系人、联系电话。否则,投标保证金滞留的责任由供应商自行承担。 8、办理交纳或退还保证金事宜,如有疑问请与我中心办公室财务人员联系。 电话:0459—4671759,传真:0459-6370158。 9、发生下列情况之一,投标保证金将不予退还: ⑴投标开始后在投标有效期间,供应商撤回其投标资料。 ⑵中标方不按本文件及成交通知书规定签订合同协议。 ⑶将中标项目转让给他人,或者在投标文件中未说明,且未经大庆市政府采购中心同意,将中标项目分包给他人的。 ⑷拒绝履行合同义务的。 九、招标文件售价:免费。 十、预计投标截止时间及开标时间:2018年2月26日9时30分,具体时间以招标文件为准。 十一、注意事项: 1、报名后请主动到大庆市公共资源交易中心网(http://ggzyjyzx.daqing.gov.cn/)《招标公告》栏下载招标文件及后续发布的与本项目相关的各类文件(如:预备会纪要、变更通知、有关问题答复、质疑答复等相关文件)。 注:在大庆市政府采购网或黑龙江省政府采购网注册的供应商且供应商注册信息审核状态达到“有效”或“入库”或“合格”状态,可网上自助报名。自助报名须办理数字证书,未办理数字证书的请查看http://ggzyjyzx.daqing.gov.cn/szzs.htm《办事指南》栏目——数字证书申请表,咨询电话0459-6046136。供应商必须先报名,之后才可以下载招标文件。 关于下载招标文件及相关文件事宜,采购中心不另行通知,均以发布的文件为准。由于供应商未及时下载与本项目相关的各类文件而影响供应商正常参与投标以及产生的其他问题和后果的,责任由供应商自行承担。 2、参标供应商应详细阅读本公告,符合条件即可报名参与。本项目要求的供应商资格证明文件报名时不需提供,参标供应商将所有资格证明文件提供到开标会上,由评标委员会审查,经评审不符合条件者投标无效。 3、未在大庆市政府采购网或黑龙江政府采购网注册的供应商,无法网上报名。未在大庆市政府采购网或黑龙江省政府采购网进行供应商注册的企业,请到www.hljcg.gov.cn,点击进入“大庆”登记注册。 4、项目报名截止时未在大庆市政府采购网或黑龙江政府采购网注册的供应商,本项目报名无效;在开标前供应商注册信息审核状态未达到“有效”或“入库”或“合格”状态,则投标无效。 未通过黑龙江省政府采购网注册审查的供应商,请联系政府采购网所属地的采购管理办公室。大庆市政府采购管理办公室供应商入网审核咨询电话: 0459-4671886/4671883。具体要求请查阅http://ggzyjyzx.daqing.gov.cn/《办事指南》栏目——供应商参与投标指南流程第1条。 5、本项目开标过程全程音视频监控,如参与本项目投标企业或个人对开标过程有疑义,可以书面形式提出,由政府采购监督部门视情况调阅监控录像进行审查。因此,所有参与本项目投标企业和个人不得对开标过程进行录音、录像、摄影,或者通过发送邮件、博客、微博客等方式传播开标过程,一经发现,投标无效,造成损失和影响的,将追究法律责任(经允许的除外)。 6、单位负责人为同一人或者存在直接控股、管理关系的不同供应商,不得参加同一合同项下的政府采购活动。 集中采购机构:大庆市政府采购中心 集中采购机构地址:大庆市萨尔图区东风新村纬二路2号(大庆市行政服务中心三楼) 网 址:http://ggzyjyzx.daqing.gov.cn/ 集中采购机构联系人:王海枫 集中采购机构联系电话:0459-4671753 采购单位:黑龙江八一农垦大学 采购单位地址:大庆市开发区新丰路5号 采购单位联系人:罗昕 采购单位联系方式:13903698502 邮 编:163311 日期:2018年2月8日 项目需求 二标段: 黑龙江八一农垦大学智慧校园融合服务项目技术参数 第一部分 总体目标 (1) 针对学校的现状和实际需求进行顶层设计和规划,统一数据标准,建立信息规范,形成稳定持续的信息化建设的决策管理机制; (2) 建设数据共享中心、数据交换平台、融合服务门户、统一身份认证平台、快速开发平台,完善学校业务系统建设,以基础平台为支撑将学校现有的应用系统和平台进行改造整合; (3) 引入企业 SOA 架构的成功管理思想和技术,融合“大平台+中应用+微服务”现代化管理理念,建设能够全面支持学校整体运营管理和服务的数字校园基础平台(以下简称“基础平台”),基础平台提供统一管理数据、用户、权限、服务的便捷、安全、完善的手段,并为全校业务一站式服务系统的建设提供全面而有效的技术手段。 (4) 实现全校各类信息系统的基础数据和共享数据进行统一管理、集成与共享,彻底消除“信息孤岛”,并提供灵活、多样的信息服务。 (5) 基础平台能够有效、合理地集成全校各种应用系统,完成应用系统间数据的互联互通,通过融合门户提供个性化的、方便的、高质量的信息化服务。 (6) 基础平台提供集成的二次开发环境和接口标准,能快速开发基于基础平台运行的各种应用与服务。 (7) 建设能够全面支撑智慧校园的软件定义数据中心(招标人自备数据中心建设所需的软硬件,投标人提供技术支持和系统集成),统一管理全校各类信息资源,能够快速部署各种应用与服务。 (8) 建立有效的长期校内信息化运营保障机制。 第二部分 技术路线 (1) 基础平台和应用系统均可运行于Linux、Unix、Windows等高安全性操作系统。开发技术应采用J2EE 标准、组件技术及在数据交换上对XML的支持,使系统功能最优化,同时将整体系统内部在技术上的相互依赖性减至最低。 (2) 基础平台和应用系统均要求采用B/S结构,采用Java 编程语言和服务器端Java 技术进行开发,且必须基于Oracle 11g及以上版本。 (3) 采用面向对象的组件技术,着重于开发构成应用程序“业务对象”的可重复使用的组件,利用这些组件顺利地建立分布式应用程序。 (4) 应用程序开发与运行结构要基于统一的技术开发平台的三层架构,即Web服务器、应用支撑服务器和数据库服务器。 (5) 能完成跨业务部门的业务流程和相对应的细颗粒度的分级授权体系。 (6) 各应用系统要充分利用现有先进技术手段,采用相同的体系结构和运行平台,基于多层架构和组件技术进行构建,做到系统结构层次清晰。所有应用逻辑、流程、数据等都应当能够根据建设方要求的颗粒度进行封装。 (7) 系统支持负载均衡,支持动态监测负载状况,自动对可用资源进行并发检测,调整和分配等功能。 (8) 系统具有灵活应变和扩充的能力,能够根据实际业务不断调整,而在进行扩展的同时不能对已有应用系统造成影响。 (9) 产品架构和基于这一架构开发的融合门户系统应支持横向扩展和纵向扩展,并能实现负载均衡。 (10) 应用系统应对第三方系统免费开放应用Web Service接口、API、数据库等资源。 (11) 对招标单位人员进行轻应用开发培训。让授训人员熟悉开发平台、流程等,保证可以完成一些小应用的开发。 (12) 本次项目涉及的所有轻应用流程开发须基于学校已有的工作流引擎(Primeton EOS Platform) 实现,本着“易用、高效、稳定”的原则,投标人需对现有工作流引擎进行二次开发封装,打造快速开发平台,实现微应用的便捷开发,最大限度的减少应用开发对技术和代码的依赖。投标人需具备基于现有平台开发、实施对接的能力,确保投标产品与现有平台实现无缝对接。 (13) 本次项目所有开发的应用服务无需多终端重复开发,由统一应用管理中心平台,对发布到不同终端的应用进行统一管理,所有轻应用在各个终端可自动适配。 (14) 项目开标前不统一组织现场勘察和答疑,投标人须在投标前主动与校方相关部门进行需求的充分沟通,否则相关风险和责任由投标人自行承担。 第三部分 安全要求 本项目所有平台具有高度的安全性和稳定性,提供完善的安全体系,保证系统的信息安全、运行安全。充分考虑主机层、数据库层、网络层和应用层各个层面的安全隐患、扩展性和稳定性。提供安全手段防止非授权用户的非法侵入、攻击,避免操作人员的越级操作。关键数据采用加密传输机制。包括: (1) 权限控制:提供灵活、安全的授权体系,防止信息被越权获取。支持分级授权,便于把各类事务的管理权限分配给二级部门管理员, 二级部门管理员可以再次把自己的权限分解授权给具体办理人员。 (2) 附件上传控制:对所有上传的附件进行合法性及大小进行检查,杜绝危险文件上传。限定上传文件的操作系统权限,杜绝文件权限滥用。 (3) 注入攻击防护:平台提供注入攻击防护功能,能对文本、URL、模板包等包含的非法脚本进行过滤,防止录入恶意脚本。平台必须具备防SQL注入式攻击功能。 (4) 备份:提供系统对附件文档及数据库的自动备份机制,管理人员可设置备份周期,系统将按照预定周期自动备份整个运行目录以及数据库文件。备份支持完全备份方式和增量备份方式。在系统意外崩溃时能够确保完整恢复数据。 (5) 审计:所有业务操作需要有详细的日志记录。对管理员、信息员的所有操作提供审计日志。记录操作员及IP地址、操作时间、操作对象及其它必要信息。 (6) 平台监控:提供完善的系统运行状态监控能力,包括:主机运行时内存、CPU负载、恶意访问等进行监控,可与学校的安全监控平台整合。 (7) 认证授权:保证用户的合法性和用户使用信息资源的权力,避免内部敏感信息泄漏和服务所提供的信息资源被非法访问,造成严重的安全事件。 (8) 信息保密:充分利用密码技术,对于需要保密的信息,采用密码技术进行 加解密处理,防止信息的非授权泄漏,确保涉密信息在产生、存储、传递和处理过程中的保密。 (9) 网络传输安全:数据网上传输采用符合国家安全标准的加密方式,网页访问采用https方式。 (10) 数据完整性:建立数据完整性检验机制,保证收发双方数据的一致性,防止信息被非授权修改。 (11) 要求投标人从物理安全、网络安全、系统安全、应用软件安全、用户安全、数据安全等几个方面提出配套的安全体系完善方案,以便防范安全风险。 第四部分 项目建设内容及需求 4.1 项目建设内容 序号 | 系统名称 | 招标要求 | 数量 | 单位 | (一)智慧校园基础平台建设要求 | 1 | 融合服务门户平台 | 详见“项目建设需求”章节要求 | 1 | 套 | 2 | 统一身份认证平台 | 详见“项目建设需求”章节要求 | 1 | 套 | 3 | 信息标准 | 详见“项目建设需求”章节要求 | 1 | 套 | 4 | 主数据综合服务平台 | 详见“项目建设需求”章节要求 | 1 | 套 | 5 | 快速开发平台 | 详见“项目建设需求”章节要求 | 1 | 套 | (二)应用开发与集成改造建设要求 | 1 | 应用与服务开发 | 详见“项目建设需求”章节要求 | 1 | 批 | 2 | 系统及业务集成 | 详见“项目建设需求”章节要求 | 1 | 批 | 3 | 系统升级改造 | 详见“项目建设需求”章节要求 | 1 | 批 | 4 | 个性化服务 | 详见“项目建设需求”章节要求 | 1 | 批 | | | | | | 4.2 项目建设需求 4.2.1融合服务综合门户建设 构建基于PC端的综合服务门户,包括通知中心、日程中心、事务中心、下载中心、资讯中心、应用中心、消息中心等。融合服务门户旨在向师生提供各类办事、办公等在线信息化服务功能,可根据访问者身份为其推荐相关服务,能集成用户相关的业务信息,为各类办事服务的管理功能提供统一的入口。 序号 | 子项名称 | 需求描述 | 投标响应 | 1 | 通知中心 | 提供待办通知功能,展示需要我办理的事务,通过集成展示界面可直接进入办理界面,待办通知需要有汇总的个数显示;提供提醒通知功能,展示与我相关的事务提醒消息;提供将通知内容一键添加行事历的个人日程中;新通知内容可以通过微信提醒和邮件提醒方式,针对不同的内容可以定义不同的提醒方式。 | | 2 | 日程中心 | 提供日程中心功能,可以月历、周历和日历方式展示与我相关的行程安排,可查看某个行程安排的详细信息; | | 提供个人日程功能,可以创建个人的行程安排,可公开个人的日程供其它用户查看;日程中心中的行程安排需要提供提醒功能,可在手机端进行提醒。 | | 提供集成各业务系统行程安排在日程中心中展示的功能,比如校历、校部会议安排、课程表、工作安排和活动等。 | | 用户可以按业务分类选择需要显示在自己日程中心里的行程安排。 | | 3 | 下载中心 | 提供资料下载中心功能,可按分类下载会议材料、领导讲话、学习资料、行业动态和学校UI系列等资料,分类需要可自定义。 | | 4 | 个性化布局功能 | 为不同身份(教师、本科生、研究生)的人员提供不同的默认界面布局。用户可自主调整个人中心页面中各窗口部件的布局位置。 | | 5 | 事务中心 | 5.1 | 访问方式 | 需支持匿名访问和实名登录两种方式。不登录时,可以浏览和检索校内的事务及相关办理指南,统一身份认证登录以后,可获取与自身有关的事务,并可进行业务的办理。 | | 5.2 | 大厅界面 | 融合门户的界面要有良好的体验,既要体现现代风格和学校特色,又要让用户易懂易用。 | | 5.3 | 事务检索 | 提供多维度的事务分类,能按分类快速检索出符合条件的事务。提供对所有事务名称、简介等进行模糊查询功能,协助用户快速找到想办理的事务。 | | 5.4 | 事务推荐 | 可根据事务的办理申请热度,展示当前的热门事务;可根据登录者身份,为其推荐当前时期用户需要的服务。比如,毕业离校时为学生推荐离校办理服务;职称评定时期为教师推荐评职的相关服务。 | | 5.5 | 事务咨询 | 提供用户对事务咨询功能,各事务的管理员可对咨询进行解答。 | | 5.6 | 在线办理 | 为用户提供以图文形式介绍各事务的办理方法、政策、流程等相关信息,并可下载相关文档。 | | 对于已开通在线办理并需要审批流程的服务,用户可以在融合门户内在线发起办理申请; | | 对于有审批流程的服务,用户能够跟踪办理进度,即系统能够以流程图的形式直观地向申请人员展示当前已办理的进度、以及每个办理环节的处理时间、后续还需要哪些办理环节; | | 对于自助查询、自助服务等无审批流程的服务,用户可以通过融合门户直接打开相关服务功能。 | | 5.7 | 事务评价 | 提供用户对事务进行打分和评价功能,各事务管理员可以对评价内容进行审核与发布。 | | 5.8 | 事务排行 | 提供各类服务的访问排行、办结时长排行、每环节平均办理时间排行等统计排行功能。 | | 6 | 个人中心(为登录用户提供个人中心界面) | 6.1 | 办事跟踪 | 事务申请人员可以跟踪自己的历史已办结的申请。 | | 6.2 | 待办事项 | 事务各环节的办理人员可以收到到达自己处理环节的各项待办事项,可以查看自己的已办事项以及已办事项的后续进度、状态。 | | 6.3 | 服务咨询 | 各事务的管理人员可以在个人中心审核、回复用户的咨询。 | | 6.4 | 服务收藏 | 为不同身份(教师、本科生、研究生)人员的快捷栏缺省初始不同的事务或应用的列表。 提供个人的事务收藏管理。用户不仅能把融合门户提供的办事服务收藏到快捷栏,也能把校内的各类应用入口收藏到快捷栏。用户能够自主调整或移除快捷栏各应用及事务的排放顺序。 | | 6.5 | 消息查看 | 用户可以在个人中心查看到事务办理过程中的消息提醒。 | | 7 | 资讯中心 | 基于学校现有信息发布平台实现门户信息的统一发布,聚合网站数据、智慧校园相关平台或其他业务系统的数据来构建全校统一的资讯信息库,实现全校网站跨站点数据交换,确定统一资讯信息数据源。 | | 通过资讯服务实现资讯信息的准确性、一致性、可订阅、可推荐,增加敏感词过滤功能与站群后台无缝对接,可直接基于站群后台进行敏感词库的维护。 | | 8 | 消息管理中心 | 整合多种通信手段,将各种通信能力开放,无缝融入到办公、教学、科研和服务中,打造综合消息服务的平台,加快业务流程、优化管理和沟通方式,提升管理和服务效率。 | | 8.1 | 消息盒 | 消息中心应具备多类新型消息盒,至少包括用户消息盒、部门消息盒、应用消息盒。 | | 8.2 | 消息管理 | 对收发件消息可以设置接收策略、自定义标签、自定义文件夹、按会话模式查看、分类阅读、高级查询、地址簿管理等方便实用的功能。 | | 8.3 | 通信手段及多种寻址模式 | 用户可通过平台向其他用户通过多种方式发送信息,支持手机短信、邮件、移动app推送。支持系统地址、系统外地址两大类寻址模式。 | | 8.4 | 发送状态监控与已读反馈 | 提供发送监控与失败重复,能对push通道提供已读反馈,方便发送者了解。 | | 8.5 | 模板消息发送 | 支持模板消息发送,实现向学生批量发送成绩通知、欠费通知等个性化通知。 | | 8.6 | 消息格式 | 除了支持基本的文本格式的消息外,还支持外链消息,附件消息、图文消息、媒体消息等多种格式的消息。 | | 8.7 | 动态全局分组 | 提供全局组管理,可以创建动态组和静态组,提供两种方式的动态人员分组,一是动态全局组,一是动态机构。 | | 8.8 | 通讯录与地址簿 | 支持校园通讯录,提供灵活的权限控制,用户可依据权限看到人员及对应可见信息。用户可以添加自己的多个联系方式,设置联系方式的公开、共享范围。支持地址簿管理,用户可以自由创建地址簿并管理联系,并能按地址簿进行批量发送。地址簿内的联系人支持系统外联系人。个人或部门还可以向他人共享自己的地址簿。 | | 8.9 | 移动端发送消息 | 具备消息发送权限的人员能通过APP进行消息发送。推送与登录用户角色相匹配的消息,包括群发消息、各类业务系统消息等,支持文字、图片、外部链接等信息格式,点击每条消息可以进入消息详情界面;面向老师、部门提供权威消息通知的功能,用户能够向自己权限范围内的部门、班级群发消息,群发的消息除了以客户端消息接收外,还能以“短信”、“邮件”的方式发送给接收者。 | | 8.10 | 即时通信 | 支持即时通信,方便用户之间的交流互动。登录用户可以和自己的好友进行点对点会话、群组会话;也可以给同一个群组中的非好友进行临时会话,提供黑名单功能,用户可以把某些人加入到自己的黑名单,列入黑名单的人无法向自己发送即时消息及好友请求。 | | 8.11 | 权限控制 | 提供基于RBAC模型的授权机制,可以创建不同角色并设置其权限。为系统管理员、部门管理员提供的授权控制对象包括用户管理、功能模块、站内信的发送范围、各通道上的发送范围、流量额度等。授权对象可以是人员、组织机构、全局组;支持多级授权,系统管理员可以创建部门消息盒并制定部门管理员,部门管理员可以在部门内二次授权,还可以进一步创建子部门消息盒并对其授权。 | | 8.12 | 多级别通道流量控制 | 应提供通道流量控制功能,管理全校所有部门和业务系统之间的信息发送量,实现信息量有效分配;管理员可以查看各部门和业务系统之间的信息流量和额度,并可以对部门总流量额度、月流量额度、周流量额度以及日流量额度进行设定,满足用户多样化的需求;可以针对部门(组织)、人员预设短信发送预付费账户,能够按照人员、部门(组织)等条件进行短信实际发送条数的计费,短信发送前如账户额度不足无法发送短信时,可友好提示。 | | 8.13 | 发送统计 | 提供对消息发送量的多维度统计功能,可以按部门、人员维度及发送方式维度进行交叉统计,统计结果以列表或柱状图形式展示。 | | 8.14 | 消息分类及通道推送规则 | 提供对消息分类的管理,包括通知、公告、会议、待办、提醒等类型,管理员可管理配置不同的消息类型;提供对已集成通道的消息推送规则的配置,比如多通道推送的优先级,多通道之间的互斥关系;还可以细化定义每个通道的推送规则,比如最多推送几次算推送失败,推送失败后是否重新推送,相隔时间是多少,单次允许推送的最大消息条数等。 | | 9 | 应用管理中心 | 融合门户提供统一的应用管理中心,打通PC和移动门户APP,支持同时管理PC Web版融合门户、移动门户APP中的办事服务及应用的注册、上架、下架、版本管理、访问统计与行为分析等基础功能。 | | 9.1 | 应用注册 | 支持事务类应用与普通应用在融合门户内注册。注册信息包括应用图标、流程描述、待办接口地址、关键词、启动入口、责任部门、业务分类等。普通应用是一般的业务系统,注册到融合门户后能为用户提供业务系统的快速链接,注册信息包括应用图标、启动入口、版本、作者、业务分类等信息。支持窗口部件注册。一个应用可以包含一个或多个窗口部件,允许业务系统在窗口部件展示业务系统的快捷信息。用户可以利用这些窗口部件在个人中心内自定义自己的界面。 | | 9.2 | 应用发布 | 支持应用发布的审核机制,平台内注册的应用需管理员审核后才能发布到融合门户中;支持多目标终端发布,管理员可根据业务场景以及应用特征,有选择的发布到web版大厅、移动门户 ios平台或安卓平台;支持版本管理。 | | 9.3 | 个性化配置 | 可以按角色授权应用,如学生能看到哪些应用、老师能看到哪些应用;也可以授权应用可见的终端,如哪些应用在PC端上架展现、哪些应用在移动端上架展现。 | | 9.4 | 授权管理 | 管理员可以为不同身份的人员分别设置各类应用的启动权限,登录人员具备相应的权限才能进入应用;管理员可以为每个事务类应用分别授权给事务管理员,事务管理员可以维护事务的办理说明、受理办事咨询等,便于各级业务部门在业务变化时及时反馈到融合门户。 | | 9.5 | 访问统计 | 提供事务大厅的内各应用的访问统计,如访问计数、排行、访问、访问来源,即访问来自于WEB大厅还是移动门户,便于管理人员对应用分析与改进。 | | | | | | 4.2.2统一身份认证平台 提供统一的身份认证服务、密码管理服务、统一角色管理服务等功能,为用户完成单点登录,向各个系统提供基础的身份认证接口。建立全校统一的业务系统认证集成平台,提供集成文档和各开发框架的示例代码,业务系统通过统一身份认证系统接口,可快速完成系统认证集成。 序号 | 子项名称 | 需求描述 | 投标响应 | 1 | 总体技术要求 | 1.1 | 标准性 | 采用最新的CAS协议,支持OAuth2.0等标准协议,提供标准的对接接口。 | | 1.2 | 安全性 | 保证认证协议安全,确保接入的应用无法截获用户凭证、无法实施中间人攻击;保证系统关键数据传输安全性;用户密码采用不可逆的加密算法加密存储,其他敏感数据采用高强度加密存储;系统还需提供二次认证、恶意猜测锁定、弱口令检测、容灾、安全审计与监控等多种安全手段。 | | 1.3 | 稳定可靠性 | 系统能保证7*24小时对外服务。 | | 1.4 | 可接入性 | 支持多种开发语言(java、.net、php、asp等)web应用的认证接入,对于不支持的语言,提供代理认证支持;支持移动APP(android、ios app)的认证接入,并为移动APP的后台服务提供与web应用一致的接入方案。提供多种对接接口API及文档和DEMO,并制定具体的管理制度;提供应用的接入认证、接口权限的授权功能; | | 1.5 | 易用性 | 提供多种登录认证方式,除了支持基本web方式的用户名口令方式外,还需支持微信绑定后扫码认证、校方移动APP扫码认证、短信认证等登录手段; | | 1.6 | 可管控性 | 管理员可监控认证系统各项功能服务的运行情况状态,并对部分参数和功能进行一定的调配,例如监控各个对接系统的认证接入情况,如果出现异常可以通过管理端进行人工干预,停止相应系统的接入服务,也可以监控具体账户的登录情况,出现异常可以人工禁用; | | 1.7 | 可配置性 | 通过后端对各项功能进行配置,包括功能是否启用、功能具体参数配置等,使管理员可以通过管理端完成大部分的配置功能,而不需要通过调整配置文件甚至修改代码来完成。用户和对接人员也可以通过web端完成各项配置工作; | | 1.8 | 易升级性 | 具备系统升级的完善计划和方案,避免频繁升级、打补丁。提供产品升级的现场服务,实现功能和数据的平滑升级。提供符合行业标准的二次开发接口,保证将来能够进行升级改造; | | 1.9 | 可伸缩性 | 支持集群、热备、负载均衡; | | 1.10 | 数据中心集成 | 身份数据来源于学校统一建设的基础数据库中心,系统需支持oracle和MySQL主流关系数据库,并支持高效率地与数据中心数据同步人员身份数据; | | 1.11 | 支持LDAP | 系统应支持数据库和LDAP两种存储形式,数据库和LDAP实时进行数据同步; | | 1.12 | 监控功能 | 提供完善的监控功能,可对平台内的用户、应用、服务进程和服务器硬件资源进行实时监控,且可通过各类图表进行直观的结果展现。可对用户身份帐号的管理、授权以及用户的认证行为中可能存在的问题进行审计,所有操作均日志记录,能够对每个角色管理员的操作行为、用户自助管理行为和用户登录访问行为进行记录; | | 1.13 | 数据承载 | 支持5万级的用户注册,单机部署时应能支持最大500人的并发用户数,双机负载均衡部署时支持1000人的并发用户数。 | | 2 | 建设内容及功能要求 | 2.1 | 自助服务 | 为终端用户提供个人信息完善、微信账号绑定、手机号绑定、密码找回等自助服务。并提供全套的关于帐号安全的运维系统,提供帐号操作行为监控功能。 | | 2.2 | 密码与认证管理 | 支持密码强度策略,并支持首次登录安全策略配置,能支持首次登录强制修改密码的策略; | | 支持多次登录失败后启用验证码; | | 支持已绑定微信账号的用户通过微信扫码认证登录; | | 支持校园APP扫码认证登录; | | 支持向已绑定手机号的用户发送动态码短信登录; | | 支持登录成功进行消息提醒等功能; | | 支持统一登出(注销)方案。用户一次注销后,所有已登录系统同时登出。 | | 2.3 | 用户身份管理 | 可从数据源头、用户状态、用户的类型等把用户分成不同的身份群体,身份群体之间的成员可能会重复、交叉,身份数据依赖于源头提供的基础数据和公共库的同步规则形成,并可以增加、减少。身份包括教职工(在职、离职、退休、离校)、本科生(统招生、双学位、交换生)、研究生(硕士、博士)、留学生(本科、硕士、博士)等。支持用户、身份的互查,不同身份的组合查询; | | 支持用户信息从数据中心同步; | | 支持用户头像维护; | | 支持将用户信息同步到LDAP、AD等目录服务器中; | | 支持用户身份在线管理、导入,也可以设定用户与用户组、组织机构等关联。 | | 2.4 | 用户分级授权管理 | 可根据学校组织结构复杂、应用繁多、系统参与人员复杂并流动性大等特点,可为无法及时进入数据中心的人员及系统,提供用户信息及身份的分级授权管理。 | | 支持管理员可以把部分组织机构及人员信息的管理权限分级授权给不同责任部门,由责任部门确认用户信息及身份的准确性。 | | 2.5 | 应用接入管理与访问授权 | 应确保未得到授权的应用系统无法接入统一身份认证系统。 | | 可以为特定应用系统开启“二次验证”策略,用户访问启用二次验证的应用系统时,系统将通过邮件、短信等向其推送二次验证动态口令,还可以向其推送微信确认、校园移动APP确认等二次验证功能。 | | 可以指定哪些“身份”的用户能够访问指定应用系统,认证系统可以阻止未得到授权的用户访问应用系统。 | | 2.6 | 移动APP接入支持 | 系统除了要支持Web应用的认证接入,还需要为第三方移动APP(android、ios app)提供认证接入方案。 | | 应确保用户从第三方移动APP登录时,第三方移动APP无法通过内存监控、网络监控等手段截获用户登录凭证。 | | 为第三方移动APP的后台服务程序提供与Web应用接入一致的认证接口。 | | 2.7 | 接口管理 | 系统须提供接口注册和接口授权管理功能。其他系统可以通过这些接口获取组织机构、身份、角色;也可以通过组织机构、身份、岗位、角色来获取用户列表,从而开展各项系统工作。 | | 2.8 | 系统监控与预警功能 | 系统须提供但不限于以下监控与预警能力: 用户登录与个人信息修改日志与监控; 各级管理员访问操作的审计日志与监控; 口令暴力破解监控、锁定及预警; 用户弱口令检测与预警; 第三方系统对统一认证接口调用监控; 系统运行状态(CPU、内存、IO、磁盘)监控与预警; 系统自身完整性检测与预警,及时发现入侵隐患。 | | | | | | 4.2.3主数据综合服务平台 4.2.3.1主数据综合服务平台系统架构要求 主数据综合服务平台建设主要是完成业务数据的底层数据集成、元数据管理、主数据管理、数据标准管理以及相应的监控和测评工作。系统充分考虑各种多源数据的整合能力、数据整合过程中的数据质量管理、数据流向及血缘管理能力,完善整体的数据管理和运维体系,能够实现如下总体需求: (1)完成梳理和管理各业务系统的非结构化数据、结构化数据表、数据字段、同步关系的具体含义整理; (2)具备关系型数据库、非结构化数据、Hadoop数据库数据及互联网信息的数据集成功能; (3)系统建设遵循国家、行业、学校、自主定义标准,建立适合本校的信息化标准,提供支持数据标准维护的流程和制度建设以及数据标准管理功能; (4)系统根据主题进行划分设计,以数据为基础,以服务为目的构建主题数据模型,通过数据标准完成对业务数据的转换,能够对外提供统一、标准的数据集成、存储、关联、传输、管理和服务。(即数据转换、过滤)。 (5)构建主数据及数据仓库存储体系,支持学校历史数据存储,能够跟踪数据更新,体现历史数据变化; (6)能够实现数据集成过程监控功能; (7)能够对各业务系统的数据以及数据标准进行对比,产生数据对比结果,确定业务数据中不符合需求和标准的记录; 4.2.3.2信息标准建设 4.2.3.2.1信息标准建设目标 所采用的信息标准必须保证和国家以及教育部的信息标准相兼容。基于国家标准、教育部标准、行业标准等,兼顾各个标准之间的兼容性、一致性以及标准的可扩展性,建设和完善学校的各项标准并给出信息分类编码规格说明书,建设形成一套符合学校自身实际的管理信息化标准。 本次数据标准包括基础代码数据标准、学校各信息子集信息标准、部门数据信息标准等。学校各信息子集准以教育部标准为主,结合学校各部门业务信息数据集制定、并完善,标准集能够反映学校各部门的业务信息现状,是学校数据中心建设的核心内容。 信息管理标准体系将遵循以下原则建设:涉及到国际或国家和教育部已颁布的标准,要采用国际或国家已颁布的标准,如:《CELTS-33高等学校管理信息标准》等;涉及到已颁布的高等学校部分管理信息标准,在相关内容上尽量与已颁布的标准保持一致;涉及到学校关于学校信息管理已经颁布执行的标准,要兼顾学校已颁布的执行标准,并完成学校标准与国家、教育部标准的匹配;信息标准体系的建设在参照相关标准的基础上,要充分满足学校信息化管理与服务的实际需求;学校信息管理标准可以根据国家、教育部、行业、学校信息管理与服务的需要不断完善。 4.2.3.2.2信息标准建设内容及技术、功能要求 序号 | 子项名称 | 需求描述 | 投标响应 | 1 | 建设内容 | 1.1 | 信息标准管理系统 | 随着项目建设不断补充完善其内容,该系统用于导入、维护、发布信息标准; | | 1.2 | 数据编码标准 | 学校数据标准建设包括元数据建设、数据代码集建设、数据集建设、数据交换标准建设; | | 1.3 | 制定元数据管理规范 | 元数据管理是数据交换的基础,元数据组成包括:基准元数据系统、元数据字典、数据属性集、数字化信息资源集等综合模块; | | 1.4 | 参考信息编码集 | 国家标准、教育部标准、行业标准、学校标准; | | 1.5 | 数据标准代码类型 | 数字型代码、字母型代码、数字与字母混合型代码、无含义代码; | | 1.6 | 校定信息标准集 | 学校管理信息子集、办公管理信息子集、学生管理信息子集、教学管理信息子集、教职工管理信息子集、财务管理信息子集、科研管理信息子集、资产与设备管理信息子集等; | | 1.7 | 数据标准追溯 | 对缓慢变化数据标准提供历史数据标准追溯功能; | | 1.8 | 应用系统对接标准 | 制定信息标准集与业务系统标准集之间的对应关系,能够对未来数据集成及历史数据集成过程进行管理和追溯; | | 1.9 | 大数据分析数据标准 | 提供大数据分析范畴的互联网数据标准;(如:排名5万以内的网站类型、网站名称、网站地址;排名5000以内的App名称、类型、地址等、提供敏感词库、情感词库标准等)。 | | 2 | 技术要求 | 信息标准在全校范围内为数据库设计、数据仓库建设、主题分析建设提供数据代码标准及数据字典的作用,为信息交换、资源共享提供了参照条件。信息标准需要保证信息在采集、处理、交换、传输的过程中有统一、科学、规范的分类和描述,能够使信息更加有序流通、发挥信息资源的综合效益。 | | 2.1 | 信息标准制定与执行:信息标准代码集、基础数据集、数据仓库集的制定,信息标准代码及数据集的发布执行; 1)软硬件平台标准与开发规范; 2)数据集成与交换标准; 3)信息化运行管理规范与标准; 4)信息编码标准导入、维护、查询工具; | | 2.2 | 参照已颁布的国际标准、国家标准或行业标准,并在建设过程中根据学校的具体情况和实际需求,建立科学、实用、完善的信息化标准体系,根据国家标准、教育部标准、行业标准和学校自身特色建设《黑龙江八一农垦大学数据信息标准》。 | | 2.3 | 为学校设计多种标准执行方案,满足我校实际情况。 | | 3. | 信息标准管理功能要求 | 3.1 | 标准管理 | (1)信息标准创建:除默认的本校信息标准外,学校可以根据需要自定义创建信息标准。 (2)数据标准管理:包括数据集创建、数据子集编辑、数据子集删除。 (3)数据项标准管理:包括数据项标准创建、数据项标准修改、数据项标准删除。 数据项标准创建:在已有的数据子类下,学校可以根据需要创建数据项。 数据项标准修改:对已有的数据项可以修改其基本信息。 数据项标准删除:可以删除自行创建的数据项。 (4)信息标准发布:学校自行编辑的信息标准内容只有通过发布才会成为本校执行标准,提供给其他普通用户查看。 | | 3.2 | 执行标准管理 | (1)执行标准描述信息查看:能查看当前执行标准相关的描述信息。 (2)执行标准内容查看:能查看当前执行标准的内容。 (3)执行标准历史发布版本管理:记录并查看历史执行标准信息。 | | 3.3 | 参照标准管理 | 可查看原生态的国家标准代码子集、教育部标准代码子集、《JY/T 1005—2012学校管理信息子集》中的数据子集内容。 | | | | | | 4.2.3.3主数据管理平台 4.2.3.3.1主数据管理平台建设目标 主数据管理平台通过数据交换工具,进行数据过滤、清洗和双向传递,实现各业务系统、共享数据服务平台相互之间的数据交换和共享,为学校教学、科研和管理提供有效的、实时的、完善的共享数据,满足校内各类人员的数据查询、报表查询展示、信息共享、决策支持等要求。 提供数据建模及元数据管理工具,保障数据可读、可追溯,基于web端制定主数据数据模型,实现对数据模型(表、视图、字段)的增删改查功能,数据模型主要包括: 学校公共信息(房屋、土地、历史沿革等)、学校实体基本信息(学生基本信息、教职工基本信息、资产信息、照片信息等)、教学活动子集、科研活动子集、人力资源管理子集、资产管理子集等一系列基础信息数据模型。 实现对主数据(确定数据来源的业务部门)内容的建设和管理,提供主数据的增删改查功能(创建(Create)、更新(Update)、读取(Retrieve)和删除(Delete)操作),提供对主数据表、字段的来源、使用者信息查询,完成关于主数据的历史版本存储和查询。 4.2.3.3.2主数据管理平台技术及功能要求 主数据管理平台是对数字校园中的各种结构化数据进行统一管理的平台,是实现数字校园数据共享,提供深层次数据挖掘,数据分析的重要基础。主数据管理系统必须满足以下要求: 序号 | 子项名称 | 需求描述 | 投标响应 | 1.1 | 技术要求 | 采用开放、标准的数据库设计,支持跨平台部署。对数据库中的表与数据项都提供中文注释; | | 1.2 | 能够基于元数据,对外提供开放的数据接口,并实现对服务接口的管理; | | 1.3 | 遵循“谁产生、谁维护”的原则,所有的数据都有特定的产生者和维护者; | | 1.4 | 支持历史主数据管理(数据映射、缓慢变化维及历史数据的查询追溯); | | 1.5 | 数据质量管理能够针对主数据模型提供灵活的质量检验规则,灵活的调度机制,存储并可查询质量检查结果。 | | 2 | 功能要求 | | 2.1 | 监控功能 | 对主数据服务器运行情况、数据库状态实现全方位,多维度的监控。 | | 2.2 | 主数据库管理 | 2.2.1 | 数据管理 | 提供主数据库建模,规划主数据流向,提供主数据与信息标准的对照及数据同步,实现历史数据管理、查询、追溯功能。 | | 2.2.2 | 元数据管理 | 提供查看学校定义的结构化元数据和无结构的主数据库元数据,动态管理主数据库的数据结构,其功能包括元数据、代码主题结构的添加、编辑、删除,元数据表、字段、代码表、代码值的新增、删除,取用执行标准,主数据库视图的新增、编辑、删除,主数据库表的搜索,主数据库表的主题分配,主数据库表、视图存储数据的查询,导出元数据生成表的SQL语句等。 | | 2.2.3 | 信息标准管理 | 提供对信息标准的内容日常管理功能(制定、维护、发布、停用、合并、拆分、变更)等,能提供教育部、国家、行业标准的参考功能; 提供业务系统标准与主数据标准的动态使用情况检查,即能自动化检测业务系统与统一标准的代码使用差异情况,便于实现代码统一; | | 2.2.4 | 数据质量管理 | 实现对主数据数据内容的数据质量管理,根据数据标准、元数据和数据自身限制,自主定义检测条件,然后对主数据进行检测。数据自身限制包括但不限于以下几种:不该为空,值域明显不符合,日期格式,小数位数不符合的,空格,记录重复的(业务关键字重复),全角、半角需要转换,长度不符合规范。提供数据质量检测规则,提供数据质量检测报告,提供数据质量提升建议。 | | 2.2.5 | 数据服务管理 | 提供采用B/S架构且依托主数据平台的元数据信息,可视化配置数据数据能力。支持对数据服务接口集进行自定义,可定义内容包括服务输入参数、输出字段属性,并能通过简单的SQL语句实现数据集内容的自定义;提供数据服务接口调用权限的授权管理,支持APPLYID、ACCESSTOKEN密令验证和客户端调用服务器IP限制,确保数据服务安全性 | | 2.3 | 数据安全管理 | 提供数据安全加密能力,平台拥有常用的数据脱敏算法,例如:手机号脱敏、身份证件号脱敏、姓氏脱敏、名字仿真等,且支持自定义扩展。提供数据加密防护项在线设置,自动化数据加密作业。 | | | | | | 4.2.3.4 数据集成平台 4.2.3.4.1 数据集成平台建设目标 实现主数据平台的数据采集与分发,要求提供对被交换信息进行清洗、转换、装载入库等数据交换服务,清理脏数据完成对数据的整理,确保数据一致性、完整性和正确性。 各业务系统通过数据集成平台与主数据平台进行数据交换与共享,各业务系统独立运行,互不影响,某一业务系统故障不会造成对其它系统的影响。 4.2.3.4.2 数据集成平台建设内容 提供对任务的运行时状态和数据吞吐流量的实时跟踪监控功能。支持对运行时状态的任务进行暂停/恢复、中断操作。与元数据管理对接,提供基于web实现对学校的ETL运行监控功能,对校园内所有现有的数据集成服务中数据抽取、同步情况进行监控和异常报警。 数据集成组件应包含以下内容: 序号 | 子项名称 | 需求描述 | 投标响应 | 1 | 组件内容 | 提供方便的ETL工具,功能至少包括现有工具(ODI等)的功能,并将现有已完成的数据集成接口平滑过渡到新的ETL平台上。 | | 2 | 工具支持实时集成、定时集成、全量集成、增量集成、结构化数据集成、非结构化数据集成,用户可自主定义转换规则和对照规则,规则可复制,数据同步接口可复用,能够满足学校需求的数据集成。 | | 3 | 基于Web提供ETL过程的相关信息接展示、汇总和查询(例执行状态、过滤条件、执行时间,运行时长,同步的数据量),同时提供基于web数据同步过程控制功能; | | 4 | ETL开发和生成过程能自动生成关于ETL的元数据,提供etl元数据web浏览功能; | | 5 | 支持大数据体系对Hadoop生态产品的集成的相应知识模块,如:直接访问读取HDFS,集成hive数据文件,支持sqoop的导入导出等功能; | | 6 | 支持数据血统关系查询分析,帮助学校掌握数据集成过程中数据的流向及来龙去脉; | | 7 | 支持数据集成及同步过程的监控功能,能够对数据集成接口任务、数据同步过程、数据流向、数据调度任务进行实施监控,并提供异常数据分析及异常情况协查功能。 | | 4.2.4快速开发平台 4.2.4.1快速开发平台建设内容 序号 | 子项名称 | 需求描述 | 投标响应 | 1 | 内容要求 | 全功能的表单开发工具与处理引擎,可可视化、零代码地开发任意类型的表单并实现高效率、高交互的处理;平台构建的表单要提供响应式能力,能自动识别出移动终端而自动调整布局,并能响应移动设备的触摸事件,提供良好的移动界面体验,使得一次定义表单,多终端适配。 | | 2 | 优化工作流引擎,既要能支持直接嵌入基于J2EE构架业务系统的运行模式,简化业务系统与流程引擎的交互方式,又要能支持独立运行模式,通过开放的标准接口体系支持远程调用,便于异构平台的业务系统与引擎交互,使得流程逻辑与业务程序代码高度分离。 | | 3 | 实现与全校各业务系统的标准化融合。通过高度易用的标准化接口体系,实现统一流程服务与各业务管理系统的无缝融合。以完备的接口体系实现业务流程功能的无限制扩展; | | 4 | 全校流程需求调研、设计与开发等过程必须标准化,提供需求分析报告、概要设计方案、详细设计方案、实施方案等文档(含流程图、数据表); | | 5 | 实现全校流程的统一管理、监控、优化分析功能; | | 6 | 提供完备、开放、安全的API体系,实现与校方流程引擎无缝融合,优化统一的流程服务体验。 | | 4.2.4.2快速开发平台技术要求 快速开发平台的构建基于现有工作流引擎进行二次开发封装,实现微应用的便捷开发,最大限度的减少应用开发对技术和代码的依赖。具体要求如下: 序号 | 子项名称 | 技术需求描述 | 投标响应 | 1 | 流程服务中心 | 流程基于HTML5开发,以适应各种终端的访问, 适配移动门户; | | 1.2 | 流程通过设置后在提交过程中如果因为某些原因中断时,可以实现自动“回滚”操作的功能,保证数据的完整性; | | 1.3 | 事务过程全管理。事务从发起到结束整个过程中比如该事务发起人、任务审核人员,执行人员,执行过程等信息全程透明。 | | 1.4 | 增加统一流程监控控制机制,实现正常执行的流程的审计监控和非正常执行流程的异常监控,能够对所有流程进行运行时控制,包括启动、停止、挂起和恢复执行流程实例等,管理后台与现有流程引擎无缝整合。 | | 2 | 服务大厅 | 用户能够以各种方式找到并启动那些他能够启动的服务。包括通过分类浏览、快速搜索、学校推荐、自主收藏等等方式,快速找到所需要的办事流程服务。 | | 2.1 | (1)待办任务 系统根据流程的需要把当前需要用户办理/填写/审批的工作节点,以待办任务的方式列出。用户(包括员工及各种管理岗位、审批领导)不必了解当前任务来自后台哪个模块,只需要以统一的方式完成该任务展现出来的具体内容即可。 | | 2.2 | (2)办理中任务 流程的办理者(包括申请者、审核者),都可以在这个模块中找到,并跟踪自己参与的流程的进展情况。 | | 2.3 | (3)已办任务 用户可以找到所有自己曾经办理过的流程及其具体内容。 | | 2.4 | (4)服务评价 系统可以让用户对所有自己请求发起的流程服务进行评价。 | | 3 | 流程开发 | 快速开发平台提供全可视化的流程集成开发环境,并拥有大量成熟实用的案例模板。无需编码即可实现绝大部分的应用开发,开发人员无需掌握复杂编程语言,简单培训即可胜任开发工作,极大的降低软件开发的复杂度和软件开发速度。 | | 需要能独立运行,既可支持Web应用开发者,也可支持非Web应用开发。 | | 通过开放的标准接口体系支持远程调用,便于异构平台的业务系统与引擎交互,使得流程逻辑与业务程序代码高度分离。 | | 提升现有流程引擎的性能,要能保证招标人的业务的并发量和响应时间的需求,并且消耗的资源量合理。假设在中等性能PC Server上,要求进行1000强并发时,每秒处理约20个全流程(5~6个环节),约260个交易数,交易平均响应时间在1~2秒以内。(提供同等强度的电信运营商、大型银行、大型企业的客户证明或验收材料(投标人或原流程引擎厂商获得的均可)) | | 3.1 | 快速开发平台对工作流的管理 | 3.1.1 | 多种运行模式 | 支持直接嵌入基于J2EE构架业务系统的运行模式,简化业务系统与流程引擎的交互方式,又要能支持独立运行模式,通过开放的标准接口体系支持远程调用,便于异构平台的业务系统与引擎交互,使得流程逻辑与业务程序代码高度分离。 | | 3.1.2 | 流程接口规范 | 支持WfMC/XPDL、BPMN、BPEL标准规范中的一种;提供Java API,方便引擎嵌入运行模式下业务系统流程的操纵、检索、监控;提供Webservice、RESTful api等远程调用接口,在独立运行模式下支持异构平台业务系统的流程接入,为学校各类业务系统的流程无缝整合提供基础能力。 | | 3.1.3 | 可视化流程建模 | 提供可视化流程建模,能直观的通过拖拽各种图元与连线实现流程定义。 | | 3.1.3.1 | 业务规则定义 | 规则中可以使用业务变量、流程上下文数据、活动上下文数据等,以"类自然语言"的方式进行灵活配置。 | | 业务规则编辑中可以引用业务操作,用户可以动态增加业务操作。 | | 支持多个条件以及在规则中进行加减乘除、括号、逻辑操作等各种复杂运算。 | | 3.1.3.3 | 扩展能力 | 具备扩展能力,建模工具除了能够定义系统预置的规则、参数、属性、事件之外,还要能为各种业务系统的特殊要求提供扩展定义。 | | 3.1.3.4 | 版本管理 | 需对所建流程提供版本管理能力。 | | 3.1.4 | 流程处理能力 | 支持20种以上的流程模式,包括:顺序流、并行分支、同步、独占选择、简单聚合、多重选择、同步聚合、多重聚合、任意循环、运行时多实例、任意顺序等复杂流程模式。并需要支持中国特色流程模式,包括退回、取回、自由流、任意回滚等。 | | 支持子流程及动态多子流程实例分配,无需设计时确定子流程实例的个数,可以在运行时根据上下文数据动态分配子流程实例。 | | 支持多种任务完成策略,包括:多人顺序、多人并行、多人抢占、多人任意、指定执行、会签、传阅等业务功能 | | 3.1.4.1 | 分配策略 | 在流程定义时基于机构/岗位/角色/人员及其组合分配,并能与学校统一身份体系的无缝对接。 | | 流程运行时动态指派任务处理人。 | | 通过业务人员配置的业务规则获取任务处理人。 | | 允许插入自定义程序逻辑机制实现更灵活的任务处理人动态计算。 | | 3.1.4.2 | 流程事件触发 | 全方位支持流程事件触发,在流程实例的启停、异常终止,活动的激活、挂起、结束等关键位置触发事件,便于业务系统进行诸如短信通知、邮件通知等扩展处理逻辑。 | | 3.1.4.3 | 灰度发布 | 支持流程的灰度发布,即发布流程的新版本时,未结束的流程能以原有版本正确运行结束。 | | 3.1.4.4 | 运行库和历史库分离 | 支持流程运行库和历史库分离,使得对历史数据的查询和分析不会影响当前流程执行,有效提升当前流程执行的效率。 | | 3.1.5 | 流程监控 | 提供统一流程监控控制台,实现正常执行的流程的审计监控和非正常执行流程的异常监控,能够对所有流程进行运行时控制,包括启动、停止、挂起和恢复执行流程实例等。 | | 支持图形化展示流程运行过程。 | | 支持任务改派,可以由管理员改派任务的责任人。 | | 支持人工实时修改运行数据,并提供人性化操作界面。 | | 支持回滚操作,允许流程回滚到任意历史位置重新执行。 | | 开放流程监控API,允许业务系统客户化流程监控功能,使之能与业务功能无缝集成。 | | 3.1.6 | 业务构建 | 提供多种方式的快速业务构建能力,支持从简单表单定义到复杂业务子系统的快速开发,快速响应业务需求。 | | 3.1.6.1 | 在线表单开发 | 支持B/S模式的在线可视化表单建模,提供拖拽式、所见即所得的可视化化表单设计能力,实现零代码开发。 | | 支持文本、日期、选择、文件上传等多种web交互控件。 | | 提供多种表单数据验证方案,灵活控制数据的有效性。 | | 支持表单数据与流程引擎交互,为流程引擎提供上下文业务数据。 | | 支持为不同流程环节定义表单内字段的只读、隐藏、编辑。 | | 在线表单可支持脚本、事件扩展,加强表单的处理能力。 | | 3.1.6.2 | 离线表单开发 | 提供高度灵活方便的离线表单开发工具,不仅能支持流程审批单,还能支持任意复杂的业务子系统开发。 | | 支持数据库反向工程,能直接映射数据库内的数据表到业务对象。 | | 支持向导式页面生成,页面生成采用模板规则,通过修改模板规则,可以高度自由定义页面生成方案。 | | 支持开发工具内断点调试,业务开发人员能观察数据从客户端的提交到与业务构件、流程引擎交互过程,方便快速定位问题。 | | 3.1.6.3 | 响应式表单 | 通过基于流程引擎二次封装的快速开发平台构建的表单要提供响应式功能,能自动识别移动终端自动调整布局,并能响应移动设备的触摸事件,提供良好的移动界面体验。使得一次定义表单,多终端适配。 | | 3.1.6.4 | 图形化编程 | 支持图形化业务逻辑开发,可以把用户的业务需求直接以分支、循环、同步等图形化编程来操作数据对象及业务组件。使得开发者无需编写代码,就能对“需求”的理解到“逻辑”的运算达到一致性,便于系统维护与未来快速响应需求变更。 | | 3.1.6.5 | 业务逻辑复用 | 通过图形编程形成的业务处理逻辑,能够打包成构件包,并允许被不同的业务逻辑调用。实现共性业务逻辑复用,大大增加开发效率。 | | 3.1.6.6 | 业务构件 | 系统需提供丰富的业务构件,包括数据操纵、事务操作、发短信通知、发邮件等常见业务功能构件。 | | | | | | 4.2.5 应用建设与系统改造 基于快速开发平台完成以下指定轻应用的开发构建。办公OA系统的改造(含移动端)、安全监控运维平台升级改造、教育资源共享云存储系统扩容、移动校园app等(具体建设内容详见相关章节要求)。 4.2.5.1 轻应用建设内容 以下轻应用为初步规划,最终需求和流程以学校调研结果为准。 序号 | 应用名称 | 功能要求 | 投标响应 | 1 | 一卡通查询 | 可实现通过移动客户端展示一卡通相关信息,如余额、消费记录等,方便师生掌上查询。 | | 2 | 课表查询 | 展示学生课表、教师课表,方便师生教学。 | | 3 | 成绩查询 | 面向学生提供成绩查询服务。 | | 4 | 户籍证明办理 | 户籍在学校集体户口的在校学生,用于办理签证或签注、婚姻登记以及购房、贷款、公证、就业、考试等其他用途。 | | 5 | 用印申请 | 对学校各级部门的各种印章的使用申请、审批、盖章存档进行管理 | | 6 | 教室借用申请 | 方便全校师生能够即时提出教室借用申请,审批通过后可以使用教室。 | | 7 | 成绩单打印申请 | 方便学生能够即时提出成绩单打印申请,经院系和教务处审核通过后可以打印成绩单。 | | 8 | 休学申请 | 方便生病学生能够即时提出休学申请,网上填写申请单,经相关部门 审核通过后可以休学。 | | 9 | 缓考申请 | 方便学生能够即时提出缓考申请,审核通过后可以缓考。 | | 10 | 补办毕业证、学位证明书 | 方便学生能够即时提出毕业、学位证明书的补办申请。 | | 11 | 人事进修申请 | 方便教职工能够即时提出进修申请。 | | 12 | 培训申请 | 方便教师能够即时提出培训申请。 | | 13 | 图书馆研讨室预约 | 为学生提供图书馆研讨室在线预约功能 | | 14 | 学籍证明申请 | 方便学生能够即时提出学籍证明申请, 审核通过后即可开具学籍证明。 | | 15 | 本科生办理在读证明 | 方便学生能够即时提出办理在读证明申请。 | | 16 | 本科生补办学生证 | 方便学生能够即时提出补办学生证申请。 | | 17 | 单身宿舍申请 | 方便教职工能够即时提出宿舍申请 | | 18 | 人事证明申请 | 面向教职工提供在线申请开具人事证明服务,用于诸如本人出国/出境、担保他人出国/出境、购房个人贷款、办理暂住证、办理子女入学证明等用途。 | | 19 | 兵役登记及征兵报名 | 面向学生提供服兵役相关指南:包括面向对象、征集条件以及相关征集流程;此外,也方便学生能够即时发起报名申请。 | | 20 | 网络报修业务 | 校园各类网络设施报修,学校用户登录系统后可以发起报修申请,报修信息包括所在楼宇、详细地址、维修项目、照片、故障描述和联系方式。 | | 21 | 工资查询 | 教职工查询自己的每月工作表。 | | 22 | 失物招领 | 为学生提供一个在线失物招领平台。 | | 23 | 心理咨询预约 | 对外公布所有心理导师,学生可以预约心理导师。 | | 24 | 学生入校流程 | 为新生报到提供服务流程指南,辅助新生报到过程。新生可以知道报到时间、地点及路线。 | | 25 | 学生离校流程 | 为毕业生提供离校流程指南,辅助符合毕业条件的学生快速办理离校手续。 | | 26 | 职工退休流程 | 方便教职工办理退休,达到退休年龄的教职工可以在线提出申请。 | | 27 | 校园一卡通业务申请 | 方便申请人(学生或教职工)学生能够即时提出校园卡开通申请。 | | 28 | 授课计划申请 | 方便老师能够在线提交授课计划申请。 | | 29 | 选修课申请 | 方便任课老师能够即时提出选修课开课申请。 | | 30 | 档案借阅/外借申请和审批 | 方便校内师生、教职工能够即时提出档案调阅、档案外借申请。 | | 31 | 调停课申请 | 方便教师能够即时提出调课、停课申请。 | | 32 | 会议室申请 | 对会议室的使用申请。 | | 33 | 合同审批 | 教职工发起合同审批流程,填写申请,上传合同内容,报相应部门审批通过后合同才能生效。 | | 34 | 邮箱申请 | 方便学生、老师能够即时提出电子邮箱申请业务办理 | | 35 | 停车证申请 | 面向教职工提供停车证在线申请服务。 | | 36 | 官方微博、微信开通申请 | 方便学校需要开设和建立微博、微信的相关部门能够即时提出申请,进一步发挥新媒体在引导社会舆论、推进校园文化健康发展中的积极作用 | | 37 | 工会疗养申请 | 方便教职工能够即时提出疗休养申请,丰富教职工福利,利于校园文化建设 | | 38 | 校园通讯录 | 为师生提供学校各部门的联系电话。 | | 39 | 电子邮箱业务办理 | 方便学生、老师能够即时提出电子邮箱业务办理(恢复邮箱密码、注销邮箱、申请邮箱、邮箱扩容等)申请。 | | 40 | 域名申请、变更、注销 | 方便学校二级域名的申请、变更及注销。 | | 41 | 网站建站申请 | 方便学校各部门即时提出网站建设申请。 | | 42 | 日程管理 | 提供日历日程模块,为每个用户提供基于日历形式的日程安排查看服务;支持个人日程的新建、编辑、查看功能;支持与各业务系统对接,提供日程安排统一展现服务;允许个人共享、公开自己的日程。 | | 43 | 寒暑假留舍申请 | 学生申请寒暑假留校,学生处审核申请。 | | 44 | 出差审批 | 教职工出差发起申请,各级分管领导审批后通知申请人。 | | 45 | 临时校园卡申请 | 学校接待外来访客时为访客开临时卡,为来访人提供临时卡申请服务。 | | 46 | 虚拟服务器申请 | 各个部门需要使用服务器的时候,向管理部门提出申请,经部门领导同意后由信息办根据实际情况处理。 | | 47 | 师生集体外出活动报备 | 师生提交外出活动报备申请,经领导审核后,交由后保处办理。 | | 48 | 学生请销假申请 | 学生需要请假和销假的时候发起申请,根据请假的天数报备和注销。 | | 49 | 统一身份认证账号申请 | 新晋人员申请开通使用统一身份认证账号。 | | 50 | 资源申请 | 教师因办公需要,申请云资源。 | | 4.2.5.2办公系统改造主要功能需求 基于学校现有OA系统进行功能完善和改造,并增加移动端适配,投标人需具备基于现有平台开发、实施对接的能力,确保投标产品与现有平台实现无缝对接。 序号 | 应用名称 | 功能要求 | 投标响应 | 1 | 功能实现 | 在保留原有功能的前提下,以下功能需基于流程平台改造实现并增加手机端自适应。 | | 2 | 门户展示改造 | 对办公门户重新规划涉及pc端和移动端,所有功能模块界面集成在办公门户展示。 | | 3 | 提醒功能改造 | 流程都发送到岗位,由学校提供岗位。PC端即时提醒功能,用户打开PC端办公门户的情况下,当有新待办事项到达时需要即时告知用户。 | | 4 | 群组功能扩展 | 增加系统群组和个人群组功能,系统群组用现有群组功能,群组可以有多级,扩展个人群组功能,支持多级。 | | 5 | 换岗查询改造 | 支持某个岗位上的人员换了之后,新换上的人员可以查看该岗位之前办理过的事情。 | | 6 | 流程转办改造 | 管理员可以对在办的流程进行转办,即转交给另一个岗位/人员进行处理。 | | 在各流程的管理界面(包括收文、发文)增加转办按钮,可以将一个或者多个在办流程转交给另一个岗位/人员办理。须调用工作流引擎相关接口来实现。 | | 7 | 意见管理改造 | 管理员可以对流程的办理意见进行修改和删除,删除意见后办理过程应保留。 | | 在各流程的管理界面(包括收文、发文)增加意见管理按钮,选中一个流程点击意见管理按钮后弹出div展示该流程意见列表可以进行修改和删除操作,提供管理员对所有流程意见的修改和删除功能。 | | 默认快速意见需要根据不同类型步骤展示特定的内容,即展示不同的默认意见列表,默认意见用下拉框即可,不需弹出页面选择。 | | 在活动上配置快速意见框相关参数,表单根据参数自动调用相关快速意见框。 | | 在个人设置功能模块里增加“常用意见设置”功能,提供个人设置自己的常用意见。 | | 系统管理功能模块新增“常用意见设置”功能,可以维护多套常用意见,与活动的配置关联,在意见输入框处展示。 | | 新增常用意见表,包含系统常用意见和个人常用意见,每种意见一条记录。 | | 8 | 流程状态改造 | 流程待办需要有已读和未读状态,待办人员打开后为已读状态,管理员可以看到每个流程的已读/未读状态。 | | 增加工作项的状态,待办人员打开流程处理页面后即为已读状态,后台管理界面展示已读/未读状态。 | | 9 | 流程收回改造 | 流程发送者可以在下一步流程办理人员未处理时收回流程。已经结束的流程也要可以收回。 | | 在我已发送的流程查看界面增加收回按钮。 | | 10 | 发文编辑改造 | 发文模块正文提供编辑留痕功能 | | 发文多人会签步骤,修改文件覆盖需要先锁定,防止多人修改相互覆盖,文件修改要留痕,痕迹要显示修改人的名字,需要可以看到谁在修改发文正文,发起人可以即时对修订进行接受。 | | 发文增加正文是否在编辑状态,并记录编辑人和打开时间。 | | 在表单页面增加当前编辑人显示,如果有人在编辑那么打开文档为只读模式,如果没有人在编辑,当前人打开后,更新正文编辑状态,记录编辑人和打开时间,文档编辑页面每隔2分钟自动更新打开时间,文档关闭时取消编辑状态。 | | 判断是否在编辑状态还可根据正文打开时间和当前时间的差决定,如果两者之差超过5分钟,那么表示文档没有人在编辑。 | | 发文正文编辑须能能限定正文内容的字体字号。 | | 发文套红可以对正文进行套红。另外套红文档可打印。 | | 使用字典表保存红头名称和模板文件,支持无红色打印。 | | AIP格式文件可实现在线阅读,不用下载后再阅读。 | | 在发文签章环节,可实现对正文的签章功能。 | | 发文管理须作为一个功能模块开发,包括行政发文、部门发文、党委发文、纪委发文。 | | 发文编号,应自动生成编号。 | | 发文编号在编号环节进行处理(院办秘书办理),编号组成方式:发文字、年份和顺序号三部分组成,其中发文字手动选择(做成字典表)、年份自动带入可以修改、顺序号按同一发文字和年份顺序增加,从1开始。号数可手工修改,系统判断是否冲突。无冲突可以保存。 | | 4.2.5.3移动校园APP平台功能需求 构建一套整体的移动开放平台,整合现有pc应用资源,为全校师生打造一个可迭代的移动服务生态环境。 序号 | 子项名称 | 功能要求 | 投标响应 | 1 | 技术要求 | 移动开放平台的客户端程序需要支持安卓与IOS操作系统的终端设备。支持在Wi-Fi、3G、GPRS等多种网络环境下进行应用访问。 | | 支同一用户多设备。能保持用户在自己多个移动设备之间的信息同步。 | | 移动开放平台要能够集成第三方应用,需要支持的第三方应用类型包括独立编译的Native应用、web应用、本地html5应用。并为web应用与本地html5应用提供设备本地能力的调用接口,比如拍照、打电话等功能。 | | 提供系统监控手段,可以获得系统使用情况等相关数据。 | | 开发技术应采用J2EE标准、组件技术及在数据交换上应对XML支持,以保证系统功能最优化,并将整体系统内部在技术上的相互依赖性减至最低。 | | 与学校现有信息发布系统无缝集成,实现PC端与移动端网站资讯聚合,信息只需发布在WEB网站后台,移动门户端可自动获取信息并进行界面信息展示。同时,通过移动端发布并编辑的信息,也应直接发布到PC端网站后台相关栏目中,实现信息双向同步。 | | 具备开放消息接口能力,业务系统可以通过消息接口向目标用户发送IM消息。需要支持用户在移动开放平台客户端中收到业务消息后,能以业务系统提供的模块或业务系统APP来正确处理业务消息。 | | 移动开放平台客户端提供界面集成能力,提供开放接口,使第三方应用能够在客户端主界面展示自己特有内容,并支持用户个性化定制主界面上的内容与布局。 | | 支持根据不同用户身份定义移动客户端初始化界面,并默认安装与用户身份匹配的平台应用。 | | 2 | 建设内容 | 2.1 | 移动开放平台 | 移动开放平台构建开放、可集成的校园移动服务环境,为校园移动应用提供丰富的用户体验; | | 面向各角色用户提供统一的个性化移动应用分发通道; | | 移动开放平台具备安全访问能力:提供第三方通过安全授信的方式获取学校内部私有核心业务数据逻辑的访问能力。 | | 2.2 | 开发者平台 | 为开发者提供注册、上传、上架申请、测试等功能,管理员审核后,上架的应用即可被用户下载安装。 | | 2.2.1 | 面向开发人员 | 1)应用创建 可以创建自己的应用,登记应用的基本信息。 2)版本管理 可以为自己的应用创建版本,为版本提供说明,上传应用包,设置客户端权限要求,设置多种大小的图标、截图、置顶广告图片等信息。 3)评论查看 可查看到用户对各应用版本的评论与评价。 4)上架、下架申请 可以向管理员发出版本的“上架、下架”申请,申请被通过后,新版本将可以被用户下载。 5)测试人员登记 可以为自己的应用登记一定数量的测试人员,测试人员在版本尚未被发布时,可在应用平台客户端下载安装自己能测试的应用。 | | 2.2.2 | 面向管理员 | 1)开发人员授权 可以授权具备统一身份认证帐号的人员为开发人员,被授权者可以在平台中创建应用、更新版本、申请发布等功能。 2)应用审核 能够审核开发人员提交的版本发布申请。 新版本在审核过程中时,用户能够下载到历史版本。 新版本审核通过后,用户能够下载到新的版本。 3)应用管理 可以创建应用分类,并把平台内注册的应用归纳到不同的分类下。 可以设置多个全局的置顶应用,置顶的应用将在移动客户端应用市场上优先展示。 可以为每个分类设置多个应用推荐,被推荐的应用将在移动客户端的推荐列表中展示。 可对应用直接创建、上传、新建版本、发布、下架等操作。 4)评论审核 能够关闭或开放评论功能。 可以审核用户对各应用发表的评论。 5)统计分析 提供移动应用客户端安装统计、访问统计,以及各类应用的安装统计与访问统计。 | | 2.3 | 应用市场 | 应用市场提供应用的统一分发和统一访问通道,用户可以从市场中下载自己需要的应用。 | | 具体功能包括应用排行、推荐总览、应用分类搜索、下载安装、更新、移除、应用评价等。 | | 2.4 | 移动门户 | 移动门户主要提供用户登录、个人信息维护、用户个性化、接收PUSH消息和系统消息服务等。 | | 2.4.1 | 账号登录及授权 | 与统一身份认证系统无缝集成。实现用户在移动设备上保持登录功能,并能无缝对接已经采用校内统一认证的原有业务系统,即从移动开放平台客户端访问学校原有业务系统时,原有业务系统不需额外改造认证接口即能实现单点登录功能。 | | 2.4.2 | 个人信息维护 | 可灵活设置个人头像、个人联系方式等属性信息,并在使用第三方应用时可以自主选择是否允许第三方应用访问个人授信信息。 | | 2.4.3 | 个性化 | 根据用户身份初始化移动门户界面,并默认安装与用户身份匹配的各类已集成到平台中的应用。 | | 个人能够根据需要,自主设置首页显示的版块内容,如是否显示资讯图片、消息提醒、个人备忘等,并可以调整显示顺序等,不能只是简单的更换背景。 | | 2.4.4 | PUSH服务 | 推送系统内重要的与用户关联密切的通知消息(包括IM)。PUSH的消息支持系统内嵌服务跳转,如新闻、通知公告或外链的第三方跳转,也支持被集成的移动应用的调用。 | | 2.5 | 资讯聚合 | 提供基于移动端的资讯聚合功能。 | | 按用户权限将校内活动、大事件、新闻等资讯个性化推送给用户,内容可以包括文字、图片、外部链接等富媒体信息,并可实现自主订阅和分享到微信、微博、QQ空间等朋友圈。 | | 基于移动客户端可直接订阅校园PC端各个网站任何栏目的新闻信息,不局限学校主页或新闻网,可以是任何校园网站已发布的信息; | | 支持移动端多站点管理发布,支持无限栏目管理; | | 用户可以订阅添加自己感兴趣的栏目,订阅栏目的最新信息会自动推送到用户的移动终端,用户登陆后可以在自己的订阅中心查看。 | | 2.6 | 移动信息发布 | 支持在移动客户端起草编辑和发布新闻并与对应pc端网站同步展示。 | | 信息发布可选择同时发布至移动客户端或PC端。 | | 2.7 | 统一通讯录 | 基于学校组织机构构建全校统一通讯录。通讯录数据云端管理。 | | 通讯录详情变更增量同步。 | | 支持通讯录响应式搜索。 | | 支持访问权限设定,面向不同对象可以限定其可见的人员范围的及人员属性。 | | 支持分级授权,权限逐级分解给各级部门管理员进行再次分配,减轻上级管理员的工作压力。 | | 支持默认授权,老师对自己所教课程的学生、辅导员对自己负责的班级、学生对同班同学、教职工对本部门成员等默认授权,并可全局控制相关授权。 | | 支持个人向好友、部门内成员、公众公开自己的私有联系方式。 | | 2.8 | IM(即时通讯) | 提供即时通讯,支持文字、表情、拍照、语音等多种交流方式。 | | 支持在线接收与离线消息推送。 | | 支持最新会话列表查询与历史消息记录查询。 | | 支持同一用户多设备之间的消息同步。 | | 支持通过通讯录发起即时消息。 | | 支持群组消息。 | | 支持好友申请、好友分组与黑名单管理。 | | 支持通过IM接收业务消息和通知提醒。 | | 2.9 | 群发消息 | 支持消息群发功能,可实现按部门、班级等群组进行消息群发; | | 可选择以个人名义或部门名义群发消息; | | 支持跟踪消息群发是否被接收; | | 支持有条件的以短信、邮件等方式发送消息。 | | 3. | 需要构建和集成的应用:(本次项目移动APP所展示及构建的应用,除包含融合服务门户新增的应用与服务须同步到移动APP外,还须建设以下功能应用:) | 3.1 | 移动资讯 | 与学校网站群系统无缝集成,实现移动终端起草信息,发布在站群系统内对应网站的指定栏目。同时也支持调用移动终端的拍照功能,实现拍照发稿。投标人需要具备基于现有站群开发实施的能力,投标时需提供成功案例合同原件或原厂证明。 | | 3.2 | 会议安排 | 管理员可在web后台进行会议发布,包括会议时间、地点、主题,并在通讯录中选择参与人员,最终生成一周会议安排在移动端发布,并给参会人发送提醒;支持生成会议二维码,在现场进行扫二维码签到功能。 | | 3.3 | 日历日程 | 提供日历日程模块,为每个用户提供基于日历形式的日程安排查看服务;支持个人日程的新建、编辑、查看功能;支持与各业务系统对接,提供日程安排统一展现服务;支持将日程安排推送到手机通知提醒栏,实现日程推送、提醒服务。 | | 3.4 | 通知公告 | 提供全校级“通知公告”发布服务,聚合全校各部门的通知公告内容并分类展示;每个用户可进行个性化订阅和取消。 | | 3.5 | 调查投票 | 提供调查投票项目发布、移动端投票、调查数据统计发布。 | | 3.6 | 邮件服务 | 与学校邮件系统对接,实现基于手机客户端的邮件收发和提醒服务。 | | 3.7 | 活动讲座 | 对校内的各类活动、讲座信息提供编辑、发布和分类查看。 | | 3.8 | 失物招领 | 提供物品丢失,或失物招领的发布平台。 | | 3.9 | 跳蚤市场 | 提供给全校师生一个二手物品置换平台。 | | 3.10 | 魅力校园 | 采用Html5技术和前端框架(不可使用Flash等插件方式),依据国际标准的地图投影算法,实现二维、卫星、2.5D仿真三维图的准确坐标换算,并兼容百度的卫星图、二维图,实现无缝叠加和校园全景图的查看和导航;支持直接移动端浏览器打开;提供现有校园的2.5D建模、地理位置字典库维护与共享功能,学校可自行维护地理位置字典与网站群平台同步共享,在现有网站群平台中编辑文章内容时,可设置相关地理位置关键字自动生成地图链接,新闻发布后,点击超链直接定位到地图上对应位置。 | | | | | | 4.2.5.4安全监控运维平台改造要求 基于现有运维系统改造,将全面升级现有服务器及业务应用运维监控软件平台运行能力,使其更加符合智慧校园运维体系,统一管理、维护计算资源与智慧校园各业务平台底层系统,所有服务器、虚拟机、业务应用系统的服务和网络设备状态数据,将全部通过新建智慧校园体系进行收集,实时监控系统服务和应用服务器的运行状态,并由控制面板来进行图形化展示,将运行数据以数据库形式进行存储,实现灵活的告警机制,快速定位服务器、虚拟机及某个应用服务的故障位置。投标人需具备基于现有运维系统开发、实施对接的能力,确保投标产品与现有系统实现无缝对接。具体功能改造需求如下: 序号 | 子项名称 | 改造要求描述 | 投标响应 | 1 | 系统运行信息监控 | 通过WEB监控接口对系统的运行信息进行监控。用户可监控系统实例的运行状态,部署服务的运行状态等多方面信息。 | | 2 | 资源管理 | 对现有异构计算资源进行虚拟化改造,实现异构计算资源的统一管理,动态分配和调度资源以满足多应用需求,实现计算资源的可管理、易于调度、按需分配。平台具备开放性,支持异构的虚拟化技术,可统一管理主流的虚拟化系统。 | | 3 | 计算节点管理 | 支持虚拟机创建、配置、部署,虚拟机管理、回收、状态查询,弹性存储管理、快照管理。可管理计算节点数量无限制,虚拟机数量无限制。 | | 4 | 资源调度管理 | 可通过系统设置功能配置资源分配和调度的策略,资源管理模块会根据当前资源池的资源可用情况和设置的策略来合理分配和使用资源 | | 5 | 资源隔离 | 确保资源池中的不同系统间的内存、CPU、网络、存储等资源都是有效的,并且是隔离的。虚拟机之间做到隔离保护,其中每一个虚拟机发生故障都不会影响同一个物理机上的其它虚拟机运行,每个虚拟机上的用户权限只限于本虚拟机之内,以保障系统平台的安全性。 | | 6 | 资源监控 | 提供对计算资源的状态监控,包括对物理机的监控、虚拟机的监控、资源池中存储的监控。 | | 7 | 资源告警 | 提供对资源的告警管理,可配置告警规则、查询告警事件列表等。选择告警指标、指定告警阀值、定义告警级别等内容后,便可创建一条告警规则。 | | 8 | 应用性能管理 | 通过实时的数据监控,确认出现差异的区域、应用、网络和服务器,快速确定出现异常的时间段,提升网络的服务质量和整个应用的性能。 | | 9 | 运维监控模板 | 通过添加监控设备方式添加监控对象,监控设备允许使用模板,模板中可以添加监控策略,模板允许继承。 | | 10 | 故障告警配置 | 可以自定义告警升级、接收者及告警方式。 告警信息可以配置并允许使用宏变量。 | | 11 | 实时绘图 | 通过内置的绘图方法实现监控数据实时绘图。 允许自定义创建多监控项视图。 | | 12 | 历史数据存储 | 数据存储基于数据库,历史数据可管理,内置数据清理机制。 | | 13 | 开放API接口 | 开放程序级别的访问接口,第三方程序可以很快接入。 | | 14 | 权限体系改造 | 优化权限认证机制。 提供完善的用户管理机制,包括:用户创建、删除、状态管理、信息修改、用户组管理、用户权限控制策略,支持角色管理,功能权限控制。 | | 15 | 监控agent | 可在监控目标上部署。 支持Linux ,Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X, Windows等系统。 | | 16 | 复杂环境应对 | 可以轮询主动接收监视数据,同时还可被动接收agent发送的数据。 运维监控支持SNMP (v1,v2),可以与SNMP软件配合使用。 | | 4.2.5.5教育资源云存储系统扩容要求 基于现有存储系统进行功能改造和用户数扩容。投标人需具备基于现有存储系统开发、实施对接的能力,确保投标产品与现有系统实现无缝对接。具体改造扩容要求如下: 序号 | 子项名称 | 扩容要求描述 | 投标响应 | 1 | 文件同步存储 | 实现跨平台终端文件同步。文件存储于校园内网服务器(私有云)端,用户可将文件组织成资料库,每个资料库可选择性的同步到任意设备。提高工作效率。 | | 2 | 多平台支持 | 增加离线修改文件功能,支持移动端访问。客户端支持 Windows, Mac, Linux, iOS, Android 多平台,直接通过本地磁盘来访问云端文件,为用户端提供服务器的海量存储空间。能与操作系统无缝集成。 | | 3 | Web用户界面 | 改进现有web界面,实现用户使用Web方式直接浏览、管理文件,并支持移动端适配。 | | 4 | 支持文件共享与权限控制 | 改造现有权限机制,实现任意创建分享链接共享资源,可共享文件到群组。支持基于角色的用户权限管理,细粒度权限控制,能实现单点登录 | | 5 | 高性能 | 提升原系统性能,在多用户并发访问的环境下能持续保持高效,稳定、可靠的数据服务 | | 6 | 数据安全 | 支持在各种极端的场合下都能正确的工作、不丢数据。实现文件同步的可靠性,具备高度可靠的同步算法与文件保护机制。数据存储采用加密算法,数据传输采用基于HTTPS/TLS协议的加密方式 | | 7 | 支持多用户在线协同编辑 | 使用整合的办公套件,支持所有主流文档、电子表格和演示文稿等文件格式,能兼容各种主流浏览器,具备文件预览功能。 | | 8 | 集成接口开发 | 开发WebDAV、REST API接口,实现与移动校园App平台、统一身份认证系统集成,支持同步AD/LDAP群组和用户信息。 | | 9 | 用户数扩容 | 用户数授权扩容至无限用户。 | | 10 | 存储容量扩容 | 软件层现有存储容量扩容无限授权。 | | 第五部分 应用集成要求 1.总体要求: 在数据管理平台、应用管理平台等相关平台中集成改造招标方现有系统,实现校内业务系统的集中管理、数据的集成与共享,及各业务系统之间数据的互联互通。 2.集成内容: 集成的业务系统主要包括:一卡通系统、上网认证、VPN、邮件、学工、科研、图书馆、OA、站群、教务、人事、研究生、校友等甲方提出的相关业务系统。 3、第三方集成费用: 中标人按要求完成集成工作,集成费用和原系统接口改造、联调等相关费用均包含在本次项目中。 第六部分 项目实施要求 6.1 实施要求 (1)交付时间 一、要求中标以后5个工作日内: 1) 完成基本平台的部署(包括统一身份认证、融合门户、统一数据管理、快速开发平台),各项技术指标满足招标需求; 2) 完成移动校园基础平台部署,实现资讯聚合、移动资讯、移动发布等指定要求; 3) 到场进行需求调研和流程设计工作。 如果上述要求未在规定的时间内完成,学校有权拒绝签订合同,并追究中标人相应责任。 二、项目的建设工期为合同签订后 6 个月内所有建设内容交付用户试运行,试运行1个月后提交验收。如果不能按期完成,甲方有权单方终止合同,中标人应向甲方支付合同额30%的违约金并承担相关责任。 (2)人员配置 投标方应在实施方案中详细描述,包括项目组成员名单、本项目工作职位、专业方向、工作、项目履历和在本项目中的职责分工。 (3)成果和文档资料 在本期项目的开发过程中和交付使用后,要求将全面、规范的成果和文档资料交付给学校,而且要提供明确的交付清单。同时,成果和文档资料应符合软件工程的相关要求。要交付的成果和文档资料主要包括以下部分: 技术文档: 包括项目开发中的各种技术文档,如,开发环境配置说明、需求分析说明、变更说明、系统设计说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等等。 管理文档: 包括项目开发中的一些工作文档,如,计划、报告、讨论纲要、会议记录等。 需提交文档包括: 《项目实施计划》 《系统集成方案》 《测试报告》 《上线试运行确认单》 《试运行阶段用户问题反馈确认单》 《验收报告》 《用户使用手册》 《常见问题说明》 《系统接口说明书》 《系统配置手册》 《系统维护手册》 《系统管理员手册》 6.2 实施保障 (1)实施阶段与过程 根据本项目的实施策略和建设时间要求,将该项目的建设实施过程科学、合理、有效地分成若干个主要阶段,将建设内容和范围分成若干部分。项目的实施要统筹考虑,首先要完成学校最急需、最重要的应用,根据学校现行业务运作周期的规律,确定实施的时间,同时还要考虑应用实施的各种内部、外部因素,原有应用和人员基础等情况,制定分阶段实施计划,进一步明确和细化每个阶段的工作范围、内容、人力投入、过程、责任、交付成果等,成为下一阶段的基础。 (2)合作研发和管理 在项目建设实施的整个过程中,制定明确的总体和分阶段成果交付与验收内容、准则、程序、监控手段等。 6.3 安装、测试及验收要求 (1)软件系统部署与安装 在整个项目的开发实施过程中,包括需求分析阶段、系统设计阶段、代码生成阶段和测试运行阶段,要充分考虑合作研发,在每个阶段设计安排学校参与人员的数量、技术背景、工作任务等,不仅使参与人员在研发中得到技术培训和锻炼,而且使他们能够深入了解把握项目开发的全过程,监督控制研发过程的质量。 (2)测试和验收 中标方应向采购人提供本项目采购产品的部署与安装、调试和已有的应用系统集成及后期维护服务的全部内容,中标方应本着认真负责态度,组织技术队伍,做好投标的整体方案,并书面提出长期保修、维护、服务以及今后技术支持的措施计划和保障措施。 中标方应根据所提交的验收方案和实施办法,自行组织设备和人员,并在使用单位监查下现场进行测试和验收。 第七部分 售后服务要求 中标方应承诺,终验合格后对项目产品实行一年全方位质保和技术服务。中标单位需提供完善快捷的后续软件维护服务,承诺在软件维保期内免费提供基于系统更新、升级的各类更新版本,以确保系统平台安全、可靠运行。 中标方应承诺,根据对校方相关业务运作的规律来有计划地制定服务保障体系。服务保障体系应具体包括如下内容: (1)运行保障机构 投标方应详细描述对于建设本项目的运行保障能力。 (2)质保期内运行服务内容 中标方须提供原厂一年的技术支持、质保。质保期从项目整体验收结束之日起计算。 对于售后服务请求,30分钟内响应,6小时内到达现场,常规技术故障应在12小时内解决升级服务:在质保期内提供升级服务。 升级服务:在质保期内提供同版本系列升级服务。 维护服务:定期走访或实行远程维护:定期维护的时间区间、周期和详细规划,规划包括:方式、人员和详细的维护内容。 重大事项的及时响应:系统出现故障或意外情况导致系统不能正常运行时,中标方响应的情况描述,应该包括:人员、时间和内容等。 服务请求的方式:在校方需要提供服务时,能够与中标方联系沟通的方式描述,应包括:服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站。 服务请求的流程:中标方对用户的支持或维护请求处理流程的流程图和详细描述。 (3)质保期后的服务标准 投标人须明确标明质保期满后的售后服务标准及费用。 (4)运行服务的档案 运行服务的详细记载,可以用于分析总结。 (5)用户投诉 有用户投诉受理,请描述以下内容:电话(或传真)、投诉负责人和受理答复时间。 7.1 培训要求 培训应贯穿于整个项目的实施过程中,包括在从项目准备、研发到项目运行的全过程中。为了使学校的相关人员掌握本次建设内容的使用、维护和管理方法,达到能独立进行管理、故障处理、日常测试和维护等工作的目的,应进行系统的技术培训,以保证所建设的系统能够正常、安全、平稳地运行。要求提供以下几方面关于培训的描述: 1、培训要求: 中标方派出的培训教员应具有丰富的同类课程的教学经验和应用经验;所有的培训教员应用中文授课;中标方应为所有被培训人员提供培训用文字资料和讲义等相关材料,如果培训地点在外地,中标方还应为所有被培训人员提供食宿;中标方应按合同规定安排培训时间和培训名额。所有的针对本项目的培训应免费提供。 2、培训方式: 包括课堂讲解、上机操作和实际工作的参与。 中标方进行的培训工作包括了培训方案的设计、培训制度的制定、培训开发、培训实施和培训效果评估,及时监控培训效果,保证培训课程符合学校实际的需要。在系统运行(含试运行)的各个阶段相应的培训内容描述,培训阶段安排包括:项目管理人员培训、系统分析人员培训、系统开发人员培训、系统管理人员培训、系统维护人员培训和系统使用人员培训。 3、培训内容 1)运行管理培训 为了使学校的相关人员掌握有关应用系统的使用、维护和管理方法,达到能独立进行管理、故障处理、日常测试和维护等工作的目的,应进行系统的技术培训,以保证所建设的系统能够正常、安全、平稳地运行。 2)数据清洗与整合业务培训 讲解数据清洗与整合的概念,提供详细的数据清洗与整合中间件的参数设置指南,指导用户上机进行模拟操作。 3)业务系统使用培训 通过培训,使用户掌握智慧校园产品应用系统的使用方法,能够独立的在智慧校园应用系统上完成日常工作办理。 7.2 个性化服务要求 7.2.1 专项服务 序号 | 服务名称 | 服务描述 | 投标响应 | 1 | 应用数据维护 | 因非正常操作引起的数据错误、不完整、丢失、混乱而产生的维护工作; | | 因不规范历史数据需要导入系统而产生的维护工作; | | 由于指标使用中超出规定引起系统性能问题而产生的维护工作; | | 用户对安全授权体系的不正确操作而产生的维护工作; | | 用户组织机构等基本数据准备不完整而产生的维护工作。提供解决方案。 | | 2 | 系统迁移 | 因用户原因需要进行系统迁移,提供解决方案。 | | 3 | 安全云服务 | 利用安全监控预警系统,实现个性化安全监控服务,包括服务器运行状态监控、快速安全预警,实现从被动安全体系建设到主动安全体系建设。 | | 4 | 培训服务 | 通过远程交流、视频会议等形式,为学校提供业务或产品使用方面的培训。 | | 5 | 等级保护配合 | 按照GB/T 22239-2008《信息安全技术 信息系统安全等级保护基本要求》中第二级或第三级“应用安全”和“数据安全及备份恢复”的要求配协助完成等级保护测评。 | | 7.2.2 运营与推广 序号 | 服务名称 | 服务描述 | 投标响应 | 1 | 业务研讨 | 围绕教育信息化热点、建设方案、建设经验等内容定期举行业务研讨。 | | 2 | 开发培训 | 为校内核心人员提供基于融合服务的开发培训。 | | 3 | 推广服务 | 以提升融合服务的用户体验、知晓量、访问量为目标,根据实际情况制订推广方案(包括内容创意/策划/设计、地推、网络推广、活动等),以争取在短时间内实现推广效果。 | | 4 | 运营服务 | 帮助学校组建校内长期运营团队,并提供内容建设、活动策划、用户维系、数据分析等服务,持续关注用户体验改进。 | | 第八部分 其他要求 (1)所有内容均为必要条件,有一条不满足即按废标处理。 1
来源:黑龙江黑龙江八一农垦大学
------------------------------------招标信息结束----------------------------
标签: 监控 项目 中标 政府 资源
上一篇: 2018年02月08日辛集市土地开发中心于下午发布辛集市土地开发整理中心辛集市2017年度高标准农田建设项目公开招标公告2月8日
下一篇: 返回列表
本站网址:
-------------------------------------友情提示:--------------------------------
注意:本站点所有信息全部免费浏览,来源于黑龙江黑龙江八一农垦大学地政府采购网站,本站不做任何修改以及联系方式屏蔽,其真实性需要使用者自己确认,十环网2018招标所有信息均为免费公开查询,不承担任何商业责任!如果2018招标有涉及到虚假和隐私信息,需要删除的请使用以下方式联系我们,我们将在第一时间处理!
更正或删除信息请发邮件:59922383@qq.com
|