扬州工业职业技术学院融合门户建设项目 JSZC-320000-SCZX-G2024-0260
扬州工业职业技术学院融合门户建设项目 JSZC-320000-SCZX-G2024-0260
江苏省政府采购合同(服务)
2024 年 9 月 13 日
江苏省政府采购合同(服务)
(合同编号: )
项目名称:扬州工业职业技术学院融合门户建设项目 项目编号:JSZC-320000-SCZX-G2024-0260
甲方:(买方):扬州工业职业技术学院 乙方:(卖方):师创教育软件研究院(江苏)有限公司
甲、乙双方根据江苏省政府采购中心融合门户建设项目公开招标的结果,签署本合同。
一、合同内容
1.1 标的名称:扬州工业职业技术学院融合门户建设项目。
1.2 标的质量:符合招标文件要求及国家标准。
1.3 标的数量(规模):1 套。
1.4 履行时间(期限):合同签订后 23 个月内。
1.5 履行地点:扬州工业职业技术学院。
1.6 履行方式:现场交付。二、合同不可分割部分
招标(采购)文件、投标(报价)文件、合同条款及中标(成交)通知书,乙方在投标(响应)、评标(评审)过程中所作其它有关承诺、声明、书面澄清等均为合同不可分割的部分,与主合同具有同等法律效力。
三、合同金额
3.1 本合同金额为:¥1,178,000.00,大写:壹佰壹拾柒万捌仟圆(元)人民币。四、技术资料
4.1 乙方应按招标文件规定的时间向甲方提供服务(包含与服务相关的货物)的有关技术资料。
4.2 没有甲方事先书面同意,乙方不得将由甲方提供的有关合同或任何合同条文、规格、计划、图纸、样品或资料提供给与履行本合同无关的任何其他人。即 使向履行本合同有关的人员提供,也应注意保密并限于履行合同的必需范围。
五、知识产权
5.1 乙方应保证甲方在使用、接受本合同服务(包含与服务相关的货物)或其任何一部分时不受第三方提出侵犯其专利权、版权、商标权和工业设计权等知识产权的起诉。一旦出现侵权,由乙方负全部责任。
5.2 甲方享有本合同约定的软件系统在扬州工业职业技术学院范围内的永久使用权。甲方可根据自身业务管理的需要,把该软件用于实际的计算机应用环境或者改进其功能、性能而进行必要的修改。
5.3 乙方应保证甲方在使用、接受本合同服务(包含与服务相关的产品)或其任何一部分时不受第三方提出侵犯其专利权、版权、商标权和工业设计权等知识产权的起诉。一旦出现侵权,由乙方负全部责任。
5.4 本项目合同生效前已有的知识产权(包括著作权)归软件原厂商,生效后新产生的知识产权(定开部分)归甲方所有。甲方利用乙方提交的技术服务工作成果所完成的新的技术成果,归甲方所有。乙方利用甲方提供的技术资料和工作条件所完成的新的技术成果,归甲乙双方所有。
六、产权担保
6.1 乙方保证所交付的服务(包含与服务相关的货物)的所有权完全属于乙方且无任何抵押、查封等产权瑕疵。
七、履约保证金
7.1 乙方交纳合同金额的 5%作为本合同的履约保证金。
7.2 合同履行结束后,甲方应及时退还交纳的履约保证金。
7.2.1 履约保证金退还方式:甲方应将履约保证金原路退还至乙方指定的银行账户。
7.2.2 履约保证金退还时间:甲方应在项目所有阶段的任务完成且验收合格后的 5 个工作日内,将履约保证金退还给乙方。
7.2.3 履约保证金退还条件:项目所有阶段的任务完成且验收合格。
7.2.4 履约保证金不予退还的情形:
(1)乙方未按照合同约定履行义务,导致合同无法正常履行;
(2)乙方提供的产品质量不符合合同约定,经甲方提出整改要求后仍未达到要求;
(3)乙方存在严重违约行为,如延期交付、提供虚假材料等;
(4)因乙方原因导致合同解除或终止。八、合同转包或分包
8.1 乙方不得将合同标的转包给他人履行。
8.2 乙方不得将合同标的分包给他人履行。
8.3 乙方如有转包或未经甲方同意的分包行为,甲方有权解除合同。九、合同款项支付
9.1 合同款项的支付方式及进度安排
9.1.1 第一次付款:乙方按要求完成融合门户建设的第一阶段建设内容。经甲方确认无质量问题,乙方向甲方开具发票,自收到发票之日起 15 日内支付合同金额的 40%。
9.1.2 第二次付款:乙方按要求完成融合门户建设的第二阶段建设内容。经甲方确认无质量问题,乙方向甲方开具发票,自收到发票之日起 15 日内支付合同金额的 30%。
9.1.3 第三次付款:乙方按要求完成融合门户建设的第三阶段建设内容。经甲方确认无质量问题,乙方向甲方开具发票,自收到发票之日起 15 日内支付合同金额的 30%。
十、税费
10.1 本合同执行中相关的一切税费均由乙方负担。十一、项目实施周期
11.1 项目履行时间为合同签订后 23 个月内。
11.2 合同签订后 4 个月,完成第一阶段建设内容。
11.3 合同签订 12 个月,完成第二阶段建设内容。
11.4 合同签订 23 个月,完成第三阶段建设内容。
11.5 每阶段的具体建设内容详见附件 2《招标文件内容要求》。十二、培训服务
本项目提供提供免费培训 4 次,确保使用人员可独立自主运用系统能力。针对至少系统管理员、业务部门、普通教师三种角色分类别进行针对性培训。
十三、项目验收
13.1 甲方依法组织履约验收工作。
13.2 甲方在组织履约验收前,将根据项目特点制定验收方案,明确履约验收的时间、方式、程序等内容。乙方应根据验收方案内容做好相应配合工作。
13.3 对于实际使用人和甲方分离的项目,甲方邀请实际使用人参与验收。
13.4 如有必要,甲方邀请参加本项目的其他供应商或第三方专业机构及专家参与验收,相关意见将作为验收书的参考资料。
13.5 甲方成立验收小组,按照采购合同的约定对乙方的履约情况进行验收。验收时,甲方按照采购合同的约定对每一项技术、服务、安全标准的履约情况进行确认。
13.6 验收合格的项目,甲方根据采购合同的约定及时向乙方支付合同款项、退还履约保证金。验收不合格的项目,甲方依法及时处理。采购合同的履行、违约责任和解决争议的方式等适用《民法典》。乙方在履约过程中有政府采购法律法规规定的违法违规情形的,甲方将及时报告本级财政部门。
十四、售后服务
14.1 提供远程网络支持服务及热线电话,简单问题和故障 4 小时内解决,复杂 问题 8 小时内解决、如遇软件系统严重故障并不能通过远程服务进行解决的,安排工程师于 20 小时内到现场提供技术支持服务直至问题和故障排除,36 小时内确保正常运行。
14.2 提供自系统验收之日起三年免费质保和版本升级服务,在此基础之上延长三年免费质保,即提供六年的免费质保服务,免费质保期后的运维费用另行计算。
14.3 BUG 处理:如投标人交付的业务系统存在 BUG,提供修正与消缺服务,如有修复 BUG 的补丁,提供升级服务。
14.4故障处理:交付的系统上线运行时,出现问题导致业务中断时,对故障进行处理。由于非计划掉电导致系统故障时,配合系统恢复。由于系统资源不足
导致系统故障时,配合学校系统恢复。由于硬件故障时,在学校数据还原后,配合学校系统恢复。
14.5 运行支持:对系统运行过程中系统管理员及业务管理员的问题提供解答和问题解决跟踪。
14.6在项目质保期内,因为软件系统本身原因导致系统不可用,全程跟踪解决,确保问题快速解决,因为操作系统、服务器、网络设备及其他硬件设备导致系统不可用时,配合甲方排查故障,提供解决方法供甲方选择,配合甲方解决问题。
14.7 乙方派往甲方现场的人员,具有较高的业务素质,现场解决问题时,不会无故拖延或推迟,为甲方提供最佳的服务。
14.8 乙方无偿向甲方提供系统运行初期的技术培训及质保期内的运行技术服务。 14.9质保服务到期后,每年服务费不得高于中标金额的 10%。
十五、违约责任
15.1 甲方无正当理由拒绝接受乙方提供服务的,甲方向乙方偿付拒绝接受服务合同价款总值的违约金。
15.2 甲方无故逾期验收和办理合同款项支付手续的,甲方应按逾期付款总额每日向乙方支付违约金。
15.3 乙方逾期提供服务的,乙方应按逾期提供服务合同总额每日千分之六向甲方支付违约金,由甲方从待付合同款项中扣除。逾期超过约定日期 10 个工作日不能提供服务的,甲方可解除本合同。乙方因逾期提供服务或因其他违约行为导致甲方解除合同的,乙方应向甲方支付合同价款总额的违约金,如造成甲方损失超过违约金的,超出部分由乙方继续承担赔偿责任。
15.4 乙方所提供服务的标准不符合合同规定及招标文件规定标准的,甲方有权拒绝接受服务,并可单方面解除合同。
十六、不可抗力事件处理
16.1 在合同有效期内,任何一方因不可抗力事件导致不能履行合同,则合同履行期可延长,其延长期与不可抗力影响期相同。
16.2 不可抗力事件发生后,应立即通知对方,并寄送有关权威机构出具的证明。
16.3 不可抗力事件延续 120 天以上,双方应通过友好协商,确定是否继续履行合同。
十七、解决争议的方法
17.1 双方在签订、履行合同中所发生的一切争议,应通过友好协商解决。如协商不成,由甲方住所地人民法院管辖。
十八、合同生效及其它
18.1 合同经双方法定代表人或授权委托代表人签字并加盖单位公章后生效。
18.2 本合同未尽事宜,遵照中华人民共和国现行法律法规有关条文执行。
18.3 本合同正本一式捌份,具有同等法律效力,甲方执陆份、乙方执贰份。以下无正文。
甲方:扬州工业职业技术学院
地址:江苏省扬州市邗江区华扬西路 199 号法定代表人或授权代表::
联系电话:
乙方:师创教育软件研究院(江苏)有限公司
地址:江苏省常州市新北区太湖东路 9-2 号 B 楼 23 层法定代表人或授权代表::
联系电话:15868432744
签订日期: 2024 年 9 月 13 日
附件 1:招标文件具体采购需求一、基本要求
(一)项目总体设计
要求从建设背景、总体建设目标、涉及的领域技术、建设的相关标准、建设的相关原则、建设的相关技术路线等角度出发,进行总体设计方案编制,切实服务学校实际情况和当前信息化发展技术。
要求融合门户建设项目能够打造数字化校园整体建设规划总集成入口和门面,通过整体规划集成,打造一网通办、一网统管门户服务、一网畅学高度集中的应用板块,使得学校业务模块化,应用定位高效化,门户使用便捷化。要求提供统一日程中心、统一待办中心、统一消息中心、统一资讯中心、统一应用中心,实现服务聚合、业务协同功能,让师生在一个平台上就能够便捷地完成多项操作,提高工作效率。要求提供统一身份认证平台,优化认证机制,提升用户体验,适应学校对精细化身份管理的需求,打破前序建设过程中身份认证需要面向不同终端反复对接的桎梏,建立基于统一的身份网关,实现一次接入,多端复用的对接体验。融合门户建设项目的完成将进一步提升教育数字化水平,推进数字化校园建设,更好地服务于教学、科研和管理,为师生创造更优质、便捷的数字化环境。
(二)项目建设范围
序号 | 建设 内容 | 内容明细 | 数量 | 技术规格 |
1 | 融 合 门户建设 | 基础支撑服务平台 | 1 套 | 参见系统指标要求 4.1 |
2 | 融合门户服务 | 1 套 | 参见系统指标要求 4.2 | |
3 | 移动支撑服务 | 1 套 | 参见系统指标要求 4.3 | |
4 | 统一身份认证平台 | 1 套 | 参见系统指标要求 4.4 | |
5 | 对 接 服务 | 实现现有第三方系统对接,并提供本平台所有统一规范的接口用于后续 系统应用的接入 | 1 套 | 参见系统指标要求 5 |
二、建设内容具体技术要求
(一)软件项目建设要求
1、软件供应商(含原厂商)必须遵照软件工程规范进行项目系统开发,执行学校的信息化建设规范和标准,以确保学校数据中心(中台)与各系统数据共享和交换的一致性;软件供应商(含原厂商)需要配合学校对数据标准进行补充、完善;系统须支持 IPv4/ IPv6 双栈部署及访问;系统须兼容 HTTPS 协议。
2、各软件系统所需要的基本共享数据及需要学校其他系统提供的各类数据,一律以标准数据访问接口方式从学校数据中心(中台)获取;软件系统所产生的所有数据归学校所有均须对学校开放,须永久免费提供用于数据采集和数据交换的对外接口,支持通过多种方式与学校数据中心(中台)对接。满足学校实时数据集成的需求,按照学校确定的对接实现方式,提供各种实时对接支持,提供详尽数据字典,开放数据库日志,提供数据库、日志等读权限账号。验收前须按学校要求完成所有数据对接工作,并在质保期内随着学校数据中心(中台)升级、改版等需要免费升级或重新对接。
3、软件供应商(含原厂商)必须保障基础设施、信息系统和信息资源的安全,包括并不限于操作系统安全、业务系统安全、数据安全、运维安全等,做好系统及数据本地备份。项目实施前签订《安全承诺函》并加盖公章。
4、系统上线运行须提供第三方的安全测评报告,系统运行过程中及时解决各类安全漏洞,确保系统一直满足相应的信息系统安全等级保护标准;因系统安全原因造成的损失供应商必须承担相应责任。
5、软件系统验收其他要求按学校有关规定执行。
6、投标供应商应承诺本项目质保期内相关对接、集成、改造费用,包括学校与相对应的平台、数据和接口发生新建、升级、改造,均包含在本次投标费用中。
7、本项目质保期内需满足教育部全国职业教育智慧大脑院校中台的数据要求,配合学校提供相应数据,完成教育部数据上报工作。
(二)技术指标要求 1、技术要求
本项目平台要求符合国家级、省部级相关部门的设计指导原则,系统建设必须符合我国相关部门制订的标准,对安全策略、密码与安全设备选用、网络互联、安全管理必须符合我国信息安全法律法规。
本项目要求采用微服务架构模式,采用较为稳定的负载均衡技术、服务器状态监测技术、附件要求采用分布式存储技术、数据库要求支持自动备份,以提高系统的高稳定性。本项目的建设要求支持以下建设原则:
1.1 先进性和实用性
本项目平台设计既要采用超前思维、先进技术和系统工程方法,又要注意思维的合理性,技术的可行性,方法的正确性。系统的设计,能反映当今的先进技术和对应理念,符合职业院校发展规律,解决学校管理和治理中的痛点问题。
1.2 标准化和规范化
本项目平台建设技术路线应能够实现学校统筹规划的应用需求和未来发展,符合并遵守学校制定的教育信息化技术规范、软件设计与开发规范、软件设计开发标准标准规范要求。
1.3 可用性和可靠性
本项目平台在高负载的情况下系统需保证业务的可用性;在局部故障发生时需保证整体业务的连续性;要求解决方案和产品必须具有良好的可管理性和可维护性,便于日常运行维护和管理。
1.4 可管理性和可维护性
本项目平台需具有良好的可管理性和可维护性。面对的不同用户角色、不同的职位,访问权限和业务操作需要也不尽一致,从功能的扩展和管理要求而言,应将业务功能碎片化、微服务化、便捷化、实现独立封装。
1.5 安全性和保密性
按照信息系统平台需具有系统性、立体性要求,在系统硬件、网络、操作系统、数据库、应用操作权限、应用访问权限、数据权限、身份认证方面,提供全面的、多级别的安全防护设计方案。
2、项目安全要求
2.1 运维安全
加强信息化建设的同时,需将信息安全作为运维中的关键点,以此为基础的情况下,保障平台高效运行。
2.2 开发安全
要求遵从国家相关安全开发标准,确保软件开发过程安全;
要求对所利用开源代码、商用组件、商用密码等提前进行声明并为用户接受;要求制定代码编写安全规范,开发人员须按照规范编写代码;
要求提供软件设计的相关文档和使用指南,并指派专人负责保管;要求利用内部数据进行测试时,应对敏感数据进行脱敏处理;
要求开发测试环境应与生产环境进行隔离,禁止在生产环境中进行直接测试,第三方人员接入生产环境时,应有访问控制及安全审计管理;
要求提供应用软件开发须遵循的相关标准(包括国家标准和行业标准)目录,并严格按照标准进行开发,对无法达到标准要求的,须作出说明并得到用户同意。
2.3 代码安全
要求能够防范跨站脚本、SQL 注入、命令注入、路径遍历等攻击;
要求能够防止存在 LDAP 注入、XML 注入、XPATH 注入、SMTP 注入及其他常见的注入攻击漏洞;
如果系统提供了下载功能,要求能够防止用户通过路径遍历漏洞下载敏感资源文件;
如果系统提供了文件上传功能,要求能够防止用户上传后门脚本;
要求禁止应用系统设计有违反或绕过安全规则的任何类型的入口和文档中未说明的任何模式的入口;
要求系统调用应采用域名方式。
2.4 数据安全
(1)要求数据的管理权限符合以下要求:
数据库管理账号的权限包括创建和删除数据库表、创建和删除索引、修改表结构、授予数据库权限给其他用户;
数据库应用账号的权限包括访问数据库表和索引;
数据库运维账号的权限包括访问、创建、删除表和索引。
(2)要求数据的传输与存储符合以下要求:
要求采用加密或其他有效措施实现系统鉴别信息传输和存储的保密性。
(3)要求数据库审计符合以下要求:
要求对数据库登录行为进行记录审计,记录内容应包括:登录使用的账号、登录时间、登录 IP 地址、IP 所在地区、登录是否成功;
要求对数据库操作行为进行记录审计,记录内容应包含:操作时间、操作类型、操作用户、数据库表、操作执行结果;系统日志和操作日志应至少保留 180天。
(4)要求能够进行数据备份:
要求能够制定数据备份策略,要求能够配合学校对数据备份行为进行记录和保存,能够在维保期内配合学校采用抽测或全测的方式至少每半年对备份数据进行一次有效性验证。
3、其他服务要求
3.1 要求用户的访问界面采用 Web 方式。
3.2 要求支持多种主流的浏览器,如 Edge、Chrome、Safari、火狐、360 浏览器。
3.3 要求融合门户平台支持 50000 注册用户使用。
3.4 要求融合门户在100000 条数据记录并发下查询操作平均响应时间小于3秒。
3.5 投标方需列出本次产品合理的设备需求,并阐述每一台设备的规划,方便学校考虑资源投入。
3.6 要求融合门户建设项目能够适配主流的国产服务器操作系统。
3.7 融合门户建设项目运行数据应适配我校提供的主流国产化数据库。投标方需提供适配报告,加盖公章。
3.8 要求系统上线前完成相关网站安全自检工作,修复好安全漏洞。
3.9 要求系统供应商积极配合学校做好互联网访问的公安备案工作。新建系统等级保护要落实“同步规划、同步建设、同步使用”三同步要求,要求供应商配合学校做好定级备案和等级测评工作。
4、系统应用建设要求
4.1 基础支撑服务
基础支撑服务提供用户管理服务、组织架构服务、融合门户引擎服务、数据同步服务和数据开放服务,形成治理一体化的基础引擎支撑服务,完成面向各级领导和管理者的决策中心,利用信息技术向师生提供更优质的服务体验。
要求将融合门户和身份认证中的用户管理、组织架构和权限管理进行全面且
统一的优化和管理。通过采用集中化、标准化的管理策略,可以确保我校资源的安全性和高效性。
序 号 | 内容 明细 | 数 量 | 单 位 | 功能及技术参数 |
1 | 用户管理服务 | 1 | 套 | 1、部门属性维护。要求支持新增部门属性、对已有的部门属性进行编辑、删除和查询。要求提供高级搜索和模糊搜索,可以对属性名称进行筛选搜索。 2、用户类别。要求支持用户类别绑定默认角色,支持用户类别的增删改查、支持查看每个用户类别绑定的用户数,可下钻查看具体人员,并可以在此进行绑定人员的解绑和新绑定。 3、用户来源。要求能够支持记录该用户信息的记录源头,如人事系统对接人员、手动新增的临时人员。 4、角色管理。要求角色管理可以对角色进行增删改查,同时支持查看每个角色绑定用户数、应用数,可下钻查看具体详情,并可以在此进行绑定人员的解绑和新绑定。 5、角色标签维护。要求支持角色标签的增删改查,如果标签下绑定角色,不允许删除。要求提供高级搜索和模糊搜索,可以对标签进行筛选搜索。 6、在线统计。要求支持查看当前在线人员,并支持导出可按照账号、姓名和部门进行筛选。 7、管理员可查看并管理在线用户相关信息,包括可查看登录账号、用户姓名、登录系统(PC 端、移动端、H5、管理端等)、部门、主机IP、IP 地址、登录地址、浏览器、操作系统、会话状态(在线、离线)、登录时间、最 后访问时间、操作(强退)。 |
为实现数据统一呈现和数据共享互通,要求能够贯通数据库,实现数据中心数据同步至门户进行呈现,融合门户相关数据能够归档至数据中心,并便于其他业务进行数据调用。具体要求如下:
2 | 组织架构服务 | 1 | 套 | 1、要求组织架构模块内进行部门管理、用户管理、筛选管理、显示列定制、批量移动人员和操作日志,组织架构要求支持分级授权、多部门管理。 2 要求管理与学校发生关联的全部用户,包括领导、教职工、学生、校友、后勤人员、访客、临时人员、校外专家、家长,满足学校日益增长的个性化人员体系管理需求。 3、要求能够支持新增临时人员信息,并对临时人员信息能够进行编辑和删除操作。 4、要求与企业微信做人员及组织架构的对接,能将人员信息推送给企业微信,同时将企业微信号保存到身份认证 系统内;需支持通过企业微信消息来自助修改密码。 |
3 | 1 | 套 | 要求提供可视化的门户引擎服务,学校管理员可以通过可视化的操作,快速通过门户引擎进行融合门户的修改、调整和新增。具体如下: 1、基础信息设置 1.1 要求能够在门户引擎中对学校基本信息进行设置维护:能够直接配置学校名称、学校简称、系统名称、是否启用系统名称;要求能够支持上传学校的 LOGO,支持添加学校标签和学校图标。 1.2 要求能够在门户引擎中对融合门户中的导航菜单栏进行设置维护:要求支持设置分类是否显示;支持新增新的分类,新的分类需要维护名称、链接和打开方式,其中打开方式包含内嵌、新标签页、新窗口;支持分类支持拖拽排序。 1.3 要求能够在门户引擎中对图标链接进行设置维护:图标链接支持设置是否显示,新增新的图标链接,支持图标链接排序。新增新的图标链接时需要维护名称、图标。 1.4 要求能够在门户引擎中对版权信息进行设置维护:支 持自定义设置登录页背景图,支持自定义设置登录页底部 |
版权信息。 1.5 要求支持融合门户首页中英文切换功能,要求支持融合门户首页字体大小一键切换功能。 2、门户元素服务要求门户元素能够进行分类和授权,根据授权判断是否可见,支持导入新增的元素。 2.1 要求支持修改元素所属分类,要求支持不同的元素在此维护,要求在编辑每个元素时,可撤销和恢复上一步操作;要求支持预览元素。 2.2 要求支持导出系统中已有元素,并支持将导出的包进行备份。 门户元素要求包含以下内容: 顶部导航元素:要求支持Logo 能够灵活维护。支持搜索框可配置是否显示,搜索框点击后有历史搜索记录。支持头像和姓名取用户信息中的头像和姓名。 资讯中心元素:要求支持设置资讯中心背景图或背景颜色,支持修改资讯中心顶部标题名称,支持增加、删除资讯中心的 tab 页,要求支持配置底部遮罩背景图或背景颜色。 快捷导航元素:要求支持设置滚动、分类、快捷导航区域的背景图或背景颜色,支持设置滚动图和滚动图滚动时间间隔。 通知公告元素:要求支持修改通知公告名称,支持配置数据来源接口,接口配置后,若有相关数据,则需自动获取当前接口所有的字段,在标题、时间、详情地址、详情内容、图片上面选择对应的接口字段,支持配置更多页面地址。 底部统计元素:要求支持设置底部统计背景图或背景颜色,联系方式支持添加多行维护文本内容,访问量固定三 个统计不能修改:当日访问量、当前在线人数、共计访问 |
量。 版权信息元素:要求支持设置版权信息背景颜色;支持添加多行,每一行内支持添加多个文字描述和图片,每行支持拖拽排序,行内添加的文字和图片也支持拖拽排序。 3、门户布局服务 3.1 要求布局排版时,可根据需要打开和关闭元素库、打开和关闭配置、打开和关闭图层,支持布局页面的画板缩放,支持选择不同分辨率情况进行预览。 3.2 要求支持每个门户布局可单独设定排版,每个元素可在同一门户布局内被多次使用,每个元素在布局排版页面时,点击每个元素可放大预览元素。 3.3 要求每个元素在布局时要支持直接选中,鼠标移动至某个元素右键出现操作,可对元素名称和分类进行搜索。 3.4 要求在布局服务中能够设置对应元素所对应的使用者、应用及其权限。 3.5 实现二次认证。要求针对融合门户中的敏感信息页面或个人应用进行二次身份认证,要求支持以密码输入的形 式再次验证身份其身份,确保关键信息安全。 | ||||
4 | 数据同步服务 | 1 | 套 | 1、系统所需要的基本共享数据及需要学校其他系统提供的各类数据,一律以标准数据访问接口方式从学校数据中心(中台)获取。系统接口同步支持自动同步,以及管理员手动同步操作。 2、要求支持同步计划的管理。可以设置同步的执行类型,可以对同步过程的间隔时间以及同步的模式进行自定义。 3、管理员可查看并管理同步接口任务相关的调度日志,包括任务名称、日志同步相关信息(任务名称、同步时长)、 同步状态(成功、失败)、同步时间、同步详情。 |
5 | 数据 开放 | 1 | 套 | 1、系统所产生的所有数据归学校所有均须对学校开放, 须永久免费提供用于数据采集和数据交换的对外接口,支 |
服务 | 持通过多种方式与学校数据中心(中台)对接。 2、满足学校实时数据集成的需求,按照学校确定的对接实现方式,提供各种实时对接支持,提供详尽数据字典,开放数据库日志,提供数据库、日志等读权限账号。 3、要求能够按照数据标准将数据归档至数据中心,比如 用户基本信息修改、新增人员账号。充分发挥本平台内的数据效能。 | |||
6 | 能力开放平台 | 1 | 套 | 1、展示各类接口的信息,支持接入、删除等管理操作,支持查看接口授权情况、使用情况、被调用日志等操作。 2、支持直接在应用详情的页面上,统一展示接口的授权信息。可以将系统中已经定义的接口授权给指定的应用。 3、系统应支持配置是否限制某一或多个 ip 地址的接口调用权限,并支持管理员的启停操作。 4、投标方列出能力开放平台的接口清单,至少包含用户属性接口、用户组接口、用户组属性接口、消息发送、查询消息发送状态、消息阅读状态、待办接口、待办事务状态、待办阅读状态、日程接口、搜索能力接口、资讯管理 接口、应用管理接口。 |
4.2 融合门户服务
序 号 | 内容 明细 | 数 量 | 单 位 | 功能及技术参数 |
1 | 融合门户展板 | 1 | 套 | 要求提供 PC 和移动端同步联动的聚合展示用户个人相关的数据信息,包括成绩、一卡通信息、图书借阅信息、未读邮件模块、工资信息、值班信息,让用户登录融合门户 后能够快速查看与自身相关信息,要求支持融合门户首页 |
融合门户服务包括融合门户展板、一网通办门户服务、一网统管门户服务、一网畅学门户服务、统一日程中心、统一待办中心、统一消息中心、统一资讯中心、统一应用管理、通讯录、角色门户分类、用户信息服务、效能数据分析功能。具体如下:
中英文切换功能,要求支持融合门户首页字体大小一键切换功能。 1、值班展示模块:要求支持与 OA 接口对接,支持值班 excel 表的导入,支持相应权限管理员进行调班的操作。展示当前带班校领导、总值班、男女辅导员。并与消息中心打通,能够设置消息提醒时间。 2、未读邮件模块:要求支持对接外部邮箱(我校使用的是腾讯企业邮箱)与 OA 内部邮件,展示未读邮件。 3、图书借阅模块:要求支持对接图书系统,展示未还图书数、总借图书数。 4、一卡通信息模块:要求支持与数据中心 API/ETL 接口对接,支持与完美校园对接,根据实际情况选择对接方式,展示卡内余额、月度消费总额。 5、成绩模块:要求支持与教务系统对接,展示学生成绩信息。 6、工资模块:要求支持与数据中心 API/ETL 接口对接,支持与工资接口对接,展示个人工资。 7、一站式社区模块:要求支持学生账户登录后,能够查看一站式社区元素样式,要求能够对接学校数据中心获取 学生一站式的相关数据并展示。 | ||||
2 | 一网通办门户 | 1 | 套 | 1、要求一网通办模块简洁、醒目,重视视觉效果和用户体验,页面内容丰富、分类精准、功能贴心、操作快捷。以平台为载体,以规范化、数字化、智能化建设为核心,以信息技术为支撑,以服务师生为根本出发点,提高师生办事效率,优化师生的办事体验。 1.1 事务分类 1.1.1 要求提供不少于两种应用展现模式,如“卡片 式”、“列表式”或其他方式。每一种展现模式中,均需要能够将应用按部门、按主题进行分类,同时需要支持以 |
部门所属和主题分类进行应用交叉过滤。 1.1.2 要求每个服务事项均能够体现服务名称、所属分类,并能够提供服务指南查询、在线办理和快速收藏。并且通过服务指南页面也能够进行在线办理和收藏,无需用户返回后进行相关操作。 1.2 服务检索 要求为全校师生用户提供事项查询与服务指南查看服务,支持包括模糊搜索、标签搜索、分类浏览、快速搜索、推荐事项、服务排行、我的收藏在内的搜索方式,协助用户快速找到想办理的事务。 1.3 服务指南 1.3.1 要求能够通过应用管理将一网通办中的服务进行统一的编排和管理,并且能够进行“服务指南”的相关维护。提供完整的“服务指南”清单,以满足各部门进行相 关服务的指南撰写,如服务名称、所需材料、办事流程、遵循制度。 1.3.2 要求为一网通办的所有应用提供“服务指南”功能。要求通过“服务指南”即可进入部门维护的指南界面,帮助用户了解相关业务的名称、所需材料信息,并在服务指南页面能够进行业务的快速办理。 1.4 在线办理。要求为一网通办的每一个服务均提供对应的“在线办理入口”,通过在线办理即可快速打开对应构建后的表单,从而发起对应事项,所有事项均需要能够查看到实时办理状态和审批意见。同时,要求在上述“服务指南”中也提供“在线办理”入口,在查看相关指南后快速办理事项,无需返回后再进行操作。 1.5 推荐应用。要求能维护推荐应用的推荐背景图、标题和推荐内容、推荐应用的排序、从应用库中新增新的授权 应用、取消推荐应用。支持推荐高频应用。 |
1.6 事务统计。要求系统支持按照访问次数维度进行统计分析,分析出最受欢迎的事务;统计周期包括近一个月、半年或一年。 1.7 主题服务聚合。要求提供服务主题设置,支持将不同系统的服务根据所需业务进行快速重组,让师生能够聚焦办事,例如迎新服务。服务主题支持时效性设置,定时开启或关闭。 2、要求将我校现有系统中的已经对接的应用进行碎片化展示,要求系统提供开放接口,便于后续新系统自行对接 并进行碎片化展示。 | ||||
3 | 一网统管门户 | 1 | 套 | 一网统管门户服务模块要求强调成立统一的业务系统整体推进改革,强调业务系统展示的统一性、数据信息的一致性、平台标准化和业务办理的协同性。要求提供业务直通车和多个业务系统分析和关联分析。 1、应用统管。要求能够进行自定义的管理应用集中展示,要求能够以卡片的形式进行展示,能够展示该应用头像、名称、收藏按钮内容。要求能够将所有管理应用进行一页罗列,提供关闭与展开页面按钮,能够折叠所有的管理应用,达到页面整洁的效果。 2、收藏管理。 2.1 要求能够在管理应用卡片的明显位置设置应用收藏功能,便于师生能够快速收藏常用或重要的管理应用。要 求点击收藏按钮即可收藏成功,再次点击即可取消收藏,并能够以弹框的形式进行提醒收藏成功与取消收藏成功。 2.2 要求能够集中管理我的收藏的应用,能够支持以卡片的形式集中查看,能够查看应用头像、名称内容。 3、最近访问管理。要求能够智能化记录访问历史应用,并进行页面集中呈现,要求能够按照时间顺序展示最近访 问的管理应用,能够支持以卡片的形式集中查看,能够查 |
看应用头像、名称、是否收藏内容。要求能够将所有最近访问的管理应用进行一页罗列,提供关闭与展开页面按钮,能够折叠所有的管理应用,达到页面整洁的效果。 4、数据统计与 TOP 排名 4.1 要求能够针对管理应用的点击次数和最近访问次数进行数据统计分析,能够分别按照应用点击次数和最近访问次数进行折线图、柱状图或其他图形分析形式的数据分析展示,要求鼠标悬停具体图形点时能够展示数量和应用名称。 4.2 要求能够按照访问量进行 TOP5 的应用展示,要求能 够展示应用名称和访问量,要求能够从 TOP 排名上直接访问对应的应用。 | ||||
4 | 一网畅学门户 | 1 | 套 | 一网畅学模块要求针对师生线上学习系统,完美践行云教育理念,重视学生体验,页面内容丰富、分类精准、功能贴心、操作快捷。以平台为载体,以云课堂教育模式信息化、规范化、智能化建设为核心,以信息技术为支撑,以服务师生为根本出发点,实现线下线上教学同步进行。 1、要求一网畅学模块在门户中与一网通办模块并行,师生进入系统后可以迅速定位到一网畅学模块,可以在一网畅学模块下快速定位所需要学习的课程。 1.1 学习数据概览。要求能够展示登陆人基本信息,能够展示累计学习次数、与昨日学习次数比较数、应用访问次数、与昨日访问比较数、校内排名信息;要求能够展示访问应用分类展示以及其占比展示。 1.2 学习应用。要求能够进行自定义的学习应用集中展示,要求能够以卡片的形式进行展示,能够展示该应用头像、名称、学习数据次数内容,要求能够通过关键词进行模糊查询。 1.3 应用收藏。要求能够在应用卡片的明显位置设置应用 |
收藏功能,便于师生能够快速收藏常用或重要的应用。要求点击收藏按钮即可收藏成功,再次点击即可取消收藏,并能够以弹框的形式进行提醒收藏成功与取消收藏成功。要求能够集中管理我的收藏的应用,能够支持以卡片的形式集中查看,能够查看应用头像、名称、学习数据次数内容,能够通过关键词进行模糊查询。 1.4 应用推荐。要求能够按照学校不同的阶段或学校不同的活动开展周期进行不同的应用推荐,要求能够以卡片的形式进行展示,能够展示该应用头像、名称、学习数据次数、收藏按钮内容,要求应用推荐模块能够展示在显眼的位置,能够让师生快速定位应用,提高学习效率。 1.5 学习动态。要求设置学习动态,能够按照时间进行展示师生的学习历史动态,详细记录学习者的名称、学习的内容、学习的时间、学习者的头像。以记录的形式汇总师生的学习历程,便于查看该名教职工或学生的学习路径或学习方向。 2、要求支持管理员可按照自身需求自由配置一网畅学首 页展现位置、板块样式、颜色和文字内容。 | ||||
5 | 统一日程中心 | 1 | 套 | 1、要求提供日程中心服务,集“日程事项添加、日程事项提醒、领导日程自动同步、各系统日程事项自动同步”功能于一体的统一日程中心,使本项目中各应用日程不再分散,提高用户的使用效率。日程中心提供标准接口功能,能够对接统一消息中心。 2、要求支持日程订阅,要求支持用户自行对可订阅的日历进行订阅,要求存在强制订阅日历,不可取消。 3、要求支持日程查看,要求能够选择日历上的时间段进行查看,要求能够支持按照日、周、月查看。 4、要求支持日程提醒功能,要求能够选择某一类日程对 其设置提醒,并能够自行设置日程提醒时间。要求单独新 |
增的日程能够单独设置其提醒方式和提醒时间。要求能够对用户后一天的所有日程进行一次消息提醒。 5、要求提供 PC 端和移动端同步联动的日程中心体系,汇聚个人、系统日程,支持和学校业务系统、校历进行数据集成,自动展示用户相关的校历、课程、会议、活动、值班等。 6、支持日程搜索,在日程汇总能够查看日程详情,包括名称、时间、地点和其他文字详情等。 7、支持个人、群组日程信息的创建,支持日程和消息的打通,支持自行设定日程提醒时间节点,支持创建日程,并选择日程可见人员、日程开始时间、结束时间、地点、事务类型、是否重复等。可见人员在自己日程中可查看该 条日程。 | ||||
6 | 统一待办中心 | 1 | 套 | 1、要求能够通过统一待办中心管理后台进行统一待办配置。要求在配置的过程中,能够实现待办的启用、PC 端和移动端的待办显示状态。 2、要求能够与统一消息中心进行互联互通,实现统一待办提醒的系统消息配置。 3、要求提供统一待办接口,便于第三方系统的接入,如教务系统待办、一站式办事大厅的待办、学生系统待办,实现所有接入待办可从本中心呈现,统一界面,统一入口,简化操作。 4、支持待办任务状态变更接口,允许应用在待办任务完成后修改其状态。 5、平台需支持对待办任务进行状态更新,当应用提供相应接口时,可通过回调应用接口获取最新的待办信息和待办状态,确保待办信息的准确性和实效性。 6、支持待办的搜索,支持模糊搜索,也支持通过关键词、 发起人精准搜索。 |
7、待办能通过消息提醒到用户,用户点开之后直接进入待办内容。 8、对第三方系统的待办进行分类展示。 | ||||
7 | 统一消息中心 | 1 | 套 | 要求提供消息中心服务,集“事项发起提醒、事项审核提醒、待办推送提醒、定时任务推送提醒”功能于一体的消息推送提醒中心,使本项目中各应用消息不再分散,提高用户的使用效率。 1、要求本项目在质保期内,每年提供不少于 25 万条短信包服务。投标人需在投标文件中进行承诺并加盖公章。 2、消息接口管理。消息中心提供标准接口功能,能够对接学校现有的短消息、邮件、企业微信(个人微信)主流应用平台的消息推送机制。提供短信、微信通知、邮件等消息提醒功能;推送的消息支持待办办理链接的关联,实现消息驱办和个性化催办。要求统一消息中心管理端具备后续其他系统消息接入的能力。 3、门户对接管理。要求通过融合门户,能够进行消息中心的快速打开,并对不同类型的消息进行分类呈现,能够展示消息的类型、消息的内容、接收时间、消息状态和对应的操作详情。要求通过消息中心能够使用关键词进行快速搜索,并支持相关删除操作和批量删除操作。 4、消息模板管理。要求支持消息模板管理,认证业务中存在多个涉及消息服务的功能,包括验证码信息、通知信息,要求能够解决涉及的业务类型很多导致需要配置的信息内容非常多的痛点,能够通过管理页面实现对认证业务中涉及的消息内容进行统一管理和配置。然后通过消息平台进行消息推送,包括查询账号、完善信息、激活账号、找回密码、绑定/修改安全邮箱、修改安全手机、修改安全问题、绑定/解绑社交账号操作时的消息推送。 5、消息日志管理。要求支持消息日志审计,记录本平台 |
中发生的所有消息任务,包括在线发送(人工)和系统发送(自动)的全部已发送完成的消息任务记录。提供高级搜索进行消息的检索查询。 6、消息群发管理 a.消息群发 (1)统一消息中心需支持消息的群发,可以将消息发送到指定的用户组; (2)在消息群发时,支持发送者可以选择允许其使用的发送通道,或选择智能发送; (3)当选择智能发送时,通过分析该用户日常使用习惯,进行通道优先级排序,并向用户最常访问通道发送消息。如发送失败,则使用下一优先级通道。如全部失败,则邮箱、短信等方式。 b.消息群发授权 (1)消息群发功能可被授权给部门管理员,部门管理员可以管理自己发送的消息通知,支持新建、删除、查看,部门管理员只能看到本部门发送的消息。 (2)支持富文本消息格式,消息支持添加附件。 (3)支持创建部门私有群组,支持发送信息到指定人员或私有群组或公共群组。 c.消息阅读管理。群发的消息支持用户待阅确认,用户从任何一个端阅读消息,均可将消息视为已读;需支持必读消息提醒功能;当必读消息发送之后,若用户超过时限仍未读此消息,将会触发“提醒规则”;提醒规则需包含的项目有:提醒通道、每天提醒时间、提醒模板。 d.消息发送管理。支持查看消息的发送情况,如:发送成功率、成功发送名单、失败名单、发送通道、用户读取状态、用户阅读时间,并提供发送失败时的处理方法。支 持多通道消息发送,消息通道包括:短信通道、邮箱通道、 |
APP 消息(微信服务号、企业微信、钉钉等)发送通道;消息中心应提供扩展能力,可定制消息通道对接学校指定的其它消息发送通道;应用与其对接后可对外发送消息,所提供的消息发送接口应支持以下两种方式的消息发送: (1)指定通道类型:应用通过指定通道类型发送的消息默认从该类型通道发出。 (2)智能选择:应用通过智能选择方式发送的消息,根据管理员的配置自动发送到多个通道上,用户可根据自身需要订阅使用哪个通道接收消息。 e.消息中心配置管理。消息中心需提供配置界面,允许管理员定义全局默认的消息发送通道;允许管理员定义应用默认消息发送通道;允许管理员调整应用发送的消息的文字内容;允许管理员调整应用发送的消息所使用的通道。 f.消息运行状态管理。平台应提供界面,允许管理员查看平台消息处理能力的运行状态,查看消息发送状态,具体要求: (1)应支持查看消息内容及发送的状态;包含进行消息队列的时间及阅读状态; (2)应支持查看单条消息的发送详情,包括该条消息的具体内容及发送情况,并在通道维度中可查看消息发送失败的故障原因; (3)管理员应可查看该条消息的发送总量及各个发送状态的环比,同时针对该消息发送的各个通道发送数进行展示; (4)应支持该条消息通过用户的维度查看消息的已读及未读情况。 g.消息中心管控台。消息中心管控台应提供通过消息中 心从部署至今的分发消息情况看板统计,可使管理员通过 |
总看板分析的角度查看当前应用系统消息的概况,具体要求: (1)应支持查看发送消息的总数、当天消息数、当天已发消息数、接入至消息中心的应用数、管理员已配置的通道数; (2)应支持查看应用消息、通道消息维度查看消息在一定日期范围内的消息总数及已发消息数;同时通过通道发送的消息,应支持查看发送失败的消息总数及各类型故障原因的环比数据及发送失败消息走线图; (3)应支持查看发送消息最多的应用 Top5 排行,并展示发送次数; (4)应支持通过通道发送的消息详情柱状比,通过对比一定时间内的各应用发送消息的数及失败数进行对比,了解通道的使用情况; (5)应支持查看当前已接入至平台中的应用使用消息中 心分发消息的占比,及消息阅读情况的占比。 | ||||
8 | 统一资讯中心 | 1 | 套 | 1、系统支持聚合学校所有资讯信息,提供统一资讯接口,便于第三方系统的接入,如学校各官网信息、各官方公众号信息,系统平台根据不同角色人员按照场景化,推送相关资讯到相关人员的门户资讯板块。 2、要求支持展示学校公众号相关内容,要求能够对接学 校公众号获取学校公众号相关数据并展示。 |
9 | 统一应用中心 | 1 | 套 | 1、应用分类。支持应用分类的增删改查,删除分类时,如果分类下有绑定应用,不允许删除;所有应用只允许绑定在二级分类下,可查看每个二级分类绑定的应用,同时支持在此解除绑定应用。 2、应用标签。要求支持应用标签的增删改查,删除标签时,如果标签下有绑定应用,不允许删除,支持查看每个 标签绑定的应用,同时支持在此直接新增和解除绑定应 |
用。 3、应用权限。要求支持根据不同的角色权限对不同的应用进行展示。 4、图标管理。要求支持图标分类的增删改查、图标库图标的增删改查、图标的导出和导入。 5、应用设置。要求应用设置支持查看每个应用的 url、一键置顶、应用的增删改查、应用的分角色授权、维护数据、导出和导入应用、拖拽排序。 6、推荐应用。要求在此显示应用中心设置为推荐应用的应用。可维护推荐应用的推荐背景图、标题和推荐内容、推荐应用的排序、从应用库中新增新的授权应用、取消推荐应用。 7、应用维护。要求用于给应用的管理角色的人员维护有 权限维护的应用的上下架、上下线和服务指南内容。 | ||||
10 | 通讯录 | 1 | 套 | 通讯录旨在为在校用户提供一个便捷、高效且安全的通讯方式,实现学校教师或其他组织内部成员之间的快速沟通和联系。 1、通讯录按照登录用户的身份划分为教师通讯录和学生通讯录。 1.1 学生通讯录内支持查看任课老师、班主任、辅导员和同班同学联系方式、邮箱、姓名、学号、工号,支持通过姓名或者手机号、部门、任课课程和是否在线查看详细的用户通讯信息,学生通讯里支持对每个用户的通讯信息通过卡片的形式呈现。 1.2 教师通讯录支持查看全校和本部门的通讯信息,支持采用左数右表的形式进行通讯信息展示,支持通过部门查看教师的通讯录,支持通过选择班级查看学生的通讯录,支持通过姓名、状态、联系人部门和是否在线查看联系人 的通讯信息,支持列表展示姓名、工号、部门、邮箱,支 |
持通过图标的形式展示对方登录的设备。 2、通讯录里的组织架构及用户信息要与数据中台同步,当数据中台的组织架构及用户信息发生变化时,通讯录里的用户信息需自动更新。 3、要求支持按照类型选择是否隐藏显示,要求能够对通讯录中没有的人员进行单个新增。在移动端需支持调用系统通话功能,在每个人后面有个拨号按钮,点击按钮后, 可直接拨打电话。 | ||||
11 | 角色门户分类 | 1 | 套 | 1、平台能够根据不同角色进行个性化的信息展示,包括领导、教师、职工及不同类别的学生角色,展示与角色相关的信息和各类自主设置功能。 2、提供多角色客户定制化的智能门户平台,提供游客访问门户,游客访问时可查看门户中对外开放的资讯信息以 及可查看游客服务流程。 |
12 | 用户信息服务 | 1 | 套 | 1、要求支持对接学校现有的用户信息,要求能够实现用户查看自身的个人信息,包括头像、姓名、性别、登录账号、部门、岗位信息。 2、展示用户个人的基本信息,包括姓名、身份、手机号码。支持用户修改个人基本信息,包括手机号码、个人邮箱等,修改后的信息要同步至数据中心。 3、用户可自行修改个人密码、绑定与解绑邮箱、绑定与解绑微信账号等。 4、提供意见与建议反馈功能,用户端可通过图文提交意见,管理员可查看用户具体反馈情况,并进行后续跟进,管理员可对反馈意见进行处理,如对反馈意见进行分类,对反馈意见进行回复及管理,便于门户的持续优化和改 进。 |
13 | 效能 数据 | 1 | 套 | 1、要求效能数据分析包含当前在线人数、当日访问量、 服务事项总数、累计访问人数、累计办结事项、应用调用 |
分析 | 次数统计。 2、要求能够进行线上热门搜索统计分析,包括搜索人次、人均搜索次数、搜索关键词 TOP5 排名; 3、要求能够进行用户活跃度统计分析,包含院领导、综合管理机构、教学机构,能够查看总使用人次和所占百分比; 4、要求能够分别进行一网通办、一网畅学、一网统管门户服务的数据统计与分析,包含采用柱状图或其他形式展示应用访问量对比分析、对应 TOP5 的应用访问量排名,展示排名、应用名称、访问量,支持对具体应用的访问量 进行占比展示。 |
4.3 移动支撑服务
序 号 | 内容 明细 | 数 量 | 单 位 | 功能及技术参数 |
1 | 移动支撑服务 | 1 | 套 | 移动门户实现融合门户 PC 端展示内容在移动端的展示。 1、移动门户需支持企业微信、个人微信小程序的访问,建设统一的微门户作为移动端唯一入口,且实现学校其它业务系统直接与移动门户对接,不需再与企业微信等进行对接。同时移动门户功能调整、界面调整等配置完后实时更新,不需要经过腾讯审核。 2、移动门户须与 PC 端门户风格匹配,统一用户的使用习惯。 3、移动门户的待办、消息、日程的展示逻辑与 PC 门户保持一致,展示数据也保持一致。方便用户及时接收消息、快速查看和处理待办事项,确保工作的连续性和一致性。 4、移动门户须跟 PC 端在一个端进行管理,包括模板、展示内容、权限管理、页面配置等功能,在管理端调整完之后页面同步更新。 5、移动门户同样包括专题服务、热门服务与应用、最新 |
服务与应用、最近使用、推荐服务与应用、服务与应用分类、办理统计、服务与应用导航等多个功能。 6、实现学校已有移动门户中的所有功能,包括前台应用功能、后台管理功能。如:学生/教师课表查询、工资查询、一卡通消费查询、学生信息查询、固定资产查询、校园地图、学校税号、校历、学校概况、学校动态、未读邮件、事务中心(待办/已办/我的)、OA 通知、一周会议、 通讯录、办事大厅流程等。 |
4.4 身份认证服务
序 号 | 内容 明细 | 数 量 | 单 位 | 功能及技术参数 |
1 | 个人自助服务 | 1 | 套 | 1、要求个人自助服务中心主要面向学校内的最终用户,包括所有学生、教师和工作人员。身份自助服务可满足用户对自己帐号信息和密码信息的维护需求,包括账号激活、账号登录、个人密码修改、个人资料修改、个人账号安全设置功能。 2、要求支持密码找回功能,要求支持密保问题回答找回、手机验证码找回和邮箱找回。 3、用户可以维护修改自己的信息,包括办公室地点、办公电话、手机号、邮箱地址,并可将这些数据再同步到数据中心。 4、系统需支持用户查询各类认证记录,包括当前登录记录、 帐号认证记录、密码维护记录、应用访问记录。 |
2 | 登录页功能配 置 | 1 | 套 | 1、提供定制化 PC 端及移动端的自适应登录页。 2、要求管理员可单独配置 PC 端及移动端登录页面的名称、学校门户名称、学校门户链接、学校 logo、标签名称和标签图标、设置登录页面的显示,其中标签名称可设置学校的简称, |
要求支持根据用户在学校的职务、角色和职责,精细划分并统一管理不同应用系统的访问权限。确保数据安全的同时,也满足用户在不同业务场景下的个性化需求。采用高级加密算法和技术,确保用户认证过程的安全性,有效防止未经授权的访问,提高系统的整体安全性。具体要求如下:
标签图标可设置成学校的 logo,管理员可根据需要添加调整美化登录页面。管理员可通过配置登录背景图可单独修改登录 页面的背景图片,并设置登录页底部版权信息显示。 | ||||
3 | 多元登录 | 1 | 套 | 1、用于学校对学生、教师和其他人员的数字化身份的登录验证。支持帐号和密码进行认证登录方式。 2、要求能在有短信网关支持的前提下,提供基于短信的动态码登录方式。 3、要求提供包括但不限于微信、QQ 二维码扫码登录方式。 4、要求提供生物识别,包括但不限于如人脸、指纹。 |
4 | 多因子认证 | 1 | 套 | 1、要求提供多因子认证(也可称双因素认证)安全策略。即:利用一种结合两种或两种以上验证因素来进行用户身份认证的方法。管理员可维护该功能,支持管理员启动或启停、维护 不同认证顺序等。 |
5 | 单点登录 | 1 | 套 | 1、用户在访问多个已接入统一身份认证的相互信任的应用系统时,支持用户一次登录后在不同系统之间漫游而不需要再次 输入密码。 |
6 | 用户管理 | 1 | 套 | 1、平台需提供完善的用户管理模块,包括帐号的新增、发放、维护、注销管理,旨在帮助管理员完成全校身份帐号数据的增加、删除、修改、过期设置、变更生命周期以及锁定/解锁等操作。 2、系统允许针对不同的用户来源创建至少三种生命周期,包括未入校、在校、离校三个状态。系统应能自动创建对应生命周期的用户组。同时应能对生命周期设置有效期,在有效期到期后,自动转换生命周期状态。 3、需支持管理员对全校用户身份帐号数据的增加、删除、修改、过期设置、休眠、锁定、冻结等操作。在进行导入用户操作时,可实现拥有多账号的用户自动绑定,无需管理员手工干预,系统自动判定导入账号是否归属同一人,若为同一人不同 阶段账号,则系统自动创建自然人,同时完成账号绑定。 |
7 | 账号发放 | 1 | 套 | 1、要求系统提供两种帐号发放的方式,分别为设置默认密码和密码激活方式。管理员可以根据使用需求选择启用何种方式进行帐号发放。 2、要求默认密码方式支持设为固定的密码组合。 3、要求密码激活流程包括身份验证、信息校验、绑定手机、设置密保问题、设置密码、激活完成六部分,可在账号激活配置中调整激活步骤,在进行信息校验过程中与系统中用户信息进行比对,只有该用户为系统中存在的“未激活”用户才能进行激活流程。 4、在账号激活过程中完成用户的手机号码、邮箱等基础信息 的绑定,为后续找回密码,人员匹配功能提供数据支撑。 |
8 | 账号管理 | 1 | 套 | 1、账号密码重置。管理员可重置用户密码,重置后的密码可通过短信、微信通知等方式(管理员可选择通知方式)告知用户密码。 2、账号休眠 2.1 账号自动休眠。要求对于一定时间不使用的账号,可以设置其空置时间,并自动休眠。 2.2 休眠账号管理。要求对计入休眠状态的账号可查看休眠时长,解除休眠状态,也可以手动把休眠账号进行冻结,冻结后账号则无法正常登录,需解除冻结才能登录。 2.3 休眠账号自动锁定和自动冻结。要求当账号长时间未登录可根据冻结天数和锁定天数进行自动冻结和自动锁定,账号则会从休眠状态进入冻结和锁定状态。 2.4 休眠白名单。要求管理员可添加账号到休眠白名单中,使这些账号不会进行休眠状态。 3、账号锁定 3.1 账号自动锁定。要求对于连续输入多次错误密码的账号可进行账号锁定,账号锁定后则无法登录成功。账号锁定后可设置具体时长自动解锁,也可以设置用户通过找回密码功能实现 |
解除账号锁定。 3.2 锁定账号管理。要求对进入锁定状态的账号可查看账号锁定时间,预计解锁时间和锁定原因,锁定账号可由管理员进行手动解除锁定。显示预计解锁时间的账号则会在到达解锁时间时自动解除锁定。 3.3 锁定白名单。要求管理员可添加账号到锁定白名单中,使这些账号不会进行锁定状态。 4、账号冻结 4.1 冻结状态。要求管理员可以直接在组织机构中修改账号状态为冻结,账号在休眠到达设置天数后也会自动进入冻结状态,也可以在休眠账号列表中直接冻结账号。 4.2 冻结账号管理。要求对进入冻结状态的账号可查看账号冻结时间和冻结原因,冻结账号可由管理员进行手动解除冻结。 4.3 冻结白名单。要求管理员可添加账号到冻结白名单中,使 这些账号不会进行冻结状态。 | ||||
9 | 账号安全管理 | 1 | 套 | 1、系统需支持按照用户会话数、IP 数去判定某个会话是否为异常会话并触发帐号冻结机制,管理员可配置触发冻结的阈值以及冻结时长。 2、系统需支持根据同一天多次登录成功\登录失败判定某个帐号是否为恶意登录行为并触发帐号冻结机制,管理员可配置触发冻结的阈值以及冻结时长。 3、系统需支持异常应用的管理功能,可配置异常应用判定规则。 4、恶意登录管理:系统应支持帐号恶意登录的锁定功能,并可通过短信或微信通知等方式提醒用户,确保帐号安全。 5、系统需提供系统安全运行看板,管理员可按照不同时间段,查询系统登录信息,包括尝试登录次数、成功登录次数、失败登录次数、拦截恶意登录,并提供相关的趋势变化图。 |
10 | 应用 管理 | 1 | 套 | 1、提供校内身份类型组的管理功能,用于区分用户的身份类 型,为校内应用提供资源级授权。 |
11 | 管理工具 | 1 | 套 | 1、需支持将身份认证系统内的通讯录数据自动同步到企业微信/钉钉,同步内容需包括组织机构及人员信息。在组织机构发生人员异动后,需支持对企业微信/钉钉通讯录进行人员同步。 2、平台需提供统一的管理工具,方便对用户与组织、日志与审计、移动端适配以及使用分析的相关功能进行支撑。 3、日志中心需支持查看用户操作记录、用户认证记录、管理员操作记录,支持按照认证帐号、操作时间段等条件查询用户认证记录;支持按照操作者、操作对象、操作 IP、IP 所在地址、操作时间段查询用户操作记录;支持按照管理员帐号、登录 IP、IP 所在地址、操作时间段查询管理员操作日志。 4、应用认证分析,支持一段时间或者快捷查询今日、昨日、近 7 天、近 30 天、近 90 天的应用认证次数排名,以柱状图的 方式由高到低排列展示排名前 10 的应用;提供应用认证次数列表,按照认证次数由高到低的顺序逐行展示认证应用。 5、帐号变动分析,支持一段时间,或者快捷查询近 7 天、近 30 天、近 90 天的帐号变动情况,以柱状图的方式展示查询期间帐号变动情况,对于每日新增次数、修改次数、删除次数采用不同颜色的柱状体进行展示。 |
12 | 开放能力 | 1 | 套 | 1、所提供的认证接口均适用于 PC 端和移动端的认证,实现一次接入,多端复用。 2、展示各类接口的信息,支持接入、删除等管理操作,将系统中所有开放接口在同一出口向用户提供,可以下载接口文档按照接口文档中的对接方式和对接要求进行接口对接。 3、支持查看接口授权情况、使用情况、被调用日志等操作。 |
13 | 跨平 台与 | 1 | 套 | 1、可以支持跨平台和各种开发语言的应用系统接入平台,如 目前学校各类应用系统所使用的 ASP、.NET、JAVA、PHP、 |
协议支持 | Python、Perl、Ruby、uPorta 等多种开发语言;平台需使用 CAS5.3 或以上版本认证内核,支持的标准至少包括 CAS 1.0、 CAS2.0、CAS3.0、LDAP。 2、需支持 OAuth2.0 协议,支持 OAuth 开放服务,可向第三方提供 OAuth2.0 接口,方便第三方使用 OAuth 开放协议来获取服务,包括 OAuth 应用注册和 OAuth 服务管理。未注册的应用不允许授权。 3、需支持 FIDO 协议,能将支持该协议的设备、浏览器的用户生物信息与个人帐号信息绑定,面向用户提供管理页面,让用户在个人自助中心可自行绑定设备,需支持利用个人生物信息进行登录服务。 4、需支持 SMAL2.0 认证协议,支持 RESTful 认证服务,支持 使用 WebHook 扩展系统功能。 | |||
14 | 认证对接要求 | 1 | 套 | 1、本次至少完成现有第三方系统的对接,实现学校现有已对接系统正常运行,并负责现有第三方平台对接的费用。 2、系统需开放第三方认证接口,支持主流开发语言,且支持 https 协议。 |
5、对接服务
5.1 接口要求
本平台作为一个开放的平台,要求提供统一、规范的接口及对应的说明文档,相关接口包括但不限于待办接口、消息接口、资讯接口、日程接口、身份认证接口,便于后期建设的项目进行对接。投标人需在投标文件中进行承诺并加盖公章。
5.2 数据对接要求
所需要的基本数据及需要学校其他系统提供的各类数据,一律以标准数据访问接口方式从学校数据中心(中台)获取;系统所产生的所有数据归学校所有均须对学校开放,须永久免费提供用于数据采集和数据交换的对外接口,支持通过多种方式与学校数据中心(中台)对接,能够按照学校数据标准将数据归档至数据中心(中台)。满足学校实时数据集成的需求,按照学校确定的对接实现方式,提供各种实时对接支持,提供详尽数据字典,开放数据库日志,提供数据库、日
志等读权限账号。验收前须按学校要求完成所有数据对接工作,并在未来随着学校数据中心(中台)升级、改版等需要免费升级或重新对接。投标人需在投标文件中进行承诺并加盖公章。
5.3 应用对接要求
融合门户(移动、PC)实现与学校现有 VPN 的对接,实现内网应用在公网上无感知使用,使师生在校外便捷使用融合门户相关应用,极大地提升用户体验。
完成现有统一身份认证平台、数字化校园门户的历史数据平稳迁移。
由中标方负责我校数字化校园、统一身份认证平台中现有第三方系统对接的费用。投标人需在投标文件中进行承诺并加盖公章。
5.4 其他要求
服务期内免费数据对接、免费纠错性系统升级。 6、实施要求
为确保本项目的顺利推进与实施,需要提供明确的实施计划。要求方案内容包括组织架构与职责、实施阶段与过程、项目管理、项目实施安全、项目测试方案等方面。具体要求如下:
6.1 交付时间要求
合同签订后 4 个月,完成第一阶段建设内容,第一阶段建设内容如下:
序号 | 功能模块 | 内容明细 |
1 | 基础支撑服务 | 用户管理服务 |
2 | 组织架构服务 | |
3 | ||
4 | 数据同步服务 | |
5 | 数据开放服务 | |
6 | 能力开放平台 | |
7 | 融合服务门户 | 融合门户展板 |
8 | 一网通办门户 | |
9 | 一网统管门户 | |
10 | 一网畅学门户 | |
11 | 统一待办中心 |
12 | 统一日程中心 | |
13 | 统一消息中心 | |
14 | 统一资讯中心 | |
15 | 统一应用中心 | |
16 | 用户信息服务 | |
17 | 移动支撑服务 | 移动门户实现融合门户 PC 端展示内容在移动端的展示。 1、移动门户需支持企业微信、个人微信小程序的访问,建设统一的微门户作为移动端唯一入口,且实现学校其它业务系统直接与移动门户对接,不需再与企业微信等进行对接。同时移动门户功能调整、界面调整等配置完后实时更新,不需要经过腾讯审核。 2、移动门户须与 PC 端门户风格匹配,统一用户的使用习惯。 3、移动门户的待办、消息的展示逻辑与 PC 门户保持一致,展示数据也保持一致。方便用户及时接收消息、快速查看和处理待办事项,确保工作的连续性和一致性。 4、移动门户须跟 PC 端在一个端进行管理,包括模板、展示内容、权限管理、页面配置等功能,在管理端调整 完之后页面同步更新。 |
18 | 身份认证服务 | 个人自助服务 |
20 | 登录页功能配置 | |
21 | 单点登录 | |
22 | 多元登录 |
23 | 用户管理 | |
24 | 账号发放 | |
25 | 账号管理 | |
26 | 应用管理 | |
27 | 管理工具 | |
28 | 跨平台与协议支持 | |
29 | 认证对接要求(OA 办公、办事大厅、财务系统、教务系统、科研系统、外部邮件、一表通、数据中台、webvpn、 会议系统、一卡通系统、职教云) |
合同签订 12 个月,完成第二阶段建设内容,第二阶段建设内容如下:
序号 | 功能模块 | 内容明细 |
1 | 融合门户服务 | 通讯录 |
2 | 角色门户分类 | |
3 | 效能数据分析 | |
4 | 移动支撑服务 | 细化移动门户建设内容,包括专题服务、热门服务与应用、最新服务与应用、最近使用、推荐服务与应用、服务与应用分类、办理统计、服务与应 用导航等多个功能。 |
5 | 身份认证服务 | 账号安全管理 |
6 | 开放能力 | |
7 | 认证对接要求(学工系统、学生成长平台、教师发展、专业与课程整改、课程平台、双高建设项目管理系统、上网自助、大数据画像、人事系统、 图书馆) | |
8 | 针对第一阶段建设内容的运行情况进行优化整改 |
合同签订 24 个月,完成第三阶段建设内容,第三阶段建设内容如下:
序号 | 功能模块 | 内容明细 |
1 | 身份认证服务 | 多因子认证 |
2 | 认证对接要求(安全出入系统、房产系统、图书馆系统、实验实训教学智能平台、非机动车系统、化工虚仿平 台、化工实验平台) | |
3 | 针对第二阶段建设内容的运行情况进行优化整改 |
6.2 实施方案
该项目规模较大,系统需求复杂,涉及部门、环节多,为了保证实施过程顺利有序,投标人必须做出详尽的实施方案,主要内容应包括以下几个方面:
6.2.1 组织架构与职责
(1)描述项目成员的组成,以及成员的职责。
(2)提供项目经理一人,负责全程跟踪项目的开发与实施,直至该项目验收。该项目经理应具备高校数字化校园基础平台及应用系统(基础平台、门户平台、身份认证平台等)项目成功开发实施经验,并在项目中承担项目经理职务。
(3)项目组其他实施人员应满足项目开发和实施的需要,项目组成人员应不少于 4 人,有两个及以上数字化校园开发和实施经验。
(4)项目实施期内,至少 1 人驻场,驻场人员要求有同类项目实施经验一年及以上。
(5)投标人需梳理学校现有系统及部署情况,后续提供合理的迁移及实施计划。
6.2.2 实施阶段与过程
描述各个实施阶段的工作范围、内容、人力投入、过程、责任、交付成果等。基于本项目为学校信息化建设的重点支撑,投标方的项目实施计划及过程进
度管控能力是项目成败的关键,因此需要投标方提供或开发针对项目的详细进度计划管理工具软件或系统,对详细进度计划涉及的功能模块、任务、时间节点、人员进行精细化管理,且支持开放给采购人使用,方便双方项目团队成员以工程
项目为基础,对项目实施计划及项目计划任务执行情况进行跟踪及反馈,对项目实施过程中出现的问题及其处理过程进行完整记录,并可对于项目交付物统一管理,项目汇报规范,交付过程项目团队响应和解决及计划完成有效监控,使项目交付过程面向校方全程开放。软件应至少包含以下内容:
1、可查看项目的当前状态、校内所有项目问题及投诉的实时处理进展、以及每一项目的建设周期、关系人、进度任务、问题、投诉、配置库等信息;
2、应支持记录项目实施中的日报、周报、月报等工作过程,在实施人员填写完成后,用户可以直接查看,还可对工作记录进行批注,提高信息透明度;
6.2.3 项目管理要求
投标方必须提出对项目的建设进行科学严格的管理方案与措施,保证项目全面顺利实施。
6.2.4 项目配置管理
在项目的建设过程中以及交付使用后,会产生大量文档和程序,如:需求分析说明、设计说明、可执行码、用户手册、测试用例、测试结果等技术性文档以及合同、计划、会议记录、报告等管理文档,而且文档的版本在不断变迁和修改中,势必产生一个庞大、动态的信息集合。因此,必须建设相应的配置管理系统,通过一系列技术、方法和手段来维护产品的历史,鉴别和定位产品独有的版本,在产品开发和发布阶段控制变化,制定规范的配置管理工作计划和流程,沟通交流配置管理工作情况,从而使管理制度化、有效减少重复性工作、保证产品的质量和效率和系统的后续升级和维护。
6.2.5 项目管理规范和手段
根据项目的实施方案,在实施过程中,为了保证用户方、开发方等各方能够对项目建设实施进行监控,及时发现和解决的问题,必须建立相应的项目管理规范,包括项目执行监控流程、执行监控的方法、执行监控的责任等,使管理和监控工作流程化、规范化,管理和监控工作责任明确。
6.2.6 项目管理控制
项目的管理控制包含多个方面:项目范围、风险、进度、质量、变更管理控制,贯穿项目开发建设的始终,必须做到对项目建设范围准确定义,一旦范围发生变更,要有相应的变更控制和应对措施。
6.2.7 项目实施安全
项目实施安全是对项目风险从识别到分析到应对措施的一个过程,包括风险识别、风险量化、风险对策、风险对策实施控制四个方面。项目在实施过程中会出项各种各样的风险,必须做到充分、有效识别风险,应对风险和控制风险,在项目实施之初必须制定风险预测和规避风险的对策。
6.3 验收要求
6.3.1 系统开发、部署、调试完成后,采购单位组织验收。系统验收的基本条件是:
①全面完成系统的设计、开发、测试和集成工作,系统安装调试,并进行相关的配置和系统优化的调试,达到功能、性能、使用等方面的要求;
②完成系统部署实施并上线试运行;
③用户对系统的使用方式基本满意,确实方便了用户,提高了用户的效率,达到了系统的设计目标;
④系统试运行稳定,上线试运行后确保不会影响业务部门的正常工作,并出具试运行报告;
⑤完成实施过程中所有文档的提交(技术文档:包括项目开发中的各种技术文档,如包括第三方组件的开发技术文档、数据库连接方式、数据库配置文档、数据字典、常见问题手册、用户操作手册以及系统培训资料。管理文档:包括项目推进中的一些工作文档,如,需求规格说明书、概要设计说明书、测试文档、实施文档、用户使用手册、计划、报告、讨论纲要、会议记录、版本管理、变更记录。)。成交供应商在验收前 10 天提供一份详细的验收方案,经采购单位认可后执行。
供应商完成所有建设工作,系统试运行正常,按采购单位要求提供所有建设文档后,由采购单位组织项目验收,验收通过后系统正式上线运行。
6.3.2 项目竣工时,除提交上述相关文档、成果外,还须提供完整的平台安装、部署、测试环境、应用环境等相关文档;当软件发生升级、调整时,须提供更新的版本。
7、运维要求
7.1 运维功能要求
在系统进行初次部署、交付和后期的服务售后运维过程中,需要提供相关运维服务,尽量提高安全性、便捷性和全面性。
(1)DNS 枚举功能:要求能够通过谷歌或者字典文件猜测可能存在的域名,并对一个网段进行反向查询,可启用递归查询,可设置 WHOIS 请求之间的时间延迟;可允许用户指定输出位置。
(2)SNM 枚举:要求能够使用 GETNEXT 请求,查询指定的所有 OID 树信息。要求能够获取目标主机的系统信息(主机名、操作系统类型及架构);设备 ID号、类型和状态、文件系统类型;获取用户账户信息;获取进程信息,如进程 ID、进程名和进程类型等;获取网络信息,如 TTL 值、TCP 段和数据元等。
(3)指纹识别:要求工具通过进行分析目标主机发出的数据包,对主机上的操作系统进行鉴别,主要识别的信息:包括操作系统类型、端口、是否运行于防火墙之后、是否运行于 NAT 模式、是否运行于负载均衡模式、远程系统已启动时间、远程系统的 DSL 和 ISP 信息等。
(4)漏洞扫描:要求能够对主机安全情况进行扫描,要求能够展示扫描到的信息数,扫描任务名称、状态、策略、目标主机和时间等。要求使用不同颜色标识漏洞的严重性。
( 5 ) 弱口令检查工具: 要求实现应用程序协议的弱口令检查, 如 Ldap-cramd5、SMB、RDP、TELNET、SSH 等应用协议,也可指定端口进行测试,支持通过文件进行批量目标测试。测试工具可加载自定义的弱口令字典。
(6)自动化漏洞验证工具:要求能提供了多种用户接口,包括终端、命令行和图形化界面等,要求能够提供内置截图和录屏工具。
(7)社会工程:要求具备社工测试工具,能够模拟常见社会工程,常见包括:鱼叉式网络钓鱼攻击、网站攻击向量、传染性媒体、群发邮件攻击、基于 Arduino 的攻击向量、SMS 欺骗攻击向量、无线接入点攻击向、QRCode 生成器攻击向量、Powershell 攻击向量等。
(8)二进制:要求能够对给定的二进制映像中搜索嵌入式文件和可执行代码。在扫描时要求支持设置包含过滤、排除过滤条件;要求具备比较功能,能够以不同颜色,标识相同部分、不同部分、部分不同部分。
(9)要求具备数据库安全检测工具,并全面支持平台对应的数据库,如
MySQL,Oracle 等。
(10)为了方便在特殊环境下使用,要求脱离外设键盘鼠标等,也可完成对本设备的所有操作,包括:内容输入、各模块工具参数的配置、IP 地址配置等。
(11)为了能够在测试分析以及鉴定时,进行相关资料获取,并进行快速记录。
(12)为了能够在实际运维过程中快速开展工作,要求本工具平台具备物理的快捷按键,通过该快捷按键能够实现对当前内容的一键打印。
7.2 运维工具要求
运维人员在运维检测时,需要配备专业化的、集软硬一体化的平台运维工具箱做以运维检测支撑。
(1)软硬件一体化产品,要求采用专用硬件架构,不接受改造产品。
(2)运维工具磁盘要求 SSD,空间不小于 100G、内存不小于 4G.
(3)运维工具要求 100/1000M 自适应电口不少于 4 个、HDMI 输出接口不少于 2 个,标准 VGA 接口不少于 2 个,UART 接口不少于 2 个,GPIO 接口不少于 1个。USB2.0 接口不少于 2 个,USB3.0 接口于不少于 2 个。标配 3.5mm 音频输入输出。
(4)要求集成显示屏,不小于 10 寸,1920*1080 分辨率。
(5)要求集成热敏打印机。 8、交付物要求
在本项目的开发过程中和交付使用后,各个阶段都会有各种成果和文档资料。这些成果和文档资料对所开发系统的维护和持续发展起着非常重大的作用。因此,要求将全面、规范的成果和文档资料交付给学校。同时,成果和文档资料必须符 合软件工程的相关要求。要交付的成果和文档资料主要包括以下部分:
(1)软件部署:招标文件中所涉及的功能需求需要正常运行,且部署在招标文件中指定位置。
(2)技术文档:包括项目开发中的各种技术文档,如包括第三方组件的开发技术文档、数据库连接方式、数据库配置文档、数据字典、用户操作手册以及系统培训资料。
(3)管理文档:包括项目推进中的一些工作文档,如,计划、报告、讨论
纲要、会议记录、版本管理、变更记录。
(4)交付的所有成果应包括成果的电子化版本。 9、培训要求
本项目要求提供线下使用操作培训,确保使用人员可独立自主运用系统能力。能够针对至少系统管理员、业务部门、普通教师三种角色分类别进行针对性培训。
要求投标文件中提供明确的培训方案,要求方案内容包括但不限于培训目的、培训次数、培训类别、培训方式、培训对象、培训对象及内容、培训场地、培训 时间等方面。
10、售后要求
要求投标文件中提供明确的售后服务方案,要求方案内容包括但不限于交货期、质保期、服务内容、技术支持、售后服务策略、售后服务管理制度、服务升级等方面。
10.1 售后服务内容
投标单位需具备远程网络支持服务及热线电话、简单问题和故障 6 小时内解
决,复杂问题 12 小时内解决、如遇软件系统严重故障并不能通过远程服务进行
解决的,须安排工程师于 24 小时内到现场提供技术支持服务直至问题和故障排除,48 小时内确保正常运行。
(1)系统免费质保期为项目验收后三年,免费质保期后的运维费用另行计算。
(2)合同履行期限:合同签订生效后的 24 个月完成系统的开发和部署,并开始上线运行。
(3)服务周期内对软件系统提供及时响应及修订。
(4)服务工作需符合国家网络安全、数据安全相关法律法规的要求,承诺不泄露校方数据,并承担违反上述法律法规要求的全部责任。
(5)项目部署后由投标方提出申请后进行项目验收。
10.2 售后服务保障能力
提供自系统验收之日起三年免费质保和版本升级服务;
须明确服务响应级别,并出具详细的方案和事件升级策略;须提供多种服务受理通道,包括线上、电话、邮件等;
须提供详细的线上服务流程说明,线上报修须能够做到问题登记、问题处理、加急处理,常见问题案例库,消息通知等。
要求在服务响应过程中,须有运营专员参与,全程跟踪服务过程,协调解决服务过程中的问题,须在方案中说明运营保障内容,提供详细服务方案;
须提供本项目服务团队组织说明,包含项目成员和职责。
10.3 其他售后服务
BUG 处理:如投标人交付的业务系统存在 BUG,投标人须提供修正与消缺服务,如有修复 BUG 的补丁,应提供升级服务。
故障处理:如投标人交付的系统上线运行时,出现问题导致业务中断时,投标方应对故障进行处理。由于非计划掉电导致系统故障时,投标方应配合系统恢复。由于系统资源不足导致系统故障时,投标方应配合学校系统恢复。由于硬件故障时,投标方应在学校数据还原后,配合学校系统恢复。
运行支持:投标方应对系统运行过程中系统管理员及业务管理员的问题提供解答和问题解决跟踪。
在项目质保期内,因为软件系统本身原因导致系统不可用,投标方应全程跟踪解决,确保问题快速解决,因为操作系统、服务器、网络设备及其他硬件设备导致系统不可用时,投标人应配合招标人排查故障,提供解决方法供招标人选择,配合招标人解决问题。
成交供应商派往采购人现场的人员,应具有较高的业务素质,现场解决问题时,不得无故拖延或推迟,应为采购人提供最佳的服务。
成交供应商必须无偿向采购人提供系统运行初期的技术培训及质保期内的运行技术服务。
10.4 质保服务到期后,要求每年服务费不得高于中标金额的 10%。
附件 2:拟配备人员清单
序号 | 姓名 | 年龄 | 本项目职责 | 人员证书名称 |
1 | 滕爱驰 | 26 | 岗位:项目经理 职责:项目策划与执行管理、团队协调与沟通、质量和风险管理 | 信息系统项目管理师证书(高级)、智能化系统集成项目 经理(高级) |
2 | 范恒宾 | 29 | 岗位:系统分析规划 职责:需求分析、系统设计、系统开发与测试、技术支持与维护 | 系统分析师、高级网络信息安全工程师、信息系统运维管理 工程师 |
3 | 鲍 妍 | 27 | 岗位:报表及数据分析开发工程师 职责:数据报表开发与维护、数 据分析与挖掘、数据平台与工具优化 | 大数据分析师(高级) |
4 | 许 迪 | 26 | 岗位:测试工程师 职责:制定测试计划与用例、执行测试与缺陷跟踪、测试环境搭建与维护 | 软件测试技术(高级) |
5 | 徐晨曦 | 30 | 岗位:开发负责人兼系统架构设计 职责:技术架构与团队领导、项目管理和进度控制、代码审查与 质量保证 | 系统架构设计师(高级) |
6 | 赵 勇 | 24 | 岗位:后端开发工程师 职责:系统设计与开发、性能优化与数据管理、协作与集成 | / |
7 | 盛 炎 | 29 | 岗位:后端开发工程师兼数据库系统管理 职责:系统设计与开发、性能优 化与数据管理、协作与集成 | 数据库系统工程师 (高级) |
8 | 叶 露 | 32 | 岗位:后端开发工程师 职责:系统设计与开发、性能优化与数据管理、协作与集成 | / |
9 | 吴 雨 | 27 | 岗位:后端开发工程师职责: 系统设计与开发、性能优化与数 据管理、协作与集成 | / |
10 | 吴林辉 | 27 | 岗位:前端开发工程师 职责:界面开发与交互实现、框架与库的应用、与后端集成与调 | / |
试 | ||||
11 | 湛志成 | 28 | 岗位:前端开发工程师职责: 界面开发与交互实现、框架与库 的应用、与后端集成与调试 | / |
12 | 张 瑶 | 28 | 岗位:UI 设计负责人 职责:设计策略与视觉指导、用户体验优化、跨部门协作与管理 | / |
13 | 陆 凯 | 25 | 岗位:UI 设计工程师 职责:界面创意与实现、交互设计与用户体验优化、技术集成与创新 | / |
14 | 居 鹏 | 27 | 岗位:UI 设计工程师 职责:界面创意与实现、交互设计与用户体验优化、技术集成与创新 | / |
15 | 刘紫怡 | 24 | 岗位:实施工程师 职责:项目部署与配置、客户培训与支持、项目管理与协调 | / |
16 | 贾正宇 | 23 | 岗位:实施工程师 职责:项目部署与配置、客户培训与支持、项目管理与协调 | / |
17 | 徐 毅 | 35 | 岗位:实施工程师职责: 项目部署与配置、 客户培训与 支持、项目管理与协调 | / |
18 | 罗 洋 | 26 | 岗位:实施工程师 职责:项目部署与配置、客户培训与支持、项目管理与协调 | / |
19 | 孙凯瑞 | 27 | 岗位:测试工程师 职责:制定测试计划与用例、执行测试与缺陷跟踪、测试环境搭建与维护 | / |
20 | 方正阳 | 26 | 岗位:测试工程师 职责:制定测试计划与用例、执行测试与缺陷跟踪、测试环境搭建与维护 | / |
附件 3、安全承诺函
扬州工业职业技术学院手机融合门户建设项目数据安全厂商承诺函
校方:扬州工业职业技术学院信息中心(以下简称甲方)
厂商:师创教育软件研究院(江苏)有限公司(以下简称乙方)
鉴于扬州工业职业技术学院融合门户建设项目涉及校方的核心业务和敏感 数据,为保证信息安全相关事宜,乙方根据《中华人民共和国网络安全法》、《中华人民共和国政府采购法》和其他相关法律、法规的规定,并按照公正、平等、自愿、诚实信用的原则,同意按照以下条款和条件,做出数据安全承诺。
一、保密数据的范围
(一)保密数据是指校方提供给乙方的与数据中心项目相关的信息化设备、误施、系统等产生的所有数据,包括数据库信息、数据信息等。
(二)双方基于业务数据,分析、统计得出的衍生数据,校方拥有衍生数据的所有权,校方可授权乙方合法开发衍生数据的深度价值.
二、保密数据的保存和使用
(一)双方有权保存和使用必要的保密数据,以便其履行在数据中心项目中所承担的责任与义务。
(二)双方有权使用保密数据对与数据中心项目及其事物相关的索赔、诉讼、司法程序及指控进行抗辩,或者对与数据中心项目及其事物相关的传唤、传票或其他法律程序做出答复。
(三)乙方从校方获取的数据享有受限的使用权限,仅限于在与扬州工业职业技术学院信息中心所签订项目内使用,不得在其他项目或透露到校外使用。
三、双方责任与义务
(一)校方为保密数据的提供方,乙方为接受方,乙方在抽取、治理、使用、管理数据信息的过程中负有保密义务,承担保密责任,未经校方书面许可,乙方不得以任何形式、载体传播保密数据。
(二)未经校方书面授权同意,乙方不得向任何第三方(包括且不限于新闻界人士、数据中心项目涉及的其他企业、广告公司、客户、校外等)公开或披露任
何保密数据,或以其他方式使用保密数据。
双方也须促使各自项目执行人员不向任何第三方(包括但不限于新闻界人士、数据中心项目涉及的其他企业、广告公司、客户、校外等)公开或披露任何保密 资料或以其他方式使用保密资料。
(三)乙方必须将保密数据的接触范围严格限制在数据中心项目实施范围内。 (四)乙方使用校方保密数据,必须建立健全的使用机制和安全保护机制,采
用有效的保密措施。
(五)未经校方书面许可,乙方不得擅自丢弃或擅自处理任何保密数据。
(六)如双方终止合作,校方提出书面要求,乙方应在五个工作日返还其控制的全部保密数据.包含或体现了保密数据的所有文件、数据库密码等,无法返还的应在双方监督下销毁。
(七)校方发现保密数据出现泄露的情况,必须第一时间通知乙方,乙方须承担所有相应责任,并赔偿校方由此造成的损失。
(八)乙方不得私自对学校数据进行修改删除。
四、违约责任与争议解决
(一)若乙方违反承诺函规定导致保密数据泄露或有泄雾的可能,经校方书面下达整改通知,乙方未采取有效整改措施的,校方有权单方面终止与乙方的合作,并停止履行相关义务。
(二)若因乙方过失导致保密数据泄雾的,乙方应当赔偿校方的实际损失,校方保留向扬州市人民法院起诉乙方的权利。
(三)凡因本承诺函引起的或与本承诺函有关内容产生的任何争议,双方友好协商解决。协商不成时,双方均有权向扬州仲裁委员会提起仲裁解决。
四、其他事项
(一)未经另一方同意,任一方不得转让其在本承诺函下的全部或部分权力。 (二)双方若有未尽事宜,可另行协商签订补充承诺函。
(三)本承诺函经乙方加盖公章后正式生效,对各方均有法律约束力。本承诺函一式捌份,校方陆份,乙方执贰份,具有同等法律效力。
49