软件配置管理中的三个基线概念

软件配置管理计划(SCMP)

软件配置管理计划(SCMP)说明《软件配置管理计划》(SCMP)说明在项目中如何实现配置管理。

软件配置管理计划的正本格式如下：1引言本章应分成以下几条。

1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。

1.2系统概述本条应简述本文档适用的系统和软件的用途。

它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。

1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。

1.4组织和职责描述软件配置管理(SCM)负责人和软件配置控制委员会(SCCB)的组成以及他们在项目中的职责和权限；说明与项目配置管理相关的人员，如项目经理、部门SCM组长的职责；描述以上人员之间的关系。

为了能够清晰的表述，可选用图表的方式进行说明。

1.5资源描述项目配置管理活动所需的各种资源，包括人员、培训、工具、设备、设施等等。

其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。

2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。

本章还应标识不能通过正常的供货渠道获得的所有文档的来源。

3管理描述负责软件配置管理的机构、任务、职责及其有关的接口控制。

3.1机构描述在各阶段中负责软件配置管理的机构。

描述的内容如下：a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构；b.说明项目和子项目与其他有关项目之间的关系；c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制委员会的相互关系。

3.2任务描述在软件生存周期各阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中(软件开发库、软件受控库或软件产品库)。

3.3职责描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系：a.指出负责各项软件配置管理任务(如配置标识、配置控制、配置状态记录以及配置的评审与检查)的机构的职责；b.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系；c.说明由本计划第3.2条指明的生存周期各阶段的评审、检查和审批过程中的用户职责以及相关的开发和维护活动；d.指出与项目有关的各个机构的代表的软件配置管理职责；e.指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。

技术评审

技术评审在工作中，我们经常可以听到以下的声音：“我们不进行评审，是因为我们项目比较特殊，没有时间……”。

“我们的项目已经进行了测试，不需要再进行评审了”。

“评审都是在走过场，没有效果……”。

业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。

一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。

另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。

Why-为什么要技术评审？测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。

而评审是一种在产品开发过程中尽早发现缺陷的手段。

根据IBM的统计数据显示：大多数企业的产品开发中，2/3的缺陷都是在需求和设计阶段引入的。

因此，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。

缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。

案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。

评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！What-什么是技术评审？测试和技术评审都是有效的质量控制手段，但也有明显的区别。

类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。

配置管理基线包括

配置管理基线包括配置管理基线是软件开发过程中非常重要的一个概念。

它是指在软件开发过程中，建立一个稳定的基准版本，作为开发团队和测试团队的参考点。

配置管理基线可以确保软件开发过程中的版本控制和变更管理，有助于提高软件的质量和可维护性。

配置管理基线的建立需要经过以下几个步骤。

首先，需要明确确定配置项和配置管理文档。

配置项是软件开发过程中需要管理的元素，可以是源代码、测试用例、文档等。

配置管理文档则是记录配置项的属性和变更历史的文档。

其次，需要建立一个版本控制系统。

版本控制系统可以追踪和管理配置项的变更，确保每个配置项都有一个唯一的标识符，并记录每次变更的详细信息。

常用的版本控制系统有Git和SVN等。

然后，需要制定配置管理流程。

配置管理流程是指在软件开发过程中，如何进行配置项的变更、审批和发布等操作。

配置管理流程应该清晰规范，确保每个变更都经过充分的测试和审批。

最后，需要定期建立配置管理基线。

配置管理基线是指在软件开发过程中，选取一个稳定的版本作为基准版本。

建立基线时，需要确保所有的配置项都是可用的，并且经过了充分的测试。

配置管理基线的建立具有以下几个重要的作用。

首先，它可以确保软件开发过程中的版本控制。

通过建立基线，可以追踪和管理软件的变更，确保每个版本都是可追溯的。

其次，配置管理基线有助于提高软件的质量和可维护性。

通过建立基线，可以确保每个配置项都经过了充分的测试和审批，从而减少软件中的缺陷和问题。

此外，配置管理基线还可以提高团队的协作效率。

通过基线，团队成员可以在同一个版本上进行开发和测试，避免了版本不一致的问题。

在实际应用中，配置管理基线可以应用于各个软件开发阶段。

在需求分析阶段，可以通过配置管理基线来追踪和管理需求的变更。

在设计和开发阶段，可以通过基线来管理源代码的版本和变更。

在测试和发布阶段，可以通过基线来管理测试用例和发布版本。

通过配置管理基线，可以确保软件开发过程中的各个阶段都有一个稳定的基准版本，提高了软件的可控性和稳定性。

技术评审

技术评审在工作中，我们经常可以听到以下的声音：“我们不进行评审，是因为我们项目比较特殊，没有时间……”。

“我们的项目已经进行了测试，不需要再进行评审了”。

“评审都是在走过场，没有效果……”。

业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。

一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。

另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。

Why-为什么要技术评审？测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。

而评审是一种在产品开发过程中尽早发现缺陷的手段。

根据IBM的统计数据显示：大多数企业的产品开发中，2/3的缺陷都是在需求和设计阶段引入的。

因此，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。

缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。

案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。

评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！What-什么是技术评审？测试和技术评审都是有效的质量控制手段，但也有明显的区别。

类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。

软件配置管理计划模板

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 配置项计划配置管理员标识配置项，标识符的参考格式为：项目编号-配置项类型-配置项序号-配置项版本配置项名称。

软件配置管理 (2)

