免费智能真题库 > 历年试卷 > 系统架构设计师 > 2015年下半年 系统架构设计师 上午试卷 综合知识
  第26题      
  知识点:   版本管理   配置管理   配置项
  关键词:   配置管理   配置项        章/节:   开发管理       

 
项目配置管理中,配置项的状态通常包括( )。
 
 
  A.  草稿、正式发布和正在修改
 
  B.  草稿、技术评审和正式发布
 
  C.  草稿,评审或审批、正式发布
 
  D.  草稿、正式发布和版本变更
 
 
 

 
  第25题    2016年下半年  
   65%
(25)是关于需求管理正确的说法。
  第25题    2019年下半年  
   35%
需求变更管理是需求管理的重要内容。需求变更管理的过程主要包括问题分析和变更描述、   (24)   、变..
  第22题    2009年下半年  
   65%
配置项是构成产品配置的主要元素,其中(22)不属于配置项。
   知识点讲解    
   · 版本管理    · 配置管理    · 配置项
 
       版本管理
        在配置管理中,所有的配置项都应列入版本控制的范畴。对于信息产品的版本有两个方面的意思,一是为满足不同用户的不同使用要求,如用于不同运行环境的系列产品。如适合Linux、Windows、Solaris用户的软件产品分别称为Linux版、Windows版和Solaris版。它们在功能和性能上是相当的,原则上没有差别,或者说,这些是并列的系列产品。对于这类差别很小的不同版本,互相也称为变体(variant)。
        另一种版本的含义是在信息系统产品投产使用后,产品经过一系列的变更,如纠错,增加功能,提高性能,而形成的一系列的顺序演化的产品,这些产品也称为一个版本,每个版本都可说出它是从哪个版本导出的演化过程。
        必须注意到,修正后的新版本往往不能完全代替老版本,尽管新版本有某些优越的特性。因为一些用户仍然使用着老版本,并且不能立刻做到以旧换新,否则可能会打扰老版本原有的工作环境。显然,多个版本被多个用户同时使用的情况是不可避免的现实,这就要求多个版本共存,这也就是配置管理要解决的一个重要课题。
        配置项的状态通常有3种,分别是草稿、正式发布和正在修改。一般来说,配置项版本控制的流程如下:
        (1)创建配置项。
        (2)修改处于草稿状态的配置项。
        (3)技术评审或领导审批。
        (4)正式发布。
        (5)变更和修改版本号。
        版本管理要解决的第一个问题是版本标识,也就是为区分不同的版本,要给它们科学的命名。通常有两种版本命名的方法,分别是号码版本标识和符号版本标识。其中号码版本标识以数字表示,如用1.0,2.0,1.2,2.1.1等表示版本号;符号版本标识是将重要的版本属性有选择地给出,如Windows XP、Windows 2003、Jbuilder 2005将版本产生的时间给出。为了从版本标识上看到更多信息,可能给出更多的属性,如面向的客户群、开发语言、硬件平台、生成日期等。
        在配置管理中,版本包括配置项的版本和配置的版本,这两种的版本的标识应该各有特点,配置项的版本应该体现出其版本的继承关系,它主要是在开发人员内部进行区分。另外,还需要对重要的版本做一些标记,如对纳入基线的配置项版本应该做一个标识。
 
       配置管理
        随着信息系统软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发、维护面临越来越多的问题,其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目,对每个项目的变更进行管控(版本控制),并维护不同项目之间的版本关联,以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括:配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准,制定配置管理计划,主要包括以下内容。
               (1)该项目对配置管理的要求。
               (2)实施配置管理的责任人、组织及其职责。
               (3)需要开展的配置管理活动及其进度安排。
               (4)采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性,及其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理,“配置”经常被划分为各类配置项,这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合,在配置管理过程中,配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档,源程序与目标代码,以及运行所需的各种数据等。同时,应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加,修改或删除,配置项的版本随之演变。应当记录每个软件配置项的所有历史记录,并记录该软件配置项由何人创建,何人在何时因何原因进行了修改等信息,以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分,包含评估、协调、批准/拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程,确认受控软件配置项满足需求并就绪。其内容如下。
               (1)功能审计:配置项的变更控制是否和配置管理计划中的描述相一致。
               (2)物理审计:配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单,变更请求当前的处理状态,以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程,它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       配置项
        GB/T 11457—2006对配置项的定义为:“为配置管理设计的硬件、软件或二者的集合,在配置管理过程中作为一个单个实体来对待。”配置项的例子有:交付的软件产品和数据,用于创建或支持软件产品的支持工具,供应商提供的软件和客户提供的设备/软件,各类文档,源代码,可执行代码,测试用例,运行软件所需的各种数据等。
        在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如,基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO(配置管理员)严格管理,基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB及相关人员开放。
   题号导航      2015年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第26题    在手机中做本题