软件项目管理

 

第一章 软件项目管理基本概念

项目定义

项目(Project)是为了创造一个唯一的产品或提供一 个唯一的服务而进行的临时性的努力。

项目的特征

• 有明确的目标
• 项目之间的活动具有相关性
• 限定的周期
• 有独特性
• 资源成本的约束性
• 项目的不确定性

项目管理定义

项目管理是一系列的伴随着项目的进行而进 行的、目的是为了确保项目能够达到期望的 结果的一系列管理行为。

软件项目管理

• 是软件工程组成部分
• 确保软件项目满足预算,成本等约束,提交高质量软件产品

敏捷模型（Agile Development）

• 敏捷组织提出的一个灵活开发方法
• 应对迅速变化需求的快速软件开发方法
• 是一种迭代、循序渐进的开发方法

敏捷宣言——4个价值

• 个体和互动高于流程和工具
• 可工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

第二章 软件项目确立

项目立项

明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可 。

项目招投标过程

甲方招标书定义——乙方项目分析——招标与竞标——合同签署

项目章程(Project Charter)

确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。

敏捷项目章程

基本要素:

• 项目目标
• 发布标准
• 预期的工作流

第三章 生存期模型

生存期模型

• 预测型模型
• 迭代模型
• 增量模型
• 敏捷模型
• 混合模型

软件开发模型变迁

作坊式——过程控制——敏捷——DevOps

项目生存期选择

• 预测型:提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。
• 迭代型:允许对未完成的工作进行反馈，从而改进和修改该工作。
• 增量型:向客户提供各个已完成的，可以立即使用的可交付成果。
• 敏捷型:既有迭代，也有增量，便于完善工作，频繁交付。

预测型-模型

• 瀑布模型
• V模型

迭代模型Or:原型模型

增量模型

优点：

• 阶段式提交一个可运行的产品
• 关键的功能更早出现
• 早期预警问题，避免缺陷蔓延
• 阶段性完成可以降低估计失误

敏捷方法

敏捷方法是一个囊括了各种框架和方法的涵盖性术语。

Scrum模型

• 1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。
• 敏捷模型的代表。

XP(eXtreme Programming)极限编程模型

XP(eXtreme Programming)极限编程是由Kent Beck提出的一套针对业务需求和软件开发实践的规则。

精益（Lean）

精益（Lean）模式提倡持续不断地改进, 减少流程中的浪费。

DevOps: Development和Operations的组合

• 全程敏捷思维。
• 开发和运维工作紧密合作。

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（ QA）部门之间的沟通、协作与整合。

混合模型

第四章 软件需求管理

软件需求管理过程

• 需求获取
• 需求分析
• 需求规格编写
• 需求验证
• 需求变更

需求建模的基本方法

• 原型方法
• 基于数据流建模-结构化分析法
• 基于UML建模- 面向对象的用例分析法
• 敏捷需求分析

软件需求定义

需求是指用户对软件的功能和性能的要求。

需求获取

需求分析

需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。

需求规格编写

需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。

需求验证

需求变更管理

① 确定需求变更控制过程

② 建立变更控制委员会(SCCB)

③ 进行需求变更影响分析

④ 跟踪所有受需求变更影响的工作产品

⑤ 建立需求基准版本和需求控制版本文档

⑥ 维护需求变更的历史记录

⑦ 跟踪每项需求的状态

⑧ 衡量需求稳定性

需求建模的基本方法介绍

传统方法: 1. 原型方法 2. 基于数据流建模 3. 基于UML建模

敏捷方法

基于数据流- 结构化分析方法

• 20世纪70年发展起来的面向数据流的方法
• 是一种自顶向下逐步求精的分析方法
• 根据软件内部数据传递、变换的关系进行分析的

基于数据流的技术

• 数据流图(DFD)
• 数据字典(DD)
• 系统流程图

基于UML方法

• 基于面向对象的情景分析方法
• 从用户角度出发考虑的功能需求
• 用例是系统向用户提供一个有价值的结果的某项功能

UML需求视图

