资料软件配置管理过程Word下载.docx

资料软件配置管理过程Word下载.docx

《资料软件配置管理过程Word下载.docx》由会员分享，可在线阅读，更多相关《资料软件配置管理过程Word下载.docx（12页珍藏版）》请在冰点文库上搜索。

计划、文档、程序、记录等。

这些制品包括需要提交给客户或者最终用户的制品，也包括那些无需提交的制品。

支持性记录

除配置项外，有一类工作产品，如各类报告、变更单、问题单、会议记录等，作为重要的工作产品需要管理，但又不需要变更，这些工作产品称为支持性记录。

配置库

为项目建立或可以利用的一个仓库，用于存储软件配置项和相关联的配置管理信息。

构建（Build）

包括把源文件转换成目标文件相关的所有处理过程。

在软件程序开发中，构建活动可分成几个关键行为：

依赖性检查、源码编译、可执行连接，有时还会包括某种形式的数据文件的生成。

SCCB（SoftwareConfigurationControlBoard）

软件配置控制委员会，是项目的决策性组织，负责评价、认可或否定有关变更建议并确保已授权的变更得以执行。

SCM组

负责协调和实施项目SCM的小组，由SCM经理和SCME两类角色组成。

SCM经理

SCM组的负责人，此角色可由专职担任也可兼职。

SCME（SCM工程师）

项目SCM活动负责人。

此角色可专职担任也可兼职。

SCMP

软件配置管理计划

2方针

软件配置管理活动必须遵循以下方针：

1.每个项目都应指定SCME来负责软件配置管理工作；

2.软件配置管理活动贯穿软件项目生命周期的所有阶段；

3.软件配置管理活动的对象需包括：

对外发布的软件产品、指定的内部软件工作产品以及指定的软件项目支持工具等；

4.为软件项目建立配置库，用来存储配置项/单元和相关联的配置管理记录；

5.定期审计软件基线和软件配置管理活动。

3过程综述

软件配置管理是CMML2的一个关键过程域，其目的是协调软件开发过程，使混淆减至最小，从而保证软件工作产品在软件项目生命周期中的完整性和一致性。

软件配置管理是应用于整个软件过程中的庇护性活动，其主要责任是控制变更。

SCM通过标识配置项并系统的控制配置项的更改来帮助开发团队“维持秩序”，尽可能的降低开发过程中的混乱程度；

通过审计活动来保证软件工作产品被正确的实现；

通过状态报告来改善相关人员之间的及时通信，解决“左手不知道右手在干什么”的问题。

本过程将通过SCM策划、配置标识、配置控制、配置审计、配置报告等几个部分来描述软件配置管理过程。

4过程目标

软件配置管理过程需要达到以下目标：

1.软件配置管理活动是有计划的

2.所选择的工作产品是经过标识、受到控制并具有可用性的

3.所标识的软件工作产品的更改是受控的

4.软件项目相关人员能够及时了解软件基线的内容和状态信息

5角色与职责

相关角色

职责

高层经理

Ø

为SCM活动提供必要的资源和资金

在里程碑处对SCM活动进行评审

SCME

负责制定项目SCM计划

执行项目的SCM活动

SCM经理

负责开发和维护组织级SCM相关规程及模板

负责提供SCM培训和过程指导

负责审计SCM过程，并协助执行改进方案

管理软件产品库

SCCB

负责授权建立基线

负责评审和授权基线变更

负责评审和授权计划约定的其他重要变更

负责授权发布产品

项目经理

协助SCME制定SCM计划并支持计划的执行

负责受控配置项变更的审批

负责基线发布及基线变更的申请

负责产品发布申请

根据需要定期或随时评审SCM活动

SQAE（SQA工程师）

协助SCME制定SCM计划

通过日常检查对SCM活动进行评审

项目组成员

遵循配置管理规范进行工作

6输入准则

软件项目策划开始

WBS完成

SCM人员到位

7输入

软件项目计划（初稿）

WBS

8活动

8.1SCM策划

1.SCME在项目策划的早期进行SCM策划活动；

2.策划的主要负责人是SCME；

PM和SQAE提供必要的协助

3.策划的主要内容有：

1）项目的SCM活动及工时估计，结果生成SCM进度计划

2）选择的配置项，结果生成配置项列表

3）计划项目要建立的基线，结果生成基线列表

4）规划配置库的结构及权限分配

5）定义项目的程序构建策略及流程，形成构建计划（可裁剪）

6）描述项目的产品发布计划

7）描述项目的备份及安全防护计划

