招标
黑龙江旅游职业技术学院应用软件场内外询价需求公告
金额
90万元
项目地址
黑龙江省
发布时间
2023/08/23
公告摘要
公告正文
项目名称: 黑龙江旅游职业技术学院应用软件场内外询价
项目编号: DZJJ23082310371120
项目基本信息
采购单位:黑龙江旅游职业技术学院 报价截止时间:2023-08-26 09:00:00 项目预算(元):900000.00 联系人:宋岩 送货地点:黑龙江省哈尔滨市南岗区学府路315号黑龙江旅游职业技术学院 到货时间:合同签订后7个日历日到货 签约时间:成交公告发布后5个工作日内签署合同 仅面向中小企业:否
售后服务要求
售后服务网点: 当地售后服务网点
免费维修质保期: 3年 电话支持响应要求: 7*24小时
售后上门服务年限: 3年
售后上门服务时限: 接到报修后24小时
踏勘需求
踏勘地点: 踏勘时间:
采购产品需求清单
项目编号: DZJJ23082310371120
项目基本信息
采购单位:黑龙江旅游职业技术学院 报价截止时间:2023-08-26 09:00:00 项目预算(元):900000.00 联系人:宋岩 送货地点:黑龙江省哈尔滨市南岗区学府路315号黑龙江旅游职业技术学院 到货时间:合同签订后7个日历日到货 签约时间:成交公告发布后5个工作日内签署合同 仅面向中小企业:否
售后服务要求
售后服务网点: 当地售后服务网点
免费维修质保期: 3年 电话支持响应要求: 7*24小时
售后上门服务年限: 3年
售后上门服务时限: 接到报修后24小时
踏勘需求
踏勘地点: 踏勘时间:
采购产品需求清单
序号 | 商品分类 | 产品名称 | 参考品牌 | 参考型号 | 计量单位 | 采购数量 | 产地要求 | 现货要求 | 原装正品要求 | 技术指标 |
1 | 应用软件 | 融合门户 轻量化服务 | 金智 | 无 | 套 | 1 | 中国 | 是 | 是 | 1项目背景 1.1技术路线 1)本次项目建设的平台可运行于Linux、Unix、Windows等高安全性操作系统。开发技术应采用J2EE标准、组件技术及在数据交换上对XML的支持,使系统功能最优化,同时将整体系统内部在技术上的相互依赖性减至最低。 2)本次项目建设的平台要求采用B/S结构,采用Java编程语言和服务器端Java技术进行开发,且必须基于Oracle 11g或以上版本。 3)采用面向对象的组件技术,着重于开发构成应用程序“业务对象”的可重复使用的组件,利用这些组件顺利地建立分布式应用程序。 4)应用程序开发与运行结构要基于统一的技术开发平台的三层架构,即Web服务器、应用支撑服务器和数据库服务器。 5)能完成跨业务部门的业务流程和相对应的细颗粒度的分级授权体系。 6)系统必须支持负载均衡,支持动态监测负载状况,自动对可用资源进行并发检测,调整和分配等功能。 7)▲为保证系统运行的稳定性与安全性,本次项目建设的平台应自带中间件以满足项目需要,无需学校另行采购。 8)▲需支持国产操作系统和国产数据库,并提供适配报告,加盖公章。 1.2安全要求 1)认证授权:保证用户的合法性和用户使用信息资源的权力,避免内部敏感信息泄漏和服务所提供的信息资源被非法访问,造成严重的安全事件。 2)信息保密:充分利用密码技术,对于需要保密的信息,采用密码技术进行加解密处理,防止信息的非授权泄漏,确保涉密信息在产生、存储、传递和处理过程中的保密。 3)数据完整性:建立数据完整性检验机制,保证收发双方数据的一致性,防止信息被非授权修改。 4)审计:记录应用日志,对事件进行分析,并能提供预警信息。 5)数据备份:利用数据库的备份功能将建设的平台和系统数据备份到指定的服务器或存储系统上。 6)要求投标人从物理安全、网络安全、系统安全、应用软件安全、用户安全、数据安全等几个方面提出配套的安全体系完善方案,以便防范安全风险。 7)▲投标人所投产品,需符合国家等保三级要求,提供专业机构检测报告并加盖公章 2本期建设需求 2.1首页 平台应支持通过首页预览服务总体运行情况,至少需包括:待处理事项,校内组织机构,用户情况,应用情况,接口情况,服务器状态,操作日志,产品更新记录。 2.2应用管理 应用管理作为校内服务应用的权威发布中心,负责为校内应用提供信息维护、发布注册、授权使用、统一协议配置、消息待办预集成、应用内接口授权、应用下服务配置、应用访问日志等功能,统一发布管理,并打通PC门户、移动H5门户。 应用接入 需支持手工创建和快捷创建2种方式完成应用的接入,基本信息主要包括应用名称、业务域、访问地址、应用描述、应用图标。应用接入到系统后,可以进一步配置该应用所对接的认证协议参数,并进行应用授权。 需支持当用户授权为多个用户组时,可配置打开服务时是否需选择对应用户组。 应用详情 系统需提供应用详情页用于展示和应用关联的详情界面,包含应用的基本信息、应用的相关操作以及应用配置菜单列表,如:服务、消息、待办、接口、回调等。 需提供多种授权维度和授权颗粒度,支持根据组织机构、域及用户组、用户三种进行授权,同时,也可以对各维度的各级节点或单独人员进行独立授权。 需支持针对每个应用维护相关的认证协议,需可在应用详情页面直观查询并手动启停。 需支持在应用下添加多个不同的服务,服务类型包括:手工、接入、集成接入。手工接入应用,需支持服务查看详情、配置授权和编辑服务;集成接入服务,仅支持服务查看详情。 需支持配置消息模版、消息优先级及消息通道,并支持接入待办。 需支持平台调用第三方系统接口达到数据通知的功能。需支持HTTPS协议,同时检验证书的有效性;需支持国密和非国密的算法进行加密。 2.3管理工具 平台需提供统一的管理工具,方便对用户与组织、日志与审计、移动端适配以及使用分析的相关功能进行支撑。 2.3.1门户与内容 投标方需提供统一的门户与内容管理模块,所有操作在一体化管控台完成,包括展示方案管理、服务分类设置、个人数据集合管理、资讯聚合管理、消息中心、待办中心管理、日程聚合管理、意见反馈管理、搜索管理、应用服务评价管理等功能,具体要求如下: 展示方案管理 需支持通过可视化的方式对展示样式的模板、卡片、布局、主题色进行配置,需支持维护多个不同的展示样式并在需要时进行切换。 需支持启用多个站点的展示模式,需支持按站点配置不同的站点路由,实现多站点页面独立网址访问。 ▲需支持一键生成小程序功能,直接配置好的H5展示方案可一键生成对应的微信及钉钉小程序代码,以方便上传至第三方开放平台使用。 服务分类 需支持按服务分类划分,支持创建3级分类,可在二级/三级分类中添加服务(一级分类不可添加服务)。支持可通过搜索服务名称、筛选服务归属的应用,快捷找出需要设置分类的服务。 个人数据聚合 ▲需支持个人数据聚合管理,用于提供门户个人数据卡片的数据来源。列表展示数据标题、主要信息、次要信息、数据来源方式、启停状态、缓存时长。支持创建个人数据,支持对个人数据对编辑、搜索、排序、授权以及删除。 新建个人数据时候,需支持配置是否为个人信息。若选择“是”,原有标题、主要信息、次要信息、图标字段去除,且数据来源方式只支持JSON接口、外部数据库方式;如果选否,则按照之前的逻辑。 资讯聚合 需支持资讯聚合的配置功能,需支持手动添加频道并配置频道数据源,数据源抓取方式支持:外部数据库、页面抓取、RSS。 待办中心 需提供待办中心功能,方便聚合校级所有待办中心数据内容,需支持面向普通用户、处理业务的老师以及业务系统开发者解决任务的接入、集中展示、查看、跳转等问题支持待办任务的聚合。 日程聚合 系统应提供日程聚合功能以解决以聚合展示学校课表信息、会议信息、活动信息等公共日历的事件信息以及个人信息的日程事件信息。需支持外部数据库和插件类的方式聚合日程信息。 意见反馈 需提供意见反馈管理功能,主要用于维护管理意见反馈数据,列表展示意见标题、意见内容、反馈时间、反馈人、意见是否回复。需支持搜索和查看意见反馈详情。需支持回复反馈内容,只允许流转一次,可对单条反馈内容进行多次回复。 搜索管理 系统应提供管理门户搜索内容及辅助搜索能力的配置功能,需提供预置的采集内容分组,同时也提供自建渠道。需支持按照分组呈现搜索关联信息,并应支持对分组内容进行启停以及手工同步。 需支持通过对各分组项下的内容维护后,设置检索项,从而让参数可以作为检索项被前台用户搜索。 需支持同义词维护功能,搜索过程中基于同义词进行判断相关搜索结果,系统应自带同义词词库,同时也应支持用户手工维护本校特有同义词关联内容。 应用服务评价管理 需提供应用服务评价管理功能,包括服务评价人次、平均评分;应可针对评价详情,进行隐藏操作。 2.3.2日志与审计 1、需支持查看管理员操作日志,操作者姓名、用户名、操作者IP、操作时间、操作内容、调用结果,支持搜索和查看管理员日志详情; 2、需支持接口调用日志,包括APP ID、接口地址、接口类型、调用时间、调用者IP、耗时(ms)、调用结果。支持搜索接口调用日志。 2.3.3使用分析 门户使用分析 需支持查看PC/H5门户的总体使用情况,提供门户访问分析、内容使用分析、用户行为分析进行可视化分析,帮助用户发现门户使用价值及使用中的问题。 消息使用分析 需支持消息中心数据运行监控看板功能,可以看见消息发送的总体概况,应用消息和通道消息的发送情况以及发送消息的时间段分析,消息阅读和应用使用情况的分析。 2.4系统配置 2.4.1公共配置 平台需提供相关公共能力的配置模块,支持对学校标识、消息通道管理、外部数据库连接管理、敏感词管理进行统一配置,方便平台整体管理风格一致。 消息通道 需支持通过可视化的方式配置相关通道参数以及流量的自定义配置,消息通道至少支持短信通道、邮件通道、App通道等通道。 需可同时配置包括全局、短信、邮件、APP(钉钉、微信服务号、今日校园、微信企业号、消息总线)等多种消息发送方式。同时允许管理员配置消息发送间隔,以及单个用户每天被发送信息的上限次数。 消息模板 需支持配置短信模板,支持验证码、短信通知、推广短信三种模式,支持通过变量替换实现个性短信定制。 敏感词管理 面对高校愈发严格的舆情管理,增加敏感词限制,以便门户业务上消息、意见反馈、事项评价、服务评价内容的合规展示。平台需预置的敏感词内容入库,且内容可被删除修改。 敏感词涉及两种使用策略: 禁发类:生效后,不允许提交包含敏感词的内容,并弹窗提示; 隐藏类:生效后,可允许提交包含敏感词的内容,但提交的内容以星号的方式展示。 2.4.2高级配置 管控台授权 通过管控台授权,超级管理员可以基于用户管理、应用管理、组织管理、安全性管理等管控台的大部分功能按照需求分配给二级管理角色。实现用户、应用、组织等内容的二级管理功能,需支持对敏感信息配置查看权限。 域管理 “域”用于定义二级管理的范围,管理员可在此创建或者编辑所需要用于二级管理的域。创建后的域可以在创建应用、创建用户组的时候被选择,选择之后应用或用户组会自动加入该域,纳入域的应用或用户组会根据该域的管理员授权提供二级管理功能。 插件管理 需支持插件管理功能,插件列表,包括插件名称、插件代码、功能模块、插件类型、插件来源、当前使用版本、启停状态、最近更新时间(当有版本更新需进行提示,重启后再消失该提示)。需支持插件启用/停用、卸载、更换当前版本。 其他 1、消息中心 消息设置:支持发送次数设置(不限制/统一类型次数/自定义类型次数)、重试时间设置(消息最大重试时间、重试间隔时间、添加间隔时间等)。 消息总线:直接调用消息总线的restful接口给用户发送消息 数据覆盖导入:支持导入消息数据。 2、待办中心 配置待办中心过期时间,默认是30天,0天则为没有过期时间。需支持待办定时提醒开关,开启后,配置发送消息时间、间隔时间、消息标题、消息内容、消息类型配置。需支持待办定时补偿,开启后,配置定时补偿开始时间、定制补偿频率。 3、多语言支持 可在该选项卡设置系统支持的语言,默认语言为中文且不可修改,管理员可以在这里控制是否开启多语言切换。开启后,登录页与对应前台门户内容将会支持多语切换,管控台本身不支持多语言。 4、系统任务管理 需支持查看系统任务列表,包括任务名称、任务处理类、上次/下次执行时间和任务状态,支持立即执行任务。 产品版本管理 需支持用户查看已安装产品的当前运行版本、最新版本和发布时间,可查看历史版本列表和产品服务信息。 多语言翻译管理 用于可视化管理翻译内容,需支持按照不同模块配置对应功能类型翻译内容。 2.5消息中心 前端展现 门户前台需提供前端消息展现卡片,需支持对所有消息的查看、搜索、类型过滤,可设置全部已读,设置标旗等。当设置全部已读时,不能对必读消息进行设置,即不能忽略必读消息。 必读消息提醒 需支持必读消息提醒功能,当必读消息发送之后,若用户一直未读此消息,将会触发提醒规则,可配置规则(提醒通道、每天提醒时间、提醒模板),待发送提醒用户(根据应用分类的未读消息列表)。 一网通办支撑套件,提供高校一网通办运营所需的软件工具,包括事项管理中心、事项与流程运营效率看板,帮助学校建立校级服务治理机制,提升服务质量、优化服务效率,最终实现校务服务的科学治理。 2.6事项管理中心 用于管理前台对应服务事项内容的维护,支持用户自主维护事项字段内容;用户可维护不同服务对象的配置,实现不同人员看到与其类型相关的服务事项内容。 向高校的门户网站提供服务事项的所有内容数据,支持提供从事项信息设置、事项创建/编辑、关联用户组、启用/停用的全生命周期管理过程。 服务事项管理 需支持查看已创建的服务事项,并可根据自定义字段创建服务事项; 需支持通过服务事项名称关键字搜索; 需支持通过已配置且已关联服务事项的服务对象、责任部门、服务主题进行下拉筛选; 需支持通过是否关联服务进行筛选; 需支持通过服务事项状态进行筛选 需按照服务事项名称、服务对象、责任部门、服务主题、是否关联服务、是否第三方、最近修改时间、填写进度、启停状态、操作(编辑/启停/删除)内容展示服务事项列表 服务事项评价管理 1、服务事项评价查询 需支持按服务事项、服务对象、责任部门、服务主题筛选; 需支持评价结果的隐藏处理。 2、查看评价 需通过服务事项列表中某一条事项点击查看评价展开,可查看某条服务事项评价的具体内容; 评价分数为四项:服务态度、信息完整度、办事进度、整体满意度,评价总分为前四项平均分,最高为五分(5.0) 评价内容列表支持按照全部、好评、差评筛选查看,其中好评为三分及三分以上,差评为三分以下; 评价内容展示评价人名称、评价时间、四项评价分数。 服务事项排序 管理员可通过已配置好的服务分类、责任部门内容,针对已有的服务事项进行排序;用于用户在前台根据不同的主题分类、部门分类筛选下查看的服务事项排序规则配置; 三张清单管理 1、责任清单维护 需支持按照“部门配置”中的部门树配置职责内容,同时支持搜索查询部门名称;部门树支持展示该部门下配置了多少个职责数量; 2、审批&服务清单查询 需支持按照“部门配置”中的部门树查询内容,同时支持搜索查询部门名称; 需点击部门可查看该部门下的清单内容,支持按照服务事项名称、清单类型、办理类型查询; 服务事项配置 1、分类配置 管理员可通过配置分类,为不同服务事项进行分组管理;用户可在前台门户通过关联服务事项的分类内容进行筛选查询服务事项; 服务事项分类支持最多可添加三级;同级别内支持上下排序; 分类列表支持添加、编辑、删除分类内容,可根据不同分类纬度下进行分类名称关键字搜索; 支持按照分类名称、图标类型(字体图标、PNG图标、不需要图标)新建一级分类; 支持按照分类名称、一级分类选择的图标类型来新建二/三级分类; 2、服务事项详情配置 用户可以配置新建服务事项时的填写字段信息,用于生成办事指南展示给前台用户查看,分为基本信息与独立模块部分,系统出库将会包含预置信息部分。 3、服务对象配置 管理员可通过关联组织机构、用户组、用户、游客配置服务对象,使用户在前台门户可以快速定位到与自己相关的内容,并针对不同的对象进行不同内容的推荐相关内容; 列表展示服务对象名称及单条服务对象对应的配置信息; 支持对单条服务对象进行关联、编辑、删除操作,并可对服务对象内容进行排序;其中管理员可通过关联组织机构、用户组、用户、游客配置服务对象; 4、部门配置 用于维护服务事项基本信息内服务部门及责任部门内容;管理员可通过管控台提供的组织机构树中选择相应部门。 授权管理 用于管理维护系统管理员、服务事项管理员; 系统管理员:可在授权范围内使用事项管理中心的菜单; 服务事项管理员:使用授权部门范围内的服务事项管理、服务事项评价查询、服务事项排序;服务事项管理员需设置事项管理的部门范围,可选择一个或多个部门。 2.7事项审批流程 ▲需提供事项上架、下降、变更时的流程审核服务,各业务部门可以通过该功能自助完成上架、变更、删除部门负责事项,相关人员审核完毕后,可面向用户呈现。 功能需包括:服务事项名称、服务对象、责任部门、服务所属主题、是否关联服务、最近修改时间、填写进度、事项状态等,并可根据服务事项名称、服务对象、责任部门、服务主题多维度统计查询。 管理端可以查看事项申请的发起时间、审核时间、审核状态,审核者等数据。 2.8前端展示(融合门户) 对校内各类信息和应用系统进行整合,支撑多主题PC门户、移动H5门户和门户小程序构建,为用户提供统一的访问入口;基于API网关提供预置的日程、待办、消息、第三方电子签章的能力开放,简化异构系统集成工作,实现校园信息系统的深度融合,面向全校师生提供一体化、一站式、个性化信息服务。 2.8.1门户PC版 系统应支持学校按自己的实际需求通过卡片及展示模板的组合构建符合自己需求的门户,其中模板应不仅是简单的颜色变换,而是整体结构、布局方式的不同。 2.8.2门户移动版 系统应支持通过移动端浏览器输入和PC门户一致的地址时,直接呈现符合移动布局的门户界面,而非只是简单的PC门户页面缩放。 系统应支持集成到企业微信、钉钉、微信公众号。 系统应支持PC和移动门户在同一个页面上进行展示样式的修改和管理。 2.8.3多级主题门户 平台应支持针对业务管理部门、二级学院等有特定需求的部门设定可独立访问的主题门户体系,如:学工门户等,需支持通过输入不同的URL地址访问,并基于统一管理后台进行管理,包括使用的模板、页面布局、卡片排布等,平台同时也应支持对不同的主题门户设置独立管理人员,方便对对应主题门户的用户、应用、页面布局以及用户访问权限等内容进行管理。 应支持针对站点管理员的具体权限进行管理,至少包含用户管理员、应用管理员、只读管理员、认证管理几个分类权限。 2.8.4标准模板 产品出库时需提供至少五套标准模板,其中至少2套要支持Pc+移动双适配。▲各套模板间不得仅仅只是简单的颜色变更,应体现出明显的风格差异。 2.8.5标准卡片包 平台需支持提供丰富的标准内容卡片库,供学校选择使用来支撑信息门户内容展示,卡片适配的终端包含PC端、移动端; 主要包含服务与事项类、待办与任务类、内容与资讯类3类共计43张不同的卡片内容(PC与移动卡片功效一致的情况下记为一张卡片): 服务与事项类 卡片名称 适配终端 全部服务 PC端+移动端 最近使用服务 PC端+移动端 我收藏的服务 PC端+移动端 推荐服务 PC端+移动端 最新服务 PC端 热门服务 PC端 业务直通车 PC端+移动端 全部事项 PC端 最近使用事项 PC端 我收藏的事项 PC端+移动端 推荐事项 PC端+移动端 最新事项 PC端 热门事项 PC端 事项分类 PC端+移动端 事项分类详情 PC端+移动端 事项详情 PC端+移动端 事项统计 PC端+移动端 审批清单 PC端 服务清单 PC端 责任清单 PC端 待办与任务类 卡片名称 适配终端 待办 PC端+移动端 我的申请 PC端+移动端 待办任务 PC端+移动端 已办任务 PC端+移动端 我的办理进度 PC端 办理统计 PC端+移动端 消息中心 PC端 我的申请列表 PC端+移动端 待办任务列表 PC端+移动端 已办任务列表 PC端+移动端 我的办件 PC端 内容与资讯类 卡片名称 适配终端 新闻通知公告 PC端+移动端 新闻详情 PC端+移动端 搜索结果 PC端+移动端 富文本 PC端 我的日程 PC端 校历 PC端 个人数据 PC端+移动端 意见反馈 PC端+移动端 新闻列表 PC端+移动端 链接导航 PC端+移动端 轮播图 PC端+移动端 日程详情 PC端 ▲需支持拖拽方式对现有展示页面的卡片布局进行调整,同时需支持将多个卡片放在一个容器内进行集中呈现。 2.8.6服务推荐 优化服务推荐方式,在原有手工推荐的基础上,提供基于智能算法的服务推荐,支持按照应用使用情况、排名情况、使用用户角色等权重进行计算,并在合适的业务周期进行服务推荐,投标人应提供详细的服务推荐算法说明。 2.9流程服务 需提供不少于50个的流程服务构建,需要配合我校梳理流程服务模块,也可在成熟的已配置流程服务模型中选择,部署过程中只需要导入流程服务配置模型后简单调整后即可上线使用。[50个流程] 3其他要求 3.1工程实施服务要求 3.1.1时间进度要求 本次项目须严格按工期部署完成,并达到采购人的要求。投标方需要在投标文件中给出预实施工期进度表。采购人要求签订合同后3个月内完成项目建设工作。 3.1.2实施方案 该项目规模较大,系统需求复杂,涉及部门、环节多,为了保证实施过程顺利有序,投标人必须作出详尽慎密的设计方案和实施方案,以交付学校使用,主要内容应包括以下几个方面: 3.1.2.1组织架构与职责 1)描述项目成员的组成,以及成员的职责。 2)提供项目经理一人,负责全程跟踪项目的开发与实施,直至该项目验收,并保证现场工作时间3个月以上。 描述各个实施阶段的工作范围、内容、人力投入、过程、责任、交付成果等。 3.1.2.3项目管理要求 投标方必须提出针对本项目的科学严格的管理方案与措施,保证项目全面顺利实施。 3.1.2.4项目配置管理 在项目的建设过程中以及交付使用后,会产生大量文档和程序,如:需求分析说明、设计说明、可执行程序以及软件定制开发部分的源代码、用户手册、测试用例、测试结果等技术性文档以及合同、计划、会议记录、报告等管理文档。 由于文档的版本在不断变迁和修改中,势必产生一个庞大、动态的信息集合。因此,必须建设相应的配置管理系统,通过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的版本,以对在产品开发和发布阶段的软件变化进行控制,通过制定规范的配置管理工作计划和流程,沟通交流配置管理工作情况,从而使管理制度化、有效减少重复性工作、保证产品的质量和效率和系统的后续升级和维护。 3.1.2.5项目管理规范和手段 根据项目的实施方案,在实施过程中,为了保证用户方、开发方等各方能够对项目建设实施进行监控,及时发现和解决的问题,必须建立相应的项目管理规范,包括项目执行监控流程、执行监控的方法、执行监控的责任等,使管理和监控工作流程化、规范化,管理和监控工作责任明确。 3.1.2.6项目管理控制 项目的管理控制包含多个方面:项目范围、风险、进度、质量、变更管理控制,应贯穿项目开发建设的始终,必须做到对项目建设范围准确定义,一旦范围发生变更,要有相应地变更控制和应对措施。 3.1.2.7风险管理 项目风险管理是识别和分析项目风险及采取应对措施的一个过程,包括风险识别、风险量化、风险对策、风险对策实施控制四个方面。项目在实施过程中会出项各种各样的风险,必须做到充分、有效识别风险,应对风险和控制风险,在项目实施之初必须制定风险预测和规避风险的对策。 3.1.3实施过程管控工具要求 基于本项目为学校信息化建设的重点支撑,投标方的项目实施计划及过程进度管控能力是项目成败的关键,因此需要投标方提供或开发针对项目的详细进度计划管理工具软件或系统,对详细进度计划涉及的功能模块、任务、时间节点、人员进行精细化管理,且支持开放给采购人使用,方便双方项目团队成员以工程项目为基础,对项目实施计划及项目计划任务执行情况进行跟踪及反馈,对项目实施过程中出现的问题及其处理过程进行完整记录,并可对于项目交付物统一管理,项目汇报规范,交付过程项目团队响应和解决及计划完成有效监控,使项目交付过程面向校方全程开放。软件应至少包含以下内容: 1、▲应提供以学校领导为视角的项目综合看板,可查看本学校内所有项目的当前状态、校内所有项目问题及投诉的实时处理进展、以及每一项目的建设周期、干系人、进度任务、问题、投诉、配置库等信息; 2、应提供以业务老师为视角的项目信息管理,可查看个人负责和参与的所有项目,以及每一项目的建设周期、干系人、进度任务、问题、投诉、配置库等信息; 3、▲支持对对实施进度及实施任务执行情况追踪,可以新建任务、添加任务执行过程、完成任务已经任务完成确认等,可集中管理该项目下所有产品的实施进度任务,包含里程碑任务、工程任务、客户任务以及个人任务等; 4、▲应支持记录项目实施中的日报、周报、月报等工作过程,在实施人员填写完成后,用户可以直接查看,还可对工作记录进行批注,提高信息透明度; 5、对于项目中出现的重大问题,用户可以直接通过平台进行投诉,提交投诉后,投标方公司的专业运营团队进行跟踪处理,受理投诉内容,并及时反馈解决进度及解决方案,直至校方满意并主动关闭投诉为止; 6、提供多种消息推送方式(站内信、邮件等),支持自定义消息接收渠道、类型、时间节点等。 3.2培训要求 1)在项目合同中将具体规定培训内容、培训时间和培训名额等。 2)投标人派出的培训教员应具有丰富的同类课程的教学经验和应用经验;所有的培训教员必须用中文授课;投标人必须为所有被培训人员提供文字资料和讲义等相关培训材料。 3)投标人应按合同规定安排培训时间和培训名额,在实施过程中,针对系统管理人员提供培训,保证培训效果,让系统管理人员都能熟练掌握系统的使用方法。 3.3验收交付要求 在本期项目的开发过程中和交付使用后,要求将各个阶段产生的全面、规范的成果和文档资料交付给采购方,而且需要提供明确的交付清单。同时,成果和文档资料必须符合软件工程的相关要求。要交付的成果和文档资料需要包括以下部分: 1、可运行的系统 2、技术文档 包括项目开发中的各种技术文档,如开发环境配置说明、软件工具清单、需求分析说明、变更说明、系统设计说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等。 3、管理文档 包括项目开发中的一些工作文档,如,计划、报告、讨论纲要、会议记录等。 3.4售后服务要求 1.投标人应具备完整的售后服务保障能力,包含(但不限于)以下服务要求: (1)须明确说明服务期限,满足招标文件要求; (2)须明确服务响应级别,并出具详细的方案和事件升级策略; (3)须提供多种服务受理通道,包括但不限于线上、电话、邮件等; (4)须提供详细的线上服务流程说明,线上报修须能够做到问题登记、问题处理、加急处理、问题关闭与评价,常见问题案例库,消息通知等。要求提供服务网站地址及各个模块的功能截图或功能演示。 (5)要求在服务响应过程中,须有运营专员参与,全程跟踪服务过程,协调解决服务过程中的问题,须在方案中说明运营保障内容,提供详细服务方案。 (6)须提供线上服务申诉通道,要求可针对服务人员、服务流程等进行投诉。须提供投诉的功能截图或演示材料。 (7)须提供本项目服务团队组织说明,包含项目成员和职责。 2.投标人应提供本次投标产品的售后服务,包含(但不限于)以下服务要求: (1)BUG处理:如投标人交付的业务系统存在BUG,投标人须提供修正与消缺服务,如有修复BUG的补丁,应提供升级服务。 (2)故障处理:如投标人交付的系统上线运行时,出现问题导致业务中断时,投标方应对故障进行限时处理。 由于非计划掉电导致系统故障时,投标方应配合系统恢复。 由于系统资源不足导致系统故障时,投标方应配合学校系统恢复。 由于硬件故障时,投标方应在学校数据还原后,配合学校系统恢复。 (3)运行支持:投标方应对系统运行过程中系统管理员及业务管理员提出的问题提供解答和问题解决跟踪。 (4)在项目质保期内,因为软件系统本身原因导致系统不可用,投标方应全程跟踪解决,确保问题快速解决,因为操作系统、服务器、网络设备及其他硬件设备导致系统不可用时,投标人应配合招标人排查故障,提供解决方法供招标人选择,配合招标人解决问题。 4.系统集成要求 1.★与数据上报平台数据对接:要求与学校数据上报平台完成对接,并提供配合书。 2.★与学工系统数据对接:要求与学校学工系统完成对接。并提供配合书。 3.★完成与我校现有国产系统、数据库的部署,要求提供国产厂商配合书。 |
返回顶部