一、系统功能需求 *.系统工作台 (*)应用管理 ▲需提供应用系统的编辑、应用授权等操作，便于管理人员对不同应用系统进行相应管理。应用编辑时支持查看应用的版本信息、应用访问入口地址，支持修改和查看应用图标信息等。（提供证明材料） (*)工作台 需提供面向院长、副院长、专任教师的不同的工作台，包括电脑端和移动端。 待办任务：支持待办事项、已办事项、我发起的事项等信息，点击待办任务可打开具体业务进行审批处理。 提供学院相关通知公告的发布、管理。 *.我的学科指标值 展示可运用学科指标值、已运用学科指标值、学科指标值申请总值、被分配学科指标值总值、被转让学科指标值总值、转出学科指标值总值及明细。 *.学科指标计值申请 ★需根据学院学科建设发展指标体系方案开发设计学科指标申请，需支持选择不同的一级指标、二级指标、三级指标、等级类型填写对应指标项数据，需满足***余项指标项设计，如选择人才培养→教学成果奖养→国家级教学成果奖养→特等奖，则填写获奖时间、获奖等级、教学成果类型、附件等数据项。需支持将申请的学科指标值分配给其他老师。（提供承诺函） ▲附件：证明材料扫描件，支持设置每个指标项的附件上传要求，附件大小、类型、附件说明。支持****、***、图片文件在线预览，不需要额外安装插件。（提供证明材料） 保存草稿：提交人在填写信息后，可暂时保存为草稿，待后续再行提交。经审核人退回的申请，处于草稿状态，申请人可继续进行修改，之后再提交。 撤回：若下一环节尚未审核，提交人可撤回并重新编辑。 *.学科指标值审核 ▲需根据***余项不同的学科指标申请设计不同的审批流程，如某项学科指标审批流程：学科指标值属人申请，并根据选择学生类型（本科生、研究生）流转至本科生秘书审核或研究生秘书审核再流转至本科生副院长审核或研究生副院长审核，如果申请人和审核是同一个人的时候，由协管学科副院长审核确认。（提供承诺函） 同意：审核人确认成果真实有效、指标归属正确后，系统自动计算并记录学科指标值至指标值属人名下。 不同意：审核人需填写不同意理由，退回给申请教师修改或撤销。 支持查看待办、已办任务。 *.转让学科指标值 系统需支持专任教师、退休教师获得的学科指标值可以转让至本学院内其他相关专任教师，不限制接受人员。 院长有干预权限，撤回已转让的学科指标值，撤销后被转让人学科指标值减少。 *.学科指标值转让管理 系统需具备院长将申请通过的学科指标值退回的权限，将学科指标值申请直接退回至学科指标申请人，退回后已获取的学科指标值将同步减少。 *.学科指标值运用 拥有学科指标值的专任教师选择需要的指标调节事项。运用后专任教师的可运用学科指标值同步减少。 支持查看学科指标值历史运用记录。 专任教师申请运用的指标调节事项，未到截止时间可撤回，已运用指标值同步减少。 *.指标调节事项管理 院长和副院长有权限管理指标调节优化事项，管理功能如下： 新建：新建一个事项，并选择事项类型，不同类型的指标调节事项对应数据项不同。新建的事项默认是草稿状态，上架后才生效。 编辑：修改下架状态的运用事项，比如修改运用事项有效时间。 上架：上架指标调节事项 下架：下架指标调节事项。 删除：系统禁止删除已经运用过的调节事项。 *.学科指标值统计 系统需支持书记查看/导出全局学科指标情况（按时间段、按人头、按方向、勾选老师打包、按调节事项） 系统需支持院长查看/导出全局学科指标情况。 系统需支持分管副院长查看/导出分管学科指标情况。 系统需支持副书记查看/导出分管学科指标情况。 **.学科指标管理 需提供学科建设发展指标体系的新增、编辑、上架、下架管理。 ▲系统需支持管理维护***余项指标，包含指标名称、指标编码、指标层次、类型/级别、指标值属人、学科指标值、审核人、期刊会议、数据项别名、数据字段等信息。（提供证明材料） **.期刊会议数据管理 ▲需提供期刊与会议数据管理功能，以满足学科指标申请中对期刊或会议的选择需求。支持多个指标项与同一个期刊或会议建立关联，并依据指标项中的数据类型（期刊或会议）筛选相应的期刊或会议数据。（提供证明材料） **.学科指标相关文件 提供学科指标相关文件管理、下载、预览，支持****、***、图片文件在线预览，不需要额外安装插件。 **.系统管理配置 (*)流程设计 系统需支持***可视化设计流程设计，无需编写代码实现业务流程设计，系统管理员可根据业务需求配置不同的审核流程。 流程模式需支持顺序、分支、并发、子流程、条件路由、并行会签、串行会签。 流程操作权限需支持提交、退回、追回、转办、终止、催办、加签、跳转、挂起。 流程节点类型需支持单人活动、多人并行、多人顺序、多人单一几种类型。 办理人设置方式，需支持按照人员、部门、用户组、岗位方式设置流程节点办理人； 需支持在不同流程节点设置不同的表单，每个流程节点上需支持**、移动表单，系统须自动根据访问终端属性定位到**或者移动表单。 流程分支判断条件根据登录人的基本信息和业务字段信息，进行*** ** 等布尔表达式进行判断。 需支持多版本管理，需支持将修改后的流程保存为新的版本，旧的版本可恢复。 (*)数据模型配置 ▲需提供灵活自定义、可视化的数据模型配置功能，支持业务表结构调整，包括增减字段、调整字段显示名称、字段大小、字段类型、字段分组等。根据后续业务开展需要，可灵活扩充数据模型。 (*)在线部署升级 ▲需提供应用程序的在线升级部署，可及时获取到各应用程序的最新版本迭代情况，根据需要在线升级部署；可监控应用程序的当前版本情况、健康状态、操作时间等信息，有效保障应用程序运行健康。（提供证明材料） (*)运行数据统计 ▲需提供应用程序访问量统计，可统计查看某个应用程序及其子功能页面的访问量，提供应用程序访问用户数统计。（提供证明材料） **.会议室预约 (*)会议室管理 会议室管理员可以维护会议室的基本信息，所在位置、定位信息、配套设施等，同时需要设置当前会议室可开放预约的时间段，以及开放的人群（完全开放、部分开放、自定义等），支持设置预约规则，可提前预约和取消的规则。 开启/关闭预约，会议室开启后用户才能对会议室可见，关闭后将不可见，但不会对已预约的数据造成影响。 锁定会议室，若会议室因临时有更高授权的安排，可对会议室进行锁定，锁定的时间段不支持预约。 删除会议室，删除会议室会将会议室的预约记录全部取消，并发送消息通知预约人。 二维码，开启了扫码登记使用的会议室可以查看和下载二维码。 (*)会议室预约 ▲会议室预约界面需根据系统管理员、专任教师、行政教师、拔尖班教师等不同角色人员显示不同的提示信息：您未来**天还有**小时可预约会议室时长。（提供证明材料） 查看可预约的会议室数据，支持上下周来回切换查看可预约的会议室，也支持高级查询来定位自己所需要的会议室类型、容量、时间等。 单次预约不支持跨时间段预约，只支持连续时间预约。 若开启了评价功能，点击会议室详情时可以查看历史评价记录。 若当前用户处理违约名单中，且违约状态还未解除的将无法进行预约。 预约提交成功后，若审批还未通过时将锁定当前时间段不允许其他人预约，若申请被驳回即可释放当前资源。 预约成功后，系统会根据配置中的提醒内容在使用前推送消息给预约人。 若当前会议室需要审批时，需要会议室管理员审批通过后才表示预约成功。 (*)我的预约 用户可以查询到自己的预约历史记录，对于还未开始登记使用的数据提供取消功能，取消时需要注明取消原因。 若预约数据需要审核时，可查看预约审批进度。 使用评价，若开启了评价功能，预约人可以对预约记录的使用进行评价。 扫码登记使用，若会议室开启了扫码登记使用时，支持用户通过扫码后显示当日的预约信息，并可对预约信息进行扫码登记操作，点击后将使用状态更新为“已使用”。 系统配置若开启了签到功能，且预约成功后，预约人可以发起签到，保存签到之后会提醒用户进入“电子签到”服务中维护签到成员。 取消预约，若取消的时间在规则中，可以支持取消功能，取消后会议室资源将得到释放，其他用户即可对当前会议室进行预约。 (*)预约记录 管理员可以查看对应权限的预约记录，同时可以查看对应记录的评价内容。 数据中若未开启扫码登记使用，到了预约的使用时间时将自动设置使用状态为“已使用”。 管理员若操作了取消预约后，将会有消息通知预约人预约被取消。 开启了扫码登记功能时，超过使用时间的预约记录，使用状态为“未使用”的，将被加入违约名单。 (*)会议室统计分析 会议室管理者能够按照多个维度统计会议室预约使用的情况，目前支持两个维度的统计。 按评分统计：统计每个会议室的评分的平均分，支持按年、月进行筛选统计。 统计使用率：统计每个会议室的使用率，并支持明细数据查询。 (*)会议室配置 使用系统前的基础配置，支持多个配置项，管理员可根据学校实际使用情况自行配置数据。 预约须知，师生预约时会提醒用户需要注意哪些规则、细节，同时可设定浏览须知时需要多长时间才允许关闭； 预约日期可见范围，教职工预约会议室时最多能看见什么时间的数据； ▲可预约最小时间单位，指教职工在预约使用时间时，可选择的最小单位，默认有半小时、*小时、*小时，若此处设置为*小时，教职工可预约的使用时间段则为*小时 * *，例如**：**~**：**。（提供证明材料） 违约规则，可设定违约的规则，违约是指用户在预约会议室后没有履约使用会议室，造成了会议室资源的浪费，可限制违约人多少天内不允许再次预约。 提醒设置，用于提前提醒预约人记得登记使用会议室。 评价配置，管理员可开启或关闭评价功能，开启评价后师生可对会议室每次使用后作出评价，若用户没有主动评价，可触发自动评价功能。 ▲会议室预约时长限制，会议管理员无预约时长限制；支持专任教师提前一周预约所有会议室，上限*小时/人；支持行政教师提前一个月预约所有会议室，上限**小时/人；支持拔尖班教师提前一个月预约***和****会议室，其他会议室权限跟专任教师相同，所有会议室（含***和****会议室）上限*小时/人。（提供证明材料） 二、技术要求 投标方提供的平台和系统均要求采用*/*结构，均可运行于****、*****、*******等高安全性操作系统及麒麟、统信、龙蜥、欧拉等国产化操作系统上。开发技术应采用****标准、组件技术及在数据交换上对***/****的支持，使系统功能最优化，同时将整体系统内部在技术上的相互依赖性减至最低。 具体要求如下： （*）▲平台及应用系统软件必须遵循****的技术路线，采用****编程语言和服务器端****技术进行开发，业务应用系统必须基于**********数据库上。 （*）采用面向对象的组件技术，着重于开发构成应用程序“业务对象”的可重复使用的组件，利用这些组件顺利地建立分布式应用程序。并通过业务组件库实现行业知识的积累。组件采用面向对象的思想构建，组件之间可以继承，组件之间从物理和逻辑上都是隔离的。 （*）应用程序开发与运行结构要基于统一的技术开发平台的三层架构，即***服务器、应用支撑服务器和数据库服务器。 （*）能完成跨业务部门的业务流程和相对应的细颗粒度的分级授权体系。 （*）各应用系统要充分利用现有先进技术手段，采用相同的体系结构和运行平台，基于多层架构和组件技术，进行构建，整体架构基于******的***结构，分为显示层、控制层、服务层、持久化层。组件的执行是以模型进行驱动，每层都有相应的模型配置，引擎解析这些模型，自动实现各层的功能做到系统结构层次清晰。所有应用逻辑、流程、数据等都应当能够根据实际业务要求的颗粒度进行封装。 （*）平台须支持多机负载均衡模式。 （*）系统须采用学校的数据标准进行设计，数据字典须基于学校标准建设。 （*）▲投标人所提供的系统须支持在国产化操作系统(如龙蜥、欧拉、麒麟等)上部署，数据库须支持******、**********等传统数据库及国产化数据库(如华为*******、人大金仓、达梦等)，系统须保证数据存储和数据传输安全，并建立数据容灾备份及数据恢复机制。（提供承诺函） （*）投标人须承诺配合完成学校数据治理工作，根据学校数据治理要求，完善数据标准，并对数据质量问题进行整改，根据数据中台开放***接口标准进行各项业务数据对接( 如教职工信息、组织架构信息等 )等,并向数据中台开放业务数据。 （**）投标人须承诺项目完成后应建立完整的书面和电子的建设技术文档， 便于运行维护的文档资料。应提供的文档包括但不限于：《需求分析规格说明书》《系统详细设计说明书》《数据库详细设计说明书》《数据字典表》《测试计划与报告》《安全评估报告》《集成规范报告》《安装部署手册》《用户使用手册》《维护手册》等。 三、安全要求 （*）认证授权：需保证用户的合法性和用户使用应用信息资源的权力，避免内部敏感信息泄漏和服务所提供的信息资源被非法访问，造成严重的安全事件。 （*）信息保密：需充分利用密码技术，对于需要保密的信息，采用密码技术进行加解密处理，防止信息的非授权泄漏，确保涉密信息在产生、存储、传递和处理过程中的保密。 （*）数据完整性：需建立数据完整性检验机制，保证收发双方数据的一致性，防止信息被非授权修改。 （*）审计：需记录应用日志，对事件进行分析，并能提供预警信息。 （*）数据备份：需利用数据库的备份功能将建设的平台和系统数据备份到指定的服务器或存储系统上。 （*）投标方需从物理安全、网络安全、系统安全、应用软件安全、数据备份安全等几个方面提出配套的安全体系完善方案，以便防范安全风险。 （*）▲系统上线前应完成安全检测，并提供学校认可的第三方安全检测报告。安全检测费用已包含在本项目内，甲方不额外支付费用。（提供承诺函） 四、工程实施要求 *.时间进度要求 ★本次项目须严格按工期部署完成，并达到采购人的要求。投标方需要在投标文件中给出预实施工期进度表。需在合同签定后**天内完成系统开发。（提供承诺函） *.实施方案要求 （*）提供项目经理一人，负责全程跟踪项目的开发与实施，直至该项目验收，并保证现场工作时间*个月以上。 需提供驻场服务和远程服务。合同签订后至项目验收，提供***小时服务，负责业务调研、需求梳理、平台部署、技术协调及实施。 （*）实施阶段划分 要求描述各个实施阶段的工作范围、内容、人力投入、过程、责任、交付成果等。 *.项目管理要求 投标方必须提出对项目的建设进行科学严格的管理方案与措施，保证项目全面顺利实施。 （*）项目管理规范和手段要求 根据项目的实施方案，在实施过程中，为了保证用户方、开发方等各方能够对项目建设实施进行监控，及时发现和解决问题，必须建立相应的项目管理规范，包括项目执行监控流程、执行监控的方法、执行监控的责任等，使管理和监控工作流程化、规范化，管理和监控工作责任明确。 （*）项目管理控制要求 项目的管理控制包含多个方面：项目范围、风险、进度、质量、变更管理控制，贯穿项目开发建设的始终，必须做到对项目建设范围准确定义，一旦范围发生变更，要有相应的变更控制和应对措施。 （*）风险管理要求 项目风险管理是对项目风险从识别到分析到应对措施的一个过程，包括风险识别、风险量化、风险对策、风险对策实施控制四个方面。项目在实施过程中会出现各种各样的风险，必须做到充分、有效识别风险，应对风险和控制风险，在项目实施之初必须制定风险预测和规避风险的对策。 *.项目配置管理 在项目的建设过程中以及交付使用后，会产生大量文档和程序，如：需求分析说明、设计说明、可执行码、用户手册、测试用例、测试结果等技术性文档以及合同、计划、会议记录、报告等管理文档，而且文档的版本在不断变迁和修改中，势必产生一个庞大、动态的信息集合。因此，必须建设相应的配置管理系统，通过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的版本、在产品开发和发布阶段控制变化，制定规范的配置管理工作计划和流程，沟通交流配置管理工作情况，从而使管理制度化、有效减少重复性工作、保证产品的质量和效率和系统的后续升级和维护。 五、验收交付要求 在本期项目的开发过程中和交付使用后，要求将各个阶段产生的全面、规范的成果和文档资料交付给采购方，而且需要提供明确的交付清单。同时，成果和文档资料必须符合软件工程的相关要求。要交付的成果和文档资料需要包括以下部分： （*）满足校方要求的可运行的系统 （*）技术文档 包括项目开发中的各种技术文档，如开发环境配置说明、软件工具清单、需求分析说明、变更说明、系统设计说明、数据库设计说明书、项目编码规范、用户手册、系统安装手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等。 （*）管理文档 包括项目开发中的一些工作文档，如，计划、报告、讨论纲要、会议记录等。 六、售后服务要求 *.售后服务时间 要求投标方案针对本次项目提供*年的免费售后服务，售后服务期自验收之日起。 *.运行保障能力 （*）要求充分说明公司的运行保障能力，包括技术支持队伍、能力配置、人员配置、机构情况，在本地有无技术支持中心、地点设在何处等。 （*）★质保期内系统出现故障，****小时服务响应，根据校方要求能随时**分钟到达现场处理。（提供承诺函） （*）系统正式上线运行后，预留一定工作量用于除免费售后服务外的后续的新的需求变更。 *.应用软件服务 投标人应确保本次招标的平台安全稳定地运行，投标方应提供对应的售后服务支持，售后服务期自验收合格之日开始计算。方案中应对服务的范围和内容进行详细阐述，并至少包括以下内容： （*）缺陷管理：针对本次招标的各类系统中存在的***、缺陷，不论在质保期内、外，投标方均应持续提供修正与消缺服务。 （*）应急故障处理：系统运行环境出现故障或意外情况导致系统不能正常运行时，投标人响应的情况描述，包括针对不同故障级别的响应时间和响应内容。 （*）系统升级：提供平台的软件补丁版本的升级服务。 （*）需求变更：对于学校业务流程的变化、性能要求提升导致的部署结构变化（如搭建双机环境），提供限定次数的变更支持。对由于本期招标或集成的各类业务系统本身变更（如邮件系统升级了，认证结构发生变化）导致的集成需求变更，提供配套的支持服务；对由于学校业务规则变更（权威数据源发生变化）导致的数据集成需求变更，提供配套的支持服务。 （*）文档服务：整个服务过程均需有完善的文档记录，便于跟踪、分析问题；对各项服务提供详细的书面报告，包括故障处理报告、健康巡检报告、系统性能检测调优报告、维护总表报告、服务年度报告等。 （*）运行支持：对系统运行过程中师生用户及业务部门的问题提供解答和问题解决跟踪，对关键业务点的上线推广与运行提供现场保障。 *.服务请求流程 投标人需对用户支持或维护请求处理的流程进行详细描述。 *.服务请求方式 对采购方与投标人联系沟通的方式进行详细描述，以方便学校便利地获取各类即时的和非即时的服务支持。投标方提供的服务请求方式至少应包括：服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站。 投标人是否设有用户投诉受理电话，对用户的意见作出反应。如果有用户投诉受理电话，请描述以下内容：电话号码（或传真）、投诉中心负责人和受理答复时间。 七、培训要求 （*）按校方要求确定培训内容、培训时间和培训名额等。 （*）投标人派出的培训教员应具有丰富的同类课程的教学经验和应用经验；所有的培训教员必须用中文授课；投标人必须为所有被培训人员提供培训用文字资料和讲义等相关材料。 （*）投标人应按合同规定安排培训时间和培训名额，在实施过程中，对系统管理人员提供培训，保证培训的效果，让系统管理人员都能熟练掌握系统的使用方法。 八、验收交付要求 *.在本期项目的开发过程中和交付使用后，要求将各个阶段产生的全面、规范的成果和文档资料交付给采购方，而且需要提供明确的交付清单。同时，成果和文档资料必须符合软件工程的相关要求。要交付的成果和文档资料需要包括以下部分： (*)技术文档 包括项目开发中的各种技术文档，如开发环境配置说明、软件工具清单、需求分析说明、变更说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等。 (*)管理文档 包括项目开发中的一些工作文档，如，计划、报告、讨论纲要、会议记录等 *. 乙方按双方共同约定的《用户验收测试用例》完成系统测试后，向甲方提交《功能确认单》和《项目试运行申请单》，甲方签署《项目试运行申请单》后，项目即进入试运行，试运行期为一个月； *. 乙方交付前应对产品或服务作出全面检查和对验收文件进行整理，并列出清单，作为甲方验收依据。 *.试运行期满后，甲方在*个工作日内，组织验收，并签署项目验收报告。对于验收时未到业务期的模块，甲方签署《功能确认单》，即视为验收通过。

