还剩10页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
标准文档模板•配置管理CMMI3第章配置管理
17217.1介绍
217.2制定配置管理计划
417.
2.1目的
417.
2.2角色与职责
417.
2.3启动准则
417.
2.4输入
417.
2.5主要步骤4[Stepl]确定配置管理的软硬件资源4[Sep2]制定配置项计划5[Step3]制定基线计划5[Step4]制定配置库备份计划5[Step5]审批《配置管理计划》
517.
2.6输出
517.
2.7结束准则
617.
2.8度量
617.3配置库管理
617.
3.1目的
617.
3.2角色与职责
617.
3.3启动准则
617.
3.4输入
617.
3.5主要步骤6fStepl]创建配置库6[Step2]分配权限7[Step3]配置库操作与管理
717.
3.6输出
717.
3.7结束准则
717.
3.8度量
717.3版本控制
717.
3.1目的
717.
3.2角色与职责
817.
3.3配置项状态变迁规则
817.
3.4配置项版本号规则8配置项版本控制流程[Stepl]创建配置项•项目成员依据《配置管理计划》,在配置库中创建属于其任务范围内的配置项此时配置项的状态为“草稿”,其版本号格式为O.YZISteplJ修改处于“草稿”状态的配置项•项目成员使用配置管理软件的Checkout/Checkin功能,可以自由修改处于“草稿”状态的配置项(不受变更控制规程约束),版本号格式为
0.YZ[Step3]技术评审或领导审批•如果配置项是技术文档,则需要接受技术评审(参见技术评审规程[SPP-PROC-TR])如果配置项是“计划”这类文件,则需要项目经理(或上级领导)的审批•若配置项通过了技术评审或领导审批,则转向[Step41,否则转向[Step2][Step4]正式发布•配置项通过技术评审或领导审批之后,则配置项的状态从“草稿”变迁为“正式发布”,版本号格式为X.Y[Step5]变更•修改处于“正式发布”状态的配置项,必须按照“变更控制规程”执行,主要步骤如下(详见变更控制规程)令如果CCB同意变更,则配置项状态从“正式发布”变迁为“正在修改”项目成员使用Checkout/Checkin功能,可以修改处于“正在修改”状态的配置项,版本号格式为X.YZ修改完毕后,该配置项要重新接受技术评审或领导审批,转向[Step3]配置项变更控制
17.
417.
4.1目的•防止配置项被随意修改而导致混乱
17.
4.2角色与职责•CCB对审批变更申请
17.
4.3启动准则•待变更的配置项状态为“正式发布”,或者该配置项已经成为某个基线的一部分(即被“冻结”)
17.
4.4输入•待变更的配置项
17.
4.5主要步骤[Stepl]变更申请•变更申请人向CCB提交变更申请,重点说明“变更内容”和“变更原因IStepZ]审批变更申请•CCB审批该申请,分析此变更对项目造成的影响如果同意变更,则转向[Step3],否则终止本规程补充说明:一个配置项的变更可能导致其它配置项也发生变更,CCB在审批变更申请时一定要考虑这些问题[Step3]安排变更任务•CCB指定变更执行人,安排他们的任务CCB需要和变更执行人就变更内容达成共识补充说明:变更执行人可能是变更申请人,也可能不是[Step4]执行变更任务•变更执行人根据CCB安排的任务,修改配置项•CCB监督变更任务的执行,如检查变更内容是否正确、是否按时完成工作等(Steps1对更改后的配置项重新进行技术评审(或审批)•如果配置项是技术文档,则需要接受技术评审(参见技术评审规程[SPP-PROC-TR])如果配置项是“计划”这类文件,则需要项目经理(或上级领导)的审批•若配置项通过了技术评审或领导审批,则转向[Step6],否则转向[Step4](即重新修改)[Step6]结束变更•当所有变更后的配置项都通过了技术评审或领导审批,这些配置项的状态从“正在修改”变迁为“正式发布:CCB在《配置项变更控制报告》中签字,结束变更
17.
4.6输出•本规程的所有信息都记录在《配置项变更控制报告》中
17.
4.7结束准则•CCB签字结束变更
17.
4.8度量•CCB统计变更工作量实施建议
17.5•要求所有人员对其工作成果进行配置管理•对全员进行配置管理培训•由于配置库里保存的是项目的所有工作成果,应当选择“责任心强、可靠”的人员担任配置管理员•选用合适的软件工具,尽量减少配置管理过程的工作量配置项版本控制流程9[Stepl]创建配置项9Stcp2]修改处于“草稿”状态的配置项9[Step31技术评审或领导审批9Stcp4]正式发布9[Step5]变更
917.4配置项变更控制
917.
4.1目的
917.
4.2角色与职责
1017.
4.3启动准则
1017.
4.4输入
1017.
4.5主要步骤10Stepl]变更申请10[Step21审批变更申请10Stcp3]安排变更任务10[Step4]执行变更任务10lStcp5J对更改后的配置项重新进行技术评审或审批10|Step6]结束变更
1117.
4.6输出II
17.
4.7结束准则
1117.
4.8度量
1117.5实施建议11第章配置管理17配置管理(Configuralion Management,CM)的目的是通过执行版本控制、变更控制等规程,以及使用配置管理软件,来保证所有配置项的完整性和可跟踪性配置管理是对工作成果的一种有效保护配置管理过程域是SPP模型的重要组成部分本规范阐述了配置管理过程域的四个主要规程制定配置管理计划[SPP-PROC-CM-PLANNING]配置库管理[SPP-PROC-CM-LIB]配置项版本控制ISPP-PROC-CM-VERSION]配置项变更控制[SPP-PROC-CM-CHANGE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义本规范适用于国内IT企业的软件研发项目建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用介绍
17.1项目研发和管理过程中会产生许许多多的工作成果,例如文档、程序和数据等,它们都应当被保存起来,以便查阅和修改如果把所有文件一股脑地塞进计算机里,那么使用起来肯定很麻烦毫无疑问,人们应当将文件分门别类、有条理地保存起来凡是纳入配置管理范畴的工作成果统称为配置项(ConfigurationItem,CI),配置项主要有两大类
(1)属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例等
(2)项目管理和机构支撑过程域产生的文档这些文档虽然不是产品的组成部分,但是值得保存每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等所有配置项都被保存在配置库里,确保不会混淆、丢失配置项及其历史记录反映了软件的演化过程基线(Baseline)由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体基线中的配置项被“冻结”了,不能再被任何人随意修改(见变更控制规程)基线通常对应于开发过程中的里程碑(Milestone),一个产品可以有多个基线,也可以只有一个基线基线的主要属性有名称、标识符、版本、日期等通常将交付给客户的基线称为一个“Release”,为内部开发用的基线则称为一个Build”所有的项目成员都要使用配置管理软件来保护自己的工作成果机构应当采用统一的配置管理软件,常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase等为了提高配置管理的效率和安全性,机构应当有专门的配置管理员(角色)配置管理员为每个项目制定《配置管理计划》,创建和维护配置库鉴于配置管理的重要性和复杂性,机构还应当设立配置控制委员会(ConfigurationControlBoard,CCB)o CCB是个虚拟小组,对配置管理各项活动拥有决策权(例如审批计划,审批变更请求等)对于配置管理而言,CCB是决策者,而配置管理员是执行者如果机构的各个项目紧密相关(例如一个产品线下的多个项目),建议机构设立公共的CCB,这个公共的CCB对所有项目的配置管理拥有决策权如果机构的各个项目相对独立,那么每个项目可以设立各自的CCBCCB的决策采用“少数服从多数”原则配置管理的流程如图17-1所示图17-1配置管理流程图
一、制定配置管理计划配置管理员制定《配置管理计划》,主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等CCB审批该计划
二、配置库管理配置管理员为项目创建配置库,并给每个项目成员分配权限各项H成员根据自己的权限操作配置库配置管理员定期维护配置库,例如清楚垃圾文件、备份配置库等
三、版本控制在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来对配置项的任何修改都将产生新的版本由于我们不能保证新版本一定比老版本“好”,所以不能抛弃老版本版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本配置项的状态有三种“草稿”、“正式发布”和“正在修改”,本规程制定了配置项状态变迁与版本号的规则
四、变更控制在项目开发过程中,配置项发生变更几乎是不可避免的变更控制的目的就是为了防止配置项被随意修改而导致混乱修改处于“草稿”状态的配置项不算是“变更”,无需CCB的批准,修改者按照版本控制规则执行即可当配置项的状态成为“正式发布”,或者被“冻结”后,此时任何人都不能随意修改,必须依据“申请一审批一执行变更一再评审一结束”的规则执行
五、配置审计为了保证所有人员(包括项目成员、配置管理员和CCB)都遵守配置管理规范,质量保证人员要定期审计配置管理工作配置审计是一种“过程质量检查”活动,是质量保证人员的工作职责之一请参考质量保证规范SPP-PROC-QA,此处不再论述配置管理过程域产生的主要文档有◊《配置管理计划》,模板见[SPP-TEMP・CM・PLAN]今《配置库管理报告》,模板见[SPP-TEMP-CM-LIB]o◊《配置项变更控制报告》,模板见[SPP-TEMP-CM-CHANGEJo制定配置管理计划
17.
217.
2.1目的•制定配置管理计划,以便有计划地开展配置管理工作
17.
2.2角色与职责•配置管理员制定《配置管理计划》•CCB审批《配置管理计划》CCB的人数视项目的规模而定通常CCB由项FI经理、资深项目成员等人组成,项目经理为CCB负责人CCB的决策采用“少数服从多数”原则
17.
2.3启动准则•《项目计划》已经制定•配置管理员和CCB已经确定
17.
2.4输入•《项目计划》
17.
2.5主要步骤IStepl]确定配置管理的软硬件资源•配置管理员根据项目的规模以及财力,确定配置管理软件以及计算机资源(考虑内存、外存、CPU等)常用的配置管理软件有Microsoft公司的VisualSourceSafe和Rational公司的ClearCase等[Step2]制定配置项计划•配置管理员识别项目的主要配置项每个配置项都有唯一的标识符,标识符的参考格式为Project-Type...Type-Numbero可以在Project(或Product)前面加上公司的标识符令Type…Type表示配置项类型,可以采用多级缩写令Number为3为数字,范围从001到999,表示一个配置项有若干个文件若配置项只有一个文件,则该项可以省略•配置项计划的参考格式如下类型主要配置项标识符预计正式发布时间[Step3]制定基线计划•配置管理员确定每个基线的名称(标识符)及其主要配置项,估计每个基线建立的时间基线计划的参考格式如下基线名称/标识符基线所包含的主要配置项预计建立时间[Step4]制定配置库备份计划•配置管理员制定配置库备份计划,指明“何人”在“何时”(频度)将配置库备份到“何处”[Step5]审批《配置管理计划》•CCB审批《配置管理计划》若该计划被批准,则请CCB负责人签字认可否则,配置管理员按照CCB的意见修改《配置管理计划》,直到该计划被批准为止
17.
2.6输出《配置管理计划》
17.
2.7结束准则・《配置管理计划》己经制定并被CCB的批准
17.
2.8度量•配置管理统计工作最以及文档的规模,汇报给项目经理配置库管理
17.
317.
3.1目的•所有人员依照配置管理规范和《配置管理计划》操作配置库
17.
3.2角色与职责•配置管理创建并维护配置库•项H成员在权限之内操作配置库
17.
3.3启动准则・《配置管理计划》己经制定•配置管理的软件硬件已经存在
17.
3.4输入・《配置管理计划》
17.
3.5主要步骤[Stepl]创建配置库•配置管理员创建配置库,并且至少创建配置库的所有第一级目录lStep2J分配权限•配置管理员为每个项目成员分配操作权限一般地,项目成员拥有Add,Chcckin/Chcckout,Download等权限,但是不能拥有“删除”权限配置管理员的权限最高具体操作视所采用的配置管理软件而定[Step3]配置库操作与管理•项目成员根据自己的权限操作配置库,例如Add,Checkin/Checkout,Download等•配置管理员根据“基线计划”创建与维护基线,“冻结”配置项,控制变更•配置管理员定期清除配置库里的垃圾文件•配置管理员定期备份配置库•交付管理这里“交付”是指从配置库中提取配置项,交付给客户或项目外的人员交付出去的配置项必须有据可查,避免发生混乱流程如下
(1)“索取人”向CCB提出交付申请
(2)CCB审批该申请如果该申请不合法(合理),则拒绝交付配置项如果同意交付,CCB应给出详细的交付清单
(3)配置管理员依据CCB的批示,从配置库中提取配置项交付给“索取人工
(4)“索取人”验收后签字输出・《配置库管理报告》(由配置管理员撰写)
17.
3.7结束准则•对配置库的操作与管理将持续到项目结束
17.
3.8度量•配置管理员统计工作量以及文档规模版本控制
17.
317.
3.1目的•按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地杳找到配置项的任何版本
17.
3.2角色与职责•所有项目成员都必须遵照版本控制规程操作配置库
17.
3.3配置项状态变迁规则配置项的状态有三种“草稿”(Draft)、“正式发布(Released)和“正在修改”(Changing)a配置项状态变迁如图17-2所示配置项刚建立时其状态为“草稿”配置项通过评审(或审批)后,其状态变为“正式发布”此后若更改配置项,必须依照“变更控制规程”执行,其状态变为“正在修改二当配置项修改完毕并重新通过评审(或审批)时,其状态又变为“正式发布”,如此循环图17-2配置项状态变迁图
17.
3.4配置项版本号规则配置项的版本号与配置项的状态紧密相关
(1)处于“草稿”状态的配置项的版本号格式为O.YZ◊YZ数字范围为01-99◊随着草稿的不断完善,“YZ”的取值应递增“YZ”的初值和增幅由用户自己把握
(2)处于“正式发布”状态的配置项的版本号格式为X.Y◊X为主版本号,取值范围为1-9Y为次版本号,取值范围为1-9令配置项第一次“正式发布”时,版本号为LOo令如果配置项的版本升级幅度比较小,一般只增大Y值,X值保持不变只有当配置项版本升级幅度比较大时,才允许增大X值
(3)处于“正在修改”状态的配置项的版本号格式为X.YZ◊配置项正在修改时,一般只增大Z值,X.Y值保持不变◊当配置项修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值参见规则
(2)。