全部科目 > 系统集成项目管理工程师 >
2010年下半年 下午试卷 案例
第 5 题
知识点 配置管理   配置管理员   配置基线   质量管理   变更控制   变更控制委员会   管理体系   基线   开发人员   配置管理计划   评估   审核  
 
 
某公司的质量管理体系中的配置管理程序文件中有如下规定:
1、由变更控制委员会(CCB)制定项目的配置管理计划;
2、由配置管理员(CMO)创建配置管理环境;
3、由 CCB 审核变更计划;
4、项目中配置基线的变更经过变更申请、变更评估、变更实施后便可发布;
5、CCB 组成人员不少于一人,主席由项目经理担任。
公司的项目均严格按照程序文件的规定执行。在项目经理的一次例行检查中,发现项目软件产品的一个基线版本(版本号 V1.3)的两个相关联的源代码文件仍有遗留错误,便向 CMO 提出变更申请。CMO 批准后,项目经理指定上述源代码文件的开发人员甲、乙修改错误。甲修改第一个文件后将版本号定为 V1.4,直接在项目组内发布。次日,乙修改第二个文件后将版本号定为 V2.3,也在项目组内发布。
 
问题:5.1   请结合案例,分析该公司的配置管理程序文件的规定及实际变更执行过程存在哪些问题?
问题:5.2   请为案例中的每项工作职责指派一个你认为最合适的负责角色。(在答题纸相应的单元格中画“√”,每一列最多只能有一个单元格画“√”,多画、错画“√”不得分)

