软件配置管理全解

软件配置管理软件配置管理CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介绍配置管理（CM）目的：通过配置标识、配置控制、配置状态报告和配置审计等活动，建立和维护工作产品的完整性。工作产品包括：提交给客户的产品，指定的内部工作产品，获得的产品、工具，以及被用于构建和描述这些工作产品的其他项。借助于配置管理系统的配置控制、变更管理和配置审计功能，使基线变更和工作产品发布得到监督和控制。CM（一）SG1EstablishBaselines（建立基线），建立已识别工作产品的基线。SP1.1IdentifyConfigurationItems（识别配置项），标识将要置于配置管理之下的配置项、组件和相关的工作产品。SP1.2EstablishaConfigurationManagementSystem（建立配置管理系统），建立和维护配置管理和变更管理系统，控制工作产品的完整性。SP1.3CreateorReleaseBaselines（建立或发布基线），创建或者发布基线，供内部使用或提交给客户。CM（二）SG2TrackandControlChanges（跟踪并控制变更），跟踪和控制配置管理下工作产品的变更。SP2.1TrackChangeRequests（跟踪变更申请），变更申请不只是关于新的或变更的工作产品，还包括工作产品中的错误及缺陷。SP2.2ControlConfigurationItems（控制配置项），主要是控制配置项的变更，一般会形成配置项的修订历史和基线的存档两种工作产品。CM（三）SG3EstablishIntegrity（建立完整性），建立和维护基线的完整性。SP3.1EstablishConfigurationManagementRecords（建立配置管理记录），建立和维护描述配置项的记录。SP3.2PerformConfigurationAudits（实施配置审计），执行配置审计以维护配置基线的完整性。第八章软件配置管理CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介绍配置管理定义配置管理：包含版本控制、工作空间管理、并行开发控制、过程管理、权限管理、变更管理等内容。软件配置管理：是在贯穿整个软件生命周期中建立和维护项目产品的完整性目标：软件配置管理的各项工作是有计划进行的；被选择的项目产品得到识别，控制并且可以被相关人员获取；已识别出的项目产品的更改得到控制；使相关组和个人及时了解软件基准的状态和内容。存放配置项的数据库，常用两种形式：按配置项类型分类建库和按任务建库。按配置项的类型分类建库：适用于通用的应用软件开发机构。产品的继承性较强，工具比较统一，对并行开发有一定需求使用这样的库结构有利于对配置项的统一管理和控制能提高编译和发布的效率。这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。概念——配置库按任务建立相应的配置库适用于专业软件的研发机构，使用的开发工具种类繁多，开发模式以线性发展为主，没有必要把配置项严格的分类存储，人为增加目录的复杂性。特别是对于研发性的软件机构来说，还是采用这种设置策略比较灵活。配置库的日常工作：主要保证配置库的安全性，如：对配置库的定期备份、清除无用的文件和版本、检测并改进配置库的性能等。概念——配置库（续）在项目开发过程中，配置库可分开发区、受控区和测试区三个区域，其各自存放的内容及存取的规定为：开发区：开发区存放项目组所遵循的过程标准、参考资料、所有未经批准的配置项、已经批准但未纳入基线的配置项，此区域中的配置项由项目经理负责和控制，项目总结结束后删除。受控区：受控区存放基线。此区域的配置项由项目经理或CCB评审批准后，由配置管理员从开发区更新而来，此区属配置管理员所有。测试区：该区仅为临时区，不作详细规定，测试通过后需删除该区。测试内容也可由配置管理员从受控区获取（getlatest）到指定的路径进行测试。概念——配置库（续）配置库使用建议流程图开发区：项目经理负责控制、管理开发人员工作站文档或编码完成按配置管理中的标识规则进行操作.根据BUG或配置项变更申请表Checkout进行修改受控区：CM进行管理，项目经理或CCB控制基线（文档类）通过评审放入代码类根据集成计划测试区，可为指定目录可执行程序放入BUG库测试工程师工作站得到进行测试进入集成测试阶段以后，开发工程师每日查看对于BUG进行修改，完成后提交到开发区发现BUG放入配置管理员工作站全部通过验证后产品交付构造工作站对配置项进行标识进行变更控制基线（代码类）通过评审放入软件工程师按如下原则使用配置库：只能访问开发区。在添加配置项后，按公司版本的约定打标识，给定一个初始版本；签入/签出不需要更新标识；当工作产品完成之后，签入后，按公司版本约定打标识；如果需要再修改，则签出；修改完成后签入，三级或四级版本号加一，按打上面版本约定打标识依次类推，直到该配置项完全定稿。配置库建议使用原则配置管理员按如下原则使用配置库：拥有配置库的全部权限，建立配置库并分配操作权限；把评审通过的配置项根据评审后确定的版本，打上版本标识；根据审计过的版本控制表生成基线，从开发区把配置项移到受控区；之后，锁定该版本的工作产品；负责配置库的日常维护及备份；发布时定期或事件驱动从配置库生成配置状态报告。配置库建议使用原则（续）测试工程师按如下原则使用配置库：测试工程除了对测试区域及公共区域有权限外，其他区域均无操作权限；当一个系统/变更测试通过之后，通知配置管理员，由配置管理员根据测试结果对相关配置项打标识。配置库建议使用原则（续）基线，由一个或若干个通过（正式）评审并得到确认的配置项组成，是项目进入下一个生命周期阶段的出发点（或基准）。基线是软件文档或源码(或其它产出物)的一个稳定版本，它是进一步开发的基础，只有经过授权后才能变更。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。概念——基线建立基线的原因：重现性：及时重新生成软件系统给定发布版本的能力，重新生成开发环境。可追踪性：建立项目工作产品之间的前后继承关系，确保设计满足要求、代码满足设计及用正确的代码编译系统。报告：来源于基线之间内容的比较，有助于调试并生成发布说明。概念——基线（续）建立基线的优点：为开发工作提供了一个定点和快照。新项目可以从基线提供的定点建立，作为一个单独分支，新项目将与随后对原始项目所进行的变更进行隔离。各开发人员可以将建有基线的工作产品作为他在隔离的私有工作区中进行更新的基础。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。概念——基线（续）常用的基线：需求基线（SRS_BL）：在需求分析阶段结束后，《用户需求说明书》、《软件需求规格说明书》经过了评审。计划基线（PLN_BL）：详细计划经过评审。设计基线（DESIN_BL）：在概要设计和详细设计阶段结束后，设计阶段工作产品经过了评审。实现基线（CODE_BL）：代码和集成测试计划、用例、报告等工作产品经过了评审。测试基线（TEST_BL）：系统测试计划、用例、报告等工作产品经过了评审。发布基线（RELEASE_BL）：通过软件系统验收测试与正式的配置审核，产生了作为最终产品交付用户的配置项的集合。概念——基线（续）工作空间为开发人员提供独立的工作空间。工作空间是被设计用来防止用户之间的相互干扰。在企业里，一般对每个人的工作空间可以建立如下约定：开发人员在项目结束后在本地机器删除所有项目资料；严格按照开发环境的描述安装相关软件，搭建自已的工作平台；及时备份半成品，在开始修改配置项之后检查当前配置项状态/版本号；不随意安装未经过批准的软件。概念——工作空间对于大型的软件开发项目，无控制的变更将迅速导致混乱，使整个项目无法顺利进行下去而失败。变更控制就是通过结合人为的规程和自动化工具，以提供一个变化控制的机制。变更控制的对象主要指配置库中的各基线配置项变更管理的一般流程是：由开发人员或系统分析人员提出变更需求；由CCB（变更控制委员会）或项目经理审核并决定是否批准；配置管理员根据CCB或项目经理的决定开放相应的权限，并形成记录备案；变更申请人员执行相应的变更。概念——变更控制第八章软件配置管理CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介绍配置管理方针项目组软件配置管理应有专人负责（称配置管理员）；中小型项目，由项目经理或指定专人担任配置管理员，负责项目配置管理。大规模项目，应建立配置管理小组（CM组），在项目经理领导或授权下负责项目配置管理。配置管理贯穿软件生命周期全过程，但分两个阶段：从需求到产品发布的开发阶段，配置管理由项目经理或指定专人负责；发布后进入产品维护阶段，由负责该产品技术支持部门指定的配置管理员负责。在整个开发阶段，各类工作产品（配置项）及其变更是项目配置管理的重点；而开发环境、测试环境和运行环境的描述文档则只作为配置项纳入配置管理，受到控制。在产品维护阶段，配置管理的重点则包括变更控制、版本控制和基线管理。项目启动后就应开始配置管理活动，包括：定义、标识配置项，定义基线，建立配置库和基线库，确定访问权限，控制配置库/基线库的签出（Checkout）和签入（Checkin）。在项目计划阶段，应编写配置管理计划（CM计划），与项目开发计划一起提交评审；在产品发布后进入维护阶段，也应编写CM计划。按评审确认的CM计划建立基线、审计配置库和基线，及时报告配置状态。每一个产品的所有配置项的变更均应得到管理和控制。（每一个项目组的）软件产品最终集成（产品发布基线，或产品发布后的产品维护阶段定期生成的基线），由项目配置管理员负责实施，技术支持的配置管理员负责监督。配置管理方针（续）配置管理流程图输入输出项目任务书编制配置管理计划项目策划阶段配置管理计划评审批准的配置管理计划纳入配置库,执行配置管理YN定期报告配置状态统计和变更情况按计划迭代执行批准的配置管理计划配置基线报告配置项变更状态报告配置审计跟踪项目验收发布技术支持配置管理下游活动代码类配置项（源代码、可执行代码以及相关的数据文件）的划分由项目组结合项目具体情况确定（例如，一个单元或模块的代码作为一个配置项），代码类配置项的命名必须结合软件产品的特征，而版本编号则应符合机构统一规定。开发环境、测试环境和运行环境描述，单独成文，并作为单独的配置项进行管理。文档类配置项，比如：需求类文档、计划类文档、设计类文档、测试用例/方案文档、测试报告、用户手册等。实际执行时项目组应遵照机构标准并结合项目具体情况加以适当裁剪。配置项分类配置项识别的参考标准：可能被两个或两个以上组使用的工作产品；无论是因为错误还是因为需求变更而导致变更的工作产品；工作产品相关依赖，其中一个变更会导致另外一个变更；对项目非常重要的工作产品（环境类文档应当属于这一类）。机构应制定如下配置项标识命名规则：文档类配置项命名规则，文档版本编号规则，代码类配置项命名规则，单元（模块）源代码和执行码版本编号规则。配置项识别及标识编制配置管理计划配置管理计划的形成时间：项目计划初步阶段形成草稿，项目计划细化阶段定稿，并与项目开发计划一起评审。根据《机构标准软件过程》中的列表，识别本项目中的配置项，并作为配置管理计划的一部分。在项目经理的指导下，配置管理员完成配置管理计划。明确各类基线包含的工作产品及建立的时间、标识等。需求基线（SRS_BL）:在软件需求规格说明书批准时建立；计划基线（PLN_BL）:在项目计划批准时建立；设计基线（DESIN_BL）:在概要设计、详细设计和数据库设计批准时建立；编码基线（CODE_BL）:在单元测试通过时为集成测试建立