配置管理资料

1、1 软件配置管理理论知识：1.1 理论Ø 配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。Ø 其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制（？）、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。Ø 软件配置（ software configuration）是指开发过程中，构成软件产品的各种

2、文档、程序及其数据的优化组合。该组合中的每一个元素称为配置中的一 个配置项(configuration item)。也可以把软件配置项定义是软件中可以独立进行开发的一个实体，该实体包括程序、数据及其相应的文档和说明。Ø 配置管理要对软件生存期内各阶段的文档、实体和最终产品的演化和变更进行管理；同时要解决变更的标识、控制和发布等问题。目的是使对设计变更的管理制度化，从而提高开发效率、减少错误，保证产品的质量1.2 术语定义 软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的

3、使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。基线是被评审过的一个或多个软件配置项。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版

4、本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。是软件开发过程中最重要的里程碑，不过基线更强调的是一个开发阶段到达里程碑时的结果及其内容，如功能基线是 经过评审和批准的需求规格说明书；产品基线是经集成和确认测试后，经正式审批可交付客户的软件产品的全部配置项（包括软件实体和所有的文档）。（确定成为基线，必须经过评审和批准）基线就是一个配置项（或一组配置项）在其生命期的不同阶段完成时，通过评审而进入受控状态的一组文档和程序实体，这个过程被称为 “基线化”。每个基线都是其下一步开发的基点和参考点；它们都将接受配置管理的严格控制。因此，基线必须通过评审过程建立；基线存在于基线

5、库中，接受更高权限的控制；基线是进一步开发和修改的基准和出发点。（如后面基线发生大的更改，则版本发生了一次大的更改）受控库 是软件开发过程中，其修改权限受到控制的文档库和程序库，其中基线库和产品库，特别是产品库的修改权限将受到严格的控制，即使是授权修改的人，在修改前还必须得到批准。基线库 是受控库中一些特别重要的库，如需求（基线）库和产品（基线）库。 产品库 是存放软件最终产品（即产品基线）的库，基于它的重要性，对它的修改将受到特别的控制。 产品基线是最初批准的产品配置标识。配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员

6、负责统一添加或修改相关文档的最新有效版本以及审批人签字。配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。里程碑：即通常所说的软件开发过程中的“阶段”，如果说它们之间有 区别的话，那么“阶段”强调的是过程，而“里程碑”则强调过程的终点和终点的标识。这些阶段可以是需求分析阶段、概要设计阶段、详细设计阶段等等。1.3 配置管理在软件开发过程和项目管理过程中的作用Ø 一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开过程的

7、宏观管理，即项目管理，也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性（？），使软件系统具有可重复性，使用户和主管部门用软件质量和开发小组有更强的信心。Ø 配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期Ø 好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开发团队象一个交响乐队一样和谐而又错杂地行进。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境

8、，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。1.4 配置管理系统应该具备以下主要功能Ø 并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制；Ø 修订版管理：跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定 ；Ø 版本控制：能够简单、明确地重现软件系统的任何一个历史版本Ø 产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了

9、解项目的状态 ；Ø 建立管理：基于软件存储库的版本控制功能，实现建立（build）过程自动化 ；Ø 过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等Ø 变更请求管理：跟踪、管理开发过程中出现的缺陷（Defect）、功能增强请求（RFE）或任务（Task），加强沟通和协作，能够随时了解变更的状态Ø 代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发资源2 软件开发存在的问题及配置管理的必然性Ø 在一个软件开发项目中，会有大量的所谓“产品”产生，典型的如代码、文档（包括技术文档、产品文档、管理文档）、数据、脚本、执行文件、

10、安装文件、配置文件、甚至一些参数等，这些产品实际上都是软件项目的直接产品，同时也都是项目资产，所有的产品都以“信息”的形式存放在计算机中，因此，与硬件比较而言，极容易被修改（不考虑权限问题）和变化。Ø 软件开发一直就是“变化”的，需求会变，技术会变，系统架构会变，代码会变，甚至连环境都会变，所有的变化最终都要反映到上述的项目产品中。如何应对这些变化，如何在受控的方式下引入变更，如何监控变更的执行，如何检验变更的结果，如何最终确认并固化变更，如何使变更具有追溯性，这一系列问题都将直接影响项目的进行。 Ø 软件项目最终的目标是提交“高质量”的软件产品给最终用户，经常在项目没有真

11、正结项时，就给客户程序。所以客户那边就产生了很多版本。Ø 忽视软件配置管理可能导致的混乱现象：标识混乱；版本混乱；不能协同工作；已经解决的缺陷过后又出现错误；找不到最新修改了的源程序；找不到编程序的人3 配置管理（scm）的职责Ø 软件配置管理（Software Configuration Management , SCM）是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性、控制这些特性的变更、记录和报告变更的过程和状态，并验证它们与需求是否一致。Ø SCM通过管理配置项控制变更、验证变更，使项目的混乱减到最小，使错误达到最小，并最

