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

项目概况

采购服务信息列表

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