大学数字化校园基础平台及应用系统建设项目实施方案.doc

《大学数字化校园基础平台及应用系统建设项目实施方案.doc》由会员分享，可在线阅读，更多相关《大学数字化校园基础平台及应用系统建设项目实施方案.doc（33页珍藏版）》请在三一文库上搜索。

1、安徽师范大学数字化校园基础平台及应用系统建设项目实施方案编制人员：丁峰编制部门：苏皖大区项目名称：安徽师范大学数字化校园基础平台及应用系统建设项目文件名称：项目实施方案文件修改记录表序修改人修改内容批准人修改日期版本号1丁峰新建刘亮明2013-7V1.0345文件审批表单位名称负责人签字签字日期安徽师范大学信息管理中心金智教育目 录1项目内容41.1基础支撑平台建设41.2业务系统集成41.3第三方软件52项目组织72.1金智项目组织72.2金智项目组成员72.3安徽师范大学项目成员（待补充）83实施策划93.1总体思路93.2实施模型93.3里程碑计划104信息标准实施144.1实施约定14

2、4.2标准范围144.2.1学校公共标准(完全个性化部分)154.2.2人员相关标准154.2.3业务活动相关标准164.3标准引入机制164.4主要风险165软硬件平台实施185.1实施思路185.2硬件部署方案185.2.1数据库服务器195.2.2身份认证服务器205.2.3数据交换服务器205.2.4信息门户平台服务器205.2.5HTTP服务器215.2.6信息门户、应用服务器集群215.2.7刀片机箱及辅助设备225.3实施风险236应用系统集成实施256.1实施思路256.2实施风险257校方配合需求277.1信息管理中心277.2待集成应用部门288项目管理298.1沟通机制2

3、99项目培训309.1培训思路309.2培训范围3010交付物3110.1交付程序3110.2交付文件311 项目内容安徽师范大学基础平台及应用系统建设项目(以下简称项目)主要包括以下内容建设：1.1 基础支撑平台建设序建设内容主管部门内容说明1信息标准建设及信息标准管理系统信息管理中心按照教育部和国家相关标准，并结合学校实际情况，制定安徽师范大学信息标准，建设信息标准管理系统。2基础数据平台信息管理中心1、 基础数据集成平台。2、 基础数据交换平台。3、 现有主要应用系统集成。3身份认证管理平台信息管理中心实现身份信息的统一认证和授权，统一存储和管理。 4校园信息门户平台信息管理中心面向各类

4、不同身份用户提供个性化的校园网信息、服务和资源。1.2 业务系统集成序号集成系统业务部门内容说明1.人事管理系统人事处实现对人事系统的数据集成：1. 保证教职工用户关键身份数据的完整性。2. 如条件具备，可在门户中实现人事待办事宜的提醒。3. (依据最终确定的集成方案定)2.财务管理系统财务处实现对财务查询系统的数据集成、认证集成和门户集成：1. 保证学生收费/教师工资数据。2. 如果条件具备，则实现用户登录门户后，可通过快速通道直接进入财务查询系统。3. 如条件具备，可在门户中实现交费通知、工资查询通知等服务。(依据最终确定的财务集成方案定)3.资产管理系统资产与设备管理处实现资产系统的数据

5、集成、认证集成和门户集成：1. 如条件具备，保证实现校内资产数据、资产保管情况等信息的及时同步。2. 如条件具备，则实现用户登录门户后，可通过快速通道直接进入资产查询系统。3. 如资产相关数据具备条件，则可在门户中提供个人保管资产情况、各部门资产拥有情况查询(关键指标)等服务。(依据最终确定的集成方案定)4.教务系统教务处实现对教务系统的数据集成、认证集成和门户集成：1. 保证学生用户关键身份数据的完整性。2. 保证用户登录门户后，可通过快速通道直接进入教务系统。3. 如条件具备，可在门户中实现学生个人相关信息查询、选课提醒、相关课程安排。(依据最终确定的教务集成方案定)5.一卡通系统实现对一