• 用例图（Use case Diagram）
• 顺序图（Sequence Diagram）
• 状态图（State Diagram）
• 活动图（Activity Diagram）

基于UML方法综述

• 识别出系统的Actor
• 描述需要的Use case
• 实现用例视图
• 实现顺序视图，活动视图，状态视图等

Product Backlog:产品待办事项列表

• 需求的来源
• 包含产品想法的一个有序列表
• 一个长短不定列表
• 可以是模糊的或是不具体的
• 逐渐完善，越来越明确

Sprint Backlog:待办事项列表的细化

• 按照迭代计划,逐步细化需求,形成Story(故事),
• 鼓励开发人员、测试人员、业务分析人员和产品 负责人合作编写故事,
• 确保所有的故事都足够小,可以持续交付工作。
• 最好每天完成至少一个故事。

第五章 软件项目任务分解

任务分解

任务分解是项目管理的基础

过程：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、 更易操作

结果：WBS（ Work Breakdown Structure: 任务分解结构）

工作包（ Work packages）

• WBS的最低层次的可交付成果
• 工作包应当由唯一主体负责

分解方法

• 类比
• 模板参照
• 自上而下
• 自下而上

WBS任务分解建议

• 最低层是可控的和可管理的，但是不必要的过细
• 每个Work package必须有一个提交物
• 定义任务完成的标准
• 有利于责任分配
• 推荐任务分解到40小时以内,敏捷项目分解到小时

第六章 软件项目成本计划

关于估算

• 估算不是很准确，有误差
• 项目经验数据非常重要
• 不要太迷信某些数学模型

软件项目规模

软件项目规模即工作量 例如：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。

软件规模单位

• LOC(Loc of Code)
• 源代码长度的测量
• FP(Function Point)
• 用系统的功能数量来测量
• 人月
• 人天
• 人年

软件项目成本

• 完成软件规模相应付出的代价。
• 待开发的软件项目需要的资金。
• 人的劳动的消耗所需要的代价 是软件产品的主要成本
• 货币单位

成本估算结果

直接成本

与具体项目相关的成本, 例如：参与项目的人员成本

间接成本

可以分摊到各个具体项目中的成本，例如：培训、房租水电、员工福利、市场费用、管理费、其他等等

传统估算方法

代码行估算法

从软件程序量的角度定义项目规模

1. 与具体的编程语言有关
2. 分解足够详细
3. 有一定的经验数据

代码行技术的主要优缺点

优点：代码是所有软件开发项目都有的"产品"，而且很容易计算代码行数。

缺点：1. 对代码行没有公认的可接受的标准定义

2. 代码行数量依赖于所用的编程语言和个人的编程风格.

3. 在项目早期,需求不稳定、设计不成熟、实现不确定的 情况下很难准确地估算代码量.

4. 代码行强调编码的工作量,只是项目实现阶段的一部分

功能点估算法

• 与实现的语言和技术没有关系
• 用系统的功能数量来测量其规模
• 通过评估、加权、量化得出功能点

Albrecht功能点估算

• 1979年, Alan Albrecht 提出
• 也称为IFPUG(国际功能点用户组织)功能点
• 适用于信息系统

功能点公式

FP =UFC*TCF

UFC：未调整功能点计数

TCF：技术复杂度因子

外部输入(External Inputs： EI)

给软件提供面向应用的数据的项（如屏幕、表单、对话 框、控件，文件等）；在这个过程中，数据穿越外部边界进入到系统内部。

外部输出(External Outputs EO)

向用户提供(经过处理的)面向应用的信息，例如， 报表和出错信息等。

外部查询(External Inquiry EQ)

外部查询是一个输入引出一个即时的简单输出。 没有处理过程。

外部接口文件（External Interface Files EIF's）

外部接口文件是用户可以识别的一组逻辑相关数据， 这组数据只能被引用。用这些接口把信息传送给另一个系统。

