移动应用管理平台技术参数

1、移动应用管理平台技术参数技术要求1.1项目简介项目名称项目名称：移动应用管理平台项目建设单位项目由武汉理工大学网络信息中心承担建设。项目背景随着信息技术的高速发展，传统的PC用户必须通过电脑和网络才能进行应 用的获取，具有极大的不便捷性和讯息滞后性。而现代校园学习和生活节奏加快， 对学校的服务性要求更高，校领导工作繁忙、会议频繁、经常出差，通知多、提 醒多、代办事项多、业务观注面大，采用PC进行应用的获取尤为不便；对普通 师生来说，广泛的应用服务均需要依赖PC进行访问，在时间和空间有诸多限制， 使得应用的推广效果不佳，移动应用平台能方便解决这些问题。移动应用管理平台作为传统数字校园门户平台的拓

2、展，为师生领导提供个性 化的服务。用户在智能移动设备上，通过校园内外WIFI网络环境、移动运营商 提供的GPRS、3G、4G等网络，接入学校网络的各个系统，访问校内资源，覆 盖部分传统数字校园的应用（包括校内要闻、最新公文、OA公告、文件传阅、 会议提醒、科研信息、教务通知、我的成绩、个人课表、校内通讯录、学术动态、 工资信息、学费信息、图书馆信息等），并结合手机自身的功能提升用户体验。建设目标本项目的建设目标是构建开放、可集成的校园移动运行环境，为校园移动应 用提供可靠一致的集成用户体验，提供统一的面向各角色分用户的个性化移动应 用分发通道，实现通过主流移动终端操作系统（iOS、Andrio

3、d等）获取信息化 校园相关资讯、个人信息及完成主要业务操作。期望通过移动应用管理平台将学校丰富的信息化技术发展的最新成果在学 校教学理念与信息化发展思想的统一指导下进行移动式展现，推动学校教学、科 研、管理等各项工作的全面开展，有力提高学校教学和管理水平。1.1.5.项目现状目前我们学校已经基本建设完成校园无线网络建设，实现校园WIFI全覆盖， 在这样的网络环境下，移动应用管理平台就有了很好的外部环境。移动应用管理 平台目前只有网络信息中心开发的“移动OA”，其他职能部门也陆续准备建设自 己的移动终端应用，因此建设全校统一的移动应用管理平台迫在眉睫，在这个统 一的移动应用管理平台上，可以将各职

4、能部门需要的应用模块按照等级分类，分 层次进行开发部署。1.2建设原则移动应用管理平台作为传统数字校园门户平台的拓展，各应用系统都需要和 移动应用管理平台进行集成，该平台是综合性的、涉及全校各单位的一项工作， 因此需要充分调研，确定用户需求，并对这些需求进行综合分析，确定设计方案。 系统建设依据“科学规划、充分继承、标准统一、实用灵活，安全可靠”的原则：先进性和成熟性系统设计既要采用超前思维，先进技术和系统工程方法，又要注意思维的合 理性，技术的可行性，方法的正确性。不但能反映当今的先进技术和理念，而且 具有发展潜力，能保证未来若干年内占主导地位。先进性与成熟性并重，并考虑 到近年来的应用发展

5、特点，把先进性放在重要位置。开放性与标准化原则应用平台应是一个开放的且符合业界主流技术标准的系统平台，并使网络的 硬件环境、通信环境、软件环境、操作平台之间的相互依赖性小。可扩展性及易升级性本项目面临着各类扩展性需求，例如业务规模的扩展、业务类型的扩展、集 成范围的扩展、性能扩展等。应用平台模块间应完全独立，接口清晰，内部的业 务流程升级和改造与其它模块无关，所有模块基于组件开发，并为二次开发提供 开发API接口，该平台需要支持集群部署方式。可靠性和稳定性本项目技术方案从系统基础设施结构，系统软件、技术措施，设备性能，应 用设计，系统管理等各个层面确保系统运行的可靠性和稳定性，达到最大的平均无

