第一章 项目管理概述

项目的特征▲

1. 有明确的目标；
2. 项目之间的活动具有相关性；
3. 限定的周期；
4. 有独特性；
5. 资源成本的约束性；
6. 项目的不确定性；

软件项目管理与传统项目管理的区别

1. 软件是纯知识产品。其开发进度和质量很难估计和度量，生产效率也难以预测和保证；
2. 项目周期长，复杂度高，变数多；
3. 软件需要满足一群人的期望；

项目管理的5个标准化过程▲

1. 启动过程组：主要是确定一个项目或一个阶段可以开始了，并要求着手实行；定义和授权项目或者项目的某个阶段；
2. 计划过程组：为完成项目所要达到的商业要求而进行的实际可行的工作计划的设计、维护，确保实现项目的既定商业目标。 计划基准是后面跟踪和监控的基础；
3. 执行过程组：根据前面制定的基准计划，协调人力和其他资源，去执行项目管理计划或相关子计划；
4. 控制过程组：通过监控和检测过程确保项目达到目标，必要时采取一些修正措施。集成变更控制是一个重要的过程；
5. 收尾过程组：取得项目或阶段的正式认可并且有序地结束该项目或阶段。向客户提交相关产品，发布相关结束报告，并且更新组织过程资产并释放资源；

关系：各个过程组通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。其中，计划过程组、执行过程组、控制过程组是核心管理过程组。

---

第二章 项目确立

项目立项

项目立项的定义

立项是要解决做什么的问题，需要确定开发的项目，关注点是效益和利润。

项目立项的流程

项目发起人对发起的项目进行调研、可行性分析，如果认为可以立项，就提交项目立项申请。如果审核不通过就取消立项。如果通过就确定表示项目可以立项。它标志着项目可以正式确立了。

Make or Buy 决策

乙方投标书

项目章程的定义

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

---

第三章 生存期模型

软件生存期模型的选择

预测型生存期模型

瀑布模型的定义

瀑布模型是最经典，最传统的模型。它要求项目严格按照顺序来执行单项的，如同瀑布一样，只能从上往下，不能返回。例如，编码阶段不能重新修改需求分析和设计。

瀑布模型的优点是管理很方便，只需要严格控制阶段的执行顺序。但是缺点也很明显，即项目的可变性无法满足瀑布模型的要求。

适合瀑布模型的项目特征▲

需求很明确、实现方案很明确，适合短期项目

V模型的定义

V模型是瀑布模型的一个变种，也是单项执行的，但是它强调测试与开发的对应关系。例如需求分析与系统测试的对应关系。那么这个对应关系说明了测试与开发是相互伴随的，例如系统测试的依据是需求规格。所以需求分析阶段完成系统测试的一些准备工作，是合理的。

适合V模型的项目特征▲

有与瀑布模型相似的特征，需求、设计不能变更。另外，这类项目一般对系统的安全性、性能要求是比较高的，相应测试工作量就多，成本相对就高。

迭代型生存期模型

迭代模型的定义

迭代模型是通过连续的原型和概念验证来改变产品或结果，每一个新的原型都能带来相关新的反馈和团队见解。

迭代有利于识别和减少项目的不确定性，通过不断地对部分完成或者未完成的工作进行反馈，从而对该工作进行改进和修改。

适合迭代模型的项目特征▲

迭代模型的优点是可以应对需求的变化。

当项目需求不明确，复杂性高，变更频繁，采用迭代生存模型会有优势。

迭代模型可能需要更长的时间，因为它需要不断反馈、修正的过程。

适合增量模型的项目特征▲

需求基本明确,可能发生变化，对于市场和用户把握需要逐步了解，系统改造需要一步一步实施。

Scrum模型

这个图示展示了Scrum模型。可以分三个部分来说明。两层的项目规划（产品订单、冲刺订单），迭代式的软件开发过程，还有4个管理会议。