6、卡通系统的数据集成、认证集成和门户集成：1. 保证教职工和学生用户关键身份数据的完整性。2. 保证用户登录门户后，可通过快速通道直接进入一卡通系统。3. 如条件具备，可在门户中实现教职工和学生个人相关消费流水和考勤等方面的信息查询。(依据最终确定的一卡通系统集成方案定)6.研究生管理系统研究生处实现研究生管理系统的数据集成、认证集成和门户集成：1. 如具备条件，保证用户身份信息等数据可以及时同步到研究生教务与学生管理系统。2. 如条件具备，则实现用户登录门户后，可通过快速通道直接进入研究生教务与学生管理系统。3. 如条件具备，在门户中实现研究生教务与学生管理系统的信息待办和提醒等功能。(依据最

7、终确定的研究生管理系统集成方案定)7.科研管理系统科技处实现科研管理系统的数据集成、认证集成和门户集成：1. 如具备条件，保证用户身份信息等数据可以及时同步到科研管理系统；同时科研管理系统可以及时将科技信息及时同步到共享库。2. 如条件具备，则实现用户登录门户后，可通过快速通道直接进入科研管理系统。3. 如条件具备，在门户中实现科研管理的信息待办和提醒等功能。4. (依据最终确定的科研管理系统集成方案定)8.图书借阅系统图书馆实现图书借阅系统的数据集成、认证集成和门户集成：1. 保证用户身份信息可以及时同步到图书借阅系统。2. 保证图书预约、借阅相关信息可以及时同步到共享数据库。3. 如条件具

8、备，则实现用户登录门户后，可通过快速通道直接进入图书借阅系统。4. 如条件具备，在门户中实现预约、欠书、欠费的提醒服务等。(依据最终确定的图书馆集成方案定)9.办公系统校长办公室实现办公系统的数据集成、认证集成和门户集成：1. 如具备条件，保证用户身份信息等数据可以及时同步到办公自动化系统。2. 如条件具备，则实现用户登录门户后，可通过快速通道直接进入办公自动化系统。3. 如条件具备，在门户中实现办公系统的信息待办和提醒等功能。(依据最终确定的办公系统集成方案定)1.3 第三方软件软件内容主管部门内容说明数据集成平台信息管理中心Oracle Data Integrator 服务器操作系统信息管

9、理中心Linux ，Redhat AS 5 U5身份认证组件信息管理中心Sun Access Manager ，LDAP Server（Direct Server）应用服务器信息管理中心IBM WebSphere ND数据库信息管理中心Oracle数据库集群软件信息管理中心Oracle RAC2 项目组织2.1 金智项目组织安徽师范大学数字化校园项目组组建思路如下：A. 接口清晰明确：对于本期所涉及的新建系统，双方明确项目经理作为项目的接口负责人，在项目验收前，全程负责双方资源的协调和配合。B. 统一策划：项目整体计划由金智项目经理和金智项目管理小组、学校项目管理小组进行统一策划，各组成部分的

10、设计和实施方案由双方项目管理小组进行统一评审，保证系统的整体性和有序性。C. 本地化实施：为保证系统实施及运行期间的用户响应效率，金智本项目的实施由项目经理、项目助理、驻场服务人员为主，由公司产品团队、开发团队和质量团队提供及时的配合和支持。2.2 金智项目组成员角色人员联系方式职责说明项目管理组丁峰项目管理组长，协同内部资源，监控项目进展，关注用户价值刘亮明13851489966 负责工程中心资源调度安排，参与项目设计和策划周平负责产品部资源调度安排，参与项目设计和策划，落实开发计划石奇波13913952797 负责质量部资源调度安排和项目过程监控刘秀负责项目变更管理和确认项目实施组丁峰项目

11、经理，对进度及用户使用情况负责谢玉龙18355127799 实施人员，参与现场实施，配合项目经理工作黄林林13365698887 实施人员，参与现场实施许文榕数据库部署工程师陈天顺EAI平台部署工程师邹墨林应用中间件部署工程师张亮评审测试人员缪晶晶13851782976质量保证人员、配置管理人员客户经理刘秀已有负责项目商务协调，关注客户满意度需求分析丁峰已有负责整体需求调研(含策划)参与需求、设计和验证谢玉龙已有参与需求、设计和验证运维服务王华锋运维部经理2.3 安徽师范大学项目成员（待补充）角色人员联系方式项目总负责人项目管理小组平台实施硬件/网络工程师数据库管理员统一身份认证平台负责人系统