内部逻辑文件(Internal Logical Files： ILF'S)

用户可以识别的一组逻辑相关的数据，而且完全存在于应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目。

其他功能点方法

• Mark II 功能点(主要应用在英国)
• COSMIC – FFP 功能点(适用实时系统或者嵌入式系统)

用例点估算法

用例点估算方法的基本步骤

1. 计算未调整的角色权值UAW;

2. 计算未调整的用例权值UUCW ;

3. 计算未调整的用例点UUCP;

4. 计算技术和环境因子TEF;

5. 计算调整的用例点UCP ;

6. 计算工作量( man－hours) 。

类比 (自顶向下)估算法

估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量）。是一种自上而下的估算形式。

类比估算—使用情况

• 有类似的历史项目数据
• 信息不足（例如市场招标）的时候
• 要求不是非常精确估算的时候

自下而上估算法

利用任务分解图(WBS),对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本。

特点

1. 相对比较准确，它的准确度来源于每个任务的估算情况
2. 花费时间

三点估算法

基于任务成本的三种估算值来计算预期成本的方法.

三种估算值

最可能成本（CM）:比较现实的估算成本。

最乐观成本（CO）:最好情况所得到的估算成本。

最悲观成本（CP）:最差情况所得到的估算成本。

参数估算法

• 通过项目数据,进行回归分析,得出回归模型
• 通过参数模型估算(规模)成本的方法。

参数模型综述

• 根据项目数据进行回归分析，得出回归模型作为参数模型。
• 回归分析方法：线性回归，多项式回归，逻辑回归，神经网络，集成方法等。
• 参数模型可以是线性也可以是非线性的。

使用条件

1. 具有良好的项目数据为基础
2. 存在成熟的项目估算模型

特点

1. 比较简单,而且也比较准确
2. 如果模型选择不当或者数据不准, 也会导致偏差

专家估算法

由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值, 最后得出综合的估算值。

专家估算法-Deiphi

1. 组织者确定专家，这些专家互相不见面

2. 组织者发给每位专家一份软件规格说明

3. 专家以无记名对该软件给出3个规模的估算值

① 最小ai

② 最可能的mi

③ 最大bi

4. 组织者计算每位专家的Ei=(ai+4mi+bi)/6

5. 最终可以获得一个多数专家共识的软件规模： E=E1+E2+…En/n（n:表示n 个专家）

6. 如果各个专家的估算差异超出规定的范围（例如： 15%），则需重复上述过程

敏捷估算思维

• 采用轻量级估算方法快速生成高层级估算
• 短期规划可以进行详细的估算

Story point估算方法

Story point（故事点）用来度量实现一个Story 需要付 出的工作量的相对估算。

成本预算

• 成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去
• 成本预算的目的是产生成本基线

分配项目成本预算包括三种情况：

1. 给任务分配资源成本

2. 给任务分配固定资源成本

3. 给任务分配固定成本

分配固定资源成本

当一个项目的资源需要固定数量的资金时，可以向任务分配固定资源成本。

第七章 软件项目进度计划

进度计划的重要性

1. 按时完成项目是项目经理最大的挑战之一
2. 时间是项目规划中灵活性最小的因素
3. 进度问题是项目冲突的主要原因

进度的定义

进度是对执行的活动和里程碑制定的工作计划日期表

任务定义（Defining Activities）

确定为完成项目的各个交付成果所必须进行的诸项具体活动

项目任务的关联关系

项目各项活动之间存在一定的关联关系，根据这些关系安排任务之间的顺序

前置活动（任务）→后置活动（任务）

任务之间的关系

任务之间关联关系的依据

• 强制性依赖关系
• 软逻辑关系
• 外部依赖关系
• 内部依赖关系

进度管理图示

• 网络图
• 甘特图
• 里程碑图
• 资源图
• 燃尽图(Burndown Chart)
• 燃起图(Burnup Chart)

网络图

• 网络图是活动排序的一个输出
• 展示项目中各个活动以及活动之间的逻辑关系

常用的网络图

PDM (Precedence Diagramming Method）

优先图法 ,节点法 (单代号)网络图

ADM (Arrow Diagramming Method )

箭线法 (双代号)网络图

PDM图例

PDM(Precedence Diagramming Method)

• 构成PDM网络图的基本特点是节点(Box)
• 节点(Box)表示活动（任务）
• 用箭线表示各活动(任务)之间的逻辑关系.
• 可以方便的表示活动之间的各种逻辑关系。

ADM图例

ADM（ Arrow Diagramming Method ）

• ADM也称为双代号项目网络图
• 在ADM网络图中,箭线表示活动(任务)
• 两个代号唯一确定一个任务
• 代号表示前一任务的结束,同时也表示后一任务的开始.

ADM图例-虚活动

虚活动

• 为了定义活动
• 为了表示逻辑关系
• 不消耗资源的

历时估算

估计任务、路径、项目的持续时间

历时估算的基本方法 - 传统

• 定额估算法
• 经验导出模型
• CPM(关键路径法估计)
• PERT(工程评估评审技术)
• 预留分析
• 其他
  • Jones的一阶估算准则
  • 类比估算
  • 专家判断
  • 基于承诺的估计

定额估算法

T=Q/(R*S)

T:活动历时

Q:任务工作量

R:人力数量

S:工作效率（贡献率）

e.g: Q=6人天 ,R=2人,S=1 则：T=3天

Q=6人天 ,R=2,S=0.5 则：T=6天

经验导出模型

D:进度(以月单位)

E:工作量(以人月单位)

a:2—4之间

b:1/3左右:依赖于项目的自然属性

建议掌握模型

Walston-Felix模型：

基本COCOMO:

关键路径法估计

• 确定项目网络图
• 每个任务有单一的历时估算
• 确定网络图中任务的逻辑关系
• 关键路径是网络图中最长的路径
• 关键路径可以确定项目完成时间

工程评估评审技术（PERT)

• (Program Evaluation and Review Technique)利用网络顺序图逻辑关系
• 项目中某项单独的活动，存在很大的不确定性
• 加权算法估算任务历时
• 利用网络图逻辑关系，确定路径、项目历时

工程评估评审技术（PERT)-加权算法

