规范软件开发过程——软件配置管理实践

第一篇：规范软件开发过程——软件配置管理实践

规范软件开发过程——软件配置管理实践

2010-05-19 来源：网络

随着软件系统的规模、复杂度日益上升，软件开发过程管理已经成为保证软件系统开发效率、质量、成本的关键性因素。作为软件开发过程中质量保障的重要组成部分，行之有效的软件配置管理（以下简称SCM，Software Configuration Management）能够显著提高软件开发组织的自身能力、提高软件开发过程的完整性，以及降低软件开发的风险。

软件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983对SCM的定义有不同的描述。ISO9000定义SCM为“一个管理学科，它对配置项的开发和支持生命周期给予技术上和管理上的指导。配置管理取决于项目的规模、复杂程度和风险大小”。

CMM2将SCM定义为一个关键过程域KPA，是“贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现（4）向其他可能有兴趣的人员报告变化。”。SCM包括了配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计等活动，其中以版本控制最为核心和关键。

数据集中工程软件配置管理策略

1、数据集中工程项目背景

中国建设银行数据集中工程的目标是通过建立总行级的数据中心，向全行38个一级分行、20000多个网点提供完整的核心金融服务。其核心应用系统DCC-CCBS包括主机、前置、前端三大部分。主机应用部分部署在总行级数据中心，前置应用部分部署在数据中心前置通信网关、各一级分行业务大前置，前端部分部署在网点。

DCC-CCBS项目的SCM需要实现开发、发布、部署的全过程软件配置管理。开发过程SCM的核心是系统源码版本管理；发布过程的SCM核心是系统目标码版本管理；部署过程以确保系统目标码版本在数据中心、一级分行、网点和外系统的正确部署为首要目标。

2、开发过程软件配置管理

系统源码版本除系统源程序、参数外，还包括需求规格说明书、系统总体架构设计说明书、主机/前置/前端系统结构设计说明书、各子系统的详细设计说明书、各子系统的对外接口规范、业务操作手册、系统使用手册、系统安装维护手册等文档。根据配置项的不同属性，经过评审，形成需求基线、设计基线和源代码基线等不同的基线。开发过程SCM按照子系统的性质，分为主机、前置、前端三部分独立管理。

DCC-CCBS项目总体组负责整个需求和变更的控制。通过审批的需求按照功能分布分解为主机、前置、前端的子需求，再由各部门分别管理和实现。环境及版本控制小组负责向各部门提出形成“系统基线”的要求，以同步主机、前置、前端的源码版本。

3、发布过程软件配置管理

发布过程的系统目标码版本包括系统目标码（执行码）、系统参数及相关文档等。按照用途，系统目标码版本可分为测试版和正式版。以前置平台为例，发布过程SCM的主要活动包括：构建环境管理，保证编译环境的纯净性和正确性；

构建过程管理，保证构建过程的自动化操作，及其正确性和完整性；

版本编号管理，统一版本命名规则，确保目标码版本号的唯一性和可追踪性；

目标码版本生成管理，从各版本管理工具系统收集、整理、打包相应的目标码、参数和文档，形成完整的或部分（补丁）的目标码版本；

配置状态检查，检查目标码版本包中内容的正确性、完整性和一致性；

4、部署过程软件配置管理

部署过程SCM的主要任务是：建立安全、可靠和迅速的传输流程和传输渠道；建立目标码版本记录和追踪机制、版本运行时刻检查机制和版本恢复机制；确保正确的版本、按照正确的渠道、在规定时间递交到正确的用户并生效。

在DCC-CCBS生产环境中，软件开发中心将通过数据中心版本管理系统发布各单位所需的目标码版本，各单位在版本管理系统和数据传输通道的支持下，实现版本/补丁的主动分发、查询、下载和生效。

软件配置管理实施经验

1、树立正确的企业配置管理意识

SCM是一门管理学科。归根结底，其关键是“管理”，然后才是“软件配置”。项目级SCM能否成功实施，与企业的软件配置管理目标、策略、能力、组织和资源息息相关。

2、提高全员的配置管理素质

SCM是规则和流程的集合，需要依靠流程中所有部门和人员共同的支持和努力。任何环节上的疏忽和懈怠，都将直影响SCM的实施效果。

3、采用合适的工具

功能强大的或昂贵的工具未必是合适的工具。往往20%的功能即可解决80％的配置管理问题。目前比较流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在选择具体工具时，往往需要考虑以下因素：（1）工具将要使用的范围；（2）工具自身的功能、稳定性、扩展行，以及对环境的要求；（3）工具使用的复杂度；（4）工具与其他流程和工具的集成度和交互性；（5）工具的投资和维护费用。

4、及时的检查和梳理

大系统开发过程中，配置管理往往采用分步离散管理方式，因此保证整个系统配置管理的完整性成为一件精密细致的工作，需要投入大量人力及时修订基线，防微杜渐，避免混乱，以满足对配置管理正确性、完整性和及时性的要求。

5、系统化思考、分步实施、持续改进

SCM不是一项孤立的管理活动。企业的战略目标、管理能力、文化背景、组织结构，项目的规模、性质、技术、人员等都是影响SCM决策的重要因素。因此需要在项目乃至企业的整体环境中系统的考虑SCM的实施策略和方法。

通过分阶段实施量化的、渐进的配置管理目标，可以避免由于引入复杂管理流程所造成的混乱，有利于方便灵活地优化配置管理流程。同时，阶段性目标的实现将有助于整个团队提高士气、增强信心，并逐步提高开发队伍的配置管理素质。