1. 两层的项目规划：体现为远期的计划和近期的计划。基于远粗近细的原则，远期计划与近期计划通过产品订单和冲刺订单来体现，产品订单是所有需求的唯一来源。所有工作都来源于它。开始阶段是比较模糊的，随着时间推移越来越明确，最高优先等级需求就是当前的冲刺订单。那冲刺订单是当前迭代完成的任务清单。
2. 迭代时开发：通过将整个软件交付过程分成多个迭代周期，一个迭代就是一个冲刺。每个迭代周期2-4周，迭代内任务有详细的分解估算、可以分解到小时。迭代结束时提交一个运行版本。
3. 4个管理会议，包括冲刺规划会议，每日站立会议，冲刺评审会议，冲刺回顾会议。 冲刺规划会议是在每个迭代开始前进行的，要确定任务的目标，本期迭代的需求版本。第二，每日站立会议，每个迭代的过程当中，每天站着开会，说明昨天做了什么，今天准备做什么，有什么风险。冲刺评审会议，每个迭代结束的时候，团队都会召开迭代复审会议，展示本迭代的运行版本并得到反馈信息，同时决定下一个迭代的内容。第四，冲刺回顾会议，每个迭代完成后，要举行冲刺回顾会议，为了进行持续的过程改进。

DevOps模型

由持续交付演变出DevOps，即Development and Operations的组合。它是开发端和运维端全程敏捷的思维。

开发和运维原本有着不同的目标，开发人员 希望尽快提交产品，运维端希望产品的更合理化，例如高性能，高可靠性，减少运维成本。

开发者和运维人员之间的目标上的差异称为混乱之墙（Wall of Confusion）。

DevOps融合开发和维护，形成了一个统一的敏捷过程，旨在帮助这些人员向着一个共同目标来努力。

---

第四章 需求管理

需求规格编写

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

项目规划开发的基础，相当一个开发的图纸。

应当明确各种问题的具体描述，开发方与客户方不能只在各种问题的基本轮廓上达到一致。

基于数据流建模的需求分析方法

面向数据流方法是一种自定向下、逐步求精的分析方法。因此是根据数据流关系来分析需求。

数据流方法的主要技术有，实体关系图、数据流图、数据字典、系统流程图等等。

实体关系图

实体关系图使用实体、属性和关系三个基本的构建单位来描述数据模型。

数据流图

数据流图（DFD）直观地展示了系统中的数据是如何加工处理和流动的，使用四种基本元素来描述系统的行为，它们是过程、实体、数据流和数据存储。

数据字典

如果希望继续对数据流图中的数据进行描述，可以采用数据字典等工具来描述。

数据字典是数据流图的补充工具，它提供了对数据流、数据存储、数据项等元素的精确描述和解释。

系统流程图

系统流程图是一种表示操作顺序和信息流动过程的图表，其基本元素或概念用标准化的图形符号来表示，相互关系用连线表示。流程图是有向图，其中每节点代表一个或一组操作。

用户故事

用户故事模板

用户需求是通过user story来体现的。基于敏捷的方法是从user story用户故事开始的。

用户故事按照一定的语法形式进行表示，不需要使用技术语言来描述。只是以客户能够明白的、简短的形式来表达。

一个典型的描述模板如下，as a type of user，作为某类型的用户，i want some goal，希望达到什么目标， so that some reason，原因如何如何。

用户故事评价

那么如何评价一个story是一个好的story呢？有一些标准是可以参考的。

例如invest。它描述了一个好的story应具有的六个特征，i代表独立特征，n代表可协商的，v代表需求或者业务是有价值的，e和s代表story比较小，足以进行估算，t代表可测试的。

独立性意味着拆分后的用户故事应该相对独立，能够单独进行开发，而不具有强耦合性。这有助于团队并行工作，提高开发效率。

可协商的意思是用户故事不需要一开始就过于详细，它们应该是可以讨论的起点，允许团队成员在开发过程中根据实际情况进行调整。

可测试的意思是用户故事应该是可验证的，即团队应该能够明确地知道何时一个用户故事已经完成并达到了预期的效果。

用户故事迭代优先级

用户故事必须被优先排序：

• 排序是基于业务价值的。
• 业务价值必须得到积极投资回报率（ROI）的支持。
• 还需要考虑风险。

根据用户故事的优先级和计划的估计来选择要包含在下一版本中的用户故事。

MoSCoW模型是在项目管理、软件开发中使用的一种排序优先级的方法，旨在帮助开发人员、产品经理、客户对每个需求交付的重要性达成共识。MoSCoW是一个首字母缩略词。