• 选定3个估算值
  • O是最小估算值:乐观(Optimistic)
  • P是最大估算值:悲观(Pessimistic)
  • M是最大可能估算(Most Likely)
• 采用加权平均得到期望值E=(O+4m+P)/6

PERT的风险指标

• 标准差δ =(最大估算值-最小估算值)/6
• 方差δ² = [(最大估算值-最小估算值)/6]²

PERT估算举例

PERT估算评价举例

预留分析

应急预留

应急预留是包含在进度基准中的一段储备时间， 用来应对已经接受的已识别风险, 以应对进度方面的不确定性 。

管理预留

管理预留是为管理控制的目的而特别留出的项 目预算，用来应对项目范围中不可预见的风险。

Jones的一阶估算准则

• 估算项目功能点
• 从幂次表中选择合适的幂次将功能点升幂

类比估算

以过去类似项目的实际持续时间为依据，来估算当前项目的持续时间.

专家判断

根据下面专业知识而做出的历时估算

• 进度计划
• 有关估算
• 学科或应用知识

基于承诺的进度估算

• 要求开发人员做出进度承诺
• 进行中间的工作量（规模）估计

优点：有利于开发者对进度的关注

历时估算的基本方法 - 敏捷

开发速度稳定前- 举手表决

开发速度稳定后

• 基于故事点生产率的估算
• 基于迭代生产率的估算

传统估算方法:

1. 定额估算法
2. 经验导出模型
3. CPM(关键路径法估计)
4. PERT(工程评估评审技术)
5. 基于承诺的进度估计
6. Jones的一阶估算准则

敏捷估算方法:

1. 举手表决
2. 基于故事点生产率的估算
3. 基于迭代生产率的估算

进度编制的基本方法

任务滞后(Lag)

任务超前(Lead)

作用：

1）解决任务的搭接

2）对任务可以进行合理的拆分

3）缩短项目工期

关键路径法

• 最早开始时间(Early start)
• 最晚开始时间(Late start)
• 最早完成时间(Early finish)
• 最晚完成时间(Late finish)
• 总浮动（ Total Float）
• 自由浮动（Free Float）

