华中科技大学信息化项目申报书.docx

申请编号:
华中科技大学
信息化工程申报书
□论证版本口终审版本
工程名称：
工程建设单位：（盖章） 工程负责人：
工程联系人：
联系 ：
Email 信箱：
申报日期：年—月—日表X02网络与信息化办公室编制
4.预算明细表（信息系统填写）:
预算明细表
功能模块
功能说明
工时
（人天）
价格（元）

10
四、工程采购相关1.购置清单及预算：
设备名称
规格型号
数量
单价
（万元）
总价
（万元）
所属采购需 求调查

2.*

工程建设总预算：（万元）
2.采购需求调查（一个采购工程对应一个需求调查，分次采购的请分别填写）:
2.1采购工程名称
采购预算万元
拟安装地点/部署环境

2.1.1安装使用环境及设施条件：对放置地点、面积，电力、温湿度控制等环境需 求和保障情况；对环保、消防平安有何影响及预防措施等。
2.1.2相关产业开展、市场供给情况、中小微企业的供应情况：
2.1.3同类采购工程（设备）历史成交情况，包括但不限于工程单位、建设时 间、成交金额、主要成交内容等，相关合同材料作为申报的附件：
2. L 4采用⑵L 5）所列2—3个厂家实施方案、性能、价格分析比拟：
122.1. 5可供货厂商调查概况（选择的调查对象一般不少于3个,并应当具有代表性）
公司1名称

企业所属行业
口制造业；口信息传输业（包括电信、互联 网和相关服务）；□软件和信息技术服务业； 口其他行业：
企业类型
大型/中型/ 小型/微型
报价明细 （含品牌型号）
（另附表）
总价
（万元）
运行维护方案

免费质保期
月
升级更新方案

同类采购工程历 史成交情况
包括但不限于工程单位、建设时间、成交金额、主要成交内容等， 相关合同材料作为申报的附件。
后续备品备件、
耗材采购方案及 费用情况

13
公司2名称

企业所属行业
制造业
信息传输业（包括电信、互联网和相关服务） 软件和信息技术服务业
其他行业：
企业类型
大型/中型 /小型/微 型
报价明细 （含品牌型号）
（另附表）
总价
（万元）
运行维护方案

免费质保期
月
升级更新方案

同类采购工程历 史成交情况
包括但不限于工程单位、建设时间、成交金额、主要成交内容等， 相关合同材料作为申报的附件。
后续备品备件、
耗材采购方案及 费用情况

14
公司3名称

企业所属行业
制造业
信息传输业（包括电信、互联网和相关服务） 软件和信息技术服务业
其他行业：
企业类型
大型/中型/ 小型/微型
报价明细 （含品牌型号）
（另附表）
总价
（万元）
运行维护方案

免费质保期
月
升级更新方案

同类采购工程历 史成交情况
包括但不限于工程单位、建设时间、成交金额、主要成交内容等， 相关合同材料作为申报的附件。
后续备品备件、
耗材采购方案及 费用情况

15
五、工程实施计划16
建设阶段
建设内容
时间段
负责人员（在编在岗人员）
姓名
职务职称
工程申报
起草工程建设及论证方案

工程采购
采购意向公开（到达政府采 购限额标准,即货物服务预 算100万及以上），发起采 购流程、起草合同并签订

工程实施
配合承建商进行需求分析、 系统设计、开发、测试、初 验及上线/设备到货及平安 调试初验，人员培训

工程验收
组织、整理验收材料，资产 建账，财务申报

工程运维
系统维护更新、升级及配合 相关平安工作

备注

