XX大学数字校园平台及OA系统升级服务要求模板.docx
《XX大学数字校园平台及OA系统升级服务要求模板.docx》由会员分享，可在线阅读，更多相关《XX大学数字校园平台及OA系统升级服务要求模板.docx（49页珍藏版）》请在冰豆网上搜索。
XX大学数字校园平台及OA系统升级服务要求模板
山西大学数字校园平台及OA系统升级服务要求
一、商务要求
1、交货时间
自合同签订之日起60个工作日内完成运输、安装、调试、培训，达到正式上线要求。
2、交货地点
山西大学
3、付款方式
合同额分三年支付，验收合格后支付45万元，第二年、第三年分别提交当年服务运行报告和用户满意度调查报告后支付45万元/年。
4、履约保证金
（1）、本项目要求中标供应商提交履约保证金。
（2）、中标供应商在签订合同时，向采购人提交合同额5%的履约保证金。
（3）、提交履约保证金按照采购人的要求以支票、汇票、本票或者金融机构、担保机构出具的保函等非现金形式提交。
（4）、中标供应商合同主要义务履行完毕，项目合同验收合格后，履约保证金转为质量保证金，质量保证金三年后采购人无息退还。
三、服务要求
1、学校统一移动门户为企业微信，需要将OA的移动端功能对接到企业微信；新门户的通知公告、消息、待办等需和现有企业微信完全打通，各类通知与企业微信中的各类通知打通，PC门户的移动端功能需完全基于企业微信；实现现有门户数据无损迁移。
2、完成现有认证平台数据的平滑迁移，密码不变，保证我校业务稳定运行；同时按照三级等保要求对认证系统进行安全加固。
3、需集成系统包括：
办公系统（金智）、本科教务（青果）、研究生系统（金智）、网络教学、考勤系统、东航机票、网站管理（通元）、健康管理、固定资产、人事系统（金智）、我的财务、科研系统、学工系统（金智）、一卡通查询、节能减排、腾讯邮箱等。
4、完成现有2套旧数据平台数据接口的完整迁移，确保所有接口运行正常。
5、需能将旧OA系统所有公告、流程、公文、知识库等相关过程性、结果性数据和功能无损迁移到新OA系统，不得并行运行2套系统来解决。
6、任何时候，无条件配合学校完成等保、安全风险评估、漏洞补丁、安全加固等工作。
7、本次对接不包含第三方厂商系统集成所需费用，由学校协调解决，平台方不再收取集成费用；以后与平台的接口费用按照实际工作量支付，但最高不得超过5万/系统。
技术需求书
一建设目标
建设融合服务大厅，满足信息门户、办事大厅、行政办公综合性服务的需求，同时服务大厅支持面向不同人员提供个性化配置，以满足不同人员使用需求。
同时提供丰富的平台能力，能够支撑智慧校园应用接入、事项管理、智能咨询、消息推送、用户售前、接口开放、服务运行分析等业务场景。
同时给学校提供统一的后台管控中心，可便捷的进行设置前端服务大厅的内容及展示方案、平台版本维护、业务域管理、用户组管理等操作。
1、完善身份互联建设：
通过本次项目建设，在我校建成一套符合高校使用需求的校园身份互联平台，完成我校各类业务系统的身份对接，解决单点登录、用户管理、认证授权、认证审计等一系列问题。
2、实现校务服务事项数据共享：
打破信息孤岛，实现数据共享，组织数据来源部门编制校务服务数据目录，推动学校行政办公、财务管理、学生工作、教学管理、科研管理、后勤服务等各部门建立数据仓，不断充实校务服务大数据。
3、推进校务服务事项流程优化：
优化办事流程，进一步减少前置条件、精简办事材料、缩短办理时间，有效避免师生在办事过程中重复填写表单和重复提交证明。
4、提高办公管理和决策的自动化：
通过信息化的先进手段提升党政办日常工作的管理效率和服务水平，为文稿、信息、督察（一把利剑、两个拳头）三大核心业务提供综合性平台。
立足高校一网通办的需求，结合学校信息化现状，通过新建、改造以及配套相应的服务，为学校建设一网通办提供IT技术支撑。
二建设要求
1总体要求
（1）遵循统一规划、顶层设计的原则，从技术角度实现学校现有数据资源、身份认证和访问界面的集成，搭建统一的应用集成框架，支持未来应用的可持续发展，从“实现使用价值”的角度使得招标方的总体收益最大化。
（2）引入SOA服务化、组件化的成功管理思想和技术，融合现代化管理理念和流程，并根据高校的共性以及学校自身的特点，因地制宜的打造一套满足学校整体运营管理和服务的业务身份统一与认证的支持平台。
通过信息化的手段强化学校身份账号的管理能力，提升面向师生的身份账号服务水平，实现和谐发展。
（3）投标方提交的标书必须结合校方的具体需求，考虑到学校规模的可扩展性和长期可持续建设发展特性，要综合考虑当下技术的发展趋势，确保系统建设切合招标方内部的工作、管理流程和行业特性。
本次平台建设过程中，要保证平台的可持续服务能力及外部接入的开放能力。
（4）为了保证我校未来智慧校园建设的进度与可持续性，要求本次项目投标方应具有独立开发完成的软件原型产品，具备一定的成熟度，并可在现有原型基础上对我校需求进行快速响应与定制开发。
2技术路线
投标方提供的平台和系统均要求采用B/S结构，可运行于Unix、Linux、windows等高安全性操作系统。
开发技术应采用J2EE标准、组件技术及在数据交换上对XML的支持，使系统功能最优化，同时将整体系统内部在技术上的相互依赖性减至最低。
具体要求如下：
（1）平台及应用系统软件必须遵循J2EE的技术路线，采用Java编程语言和服务器端Java技术进行开发，业务应用系统和数据集成平台均必须基于主流数据库，包含oracle11g数据库等，有向国产数据库迁移的方案。
（2）采用面向对象的组件技术，着重于开发构成应用程序“业务对象”的可重复使用的组件，利用这些组件顺利地建立分布式应用程序。
（3）采用成熟的SOA架构及设计理念，保证学校内部各业务系统集成和交互过程中异构技术架构和异构数据结构集成中的稳定性和可管理性。
（4）应用程序开发与运行结构要基于统一的技术开发平台的三层架构，即Web服务器、应用支撑服务器和数据库服务器。
（5）系统必须支持负载均衡，支持动态监测负载状况，自动对可用资源进行并发检测，调整和分配等功能。
3安全要求
（1）认证授权：
保证用户的合法性和用户使用应用信息资源的权力，避免内部敏感信息泄漏和服务所提供的信息资源被非法访问，造成严重的安全事件。
要解决弱口令所存在的安全隐患，登录安全体系方面需要支持双因子认证，密码要求体系方面，可以自定义密码安全要求级别（密码复杂性要求、强制密码修改要求、密码锁定要求）。
针对原有系统中的弱口令账户，要有冻结机制，彻底杜绝弱口令技术问题。
（2）信息保密：
充分利用密码技术，对于需要保密的信息，采用密码技术进行加解密处理，防止信息的非授权泄漏，确保涉密信息在产生、存储、传递和处理过程中的保密。
（3）数据完整性：
建立数据完整性检验机制，保证收发双方数据的一致性，防止信息被非授权修改。
（4）审计：
记录应用日志，对事件进行分析，并能提供预警信息。
（5）数据备份：
利用数据库的备份功能将建设的平台和系统数据备份到指定的服务器或存储系统上。
（6）要求投标方需从物理安全、网络安全、系统安全、应用软件安全、用户安全、数据安全等几个方面提出配套的安全体系完善方案，以便防范安全风险。
三建设内容
1融合服务大厅
1.1建设目标
★融合服务大厅是师生等各类用户进入学校综合服务应用的唯一入口，建成后将为师生等各类用户提供一站式、个性化的信息及应用服务，同时也是全校的应用管理平台，是构建学校智慧校园可持续发展生态体系的重要支撑工具。
还须充分考虑当前用户的使用场景和使用习惯，提供电脑PC端入口和微信企业号\公众号入口等。
融合服务大厅实现对校内外应用创建、应用上下线、多终端发布（PC端、微信端、自助服务终端等）、业务域与授权、使用状况采集与量化评估的全生命周期管理，实现服务碎片化、管理集中化，提升应用服务平台作为一站式服务的集中承载与管理的便捷性，构建开放、灵活的智慧校园生态体系。
1.2建设内容
1.2.1线上服务大厅建设要求
1.2.1.1校园门户
为师生用户提供查看学校各类信息资讯、新闻、通知公告和系统直通车的统一门户。
●支持个性化界面
★投标方需提供多套不同主题风格的界面模板供学校选择，页面模板支持两列和三列布局，并不同尺寸、不同内容的卡片组成页面的内容，学校可根据自身的要求配置整体配色、校徽、Tab页标题、头图等内容。
门户平台需提供开放能力支持根据学校的个性化需求设计界面。
●丰富的内容卡片
★提供丰富的标准内容卡片库，供学校选择使用来支撑信息门户内容展示。
●VIS风格UI设计
按照山大VIS标识设计新门户，布局和使用习惯需要和现有旧门户布局基本一致。
●系统直通车
需支持灵活添加业务系统，并支持授权不同角色的用户，用户只能看到自己有权限的系统。
●新闻资讯聚合
需支持接口、数据库、网页抓取方式将学校公文、部门通知、校内新闻等内容集成在新的校园门户中。
●历史数据迁移
需能将旧门户系统通知公告、站内信、门户其他内容等数据无损迁移到新门户系统。
1.2.1.2办事大厅
需为学生、教职工、单位办事不同角色的用户提供按照不同的办事主题和办事部门对外提供办事服务，既包括线上可办理的信息化服务，也包括在线下办理的事项清单，让师生及游客对校内办事清单有详细的了解，包括办理部门、办理地点（地图的形式体现）、办理时间、部门电话、所需材料、常见问题等。
●首页
需包含对事项的搜索功能、整体导航，在线服务的最近使用以及办事大厅的简要统计。
●分角色目录页
需针对学生、教师、游客分别提供分角色目录页，支持按照事项主题、事项部门、标签的查找，以及对具体事项是否有在线办理的筛选。
●事项详情页
对某一事项的具体描述页面，描述内容需包含事项名称、责任部门、服务部门、前置条件、服务内容、业务周期、内容标签、办理须知、所需材料、办理时间和地点、咨询电话和常见问题等；
针对有在线办理的事项需提供“在线办理”按钮进行跳转。
●个人中心
包含用户个人在办事大厅中的办件以及意见反馈。
1.2.1.3工作台
★需为全校涉及业务管理类、行政审批类用户提供快速、方便、高效的工作页面，只显示跟自己工作相关内容，预置已经分类完成的管理服务目录，我的收藏，任务中心统一处理待办任务入口，不需要登录到各个系统中办理，提高办事效率。
1.2.1.4三张清单
需提供符合学校要求的三张清单（职责清单、审批清单、责任清单）管理后台，能够根据不同的部门填写职责、并对每个职责关联服务事项，在前台统一展示。
责任清单：
展示各部门（单位）的主要工作职责、具体工作事项以及落实、督促、检查各项工作职责的制度措施，“责任清单”比传统的“工作职责”更具体、更详细，“责任清单”中要明确各部门必须承担哪些责任、必须做哪些事情，以此可划定该部门的“职责边界”，此“边界”外的不属于该部门的权力、责任、义务。
审批清单：
展示相关部门对申报材料同时进行形式审查与实质审查的事项，经裁量权衡后，可能做出批准或不批准的事项。
服务清单：
展示相关部门只需要对于申报材料进行形式审查，若材料数量齐全、形式合规，则必须予以确认或提供有关服务的事项。
1.2.1.5我的收藏
提供应用收藏功能，用户可将自己经常需要使用的应用添加到收藏夹。
在个人中心页面有我的收藏模块，用户可以更直接方便的获取到自己收藏的应用。
1.2.1.6意见反馈
提供用户问题反应渠道，用户可填写反馈意见或建议。
为用户提供意见反应渠道，搭建用户与管理者之间的网络沟通桥梁，管理端根据获取的意见可及时做出调整并回复用户处理结果。
1.2.1.7服务评价
提供用户对服务事项、办结的流程进行满意度评价，将自己最真实的使用感受分享给其他用户、反馈给应用管理员。
用户使用应用前也可以通过查看其它用户对该应用的评价，作为应用选择的依据。
应用管理员可以查看来自用户的应用评价，为进一步优化升级应用提供参考依据。
1.2.1.8消息提醒
应用程序能调用消息中心接口，将提醒消息推送到服务大厅中分类展示，并显示消息的查看状态。
1.2.2移动H5服务大厅建设要求
支持一站式服务大厅前台使用移动端浏览器访问，内容与PC端一致，提供专门的移动端卡片和管理支撑能力，包括我的大学、办事大厅两部分内容。
支持集成到企业微信、钉钉、微信公众号。
新门户的通知公告、消息、待办等需和学校现有企业微信完全打通，各类通知与企业微信中的各类通知打通。
●我的大学
包括个人数据、校内新闻、通知公告、校内发文、待办通知、最近使用服务、通知公告、业务直通车等；
●办事大厅
用户可搜索服务事项，并可根据学生、老师、游客不同角色分类展示学校内部各个部门所提供的办事指南，办事指南包括事项名称、责任部门、服务部门、前置条件、服务内容、业务周期、内容标签、办理须知、所需材料、办理时间和地点、咨询电话和常见问题等，并可在办事指南中关联在线应用、提供咨询、评价等服务；展示个人办事详情，包括正在办件，已完成办件，待办任务，我管理的事项；提供办事大厅运行数据展示，包括当前进驻事项、可在线办理事项、当前正在办件、已完成办件、累计服务师生数。
支持企业微信、钉钉、微信公众号等移动终端对接方式。
1.2.3平台公共服务建设
移动端功能需完全基于企业微信。
1.2.4事项管理中心
1.2.4.1服务事项管理
★需支持对事项清单和三项清单进行全生命周期管理，建设学校统一事项清单库。
●事项审核
需支持校级管理部门对业务部门申报的服务事项进行审核，审核通过后，可对事项进行配置。
●事项配置
需支持管理员对审核通过的事项进行应用配置、标签配置、可能问法配置。
进行应用配置时可直接查询线上服务大厅上的所有线上服务列表，直接点击关联，无需配置其他信息。
●事项发布
事项审核完成并进行相关配置后，需支持管理员对外发布，师生可在办事大厅中查询该事项。
●事项查询
需支持事项库的多维事项查询，包括事项类型、职能部门、服务类型、起止时间等，显示各类事项的查询结果，并可以导出事项清单。
需支持服务事项字段自定义，除了产品标准提供的填写字段以外，用户还能自定义符合本校的字段并能编辑字段名称、内容显示、是否必填等。
需支持服务事项运行数据采集，采集各部门服务事项数、访问次数、用户评价、线上服务数等内容，并在运营中心做多维度统计分析。
1.2.4.2服务字典表管理
需能对服务主题和服务部门的增删配置操作，用于支撑线上服务大厅的模板前台的内容。
1.2.4.3事项管理员维护
支持针对部门指定业务管理员，用于将服务事项维护的权限下放，某个部门下的业务管理员能够对此部门为责任部门的服务事项进行维护。
1.2.4.4任务中心
各类应用服务通过任务中心对外开放接口对接任务中心，将服务内部产生的任务信息推送至任务中心，使用户能够在服务大厅统一处理待办任务、已办任务。
●待办任务
用户能够在任务中心中查询当前自己所有的待办任务，并能根据接收时间、任务来源、紧急程度、任务类型进行筛选，并能够点击单条任务跳转至对应的应用。
●已办任务
用户能够在任务中心中查询自己所有的已办任务，并能根据任务名称进行关键字搜索，以及根据处理时间、任务来源、流程状态进行筛选，可以查询到已办任务。
当前所属流程的状态以及流转记录。
针对流转记录，用户可以查看到此流程经历的每个节点名称、处理人、处理意见、处理结果、接受&处理时间以及耗时。
●我发起的
用户可以在任务中心中查看自身在所有的系统中发起的流程，能通过流程名称进行关键字搜索，并能根据发起时间范围、任务所属来源以及流程状态进行筛选；针对某个流程，用户可以点击跳转至应用内部、查看此流程的流转记录以及对当前办理人进行催办。
1.2.5应用管理中心
需支持对接入应用的多终端（PC、移动校园、微信端）发布、上架、下架管理、权限管理能力，实现一处发布多终端使用；支持对前台大厅统一管理与配置，大厅模板管理、卡片配置管理以及其他内容配置能力。
管理：
包含分配业务域、分配应用管理员、编辑、网页端和移动端应用的上线和下线设置；
配置：
配置项包括属性、授权、开放时间、维护时间。
属性中包括服务场景、服务角色、服务类别、服务方式、应用属性配置、推荐周期设置、应用可见性设置、应用详情设置。
1.2.6流程中心
1.2.6.1流程设计
为实现真正意义业务办理，投标方需提供一套遵循BPMN2.0规范的流程执行引擎和服务引擎来执行流程和流程所定义的服务。
可以执行基于BPMN2标准的业务流程模型，包括执行人工任务以及各种事务型服务。
提供流程定义与执行语言完全遵循国际标准的流程执行语言BPMN2.0。
1）采用业内通用并符合BPMN2.0标准的Activiti流程引擎
2）可视化流程设计，支持在Web页面采用拖拽方式设计流程；按照BPMN流对象与类型进行设置。
3）多种流程模式，顺序、分支、并发、子流程、条件路由、并行会签、串行会签等流程
4）多种流程操作权限，
提交：
流程提交操作
退回：
退回已办理过的节点，可以设定退回的节点范围。
追回：
在当前办理人尚未处理文件前，允许上一节点提交人员执行撤回。
转办：
允许将流程转办给其他人员。
终止：
强制终止当前流程。
催办：
可以给当前办理人员发送催办通知消息。
加签：
允许当前办理人根据需要自行增加当前办理节点的办理人员。
跳转：
执行此操作可以将当前流程实例跳转到任意办理节点。
挂起：
可以暂停、恢复当前流程实例。
5）丰富的任务节点类型
单人活动：
办理人为多人时，系统会提示选择某个人来办理；
多人并行：
办理人为多人时，同时发送给所有办理人，办理人可以不分先后进行办理；
多人顺序：
办理人为多人时，按照定义的顺序发送给办理人；
多人单一：
办理人为多人时，同时发送给所有办理人，只要有一个办理人办理了，系统就提交至下一节点；
6）多种办理人设置方式
支持按照人员、部门、用户组、岗位方式设置流程节点办理人；
7）支持多表单设置，在不同流程节点设置不同的表单；
8）可人工选择下一步分支环节，并可配置这项功能在哪个环节启用；
9）可人工选择下一步处理人，并可配置这项功能在哪个环节启用；
10）可配置判断分支条件，根据登录人的基本信息和业务字段信息，进行ANDOR布尔表达式进行逻辑判断。
11）多版本管理，支持将修改后的流程保存为新的版本，旧的版本可恢复。
12）12）需同时支持PC端和移动端。
1.2.6.2流程分析
需支持按时间统计分析各部门办件、个人办件、办件状态、业务办理情况，通过统计分析，帮助管理人员分析工作流状态，定位工作瓶颈，改进工作流程，提高工作效率。
1.2.6.3流程干预
需支持异常流程查询、干预功能，当异常流程或当前环节处理人无法处理时，服务管理员直接将流程转办、挂起或终止。
1.2.6.4流程实施
需调研学校各职能部门，对学校各类师生流程进行梳理，按学校要求在流程中心上线。
1.2.7一张表
提供师生数据一张表功能。
1.3服务要求
服务要求：
需在企业微信员工服务建立专门客服群，至少指派2名客服专员7*14小时在线解答师生使用问题。
8：
00-20：
00提问必须在2小时内做出建设性回复。
二次开发需求：
3年内平台、系统中软件，用户提出的合理性需求，需通过二次开发满足的，需要在15个工作日内无条件满足。
使用权：
软件LICENSE为终身使用，用户拥有资产处置权，乙方不得因3年内不继续购买服务而停止软件使用。
高可用性：
按多节点集群方式部署，支持硬件负载均衡和故障迁移。
2校园身份互联平台
2.1建设目标
统一身份认证管理平台应能实现身份数据的统一存储、统一管理，实现全校各类应用的单点登陆，以及各类访问与操作安全审计。
同时，还应提供便利的工具，便于系统的维护和管理。
供应商需完成现有认证平台数据的平滑迁移，密码不变，保证我校业务稳定运行。
2.2技术要求
1、标准化
必须采用基于LDAP标准的目录服务器存储身份数据，并提供身份认证。
平台需基于J2EE标准的微服务技术架构。
支持SAML，CAS,OAuth等国际标准协议。
2、可集成性
提供多种认证接口的异构支持，包括代理认证和LDAP目录服务接口。
支持多种语言的接口方式，包括Nginx反向代理、Java、Python、C#、Ruby、Node.js、PHP、go等。
为没有单点登录接口的厂商或者自研系统提供SDK。
支持Unix、Linux、Windows多种平台，完全支持跨平台的部署。
支持自定义标准协议（customprotocol）:
钉钉、腾讯等。
3、可扩展性
身份、授权、认证功能相对独立，可以灵活的与第三方产品对接。
可实现用户名/口令认证模式，手机号绑定认证，支持动态口令认证接口。
★·可支持OAuth2.0协议，支持绑定第三方授权认证方式。
IT管理员可使用指定的外部身份认证源（例如AD/LDAP）进行联合认证。
提供大并发访问下的高可用性，支持集群工作模式，具备多机热备和负载均衡的能力。
★·支持同一个域内的多个应用系统间的单点登录，具有开放的跨平台SSO实现技术。
支持学校移动app客户端的统一身份认证集成，并能支持网页端、移动端同时登录。
4、安全性
要求系统对用户登录信息进行加密传输，保证数据能在客户端与单点登录服务器之间、WEB代理与单点登录服务器之间进行安全通信，保证数据传输的安全性。
需按照三级等保要求对系统进行安全加固，并能够通过测评检测。
系统需提供用户密码加密功能，支持扩展SSHA、MD5、SHA、RC4等多种密码加密算法，加密算法不可逆，加密后数据不可被复制猜测；并可以快速扩展用户属性信息。
基于非共享Cookie的CAS认证方式，集成应用不能读到CAS域名下的安全令牌。
对用户的操作行为进行日志记录，以追溯用户的行为过失，确保数据安全。
系统支持帐号恶意登录的锁定功能，并可通过短信提醒用户，确保帐号安全。
系统支持帐号单点登录设置，确保同一时刻帐号只在一个终端登录。
需能支持二次登录的设置及异动提醒功能。
对不同的部门、应用、人员等属性按需设置相应的访问权限安全策略，提升安全性
可以和对接应用之间定期进行密钥的轮换，访问日志记录及IP黑白名单限制。
采用令牌失效机制，通过对密钥令牌的有效时长、使用次数、实时撤销等设定，有效防范中间人攻击和回放攻击。
支持人员属性信息的映射与转换。
5、高性能
可为数百个应用提供统一身份认证服务的同时保证亚秒级的认证操作时间。
对资源池连接数、滞后时间的调整（滞后时间是指在线用户多少时间不活动，此用户的资源连接就应该释放）。
可为数百个应用提供统一身份认证服务的同时保证亚秒级的认证操作时间。
★系统需支持10000用户并发进行登录操作时，平均响应时间不超过4.1秒。
需提供省级软件产品质量监督检验机构出具的检测报告复印件证明。
系统需按多节点集群方式部署，支持硬件负载均衡和故障迁移。
6、高效特性
提供灵活的同步策略配置，并通过小工具将权威数据源中新建和变更的用户身份数据同步至校园身份互联平台。
7、可管理性
集中的身份数据管理，不仅提供用户帐号的维护，还能提供便捷的批量导入等功能。
平台应提供历史事件的查询和认证会话的相关操作，建立完善的事后追溯机制。
系统具备详细的登录和访问应用的日志，可以界面查询。
2.3建设内容
2.3.1基础服务中心
2.3.1.1核心数据模型
按照学校特点和应用现状设计用户、组、权限等模型，并按照模型设计完成数据存储。
所有的用户信息应分别存放在LDAP目录服务和数据库中，通过可靠的机制完成两者的同步，用户身份信息在目录服务中以层次结构，面向对象的数据库的方式集中存储管理，从而保证身份数据的一致性和完整性，为校园各类应用提供一致的用户信息访问。
支持设置用户身份类型，方便平台和硬件平台、应用系统等通过LDAP接口的方式实现身份集成。
2.3.1.2配置中心
提供统一的配置入口，在后续节点扩展过程中，无需额外进行配置，仅需指定配
升级会员 