问题:5.3   请就配置管理,判断以下概念的正确性(在答题纸对应栏内,正确的画“√”,错误的画“×”):
(1) 配置识别、变更控制、状态报告、配置审计是软件配置管理包含的主要活动。( )
(2) CCB 必须是常设机构,实际工作中需要设定专职人员。 ( )
(3) 基线是软件生存期各个开发阶段末尾的特定点,不同于里程碑。 ( )
(4) 动态配置库用于管理基线和控制基线的变更。 ( )
(5) 版本管理是对项目中配置项基线的变更控制。 ( )
(6) 配置项审计包括功能配置审计和物理配置审计。 ( )




 
 
 
知识点讲解
· 配置管理
· 配置管理员
· 配置基线
· 质量管理
· 变更控制
· 变更控制委员会
· 管理体系
· 基线
· 开发人员
· 配置管理计划
· 评估
· 审核
 
        配置管理
        配置管理是为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,而标识系统在不同时间点上配置的学科。
        GB/T 11457—2006中,对“配置管理”的正式定义为:“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征,控制这些特征的变更,记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
 
        配置管理员
        配置管理员(Configuration Management Officer, CMO)负责在项目的整个生命周期中进行配置管理活动,包括:
        .编写配置管理计划。
        .建立和维护配置管理系统。
        .建立和维护配置库。
        .配置项识别。
        .建立和管理基线。
        .版本管理和配置控制。
        .配置状态报告。
        .配置审计。
        .发布管理和交付。
        .对项目成员进行配置管理培训。
 
        配置基线
        配置基线(常简称为基线)由一组配置项组成,这些配置项构成一个相对稳定的逻辑实体。基线中的配置项不能随意修改,对基线的变更必须遵循正式的变更控制程序。
        基线可以是一组拥有唯一标识号的需求、设计、源代码文件以及相应的可执行代码、构造文件和用户文档构成的产品,也可以是产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例与使用手册等)。基线需要定义的内容包括建立基线的事件,受控的配置项,建立和变更基线的程序,批准变更基线所需的权限。
        基线通常对应于开发过程中的里程碑(Milestone),一个产品可以有多个基线,也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release Baseline),内部开发使用的基线一般称为构造基线(Build Baseline)。
        建立基线有如下好处:
        .基线为开发工作提供了一个定点和快照。
        .新项目可以在基线提供的定点上建立。新项目作为一个单独分支,将与随后对原始项目(在主要分支上)所进行的变更进行隔离。
        .当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。
        .可以利用基线重新建立基于某个特定发布版本的配置,以重现已报告的错误。
 
        质量管理
        质量管理是指确定质量方针、目标和职责,并通过质量体系中的质量规划、质量保证和质量控制以及质量改进来使其实现所有管理职能的全部活动。
 
        变更控制
        变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序,其中包括必要的表格或其他书面文件,责任追踪,以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力,并由所有的项目干系人认可。在审批变更时,要加强对变更风险和变更效果的评估,并选择对项目影响最小的变更方案,尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑,形成整体。
               变更控制委员会
               变更控制委员会(Change Control Board,CCB)也称配置控制委员会(Configuration Control Board),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以全职的,也可以是兼职的。
               如果CCB除控制变更以外,还要承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
               变更控制的流程
               变更管理的基本流程如下:
               ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
               ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
               ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
               ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
               ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
               ⑥沟通存档。将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。
               变更申请需要采用书面的形式提出,主要内容有如下3个方面:
               ①变更描述。包括变更理由、变更的影响、变更的优先级等,就是要描述做什么变更,为什么要做,以及打算怎么做的问题。
               ②对变更的审批。对变更的必要性、可行性的审批意见,主要是由配置管理员和CCB对此项变更把关。
               ③变更实施的信息。
               利用配置库实现变更控制
               配置项可以有3种状态,分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来,对于其他配置项来说是处于不处理工作状态下(自由状态),此时它并未受到配置管理的控制,开发人员的变更并未受到限制。但当开发人员认为工作已告完成,可供其他配置项使用时,它就开始于稳定。把它交出评审,就开始进入评审状态;若通过评审,可作为基线进入配置库(实施检入),开始冻结,此时开发人员不允许对其任意修改,因为它已处于受控状态。通过评审表明它确已达到质量要求;但若未能通过评审,则将其回归到工作状态,重新进行调整。配置项的状态变化过程如下图所示。
               
               配置项的状态变化过程
               处于受控状态下的配置项原则上不允许修改,但这不是绝对的,如果由于多种原因需要变更,就需要提出变更请求。在变更请求得到批准的情况下,允许配置项从库中检出,待变更完成,并经评审后,确认变更无误方可重新入库,使其恢复到受控状态。
 
        变更控制委员会
        变更控制委员会(Change Control Board, CCB)也称为配置控制委员会(Configuration Control BoarD),其任务是对建议的配置项变更做出评价、审批,以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构,可以根据工作的需要组成,其中的人员可以是全职的,也可以是兼职的。
        如果CCB不只是控制变更,而是承担更多的配置管理任务,那就应该包括基线的审定、标识的审定,以及产品的审定,并且可能实际的工作需分为项目层、系统层和组织层来组建,使其完成不同层面的配置管理任务。
 
        管理体系
        灾备管理体系主要是指组织机构的各个层面,在日常状态和灾难状态下的各种管理工作,至少包括以下5个方面。
        (1)灾难恢复组织机构。商业银行应结合本行机构设置的具体情况,设立灾难恢复组织机构,包括灾难恢复规划建设、运行维护、应急响应和灾难恢复等各阶段工作所需的人员,有关人员可为专职,也可为兼职,关键岗位的人员应有备份。商业银行可以参考《JR/T0044 2008银行业信息系统灾难恢复管理规范》,设置灾难恢复组织机构,包括决策层、管理层和执行层,各层之间分工明确、职责清晰。
        (2)岗位与培训管理。灾备中心的应急生产岗位应与生产中心对等,只不过可以按照人员复用的原则,由灾备管理人员、开发测试人员或系统运维人员专职或兼职担任。对不同层次、不同部门的岗位,在灾难恢复策略规划、系统建设与运维、预案制定、演练和更新维护等不同阶段,应按照不同的培训目标,安排不同的培训计划。
        (3)灾难恢复预案管理与演练。灾难恢复预案要长期保持有效性,必须在灾难恢复策略发生变化、演练发现问题、生产系统发生变更、人员出现调整等情况下,及时修订维护预案,做好变更管理、版本管理,以及发布管理等,确保合适的人员及时获得最准确、最合适的信息。演练验证灾难恢复预案有效性的最佳手段。演练管理就是要对演练的计划、场景、人员、过程、总结评估和后续完善调整等进行全面管理,通过演练来培养灾难恢复团队面对复杂环境的信心和冷静心态,验证灾难恢复能力,改进灾难恢复流程,发现并纠正灾备体系中的缺陷。
        (4)灾备中心日常运维、灾难响应与重续运行管理。灾备中心应随时做好接替生产中心的准备,因此,必须像生产中心一样,对灾备中心的系统、网络和环境等基础资源进行运行维护,按照备份策略按时完成数据备份,完成灾备系统与生产系统的同步。当灾难发生后,灾难恢复组织机构的各层人员立即响应,在指挥报告、协调、联络、保障等工作机制的保障下,按照灾难恢复流程步骤,一步步地恢复信息系统及其支撑的关键业务功能。在生产系统成功切换到灾备中心运行后,要按照生产中心的规章制度、操作流程、技术规范来管理,保障生产系统安全稳定运行,直至生产中心重建并恢复了生产运行能力。
        (5)外部资源管理。外部资源主要指商业银行的合作伙伴、服务商、设备商和外协人员等。当发生灾难时,可能需要这些外部资源的支持才能完成灾难恢复,比如,从设备供应商紧急采购灾备生产设备,从电信运营服务商紧急租用通信线路,从银联借调交易流水等。因此,需要与这些外部资源建立日常联系或签订协议,并不定期地测试其支持能力,以保证在灾难恢复期间,外部资源可以提供有效的支持。
 
        基线
        基线(baseline)是项目生存期各开发阶段末尾的特定点,也称为里程碑(milestone),在这些特定点上,阶段工作已结束,并且已经形成了正式的阶段性产品。
        建立基线的概念是为了把各开发阶段的工作划分得更加明确,使得本来连续开展的开发工作在这些点上被分割开,从而更加有利于检验和肯定阶段工作的成果,同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果,并且认为建立了里程碑,有些完成的阶段成果已被冻结。
        作为阶段工作的正式产品,基线应该是稳定的,如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿,就不能作为基线,不能被冻结。
        如果把软件看作是系统的一个组成部分,以下3种基线最受人们关注的:功能基线、分配基线、产品基线。
        (1)功能基线:指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
        (2)分配基线(指派基线):指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
        (3)产品基线:指在软件组装与系统测试阶段结束时,经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
        另外,交付给外部顾客的基线一般称为发行基线,内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
        :提出基线的概念本来是为了更好地实现变更控制,但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如,假定某个大型软件中的一个模块修改了,如果将这一变更当做整个软件产品基线的变更,就很不方便。
 
        开发人员
        ①多媒体软件:项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物:策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
        配置管理计划
        主要内容
        配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。由配置控制委员会审批该计划。
        主要步骤
        制订配置管理计划的主要步骤如下:
        (1)建立并维护配置管理的组织方针。
        (2)确定配置管理所需要的资源。
        (3)分配责任。
        (4)培训计划。
        (5)确定和配置管理有关的项目干系人并确定其介入时机。
        (6)制订识别配置项的准则。
        (7)制订配置项管理表。
        (8)制订基线计划。
        (9)制订配置库备份计划。
        (10)制订变更控制流程。
        (11)制订审批计划。
 
        评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。
 
        审核
        依据知识库内容加入的审核标准,由资深技术人员审核内容的正确性和完整性,避免与原有的知识库内容重复或冲突,给出审核意见后提交批准加入知识库中。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2025 All Rights Reserved
软考在线版权所有