软件项目管理方法与实践 第11讲 配置管理（1）

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件项目管理,第,11,讲：配置管理（,1,）,阳王东,风险管理复习,高风险的数据分析项目的风险管理,一个网站开发项目的风险管理,高风险数据分析项目的风险管理,风险识别,需求不确定性的风险；,决策层沟通障碍的风险；,分析技术路线的风险；,其他风险。,风险分析,风险规避,风险分析,需求不确定性风险还会导致项目进度、成本、质量、资源、合同等相关风险，使项目处于失控状态。在实际工作中，往往遇到当项目快要收尾时，依然出现客户对系统提出“在客户分析方面需要拔高”，“在经营指标分析方面要加强体现某领导讲话精神”之类模糊不清的需求。,决策层沟通障碍风险容易使最终决策领导对项目的期望保留在项目竞标阶段，理想而抽象，项目组不能真正理解领导的需求，甚至无所适从，大量工作“跑题”浪费，使时间和成本的投入成倍增长。,技术路线风险可以直接导致项目失败。项目的目标有时会超过项目组所选技术能够支持的范围，再加上项目组对产品并不熟悉，选用了看似完美而实际并不成功的分析模型，无疑会使项目处于毁灭性的风险中。像某国家级银行采用,SAS,和,Cognos,实现的全国性信贷分析系统几乎无法使用就是典型案例。,风险规避,项目经理同客户最高决策层拥有畅通的沟通渠道；,项目开发模型采用迭代模型；,审慎运用尚处于研究阶段的分析技术与模型；,层次较高、结构合理的项目组织结构；,多参考专家意见。,思考题,一个玩具销售公司决定开发一个网站实现网上销售玩具，决定开发时间为,9,月份，必须赶上圣诞节的销售旺季，你作为一个负责人，请进行风险识别和分析。,下面是实际情况，请进行分析总结出现这种情况的原因，应该采取什么措施去避免。,在项目的初期一个负责服务器端开发的人员一直兼任另一个项目，而到了中期又因病离职，导致服务器端的开发几乎没有任何进展。项目组在,12,月份调入另一名能力较强的开发人员来接班。在项目组的努力下终于在,12/24,如期发布了,beta,版。,到这里似乎一切顺利，但接下来的一个月中，未确定的需求和不断发现的,bug,成了灾难。项目从原定的,1/25,推迟到,2/8,，再推迟到,2/16,。而这时开发团队也由原来的两个人增加到五个人，增加的三个人专职测试。最后终于发布了，结果发布当天就因为一个小,bug,导致数十个用户数据被误删。于是暂停服务继续修改，改为封闭式开发，并且继续增加测试队伍到,10,个人，这样整个团队就有,12,个人在工作。,这样的状况一直持续到二月底，项目总算正常发布了。但实际的工时约为预计的,3,倍。,本讲主要内容,软件配置管理的概念,配置管理计划,接口和子合同方,/,供应商的控制,软件配置管理的概念,七十年代初期加利福利亚大学的,Leon Presser,教授就撰写了一篇论文，提出控制变更和配置的概念,在,CMM,二级当中，对软件配置管理（,Software Configuration Management SCM,）是这样描述的，软件配置管理目的是建立和维护在项目的整个软件生存周期中软件产品的完整性。,配置管理内容,标识在给定时间点上软件的配置（即选定的软件工作产品及其描述），系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。至于软件配置管理之下的工作产品包括交付给顾客的软件产品（例如软件需求文档和代码），以及与这些软件产品等同的产品项或生成这些软件产品所要求的产品项（例如编译程序）。,定义。软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。,配置管理其实是任何管理工作的基础,软件配置管理的特点,易变性,难以控制的变化,配置项的复杂,难以审核配置项的变更,长期性,配置管理计划,确定项目中的软件配置项,确定软件项目的基线划分,配置库的规划,确定变更控制规程,一份软件配置计划书的分析,确定项目中的软件配置项,配置管理的对象主要是软件配置项。,件配置项是一些特定的、可文档化的工作产品集。,一个工作产品可以定义为一个由软件开发项目的功能、活动或任务所产生的任意有形的软件项目。,一个软件配置项是开发的一部分或可交付系统的一部分，需要对它们进行单独的识别、存储、审核、使用、更改、交付或维护。,主要的软件配置项,管理计划（项目、进度、成本管理、质量保证、测试、风险管理、配置管理等）；,需求文档（项目标书、需求规格说明、客户需求确定书、需求变更记录）和测试文档（测试方案、测试用例、测试记录）；,用户、维护文档和手册（使用手册、安装手册、系统备份和恢复手册、维护记录、升级说明等）；,支持软件（包括开发工具、操作系统、文档制作工具、,CASE,工具、打包工具软件等）；,数据字典和各种交叉引用（一些相关的规范等）；,源代码，包括外部得到的、可用的代码；,可执行程序，包括外部获得的组件或函数库；,关系图和建造过程的其他产品；,产品发布说明，例如版本描述文档、产品宣传资料；,创建和运行产品所使用的数据库；,接口控制文档，在一个系统工程的配置管理系统中可能不对这类配置项进行单独维护；,任何支持产品开发和运行的项，其中有些项只有可运行的形式。,基线管理,基线的概念,确定基线的内容,基线的划分,基线的概念,基线是一个或一些配置项的集合，它们的内容和状态已经过技术的评审，并在生存周期的某一步骤被接受。,一旦一些软件配置项已经通过了评审，并正式成为一个初始基线，那么该基线就可以作为产品生存周期下面开发活动的起点和依据。,对于基线中的软件配置项，可以进行变更，但只能通过软件开发项目所建立的基线变更控制规程。,确定基线的内容,创建基线的事件；,与基线和配置控制相关联的软件配置项；,基线的变更条件和记录；,建立和更改基线以及基线中的软件配置项所使用的规程；,批准基线中软件配置项更改的机构应该具有的权限；,如何标识变更、如何将这一变更与基线和其中的软件配置项关联起来。,基线的划分,功能基线,描述系统应该能够执行的功能，是在系统需求评审和系统设计评审之后所建立的配置。,功能基线中的文档规范了软件配置项的所有必要的功能特性、为表示这些特性的实现所要求的系统层的测试、必要的接口特性、性能需求、质量属性以及设计约束。,分配基线,它描述了被开发的软件所能执行的功能，是在软件需求评审之后建立起来的配置，是系统分配给软件的需求配置。,一般是软件项目组在完成对系统的功能性需求和非功能性需求分析后经过客户参与的评审确定后的软件需求规格说明。,开发基线,软件开发项目组可以根据项目的需要设置设计基线。可以设计概要设计基线、详细设计基线以及在开发过程中设计的一些软件基线。,产品基线。,是在经过系统层验证和确认活动，确信可交付的产品满足需求基线中的所有需求项所建立起来的配置。,产品基线完整地记录了软件的最终版本。,基线与项目开发周期中的对应位置,配置库的规划,软件配置库为实现软件配置管理对软件配置项及其所需要的控制和变更历史功能提供了存储机制。,文件系统,数据库系统,配置库的组织结构,按配置项的类型分类建库,而按任务建立相应的配置库,配置库的分类,开发库。开发库中存放处于变动之中的软件项，或临时性软件项，或半成品。开发库由项目组自行管理。,受控库。受控库中存放那些在预定时刻其状态应予冻结的软件配置项。对受控库中的软件配置项的状态变更应实施正规的、严格的控制。,产品库。产品库中则存放那些由取自受控库的软件配置项所构成的指定产品。一般不直接修改。,配置库的组织样例,确定变更控制规程,配置管理中变更控制针对于不同类型的配置库有不同的控制规程。,开发库的控制流程,受控库的控制流程,产品库的控制流程,开发库的控制流程,初始入库。,更新开发库（,Check In,）。,提取开发配置项（,Check Out,）。,受控库的控制流程,提出变更。需要变更的人提交书面的变更请求，项目经理和配置管理员确定变更的影响范围。,实施变更。配置管理员提出需要变更的配置项，当事人实施变更。,重新入库。项目经理组织相关人员对变更内容进行审核，由测试人员进行测试，并经过配置管理员的审定入库，并形成新的版本号。,产品库的控制流程,发布准备。提出发布申请版本及配置项清单。,形成产品。相关人员对配置清单进行审定，配置管理员根据版本号从配置库中提取相应的配置项，并要经过相关人员对每个配置项进行审核后，配置管理员在产品库中形成新的版本的产品。,产品发布。在从产品库中提出需要的版本的产品复制到相应的介质上，并形成相应文档，进行包装，形成具体的产品。,一份软件配置计划书的分析,NewSkyCRM,项目软件配置管理计划,接口和子合同方,/,供应商的控制,硬件和系统集成作为大系统的一部分，与软件系统一起协调开发、调试或部署；,项目的产品必须运行在一个商业计算平台上，需要利用该平台的,API,来调用平台提供的服务；,产品要与商业组件一起集成和分布；,产品的一个模块或子系统被分包给外部的第三方。该组件必须在产品发布之前集成到产品中，或必须与产品一起进行分布处理。,建议与忠告,好记心不如烂笔头；,项目中不要存在私房软件；,规划和确定项目的软件配置项，其实也是对软件的一个整体认识过程；,要把需要进行组织上控制和个人控制的软件配置项进行严格分开。,思考题,学习一门课程可以看作一个项目，谈谈学习本课程的配置管理,有哪些配置项,如何规划这些配置项,