免费智能真题库 > 历年试卷 > 信息系统监理师 > 2010年下半年 信息系统监理师 上午试卷 综合知识
  第33题      
  知识点:   配置项标识   基线   配置项   生命周期   项目生命周期
  关键词:   基线   配置项   生命周期        章/节:   软件与软件工程知识       

 
基线(Baseline)是指一个(或一组)配置项在项目生命周期的不同时间点上通过(33)而进入正式受控的一种状态。
 
 
  A.  领导批准
 
  B.  质量控制
 
  C.  正式评审
 
  D.  验收测试
 
 
 

 
  第38题    2012年下半年  
   55%
软件配置管理应满足“ (38) ”、“可见性”和“可控性”要求。
  第32题    2014年上半年  
   49%
软件配置管理项应满足的特性不包括()。
  第29题    2014年下半年  
   56%
软件配置管理项都必须做到“文实相符,文文一致”,以满足”有效性”、“可见性”和 (29)要求。
   知识点讲解    
   · 配置项标识    · 基线    · 配置项    · 生命周期    · 项目生命周期
 
       配置项标识
        软件过程的输出信息可以分为以下三个主要类别:
        (1)计算机程序,包括源代码和可执行程序。
        (2)描述计算机程序的文档,分别针对技术开发者、管理人员和用户。
        (3)数据,包含在程序内部或外部。
        这些信息包含了所有在软件过程中产生的信息,总称为软件配置项(Software Configuration Item,SCI)。由此可见,配置项的识别是配置管理活动的基础,也是制订配置管理计划的重要内容。
        在软件的开发过程中把所有需要加以控制的配置项分为基线配置项和非基线配置项两类。例如,基线配置项可能包括所有的设计文档和源程序等,非基线配置项可能包括项目的各类计划和报告等。基线又称为里程碑,通常作为一个阶段完成的标志。
        所有配置项都应按照相关规定统一编号,按照相应的模板生成,并在文档的规定章节(部分)中记录对象的标识信息。在引入软件配置管理工具进行管理后,这些配置项都应以一定的目录结构保存在配置库中。
        在配置管理系统中,应建立下列三个库。
        (1)开发库(动态系统)。存放开发过程中需要保留的各种信息,供开发人员个人专用。库中的信息可能有较为频繁的修改,只要开发库的使用者认为有必要,无须对其做任何限制。因为这通常不会影响到项目的其他部分,而仅在项目开发组内设立,并由其负责维护。
        (2)受控库(主库)。在信息系统开发的某个阶段工作结束时,将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的及人工可读的文档资料,通常以软件配置项为单位建立并维护。
        (3)产品库(静态系统,备份库)。在开发的信息系统产品完成系统测试之后,作为最终产品存入库存内,等待交付用户或现场安装,可在系统、子系统级上设立并维护。
        各类库中应存放哪些配置项,应根据所开发软件的实际情况决定。
 
       基线
        基线(baseline)是项目生存期各开发阶段末尾的特定点,也称为里程碑(milestone),在这些特定点上,阶段工作已结束,并且已经形成了正式的阶段性产品。
        建立基线的概念是为了把各开发阶段的工作划分得更加明确,使得本来连续开展的开发工作在这些点上被分割开,从而更加有利于检验和肯定阶段工作的成果,同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果,并且认为建立了里程碑,有些完成的阶段成果已被冻结。
        作为阶段工作的正式产品,基线应该是稳定的,如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿,就不能作为基线,不能被冻结。
        如果把软件看作是系统的一个组成部分,以下3种基线最受人们关注的:功能基线、分配基线、产品基线。
        (1)功能基线:指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
        (2)分配基线(指派基线):指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
        (3)产品基线:指在软件组装与系统测试阶段结束时,经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
        另外,交付给外部顾客的基线一般称为发行基线,内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
        :提出基线的概念本来是为了更好地实现变更控制,但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如,假定某个大型软件中的一个模块修改了,如果将这一变更当做整个软件产品基线的变更,就很不方便。
 
       配置项
        GB/T 11457—2006对配置项的定义为:“为配置管理设计的硬件、软件或二者的集合,在配置管理过程中作为一个单个实体来对待。”配置项的例子有:交付的软件产品和数据,用于创建或支持软件产品的支持工具,供应商提供的软件和客户提供的设备/软件,各类文档,源代码,可执行代码,测试用例,运行软件所需的各种数据等。
        在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如,基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO(配置管理员)严格管理,基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB及相关人员开放。
 
       生命周期
        IT服务生命周期由规划设计(Planning&Design)、部署实施(Implementing)、服务运营(Operation)、持续改进(Improvement)和监督管理(Supervision)5个阶段组成,简称“PIOIS”。
        (1)规划设计:从客户业务战略出发,以需求为中心,参照ITSS对IT服务进行全面系统的战略规划和设计,为IT服务的部署实施做好准备,以确保提供满足客户需求的IT服务。
        (2)部署实施:在规划设计基础上,依据ITSS建立管理体系、部署专用工具及服务解决方案。
        (3)服务运营:根据IT服务部署情况,依据ITSS,采用过程方法,全面管理基础设施、服务流程、人员和业务连续性,实现业务运营与IT服务运营的全面融合。
        (4)持续改进:根据IT服务运营的实际情况,定期评审IT服务满足业务运营的情况,以及IT服务本身存在的缺陷,提出改进策略和方案,并对IT服务进行重新规划设计和部署实施,以提高IT服务质量。
        (5)监督管理:本阶段主要依据ITSS对IT服务质量进行评价,并对IT服务供方的服务过程、交付结果实施监督和绩效评估。
 
       项目生命周期
               项目生命周期的定义
               项目生命周期指项目从启动到收尾所经历的一系列阶段。
               项目生命周期通常规定:
               .每个阶段应完成哪些技术工作?
               .每个阶段的交付物应何时产生?对每个交付物如何进行评审、验证和确认?
               .每个阶段都有哪些人员参与?
               .如何控制和批准每个阶段?
               项目阶段的特征:
               .每个项目阶段都以一个或多个可交付成果的完成为标志。
               .项目阶段的结束通常以对完成工作与可交付成果的审查为标志。
               .在未决定是否启动任何其他阶段时,也可以结束一个阶段。
               .阶段的正式完成不包括核准随后的阶段。阶段末审查往往称为阶段放行口、阶段关卡或验收站。
               项目生命周期的特征
               大多数项目生命周期都具有如下特征:
               .在初始阶段,费用和人员水平较低,在中间阶段达到最高,当项目接近结束时则快速下降。
               .项目初始阶段不确定性水平高,因此不能达成项目目标的风险也高,后续阶段完成项目的确定性逐渐变好。
               .随着项目阶段的深入,变更和缺陷修改的费用通常会增加。
               .项目初始阶段,项目干系人影响项目的最终产品特征的能力最高,随着项目的继续逐渐变低。
               项目生命周期与产品生命周期的关系
               产品生命周期开始于经营计划,经过构思,到产品,到日常经营和产品退出市场。
               在某些应用领域,项目生命周期可以视为产品生命周期的一部分。
               典型信息系统项目生命周期模型
                      瀑布模型
                      经典的软件生命周期模型,也叫预测型生命周期、完全计划驱动型生命周期。在项目开始时就对产品和可交付成果进行定义,对任何范围变化都要进行仔细管理。
                      瀑布模型一般将软件开发分为可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段,通过顺序执行各个阶段的活动来完成项目。瀑布模型适用于需求明确或很少变更的项目,适用于充分了解拟交付的产品,有厚实的行业实践基础,或者整批一次性交付产品有利于干系人的项目。
                      迭代和增量模型
                      迭代方法是通过一系列重复的循环活动来开发产品,而增量方法是渐进地增加产品的功能。一次迭代中,将执行所有项目管理过程组中的活动。每次迭代结束时,将完成一个或一组可交付成果。后续迭代可能对这些可交付成果进行改进,也可能创造新的可交付成果。
                      RUP是迭代模型的一种,可分四个阶段:初始、细化、构造、移交,这四个阶段的顺序执行就形成了一个周期。各阶段的主要任务有:
                      .初始阶段:系统地阐述项目的范围,选择可行的系统构架,计划和准备业务案例。
                      .细化阶段:细化构想,细化过程和基础设施,细化构架并选择构件。
                      .构造阶段:资源管理、控制和过程最优化,完成构件的开发并依据评价标准进行测试,依据验收标准评估产品的发布。
                      .移交阶段:同步并使开发的构造增量集成到一致的实施基线中,根据完整的构想和需求集的验收标准评估与实施有关的工程活动的实施基线。
                      迭代和增量模型适用于组织需要管理不断变化的目标和范围,组织需要降低项目的复杂性,或者,产品的部分交付有利于一个或多个干系人,且不会影响最终或整批可交付成果的交付。大型复杂项目通常采用迭代方式来实施,这使项目团队可以在迭代过程中综合考虑反馈意见和经验教训,从而降低项目风险。
                      敏捷方法
                      敏捷方法也被称为适应型生命周期或变更驱动方法,是为了应对大量变更,获取干系人的持续参与而采用的方法。适应型生命周期也包含迭代和增量的概念,但和迭代增量模型不同之处在于,迭代很快(通常2~4周迭代1次),而且所需时间和资源是固定的。
                      敏捷方法是一种应对快速变化的需求的软件开发方法,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队,也更注重软件开发中人的作用。
                      敏捷方法适用于需要应对快速变化的环境,需求和范围难以事先确定的情况,或者能够以有利于干系人的方式定义较小的增量改进的情况。
                      V模型
                      V模型如下图所示,左边开发过程的各开发阶段和右边测试过程的各测试阶段相互对应,形成了字母“V”的形状。
                      
                      V模型示意图
                      V模型的价值在于它非常明确地标明了测试过程中存在的不同阶段,并且清楚地描述了这些测试阶段和各开发阶段的对应关系。
                      原型化模型
                      原型化模型是为弥补瀑布模型的不足而产生的。
                      原型化模型首先要构造一个快速原型,实现客户或未来的用户与系统的交互,经过和用户针对原型的讨论和交流,弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后,再在原型基础上开发出用户满意的产品。在实际中,原型化经常在需求分析定义的过程中进行。原型化模型减少了瀑布模型因为软件需求不明确而给开发工作带来的风险,因为在原型基础上的沟通更为直观,也为需求分析和定义提供了新的方法。
                      一般有两种原型,即抛弃型原型和进化型原型:
                      .抛弃型原型:此类原型在系统真正实现以后就抛弃不用了。
                      .进化型原型:此类原型的构造从目标系统的一个或多个基本需求出发,通过修改和追加的过程逐渐丰富,演化成为最终的系统。
                      对于复杂的大型软件,开发一个原型往往达不到要求,为减少开发风险,在瀑布模型和原型化模型的基础上演进,出现了螺旋模型以及大量使用的RUP。
                      螺旋模型
                      螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来,使得软件的增量版本的快速开发成为可能。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。
   题号导航      2010年下半年 信息系统监理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第33题    在手机中做本题