6、故障时间。安全性和保密性在应用软件平台设计中，应充分考虑信息资源的共享，注意信息资源的保护 和隔离，分别针对不同的应用需求，采取不同强度的安全保密措施，包括数字证 书认证、数字签名、细粒度的数据存取控制、防毒防黑、审计和安全管理制度等。可管理性和可维护性应用平台是由多个部分组成的较为复杂的系统，为了便于系统的日常运行维 护和管理，本项目解决方案应提供快速部署、增强的易用性和轻松的远程专用的 可视化的系统管理模块。1.3项目范围开发移动应用管理平台及若干凸显信息服务的应用，以实现上述建设目 标，具体内容参照【1.4系统业务要求】。投标人在本项目建设中的工作内容包括但不限于方案设计、系统需求调 研

7、、需求分析、系统设计、系统开发、部署与培训、试运行、技术支持与售后服 务等。本项目不包括硬件、操作系统，但投标人需要对能够满足本系统需要和 性能要求的硬件配置（包括服务器、网络设备）、操作系统、网络架构以及安全 措施提交相关设计和建议。投标人在本项目建设中使用武汉理工大学已采购软件 Oracle Database Enterprise Edition 10g RAC之外的第三方软件时，须自行承担采购相应产品的费 用，其使用的第三方软件产生的问题由投标人负责。1.4系统业务要求本标书所提的系统业务要求包括但不限于以下内容，请投标人报价时充分 考虑需求变化风险。投标人须对完全实现项目技术要求作出承

8、诺（加盖公章承诺函）。将移动应用技术与数字化校园相结合，构建学校的移动应用管理，为学校开 展各项移动应用构建一个移动应用管理，基于该平台可以方便发布各类移动应 用，并在此基础上能快速的集成各类服务并发布到移动端。移动应用构建一个基 础架构，基于该平台可以方便的开发各类移动应用，并在此基础上建设移动应用管理门户和移动应用。移动应用管理平台移动应用管理平台构建开放、可集成的校园移动运行环境，为校园移动 应用提供可靠一致的集成用户体验移动应用管理平台提供统一的面向各角色分用户的个性化移动应用分发 通道移动应用管理平台将学校内部私有业务数据访问能力安全开放，供第三 方基于安全授信的方式获取核心业务数据

9、逻辑的访问能力移动应用基础平台移动应用基础平台提供应用的统一分发和统一访问通道，包括移动门户和 应用管控台。移动门户主要提供用户登录、个人信息维护、移动应用在终端的聚合和管 理（下载、安装、更新、移除）以及接收PUSH消息和系统消息服务。账号登录及授权与学校现有统一身份认证系统无缝集成，实现单点登录。个人信息维护可灵活设置个人昵称、个人照片信息、个人联系方式等属性信息，并在使 用第三方应用时可以自主选择是否允许第三方应用访问个人授信信息。个性化系统消息提醒用户登录后可以接受系统推送的与角色相匹配的消息，支持语音、图片、 外部链接、新闻等富媒体信息格式。 PUSH服务推送系统内重要的与用户强关联

10、的通知消息。PUSH的消息支持系统内嵌 服务跳转，如新闻、通知公告或外链的第三方跳转，也支持被集成的移动应用 的直接调用。移动应用市场提供学校专属的移动应用列表，并为不同权限用户展现个性化的移动应用列表，用户可以对应用进行安装、卸载、评价。应用管控台可对用户、应用、权限进行管理。管理权限设置支持不同管理组的设置，如身份管理、应用管理、内容管理、客户端管理 等，并对不同管理组配置相应的管理员，通过页面授权的方式进行独立管理。 用户及角色信息管理可以自定义用户角色，如分为学生、教师、行政管理人员等角色，根据不 同角色进行差异化的应用推荐和功能设置。应用管理可对授权的第三方应用进行管理，如添加、编辑

