免费智能真题库 > 历年试卷 > 信息系统监理师 > 2012年下半年 信息系统监理师 上午试卷 综合知识
  第40题      
  知识点:   软件配置管理   安全性   变更控制   可靠性   配置管理   软件配置   实体   一致性
  关键词:   安全   保密   变更控制   可靠性   可追踪性   软件配置管理   实体   正确性   变更   配置管理   软件配置        章/节:   信息系统工程监理概念       

 
软件配置管理规程中应明确规定(40)。
①各级、各库中所管的软件实体的清单
②保证安全性可靠性、保密性、正确性、完备性、一致性和可追踪性的具体措施
③入库控制办法和审批手续
④出库条件及其必备的手续
变更控制办法和审批手续
 
 
  A.  ③④⑤
 
  B.  ①②③④⑤
 
  C.   ①②③④
 
  D.  ①③④⑤
 
 
 

 
  第2题    2019年上半年  
   69%
在信息系统开发项目中,( )不属于需求分析阶段监理工作的质量控制要点。
  第28题    2014年上半年  
   45%
对于监理工作而言,软件质量保证应从()时开始定义和实施,一直持续到运行期。
  第67题    2012年上半年  
   52%
(67)不属于工程监理验收报告必须包括的内容。
   知识点讲解    
   · 软件配置管理    · 安全性    · 变更控制    · 可靠性    · 配置管理    · 软件配置    · 实体    · 一致性
 
       软件配置管理
        在软件配置管理方面,监理的主要工作如下。
        (1)确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。
        (2)控制承建单位依据书面规程,为应用软件系统建设项目制定软件配置管理计划。
        (3)监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础。
        (4)控制承建单位依据的书面规程,对所有配置项/单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。
        (5)监督承建单位依据书面规程,控制对基线的更改。
        (6)控制承建单位编制软件配置管理报告,证明软件配置管理活动和软件基线库的内容,并提供给建设单位。
        (7)监督承建单位依据书面规程进行软件基线库的审核,进行软件配置管理活动状态的跟踪和记录。
        (8)定期审查软件配置管理活动和软件配置管理基线,以验证它们与文档定义的一致性。
        (9)审核软件配置管理活动及其工作产品,并给出软件配置管理监理报告。
 
       安全性
        (1)可用性。可用性评价指标及测量,如下表所示。
        
        可用性评价指标及测量
        
        (2)完整性。完整性评价指标及测量,如下表所示。
        
        完整性评价指标及测量
        (3)保密性。保密性评价指标及测量,如下表所示。
        
        保密性评价指标及测量
        
 
       变更控制
        变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序,其中包括必要的表格或其他书面文件,责任追踪,以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力,并由所有的项目干系人认可。在审批变更时,要加强对变更风险和变更效果的评估,并选择对项目影响最小的变更方案,尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑,形成整体。
               变更控制委员会
               变更控制委员会(Change Control Board,CCB)也称配置控制委员会(Configuration Control Board),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以全职的,也可以是兼职的。
               如果CCB除控制变更以外,还要承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
               变更控制的流程
               变更管理的基本流程如下:
               ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
               ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
               ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
               ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
               ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
               ⑥沟通存档。将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。
               变更申请需要采用书面的形式提出,主要内容有如下3个方面:
               ①变更描述。包括变更理由、变更的影响、变更的优先级等,就是要描述做什么变更,为什么要做,以及打算怎么做的问题。
               ②对变更的审批。对变更的必要性、可行性的审批意见,主要是由配置管理员和CCB对此项变更把关。
               ③变更实施的信息。
               利用配置库实现变更控制
               配置项可以有3种状态,分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来,对于其他配置项来说是处于不处理工作状态下(自由状态),此时它并未受到配置管理的控制,开发人员的变更并未受到限制。但当开发人员认为工作已告完成,可供其他配置项使用时,它就开始于稳定。把它交出评审,就开始进入评审状态;若通过评审,可作为基线进入配置库(实施检入),开始冻结,此时开发人员不允许对其任意修改,因为它已处于受控状态。通过评审表明它确已达到质量要求;但若未能通过评审,则将其回归到工作状态,重新进行调整。配置项的状态变化过程如下图所示。
               
               配置项的状态变化过程
               处于受控状态下的配置项原则上不允许修改,但这不是绝对的,如果由于多种原因需要变更,就需要提出变更请求。在变更请求得到批准的情况下,允许配置项从库中检出,待变更完成,并经评审后,确认变更无误方可重新入库,使其恢复到受控状态。
 
       可靠性
        (1)完备性。完备性评价指标及测量,如下表所示。
        
        完备性评价指标及测量
        (2)连续性。连续性评价指标及测量,如下表所示。
        
        连续性评价指标及测量
        
        (3)稳定性。稳定性评价指标及测量,如下表所示。
        
        稳定性评价指标及测量
        (4)有效性。有效性评价指标及测量,如下表所示。
        
        有效性评价指标及测量
        (5)可追溯性。可追溯性评价指标及测量,如下表所示。
        
        可追溯性评价指标及测量
        
 
       配置管理
        随着信息系统软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发、维护面临越来越多的问题,其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目,对每个项目的变更进行管控(版本控制),并维护不同项目之间的版本关联,以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括:配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准,制定配置管理计划,主要包括以下内容。
               (1)该项目对配置管理的要求。
               (2)实施配置管理的责任人、组织及其职责。
               (3)需要开展的配置管理活动及其进度安排。
               (4)采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性,及其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理,“配置”经常被划分为各类配置项,这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合,在配置管理过程中,配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档,源程序与目标代码,以及运行所需的各种数据等。同时,应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加,修改或删除,配置项的版本随之演变。应当记录每个软件配置项的所有历史记录,并记录该软件配置项由何人创建,何人在何时因何原因进行了修改等信息,以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分,包含评估、协调、批准/拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程,确认受控软件配置项满足需求并就绪。其内容如下。
               (1)功能审计:配置项的变更控制是否和配置管理计划中的描述相一致。
               (2)物理审计:配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单,变更请求当前的处理状态,以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程,它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       软件配置
        软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式(机器可读和人工可读)和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
 
       实体
        从上表中可见,在E-R模型中实体用矩形表示,通常矩形框内写明实体名。实体是现实世界中可以区别于其他对象的“事件”或“物体”。例如,企业中的每个人都是一个实体。每个实体由一组特性(属性)来表示,其中的某一部分属性可以唯一标识实体,如职工号。实体集是具有相同属性的实体集合,例如,学校所有教师具有相同的属性,因此教师的集合可以定义为一个实体集;学生具有相同的属性,因此学生的集合可以定义为另一个实体集。
 
       一致性
        在讨论一致性之前,先看一下CAP理论。它作为一种理论依据,使得在不同应用中,对一致性也有了不同的要求。CAP理论:简单地说,就是对于一个分布式系统,一致性(Consistency)、可用性(Availablity)和分区容忍性(Partition tolerance)三个特点最多只能三选二。
        一致性意味着系统在执行了某些操作后仍处在一个一致的状态,这点在分布式的系统中尤其明显。比如某用户在一处对共享的数据进行了修改,那么所有有权使用这些数据的用户都可以看到这一改变。简言之,就是所有的结点在同一时刻有相同的数据。
        可用性指对数据的所有操作都应有成功的返回。高可用性则是在系统升级(软件或硬件)或在网络系统中的某些结点发生故障的时候,仍可以正常返回。简言之,就是任何请求不管成功或失败都有响应。
        分区容忍性这一概念的前提是在网络发生故障的时候。在网络连接上,一些结点出现故障,使得原本连通的网络变成了一块一块的分区,若允许系统继续工作,那么就是分区可容忍的。
        在数据库系统中,事务的ACID属性保证了数据库的一致性。比如银行系统中,转账就是一个事务,从原账户扣除金额,以及向目标账户添加金额,这两个数据库操作的总和构成一个完整的逻辑过程,具有原子的不可拆分特性,从而保证了整个系统中的总金额没有变化。
        然而,这些ACID特性对于大型的分布式系统来说,是和高性能不兼容的。比如,你在网上书店买书,任何一个人买书这个过程都会锁住数据库直到买书行为彻底完成(否则书本库存数可能不一致),买书完成的那一瞬间,世界上所有的人都可以看到书的库存减少了一本(这也意味着两个人不能同时买书)。这在小的网上书城也许可以运行得很好,可是对Amazon这种网上书城却并不是很好。
        而对于Amazon这种系统,它也许会用Cache系统,剩余的库存数也许是几秒甚至几个小时前的快照,而不是实时的库存数,这就舍弃了一致性。并且,Amazon可能也舍弃了独立性,当只剩下最后一本书时,也许它会允许两个人同时下单,宁愿最后给那个下单成功却没货的人道歉,而不是整个系统性能的下降。
        由于CAP理论的存在,为了提高性能,出现了ACID的一种变种BASE(这四个字母分别是Basically Available,Soft—state,Eventual consistency的开头字母,是一个弱一致性的理论,只要求最终一致性):
        .Basically Available:基本可用。
        .Soft state:软状态,可以理解为“无连接”的,而与之相对应的Hard state就是“面向连接”的。
        .Eventual consistency:最终一致性,最终整个系统(时间和系统的要求有关)看到的数据是一致的。
        在BASE中,强调可用性的同时,引入了最终一致性这个概念,不像ACID,其并不需要每个事务都是一致的,只需要整个系统经过一定时间后最终达到一致。比如Amazon的卖书系统,也许在卖的过程中,每个用户看到的库存数是不一样的,但最终卖完后,库存数都为0。再比如SNS网络中,C更新状态,A也许可以1分钟就看到,而B甚至5分钟后才看到,但最终大家都可以看到这个更新。
        具体地说,如果选择了CP(一致性和分区容忍性),那么就要考虑ACID理论(传统关系型数据库的基石,事务的四个特点)。如果选择了AP(可用性和分区容忍性),那么就要考虑BASE系统。如果选择了CA(一致性和可用性),如Google的bigtable,那么在网络发生分区的时候,将不能进行完整的操作。
        ACID理论和BASE的具体对比如下表所示。
        
        ACID和BASE的对比表
   题号导航      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 /
 
第40题    在手机中做本题