第二篇：软件配置管理最佳实践

软件配置管理最佳实践

PMTeam杂志 Li Ben 编

现在大家都已经认识到了有效的软件配置管理工作对于提高团队开发效率、保障软件产品质量的重要意义，很多朋友也开始了在配置管理实施方面的一些研究，市场上我们也可以看到一些软件配置管理工具厂商针对具体配置管理工具提供的实施服务；但是，实施软件配置管理到底应该做哪些东西？团队的配置管理现状怎么评估？在哪些方面还可以进行改进？我们相信，这些问题可能正困扰着大多数研发主管和项目经理。

国外软件产业界在软件配置管理这个专题上已经进行了多年的理论和实践上的研究。在多年经验积累的基础上，产业界总结出来一系列“最佳实践”（Best Practices），我们可以使用这些“最佳实践”来作为评估一个组织软件配置管理能力的标尺，也可以作为我们实施软件配置管理的指南。这些“最佳实践”包括：

1、标识需要进行存储的工件（Artifact）并保障安全存储；

2、控制并且审计（Audit）对于工件的修改；

3、设立并管理基线（Baseline）；

4、记录并跟踪变更请求；

5、维护稳定、一致的工作空间；

6、支持对于工件和控件的并发修改；

7、尽早集成、持续集成；

8、保证软件构建的重现能力；

9、以控件（Component）为单位实施版本控制；

10、使用“活动”（Activity）来组织和整合版本集。

下文将介绍前5条最佳实践。

1、标识需要进行存储的工件（Artifact）并保障安全存储

在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件（Artifact）。对于一个软件开发组织来说，这些工件就构成了组织的核心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，好好地保存；对于软件资产，我们也需要相似的措施。所以，软件配置管理工作的第一步就是建立一个安全、可靠的存储库（Repository），用于保存组织的核心软件资产。这个库对于开发团队来说，就像是财务室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除此之外，随着

组织的增长，置于库中的数据会越来越多，为保证运行效率，库的可扩展性也是非常重要的一个属性。

对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。

在建立好存储库以后，需要做的工作就是确定将哪些工件置于库中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入库中。我们把放入库中的文件称之为配置项（Configuration Item）。

2、控制并且审计（Audit）对于工件的修改

在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些工件的修改控制机制以及审计机制。

库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方（Who、When、Why、What）。审计机制通常通过“检出/检入”（Check out/Check in）模式得到实现。在这种模式下，工件一旦入库，读写权限就变成只读（read only），如果要对该工件进行修改，则需要通过“检出”这个步骤；在修改结束以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人把上边的过程称之为“版本控制”（Version Control）。在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。

3、设立并管理基线

通过审计机制我们可以保存一个工件完整的变更历史；但是一个项目通常是由成百上千个工件构成的，每个工件在变更过程中都会形成一系列的版本，如何确认系统在某个时刻分别由哪些工件的哪些版本构成？这就需要引入一个概念：配置（Configuration）。对于软件系统来说，在开发过程中某个时刻存储库中所有工件的一个“快照”（snapshot），就形成一个“配置”。对于一些重要时刻的系统配置，我们可以使用基线（Baseline）来进行标志。

IEEE对于基线的定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变

简单地说，基线就是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于这个标准进行，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对它进行的变更都将记录为一个差值，直到建成下一个基线。

建立基线的主要原因是：重现能力、可追踪性和报告能力。

重现能力是指返回并重新生成软件系统给定发布版本的能力。可追踪性建立项目各种类型工件（需求、设计、实现、测试等）之间的横行依赖关系，其目的在于确保设计满足需求、代码实施

设计以及使用正确代码编译生成可执行文件。报告能力来源于一个基线内容同另一个基线内容的比较，基线比较有助于程序调试并生成发布说明（Release notes）。

建立基线有以下几个好处：

(1)基线为开发工件提供了一个定点和快照。新项目可以从基线提供的定点之中建立。

(2)当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。

(3)可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现被报告的错误。在开发过程中，需要定期建立基线以确保团队开发人员的工作保持同步，通常，在项目生命周期中的里程碑处定期建立基线。

4、记录并跟踪变更请求

以上我们谈论的都是对于工件的变更活动的实施，下面我们要谈到的是软件配置管理的另一个方面：对于变更请求的管理。这是变更活动的源头。

著名的软件大师Brooks曾经谈到导致软件开发困难的一个原因就是软件的可变性。大家都知道，各种要素，如市场的变化、技术的进步、客户对于项目认识的深入等等，都可能导致软件开发过程中的变更请求的提出，而且承认这种变更请求的合理性也已经是工业界的共识。

但是，如果缺乏对于变更请求的有效的管理能力，纷至沓来的变更就会成为开发团队的噩梦。缺乏有效的变更请求管理会导致以下一些问题：

（1）软件产品质量低下，对一些缺陷的修正被遗漏；

（2）项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力；

（3）开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况。

变更请求管理的复杂程度与变更的具体类型有关。简单地说，变更请求管理会涉及到变更请求的提交、变更请求的复审、变更任务分配、变更结果的验证等一系列活动。通常，变更请求管理的流程是：由请求者提交变更请求，变更控制委员会（Change Control Board，CCB）召开CCB复审会议对变更请求进行复审，以确定该请求是否为有效请求。如果是，则基于项目团队所确定的优先级、时间表、资源、变更难度、风险、严重性以及其他相关标准，判定对该变更的修改程序，并分配实施变更任务的人力资源和时间资源；变更任务实施人员负责实施该变更；实施结束以后提交验证人员，由验证人员负责对变更结果进行验证，如果变更成功则通知相关人员，否则由变更实施人员返工。

