软件配置管理培训教材

软件配置管理培训课程内容软件配置管理过程配置库管理使用规范配置变更管理规范版本发布控制规范软件配置管理过程•什么是配置管理？•目的？•主要活动有哪些？•人员与职责？定义：•唯一标识•受控存储•变更控制•状态报告系统生命周期内所选定的中间工作产品、产品组件以及产品的唯一标识、受控存储、变更控制和状态报告。目的：•通过配置标识、配置控制、配置状态报告和配置审计等手段，建立和维护工作产品的完整性.误区：配置管理不是简单的备份！！！配置项为了配置管理的目的而作为一个单位来看待的软件要素的集合。•代码•文档•数据结构配置项类和实例用户需求规格说明配置项类用户需求规格说明版本1用户需求规格说明版本2用户需求规格说明版本3配置项实例配置项类的生命周期•P代表生产，I代表标识，S代表存储，C代表变更控制，U代表使用。标识（I）存储V1变更控制（C）生产（P）使用（U）ISV1V2PUCISV1V2V3CUP配置标识为配置项确定元数据－－惟一地标识配置项，并确定它和外界以及其他配置项的关系。元数据可能包括配置项名称、配置项创建者的姓名、创建日期等。配置控制控制对配置项的修改，对配置项的变更申请进行初始化、评估、协调、实现，包括将通过和实现的变更加入到基线区中的更改控制过程。评估协调实现验证基线软件开发过程中的里程碑，它以一或多个软件配置项的交付为标志。基线由已经通过正式评审和批准的某规约或产品组成，它因此作为进一步开发的基础，并且只能通过正式的变更控制过程才能够改变。配置项与基线的区别•配置项是需要进行配置管理的最小单位，如：一份文档、一片段代码等。•基线是配置项的一种，基线需要进行更加严格的管理。•一般配置项的管理等级是：权限控制、版本控制。而基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。•基线是由一组配置项组成的，这些配置项构成了一个相对稳定的逻辑实体配置审计指对于存储配置项及相关记录的软件基线库的结构、内容和设施进行检验。•功能配置审计•物理配置审计功能配置审计•验证配置项的实际功效是与软件需求一致的。验证手段：文档的评审、软件的测试物理配置审计•确定配置项符合预期的物理特性，即特殊的媒体形式。就是检查工作产品是否符合格式、版本号等方面的要求，一般有配置管理员负责配置状态报告状态报告把有效地管理产品开发与维护所需的信息以一种有用的可读方式呈现给相关人员。它提供了已批准的基线和过程的当前状态，也提供已提出并批准的请求变更的状态。配置控制委员会（CCB）CCB是确定配置基线，评估、批准变更，并保证已批准变更的实施的组织。项目经理、测试人员、业务专家、QA、CMO等配置管理员（CMO）负责执行、监督配置管理活动的人员。为什么需要软件配置管理？•现代软件开发复杂度高•众多的开发人员•文件及相关资源多种多样源代码目标代码文档模型和设计需求测试脚本•多个发布版本•多种平台•开发团队跨地域忽视软件配置管理可能导致的混乱现象：标识混乱版本混乱不能协同工作已经解决的缺陷过后又出现错误找不到最新修改了的源程序找不到编程序的人软件配置管理的作用•存储和保护所有软件资产和相关资源•记录软件所有的历史变更Whatchanged?Whochangedit?Whendiditchange?Whydiditchange?•帮助项目经理更好的了解项目的进度•有利于管理者应对开发人员流动较大的情况，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。如何做好配置管理？先做好两步，再做好两件事识别需要进行配置管理的东西建立一个配置管理系统来管理需要进行配置管理的东西。两步两件事对一般的配置项进行管理对基线级别的配置项进行基线级别的管理配置管理的主要活动•配置标识•配置库管理•版本管理•变更管理•配置状态报告•配置审计人员与职责配置变更控制委员会（CCB)分析、评审和批准基线的变更。批准正式基线的发布。批准产品发布。项目经理•申请项目配置库和批准权限。•负责审核批准开发基线的变更。•批准非正式基线的发布。项目成员•严格按照软件配置管理的各个规范执行配置管理活动。项目CMO•制订项目配置管理计划。•维护配置状态记录；制定和发布配置状态报告。•维护配置库的目录结构。•编写和发布配置审计报告。•编写和发布基线发布报告。公司CMO•建立配置库、权限管理和备份配置库。•培训•研究工具。•协助项目组开展配置管理活动。•检查和指导项目CMO工作。课程内容软件配置管理过程配置库管理使用规范配置变更管理规范版本发布控制规范配置库管理使用规范•技术文档（Document）管理方法•代码（SourceCode）管理方法•项目管理文档（ProjectManagement）管理方法•配置库基本目录结构•权限管理方法技术文档管理方法技术文档分类：按照文档类型存放。Business（方案类）Plan（计划类）Requirement（需求类）Design（设计类）Test（测试类）Manual（操作手册类）Summary（总结类）等。文档标识规范•标识组成：项目编号/文档类别（编码）•例子：综合结算项目需求规格说明书标识：DIC-TSS/SRS文档类别编码方法请祥见体系文件《配置项标识规范》文档管理流程2区管理模式各个子分支内存储不同产品并由不同的角色控制。•Develop•Build文档管理流程（1）文档管理流程开发区基线区输出输入项目CMO项目经理/CCB开发人员文档编写文档评审通过纳入基线区是否发布基线结束开发计划基线发布报告文档管理注意几点：•在文档的首页请正确填写文档标识、文档版本、文档状态、文档修订信息、页角页眉等。•纳入基线区的文档状态必须改成CF状态。•注意文档存放位置。代码管理方法•4区管理模式•流程•代码目录结构定义4区管理模式开发区构建区测试区发布区•Develop•Build•Test•Release代码管理流程代码管理流程开发区构建区测试区发布区实施或者维护负责人输出测试负责人构建负责人输入开发人员开发计划日常开发工作检查通过纳入构建区YN通过纳入测试区N通过纳入发布区N版本发布说明、测试报告产品审批申请表版本发布说明测试用例、测试报告生成版本YY提取版本提取版本结束发布版本单元测试集成测试系统测试代码目录结构定义建立时机：详细设计文档已基线化。要求：与详细设计文档中各模块定义结构一致。项目管理文档管理方法目录分类MA（度量）SCM（配置管理）SQA（质量管理）WeeklyReport（周报）Minute（会议既要）Review（评审）Training（培训）配置库基本目录结构权限管理方法权限管理流程输出输入CMO项目经理或者研发负责人申请人提出权限申请权限需求审批权限申请通过开通权限并通知申请人Y结束N更新权限列表权限列表权限管理说明几点•所有的权限申请必须通过邮件的方式，不接受任何口头的申请。•在邮件中请说明具体要开通哪些权限。课程内容软件配置管理过程配置库管理使用规范配置变更管理规范版本发布控制规范配置变更管理规范•变更对象？•变更流程变更对象•所有已基线化的配置项变更必须执行此规范。变更流程配置变更控制流程提出变更审批变更实施验证输出项目经理项目CMO项目成员CCB输入提出变更请求结束同意变更？分析和评估变更影响配置变更审批表记录并发布变更配置状态报告实施变更从基线区提取相关配置项验证变更审核变更请求是否变更与提出者沟通不同意通过不通过重大变更一般变更确定变更实施方案配置变更审批表同意不同意提交变更申请•作为变更控制的第一步，首先应该有变更请求人填写《配置变更审批表》，说明需要变更的内容和理由。配置变更申请变更编号：(由项目的配置管理员统一编号）产品(项目)名称：申请人:申请日期变更原因：需求变更□内部改进□产品缺陷□系统环境变更□其他□变更的配置项：受影响的基线或者配置项：变更描述：见《配置项变更描述说明》审核变更请求•项目经理对变更申请人提出的变更请求进行审核，审核更改方案的可行性，检查《配置变更审批表》的正确性和完整性。项目经理审核审核人意见：□返回申请人返回原因：□可直接实施实施人：验证人：□需制定变更方案并提交CCB评审方案制定人：方案审核人：变更类型：一般变更审核人签字：审核日期：变更方案：方案制定人签名：日期：分析和评估变更影响•变更申请表送交CCB进行分析和评估，CCB根据成本/效益和涉及到的技术的因素判断变更实施的必要性并评估变更方案，确定是否可以实施变更。CCB审核CCB评审意见：□立即变更□推迟变更原因：□不接受变更原因：实施人：解决期限：验证人：验证期限：CCB成员：CCB主席签字：批准日期：实施变更•变更申请通过审核或者审批后，项目CMO从基线区中取出需要变更的配置项，放到开发区中，通知实施人员对变更项进行实施。实施和验证变更实施内容：实施人签字：实施日期：验证变更•变更实施后，实施人员通知验证人对变更的配置项进行验证。验证意见:□同意□不同意意见：验证人签字：验证日期：记录并发布变更•变更通过验证后，通知项目CMO将变更后的配置项重新纳入基线区，记录并发布变更。变更发布配置项在基线库中的位置：（填写配置项在基线库中的路径）发布人：发布日期：课程内容软件配置管理过程配置库管理使用规范配置变更管理规范版本发布控制规范版本发布控制规范•版本类型分类•版本编号定义•版本发布流程版本类型分类•研发版本：指的是此版本是只用于研发项目使用的版本。生产版本：指的是此版本是用于实施或者维护项目使用的版本。生产版本补丁：对于生产版本打的补丁。版本编号定义•由4位数字组成：Va.b.c.d•主副版本编号：由Va.b两位数字组成。•补丁版本编号：由Va.b.c三位数字组成。•回归版本编号：由Va.b.c.d四位数字组成。注意：主版本的回归测试编号为：Va.b.0.dOA上版本发布流程•研发版本发布流程•生产或生产补丁版本发布流程研发版本发布流程•提交版本申请－系统测试。测试人员反馈结果•填写内容：系统测试结果描述、测试用例总数、通过个数、测试时间、测试负责人、是否同意发布生产版本或生产版本补丁流程•提交版本申请－系统测试。测试人员反馈结果•版本接收人点编辑按扭并填写系统测试结果；测试用例总数；通过个数；测试时间；测试负责人，是否同意发布（如果点通过（有无确认测试一行出现）；如果点是（确认测试接收人一行出现）。并在出现的对话框中选择确认测试接收人）现场人员反馈确认测试结果•确认测试接收人点编辑按扭填写确认测试结果；测试用例总数；通过个数；测试时间；测试负责人，是否同意发布（如果点通过（则会出现产品部署接收人一行）。产品部署人反馈结果•产品部署接收人点编辑按扭填写产品部署发布结果描述；选择是否通过生产，点通过。版本发布流程注意几点•项目经理必须先在OA上填写版本编号。•主副版本编号是必选项。•请正确选择版本编号。Q&A