免费智能真题库 > 历年试卷 > 系统架构设计师 > 2017年下半年 系统架构设计师 上午试卷 综合知识
  第25题      
  知识点:   变更管理   变更控制   需求变更管理
  关键词:   变更管理   变更控制   项目风险   需求变更   变更   风险   需求        章/节:   开发管理       

 
一个好的变更控制过程,给项目风险承担者提供了正式的建议变更机制。如下图所示的需求变更管理过程中,①②③处对应的内容应分别是( )。
 
 
  A.  问题分析与变更描述、变更分析与成本计算、变更实现
 
  B.  变更描述与成本计算、变更分析、变更实现
 
  C.  问题分析与变更分析、成本计算、变更实现
 
  D.  变更描述、变更分析与变更实现、成本计算
 
 
 

 
  第25题    2018年下半年  
   23%
下面关于变更控制的描述中,( )是不正确的。
  第25题    2019年下半年  
   36%
需求变更管理是需求管理的重要内容。需求变更管理的过程主要包括问题分析和变更描述、   (24)   、变..
  第25题    2016年下半年  
   64%
(25)是关于需求管理正确的说法。
   知识点讲解    
   · 变更管理    · 变更控制    · 需求变更管理
 
       变更管理
        变更是指在信息系统项目的实施过程中,由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、架构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。在项目实施过程中,变更越早,损失越小;变更越迟,难度越大,损失也越大。项目在失控的情况下,任何微小变化的积累,最终都会对项目的质量、成本和进度产生较大影响,这是一个从量变到质变的过程。
        变更产生的原因主要有以下几个方面:
        (1)项目外部环境发生变化,如政府政策的变化。
        (2)项目总体设计、项目需求分析不够周密详细,有一定的错误或遗漏。
        (3)新技术的出现,设计人员提出了新的设计方案或新的实现手段。
        (4)建设单位由于机构重组等原因造成业务流程的变化。
               配置库
               配置库也称为配置项库,是用来存放配置项的工具。配置库记录与配置相关的所有信息,其中存放受控的配置项是很重要的内容,利用库中的信息可评价变更的后果,这对变更控制有着重要的意义。
               配置库有3类:
               (1)开发库(development library)。存放开发过程中需要保留的各种信息,供开发人员个人专用。库中的信息可能有较为频繁的修改,只要开发库的使用者认为有必要,无须对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统(开发者系统、开发系统、工作空间)。
               (2)受控库(controlled library)。在信息系统开发的某个阶段工作结束时,将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的,以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。受控库也称为主库,对应配置管理系统中的主系统(受控系统)。
               (3)产品库(product library)。在开发的信息系统产品完成系统测试之后,作为最终产品存入库内,等待交付用户或现场安装。库内的信息也应加以控制。产品库也称为备份库,对应配置管理系统中的静态系统(受控系统)。
               作为配置管理的重要手段,上述受控库和产品库的规范化运行能够实现对信息系统配置项的管理。
               变更控制
               变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序,其中包括必要的表格或其他书面文件,责任追踪,以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力,并由所有的项目干系人认可。在审批变更时,要加强对变更风险和变更效果的评估,并选择对项目影响最小的变更方案,尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑,形成整体。
                      变更控制委员会
                      变更控制委员会(Change Control Board,CCB)也称配置控制委员会(Configuration Control Board),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以全职的,也可以是兼职的。
                      如果CCB除控制变更以外,还要承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
                      变更控制的流程
                      变更管理的基本流程如下:
                      ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
                      ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
                      ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
                      ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
                      ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
                      ⑥沟通存档。将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。
                      变更申请需要采用书面的形式提出,主要内容有如下3个方面:
                      ①变更描述。包括变更理由、变更的影响、变更的优先级等,就是要描述做什么变更,为什么要做,以及打算怎么做的问题。
                      ②对变更的审批。对变更的必要性、可行性的审批意见,主要是由配置管理员和CCB对此项变更把关。
                      ③变更实施的信息。
                      利用配置库实现变更控制
                      配置项可以有3种状态,分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来,对于其他配置项来说是处于不处理工作状态下(自由状态),此时它并未受到配置管理的控制,开发人员的变更并未受到限制。但当开发人员认为工作已告完成,可供其他配置项使用时,它就开始于稳定。把它交出评审,就开始进入评审状态;若通过评审,可作为基线进入配置库(实施检入),开始冻结,此时开发人员不允许对其任意修改,因为它已处于受控状态。通过评审表明它确已达到质量要求;但若未能通过评审,则将其回归到工作状态,重新进行调整。配置项的状态变化过程如下图所示。
                      
                      配置项的状态变化过程
                      处于受控状态下的配置项原则上不允许修改,但这不是绝对的,如果由于多种原因需要变更,就需要提出变更请求。在变更请求得到批准的情况下,允许配置项从库中检出,待变更完成,并经评审后,确认变更无误方可重新入库,使其恢复到受控状态。
 
       变更控制
        变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序,其中包括必要的表格或其他书面文件,责任追踪,以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力,并由所有的项目干系人认可。在审批变更时,要加强对变更风险和变更效果的评估,并选择对项目影响最小的变更方案,尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑,形成整体。
               变更控制委员会
               变更控制委员会(Change Control Board,CCB)也称配置控制委员会(Configuration Control Board),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以全职的,也可以是兼职的。
               如果CCB除控制变更以外,还要承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
               变更控制的流程
               变更管理的基本流程如下:
               ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
               ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
               ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
               ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
               ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
               ⑥沟通存档。将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。
               变更申请需要采用书面的形式提出,主要内容有如下3个方面:
               ①变更描述。包括变更理由、变更的影响、变更的优先级等,就是要描述做什么变更,为什么要做,以及打算怎么做的问题。
               ②对变更的审批。对变更的必要性、可行性的审批意见,主要是由配置管理员和CCB对此项变更把关。
               ③变更实施的信息。
               利用配置库实现变更控制
               配置项可以有3种状态,分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来,对于其他配置项来说是处于不处理工作状态下(自由状态),此时它并未受到配置管理的控制,开发人员的变更并未受到限制。但当开发人员认为工作已告完成,可供其他配置项使用时,它就开始于稳定。把它交出评审,就开始进入评审状态;若通过评审,可作为基线进入配置库(实施检入),开始冻结,此时开发人员不允许对其任意修改,因为它已处于受控状态。通过评审表明它确已达到质量要求;但若未能通过评审,则将其回归到工作状态,重新进行调整。配置项的状态变化过程如下图所示。
               
               配置项的状态变化过程
               处于受控状态下的配置项原则上不允许修改,但这不是绝对的,如果由于多种原因需要变更,就需要提出变更请求。在变更请求得到批准的情况下,允许配置项从库中检出,待变更完成,并经评审后,确认变更无误方可重新入库,使其恢复到受控状态。
 
       需求变更管理
        控制项目范围扩展
        扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。
        控制范围扩展的技术:
        .把新系统的视图、范围、限制文档化并作为业务需求的一部分,将每一项建议的需求与项目的视图和范围相比较决定是否应该采纳。
        .原型法:能够给用户提供预览所有可能的实现,以帮助用户与开发方沟通从而准确把握用户的真实需求。
        控制范围扩展的方法是要敢于说“不”。
        变更控制过程
        变更控制策略有:
        .所有需求变更必须遵循的过程,按照此过程,如果一个变更需求未被采纳,则其后过程不再予以考虑。
        .对于未获批准的变更,除可行性论证之外,不应再做其他设计和实现工作。
        .简单请求一个变更不能保证能实现变更,要由项目变更控制委员会决定实现哪些变更。
        .项目风险承担者应该了解变更数据库的内容。
        .决不能从数据库中删除或修改变更请求的原始文档。
        .每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
        变更控制状态报告是用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。项目管理人员通常使用这些报告来跟踪项目状态。
        变更控制过程可以通过自动工具来执行,挑选工具时应该注意以下几个方面:
        .可以定义变更请求的数据项。
        .可以定义变更请求生存期的状态转换图。
        .可以加强状态转换图,使经授权的用户仅能作出所允许的状态变更。
        .记录每一种状态变更的数据,确认作出变更的人员。
        .可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。
        .可以根据需要生成标准的或定制的报告和图表。
        变更控制委员会
        变更控制委员会可以由一个小组担任,也可由多个不同的组担任,负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用,其人员可以包括:
        .产品或计划管理部门
        .项目管理部门
        .开发部门
        .测试或质量保证部门
        .市场部或客户代表
        .制作用户文档的部门
        .技术支持部门
        .帮助桌面或用户支持热线部门
        .配置管理部门
        度量变更活动
        需求变更活动的度量需要考虑下列方面的内容:
        .接收、未做决定、结束处理的变更请求的数量。
        .已实现需求变更(包括增、删、改)的合计数量。
        .每个方面发出的变更请求的数量。
        .每一个已应用的需求建议变更和实现变更的数量。
        .投入处理变更的人力、物力。
   题号导航      2017年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第25题    在手机中做本题