12、管理员统一信息门户平台负责人系统管理员共享数据平台/信息标准平台负责人系统管理员运行服务台人员已有系统集成人事管理系统业务部门负责人建设部门协调人系统管理员财务管理系统业务部门负责人建设部门协调人系统管理员资产管理系统业务部门负责人建设部门协调人系统管理员教务系统业务部门负责人建设部门协调人系统管理员一卡通系统业务部门负责人建设部门协调人系统管理员研究生管理系统业务部门负责人建设部门协调人系统管理员科研管理系统业务部门负责人建设部门协调人系统管理员图书借阅系统业务部门负责人建设部门协调人系统管理员办公系统业务部门负责人建设部门协调人系统管理员3 实施策划3.1 总体思路安徽师范大学本次的数字化

13、校园建设项目是学校站在全校角度进行规划建设的项目，这决定了该项目无论在外部参照系上还是在内部理解一致性上均存在一定的风险，也正因如此，在校级层面，目前预期能够解决的问题(项目价值点)主要在于：1. 能够建立一套全校的基本信息标准体系以及面向全校权威数据的共享数据库，这一工作完成后的最大受益者是后续应用系统建设，新系统建设时，将会事半功倍，不仅能够保证信息的无二义性表达、提高信息共享效率，更可以大幅度缩短应用系统实施周期。2. 能够为全校师生建立校园网内唯一数字身份，解决早期系统建设需要用户记忆多套用户名和密码，而且每进入一个系统，就需要进行一次登录，导致每建成一个系统，对用户而言就是多了一个负

14、担。而对于新系统建设者而言，不仅在系统中要花费大量精力在如何保证认证安全、如何收集并及时更新用户数据，而且因不同厂商的技术水平不一致，极有可能因一个系统的安全设计不到位，导致用户关键信息的泄漏，造成学校的被动。能够为全校师生建立统一校园网内信息和服务的单一访问入口，让所有需要访问校园内信息的用户都只需要记住一个地址，使用一个帐号就可以访问到所有自己有权限访问到的资源。同时，后续任何新的系统和服务上线，只需实现和门户的集成，并利用门户的推送功能，将希望用户获得的信息主动的推送给用户，这也会使得各建设部门能够把更多的精力放在如何创新和改进自己的业务和服务模式上。3. 鉴于以上情况，为保证安徽师范大

15、学项目能够成为一个成功案例、让安徽师范大学信息化建设尽早在全校高度上进入良性循环，在本期项目建设中，需要全校各相关部门能够按照以下实施模式提供配合。3.2 实施模型本项目整体实施模型，具体阶段定义如下：3.3 里程碑计划里程碑子里程碑点工作内容初步计划结束完成项目启动完成项目启动准备 双方签署工程启动确认单。 双方讨论确定项目实施方案,并签字确认。2013年8月上旬完成项目内部启动 完成项目里程碑策划(参数估计)。 完成项目风险管理列表。 完成项目评审计划策划。 完成项目裁减表。 通过公司内部启动评审。2013年8月上旬召开校内项目启动会 双方讨论确定启动汇报材料(重点:预期效果、组织架构、整

16、体计划、配合要求)。 完成校内启动会组织(重点:落实配合部门及配合责任)。 确认汇报机制（双周例会和网络中心讨论项目进展情况，月例会向分管校领导汇报执行情况）2013年9月初系统平台部署完成部署规划 双方讨论确定项目部署规划,并签字确认。2013年8月中旬完成平台客户化 双方讨论确定UI设计。 校方完成平台初始化数据收集和整理。2013年9月上旬完成平台部署阶段 双方根据部署规划完成平台部署和检测。 公司完成部署报告准备。 校方完成部署报告审核，并签字确认。2013年9月上 确定信息标准完成信息标准调研和设计 公司提供信息标准集供双方参考。 公司对学校数据编码情况、数据流向和业务部门需求进行全