12、大限度地提高生产率。 Ø 实施软件配置管理的目的是保证软件项目的工作产品在整个项目周期中的“完整性”。所谓完整性是指，工作产品要求有完整的变更历史记录，要求有正式的变更过程，而且还要求保证工作产品能和需求以及变更保持一致性。4 配置管理的工作内容：4.1 项目计划阶段，也即是配置管理的准备阶段4.1.1 制定配置管理计划对于项目工程部在项目立项前期指派配置管理人员的项目，在项目立项初期，配置经理要与项目经理协商，制定配置管理的计划，规划未来的配置管理工作。配置管理计划的约束条件：配置管理的规划必须以项目开展的工作为基础，参考工作说明书。配置管理计划的编写必须以公司的流程为模版，与工作

13、说明书和质量保证计划相一致；配置管理计划能够指导未来的配置管理工作，配置管理工作必须以配置管理计划为基准；配置管理计划必须经过最终的评审通过，才能够成立；如配置管理计划不能满足未来配置管理工作的需要，可以再增加配置管理工作计划作为配置管理计划的辅助，指导未来的配置管理工作4.1.2 规范配置管理环境配置管理计划制定结束后，配置管理人员要依据计划实施配置管理的前期工作。首先必须规范配置管理的环境，实现项目组内的专机专用，与项目经理协商，开发用机、测试用机、配置用机的情况，并最终生成配置管理环境维护清单，便于后期对环境的维护4.1.3 建立配置库：配置库作为项目组内成员今后工作的平台，前期的详细准

14、备是非常重要的。配置库建立的准则：依据配置管理计划中的定义建立配置库；与项目经理协商配置库人员使用的权限规定与配置库工作区间的划分，保证个人工作区间的隔离Ø 应用注意：三个配置库：（1）开发库： 存放开发过程中需要保留的各种信息，供项目组成员使用。（2）基线库： 在软件开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。对库内工作产品的读写和修改应该加以控制。（3）产品库： 在开发的软件产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。对库内工作产品也应该加以控制。4.1.4 与项目负责人讨论变更控制的实施与项目SCCB讨论项目中变更控制实施的措施，指定出相

15、应的变更控制流程。在变更控制流程中应注意变更过程中责任到人，不同变更情况的处理方式，具体操作可参见变更控制流程制定指导书4.1.5 配置培训配置培训作为与项目成员沟通配置管理内容的一个主要渠道，配置经理应与项目经理协商在项目开始初期进行。培训内容包括：配置管理的基本概念；项目中配置管理工具的使用；项目中配置管理的相关流程；配置库的使用及规范等4.1.6 生成计划基线，并发布基线在项目的立项材料经过正式评审通过，宣布项目立项后，配置经理要整理项目的立项材料，正式生成计划基线，并标识基线，保证基线存放于基线库中。基线的发布通过配置状态报告来实现4.2 项目执行阶段：配置工作真正深入到了项目中4.2

16、.1 维护配置库: 配置库维护包括维护配置库结构、日常权限的设置、帐户的增加与删除、工作区维护、配置库备份等；维护时要注意: 对配置库的备份要与配置机分开，以确保安全性；配置库中帐户的管理要注意定期维护，避免帐户不断增加，出现垃圾帐户的问题；工作区的维护要注意结构清晰、明了，工作区隔离；监督项目组成员使用配置库问题，避免工作脱离配置库平台和配置项长期被CHECK OUT的问题等4.2.2 进行版本控制版本控制是配置管理的另一项主要内容，包括文档版本的控制和代码版本的控制。版本控制中注意的问题：版本标识明确、清晰；在配置库中，有效利用标签；注意保证版本的历史在线和可以回溯；注意每一次的开发以基线

17、版本为基础和基准；注意版本的受控性，保证测试的版本的受控；每一次新的基线版本的生成，要及时发布4.2.3 协助生成项目进行过程中的各种基线项目执行过程中生成各种基线，包括需求基线、设计基线、代码基线等，基线的正式生成要经过评审通过才有效。配置经理协助项目经理组织评审。在评审之前首先要进行物理审计，审计后填写物理审计报告，然后传递给QA进行过程审计。物理审计报告作为配置项存放在配置库中。评审通过后，正式生成基线，配置经理负责整理并标识基线，然后把基线存放在基线库中，通过配置状态报告来发布基线。在代码基线生成时，注意维护源代码清单4.2.4 与测试人员协作配置经理注意与测试人员的沟通，保证与测试组

