免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2012年上半年 信息系统项目管理师 上午试卷 综合知识
  第65题      
  知识点:   变更管理   变更控制   配置管理   配置项   配置项状态
  关键词:   变更控制   配置管理   配置项   变更        章/节:   配置管理基础       

 
配置管理中有一项工作是变更控制,其中配置项状态的过程如图2所示:

在这个状态变化过程中,图中的(1)、(2)、(3)三个状态依次为(65)。
 
 
  A.  工作状态、受控状态、评审状态
 
  B.  评审状态、工作状态、受控状态
 
  C.  工作状态、评审状态、受控状态
 
  D.  受控状态、评审状态、工作状态
 
 
 

 
  第63题    2015年上半年  
   23%
软件系统的版本号由3部分构成,即主版本号+次版本号+修改号。某个配置项的版本号是1.0,按照配置版本号规则表明()。
  第64题    2009年下半年  
   22%
某个配置项的版本由1.0变为2.0,按照配置版本号规则表明(64)。
  第49题    2022年下半年  
   68%
通常质量管理人员具有()的权限。
①对受控库的文档的Add   
②对受控库文档的Check   
   知识点讲解    
   · 变更管理    · 变更控制    · 配置管理    · 配置项    · 配置项状态
 
       变更管理
        信息系统开发项目的变更
        信息系统开发项目的变更有如下特点:
        .变更的不可避免性。
        .变更的复杂性。
        项目变更常见的原因如下:
        .产品范围定义的过失或疏忽。
        .项目范围定义的过失或疏忽。
        .增值变更。
        .应对风险的紧急计划或回避计划。
        .项目执行过程与项目基准要求不一致。
        .外部事件。
        变更管理的任务
        变更管理的主要任务如下:
        .分析变更:研究变更的必要性、经济可行性和技术可行性。
        .记录和追踪变更。
        .采取措施保证变更在受控状态下进行。
        变更管理流程
        变更管理过程的一般程序如下:
        (1)提出与接收变更申请。
        变更提出应当以正式的方式进行,并留下书面记录。
        (2)对变更进行初审。
        变更初审的目的如下:
        .对变更提出方施加影响,确认变更的必要性。
        .格式校验,完整性校验,确保评估所需信息准备充分。
        .在干系人间就提出供评估的变更信息达成共识。
        变更初审常见方式为变更申请文档的审核流转。
        (3)变更方案论证。
        对变更申请进行技术评估和经济评估,以供CCB决策。
        (4)项目变更控制委员会审查。
        变更控制委员会(CCB)决定是否批准变更申请。
        (5)对否决的变更申请进行记录并通知相关人员,对批准的变更申请发出变更通知并开始实施。
        (6)对变更实施进行监控。
        (7)对变更效果进行评估。
 
       变更控制
        变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序,其中包括必要的表格或其他书面文件,责任追踪,以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力,并由所有的项目干系人认可。在审批变更时,要加强对变更风险和变更效果的评估,并选择对项目影响最小的变更方案,尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑,形成整体。
               变更控制委员会
               变更控制委员会(Change Control Board,CCB)也称配置控制委员会(Configuration Control Board),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以全职的,也可以是兼职的。
               如果CCB除控制变更以外,还要承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
               变更控制的流程
               变更管理的基本流程如下:
               ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
               ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
               ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
               ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
               ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
               ⑥沟通存档。将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。
               变更申请需要采用书面的形式提出,主要内容有如下3个方面:
               ①变更描述。包括变更理由、变更的影响、变更的优先级等,就是要描述做什么变更,为什么要做,以及打算怎么做的问题。
               ②对变更的审批。对变更的必要性、可行性的审批意见,主要是由配置管理员和CCB对此项变更把关。
               ③变更实施的信息。
               利用配置库实现变更控制
               配置项可以有3种状态,分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来,对于其他配置项来说是处于不处理工作状态下(自由状态),此时它并未受到配置管理的控制,开发人员的变更并未受到限制。但当开发人员认为工作已告完成,可供其他配置项使用时,它就开始于稳定。把它交出评审,就开始进入评审状态;若通过评审,可作为基线进入配置库(实施检入),开始冻结,此时开发人员不允许对其任意修改,因为它已处于受控状态。通过评审表明它确已达到质量要求;但若未能通过评审,则将其回归到工作状态,重新进行调整。配置项的状态变化过程如下图所示。
               
               配置项的状态变化过程
               处于受控状态下的配置项原则上不允许修改,但这不是绝对的,如果由于多种原因需要变更,就需要提出变更请求。在变更请求得到批准的情况下,允许配置项从库中检出,待变更完成,并经评审后,确认变更无误方可重新入库,使其恢复到受控状态。
 
       配置管理
        随着信息系统软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发、维护面临越来越多的问题,其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目,对每个项目的变更进行管控(版本控制),并维护不同项目之间的版本关联,以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括:配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准,制定配置管理计划,主要包括以下内容。
               (1)该项目对配置管理的要求。
               (2)实施配置管理的责任人、组织及其职责。
               (3)需要开展的配置管理活动及其进度安排。
               (4)采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性,及其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理,“配置”经常被划分为各类配置项,这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合,在配置管理过程中,配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档,源程序与目标代码,以及运行所需的各种数据等。同时,应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加,修改或删除,配置项的版本随之演变。应当记录每个软件配置项的所有历史记录,并记录该软件配置项由何人创建,何人在何时因何原因进行了修改等信息,以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分,包含评估、协调、批准/拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程,确认受控软件配置项满足需求并就绪。其内容如下。
               (1)功能审计:配置项的变更控制是否和配置管理计划中的描述相一致。
               (2)物理审计:配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单,变更请求当前的处理状态,以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程,它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       配置项
        GB/T 11457—2006对配置项的定义为:“为配置管理设计的硬件、软件或二者的集合,在配置管理过程中作为一个单个实体来对待。”配置项的例子有:交付的软件产品和数据,用于创建或支持软件产品的支持工具,供应商提供的软件和客户提供的设备/软件,各类文档,源代码,可执行代码,测试用例,运行软件所需的各种数据等。
        在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如,基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO(配置管理员)严格管理,基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB及相关人员开放。
 
       配置项状态
        配置项的状态可分为“草稿”“正式”和“修改”三种。配置项初始状态为“草稿”,通过评审后,其状态变为“正式”。此后若更改配置项,则其状态变为“修改”,当修改完毕并重新通过评审后,其状态又变为“正式”。
        配置项状态变化如下图所示。
   题号导航      2012年上半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第65题    在手机中做本题