logo资料库

中南大学软件学院软件配置管理复习重点整理.docx

第1页 / 共50页
第2页 / 共50页
第3页 / 共50页
第4页 / 共50页
第5页 / 共50页
第6页 / 共50页
第7页 / 共50页
第8页 / 共50页
资料共50页,剩余部分请下载后查看
软件配置管理 第 1 章软件配置管理概念与目标 1. 软件配置管理(Software Configuration Management, SCM) (1) 定义(多个):  软件配置管理是指一套管理软件开发和维护过程中所产生的各种中间软件产品 的方法和规则,它是控制软件系统演变的学科。  软件配置管理是一组针对软件产品的追踪和控制活动,它贯穿于项目生命周期 的始终,并代表着软件产品接受各项评审。  软件配置管理是贯穿于整个软件过程中的保护性活动,它被设计用来:(1) 标识 变化;(2) 控制变化;(3) 保证变化被适当的发现;(4) 向其他可能有兴趣的人 员报告变化。 (2) 目标:  软件配置管理的各项工作是有计划进行的。  被选择的项目产品得到识别,控制并且可以被相关人员获取。  已识别出的项目产品的更改得到控制。  使相关组别和个人及时了解软件基准的状态和内容。 (3) 目的:使错误降为最小并最有效地提高生产效率。 2. 最终软件版本产品 最终软件版本产品是文档、程序和数据的集合,是软件生产商交付给客户的软件产品, 是用户能够直接使用的软件产品。 3. 软件配置 软件配置是一个软件产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)和 不同版本的程序、文档及相关数据的集合,或者说是配置项的集合。 4. 软件配置项(Software Configuration Item,SCI)  软件配置是一个集合,该集合中的每一个元素称为该软件产品软件配置中的一个配 置项。  软件配置项是软件配置管理的对象,一个软件配置项是项目中一个特定的、可文档 化的工作产品集。
5. 基线(Baseline) (1) 概念  基线是指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审 而进入正式受控的一种状态。  基线是已经正式通过复审和批准的某规约和产品。  经过正式评审和审计,并被批准后的阶段性软件工作产品,称为软件配置管理 中的一根基线。 (2) 分类  功能基线:  在系统分析和软件定义阶段结束时,经过正式评审和批准的系统设计规格 说明中对被开发软件系统的规格说明;  经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定 的对被开发软件系统的规格说明;  由下级申请及上级同意或直接由上级下达的项目任务书中所规定的对待开 发软件系统的规格说明。  指派基线:又称为分配基线,指在软件需求分析阶段结束时,经过正式评审和 批准的软件需求的规格说明,指派基线是最初批准的指派配置标识。  产品基线:指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关 所开发的软件产品的全部配置项的规格说明,产品基线是最初批准的产品配置 标识。 6. 软件配置控制委员会(Software Configuration Control Board, SCCB,简称 CCB)  负责管理软件配置项变更的组织。  具体责任如下:  评估变更;  批准变更请求;  在生命周期内规范变更申请流程;  对变更进行反馈;  与项目管理层沟通。
第 2 章软件配置管理角色与过程 1. 软件配置管理角色及职责 (1) 项目经理(Project Manager,PM)  项目经理是整个软件研发活动的负责人,他根据软件配置控制委员会的建议批 准配置管理的各项活动并控制它们的进程。  其具体职责为以下几项:  制定和修改项目的组织结构和配置管理策略;  批准、发布配置管理计划;  决定项目起始基线和开发里程碑;  接受并审阅配置控制委员会的报告。 (2) 配置控制委员会(Configuration Control Board,CCB)  负责指导和控制配置管理的各项具体活动的进行,为项目经理的决策提供建议。  其具体职责为以下几项:  定制开发子系统;  定制访问控制;  制定常用策略;  建立、更改基线的设置,审核变更申请;  根据配置管理员的报告决定相应的对策。 (3) 配置管理员(Configuration Management Officer,CMO)  根据配置管理计划执行各项管理任务,定期向 CCB 提交报告并列席 CCB 的例会。  其具体职责包括以下几项:  软件配置管理工具的日常管理与维护;  提交配置管理计划;  各配置项的管理与维护;  执行版本控制和变更控制方案;  完成配置审计并提交报告;  对开发人员进行相关的培训;  识别软件开发过程中存在的问题并拟定解决方案。 (4) 系统集成员(System Integration Officer,SIO)  负责生成和管理项目的内部和外部发布版本。  其具体职责为以下几项:  集成修改;  构建系统;  完成对版本的日常维护;  建立外部发布版本。 (5) 开发人员(Developer,DEV)  根据组织内确定的软件配置管理计划和相关规定,按照软件配置管理工具的使 用模型来完成开发任务。 2. 软件配置管理基本流程
(1) 计划阶段  CCB 根据项目的开发计划确定各个里程碑和开发策略;  CMO 根据 CCB 的规划,制定详细的配置管理计划,交 CCB 审核;  CCB 审核配置管理计划后交项目经理批准,发布实施。 (2) 开发和维护阶段: 在这一阶段中,软件配置管理活动主要分为三个层面:  主要由 CMO 完成的管理和维护工作;  由 SIO 和 DEV 具体执行软件配置管理策略;  变更流程。 核心流程为:  CCB 设定研发活动的初始基线;  CMO 根据软件配置管理规划设立配置库和工作空间,为执行软件配置管理做好 准备;  开发人员按照统一的软件配置管理策略,根据获得的授权的资源进行项目的研 发工作;  SIO 按照项目的进度集成组内开发人员的工作成果,并构建系统,推进版本的演 进;  CCB 根据项目的进展情况,审核各种变更请求,并适时的划定新的基线,保证 开发和维护工作有序的进行。 3. 软件配置管理基本活动
(1) 制定配置管理计划  步骤:  参加项目规划  规划配置管理任务  形成配置管理计划  评审配置计划  配置管理计划主要内容:  配置管理组织及其职责  配置管理工具和配置库的组织结构  配置项标志和基线定义  变更管理流程  配置审核和配置状态统计 (2) 识别和标志配置项 步骤:  将软件项目中需要进行控制的工作产品定义为配置项(SCI)。 配置项分为:  基本配置项:软件开发者在项目开发过程中所创建的基本工作单元。  集成配置项:一个集成配置项是基本配置项或其它集成配置项的集合。  为每一个配置项分配唯一的标志。
注意:配置项标识并不是指程序/文档文件的文件名,而是该程序/文档作为一 个配置项的标识。  建立配置项间的对应关系。 可使用某种模块互联语言(Module Interconnection language, MIL)来描述配置项 之间的关系。 (3) 搭建配置管理环境  配置管理环境是用于进行软件配置管理的系统环境,其中最重要的是配置管理 库,简称配置库。  配置库存储配置项 (SCI)、修改请求、变化记录等,并提供对库中所存储文件的 版本控制。  为不同的开发人员分配不同的访问配置库的权限。  一般需采用配置管理工具来建立配置库。  配置库中文件的更改是受控的。 (4) 配置项的版本控制  当开发人员要使用配置库中的一个文件时,将文件检出到自己的工作目录里, 此时该文件在配置库中被自动锁定,开发人员处理完该文件后,再将文件检入 到配置库中(需有修改权限),一个新的版本号自动与文件相关联,文件解锁。  配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题:  访问控制:保证具有相应权限的人员才能修改配置项。  并行控制:保证不同人员同时对某配置项进行的修改不会互相覆盖。  软件产品不同类型的版本的特性和所包含的配置项应被明确描述,保证可根据 要求将配置项组合生成适用于不同应用环境的正确的软件产品版本。 (5) 基线变更管理  变更请求
 变更评估  变更批准/拒绝 根据评估结果对变更作出决策:  直接实现变更  挂起或延迟变更  拒绝变更  对于批准的变更,要确定其实现进度  立即实现变更  特定的日期实现变更  在软件另外的版本中实现  变更实现 (6) 配置审核  配置管理活动审核:确保所有配置管理活动符合已批准的软件配置管理规程。
 基线审核:审核基线配置项的完整性和一致性,从而保证基线配置项可被正确 地构造。  配置库中是否包含了所有计划纳入的基线?  基线自身的内容是否完整?  编译所有的源代码,检查是否可产生最终软件产品。  检查需求、设计与代码间的一致性。 (7) 配置状态统计  配置管理系统的状态统计和评估  变更请求的数量。  变更管理活动的执行情况  配置管理系统存储量的变化。  配置管理系统在运作中发生异常的次数。  配置状态报告  每次配置的更改被批准或实现时,都会产生一个配置状态报告,通知相关 人员:更改了哪些内容?由谁更改?什么时候更改?更改会产生哪些影 响?  对于大型项目的开发,配置状态报告非常重要,它促进了人员之间的通信。 4. 版本的编号 (1) 数字顺序型版本编号  普通版本编号  产品的版本号由若干数字组成,数字之间用“.”分隔。一种典型的编号策 略如下: x.y.z,x 为主版本号,y 为特征版本号,z 为缺陷修复版本号,如 V3.10.16。  主版本号的增加表示提供给客户的主要产品功能的增强。  特征版本号的增加表示产品新增了一些特征或做了一些重要修改。  缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。  文档编号的具体形式为英文(或中文)名加上该配置项所在的版本号,例 如,详细说明书是一个配置项,它的某一个版本标识为“详细设计说明书 V1.0.1”。  α和β版本编号  在普通版本编号后面增加一个大写字符 A 或者 B 来分别表示α版本或β版 本。例如 1.2.4A 或 1.2.4B。  如果存在多次的α发布和β发布,可在 A 或 B 后面添加一个数字来说明发 布的次数,例如:1.2.5A1,1.3.0B2。  α测试是由公司内部的用户在模拟实际操作环境下进行的测试。  β测试是由软件的多个用户在实际使用环境下进行的测试。 (2) 属性版本编号  把版本的重要属性反映在标识中。可以包括的属性有:客户名、开发语言、开 发状态、硬件平台、生成日期等。例如:J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122(Jit(Just in Time):Java 即时编译技术)  包含的信息丰富,方便了查询和管理,版本间的关系易于保持,但由于太复杂, 一般只用于软件组织内部的管理。 第 3 章软件配置管理核心功能 1. 软件配置管理与 CMM/CMMI
分享到:
收藏