第8章软件配置管理.pptVIP

基于CMMI的软件工程;第八章 软件配置管理;配置管理（CM）;CM（一）;CM（二）;CM（三）;第八章 软件配置管理;配置管理定义;存放配置项的数据库，常用两种形式：按配置项类型分类建库和按任务建库。 按配置项的类型分类建库： 适用于通用的应用软件开发机构。 产品的继承性较强，工具比较统一，对并行开发有一定需求 使用这样的库结构有利于对配置项的统一管理和控制 能提高编译和发布的效率。 这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。;按任务建立相应的配置库 适用于专业软件的研发机构，使用的开发工具种类繁多，开发模式以线性发展为主，没有必要把配置项严格的分类存储，人为增加目录的复杂性。 特别是对于研发性的软件机构来说，还是采用这种设置策略比较灵活。 配置库的日常工作：主要保证配置库的安全性，如：对配置库的定期备份、清除无用的文件和版本、检测并改进配置库的性能等。;在项目开发过程中，配置库可分开发区、受控区和测试区三个区域，其各自存放的内容及存取的规定为： 开发区：开发区存放项目组所遵循的过程标准、参考资料、所有未经批准的配置项、已经批准但未纳入基线的配置项，此区域中的配置项由项目经理负责和控制，项目总结结束后删除。 受控区：受控区存放基线。此区域的配置项由项目经理或CCB评审批准后，由配置管理员从开发区更新而来，此区属配置管理员所有。 测试区：该区仅为临时区，不作详细规定，测试通过后需删除该区。测试内容也可由配置管理员从受控区获取（get latest）到指定的路径进行测试。;配置库使用建议流程图;软件工程师按如下原则使用配置库： 只能访问开发区。 在添加配置项后，按公司版本的约定打标识，给定一个初始版本； 签入/签出不需要更新标识； 当工作产品完成之后，签入后，按公司版本约定打标识； 如果需要再修改，则签出； 修改完成后签入，三级或四级版本号加一，按打上面版本约定打标识 依次类推，直到该配置项完全定稿。;配置管理员按如下原则使用配置库： 拥有配??库的全部权限，建立配置库并分配操作权限； 把评审通过的配置项根据评审后确定的版本，打上版本标识； 根据审计过的版本控制表生成基线，从开发区把配置项移到受控区；之后，锁定该版本的工作产品； 负责配置库的日常维护及备份； 发布时定期或事件驱动从配置库生成配置状态报告。;测试工程师按如下原则使用配置库： 测试工程除了对测试区域及公共区域有权限外，其他区域均无操作权限； 当一个系统/变更测试通过之后，通知配置管理员，由配置管理员根据测试结果对相关配置项打标识。;基线，由一个或若干个通过（正式）评审并得到确认的配置项组成，是项目进入下一个生命周期阶段的出发点（或基准）。 基线是软件文档或源码(或其它产出物)的一个稳定版本，它是进一步开发的基础，只有经过授权后才能变更。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。;建立基线的原因： 重现性：及时重新生成软件系统给定发布版本的能力，重新生成开发环境。 可追踪性：建立项目工作产品之间的前后继承关系，确保设计满足要求、代码满足设计及用正确的代码编译系统。 报告：来源于基线之间内容的比较，有助于调试并生成发布说明。;建立基线的优点： 为开发工作提供了一个定点和快照。 新项目可以从基线提供的定点建立，作为一个单独分支，新项目将与随后对原始项目所进行的变更进行隔离。 各开发人员可以将建有基线的工作产品作为他在隔离的私有工作区中进行更新的基础。 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。;常用的基线： 需求基线（SRS_BL）：在需求分析阶段结束后，《用户需求说明书》、《软件需求规格说明书》经过了评审。 计划基线（PLN_BL）：详细计划经过评审。 设计基线（DESIN_BL）：在概要设计和详细设计阶段结束后，设计阶段工作产品经过了评审。 实现基线（CODE_BL）：代码和集成测试计划、用例、报告等工作产品经过了评审 。 测试基线（TEST_BL）：系统测试计划、用例、报告等工作产品经过了评审。 发布基线（RELEASE_BL）：通过软件系统验收测试与正式的配置审核，产生了作为最终产品交付用户的配置项的集合。;工作空间为开发人员提供独立的工作空间。工作空间是被设计用来防止用户之间的相互干扰。 在企业里，一般对每个人的工作空间可以建立如下约定： 开发人员在项目结束后在本地机器删除所有项目资料； 严格按照开发环境的描述安装相关软件，搭建自已的工作平台； 及时备份半成品，在开始修改配置项之后检查当前配置项状态/版本号； 不随意安装未经过批准的软件。 ;对于大型的软件开发项目，无控制的变更将迅速导致混乱，使整个项目无法顺利进行下去而失败