18、配置管理协接的无误。测试组与配置组沟通的两个主要问题是：测试配置项的管理问题和版本的传递问题。配置经理要与测试经理、项目经理沟通有关测试配置项的管理问题与版本的传递问题。测试配置项可以单独管理，也可以与其他配置项一起存放与一个配置库中，这要根据项目的大小和配置库的增长趋势来决定，建议大型项目在有条件的情况下单独存放，单独管理测试案例、测试数据等；版本的传递指开发组产生出代码，经配置组编译执行生成执行文件并进行版本标识后，传递给测试组进行测试的过程。在此过程中注意的问题是：配置组与开发、测试组的接口的唯一，保证测试版本的正确性4.2.5 与QA协作：配置经理负责向QA及项目经理反映项目进行过程中

19、的不规范问题，并与QA与项目经理沟通，解决问题4.2.6 发布配置状态报告配置经理在项目进行过程中，要及时发布配置状态报告。发布配置状态报告有两种方式：时间驱动和事件驱动。基线生成时、重要配置象产生时，都要发布配置状态报告；定期发布配置状态报告以向全体成员通报项目现阶段的进展情况，注意全体成员要包含QA4.2.7 优化配置管理活动在配置管理过程中，随项目的进展和工作的开展情况，配置经理要适时的调整配置管理的活动。如整理配置库、优化配置流程等。但是必须注意，任何变动和更改必须经过项目经理的同意；更改后要通过配置状态报告发布；变动和更改的配置项要有相应的变更说明。如配置工作需要调整时，需升级配置管

20、理计划，必须确保工作与计划的一致性；4.2.8 维护项目环境在项目进行过程中，注意维护项目的环境，包括配置环境、测试环境、开发环境等。环境的变更要体现在配置管理环境维护清单中。环境的变化要通过配置状态报告发布出去4.2.9 协助项目组完成变更管理配置组有责任协助项目组完成变更控制的管理，并维护变更管理过程记录。变更执行过程中出现的问题，可以向项目经理和QA甚至SCCB反映。变更执行结束，要发布配置状态报告，报告变更的情况4.2.10 参加项目组的会议为使配置管理工作对项目切实可行和有意义，配置管理人员除主动积极了解项目情况外，要参加项目组的例行会议，了解项目的总体情况，以及项目的下一步工作规划

21、，以便配置管理及时作出反馈4.2.11 参加项目工程部的活动配置经理要积极参加项目工程部组织的各种配置活动，如配置经理述职等4.3 项目结项：项目结项时，配置管理人员主要是协助项目经理整理结项材料，对项目配置管理工作进行总结、整理，编写配置管理案例、进行配置工作述职等。如项目配置项需要入产品库，则按产品库规范整理产品配置项。在编写案例时要注意总结项目配置管理工作进行过程中的得失以及经验教训。案例总结和述职的进行都要在项目工程部内进行5 配置管理实施步骤5.1 项目开始之前就进行配置管理计划。配置管理计划往往和项目开发计划一起产生，并相互影响。配置管理计划的目标是规划整个项目的配置管理活动，尤其

22、是重要的比如发布、基线管理等问题。配置管理计划的主要内容包括配置项的标识和命名规范、配置管理环境方案、配置管理活动计划和时间表、基线计划、发布计划等。可以说，配置管理计划直接决定了项目配置管理的方针，以及配置管理活动的准则。忽略配置管理计划，将使整个配置活动甚至项目都受到影响。 5.2 配置库管理配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等5.3 版本控制版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。配置项的状态有三

23、种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则5.4 要进行配置项的标识要进行配置标识，首先必须明确项目生命周期内所要产生的工作产品，然后确定工作产品的命名和标识规则所谓配置项，简单地说就是受SCM控制和管理的工作产品单元，也是配置管理的目标。程序（源代码、目标代码、可执行程序、函数等）、文档（需求定义、系统分析、系统设计、高层设计、低层设计、测试规格说明书、测试计划、安装手册、发布说明、用户手册等）、数据（测试数据和项目数据）、执行文件等，都是典型的配置项，又如操作系统参数、编译器描述、物理特性、版本描述等，为了能进行配置管理，需要对其进行描述，并形成文档

24、，再以配置项形式进行管理。Ø 应用注意：配置项标示的原则¨ 唯一性¨ 可追溯性¨ 与同类配置项不同的信息，应纳入标识：这是为了便于区分、查找¨ 同类配置项的标识方法统一¨ 容易记忆Ø 配置项的相关标识信息¨ 组名¨ 项目名¨ 文档内容¨ 版本号¨ 文档撰写时间¨ 文档撰写作者5.5 进行变更控制可以这样说，我们所熟知的版本管理，其本身并没有什么直接作用，而真正起发挥作用是为变更控制进行支持主要的原因是，所记录的配置项的所有状态，只有和变更控制进行配合，将变更的原因和

