logo资料库

软件配置管理(刘伟 PPT 精简版).doc

发布时间：2022-06-08 发布人：admin 分类：说明书 资料大小：0.24M 资料格式：doc 举报 版权申诉
第1页 / 共12页
第2页 / 共12页
第3页 / 共12页
第4页 / 共12页
第5页 / 共12页
第6页 / 共12页
第7页 / 共12页
第8页 / 共12页
资料共12页，剩余部分请下载后查看
    第一章 1，软件配置管理用于控制变化 2，软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的 各种中间软件产品的方法和规则，它是控制软件系统演变的学科。 3，软件配置管理是一种标识、组织和控制修改的技术，软件配置管理应用于整个软件工程过程 4，SCM 活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更 5，从某种角度讲，SCM 的目的是使错误降为最小并最有效地提高生产效率。 6，软件配置管理定义： 软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计用来： (1) 标识变化；(2) 控制变化；(3) 保证变化被适当的发现；(4) 向其他可能有兴趣的人员报告变化 7，配置管理是否有成效取决于三个要素：人、规范、工具。 8，软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程 序、文档及相关数据的集合，或者说是配置项的集合 9，软件配置是一个集合，该集合中的每一个元素称为该软件产品软件配置中的一个配置项（Software Configuration Item，SCI）。 10，常见的软件配置项：需求规格说明书、设计规格说明书、源代码、测试计划、测试用例、用户手册等 11，基线(Baseline)是指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受 控的一种状态。基线是软件生命周期中各开发阶段的一个特定点，它的作用是把开发各阶段工作的划分更 加明确化，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果 12，基线是已经正式通过复审和批准的某规约和产品，它因此可作为进一步开发的基础，并且只能通过正 式的变化控制过程来改变。基线通常标志开发过程一个阶段的结束（里程碑）。 13，里程碑(Milestone)是检查点 (Check Point)，检查点不一定是里程碑，因为检查点还可以是时间、计划 和事件 14，功能基线：所规定的对待开发软件系统的规格说明 15，指派基线：又称为分配基线，指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格 说明，指派基线是最初批准的指派配置标识。 16，产品基线：指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全 部配置项的规格说明，产品基线是最初批准的产品配置标识 17，软件配置控制委员会(Software Configuration Control Board, SCCB)负责管理软件配置项变更的组织。 具体责任如下： 评估变更；批准变更请求；在生命周期内规范变更申请流程；对变更进行反馈；与项目管理层沟通 18，软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括：  目标 1: 软件配置管理的各项工作是有计划进行的。  目标 2: 被选择的项目产品得到识别，控制并且可以被相关人员获取。  目标 3: 已识别出的项目产品的更改得到控制。  目标 4: 使相关组别和个人及时了解软件基准的状态和内容。 第二章 1，软件配置管理角色 PM: 项目经理；CCB: 配置控制委员会；CMO: 配置管理员；SIO: 系统集成员；DEV: 开发人员 2，项目经理（Project Manager，PM） 根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。 职责：制定和修改项目的组织结构和配置管理策略；批准、发布配置管理计划； 决定项目起始基线和开发里程碑；接受并审阅配置控制委员会的报告。
    配置控制委员会（Configuration Control Board，CCB） 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。 职责：定制开发子系统；定制访问控制；制定常用策略；建立、更改基线的设置，审核变更申请；根据配 置管理员的报告决定相应的对策。 配置管理员（Configuration Management Officer，CMO） 根据配置管理计划执行各项管理任务，定期向 CCB 提交报告并列席 CCB 的例会。 职责：软件配置管理工具的日常管理与维护；提交配置管理计划；各配置项的管理与维护；执行版本控制 和变更控制方案；完成配置审计并提交报告；对开发人员进行相关的培训；识别软件开发过程中存在的问 题并拟定解决方案。 系统集成员（System Integration Officer，SIO） 系统集成员负责生成和管理项目的内部和外部发布版本。 职责：集成修改；构建系统；完成对版本的日常维护；建立外部发布版本。 开发人员（Developer，DEV） 开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型 来完成开发任务。 3
    4，软件配置管理过程包括 7 项基本活动： (1) 制定配置管理计划；(2) 识别和标志配置项；(3) 搭建配置管理环境；(4) 配置项的版本 控制；(5) 基线变更管理；(6) 配置审核；(7) 配置状态统计 5，制定配置管理计划 参加项目 规划配置 形成配置 规划 管理任务 管理计划 评审配置 计划  配置管理计划的主要内容： 配置管理组织及其职责；配置管理工具和配置库的组织结构；配置项标志和基线定义； 变更管理流程；配置审核和配置状态统计 6，识别和标志配置项： （1）为每一个配置项分配唯一的标志；建立配置项间的对应关系 （2）两类配置项：  基本配置项：软件开发者在项目开发过程中所创建的基本工作单元。  集成配置项：一个集成配置项是基本配置项或其它集成配置项的集合。 7，搭建配置管理环境 配置管理环境是用于进行软件配置管理的系统环境，其中最重要的是配置管理库，简称配置库 配置库存储配置项 (SCI)、修改请求、变化记录等，并提供对库中所存储文件的版本控制 一般需采用配置管理工具来建立配置库。 8，配置项的版本控制
    Check in 配置库 Check out 新版本  配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题：  访问控制：保证具有相应权限的人员才能修改配置项。  并行控制：保证不同人员同时对某配置项进行的修改不会互相覆盖。  对配置项的修改（不同版本间的差别）应被记录下来。 更动者（姓名及其身份）；更动日期和时间；被更动 SCI（名及其版本号）； 更动内容及其位置；更动原因；受此更动影响的诸 SCI 名表。  软件产品版本编号方法  数字顺序型版本编号 普通版本编号 α和β版本编号  x.y.z，x 为主版本号，y 为特征版本号，z 为缺陷修复版本号，如 V3.10.16。  主版本号的增加表示提供给客户的主要产品功能的增强。  特征版本号的增加表示产品新增了一些特征或做了一些重要修改。  缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。  在普通版本编号后面增加一个大写字符 A 或者 B 来分别表示α版本或β版本。 例如 1.2.4A 或 1.2.4B。  如果存在多次的α发布和β发布，可在 A 或 B 后面添加一个数字来说明发布的 次数，例如：1.2.5A1，1.3.0B2。 α测试是由公司内部的用户在模拟实际操作环境下进行的测试。 β测试是由软件的多个用户在实际使用环境下进行的测试。  属性版本编号： 把版本的重要属性反映在标识中。可以包括的属性有：客户名、开发语言、开发状态、硬件平 台、生成日期等。例如： J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122  包含的信息丰富，方便了查询和管理，版本间的关系易于保持，但由于太复杂，一般只用于 软件组织内部的管理 9，基线变更管理 变更请求 变更评估 变更批准 变更实现 /拒绝
     变更批准或拒绝 根据评估结果对变更作出决策： 直接实现变更；挂起或延迟变更；拒绝变更 对于批准的变更，要确定其实现进度： 立即实现变更；在特定的日期实现变更；在软件另外的版本中实现  变更实现 检出(check out)基线 对基线进行变更 测试和验证 检入(check in)基线 10，配置审核 配置管理活动审核：确保所有配置管理活动符合已批准的软件配置管理规程 基线审核：审核基线配置项的完整性和一致性，从而保证基线配置项可被正确地构造。 11，配置状态统计和报告 变更请求的数量。变更管理活动的执行情况。 配置管理系统存储量的变化。配置管理系统和 SCCB 在运作中发生异常的次数 第三章 1，CMM/CMMI 将软件配置管理的活动分为 6 个方面，每个方面又再进行了细分 SCM 过程管理；软件配置标识；软件配置控制；软件配置状态统计；软件配置审计；软件发布管理和交付 2，在 CMM 和 CMMI 中，将配置管理的目的定义为“建立和维护产品的完整性”， 3，配置完整性（对标准的理解）  产品完整性：项目提交的工作成果是“产品集合完整、子产品正确”的  产品集合完整：产品包含的子产品（配置项）是完整的  子产品正确：子产品（配置项）达到了需求要求，满足标准、规程的要求 4，三库管理：三库的概念源自 CMM/CMMI，即开发库、受控库和产品库。配置项在三库之间迁移，一级 比一级的控制更严格。 5，软件开发组日常的工作在开发库中开展，当工作达到里程碑时，再迁移到受控库，在受控库中经过更严 格的测试后，再上升到产品库，最后发布。 6，在实践中，三库常常被实现为物理上的三库，而不是通过逻辑的方式来实现，三库物理隔离带来的最大 问题是配置项失去了历史可追溯性 7，实现三库的指导思想应该是逻辑上独立，物理上在一起，通过权限与流程的控制来实现配置项在不同库 之间的流转，以及相应角色的人员对相应库的访问。 8， CMM2 在配置管理方面主要针对于实现部分;CMM3 将配置管理扩展到需求、规格说明、设计和工具
    9， SCM 意义： 记录软件产品的演化过程； 确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置； 最终保证软件产品的完整性、一致性、追朔性、可控性;。 10，每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软 件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程 11，建立基线的好处：重现性；可追踪性；版本隔离。 基线管理的步骤： (1) 在开发前确定基线的“配置”；(2) 基线批准前，根据“配置”检查配置项是否齐备； (3) 对各个配置项，确认其版本的正确性；(4) 对每个配置项建立基线标志； (5) 基线变更管理；(6) 基线的各类报告和审计信息。 12，变更管理的流程： （获得）提出变更请求；由 CCB 审核并决定是否批准； 为（被接受）修改请求分配人员，提取 SCI，进行修改； 提交修改后的 SCI，并测试（或者评审）；重建软件的适当版本； 复审（审计）所有 SCI 的变化；发布新版本。 ---可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》 13，配置库管理 (1)设置配置库（即文件夹设置）和设置版本的分支 (2)为每个配置项从建立开始就划分成 3 个不同的分支：私有分支、集成分支、公共（主干）分支 私有分支（开发人员的私有开发空间）：开发人员 集成分支（开发团队的公共空间）：由系统集成员及相关指定人员负责：所有涉及多人协调的开发工作（如 集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读 权限。 公共（主干）分支（整个软件开发组织的公共空间）:系统集成员:各个开发小组在现阶段的任务完成后， 将可以发布的版本归并到该分支上,对组织内的全体软件人员开放只读权限 上面定义的 3 类工作空间（分支）由配置管理员统一管理 (3)按配置项类型分类建库和按任务建库。 (4)配置库的日常工作：对配置库的定期备份；清除无用的文件和版本；检测并改进配置库的性能等 14, 配置审计：主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现 记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地 方。 （Who、When、Why、What）  同时配置审计工作该应当说明如下信息： (1) 变更要求被完成，并且对附加的修改已经执行了 (2) 采用了正确的正式验证手段 (3) 遵循了标准的要求 (4) 变更的 4W 信息被完整记录，并和相关配置项关联  配置审计有两种:  主要是检查版本是否正确一致。(1) 配置项是否齐备；(2) 版本是否齐全，由非配置管理人员来进行。  PCA (Physics Configuration Audit)-----非配置管理人员 FCA (Function Configuration Audit) -----CMO 检查配置项是否完整，各种过程文档是否齐备、正确、与需求是否一致，归结为两点，即完全和齐备。
    15，配置审计  When：软件交付或 release 时；每个阶段结束时；对于维护性项目，周期性地进行  Who：非本项目组成员；其他项目中的配置控制者；内部审计者；SCM 小组  配置审计步骤（How-审计流程）  (1) 由项目经理决定何时进行配置审计工作（识别配置审计的时间[PM]） (2) 质量保证组或项目组的配置管理组制定该项目的配置审计人员（指派审计者[QA/Audit Group]） (3) 项目经理和配置审计员决定审计范围（定义审计范围[PM&Auditors]） (4) 配置审计员准备配置审计检查单（准备配置审计 Checklist[Auditor]） (5) 配置审计员安排时间审计文档和记录，审计活动可能涉及到：项目范围，配置项的入库(check in) 及出库(check out)，评审记录，配置项的变更历史，测试记录，文件的命名，变更请求和版本的编号等       （通过评审（Review）、文档记录进行审计[Auditor]）  (6) 配置审计员在审计中发现不一致现象，并作记录（识别不符合项[Auditor]） (7) 由项目经理负责消除不一致现象（关闭不符合项[PM]） (8) 配置审计员验证所有发现的不一致现象确已得到解决（验证[Auditor]） 16，配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况 应该是定期进行，并尽量通过 CASE 工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。 应着重反映当前基线配置项的状态，以作为对开发进度报告的参照 17，软件配置管理最佳实践： 统一标识配置项并存入安全的配置管理系统；控制和审计配置项的变更；合理组织配置项； 在项目的里程碑建立相应的基线；记录和跟踪变更请求；过程驱动的软件配置管理； 维护稳定而一致的工作空间；支持并行开发；尽早和持续集成； 确保有能力重现软件的构建过程；把握好工具、流程和人员三者之间的关系；善用模式和反模式； 18，模式可以指导我们如何成功应用前人的实践，避免犯前人犯过的错误，提高 SCM 的实施成功率。 反模式是指那些在特定情况下不应该采取的策略和方式。 第 4 章 1，软件配置管理计划： 人员及职责；配置管理软硬件资源；配置项计划；基线计划；配置库备份计划 2，配置库管理报告： 基本信息；项目成员的操作权限；配置项记录；基线记录；配置库备份记录；配置 项交付记录；配置库重要操作日志 3，配置项变更控制报告： 变更申请；审批变更申请；变更配置项；结束变更 4，配置状态报告 (Configuration Status Report)目的：有效记录和报告管理配置所需要的信息，及时、准确 地给出软件配置项的当前状态，供相关人员了解，以加强配置管理工作  内容  各份变更请示概要：变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版 本、变更结束日期  基线库状态：库标识、至某日预计库内配置项数、实际配置项数  发行信息：发行版本、计划发行时间、实际发行日期、说明  备份信息：备份日期、介质、备份存放位置  配置管理工具状态  配置管理培训状态 5，配置审计目的：验证配置项信息与配置标识（需求、标准、流程…）的一致性，4“W” 配置审计报告内容：配置项状态统计；基线库基线统计；变更统计；审计中发现的主要问题
    第 5 章 1，配置管理模式分类： 描述工作区结构的模式； 描述码线结构的模式 2，码线(codeline)--源代码文件与组成某个软件组件的其他人工制品（配置项）随着时间而变更的进展过程。 码线包含沿着一条路径发展的各个配置项的每个版本 3，与码线有关的模式：主线； 活动开发线； 码线策略； 私用版本； 版本线； 版本预备线； 任务分支 4，与工作区有关的模式： 私有工作区；储存库； 私有系统构造； 集成构造； 第三方码线；任务级提； 冒烟测试； 单元测试； 回归测试 5， 主线——问题： 如何使当前活动码线的数目保持在容易管理的水平，避免项目的版本树长得太宽太 密？如何使合并的开销减至最小？ 解决方案：简化分支模型：开发单个产品版本时，在主线上进行开发。分支时，先考虑总体 战略，然后再创建分支 6，分支是组织文件版本和显示版本历史的手段，是隔离变更的强有力机制。 7，主线既要使码线的并发性达到最大，又要使推迟集成可能造成的问题减至最小 8，私有工作区——问题： 如何跟上不断变化的码线并取得进展，而不会为环境变化而分心？  解决方案：以隔离工作的方法控制变更 (Isolate your work to change control) 10，储存库——问题：如何获得填充新工作区的正确组件的正确版本 11， 11，冒烟测试(Smoke Test)：如何知道系统在你变更后仍能工作？ 描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程； 是确定和修复软件缺陷的最经济有效的方法；缺点在于覆盖面很有限。执行者是开发人员或版本编译人员 12，每次构造都必须进行冒烟测试，以显而易见的方式验证应用未被损坏。 13，单元测试（(Unit Test)）：如何测试模块经你变更后是否仍能像预期一样工作？ 14，回归测试（(Regression Test)）：如何确保现有的代码没有因你进行其他改进而变得更糟？ 15，每日构建 (Daily Build) 就是把一个软件项目的所有的最新的代码从配置库中取出，然后从头进行编译、链接和运行。通常由工具 自动完成（构建自动化）。 daily build 的另一个重要功能就是验证软件中各模块关系是否正确，也可称为“每日集成”。 第 9 章 1，版本库（Repository）：按照一定格式存储了所有数据，包括文件和目录 经过授权的客户端可以连接到版本库，读写库中的文件 版本库和普通文件服务器的不同：版本库会记录每一次的更改 2，版本控制系统的核心任务：协作编辑和数据共享 3，拷贝-合并模型假定文件是可以通过上下文合并的。通常情况下，文本文件（例如源代码以及用纯文本， HTML，TXT 等格式保存的文档）因为其内部结构直观可知，容易理解上下文，所以用拷贝-合并方案较 好。而二进制文件（例如用 Microsoft Word 格式说，PDF 等格式保存的文档及图片，声音，可执行文件， 库等）内部结构复杂，且不容易理解更改处的上下文，采用锁定-解锁方案较好 4，Subversion 主要采用拷贝-修改-合并模型，配合锁定-修改-解锁模型管理数据的共享 5，工作拷贝（Working Copy）是本地机器的一个普通的目录，是私有工作区 6，修订版本（Revision）：每当一次提交完成后，版本库的文件系统就进入了一个新的状态，叫做一次修 订（Revision）。在版本库中，最新的一个修订版本称为 HEAD 7，CheckOut：从版本库中取出某个目录的拷贝到本机上某个目录的操作 例：svn co svn://192.168.0.1/svnrepos/skizcorp/trunk -r 1452 会检出 1452 版，如果存在的话；-N：不递归（仅针对顶层目录），否则目录递归（默认，常用） 8，Update：把版本库的修改同步到本地
    分享到：
    赞 收藏

    相关推荐

    资料库

    课程资源

    共收录17145份资料，累计13个分类，关注成员有19位，主要包括：PHP,网络管理,网页制作,Java,.Net,数据库,3G/移动开发,C/C++,游戏开发,嵌入式,讲义,软件测试,专业指导

    热门标签

    PHP 网络管理 网页制作 Java .Net 数据库 3G/移动开发 C/C++ 游戏开发 嵌入式 讲义 软件测试 专业指导

    最新资料