第13章-软件配置管理

软件项目管理第13章软件配置管理13.1软件配置及其管理的概念13.2软件配置管理的基本活动13.3软件的测试管理软件配置：程序（模块或组件）、管理及技术文档、数据（参数）

一个软件产品在生存期各个阶段的不同形式和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。什么是软件配置？配置管理混乱的现象：开发人员使用错误的版本修改程序开发人员未经授权修改代码或文档,或修改的结果不能及时反映到各个相关部分；人员流动，交接工作不彻底造成软件关键内容遗失；已修复的Bug在新版本中出现找不到某个文件的历史版本；无法重新编译某个历史版本，使维护工作十分困难；因协同开发中，版本变更混乱导致整个项目失败……初始系统机型1机型2机型n操作系统1操作系统2用户1用户2

不同用户有自己的工作环境用户需要不同的配置ABCGDHEABFCDE

用户1

用户2

面对不同用户软件产品的配置用户需要不同的配置配置库示例

AFBDGCHE用户1用户2ABCDE

FABCDE

GH

产品1产品2

两个软件产品具有不同的配置用户1：A、B、C、D、E和F用户2：A、B、C、D、E和G、H

软件配置管理：

在软件开发过程中，标识、控制和管理软件变更的管理活动。

使整个软件产品的演进过程处于受控（包括可回溯）的状态。13.1软件配置及其管理的概念软件配置项（1/3）软件配置项(SCI:SoftwareConfigurationItem)：配置管理的对象。SCI的形式技术文档软件需求规格说明书软件概要设计规格说明书软件测试计划用户手册,……软件配置项（2/3）管理文档软件开发计划软件配置管理计划软件质量保证计划，……程序代码(源代码和可执行代码)模块1的源程序代码(例如，A.Java)模块1的可执行代码(例如，A.class)组件(程序包，例如，code.dll)可执行文件(例如，word.exe)……数据配置文件(例如，a.ini)数据文件(例如，a.pot)，……软件配置项（3/3）SCI的描述唯一的命名和编号属性版本(1.0)类型(文档)关系与软件的关联基线(1/4)什么是基线？已经通过正式复审和批准的软件产品、标准或规约，它们可以作为进一步开发的基础，并且只能通过正式的变化控制过程才允许对它们进行变更基线(2/4)为什么需要基线？开发过程中的变化不可避免变化不利于软件开发需要控制变化，软件产品保持一定程度的稳定以此作为软件开发的基础不允许随便、非正式更改保持相对稳定要改，须经评估和认可，要进行控制基线(3/4)

软件产品典型基线基线(4/4)作为基线的SCI软件配置管理的任务制定软件配置管理计划确定配置标识规则对变更进行控制报告配置状态进行配置审核进行版本管理和发行管理13.2软件配置管理的基本活动《ISO/IEC12207:1995信息技术—软件生存周期过程》关于软件配置管理过程的规定活动任务解释1．实施过程开发配置管理计划计划描述：配置活动、这些活动的规程、进度、配置管理组织及与其他组织的关系计划应形成文件2．配置标识制定标识规则以控制软件项及其版本标识内容包括：基线文档、版本基准号、其他3．配置控制标志并记录变更申请分析与评价变更批准（或不期准）申请实现、验证和发行已变更的软件项审核跟踪变更控制并审核受控软件项

跟踪变更原因、变更授权以保证重要功能的安全或保密4．配置状态报告编制管理记录和状态报告表明受控项（包括基线）的状态和历史状态报告应包括变更号、最新版本、发行标识、版本号及各种版本比较5．配置评价确定和保证软件项的功能完整性、物理完整性

6．发行管理和交付有效控制软件产品和文档的发行和交付在产品的生存期内保存代码、文挡的主拷贝

