CMMI 3标准文档模板-配置管理.docx

《CMMI 3标准文档模板-配置管理.docx》由会员分享，可在线阅读，更多相关《CMMI 3标准文档模板-配置管理.docx（12页珍藏版）》请在三一办公上搜索。

1、CMMI3标准文档模板.配置管理第17章配置管理217.1 介绍217.2 制定配置管理计划417.2.1 目的417.2.2 角色与职责417.2.3 启动准则417.2.4 输入417.2.5 主要步骤417.2.6 确定配置管理的软硬件资源417.2.7 制定配置项计划517.2.8 制定基线计划517.2.9 制定配置库备份计划517.2.10 审批配置管理计划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 主要步骤6SteplJ创建配置库6St

2、ep2分酉己权限7Step3配置库操作与管理717.3.6 输出717.3.7 结束准则717.3.8 度量717.3 版本控制717.3.1 目的717.3.2 角色与职责817.3.3 配置项状态变迁规则817.3.4 配置项版本号规则817.3.5 配置项版本控制流程9Stepl创建配置项9ISleP2修改处于“草稿”状态的配置项9Step3技术评审或领导审批9Step4正式发布9Step5变更917.4 配置项变更控制917.4.1 目的917.4.2 角色与职责1017.4.3 启动准则1017.4.4 输入1017.4.5 主要步骤10Stepl变更申请10Sl叩2审批变更申请10

