配置管理流程

Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT

简介

业务目的：

为解决、控制过程及部分服务交付过程提供需要的配置项及其属性信息。

IT 目的：

1)建立一个完整的配置项管理框架，降低了无控制环境变更的危险性；

2)CMDB提高支援及各类服务活动的效率和品质，确保服务交付流程如连续性、容量等良好运作。

适用范围

此流程适用IT管理手册中定义的服务范围。

软件配置管理流程

配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________

目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)

1.配置管理流程 1.1概述规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图

1.3软件需求分析阶段参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护开发人员

软件配置管理规范.doc

软件配置管理规范1 1．简介软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的本文档指导项目开展配置管理活动。 1.2 范围本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构第一部分：简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。第二部分：配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。第三部分：变更控制工作规范的正文，包括活动的流程图、进入能及退

出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。第四部分：参考文献，列出了编写本规范所参考的相关的文献资料。第五部分：附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。

PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1

软件配置管理过程指导说明书(超级实用)

软件配置管理过程指导说明书

目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)

1 前言 1.1 目的用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性；验证配置库内容的完备性和正确性等。

配置管理流程

配置管理流程 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT

简介业务目的：为解决、控制过程及部分服务交付过程提供需要的配置项及其属性信息。 IT 目的： 1)建立一个完整的配置项管理框架，降低了无控制环境变更的危险性； 2)CMDB提高支援及各类服务活动的效率和品质，确保服务交付流程如连续性、容量等良好运作。适用范围此流程适用IT管理手册中定义的服务范围。相关流程 IT服务管理手册 (QM-ITSM-2011) 服务规划及管理流程(OP-ITSM-004) 服务报告管理流程 (OP-ITSM-006) 事件和服务请求管理流程 (OP-ITSM-007) 问题管理流程 (OP-ITSM-008) 变更管理流程 (OP-ITSM-010) 发布管理流程 (OP-ITSM-011) 连续性管理流程 (OP-ITSM-012) 容量与可用性管理流程 (OP-ITSM-014) 信息安全管理流程 (OP-ITSM-015) 供应商管理流程 (OP-ITSM-017) 服务策划管理流程(OP-ITSM-019) 定义术语表：无角色定义表

仪器种类代号

编号格式主要设备按以下方式进行编号登记： XX9999YY XX = 仪器种类代号 9999 = 4至5位数字 YY = 地域代号内的缩写式代号内容流程解释配置管理流程从配置规划、日常运维、配置审计、配置管理检讨的PDCA循环保障CI的完整性和有效性，其中配置规划包括配置管理应用的各类规则。配置规划 (P) 5.2.1配置管理范围工具、用途说明：

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改；但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。常见的配置管理工具正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制

配置管理指南

配置管理指南本页仅作为文档页封面，使用时可以删除 This document is for reference only-rar21year.March

配置管理指南有限公司

变更记录修改点说明的内容有如下几种：创建、修改（+修改说明）、删除（+删除说明）

目录 1. 过程概述 ...................................................................................................................... 错误!未定义书签。 2. 过程目标 ...................................................................................................................... 错误!未定义书签。 3. 必要条件 ...................................................................................................................... 错误!未定义书签。 4. 应执行活动 .................................................................................................................. 错误!未定义书签。 5. 验证与监督 .................................................................................................................. 错误!未定义书签。 6. 裁剪指南 ...................................................................................................................... 错误!未定义书签。 7. 附件说明 ...................................................................................................................... 错误!未定义书签。 8. 相关过程 ...................................................................................................................... 错误!未定义书签。

SCMS软件配置管理过程

文档变更请求(DCR)

文档变更记录

目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A ：软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B ：配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C ：软件配置管理测量报告 (11)

1概述 1.1目的软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据。 1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任人”）。 1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for Software （Version 1.1） 1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90

配置管理岗位职责

配置管理员岗位职责摘自：软件配置管理论坛一、配置经理的基本技能与资格资格：能够重视配置管理工作；能够按规范实施配置管理工作；积极支持部门的配置管理方面的工作；能够积极支持与帮助其他人员；为部门的配置管理能力的提高贡献力量；熟悉公司配置流程以及其他相关的流程；为增进项目管理，对于项目内的困难和关键问题，能够及时反映到部门；基本技能：能够独立规划项目的配置管理工作；熟练掌握配置管理的相关概念；能够了解配置的相关工具，熟练使用技术工程部配置所使用的工具；具有基本的与人沟通的技巧；能够了解项目管理过程中的主要环节；初步了解项目管理过程中的质量保证的各个方面；了解部分系统和应用工具，如数据库ORACLE，前台开发工具DEPHI等；二、配置经理的职责作为一名配置人员，配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如：作为质量保证的成员之一，能够为整个技术工程部规范化管理的推进作贡献，如宣传规范化管理的知识，陈述规范化管理的利弊等；能够在项目进行的整个生命过程中，不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通，为项目配置管理的规范化作出努力. 具体表现为： ?项目进行初期或首次进入项目中时，能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通，取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持； ?积极了解项目情况，项目各阶段的进展，为更好的进行配置管理作努力； ?熟练并充分的利用配置管理工具的各方面的功能，提高配置管理的效率； ?为项目控制好版本，保证项目各阶段所使用的版本正确； ?及时发现项目问题，把问题及时反馈给项目经理、QA或SCCB，并积极协助解决； ?与项目内其他组成员，如开发组、测试组等协调工作，并能够很好的沟通； ?能够在项目中不断总结、分析，为项目内配置管理工作的进一步优化作贡献；