17、面调研 双方根据调研表分析结果，确定标准增删内容，分析需设计内容，并初步确定责任部门。 公司提供所遵循标准类别建议及标准设计建议表。 责任部门根据自己的业务特征给出标准初始数据及后续维护责任人。 在责任部门难以配合时，信息管理中心给出取舍策略，如果属于必建标准，需及时提交校领导进行协调落实。 进行标准公示，各部门反馈修改意见。2013年10月下旬完成信息标准实施 双方完成参照标准导入工作。 双方完成标准初始化和相关的标准维护权限设置。 培训标准维护责任人使用标准维护工具。2013年11月中旬确定共享模式完成信息资源规划 公司对学校数据编码情况、数据流向和业务部门业务需求进行全面调研。 公司最终

18、给出安徽师范大学信息标准和信息系统模型。2013年10月中旬完成共享需求调研和设计 公司提供共享信息集供双方参考。 双方围绕数据集成范围及集成调研表分析结果，确定增删内容，分析需设计内容。 公司完成共享信息集增删改部分设计。 信息管理中心完成共享信息集设计文档审核，通过后签字确认，作为实施的指导文档。2013年11月上旬完成共享模式实施 公司完成缺省部署的共享模式集更新。 信息管理中心结合双方确定的共享信息集，对部署的共享库结构进行检查确认，输出检查确认表。2013年11月中旬建设信息门户完成信息门户需求调研和设计 完成信息门户需求调研 完成信息门户UI需求确认2013年10月下旬完成信息门户

19、开发和实施 双方共同完成信息门户服务内容初始化。 根据调研结果完成信息门户实施工作。2013年12月中旬应用系统集成完成应用集成调研 公司提供应用集成需求调研表，用于进行摸底调研。 双方通过访问系统、分析样例数据、用户拜访等方式，共同完成各系统集成需求摸底调研。 公司完成集成需求调研反馈表的分析，完成各系统集成备选方案设计，形成各系统集成方案讨论胶片(可由双方共同讨论定稿)。 协调业务部门及系统供应商共同讨论确定各系统最终集成方式，由公司形成应用系统集成方案及应用集成实施计划，提交公司质量部发起内部评审。 三方(公司、信息管理中心、业务部门)组织联合评审，评审通过后，签字确认。 如果供应商配合

20、涉及商务问题，由信息管理中心和业务部门协调进行落实。2013年9月下旬完成应用集成实施 遵循确认后的应用集成方案及集成实施方案，三方进行集成实施。 如果涉及认证集成，三方责任分别是:1公司指导供应商(或用户)完成认证集成实施；2供应商(或用户)完成系统改造和验证；3信息管理中心开通业务系统认证集成系统帐号和访问权限(帐号规则建议:业务系统中文缩写+AMConn)。 如果涉及数据集成，三方责任分别是：1公司完成集成分析，输出源到目标的映射关系表及标准转换对照表；2供应商(或用户)开放系统访问权限，参与转换对照表编制，并对自己系统中的表结构进行解释说明；3信息管理中心需要保证数据集成服务器到集成系

21、统业务库之间的访问通道的稳定性。 如果涉及界面集成，三方责任分别是：1公司完成对应应用界面集成配置；2供应商(或用户)保证集成页面的可独立运行，对于需要带入参数的页面，需要明确参数格式；3信息管理中心需要保证门户服务器到集成系统应用服务器间的访问通道的稳定性。 如果涉及门户开发，三方责任分别是：1公司完成应用开发和测试，并完成到测试服务器的部署和验证；2业务部门用户完成应用功能的检查确认，并明确应用的授权要求；3信息管理中心完成功能检查确认，并完成在运行服务器的部署和权限配置。2013年12月上旬完成应用集成验证 对于认证集成，双方检查认证集成效果。(方式是使用业务系统最大权限帐号登录门户，再

22、进入集成业务系统，点击所有应用页面，确认集成有无遗漏，输出模块检查确认表)。 对于数据集成，双方检查数据集成完整性(主要通过记录条数进行总体检查，通过抽样数据比对进行映射关系的检查)。 对于门户集成，双方检查集成效果。(主要检查页面布局效果、应用界面风格的一致性) 对于门户开发应用，双方检查功能和权限的正确性，对于访问量较大的应用，双方共同完成性能测试，形成性能测试报告。 检查通过后，信息管理中心签署应用系统集成确认报告，标识着应用系统的集成阶段完成。2013年12月中旬正式试运行系统进入正式试运行 公司提交正式试运行申请单。 信息管理中心签署正式试运行申请单。 信息管理中心面向全校用户正式发