• M就代表Must Have，是必须实现的功能，否则系统无法运行；或者说是产品成功的关键任务功能。
• S就代表Should have，是虽然很重要，但是也不是必需的功能。
• C就代表could have，通常就是一些扩展性的功能，是客户期望的，但不是必需的。它们可以提高用户体验或客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。
• Won’t have this time，不会有。 最不重要，最低回报项目，或在当下是不适合的要求。不会被计划到当前交货计划中。

---

第五章 任务分解

任务分解概念

任务分解的定义与结果

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

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

WBS的定义▲

WBS是对项目由粗到细的分解过程，是面向可交付成果的对项目元素的分组，组织并定义了整个项目的范围。

工作包的定义

工作包是WBS最低层次的可交付成果，是WBS的最小元素。工作包应当由唯一主体负责。

任务分解方法

类比

虽然每个项目是唯一的，但是WBS经常被“重复使用”，有些项目在某种程序上是具有相似性的。可以采用类似项目的WBS作为参考。

模板参照

许多应用领域都有标准或半标准的WBS，它们可以当作模板参考使用。

自上而下

自上而下方法采用演绎推理方法，从项目的大局着手，然后逐步分解子细目，将项目变为更细、更完善的部分。

自下而上

自下而上方法按从特殊向一般的方向进行，首先定义项目的一些特定任务，然后将这些任务组织起来，形成更高级别的WBS层。

检验任务分解结果的标准▲

1. 最底层的要素是否是实现目标的充分必要条件
2. 最底层要素是否有重复的
3. 每个要素是否清晰完整定义
4. 最底层要素是否有定义清晰的责任人
5. 是否可以进行成本估算和进度安排

---

第六章 成本计划

估算过程概念

软件项目规模的定义

软件项目规模即工作量。例如，软件规划、软件管理、需求分析、系统设计、编码、测试以及后期维护等工作量的总和，即为软件规模。

软件规模单位

代码行、功能点、人月、人天、人年等都可以是规模单位。

软件项目成本

1. 完成软件规模相应付出的代价；
2. 待开发的软件项目需要的资金；
3. 人的劳动的消耗所需要的代价是软件产品的主要成本；

我们可以采用货币单位来表示软件成本。

估算方法

功能点估算法▲

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

UFC

TCF

三点估算法

当我们在估算时需要考虑项目的不确定性和风险的时候，可以采用三点估算法。三点估算方法是基于任务成本的三种估算值来计算预期成本的方法。

这三种估算值是最可能成本、最乐观成本、悲观成本。

• 最可能成本（CM）：比较现实的估算成本。
• 最乐观成本（CO）：最好情况所得到的估算成本。
• 最悲观成本（CP）：最差情况所得到的估算成本。

最可能成本是比较现实的估算成本。但是最可能成本的不是通过严格的概率计算得出的，而是基于项目管理者的经验、专业知识和对项目具体情况的理解。项目管理者会考虑各种因素，如资源需求、工作效率、历史数据以及潜在风险等，来形成一个相对现实的成本估算。尽管最可能成本的估算是一个相对主观的过程，但它仍然是一种有用的工具。最乐观成本是最好情况下所得到的估算成本。

参数估算法▲

IBM模型

COCOMO模型

1. 基本COCOMO-81

2. 中等COCOMO-81

成本基线的理解

成本基线是每个时间阶段内的成本，它是项目管理者度量和监控项目的依据。

成本基线的作用：如果在项目进行过程中通过成本基线发现某个阶段的成本超出预算，则需要研究其原因，必要时采取措施。

---

第七章 进度计划

进度基本概念

进度的定义

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

任务之间的关系

项目各项活动之间存在相互联系与相互依赖关系，根据这些关系安排任务之间的顺序。

进度管理图示

网络图▲

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

PDM (Precedence Diagramming Method)优先图法/节点法 (单代号)网络图

• 构成PDM网络图是节点表示任务，用箭线表示各任务之间的逻辑关系；
• 可以方便的表示活动之间的各种逻辑关系；

ADM (Arrow Diagramming Method)箭线法 (双代号)网络图

