软件工程Chapter10.pptVIP

第二部分 软件项目管理第十章 软件配置管理 华南师范大学 教育信息技术学院 郑云翔 提纲 简介 软件配置管理 软件配置管理工具 简介 变更不可避免，变更增加了混淆程度(如：变更没有记录、没有及时通知) 变更的表现：客户希望修改需求，开发者希望修改技术方法，管理者希望修改项目管理方法 简介 变更的基本原因： 新的商业和市场条件，引起产品需求和业务规则的变更 新的客户需求要求修改某些功能或服务 企业改组或增加/减少规模 预算或进度限制，导致系统或产品的重新定义 随着项目进展，人员知道的信息就是变更的推动力 简介 大多数变更是合理的 软件配置管理(SCM)：标识、组织和控制正在开发的软件的修改的技术，贯穿于整个开发过程 软件配置管理目的：协调软件开发，将混淆减小到最低程度，提高生产力 软件配置管理活动包括：标识变更、控制变更、保证变更被恰当地实施、报告变更给有关人员 简介 软件配置管理与软件维护不同： 配置管理是软件项目开始实施时就开始，且着眼于控制、管理软件修改 软件维护发生在软件交付给客户并投入运行以后，着眼于软件本身的修改 简介——软件配置项和基线 软件配置项(SCI)：所有在软件过程中产生的信息，包括：计算机程序(源代码及可执行程序)、文档(针对技术开发者和用户)、数据(程序里面和程序外部的)、以及开发和运行环境所需的支撑软件和相应文档，实际上就是软件工程的产品(工件, artifacts) 软件配置项的变更在任何时候都可以发生，且会在整个软件生存周期中持续 简介——软件配置项和基线 软件配置项的分类、特征和举例 简介——软件配置项和基线 基线(Baseline)： 不能轻易改变的底线 帮助在不严格阻碍合理变更的基础上控制变更 软件配置项变成基线前，变更可迅速地、非正式进行；一旦基线已经建立，如果要变更，则必须经过正式的规程和手续来评估和验证，才能执行变更 IEEE定义：已经通过正式评审和批准的规约或产品，可作为进一步开发的基础，并且只能通过正式的变更控制规程才能改变 简介——软件配置项和基线 基线可看做软件开发的里程碑，其标志是有一个或多个软件配置项的交付，且这些配置项已经经过正式技术复审而获得认可 基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果 简介——软件配置项和基线 最常见的基线：系统规约、软件需求、设计规约、源代码、测试计划、测试用例、可运行系统 简介——项目数据库 一旦一个SCI成为基线，就把它存放到项目数据库中 当软件组织成员想要对基线SCI进行修改时，把它从项目数据库中复制到该工程师的专用工作区中 例如，把一个名为B的SCI从项目数据库复制到工程师的专用工作区中。工程师在B(B的副本)上完成要求的变更，再用B来更新B 提纲 简介 软件配置管理 软件配置管理工具 软件配置管理 涉及： 如何标识和管理程序/文档的多个现存版本？ 如何在软件发布给用户之前和之后控制变更？ 谁负责审批变更并确定其优先级？ 如何保证变更已经适当的在执行？ 采用什么机制通知有关人员已经发生了变更？ 基本任务：标识、版本控制、变更控制、配置审计和报告 软件配置管理 配置对象标识： 两类配置对象：基本对象、聚合对象 每个配置对象必须独立命名，具有一个唯一标识的名字、描述、资源表和“实现”，其中： 描述是一个数据项的列表，它们给出了该对象的类型(文档、数据或程序)、项目标识符、变更或版本信息 资源是对象提供的处理、引用或需要的实体 实现是一个指针，指向聚合的基本对象，对于基本对象则指向其本身 软件配置管理 版本控制： 赋予每个版本版本号和特征表 完整版本是由一组SCI(源代码、文档、数据)组成的 能通过对适当版本的选择来制定可选的软件系统配置 实体、版本(Version)、变体(用Release表示)及其关系 软件配置管理 各个结点都是聚合对象，是一个完全的软件版本 每一版本都是SCI(源代码、文档、数据)的一个收集，且各个版本都可能由不同的变体(变种)组成 例如，一个简单的程序版本由1、2、3、4和5等部件组成： 部件4在软件使用彩色显示器时使用 部件5在软件使用单色显示器时使用 软件配置管理 版本管理： 将开发组的档案集中地存放在服务器上，经系统管理员授权给各个用户 用户通过登入(check in)和检出(check out)的方式访问服务器上的文件，未经授权的用户无法访问服务器上的文件 软件配置管理 变更控制： 代码的极小混乱可能带来产品的大故障，代码的极小修改也可能修复大故障 变更控制不宜太频繁或太松散，需平衡 变更控制机制：见P161，部分步骤可省略 在软件配置项变成基线以前不需要进行这样的变更控制 软件配置管理 配置审计： 在工程变化指令中说明的变化已经完成了吗？加入了任意附加的修改吗？ 是否已经进行了正式的技