免费智能真题库 > 历年试卷 > 信息系统管理工程师 > 2018年上半年 信息系统管理工程师 上午试卷 综合知识
  第64题      
  知识点:   错误控制   变更管理   变更请求
  关键词:   变更管理   错误控制   故障   变更        章/节:   系统运行管理知识       

 
错误控制是管理、控制并成功纠正已知错误的过程,它通过变更请求变更管理部门报告需要实施的变革,确保已知错误被完全消除,避免再次发生故障。错误控制的过程中不包括下列( )的工作内容。
 
 
  A.  无负载加载启动
 
  B.  发现和记录错误
 
  C.  记录错误解决过程
 
  D.  跟踪监督错误解决过程
 
 
 

 
  第64题    2011年上半年  
   35%
在系统故障与问题管理中,问题预防的流程主要包括趋势分析和(64)。
  第61题    2012年上半年  
   50%
问题管理流程应定期或不定期地提供有关问题、已知错误和变更请求等方面的管理信息,其中问题管理报告应该说明如何调查、分析、解..
  第60题    2016年上半年  
   46%
在对问题控制与管理中,问题的控制过程中常用到调查分析,其分析方法主要有四种,这四种分析方法正确的是(60)。
   知识点讲解    
   · 错误控制    · 变更管理    · 变更请求
 
       错误控制
        错误控制是管理、控制并成功纠正已知错误的过程,它通过变更请求向变更管理部门报告需要实施的变革,确保已知错误被完全消除,避免再次发生故障。错误控制对所有已知错误从其被发现至被解决的全过程进行控制,涉及公司的许多不同部门。错误控制的过程主要分为三个阶段,如下图所示。其中跟踪和监督错误活动将覆盖问题的整个生命周期。
        
        错误控制
               发现和记录错误
               一旦确定了问题产生的根本原因,问题就将转变为一项错误;如果找到对付错误的应急措施,错误又将成为已知错误。错误或已知错误的确定是错误控制过程的开始。
               错误控制系统中有关已知错误的数据来源主要有两个:运行过程和开发过程。前者主要指在问题控制过程中把某个问题升级为已知错误时,在问题调查和分析阶段记录的数据可直接作为错误控制所需错误信息的基础;后者如应用系统包含了开发阶段形成的错误,但直到正式实施时才会被发现,则有关这些错误的信息应该按要求输入到错误控制系统的数据库中。
               评价错误
               发现和记录错误后,问题管理人员与支持组将一道对错误可能的解决方法进行初步评估。如果他们发现不能消除错误,就将通过变更请求向变更管理部门报告有关情况。变更管理部门根据错误对业务的影响、紧迫性、严重性来确定变更管理请求的优先级。
               记录错误解决过程
               错误控制系统应该详细记录每个已知错误的解决过程,特别是与已知错误有关的配置项、症状和解决方案(或替代方案),记录的信息保存于问题管理数据库中。这些信息可用于故障匹配中,为以后的故障调查和解决提供指导,也可用于管理报告中。
               终止错误
               在实施变更已成功消除错误后,可以终止已知错误及其相关的故障和问题,并通过实施后评审确认已知错误的解决效果。对故障来说,实施后评审延续就是简单地打电话询问客户是否满意,但对问题和已知错误来说,实施后评审应该是一个正式的和规范的过程。
               跟踪监督错误解决过程
               变更管理流程将负责处理变更请求,而错误控制需要对已知错误的解决过程进行监控。在整个解决过程中,问题管理需要从变更管理获得有关问题和错误解决情况的正规报告。
 
       变更管理
        变更是指在信息系统项目的实施过程中,由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。在项目实施过程中,变更越早,损失越小;变更越迟,难度越大,损失也越大。项目在失控的情况下,任何微小变化的积累,最终都会对项目的质量、成本和进度产生较大影响,这是一个从量变到质变的过程。
        变更产生的原因主要有以下几个方面:
        (1)项目外部环境发生变化,例如政府政策的变化。
        (2)项目总体设计、项目需求分析不够周密详细,有一定的错误或遗漏。
        (3)新技术的出现,设计人员提出了新的设计方案或新的实现手段。
        (4)建设单位由于机构重组等原因造成业务流程的变化。
               配置库
               配置库也称为配置项库,是用来存放配置项的工具。配置库记录与配置相关的所有信息,其中存放受控的配置项是很重要的内容,利用库中的信息可评价变更的后果,这对变更控制有着重要的意义。
               配置库有3类:
               (1)开发库(development library)。存放开发过程中需要保留的各种信息,供开发人员个人专用。库中的信息可能有较为频繁的修改,只要开发库的使用者认为有必要,无须对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统(开发者系统、开发系统、工作空间)。
               (2)受控库(controlled library)。在信息系统开发的某个阶段工作结束时,将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的,以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。受控库也称为主库,对应配置管理系统中的主系统(受控系统)。
               (3)产品库(product library)。在开发的信息系统产品完成系统测试之后,作为最终产品存入库内,等待交付用户或现场安装。库内的信息也应加以控制。产品库也称为备份库,对应配置管理系统中的静态系统(受控系统)。
               作为配置管理的重要手段,上述受控库和产品库的规范化运行能够实现对信息系统配置项的管理。
               变更控制
               变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序,其中包括必要的表格或其他书面文件,责任追踪,以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力,并由所有的项目干系人认可。在审批变更时,要加强对变更风险和变更效果的评估,并选择对项目影响最小的变更方案,尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑,形成整体。
                             变更控制委员会
                             变更控制委员会(Change Control Board, CCB)也称为配置控制委员会(Configuration Control BoarD),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以是全职的,也可以是兼职的。
                             如果CCB不只是控制变更,而是承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
                             变更控制的流程
                             变更管理的基本流程如下:
                             (1)变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
                             (2)变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
                             (3)变更决策。由具有相应权限的人员或机构决定是否实施变更。
                             (4)变更实施。由管理者指定的工作人员在受控状态下实施变更。
                             (5)变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
                             (6)沟通存档。将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。
                             变更申请需要采用书面的形式提出,主要内容有如下3个方面:
                             (1)变更描述。包括变更理由、变更的影响、变更的优先级等,就是要申述做什么变更,为什么要做,以及打算怎么做的问题。
                             (2)对变更的审批。对变更的必要性、可行性的审批意见,主要是由配置管理员和CCB对此项变更把关。
                             (3)变更实施的信息。
                             利用配置库实现变更控制
                             配置项可以有3种状态,分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来,对于其他配置项来说是处于不处理工作状态下(自由状态),此时它并未受到配置管理的控制,开发人员的变更并未受到限制。但当开发人员认为工作已告完成,可供其他配置项使用时,它就开始稳定。把它交出评审,就开始进入评审状态;若通过评审,可作为基线进入配置库(实施检入),开始冻结,此时开发人员不允许对其做任意修改,因为它已处于受控状态。通过评审表明它确已达到质量要求;但若未能通过评审,则将其回归到工作状态,重新进行调整。配置项的状态变化过程如下图所示。
                             
                             配置项的状态变化过程
                             处于受控状态下的配置项原则上不允许修改,但这不是绝对的,如果由于多种原因需要变更,就需要提出变更请求。在变更请求得到批准的情况下,允许配置项从库中检出,待变更完成,并经评审后,确认变更无误方可重新入库,使其恢复到受控状态。
 
       变更请求
        变更请求是关于修改任何文档、可交付成果或基准的正式提议。变更请求被批准之后将会引起对相关文档、可交付成果或基准的修改,也可能导致对项目管理计划其他相关部分的更新。其他变更请求包括必要的预防措施或纠正措施,用来防止以后的不利后果。变更请求可以是直接或间接的,可以由外部或内部提出,可能是自选或由法律/合同所强制的。
        变更请求可以包括:
        .纠正措施:为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
        .预防措施:为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
        .缺陷补救:为了修正不一致的产品或产品组件而进行的有目的的活动。
        .更新:对正式受控的项目文件或计划等进行的变更,以反映出修改或增加的意见或内容。
   题号导航      2018年上半年 信息系统管理工程师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第64题    在手机中做本题