典型的变更请求管理如需求变更管理、缺陷追踪等。实施有效的变更请求管理有以下好处：

（1）提高软件产品质量；

（2）提高开发团队沟通效率；

（3）帮助项目管理人员对产品状态进行客观的评估。

关于变更请求管理的详细过程以及相关准则PMT将在相关报告中阐述。

5、维护稳定、一致的工作空间

在我们把相关工件纳入集中的存储库、大家也都遵照“检出/检入”的工作模式对工件进行修改以后，下一步的工作就是要为每位开发人员设定“私有”的工作区，或者叫做工作空间。

工作空间通常以特定的基线为基础创建，要求能够做到为指定的任务方便地取出正确的工作版本建立私有工作空间；开发人员根据项目要求在自己的私有空间中对工件进行修改和测试活动，而与其他开发人员相对保持隔离，也就是说，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员。但是，在保持隔离的同时，又应该提供相应的机制，当开发人员希望共享工作成果的时候，能够很方便地实现共享。

开发人员日常的开发工作都是在工作空间里进行的，因此，稳定性应该是工作空间首要的特性，只有高度稳定的工作空间才能保证开发人员的工作效率。

第三篇：软件开发过程规范（模版）

软件开发过程规范

1目的为了规范软件研发各个阶段的开发行为，特制定此规范。

2适用范围

本规范适用于研发中心软件产品研发从立项，到开发实施、测试、结项的各个阶段，规定了各开发阶段的文档编制、代码编写和资料备份内容与要求。3术语和缩写

研发项目干系人：公司内部与研发项目有关联的任何人。

项目计划周期：从项目立项到计划完成时间的实际工作日数。

项目实际周期：从项目立项到实际完成时间的实际工作日数。

项目质量目标：项目允许出现的总的缺陷数的加权平均值。

项目实际质量：项目实际出现的总的缺陷数的加权平均值。

软件缺陷：在测试过程中被发现的软件bug，按照不同的严重程度分为四级；一级，系统崩溃，无法自动恢复，加权系数为100。

二级，系统功能无法实现或性能指标无法达到，但不影响其他功能的使用，加权系数为2。

三级，系统功能实现不完整，加权系数为1。

四级，不影响系统功能和性能的小错误，忽略此错误系统可正常运行，加权系数为0.5。

加权缺陷数量：测试中出现的各种缺陷的数量乘以其对应的加权系数，求和。4内容和要求

4.1研发立项

4.1.1立项申请，产品研发经过申请后才能立项，立项申请人可以是公司员工，也可以是公司各职能部门。

4.1.2立项申请人或委托其部门负责人召集相关人员讨论通过，确定项目经理并初步确定项目组成员。

4.1.2.1《研发立项申请书》由项目经理负责编制。

4.1.2.2项目编号规则为，软件项目：PS+编制日期；（硬件项目：PH+编制日期）。如：PS20070902。

4.1.2.3《研发立项申请书》要规定开发的产品的具体名称，以及所属各个系列的规格型号定义。

4.1.2.4《研发立项申请书》规定开发的产品的属性，包括功能详细描述，性能要求详细描述和稳定性要求详细描述。

4.1.2.5《研发立项申请书》明确项目经理和项目组成员。

4.1.2.6《研发立项申请书》明确项目的开始日期和计划完成日期。

4.1.2.7《研发立项申请书》概要说明项目开发的资源需求，包括硬件设备、软件工具、场地环境等。

4.1.2.8《研发立项申请书》确定项目的质量目标，包括各级缺陷的数量和测试周期，所制定的质量目标不允许有一级缺陷。

4.1.2.9《研发立项申请书》的编制格式参照《研发立项申请书模板》。

4.1.3《研发立项申请书》由研发项目经理、主管软件的研发经理、营销中心经理认可，主管研发副总经理最终确认。

4.1.4内容变更：研发项目干系人可对申请对《研发立项申请书》的内容进行变更，变更后按申请的流程进行签字确认，变更后的内容重新填写《研发立项申请书》并附在原申请书后。项目组成员的变更由研发内部掌握，不必进行变更申请。变更可在结项前的任何阶段提出。

4.1.5项目撤销，如遇重大变故造成所研发的项目已经无实际意义或其他原因需要立即停止，可申请撤销，申请人需是项目干系人，并具有中心经理以上的级别，申请人负责编写《研发项目撤销申请书》,说明撤销原因，撤销申请需得到项目经理、主管软件的研发经理、营销中心经理和主管研发副中经理认可，经由总经理批准后生效。撤销申请可在结项前的任何阶段提出。

4.2研发

4.2.1研发立项确定后，项目经理需编写《项目研发计划书》。

4.2.1.1《项目研发计划书》初步制定项目开发的任务列表和模块划分，以及项目组人员的模块归属和工作时间安排。

4.2.1.2《项目研发计划书》可以用通用的项目管理工具来完成，编制格式由项目经理确定，推荐使用Microsoft Project。

4.2.1.3《项目研发计划书》由项目组成员认可。

4.2.1.5项目经理可根据实际情况和设计的深入，随时变更《项目研发计划书》。

4.2.1.6主管软件的研发经理可抽查《项目研发计划书》的编制和实施情况，并给出改进建议。

4.2.2研发设计

4.2.2.1《软件需求分析说明书》

4.2.2.1.1软件项目需编制《软件需求分析说明书》。

4.2.2.1.2《软件需求分析说明书》由项目经理或其委托人编制。

