大学软件项目管理方法与实践-阳王东-大学教学资料课件PPT
收藏
资源目录
压缩包内文档预览：(预览前20页/共30页)
编号：21835966
类型：共享资源
大小：12.25MB
格式：ZIP
上传时间：2019-09-06
上传人：QQ24****1780
认证信息
个人认证
王**（实名认证）
浙江
IP属地：浙江
25
积分
- 关 键 词：
-
大学
软件
项目
管理
方法
法子
实践
王东
教学
资料
课件
ppt
- 资源描述：
-
大学软件项目管理方法与实践-阳王东-大学教学资料课件PPT,大学,软件,项目,管理,方法,法子,实践,王东,教学,资料,课件,ppt
- 内容简介：
-
NewSkyCRM项目软件配置管理计划一. 概述1.1 目的和范围本文档描述NewSkyCRM软件开发项目的软件配置管理计划，该计划向NewSkyCRM软件开发项目组以及相关受SCM活动影响的组和个人提供相应的说明和活动指南，使某某软件开发中心SCM方针能够在NewSkyCRM软件开发项目的SCM活动中得到贯彻。本计划适用于NewSkyCRM软件开发项目的整个生命周期。1.2 软件配置管理计划维护本计划由NewSkyCRM项目经理和软件配置管理经理共同制订。如果计划中的SCM活动在实施中出现偏离，由软件配置管理经理按照变更控制规程及时维护。1.3 参考资料电信NewSkyCRM产品 软件开发计划书，Version 1.3.0，NS.TEL-NewSkyCRM-CRM-RM-03；电信NewSkyCRM产品 系统功能说明书，Version 1.1.1，NS.TEL-NewSkyCRM-CRM-RM-02；某某软件开发中心软件配置管理过程，Version 1.1，NS-PROC-SCM-001；某某软件开发中心软件配置管理计划规程，Version 1.0，NS-PROC-SCM-002。二. 角色与职责2.1 软件配置管理代表软件配置管理代表的职责是遵循某某软件开发中心软件配置管理过程及有关规程等文档进行软件配置管理活动。表8-1 软件配置人员表软件配置管理代表*2.2 配置控制委员会NewSkyCRM软件开发项目配置控制委员会的职责是管理本项目内软件基线的变更等操作和配置项/单元标识的审定。主席主持配置控制委员会的活动。表8-2 配置控制委员会配置控制委员会主席*配置控制委员会成员*配置控制委员会成员*配置控制委员会成员*配置控制委员会成员*2.3 项目经理NewSkyCRM软件项目经理必须履行某某软件开发中心软件配置管理过程及有关规程等文档中指定的有关项目经理的职责。2.4 项目开发组NewSkyCRM软件项目开发组必须履行某某软件开发中心软件配置管理过程及有关规程等文档中指定的有关项目开发组的职责。表8-3 项目组成员表项目开发组成员，项目经理*项目开发组成员，软件经理*项目开发组成员，系统分析员*项目开发组成员，系统分析员*项目开发组成员，高级程序员*项目开发组成员，高级程序员*项目开发组成员，高级程序员*项目开发组成员，高级程序员*三. 配置管理环境3.1 文档工具NewSkyCRM软件项目的配置管理活动所有文档由下列办公系统软件生成，或由配置管理工具自动生成。表8-4 文档工具表办公系统软件Microsoft Office 20003.2 软件配置管理工具NewSkyCRM软件项目的配置管理活动使用下列工具：表8-5 配置工具表更改控制工具（厂商和版本）Rational ClearQuest 2001或手工管理版本控制工具（厂商和版本）Visual SourceSafe3.3 配置管理服务器NewSkyCRM软件项目使用如下配置的配置管理服务器：表8-6 配置管理服务器配置表硬件平台（厂商和型号）联想 开天 4600操作系统（版本）Microsoft Windows 2000 Advanced Server处理器IntelPentium4 1.5GHz内存SDRAM 256MB网络适配器Inter PRO/100 VE network connection硬盘空间40G四. 配置管理活动4.1 配置标识4.1.1 文档配置项表8-7 文档配置项表需求需求获取/分析表系统功能说明书软件开发计划软件配置管理计划软件质量保证计划软件测试计划软件需求规格说明书设计概要设计书确认测试方案详细设计书集成测试方案用户手册数据库(数据仓库)设计BOSS接口规范编码及单元测试源代码模块执行代码模块单元测试用例单元测试记录单元测试报告测试续表集成测试记录集成测试报告确认测试记录确认测试报告验收产品发布记录软件质量总结报告财务总结报告项目总结报告维护维护记录4.1.2 产品配置项表8-8 产品配置项表产品执行代码模块用户手册产品定义中其它配置项4.1.3 标识方法4.1.1和4.1.2中所列各项需要分配唯一软件配置项用以标识，具体方法参考某某软件开发中心软件配置管理过程中6.3节内容。4.1.4 配置基线表8-9配置基线表需求基线系统功能说明书设计基线概要设计书确认测试方案详细设计书集成测试方案用户手册数据库(数据仓库)设计BOSS接口规范产品基线执行代码模块用户手册产品定义中其它配置项4.2 配置控制软件配置项/单元的变更控制适用于NewSkyCRM软件项目的所有受控文档和代码，具体涉及到变更的提交、评审和处理的流程参考某某软件开发中心变更控制规程中有关章节内容。4.3 配置状态统计软件配置管理代表依照某某软件开发中心配置状态记录规程记录NewSkyCRM软件项目的配置项/单元的状态，定期或事件驱动的生成有关的状态报告。4.3.1 配置控制委员会会议记录保留NewSkyCRM软件项目配置控制委员会每次会议的记录。配置控制委员会的会议记录根据会议日期来命名，命名格式为NewSkyCRM CCB MR-YYYYMMDD，其中“MR”指“会议记录”，“YYYY” 指年份，“MM” 指月份，“DD”某日份。假如，NewSkyCRM软件项目CCB于2001年10月25日召开了会议，其会议记录名称应为NewSkyCRM CCB MR-20011025。4.3.2 变更请求状态变更请求状态报告用于跟踪和报告变更请求的状态，由软件配置管理代表每周生成所有变更请求的状态报告，或者事件驱动的生成所有/特定变更请求的状态报告。4.3.3 配置项状态配置项状态报告用于跟踪和报告本文档4.1.1和4.1.2节中所描述的配置项的状态，由软件配置管理代表每周生成所有配置项的状态报告，或者事件驱动的生成所有/特定配置项的状态报告。4.4 基线审核软件配置管理代表依照某某软件开发中心基线审核规程对NewSkyCRM软件项目基线进行每月一次的审核。五. 配置管理审核依照某某软件开发中心软件配置管理过程，NewSkyCRM软件项目执行如下软件配置管理审核活动：高级经理每两月一次参加有关软件配置管理的审核；项目经理每月一次同时也事件驱动的参加有关软件配置管理的审核；软件配置管理代表每月一次的审核项目基线；软件质量保证组按照软件质量保证计划评审和审核软件配置管理活动。六. 配置控制委员会主要活动时间表以下仅列出配置控制委员会主要定期活动的参考时间表，不包括处理变更控制等事件驱动性质活动的时间表。表8-10 软件配置管理活动时间表活动名称活动时间（参考）活动内容需求基线2001-12-12以后一周内审核需求基线工作产品设计基线2002-03-25以后一周内审核设计基线工作产品产品基线2002-05-13以后一周内审核产品基线工作产品产品发行2002-05-20审核NewSkyCRM软件产品NewSkyCRM项目软件配置管理计划一. 概述1.1 目的和范围本文档描述NewSkyCRM软件开发项目的软件配置管理计划，该计划向NewSkyCRM软件开发项目组以及相关受SCM活动影响的组和个人提供相应的说明和活动指南，使某某软件开发中心SCM方针能够在NewSkyCRM软件开发项目的SCM活动中得到贯彻。本计划适用于NewSkyCRM软件开发项目的整个生命周期。1.2 软件配置管理计划维护本计划由NewSkyCRM项目经理和软件配置管理经理共同制订。如果计划中的SCM活动在实施中出现偏离，由软件配置管理经理按照变更控制规程及时维护。1.3 参考资料电信NewSkyCRM产品 软件开发计划书，Version 1.3.0，NS.TEL-NewSkyCRM-CRM-RM-03；电信NewSkyCRM产品 系统功能说明书，Version 1.1.1，NS.TEL-NewSkyCRM-CRM-RM-02；某某软件开发中心软件配置管理过程，Version 1.1，NS-PROC-SCM-001；某某软件开发中心软件配置管理计划规程，Version 1.0，NS-PROC-SCM-002。二. 角色与职责2.1 软件配置管理代表软件配置管理代表的职责是遵循某某软件开发中心软件配置管理过程及有关规程等文档进行软件配置管理活动。表8-1 软件配置人员表软件配置管理代表*2.2 配置控制委员会NewSkyCRM软件开发项目配置控制委员会的职责是管理本项目内软件基线的变更等操作和配置项/单元标识的审定。主席主持配置控制委员会的活动。表8-2 配置控制委员会配置控制委员会主席*配置控制委员会成员*配置控制委员会成员*配置控制委员会成员*配置控制委员会成员*2.3 项目经理NewSkyCRM软件项目经理必须履行某某软件开发中心软件配置管理过程及有关规程等文档中指定的有关项目经理的职责。2.4 项目开发组NewSkyCRM软件项目开发组必须履行某某软件开发中心软件配置管理过程及有关规程等文档中指定的有关项目开发组的职责。表8-3 项目组成员表项目开发组成员，项目经理*项目开发组成员，软件经理*项目开发组成员，系统分析员*项目开发组成员，系统分析员*项目开发组成员，高级程序员*项目开发组成员，高级程序员*项目开发组成员，高级程序员*项目开发组成员，高级程序员*三. 配置管理环境3.1 文档工具NewSkyCRM软件项目的配置管理活动所有文档由下列办公系统软件生成，或由配置管理工具自动生成。表8-4 文档工具表办公系统软件Microsoft Office 20003.2 软件配置管理工具NewSkyCRM软件项目的配置管理活动使用下列工具：表8-5 配置工具表更改控制工具（厂商和版本）Rational ClearQuest 2001或手工管理版本控制工具（厂商和版本）Visual SourceSafe3.3 配置管理服务器NewSkyCRM软件项目使用如下配置的配置管理服务器：表8-6 配置管理服务器配置表硬件平台（厂商和型号）联想 开天 4600操作系统（版本）Microsoft Windows 2000 Advanced Server处理器Intel?Pentium?4 1.5GHz内存SDRAM 256MB网络适配器Inter? PRO/100 VE network connection硬盘空间40G四. 配置管理活动4.1 配置标识4.1.1 文档配置项表8-7 文档配置项表需求需求获取/分析表系统功能说明书软件开发计划软件配置管理计划软件质量保证计划软件测试计划软件需求规格说明书设计概要设计书确认测试方案详细设计书集成测试方案用户手册数据库(数据仓库)设计BOSS接口规范编码及单元测试源代码模块执行代码模块单元测试用例单元测试记录单元测试报告测试续表集成测试记录集成测试报告确认测试记录确认测试报告验收产品发布记录软件质量总结报告财务总结报告项目总结报告维护维护记录4.1.2 产品配置项表8-8 产品配置项表产品执行代码模块用户手册产品定义中其它配置项4.1.3 标识方法4.1.1和4.1.2中所列各项需要分配唯一软件配置项用以标识，具体方法参考某某软件开发中心软件配置管理过程中6.3节内容。4.1.4 配置基线表8-9配置基线表需求基线系统功能说明书设计基线概要设计书确认测试方案详细设计书集成测试方案用户手册数据库(数据仓库)设计BOSS接口规范产品基线执行代码模块用户手册产品定义中其它配置项4.2 配置控制软件配置项/单元的变更控制适用于NewSkyCRM软件项目的所有受控文档和代码，具体涉及到变更的提交、评审和处理的流程参考某某软件开发中心变更控制规程中有关章节内容。4.3 配置状态统计软件配置管理代表依照某某软件开发中心配置状态记录规程记录NewSkyCRM软件项目的配置项/单元的状态，定期或事件驱动的生成有关的状态报告。4.3.1 配置控制委员会会议记录保留NewSkyCRM软件项目配置控制委员会每次会议的记录。配置控制委员会的会议记录根据会议日期来命名，命名格式为NewSkyCRM CCB MR-YYYYMMDD，其中“MR”指“会议记录”，“YYYY” 指年份，“MM” 指月份，“DD”某日份。假如，NewSkyCRM软件项目CCB于2001年10月25日召开了会议，其会议记录名称应为NewSkyCRM CCB MR-20011025。4.3.2 变更请求状态变更请求状态报告用于跟踪和报告变更请求的状态，由软件配置管理代表每周生成所有变更请求的状态报告，或者事件驱动的生成所有/特定变更请求的状态报告。4.3.3 配置项状态配置项状态报告用于跟踪和报告本文档4.1.1和4.1.2节中所描述的配置项的状态，由软件配置管理代表每周生成所有配置项的状态报告，或者事件驱动的生成所有/特定配置项的状态报告。4.4 基线审核软件配置管理代表依照某某软件开发中心基线审核规程对NewSkyCRM软件项目基线进行每月一次的审核。五. 配置管理审核依照某某软件开发中心软件配置管理过程，NewSkyCRM软件项目执行如下软件配置管理审核活动：高级经理每两月一次参加有关软件配置管理的审核；项目经理每月一次同时也事件驱动的参加有关软件配置管理的审核；软件配置管理代表每月一次的审核项目基线；软件质量保证组按照软件质量保证计划评审和审核软件配置管理活动。六. 配置控制委员会主要活动时间表以下仅列出配置控制委员会主要定期活动的参考时间表，不包括处理变更控制等事件驱动性质活动的时间表。表8-10 软件配置管理活动时间表活动名称活动时间（参考）活动内容需求基线2001-12-12以后一周内审核需求基线工作产品设计基线2002-03-25以后一周内审核设计基线工作产品产品基线2002-05-13以后一周内审核产品基线工作产品产品发行2002-05-20审核NewSkyCRM软件产品软件项目管理 第10讲：风险管理,阳王东 ,复习,如何定义一个电子商务网站的质量特性 如何看待windows vista的质量问题,主要内容,风险识别 风险控制 风险应对 案例分析,风险的概念,什么是风险。风险是其损益结局具有不可确定性的活动。 任何可能出现的条件或事件，一旦发生，对项目会造成损害； 风险是不确定的条件或因素，不同于“测试中肯定会发现缺陷，但不知道是何时”。 风险的特征 所涉及的不确定性，这一不确定性通常被表示为可能性，也就是有发生的概率； 与风险相关的损失，如生活、健康、金钱、财产、名誉或机会等方面的损失； 它是可管理的，在这一意义下，人类活动可以改变风险的形式和程度。,风险识别的方法,问询和探讨 头脑风暴法 咨询 分析历史数据 流程图法 逆向推导法,流程图法,逆向推导法,逆向推导法是从项目的结果出发，去推导导致结果的可能存在的风险因素 项目失败 项目中途终止； 当完成了项目开发的软件产品后，而客户或公司却放弃了对软件开发合同履行,逆向推导法（续）,导致第一种情况出现的风险可能有： 项目的经费供应终止。可能是投资方撤资或倒闭。 公司决策层放弃。可能由于市场、技术或者业务方向等问题，导致公司放弃了项目所开发的软件产品。 由于项目组主要的关键人员离开项目组，可能是被竞争对手挖走，或者是疾病与死亡等，而项目组一时找不到可替代的人员，并且项目缺乏这些人员不能继续。 项目开发的软件产品违反国家有关法律或法规，被勒令终止。,逆向推导法（续）,可能导致第二种情况出现的风险可能有： 客户的业务发生重大变化，项目组开发的软件产品已经不能适应新的业务需要。 客户的组织发生了重大变化，新的组织不再履行以前组织签订的软件合同。这一方面在客户是行政事业单位更为明显。 项目组开发的软件产品存在重大质量问题，使得客户根本无法开展业务工作，从而导致客户根据软件合同相关条款终止合同的履行。 项目进度严重滞后，当项目组把软件产品开发出来后，客户已经不需要了。 由于硬件提供商违约，既定的硬件基础不能到位，导致客户根本无法运行项目开发的软件产品，并且不能在短时期能得到解决，因而客户终止对软件合同的履行。 也可能是客户在软件合同经费的支付上违反合同的相关条款，公司放弃了对客户的软件合同的履行。,软件项目中常见的风险,需求风险 计划编制风险 组织和管理风险 人员风险 开发环境风险 客户风险 产品风险 设计和实现风险 过程风险,需求风险,需求已经成为项目基准，但需求还在继续变化； 需求定义欠佳，而进一步的定义会扩展项目范畴； 添加额外的需求； 产品定义含混的部分比预期需要更多的时间； 在做需求中客户参与不够； 缺少有效的需求变化管理过程。,计划编制风险,计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致； 计划是优化的，是“最佳状态”，但不现实，只能算是“期望状态”； 计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上； 产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大； 完成目标日期提前，但没有相应地调整产品范围或可用资源； 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。,组织和管理风险,仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长； 低效的项目组结构降低生产率； 管理层审查、决策的周期比预期的时间长； 预算削减，打乱项目计划； 管理层作出了打击项目组织积极性的决定； 缺乏必要的规范，导致工作失误与重复工作； 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。,人员风险,作为先决条件的任务(如培训及其他项目)不能按时完成； 开发人员和管理层之间关系不佳，导致决策缓慢，影响全局； 缺乏激励措施，士气低下，降低了生产能力； 某些人员需要更多的时间适应还不熟悉的软件工具和环境； 项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低； 由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作； 不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性； 没有找到项目急需的具有特定技能的人。,开发环境风险,设施未及时到位； 设施虽到位，但不配套，如没有电话、网线、办公用品等； 设施拥挤、杂乱或者破损； 开发工具未及时到位； 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具； 新的开发工具的学习期比预期的长，内容繁多。,客户风险,客户对于最后交付的产品不满意，要求重新设计和重做； 客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做； 客户对规划、原型和规格的审核 决策周期比预期的要长； 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更； 客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长； 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。,产品风险,矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作； 开发额外的不需要的功能(镀金)，延长了计划进度； 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作； 要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作； 在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题； 开发一种全新的模块将比预期花费更长的时间； 依赖正在开发中的技术将延长计划进度。,设计和实现风险,设计质量低下，导致重复设计； 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能； 代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作； 过高估计了增强型工具对计划进度的节省量； 分别开发的模块无法有效集成，需要重新设计或制作。,过程风险,大量的纸面工作导致进程比预期的慢； 前期的质量保证行为不真实，导致后期的重复工作； 太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发； 过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作； 向管理层撰写进程报告占用开发人员的时间比预期的多； 风险管理粗心，导致未能发现重大的项目风险。,建议和忠告,考验一个项目经理和项目开发团队，不仅要看其在没有什么风险的环境中的做事的能力；更要看其在出现各种风险的环境下的做事能力； 风险并不可怕，可怕是不知道有风险； 不能因为有风险就不去做，风险是锻炼一个人的最好的机会； 一般是高风险才能有高的回报。,风险控制,风险管理模型 风险控制计划 十个风险清单 风险控制方法,风险管理模型,Barry Boehm模型 。RE=P (UO)*L (UO) 。 其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生破坏性的程度。Boehm思想的核心是10大风险因素列表。 SEI的CRM模型。 它将风险管理划分为五个步骤：风险识别、分析、计划、跟踪、控制。 SERIM模型 。 从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。,风险控制计划,风险管理计划 应急计划 应急储备,风险管理计划,(1) 项目中存在哪些风险； (2) 风险的发生可能性大小； (3) 不同风险对项目的影响程度； (4) 风险可能出现的阶段及其影响的阶段； (5) 谁对哪些风险具体进行跟踪和负责。 计划表中风险类别 BU-商业风险，CU-客户特性风险，DE-开发环境风险，TE-人员经验风险，ST-建造技术风险，PS-产品规模风险，PU-过程风险。,风险管理计划表,风险管理计划表（续）,十个风险清单,风险控制方法,为了有效的风险控制，项目组和项目经理必须具备： 衡量项目进展状态的标准； 监视项目实际进展所需要的信息； 必要时采取调整和纠正行动的权限； 从各种备用措施中选取最优者加以实施的能力。 风险控制策略 降低风险发生的概率 为事件的发生做好准备，减轻风险的影响 制度化、规范化的运作，可以降低人为因素的风险 转移风险有时也是一种好的方法 凡是留有回旋余地，不至于到时一筹莫展 惹不起，躲得起 默默得承受有时既是无奈的选择，但可能是明智的选择,降低风险发生的概率,公司在制定开发流程一定要从实际出发，是真正为了提高开发效率与质量而制定的，而不是为了制度而制度； 项目经理要根据项目的实际情况进行适当裁减； 要对开发人员进行培训，让他们能够掌握开发流程的精髓； 在执行过程中，能够不断进行改进，让开发人员切实感觉到遵照开发流程进行开发，确实能够提高效率，还能保证质量。,转移风险的方式,出售 发包 开脱责任合同 保险 担保。,回避的项目,开发的软件系统存在法律障碍。 客观上不需要的项目，没有必要去冒险。 一旦造成损失，软件公司无力承担后果的项目。,建议与忠告,将风险管理集成到项目管理； 使用工具； 开始时不要对量化过于强调； 不要期待实施风险管理的费效分析； 记住风险计划可能引入新的风险或增加成本。 风险回避应是最后一招，采用时应非常清醒 使用组织层的风险数据库以便项目间相互借鉴,风险的应对,关注风险，但不焦虑风险 发现苗头，及时处理 当风险变成现实时，不要回避,关注风险，但不焦虑风险,要有一个良好的心态 要树立能解决风险所带来影响的信心 要树立能解决风险所带来影响的信心 让项目组每个人都能够了解风险 记录风险，并不是时时刻刻讲风险 不同风险让专人去跟踪 周期性汇报风险的状态,发现苗头，及时处理,发现苗头，及时处理 客户需求不确定 客户推迟项目验收 开发人员的变动 模块质量不过关 开发进度延迟,建议与忠告,承认风险是不可避免的； 公开交流风险讨论本身似乎能减少风险的影响； 奖励阻止风险发生的人，而不仅仅是惩罚那些造成风险的人； 同一时刻不要管理太多风险； 记下风险； 不要仅关注容易处理的风险。,当风险变成现实时，不要回避,要承认风险发生的现实 要有一个良好的心态 要迅速的行动 要有针对地行动 事态严重必须向上级汇报 事故的处理结果要及时公布 风险的处理要有记录，并且要形成正式的处理报告,高风险数据分析项目的风险管理,风险识别 需求不确定性的风险； 决策层沟通障碍的风险； 分析技术路线的风险； 其他风险。 风险分析 风险规避,风险分析,需求不确定性风险还会导致项目进度、成本、质量、资源、合同等相关风险，使项目处于失控状态。在实际工作中，往往遇到当项目快要收尾时，依然出现客户对系统提出“在客户分析方面需要拔高”，“在经营指标分析方面要加强体现某领导讲话精神”之类模糊不清的需求。 决策层沟通障碍风险容易使最终决策领导对项目的期望保留在项目竞标阶段，理想而抽象，项目组不能真正理解领导的需求，甚至无所适从，大量工作“跑题”浪费，使时间和成本的投入成倍增长。 技术路线风险可以直接导致项目失败。项目的目标有时会超过项目组所选技术能够支持的范围，再加上项目组对产品并不熟悉，选用了看似完美而实际并不成功的分析模型，无疑会使项目处于毁灭性的风险中。像某国家级银行采用SAS和Cognos实现的全国性信贷分析系统几乎无法使用就是典型案例。,风险规避,项目经理同客户最高决策层拥有畅通的沟通渠道； 项目开发模型采用迭代模型； 审慎运用尚处于研究阶段的分析技术与模型； 层次较高、结构合理的项目组织结构； 多参考专家意见。,思考题,一个玩具销售公司决定开发一个网站实现网上销售玩具，决定开发时间为9月份，必须赶上圣诞节的销售旺季，你作为一个负责人，请进行风险识别和分析。 下面是实际情况，请进行分析总结出现这种情况的原因，应该采取什么措施去避免。 在项目的初期一个负责服务器端开发的人员一直兼任另一个项目，而到了中期又因病离职，导致服务器端的开发几乎没有任何进展。项目组在12月份调入另一名能力较强的开发人员来接班。在项目组的努力下终于在12/24如期发布了beta版。 到这里似乎一切顺利，但接下来的一个月中，未确定的需求和不断发现的bug成了灾难。项目从原定的1/25推迟到2/8，再推迟到2/16。而这时开发团队也由原来的两个人增加到五个人，增加的三个人专职测试。最后终于发布了，结果发布当天就因为一个小bug导致数十个用户数据被误删。于是暂停服务继续修改，改为封闭式开发，并且继续增加测试队伍到10个人，这样整个团队就有12个人在工作。 这样的状况一直持续到二月底，项目总算正常发布了。但实际的工时约为预计的3倍。,软件项目管理第10讲：风险管理阳王东复习如何定义一个电子商务网站的质量特性如何看待windows vista的质量问题主要内容风险识别风险控制风险应对案例分析 风险的概念什么是风险。风险是其损益结局具有不可确定性的活动。任何可能出现的条件或事件，一旦发生，对项目会造成损害；风险是不确定的条件或因素，不同于“测试中肯定会发现缺陷，但不知道是何时”。风险的特征所涉及的不确定性，这一不确定性通常被表示为可能性，也就是有发生的概率；与风险相关的损失，如生活、健康、金钱、财产、名誉或机会等方面的损失；它是可管理的，在这一意义下，人类活动可以改变风险的形式和程度。 风险识别的方法 问询和探讨 头脑风暴法 咨询分析历史数据 流程图法 逆向推导法 流程图法逆向推导法 逆向推导法是从项目的结果出发，去推导导致结果的可能存在的风险因素 项目失败项目中途终止；当完成了项目开发的软件产品后，而客户或公司却放弃了对软件开发合同履行 逆向推导法（续）导致第一种情况出现的风险可能有：项目的经费供应终止。可能是投资方撤资或倒闭。公司决策层放弃。可能由于市场、技术或者业务方向等问题，导致公司放弃了项目所开发的软件产品。由于项目组主要的关键人员离开项目组，可能是被竞争对手挖走，或者是疾病与死亡等，而项目组一时找不到可替代的人员，并且项目缺乏这些人员不能继续。项目开发的软件产品违反国家有关法律或法规，被勒令终止。逆向推导法（续）可能导致第二种情况出现的风险可能有：客户的业务发生重大变化，项目组开发的软件产品已经不能适应新的业务需要。客户的组织发生了重大变化，新的组织不再履行以前组织签订的软件合同。这一方面在客户是行政事业单位更为明显。项目组开发的软件产品存在重大质量问题，使得客户根本无法开展业务工作，从而导致客户根据软件合同相关条款终止合同的履行。 项目进度严重滞后，当项目组把软件产品开发出来后，客户已经不需要了。由于硬件提供商违约，既定的硬件基础不能到位，导致客户根本无法运行项目开发的软件产品，并且不能在短时期能得到解决，因而客户终止对软件合同的履行。也可能是客户在软件合同经费的支付上违反合同的相关条款，公司放弃了对客户的软件合同的履行。软件项目中常见的风险 需求风险 计划编制风险 组织和管理风险 人员风险 开发环境风险 客户风险 产品风险 设计和实现风险 过程风险 需求风险需求已经成为项目基准，但需求还在继续变化；需求定义欠佳，而进一步的定义会扩展项目范畴；添加额外的需求；产品定义含混的部分比预期需要更多的时间；在做需求中客户参与不够；缺少有效的需求变化管理过程。计划编制风险计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；计划是优化的，是“最佳状态”，但不现实，只能算是“期望状态”；计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；完成目标日期提前，但没有相应地调整产品范围或可用资源；涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。 组织和管理风险仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；低效的项目组结构降低生产率；管理层审查、决策的周期比预期的时间长；预算削减，打乱项目计划；管理层作出了打击项目组织积极性的决定；缺乏必要的规范，导致工作失误与重复工作；非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。人员风险作为先决条件的任务(如培训及其他项目)不能按时完成；开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；缺乏激励措施，士气低下，降低了生产能力；某些人员需要更多的时间适应还不熟悉的软件工具和环境；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；没有找到项目急需的具有特定技能的人。开发环境风险 设施未及时到位；设施虽到位，但不配套，如没有电话、网线、办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；新的开发工具的学习期比预期的长，内容繁多。客户风险 客户对于最后交付的产品不满意，要求重新设计和重做；客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；客户对规划、原型和规格的审核 决策周期比预期的要长；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。产品风险 矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；开发额外的不需要的功能(镀金)，延长了计划进度；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；开发一种全新的模块将比预期花费更长的时间；依赖正在开发中的技术将延长计划进度。 设计和实现风险 设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能； 代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。过程风险 大量的纸面工作导致进程比预期的慢；前期的质量保证行为不真实，导致后期的重复工作；太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。建议和忠告 考验一个项目经理和项目开发团队，不仅要看其在没有什么风险的环境中的做事的能力；更要看其在出现各种风险的环境下的做事能力；风险并不可怕，可怕是不知道有风险；不能因为有风险就不去做，风险是锻炼一个人的最好的机会；一般是高风险才能有高的回报。 风险控制 风险管理模型 风险控制计划 十个风险清单 风险控制方法 风险管理模型 Barry Boehm模型 。RE=P (UO)*L (UO) 。其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生破坏性的程度。Boehm思想的核心是10大风险因素列表。 SEI的CRM模型。它将风险管理划分为五个步骤：风险识别、分析、计划、跟踪、控制。 SERIM模型 。从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。 风险控制计划 风险管理计划 应急计划 应急储备 风险管理计划(1) 项目中存在哪些风险；(2) 风险的发生可能性大小；(3) 不同风险对项目的影响程度；(4) 风险可能出现的阶段及其影响的阶段；(5) 谁对哪些风险具体进行跟踪和负责。计划表中风险类别BU-商业风险，CU-客户特性风险，DE-开发环境风险，TE-人员经验风险，ST-建造技术风险，PS-产品规模风险，PU-过程风险。 风险管理计划表 风险管理计划表（续）十个风险清单 风险控制方法 为了有效的风险控制，项目组和项目经理必须具备：衡量项目进展状态的标准；监视项目实际进展所需要的信息；必要时采取调整和纠正行动的权限；从各种备用措施中选取最优者加以实施的能力。风险控制策略降低风险发生的概率 为事件的发生做好准备，减轻风险的影响 制度化、规范化的运作，可以降低人为因素的风险 转移风险有时也是一种好的方法 凡是留有回旋余地，不至于到时一筹莫展 惹不起，躲得起 默默得承受有时既是无奈的选择，但可能是明智的选择 降低风险发生的概率 公司在制定开发流程一定要从实际出发，是真正为了提高开发效率与质量而制定的，而不是为了制度而制度；项目经理要根据项目的实际情况进行适当裁减；要对开发人员进行培训，让他们能够掌握开发流程的精髓；在执行过
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号