软件功能需求 |
序号 | 名称 | 描述 |
1.1 | 可视化分析及管理 | 分析指定当前人员信息;楼栋人员信息(图形化展示,包含折线图等);当前人员不同维度类别比例(图形化展示,包含饼状图等);当前楼内每个人员信息占比及分布(图形化展示,包含饼状图等); |
1.2 | 楼栋,分析按天或多天出入信息,可表格展示; |
2.1 | 学生基本信息分析及管理 | 个人详细信息数据,包含人员姓名、学号、学院、专业、年级,人员照片等,显示人员详细信息列表,点击可查看对应人员综合信息; |
2.2 | 支持多条件分析人员信息;如晚归,未归情况;支持快速关联人员个人基本信息情况,显示最新位置;支持搜索数据结果导出; |
2.3 | 分析个人人脸识别出入记录,个性化指定时间段;(默认 * 年) |
3.1 | 应用策略管理 | 自定义策略,对设备区域人员出入限定,自动化管理及应用,满足校方工作需求的各种快速查询和管理功能。 |
4.1 | 维护工具 | 自定义数据字段添加,支持标签设定及分组; |
5.1 | 照片自助上传 | 自助照片上传,校验及审批管理。 |
6.1 | 照片同步管理 | 提供数据标准化接口,其他系统可同步人脸识别照片库;支持以图搜图功能,可上传人脸照片由系统自动比对搜索,筛选并显示出与其相似度较高的记录照片,在显示列表中以相似度排序, (略) 记录信息; |
7.1 | 告警管理 | 支持告警级别设定,支持不同告警方式; |
7.2 | 分析人员告警信息,人员未归,晚归告警等; |
7.3 | 分析人脸识别认证记录,提供预警概览功能,显示对比昨日预警数量、并提示预警数量达到最高峰时候的日期,预警包括但不限于人员晚归、未归等情况; |
7.4 | 历史告警信息,包括人员晚归,未归等信息; |
7.5 | 支持事件关联及触发操作; |
8.1 | 日志管理 | 数据下发记录管理; |
8.2 | 人员操作及出入数据管理,可支持日志可视化查询; |
9.1 | 服务状态监控 | 支持监控服务器硬件使用率,应用流量,服务端口Web,API等; |
* .1 | 系统对接 | (略) 系统,匹配校验及获取数据; |
* .1 | 数据管理 | 提供对 (略) 理、清洗转换等功能,主要包括数据清洗、数据转换、数据加解密等。 |
* .2 | (略) 数据获取策略管理,能根据采集工具及数据源类型,配置采集参数,采集频率等。 |
* .3 | 平台的各种重要组件 (略) 的弹 (略) 署,并支持本地服务器群、私 (略) 署环境。 |
* .4 | 提供标准化数据接口,可以提供接口权限管理。 |
* .5 | 电控管理 | 支持电控管理,可查看电控联动记录,并可实时控制宿舍房间供电或断电。 |
* .6 | ▲手机端应用系统 | 至少支持手机端查询、管理、审核等功能 |
* .7 | ▲微信小程序访客管理系统 | 支持微信小程序访客管理系统,进行访客邀请、审核、下发授权 |
* .8 | ▲ (略) | 设备 (略) 、 (略) 域网络的情况下,也能正常开门,正常下发用户权限; |
门禁离线开门,支持手机APP离线、门禁设备离线均可开门; |
支持设备 (略) 、 (略) 域网络的情况下,能正常开门,也能实时授权用户权限,用户在获得对应门禁权限后,可立刻开门; |
安全性: * 维码中使用的加密算法与加密规则为国际标准加密算法,至少使用两层加密,RSA与AES加密,RSA加密秘钥长度至少有 * 位; |
(略) 于离线状态时,防止 * 维码截图。 |
软件技术参数 |
序号 | 名称 | 技术参数要求 |
1.1 | 系统结构 | 支持系统采用B/S结构架构,支持多终端(PC/移动),支持多操作系统(windows/mac/linux, ios/安卓); |
1.3 | 数据库存储方式 | 支持Hadoop分布式存储方式; |
1.4 | (略) 理方式 | 支持流 (略) 理功能,并将流式的实时数据分解到计 (略) 理; |
1.5 | 部署方式 | 能支持分布式负载均衡设计架构,支持高并发,接口支撑不受单个程序异常的影响,并提供开发者权限管理功能; |
1.6 | 架构模组编辑 | 可对底层 (略) 运维管理; |
1.7 | 文件数据存储 | (略) 数据多副本冗余存储,网络的多链路冗余技术,保证数据及存储的安全性; |
1.8 | 数据采集及计算能力 | 针对实时性要求比较高的数据,能够提供实时采集、实时计算、实时展示等功能;提供Flume或与其最新版本效能相当的日志采集系统、采用Kafka或与其最新版本效能相当的工 (略) 理, (略) 列; |
2.1 | 接口授权管理 | 可针对不同的API (略) 授权管理; |
2.2 | 数据库权限管理 | 提供数据库群组权限管理,至少提供增加、删除、修改等用户权限管理; |
2.3 | 出入管控 | 可管控出入,支 (略) I/O控制,设备区域分组及限定。 |
2.4 | 人员轨迹 | (略) 筛选,通过Echarts或AntV或能满足展示需求的图 (略) 轨迹可视化展示 |
2.5 | 设备管理 | 支持对设 (略) 状态监控,包含Web,API端口。 |
2.6 | 用户信息管理 | 可对接入的数据改写,维护,校验数据。 |
3.1 | 数据采集 | (略) 采集策略管理,能根据采集工具及数据源类型,定制采集方式,采集频率等; 可实现结构化数据采集,并可选择不同 (略) 存储; |
3.3 | 数据质量监控 | 结构化数据采集支持针对不同的业务系统的数据抽取情况整体监控, (略) 采集的表数量和每天数据采集情况; |
3.4 | 日志数据管理 | 提供包含面向日志数据采集的Flume采集工具,能满足日志数据的采集; |
3.5 | 高性能读取、缓存 | 支持搜索引擎采用ES(ElasticSearch)技术或与其最新版本效能相当的全文搜索技术;缓存使用Redis技术或与其最新版本效能相当的缓存数据库;要求提供 * 用户同时高性能并发的架构性能负荷; |
3.6 | 多系统数据同步、扩展 | (略) 现有人员管理平台数据同步,支持对同 (略) 扩展编辑; |
3.7 | 信息管理 | 提供统 * 的教师,人员信 (略) ,实现对服务流程产生的数据的统 * 管理功能; |
3.8 | 设备权限管理 | 可同步人员数据到设备并实现统 * 权限管理; |
4.1 | 数据检索 | 提供数据的高效检索及查询功能;支持通过图形化界面对数据 (略) 高效率检索; |
4.2 | 多样化数据导出 | 支持数据连接及数据集功能(支持本地Excel导出,支持MySQL,数据接口等方式连接,支持实时刷新、定时刷新、条件筛选、动态汇合、数据聚合); |
4.3 | 热力图数据可视化 | 支持点击某栋建筑,在页面呈现到该建筑的时段热力图,可实时查看该建筑的进入人数; 支持标注图、热力图两种呈现方式;支持时间轮询查询; |
4.4 | 报表数据可视化 | 显示楼宇的整体情况,包括月总结、日总结、标签和高峰期,分析内容包括总访问次数,人均访问次数,全校排名及趋势,单日访问量以及访问人员群体标签排名等信息; |
4.5 | 图表数据可视化 | 显示全校人员校内密度图以及趋势,支持选择日期、时间间隔; 显示全校人员校内人流密度分布,可知校内访问高峰地点和时间、早上活跃时间点; |
5.1 | 系统预警 | 提供基于大数据分析的人员紧急预警、未归预警、晚归预警、未离开等预警内容; |
5.2 | 预警级别 | 系统根据规则自动判断预警严重级别,预警由严重到轻微分为4个等级;并设置2种预警状态:已处理预警、未处理预警; |
5.3 | 预警数据分析 | 根据人员在校内的数据,提供实时预警人员的严重预警概览功能,显示对比昨日预警数量、环比增长率,并提示预警数量达到最高时候的日期, (略) 及时掌握预警关键信息; |
5.4 | 预警基础信息设置 | 在自定义的时间点内,若人员未回到宿舍,根据人员夜归次数来给予不同级别的夜归预警; |
5.5 | 历史预警可视化分析 | 提供历史预警趋势展示功能, (略) 预警数量; |
系统安全要求 |
序号 | 名称 | 描述 |
1 | 隐私保密 | 应用系统应严 (略) 信息安全保密协议的相关规定,确保信息安全。 |
2 | 系统安全规范 | 系统建设符 (略) 门制订的标准,对安全策略、密码与安全设备选用、网络互联、安全管理等符合我国信息安全法律法规,需完成 * 级安全指标测试。 |
3 | 系统日志 | (略) 日志和用户操作日志,系统具备日志跟踪与分析功能,记录用户帐号、操作和时间等,提供访问、修改、删除等的用户操作日志。 |
4 | 系统架构 | 应用系统应在架构、设计、编码等各方面符合可信计算的规范和要求,确保系统不存在各类已知的安全漏洞隐患,包括但不限于:SQL注入、 (略) 、任意文件或未经校验文件上传、任意文件下载、越权访问、 (略) 、应用程序错误信息或服务器信息泄露、httphost头攻击等常见漏洞;使用明文或在程序/脚本文件中写死密码;在网页源码 (略) 理逻辑等敏感信息;表单信息有效性缺少服务器端后台校验;系统留有“后门”,设计违反或者绕过安全规则的任何类型的入口和设计文档中未说明的任何模式的隐藏入口。 |
5 | 系统权限 | 系统具有完善、有效的用户角色权限控制机制,确保资源和数据的权限授权和控制粒度符合业务需求。应用用户的权限最小化,控制用户对功能、文件、数据等的访问。 |
6 | 证书 | 系统支持HTTPS,可使用HTTPS访问。 |
7 | (略) 署 | (略) 在操作系统、 (略) (略) 依赖的相关组件的安装、配置, (略) 络安全要求,不开放不必要的端口,不存在已公布或已知的漏洞或隐患。 |
8 | 系统数据存储及稳定性 | 在硬件环境满足的前提下,应用系统应满 (略) 景下并发访问和在线访问人数要求,确保并发访问响应时间符合操作要求;系统安全、稳定,保证7× (略) ;存储系统满足需求,运行稳定,易于扩充;支持负载均衡、可横向扩展;支持远程管理; |
实施技术要求 |
1 | 名称 | 描述 |
1.1 | 平台支持要求 | 架构设计遵循成熟的方法论,包 (略) 有的功能模块,并在各个层面对模块之间的关系有深入的理解。同时,提供更多相关功能模块的供应商将优先考虑。 |
1.2 | 设计功能要求 | 建设的 (略) 业内的最佳实践,并包含大量预制的功能,无 (略) 大量的定制开发。实施商须提供对软件界面优化的方案示例。 |
1.3 | 接口要求 | 在服务质保期内,向学校提供免费对接技术支持以保证后续持续升级改造 (略) 商更换情况。接口传输方式需满足且不限于Web service、API接口。 (略) 相关系统对接以获取学生的基本信息,姓名、学号、,学院、专业、年级等。系统应提供标准接口供外围系统调用获取或传递数据,并保证接口数据的完整性、 * 致性和正确性。 |
1.4 | 扩展性 | (略) 规模的扩大,管理要求的提高,系统必须具备良好的后期扩展能力,横向扩展方面支持更多的用户接入、更大的应用负荷,纵向扩展要保证技术的持续升级能力,提供更为完善后期维护服务。同时, (略) 现有人脸识别平台软件指定功能。 |
1.5 | 易操作性 | 操作简便,从实际出发,降低用 (略) 维护管理的成本。 |
1.5.1 | 界面风格 | 各模块统 * 的录入、查询等操作风 (略) 风格,可以有效减少操作人员熟悉系统的时间及增加操作便利性。 |
1.5.2 | 方便操作,操作流程合理 | a.功能菜单、 (略) 简洁易用,尽量从用户使用便捷角度出发设计系统界面,符合用户操作习惯,信息检索时可以通过输入关键字模糊查询。 |
b.能方便快捷的录入查询各种数据。 |
c.帮助文档完善,且方便调取,所有帮助文档均有关键字(词)搜索功能。 |
d.工作台应用可控制必录入项,系统能够对 (略) 控制,且有颜色或图标提示,使用户能够确保信息录入的完整性。 |
e.控制错误录入,系统能检查用户录入的字段是否符合字段标准要求。 |
f.可根据管理员设定的基本参数检查用户录入正确性。 |
1.5.3 | 易用的功能展示菜单 | a.菜单应按照常用的操作展示清晰,充分考虑用户使用习惯,便捷直观,不展示无关信息; |
b.提供必要的系统提示信息。 |
1.6 | 系统性能指标 |
1.6.1 | 操作响应速度 | a.客户端打开操作界面、保存数据等基本操作平均响应时间(除报表统计、数据导入等涉及大量数据的操作外)不超过5秒。 |
b.在线报表和图表生成时间不超过 * 秒。 |
1.6.2 | 数据导入速度 | 通过EXCEL、TXT等格式文件大批量数据,导入时间每千条不超过 * 秒。 |
1.6.3 | 并发性能 | 支持多位用户并发使用,同时达到以上性能指标。 |
1.6.4 | 稳定性能 | a.除硬件及操作系统故障外,应用服 (略) 。 |
b.系统 (略) ,不出现异常及明显的功能缺陷。 |
c.数据库 (略) ,不会出现内存不足等各种数据异常。提供关于存储空间规划、数据维护、备份/恢复等完整的数据库管理方案。 |
1.7 | 多语言支持 | 系统必须支持多语言的信息访问和存储,至少应支持简体中文和英文。用户可以根据需要灵活简便的切换。 |
1.8 | 应用对接管理 | 系统需要提供统 * 的对外接口管理功能,能够灵活的发布对外服务接口,提供学生照片、学工号、姓名等信息查询接口,并能提供接口调 (略) 日志,所有接口需要按照 (略) 提供。 |
服务质保期内, (略) 信息化建设需要,所含的标准接口均需无条件提供; (略) 提供免费对接技术支持。 |
1.9 | 系统安全指标 | 软件测试环境需要对 (略) (略) 理。 |
软件需要满足 * 级等 (略) 安全扫描后方可上线。 |
记录日志: |
a.应用服务及客户端能够记录各用户 (略) 为。 (略) (略) 有错误,包括 (略) 络错误,便于查找错误的原因。 |
b.记录日志可导出为EXCEL或txt文件,自动维护日志表,确保读写性能。如日志文件本身为文本文件,则当日志文件达到特定大小后可自动更名并归档,确保当前日志的读写性能。 |
2 | 项目组织及实施要求 |
2.1 | 实施技术要求 | 对于下述的实施技术要求,投标人应详细描述每项要求的满足程度。 |
1)系统能支持相关业务的 * 体化,数据共享,流通顺畅。 |
2)能根据系统预先定义好的工作流程,完成工作流,能够驱动业务目标的实现,实现的审批工作流可灵活配置,使系统具备良好的可维护性。 |
3) (略) 灵活的用户权限设置, (略) 良好的权限分级管理。 |
4)提供完善的操作手册,培训文档。 |
2.2 | 实施方案要求 | 本项目实施的组织 (略) 丽湖校区。项目各模块功能应覆盖前述功能需求。项目实施方案应包括但不限于以下内容: |
1)投标单位应根据校园管理信息化项目的总体要求,对业务需求的点对点应答,提出解决方案; |
2)投标单位对技术架构及实现方式的建议,包括对系统实施过程中应用环境的管理,本项目的技术规范和工具的建议,本项目的实施方法论的建议,本项目的项目基准实施计划及各阶段的交付件的建议; |
3)投标单位对本项目建议的项目组织架构及人员数量,角色,职能,现场服务时间的建议; |
4)投标单位对于项目实施中培训和知识转移的建议,技术支持和售后服务的建议;项目实施期间对我校的要求; |
5)供应商需提供产品各模块详细功能说明以及硬件配置要求和参数,并提供类似的案例情况参考; |
6)投标单位需提供完整、可行的项目实施计划:包含项目目标、范围,人员分工,进度以及项目变更策略等; |
7)投标单位应提供突发事件的应急和风险控制措施; |
8)投标单位需针对项目产品提供用户培训或相关知识转移计划; |
9)投标单位需明确源代码的开放情况; |
* )投标单位认为需补充提供的其它材料。 |
2.3 | 项目实施要求 |
2.3.1 | 项目建议书要求 | 高校管理系统的实施必然带来 * 定的组织和职能的变化,以及 * 些新的管理思路和管理模式的变化,因此项目实施过程中需要明确变更或增补内容,实施公司应在项目建议书中对于项目中的变更和增补内容提供管理办法。 |
2.3.2 | 文档要求 | 实施公司必须有标准化的文档管理制度,并在项目进程中得 (略) ;必须提供实施各阶段文档资料,包含项目计划文档、项目进度文档、周报、需求调研、分析报告、设计说明书、配置文档、开发文档、需求变更文档、测试实例、测试报告、操作手册(中英文)等所有相关的项目实施文档。 |
文档须实时更新并统 * 存储及共享。 |
对本项目中产出的文档,包括由招标 (略) (略) 资料、技术文档和信息予以保密。必须遵守保密协议,未经招标人书面许可,不得以任何形式向第 * 方透露本项目的任何内容。 |
2.3.3 | 源码管理 | 使用的软件中客户化的源代码须及时加入指定源代码服务器的指定库中。 |
| | | | | |