23、布系统的访问域名、帐号规则及支持热线。2013年12月下旬项目整体验收完成项目整体验收 公司提交项目验收申请单。 双方讨论确定项目验收会议汇报材料(重点:系统使用状况、用户价值实现情况、后续发展规划) 信息管理中心组织项目验收会议，验收通过后，双方签署正式的项目验收报告。2014年3月确定项目售后计划 验收通过后，双方讨论确定售后服务计划。 公司完成售后服务计划编制，提交公司内部评审。 信息管理中心审核售后服务计划，并签字确认售后服务计划。2014年3月完成项目内部结项 项目组提交项目内部总结报告，通过内部评审。 公司内部将项目转为售后服务项目进行统一管理和跟踪。2014年4月4 信息标准实施

24、4.1 实施约定信息标准是整个项目的基础，在信息标准实施中考虑以下基本约定：1. 约定范围：对于只涉及到一个业务系统的标准，不在学校层面进行定义和管理。2. 唯一性原则：任何一个标准需要有唯一的维护责任部门，对于无法确定维护主体或责任主体无法承诺及时更新时，需要提交学校工作小组进行协调。3. 数据优先：所有标准先和责任部门确定初始化数据，由项目组完成初始化实施和备份，保证后续系统的正常上线。4. 只增不改：为防止业务数据出现紊乱，所有标准一经发布，只允许增加和停用，不允许修改和删除。5. 及时更新：所有标准一经发布，将会按照需要自动同步到所有需要这些标准的系统。6. 单一入口：体现在两个方面，

25、首先所有校级标准维护模块和数据集中在共享平台的管理系统中，其次对于由业务部门维护的标准，会考虑将标准的维护界面融合到对应业务系统中，避免标准维护人员频繁切换界面。4.2 标准范围项目信息标准建设重心是构建一个可扩展的信息标准管理平台，并围绕本期项目建设内容，原则上最终所确定的共享模式中涉及的标准，在标准库中都有其标准结构，对于标准数据建设的重点主要在：学校个性化的公共标准、人员相关标准以及本期集成中已经有成熟业务系统中涉及到的业务活动标准。4.2.1 学校公共标准(完全个性化部分)4.2.2 人员相关标准4.2.3 业务活动相关标准4.3 标准引入机制4.4 主要风险风险影响对策组织机构编码无

26、单位能够拍板，长期议而不决 共享库中产生垃圾数据 无法按部门进行统计分析由校领导组织协调，给明确结论。(南师模式)人员编码定了，但已有业务部门无法执行 无法给出统一认证帐号 集成中产生大量冗余数据 集成后影响原有系统运行收集现有数据进行充分分析基础上，制定能够确保唯一编码规则，并通过学校正式发文，给出业务部门明确的整改时间。(同济模式)业务相关编码无法确定对学校负责的部门 对应编码无维护责任人 对应编码无人敢用策略一.由校领导组织协调，给明确结论。策略二.放弃业务相关编码确定了责任部门，但业务部门坚持只提供标准数据，不同意承担维护责任 对应编码无法及时更新 运行中会影响到使用编码的部门和系统策

