质量保证系列课件-配置管理(V1.3).pptx

上传人:牧羊曲112 文档编号:6610337 上传时间:2023-11-17 格式:PPTX 页数:46 大小:908.18KB
返回 下载 相关 举报
质量保证系列课件-配置管理(V1.3).pptx_第1页
第1页 / 共46页
质量保证系列课件-配置管理(V1.3).pptx_第2页
第2页 / 共46页
质量保证系列课件-配置管理(V1.3).pptx_第3页
第3页 / 共46页
质量保证系列课件-配置管理(V1.3).pptx_第4页
第4页 / 共46页
质量保证系列课件-配置管理(V1.3).pptx_第5页
第5页 / 共46页
点击查看更多>>
资源描述

《质量保证系列课件-配置管理(V1.3).pptx》由会员分享,可在线阅读,更多相关《质量保证系列课件-配置管理(V1.3).pptx(46页珍藏版)》请在三一办公上搜索。

1、质量保证系列课件配置管理,HSS质量部 2012年3月,2,目录,配置管理概念,1、什么是配置管理?配置管理是通过对在产品生命周期不同时间点上的产品配置项(产品过程交付和最终交付)进行标识,并对配置项的开发、归档和变更进行系统管理,对配置项的版本进行控制,从而保证产品交付的完整性、一致性和可溯性。配置管理是对工作成果的一种有效保护。2、配置管理主要体现在项目过程中哪些地方?所有的项目成员从配置库中去制作开发的软件产品;在某一特定时刻标识软件产品的配置状态;系统地控制配置项的变更;贯穿软件生存周期,维护软件产品基线的完整性和可跟踪性。,为什么进行配置管理,代码已经编了一半了,发现取的基础版本不是

2、最新的修改完需求文档之后,发现把原本正确的修改为错误的了!执行测试时,发现变更后的代码与需求不一致,代码实现中多出某一特性#$究竟哪份才是最新修改了的源程序?小莫离职时把工作交接给我,可我不知道他在代码里修改了哪些地方系统瘫痪,所有的工作成果毁于一旦-_-!,软件配置管理正是为解决这个问题而提出的。,6,配置库的特点安全可靠性完整性、一致性方便备份和恢复,配置库介绍,配置库是指在产品生命周期过程中为存放产品数据所建立的存储空间及其上的数据。狭义的配置库单指在配置库服务器上物理体现的存储空间。,项目配置库要求统一使用配置管理工具SVN进行管理。,7,目录,8,管理策略,9,保障机制,10,角色和

3、职责,11,目录,12,集中管理,场地所有项目配置库、归 档库,物理存放到场地配置及归档服务器上,由组织级CMO统一管理配置管理工具要求,统一使用SVN项目结束1年以上的项目配置库或归档库,需要转移到历史库,配置库管理,13,创建配置库目录结构组织级CMO创建配置库时,根据QA提供的配置库目录模板创建配置库目录结构如果配置库目录不适合项目使用,PM需要和华为产品CMO、华为QA、项目QA协商定制设置配置库权限访问必须通过域用户方式 组织级CMO统一添加配置库访问权限项目级CMO控制配置库已添加访问权限人员的读写权限,14,归档库管理,管理项目转测试版本与转验收版本设置配置库权限访问必须通过域用

4、户方式 组织级CMO统一添加归档库访问权限项目级CMO控制归档库已添加访问权限人员的读写权限,15,历史库管理,管理已结束项目配置库、归档库历史配置库按PDU结构存储查询历史库信息需单独申请权限,16,目录,17,项目配置管理,配置管理计划配置项标识版本控制变更控制配置审计配置状态报告组织级配置库目录结构,配置管理计划,人员与职责配置库信息配置项标识配置项权限控制基线计划配置审计计划版本转测试检查版本转验收检查本计划审批意见,配置管理计划主要内容,CMO在项目启动时,根据项目类型、项目计划,制定配置管理计划,由CCB负责人(通常是PM)审批。,配置管理计划(CMP)规定了在软件开发中各种必要的

5、配置管理条款,并做为配置管理工作开展的依照。,配置项标识,配置项标识是对产品进行配置管理,维护在整个产品生命周期中配置的完整性、一致性和可溯性的前提和基础。,配置指一个产品在生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项(CI,Configuration Item)配置项即一个被唯一标识的实体,是被控制的系统配置的一部分,处于配置管理的控制之下。一个配置项在大小,复杂程度和类型上划分非常广泛,可以从整个的系统(包括硬件,软件和文件)到一个单一的模块。配置项可以是:与合同,计划和产品有关的文档及数据源代码,目标代码相关产品,