• 在ADM网络图中,箭线表示活动(任务)；
• 两个代号唯一确定一个任务；
• 代号表示前一任务的结束，同时也表示后一任务的开始；
• ADM网络图之间是有虚活动的，例如6到5之间；

甘特图

优点：

1. 很容易地看出一个任务的开始时间和结束时间
2. 方便地制定项目计划和进行项目计划控制
3. 简单易用而且容易理解

缺点：

1. 不能反映某项任务的进度变化对整个项目的影响
2. 不能明显地表示各项任务彼此间的依赖关系
3. 不能明显地表示关键路径和关键任务

PERT（工程评估评审技术）

• 利用网络图逻辑关系，确定路径、项目历时；
• 加权算法估算任务历时；
• 估算任务历时存在不确定性时，可以采用PERT方法；

它是基于对某项任务的乐观，悲观以及最可能的概率时间估计；

进度计划编排

关键路径法▲

• 最早开始时间(Early Start, ES)
• 最晚开始时间(Late Start, LS)
• 最早完成时间(Early Finish, EF)
• 最晚完成时间(Late Finish, LF)
• 总浮动(Total Float, TF)：在不影响项目最早完成时间EF的前提下，一个任务可以延迟的时间
• 自由浮动(Free Float, FF)：在不影响后置任务最早开始时间ES(S)的前提下，一个任务可以延迟的时间
• 历时(Duration)

关键路径

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

核心计算公式

• 最早完成时间EF = 最早开始时间ES + 历时duration
• 最晚开始时间LS = 最晚结束时间LF – 历时duration
• 后置任务最早开始时间 ES(S) = 最早完成时间EF + 滞后Lag
• 前置任务最晚完成时间LF(P) = 最晚开始时间LS – 滞后Lag
• 总浮动TF = LS – ES = LF – EF
• 自由浮动FF = ES(S) – EF – Lag

资源优化法

根据资源供需情况，调整活动的开始和完成日期，同时进行资源优化配置的方法。资源平衡和资源平衡都属于资源优化方法。

资源平衡法为了在资源需求与资源供给之间取得平衡，通过对开始日期和完成日期进行调整来协调资源的冲突。资源平衡往往导致关键路径改变。

如果共享资源或关键资源数量有限，或被过度分配，如一个资源在同一个时段内被分配至两个或多个活动，就需要进行资源平衡。

资源平滑法是对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。资源平滑不会改变项目关键路径，完工日期也不会延迟，活动只在其自由和总浮动时间内延迟。

时间压缩法

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

应急法

通过压缩各个任务的时间达到压缩项目时间的目的，不改变任务间的逻辑关系。

平行作业法

通过调整任务间的逻辑关系，解决任务的搭接，压缩项目的时间。

---

第八章 质量计划

软件质量基本概念

软件质量的定义

质量是满足要求的程度，包括符合规定的要求和满足顾客隐含需求。

软件质量的形成

质量形成于产品或者服务的开发过程中，而不是事后的检查（测试）把关等。后期的测试修复不能直接提高质量。

软件质量成本

预防成本：前期质量成本

缺陷成本：后期质量成本

软件质量保证▲

1. 质量保证是为了证明项目将会达到有关质量标准而开展的有计划、有组织的工作活动；
2. 对已经完成工作的一种评价和审核；
3. 通过评价项目整体绩效,建立对质量要求的信任；
4. 提供项目和产品可视化的管理报告，例如《软件设计说明书》质量审计；
5. 这个任务本身并不能提高产品的质量；
6. 一般由质量保证部门人员实施；

质量保证活动-审计

质量审计是质量保证的主要方法。

审计(Audit)是对过程或者产品的一次结构化的独立评估。 将审核的主体与为该主体以前建立的一组规程和标准进行比较，目的是确保真正其真正地遵循了这一过程。

软件项目中常用的质量保证活动：项目执行过程审计、项目产品审计。

软件质量控制

1. 确定项目结果与质量标准是否相符，同时，确定不符的原因和消除方法；
2. 控制产品的质量，及时纠正缺陷，例如：代码评审、单元测试；
3. Is it right done ？
4. 这个任务本身提高产品的质量；
5. 一般由开发人员实施；

质量保证与质量控制的比较▲