*.售后服务时间 要求投标方案针对本次项目提供*年的免费售后服务，售后服务期自验收之日起。 *.运行保障能力 （*）要求充分说明公司的运行保障能力，包括技术支持队伍、能力配置、人员配置、机构情况，在本地有无技术支持中心、地点设在何处等。 （*）★质保期内系统出现故障，****小时服务响应，根据校方要求能随时**分钟到达现场处理。（提供承诺函） （*）系统正式上线运行后，预留一定工作量用于除免费售后服务外的后续的新的需求变更。 *.应用软件服务 投标人应确保本次招标的平台安全稳定地运行，投标方应提供对应的售后服务支持，售后服务期自验收合格之日开始计算。方案中应对服务的范围和内容进行详细阐述，并至少包括以下内容： （*）缺陷管理：针对本次招标的各类系统中存在的***、缺陷，不论在质保期内、外，投标方均应持续提供修正与消缺服务。 （*）应急故障处理：系统运行环境出现故障或意外情况导致系统不能正常运行时，投标人响应的情况描述，包括针对不同故障级别的响应时间和响应内容。 （*）系统升级：提供平台的软件补丁版本的升级服务。 （*）需求变更：对于学校业务流程的变化、性能要求提升导致的部署结构变化（如搭建双机环境），提供限定次数的变更支持。对由于本期招标或集成的各类业务系统本身变更（如邮件系统升级了，认证结构发生变化）导致的集成需求变更，提供配套的支持服务；对由于学校业务规则变更（权威数据源发生变化）导致的数据集成需求变更，提供配套的支持服务。 （*）文档服务：整个服务过程均需有完善的文档记录，便于跟踪、分析问题；对各项服务提供详细的书面报告，包括故障处理报告、健康巡检报告、系统性能检测调优报告、维护总表报告、服务年度报告等。 （*）运行支持：对系统运行过程中师生用户及业务部门的问题提供解答和问题解决跟踪，对关键业务点的上线推广与运行提供现场保障。 *.服务请求流程 投标人需对用户支持或维护请求处理的流程进行详细描述。 *.服务请求方式 对采购方与投标人联系沟通的方式进行详细描述，以方便学校便利地获取各类即时的和非即时的服务支持。投标方提供的服务请求方式至少应包括：服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站。 投标人是否设有用户投诉受理电话，对用户的意见作出反应。如果有用户投诉受理电话，请描述以下内容：电话号码（或传真）、投诉中心负责人和受理答复时间。