4.2.2.1.3《软件需求分析说明书》确定整个系统的物理结构和部署要求，并根据系统的物理结构进行模块划分，确定各个模块的功能范围和模块间的接口方式。详细说明系统规模要求和运行环境限制，并指出系统运行所需资源的要求。明确开发和系统运行所需软硬件资源的要求。确定项目进行一次全面测试所需要的测试人员人数和测试周期。《软件项目需求分析说明书》的格式参照《软件项目需求分析说明书模板》。在软件需求分析过程中，如果软件有用户界面，要在此阶段进行界面的初步设计，为了提高效率，界面草图的绘制不限定形式和格式。

4.2.2.1.4《软件需求分析说明书》由项目组全体成员认可，主管软件的研发经理最终确认。

4.2.2.1.5《软件需求分析说明书》的变更，在开发过程中，项目组成员可提出对《软件需求分析说明书》的变更申请，变更的范围限于不能违背《研发立项申请书》的要求，即不能有涉及到《研发立项申请书》变更的内容，如果有，需要做《研发立项申请书》变更的流程。《软件需求分析说明书》变更的主要目的是修正其中的错误，或者经过变更可提高产品的品质或性能指标或缩短产品的研发周期。《软件需求分析说明书》的变更需得到项目经理的同意，必要时由项目经理召集相关技术人员和项目组成员召开简短的技术会议进行论证。项目经理将变

更后的内容形成新版本的《软件项目需求分析说明书》，由主管软件的研发经理最终确认。

4.2.2.2《软件概要设计说明书》

4.2.2.2.1软件项目需编制《软件概要设计说明书》。

4.2.2.2.2《软件概要设计说明书》由项目经理或其委托人编制。

4.2.2.2.3《软件概要设计说明书》确定整个系统的逻辑结构，并对需求分析中各物理模块进行逻辑模块划分，详细描述各逻辑模块的业务规则和模块之间的接口以及重要的内部接口，确定系统级的全局变量和数据结构，确定各逻辑模块所包含的程序文件名称和使用的开发工具，描述每个文件中所包含的函数功能。确定数据库的类型和所有数据表名称及数据表的用途，确定数据库的访问方式。详细描述系统的配置方式。如果软件有用户界面，要对界面进行详细设计，确定所有界面的名称、规格及界面上的元素类型及功能，界面设计可在开发工具中直接绘制，也可采用其他绘图方式，但在概要设计文档中要保留图示并进行详细说明。格式参照《软件项目概要设计说明书模板》。

4.2.2.2.4《软件概要设计说明书》由项目组全体成员认可，主管软件的研发经理最终确认。

4.2.2.2.5《软件概要设计说明书》的变更，在开发过程中，项目组成员可提出对《软件概要设计说明书》的变更申请，变更范围限于不得违背《研发立项申请书》和《软件需求分析说明书》的要求，所涉及的变更不至于影响到《研发立项申请书》和《软件需求分析说明书》的变更，如果有，需要做《研发立项申请书》的变更流程或者《软件需求分析说明书》的变更流程。《软件概要设计说明书》变更的主要目的是修正其中的错误，或者经过变更可提高产品的品质或性能指标或缩短产品的研发周期。概要设计说明书的变更需得到项目经理的同意，必要是由项目经理召集相关技术人员和项目组成员召开简短的技术会议进行论证。项目经理将变更后的内容写入新版本的《软件项目概要设计说明书》，主管软件的研发经理最终签字确认。

4.2.2.3软件详细设计

4.2.2.3.1软件详细设计由项目经理指派，项目组成员分担完成。

4.2.2.3.2软件项目详细设计的内容及格式要求，软件项目的详细设计根据《软件概要设计说明书》划分的各个逻辑模块包含的程序文件，确定每个程序文件中所包含的函数的详细描述，要求有函数的功能描述、输入输出说明、使用规则和限制，如有必要，还可以描述函数的实现流程。详细描述软件中所有全局变量的格式、初始值、用途和使用规则。详细描述软件中所有的数据结构和类结构。详细描述数据库中的数据表，确定数据表的的每个字段，以及数据表之间的关系，确定所有的视图、触发器和存储过程。详细设计文档不做具体的格式要求，为了提高研发效率，可以把详细设计作为代码的一部分，直接在程序中编写，编写时要遵循《研发中心软件编码标准》的规定。

4.2.2.3.3项目经理负责组织对详细设计进行审核，审核方式可采用项目经理主审和项目成员互审相结合的方式，主要审核详细设计和概要设计及需求分析的符合性，及详细设计的正确性。主管软件的研发经理可组织相关技术人员对详细设计情况进行抽查。

4.2.2.3.4详细设计的变更，可在项目开发的任何时段进行，由项目成员在得到项目经理的口头同意后进行，要在变更处做好变更记录。

4.2.2.4质量控制

4.2.2.4.1项目组内部互审，在项目的开发过程中，项目经理可组织项目组成员对编制的代码进行互相审核，目的是审查代码是否符合《研发中心软件编码标准》的要求，并在联调前找到代码中的缺陷，审核时要做好审核记录，内容为代码的编写人、审核人、缺陷位置、缺陷描述和改进建议，格式由项目经理决定。根据项目的具体情况，项目经理有权决定不进行代码的互审。

4.2.2.4.2研发中心内部抽查审核，在项目的开发过程中，主管软件的研发经理可组织相关人员对项目组的开发质量进行抽查审核，被审核的代码模块由研发经理确认，审核的主要目的是验证的代码书写的规范性和与设计的符合性。在评审中发现问题，主管软件的研发经理可口头通知项目经理进行整改，问题严重时，可对项目组下达《软件整改通知单》，通知项目组进行整改。具体使用何种方式由主管软件的研发经理确定。《软件整改通知单》下达后，按比例扣除项目组的项目奖金，扣除办法参见《研发软件项目奖金发放制度》。