软件配置管理工具+Vss+60实用指南

软件配置管理工具Vss6.0实用指南一、版本管理的必要性如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展，那么80～90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现，这就是软件的版本管理。只要参加过软件开发的人都清楚，现在的软件项目完全由一个人来完成是难以想象而且也是不可能的，通常是有一个研发小组来共同分析、设计、编码和维护，并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中，需要涉及到各个方面的人员，信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间，还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义改动，大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中，由于软件开发所固有的特征，可能会形成众多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何有效地解决这些问题，具体地说就是如下一些问题： 1.怎样对研发项目进行整体管理； 2.项目开发小组的成员之间如何以一种有效的机制进行协调； 3.如何进行对小组成员各自承担的子项目的统一管理； 4.如何对研发小组各成员所作的修改进行统一汇总； 5.如何保留修改的轨迹，以便撤销错误的改动； 6.对在研发过程中形成的软件的各个版本如何进行标识，管理及差异识辨等等。一个非常直接的反应，我们必须要引进一种管理机制，一个版本管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管理，而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法，诸如在对他人的源程序进行修改时注释修改原因，修改人和日期，如果是多个成员同时进行了修改，那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了，可以说是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了。其实，版本管理的思想很早就存在于软件开发者的头脑之中，只是以往的认识没有现在人们所意识到的那样迫切。UNIX 的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具，现在的Linux更是提供功能强大的能够跨平台的版本管理器，国外公司的基于Windows的版本管理器也已经有了比较成熟的产品，国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中，这里只将对使用比较广泛，有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe6.0进行详细的介绍，针对普通的研发小组的解决方案，及具体的实现。二、Visual SourceSafe6.0(VSS6.0)简介 VSS6.0现在是作为Microsoft Visual Studio6.0这个开发产品家族的一员，如Visual C++6.0和Visual J++6.0一样。 1.VSS的简单工作原理 Microsoft的VSS6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的

软件配置管理流程

目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)

1.配置管理流程概述规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。总体流程图

软件需求分析阶段参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。软件设计阶段参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。制定配置管理计划配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。配置库管理配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。相关人员分配权限项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护；开发人员 1）根据确定的配置管理计划和相关规定，提交配置项

软件配置管理控制程序A0

程序文件软件配置管理控制程序文件编号版木A0 贞数第1贞共6贞編制部门研发部生效日期2018年09月05日修改页文件编号修改条款修改内容修改人/日期生效日期全文首次发行分发部门会签编制审核批准□业务部□研发部□采购部□生产韶□质量部□行政部

软件配置管理控制程序软件配這皆理贯穿于软件整个生命周期，对规范软件版本、源代码、文件、工具、现成软件等控制要求，确世配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。适用于本公司所有的软件项目，并贯穿于软件生存周期全过程。 3.1项目经理负责指过配置管理人员: 负责审批配置管理il ?划; 负责执行配置管理il 划。 3. 3质量部 > 负责跟踪配置管理il ?划的实施。 4.1术语泄义软件配置管理：是标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和变更, 记录并报告配置的状态和变更要求，验证配置项的完整性和正确性。软件配置项：为配置管理的目的而作为一个单元来看待的硬件/软件成分。基线：一组拥有唯一标识号的需求、设计、源代码文件以及柑应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配苣项〉和生成可执行文卷的工具" 4.2配置管理讣划编制所有项目在指；4^项目开发计划时，都应有项目经理指定配置管理人员，然后由配置管理人员编写《配置管理计划》，也可以包含在《软件开发计划中》，配置管理讣划至少应包括的内容: ? 配置管理人员的组成及分工 2. 范围 3. 职责 3.2 配置管理人员 4. 工作程序

软件正版化工作指南

附件: 正版软件管理工作指南推进使用正版软件工作部际联席会议办公室 2016年7月11日

前言为推进各级政府机关和企事业单位落实软件正版化工作主体责任，加强正版软件管理，保障信息安全，提高使用效率，降低使用成本，推进软件正版化工作规范化标准化，制定《正版软件管理工作指南》（以下简称《指南》）。《指南》主要包括责任制度、日常管理、软件配置、软件台账、安装维护等五项软件使用管理制度范本和台账范本，供各单位开展正版软件管理工作参考。各单位可根据本单位实际情况对《指南》相关内容进行修改完善，建立本单位正版软件管理办法。《指南》主要内容如下：一、软件正版化工作责任制度。明确软件正版化工作领导小组人员组成和工作职责，以及软件使用部门和工作人员职责。二、软件日常使用管理规定。明确软件日常使用管理涉及的工作计划、预算编制、软件采购、软件维护、宣传培训、检查考核、总结报告等工作流程和要求。