包括重要的安全或保密功能的代码和文档应按组织的方针处理、储存、包装和交付软件配置管理计划配置管理计划标准——IEEE828-19901．引言——配置管理计划的目的、适应范围、使用要求——项目概述——项目中需特别关注的配置管理问题和风险——软件配置管理严格性要求的等级——限制和假设——术语——参考文件2、软件配置管理（谁来管理？）——配置管理的组织结构——职责和权限——指令和方针——参照的规程（组织的规程或客户的规程）——遵循的标准3、软件配置管理活动（如何管理？）——配置管理活动——变更管理和配置控制——配置状态说明——配置审核——接口和子合同方控制4、软件配置管理进度安排（什么时候管理？）——软件配置管理重要事件的顺序——软件配置管理各项活动间的依赖关系5、软件配置管理所需的资源——采用的工具——使用的设备——所需的培训——对其他人员的要求6、软件配置管理计划的维护——维护的职责——计划更新的条件和审批——计划变更的交流和通报软件配置项标识任务识别有哪些SCI详细描述每个SCI识别SCI的要求完整，不要有遗漏系统，包括所有的技术文档、必须的管理文档、所有的程序(源码和可执行)、所有的数据SCI描述的要求唯一和直观命名，在本项目中是唯一标识的，直觉意思明确，有利于对该SCI的状态控制，便于增删、修改；描述属性，便于进一步详细了解SCI，如类型、创建者、时间、修改者，……描述与其他SCI的关系，便于追踪和管理其影响文档编号命名(例)C_Lib.2.RA.1.1.00形式：C_Lib.2.RA.1.1.00项目名称或者编号：C_Lib子系统编号：2文档类型：RA序号：1，表示本文档在同类型中的排序版本号：1修订号：00AD---结构设计CR---更动报告DD---详细设计DP---开发计划FA---可行性分析IC---接口控制IG---安装手册QA---质量保证RA---需求分析SL---源码列表SS---系统规格说明书TP---测试计划TR---测试报告UM---用户手册序号文档属性描述：编写人：例如，薄呱呱质检人：例如，李斯审核人：例如，张五常批准人：例如，雷政富发布版本：例如，1.00发布日期：例如，2008/05/19变化情况：……描述要体现其功能和所在的结构层次代码SCI的编号命名形式：子系统编号.组件编号.模块编号.表示功能涵义的字符串例如，3.32.324.Stack名称:Stack功能:堆栈语言：Java版本:1.0开发者:Dr.Ma开发时间:2008/06/30修改者:修改时间:描述关联关系为了便于更动控制时进行影响域评估，必须描述SCI之间的关联关系建立关联矩阵关联列表版本控制为什么SCI会有不同的版本软件因纠错/改进/完善/扩充会导致同一SCI有多个版本在同时从事多项目开发时，同一SCI的不同版本可能应用于不同的项目要保证开发需要，必须进行版本控制SCI的版本演化一般可采用存储版本树的办法来进行版本控制变更控制(1/2)变化不可避免，不控制变化将导致混乱无论何人、何时修改配置库中的SCI均应按规范流程处理提出书面申请变更控制组审核和评估(必要性/可行性/影响域/资源)同意,则授权执行指定修改；结论也可能是不同意或暂缓变更控制(2/2)软件配置审计配置审计的内容检查配置控制手续是否齐全变化是否完成？验证当前基线与前一基线的可追踪性确认各SCI是否均正确反映需求确保SCI及其介质的有效性定期复制、备份、归档，以防止意外的介质破坏配置审计结果应写成报告，通报有关人员或组织状态报告(1/2)为了及时追踪并记载SCI的变化,以备审计时使用，需要在整个生命周期中对每个SCI的变化进行系统的记录发生了什么变化谁产生的变化什么时候发生的变化对其它SCI有什么影响状态报告(2/2)根据SCI的出入库情况和变更控制组的审核记录，产生配置状态报告，并将状态报告及时发放给各有关人员和组织。配置状态报告也被存放在受控库中，可供有关人员随时查询通常,有以下两种报告:现行状态报告：指定SCI的现行状态，指明:现行版本号、是否正被某人专用?还是可共享?（并发控制）历史状态报告：指定SCI的历史记录，报告：谁于何时因何故对SCI做了何事(入库/出库/更动)?谁来实施软件配置管理软件配置管理小组来实施软件配置管理负责制定软件配置管理计划实施软件配置活动软件配置管理工具RationalClearCaseMicrosoftSourceSafePVCSCVS第14章项目的执行与控制14.1项目计划的执行14.2跟踪项目进展情况14.3项目控制14.1项目计划的执行项目执行=计划+按计划执行项目计划的执行：按照预定计划执行实施项目。执行的依据：项目计划、辅助说明、组织管理政策、纠正措施。执行的工具和方法：管理技能+专业知识+工作分配体系+绩效检查+项目信息管理系统+组织管理程序14.2跟踪项目进展情况为什么要跟踪项目进展？了解项目总体进度了解成员工作情况调整工作安排、合理利用资源进一步完善项目计划及时对人员进行考核项目进展跟踪：跟踪采集的对象、项目跟踪的方法、项目跟踪的结果14.3项目控制成功项目=好的计划+有效的控制如何有效地对项目进行控制？建立完善的项目监控和报告体系，明确所需的信息充分了解项目当前状态依据项目计划对当前状态进行分析、比较，做决策及时纠偏项目控制项目控制的步骤：制定控制计划设定阶段性成果验收准则（阶段性目标）收集项目进展情况判断偏差分析偏差产生的原因和趋势采取适当的纠正预防措施跟踪纠偏措施的有效性控制的目标：范围控制、进度控制、成本控制首先分析、估计目标偏离的可能性决策：采取预防措施发生了偏离后分析原因决策：采取纠偏措施主动控制被动控制分析预测目标偏离预防措施再分析预测再预防......纠偏措施目标再偏离再纠偏......主动控制与被动控制第15章项目收尾与验收15.1项目收尾概述15.2项目验收15.3项目移交与清算15.4项目后评审15.1项目收尾概述项目的终结：内部项目正常：目标已经实现异常：项目已经不具备实用价值、项目无期限拖延、项目环境变化、立项者撤消项目……外部项目正常：目标已经实现异常：对方严重违约导致另一方异常终止项目收尾概述项目的收尾过程：确认工作完成范围的符合性质量验收费用决算合同终