11、、上架、下架、删除、升 级、版本回退等。服务分发统计服务可以获取用户访问总数、订阅用户数、新增用户数、在线用户数、月活/日 活用户数等统计数据。应用内容管理对新闻、通知公告等依赖于PC应用系统的移动应用，进行应用订阅源管 理、应用内容发布、内容同步等管理。客户端版本升级管理可以对客户端版本升级信息进行管理。开发者服务平台开发者服务平台提供身份、文件、消息等公共服务的API接口，同时为应 用开发提供过程管理和支持，包括注册登录、应用创建和提交审核、应用统 计、版本更新、文档支持、SDK包下载、接口测试工具等。身份服务：提供基于实名用户身份的统一认证和授权机制，实现面向移动 端的SSO和身份能力开

12、放。缓存服务：通过配置即用和API两种方式提供系统各个层面的缓存能力， 包括数据层、应用层、视图层。应用服务集群：提供应用服务节点的横向扩展能力，依赖于硬件资源的配 置，提供脚本工具和可视化管理两种方式。文件服务：提供各种文件的上传、下载以及文件的预处理（图片文件缩放、 裁剪、水印，视音频编码转换、压缩等）等。消息服务：提供各种消息通道的实现，如：PUSH提醒、应用内系统消息、 短信、邮件等。行为分析服务：支持海量用户行为数据的收集、存储、汇总、统计和分 析，辅助运营决策。数据服务：通过API方式提供传统关系型SQL和非关系型NoSQL两种数据 的存储和查询访问。搜索服务：通过API和外部数据

13、接入的方式，提供基于全文、位置、关系 以及用户行为的信息检索和推荐。推荐服务：基于广泛的用户属性和行为数据，提供基于上下文的更丰富的 信息发现和获取方式。队列服务：基于消息事件的方式，协调各服务之间的业务状态同步，解耦 服务之间依赖关系。管理/监控：提供基础环境、集群、应用服务等的管理以及对访问情况和负 载情况的监控统计。开发者服务：提供开发者注册和登录、应用创建和管理、权限管理、数据统 计、SDK包下载、开发指南、API参考手册和测试工具等。移动业务支撑本模块提供APP应用接入和WAP应用接入服务，支持Native App和Web App 以及 Hybrid App 应用。移动终端MVC框架

14、移动终端依照MVC框架设计模式，进行架构和开发，对独立应用进行统一 的管理，包括：统一的UI显示、统一的系统行为、安全认证、下载、安装、调 用和版本控制。同时支持Native App和Web App以及Hybrid App应用。消息推送实现系统管理员或者集成应用服务向某部门下所有用户、某角色下所有用 户、某些用户或某个用户发送消息的功能。移动终端支持范围应支持苹果及安卓两个平台的所有智能手机和平板电脑，屏幕构件应根据实 际移动终端的尺寸和分辨率自动采用最合适的尺寸，使应用具有良好的用户体 验。校园服务类应用移动门户门户能够给学校用户提供丰富的信息展示，不同角色获取的服务不 一样。例如对校领导而

15、言，可以通过移动办公随时随地审批公文，交代工作；对 老师而言，可以通过移动教学实现教学方面的安排；对在校学生而言，可以通过 讲座查询功能实现讲座信息的查询；对新生而言，可以通过移动迎新获取迎新报 道时的导航和报道相关事项信息；对游客而言，可以通过校园风采，了解校园风 光、学习概况等校园风采。同时提供各个业务应用系统中推送过来的消息通知， 用户也可自定义自己的门户主页，选择性添加个人爱好所需的应用内容，最终可 以实现通过移动门户门户获取校内、个人等相关信息、完成主要业务操作。1.4.2.1.资讯门户资讯门户的典型栏目包括学校概况、新闻资讯、校园风景、生活服务，系统 提供四类基本展示框架用于各种门

16、户信息的显示和浏览。利用这四类展示框架， 根据学校的需求扩充门户栏目。移动门户的栏目可以与学校统一信息门户的相关 栏目对应，也可以另行建设，通过移动门户平台发布相关信息。1）学校概况学校概况展示框架分成三层，即分类、列表和详细内容。根据学校的特点将 学校概况的相关信息进行分类，如“学校概况”、“院系介绍”等。2）新闻资讯用于展示校内各网站的新闻资讯，系统提供展示新闻的基本框架，通过配置 设定新闻资讯的内容。3）校园风景“校园风景”类栏目用于显示学校的各类图片，该类栏目的展示框架分成分类、缩略图、放大图三层。4）生活服务用于展示日常生活中常用到的信息资源，包括校园地图、校车线路、班车信 息、校园

