学生工作综合管理平台建设方案一、项目概述学生作为学校最主要的组成成员，从入校注册到毕业离校过程中，会产生大量冗余的、重复的数据资源，使得学生管理工作千头万绪。
对于学生管理部门来说，无法实时了解宿舍卫生情况、宿舍日常行为、勤工助学等各业务实时进展和结果。
无法实时监控业务进展和获取实时统计数据。
对于学生群体来说，都需要线下重复填表，对于申请事务无法了解办理进展，无法及时获取相关事务消息和通知。
对于学生家长来说，无法实时了解小孩在校的表现。
为解决以上用户困境，继续建设学生一体化管理与服务管理系统。
提供学生在校期间除课堂学习之外的其他所有事务。
二、建设目标学生工作管理系统是以学生为中心，整合教学、教务管理、学生管理等信息，面向学生、教师、家长、企业等众多用户建立学生信息统一视图，覆盖学生在校全生命周期的，具备深度、广度上的服务拓展能力，提供高效、便捷的多维度信息展示和一站式服务的信息化管理系统。
三、建设内容学工管理系统、素质拓展管理系统及学生预约平台等相关系统四、功能描述1、技术要求（1）总体要求：系统必须基于Java平台开发。
系统服务端能够跨平台运行，如Linux、HP-UNIX、AIX等操作系统，保证其灵活性。
系统采用B/S结构，系统只需安装在服务器上，数据库也统一集中在服务器上存储和管理，客户端用户通过互联网或在局域网内部就可以通过输入用户名和密码来访问学生工作综合管理系统。
（2）服务端技术要求：系统采用框架结构，整合布局、视图、持久层、连接池、缓存、安全、日志等框架技术，降低系统耦合度。
系统采用成熟度高，业内认可度高的软件项目主流实现技术。
（3）客户端技术要求：操作界面应简洁美观，操作响应迅速、简单易懂。
跨浏览器一致性，字体图标一致性，支持主流浏览器（IE10+、360安全、360极速和chrome）。
（4）数据库技术要求：选用 ORACLE数据库作为持久层。
提供数据库部署、管理和扩展解决方案。
（5）成熟度要求：学生工作综合管理平台的建设需采用成熟的技术，且需要有在全国范围内、湖南省内有高校成功应用并验收的案例。
（6）信息标准要求：系统的开发必须严格遵循教育部最新发布的教育信息化行业标准，并符合学校要求的相关信息标准。
（7）二次开发要求：项目建设提供方应有足够的研发力量，能根据用户的个性化需求，在规定的时间及时响应并完成个性化的开发设计。
2、性能要求五、详细参数(一) 学生一体化管理平台六、安全设计系统设计规范、安全、稳定，达到网络信息安全等级保护测评二级以上要求。
七、商务及资质要求1、投标人须符合《中华人民共和国政府采购法》第二十二条规定的要求。
2、本项目不接受供应商为代理商和联合体形式参与投标。
3、提供前一年度的财务审计报告。
八、评分标准本项目采用综合评分法，由评委会对所有有效投标进行详细的评分，采用百分制计分方法。
评标时，评标委员会各成员遵循公平、公正、择优原则，独立对每个有效投标人的标书进行评价、打分，评标委会按评审后最终综合得分由高到低顺序排列名次，并推荐出中标人。
如得分相同的，按投标报价由低到高顺序推荐中标人。
涉及以上评分的证明材料需在投标文件中提供复印件，并在投标截止前携带原件或公证件至开标现场备查，不提供的不得分。
九、验收要求（一）系统实施与培训服务要求1、验收原则验收参与部门：项目主管部门、系统使用单位、供应商代表、专家小组。
在软件开发合同的签订阶段就提出软件验收项目和验收通过标准的意见；在软件的需求评审阶段，仔细审阅软件的需求规格说明书，指出不利于测试和可能存在歧义的描述；在开发方开发完软件并经过开发方内部仔细的测试后，对完成的软件进行评审，提供完整的测试报告给用户方，由用户方判断是否进行验收。
2、验收项目1）功能项测试：对软件需求规格说明书中的所有功能项进行测试；2）业务流程测试：对软件项目的典型业务流程进行测试；3）适应性测试：参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境。
4）文档测试：用户文档包括安装手册、操作手册和维护手册。
对用户文档测试的内容包括：操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；用户文档描述的信息是否正确, 是否没有歧义和错误的表达；用户文档是否容易理解，是否通过使用适当的术语、图形表示、详细的解释来表达；用户文档对主要功能和关键操作是否提供应用实例；用户文档是否有详细的目录表和索引表。
3、验收错误描述软件错误的严重性等级：1级：不能执行正常功能或重要功能，或者危及人身安全；2级：严重地影响系统要求或基本功能的实现，且没有办法解决；3级：严重地影响系统要求或基本功能的实现，但存在合理的解决办法；4级：使操作者不方便或遇到麻烦，但不影响执行正常功能或重要功能；5级：其它错误；错误与严重性等级对应关系：1级错误包括: 没有实现或错误地实现重要的功能；业务流程存在重大隐患；软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况；软件在操作过程中由于软件自身的原因对系统或数据造成破坏；在现有的软、硬建设环境下不能实现应有的功能；特殊软件在操作过程中可能危及系统和人身安全等。
2级错误包括: 没有实现基本功能，并且不存在替代办法；没有实现重要功能中的部分功能，并且不存在替代办法；业务流程衔接错误；密钥以明文方式存储；没有留痕功能；用户的权限分配不合理；在现有的环境下，不能实现部分功能且没有替代方案；没有满足系统的性能要求。
3级错误包括：与第2 级别的错误相对应的，而第3 级错误则存在替代方法；对误操作或错误操作没有提示，导致非法数据进入数据库。
4级错误包括：界面不友好、前后风格不一；中英文混杂；查询结果输出不直观等。
5级错误包括：安装手册、操作手册、维护手册中的描述错误。
对发现的每一个错误都要确定相应的严重性等级，如错误的级别和数量在合同可接受的范围外，用户方认为软件不可验收，在规定的时间内全面整改软件，提交给软件评测中心再次进行完整的验收测试。
（4）验收标准验收项目的划分参照GB/T 16260 标准。
在该标准中，将软件的质量特性分为6 大特性、21 个子特性，而对于具体的软件，并非都要进行这21个特性的测试和评价。
本项目选取的是最通用的子特性部分，针对各种不同的软件，可以对验收项目进行剪裁或扩充。
验收标准：不允许存在1 级和2级错误，而3 级错误的数量则可按本标准确定或由用户方和开发方根据软件的规模和复杂程度进行商定，并在软件开发合同中明确地列出。
在软件验收测试中，测试的依据包括软件的投标文件、开发合同、需求规格说明书, 同时还包括特定软件的相关行业标准。
用户方根据错误报告中每一级别的错误数量和错误清单与软件开发合同中的验收标准进行对照，如错误的级别和数量在合同中没有约定，可按本办法的规定进行。
用户方认为软件可以验收，但要求开发方对错误报告中的所有错误进行整改，或者提交给软件评测中心进行回归测试，确认错误报告中的所有错误全部改正方可；如错误的级别和数量在合同可接受的范围外，用户方认为软件不可验收，要求开发方在规定的时间内全面整改软件，或提交给软件评测中心再次进行完整的验收测试。
（5）验收资料项目验收申请报告；招标文件、投标文件；相关合同；各种技术文档；软件需求及设计说明书；数据及数据库设计要求说明书；操作手册；用户手册；用户使用评价过程意见；必要的软件接口规范；安装盘；专家组要求的其他材料。
（二）售后服务要求本项目一旦运行起来，就占有很重要的地位，稍有差错就会引起各方面的反应和损失，所以系统的售后维护服务和技术支持工作也应有足够保障。
厂商作为具有丰富信息化项目经验的系统集成和软件开发企业，应通过自身不断的努力和原厂商的鼎力支持；针对客户的不同的系统的需求，制定不同的运行保障方案，建立完善的本地售后服务体系。
除了上述的有关承诺之外，厂商关于服务保障体系的描述应具体包括如下内容：1、运行保障机构主要描述公司对于对本项目的运行保障能力描述，包括技术支持队伍、能力配置、人员配置、机构情况，在本地有无技术支持中心、地点设在何处等。
2、运行服务内容应确保本次项目系统安全稳定的运行，并承诺提供三年免费服务，售后服务期自验收合格之日开始计算。
方案中应对服务的范围和内容进行详细阐述，并至少包括以下内容：1）缺陷管理：针对本次项目系统中存在的bug、缺陷，不论在保期内、外，均应持续提供修正与消缺服务。
2）应急故障处理：系统运行环境出现故障或意外情况导致系统不能正常运3）系统升级：提供项目系统的软件补丁版本的升级服务。
4）需求变更：对于我校自身业务规则的变化导致的非模块级功能需求变更、性能要求提升导致的部署结构变化，可经双方协商提供限定次数的服务支持。
5）文档服务：整个服务过程均需有完善的文档记录，便于跟踪、分析问题；对各项服务提供详细的书面报告，包括故障处理报告、健康巡检报告、系统性能检测调优报告、维护总表报告、服务年度报告等。
6）运行支持：对系统运行过程中师生用户及业务部门的问题提供解答和问题解决跟踪，对于关键业务点的上线推广与运行提供现场保障。
7）现场保障：在迎新离校等业务重要节点，提供现场技术支持。
3、服务请求流程需对用户支持或维护请求处理的流程进行详细描述。
4、服务请求方式对我校与厂商联系沟通的方式进行详细描述，以方便我校便利的获取各类即时的和非即时的服务支持。
厂商提供的服务请求方式至少应包括：服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站。
厂商是否设有用户投诉受理电话，对用户的意见做出反应。
如果有用户投诉受理电话，请描述以下内容：电话号码（或传真）、投诉中心负责人和受理答复时间。