六、信息平安（仅对于信息系统工程，参考国家标准 信息平安技术网络平安等 级保护定级指南、信息平安技术网络平安等级保护基本要求）
信息系统业务描述
信息系统平安保护等级口一级；□二级；口三级
本工程信息系统在设计和实现过程遵循《华中科技大学信息系统建设与运行 维护平安技术规范》，具体如下：
一、总那么
1 .为提高我校信息系统（网站）的整体平安水平，根据《华中科技大学网络与信息 技术平安管理方法》（校信息化（2015） 7号）、《华中科技大学信息系统建设与运行维护 管理暂行方法》（校信息化（2017） 1号）等文件，结合学校实际，制定木规范。
2 .平安技术规范。技术规范是规定产品、过程或服务应满足技术要求的文件。信 息系统（网站）的平安贯穿软件系统的整个生命周期，学校各单位在建设与运行维护信 息系统（网站）的整个过程中需遵守本平安技术规范。
3 .基本原那么。信息系统（网站）的平安建设与运行维护应遵守“最小可用、不断更 新”的总体原那么。为确保信息系统（网站）平安运行，以最小可用的权限运行各种应用 和数据库、以最小可用的原那么定制各种平安配置，禁止任何不必要的额外权限。网络安 全技术日新月异，各种平安漏洞层出不穷，平安技术规范的内容必须与时俱进，满足“不 断更新”的原那么。
二、常规WEB应用服务器平安规范
1 .禁止采用失去技术升级支持的操作系统；禁止采用含有漏洞或失去技术支 持的各类应用程序（web、数据库等）、各类框架组件及第三方库，以上软件必须执行安 全配置和安装，禁止默认安装；
2 .所有软件（操作系统和其他应用程序、框架组件及第三方库）已安装最新的安 全修补程序（补丁最新）；
3 .原那么上禁止使用任何开源和研究性质的应用程序（wob、数据库等）、框架组件 及第三方库。确定必须要使用时开发方需承诺对其源代码已进行彻底分析了解，并自行 跟踪相关漏洞信息并保证及时修复漏洞，且不能影响到今后系统的正常功能使用。
4 .服务器开启防火墙，根据实际部署情况，设置防火墙访问规那么，关闭不使用的 端口，仅开放系统提供服务必须开放的监听端口。对于可限制访问源ip范围的端口， 开启防火墙规那么进行限制。
5 .关闭不使用的网络服务。
17
6 .开启操作系统各类日志记录，所有tl志保存6个月以上。
7 .尽量不要以操作系统管理员身份运行应用程序（web和数据库等），遵守最小可 用规范。
8 .数据库和应用系统如在同一台服务器，须采用本机回路地址进行访问；
9 .如前端及数据库分为不同服务器，须设置本机防火墙访问规那么，禁止非前端服 务器访问数据库网络端口。
三、Web平安配置规范
10 .根据Mb应用所选用的Web容器，按照相应的配置规范进行平安配置，如：IIS、 Apache> WeblogicTomcat> Jboss 平安配置等。
11 .如使用了其他插件、框架和第三方库，有平安配置规范的即按照要求配置。
12 .所有平安配置遵循最小可用原那么。
举例：采用第三方CMS模板搭建网站时，禁止默认安装，包括目录、权限、用户名 /密码以及功能设置等；删除各种默认安装的例程、调试/说明文档、数据库配置及管理 程序，如：Weblogic如不需要应关闭T3协议；删除Tomcat的manager/html登录页面 及相关默认测试页面；关闭网站的debug模式。
四、Web设计平安规范
系统中使用的其他排件、框架、第三方库和软件作为系统的组成局部，也必须满足 以下要求：
4・1用户登录认证
13 .强制口令复杂度要求，必须有密码复杂度检查模块，可检查用户口令是否符合 最短8位字符，包括大小写字母、数字、特殊字符等，不符合要求的密码不允许保存使 用。
14 .必需设置有效的验证码手段防止暴力破解，使用的图片验证码应当能抵抗自动 识别，但不影响普通用户的正常识别，应实现为长度至少4位旦包含字母的随机串，旦 使用扭曲、噪点干扰、字体变换、大小变换、位置变换等防自动识别的一种或者多种方 法。
15 .验证码内容不能与客户端提交的任何信息相关联。
说明：在使用验证码生成模块时不允许接收来自客户端的任何参数，例如：禁止通 过getcode. jsp?code=1234的URL请求，将1234作为验证码随机数。
16 .验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。
说明：在客户端网页.卜.点击鼠标右键、选择“查看源文件”时，必须看不到验证码 模块生成的随机数。
17 .验证码在一次使用后要求立即失效。
说明：不能依靠用户刷新操作进行失效处理，进行验证码校验后，立即将会话中的18
验证码信息清空，而不是等到生成新的验证码时再去覆盖旧的验证码，防止验证码屡次 有效。当客户端提交的验证码为空，验证不通过。
18 .用户名、密码和验证码必须在同一个请求中提交给服务器，必须先判断验证码 是否正确，只有当验证码检验通过后才进行用户名和密码的检验，否那么直接提示验证码 错误。
19 .同一客户端在屡次连续尝试登录失败后，服务端需要进行用户帐号或者是客户 端所在机器的IP地址的锁定策略，且该锁定策略必须设置解锁时长，超时后自动解锁。
注意：管理员帐号不能被锁定，只能锁定操作的客户端所在IP,这是为了防止系 统不可用。
20 .提示用户认证失败时不应明显区分是账号错误还是口令错误。
21 .在使用短信口令的程序中，应用软件需设定短信有效时间不超过10分钟，请求 间隔不少于60秒。
22 .所有登录页面的认证处理模块必须统一。
说明：可以存在多个登录页面，但是不允许存在多个可用于处理登录认证请求的模 块，防止不一致的认证方式。
23 .所有针对其他第三方开放接口的认证处理模块必须统一。
24 .认证处理模块必须对提交的参数进行合法性检查。
25 .最终用户接口和管理接口别离。
说明：最终用户接口和管理接口必需别离，防止相互影响，防止来自用户面的攻击 影响管理面以及越权攻击。尽量将最终用户接口和管理接口分别部署在不同的物理服务 器；如果部署在同一台物理服务器上，那么必须做到web服务别离。
26 .禁止在web系统中预留任何的后门帐号或特殊的访问机制。
27 .对于重要的管理事务或重要的交易事务要进行重新认证，以防范会话劫持和跨 站请求伪造攻击。
28 .管理页面建议实施强身份认证。说明：如双因素认证、SSL双向证书认证、生物 认证等；还可以通过应用程序限制只允许某些特定的IP地址访问管理页面，并且这些 特定的IP地址可配置。
29 .如果长期不登陆默认账号应停用处理。
4. 2会话管理
设置有效的会话管理及访问控制机制，防止越权提权等：
30 .在同一登录过程中，当某用户认证成功后，应为此用户创立新的会话并释放原 有会话，创立的会话凭证应满足随机性和长度要求，防止暴力破解、遍历和猜想攻击；
31 .应将用户登录成功后所生成的会话数据存储在服务器端，并确保会话数据不能 被非法访问，当更新会话数据时，应对数据进行严格的输入验证，防止篡改和非法重用19
填写说明
1 .凡申请学校信息化经费用于建设校园信息网络、大型管理信息系统、网络与信息 平安保障体系、信息化相关支撑体系和基础平台等，均需编制信息化工程建设方 案，填写本表。按照《华中科技大学信息化工程管理方法》（校信息化（2015） 1 号）和《华中科技大学信息化经费管理暂行方法》（校信息化（2016） 4号）由网 络与信息化办公室进行工程和经费管理。
2 .工程建设单位应为学校二级单位或校机关部处，工程负责人应为单位负责人，项 目建设坚持单位主要负责人负责制。工程建设内容所涉及业务应符合工程建设单 位的职责业务范围。信息化工程涉及多个单位共建或者参与建设的，由相关单位 协商确定牵头单位，由牵头单位作为工程建设单位，编制工程建设申报书。
3 .表中设备泛指硬件、软件、信息系统等服务采购或工程建设。名称应准确、简洁， 在本工程建设方案及所有附件资料中名称务必保持一致。在学校相关职能部门后 续采购、建账、管理环节中，货物、服务、工程名称均以此为准。需要办理进口 免税的设备名称必须符合海关管理规定。
4 .设备的性能指标、技术要求、功能要求、服务维保要求等，以通过专家论证并根 据专家论证意见修订完善的《信息化工程申报书》为准。学校相关职能部门后续 采购、验收、效益评估等管理环节，均以此为主要依据。工程建设单位按《政府 采购需求管理方法》（财库（2021） 22号）、《华中科技大学采购管理方法》（校财 [2018]2号）实施采购。
5 .涉及信息系统或软件建设的工程，申报内容需按《华中科技大学信息系统建设与 运行维护管理暂行方法》（校信息化（2017）1号）《中华人民共和国数据平安法》
《中华人民共和国个人信息保护法》做好前期规划和方案设计，按《政府采购需 求管理方法》要求做好采购需求调查。
6 .工程建设单位应先将工程申报书及附件的电子文档发送给网络与信息化办公室 信息化工程邮箱（xxhxm@ ）,经网络与信息化办公室预审通 过之后，工程负责人签署意见并加盖单位公章。网络与信息化办公室组织专家论 证。工程论证通过，网信办报校领导批准后，工程可以启动。
7 .封面论证版本为专家论证用，终审版本为论证会后根据专家意见的修改稿。
攻击；
32 .在B/S结构的应用程序中，当处于登录状态的用户宜接关闭浏览器时，应提示 用户执行平安退出或者自动为用户完成退出过程，确保本次会话的平安终止，防止非法 重用攻击；
33 .所有登录后才能访问的页面都必须有明显的“注销（或退出）”的按钮或菜单， 如果该按钮或菜单被点击，那么必须使对应的会话立即失效。
说明：这样做是为了让用户能够方便地、平安地注销或退出，减小会话劫持的风险。
34 .当Web应用跟踪到非法会话，那么必须记录口志、清除会话并返回到认证界面。
说明：非法会话的概念就是通过--系列的服务端合法性检测（包括访问未授权资 源，缺少必要参数等情况），来检测发现非正常请求产牛.的会话。
35 .必须设置会话超时机制，在超时过后必须要清除该会话信息。
36 .在服务器端对业务流程进行必要的流程平安控制，保证流程衔接正确，防止关 键鉴别步骤被绕过、重复、乱序。
说明：客户端流程控制很容易被旁路（绕过），因此流程控制必须在服务器端实现。
37 .如果产品（如嵌入式系统）无法使用通用的除b容器，只能自己实现Web服务, 那么必须实现会话管理，并满足以下要求：
1）采用会话cookie维持会话。
2）生成会话标识（session ID）要保证足够的随机、离散,以便不能被猜想、枚举, 要求session ID要至少要32字节，要支持字母和数字字符集。
3）服务端必须对客户端提交的session ID的有效性进行校验。
4. 3权限管理
38 .对于每个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是 否合法、用户是否被授权可执行这个操作。
说明：防止用户通过直接输入URL,越权请求并执行一些页面或servlet；建议通 过过滤器实现。
39 .禁止利用js在用户端进行控制及验证用户登录是否成功和角色身份等，防止逻 辑越权攻击。
40 .授权和用户角色数据必须存放在服务器端，不能存放在客户端，鉴权处理也必 须在服务器端完成。
说明：禁止将授权和角色数据存放在客户端中（比方cookie或隐微域中），以防止 被篡改。
41 . 一个帐号只能拥有必需的角色和必需的权限。一个组只能拥有必需的角色和必 需的权限。一个角色只能拥有必需的权限。
42 .系统中任何资源（目录、文件、数据等）的访问权限均按照最小可用原那么进行定20
制设置
43 .对于运行应用程序的操作系统帐号，不应使用“root”、“administrator”、 "supervisor"等特权帐号或高级别权限帐号，应该尽可能地使用低级别权限的操作系 统帐号。
44 .对于应用程序连接数据库服务器的数据库帐号，在满足业务需求的前提卜，必 须使用最低级别权限的数据库帐号。
说明：根据业务系统要求，创立相应的数据库帐号，并授予必需的数据库权限。不 能直接使用“sa”、“sysman”等管理帐号或高级别权限帐号。
五、Web编程平安规范
系统中使用的其他插件、框架、第三方库和软件作为系统的组成局部，也必须满足 以下要求：
45 .必须对所有用户产生的输入进行校验，一旦数据不合法，应该告知用户输入非 法并且建议用户纠正输入。
说明：用户产生的输入是指来自text、pas sword textareas或file表单域的数 据；必须假定所有用户产生的输入都是不可信的，并对它们进行合法性校验。
46 .必须对所有服务器产生的输入进行校验，一旦数据不合法，必须使会话失效，并 记录告警日志。
说明：服务器产生的输入是指除用户产生的输入以外的输入，例如来自hidden fields、 selection boxes、 check boxes^ radio buttons、 cookies、 headers、 热点链接包含的URL参数的数据或客户端脚本等；必须假定所有服务器产生的输入都是 被篡改过的、恶意的，并对它们进行合法性校验。
47 .不能依赖于客户端校验，必须使用服务端代码对输入数据进行最终校验。
说明：客户端的校验只能作为辅助手段，减少客户端和服务端的信息交互次数。
48 .如果输入只允许包含某些特定的字符或字符的组合，那么使用白名单进行输入校 验。如果输入为数字参数那么必须进行数字型判断。如果输入为字符串参数那么必须进行字 符型合法性判断。
说明：可定义一个合法字符集。对于一些有规那么可循的输入，如email地址、日期、 小数等，使用正那么表达式进行白名单校验。
49 .校验输入数据的长度。
说明：如果输入数据是字符串，必须校验字符串的长度是否符合要求，长度校验会 加大攻击者实施攻击的难度。
50 .校验输入数据的范围。
说明：如果输入数据是数值，必须校验数值的范围是否正确，如年龄应该为0〜150 之间的正整数。
21
51 .对用户输入进行严格有效过滤防止sql注入，xss跨站脚本，命令执行，crsf跨 站请求伪造等，建议采用白名单过滤策略；禁止动态构建XPath语句。
说明：和动态构建SQL一样，动态构建XPath语句也会导致注入漏洞（XPath注入）。
52 .禁止在 请求中以明文或可逆编码（如base64、url编码等）的形式传递SQL 语句到后端程序代入执行，禁止由Web前端直接生成和传递SQL语句到数据库进行执 行。
53 .数据库查询必须采用预编译和参数结构化查询。
54 .在源代码中尽量采用相对路径。
55 .禁止使用方式访问文件和目录。
56 .禁止将未经筛选的用户输入直接存储于数据库中。
57 .不回显各种调试、报错信息（如：断点，printf等调试信息）及注释信息，系 统需删除系统默认安装的各种例程、文档及管理程序；
58 .控制上传点，对于上传文件类型进行严格控制（禁止仅使用js进行控制），必 须在服务器端采用白名单方式对上传或下载的文件类型、大小进行严格的限制。上传目 录不能有执行权限，原那么上不允许有未经登陆验证的上传点。
59 .禁止以用户提交的数据作为读/写/上传/下载文件的路径或文件名，以防止目录 跨越和不平安宜接对象引用攻击。
60 .在注释信息中禁止包含物理路径信息、数据库连接信息和SQL语句信息。对于 静态页面，在注释信息中禁止包含源代码信息。对于动态页面不使用普通注释，只使用 隐藏注释。
61 .版本归档时，必须删除开发过程（包括现场定制）中的临时文件、备份文件、无 用目录等。
62 .禁止将敏感文件（如日志文件、配置文件、数据库文件等）存放于Web内容目录 下。
六、敏感数据保护
敏感数据包括但不限于：口令、密钥、证书、会话标识、License、隐私数据（如短 消息的内容）、授权凭据、个人数据（如姓名、住址、 等）等，在程序文件、配置文 件、日志文件、备份文件及数据库中都有可能包含敏感数据。
63 .禁止在代码中存储敏感数据。
64 .禁止密钥或帐号的口令以明文形式存储在数据库或者文件中；密码必须进行带 salt的哈希之后保存数据库。
65 .禁止在cookie中以明文形式存储敏感数据。
66 .禁止在隐藏域.中存放明文形式的敏感数据。
67 .禁止用自己开发的加密算法，必须使用公开、平安的标准加密算法。
22
68 .禁止在日志中记录明文的敏感数据。
69 .禁止带有敏感数据的Web页面缓存。
70 .带有敏感数据的表单必须使用 -P0ST方法提交。
71 .在客户端和服务器间传递明文的敏感数据时;必须使用带服务器端证书的SSLo
72 .禁止在URL中携带会话标识（如jsessionid）o
说明：由于浏览器会保存URL历史记录，如果URL中携带会话标识，那么在多人共用 的PC上会话标识容易被其他人看到，一旦该会话标识还在其生命有效期，那么恶意用户 可以冒充受害用户访问Web应用系统。
73 .禁止将对用户保密的信息传送到客户端。
七、日志审计
本节的日志审计是针对呢b业务应用，不包括对操作系统、容器的平安审计。 对于操作系统和Web容器的平安审计，可以参考对应的操作系统和Web平安配置规范。
74 . Web应用日志信息必须包括但不限于：时间，源目的ip,访问URL及 方法, 返回状态码等。
75 .应用服务器必须对平安事件及操作事件进行日志记录。
说明：平安事件包括登录、注销、添加、删除、修改用户、授权、取消权限、鉴权、 修改用户口令等；操作事件包括对业务系统配置参数的修改，对重要业务数据的创立、 删除、修改、查询等；对于上述事件的结果，不管是成功还是失败，都需要记录口志。
76 .平安日志必须包括但不限于如下内容：事件发生的时间、事件类型、客户端IP、 当前用户的标识、受影响的个体（数据、资源）、成功或失败标识、启动该事件的进程标 识以及对该事件的详细描述。
77 .严格限制对平安日志的访问，仅最高权限管理员可见。
78 .所有日志必须保存6个月以上
八、其他
79 .局部或全部使用 WebSocket、WebService 及 DWR （Direct Web Remoting）等其 他非常规卷b应用通讯协议、服务及框架的系统，也必须完全符合以上二至六章所列规 范。
九、平安自检
各建设单位在申请信息系统上线之前，必须按以上内容完成平安自查，并提交华中 科技大学信息系统（网站）平安自检表，通过平安自检的系统才能开始申请上线流程， 网络与计算中心负责对华中科技大学信息系统（网站）平安自检表进行不定期更新，以 最新发布的自检表为准。
23
七、工程建设绩效目标申报（申报金额＞20万的必填，三级指标和指标值可自 定义）24
建设总体目标