8）如有其他管理约定，一并沟通确定并描述。

4.策划的结果生成文档化的SCM计划，请参照《软件配置管理计划模板》

5.SCM计划作为项目整体计划的一部分，需与项目计划一起，经相关人员评审通过方可生效。

6.评审通过的SCM计划应纳入配置库进行管理。

8.2配置标识

8.2.1标识配置项

1.选择要纳入配置管理的软件工作产品作为配置项，需包括需求文档、设计文档、源代码、目标代码、测试文档、管理文档（如计划、规范等）、及重要的支持工具。

2.指定每个配置项的责任人及纳入管理的时间点。

3.为选择的软件工作产品制定命名规范和版本标识规范。

8.2.2标识基线

1.计划项目要建立的基线类型，需包括：

需求基线、设计基线、产品基线。

2.指定每类基线包含的配置项及基线建立时机。

3.为基线制定命名规范和版本标识规范。

8.2.3标识支持性记录

1.选择要纳入管理的支持性记录,至少需包括会议记录、各类周报、评审报告、SQA活动记录、SCM相关报告和记录、变更单、问题单、变更列表、问题列表。

2.为选择的支持性记录制定命名规范

8.3配置控制

8.3.1配置库控制

配置库是配置管理对象的存储区域，通过配置库的划分和相应的操作规则实现对配置项的有效管理控制。

1.配置库划分

在软件开发过程中，软件工作产品一般可分为4种状态：

开发状态（正在工作中）、受控状态（已经完成，纳入管理）、基线状态（已经评审通过并作为下一步工作的基准）和产品状态（作为软件产品已经发布）。

为了管理处于不同状态的软件工作产品，将配置库逻辑上划分为开发库、受控库、基线库和产品库。

1）开发库：

相对自由的环境，用于存放正在进行（未经审批通过）的工作产品。

主要目的是方便开发人员日常版本控制，可看作开发人员的个人工作空间；

2）受控库：

存放经过评审的工作产品。

包括2类：

配置项和支持性记录（如各类报告、变更单、问题单、会议记录类文档）。

3）基线库：

存放已发布的基线。

4）产品库：

存放已发布的产品。

此库内容不允许变更。

2.出入库规则

为了有效控制变更，减少混乱，同时又不防碍正常变更的执行，需要对不同状态的工作产品采取不同的控制力度。

开发库的入库出库操作不受控制。

由项目组成员根据日常工作需要对自己有相应权限的工作产品执行入库出库操作。

支持性记录可直接入库。

配置项则需遵循出/入库流程。

入库流程：

a）入库申请：

责任人向SCME提交入库申请（书面或Email，简要说明提交内容及所在位置）。

b）入库检查：

SCME执行入库检查，检查项参照入库检查表。

若检查通过，进入步骤c；

若检查不通过，则将检查结果返回申请人进行处理。

c）入库：

SCME执行入库操作，并在《配置库操作清单》中进行登记，同时更新配置项状态报告。

d）通知：

SCME通知项目相关人员某某配置项已入库，并分发最新的配置项状态报告（邮件附送或告知存放位置）。

出库流程：

a）出库申请：

责任人向SCME提交出库申请（书面或Email，简要说明需出库的配置项及出库原因――－若因变更出库，附上变更单；

若非变更型出库，则需说明更改内容。

）。

b）出库检查：

SCME执行出库检查，检查项参照出库检查表。

若检查不同过，则将检查结果返回申请人进行处理。

c）出库：

SCME执行出库操作，并在《配置库操作清单》中进行登记，同时更新配置项状态报告。

d）移交：

SCME将出库的配置项交给申请人（邮件发送或指明存放位置）。

对基线库的操作主要有基线发布和基线变更2种情况。

基线发布需经发布申请、发布检查、发布审批、执行发布几个步骤；

具体流程参加《基线及产品发布规程》

基线变更需经SCCB评审和授权，具体流程参照《变更控制规程》。

SCME在基线变更后执行基线审计。

4）产品库

由组织级集中管理，执行产品发布的同时需将发布内容提交至产品库保存。

产品发布相关活动请参照《基线及产品发布规程》。

5）配置项迁移

随着配置项状态的演进，需要在各库之间迁移（如：

开发库到受控库，受控库到基线库，基线库到产品库）。

迁移的具体操作方式与使用的配置管理工具有关，需在各项目SCM计划中描述。

8.3.2变更控制

对受控配置项和基线的变更进行控制，具体参照《变更控制规程》。

8.3.3基线及产品发布

