25、配置与变更管理
本章学习建议:
本章可能考选择和案例。按考试大纲,论文也是可能考的,但是论文到目前为止,还没单独考一个大题,但是曾经在论文的子题目考到,比如就曾经用论文考过变更的流程。请认真学原文,尽力理解相关知识点。
19.1 配置管理
1、配置管理是为了系统地控制配置变更,在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性,而标识信息系统建设在不同时间点上配置的学科。
2、应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征,控制这些特征的变更,记录和报告变更处理和实现状态并验证与规定的需求的遵循性。
19.1.1 管理基础
1、配置项
比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等,它们经评审和检查通过后进入配置管理。所有配置项都应按照相关规定统一编号,并以一定的目录结构保存在 CMDB中。例如,在信息系统的开发项目中需加以控制的配置项可以分为基线配置项和非基线配置项两类,基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由配置管理员严格管理,基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向项 教案下目载:www.1ppt.com/jiaoan/ PPT论坛:www.经1ppt.cn 理、CCB及相关人员开放。
2、配置项状态
可将配置项状态分为“草稿”“正式”和“修改”三种。配置项刚建立时,其状态为“草稿”。配置项通过评审后,其状态变为“正式”。此后若更改配置项,则其状态变为“修改”。当配置项修改完毕并重新通过评审时,其状态又变为"正式”。
图19-1 配置项状态变化
3、配置项版本号
当配置项修改完毕,状态成为正式时,将Z值设置为0,增加 X.Y 值。
4、配置项版本管理
在信息系统开发项目过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或 教案下混载:www.1ppt.com/jiaoan/ PPT论坛:www.淆1ppt.cn 等现象,并且可以快速准确地查找到配置项的任何版本。
5、配置基线
1、配置基线由一组配置项组成,这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。
2、基线中的配置项被“冻结”了,不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。例如,一组拥有唯一标识号的需求、设计、源代码文档以及相应的可执行代码、构造文档和用户文档构成一条基线。产品的一个测试版本也是基线的例子。
3、基线通常对应于项目过程中的里程碑,一个项目可以有多个基线,也可以只有一个基线。交付给用户使用的基线一般称为发行基线,内部过程使用的基线一般称为构造基线。
6、配置管理数据库
1、我们常使用配置库管理数据库来管理配置项,它是指包含每个配置项及配置项之间重要关系的详细资料的数据库。对于信息系统开发项目来说,常使用配置库实施配置数据的管理。配置管理数据库主要内容包括:
2、配置管理数据库管理所有配置项及其关系,以及与这些配置项有关的事件、问题、已知错误、变更和发布及相关的员工、供应商和业务部门信息;保存多种服务的详细信息及这些服务与IT 组件之间的关系;保存配置项的财务信息,如供应商、购买费用和购买日期等。
7、配置库
1、配置库可以分开发库、受控库、产品库3种类型。
(1)开发库,也称为动态库、程序员库或工作库,用于保存开发人员当前正在开发的配置实体,如:新模块
、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人
工作区,由开发人员自行控制。库中的信息可能有较为频繁的修改,只要开发库的使用者认为有必要,无需
对其进行配置控制,因为这通常不会影响到项目的其他部分。可以任意的修改。(2)受控库,也称为主库,包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之
下。在信息系统开发的某个阶段工作结束时,将当前的工作产品存入受控库。可以修改,需要走变更流程。
(3)产品库,也称为静态库、发行库、软件仓库,包含已发布使用的各种基线的存档,被置于完全的配置管在开发的信息系统产品完成系统测试之后,作为最终产品存入产品库内,等待交付用户或现场安装
。一般不再修改,真要修改的话需要走变更流程。
配 置 与 变 更 管 理
2、配置库的建库模式有两种:按配置项类型建库和按开发任务建库。
(1)按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内,往往产品的继承性较强,工具比较统一,对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制,同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的,所以可能会造成开发人员的工作目录结构过于复杂,带来一些不必要的麻烦
(2)按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内,使用的开发工具种类繁多,开发模式以线性发展为主,所以没必要把配置项严格分类存储,人为增加目录的复杂性。对于研发性的软件组织来说,采用这种设置策略比较灵活。
19.1.2 角色与职责
配置管理相关角色常包括:变更控制委员会(CCB)、配置管理负责人、配置管理员和配置项负责人等。24年第2批考题
1、配置管理负责人
配置管理负责人也称配置经理,负责管理和决策整个项目生命周期中的配置活动。具体有:
2、配置管理员
配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动,具体有:24年第2批考题
3、配置项负责人
配置项负责人确保所负责的配置项的准确和真实:
19.1.3 目标与方针
1、管理目标
针对信息系统开发项目,常需要通过实施软件配置管理达到配置管理的目标,即在整个软件生命周期中建立和维护项目产品的完整性。
2、管理方针
无重要考点。
19.1.4 管理活动
配置管理的日常管理活动主要包括:制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。
1、 制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划,是配置管理过程的基础,应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。
2、 配置项识别
配置项识别是识别所有信息系统组件的关键配置,以及各配置项间的关系和配置文档等结构识别。它包括为配置项分配标识和版本号等。配置项识别是配置管理的一项基础性工作,要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。
(1)确定配置项范围。
(2)确认和记录配置项属性。
(3)为配置项定义标识符。
(4)确定配置基准线。
(5)确定配置结构。
(6)确定配置项命名规则。
3、配置项控制
配置项控制即对配置项和基线的变更控制,包括:标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。
(1)变更申请。(2)变更评估。CCB负责组织对变更申请进行评估并确定:
CCB 决定是否接受变更,并将决定通知相关人员。
通告评估结果。CCB 把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干如果变更申请得到批准,应该及时把变更批准信息和变更实 范教文案下下施载载::wwwwww..11pppptt..ccoomm//jfiaanowaen/n / P P T 论试坛卷:下w载ww:.方w1pwptw..c1nppt.com/shiti/ 案通知给那些正在使用受影响的配置基线的干系人。如果变更申请被否决,应通知有关干系人放弃该变更申请。(4)变更实施。项目经理组织修改相关的配置项,并在相应的文档、程序代码或配置管理数据中记录变更信息。
(5)变更验证与确认。项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB,由其确认变更是否已经按要求完成。
(6)变更的发布。配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员,并做好记录。
(7)基于配置库的变更控制。
现以某软件产品升级为例,其过程简述为:
(1)将待升级的基线(假设版本号为 V2.1 )从产品库中取出,放入受控库。
(2)程序员将欲修改的代码段从受控库中检出(Check out ),放入自己的开发库中进行修改。代码被检出后即被“锁定”以保证同一段代码只能同时被1个程序员修改。如PPW节优资范教PPoTT日秀料文案r模背dPP下下下教PP板景TT载载载程模下下图::::板载载片www ::::wwwwwwwwwwww...wwwww111.pppwwww1ppp....pttt1111...pppppccct.ppppooocttttmmm....occcc///mjoooofziai/almmmminwo////awjxaboiomireeen/ao idr/nzj ib/i/a/ an i果 /g n // P P T 行PP PE论PPPP试xPTT业TcT坛e卷图教P素l课P:教T下表程材件w模程载下:下w下 板:w:载载w载.w:w1w:::pwwwwwpwww.twww.1w..cww1p1wnw.ppwp..1tp.1p.1pt1tcp.p.ppocpcptpot.omt.tc.m/c.mcocpo/o/omeosmm/xhmw//ciht/tseeakiulur/n/ebc p gijaioayi ai /oenn/t// / 甲 正对其修改,乙就无法 Check out。(3)程序员将开发库中修改好的代码段检入(Check in )受控库。检入后,代码的“锁定”被解除,其他程序员可以 Check out 该段代码了。
(4)软件产品的升级修改工作全部完成后,将受控库中的新基线存入产品库中(软件产品 的版本号更新为V2.2 ,旧的 V2.l 版并不删除,继续在产品库中保存)
4、配置状态报告
配置状态报告也称配置状态统计,其任务是有效地记录和报告管理配置所需要的信息,目的是及时、准确地给出配置项的当前状况,供相关人员了解,以加强配置管理工作。在信息系统项目中,配置项在不停地演化着。配置状态报告就是要在某个特定的时刻观察当时的配置状态,也就是要对动态演化着的配置项取个瞬时的“照片”,以利于在状态报告信息分析的基础上,更好地进行控制。配置状态报告应该主要包含:
(1)每个受控配置项的标识和状态。一旦配置项被置于配置控制下,就应该记录和保存它的每个后继进展的版本和状态。
(2)每个变更申请的状态和已批准的修改的实施状态。
(3)每个基线的当前和过去版本的状态以及各版本的比较。
(4)其他配置管理过程活动的记录等。
23年11月第3批考题
5、配置审计
1、配置审计也称配置审核或配置评价,包括功能配置审计和物理配置审计,分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性,体现了配置管理的最根本要求,不允许出现任何混乱现象。23年5月第59,23年11月第1、4批考题
1)功能配置审计。功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致),验证:
(1)配置项的开发已圆满完成。
(2)配置项已达到配置标识中规定的性能和功能特征。
(3)配置项的操作和支持文档已完成并且是符合要求的等。
2)物理配置审计。物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致)。具体验证(1)要交付的配置项是否存在。
(2)配置项中是否包含了所有必需的项目。
2、一般来说,配置审验应当定期进行,应当进行配置审计的场景包括:
3、部分常规配置审计工作可由审计软件完成,如比较两台计算机的配置情况,分析工作站并报告它当前的状况。但要注意的是,审计软件即使发现不一致的情况,也不允许自动更新配置库或配置管理数据库,必须由有关负责人调查后再进行更新。24年第1批考题
6、配置管理回顾与改进
望回顾与改进即定期回顾配置管理活动的实施情况,发现在配置管理执行过程中有无问题,我到改进而优化配置管理过程。配置管理回顾及改进活动包括:
19.2 变更管理
19.2.1 管理基础
变更管理的实质是根据项目推进过程中越来越丰富的项目认知,不断调整项目努力方向和资源配置,最大程度地满足项目需求,提升项目价值。
1、变更管理与配置管理
如果把项目整体的交付物视作项目的配置项,配置管理可视为对项目完整性管理的一套系统,当用于项目基准调整时,变更管理可视为其一部分。
2、变更产生的原因 23年5月第60考题变更的常见原因包括:
3、变更的分类
通常来说,根据变更性质可分为重大变更、重要变更和一般变更,通过不同审批权限进行控制。根据变更的迫切性可分为紧急变更、非紧急变更。
4、项目变更的含义
变更管理是为使得项目基准与项目实际执行情况相一致,应对项目变化的一套管理方法。其可能的两个结果是拒绝变化,或是调整项目基准。23年5月第60考题
19.2.2 管理原则
变更管理的原则是项目基准化和变更管理过程规范化。主要内容包括:
(1)基准管理:基准是变更的依据。每次变更通过评审后,都应重新确定基准。
(2)变更控制流程化:建立或选用符合项目需要的变更管理流程,所有变更都必须遵循这个控制流程。
(3)明确组织分工:至少应明确变更相关工作的评估、评审、执行的职能。
(4)评估变更的可能影响(5)妥善保存变更产生的相关文档:确保其完整、及时、准确和清晰,适当时可以引入配置管理工具。
19.2.3 角色与职责
1、项目经理在变更中的作用是:响应变更提出者的需求;评估变更对项目的影响及应对方案;将需求由技术要求转化为资源需求,供授权人决策;并据评审结果实施(即调整基准),确保项目基准反映项目实施情况。
2、信息系统项目中,除项目经理和CCB外,通常还会定义变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。
1、变更管理负责人
变更管理负责人也称变更经理,通常是变更管理过程解决方案的负责人,其主要职责包括:
(1)负责整个变更过程方案的结果
(2)负责变更管理过程的监控
(3)负责协调相关的资源,保障所有变更按照预定过程顺利运作
(4)确定变更类型,组织变更计划和日程安排
(5)管理变更的日程安排
(6)变更实施完成之后的回顾和关闭
(7)承担变更相关责任,并且具有相应权限
(8)可能以逐级审批形式或团队会议的形式参与变更的风险评估和
23年11月第3批, 24年第2批考题
2、变更请求者
变更请求者负责记录与提交变更请求单,具体为:
(1)提交初步的变更方案和计划
(2)初步评价变更的风险和影响,给变更请求设定适当的变更类型(3)对理解变更过程有能力要求等。
3、变更实施者
变更实施者需要拥有有执行变更方案的内容的技术能力,负责按照实施计划实施具体的变更任务
4、变更顾问委员会
变更顾问委员会负责对重大变更行使审批,提供专业意见和辅助审批,具体为:
(1)在紧急变更时,其中被授权者行使审批权限(2)定期听取变更经理汇报,评估变更管理执行情况,必要时提出改进建议等。
19.2.4 工作程序 24年第1批案例
(1) 变更申请
变更提出应当及时以正式方式进行,并留下书面记录。变更的提出可以是各种形式,但在评估前应以书面形式提出。项目的干系人都可以提出变更申请,但一般情况下都需要经过指定人员进行审批,一般项目经理或者项目配置管理员负责该相关信息的收集,以及对变更申请的初审。
(2) 对变更的初审
变更初审的目的主要包括:
变更初审的常见方式为变更申请文档的审核流转。
(3) 变更方案论证
变更方案的主要作用,首先是对变更请求是否可实现进行论证,如 教案下果载:www.1ppt.com/jiaoan/ PPT论坛:www.可1ppt.cn 能实现,则将变更请求由技术要求转化为资源需求,以供CCB 决策。对于一些大型的变更,可以召开相关的变更方案论证会议,通常需要由变更顾问委员会(相关技术和经济方面的专家组成)进行相关论证,并将相关专家意见作为项目变更方案的一部分,报项目CCB 作为决策参考。
(4) 变更审查
变更审查过程是项目所有者根据变更申请及评估方案,决定是否变更项目基准。
(5) 发出通知并实施
(6) 实施监控
变更实施的过程监控,通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等,也可以通过监理单位完成监控。
(7) 效果评估
变更评估的关注内容主要包括:
(8) 变更收尾
变更收尾是判断发生变更后的项目是否已纳入正常轨道。
19.2.5 变更控制
在项目整体压力较大的情况下,更需强调变更的提出和处理应当规范化,可以使用分批处理、分优先级等方式提高效率。项目规模小、与其他项目的关联度小时,变更的提出与处理过程可在操作上力求简便、高效。但小项目的变更仍应注意对变更产生的因素施加影响(如防止不必要的变更,减少无谓的评估,提高必要变更的通过效率等),对变更的确认应当正式化,变更的操作过程应当规范化等。23年5月第60考题
1、变更申请的控制应严格控制变更申请的提交。
2、变更过程控制无重要考点。
19.2.6 版本发布和回退计划
1、对于很多信息系统开发项目来说,项目变更必须做相应的版本发布,并制定相应的应急回退方案。为确保版本发布的成功,在版本发布前应对每次版本发布进行管理,并做好发布失败后的回退方案。
2、版本发布前的准备工作包括:
3、回退步骤通常包括:
19.3 项目文档管理
信息系统相关信息(文档)是指某种数据媒体和其中所记录的数据。它具有永久性,并可以由人或机器阅读,通常仅用于描述人工可读的东西。
19.3.1 管理基础
、对于信息系统开发项目来说,其文档一般分开发文档、产品文档和管理文档。
(1)开发文档描述开发过程本身,基本的开发文档包括:可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明。
(2)产品文档描述开发过程的产物,基本的产品文档包括:培训手册、参考于册和用户指南、软件支持手册、产品手册和信息广告。
(3)管理文档记录项目管理的信息,例如:开发过程的每个阶段的进度和进度变更的记录:软件变更情况的记录:开发团队的职责定义、项目计划、项目阶段报告;配置管理计划。
23年11月第2、3批,24年第1批考题
2、文档的质量通常可以分为4级:
(1)最低限度文档 (1级文档):适合开发工作量低于一个人月的开发者自用程序。
(2)内部文档(2级文档):可用于没有与其他用户共享资源的专用程序。
(3)工作文档(3级文档):适合于由同一单位内若干人联合开发的程序,或可被其他单位使用的程序。
(4)正式文档(4级文档):适合那些要正式发行供普遍使用的软件产品。
19.3.2 规则和方法
文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。(1)文档书写规范。管理信息系统的文档资料涉及文本、图形和表格等多种类型,无论是哪种类型的文档遵循统一的书写规范,包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写
日期等。图表编号规则。在管理信息系统的开发过程中用到很多的图表,对这些图表进行有规则地编号,可以
方便图表的查找。(3)文档目录编写标准。为了存档及未来使用的方便,应该编写文档目录。管理信息系统的文档目录中应档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。(4)文档管理制度。文挡的管理制度须根据组织实体的具体情况而定,主要包括建立文档的相关规范、文记录的登记制度、文档使用权限控制规则等。
23年5月第61考题
考题举例
1、在配置审计的工作中,(59)不属于功能配置审计验证的内容。
A、要交付的配置项是否存在
B、配置项的开发已圆满完成
C、 配置项已达到配置标识中规定的性能和功能特征
D、配置项的操作和支持文档已完成并且是符合要求的
2、关于项目变更管理的描述,不正确的是(60)。
A、项目范围(工作)和产品范围(工作)定义的过失或者疏忽不属于变更的原因B、项目规模小、与其他项目的关联度越小时,变更的提出和处理过程可在操作上力求简便、高效C、变更管理的实质是根据项目情况不断调整项目方向和资源配置,最大程度满足项目需求D、在项目变更过程控制中,需要对进度变更控制、成本变更控制和合同变更控制等进行重点关注
3、文档的规范化管理主要体现在(61)方面。
4、关于软件配置管理的描述,不正确的是(11)。
A、配置控制委员会成员必须是专职人员
B、配置库包括动态库(开发库),受控库(主库)、静态库(产品库)
C、常用的配置管理工具有SVN、GIT等
D、配置项的状态分为草稿、正式和修改三种
5、运维过程中发现待修改问题,程序员首先需将待修改代码从()中取出放入(),其次检出代码段放入(),修改完成被检入受控库后,才能被其他程序员检出。
A.产品库 开发库 受控库B.受控库 开发库 产品库C.受控库 产品库 开发库D.产品库 受控库 开发库
6、版本发布前的准备工作包括:
A、
7、以下属于物理配置审计的是 ()
A、配置项的开发已圆满完成
B、配置项已达到配置标识中规定的性能和功能特征
C、配置项的操作和支持文档已完成并且是符合要求的等
D、要交付的配置项是否存在
8、以下关于文档的说法中,错误的是()。
A、对于信息系统开发项目来说,其文档一般分开发文档、产品文档和管理文档。
B、产品文档描述开发过程的产物,基本的产品文档包括:培训手册、参考于册和用户指南、软件支持手册、产品手册和信息广告。
C、工作文档(3级文档):适合于由同一单位内若干人联合开发的程序,或可被其他单位使用的程序。D、文档书写规范是在管理信息系统的开发过程中用到很多的图表,对这些图表进行有规则地编号,可以方便图表的查找。
9、关于配置管理的说法中,错误的是()。
A、所有配置项的操作权限应由配置管理员严格管理,基本原则是:基线配置项向开发人员开放读非基线配置项向项目经理、CCB及相关人员开放。
B、可将配置项状态分为“草稿”“正式”和“修改”三种
C、由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。
D、配置库可以分开发库、受控库、产品库、备份库4种类型。
10、以下说法中,错误的是()
A、配置状态报告就是要在某个特定的时刻观察当时的配置状态,也就是要对静态的配置项取个瞬时的“片”。
B、配置管理计划是CMO编写完成的。
C、配置项识别是识别所有信息系统组件的关键配置,以及各配置项间的关系和配置文档等结构识别。D、配置项控制即对配置项和基线的变更控制,包括:标识和记录变更申请、分析和评价变更、批准或否申请、实现、验证和发布已修改的配置项等任务。
11、对于信息系统开发项目来说,其文档一般分开发文档、产品文档和管理文档。不属于开发文档的是()
A、软件集成计划 B、安全和测试信息 C、配置管理计划 D、可行性研究报告
12、关于配置审计的描述,不正确的是()
A、审计软件即使发现不一致的情况,也不允许自动更新配置库或配置管理数据库,必须由有关负责
后再进行更新
B、配置审计也称配置审核或配置评价,包括功能配置审计和物理配置审计
C、功能配置审计是审计配置项的完整性,物理配置审计是审计配置项的一致性
D、验证配置项的开发已圆满完成属于功能配置审计
1、【答案】A
【解析】本题考查功能配置审计内容,必须会。P563页。功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致),具体验证主要包括:
2、【答案】A
【解析】本题考查变更管理相关内容,必须会。P564页。变更的常见原因包括:
3、【答案】D
【解析】本题考查文档规范化相关内容,建议会。
P569页。文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
4、【答案】A
【解析】考查软件配置管理相关知识,必须掌握CCB不必是常设机构,完全可以根据工作的需要组成,小的项目CCB可以只有一个人,甚至只是兼职人员。
5、【答案】D
【解析】考查的是配置管理的相关知识。必须掌握马老师重点讲过这个题。
6、【答案】A
【解析】本题考查版本发布的相关内容,必须会。
P568, 请按上面的顺序读下就好。
7、【答案】D
【解析】本题考查物理配置审计的相关内容,必须会。P563,功能配置审计:是审计配置项的一致性(配置项的实际功效是否与其需求一致),具体验证主要包括:
(1)配置项的开发已圆满完成(2)配置项已达到配置标识中规定的性能和功能特征(3)配置项的操作和支持文档已完成并且是符合要求的等。物理配置审计:是审计配置项的完整性(配置项的物理存在是否与预期一致),具体验证主要包括(1)要交付的配置项是否存在(2)配置项中是否包含了所有必需的项目等。
8、【答案】D
【解析】本题考查文档的相关内容,必须会。
P570,文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
(1)文档书写规范。管理信息系统的文档资料涉及文本、图形和表格等多种类型,无论是哪种类型的文档都应该遵循统一的书写规范,包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
(2)图表编号规则。在管理信息系统的开发过程中用到很多的图表,对这些图表进行有规则地编号,可以方便图表的查找。
(3)文档目录编写标准。为了存档及未来使用的方便,应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。
(4)文档管理制度。文挡的管理制度须根据组织实体的具体情况而定,主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。
9、【答案】D
【解析】本题考查配置管理的相关内容,必须会。P558,配置库可以分开发库、受控库、产品库3种类型。
10、 【答案】A
【解析】本题考查配置管理的相关内容,必须会。P563,在信息系统项目中,配置项在不停地演化着。配置状态报告就是要在某个特定的时刻观察当时的配置状态,也就是要对动态演化着的配置项取个瞬时的“照片”,以利于在状态报告信息分析的基础上,更好地进行控制。
11、【答案】C
【解析】本题考查文档的相关内容,必须会。
P569页。对于信息系统开发项目来说,其文档一般分开发文档、产品文档和管理文档。
(1)开发文档描述开发过程本身,基本的开发文档包括:可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明(包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等)。
(2)产品文档描述开发过程的产物,基本的产品文档包括:培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。
(3)管理文档记录项目管理的信息,例如:开发过程的每个阶段的进度和进度变更的记录;软件变更情况的记录;开发团队的职责定义、项目计划、项目阶段报告:配置管理计划。
12、 【答案】C
【解析】本题考查配置审计的相关内容,必须会。P563页。配置审计也称配置审核或配置评价,包括功能配置审计和物理配置审计,分别用以验证当前配置项的一致性和完整性。