浮动时间(Float)：浮动时间是一个任务的机动性,它是一个任务在不影响其它任务或者项目完成的情况下可以延迟的时间量。

总浮动与自由浮动

总浮动（ Total Float）： 在不影响项目最早完成时间的前提下，一个任务可以延迟的时间

自由浮动（Free Float）：在不影响后置任务最早开始时间的前提下，一个任务可以延迟的时间

关键路径（Critical Path ）

• 网络图中最长的路径
• 关键路径是决定项目完成的最短时间。
• 时间浮动为0（Float=0）的路径
• 关键路径上任何活动延迟，都会导致整个项目完成时间的延迟
• 关键路径可能不止一条

时间压缩法

时间压缩法是在不改变项目范围的前提下缩短项目工期的方法

应急法--赶工（Crash）

• 在最小相关成本增加的条件下，压缩关键路经上的关键活动历时的方法
• 赶工也称为时间-成本平衡方法

1. 进度压缩单位成本方法线性关系

进度压缩单位成本=（压缩成本-正常成本）/(正常进度-压缩进度)

2. Charles Symons(1991)方法进度压缩比普通进度短的时候，费用迅速上涨

进度压缩因子=压缩进度/正常进度

压缩进度的工作量=正常工作量/进度压缩因子

平行作业法--快速跟进

改变活动间的逻辑关系，并行开展某些活动.

提前量方法

资源优化

• 根据资源供需情况，调整活动的开始和完成日期。
• 资源优化配置，形成最有效的利用资源
  • 使资源闲置的时间最小化
  • 尽量避免超出资源能力

资源平衡

• 为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。
• 通过调整任务的时间来协调资源的冲突
• 资源平衡往往导致关键路径改变

资源平滑法

资源平滑法是在项目编排中进行资源的优化配置， 保证资源最优化、最优效 。

资源平滑不会改变项目关键路径，完工日期也不会延迟。活动只在其自由和总浮动时间内延迟.

Agile Planning:敏捷计划

Release planning - 发布计划 – 远期计划 – 粗计划.

Iteration planning - 迭代计划 – 近期计划 – 细计划

软件项目进度问题(SPSP)模型

软件项目进度问题（Software Project Scheduling Problem，SPSP）模型是在给定的项目任务工作量及其关系和资源限制下，对项目确定合适的人员安排，以保证项目的时间最短、成本最小。

目标：时间最短、 成本最低

目标函数：

目标结果：f(x)达到最小

第九章 软件项目配置管理计划

软件配置管理基本概念

配置管理定义

• 记录软件产品的演化过程
• 得到精确的产品配置
• 最终保证软件产品的完整性、一致性、追朔性、可控性

配置管理的主要功能

• 版本管理
• 变更管理

软件配置项

SCI:software configration item

受控于软件配置管理的款项

基线定义

• 基线提供了软件生存期中各个开发阶段的一个特定点, 标志开发过程一个阶段的结束,或者里程碑
• 一个(些)配置项形成并通过审核，即形成基线
• 基线修改需要按照正式的程序执行

软件配置控制委员会(SCCB)

• 评估变更
• 批准变更申请
• 在生存期内规范变更申请流程
• 对变更进行反馈
• 与项目管理层沟通

软件配置管理过程

配置管理基本过程

1.配置项标识、跟踪

将软件项目中需要进行控制的部分拆分成SCI

建立配置项的对应关系，以便于进行跟踪和版本控制.实现数字化管理

2.配置管理环境建立

建立配置管理库

软件配置管理库是用来存储所有基线配置项及相关文件的等内容的系统，是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。

3.基线变更管理

基线修改应受到控制，这种变化要经SCCB授权，按程序进行控制并记录基线修改的过程。

• 变更请求
• 变更评估
• 变更批准/拒绝
• 变更实现

4.配置管理审计

• 配置管理过程审计
• 基线审计

5.配置状态统计

• 被批准的配置项
• 变更请求的数量
• 配置项的所有请求的变化状态
• 配置项所有被批准的变更实现状态
• 配置管理系统以及SCCB在运作中发生异常的次数等等

6.配置管理计划