25、变更的结果（配置项的某一版本）联系在一起，才能以变更为主线，将所有版本变为“有理由的”（reasonable），才能形成基线，真正发挥变更控制和版本管理的作用。 变更控制的目的就是为了防止配置项被随意修改而导致混乱；修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请审批执行变更再评审结束”的规则执行如何记录这些变更，需要做二件事。一是要标识这些设计文件，即根据文件名，确定一个唯一的标识符（VSS用label可以实现）；二是要动态地记录这些变更文件（即用版本的方法

26、记录这些变更）-用配置软件可以实现n 版本号形式：主版本号.从版本号.维护版本号 n 主版本号对系统作重大调整，在功能和性能上有大的变化时主版本号增加。第一次版本号和第二次版本号为零。版本号升级由项目组长/室主任决定。n 从版本号与上一版本相比，对系统功能或性能进行了少量的增加或修改，从版本号增加，主版本号不变。版本号升级由项目组长决定。n 维护版本号与上一版本相比，修改了小量系统bug，维护版本号增加，主版本号和从版本号不变。版本号升级由项目组长决定。n 通常来说，通过软件系统测试后系统版本号变为V1.0，软件系统第一次发布时版本号为V，从版本号和维护版本号均为0。5.6 要进行配置管理的状

27、态监控和报告基本上依照项目对配置管理的要求进行统计和分析。但是，配置管理状态报告往往能从另一个方面反映项目的进度情况，甚至有时比项目进度状况报告还要准确。比如，变更请求状态分布报告，就可以客观地反映按照计划应该完成多少变更请求，而实际上完成多少变更请求，这实际上客观地反映出已完成和未完成工作量。这方面的内容在项目进度报告中很难客观反映，从而造成项目实际情况与进度报告不符。 5.7 进行配置审核（配置审计）这个环节是配置管理达到效果的重要手段，否则容易造成在产品测试、产品发布是仍然出现混乱。确认产品的完整性并维护配置项间的一致性5.8 总结：一个完整的SCM系统要具有三个核心功能：版本控制、变更

28、控制、配置控制以及两个支持功能：状态统计和配置审计。5.8.1 版本控制：版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合5.8.2 变更控制：变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在 的缺陷进行修补。对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制

29、委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。（VSS,CVS）变更机制如下图所示：5.8.3 配置控制:软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。 (?值得思考，如果这个问题解决了，就可以模块组合，然后形成新的版本，从而解决不同客户的需求. 在开发过程中，我们在不同阶段要建立各种基线,基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置5.8.4 状态报告: 状态报告要回答所谓4W的问题 What：发生了什么事Who：谁做的此事When：此事是什么时候发生

30、的Why：为什么做此事状态报告还要能够报告所有配置项以及变更请求的状态5.8.5 配置审计配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等. 置审计是一个SQA（软件质量保证）活动。6 一般配置管理中的角色Ø 项目经理：项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助，制定项目的组织结构和配置管理策略。这些工作包括：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，以及进行系统集成Ø 配置管理员：配置管理员的职责是根据项目经理制定的开发组织结构和策略，实施、维护配置管理的环

31、境。其主要职责如下：创建配置管理库，对存储库进行日常备份和恢复，维护配置管理环境，及管理配置管理相关的用户Ø 软件开发人员：软件开发人员依据项目的开发和配置管理策略，创建、修改和测试开发工件Ø 集成人员：对软件进行归并，形成相应的基线或发布版本Ø QA人员：需要对软件配置管理有较深的认识，其主要工作是跟踪当前项目的状态，测试，报告错误，并验证其修复结果7 配置库实施的目录结构：7.1 一级目录介绍7.1.1 基线库经过评审，变更严格控制的工作产品。基线库由配置管理员建立并维护，其它任何人没有写权限。7.1.2 产品库产品库由配置管理员建立并维护，整个项目结束后，配

32、置管理员从基线库里把所有的文档挪到产品库中，其它任何人没有写权限。7.1.3 开发库开发库由配置管理员创建主要目录，项目组成员可以在目录下创建子目录以及文件。文件/目录的创建者本人拥有该目录/文件的完全控制权限，而项目其它成员缺省情况下是只读权限。如果其它成员需要修改文件/目录，必须先由文件的创建者赋予权限。 7.2 重点目录说明开发库目录7.2.1 计划项目计划相关文件（估计、进度）纳入基线前的文件，以及项目初始计划等7.2.2 需求纳入基线前的需求说明书等文件，需求跟踪矩阵7.2.3 设计纳入基线前的设计文件，包括概要设计、详细设计。项目组长有读写权限7.2.4 源代码项目开发过程中的代码7.2.5 测试项目单元测试和集成测试所需要的工作产品和测试过程