27、略一.由校领导组织协调，给明确结论。策略二.由系统管理员代为维护编码确定后，初次集成通过建对照表的方式完成了，但业务系统保持不规范的操作，继续产生新的非标准数据 集成完成后,数据是对的，但一段时间后，数据又不一致了。 使用部门越来越不信任共享库中的数据策略一.改造业务系统中不规范操作部分。策略二.明确由业务部门维护集成对照表。5 软硬件平台实施5.1 实施思路软硬件平台的实施和维护质量，直接决定了系统运行可靠性，软硬件平台通过接受性测试后，需要正式交接给用户系统管理员，交接时间点必须在应用系统投入试运行前，并共同定义出相应的运行管理规定，其中重点需考虑以下几个问题：1. 建立使用申请管理制度：

28、软硬件平台交接后，所有对于运行环境的更新需要提供更新请求，明确更新原因、更新内容、更新时间和影响，在得到系统管理员的许可后才可以进行具体操作。2. 建立使用登记机制：对于已交接给用户的系统，所有基于其上的操作必须留下详细的操作登记。3. 建立定期巡检机制：系统管理员必须根据交接时提供的系统巡检表对软硬件平台进行定期巡检，以及时发现并消除系统故障隐患。4. 公司提供详细的系统日常管理维护工作内容，技术指导手册和相关培训。5.2 硬件部署方案5.2.1 数据库服务器建议选用2台品牌小型机系统（高配置PC服务器），组建负载均衡系统，部署数据库服务。指标项建议配置要求基本配置品牌小型机系统（或高配置P

29、C服务器）CPUCPU主频2.0GHz配置中CPU内核数量4颗内存要求配置内存32GB系统硬盘配置硬盘4块单盘容量146GB在线热拔插FC硬盘集成硬件RAID卡, 可以实现RAID 0/1I/O子系统千兆以太网口 4个HBA 4GB/s光纤通道接口 4个操作系统UNIX、Solaris投资允许的情况下我们建议数据库服务器采用扩展性更强、安全性更高、运行更稳定的小型机系统。5.2.2 身份认证服务器建议选用2台刀片服务器中，组建负载均衡集群，部署统一身份认证服务。指标项建议配置要求基本配置品牌刀片式服务器，标准机柜安装CPUCPU主频2.0GHz配置中CPU内核数量2颗内存要求配置内存6GB系统

30、硬盘配置硬盘2块单盘容量146GBI/O子系统千兆以太网口2个5.2.3 数据交换服务器建议采用刀片服务器中的1组服务器部署数据交换服务。指标项建议配置要求基本配置品牌刀片式服务器，标准机柜安装CPUCPU主频2.0GHz配置中CPU内核数量2颗内存要求配置内存6GB系统硬盘配置硬盘2块单盘容量146GBI/O子系统千兆以太网口2个5.2.4 信息门户平台服务器建议采用刀片中的1组服务器对信息门户服务进行部署。指标项建议配置要求基本配置品牌刀片式服务器，标准机柜安装CPUCPU主频2.0GHz配置中CPU内核数量2颗内存要求配置内存6GB系统硬盘配置硬盘2块单盘容量146GB在线热拔插SAS硬

31、盘集成硬件RAID卡, 可以实现RAID0/1I/O子系统千兆以太网口2个HBA 4GB/s光纤通道接口 2个5.2.5 HTTP服务器建议采用刀片服务器中的1组服务器部署HTTP服务。软件平台选用IBM WebSphere http系统。指标项建议配置要求基本配置品牌刀片式服务器，标准机柜安装CPUCPU主频2.0GHz配置中CPU内核数量2颗内存要求配置内存6GB系统硬盘配置硬盘2块单盘容量146GB在线热拔插SAS硬盘I/O子系统千兆以太网口2个5.2.6 信息门户、应用服务器集群建议采用刀片中的8组服务器对应用服务进行部署，并共同组建负载均衡集群。建议配置如下：指标项建议配置要求基本配