基线发布、产品发布流程都需经过发布申请、发布检查、发布审批、执行发布几个步骤，具体参照《基线及产品发布规程》。

8.4配置审计

8.4.1基线审计

基线审计主要是对基线的完备性、基线内容相关信息的正确性和基线间的一致性进行审计。

审计的时机有2个：

阶段里程碑处和基线变更之后。

具体流程参照《基线审计规程》。

8.4.2配置库审计

SCME对配置库进行不定期审计，保证配置库内容的完整性和一致性。

SQAE对配置库进行不定期审计，以验证配置库内容是否符合计划及规范约定。

审计的具体检查项参照《工作产品审计检查表（配置库）》。

8.5配置报告

配置报告由SCME负责填写并报告，主要有以下几种：

1.配置项状态报告：

在配置项出库或入库时填写，并将报告发送给受影响的项目相关人员。

2.基线状态报告：

在基线发布及变更时填写，并将报告发送给受影响的项目相关人员。

3.SCM周报：

每周填写，并将报告发送给PM、SCM经理、SQAE。

4.SCM阶段总结：

阶段里程碑处填写，并将报告发送PM（PM在里程碑评审之前发送项目相关人员）。

9输出

●软件配置管理计划

●配置库操作清单

●配置项状态报告

●基线状态报告

●基线/产品发布申请

●产品发布公告

●软件变更申请单

●变更列表

●SCM周报

●SCM阶段总结

10输出准则

项目结项或终止。

11测量与分析

1.SCME执行软件配置管理活动的工作量以及和计划工作量的偏差；

2.变更的类型统计分析、原因统计分析、状态统计分析、变更源统计分析及变更花费的工作量统计分析；

3.与SCMP比较，配置项入库比例。

12验证

1.高层经理通过SCM阶段总结对SCM活动进行评审。

2.项目经理通过SCM周报、SCM阶段总结对SCM活动进行评审。

3.SQA工程师通过SCM周报、SCM阶段总结以及日常抽查活动（如配置库审计）对SCM的活动进行评审。

4.SCM经理组织SCM组评审SCM活动及过程，频度为每半年一次（如需要可酌情增加评审次数）。

13剪裁指南

1、配置库控制部分：

1）本规范所描述的配置库划分是通用的一般方式，如项目组有特殊情况采用其他划分方式，则需写入配置管理计划，经SCCB批准方可生效。

2）逻辑上划分的配置库在物理上如何设置，与配置管理工具及项目习惯的操作方式有关，需在各项目的配置管理计划中描述。

2、关于出入库登记：

如果工具可以自动记录，则无需在《配置库操作清单》中重复登记。

3、关于标识基线、标识支持性记录：

本文档只给出了基线类别、支持性记录类别的最小集，项目组根据实际情况可在此基础上增设其他基线或增选其他支持性记录，并写入配置管理计划。

4、附录程序构建部分：

可裁剪，由项目组根据具体情况约定，并写入配置管理计划。

5、产品的集中管理：

原则上要求执行产品发布的同时将发布内容提交至产品库保存。

确因特殊情况不能提交至产品库时（如技术保密原因需存放它处），必须经SCCB审批同意，并在产品库中做备案说明。

6、配置审计：

在约定执行的2次审计区间内（即前一次审计活动后至后一次审计活动发生前的时段），若审计对象未发生变化，则经PM、SQAE同意，后一次审计活动可省去。

7、其他部分均不可裁剪。

14参考文献

【1】Paulk,MarkC.,etal.CapabilityMaturityModelforSoftware,Version1.1CMU/SEI-93-TR-24

【2】Paulk,MarkC.,etal.KeyPracticesoftheCapabilityMaturityModel,Version1.1,CMU/SEI-93-TR-25

附录一程序构建

程序构建，即通常所说的Build工作，有些项目会将此项活动纳入SCM的范畴。

下面对程序构建进行简单介绍，如果项目组将构建工作纳入SCM活动范围，则需在SCM计划的对应章节描述本项目的构建策略和流程。

1、构建对象：

经过单元测试并检查通过的程序代码。

2、构建时机：

程序构建一般应在单元测试完成，集成测试或系统测试前进行。

3、构建策略：

各项目根据具体情况灵活确定自己的构建策略及方式，但需记入配置管理计划中。

构建频度可根据项目进展情况，灵活采取周构建、日构建等。

4、构建结果：

如构建成功，SCME需将构建完毕的工作产品（包括构建脚本）放入配置库以供测试。

如构建不成功，则SCME将构建信息通知相关责任人，修改完毕后再次提交构建。