软件配置管理

1、什么是软件配置管理？软件配置管理包括哪些方面、内容涉及哪些人员及人员的工作？
答：软件配置管理统一的定义，下面是其中几种定义：
配置管理能够系统地处理变更，从而使得软件系统可以随时保持其完整性。

配置管理又可称为“变更控制”，可以用来评估提出的变更请求，跟踪变更，并保存系统在不同时间的状态。

软件配置管理是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。

配置管理是对工作成果的一种有效保护。

配置管理能够系统地处理变更，从而使得软件系统可以随时保持其完整性。

配置管理又可称为“变更控制”，可以用来评估提出的变更请求，跟踪变更，并保存系统在不同时间的状态。

对软件开发组所建立的软件的修改进行标识、组织和控制的艺术，其目标是减少错误，提高生产力。

标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的发布和变更，记录并报告配置的状态和变更要求，验证配置项的完整性和正确性
作用：在质量体系的诸多支持活动中,配置管理处在支持活动的中心位置,它有机地把其它支持活动结合起来,形成一个整体,相互促进,相互影响,有力地保证了质量体系的实施。

目的：软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性。

主要内容包括：及时地确定软件的配置，系统地控制软件配置的变更,保证整个软件生命周期软件配置的完整性和可追溯性。

包括哪些方面：软件配置管理，贯穿于整个软件生命周期，它为软件研发提供了一套管理
办法和活动原则。

软件配置管理无论是对于软件企业管理人员还是研发人员都着重要的意义。

软件配置管理可以提炼为三个方面的内容。

Version Control-版本控制
Change Control-变更控制
Process Support-过程支持
涉及人员及任务：
•PM:project manager 项目经理
项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。

其具体职责为以下几项：
制定和修改项目的组织结构和配置管理策略；
批准、发布配置管理计划；
决定项目起始基线和开发里程碑；
接受并审阅配置控制委员会的报告。

•CCB:Configuration control board变更控制委员会
负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。

其具体职责为以下几项：
定制开发子系统；
定制访问控制；
制定常用策略；
建立、更改基线的设置，审核变更申请；
根据配置管理员的报告决定相应的对策。

开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。

•CMO:Configuration manage officer 软件配置员
根据配置管理计划执行各项管理任务，定期向CCB提交报告，告，并列席CCB的例会。

其具体职责为以下几项：
软件配置管理工具的日常管理与维护；
提交配置管理计划；
各配置项的管理与维护；
执行版本控制和变更控制方案；
完成配置审计并提交报告；
对开发人员进行相关的培训；
识别软件开发过程中存在的问题并拟就解决方案。

•SIO：项目集成员
系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：集成修改；
构建系统；
完成对版本的日常维护；
建立外部发布版本。

•DEV:开发人员
开发人员的职责就是根据组织内确定的软件配置管理
计划和相关规定，按照软件配置管理工具的使用模型来完成
开发任务。

2、服务端：仓库配置项、基线（变更哪些流程）修改（冲突，实验2）答：配置项：
•将软件项目中需要进行控制的工作产品定义为配置项（SCI）。

•为每一个配置项分配唯一的标志。

•建立配置项间的对应关系。

软件配置管理过程包括7项基本活动（（1）制定配置管理计划（2）识别和标志配置项（3）建立配置管理环境（4）配置项的版本控制（5）基线变更管理（6）配置审核（7）配置状态统计）
配置项分为两类
•基本配置项：软件开发者在项目开发过程中所创建的基本工作单元。

•集成配置项：一个集成配置项是基本配置项或其它集成配置项的集合。

三个基线：
功能基线（Functional Baseline）：功能基线指在系统分析与软件定义阶段结束时，在经过正式评审和批准的系统设计规格说明书中对开发系统的规格说明；或是指在经过项目委托单位和项目承办单位双方签字同意的协议书或合同中，所规定的对开发软件系统的规格说明；或是由下级申请并经上级同意或直接由上级下达的项目任务书中所规定的对开发软件系统的规格说明。