17、黄页、校园校历等栏目。1.4.2.2.应用门户将学校一卡通、教务处、人事处、学工部、财务处、图书馆等应用系统中信 息使用率较高的抽取整合，集中推送到个人应用门户终端上，可包括但不限于移 动迎新、移动招生、移动人事、移动教务、移动教学、移动图书馆、移动一卡通 等20个应用。1.5系统通用技术要求高并发本系统的用户规模大约60000人，其中教职工用户8000人，在校学生用户 大约50000人，远期目标支持20万人注册使用。投标人开发的系统在业务处理、 查询、统计等操作时，需解决性能和高并发访问的问题。数据监控对异常数据、异常操作、错误日志等进行查询、分析及监控。可扩展性要求投标方应充分考虑本项目在

18、后续运行、管理过程中的业务功能扩展以及性能 扩展的要求。在充分满足当前业务需求的基础上，投标方须对系统的扩展性进行 认真分析与设计，能够为第三方软件提供相关接口并且支持集群部署方式，以确 保系统可满足后续业务发展的需要。稳定性要求系统应具有较高的稳定性，要求能够支持连续的数据采集、业务管理、数据 传输、查询、统计分析任务。投标方需详细说明系统稳定性设计的内容与措施。保障性要求系统运行过程中可能会由硬件的失效、人为因素或自然灾害引起系统故障。 在系统瘫痪情况下，要求预先制定应急方案，可以有效应对紧急情况，快速恢复 系统运行。安全性要求对系统的保密数据进行加密，系统防止SQL注入等的攻击机制。1.

19、6项目实施要求项目实施总体进度要求投标人应根据本文中交付时间要求，制定项目进度计划及资源保障计划，并 按计划实施。总体进度要求如下：20?年？月完成本项目的应用部署与开发工作。20?年？月完成合同中要求的系统集成，进入试运行阶段并进行应 用推广和培训工作。20？年？月完成工程最终验收，提交验收文档。投标人须在投标文件中应包括项目进度计划，详细阐述项目过程中主要里 程碑节点、时间计划安排。项目团队要求项目团队组成要求项目团队人员配置科学合理、分工明确，至少应包括项目经理、技术负责人、 需求人员、系统分析师、系统设计人员、软件开发人员、测试人员、配置管理员、 质量保证员、用户培训人员、部署实施人员

20、、运行维护人员等角色。项目组团队需保持稳定。投标人应承诺项目经理、技术负责人必须专职承担 本项目工作，未经建设单位许可不得更换。投标人应提出具体管理措施，以确保 该承诺得到落实。在项目实施过程中，投标人须按照建设单位的要求更换建设单 位认为不合适的人员。项目经理和技术负责人的要求投标人应明确项目经理和技术负责人在本项目中的岗位职责、任职资格及管 理权限，并明确项目经理和技术负责人调动相关资源的权力，以确保工程顺利实 施。投标人需承诺项目经理和技术负责人自始自终专职承担本项目，且具有高等 学校信息系统软件项目经理从业经历，提供相关证明文件。根据项目工作建设工作的业务性质，投标人应分别配备经验丰富

21、的项目经 理、技术负责人承担本项目工作。投标文件中指定的承担本项目的项目经理、 技术负责人、系统分析师、核心技术人员需在投标人单位工作1年以上（必须 提供加盖公章的社保缴纳证明材料）。项目团队人数要求投标人应承诺在系统开发、部署实施、试运行、培训、技术支持及售后服务 五个阶段和项目管理等来配置足够的人员组织实施项目，确保按项目进度完成建 设工作。在项目实施阶段要求提供驻地研发技术人员，验收之后在武汉有常驻售 后服务团队。对项目管理要求投标人须制定项目管理及质量控制制度、规范和工作流程，合理规划项目的 组织架构、沟通方式和工作职责，并在建设单位认可的情况下按照制定的规范和 流程严格执行，提供项目