• 人员职责（确定SCCB等）
• 配置项定义
• 基线定义
• 版本控制（说明配置管理工具）
• 定义变更控制系统

敏捷项目配置管理

• 敏捷的一个重要特征是持续交付，因此，配置管理是重要的要素
• 敏捷需要全面配置管理

全面配置管理的基本要求

• 代码和编译构建产物的配置管理
• 应用的配置管理
• 环境的配置管理

代码和编译构建产物的配置管理

• 制定有效的分支管理策略
• 配置管理工具

制定有效的分支管理策略

• 基于分支的开发
• 基于主干的开发

基于分支的开发

开发都在分支上提交，并且可能有多个并行分支，直到快要上线时甚至上线后才合并到主干

基于主干的开发

所有提交到主干上，提交后自动触发持续集成进行验证和快速反馈

持续交付更倾向使用基于主干的开发模式

第十章 软件项目团队计划

人员职责计划

组织结构的主要类型

1. 职能型

2. 项目型

3. 矩阵型

人员职责计划

责任分配矩阵(RAM)

组织分解结构 (OBS)

其它,例如文本型

干系人管理计划

干系人（Stakholder）

干系人（stakeholder）是能影响项目决策、活动或者结果的个人、群体或者组织，以及会受到或者自认为会受到项目决策、活动或者结果影响的个人、 群体或者组织。

沟通计划

项目沟通的方式

1. 书面沟通和口头沟通

2. 语言沟通和非语言沟通

3. 正式沟通和非正式沟通

4. 单向沟通和双向沟通

5. 网络沟通

项目沟通活动的分类

• 内部与外部
• 正式和非正式
• 渠道（上级沟通,下级沟通,横向沟通）
• 书面与口头

项目沟通计划

沟通计划是确定谁需要信息，需要什么信息， 何时需要信息，以及如何将信息分发给他们。

敏捷团队规划

敏捷的角色

产品负责人(Product owner )

团队促进者(Team facilitator )

跨职能团队成员(Crossfunctional team member )

Scrum 角色

Product Owner（产品负责人）

Scrum Master （ Scrum主管）

开发团队

敏捷团队

最有效的敏捷团队往往由三到九个成员组成。(黄金人 数5-9人)

理想情况下，敏捷团队应该集中在一个工作场所工作。

团队成员100%为专职成员, 协同工作

敏捷鼓励自我管理团队

仆人式领导

仆人式领导是通过对团队服务来领导团队的

注重理解和关注团队成员的需要和发展

仆人式领导为团队赋权

旨在使团队尽可能达到最高绩效。

敏捷方法提倡高度透明

邀请所有相关方参与项目会议和审查

将项目信息发布到公共空间

第十一章 软件项目风险计划

风险管理过程

风险定义

风险是对潜在的、未来可能发生损害的一种度量， 如果风险确实发生了，则会对项目产生有害的或者负面的影响。

软件风险对软件开发过程及软件产品本身可能造成的伤害或损失

风险类型

预测角度

已知风险－Known known

可预测风险-Known unknown

不可预测风险-unknown unknown

范围角度

商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险、产品规模风险等。

项目风险的三要素

风险事件

事件概率

事件影响

风险管理的四个过程

1)风险识别

风险识别是识别风险事件, 系统化地确定对项目计划的威胁，识别已知和可预测的风险。

2)风险评估

对风险事件发生概率的评估，对项目风险影响的评估，给出项目风险排序。

3)风险规划

针对风险分析的结果，制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响

4)风险控制

风险控制是在项目执行过程中实施和监控风险计划，同时，不断进行风险识别、风险分析、风险规划的过程。

风险管理计划

风险识别方法

• 德尔菲方法
• 头脑风暴法
• 情景分析法
• 利用风险条目检查表

风险评估

分析

风险发生的概率（P）

风险对项目的影响（I）

风险值，R=F(P,I)

确定优先次序

按风险值排序

确定最需要关注的TOP风险

风险评估的方法-定性风险评估

定性评估风险概率及后果

风险概率

风险概率度量：