三、软件配置管理规定。明确软件配置原则和配置流程。四、软件台账管理规定。明确软件使用管理台账种类和管理办法。五、软件安装维护管理规定。明确软件安装、卸载及升级维护流程。《指南》由推进使用正版软件工作部际联席会议办公室负责解释。

目录一、软件正版化工作责任制度 (8) 二、软件日常使用管理规定 (11) 三、软件配置管理规定 (13) 四、软件台账管理规定 (15) 五、软件安装维护管理规定 (18) 六、附件： 1.软件正版化工作领导小组成员信息表 (20) 2.使用正版软件承诺书 (21) 3.软件使用需求申请表 (22) 4.软件采购计划表 (23) 5.软件正版化工作信息统计表 (24) 6.可使用免费软件清单 (25) 7.软件使用情况汇总表 (26) 8.软件使用情况明细表 (27)

软件配置管理规范流程

1 概述 1.1 目的本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理（Software Configuration Management，SCM）软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项（Configuration Item，CI）凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线（Baseline）在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一

软件配置管理规范标准

页眉软件配置管理规范 1.简介软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的本文档指导项目开展配置管理活动。 1.2 范围本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构第一部分：简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。第二部分：配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。第三部分：变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。第四部分：参考文献，列出了编写本规范所参考的相关的文献资料。第五部分：附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。基线(Baseline)

己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。版本(Version) 页脚页眉某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范项目计划与控制规范 1.5.4 指南配置管理计划指南基线策略指南配置状态报告编制指南配置审计工作活动指南配置管理工具指南 VSS 使用指南组织管理配置库使用指南软件开发文档命名约定 1.5.5模板配置管理计划配置状态报告配置审计报告文档变更请求 1.5.6 检查表无 1.5.7 培训《软件配置管理教材》《软件变更控制管理教材》《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop

软件配置管理控制程序

配置管理控制程序历史记录

1.引言 1.1目的本程序文件定义了本组织的配置管理的过程，目的是规范公司的软件配置管理活动，使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员工作产品（Work Products）：项目技术开发和管理工作中产生的有价值的成果，例如源代码、数据和各种文档。配置项（Configuration Item, CI）：纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ]；配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理。基线（Baseline）：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。 2角色与职责 2.1软件配置管理组（CM） CM组是项目里的一个小组，根据项目大小，可以由一个人，或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排，加入到项目组，由项目经理领导。

CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级，通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。配置管理控制委员会负责审批软件配置管理计划；配置管理控制委员会负责审批软件基线的建立；配置管理控制委员会负责审批对软件基线配置项的变更；配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任，代表SCCB在有关文件上签署意见。 2.4 项目经理定期或事件驱动地评审或审核CM活动。 2.5 测试组负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组负责审核《配置管理计划》任务列表中与QA有关的内容

软件配置管理规范流程模板

软件配置管理规范流程 1 概述 1.1 目的本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

如何制定配置管理流程

如何制定配置管理流程【IT168 技术文章】以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。 1. 问题描述某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。为了保证产品质量，该开发团队建立了以下的软件发布流程：图1 这四个环节分别对应以下四种环境：开发环境：开发实现客户的变更请求测试平台：开发团队把软件发布给客户之前做内部系统测试准生产环境：客户把软件发布到生产系统之前做验收测试生产系统：最终的生产系统当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。 3. 改进建议为了避免以上所述的这些质量陷阱，我们应该改进现有的配置管理流程。（1）建立闭环的质量保证流程造成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理，并且在发布过程中我们发布的是源代码，正确的流程（也是业界较为通行的做法）应该发布构建后的目标码而非源代码。我们可以建立一个闭环的质量保证流程（如下图所示）来批量地进行软件发布。

图6 其中系统测试过程中发现的缺陷应该被开发人员及时改正，然后再做构建，再测试，直到达到一个比较稳定的版本才会发布到验收测试环节。同样的，验收测试中发现的问题也会回到开发环节进行修复。这应该是一个多次循环的过程，不断地发现错误，然后改正，再测试。这个循环到什么时候结束呢？这个取决于各个软件项目的实际情况：最理想的情况当然是到所有的缺陷都被改正为止，但是所花的时间比较长，可能赶不上项目的进度要求，现实工作不大可能做到这一点。折衷的情况是所有严重的缺陷（即那些影响系统使用的的缺陷）都必须被改正，但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。大家平时在一些商用软件的新版本中经常可以见到发布说明（Release Notes）中所列的已知缺陷（Known Defects）就是属于这种情况。我们向开发团队提出这个建议后，马上遭到项目经理的反对：“客户有些紧急的变更需要马上实现并交付生产运营，几乎没有时间来走这样完整的闭环流程。” （2）区别对待缺陷和新增功能通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发： v1.0中的缺陷修复 v1.0的新增功能版本v1.1 下一个版本v2.0 这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。