一级指标
二级指标
三级指标
指标值
产 出 指 标
数量指标
XXX设备购置数量
＞套（台）
XXX功能模块购置或开发数量
＞（个）
服务完成工作量
>
用户和服务对象

核减率（（申报预算•成交金额）/申 报预算）
W %
质量指标
验收通过率
100%
合格率
> 100%
系统免费维保期
> 月
信息系统 性能指标
系统响应时间

用户覆盖范围
＞人
信息系统稳定性、平均无故障时间；
> 月
系统平安性（通过代码审计、平安扫 描、渗透测试）
是
数据规范性和准确性按教育部和学校 信息标准
是
系统保密性
按合同执行
时效指标
工程购置进度
按照工程实施期限完成
工程验收时间
按时完成验收
资产入库入账情况
按时入库、入账
本钱指标
成木是否合理
是
性价比是否最正确
是
效 益 指 标
社会效益 指标
改善广大师生员工的教学、科研条件
较显著
是否有利于社会安定、协调
是
生态效益 指标
设施设备节能降耗达标率
100%
污染化学废料是否及时处理
是
可持续影响 指标
设备购置类工程持续发挥作用期限
>年
学校基本办学条件和服务社会的能力
提升
满意度 指标
服务对象 满意度指标
学生满意度
>95%
教职工满意度
>95%
八、工程建设牵头单位及参与单位的职能及意见
同意按学校信息化工程和信息平安管理相关规定，组织保障本工程实施和运 维，保障网络与信息平安。
本单位将建立健全工程管理和信息平安管理责任制，严格按照经专家论证和 学校审定的工程建设方案组织实施，并在工程建成后，加强工程运维和信息平安 管理，保障并落实运行维护费用，严格执行政府采购、工程监理、合同管理等制 度。
工程建设单位：（盖章）工程负责人（签字）：
单位主要负责人（签字）：
年 月 日工程参与各单位意见：
单位盖章工程参与各单位负责人：
年 月 日九、审批单位意见
网络与计算中心技术审核意见：