2、三种常见基线
——功能基线在系统分析和软件定义阶段结束时，经过正是评审和批准的
系统设计规格说明中对被开发软件系统的规格说明；经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对被开发软件系统的规格说明；由下级申请及上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。
软件配置管理
内容提要
• 软件配置管理的概念 • 软件配置管理计划 • 软件配置标识 • 变更管理 • 版本管理 • 配置审核 • 配置状态报告 • 软件配置管理工具
一、软件配置管理的概念
（一）软件配置项的概念
1、软件配置项：配置管理的对象称为软件配置项。
表1 软件配置项的分类、特征和举例
分类
特征
3、软件配置管理活动
——配置管理活动 ——变更管理和配置控制 ——配置状态说明 ——配置审核 ——接口和子合同方控制
4、软件配置管理进度安排
——软件配置管理重要事件的顺序 ——软件配置管理各项活动间的依赖关系
5、软件配置管理所需的资源
——采用的工具 ——使用的设备 ——所需的培训 ——对其他人员的要求
跟踪变更原因、变更授权以保证重要功能的安全或保密
表明受控项（包括基线）的状态和历史状态报告应包括变更号、最新版本、发行标识、版本号及各种版本比较
包括重要的安全或保密功能的代码和文档应按组织的方针处理、储存、包装和交付
3、软件配置管理与软件开发过程 • 两类不同的变更：
– 开发阶段内部发生的变更： – 开发过程解决不了的变更：
表2《ISO/IEC 12207: 1995信息技术—软件生存周期过程》关于软件配置管理过程的规定
活动
任务

配置管理基线包括

配置管理基线包括配置管理基线是指在软件开发过程中，为了确保软件的质量和稳定性，制定的一套规范和标准，用于管理和控制配置项的变更和版本迭代。

基线是软件开发过程中的一个重要概念，它能够帮助团队成员更好地协作、追踪和控制软件配置的变更。

配置管理基线的目标是确保软件配置的一致性和可追溯性。

首先，配置管理基线定义了软件开发过程中需要遵循的一系列规范和标准，包括代码编写规范、命名规范、目录结构规范等。

这些规范和标准确保了团队成员之间的代码风格一致，便于代码的维护和阅读。

其次，配置管理基线规定了版本控制的策略，包括版本命名规则、版本号规则等，确保每个版本的唯一性和可追溯性。

通过版本控制，可以方便地对软件进行回溯和还原，以及追溯问题的根源。

配置管理基线的核心是配置项管理。

配置项是软件开发过程中的各个部分，包括源代码、文档、测试用例等。

配置项管理包括配置项的识别、控制、追踪和审计等环节。

首先，配置管理基线要求团队成员对配置项进行识别和分类，确保每个配置项都有一个唯一的标识符，并记录在配置项清单中。

其次，配置管理基线要求对配置项进行控制，即规定了配置项的创建、修改和发布的流程和权限。

只有经过授权的人员才能对配置项进行修改和发布，确保修改的合理性和稳定性。

同时，配置管理基线还要求对配置项进行追踪，即记录每个配置项的变更历史和版本信息，方便回溯和还原。

最后，配置管理基线还要求对配置项进行审计，即定期对配置项进行检查和审核，确保其符合规范和标准。

配置管理基线的实施需要借助一些工具和技术。

首先，版本控制工具是配置管理基线的基础工具，常用的版本控制工具有Git、SVN等。

版本控制工具能够帮助团队成员对软件进行版本控制和协作开发，确保每个版本都是可追溯和可还原的。

其次，自动化构建工具是配置管理基线的重要辅助工具，常用的自动化构建工具有Jenkins、Maven等。

自动化构建工具能够帮助团队成员实现代码的自动编译、打包和部署，提高开发效率和质量。

基线和配置项的区别和联系？

在软件开发和项目管理中，基线（Baseline）和配置项（Configuration Item）是两个重要的概念，它们有以下区别和联系：
1. 区别：
- 基线：基线是在软件开发或项目管理过程中标记为重要里程碑的特定版本或状态。

基线通常用于确定在某个时间点上项目或软件的基准状态，并且可以用来评估后续的变化和进展。

基线可以是软件的版本、需求文档的版本、设计文档的版本，或者项目计划的版本等。

- 配置项：配置项是项目或软件中被管理和控制的所有可识别、可独立变更、可审查和可追溯的实体或工件。

配置项可以是文档、源代码、测试用例、执行脚本、数据库表结构等。

每个配置项都被分配唯一的标识符，以便在项目或软件的整个生命周期中进行跟踪和管理。

2. 联系：
- 基线与配置项的关系：基线是由一个或多个配置项组成的，它是在特定时间点上对相关配置项进行版本控制，并认定为可追溯和可回溯的里程碑状态。

换句话说，配置项是构成基线的具体实体或工件。

- 配置管理：基线和配置项都是配置管理的重要概念和实践。

配置管理是一种跟踪、控制和记录项目或软件中配置项的变更和版本的管理过程。

配置管理的目标是确保各个配置项的一致性、可追溯性和可审查性，在不同阶段和团队之间提供准确的基线信息。

总的来说，基线是用于标记项目或软件的里程碑状态的特定版本或状态，而配置项是项目或软件中被管理和控制的所有实体或工件。

配置项构成基线，而配置管理则用于跟踪和管理配置项的变更和版本。

通过对基线和配置项进行有效的管理，可以提高软件开发和项目管理的质量、可控性和可追溯性。