Ch3配置和变更管理-新22课件版.ppt

软件质量保证和管理 - Ch.3 配置与变更管理 第 3章 配置与变更管理 案例:软件项目开发管理的新需求 你在一家小公司做软件工程师，开始的时候，你只有一个人，配了2个助手。你们研究了一种算法（例如：图象压缩、数据加密等），编写了一个实现模块。有一天老板看到了你的演示，认为很有市场潜力，可以结合进公司正在给某行业用户正在准备开发的系统中，成为该系统的核心技术或一个别人没有的卖点。 下一周，你的队伍增加到14（你的老板准备就此豪赌一把了），与你3个人的小组不同的是，公司从其他部门为你配备了系统分析师，还有文档编制员、测试员。你的核心模块已经被大量的用户功能所包装，成为一个行业应用系统，并开始给用户试用，这是你的系统的第一版。 3个月后，公司决定把系统升级到第二版，除增加了许多新的功能外，公司决定支持多平台，同时，为了提高系统的性能和效率，准备采用第三方厂家的中间件，取代自己做的接口。第一版的缺陷修改，也要反映到第二版中。 案例:软件项目开发管理的新需求 第2版经过2个多月的开发，最终推向了市场。公司的这个产品不但被用户所欢迎，也被一家大公司所看中（就像IBM收购了Lotus和Rational、Informix一样），你们的产品，正好可以填补这家大公司产品线的空缺，你所在的公司被这家公司买去了。 公司为你的项目组派来了产品经理、项目经理。公司决定这个产品的测试，由公司总部独立的测试部门承担。同时，公司决定把项目组增加到50人，其中有20多人并不在你所在的城市。在新公司里，产品管理、项目管理、测试、质量等等，都与你过去的环境和做法不同，特别不同的是，公司准备开发的第3版系统与公司原有的产品要进行融合，使他们看上去是一家出来的不同的兄弟和姐妹。 案例:软件项目开发管理的新需求-思考 与软件的第1版、第2版相比，你的项目管理有什么不同？ 随着这个产品的演变，项目发生了四个变化： （1）系统的复杂性发生了很大变化； （2）?用于开发该系统的项目环境发生了很大变化； （3）在不同的项目生命周期内，项目控制本身的要求和力度发生了很大变化； （4）由于组织的变化，管理流程、人员、方式发生了很大变化。 前二类变化要求项目的组织和管理适应系统扩展的需要，后二种变化则要求项目管理具有适应性和灵活性。 忽视软件配置管理可能导致的混乱现象 发错了版本 安装后不工作 异地不能正常工作 已经解决的缺陷过后又出现错误 开发人员把产品拿出去出售赢利 找不到必威体育精装版修改了的源程序 因管理不善致使未经测试的软件加入到产品中 3.1 概述 3.1 概述 3.1 概述 SCM 的目标 目标1: 软件配置管理活动被定义和计划 目标2: 软件开发过程中的制品被识别、控制和管理 目标3: 对于处于配置管理下的软件制品的修改被控制 目标4: 与软件制品相关的项目组和成员应该被通知制  品的目前状态和被修改的信息 配置管理活动的作用 配置管理与质量管理 在质量体系的诸多支持活动中，配置管理处在支持活动的中心位置。质量管理虽然也有过程的验证，但配置管理只要定义的配置项够细，则它可以管理软件开发的全过程，细到每一个模块、每一个文档、每一条工程记录的变化。 因此，配置管理从基础层开始，有机地把其它支持活动结合起来，形成一个整体，相互促进，相互影响，有力地保证了质量体系的实施。? 3.1.1 配置项的定义 项目研发和管理过程中会产生许许多多的工作成果，例如文档（针对技术开发者和用户）、程序（源代码和可执行程序）和数据（包含在程序内部或外部）等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。 所有在软件过程中产生的信息，凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项主要有两大类： （1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 （2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。 3.1.1 配置项的定义 每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 配置项内容 3.1.2 基线 基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。经过正式评审并被相关人员一致同意，可以作为以后项目开发的基础。 基线是软件生存期各开发阶段末尾的特定点，也称里程碑。标识软件过程阶段的里