32、置品牌刀片式服务器，标准机柜安装CPUCPU主频2.0GHz配置中CPU内核数量2颗内存要求配置内存6GB系统硬盘配置硬盘2块单盘容量146GB在线热拔插SAS硬盘集成硬件RAID卡, 可以实现RAID0/1I/O子系统千兆以太网口2个HBA 4GB/s光纤通道接口 2个5.2.7 刀片机箱及辅助设备指标项建议配置要求机箱每机箱支持14片刀片服务器,本次公用1套机箱支持冗余管理模块配置,可以级联冗余热插拔电源，支持N+1、N+N电源冗余模式，N2冗余热插拔风扇，配置数量4个支持内部LAN/SAN交换机和Pass-thought设备配置2个LAN交换机模块，支持冗余配置2个SAN交换机模块，支持

33、冗余可通过浏览器管理机箱内全部设备, 支持跨机箱管理, 支持冗余配置前端访问液晶显示屏, 可显示系统状态及故障信息, 可配置机箱参数配置独立的远程管理控制端口，支持远程监控图形界面, 可实现与操作系统无关的远程对服务器的完全控制，包括远程的开机、关机、重启、更新Firmware, 虚拟KVM, 虚拟软驱, 虚拟光驱等操作各应用服务器节点与HTTP服务器共同组建成应用服务器集群环境，部署如下图所示：应用服务器集群部署示意图在部署环境中，有关身份认证的信息、文件信息和数据的处理，由统一的身份认证服务器、NAS服务器和数据库服务器来处理，应用服务器主要用来处理用户的请求，其实体并不包含用户信息、业务

34、数据等。应用服务器对文件系统的访问采用NAS方式进行。所有的请求通过HTTP服务器来做负载均衡转发。在实际的部署环境中，一个应用不是需要部署到所有的应用服务器节点上面，需要根据应用的访问规模来确定应用服务器规模。对于某些特殊的应用，可能只是在某个时间内需要支持高的并发访问量， 这个时候就需要能够快速的动态增加应用节点。对于应用系统升级和维护可以使用单元管理器（即DMGR管理控制台）来进行，但前提条件是管理人员需要掌握IBM WebSphere的一般管理知识；另外，我们可以采用JMX方式来进行调用接口来完成相应的管理，这样就需要有一个统一的管理系统来负责所有应用系统的日常管理。5.3 实施风险风

35、险影响对策一段时间后运行环境开始紊乱 系统开始不稳定 系统无法维护运行环境交接后： 所有操作必须得到系统管理员许可 所有操作必须留下操作登记。应用局部升级更新后，导致整体开始不稳定 用户产生抱怨减少小变更，加强变更管理： 所有变更需要先通过测试环境验证 对运行环境变更前做好备份硬件损坏导致系统崩溃乃至无法回复 系统稳定性 建设阶段做好交叉备份 运行前尽可能解决存储及备份问题目前认证平台对同时在线用户数支持能力有限 系统真正成为所有用户的浏览器首页或成为习惯后，会导致部分用户无法登录 增加认证服务器内存配置 缩短用户身份有效时间6 应用系统集成实施6.1 实施思路已有系统集成实施，遵循以下思路：

36、1. 实用原则：围绕用户体验，对于合同中所约定系统集成范围，集成内容确定和集成方案设计时，以实用为原则，对于影响用户体验的集成内容，需要保证集成效果。2. 优先级约定：本次项目实施涉及多个应用系统集成，将依据以下因素确定优先级：a) 信息类别，所有与人的基本信息有关的系统，只要具备条件优先集成。b) 用户关注，对于师生用户及领导最为关心的系统，优先集成。c) 使用状况，对于实际使用起来的系统(通过点击率和数据变化周期识别)，优先集成。d) 用户配合，对于业务部门比较积极，并愿意协调厂商资源进行配合的，对应业务系统优先集成。e) 结构稳定，对于数据结构和功能框架已经基本稳定的系统，优先集成。3.

37、 变更约定：在系统集成通过用户接受性测试后，如果被集成系统因升级或其他原因导致需要重新进行集成实施乃至调整集成方案，首先需要有提前量(至少1周以上时间)进行通知，其次这部分变更引起的工作量需要得到校方的认可。6.2 实施风险风险影响对策业务部门不理解、不配合 无法进行集成调研 无法接触到系统环境 在项目启动会上，明确配合要求、时间和配合责任人。 信息部门和项目组预先准备，先通过基础情况调研完成摸底，结合摸底情况共同完成预先设计，提供用户可选方案，降低业务部门配合压力。 将给予配合的部门集成做出效果，在校级会议上多表示认可。业务部门无法协调原建设厂商进行配合 方案讨论难以形成结论 集成实施难以配