4.2.2.4.3项目组内部集成验证测试，项目经理可在代码完成后组织内部集成测试，并同时指派项目组成员进行《软件使用说明书》的编制，在内部集成测试结束，《软件使用说明书》完成后，项目经理可申请提交软件的a测试。

4.2.2.4.4《a测试申请书》，项目经理负责编制《a测试申请书》，格式参照《a测试申请书模板》。编制完毕后，与《软件使用说明书》一起提交给主管软件的研发经理进行审核确认，主管软件的研发经理签字同意后，指定项目的测试人员，进行a测试。

4.2.2.4.5测试人员根据《研发立项申请书》和《软件使用说明书》的要求与内容，编制《软件测试大纲》，确定要测试的具体项目以及对这些项目的要求，《软件测试大纲》编制完成后要由项目经理认可，主管软件的研发经理确认。同时项目组负责协助测试环境的搭建。

4.2.2.4.6在一轮测试结束后，测试人员出具《项目测试报告》。项目组对测试出的问题进行修改，然后再申请新一轮的测试，新的一轮测试由项目经理决定是进行验证性测试还是完整测试，如果是验证性测试，可由项目经理确定测试内容范围并和测试经理协商测试周期，循环上述过程直到项目经理认为可以结束测试。为了保证测试质量，要求最后一次测试必须是完整测试。测试结束后，测试人员要编制《测试过程总结报告》。

4.3研发结项

4.3.1测试结束后，项目经理可决定对项目进行结项提交。

4.3.2项目经理负责编制《研发结项申请书》，格式参照《研发结项申请书模板》。

4.3.3《研发结项申请书》要对所存留的问题进行详细描述。

4.3.4《研发结项申请书》说明项目的实际开发周期，与计划周期的差异将作为项目奖金的评定依据。

4.3.5《研发结项申请书》要说明项目质量目标的实现情况，根据《测试过程总结报告》统计出项目的实际质量，与计划质量目标的差异将作为项目奖金的评定依据。

4.3.6《研发结项申请书》中所存留问题部分的内容需由此项目的实际测试人员进行确认。

4.3.7《研发结项申请书》由项目经理、主管软件的研发经理、营销中心经理、技服中心经理认可后，由主管研发副总经理最终确认。

4.3.4项目提交后，项目经理出具《软件项目信息统计表》，由主管软件的研发

经理认可，主管研发副总经理最终确认，作为项目奖金分配的依据。

4.4技术资料的管理与备份

4.4.1项目经理负责技术资料的管理与备份，备份内容包括项目所涉及的文档、代码和其他相关技术资料。

4.4.2项目立项后，项目组要在代码管理服务器上建立专门的项目目录。

4.4.3在研发过程中，项目组不定期的向代码管理服务器进行代码备份，备份时机由项目经理决定。

4.4.4项目提交测试前要进行一次完整备份。

4.4.5项目结项后，要进行一次完整备份，并将最终项目内容刻录光盘备档。

4.4.6备档后的光盘由主管软件的研发经理统一管理。

4.4.7在研发过程中，纸质文档由项目经理负责管理，项目结项后提交到主管软件的研发经理备档。

4.4.8由于项目组备份不及时和备份管理不到位造成项目资料丢失，致使开发周期延误的，每发生一次按比例扣发项目经理的项目奖金，造成重大损失的，全部扣发项目经理项目奖金，并根据具体情况追究其责任,是否为重大损失由主管软件的研发经理确认。奖金的扣发办法参照《研发软件项目奖金发放制度》。5职责和权限

5.1主管研发副总经理负责本规范的编制、发布、维护与解释。

5.2主管软件的研发经理负责推动和监督本规范的实施。

5.3公司所有员工可对本规范提出修改意见。

6历史记录

本规范于2007年9月25日编制完成，形成V1.0版。

V1.0于2007年11月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.4 权限与职责 1.4.1 研发总经理助理 1）审核变更请求。

1.4.2 项目经理（Project Manager，PM）1)审核批准配置管理计划； 2)接收或拒绝小范围的变更申请； 3)召集评估变更；

4)提出配置管理的建议和要求； 5)配合配置管理员的工作。

1.4.3 配置管理员（Configuration Management Officer，CMO）1)编写配置管理计划；

2)执行版本控制和变更控制方案； 3)制定访问控制策略；

4)负责项目的配置管理工作，包括搭建环境、权限分配、配置库的建立、配置项的控制等；

5)配置管理工具的日常管理与维护； 6)配置库的日常操作和维护； 7)负责配置审核并提交报告；

8)根据配置部署表单编译发布版本，并维护版本； 9)对开发人员进行相关的培训；

10)对配置审核中发现的不符合项，拟订纠正措施，要求相关责任人进行纠正。

11)监督项目组成员规范的执行情况。1.4.4 开发人员（Developer）

1)根据确定的配置管理计划和相关规定，提交配置项和基线； 2)负责项目组内部测试； 3)负责软件集成和版本生成；

4)按照软件配置管理工具的使用模型来完成开发任务。2 实施细则 2.1 配置项管理 2.1.1 配置项的范围

软件配置可包括以下几方面：开发文档，代码，第三方控件、插件，参考资料，测试文档，用户文档，项目管理文档，验收文档等。

l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。

