配置管理流程

《配置管理流程》由会员分享，可在线阅读，更多相关《配置管理流程（11页珍藏版）》请在金锄头文库上搜索。

1、配置管理流程1 概要1.1 内容 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的 更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完 整性和可追溯性。1.2 适用范围 对于不同类别的软件项目，配置管理的流程不同，可在本流程的基础上进行裁减。1.3 术语和缩略语1.3.1 软件配置管理(Software Configuration Management, SCM)软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个 过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控 制、 规范的一系列措施。配置管理的目标是记录软件产品的

2、演化过程，确保软件开发 者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。1.3.2 配置(Configuration)配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此配置 包括了即将受控的所有产品特性，其内容及相关文档、软件版本、变更文档、软 件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配 置，软件产品的配置包括更多的内容并具有易变性。1.3.3 配置项(Configuration Item, CI)凡是纳入配置管理范畴的工作成果统称为配置项(Configuration Item, CI), 配置项逻辑上组成软件系统的各组成部分，一般是可以

3、单独进行设计、实施和测 试的。一个纯软件的CIs通常也称之为软件配置项(Computer Software Configuration Items, CSCIs)。配置项主要有两大类：1) 属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例 等；2) 项目管理和机构支撑过程产生的文档。这些文档虽然不是产品的组成部分,但 是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所 有配置项都被保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映 了软件的演化过程。1.3.4 基线(Baseline)在配置管理系统中，基线就是一个CI或一组CIs在其

4、生命周期的不同时间点上 通过正式评审而进入正式受控的一种状态,些配置项构成了一个相对稳 定的逻 辑实体,而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点 和参考点。基线确定了元素(配置项)的一个版本,且只确定一个版本。一般 情 况下，基线一般在指定的里程碑(Miles tone)处创建，并与项目中的里程碑保 持同步。每个基线都将接受配置管理的严格控制,基线中的配置项被“冻 结” 了，不能再被任何人随意修改，对其的修改将严格按照变更控制要求的过程进行， 在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一 个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将

5、交付给客户的基线称 为一个“ Release”，为内部开发用的基线则称为一个“Build”。建立基线的好处：1）重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的 早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队 提供一种取消变更的方法。2）可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代 码实施设计以及用正确代码编译可执行文件。3）版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的 定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上） 所进行的变更进行隔离。2 相关人权责2.1 项目经理（Pro

6、ject Manager, PM）责任：1）与 CCB 协商确定项目起始基线和开发里程碑；2）接受配置管理计划，并按相关规定贯彻执行；3）接受配置控制委员会的报告。权利：1）提出配置管理计划的修改要求；2）提出管理管理的建议和要求。2.2 配置控制委员会（ Configuration Control Board，CCB）责任：1）制定和修改项目的配置管理策略；权利：1）批准、发布配置管理计划；2）建立、更改基线的设置，审核变更申请；3）根据配置管理员的报告决定相应的对策。2.3 配置管理员（Configuration Management Officer，CMO） 责任：1）编制配置管理计划；

7、2）执行配置项管理方案；3）执行版本控制和变更控制方案；4）编制配置状态报告；权利：向 CCB 汇报有关配置管理流程中的不符合情况。2.4 程序库管理员（Program Librarian, PL）责任：1）配置库的建立和权限分配；2）配置管理工具的日常管理与维护；3）配置库的日常操作和维护；权利：1）各配置项的管理与维护；2）对开发人员进行相关的培训。2.5 开发人员（Developer）责任：1）根据确定的配置管理计划和相关规定，提交配置项和基线；2）负责软件集成和版本生成。权利：按照软件配置管理工具的使用模型来完成开发任务。2.6测试人员（Tes ter）责任：根据配置管理计划和相关规定

8、，提交测试配置项和测试基线；权利： 负责软件变更的测试验证。2.7 软件质量保证员（Software Quality Assurance, SQA）责任： 负责配置审核并提交报告。权利：对配置审核中发现的不符合项，要求相关责任人进行纠正。3 实施细则3.1 CCB 的成立3.1.1 项目在设计发注后，由项目经理负责组织成立 CCB。3.1.2 CCB 成员组成CCB成员人数一般为奇数，人数在37人范围内。CCB成员一般包括：1）项目经理 PM；2）配置管理员 CMO；3）SQA；4）测试人员 Tester；5）顾客代表；6）主要开发人员等。3.1.3 CCB 的决策机制寻求CCB成员的一致意见

