第4章项目管理.ppt

1 第4章软件项目管理 参考教材第5 25 26章 软件项目管理的有关概念软件项目管理的主要任务影响软件项目管理的主要元素软件项目估算项目规划项目跟踪与控制风险管理团队管理软件质量管理软件配置管理 2 4 1软件项目管理的有关概念 项目 以一套独特而相互联系的任务为前提 组织一定的人力在有限资源和进度约束条件下 为实现一个特定目标所作的工作 项目的成功受技术范围 成本 进度 用户满意度 人员等因素的制约 因此项目管理的职责是确保项目目标的实现 即在预算内按计划完成质量合格的产品 软件项目管理 是对传统项目管理的一种扩展 它在软件工程的任何技术活动之前开始 并持续贯穿于整个软件定义 开发和支持阶段的庇护性活动 是决定一个产品或项目能否成功最重要的活动之一 3 4 2软件项目管理的主要内容 需求管理软件项目估算及进度管理软件质量管理软件配置管理风险管理团队管理 4 项目管理者承担的任务 1 写出书面建议或申请书 建议书中要写清楚项目的目标和实现该目标的方法 估算项目的成本和进度 选择的开发团队等 如国家自然基金的申请书上有这样一些条目 简表立论依据 项目的研究意义 国内外研究现状分析 主要参考文献及出处 研究方案 研究的目标 内容 拟解决的关键问题 拟采用的研究方法 技术路线 实验方案及可行性分析 项目的创新之处 研究计划及预期进展 研究成果等 申请者的研究基础经费预算申请者正在研究的其他项目申请者的承诺单位意见 审查与保证等等 5 一 概述1 项目提出背景2 项目的目的 意义二 项目立项的必要性及市场需求分析1 项目技术攻关的必要性2 项目的市场需求分析三 相关领域国内外技术现状 发展趋势及现有工作基础1 国内外技术现状 专利等知识产权情况分析2 国内外技术发展趋势3 现有的工作基础四 项目计划目标及主要研究内容1 主要目标2 研究与开发内容3 项目的技术关键 包括技术难点 创新点五 技术 经济效益 市场风险分析1 技术经济效益分析 含经济效益 社会效益 2 推广应用前景分析 含产业化可行性 3 项目实施的风险分析 陕西省科技计划项目建议书编写提纲 6 六 申请单位简况1 单位简况 生产经营及科研情况 资产及经济状况等 2 项目主要负责人简介3 课题组组成简况七 必要的支撑条件 组织措施及实施步骤1 必要支撑条件2 组织管理的措施3 组织实施的步骤八 计划实施进展 经费预算及来源渠道1 年度计划2 经费预算3 经费来源九 其它说明 7 2 项目规划和进度明确项目的各种活动 里程碑 milestone 和可交付的文档 拟定计划以指导项目向既定目标开展 3 项目成本估算估算完成此项目的所有资源 4 项目监督与评审监督是一个连续性的活动 必须密切关注项目的进展 将实际的进展和成本与计划作比较 应该有正式或非正式的多次评审 可以发现潜在的问题 5 人员选择和评价理想是选择有经验 业务熟练的人员 需要挖掘现有人员的技能及培养新人 6 定期工作汇报汇报项目进展或总结经验 8 4 3影响软件项目管理的主要元素 软件项目管理中的主要元素及之间的关系 开发人员 小组 角色 任务 工作产品 进度表之间的关系 UML类图 9 Pressman 参考教材1 指出4个P People Product Process Project 对软件项目管理有实质性的影响 构成了项目管理的基本框架 人员必须被组织成有效的开发团队 产品需求被划分成较小的组成部分 便于分配给软件开发小组 开发过程应根据人员和产品选择合适的开发模型 项目必须被组织成便于控制和管理的方式 使有计划的进行 10 1 人员 人员是一个成功软件项目中最重要的因素 可分为5类 高级管理者 负责定义业务问题 影响着项目 技术管理者 组织 激励和控制开发人员 开发人员 负责开发一个产品或应用所需的技术 客户 customer 负责说明待开发的软件需求 最终用户 user 直接使用发布的软件 每一个软件项目都有上述的人员参与 必须被组织成有效的团队 最大限度的发辉每个人的技术和能力 激励他们进行高质量的工作 并协调他们实现有效的通信 11 2 产品 进行项目计划之前 应该首先定义产品的目的和范围 考虑可选的解决方案 标识技术和管理的约束 没有这些信息 就不可能进行合理的 准确的成本估算 有效的风险评估 适当的项目任务划分 可管理的项目进度安排 目的 指从用户的角度标识出该产品的总体目标而不考虑这些目标如何实现 范围 指标识出与产品相关的主要数据 功能和行为 确定了目的和范围 就可以根据产品交付的期限 预算的限制 可用的人员 技术接口及各种其他因素 选择最好的解决方案途径 12 3 过程根据以下条件选择一个合适的软件过程模型 开发人员及需要该产品的用户 产品本身的特征 项目组的工作环境采用如下的框架活动集合 启动 客户交流 计划 风险分析 工程实施 构造及发布 终结 这些活动可被修改以适应不同软件项目的特征和项目组的需求 每个活动可被分解为更详细的工作任务 13 4 项目要有计划的控制软件项目 Boehm提出了一种方法 强调项目目标 里程碑 进度 责任 管理和技术方法以及需要的资源 称之为W5H2原则 通过下面一系列的提问和回答 可以导出项目的关键特征并产生项目计划的大纲 为什么 Why 该系统被开发 值得吗 将做什么 What 什么时候 When 做 便于建立项目进度 标识关键的项目任务和里程碑 某功能由谁 Who 负责 开发人员的角色和责任 哪里需要 Where 指客户 用户和其他投资者也有责任 也是风险承担者 工作将如何 How 进行 便于定义项目的管理和技术策略 资源需要多少 Howmuch 14 4 4软件项目估算 参考教材第26章 项目计划的一个重要的前提是项目估算 估算软件的成本和工作量 软件工作量估算的失真 导致软件成本上升 开发周期延长 使项目管理实效 初步的估算用于确定软件项目的可行性 详细的估算用于指导项目计划的制定 一般以团队的历史经验为基础 同时让团队中的一线人员参与估算 以保证项目计划的可行性 成本及工作量的估算不是一门精确的科学 估算方法有几种选择 基于已完成的类似项目进行估算 使用分解技术以生成项目成本及工作量的估算 使用一个或多个经验模型 15 1 分解技术分解技术采用 分而治之 的策略进行软件项目估算 将项目分解成若干主要功能及相关的软件过程活动 通过逐步求精的方式进行成本及工作量估算 产生工作分解结构WBS WorkBreakdownStructure 然后分别采用基于经验的方法和 或某种估算方法 对分解得到的各块进行成本和工作量估算 进而获得对项目软件的整体估计 如对每块估算以下内容 16 代码行 Loc 的数量 功能点 FP 数量 即估算每个信息域特征 用户输入数 输出数 读写的文件数 查询数 与外部程序和硬件的接口数 并与14个复杂度系数加权计数 实现每个功能所需的人月数 每个软件过程活动所需人月数 估算的具体方法可以采用 17 自底向上估算 细分估算法 将整个项目系统分解成若干个小系统 逐个估算所需的工作量 然后 优点 每部分的估算较为精确 缺陷 难以把握系统级的整合成本 自顶向下估算 周期估算法 按软件开发周期进行划分 估算各阶段或任务单元的成本 然后进行汇总合计 很适合瀑布型软件开发过程 优点 重视系统级的事务成本 如系统集成 质量保证 配置管理等 但是需要估算者对软件工程各个阶段的作业量和相互间的比例具有相当的了解 缺陷 难以识别较低级别上的技术困难 18 2 类比方法又被称为基于案例的推理 Case basedreasoning 方法 主要思想是使用过去类似项目的确切数字 考虑与当前项目的差异程度 来估计当前项目的相应数据 公式为 当前项目估计 参考项目数据 1 差异百分比 其中 差异百分比 当前项目比参考项目多或少的百分比 规模估计可以选取功能 输入输出等作为比较的参考依据 该方法的缺陷 无法搞清以前的项目究竟在多大程度上代表了新项目的特点 19 3 三点法或计划评审技术 PERT 对每个软件部分 如模块 的规模 代码行 估算3个值 悲观 最大 值最可能值乐观 最小 值那么该部分软件的期望规模是 估计期望值 最大值 4 最可能值 最小值 6 例如认为一个模块的软件规模 最大值是100K代码行最小值是50K代行最可能值是60K代码行则所获得的规模估计初始期望值为 50 4 60 100 6 65K代码行 20 4 专家判定法 Delphi或WideBandDelphi 在难以获得经验 历史数据时 可考虑采用专家判定作为一种有效的估计方法 该方法通过专家群体的智慧和交流分析来获得不断趋向准确和一致的估计结果 成立估计小组 首先介绍项目和产品情况 分发软件需求说明书和记录估算值的表格 而后让估计小组成员分别对软件的规模 工作量 成本进行估计 将结果反馈给小组成员 然后分别进行下一轮估计 在反复估计的基础上进行最后的调整 得到最终的估计结果 标准Delphi技术不强调专家们讨论 不利于获得足够的交流信息 也不利于调整自己的估算值 WideBandDelphi将小组会议和Delphi技术结合起来 21 5 经验估算模型经验估算模型用于补充分解技术 并提供了一种有价值的估算方法 该模型是基于经验 历史数据 的 可以用下面的形式表示 d 其中d是要估算的值 如工作量 成本 项目持续时间 之一 是选择出来的独立参数 如被估算的Loc或FP 由经验导出的公式 最著名的是COCOMO模型 称构造型成本模型 COnstructiveCOstMOdel 初期的模型广泛的使用于软件成本估算 发展到反映不同阶段的成本 22 COCOMO模型包括基本模型 中级模型和详细模型3个子模型 是一种自底向上的易于使用的软件项目开发成本和工作量的方法 两个核心方程 用规模估计工作量 用工作量估计项目持续时间 Effort a Size bTdev c Effort d其中 Effort 度量单位为人月 表示开发工作量Tdev 度量单位为月 表示开发进度Size KLOC 表示代码量a b c d是随开发模式而变化的因子 23 初始模型的分类 基本COCOMO模型是静态单变量模型 用源代码行数 LOC 作为自变量的经验函数 计算软件开发工作量 中间COCOMO模型该模型在用LOC为自变量的函数计算软件开发工作量的基础上 用涉及产品 硬件 人员 项目等方面的影响因子调整工作量估算 详细COCOMO模型该模型包括中间COCOMO模型的所有特性 但用上述各种影响因子调整工作量估算时 还要考虑对软件工程过程中每一步骤 分析 设计等 的影响 24 COCOMO针对的软件项目类型 定义的3种开发模式 有机方式 Organic 针对较小的 相对简单的软件项目 开发小组有良好经验并在熟悉的环境中开发 嵌入式方式 Embedded 针对复杂的软件项目 必须在一组严格的硬件 软件及操作约束下开发 借助于经验的机会少 半分离方式 Semi Detached 介于有机方式和嵌入式方式之间 中等的软件项目 具有不同经验水平的项目组成员 25 例如 基本COCOMO的参数 26 模型的扩展 COCOCOM 为了适应新的软件成本估算和过程管理的需要 Boehm根据未来软件市场的发展趋势 于1994年发表了COCOCOM 扩展模型中主要的变化有 使用3层的工作量估算模型 即早期原型层 早期设计层和后体系结构层 使用5个伸缩因子作为项目工作量计算公式中的幂指数 代替了原始模型中按基本 中级 详细模型分别固定指数的方法 对一些成本属性因子进行删除和增加 27 早期原型层 使用对象点 功能点 源代码行作为不同层次模型的参数 对象点只是一种间接软件测量数 如使用以下计数 用户界面上的屏幕数 报表数 建立应用软件需要的构件数 对每个对象实例 如一个屏幕或一个报表 给出三个复杂度权数 简单 中等 复杂 如一个屏幕的权简单为1 中等为2 复杂为3 通过以下公式计算总对象点数 28 初始的对象实例数 加权因子 总的对象点 NOP 当应用基于构件的开发时 估算复用的百分比 对象点计数调整为 NOP NOP 100 复用 100 进而计算 生产率 NOP 人月例如 针对不同级别的开发者经验和开发环境成熟度 给出对象点的生产率 非常低低额定高非常高47132550项目工作量 人月 NOP 生产率 29 6 目前常用的软件成本估算方法 1 任务分解 WBS 并编号 2 规模估算估算每个任务的的规模 人月 求最可能值 3 估算直接成本先估算每个任务的成本EEi 任务i的规模 人力成本参数 万元 人月 直接成本 Ei 4 估算间接成本水电 行政 宣传 培训等 简易算法 间接成本 直接成本 间接成本系数 如1 5 3 5 总估算成本 直接成本 间接成本 软硬件采购费用 6 项目报价项目的成本不是项目的报价 是合同报价的参考值 底线 项目报价 总估算成本 风险利润 30 4 5项目规划 对一个项目有效的管理取决于对该项目进展状况的全面规划 项目开始拟定的计划 基准计划 是整个项目的驱动器 初始计划会随着项目的进展和信息的增多逐步完善 项目规划是一个反复的过程 见下表 31 确定项目的约束条件初步评估各项项目参数定义项目里程碑和可交付的文档while项目没有完成loop拟定项目进度表根据进度表启动各项活动等待 一定的时间 评审项目进展状况修正对项目参数的最初估算更新项目进度表重新协商项目约束条件和可交付的文档if 出现问题 then进行技术评审和可能的修正endifendloop 表4 2项目规划 教材p59 32 1 项目计划 这里的项目计划指开发计划 不包括项目管理的其他计划 该计划包括项目可用的资源 工作分解以及完成工作的进度安排 项目计划应包括以下内容 引言简要论述项目的目标 列出约束条件 如预算 时间限制等 项目的组织开发团队的人员及其分工 风险分析分析风险存在的可能性 避免或降低风险的策略 硬件或软件资源的需求所需的硬件或支持软件 33 工作 任务 分解把项目分解成一系列活动 指定项目里程碑和可交付的文档 项目进度描述各活动间的依赖关系 到达每个里程碑预期所需的时间以及人员在活动中的分配 监控及报告机制提交哪些管理报告 提交时间以及如何跟踪与控制项目 34 2 里程碑和可交付的文档 一个里程碑 milestone 里程标 重要事件 转折点 是一个软件过程活动的终结 每个里程碑处 都应该有一个正式的可提交的输出结果 如一份报告 里程碑是项目内部应取得的阶段性成果 供管理者来检查项目的进展情况 要建立里程碑 软件过程必须分解成一系列相关的基本活动 每个活动都要有相关的输出结果 下表列出微软嵌入式操作系统开发工具开发的里程碑 35 里程碑里程碑定义M06 1 2000初始版本功能开发的代码全部完成M17 1 2000初始版本测试完成AlphaRelease7 15 2000初始版本内部发行 MiniReleases M28 15 2000试用版本功能开发的代码全部完成 如用户能使用 文件的设计与修改 浏览功能组件的分类数据库等 M39 1 2000试用版本测试完成betaRelease9 20 2000试用版本内部发行M410 15 2000所有功能开发完成M511 30 2000候选版本发行 用户能使用产品说明中的所有功能 M612 15 2000最终的全面测试完成 缺陷都被修正 GoldRelease12 20 2000产品正式发行 终结标准都得到满足 每个里程碑的终结标准是衡量该阶段开发结果的标准 M0是产品的最基本和关键的功能 36 下表是M0和M3终结标准的部分举例 表1Alpha版M0的终结标准 ExitCriteria 嵌入式操作系统开发工具中有关进行操作系统设计的功能必须能够从头到尾 按照使用方案进行使用的 开发工具中的为进行操作系统设计的功能组件和提供架构整合的组件必须都完成 并且没有P1 P2级别的Bug 开发工具中的其它非关键性功能不能有P1级别Bug 但可以有P2 P3级别的Bug 主要使用界面中的菜单 对话框 图标等都必须按设计规约中的设计完成 为进行操作系统设计的功能组件都必须完成了单元测试 37 表2Beta版M3的终结标准开发工具的使用界面与使用说明书的解释必须一致的测试应该全部通过 使用界面的所有Bug都必须全部纠正 在初版发行之前至少一个星期开发团队的纠错率 FixRate 必须一直高于发现率 IncomingRate 被修改的缺陷 ResolvedBug 必须全部经过验证 Verified 被证明它们的确是被修正了 Fixed Closed 所有缺陷数量的时间走势必须在发行前15天里一直处于下降状态 未被修改的缺陷数量必须是在过去的10天里一直维持在零附近 38 3 项目进度计划 项目调度 管理者要估算完成各项活动所需的时间和资源 并按照一定的顺序把它们组织起来 即建立项目进度表 工作分解为若干活动 识别活动间依赖关系 并行 顺序 估算活动的资源 为活动分配人员 创建项目进度图表 软件需求 进度图表 建立项目进度计划的过程 39 甘特图和PERT图 甘特图 GanttChart 也称时间表 所有的项目活动及人员分配都可在左边的栏目中列出 水平条表示每个活动的持续时间 当同一时间段中存在多个水平条时 表示活动之间存在着并发 下页图 PERT ProgramEvaluationReviewTechnique 图程序估算评审技术采用的图 也称活动 任务 网络图 表示一个项目的活动流程 刻画了各项活动 活动之间的依赖关系及活动的持续时间 它的最简单形式可当作宏观进度表使用 40 Gantt图可清晰的表达每个任务活动的进展以及并发活动 水平条的颜色既可以表示概要活动和详细活动的分解 也可以表示活动完成的情况 或者活动具有的的弹性时间 但关键路径上的活动没有弹性时间 见教材P55 用一个特定的符号 如黑菱形 表示一个活动的里程碑 以便检查阶段成果和最后成果 41 使用自动工具生成的Gantt图 42 PERT图PERT图另一个重要的用途是用来判断关键路径 路径上可标注时间 关键路径表明了完成该项目可能需要的最小时间 使得能识别最有可能成为瓶颈的活动 该路径上的活动是项目负责人抓的主要工作 非关键路径上的活动延迟 不会导致项目总体进度偏离 还可以通过关键路径法进行包括费用在内的资源最忧化考虑 如压缩关键径路上的工作 以提高效率 每个节点的内容 43 关键路径所需时间 3 16 10 15 1 30 15 90天 图中加黑部分 PERT图 例 44 说明 考虑进度表中的变化 建立进度表时 项目分解为哪些活动以及活动持续的时间往往根据经验数据估算而来 项目进展过程中未预料到的事件 风险 如需求的变化或较晚发现的设计缺陷 都需要修改进度表 可制作短期进度表 在项目进行过程中可用实际花费的时间与估算的时间相对照来修改后面部分 可能需要重新组织活动以缩短关键路径的长度 进度表可有不同的抽象层次 高层进度表反映整个项目的进度 应包括所有可交付产品的期限 底层进度表是活动和时间的分解 可用于指导每个小组的进度 45 工作分解的方式与过程工作分解有纵向 横向两种不同的方法 纵向分解 时间轴分解 即按照工作阶段进行分解 如RUP的初始 细化 构建 移交四个阶段 下页图是一个软件项目按时间轴分解的WBS模版 横向分解 功能轴分解 按照工作产品的功能 用户的视角 进行分解 计划工作是一种管理未来 管理未知的工作 未来变幻莫测 还存在着自身无法掌握的因素 因此需要逐步求精 每个迭代主要解决什么问题 每个迭代的详细计划等到开始这个迭代之前再细化 初始计划阶段给出的估计值应该是一个范围值 随着项目的继续而不断调整与精化 46 某软件系统的构建 项目规划 需求分析 总体设计 详细设计 实现 测试 提交 合同签订 计划编制 计划确认 需求开发 需求管理 系统测试计划编制 开发标准确定 体系结构设计 集成测试计划编制 接口设计 模块设计 单元测试计划编制 编码 单元测试 集成测试 系统测试 缺陷跟踪 验收测试 产品提交 用户培训 按时间轴分解的一个WBS模版 47 例 某物业管理系统 项目的WBS 48 例 用项目管理工具Project2003进行时间管理用Project2003进行时间管理主要有以下功能 输入任务工期建立工期表确定任务之间的依赖关系显示项目的甘特图用关键路径法跟踪项目的进度 与项目的基准线进行比较 以下两页是任务工期表和甘特图 49 50 51 例 企业进销存管理系统 项目开发计划书 目录1 引言1 1项目目标1 2约束条件2 软硬件资源要求3 工作分解4 项目组织4 1小组人员构成4 2成员任务分配5 项目计划进度 52 1 引言1 1项目目标构建一个基于Internet的企业进销存管理系统 是B S结构 利用计算机完成企业经营的进货 库存 销售等各个环节 以帮助企业提高生产率和工作效率 1 2约束条件 略 2 软硬件资源要求需要计算机3台以上 至少256M内存 CPU性能Petium 1 8G 需要配置IISweb站点IE5 0以上浏览器需要安装的软件有 Visostudio6 0 Dreamweaver RationalRose Erwin 53 3 工作分解工作分解结构WBS如下图所示 54 4 项目组织4 1小组人员构成 略 4 2成员任务分配 55 5 项目计划进度见甘特图 采用Microsoftofficeproject绘制 1 显示WBS 56 2 显示具体工期 57 4 6项目跟踪与控制 项目开展阶段管理活动图 UML活动图 58 1 项目启动 进行项目计划2 项目开展 项目开展是一个迭代的过程 进行项目的跟踪与控制 1 收集状况信息的方式 定期报告 非正式的会议和交流 报告工作产品 进度误差等需要及早沟通的信息 里程碑的监督与验证 验证是否在预定时间内完成 项目检查 正式会议 所有开发人员交换活动进展状况 比较各项任务实际开始日期与计划开始日期 代码检查 同事之间的正式代码检查 项目跟踪与控制 续 59 项目跟踪与控制 续 原型示范 原型是为了验证需求或为了评估技术和功能而部分实现的系统 可用来估算初始进度 度量 主要是修正错误数目的度量 即还需要付出多少努力的估量 2 项目再计划根据项目的变化动态更新项目计划 应对一些新的需求 新的变化 风险发生做出响应 或解决问题以适应计划 或调整计划以保证最后按时交付产品 3 风险管理 60 项目跟踪与控制 续 3 项目总结 用户验收 根据项目协议中规定的验收标准对系统进行评价 并通过场景演示 测试系统功能性和非功能性需求 安装 在目标环境下安装 运行系统并提交文档 总结 总结经验教训 建立团队工作效率的历史档案 以便提高个人和团队整体的软件工程能力 61 陕西省自然科学研究计划项目结题报告中的研究工作总结编写提纲 1 主要研究内容及研究方法 2 主要研究结果 特别要说明主要的科学发现和创新之处 并有具体的内容和必要的数据 3 此项研究的科学意义 社会或经济效益 应用前景及学术界的反映和引用 4 与预期计划和目标比较 完成情况及存在问题 附录 资助项目研究成果目录 资助项目完成论著目录 62 4 7风险管理 风险是一些不利因素实际发生的可能性 如 人员跳槽 管理层变更 硬件缺乏 需求变化 描述延迟 低估了系统的规模 CASE工具性能差 技术变更 产品竟争等等 这些因素发生的可能性 因此 风险有两个特点 不确定性和如果发生带来的影响或损失 风险分析时 重要的是量化不确定性的程度以及与每个风险相关的影响的程度 为了实现这一点 必须考虑不同类型的风险 63 风险识别 风险分析 风险缓解 风险监控 潜在的风险列表 优先级高的风险列表 风险避免和应急计划列表 风险评估报告 风险识别 识别可能的项目 技术 商业等类型风险 风险分析 评估这些风险出现的可能性及其后果 风险缓解 制定计划 说明如何避免风险或降低风险对项目的影响 风险监控 不断进行风险评估 随着有关信息的增多及时修正缓解风险的计划 风险管理过程及文档 64 1 风险识别 识别项目可能的风险及类型 类型包括 p58 表4 6 技术风险 软件 硬件 人员风险 经验 培训 变更 机构风险 产品 商业 管理层 开发机构 工具风险 缺陷 不支持 需求风险 客户 用户 估算风险 时间 资金 软件规模 65 2 风险分析 每个风险可定义为一个三元组 r l x 其中 r表示风险 l表示风险发生的概率 x表示风险发生所产生的影响 风险分析需要逐一对每一个风险评估风险发生的可能性以及如果风险发生所产生的后果 风险评估的结果一般不是精确的数字 出现的可能性 非常小 75 风险的严重性 灾难性的 严重的 可容忍的 可忽略的 建立风险表 根据风险的严重程度进行排序 见下表 发生的可能性大 影响严重的风险才会得到进一步的关注 列入随后的风险管理中 66 风险样本列表 67 3 风险缓解 建立有效处理风险的策略 有效的策略必须考虑三个问题 风险避免 降低风险出现的可能性 风险监控 定期评估风险出现的可能性及其影响的变化情况 应急计划 以适当的管理策略减小风险的影响 如果采取主动策略来处理风险 避免风险是最好的策略 避免风险可用风险缓解计划实施 如为了缓解 人员频繁流动 的风险 采取的措施如下 68 在项目开始前采取措施及解决人员流动的相关问题 与现有人员一起讨论流动的原因 对项目进行良好组织 使得开发信息对所有人员透明 定义文档标准 建立相应机制确保文档能及时建立 对所有工作都进行详细评审 使每个成员都熟悉项目的工作和目标 对每项关键技术都指定后备人员 69 4 风险监控 风险缓解是一种风险避免活动 而风险监控是一种风险跟踪活动 对每一个识别的风险定期进行评估 它有三个主要目的 评估一个被预测的风险是否真正发生或发生概率的变化 保证为重大风险而定义的缓解措施被正确的执行 收集能够用于未来风险分析的信息 70 如对 人员频繁流动 的风险应该监控 项目的成员对项目任务压力的一般态度 项目的凝聚力 项目组成员彼此间的