l 代码主要指：源代码等。

l 工具主要指：脚本文件、插件、第三方控件等。2.1.2 配置项基线管理

结合SPP和ISO9000的相关规定，配置管理员根据配置管理规范及配置管理计划，对配置项进行分阶段管理，每一阶段正式评审通过后纳入受控库，作为该项目的一个基线。

l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档，评审或审批通过后建立发布基线。

l 需求阶段：系统调研后开发人员进行需求分析，并整理产品需求规格说明书。产品需求规格说明书经过客户的确认后，建立需求基线。如需升级版本则必须通过评审或审批并得到客户的确认。

l 项目计划：需求分析完成后即可制定项目的开发计划，包括项目计划和主要下属计划。包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。项目开发计划评审通过后，建立项目计划基线。

l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对用户需求规格说明书进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计说明书评审或审批通过后，建立设计基线。l 编码（设计实现）：编码按功能模块分子项目，即每个模块记作一个配置项。代码在提交项目组系统测试时建立Beta版本，系统测试产品正式发布后建立Version版本。

l 测试：单元测试和系统测试。单元测试通过提交《单元测试报告》，项目启动后应提交《系统测试计划》，系统测试完成后应提交《系统测试报告》。配置时应说明测试的版本与编码版本的对应关系。系统测试完成后建立测试基线。

l 版本发布：项目组提交《部署表单》，CMO根据部署表单进行编译，发布测试服务器上，并对版本进行维护。同时将发布的版本上传到文档服务器上备份。

l 交付与验收：在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付文档、代码、工具等。

l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。

l 相关资料：相关资料也应作为配置项纳入配置管理，此部分包括： 1)相关法律、法规；必须遵照或项目组约定的技术规范；

2)与客户或项目组内部重要的交互信息记录，如会议记录、会谈记录、e-mail和MSN记录等；

2.2 版本控制 2.2.1 文档的版本控制

所有文档的管理纳入配置管理库，用版本控制工具进行统一管理。文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现，主要分为以下几类：

2.2.1.1 版本变化型文档

命名方式：[文档名称]+[子系统名称]（可选）

适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等。

示例：项目计划.doc 详细设计_SP门户.doc 标签结构：[大版本] + [子系统简称] + [版本号] + 日期（标签控制说明版本信息）

l [大版本]： 可选，表示同一项目为不同用户定制的版本。l [子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置。

l [版本号]：采用[Vs_x_y]的形式。

l 日期：纳入基线管理的日期，用8位表示，如20071031 说明：

a.文档发布名称采用[文档名+ Vs_x_y]的形式，文档的版本号应该和版本控制工具中相应标签上的版本号一致。

b.对文档的修改需要从配置管理库中取到本地进行。

c.对于文档小的修改，如文字错误，格式调整，变更Vs_x_y中的y来区别（如：V1_0_1）。

d.文档内容没有大的增加和删节，意思表述没有发生重大的变化，版本标识通过版本工具中加上x标签来表示（如：V1_1_0），以及在文档内部控制页标注变化来表示。

e.文档有重大增加和删节，意思表述有重大变化的，版本标识通过在相应文档加上s标签来表示（如：V2_0_0）。

f.对于纳入基线库的文档的修改需要提交变更申请，经批准才能进行修改，并且修改的内容要经再次评审才能重新纳入基线库，作为后续阶段的参考文档。

2.2.1.2 时间区别型文档 命名方式：[文档名称＋撰写时间] 适用文档：文档名称有明确的含义，需要用时间标识的日常性文档。如周例会会议纪要，项目月计划，项目月总结,阶段性计划等等。

示 例：周例会会议纪要20030901.doc 2.2.1.3 时间序号型文档

命名方式：[文档名称+人员姓名（拼音）+撰写时间+序列号] 适用文档：测试报告

示例：单元测试报告_lixiaohong_20071112_01.dco 2.2.1.4 其他文档：

对于不能按照前四种类型进行命名的文档 会议纪要：会议纪要YYYYMMDD()示 例：9月9日召开的项目启动会 命名为：会议纪要20030909(项目启动).doc 评审报告：评审报告YYYYMMDD()同”会议纪要”要求一致。

示 例：10月9日召开的项目总体方案评审 命名为：评审报告20030910(总体方案).doc 2.2.2 发行版本表示

发行版本采用标签说明，结构如下：

[大版本] + [版本类型] + [版本号] + [子系统简称(拼音)]+日期 +序号 [大版本]： 可选，表示同一项目为不同用户定制的版本。

[子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置。

版本类型：分为3种

Beta表示项目组内部测试，标签：B1_0_0-20071015-01 Release系统测试，标签：Release1_0_0-SPmenhu-20071112-01 Version正式发行版，标签：Version1_0_0-SPmenhu-20071112-01 [版本号] 对于Version正式发行版 是必须要注明的，而其它可选。发行产品基线在版本号前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签； Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签。2.3 配置库管理 2.3.1 配置库的分类

配置库统一由配置管理员负责管理，服务器端使用cvsnt2.0.4，客户端主要使用乌龟CVS。配置库目录结构如下：

2.3.2 配置库的建立 所有项目应建立配置库，以便管理各配置项，配置管理员组织建立配置库。程序库主要通过设置版本的分支来实现对配置项权限管理：

1)开发库：开发人员相对比较自由的存储空间，开发人员可以在自己的权限范围内任意取出提交。

2)基线库：配置管理员有最高权限，其余相关人员均为读的权限，发生变更时变更人员须提交变更申请后方可修改基线库内的配置项。