6、包括工具,库内可复用软件,外购软件及顾客提供的软件等。,配置项标识-配置项选择,1、PM、CCB、CMO负责识别项目配置项,写入项目配置管理计划中进行跟踪。项目配置项至少要覆盖工作任务书中交付件要求。配置项划分,要符合下列原则:,配置项标识-配置项选择,2、在制定项目配置管理计划的同时,输出合作项目交付件清单。在项目转验收时,使用合作项目交付件清单检查交付件的归档情况。合作项目交付件清单中,“Build CI Status”用于记录版本的编译构建信息,不得裁剪。详细参照帮助中的“构建工具信息填写背景及填写说明”信息。3、项目必须提供版本编译指导书,使用客户提供的版本编译指导书模板.docx进行

7、编写。4、如果项目有开展持续集成,项目必须提供版本构建指导书。使用客户提供的版本构建指导书模板.docx进行编写。,版本命名版本命名与客户工作任务书中要求的版本命名保持一致,如果工作任务书发生变更,以变更后的为准 如:AAA V300R002C01文档命名工程文档命名工程文档命名规则:版本号+空格+子系统名称/模块名称+文档类型如:AAA V300R002C01 系统设计规格说明书产品资料命名产品资料命名规则:版本号+空格+产品文档+空格+产品文档版本-文档语种。如:中文版:AAA V300R002C01 产品文档 01-zh 英文版:AAA V300R002C01 Product Docum

8、entation 01-en文档版本以XX.YY标识 XX表示大修订 YY表示小修订 如:大的修订版本号V1.0、V2.0 小的修订版本号V1.01、V1.02,配置项标识-命名规范,配置项刚建立时其状态为“草稿”对未基线的配置项可以自由修改,不需要填写提交注释,版本启动准则:项目启动配置项的状态有三种:草稿、基线、正在修改,版本控制-配置项状态变迁图,修改处于“基线”状态的配置项,必须按照“变更控制”执行执行变更过程中的配置项的状态为“正在修改”,对执行完“变更控制”的配置项需要再次执行基线化,配置项评审通过后,其状态变为“基线”对基线的配置项进行修改,需要填写提交注释(注释要求见“变更控制

9、”章节),24,版本控制-基线,基线就是配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线具有以下特征:通过正式的评审过程建立基线存在于配置库中,基线的变更由CCB控制基线是下一步开发和修改的基准,25,项目阶段基线流程,基线化申请的内容应该包含:申请基线的模块名称;申请基线化的具体阶段产品及其路径;阶段产品review记录及其路径;阶段产品质量数据,开发类阶段产品的审批人为PM;测试类阶段产品的审批人为TPM;资料类阶段产品的审批人为TDC 基线审批通过的必要条件:申请基线的阶段产品是否达到质量目标,基线审批通过后,项目CMO必须获取到“阶段评审通过”的结论才能进行基

10、线“阶段评审通过”的结论可以通过如下形式体现:在评审意见汇总表单中标识评审结论为“通过”基线批准人发邮件告知项目CMO评审通过可以基线项目级CMO回收基线产品的修改权限,打上基线标签 配置库标签命名规范:LB_版本号_xxx阶段点 标签注释规范:xx阶段基线,项目CMO负责整理生成配置状态报告向全体项目成员发布,版本构建代码基线版本构建完成后,项目级CMO基线当前版本的源代码,在代码库中打上标 签配置库标签命名规范:子系统.阶段.Baseline.yyyymmdd 如:版本转测试及转验收代码基线版本转测试或版本转验收后,项目CMO基线当前版本的阶段产品和源代码,在文档库和代码库中打上标签配置库

11、标签命名规则:LB_版本号_XXX(标签名称中不带空格)如:LB_AAAV300R002C01_SDV1 LB_AAAV300R002C01_AT1,不管是标签命名还是标签注释,格式必须按照胶片中说明的规范。整个项目的基线必须保证遵从如上基线规则,基线信息填写完整。,其他基线流程,27,版本控制-版本转测试,项目启动时,PM和TPM对转测试标准达成一致PM根据项目计划中的版本转测试计划组织转测试工作开发人员从配置库上提取配置项完成版本归档,进行联调验证,写作版本描述文档项目CMO检查确保转测试交付件完整项目CMO收回配置库的修改权限,基线当前版本的阶段产品和源代码,在文档库和代码库中打上标签版