38、合 通过学校或信息部门对厂家施加压力。 准备对应系统升级和集成配合预算。 采用新的系统进行替换。业务系统没有正式运行 集成后数据没有质量 系统可用性无法保障，导致用户怀疑学校的平台 把握业务周期，配合业务部门推进系统使用。 可以先集成，借助门户和身份认证的好处，反过来推进业务系统的使用。业务系统处于调整改进中 无法形成稳定的集成方案 反复进行集成实施 采用分块实施策略，先确定总体集成思路，将稳定部分的方案先确定、先实施。 约定完成整改期限，大系统上线前，如果业务系统尚未完成整改，则暂时放弃遗留部分的集成，留在大系统深化改进阶段进行处理。 让信息部门具备应用集成实施的能力，在具备条件时可以进行集

39、成实施。业务系统变更信息无法及时告知信息部门 会导致系统突然出现问题，如数据没有了、界面不见了等情况，造成用户的困惑 在启动会上，明确对变更的通知和管理机制。 信息部门保持和业务部门的沟通，及时捕捉到变化信息。 大系统中提供明确的异常类别提醒，缩短问题定位时间。业务系统用户习惯了原来的入口，不愿意通过门户进入 会影响用户对学校大系统的体验和认可 在学校系统初步上线后，可以考虑逐步关闭原有系统的对外域名服务。 在门户中，把握住用户价值，让用户能够获得更多对自己有帮助的服务内容。部分业务部门可能因保密要求为理由，拒绝开放相应数据的集成权限 共享数据中数据不完整，影响后续跨部门应用建设 通过校方组织

40、协调会，明确提供和保密的责任。 信息管理中心和项目组和业务部门介绍清楚系统的安全保障机制。7 校方配合需求7.1 信息管理中心阶段名称任务名称需要配合工作项目启动完成项目启动 签署项目外部启动确认单。 讨论确认项目实施方案。 明确校方实施组织架构。 明确系统管理和运行维护人选。 协调部门组织召开项目协调会。平台部署完成部署规划 提供校园信息服务系统地址及DNS规划、存储使用需求。 对项目组提供的系统部署规划方案进行审核，并签字确认。完成平台客户化 参与系统界面风格讨论、提交图片供设计并确认。 和项目组共同完成系统服务内容布局设置。完成平台部署阶段 根据项目组提交的申请和格式，提供相应的初始化数

41、据。 参与平台部署。 检查确认平台部署结果，审核部署报告，通过后签字确认。确定信息标准完成信息标准调研 确定信息标准调研范围。 确定标准负责部门，协调部门配合。完成信息标准设计 协调部门确认信息标准设计。 代表学校签署共享信息标准设计文档。完成信息标准实施 参与信息标准的初始化实施。 检查确认标准实施结果。确定共享模式完成共享需求调研 协同相关责任部门配合项目组完成共享需求调研。 审核共享数据模式设计文档，通过后签字确认。完成共享模式实施 参与共享模式的初始化实施。 检查确认共享模式实施结果。建设信息门户完成信息门户需求调研和设计 确定信息门户需求 确定信息门户UI设计完成信息门户开发和实施 共同完成信息门户服务内容初始化。 检查确认信息门户实施工作。应用系统集成完成应用集成调研 配合项目组进行系统调研，并协调已有系统厂商人员的配合。 审核系统集成方案，通过后签字确认应用集成方案。 对于不具备集成条件的业务系统，给出明确的处理意见，并签署商务备忘。完成应用集成实施 协调用户及厂商人员的配合。 参与应用系统集成实施。完成应用集成验证 对集成实施成果进行确认，通过后签署应用集成报告。 接受对系统日常管理维护的管理培训。完成应用集成维护 负责面向