【分散采购备案单】非学历教育数智通
2026-04-30
湖北/武汉 招标采购
【分散采购备案单】非学历教育数智通
湖北/武汉-2026-04-30 00:00:00

【分散采购备案单】非学历教育数智通

发布日期:********** 浏览次数:

项目概况

项目名称 非学历教育数智通 项目编号 **************
开始时间 ********** **:** 结束时间 ********** **:**
供应商资格要求 参照《中华人民共和国政府采购法》第二十二条规定的资格条件。 预算金额(元) ******.**
采购方式 竞价

采购服务信息列表

序号 货物(服务)名称 数量 计量单位 预算单价
* 非学历教育数智通 * * *******
技术参数 编 号: 《“非学历教育数智通” 小 程 序》 招 标 要 求   目录 一、 建设目标* 二、 系统面向的用户群* 三、 功能需求分类* *.* 后台管理端需求* *.* 班主任端需求* *.* 学员端需求* 四、 技术及其他要求* *.* 技术要求* *.*.* 总体要求* *.*.* 兼容性要求* *.*.* 性能要求* *.*.* 对接要求* *.*.* 文档要求** *.*.* 安全性要求** *.*.* 维护性要求** *.* 服务要求** *.*.* 质保要求** *.*.* 故障处理要求** *.*.* 巡检要求** *.*.* 培训要求** 五、 项目工期** 六、 付款方式** 一、建设目标 “非学历教育数智通” 小程序以 “学员为中心、数据为驱动、高效为特征” 为核心,构建覆盖继续教育学院非学历教育 “报名 — 教学 — 评价 — 结业” 全流程的数字化服务体系。通过打通学员、班主任与继续教育学院管理三端协同,实现身份统一、过程留痕、数据集成与分析,解决现有管理体系分散、过程记录不足、数据无法沉淀、服务体验不统一等问题。最终达成统一服务入口、提升项目管理智能化水平、建立决策支持体系、规范管理流程、搭建可扩展架构的目标,为继续教育管理提质增效提供核心支撑,助力继续教育学院教育数字化转型。 二、系统面向的用户群 表 * 系统用户表 角色名称所属单位职责描述 学院超级管理员继续教育学院拥有系统全部权限,负责多角色分级授权、系统参数配置、数据共享管理及安全策略设置 项目负责人继续教育学院负责培训项目创建、批次管理、课程模板配置、师资分配及项目进度监控 班主任继续教育学院承担学员档案管理、考勤监控、请假审批、通知发布、学习质量追踪及数据报表导出职责 学员用户非学历教育参训人员完成注册认证、课程查看、签到考勤、请假申请、学习评价及电子证书获取等操作 学员带队主管/领导非学历教育参训人员完成学员信息查看,请假审批等 访客潜在项目客户学院项目展示,继续教育学院品牌宣传。 三、功能需求分类 *.*后台管理端需求(**端) 表 * 后台管理端功能清单表 功能模块功能描述 分级授权管理*. 支持学院超级管理员、项目负责人、班主任等多角色体系搭建,按最小权限原则分配操作权限。 *. 超级管理员可新增、变更、撤销各级用户权限,实现分域管理;项目负责人权限限定于所负责项目,班主任权限聚焦班级日常管理。 项目与课程管理*. 支持培训项目创建、批次划分、课程模板设计及教学计划制定,可灵活分配资源。 *. 课程信息维护包含课程名称、授课时间、地点、讲师信息、课件资料等,支持课程资料统一存储与访问权限控制。 *. 可设定出勤阈值与结业条件,系统自动判断学员是否达标。学员缺勤达到阈值时自动触发提醒功能。 数据统计*. 提供出勤率、项目进度等关键指标数据。 *. 支持按项目、班级、时间维度提取数据,包含学员出勤、评价等数据,支持 ***** 与 *** 格式导出。 档案管理与归档*. 培训项目、学员记录等数据自动归档,支持多条件检索与长期保存。 系统配置与运维*. 提供字段维护、代码表维护、日志监控、数据批量处理、远程备份等系统维护功能。 *. 记录用户操作日志与系统运行状态,实现问题预警与维护跟踪;支持系统运行状况、用户权限、报错信息等查询功能。 *.*班主任端需求(移动端) 表 * 班主任端功能清单表 功能模块功能描述 学员档案管理*. 查看学员基本信息、承诺签署状态、考勤记录与其他数据,支持学员信息快速检索与筛选。 考勤管理*. 实时查看签到状态与缺勤统计,支持查看未签到名单及缺勤学员列表。 *. 审批学员请假、补签申请,流程全程记录,审批结果同步更新出勤数据。 课程与通知管理*. 上传课程资料、课件与公告,支持班级群发消息推送。 *. 维护课程安排,可补充课程备注信息,同步更新至学员端课表。 学习质量追踪*. 跟踪学员课程评价数据,沉淀班级学习质量数据。 数据报表导出*. 按项目、班级、时间维度生成考勤等统计报表,支持 ***** 与 *** 格式导出。 预警与提醒机制*. 接收出勤预警、请假申请、任务截止等智能提示,及时处理相关事项。 *.*学员端需求(移动端) 表 * 学员端功能清单表 功能模块功能描述 注册与身份核验*. 支持通过手机号、微信授权或预导入名册注册登录,信息与后台自动校验绑定,确保身份唯一性。 *. 未完成身份认证的用户仅能浏览系统首页,无法查看课程详情或进行报名操作,需完成认证后方可解锁全部功能。 承诺签署与信息确认*. 在线签署安全、纪律与保密承诺书,自动生成电子存档,签署后方可参与培训相关操作。 课程与课表管理*. 实时查看课程安排、讲师信息、上课地点及签到,支持日历视图展示与课程提醒功能。 签到与考勤*. 采用二维码签到、地理位置校验、时间戳验证等多重机制,防止代签。 *. 支持课堂动态签到,缺勤后接收系统自动提醒;可查看个人出勤记录与签到状态。 请假与补签申请*. 在线提交请假理由与证明附件,系统自动推送至班主任端及带队主管/领导审批,实时查看审批进度与结果。 学习成果与电子证书*. 达到结业条件后,获取电子结业证书,支持证书查询。 消息中心*. 接收课程通知、公告、考勤提醒等消息,支持学习资源推送。 活动分享与查询*. 支持移动端查看同期参训学员名单及相关信息(按权限设置可见范围)。 个人中心*. 查看已报名项目、学习进度、出勤记录、电子证书等个人相关信息。 *. 支持修改个人联系方式等基础信息。 校园服务对接*. 与珞珈*卡对接,关联有需求的学员(部分短期学员及非短期学员)学号与校园卡账户,实现培训期间食堂就餐权限开通与余额显示功能。 *. 与校园速通门禁系统对接,自动同步学员身份信息与培训周期,配置对应校区入校及指定区域通行权限,支持门禁扫码通行。 四、技术及其他要求 *.*技术要求 *.*.*总体要求 *.架构要求 应用架构开放,采用表现层、业务逻辑层、数据层等的三层或多层分离结构基础模式; 应用采用面向对象、模块化、接口化、微服务化的设计框架,模块之间遵循高内聚、低耦合的设计原则,可重用、互操作的服务体系结构。 *.设计要求 灵活性好、可维护性高,具备组件的性能扩展能力,添加新模块和变更模块的功能。可以通过服务的编排组合来实现业务的组合,通过服务的松耦合来满足业务变化和调整,实现业务性能优化。 应用需保证高并发应用场景下的稳定性和高性能,对高峰期间的高并发访问有处理预案,首页等关键页面要能容错或降级运行,保障基本服务。 *.接口要求 将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义,它应该独立于实现服务的硬件平台、操作系统和编程语言。 程序接口和数据接口清晰,便于二次开发,为新功能模块预留接口。 遵循成熟、主流的接口开发标准及规范,支持通用的服务总线。 提供接口地址、命名空间、调用方法、参数组(包含参数类型),返回值采用****或***格式,并提供返回数据包格式描述,实现自动查询、调用、测试及管理,提供符合****规范的接口文档。 *.平台要求 优先选用国产信创或开源软件架构,各类组件、服务架构及技术层次均有共同的标准及规格,存在良好的兼容性。采用主流成熟中间件,应用及服务支持集群部署、负载均衡及故障转移。 *.移动端要求 除复杂填报等不适合移动端操作的功能外,针对其他重要功能,系统原则上应提供移动端适配界面,包含移动设备***、微信小程序、*****。 *.交互要求 软件能针对用户操作习惯调整功能设置和界面布局,实现界面友好、操作简便以及软件易用。软件界面设计应符合《武汉大学视觉形象识别系统》相关要求(参见*****://***.***.***.**/****/****.***)。移动端适配界面用户交互方式应尽量符合互联网主流移动应用用户交互风格,提供良好的移动端用户交互体验。 *.数据库要求 软件设计的数据表结构、数据字段、数据字典、范式设计必须符合武汉大学数据中心的数据标准,提供符合该标准的数据库设计文档,数据库推荐采用国产数据库。 *.*.*兼容性要求 *.服务端 支持目前主流操作系统(如*******、*****等)。 *.浏览器 支持*种及以上目前主流浏览器(如******、****、******、***浏览器、*******)。 *.移动端 微信小程序,支持当前安卓、*** 、鸿蒙等移动操作系统主流机型、版本。 *.升级要求 软件在版本升级中保证接口协议、功能不发生变化。 *.*.*性能要求 *.用户要求 软件运行支持至少******级用户量,支持****以上用户同时使用,支持***以上并发用户量,需提供压测分析报告。 *.运行要求 软件保证*×**小时运行,可用性达到**.**%,全年累计中断时间不超过***分钟。 一般的人为和外部的异常事件不会引起系统的崩溃、白屏;具有高可用性,当系统出现问题后能在较短的时间内恢复;具有数据完整性,多端操作不会引起数据的不一致。 *.性能响应要求 普通页面响应时间小于*秒,查询页面响应时间小于*秒,后台数据批处理时间应在**分钟内完成。 *.*.*对接要求 支持与学校相关系统对接,包括但不限于统一身份认证、消息平台、智慧珞珈、办事大厅、**系统和数据中心。 *.统一身份认证对接 支持与武汉大学统一身份认证平台对接实现用户认证。软件应支持从统一身份认证获取已登录用户基本信息,实现用户信息动态更新。 对接用户为使用此程序的学院超级管理员、项目负责人、班主任等校内用户。 *.消息平台对接 武汉大学统一消息平台已集成到智慧珞珈实现统一通知与待办推送。软件应支持与武汉大学统一消息平台对接,实现通知与待办消息推送。其中,仅需用户知晓的可推送通知消息,需要用户进软件交互办理的应推送待办消息。系统中用户待办变更为已办状态时,软件需向统一消息平台更新待办状态为已办。 管理人员通知公告:校内管理人员相关通知公告通过消息中心推送消息(限定学院超级管理员、项目负责人、班主任)。 学员通知公告:原则上通过站内消息推送,必要时可支持短信推送。 *.智慧珞珈应用上架 支持将软件微服务功能入口上架到智慧珞珈应用中心。提供的入口链接应能直接定位到对应功能点而无需用户额外操作完成功能导航,且该入口链接应实现统一身份认证自动登录,无需用户进行额外登录操作。 *.其他系统对接 根据建设方用户需求,部分功能如需集成到办事大厅、**系统等学校其他软件中,或相关功能需要与学校其他软件交互,应在附件一功能列表中另行约定系统对接需求。 *.数据对接 支持与武汉大学的数据平台进行数据交换,满足数据交互的功能。支持武汉大学标准平台中已包含的权威数据接入,如组织机构、人员基本信息等。利用数据中心已有数据减少用户重复填报。 与继续教育学院管理平台、学员信息系统、珞珈*卡、校园速通门禁系统、内部文档与课程资源库对接,实现数据互通与资源共享。 *.校园卡数据对接 按照学校相关规范编制学号,确保学员身份核验、办卡流程与入校权限全流程打通。 (*)身份与财务信息对接 (办卡流程) 按照学校相关要求,对接学员学号对应的基础身份信息(姓名、手机号、证件号等)与财务信息(办卡费用缴纳状态、缴费凭证等)。 (*)跨部门协同入校权限配置(使用保障) ①实现学员基础信息如学号、校园卡信息与学校数据平台的同步,确保数据一致性。 ②实现学员校园卡信息与校园速通门禁系统的对接,配置对应培训期间的入校及校区通行权限,满足学员正常参训的入校需求。 *.*.*文档要求 *.技术文档 承建方需提供相关技术文档,包含但不限于《项目建设方案》、《项目技术实施计划表》、《软件功能实施计划表》、《软件数据标准说明书》、《软件接口标准说明书》、《软件设计说明书》、《数据库设计说明书》。 *.实施文档 承建方需提供相关技术文档,包含但不限于《项目实施日志》、《需求规格说明书》、《测试报告说明书》、《用户操作手册》、《安装部署手册》、《软件培训计划》、《项目开发总结报告》、《软件试运行日志》、《软件维护日志》。 *.安全文档 承建方需提供相关安全文档,包含但不限于《信息资产安全检查表》(参见*****://**.***.***.**/****)。 *.*.*安全性要求 *.服务器安全 对于分配给软件使用的物理机或虚拟机等形式服务器资源,承建方为服务器维护的重要责任方。 承建方需及时修复服务器操作系统及重要软件组件相关安全漏洞,确保服务器安全。服务器端口按需向合理范围开放网络访问,避免端口过度开放造成安全隐患。 承建方需对服务器***、内存、硬盘、网络访问等资源使用情况进行监控,确保其占用率在合理范围内波动,避免服务器因不合理资源使用造成服务质量下降甚至中断。对服务器相关日志需实现日志轮转,至少保留半年日志,避免日志文件占用过多硬盘空间。 *.软件安全 承建方安排指定技术对接人员,主动披露承建软件已知漏洞、及时提供漏洞补丁并完成漏洞修复,反馈修复结果,配合学校进行复测和加固;承诺配合学校对承建软件进行必要的风险扫描、渗透测试、代码审计等安全检测工作,根据反馈报告完成软件漏洞修复和安全加固;协助学校根据《教育行业信息系统安全等级保护定级工作指南》,完成系统等级保护测评和整改工作。 软件自身具备网页防篡改、防注入式攻击、脚本过滤、防口令猜测、**地址访问控制等安全措施。软件采用主流鉴权方式实现接口调用认证,避免未授权接口调用。 *.用户安全 提供安全手段防止非授权用户的非法侵入、攻击,避免操作人员的越级操作。 采用分级管理模式,对不同级别用户的操作权限和数据访问范围有严格的限制,系统管理员可以根据学校情况灵活设置安全策略。 *.数据安全 杜绝数据外泄,承建方不得将数据复制到公网或开发商私有平台,不得向第三方公司、组织或个人泄露业务系统的数据和权限。 软件具备容灾能力,根据学校业务特点能够记录访问及操作日志,备份和恢复系统数据,保证软件安全稳定运行。 非必要不采集、不处理、不存储个人敏感信息。确有需要的,应按“最小够用”原则控制敏感个人信息采集、使用范围。软件应确保数据加密和脱敏传输,对敏感性数据进行加密保存,支持标准主流加密算法,对安全性要求特别高的数据需进行物理隔离。严格控制涉及敏感个人信息的数据批量导出功能权限与访问**授权。 *.安全事故分级标准 从软件的功能异常影响范围、非计划中断服务时长、数据泄露数量、漏洞处置响应情况以及在行业管理部门组织的网络攻防演练中软件被攻击造成的后果等维度,将安全事故严重性从低到高分别认定为一般、较大、重大三个级别,具体认定标准见下表。安全事故级别按严重性从高到低进行认定,符合其中任意一条标准即可认定为相应级别。 异常功能影响范围可根据软件需求和实际情况针对性调整,其他维度标准不可调整。网络攻防演练被攻击后果以组织方反馈报告为认定依据。 安全维度 事故级别一般安全事故较大安全事故重大安全事故 异常 功能 影响 范围****人及以上无法使用*小时内*~*小时*小时及以上 ****人以内无法使用*天以下*~*天**天及以上 非计划中断服务时长影响****人 及以上用户*小时内*~*小时*小时及以上 影响****人 以下用户*天内*~*天*天及以上 数据 泄露 数量个人敏感 信息****条以下****条及以上 *万条以下*万条及以上 非个人敏感信息*万条以下*万条及以上 **万条以下**万条及以上 漏洞 处置 响应 情况高危漏洞 未修复时间*个漏洞 **个工作日内*个漏洞 **个工作日内*个漏洞**个工作日内 或 *个及以上漏洞**个工作日内 中危漏洞 未修复时间*个漏洞**个工作日内 或 *个及以上漏洞**个工作日内 *个漏洞**个工作日内 或 *个及以上漏洞**个工作日内 *个漏洞**个工作日内 或 *个及以上漏洞**个工作日内 攻防演练被攻击后果服务器或软件管理员权限被攻破/*个权限以下*个权限及以上 *.*.*维护性要求 *.部署要求 业务系统与数据库需分开部署。 *.维护要求 为管理员提供丰富的系统设置和维护功能,包括用户和权限设置、字段维护、代码表维护、日志监控、数据批量处理、远程备份等,便于管理员远程对软件进行各项日常维护工作。 *.支持要求 提供*×**小时电话支持服务,软件出现异常时,需在*小时内查明原因出具详细报告,如需技术人员现场解决,则在指定时间内到达现场提供服务支持。 *.*服务要求 *.*.*质保要求 投标方在投标文件中响应(以下要求在合同中需合并到正文部分服务及质量保证条款) 本项目终验后进入免费质保期,免费质保期不少于 * 年。 在免费质保期内,响应时间应与实施期间标准一致。免费质保期结束后,售后服务费用每年不得高于本定制开发项目合同总金额的*%。 质保期内,甲方享有该版本下免费升级;若在质保期内无版本升级,乙方应提供一次免费升级服务。 质保期内,甲方数据库、外部接口、软硬件环境等发生变化时,乙方需免费配合变更。 *.*.*故障处理要求  投标方在投标文件中响应(以下要求在合同中需合并到正文部分服务及质量保证条款)   在本软件通过总体验收前,乙方受理甲方服务的渠道为①②③ (①现场处理 ②电话处理 ③远程在线处理 ④其他 ),受理时间范围为*****小时对用户要求服务的响应时间(从用户发出服务请求至乙方服务人员到达用户需服务的现场)不得超过****小时。紧急故障***小时内排除,一般故障*****小时内排除。   在本软件通过总体验收后的质保期内,乙方受理甲方服务的渠道为①②③(①驻场服务 ②电话服务 ③远程在线服务 ④其他 ),受理时间范围为*****小时*,对用户要求服务的响应时间(从用户发出服务请求至乙方服务人员到达用户需服务的现场)不得超过*****小时。紧急故障 * 小时内排除,一般故障*****小时内排除。 *.*.*日常巡检要求 本软件上线后,凡在质保期内,乙方需要提供 每*天*次的软件巡检服务。通过日常巡检,确保软件服务正常。日常巡检需重点检查以下内容:*)重要用户、授权等数据与数据中心同步后均正常,无大批量遗漏;*)平台服务正常;*)服务器***、内存、磁盘等资源使用情况在合理范围内。 承建方承诺在护网等重点时期,至少安排*名技术人员通过①②(①现场支持 ②远程支持)方式提供技术支持服务,配合学校确保软件及相关数据安全。 *.*.*培训要求 投标方在投标文件中响应(以下要求在合同中需合并到正文部分培训条款) 为保证本软件的顺利实施和正常运行,承建方必须提供技术培训,并免除所有费用(包括培训、教材、培训环境、食宿、差旅及相关费用)。培训时间由学校根据工程进度及工作需要安排,培训次数不少于*次。 培训方式和内容:提供分岗位、分模块、分层次的软件使用培训,对管理员提供深入的培训,使管理员能完全掌握软件的管理、升级、维护以及工作流程、数据报表的设计工作。 五、项目工期 本项目为定制化开发项目,所有模块和功能均以学校最终需求为准,投标人如有已成型的、功能类似的模块,可作为待开发模块的原型供学校参考,但不得以此拒绝学校提出的定制需求。 中标单位在合同签订后*个工作日内必须开始软件建设工作,**个日历日内完成所有定制化功能开发。 经甲方书面认可进入试运行阶段,试运行期为 *个月。试运行期满后经甲方书面认可进入总体验收程序。总体验收通过后进入售后服务和质保期(简称质保期)。 六、付款方式 *. 乙方对甲方需求进行详细调研,并完成第一阶段要求,乙方向甲方提出第一阶段即初步验收申请,通过后甲方支付合同总额的 **% 给乙方。 *. 乙方完成软件全部模块开发及试运行,且运行稳定,经学校认可后,进行项目整体验收,验收通过之日起**个工作日内,乙方将合同总金额的**%作为履约保证金,以支票或电汇形式提交给校方;校方收到履约保证金后**个工作日内支付合同总额的**% 。 *. 系统验收正常运行 **个月 后,校方退还履约保证金。
相关材料 “非学历教育数智通”小程序招标要求*******.****
微信客服
公众号
小程序