12、本归档完成后,PM将版本交付TPM项目CMO完成配置状态报告向全体项目成员发布,28,版本控制-版本转验收,PM根据项目计划中的版本转验收计划组织转验收工作开发人员从配置库上提取配置项完成版本归档,进行联调验证,写作版本描述文档项目CMO对照合作项目交付件清单检查确保版本转验收交付件完整项目CMO收回配置库的修改权限,基线当前版本的阶段产品和源代码,在文档库和代码库中打上标签版本归档完成后,PM将版本交付客户,同时提交验收申请至公司验收接口人项目CMO完成配置状态报告向全体项目成员发布版本验收通过后,由PM通过华为软件GDP系统向华为提供软件交付版本,变更控制,已经进行基线化的配置项需要进行修

13、改,启动准则,变更控制是针对基线化以后的工作产品而言的。,基线状态的配置项变更申请单或问题单,输 入,需求变更(对应变更申请单)缺陷引起的变更(对应问题单),变更类型,后面根据这两种变更类型对变更控制流程进行分类阐述。,各种变更控制流程的具体用途,用于AR基线以后,规格相关文档发生变更。变更启动前提:客户承认本次CR变更,并更新规格相关文档。,用于SRS基线以后,需求文档发生变更。,需求变更,SRS变更,缺陷导致的变更,长流程变更,短流程变更,编码完成以后,开发人员通过UT、ST等过程发现的前期阶段的工作产品中(如code/SRS/DS等)存在的问题。,产品转SDV测试后,测试团队通过SDV过

14、程发现的前期阶段的工作产品中(如code/SRS/DS等)存在 的问题,规格DS变更,需求变更管理,缺陷管理,31,客户提CR单,PM根据CR单录入变更申请。注意变更申请发出时需抄送测试与资料人员。,CCB(主要是PM)组织对CR单进行评估,并确定变更执行人。评估内容包括:涉及模块、变更规模、变更工作量、进度影响。,CMO接到PM的通知后,对变更执行人进行变更授权。,变更执行人实施变更,并记录变更说明。变更执行完成需要抄送测试与资料人员。,CCB(主要是PM)组织对变更实施情况进行验证审核。检查修改的配置项是否有相应的提交注释,注释是否完整。,项目级CMO接到CCB(主要是PM)的通知后,进行

15、版本归档。,PM对本次变更的实施情况及相关信息进行最后确认,变更控制-规格DS变更,使用需求变更汇总表跟踪需求变更的实施情况,该表单由PM从客户提CR单开始填写,并跟踪至CR单处理结束,变更申请人发现需求文档错误,提交变更申请。注意变更申请发出时需抄送测试与资料人员。,CCB(主要是ML)组织对变更进行评审,该变更申请中变更原因充分且必要,则批准变更并指定变更执行人。,变更申请人对本次变更的实施情况进行最后确认。,变更控制-SRS变更,在此只说明和“规格DS变更”不同的步骤,提单人在UT、ST测试中发现代码、需求、系统规格问题,提交问题单。,问题责任人(一般是该工作产品的编写者)修改验证问题,

16、并记录修改说明,模块负责人对修改的问题进行修改审核。,提单人确认问题已完全修改后关闭问题单。,变更控制-短流程变更,测试人员在SDV测试时发现问题,和问题责任人沟通确认后提交问题单,走问题完整流程。,TPM对问题单进行审核,检查问题单是否有效、是否重复,是否描述清晰。,PM对问题单进行审核,初步审核是否软件本身的缺陷。,问题责任人对问题进行定位,包括缺陷位置,缺陷来源和缺陷类型,最后给出修改方案。,模块负责人对于问题责任人给出的修改方案进行审核。,项目级CMO给问题责任人开通变更权限。,模块负责人对修改的问题进行修改审核,对照问题修改单和源代码文件进行评审;检查审核通过的源代码文件是否有相应的

17、提交注释,注释是否完整。,问题责任人修改验证问题,并记录修改说明。,针对归档后的版本,TPM组织测试人员对问题单进行回归测试。,测试人员对问题单进行回归测试,保证问题已完全修改。,提单人确认问题已经合理处理以后关闭问题单。,变更控制-长流程变更,项目级CMO接到模块负责人的通知后,进行版本归档。,在规格DS变更、SRS变更、UT/ST测试问题单、SDV测试问题单流程中,配置项的任何修改操作必须填写注释,注释格式规范如下:文档类提交内容的注释规范:【修改时间】:描述实际修改的时间(格式:2010-09-15)【修改人员】:描述实际修改该问题的人员信息(格式:中文姓名)【修改原因】:描述修改的原因