Ø 文档评审通过后，文档严格受控。由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除。

Ø 代码一般在移交系统测试时纳入基线库受控，可根据项目的具体情况设置基线。

3)产品库：产品库的产品均出自于基线库，产品库存储的产品用于交付和存档。

配置三库统一由配置管理员管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

2.3.3 分配权限

项目开始后配置管理员编写《配置库目录结构表》明确项目组成员以及相关人员的权限。在wincvs里有三种权限，读（r）、写（w）、添加删除（c）权限。在开发库内，文档部分项目组成员有rcw权限，其他相关人员只r权限；代码部分项目组成员有rcw权限，其他相关人员没有任何权限。在基线库内，项目组成员仅有r权限，其他相关人的权限视情况而定。在产品库内，所有人没有任何权限。配置管理员在三库内均拥有最高权限。

2.4 配置变更控制 2.4.1 变更的分类

软件及其相关文档的变更按照变更的影响范围进行分类：

1)A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认。

2)B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可。3)C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准。

Ø 系统测试前变更控制流程：

Ø 系统测试完毕发布release版本后变更控制流程

图2 变更控制流程 2.4.2 变更请求的提出

a． 由技术支撑中心汇集顾客意见，影响到需求变更则填写《配置项变更控制报告》，并提交给配置管理员。

b． 配置管理员对申请表是否清晰、明确和完整性进行审查，若发现变更不明确或不完整，应返回申请者。对通过审查的变更申请分配变更ID，以便跟踪和记录变更信息。

2.4.3 评估变更

a． 配置管理员将《配置项变更控制报告》发送给项目经理（或者其他授权人员），由项目经理负责对变更进行评估。

b． 项目经理对变更进行分解，一般的BUG修正不需要审批直接由项目经理决定是否需要变更。新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更。变更评估文档在完成变更评估后发送给配置管理员。

2.4.4 变更实施和确认

a． 变更被批准后，项目经理提交变更实施进度计划，开发人员开始实施变更，并详细记录变更的内容；质量部对变更的实施进行跟踪。

b． 对于代码变更，必须进行回归测试，以确保变更没有引入新的Bug。另外与变更相关的文档必须修订，以反映变更。当变更以及测试完成后，进行提交。

c． 通过测试后，质保人员需对变更进行审核，审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号。

a． 审核后，由配置管理员更新到基线库中。2.5 配置状态报告 2.5.1 目的

记录和报告整个软件生命周期演化状态。2.5.2 记录内容

配置状态报告记录的内容包括： 1)软件和文档的标识； 2)目前状态； 3)基线演化状态； 4)变更状态； 5)版本交付信息等。2.5.3 生成报告

配置管理报告自第一个基线创建时建立，由配置管理系统生成，及时反映当前配置状态。

2.6 配置审核 2.6.1 类别 配置审核分为：

1)功能配置审核（Functional Configuration Audit，FCA）：审核软件功能是否与需求一致，并符合基线文档要求，通常要审查测试文档等。

2)物理配置审核（Physical Configuration Audit，PCA）：审核要交付的组成项是否存在，是否包含所有必需的项目，如正确版本的源代码、资源、文档、安装说明等等。

2.6.2 执行时机

通常选择以下几种情况由质量保证人员负责实施配置审核： 1)软件产品交付或是软件产品正式发行前； 2)软件开发的阶段工作结束后； 3)在产品维护工作中，定期地进行。2.6.3 不符合项处理

对配置审核中发现的不符合现象，配置管理员进行记录，并交由责任部门限期进行纠正，配置管理员负责纠正措施的验证。所有的不符合项报告均关闭后，才能发布新版本。

2.7 发行管理

通过配置审核后，经项目经理批准，由配置管理员负责生产新版本。2.7.1.1 交付管理

这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：

1)交付人向质量部申请；

2)质量部如果不同意交付，则拒绝交付配置项。如果同意交付，配置管理员应给出详细的交付清单；

3)交付人验收后签字。

第五篇：软件配置管理解决方案

软件配置管理解决方案

目的:

● 通过使用配置管理软件,遵守版本控制、变更控制等规程,保证所有配置项的完整性和可跟踪性。

范围:

● 适用于公司的软件开发项目,它规定了软件配置管理活动的具体规程及其工作产品。

角色与职责:

● 配置管理员:编制项目配置管理计划；创建并维护配置库。

● 配置变更控制委员会(SCCB):审批配置变更申请。

● 软件开发组成员:在权限内使用配置管理工具操作配置库。

● 项目SQA人员:审计配置管理活动的规范性。

进入准则:

● 项目计划已制定。

● 项目软件过程已定义

● 配置管理员和SCCB人员已确定。

输入:

● 项目计划

● 项目软件过程

结束准则:

● 对项目配置库的操作和管理持续到项目结束。

● 只要存在用户使用配置管理就要进行。

输出:

● 配置管理计划

● 产品配置库

● 软件基线审计报告

主要活动: 在项目早期(在项目计划初稿后,并与项目计划一起评审)编制项目配置管理计划。

● 确定项目配置管理员。

● 项目经理和项目配置管理员共同指定项目组的SCCB。

● 项目经理与项目配置管理员按确定的软件生命周期,识别出项目要进行控制的软件配置项和纳入配置管理的日期。

● 项目经理与项目配置管理员依据项目定义软件过程,共同确定项目的基线,并标识每个基线的配置项。

● 项目经理确认由项目配置管理员制定的在软件生命周期各个阶段配置项的使用权限清单。

● 项目配置管理员按照《配置管理计划模板》制定项目的SCM计划。