22、管理工具平台辅助项目管理工作，定期向建设单位提供 工程实施进展情况报告。投标人可根据项目实施经验，对项目管理工作提出相关 建议。投标人须在投标文件中提交项目管理、质量控制制度与规范建议书。项目实施过程管理要求系统开发阶段要求方案设计投标人应调研系统现状及有关详细需求，明确细化具体的建设任务，建 设技术路线，建设技术框架以及具体实现的技术方法，形成详细的设计文本。 参考项目确定的总体时间进度、质量等要求，制定项目施工时间进度计划， 同时根据项目的实际情况，进行必要的项目实施风险分析，提出详细的风险 规避办法和措施。明确项目实施需要的技术标准、设计规范以及项目实施的 文档规范等，制定项目质量管理和

23、控制、项目进度管理与控制以及软件开发 定制文档规范、项目提交成果要求等。系统设计应与建设单位保持密切沟通 并得到确认，遵循统一的标准规范，使用统一的设计模式和统一描述语言。需求分析投标人按照项目实施计划所确定的目标完成需求调查与分析，深入各个 业务部门开展需求调研工作，编制需求调研报告和需求规格说明书，在此基 础上开发系统原型以确认需求。系统设计投标人在需求规格说明书、系统原型基础上完成系统概要设计和系统详 细设计等文档。系统开发投标人按照本项目招标要求完成软件编码及单元测试工作。系统测试投标人按照项目实施计划所确定的目标，提出测试方法，制定测试规范， 按照测试要求提供系统测试相关的各项报告，

24、功能和性能测试报告等文档， 包括计划、用例和报告。过程评审投标人完成方案设计、需求分析、系统设计、系统开发、系统测试等阶 段工作时，均须通过建设单位组织的评审。1.6.4.2.部署实施阶段工作要求部署实施计划投标人须按照建设单位要求制定项目部署计划（含工作计划和技术方 案），完成系统部署实施工作。投标人须在投标文件中详细阐述项目部署计划，承诺按照甲方要求，可 多次派工程师到现场完成部署实施。部署安装投标人根据项目部署实施工作需要进行应用系统及配套基础软件的安 装和部署，并通过建设单位验收。1.6.4.2.3.推广培训投标人须按照建设单位要求制定项目培训的工作计划和技术方案，编制系统的培训教材，

25、包括应用系统部署手册、用户操作手册、培训PPT等文档， 并得到建设单位的确认。培训具体要求详见【1.7.3培训工作要求】。1.6.4.3.试运行阶段工作要求试运行工作任务投标人须按照建设单位要求参与应用系统的试运行工作，编制试运行工 作方案，提供及时解决技术问题的解决方法。试运行期间的技术支持与服务详见【1.7.2试运行的技术支持与服务】。试运行故障恢复要求系统试运行过程中如果发生故障，恢复时间不能超过48小时。在试运行期 内，如系统出现重大故障，则试运行期从故障修复之日起重新计算，顺延2个月， 若仍达不到要求，继续顺延，一直到系统连续2个月无故障为止。1.7技术支持与服务要求本项目业务需求复

26、杂、服务内容多样、面向用户广泛，服务提供难度大。投 标人应建立相对稳定、有业务素养的技术支持与服务队伍，提供全面的技术支持 服务。投标人必须在投标文件中给出切实可行的技术支持与服务方案，包括但不 限于技术支持与服务队伍人员名单、人员保证措施、技术支持与服务计划、质量 控制措施、拟提交的服务文档和用户满意度指标和标准等。驻场技术支持和服务要求投标人自签订合同起，安排1名项目经理或技术负责人进驻现场（武汉 理工大学），时间到试运行通过；从系统初步验收开始，投标人安排不少于1名 专业能力强、经验丰富的技术支持工程师提供驻场（武汉市）技术支持和服务， 时间为到质保期结束。试运行的技术支持与服务在试运行