质量保证的焦点是过程和产品提交之后的质量监管，是审计产品和过程的质量，保证过程被正确执行，确认项目按照要求进行，属于管理职能。

质量控制是检验产品的质量，是产品推出前的质量把关，保证产品符合客户的需求，是直接对项目工作结果的质量进行把关的过程，属于检查职能。

---

第九章 配置管理计划

软件配置管理基本概念

软件配置管理的定义及作用

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

软件配置项的定义

配置项是配置管理的基础，因为它们代表了需要被追踪和管理的具体实体。

基线的定义

• 基线提供了软件生存期中各个开发阶段的一个特定点, 标志开发过程一个阶段的结束,或者里程碑
• 一个(些)配置项形成并通过审核，即形成基线
• 基线代表了一个经过评审和确认的稳定版本，是进一步开发和修改的基准。通过设立基线，项目团队可以确保所有相关的配置项都达到了预期的稳定状态。
• 基线修改需要按照正式的程序执行

例如，当系统完成了初步设计并准备进入编码阶段时，团队可以创建一个基线，包含此时的所有设计文档和初始代码。

SCCB（软件配置控制委员会）的职责

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

软件配置管理过程▲

1. 配置管理计划

定义了配置管理的目标、流程和规范等等，为其他五个过程提供了指导和支持。

2. 配置项标识、跟踪

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

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

3. 配置管理环境建立

软件配置管理库是用来存储所有基线配置项及相关文件等内容的系统，是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。配置管理环境的建立为其他配置管理过程提供了一个统一的、标准化的工作平台。

4. 基线变更管理

基线代表了软件产品在某个特定时间点的稳定状态，是后续开发和修改的基础。变更管理过程确保对基线的任何变更都经过严格的审查和控制，避免未经授权的修改对软件稳定性造成影响。

5. 配置管理审计

审计过程是对配置管理活动和基线进行检查和评估的重要手段。它能够发现配置管理过程和基线化软件产品可能存在的问题和不足，为改进配置管理提供依据。

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

6. 配置状态统计

状态统计过程提供关于配置项当前状态和变更历史的详细信息。这些信息有助于团队了解软件产品的整体状况，以及在开发过程中发生的变更情况。

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

---

第十章 团队计划

团队定义

• 团队是一定数量的个体成员组织的集合；
• 包括自己组织的人、供应商、分包商、客户等；
• 为一个共同的目标工作，协调一致，愉快合作；
• 最终开发出来高质量的产品；

项目组织结构的主要类型及其各自的优缺点▲

职能型

目前最普遍的项目组织形式。

• 以部门为主体来承担项目；
• 项目成员有多位领导：部门经理和项目经理；
• 这个组织结构适用于主要由一个部门完成的项目或技术比较成熟的项目；

优点：

1. 可以充分发挥职能部门的资源集中优势；
2. 部门的专家可以同时为部门内不同项目使用；
3. 便于相互交流 , 相互支援；
4. 可以随时增派人员；
5. 可以将项目和本部门的职能工作融为一体；

缺点：

1. 项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标；
2. 资源平衡会出现问题；
3. 权利分割不利于各个职能部门的交流和团结协作；
4. 行政隶属关系使得项目经理没有充分的权利；

项目型

• 项目型组织结构是按照项目来临时进行设置的，是一种单目标的垂直的组织方式；
• 以项目经理为首，项目经理具有高度的独立性；

优点：

1. 项目经理对项目可以负全责；
2. 项目目标单一，可以以项目为中心,有利于项目顺利进行；
3. 避免多重领导；
4. 组织结构简单，交流简单、快速；

缺点：

1. 资源不能共享；
2. 各个独立的项目处于相对封闭状态,不利于公司政策的贯彻；
3. 对项目组织的成员缺少一种事业上的连续性和安全感；
4. 项目组织之间处于分割状态，缺少信息交流；

矩阵型

• 职能型组织结构和项目型组织结构的一个混合体；
• 项目经理可以根据项目的需要，从不同的部门中选择合适的项目人员来组成一个临时的项目组；

优点：

1. 专职的项目经理负责整个项目 , 以项目为中心；
2. 公司的多个项目可以共享各个职能部门的资源；
3. 即利于项目目标的实现,又利于公司目标方针的贯彻；
4. 项目成员的顾虑减少了；

