行为优化提升软件配置管理
GJB5000A软件配置管理过程优化
GJB5000A软件配置管理过程优化作者：王小妮梁琦钱宏文来源：《数字技术与应用》2020年第08期摘要：软件项目运行中按照GJB5000A配置管理过程，依据项目协议任务识别项目周期模型，确定项目运行需要的配置管理阶段和配置项，结合软件项目平台系统使用三库和三基线标识并管理所需的配置项状态，最终通过软件项目配置管理过程的优化，标准规范的进行软件项目管理。
关键词：配置管理;配置库;配置项;基线中图分类号：TP311.52 文献标识码：A 文章编号：1007-9416（2020）08-0196-050 引言随着信息化的飞速发展软件研制规模不断增加，使得软件产品的版本管理困难也增加，参照GJB5000A-2008《军用软件研制能力成熟度模型》，对软件项目规模和软件项目需进行的阶段进行设计，以某小型项目文档模板按照GJB438B-2009《军用软件开发文档通用要求》为例介绍，该项目在某软件项目平台按五个阶段开展：系统需求分析与设计阶段、软件需求分析与设计阶段、软件实现与测试、软件合格性测试、软件验收与交付。
按软件项目阶段工作计划设定项目任务并分配软件项目需要的专业成员，保证软件项目研制阶段快速化、规范化、标准化。
配置管理是軟件项目开发环境管理的核心，如果不做好配置管理工作，经常会导致软件程序开发过程的多代码多版本等繁杂问题出现，这样很容易产生软件程序的冲突和混乱，处理这些问题又需要花费更多时间和精力[1]。
因此，做好软件项目的配置管理工作十分重要。
1 配置管理介绍配置管理的目的是利用配置标识、配置控制、配置状态记实和配置审核建立和维护配置项的工作产品的完整性。
配置管理主要管理软件项目开发过程中产生的各配置项，维护配置项版本的完整性及可追踪性，不仅是各配置项的管理，更是对软件项目过程中各任务的管理，因此，配置管理活动管控的是整个软件系统的形成过程。
在软件工程化管理过程中，配置管理的主要任务包括：建立软件配置管理计划、管理并标识软件各配置库中的配置项和基线、控制对软件配置项和基线的更改、建立和发布基线、记录配置项的状态和配置管理活动，生成并报告各阶段配置管理的工作报告。
配置管理计划3篇
配置管理计划第一篇：配置管理计划的概述配置管理计划是指规定产品、服务或系统在其生命周期中的配置管理活动，以确保其可靠性、安全性和正确性。
在软件开发过程中，配置管理计划是关键的组成部分，它能确保软件的开发过程有条不紊，并防止不必要的错误和资源浪费。
本文将提供一个配置管理计划的概述，以帮助读者了解这一概念。
本文将首先介绍配置管理计划的基本概念和主要目标。
其次，我们将详细讨论配置管理计划的组成要素，并提供一些配置管理计划编制的最佳实践。
配置管理计划的主要目标是确保软件开发过程中的稳定性和可靠性。
这需要实施一系列配置管理措施，使得每个版本都能得到适当的控制和管理。
配置管理计划旨在解决几个关键问题，包括如何管理软件组件和版本控制，如何制定正确的工作流程和如何保证软件质量。
一个好的配置管理计划应该包含以下组成部分：版本控制计划、质量管理计划、变更管理计划、文档管理计划和发布管理计划。
每个组成部分都有其特定的作用，这可以大大提高软件的质量和稳定性。
在编制配置管理计划时，需要考虑以下最佳实践：1. 首先我们需要明确配置管理的目标和作用，以及它在软件开发过程中的作用。
2. 需要为每个组成部分编写清晰的配置管理计划，明确每个计划的目标和实现方法。
3. 需要设立一个合适的配置管理团队，并指定合适的人员负责不同的计划。
4. 需要采用适当的工具和技术，以实现版本控制、文档管理和变更管理。
5. 需要进行培训和沟通，以确保每个团队成员都了解和支持配置管理计划。
总之，配置管理计划是一个帮助软件开发人员提高软件质量、确保软件可靠性的重要工具。
每个组成部分都需要明确的计划，以确保软件开发过程中的正确性和规范性。
第二篇：配置管理计划组成要素分析配置管理计划是软件开发过程中的一个重要组成部分。
在编制配置管理计划时，需要包含多个组成要素，以确保软件开发过程的流程正确、真实、有效和规范。
本文将提供一个配置管理计划组成要素分析，以帮助软件开发人员更好地了解配置管理计划。
测试人员如何进行软件配置管理
测试人员如何进行软件配置管理软件配置管理（Software Configuration Management）是软件开发中的重要环节，它涉及到对软件产品的版本控制、变更管理、构建和发布等方面。
而在软件配置管理过程中，测试人员需要扮演关键的角色。
本文将探讨测试人员如何进行软件配置管理的相关内容。
一、理解软件配置管理在开始讨论测试人员如何进行软件配置管理之前，首先需要了解软件配置管理的概念和重要性。
软件配置管理是指在软件开发和维护过程中，对软件配置项进行有效地识别、控制、评审和记录，以确保产品的正确性、一致性和可追踪性等特性得到满足的过程。
在软件配置管理中，其中一个关键任务是管理软件配置项（Software Configuration Item，SCI）和其对应的版本。
SCI可以是源代码、可执行文件、数据库、文档等。
通过配置管理系统，可以追踪、控制和回溯软件配置项的变更和演化。
二、测试人员在配置管理中的职责1. 配置项识别和定义测试人员在软件配置管理中的第一个职责是参与配置项的识别和定义。
他们需要与开发人员、需求分析人员等合作，明确软件配置项的范围和内容。
一旦确定了需要配置管理的软件配置项，测试人员应该对其进行记录和描述，以便后续的版本控制和变更管理。
2. 版本控制测试人员需要参与版本控制的过程。
他们应该定期检查配置管理系统，了解当前可用的软件版本，并确保测试活动使用的是正确的版本。
在测试过程中，如果发现了软件配置项的问题，测试人员应该及时报告给开发人员，并确保问题能够被正确记录和追踪。
3. 变更管理在软件开发过程中，变更是不可避免的。
测试人员需要参与变更管理过程，包括变更请求的评审、对测试活动的影响分析等。
他们应该与开发和质量保证团队密切合作，确保变更能够正确地应用到软件配置项中，并进行相应的验证和测试。
4. 构建和发布测试人员还需要参与软件构建和发布过程。
他们应该检查构建过程是否正确地整合了最新的软件配置项，并确保构建的结果符合预期。
软件项目实施保障措施之配置管理与版本控制
软件项目实施保障措施之配置管理与版本控制一、引言在软件项目的实施过程中，配置管理和版本控制是非常重要的保障措施。
配置管理旨在确保软件开发过程中的配置项的可控性和可追溯性，而版本控制则用于管理软件不同版本之间的变更和迭代。
本文将探讨软件项目实施中的配置管理和版本控制，并提出相应的保障措施。
二、配置管理配置管理是指对软件开发过程中涉及的配置项进行有效的控制和追踪管理的过程。
配置项可以包括源代码、可执行文件、文档等。
配置管理的目标是实现可重复和可控制的软件开发流程，确保软件的正确性和可维护性。
1. 配置项标识每个配置项都应该有一个唯一的标识符，以方便跟踪和管理。
可以使用版本号、日期时间等作为标识符，确保每个配置项都能够进行正确的追溯。
2. 配置项控制对于每个配置项，应制定相应的控制策略，包括配置项的创建、修改和删除等操作。
只有经过授权的人员才能进行相关操作，并且需要进行相应的记录和审查，以确保配置项的安全和可追溯性。
3. 配置项变更管理在软件开发过程中，可能会出现配置项的变更需求。
为了确保变更的有效性和可控性，需要建立一个变更管理机制。
变更管理包括变更申请的提交与审批、变更实施的记录和验证等环节，确保变更的合理性和影响分析。
三、版本控制版本控制是对软件不同版本之间进行管理和控制的过程。
通过版本控制，可以对软件的变更进行追踪和管理，并确保团队成员之间的协同开发效率。
1. 版本控制系统选择根据项目的需求和团队规模，选择适合的版本控制系统。
常用的版本控制系统包括Git、SVN等。
在选择版本控制系统时，需要考虑其功能、易用性和扩展性等方面的因素。
2. 分支管理通过分支管理，可以将软件开发过程中的不同功能点或任务进行隔离。
每个功能点或任务都可以独立创建一个分支，并在该分支上进行开发和测试。
最后通过合并分支的方式将各个功能点或任务整合到主分支中。
3. 变更冲突解决在多人协同开发的过程中，可能会出现多个人同时修改同一个文件或代码块的情况，导致冲突。
软件质量管理方法
软件质量管理方法软件质量管理是确保软件产品满足客户需求并具有高质量的关键过程。
以下是一些常见的软件质量管理方法：1. 质量保证（QA）：通过在软件开发过程中实施一系列质量保证活动，确保软件质量。
这些活动包括代码审查、测试、缺陷跟踪和管理等。
2. 敏捷开发：一种灵活的软件开发方法，强调对变化的适应性和快速交付价值。
通过敏捷开发，团队可以更好地响应需求变化，提高软件质量。
3. 持续集成（CI）/ 持续部署（CD）：CI/CD是自动化的软件开发和部署流程，通过定期集成和部署代码，减少错误并提高软件质量。
4. 缺陷预防：通过分析历史问题和数据，识别和预防缺陷。
常见的缺陷预防方法包括因果图、故障模式和效果分析等。
5. 静态代码分析：通过检查源代码中的语法错误、风格问题和潜在缺陷，提高软件质量。
静态代码分析工具可以自动执行这些检查。
6. 动态分析：通过在运行时检查程序的行为，发现潜在的错误和缺陷。
动态分析方法包括测试、压力测试和监视等。
7. 需求管理：通过明确记录和管理客户需求，确保软件满足客户期望。
需求管理过程包括需求收集、分析和验证等。
8. 配置管理：通过控制软件产品的配置信息，确保软件的一致性和可追溯性。
配置管理过程包括配置项标识、版本控制和变更控制等。
9. 评审和审计：通过内部或外部的评审和审计，确保软件质量管理体系的有效性。
评审和审计过程包括代码审查、过程审计和产品审核等。
10. 持续改进：通过不断改进软件开发过程和方法，提高软件质量。
持续改进方法包括敏捷改进、六西格玛和精益开发等。
以上方法不是孤立的，它们可以结合使用以实现更有效的软件质量管理。
同时，实施软件质量管理需要领导层的支持和团队的参与，以确保取得良好的成果。
简述软件配置管理任务与过程
简述软件配置管理任务与过程
软件配置管理任务是确保软件产品被正确地构建、交付和维护，包括以下几个方面：
1. 版本控制：确定哪些是已发布的、测试的和开发的软件版本，并确保所有版本的完整性和安全性。
2. 变更管理：跟踪和管理对软件的变更，确保这些变更被正式记录、评审和实施。
3. 发布管理：管理软件的发布过程，包括确定在哪些环境中进行测试、签署的安装包、文档、更新日志等。
4. 组态标识：在软件产品中标识软件“组态项”及其依赖关系。
5. 构建管理：确保软件的构建和编译过程正确完成，确保可重复的构建结果。
6. 缺陷管理：跟踪、管理和解决缺陷和修补程序。
7. 测试环境管理：管理测试和验证软件产品的环境，以确保所有测试环境都处于合适的状态。
软件配置管理过程包括以下步骤：
1. 计划：制定软件配置管理计划，确定配置管理工具和方法，并明确配置管理标准和规范。
2. 构建：通过软件构建和编译工具将源代码转换成可执行的软件。
3. 控制：跟踪软件变更并确保每个版本都受控。
使用版本控制工具来跟踪软件配置项。
4. 发布：生成软件发布包和文档，并确保它们经过验证和授权后才发布。
5. 跟踪：跟踪和管理软件缺陷、问题和修复程序。
6. 报告：生成和记录软件配置管理的相关文档和报告，包括问题报告、版本历史等。
7. 审核：定期审查配置管理计划的有效性和效率，调整计划和过程以最大限度地提高效率和质量。
软件配置管理计划模板
XXXX软件项目配置管理计划XXXX企业有限公司____年___月___日文档信息修改记录目录软件项目配置管理计划 (2)1 引言 (2)1.1 编写目的 (2)1.2 术语定义 (2)1.3 参考资料 (2)2 计划内容 (2)2.1 人员及职责 (2)2.2 软硬件环境计划 (4)2.2.1 项目计划环境 (4)2.2.2 需求分析和设计环境 (4)2.2.3 开发环境 (4)2.2.4 测试环境 (4)2.2.5 配置管理环境 (4)2.3 配置项计划 (4)2.4 配置库计划 (6)2.5 权限计划 (7)2.6 基线计划 (8)2.7 发布计划 (8)2.8 配置库备份计划 (9)软件项目配置管理计划1 引言1.1 编写目的本文档目的在于对本公司项目进行软件配置管理，提高软件质量，降低软件开发成本。
本计划制定了本公司如何进行配置管理活动、活动的计划安排、指派的职责和所要求的资源。
对本公司项目实施软件配置管理活动时，需要参照本计划。
1.2 术语定义1、软件配置管理（SCM）：软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。
2、配置项（CI）：配置项可包括以下几方面：项目(或活动)文档、源代码、可执行代码、度量数据、变更请求(CR)。
项目(或活动)文档即项目(或活动)相关的规范、指南中定义的各个任务的输出和输入；源代码和可执行代码是特殊的文档；度量数据指度量分析定义表中定义的度量以及对应的实际数据。
3、基线（BaseLine）: 用来标识一组配置项的特定版本的集合的标记，以记录工作成果的历史状态，或通过不同的版本组合定义不同特性的工作成果。
1.3 参考资料2 计划内容2.1 人员及职责1、根据《软件项目计划书》中的角色分配，确定CM，CCB（变更控制委员会）成员；2.2 软硬件环境计划2.2.1 项目计划环境软件：MS Office Word、MS Office Excel、MS Office Project2.2.2 需求分析和设计环境软件：MS Office Word、MS Office Visio、Sybase PowerDesigner、Rational Rose2.2.3 开发环境软件：Windows Visual Studio .Net、MyEclipse、JDK、Apache-Tomcat、Apache、Oracle 10g、SQL Server 2003、WebLogic、SQL Server 2005、Websphere2.2.4 测试环境软件：Load Runner2.2.5 配置管理环境1、软件：TortoiseSVN2.3 配置项计划配置管理员标识配置项，标识符的参考格式为：项目编号-配置项类型-配置项序号-配置项版本配置项名称。
配置管理计划
配置管理计划
配置管理计划是一个组织在软件开发或系统维护过程中使用的工具或方法。
它用来管理软件或系统的配置项，以确保它们能在整个开发或维护周期中正确地配置和管理。
配置管理计划旨在确保所有配置项的状态可追踪、可控制和可审核。
以下是一个配置管理计划可以包括的内容：
1. 配置管理目标：明确配置管理的目标，通常是确保软件或系统的稳定性、可靠性和可维护性。
2. 组织结构：定义配置管理团队的组成和责任。
3. 配置管理流程：描述软件或系统的开发或维护过程中的配置管理活动，包括配置项的定义、创建、变更、跟踪和控制等。
4. 配置项识别：确定和命名所有需要配置管理的项，例如源代码、文档、配置文件、数据库等。
5. 配置管理工具：选择和使用适当的配置管理工具，如版本控制系统、问题跟踪系统等。
6. 配置管理计划的更新和审查：规定配置管理计划的更新和审查频率，以确保其与实际情况保持一致。
7. 配置管理报告：定义生成和分发配置管理报告的方式和频率。
8. 变更管理：描述如何管理软件或系统的变更，包括变更请求的提出和评审、变更的实施和验证等。
9. 配置项版本控制：规定如何管理配置项的版本，以确保能够追溯并恢复到特定版本。
10. 配置管理的风险管理：考虑并规划配置管理过程中的风险，并制定相应的应对措施。
配置管理计划应该根据具体项目或组织的需求进行定制，以确保最佳的配置管理实践被采用。
它应该由项目经理、配置管理负责人和相关利益相关者共同制定和审查，并在整个软件开发或系统维护过程中持续更新和改进。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
计算机时代２０１２年第ｌＯ期 ・ ６７ ・ 行为优化提升软件配置管理 张薇 （北京工业大学软件学院，北京１００１２４） 摘要：软件配置管理包括对代码、文档、数据等的管理，其优劣受限于项目成员的实际操作。开发人员对于工作区如 何使用；成员之间的代码是不是可以及时更新与同步；怎样使用分支，如何进行变更合并，才能减少物理空间浪费和事件 延迟。这些问题在实际的项目开发中往往被忽视，亦或团队并没有对成员行为作细节的规范，因而许多软件项目出现了 工期推迟或代码质量不高等问题。为此提出了一系列管理措施，通过优化软件配置管理规范项目各成员的行为，以保证 高效的软件配置管理的实施。 关键词：软件配置管理；工作区；代码；分支与合并；过程及规范 中图分类号：ＴＰ３１ １．５ 文献标志码：Ａ 文章编号：１ ００６—８２２８（２０１ ２）１ ０—６７—０３
Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ ｏｆ ｂｅｈａｖｉｏｒｓ ｏｐｔｉｍｉｚｉｎｇ ａｎｄ ｐｒｏｍｏｔｉｎｇ ｓｏｆｔｗａｒｅ Ｚｈａｎｇ Ｗｅｉ （Ｂｅｉｊｉｎｇ￡，凡 ｅｒｓｉｔｙ ｏｆ Ｔｅｃｈｎｏｌｏｇｙ，Ｓｃｈｏｏｌ ｏｆ Ｓｏｆｔｗａｒｅ ｅｎｇｉｎｅｅｒｉｎｇ，Ｂｅｉｊｉｎｇ １００１２４ Ｃｈｉｎａ） Ａｂｓｔｒａｃｔ：Ｃｏｄｅ，ｄｏｃｕｍｅｎｔａｔｉｏｎ ａｎｄ ｄａｔａ ａｒｅ ｍａｎａｇｅｄ ｂｙ Ｓｏｆｔｗａｒｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ（ＳＣＭ）．Ｉｔｓ ｒｅｓｕｌｔ ｄｅｐｅＭｓ ｏｎ ｂｅｈａｖｉｏｒｓ ｏｆ ｐｒｏｊｅｃｔ ｍｅｍｂｅｒｓ．Ｈｏｗ ｄｅｖｅｌｏｐｅｒｓ ｕｓｅ ｗｏｒｋｓｐａｃｅ，ｗｈｅｔｈｅｒ ｔｈｅ ｕｐｄａｔｉｎｇ ａｎｄ ｓｙｎｃｈｒｏｎｉｚａ６０ｎ ｏｆ ｃｏｄｅ ｌｉｎｅ ｂｅｔｗｅｅｎ ｍｅｍｂｅｒｓ ａｒｅ ｏｎ ｔｉｍｅ， ｈｏｗ ｔｏ ｕｓｅ ｔｈｅ ｂｒａｎｃｈ ａｎｄ ｍｅｒｇｅ ｃｈａｎｇｅｓ ｉｎ ｏｒｄｅｒ ｔｏ ｒｅｄｕｃｅ ｔｈｅ ｗａｓｔｅ ｏｆ ｐｈｙｓｉｃａｌ ｓｐａｃｅ ａｎｄ ｐｒｅｖｅｎｔ ｅｖｅｎｔ ｄｅｌａｙ，ａｌｌ ｏｆ ｔｈｅｓｅ ｑｕｅｓｔｉｏｎｓ ｏｆｔｅｎ ｂｅ ｉｇｎｏｍｄ ｉｎ ｓｏｆｔｗａｒｅ ｐｒｏｊｅｃｔ，ｏｒ ｓｏｍｅｔｉｍｅｓ ｔｈｅ ｔｅａｍ ｄｏｅｓ ｎｏｔ ｒｅｇｕｌａｔｅ ｔｈｅ ｄｅｔａｉｌｓ ｏｆ ｂｅｈａｖｉｏｒｓ．Ｓｏ ｓｏｍｅ ｓｏｆｔｗａｒｅ ｐｒｏｊｅｃｔｓ ｃｏｎｆｒｏｎｔ ｐｒｏｂｌｅｍｓ ｏｆ ｄｕｒａｔｉｏｎ ｄｅｌａｙ ａｎｄ ｌｏｗ ｃｏｄｅ ｑｕａｌｉｔｙ．Ｉｎ ｖｉｅｗ ｏｆ ｔｈｅ ａｂｏｖｅ ｐｒｏｂｌｅｍｓ，ｐｒｏｊｅｃｔ ｔｅａｍ ｓｈｏｕｌｄ ａｌｌｏｃａｔｅ ｍａｎａｇｅｒｓ ｔｏ ｓｕｐｅｒｖｉｓｅ ｅａｃｈ ｓｔａｇｅ ｏｆ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ，ｒｅｓｏｌｖｅ ｃｏｎｆｌｉｃｔｓ，ｃｈｅｃｋ ｂｒａｎｃｈ ｃｏｎｓｏｌｉｄａｔｉｏｎ，ｅｔｃ．Ｍａｎａｇｅｒｓ ｓｈｏｕｌｄ ｒｅｃｏｒｄ ｔｈｅ ｄａｔａ ｏｆ ｐｒｏｂｌｅｍｓ ａｎｄ ｔｈｅ ｅｘｐｅｒｉｅｎｃｅ ｏｆ ｒｅｓｏｌｖｉｎｇ ｐｒｏｂｌｅｍｓ ｉｎ ｏｒｄｅｒ ｔｏ ｆｏｌｌｏｗ ｕｐ．Ｔｈｅ ｐｒｏｊｅｃｔ ｐｒｉｎｃｉｐｌｅ ｓｈｏｕｌｄ ｓｐｅｃｉｆｙ ｂｅｈａｖｉｏｒｓ ｏｆ ｄｅｖｅｌｏｐｅｒｓ ａｎｄ ｔｈｅ ｍｅｍｂｅｒｓ ｏｆ ｔｅａｍ ｓｈｏｕｌｄ ｐｌａｙ ｂｙ ｔｈｅ ｒｕｌｅｓ ｓｏ ｔｈａｔ ｓｏｆｌｗａ￣ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ ｉｓ ｉｍｐｌｅｍｅｎｔｅｄ ｅｆｆｅｃｔｉｖｅｌｙ． Ｋｅｙ ｗｏｒｄｓ：ＳＣＭ；ｗｏｒｋｓｐａｃｅ；ｃｏｄｅ ｌｉｎｅ；ｂｒａｎｃｈ ａｎｄ ｍｅ唱ｅ；ｐｒｏｃｅｓｓ ａｎｄ ｐｒｉｎｃｉｐｌｅ
０引言 软件配置管理（ＳＣＭ，Ｓｏｆｔｗａｒｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅ— ｍｅｎｔ）是软件项目中一个非常重要的活动，存在于整个软件项 目周期当中，管理项目的所有代码、数据、文档等，以保证软件 项目过程的可控，变更历史可追溯。本文从六个基本角度：工 作区、开发线、分支、合并、编译以及过程规范，探讨软件配置管 理优化的方案。希望项目成员能够以优化自己的日常工作为 起点，与团队一起共同提高软件项目的配置管理水平。
１工作区优化 工作区是开发者进行代码开发、测试、变异的特定分配区 域，几乎每种ＳＣＭ系统都存在“工作区”这个概念，它界定了开 发人员的工作领域，避免开发人员之间的工作相互影响。 １．１不共享工作区 为了便于管理，工作区应该遵循分离原则。工作区的共 享，实质上显示了开发人员工作空间的物理条件的共享性，这 样一来，某个开发人员的修改，就会导致共享此工作区的其他 人员工作的混乱。物理空间并非高价之物，不要为了节省磁盘
空间而浪费时间，在软件项目中，分秒必争，时间不可浪费。 １．２禁止工作区外开发 背着ＳＣＭ进行暗地操作，其历史的追踪将成为不可能。 为了开发团队的交流，每个开发者的工作区内容，可以被其他 成员查看，而不允许其他成员修改。如果开发人员在工作区外 部进行开发，其工作不能与团队共享，且修改历史不能被跟踪， 这将没有办法在发生问题时回滚到之前正确的状态，造成工作 的徒劳。 １．３避免由外至内的影响 对于自己工作区内的文件，应该极力避免非意志性的文件 更改。主要是，不受ＳＣＭ系统管理的外部物理空间发生的活 动，引起了ＳＣＭ工作区内的文件的更改。例如，软件的编译行 为，可能会增加ＳＣＭ控制区内文件。为了保证项目受控工作区 域的文件稳定性，应避免工作区外部行为对内部文件的增删改。 １．４同步项目库代码 开发人员ｃｈｅｃｋ—ｉｎ代码时，需先将自己的工作区与版本库 进行同步，在没有冲突的情况下进行本地修改的ｃｈｅｃｋ—ｉｎ，当有 较大冲突时，需要配置管理者对冲突进行手动修正。如果可以
收稿日期：２０１２—８—２７ 作者简介：张薇（１９８８一），女，北京人，硕士，主要研究方向：软件工程，信息服务。 ・ ６８ ・ Ｃｏｍｐｕｔｅｒ Ｅｒａ Ｎｏ．１０ ２０１２ 减少这样的冲突，及时将工作区本地版本与服务器同步，保持 ＳＣＭ管理下的代码最新，可以减少代码最终提交时的尚待解决 的冲突，避免延迟工期。 １．５及时ｃｈｅｃｋ—ｉｎ 当多名开发人员协同开发时，开发告一段落，开发人员需 要通过ｃｈｅｃｋ—ｉｎ代码去告知其他开发者自己的变更，而及时的 ｃｈｅｃｋ—ｉｎ可以保证其他人员能够及时得到库内的新版本，减少 冲突的出现。当然配置管理组，也需要建立支持频繁变更的机 制，避免对代码变更过于复杂保守的评价。变更审查的时问越 久，就会造成越大的项目时间的浪费。 ２代码行为优化 代码在配置管理的过程中会分成不同的版本，不断更新完 善，最后发布。代码的管理是软件项目配置管理的重要工作部分。 ２．１制定代码策略 代码策略指对于代码正确使用的方法、如何审定ｃｈｅｃｋ—ｉｎ 的代码，而确立的规则，这些策略将是代码部分管理的重要手 册。代码变更如何进行书面化描述，怎样进行编译、测试， ｃｈｅｃｋ—ｉｎ后的代码安定性预期值等，都需要在规则中进行明确 规定。没有规则化的代码开发，从软件配置管理的角度而言， 可以说等同于失去可控性。 ２．２设立开发控制责任人 有了代码策略，也不能排除规则不适用或者含糊不清的特 殊情况，为了解决这些特殊情况，开发者可以通过控制人员得 到统一的解决方法。设定开发控制责任者，使其承担特定部分 代码的责任以及规则把握，避免开发者遇到问题时擅自解决， 并将遇到的特殊情况书面化，以便项目组积累经验，为后续开 发奠定基础。 ２．３使用主线开发模式 图１基于主线的开发模型 如图ｌ所示的基于主线的开发模型，可以看到从主线分出 了几条发布线（”ｖｅｒｌ”、”ｖｅｒ２”、”ｖｅｒ３”）与开发线（”ｐｒｏｊＡ”、 ”ｐｒｏｊＢ”、”ｐｒｏｊＣ”）。开发者在主线与开发线上进行开发活动，发 布线用于测试以及ｂｕｇ修正。发布线与开发线上进行的变更， 最终需合并到主线中。主线开发，支持并行开发，大大减少软 件产品在其生存周期成熟之前的管理开销，并且主线模型可以 避免代码冻结，使项目顺利进行。 ３分支优化方案探讨 分支功能是软件配置管理下最容易产生问题的部分。不 同的软件配置管理方案，对分支进行不同方式的支持，或者可 以说，根据不同的规则，分支机能也得到不同程度的活用。 ３．１需用才用 所有分支的变动几乎都会引起项目人员的工作量的增加 （编译工作、代码的变更传达，分支合并等）。增加分支同时， 需要充分意识到对项目工作量的增加，减少不必要的分支的 增加，并尽可能避免在分支上再建分支，以降低对项目进度的 影响。 ３．２传递靠分支不靠备份 当开发线全部或者一部分需要转交时，不要进行复制传 递。复制传递需要将一条生产线上的全部文件都复制到新位 置，作为新的文件在新的开发分支上进行使用。由于复制之后 文件的增加，不仅增加了物理空间的负担，同时对于相同的文 件，ＳＣＭ系统仍需要管理这些新分支的“新”实体以及他们的历 史记录，这将增大配置管理的复杂度。 ３．３不同原则不同分支 如果开发人员遵循着不同的检入，检出原则，则应该在不同 分支上进行开发。例如：负责软件发布的小组，要求进行严密 的测试之后才可以进行ｃｈｅｃｋ—ｉｎ；而开发组需要及时同步代码 版本，只要进行简单的测试就可以ｃｈｅｃｋ—ｉｎ。像这样依据完全 不同的工作原则时，分支开发是必须的。 ３．４不到必要时不创建分支 不谈建立分支的物理消耗，为了最小化分支之间变更传递 的复杂性，应将分支建立尽可能向后推延。例如，过早为新功 能建立发布分支，该分支上新功能的测试以及ｂｕｇ修正不得不 同时向主线上合并，这是时间和工作量上的浪费。发布分支建 立前，在开发主线上进行测试与ｂｕｇ修正的话，分支之间传递的 变更信息将会大大减少，可以节省时间与精力。 ３．５以分支缓和冻结 有时，项目需要对代码进行冻结以便进行测试工作，而这 对于开发者而言，在测试完成之前，开发产生的变更无法与项 目代码进行整合。这种情况下，为了使开发人员的工作得以正 常进行，应该在代码冻结之前尽可能早地建立新分支。
４合并优化方案探讨 合并指的是某一分支的变更向目的分支的更新整合操 作。这是我们不得不直面的ＳＣＭ中的一个重要且普遍的问 题，而这并不是一个简单的工作。 ４．１变更合并相似分支 分支时间越长，冲突就越多，合并开销就越大。对于一次 变更，与其与经过较多修改的分支进行合并，不如与变化不大 的分支合并来的容易。例如，主线模型中，应该在发布分支上 进行ｂｕｇ修正等操作，功能稳定后合并到开发主干上。若在主 线上进行ｂｕｇ修正，合并时原本不需要的修改可能也会传给发 布分支，而这些无关变更可能造成开发人员工作混乱。 ４．２勤于合并 要尽量频繁地进行合并。及时合并处于稳定点的分支，让 自己的修改尽快被其他相关开发人员得知，这可以有效地减少 开发成员之间的代码冲突。同时变更的合并，赶早不赶晚，及 早进行合并，以减少延迟合并可能产生的冲突。