● 项目配置管理员根据项目所使用的开发工具确定项目使用的配置管理工具。

● 项目配置管理员根据项目计划的变动,适时调整项目的SCM计划。具体规程见《项目跟踪与监控过程》计划变更相关步骤。

● 由项目主管主持,项目经理、公司配置管理主管、项目配置管理员、软件工程组、软件相关组参加对配置管理计划书的评

审。具体规程参见《同行评审过程》。

按照配置管理计划,进行项目的配置库管理。

● 项目配置管理员规划、建立项目的目录结构。该结构支持对配置项的存储和检索功能。

● 项目配置管理员根据项目的规模,规划和配置管理工具相关的配置库结构。

● 项目配置管理员依据经项目经理确认的权限清单对目录结构进行权限分配,以达到在相关组之间或配置库内部之间进行共

享和传输。

● 项目配置管理员将配置项用配置管理工具统一管理,将软件工作产品存放在指定的服务器的软件基线库中。

● 项目配置管理员保证由软件基线库制造的产品的正确生成。

● 公司配置管理员定期对服务器的软件开发库、软件基线库进行备份,对配置项的归档版本提供存储和恢复功能。3 配置识别

● 项目配置管理员在制定项目的SCM计划时,与项目经理共同识别出将置于配置管理之下的软件工作产品。可标识为配置项的 软件工作产品的例子有:

◇与过程有关的文档；

◇软件需求；

◇软件设计；

◇软件源代码；

◇软件可执行代码；

◇软件测试规程；

◇为软件测试活动建立的软件系统；

◇编译程序；

◇交付给用户的或最终用户的软件系统；

◇其它支持工具等。

● 项目配置管理员依据项目配置计划书在给定的时间点上标识配置项/单元。

● 项目配置管理员依据开发规范,保证每个配置项赋予唯一的标识符。

● 项目组成员应用配置管理工具,标明每个配置项的修订版本号。

● 项目配置管理员可用配置管理工具中的label功能,说明每个配置项所属的软件基线。

● 项目配置管理员使用配置管理工具记录每个配置项/单元置于软件配置管理之下的时间,并标明其生成者。配置变更

● 变更分类

对软件及其相关文档的变更按照变更的影响范围进行分类:

1)A级:变更会影响系统级需求、外部接口、产品价格或者交付期；这类变更必须经过SCCB审核并有客户批准和确认。

2)B级:变更会影响配置项间的功能接口、组件级成本或者项目Schedule；这类变更必须由SCCB或上级管理部门的批准和认可。

3)C级:变更会影响配置项内部功能的设计和分配；这类变更可以由配置项的管理人员负责批准。

● 变更请求的提出

◇如果需对已纳入基线管理的配置项提出修改,项目组或其他相关人员应在配置项变更请求评审记录中填写变更请求,交给项目

经理。相关表格参见《配置项变更申请单》。

◇项目经理组织人员对变更请求进行评估,描述实施变更所影响的配置项、文档和资源,确定变更的分类；如果是属于A类

或B类,需要组织SCCB评审会进行评审。

● 变更实施

◇项目经理将需解决并批准的问题通知相关人员进行修改。

◇项目组成员实施《配置项变更申请单》中的所有变更,并确保相关文档得到更改。

◇测试人员对已修改的问题进行确认,并将跟踪结果记入CQ中。

◇当确认无误后,项目组成员检入配置库。

◇项目配置管理员跟踪配置项变更解决的过程。跟踪的主要内容有:

1)解决人；

2)解决日期；

3)解决方法；

4)修改的文件；

5)受影响的文件；

6)受影响的数据；

7)是否经过验证等。

● SCCB定期召开评审会,确认基线修改的正确性、完整性和一致性,并保证不会对基线造成意外的后果。保证由软件基线库生成产品并控制它们的发行。

● 项目经理或指定人员依据SDP中的build计划和软件产品测试申请单,对存放于软件配置库中的源程序进行编译,生成软件产

品,并提交测试人员进行测试。

● 测试人员依据产品测试通过标准,对待测产品进行确认测试,形成测试报告。

● SCCB依据测试报告,审计由软件基线库生成的软件产品与测试通过标准的符合性,并生成SCCB会议纪要。

● 对审计通过的产品build,项目配置管理员将其升级为基线。

● 项目配置管理员对审计通过的软件工作产品建立版本标识号(用配置管理工具的label加以标识)。

● 项目配置管理员将审计通过的软件产品(release)放入软件产品库。

当软件工作产品纳入基线管理时,进行软件基线审计。

● 根据项目配置管理计划,SCCB确认在适当的时间需要审计的软件基线,明确该基线包括的配置项。

● 在该基线包含的配置项经评审和检查通过后,项目配置管理员通过配置管理工具将配置项升级为基线状态,并为配置项标注

LABEL等。该基线所包含的所有配置项都升级为基线状态时,该基线正式建立。

● 项目配置管理员验证该基线是按照项目的配置管理计划所明确的配置项组成的。

● 项目配置管理员验证已建立的基线所包含的配置项是完备、准确的。

● 项目配置管理员将审计发现的问题记入基线审计报告,并对问题进行跟踪直至解决。

● 项目配置管理员将基线审计报告向项目经理报告。

过程裁剪说明:

◆创建配置库时,库结构需要使用公司统一目录结构,但是项目可以根据需要增加目录结构；除在公司外部连接不到公司服务器情况

外,不可以使用公司规定以外的配置管理工具。

相关文档:

◆配置管理计划模板

◆配置项变更申请表表样

◆软件基线审计报告表样