9、。若不能达成一致，可采取由顾客代表做出决策；或采 取少数服从多数的原则，由CCB成员投票确定，投票超过半数即为通过。3.2 确定配置策略3.2.1 配置策略确定的时机CCB 成立后，由 CCB 组织会议根据项目的开发计划确定各个里程碑和开发策略，CMO 负责整理确定的项目基线和配置项列表，并在编制配置管理计划时列明， 按约定的时机收集配置项和建立初始基线。3.2.2 配置项的范围1）技术文档（Documents）:项目开发计划、需求分析报告、软件设计书、质量 保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报 告等；2）程序（Program）:阶段产品、计算机程序、源程序、

10、释放产品等；3）工具（Tools）:自动设计工具、开发工具、测试工具、维护工具等；4）交互文档（Communications）：与客户或项目组内交互产生文档，如会谈记录、E-mail、会议纪要、MSN记录等。3.3 制定配置管理计划3.3.1 配置管理计划的编制通常情况下，由 CMO 在设计发注后，开始编制配置管理计划；如有特殊需要， 根据合同或项目要求，由 CMO 在某一项目或项目的某一阶段开始前制定配置管 理计划。3.3.2 配置管理计划的内容 配置管理计划应包括以下方面的内容：1）该项目对配置管理的要求；2）实施配置管理的责任人、组织及其职责；3）需要开展的配置管理活动及其进度安排；4）

11、采用的方法和工具等。333配置管理计划的由CCB负责审批。3.4 配置项标识规则341 配置项标识要求1）合同有明确标识和追踪要求时，由开发人员按合同要求进行标识，以保证满足 合同追踪要求。2）在开发过程中项目组人员提交的配置项，由项目组人员按照本节相关部分标识 规则进行标识。3）项目组人员将要标识或已标识的配置项提交给 CMO 纳入配置库统一管理，并填 写配置状态报告。342 配置项标识方式3421 标识项 配置项标识属性包括：名称、编号、文件状态、版本、作者、日期等。本文标识 规则对名称、编号、文件状态和版本进行了描述和规定。3422 名称文件名称的标识按文档模板中统一名称为准。a）编号文

12、档编号格式为CC_XXX_*$_#，其中CC表示公司，XXX是项目的三位英 文字母缩写表示， *_$表示文档类别， #表示文档顺序号。同时对应每个内 容都有固定的一个索引文件CC_XXX_*$_index,目的是为了为本类别下的文 件建立一个概要说明列表，保证快速对文档进行识别和检索。3423 文件状态 文件状态分为“草稿”、“正式发布”和“修改中”三种。 修改处于“草稿”状态的配置项不算是“变更”，无需 CCB 的批准，修改者按照 版本控制规则执行即可。当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意 修改，必须依据配置变更控制的规则执行。3424 文档版本控制 对于计

13、划性文档、技术文档和用户文档，其版本按修改的先后顺序确定。新生成 的文档第一次发行为第一版，修改后第二次发行为第二版，以此类推。3425 发行版本控制最终完成的软件版本用三位符号表示：“s.x.y ”。各符号位的含义如下： l）“y”为第二次版本号,表示纠正错误时的版本升级，用一位数字表示：“19”， 对上一次产品或项目中的缺陷做修正，第二次版本号增加；2) “x”为第一次版本号,表示增加功能时的版本升级，用一位数字表示：“09”。 与上一产品或项目相比，功能进行了小量的增加或修正时，第一次版本号增加， 第二次版本号为零,第二版本号为零时可以省略不写；3) “s”为主版本号。对产品作重大调整，

14、或与已发行的上一产品相比，在功能 与性能上有较大改善时主版本号增加；产品或项目概念全新,第一次完成,版本 号为 1.0 。3.4.2.6 基线版本标识内部基线，如计划基线、设计基线等，在版本号前加Build，如Build 1.0； 发行产品基线在版本号前加Release，如Release 2.0。3.5 配置库管理3.5.1配置库(Reposi tory)的分类配置库分为两类：1) 文档库(Document Library):由CMO负责管理，主要使用eSM系统管理除程 序以外的文档资料(包括图片等)；2) 程序库(Program Library):由PL负责管理，主要使用CVS版本工具对程序

15、 代码进行管理。3.5.2 配置库的建立3.5.2.1 CCB 成立之后， PL 即可着手组织建立配置库。所有项目应建立配置库， 以便管理各配置项。3.5.2.2文档库空间由eSM系统创建，PL仅创建基线文档库，仅PL可以对其 操作。3.5.2.3 程序库主要通过设置版本的分支，来实现对配置项权限管理，基本上 要为每个配置项从建立开始就划分成 3 个不同的分支(如图 1):1）私有分支（Private Branch）:私有分支对应的是开发人员的私有开发空间。 开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开 发分支上工作，他的 所有工作成果体现为在该配置项的私有分支上的版本的推 进，除该开发人员外，其他人员均无权操作该私有空间中的元素。2）集成分支（Integration Branch）:集成分支对应的是开发团队的公共空间。 凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作 空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。