• 高、中、低
• 极高、高、中、低、极低
• 不可能，不一定，可能和极可能

风险影响

风险影响度量

• 高、中、低
• 极高、高、中、低、极低
• 灾难，严重，轻微，可忽略

风险评估的方法-定量风险评估

1. 盈亏平衡分析

2. 敏感性分析

3. 模拟

4. 决策树分析

决策树分析

决策树分析是一种图表分析方法

提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率

提供选择一个最佳的方案的依据

决策树分析与EMV ( Expected Monetary Value)

EMV (损益期望值)是决策树的一种计算值

根据预期结果、发生的概率计算出一种期望的损益

例如： 某行动方案成功的概率是50%，收益是10 。EMV=10*50%=5

风险规划的主要策略

1. 回避风险

2. 转移风险

3. 损失控制

4. 自留风险

回避风险

回避风险是对可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案

例如：放弃采用新技术

转移风险

转移风险是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法。

例如：分包、开脱责任合同、保险

损失控制

损失预防

例如：项目技术培训，预防技术失败损失预防

损失抑制

例如：项目人员储备，抑制人员流失的损失

自留风险

由项目组织自己承担风险事故所致损失的措施。

敏捷项目风险计划

敏捷项目风险应对方法

损失预防与损失抑制策略

跨职能项目团队(识别风险)

选择迭代内容 (选择风险小的)

频繁评审增量产品

持续测试可以及早发现问题

客户参与可以减少需求变更的风险

敏捷项目存在风险

没有长期计划,识别一些风险比较困难.

没有长期规划，存在变更

第十四章 项目核心计划执行控制

范围管理 - 传统与敏捷

范围管理

范围执行控制是监督项目的范围状态，管理范围基准变更的过程。

分析技术

1. 偏差分析
2. 趋势分析

范围控制要点

防止不合理的范围扩张

• 蔓延(Scope Creeping)
• 镀金(Gold-plating)

敏捷项目范围管理

把需求列入未完项

不断构建和评审原形系统

通过发布多个版本来明确需求

性能分析的主要技术

• 图解控制法
• 挣值分析法
• 网络图分析
• 敏捷方法

图解控制法

资源图、进度图、成本图

1）项目甘特图

2）延迟图

3）时间线

4）费用曲线图

5）资源图偏差

偏差分析与控制

精确记录任务消耗的实际时间

量化任务的计划偏差

持续时间偏差 (%) =(( 实际持续时间 - 计划持续时 间 )/ 计划持续时间 )*100

进度偏差 (%)=(( 实际结束时间 - 计划结束时间 )/ 计划持续时间 )*100

对计划偏差进行根因分析

挣值分析法

输入

① BAC(Budget At Completion) 预算总值（估算结果）

② TAC(Time At Completion) 预计完成时间

③ BCWS(Budgeted cost of work scheduled) 计划工作成本

④ ACWP(Actual cost of work performed) 实际工作成本

⑤ BCWP(Budgeted cost of work performed) 已获值(Earned Value)

挣值分析输出

进度差异:SV（Schedule Variance）=BCWP-BCWS

=0：按照计划进度进行

<0：落后于进度

>0：超前于进度

成本差异:CV（Cost Variance )=BCWP-ACWP

=0：按照计划预算进行

<0：比预算差

>0：比预算好

进度效能指标 SPI (Schedule Performance Index)= BCWP/BCWS

=1：按照计划进度进行

>1：超前于进度

<1：落后于进度

成本效能指标 CPI (Cost Performance Index)= BCWP/ACWP

=1：按照计划预算进行

>1：低于预算

<1：超出预算

EAC (Estimate At Completion)=BAC/CPI 预测项目完成成本

SAC(Schedule At Completion )=TAC/SPI 预测项目完成时间

成本偏差:VAC=BAC-EAC

时间偏差:VAT=SAC-TAC

未完工指数 TCPI=剩余工作/剩余成本 =(BAC-BCWP)/(Goal-ACWP)

网络图分析

分析网络图中某任务的进度成本情况

可以采用贝叶斯网络解决项目中的不确定性问题

敏捷方法