18、大类,包含以下几种:修改早期问题(未基线化前的问题修改);修改评审检视问题;修改问题单(包括DTS库和网上问题单);规格变更同步修改。【修改说明】:详细说明修改的内容。代码类提交内容的注释规范:【系统/模块】:(举例:客户服务,缴费账务,集团,营销管理.)【来源】:新需求【需求编号/BUG编号】:DTSxxxxxxxx【需求/BUG描述】:XXXX说明:该栏目要求开发人员在提交代码时填写,其监控责任人是变更审核人。所有代码类提交内容的注释都需说明缺陷管理系统中问题单号,不允许写问题单号“无”。,变更控制-变更注释规范,在项目计划批准之后成立CCB,并指定项目内开发人员兼职项目CMOCCB成员由

19、PM、SE、QA、TPM、TDC、项目CMO等组成,CCB负责人由项目PM兼任CCB评审和批准对项目中任何基线工作产品所做的变更CCB的最终决策必须通知所有受影响的干系人,变更控制-CCB组织及运作机制,配置审计,配置审计是指对项目的配置项完整性、正确性、一致性和可跟踪性的基线审计,包括例行审计、每个版本转验收前的质量审计及阶段点审计。,主要活动,项目CMO:项目每个阶段结束时,依据项目配置管理要求,对项目该阶段配置管理工作开展情况进行审计,并将审计结果填写入配置管理计划中QA:基线审计:在每一次项目阶段基线化后,QA对照项目级CMO完成的配置状态报告完成配置库的配置审计,侧重检查配置库完整性

20、一致性。如果发现问题,项目级CMO需要对照问题重新完成项目阶段基线并生成配置状态报告提交QA重新审计变更审计:基线化或者转验收的版本发生变更,在对其进行变更控制的过程中,QA对变更配置项的配置审计,侧重检查变更注释完整性和流程规范性,审计不通过则要求重新执行变更或完善变更过程,配置状态报告,配置项的状态变更申请对已被批准的变更的实现情况,配置状态报告记录并报告生存期中软件的状态,用以跟踪对已建立基线的配置项文档的更改;以文件的形式表明每一软件版本的内容,以及形成该版本的所有更改。,启动准则,基线完成之后,主要内容,向项目成员提供基线内容和状态、基线变更信息,便于项目成员及时地了解或查阅配置项的

21、当前状态和历史版本。在项目生命周期中通过对配置项的变更数据统计分析,有利于评估项目风险,有效控制项目的执行。,目的与作用,配置管理状态报告发布说明项目级CMO依配置管理计划中的基线计划完成项目的阶段基线,根据基线化操作情况,完成配置状态报告向全体项目成员发布对基线中的配置项的变更请求被批准后,项目级CMO根据变更跟踪表单内容生成配置状态报告向全体项目成员发布在项目进行过程中,如果有必要,则项目级CMO可以生成配置状态报告并向全体项目成员发布配置状态报告发布形式不限,可以是邮件或其他形式,只要保证向全体项目成员发布信息即可,组织级配置库目录结构-V模型,组织级配置库目录结构-敏捷,附录一:软件公

22、司版本命名规范简介,版本命名平台/基线版本:解决方案/产品名称 V/R/C版本号+SP补丁号。定制版本:产品名称 R/C/L版本号SP补丁号;其中R、C体现定制版本基于的那个基线版本号。版本取VRCB划分标识,VRCB的定义如下V 版本是指产品基于的软件或者硬件平台版本。R 版本是面向客户发布的特性的集合,是产品在特定时间的具体体现形式。C 版本是基于R版本开发的快速满足客户需求的客户化版本。L 版本是定制版本B(Build)是版本开发过程中转测试的内部标识,禁止面向客户。SP是指补丁版本和补丁最大区别在于版本提供新特性,面向客户需求;补丁不提供新特性,面向版本的缺陷。紧急热补丁的PID:用HPyyyy标识,紧急冷补丁的PID:用CPyyyy标识。yyyy表示补丁号,从0001到9999编号。举例:CC&BM R002C12L00080、TopEng ISE ISP V300R001C01B409、MTV Portal V100R001C30LG0001、IMPV100R001C01B032CP0006,42,43,附录二:相关 缩略语,附录三:参考资料,软件质量保证配置管理基础知识mini培训.ppt(华为)OSSP配置管理(庄奇丹).ppt 软件配置管理(李海燕).ppt华为公司合作方配置管理要求 V1.0,44,45,Q&A,谢 谢!,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号