27、期间，投标人必须向建设单位承诺免费的技术支持和服务，免费服 务内容应包括但不限于下述内容：升级服务、调优、故障排除等。中标人应进行 全程跟踪，确保试运行的顺利进行，达到检验系统、完善系统的目的。投标人应承诺为最终用户单位、其他集成商等提供免费的技术协助，技术协 助的内容包括系统的安装部署上线、与其他系统的集成接口等。技术协作的方式 应包括电话支持、电子邮件支持、文档提供、现场支持等多种以解决实际问题为 目的的方式。培训工作要求投标人须承诺在完成应用软件开发，进行部署实施、试运行、正式运行等阶 段工作时，根据建设单位的要求，可多次派培训工程师到现场开展培训工作。培训目的确保建设单位和应用软件使用

28、单位的技术人员能够熟练地对应用软件进行 运行、管理、诊断、维护和管理。确保建设单位和应用软件使用单位的相关业务人员对其使用的应用软件能 熟练地操作和使用。培训教师投标人负责提供满足培训工作所需的培训教师，且具有相应专业知识、实际 工作和教学经验，如果应用软件使用第三方软件时，培训教师还须满足第三方软 件厂商的培训资格要求。培训教材投标人负责按照建设单位要求编写培训教材，包括视频培训教材和WORD、 HTML格式的用户操作手，以及培训PPT，培训所使用的语言和教材必须是中文。培训对象投标人负责培训建设单位的人员包括但不限于武汉理工大学职能部门的相 关业务人员、系统运行维护人员等。培训内容培训内容

29、包括应用软件部署实施培训、应用软件操作使用培训和应用软件运 行维护培训等。培训的时间、内容、人员、期次等具体内容在具体执行过程中需根据建设单 位意见进行调整。投标人在投标文件中须提供详细的培训方案，并按照上述要求进行详细说 明。质量保证期内的技术支持与服务质量保证期内需提供以下服务：实时技术支持投标人应提供7x24小时技术支持服务，在接到技术支持要求时，应为系统 使用人员提供如何使用系统的咨询。故障响应投标人在接到故障报修要求时，1小时内做出明确响应和安排，在2小时内 为建设单位提供维修服务，并做出故障诊断报告。若需要现场服务才能解决问题， 武汉理工大学现场应在4小时内到达。热线服务投标人应提

30、供热线电话、E-mail、传真、网站等途径，随时接受建设单位提 出的各种技术问题，并在24小时内提出解决方案。4 .定期跟踪投标人应每1个月不少于1次在武汉理工大学进行现场巡检服务，每半年不 少于1次在进行现场巡检服务，及时发现和排除潜在问题或故障隐患，保证系统 的稳定运行。5.系统升级维保期内投标人应每半年提供一次免费的应用软件产品升级服务。升级内容 包括解决的BUG、采纳用户完善建议实现的功能、因业务需求调整实现的功能 和其他内容。投标人应在投标文件中详细阐述质量保证期的技术支持和服务的内容、方式 与范围。售后服务的所有报价都需要计入投标总价中，否则视为免费。若投标人未能按时派员到现场或未

31、能按时限解决问题，建设单位有权自行处 理，所发生费用由投标人承担（在合同经费中扣除）。投标人须认真理解上述售后服务要求，详细列出服务方案和系统应急方案，一经应答将作为合同的一部分。质量保证期外的技术支持与服务如建设单位委托投标人进行新的系统功能开发，投标人可以适当收取费用， 但其费用额度不能超过投标文件中可比部分报价。要求投标人在投标文件中对质保期外的技术支持与服务出据承诺函并加盖 本单位公章。1.8项目验收要求初步验收系统开发、部署、调试完成后，建设单位组织初验。系统初验的基本条件是： 全面完成系统的设计、开发、测试和集成工作，系统安装调试，并进行相关的 配置和系统优化的调试，达到功能、性能