缺点：

1. 容易引起职能经理和项目经理权力的冲突；
2. 资源共享也能引起项目之间的冲突；

人员职责计划

• 责任分配矩阵（RAM）：按照项目团队成员进行分工；
• 组织分解结构（OBS）：按照现有的部门或团队来组织，并在每个部门下列出其负责的工作任务；
• 文本型：文本描述

---

第十一章 风险计划

风险基本概念

风险定义

• 风险是对潜在的、未来可能发生损害的一种度量。如果风险确实发生了，则会对项目产生有害的或者负面的影响；
• 软件风险是对软件开发过程及软件产品本身可能造成的伤害或者损失；

风险类型

预测角度

• 已知风险－用户不合作、不现实的交付时间等；
• 可预测风险－人员流动风险、需求变更等；
• 不可预测风险；

项目管理者只能对已知和可预测的风险进行规划，不可预测的风险只能靠企业的能力来承担。

范围角度

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

项目风险的三要素

1. 一个事件
2. 事件发生的概率
3. 事件的影响

定性风险评估方法

• 定性评估风险概率及后果。
• 风险概率度量、风险影响度量。

如高、中、低 / 极高、高、中、低、极低 / 灾难，严重，轻微，可忽略 等等。

定量风险评估方法

盈亏平衡分析

确定项目成本和收益相等时盈亏平衡点。

敏感性分析

考察与软件项目有关的一个或多个主要因素发生变化时，对该项目投资价值指标的影响程度。

模拟

模拟方法是运用概率以及理论统计方法来预测和研究各种不确定性因素对软件项目投资价值指标影响

决策树分析▲

• 决策树分析是一种图表分析方法
• 提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率
• 提供选择一个最佳的方案的依据

风险规划

风险规划的定义

针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响。

回避风险

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

注意事项

1. 对风险有足够的认识；
2. 当其他风险策略不理想的时候，可以考虑；
3. 可能产生另外的风险，例如我们避免采用新技术，可能导致开发出来的产品技术是落后的这样一个风险；
4. 不是所有的情况都适用的；

损失控制

损失预防

风险发生前，为了消除或者减少可能引起风险的各种因素而采取的各种具体的措施。

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

损失控制

风险发生的时候或风险发生后，为了缩小损失幅度所采取的各种措施，通过降低风险事件发生的概率或得失来减轻对项目的影响。

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

---

第十三章 集成计划执行控制

平衡项目四要素关系▲

• 范围(S)
• 质量(Q)
• 进度(T)
• 成本(C)

项目集成计划的内容

范围计划、进度计划、成本计划、质量计划、人力计划、沟通计划、干系人计划、风险计划、变更计划。

---

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

项目范围的执行与核实

范围执行控制的定义

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

控制范围过程的方法

偏差分析

将范围基准与实际的结果进行比较，以确定偏差是否在临界区间内，或者是否需要必要的采取纠正措施。

趋势分析

审核范围偏差随时间变化的情况，以判断范围管理是正在改善还是正在恶化。

范围控制的要点

防止不合理的范围扩张。

1. 范围蔓延：在没有任何机制（例如变更请求）的情况下，对项目范围进行更改。这通常发生在项目执行开始后，客户或其他利益相关者添加新的项目需求，而这些变化往往没有得到适当的审查。
2. 范围镀金：与范围蔓延不同，范围镀金通常发生在项目团队内部。它指的是项目团队在没有客户的明确要求或同意的情况下，对项目的功能或性能进行额外的或超出需求的改进或增强。

进度与成本执行控制的定义

项目进度与成本控制的基本目标是在给定的限制条件下，根据跟踪采集的进度、成本、资源等数据，与原来的基准计划比较，对项目的进展情况进行分析，以保证项目在可以控制的进度、成本、资源内进行，最后期待用最短时间、最小成本，以最小风险完成项目工作。

进度与成本控制过程的分析方法

挣值分析法▲

网络图分析

• 分析网络图中某任务的进度、成本等情况；
• 例如可以采用贝叶斯网络解决项目中的不确定性问题；

质量保证的管理

产品审计

执行过程审计