3、Step3安排变更任务10Sl叩4执行变更任务10Step5对更改后的配置项重新进行技术评审（或审批）10Step6结束变更1117.4.6 输出1117.4.7 结束准则1117.4.8 度量1117.5 实施建议H第17章配置管理配置管理(ConfigurationManagemenuCM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。配置管理过程域是SPP模型的重要组成部分。本规范阐述了配置管理过程域的四个主要规程：令制定配置管理计划ISPP-PRoC-CM-PLANNING令配置库管理SPP-PR

4、OC-CM-LIB令配置项版本控制SPP-PROC-CM-VERSION令配置项变更控制SPP-PROC-CM-CHANGE上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出“、“完成准则”和“度量”均已定义。本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范，然后推广使用。17.1 介绍项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。凡是

5、纳入配置管理范畴的工作成果统称为配置项(ConfigUratiOnItem,Cl),配置项主要有两大类：(1)属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。(2)项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。基线(Baseline)由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改(见变更控制规程)。基线通常对应于开发过

6、程中的里程碑(MiIeStOne),一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、口期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个Build”。所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配置管理软件,常见的配置管理软件有Microsoft的VisualSourceSafe和Rational的ClearCaSe等。为了提高配置管理的效率和安全性，机构应当有专门的配置管理员(角色）。配置管理员为每个项目制定配置管理计划，创建和维护配置库。鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员

7、会（ConfigUraIiOnControlBoard,CCB）,CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。如果机构的各个项目紧密相关（例如一个产品线下的多个项目），建议机构设立公共的CCB,这个公共的CCB对所有项目的配置管理拥有决策权。如果机构的各个项目相对独立，那么每个项目可以设立各自的CCB。CCB的决策采用“少数服从多数”原则。配置管理的流程如图17-1所示。一、制定配置管理计划配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审

8、批该计划。二、配置库管理配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。三、版本控制在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。四、变更控制在项目开发过

9、程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请一审批一执行变更一再评审一结束”的规则执行。五、配置审计为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。请参考质量保证规范SPP-PRoC-QA,此处不再论述。配置管理过程域产生的主要文档有：配置管

10、理计划，模板见SPP-TEMP-CM-PLANo令配置库管理报告，模板见SPP-TEMP-CM-LIBo令配置项变更控制报告，模板见SPP-TEMP-CM-CHANGEo17.2 制定配置管理计划17.2.1 目的制定配置管理计划，以便有计划地开展配置管理工作。17.2.2 角色与职责 配置管理员制定配置管理计划。 CCB审批配置管理计划。CCB的人数视项目的规模而定。通常CCB由项目经理、资深项目成员等人组成，项目经理为CCB负责人。CCB的决策采用“少数服从多数”原则。17.2.3 启动准则 项目计划已经制定 配置管理员和CCB已经确定。17.2.4 输入项目计划17.2.5主要步骤Ste

11、pl确定配置管理的软硬件资源配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、外存、CPU等）。常用的配置管理软件有MiCrOSOft公司的ViSUaISOUrCeSafe和Rational公司的ClearCase等。Step2制定配置项计划 配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符的参考格式为Project-Type.Type-Numbero可以在PrOjeCt（或ProdUCI）前面加上公司的标识符。令Type.TyPe表示配置项类型，可以采用多级缩写。令NUmbel为3为数字，范围从OOl到999,表示一个配置项有若干个文件。若配置项只

12、有一个文件，则该项可以省略。 配置项计划的参考格式如下：类型主要配置项标识符预计正式发布时间Step3制定基线计划 配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间。基线计划的参考格式如下：基线名称/标识符基线所包含的主要配置项预计建立时间Step4制定配置库备份计划 配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处Step5审批配置管理计划 CCB审批配置管理计划。若该计划被批准，则请CCB负责人签字认可。否则，配置管理员按照CCB的意见修改配置管理计划，直到该计划被批准为止。17.2.6 输出配置管理计划17.2.7 结束准则配置

13、管理计划已经制定并被CCB的批准。17.2.8 度量配置管理统计工作量以及文档的规模，汇报给项目经理。17.3配置库管理17.3.1 目的所有人员依照配置管理规范和配置管理计划操作配置库。17.3.2 角色与职责 配置管理创建并维护配置库。 项目成员在权限之内操作配置库。17.3.3 启动准则配置管理计划已经制定。配置管理的软件硬件已经存在。17.3.4 输入配置管理计划17.3.5主要步骤Stepl创建配置库配置管理员创建配置库，并且至少创建配置库的所有第一级目录。Step2分配权限 配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add,CheCkin/Checkout,Down

14、load等权限，但是不能拥有删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。Step3配置库操作与管理 项目成员根据自己的权限操作配置库，例如Add,Checkin/CheCkoUt,Download等。 配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。 配置管理员定期清除配置库里的垃圾文件。 配置管理员定期备份配置库。 交付管理。这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：（1） “索取人”向CCB提出交付申请。（2） CCB审批该申请。如果该申请不合法（合理），则拒绝交付配置

15、项。如果同意交付，CCB应给出详细的交付清单。（3）配置管理员依据CCB的批示，从配置库中提取配置项交付给“索取人”。（4） “索取人”验收后签字。17.3.6 输出配置库管理报告（由配置管理员撰写）17.3.7 结束准则对配置库的操作与管理将持续到项目结束。17.3.8 度量配置管理员统计工作量以及文档规模。17.3版本控制17.3.1 目的按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。17.3.2 角色与职责所有项目成员都必须遵照版本控制规程操作配置库。17.3.3 配置项状态变迁规则配置项的状态有三种：“草稿”（Draft）、

16、“正式发布（ReleaSed）和“正在修改”（Changing）*,配置项状态变迁如图17-2所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。图17-2配置项状态变迁图17.3.4 配置项版本号规则配置项的版本号与配置项的状态紧密相关：（1）处于“草稿”状态的配置项的版本号格式为：O.YZ令YZ数字范围为0199。 随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。（2）处于

17、“正式发布”状态的配置项的版本号格式为：X.Y令X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。令配置项第一次“正式发布”时，版本号为1.0。 如果配置项的版本升级幅度比较小，一般只增大丫值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。（3）处于“正在修改”状态的配置项的版本号格式为：X.YZ令配置项正在修改时，一般只增大Z值，X.Y值保持不变。令当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0,增加X.Y值。参见规则（2）。17.3.4配置项版本控制流程rstepl创建配置项 项目成员依据配置管理计划，在配置库中创建属于其任务范围内的配置项。此

18、时配置项的状态为“草稿”，其版本号格式为O.YZ。Step2修改处于“草稿”状态的配置项 项目成员使用配置管理软件的CheCkOUt/Checkin功能，可以自由修改处于“草稿”状态的配置项（不受变更控制规程约束），版本号格式为0.YZ。Step3技术评审或领导审批 如果配置项是技术文档，则需要接受技术评审（参见技术评审规程SPP-PROC-TR）。如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。 若配置项通过了技术评审或领导审批，则转向Step4,否则转向Step2.Step41正式发布 配置项通过技术评审或领导审批之后，则配置项的状态从“草稿”变迁为“正式发布”，版本号格

19、式为X.Y。fStep5变更 修改处于“正式发布”状态的配置项，必须按照“变更控制规程”执行，主要步骤如下（详见变更控制规程）：Q如果CCB同意变更，则配置项状态从“正式发布”变迁为“正在修改”。令项目成员使用CheckoutZCheckin功能，可以修改处于“正在修改”状态的配置项，版本号格式为X.YZ。令修改完毕后，该配置项要重新接受技术评审或领导审批，转向Step3.17.4配置项变更控制17.4.1 目的 防止配置项被随意修改而导致混乱. CCB对审批变更申请。17.4.3 启动准则待变更的配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）。17.4.4 输

20、入待变更的配置项17.4.5 主要步骤Stepl变更申请 变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因Stcp2审批变更申请 CCB审批该申请，分析此变更对项目造成的影响。如果同意变更，则转向fStep31,否则终止本规程。补充说明:一个配置项的变更可能导致其它配置项也发生变更,CCB在审批变更申请时一定要考虑这些问题。fStep31安排变更任务 CCB指定变更执行人，安排他们的任务。CCB需要和变更执行人就变更内容达成共识。补充说明:变更执行人可能是变更申请人,也可能不是。Step4执行变更任务 变更执行人根据CCB安排的任务，修改配置项。 CCB监督变更任务的执行，如检

21、查变更内容是否正确、是否按时完成工作等。Step5对更改后的配置项重新进行技术评审（或审批） 如果配置项是技术文档，则需要接受技术评审（参见技术评审规程SPP-PROC-TR）。如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。 若配置项通过了技术评审或领导审批，则转向Step6,否则转向Step4（即重新修改）。Step6结束变更 当所有变更后的配置项都通过了技术评审或领导审批，这些配置项的状态从“正在修改”变迁为“正式发布CCB在配置项变更控制报告中签字，结束变更。17.4.6 输出本规程的所有信息都记录在配置项变更控制报告中。17.4.7 结束准则CCB签字结束变更。17.4.8度量CCB统计变更工作量。17.5实施建议要求所有人员对其工作成果进行配置管理。 对全员进行配置管理培训。 由于配置库里保存的是项目的所有工作成果，应当选择“责任心强、可靠”的人员担任配置管理员。 选用合适的软件工具，尽量减少配置管理过程的工作量。