功能基线是最初批准的功能配置标识。

分配基线（Allocated Baseline）：分配基线指在软件需求分析阶段结束时，经过正式评审和批准的软件需求规格说明。

分配基线是最初批准的分配配置标识。

产品基线（Product Baseline）：产品基线指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关软件产品的全部配置项的规格说明。

产品基线是最初批准的产品配置标识。

基线变更：
•变化不可避免，无控制的变化将导致混乱
变更控制的目的是防止配置项被随意修改而导致混乱。

为了提高效
率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本
来就是草稿，本来就是要被不断地修改的当配置项状态为“正式发
布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时，如
果要修改配置项的话，那么按照变更控制规则执行。

•无论何人、何时欲修改配置库中的SCI均应履行正规更动手续
–提出书面申请
–更动控制组审核和评估(必要性/可行性/影响域/资源)
–同意,则授权执行指定修改；结论也可能是不同意或暂缓
基线变更管理过程：（变更请求，变更评估，变更批准（拒绝），变更实现
变更控制的目的是防止配置项被随意修改而导致混乱。

为了提高效率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本来就是草稿，本来就是要被不断地修改的当配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时，如果要修改配置项的话，那么按照变更控制规则执行。

版本冲突解决：
解决冲突有三种选择：A、放弃自己的更新，使用svn revert（回滚），然后提交。

在这种方式下不需要使用svn resolved（解决）B、放弃自己的更新，使用别人的更新。

使用最新获取的版本覆盖目标文件，执行resolved filename并提交(选择文件—右键—解决)。

C、手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。

然后执行res olved filename来解除冲突，最后提交。

解决步骤如下：1、在当前目录下执行“update”（更新）操作2、在冲突的文件上（选中文件--右键菜单—TortoiseSVN—Edit conflicts（解决冲突）），3、如果要使用服务器版本，在Theirs窗口选中差异内容，右键，选择Use this text block（使用这段文本块）。

同理如果要使用本地版本，在协商后，在Mine窗口右键，选择Use this text block（使用这段文本块）。

4、修改完成后，保存kingtuns.txt文件内容。

5、在B用户的冲突目录下，选中文件--右键菜单—TortoiseSVN—Resolved（解决）。

会列出冲突的文件列表，如果确认已经解决，点OK。

6、冲突解决7、提交解决冲突后的文件。

3、软件配置分两个方面：工具和良好的习惯（最佳实践）
“最佳实践”包括：1、标识需要进行存储的工件（Artifact）并保障安全存
储；2、控制并且审计（Audit）对于工件的修改；3、设立并管理基线（Baseline）；4、记录并跟踪变更请求；5、维护稳定、一致的工作空间；6、支持对于工件和控件的并发修改；
7、尽早集成、持续集成；8、保证软件构建的重现能力；9、以控件（Component）为单位实施版本控制；10、使用“活动”（Activity）来组织和整合版本集。

4、基线分支和标签，为什么要有这些东西？
基线：
IEEE 对于基线的定义是：已经通过正式复审和批准的
某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变
简单地说，基线就是项目储存库中每个工件版本在特定时期的一个“快照”。

它提供一个正式标准，随后的工作基于这个标准进行，并且只有经过授权后才能变更这个标准。

建立一个初始基线后，以后每次对它进行的变更都将记录为一个差值，直到建成下一个基线。

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

建立基线有以下几个好处：
(1) 基线为开发工件提供了一个定点和快照。

新项目可以从基线提供的定点之中建立。

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

(3) 可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现被报告的错误。

在开发过程中，需要定期建立基线以确保团队开发人员的工作保持同步，通常，在项目生命周期中的里程碑处定期
建立基线。

分支：
分支的划分
在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立开始就划分成3 个不同的分支，让它们分别。