免费智能真题库 > 历年试卷 > 系统规划与管理师 > 2022年上半年 系统规划与管理师 下午试卷 案例
  第2题      
  知识点：   IT服务部署实施计划   运维   知识转移   规范化   恢复   培训   实施计划   信息化   业务系统   应急响应

 
【说明】
某大型企业去年信息化投入大，完成了重点核心业务系统的建设。由于应急相应预案制定得不充分并且未开展演练，出现了系统性故障时，部分关键的应用系统不可用且在12小时内未能完成恢复业务，给企业带来了较大损失。
为加强该企业IT服务的规范化水平，IT服务部门管理人员小王，规划了今年的IT服务部署实施计划，在部署实施计划中包含了服务团队组建计划、知识转移计划、培训计划、工具采购部署、测试上线计划、服务计划过程绩效指标。
在应急响应预案制定过程中，与IT服务总监、客户接口人、IT恢复小组组员和运维工程师等充分沟通，明确需求与职责。
 
问题：2.1   (10分)
(1)IT服务部署实施计划阶段包括的的活动。
(2)IT部署实施阶段计划中所遗漏的工作内容。
 
问题：2.2   (11分)
(1)制定应急预算的原则。
(2)结合案例，有哪些情形是需要制定应预案的?
 
问题：2.3   (4分)
部署过程中与干系人达成共识的选择正确的是()(以下有四个正确的选项，请选出对应的选项)
A.开展原因和目标
B.项目范围
C.人员培训计划
D.公司战略目标
E.项目初步实现所要求的条件
F.公司组织结构图
G.项目交付物与其约束条件
H.持续改进的相关方法
 
 
 

   知识点讲解    
   · IT服务部署实施计划    · 运维    · 知识转移    · 规范化    · 恢复    · 培训    · 实施计划    · 信息化    · 业务系统    · 应急响应
 
       IT服务部署实施计划
               IT服务部署实施计划的目的
               IT服务部署实施计划的目的是确保部署实施的过程在有序、可控的条件下顺利地进行。部署实施，需要一个好的计划，计划是部署实施计划阶段的重要输出物。IT服务部署实施会参考项目管理方法，要在“一定的时间、范围、可接受的成本和质量标准”条件下，保证新服务或变更服务的顺利发布，并协调和组织构成服务的所有要素组件（包括过程、人员、技术和资源）。那么，如何在时间一定、资源有限的情况下，确保服务质量可控并达成既定的部署实施目标，就是部署实施计划作用的最直接、最重要的体现。在IT服务部署实施计划过程中，系统规划与管理师应当与所有干系人达成以下共识：
               （1）IT服务部署实施的目标，包括交付物、验收标准等。
               （2）IT服务部署实施详细的过程、时间及其投入。
               （3）IT服务部署实施如何实现所要求的要素，如所需要的人员、过程、资源、技术。
               （4）明确IT服务部署实施过程中需要了解项目进展信息的人员，确定相关的展现方式与时间，如确定项目进展信息的展现形式、汇报频度、汇报方式、送达人员等。
               IT服务部署实施计划的活动
               IT服务部署实施计划阶段的主要活动，包括计划沟通、计划制订、计划评估确认与计划修订，鉴于部署实施计划对整个部署实施过程具有重要指导意义，所以这是一个循环反复的过程。
                      计划沟通
                      在制订部署实施计划之前，需要分别与客户、规划设计环节的负责人和服务交付团队的负责人进行详细的沟通，各自的要点如下。
                      （1）在与客户的沟通中，着重了解客户的期望，以及客户能够提供何种资源上的支持。
                      （2）在与规划设计环节负责人的沟通中，着重了解规划设计的要素，确保无遗漏，避免出现与规划设计差距较大的情况；同时要详细了解规划设计环节中已经考虑到的风险控制机制，以确保在部署实施阶段将其导入生产环境。
                      （3）在与服务交付团队负责人的沟通中，着重了解其服务支持和提供的能力，以确保为其计划培训时间与培训内容，同时依据其服务能力定义合理的服务目标和实施里程碑。
                      计划制订
                      在制订部署实施计划的过程中，要进行周密的考虑，确保计划可执行、可监控，还要确保服务周期与相应的成本投入的合理性。部署实施计划主要包括如下内容：
                      （1）部署实施阶段的责任人。必须有明确的责任人对部署实施的全过程负责，既可以对全过程进行监控，也可以不断地推动全过程的顺利进行，并协调各团队对出现的问题，及时采取补救措施。
                      （2）角色与职责。
                      .系统规划与管理师：通常IT服务项目的部署实施负责人由该项目的系统规划与管理师来担任，也可以指派专门的部署实施经理作为部署实施的负责人，负责部署实施阶段各项具体工作的落地执行，同时负责与客户的沟通与协调，服务的测试与发布，对部署实施的结果负责。
                      .IT服务总监：实现IT服务项目组织的战略目标和利益，统一管理项目群，协调和调配项目所需要的内外部资源。负责与客户的沟通与协调，主要参与部署实施的阶段性回顾，对部署实施的计划和结果进行审核。
                      .客户接口人：负责提供服务交付团队所需的资源与支持。
                      .运维工程师：基础环境工程师、硬件工程师、软件工程师。
                      与此同时，IT服务团队在部署实施阶段还有可能与集成实施团队、设计开发团队、咨询服务团队发生协同关联关系。
                      （3）运维项目情况。主要描述部署实施范围，各阶段实施子目标的进度安排，以及如何确认它顺利完成。通常，客户对部署实施周期都会有明确的期望或要求，所以要基于总体目标划分各阶段的子目标，并且严格控制各阶段的周期长短，并定义好各阶段需要完成的里程碑。里程碑的好处是让部署实施团队、服务交付团队和客户对各阶段的收尾标识有明确的认知。
                      （4）各阶段的具体工作任务与负责人。部署实施计划一般分为两部分内容：关注如何交接现有的服务（或如何建立起新服务），关注服务管理体系的导入。这两部分内容可以视为两条主线，分别贯穿于部署实施的过程，且互相制约与影响，通常情况下，这两条主线并行执行。对于如何交接服务或如何建立起新服务，一般与具体的服务类型有关，如桌面管理服务相对于数据库管理服务，由于其服务类型不同，其计划也大不相同，所以无法给出标准化的描述。此处主要关注的是服务管理体系的导入。
                      作为一个计划，一定要有明确的任务列表与分工。此处列出IT服务部署实施计划中主要进行的工作内容。
                      .IT服务部署实施启动会。
                      .服务团队组建计划。
                      .服务团队培训与知识转移计划。
                      .服务工具采购、安装部署、测试、初始化与上线计划。
                      .核对服务目标。
                      .核对服务目录。
                      .设定服务模型。
                      .客户化服务管理过程。
                      .设定过程绩效指标。
                      .初始化服务文档体系与文档管理规范。
                      .初始化配置管理数据库（CMDB）。
                      .客户化服务规范。
                      .开发工作指导书和标准操作规范。
                      .编写服务计划。
                      .服务发布会／部署实施总结会。
                      上述各项工作内容均要指派到具体的责任人，并明确其交付物。
                      （5）交付物列表。此处仅列出上述部分的部署实施工作内容交付物。
                      例如，“服务团队组建计划”的输出物为服务团队组织结构、服务团队角色与职责，“服务工具采购、安装部署、测试、初始化与上线计划”的输出物如下。
                      .服务工具上线计划：应包含上线目的、上线时间、上线相关角色和职责定义、沟通计划、上线过程中的风险分析、回退计划、交付物列表和验收标准等上线关键要素。
                      .服务工具测试计划：应包含相关角色和职责定义、测试范围、测试环境、测试进度安排、测试项及具体测试方法等测试关键要素。
                      .服务工具测试报告：应清晰说明测试计划的完成情况、测试过程中发现的已知错误、测试结果的分析说明及测试结果的审核确认等主要内容。
                      .服务工具上线报告：应清晰说明上线计划的完成情况、上线结果的分析说明、上线过程中相关突发事件的总结与分析、配置管理数据库的更新情况汇总、上线过程中的相关资源支持情况、经验总结及改进建议等主要内容。
                      .服务工具操作指南：应包含发布范围、目标用户、工具简介、如何下载与安装、如何使用或常见操作方法、支持团队联系方式等信息。
                      .服务工具配置手册：应包含厂商、版本号、配置变更历史记录、客户化配置方法和说明等重要信息。
                      （6）交付物验收标准：交付物验收标准需要描述交付物的质量标准和交付形式。举例如下：如果交付物是文档，要对文档规范、文档包含的内容、交付形式是纸质还是电子介质等，进行明确说明。除上述验收标准外，若能同时设定交付物的验收方法，则更佳。切忌以超出自身服务能力范围的要求来设定交付物验收标准，这样会为部署实施收尾工作带来很大的困难。在设定验收标准时也需参考公司的内部管理要求。
                      （7）对客户的要求（客户的参与）：对部署实施而言，它是服务运营的初始化阶段，也是服务团队与客户的磨合期，这是一个双方互动的过程阶段，客户的协助与支持起着非常重要的作用。在部署实施计划中必须对客户方所要提供的资源和支持提出明确的要求，这需要进行细致的考虑，也需要与客户做深入的沟通，切忌提出不切实际的需求。同时，在把客户方提供的资源和支持视为输入时，需要明确计划的输出内容，让客户感受到他所提供的资源和支持是有价值的，也能够取得其最大化的支持。
                      计划评估与确认
                      IT服务部署实施计划制订完成后，系统规划与管理师要和IT服务总监、项目管理办公室（PMO）和客户接口人做充分的沟通并确认。项目干系人要对此计划的风险做评估，确保投入的资源可以按计划输出符合要求的交付物，以确保部署实施顺利完成。
                      若评估过程中发现有潜在的风险，则要进入计划修订环节。
                      计划修订
                      在计划评估环节，若发现潜在的风险或不合理的行动计划，则需要对计划进行修订。修订过程仍需要依据前述“计划制订”的要求进行仔细的梳理与编排，修订后再次提交评审。如此反复，直至IT服务部署实施计划得到了所有项目干系人的认可和确认。
               关键成功因素
               IT服务部署实施计划阶段的关键成功因素包括如下4项：①明确IT服务部署实施阶段的责任人。②明确IT服务部署实施范围、里程碑、交付物，以及交付物的验收标准。③对IT服务能力和资源合理准确的预测。④IT服务连续性的保障。其中，前两项在前面的“计划制订”中已经有了明确描述，本节主要对后两项进行说明。
               （1）对IT服务能力和资源合理准确预测。对IT服务能力和资源的准确预测是IT服务部署实施计划的成功要素之一。一方面，能力和资源是支撑计划能够得以实施的必要条件，只有在充足的能力和资源保障前提下，才可以按计划完成IT服务部署实施的过程；另一方面，IT服务部署实施的目标是IT服务运营的标准化与规范化，会为IT服务运营过程定义阶段化的服务目标，若没有充足的服务能力和资源支撑，也就无法在运营阶段达成预定义的服务目标。
               因此，IT服务能力和资源既指IT服务部署实施阶段的各种能力和资源（包括部署实施团队与客户提供的能力和资源），也指IT服务运营阶段的能力和要素（包括人员、技术、资源和过程4方面）。只有对IT服务能力和资源有了充分的、正确的预测与认知，才可以定义合理的目标，保证IT服务运营阶段有足够的能力按照预定义的“标准化”和“规范化”的轨道持续运行，即保障部署实施的成功实施。
               （2）IT服务连续性保障。在IT服务部署实施期间，如何保障IT服务的连续性是重要的关注点。例如，对于新老服务商的切换来说，在整个切换期间存在很多的风险，需要有充足的额外服务资源的保障，以应对在切换过程中的各种突发状况。对于新上线的应用系统，由于知识库或已知错误库还不完整，所以无法确保服务团队能够应付IT服务部署实施过程中的突发事件，此时需要制订相应的连续性计划／应急预案，以确保在出现突发事件时能够保障系统的服务不中断。可靠的连续性保障是用户满意度的关键之一，尤其是在IT服务部署实施期间，如果某IT服务提供方刚接管的服务即出现频繁的服务中断，将直接影响客户对该服务提供商的IT服务质量、IT服务能力的期望。
               因此，必须在IT服务部署实施的计划阶段，充分考虑服务过程中可能出现的突发状况，并预先定义好应急响应方法，并融入日常工作、故障响应、重点时段保障预案。应急响应所需的要素主要为：①风险评估。②应急响应的触发、通知机制。③制订应急预案。④成立应急响应组织，明确由何人负责启动该应急预案。⑤恢复服务所需的行动步骤和相应的责任人。⑥应急预案的培训与演练。⑦日常监测与预警。
               可能的风险与控制
               在IT服务部署实施的计划阶段，通常来说，可能存在的风险或问题包括：①IT服务部署实施计划的完整性和条理性。②IT服务部署实施计划本身的可用性。③IT服务部署实施交付物的可验收性。④与IT服务规划设计和IT服务运营的吻合性。
               （1）IT服务部署实施计划的完整性和条理性。常见的计划完整性问题包括未考虑IT服务部署实施期间的服务连续性、忽略了IT服务运营团队的培训、未考虑供应商的配合、未明确对客户的资源要求等方面。
               常见的计划条理性问题包括：①服务工具未上线即启动服务测试。②未定义服务目标即开始客户化服务管理过程。③过程与规范未开发完成即启动团队培训。④服务运营团队未组建完成即开始进行知识转移。
               上述问题均会导致计划的相关环节无法顺利衔接，以致计划部分或完全失效，部分资源频繁处于等待状态，无法正常工作，甚至出现“无用功”的情况。
               在此对“未定义服务目标即开始客户化服务管理过程”做详细说明：IT服务管理过程以及相关的资源配置、角色设定等都是为了支撑服务目标的达成，换句话说，有了服务目标，服务管理过程的规范化才有了明确的导向；进一步讲，服务管理过程是否能够有效地支撑服务目标的达成，需要进一步设定过程绩效指标（KPI），以便于定期考核并持续改进。
               （2）IT服务部署实施计划本身的可用性。可用性是指计划本身的可操作性、可交付性和可控制性。
               .可操作性：指所有的服务组件或服务资源，可以支撑在规定时间内的计划实施，且无职责的盲区或职责的重叠。这也是计划的常见风险之一，需要在计划完成后与职责相关方做充分沟通以排除风险。
               .可交付性：指计划的输出物是明确的、合理的，不超出能力范围，且责任人能够清晰地理解对交付物的要求。这也要建立在充分沟通的基础上，才可规避此风险。
               .可控制性：指各项计划不仅有责任人，还有专人负责全程监控、及时预警，并设有专人对交付物的质量做初步验收。这也是计划阶段最常见的问题之一，任何计划都需要有责任人、监控人和验收人，从机制上确保计划的顺利进行，缺乏此机制可能就会出现不可预见的风险。
               （3）IT服务部署实施交付物的可验收性。交付物的验收标准不明确是计划阶段最大的风险，这不仅会导致部署实施团队输出不合格的交付物，也会导致客户对交付物的理解偏差，对验收结果带来严重的影响。
               交付物的验收标准要清晰、明确、可量化，且可被测量，验收方式要具备可操作性，通常可以遵循SMART原则来进行设定。
 
       运维
        运维是运行维护的简称，是一种IT服务形态。在《信息技术服务分类与代码》（GB/T 29264-2012）中，对运行维护服务（operation maintenance service）给出的定义是“采用信息技术手段及方法，依据需方提出的服务级别要求，对其信息系统的基础环境、硬件、软件及安全等提供的各种技术支持和管理服务”。
        运维是信息系统全生命周期中的重要阶段，也是内容最多、最繁杂的部分，是对信息系统提供维护和技术支持以及其他相关的支持和服务。运维服务的主要对象包括基础设施、硬件平台、基础软件、应用软件以及依赖于IT基础设施的数据中心、业务应用等信息系统，其范围可以是单个IT基础设施的运维，也可以是整体IT基础设施和业务应用的总体运维。运维服务交付内容主要包括咨询评估、例行操作、响应支持和优化改善。
        在《信息技术服务分类与代码》（GB/T 29264-2012）中，将运行维护服务分成基础环境运维、硬件运维服务、软件运维服务、安全运维服务、运维管理服务和其他运行维护服务六类，每类运维服务及其说明见下表。
        
        运维服务分类与代码
        
        任何组织和个人提供运维服务需要依据需方提出的服务级别要求，并确保提供的运行维护服务符合与需方约定的质量要求。因此，具备相应运维服务能力是服务组织提供服务的必要条件，比如规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决事故和问题经验、提供知识的积累和共享手段、实现完善的IT运维管理、提高组织经营水平和服务水平等等。在《信息技术服务运行维护第1部分：通用要求》（GB/T 28827.1-2012）中给出了供方运维服务的能力模型，该模型定义了运行维护服务能力的四个关键要素：人员、资源、技术和过程，每个要素通过关键指标反映应具备的条件和能力。模型也给出了供方为持续提升运维能力的管理方法。
 
       知识转移
               知识转移的目的
               知识转移是技术部署实施的重要环节，完备的知识转移可提高IT服务技术支撑能力，降低风险，缩减成本，提升效率。
               知识转移的内容
               （1）历史运维资料。
               .相关工作界面和人员职责说明书。
               .内外部支持信息（开发商、厂商、业务部门、公司内部相关部门）。
               （2）基础架构资料。
               .系统部署和网络物理拓扑。
               .系统架构说明：软／硬件配置。
               .系统数据备份与恢复操作说明书。
               .系统应急、容灾处理方案（如集群切换和恢复）。
               .系统日常运维操作手册。
               （3）应用系统资料。
               .应用系统测试报告。
               .应用系统使用手册。
               .应用系统需求和设计文档。
               .应用系统安装配置手册。
               .应用版本说明（含与其他系统的依赖关系说明、已知错误列表及对应的临时措施等）。
               （4）业务资料。
               .业务架构图（业务功能模块在系统中的分布）。
               .业务流程（系统交互、工作流说明、业务功能说明、业务对象说明）。
               .业务场景说明（前台业务高峰说明、后台关键作业时间周期）。
               .业务培训资料。
               .业务运维文档（业务问题FAQ、业务问题诊断）。
               技术部署实施与知识转移实例如下图所示。
               
               技术部署实施与知识转换实例
 
       规范化
        关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有：1NF、2NF、3NF、BCNF、4NF和5NF，其中1NF级别最低。这几种范式之间成立。
        通过分解，可以将一个低一级范式的关系模式转换成若干个高一级范式的关系模式，这种过程叫作规范化。下面将给出各个范式的定义。
               1NF（第一范式）
               【定义7.10】若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式。记为R∈1NF。
               例如，供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下：
               FIRST（Sno，Sname，Status，City，Pno，Qty）
               F=｛Sno→Sname，Sno→Status，Status→City，（Sno，Pno）→Qty｝
               对具体的关系FIRST如下表所示。从下表中可以看出，每一个分量都是不可再分的数据项，所以是1NF的。但是，1NF存在4个问题：
               
               FIRST
               （1）冗余度大。例如每个供应者的Sno、Sname、Status、City要与其供应的零件的种类一样多。
               （2）引起修改操作的不一致性。例如供应者S1从“天津”搬到“上海”，若不注意，会使一些数据被修改，另一些数据未被修改，导致数据修改的不一致性。
               （3）插入异常。关系模式FRIST的主码为Sno、Pno，按照关系模式实体完整性规定主码不能取空值或部分取空值。这样，当某个供应者的某些信息未提供时（如Pno），则不能进行插入操作，这就是所谓的插入异常。
               （4）删除异常。若供应商S4的P2零件销售完了，并且以后不再销售P2零件，那么应删除该元组。这样，在基本关系FIRST找不到S4，可S4又是客观存在的。
               正因为上述4个原因，所以要对模式进行分解，并引入了2NF。
               2NF（第二范式）
               【定义7.11】若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF。
               换句话说，当1NF消除了非主属性对码的部分函数依赖，则称为2NF。
               例如，FIRST关系中的码是Sno、Pno，而Sno→Status，因此非主属性Status部分函数依赖于码，故非2NF的。
               若此时，将FIRST关系分解为：
               FIRST1（Sno，Sname，Status，City）∈ 2NF
               FIRST2（Sno，Pno，Qty）∈2NF
               因为分解后的关系模式FIRST1的码为Sno，非主属性Sname、Status、City完全依赖于码Sno，所以属于2NF；关系模式FIRST2的码为Sno、Pno，非主属性Qty完全依赖于码，所以也属于2NF。
               3NF（第三范式）
               【定义7.12】若关系模式R（U，F）中不存在这样的码X，属性组Y及非主属性使得X→Y，成立，则关系模式R∈3NF。
               即当2NF消除了非主属性对码的传递函数依赖，则称为3NF。
               例如，FIRST1?3NF，因为在分解后的关系模式FIRST1中有Sno→Status，Status→City，存在着非主属性City传递依赖于码Sno。若此时将FIRST1继续分解为：
               FIRST11（Sno，Sname，Status）∈ 3NF
               FIRST12（Status，City）∈3NF
               通过上述分解，数据库模式FIRST转换为FIRST11（Sno，Sname，Status）、FIRST12（Status，City）、FIRST2（Sno，Pno，Qty）三个子模式。由于这三个子模式都达到了3NF，因此称分解后的数据库模式达到了3NF。
               可以证明，3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，所以具有较好的性能。对于非3NF的1NF、2NF其性能弱，一般不宜作为数据库模式，通常要将它们变换成为3NF或更高级别的范式，这种变换过程称为“关系模式的规范化处理”。
               BCNF（Boyce Codd Normal Form，巴克斯范式）
               【定义7.13】关系模式R∈1NF，若X→Y且时，X必含有码，则关系模式R∈BCNF。
               也就是说，当3NF消除了主属性对码的部分函数依赖和传递函数依赖，则称为BCNF。
               结论：一个满足BCNF的关系模式，应有如下性质。
               （1）所有非主属性对每一个码都是完全函数依赖。
               （2）所有非主属性对每一个不包含它的码，也是完全函数依赖。
               （3）没有任何属性完全函数依赖于非码的任何一组属性。
               例如，设R（Pno，Pname，Mname）的属性分别表示零件号、零件名和厂商名，如果约定，每种零件号只有一个零件名，但不同的零件号可以有相同的零件名；每种零件可以有多个厂商生产，但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖：
               Pno→Pname，（Pname，Mname）→Pno
               由于该关系模式R中的候选码为（Pname，Mname）或（Pno，Mname），因而关系模式R的属性都是主属性，不存在非主属性对码的传递依赖，所以R是3NF的。但是，主属性Pname传递依赖于码（Pname，Mname），因此R不是BCNF的。当一种零件由多个生产厂家生产时，零件名与零件号间的联系将多次重复，带来冗余和操作异常现象。若将R分解成：
               R1（Pno，Pname）和R2（Pno，Mname）
               就可以解决上述问题，并且分解后的关系模式R1、R2都属于BCNF。
               4NF（第四范式）
               【定义7.14】关系模式R∈1NF，若对于R的每个非平凡多值依赖X→→Y且时，X必含有码，则关系模式R（U，F）∈4NF。
               4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。
               注意：如果只考虑函数依赖，关系模式最高的规范化程度是BCNF；如果考虑多值依赖，关系模式最高的规范化程度是4NF。
               连接依赖5NF
               连接依赖：当关系模式无损分解为n个投影（n>2）会产生一些特殊的情况。下面考虑供应商数据库中SPJ关系的一个具体的值，如下图所示。
               
               关系SPJ是三个二元投影的连接
               第一次SP、PJ投影连接“”起来的结果比原始SPJ关系多了一个元组“S2，P1，J2”，即上图中带下画线的元组。第二次连接的结果去掉了多余的元组，从而恢复了原始的关系SPJ。在这种情况下，原始的SPJ关系是可3分解的。注意，无论我们选择哪两个投影作为第一次连接，结果都是一样的，尽管在每种情况下中间结果不同。
               SPJ的可3分解性是基本与时间无关的特性，是关系模式的所有合法值满足的特性，也就是说，这是关系模式满足一个特定的与时间无关的完整性约束。将这种约束简称为3D（3分解）约束。上述情况就是连接依赖要研究的问题。
               连接依赖：如果给定一个关系模式R，R1，R2，R3，…，Rn是R的分解，那么称R满足连接依赖JD*｛R1，R2，R3，…，Rn｝，当且仅当R的任何可能出现的合法值都与它在R1，R2，R3，…，Rn上的投影等价。
               形式化地说，若R=R1∪R2∪…∪Rn，且，则称R满足连接依赖JD*｛R1，R2，R3，…，Rn｝。如果某个Ri，就是R本身，则连接依赖是平凡的。
               为了进一步理解连接依赖的概念，我们考虑银行数据库中的子模式：贷款（L-no，Bname，C-name，amount）。其中：
               .贷款号为L-no的贷款是由机构名为Bname贷出的。
               .贷款号为L-no的贷款是贷给客户名为C-name的客户。
               .贷款号为L-no的贷款的金额是amount。
               我们可以看到这是一个非常直观的逻辑蕴涵连接依赖：
               JD*（（L-no，Bname），（L-no，C-name），（L-no，amount））
               这个例子说明了连接依赖很直观，符合数据库设计的原则。
               【定义7.15】一个关系模式R是第五范式（也称投影-连接范式PJNF），当且仅当R的每一个非平凡的连接依赖都被R的候选码所蕴涵，记作5NF。
               “被R的候选码所蕴涵”的含义可通过SPJ关系来理解。关系模式SPJ并不是5NF的，因为它满足一个特定连接依赖，即3D约束。这显然没有被其唯一的候选码（该候选码是所有属性的组合）所蕴涵。其区别是，关系模式SPJ并不是5NF，因为它是可被3分解的，可3分解并没有为其（Sno，Pno，Jno）候选码所蕴涵。但是将SPJ3分解后，由于3个投影SP、PJ、JS不包括任何（非平凡的）连接依赖，因此它们都是5NF的。
 
       恢复
        数据恢复有3个步骤。
        （1）反向扫描文件日志，查找该事务的更新操作。
        （2）对事务的更新操作执行逆操作。
        （3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样的处理，直到事务的开始标志。
 
       培训
        培训包括旨在提高项目团队成员能力的全部活动。
        培训可以是正式或非正式的。培训方式包括课堂培训、在线培训、计算机辅助培训、在岗培训（由其他项目团队成员提供）、辅导及训练。
        应按人力资源管理计划中的安排来实施预定的培训。也应根据管理项目团队过程中的观察、交谈和项目绩效评估的结果，来开展必要的计划外培训，培训成本通常应该包括在项目预算中，或者由执行组织承担（如果增加的技能有利于未来的项目）。培训可以由内部或外部培训师来执行。
 
       实施计划
        （1）工作任务的分解：指对开发中应完成的各项工作按子系统（或系统功能）划分，指定专人分工负责。
        （2）进度：指给出各项工作的预定日期和完成日起，规定任务完成的先后顺序及完成的界面。可用PERT图或甘特图表示进度。
        （3）预算：指逐项列出本项目所需要的劳务以及经费的预算，包括办公费、差旅费、资料费，等等。
        系统说明书内容指南
        1．引言
        1.1摘要
        （摘要说明所建议开发的系统的名称、目标和功能。）
        1.2背景
        （1）项目的承担者
        （2）用户
        （3）本系统和其他系统或机构的关系和联系
        1.3参考和引用资料
        （1）本项目的经核准的计划任务书或合同、上级机关的批文
        （2）属于本项目的其他已发表的文件
        （3）本文件中各处引用的文件资料
        （列出上述文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。）
        1.4专门术语定义
        （本文件所用到的术语。）
        2．项目概述
        2.1项目的主要工作内容
        （简要地说明本项目在开发中须进行的各项主要工作，这些工作是建立新系统逻辑模型的必要条件，而逻辑模型是书写系统说明书的基础。）
        2.2系统需求说明
        （新系统是在现行系统的基础上建立起来的。在新系统设计工作开展之前，必须对系统调查清楚，掌握现行系统的真实情况，了解用户的新要求和问题所在。）
        2.2.1现行系统的现状调查说明
        （列出现行系统的目标、主要功能、用户要求等，并简要指出问题所在。）
        2.2.2业务流程说明
        （简要说明现行系统现场工作流程和事务流程概况。反映这些业务流程的业务流程图，若需要，可另附。）
        2.3系统功能说明
        （在现行系统现状调查的基础上，进一步透过具体工作，分析组织内信息、数据流动的路径和过程，真正弄清用户要解决什么问题，明确系统的功能要求。）
        2.3.1新系统功能要求
        （数据流程图是系统需求的高度概括，是调查研究的重要产物，它源于现行系统，又高于现行系统。这里主要通过数据流程图概况说明系统的功能要求。）
        （1）系统的目标
        （从新系统数据流程图的分析中，说明新系统有哪些目标。）
        （2）新系统的功能要求
        （列出新系统的主要功能）
        （3）验收
        （简单说明分析员和用户一起讨论分析的验收是否达到要求。）
        2.4系统的数据要求说明
        （从数据流程图和数据字典分析逻辑数据结构，标识每个数据结构中的每个数据项、记录和文件的长度以及它们之间的关系。）
        2.4.1系统的数据要求
        （这里的数据是指静态数据，即在运行过程中主要作为参考的数据，它们在很长一段时间内不会变化，一般不随运行而改变。）
        （1）数据项定义
        （说明数据项定义中出现的例外情况，列出作为控制或参考的主要数据项。）
        （2）容量
        （本系统所有数据项的总长度。）
        （3）用户
        （4）验收
        （指出验收情况。）
        2.4.2系统的数据要求的粗略估计
        （粗略估算系统在运行过程中动态数据的内容。）
        上述工作，再加上环境对系统影响的估计，以及研制时间和人力、物力引起的费用估计，构成系统规格说明书。
        3．实施总计划
        3.1工作任务的分解
        （对于项目开发中应完成的各项工作，按系统功能（或子系统）划分，指定专人（或小组）分工完成，指明每项任务的负责人。）
        3.2进度
        （给出每项工作任务的预定开始日期和完成日期，规定各项工作任务完成的先后顺序以及每项工作任务完成的界面。）
        3.3预算
        （逐项列出本开发项目所需要的劳务（包括工作量／人）以及经费的预算（包括办公费、差旅费、资料费等）。）
 
       信息化
        人们在生活和从事生产等活动中不断产生各种消息，接收者通过各种方式了解到的消息被称为信息。信息的传送一般应借助一定的运载工具，并将信息变换成各种表现形式，如语言、文字、图像、声音等。信息是普遍存在的，像空气一样渗透到全球各个角落、各个领域。人们在生活和工作中要随时随地地获取信息、交流和处理信息，并根据它决策或采取行动。企业为了在竞争中求得生存和发展，获取及时可靠的信息将成为第一需要。信息已同能源和材料一起成为现代化社会的三大资源。信息是资源，而且是一种战略资源。信息与材料、能源不同，信息可以被很多人使用，使用的人越多，创造的价值就越高，而且一条信息可以衍生出多条信息，取之不尽。信息与信息资源不同，信息的日常表现是无序的，但是信息本身存在着内在联系和规律，信息只有通过加工处理才能成为有价值的、可利用的信息资源。随着科技的进步和发展，特别是通信技术、电子技术、激光技术、集成电路、计算机等高技术的出现，在加快经济建设和社会发展的过程中，信息的作用越来越突出，信息和我们的日常生活密切相关，获取信息已经成为我们生活、工作中的重要内容，信息在服务于我们的生活的同时，对我们生活方式的影响也越来越大，所以我们称当前的社会为信息社会。由此衍生出了许多新兴的概念。
        信息技术是指对信息进行采集、存储、处理、检索、传递、分析与显示的高技术群。信息技术发展的总趋势是数字化、网络化与智能化，并以互联网技术及其应用技术为中心。信息产业是以现代信息技术为手段，以开发和利用信息资源为中心内容，提供信息产品和信息服务的产业部门。它包括信息产品制造业、软件与信息服务业、通信业。
        信息化是指培育、发展以智能化工具为代表的新的生产力并使之造福于社会的历史过程。智能工具一般必须具备信息获取、信息传递、信息处理、信息再生和信息利用的功能。
        完整的信息化内涵如下。
        （1）信息网络体系，它是大量信息资源、各种专用信息系统及其公用通信网络和信息平台的总称。
        （2）信息产业基础，即信息科学技术的研究、开发、信息装备的制造，软件开发与利用，各类信息系统的集成及信息服务。
        （3）社会支持环境，即现代工农业生产，以及管理体制、政策法律、规章制度、文化教育、道德观念等生产关系和上层建筑。
        （4）效用积累过程，即劳动者素质、国家的现代化水平和人们生活质量不断得到提高，精神文明和物质文明不断获得进步。
        通常人们习惯用信息产业部门所制造的收入在国民生产总值中所占的比重和信息从业者占就业人口的比例作为衡量社会信息化程度的指标。粗略认为两者均超过50%以上，其社会已进入信息社会。
 
       业务系统
        该重工集团有自己的管理模型。顶端按照工业4.0，集团管控，包括阿米巴经营模式；相应的流程制度，岗位职责，工作标准，成本绩效。左边是信息化管控，右边是智能化建设，下面是精益管理，底下是企业文化。这样的管理需要用信息化系统去实现。
        在这架构中，ERP系统是基础，利用CRM系统和客户对接，SRM管理供应链，MES监控生产。利用OA把所有业务打通，而后利用专业软件，实现前端的商务智能分析。
        下图的物联网设想把MES系统和机床、物流以及检测设备连起来，做成物联化，把ERP升级到CRM或者SCRM，把供应商和客户打通，形成企业的互联网。
        
        智能工厂物联网体系
        下图是整个业务系统的总体架构图。一个平台、两级部署、三层应用，包括商业分析、移动应用、企业门户和协同管理。
        
        智能工厂业务系统整体架构
        在业务系统这块，先后上线了ERP系统、PLM系统、OA系统和MES系统。上线的这些系统，虽然参与了生产、管理，打通了业务，却没有让领导层参与，反馈报告依然采用Excel、PPT。作为决策者，领导层更应该参与数据的可视化呈现过程。所以，2014年上线了帆软报表系统，提升了数据前端展示，利用某报表软件承担的BOSS系统决策，将领导层纳入管理体系。
 
       应急响应
        应急响应是指组织为预防、监控、处置和管理运维服务应急事件所采取的措施和行为。信息系统设施运维应急事件是指导致或即将导致信息系统设施运行中断、运行质量降低或需要实施重点时段保障的事件。当出现跨越预定的应急响应阈值的重大事件，或由于政府部门发出行政指令或对运维对象提出要求时，应当启动应急处理程序。
        应急响应是信息系统设施运维中的一个重要组成部分，针对突发公共事件，国家和地方政府出台的各项总体预案和专项预案，从整体或专业角度，对预防与应急准备、监测与预警、应急处置与救援、事后恢复与重建等方面进行了规定。但在信息技术运维领域，与之相对应的应急响应规范尚未建立起来。
        应急响应的管理是为了避免无序运维，提升应急状态下的运维响应能力，提前发现和解决问题，降低突发事件造成的不良影响，以合理的投入创造更大的效益。
        应急响应过程包括应急准备、监测与预警、应急处置和总结改进四个主要环节，如下图所示。
        
        应急响应过程
        每个环节中包括若干重点任务，这些任务覆盖了日常工作、故障响应和重点时段保障等不同类型的活动。应急响应的活动与任务如下表所示。
        
        应急响应的活动与任务
               应急准备
               （1）建立应急管理的组织和制度：建立应急管理组织，确保组建合适的组织以满足日常运维和应急响应的服务要求，明确应急响应组织中的角色及关系。应急管理组织建立后对应的应急管理制度包括负责制定应急响应方针（应急响应原则、范围等），明确应急响应的范围、要求、等级等。
               （2）风险评估与改进：风险评估与改进的目的是系统地识别运维服务对象及运维活动中可能出现的风险并提前改进，包括风险识别与评估、风险应对。
               运维人员从系统的角度识别风险要素，如运维对象、运维内容、组织及流程接口等。根据风险要素，应急响应组织按照一个确定的方法和流程来实施风险评估，明确其在其运维过程中的关键活动、所需资源、限制条件及组织面临的各种威胁，明确当威胁演变为应急事件时所产生的影响和后果，以及业务中断可能带来的损失。分析评估后应形成《风险评估报告》，报告应包括与服务水平目标相比较的运维要求、现状及趋势信息、风险要素、不符合项及问题等，并据此提出纠正措施建议，确认后的《风险评估报告》将作为风险应对预案。
               对于识别出的各种风险，制定明确的应对策略，包括风险规避、风险转嫁、风险降低、风险接受等。根据《风险评估报告》，形成《系统改进方案》以降低风险，包括降低风险转变为应急事件的可能性，缩短应急事件的持续时间，限制应急事件的影响范围。
               （3）应急事件级别划分：应急事件分级的主要参考要素为信息系统的重要程度、紧急程度、系统损失和社会影响。相关负责人按照以上要素对可能发生的事件进行评估。确定应急事件的级别。包括以下内容。
               灾难事件（Ⅰ级）：指由地震、火灾、恐怖袭击等原因造成主要IT设施毁灭性损坏，或者由于系统平台或业务数据遭受严重破坏，无法在短时间内恢复系统服务，造成核心业务服务中断超过48小时。
               重大事件（Ⅱ级）：指造成核心业务服务中断超过24小时，或重要业务数据丢失，或业务数据需要后退到上一备份状态。
               严重事件（Ⅲ级）：指造成核心业务服务中断超过12小时，或少量业务数据丢失。
               一般事件（Ⅳ级）：指造成核心业务服务中断超过4小时，或管理支撑系统服务中断超过24小时。
               （4）预案制定：预案制定的目的是提供应对运维应急事件的操作性文件。
               根据风险评估和事件级别划分制定《应急响应预案》。预案可以分为总体预案和针对某个核心系统的专项预案及其附则；预案中应该考虑到各种应急资源的调配和预置，主要包括人员、备品备件、资金、系统工具等。《应急响应预案》的内容包括应急响应预案的编制目的、依据和适用范围；具体的组织体系结构及人员职责；应急响应的监测和预警机制；应急响应的启动；应急响应的处置；应急响应的总结；应急响应的保障措施；应急预案的附则等。
               经过评审确认的应急响应预案，由责任者或授权管理者负责预案的分发，同时建立预案的版本控制。
               （5）培训与演练：培训需要制定应急响应培训计划，并组织相关人员参与，将应急响应预案作为培训的主要内容。培训应使得相关组织及人员明确其在应急响应过程中的责任范围、接口关系，明确应急处置的操作规范和操作流程。
               应急响应演练的目的，一是为了验证预案是否能够真正满足实际的需求，二是为了检验应急响应小组成员之间相互配合的默契程度和对运维事件应对步骤的熟练程度。演练的方式分为工具测试演练和场景模拟演练。
               为了检验预案的有效性，同时使相关人员了解运维预案的目标和流程，熟悉应急响应的操作规程，应急响应的演练应做到：预先制定演练计划，在计划中说明测试工具或演练的场景；演练的整个过程有详细的记录，并形成报告；演练不能对业务运行造成负面影响；按照约定周期，进行完整演练（可以有被委托的第三方机构参与），周期建议可以设定为季度、一年或三年。
               监测与预警
               （1）日常监测与预警：日常监测与预警负责保障运维服务的可用和连续，及时发现运维服务应急事件并有效预警。结合运维服务级别协议和应急响应预案，开展日常监测与预警活动，主要包括设立服务台并保持运营；确定监测项、监测时间间隔与阈值；确定活动中的人员、角色和职责。可以采用运维工具与人工相结合的方式开展日常监测与预警活动。
               （2）记录与报告：建立监测、预警信息登记和报告制度。对日常监测结果进行记录，发现运维服务应急事件时，应提交单独的报告，报告内容应包括故障或预警发生及发现的时间和地点；表象及影响的范围；原因初步分析；报告人等。对运维应急事件要保持持续性跟踪。
               （3）核实与评估：核实与评估负责对出现的运维服务应急事件进行有效识别。其中核实是指接到报告的责任者应对报告内容进行逐项核实，以判别运维服务应急事件是否属实；事件级别评估是指负责人应参见应急准备活动中的事件级别划分，确定应急事件所对应的事件级别，同时将事件级别置于动态调整控制中。
               （4）预案启动：确保以规定的策略和程序启动预案，并保持对应急事件的跟踪。
               建立、审议预案启动的策略和程序，以控制预案启动的授权和实施。对预案启动可能造成的影响进行评估，在相关方之间就启动何种类型预案达成一致，过程包括一旦事件升级，与之相对应的预案调整的方式，同时记录预案启动的过程和结果。
               信息通报内容包括预案启动的原因、事件级别、事件对应的预案、要求采取的技术应对或处置的目标、实现目标所应采取的保障措施，如人员、物资、环境、资金等；对应急处置过程及结果的报告要求，如报告程序、报告内容、报告频率等；信息通报的方式可以是电话、邮件、电视、广播和文件等。相关方对收到的通报信息进行确认和反馈。
               应急响应人员根据调整后的状态开展监测与预警活动，并按一致约定的程序和监测范围、监测频率提供报告。
               应急处置
               （1）应急调度：在应急调度中明确应急调度手段，规范应急调度过程；在调度安排下，相关人员实施应急处置，责任者根据应急处置要求，对应急处置经费、应急处置人员、应急处置设施等统一调配和管理，并完成调度明细说明的整理和归档。应急调度的工作流程包括在规定时间要求内，迅速组织人员勘察、分析；通过网络、媒体、广播等多种手段快速获取应急事件的相关信息；及时组织并协调相关部门及人员召开应急处置工作会议；根据应急处置要求，对涉及应急处置组织下达调度命令；组织人员保护可追查的相关线索。
               （2）排查与诊断：排查与诊断是基于已经启动的预案而开展的，在排查与诊断中，应建立多渠道的应急处置支持模式，如建立由服务商、供应商、生产制造商构成的应急处置支持模式。故障排查与诊断的流程包括：应急处置责任者调配处置人员进行现场故障排查；现场处置人员进行故障排查和诊断，必要时可寻求外协人员以现场或远程方式进行支持，在此过程中可借助各类排查、诊断、分析工具，如应用软件、电子分析工具、故障排查知识库等；现场处置人员应随时向处置责任者汇报故障排查情况、诊断信息、故障定位结果等；将排查与诊断的过程和结果信息进行整理与归档。
               在实施应急处置过程中，各级责任者需要及时与相关利益方进行沟通，沟通的内容主要包括应急处置故障点、造成故障的原因、排查诊断等。及时完成对沟通信息及对应组织人员的核实与确认，同时对确认信息完成归档、上报、审批等事项。
               （3）处理与恢复：负责对故障进行有效、快速的处理与恢复。应基于预案和知识库进行故障的处理与恢复，处理与恢复的原则应在满足相应服务级别协议要求的前提下，尽快恢复服务；采用的方法、手段不应造成新的事件发生。
               必要时可启用备品备件、灾备系统等。对过程及结果信息进行记录，并及时告知相关方面和人员。责任者应组织对处理与恢复的结果进行初步确认。
               （4）升级与信息通报：应急响应组织通过实施有效评审，实现对应急处置的升级与通报；故障处置责任者应组织相关人员对故障处置过程及结果情况进行评审；在评审中，参考服务级别协议中对事件处置内容情况的设定，同时结合应急故障处置的现场情况进行分析和比较。当应急故障现场处置的情况超过原应急预案中的事件处置级别要求时，应作为应急事件升级；建立、审议应急事件升级的策略和程序，以控制应急事件升级的授权和实施，就应急事件升级可能造成的影响进行评估；升级过程包含预案调整、人员调整、资金调整及相关设施调整，需要对应急事件升级的过程和结果信息进行整理与归档。信息通报内容包括事件升级的原因；事件升级后的级别；事件升级后与之对应的预案；根据升级事件处置的要求和目标，确定所需的技术应对措施；实现目标所应采取的保障措施，如人员、物资、环境、资金等；对升级事件处置过程及结果的报告，如报告程序、报告对象、报告内容、报告频率等；信息通报的范围和涉及接受者，信息通报的方式有电话、邮件、电视、广播和文件等形式。
               （5）持续服务与评价：在完成对应急事件故障处置后，应组织运维人员提供持续性服务，同时应对持续性服务的效果进行评价。
               （6）事件关闭：规范并明确应急处置的关闭流程，即申请关闭、核实、关闭通报。
               关闭申请：建立、审议事件关闭的策略和程序，以控制事件关闭的授权和实施；对应急事件处置的过程文档和各评审／评价报告进行整理，由明确的责任者或授权管理者提出事件关闭申请，并提交相关文档资料。
               关闭核实：接到事件关闭申请的责任者应逐项核实报告内容，以判别应急事件处置过程和结果信息是否属实。
               关闭通报：建立、审议应急事件关闭通报制度，应急事件关闭的责任者向相关利益方通报信息，内容应包括应急事件的级别；事件对应的预案信息；应急事件处置的过程情况；事件的调整升级情况；持续性服务状况信息；事件处置评价信息；事件关闭申请的处理意见；关闭通报的范围和涉及接受者。
               总结改进
               （1）应急事件总结：在事件关闭之后，组织相关人员对本次事件的原因、处理过程和结果进行分析，总结经验教训，并采取必要的后续措施。事件总结应包含事件发生的原因分析、应急事件的处理过程和结果；评估应急事件造成的影响；降低事件发生频率、减轻损害和避免再次发生的方法。
               调查和收证：当一个事件涉及责任认定、赔偿或诉讼时，应收集、保留和呈递证据。证据可用于内部问题分析；用做有关可能违反合同或规章要求的法律取证；与供应商或其他组织谈判赔偿事宜。
               （2）应急体系的保持：为保证应急体系的有效性和时效性，需要对应急体系进行不定期及定期的维护和审核，以确保组织具有足够的应急响应能力。
               体系维护主要是指当组织战略、业务流程、客户要求等发生重大变化时，对现有的应急体系，尤其是风险评估和应急预案进行修改。体系维护应该是不定期进行的，是由事件驱动的。
               体系审核主要是指对组织当前的应急响应能力和管理模式进行评审，以确保它们符合预定的标准和要求，同时明确组织在应急响应方面的主要不足和改进方向。体系审核应该是定期进行的，组织应该至少一年进行一次体系审核。
               体系维护：组织建立明确的应急体系维护计划，确保任何影响到组织应急管理的重大变更都能被识别出来，同时采取必要的措施对这些变更进行分析，并对应急管理体系做出相应调整，这种调整可能涉及应急管理的方针策略、流程、应急预案和资源配置。
               体系维护流程的结果应包括关于应急体系维护活动的文档记录；确保应急响应的相关人员都已经明确应急体系的调整内容，并接受必要的培训；当需要对风险评估、组织架构、人员配备进行调整时，保留必要的文档记录。
               体系审核：相关责任者按照预定的时间间隔对应急管理体系进行审核，以确保体系具有持续的适用性和有效性。体系审核包括评估体系不足和改进建议。同时，体系审核的结果应正式存档并通知给相关责任者。
               体系审核的输入信息主要包括相关利益方的要求和反馈；组织所采纳的，用于支持应急响应的各种技术、产品和流程；风险评估的结果及可接受的风险水平；应急预案的测试结果及实际执行效果；上次体系评审的后续跟踪活动；可能影响应急体系的各种业务变更；近期在处置应急事件过程中总结的经验和教训；培训的结果和反馈。
               体系审核的输出结果主要包括应急体系的改进目标；如何改进应急体系的有效性和效率；所需的各种资源，包括人员、软硬件、资金等。
               （3）应急准备工作的改进：应急时间总结、体系维护和体系审核的结果将作为应急准备阶段的重要输入信息，组织应根据应急时间总结报告中给出的建议项和体系评审结果来调整应急准备及风险应对的策略。
   题号导航      2022年上半年 系统规划与管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第2题    在手机中做本题