单位盖章：
签字：
年月
日
网络与信息化办公室意见：

单位盖章：
单位负责人（签字）：
年月
日
25
一、工程基本情况3
工程名称

工程类型
口硬件；口软件；口工程；口服务；口信息系统（可多项选择） （信息系统平安保护等级：口一级；口二级；□三级）
工程属性
口延续工程，上期工程编号; □新建工程；□其他
工程建设单位

工程负责人
姓名

职务职称

办公

移动

Email信箱

工程联系人
姓名

职务职称

办公

移动

Email信箱

信息系统运行 维护责任人
姓名

职务职称

办公

移动

Email信箱

信息系统用户
用户范围：口教职员工；□学生；口其他
访问限制：口校园网；口互联网；口内网
访问量预估：人/天
工程总预算
（万元）
工程简介：
二、工程建设的必要性及建设目标必要性：（从工程的背景、依据，现有系统存在的问题和差距，工程建设的意义等方 面阐述，延续工程应说明原设备或信息系统建设和使用的情况）
建设目标:
三、工程建设方案1.建设内容
业务需求：（说明做什么：计划面向的用户和服务对象、需实现信息化管理的业 务流程、拟采集的数据和统计分析的目的）技术方案：（说明怎么做：信息系统介绍主要功能模块、系统集成方案，业务流 程图，数据生产、调用和共享模式；通用硬件设备逐项介绍主要功能及技术指 标，原那么上不得指定品牌和型号，成套系统或还需逐项列出主要构件名称、预算 和性能指标要求。采购时，采购需求技术指标应与本工程申报论证通过的技术指 标一致）
信息系统对接与数据共享要求（信息系统建设填写）
（1）与学校统一身份认证系统（）对接要求。所有师生均通 过学校统一身份认证系统登录相关系统。系统不得自带师生用户信息的管理功能 （修改个人信息、修改密码等）。如果系统中有统一身份认证系统所没有含有的 用户信息（例如外聘人员、临时人员、社会人员等）可建立该局部人员信息的管 理功能和专用登录入口。
（2）与学校统一信息门户系统（）对接要求。在统一信息门 户系统上建立单点登录链接（师生通过统一身份认证系统账号登录）；为信息门 户提供相关数据推送服务或提供Web Services接口，以便师生登录统一信息门户 后，可直接显示相关的统计数据。
（3）与学校网上办事大厅信息平台（）对接要求。直接面向 师生的服务流程原那么上在网上办事大厅上实现，跨部门的流程必须在网上办事大 厅上实现，只涉及到本部门审批的面向师生的流程可以在业务系统里实现，但必 须为网上办事大厅的流程提供数据共享、交换、或Web Services服务，接收网上 办事大厅流程运行完成后的数据并存储在本系统中，实现数据的统计查询。具备 条件的，应和网上办事大厅在待办、评价等方面进行深度集成。
（4）与学校移动门户一“华中大微校园”（微信企业号）对接要求。开发 的面向师生的移动端应用按照华中大微校园的UI规范和集成规范进行开发，并 与华中大微校园集成，不再开发独立的APP或建立微信服务号。
（5）与学校统一通讯平台对接要求。原那么上各业务系统不再建设短信、微 信、邮件等发送和接收通道，如果需要并经学校网信办同意，可调用学校的统一 通讯平台，为用户发送短信、微信、邮件等消息。
（6）与学校岗位角色系统对接要求。系统涉及的校级公共岗位角色数据必 须从学校角色岗位系统中同步获取；具有维护权限某类岗位角色的业务系统，必 须将更新后的岗位角色数据写回到学校角色岗位管理系统中。
（7）与学校待办中心系统（或网上办事大厅的待办模块）对接要求。业务 系统中具有事项处理功能的，必须通过调用学校待办中心系统的接口，将发给用 户的待办信息发送到待办中心，由师生等用户在待办中心进行查看和点击处理
（处理仍然在业务系统中），待办处理完成后将信息或数据发送给待办中心，由 待办中心将待办事项从待办列表中去除。具体实现方式以学校待办中心的技术标 准为准。业务系统本地认可保存待办功能。
（8）与学校智能问答平台对接要求。针对业务系统日程咨询的问题，为智 能问答平台提供相关的智能问答库，并随业务系统的升级不断优化，修正和补 充。
（9）对接智能推荐平台对接要求。将系统中业务应用、运营管理、校内外 资讯等涉及师生日常工作学习的信息资源聚合到智能推荐平台，由其按个人特征 实现“千人千面”的智能推荐效果。
（10）与其他业务系统对接要求。必须完成与 系统、系统、系统等业务系统的对接，根据需要为上述业务系统提供接口服 务或调用上述业务系统接口完本钱业务系统的需要。
（11）按照教育部及学校信息标准建立数据库。按照教育部及学校的信息标 准（代码标准、数据标准）等设计数据库。
（12）与学校基础数据库的共享要求。按照学校基础数据库建设的有关规定 要求（《华中科技大学信息技化架构建设条例》（校信息化（2014） 1号）、《华中 科技大学基础数据库建设与使用管理暂行方法》（校信息化（2016） 6号）等）、 “一张表”、“一张图”工程等要求，为学校基础数据库提供相关数据；系统从学校 基础数据库通过中间库或接口调用的方式获取所需的公共基础数据或其他业务系 统产生的数据，基础数据集其他业务数据库已有数据不重复在本系统中采集；按 照数据同步规范的技术要求，进行数据同步。为学校大数据分析平台提供所有的 本系统产生的相关数据。
（13）信息系统的UI开发要求。严格遵循“智慧华中大信息系统UI设计规 范”（学校网上办事大厅申请下载），应用页面开发遵照要求文档中的总体布局、 首页、页面、入口、列表、详情、筛选、上传、搜索、表单、弹出页、校历、日 程、卡片等界面规范，以加强全校信息系统界面风格的统一性、规范性。
（14）系统建设与运维要求。严格按照《华中科技大学信息系统建设与运行 维护管理暂行方法》（校信息化（2017） 1号）规定的流程对系统进行开发、测 试、上线、运行和维护等。
2.系统拓扑图：（网络拓扑图、软件主要功能业务流程图、或与外围其它设备的连 接示意图；多台设备的连接拓扑图）3.信息化资源规划（数据库及信息资源设计、需要使用学校公共或其他部门的数 据等信息资源、本系统作为权威源产生的可供其他系统使用的数据等信息资 源）：
业务系统基础信息
用户类型
口在编教职工口全日制学生 □其他
系统开发语言
□ .NETQJAVADPHP□其他
系统运行环境
□Windows 0Linux DUnix□其他―
数据库系统
0Oracle OSOL Server CMySQL □其他
需对接的学校信息化基础应用系统
□统一身份认证口信息门户口微信门户口统一通讯平台
□其他（可写多个）
数据交流信息
系统产生数据

系统拟申请使 用学校基础数 据或其他信息 系统的数据 （详见网上办
事大厅共享数 据申请）
口人事：
□本科生：
□研究生：
□ 科研：
□ 教学：
□ 设备：
□ 财务：
口其他信息：
请列举需求信息的字段，可另附页
数据使用
遵循
口最少够用的原那么；
□信息系统非必要不收集或从数据库导入个人身份证信息；
口个人信息非必要不全量展示和批量导出；
□个人信息的查询和导出仅限特定人员
所需硬件资源（来源A：已有；B:申请学校信息化基础平台提供；C：采购）
名称
数量
来源
指标
服务器

CPU:主频个数 核数
存储

应用数据：―GB数据库数据：―GB
数据库系统

名称： 版本:
9