32、、使用等方面的要求；完成系统部署 实施并上线运行；用户对系统的使用方式满意，确实方便了用户，提供了用户 的效率，达到了系统的设计目标；系统运行稳定，上线试运行后确保不会影响 业务部门的正常工作；完成实施过程中所有文档的提交（技术文档、实施文档、 用户使用手册等）。中标人在初验前10天提供一份详细的初验方案，经建设单位 认可后执行。由建设单位组织项目初步验收，初步验收通过后，即进入试运行阶段。试运行通过初步验收后，进入四个月的连续试运行期。在试运行期间，中标人一方面要提供足够的培训和技术支持，保障用户能够 正确的理解和使用系统，另一方面，要根据运行中出现的问题以及用户需求情况， 及时修改完善系统

33、。中标人应使任何故障或问题都能在48小时内被修复和解决， 并给出详细修复细节报告。试运行期内如出现重大故障，则试运行期从故障排除之日起重新计算，直到 系统连续两个月无重大故障为止。重大故障系指因中标人原因致使系统不能正常 运行，影响到买方系统软件的正常安装和运行。所有试运行期间系统的修改和软件变化都应在试运行结束后由中标人写入 操作和维护手册中。1.8.3.项目验收试运行期满合格可以进行项目验收。合格必须满足以下条件：已提供了合同的全部系统和资料；提交实施过程中所产生的全部文档，如技术文档、实施文档、用户使用 和操作手册等；从系统初验通过之日起，进行四个月的连续试运行，在此期间要保障系 统的正

34、常运行；安装、调试、测试和试运行时出现的问题均已被解决；最终用户单位出具的系统可正常运转的说明文件。系统通过项目验收后，进入质量保证期，质量保证期为36个月。1.9其它要求保密要求投标人必须对项目技术文件以及由建设单位提供的所有内部资料、技术文 档、数据和信息予以保密。投标人必须遵守与建设单位签订的保密协议，未经建 设单位书面许可，投标人不得以任何形式向第三方透露本项目标书以及本项目的 任何内容。投标人在应答时必须说明具体的安全保密管理措施和技术方案，确保安全 保密承诺得以落实。项目文档要求投标人应负责编写本项目有关的建设、开发、架构方案。投标人提供的书面技术资料应包括项目开发及维护所涉及到全

35、套文件。投标人应向最终用户提供安装调试过程中的各种文档资料，以便采购人 今后能掌握操作和维护方法。4 .投标人在投标文件中应列出其所提供的技术资料的详细清单。包括文档 名称、内容、提交的时间和方式等。所有技术文件必须是中文。项目开发的所有技术文档资料和项目管理文档资料包括但不限于：项目任务书；项目实施方案；（3）需求分析、概要设计、详细设计文档；（4）用户手册；（5）软件源代码详细说明、源代码编写标准及技术报告；（6）软件开发期间的测试计划、测试用例和测试报告；（7）软件的质量保证计划和质量管理文档；（8）系统部署配置和管理维护手册；（9）系统培训材料；（10）系统扩展所需文档；（11）系统备

36、份恢复手册；（12）软件的项目开发总结报告；（13）与合同标的服务相符的中文技术资料，包括系统的操作手册、使用说 明、维护指南和服务手册等资料。案例要求提供五年内与本项目招标内容相关的高校建设成功案例，需提供合同关键页 复印件（包括但不限于项目名称、项目建设内容、项目进度安排、合同双方签章） 以及结项验收报告等。2. POC要求投标人应在开标日期之前完成POC (Proof of Concept)原型系统的部署和调 试。在开标现场，根据建设单位提供统一的数据、方案和测试用例，由投标人根 据测试方案操作，专家现场进行测评。实现技术要求POC系统需实现用户和权限管理，用户、角色及权限能够灵活配置，各用 户只能访问其对应角色可以访问的数据，使用其角色可以使用的功能。另外集成 的应用还需要体现“呈现即可用，可用才呈现”。对于POC系统中的要求应尽可 能的全部满足。移动应用管理客户端展示使用一个ios或者android设备，通过“理工身份证”完成移动应用管理客户 端登录，不同用户看到针对自己角色所发布的应用不同。移动门户应用集成用“理工身份证”登录移动门户后，点击我的账户，展示账户信息包括但不限 于“教师职工号(学生学号)、校园卡号、姓名、性别、