一、概述

1.1 什么是项目管理

1.1.1 项目

项目的概念

为增加某一独特的产品或服务的价值所做的一次性的、有限的努力。

项目的特点

  1. 目标性：结果只可能是一种期望的产品或服务；
  2. 独特性：每一个项目都是唯一的；
  3. 一次性：有确定的起点和终点；
  4. 约束性：每个项目的资源，成本和时间都是有限的；
  5. 关联性：所开展的活动都是密切相互关联的；
  6. 多方面性：一个项目涉及多个相关利益者；
  7. 不可逆转性：不论结果如何，项目结束结果也就随之确定。

构成项目的三要素

范围、时间、成本。

项目集和项目组合

项目集（Program）是多个项目组成的总称，程序管理通过组织有序，协调的方式来管理多个项目。
项目组合（Portfolio）是多个项目集组成的总称，利用资产组合管理，项目组合可以把项目，项目集，资产子组合和业务操作等作为一个组合来达到业务战略目标。
三者关系为相互的包含关系。（课本 P4）

1.1.2 项目管理

项目管理的概念

不同的知识体系都有不同的解释，概括来说，项目管理是组织实施为实现项目目标所必需的一切活动的计划、安排与控制。
有关项目管理的一些小概念：顾客、用户、程序等（课本 P2）

项目管理的构成和约束因素

构成（三要素）：人、过程、工具
约束：范围、时间、预算、质量。

项目管理的起源

最早起源于建筑工程项目 -> 第二次世界大战（曼哈顿计划）开始逐渐形成 -> 上世纪五六十年代诞生了计划评估，审查技术和关键路径方法 -> 1965 年欧洲美国都成了项目管理相关的组织 -> 上世纪七八十年代人们开始将信息系统的方法引入项目管理，相继建立信息管理系统。

项目管理的知识体系

最著名的有 3 个：

  • 美国 PMI 推出的 PMBOK。
  • 英国政府商务部推出的 PRINCE。
  • IBM 的 WWPMM。

1.2 项目管理的本质

单从管理来说，管理可以分为计划和监控两个阶段。在项目的初始化阶段，对项目的管理主要以计划的形式展开，其中包括风险、范围、支出的计划等等，而在执行阶段，则是进行监控，如质量保证等。
项目管理的目标，是保证质量的前提下，协调好质量、任务、成本和进度等要素的相互冲突，获取三者的平衡。对于项目管理的本质，可以从管理对象、管理思想等多个方面进行理解（课本 P7）。

1.2.1 项目失败和管理的联系

软件项目失败涉及到很多软件管理方面的问题，比如进度估计不够全面，人员配置有问题等等，如果有很好的项目管理，这些问题大部分都可以避免。

1.2.2 项目管理的对象

可以概括为 3P ——人员（People），问题（Problem）和过程（Process）。三者的关系可见课本 P10。

1.2.3 项目管理成功的标志

  • 按时交付
  • 成本在预算内
  • 功能达到要求水平
  • 通过客户验收
  • 范围变化最小或可控
  • 没有干扰或严重影响整个组织的主要工作流程
  • 未改变或改变了公司文化

1.2.4 项目管理成功的要素

  • 制定计划
  • 建立组织
  • 配备资源
  • 监控执行
  • 总结提高
    也可以概括为一个公式：目标 + 组织 + 流程 + 工具 + 管理 = 成功。

1.3 项目管理的基本方法

1.3.1 项目管理基本方法的分类

项目管理的基本方法可以分为三种：阶段化管理、量化管理与优化管理。

  • 阶段化管理：将项目的生命周期分为若干个阶段，再根据不同阶段的不同特点进行针对化管理。
  • 量化管理：针对影响项目成功的因素制定指标，收集并分析数据，从而完成对项目的控制和优化。
  • 优化管理：分析项目每部分蕴含的知识，不断吸取教训、总结经验，将知识与实践更好地融合在一起，从而对项目的计划、实施办法等进行优化，获得项目的最佳效益。

1.3.2 项目管理的基本模型

  • 组队模型：用于解决人力资源管理的问题，比如明确相互依赖的角色和责任、沟通机制等。
  • 过程模型：为了解决软件开发过程中管理的问题，比如时间管理，基于里程碑的阶段划分等，保障项目顺利实施。
  • 应用模型：应用于具体领域的需求管理和变更管理等。

1.4 项目管理的生命周期

项目生命周期可以被分为五个过程：启动、计划、执行、控制和结束
一般执行和控制都是同时进行的，因此可以把二者合并为一个阶段，自此也可以归纳为这样的四个阶段：

  • 项目准备和启动阶段
  • 项目计划阶段
  • 项目实施和监控阶段
  • 项目验收和总结阶段

1.5 项目管理的知识体系

PMBOK、PRINCE2、WWPMM 等。

1.6 软件项目管理

1.6.1 软件项目管理的不同之处

  • 软件项目是设计型项目
  • 软件过程模型
  • 需求变化频繁
  • 难以估算工作量
  • 主要的成本是人力成本
  • 以人为本的管理

1.6.2 软件项目管理的目标与范围

根据软件项目的主要任务，可以简单定义项目所需角色以及其工作职责。
项目角色和职能表（课本 P21 表 1-2）

软件项目管理的生命周期和活动范围的比较（课本 P21 表 1-3）

1.6.3 软件项目的分类

可以根据规模、软件开发模式，软件的商业模式等多个角度进行划分（课本 P22）

二、项目的准备和启动

2.1 项目建议书

项目建议书，是项目立项申请报告，重点是如何向有关的投资方或上级阐述立项的必要性。

项目建议书的内容

  • 项目的背景
  • 项目的意义和重要性
  • 项目产品或服务的市场预测
  • 项目规模和期限
  • 项目建设必须的条件，已具备和尚不具备的条件分析
  • 投资估算和资金筹措的设想
  • 市场前景和经济效益初步分析
  • 其它需要说明的情况

2.2 项目可行性分析

2.2.1 可行性分析前提

要首先了解客户的需求和想要达到的目标，对业务需求进行收集和初步分析。
初步分析的内容有：

  • 当前业务流程的分析
  • 主要功能点需求分析
  • 系统的非功能分析需求
  • 对一些限制条件的分析
  • 需求的优先次序

2.2.2 可行性分析因素

大概可以分为三个方面：经济可行性，技术可行性和风险及不确定性。（课本图 P28 ）

2.2.3 成本效益分析方法

回收期法（NCF）：原始投资额/每年现金净流入量。
净现值法（NPV）：用未来报酬的总现值减去原先的投入。公式见课本 P29。

2.2.4 技术以及风险分析方法

  • 技术分析：专家评定法
  • 风险分析：决策树

2.2.5 可行性分析结论

包含的内容有：

  • 项目需求分析概况
  • 可行性分析要素
  • 项目的设计方案
  • 人员配置和培训计划
  • 项目主要风险
  • 可行性研究的结论和建议
  • 其他重要意见
    （阅读课本 P31 - P33 的例子）

2.3 项目投标

项目投标可以分为两个阶段：
第一个是参加竞标的供应商在规定的时间内提供投标书；
第二个是需求方（客户）对投标书进行评估，得出竞标结果。

2.4 软件项目合同条款评审

合同计费的种类

  • 固定总价合同
  • 费用偿还合同
  • 时间和材料合同
  • 功能点计费合同

合同条款评审

评审过程要按照指定、评审、签订合同的顺序进行。

2.5 软件开发模型

瀑布模型

通过一系列的软件活动顺序展开，每个活动都会产生循环反馈。
瀑布模型更适合需求比较完善，不容易改变的软件系统。

快速原型实现模型

对瀑布模型的改进，侧重需求的快速挖掘。其核心是先建造一个系统的初步原型，再以此为基础逐步调整使其满足客户的需求。
快速原型实现模型适合需求难以确定，不断变更的软件系统。

增量模型

通过不断增量交付各个模块来推动开发的模块。增量模型体现了不断迭代开发和增量发布，最终交付符合用户价值产品的方法论。
增量模型支持用户参与，更适合需求复杂难以确定，动态变化的软件系统。

其他还有极限编程，行为驱动开发等，不再过多阐述。

2.6 软件项目等组织结构和人员角色

项目的组织结构

主要有三种类型：职能型、纯项目型、矩阵型。
职能型：项目功能在本职能部门内部讨论，完成再递交给下一个部门。各部门之间由经理进行协调沟通。
纯项目型：项目经理领导，项目成员直接向经理汇报，每个项目是一个独立的自主单位。
矩阵型：前二者的结合，受项目经理和职能经理的双重领导。

软件项目经理

是整个软件项目的核心和灵魂。

QA 与 QC

QA（质量保证）：通过建立和维持质量管理体系来确保产品质量没有问题，关注的是开发的系统。
QC（质量控制）：检验产品质量，保证产品符合用户需求，是产品质量检查者，关注的是产品本身。
QA 和 QC 在项目各个不同阶段的工作内容（课本 P53）

2.7 软件项目的利益相关人

概念

积极参与项目或其利益在项目执行中或成功后受到积极或消极影响的组织或个人。
项目，项目团队和项目干系人的关系（课本 P55）

2.8 软件项目启动动员会

会前准备

确定参会者，会议时间和地点，会议议程，主持人，记录人员，发送会议邀请，以及其他准备等。

会议进行

会议结束

三、项目计划

3.1 什么是项目计划

计划是事先确定项目的目标和实现目标所需要的原则、方法、步骤和手段等完整方案等等管理活动。
软件项目计划的目的是制定一套软件项目实施及管理的解决方案，其主要工作包括确定详细的项目实施范围、定义递交的工作成果，评估实施过程中的主要风险，制定项目实施的（时间）进度计划、成本和预算计划、人力资源计划等。
甘特图是很好的项目计划工具，必须掌握。

软件项目计划的作用

  • 指导软件项目的实施
  • 得到项目相关干系人的承诺
  • 获得资源的承诺
  • 明确项目人员的分工和工作责任
  • 及早了解项目存在的问题和风险
  • 获得组织在项目预算上的承诺
  • 是软件项目实施结果评估的依据
  • 软件项目实施过程的文档化

3.2 项目计划的内容

项目计划内容

  • 目标与范围
  • 项目估算
  • 风险
  • 资源
  • 进度安排

  • 跟踪和控制机制

    输出文档

  • 总体计划
  • 项目范围说明书
  • 项目进度计划
  • 项目成本计划
  • 质量管理计划
  • 项目资源计划
  • 项目风险计划
  • 采购管理计划
  • 配置管理计划
  • 产品集成管理计划

3.3 项目计划方法

滚动计划方法

一种动态编制的计划的方法，按照“近细远粗”的原则进行，先编制一定时期内的计划，再按照具体的执行情况修订计划并逐渐向后移动。
要点：分而治之，逐步求精，动态规划，和谐过渡。

敏捷开发的滚动计划方法

可以分为五个层次：产品愿景、产品路线图、发布计划、迭代计划、每日计划。

WBS 方法

一种将复杂问题分解为简单问题，然后再根据分解结果进行计划的方法。

目的

  • 关注项目目标的澄清职责
  • 建立可视化项目的可交付成果，以便计算工作量和分配工作
  • 改进时间，成本，资源估计的准确度
  • 为绩效测量和项目控制定义一个基准，容易获得项目人员的认可
  • 辅助分析项目的最初风险，明确工作责任

  • 为其他项目计划的制定建立框架或依据

    原则和要求

  • 某项具体任务应该在一个工作包，且只能在一个工作包出现
  • WBS 中某项项目内容是其下所有 WBS 项的总和
  • 一个工作包只由一个人来负责
  • 任务的分解尽量与实际执行方式一致
  • 分解合理，有良好的稳定性和适应性
  • 鼓励项目团队积极参与创建 WBS

  • 所有成果需要文档化

    创建步骤

  • 分解工作任务
  • 定义各项活动/任务之间的依赖关系
  • 安排进度和资源

网络计划技术

一种应用网络模型直观表示软件开发众多工作之间的逻辑关系和时间关系，对完成软件工程项目所需时间、费用、资源进行求解和优化的计划方法。

3.4 如何有效完成项目计划

3.4.1 软件项目特点

  • 软件开发是在不断探索和研究中进行的
  • 最佳实践还不够成熟
  • 软件的自动化对工具的依赖性也很突出
  • 软件构造过程实际是设计过程，每一个软件产品都不同，自动化程度也比较低

  • 软件变化不可避免，但是又难以实现，也会引起文档的频繁修改

    软件项目的问题

  • 时间紧迫性
  • 项目独特性
  • 软件项目的不确定性
  • 软件项目管理可视化差
  • 软件项目生产力依赖于软件人员的潜力挖掘

3.4.2 软件计划的错误倾向

  • 对计划不重视
  • 片面计划
  • 没有考虑足够的风险
  • 计划过于粗糙

3.4.3 项目计划的原则

  • 目标性原则
  • 预防性原则
  • 客观性原则
  • 系统性原则

  • 适应性原则

    制定计划的要点

  • 目标导向 必须要清晰理解描述自己的目标。
  • 重视与客户的沟通 充分听取客户的意见，使交付的产品更符合客户需求
  • 收集足够的信息 掌握更多信息，才能掌握更多有价值的内容以制定计划
  • 客观且使用 做到“知己知彼”
  • 做到完整的循环过程 先自下而上计划，再自上而下计划
  • 关注计划过程 随机应变，不断调整修改计划
  • 要有层次性 比如分为主计划、子计划

3.4.4 计划的输入

  • 项目的目标和需求
  • 项目可用的资源
  • 项目的干系人（相关利益者）
  • 项目涉及的相关技术
  • 质量政策和标准
  • 组织流程
  • 制约因素
  • 假设
  • 历史数据

3.4.5 计划的流程

  • 确定项目的目标以及工作范围
  • 根据质量目标制定质量计划
  • 采用 WBS 方法确定各项的具体任务
  • 针对具体的工作任务估算工作量和需要的资源
  • 制定资源计划，完成风险识别和分析，做出相应规划
  • 进一步完成辅助计划，如采购计划、培训计划等
  • 需要和软件项目负责人沟通、评审，达成一致意见
  • 获得有关方面的批准

3.5 计划各项内容的制定

3.5.1 确定项目范围

软件项目范围的涵义

  • 软件产品规范：明确一个软件产品应该包含哪些特性
  • 项目工作范围：为了交付上面提到的特性，必须要做的工作。

3.5.2 项目管理策略

选用的软件开发模型、技术、合同管理策略、成本管理策略、项目的控制策略和例会制度、信息汇报制度、问题发现及汇报制度等。

3.5.3 软件资源计划

项目资源计划，是指通过分析和识别项目需求，确定出项目需要投入的资源。包括人力资源计划和软硬件资源计划。
人力计划是资源计划的重点。

3.5.4 进度计划

进度计划的基本原则：以目标为导向，考虑进度的影响因素，留有余地，按照最坏的情况打算，不要过于乐观。
进度计划制定的原则如下：

  • 项目的实际参与人员制定进度
  • 尽可能先安排难度高的任务，再做难度低的任务
  • 最好安排为前紧后松的任务节奏
  • 在项目进度中设置若干个里程碑
  • 进度表中需要留下缓冲的时间
  • 发现项目交付的期限不合理，应该调整进度
  • 在需求发生变化时，应该重新评估进度表

3.5.5 成本计划

成本的分类

成本可以按照费用分类，分为：人力资源成本、资产类成本、管理费用和项目特别费用。
也可以将软件项目成本分为直接成本和间接成本：
直接成本是项目本身任务引起的成本，包括为项目购买的设备和软件工具、参与该项目工作的工作人员等；
间接成本是许多项目共享的成本，比如办公楼的租金，水电费用，公司管理费用等。

成本计划的方法

费用预算指在成本估算基础上，针对各项成本估算可能产生的其他费用；
费用控制是指通过采取特定手段，保证实际的费用低于预算。

3.5.6 风险计划

风险计划是为了降低项目风险的损害而分析风险、制定风险应对策略方案的过程，包括识别风险、评估风险或量化风险、编制风险应对策略案等过程。

3.5.7 质量计划

详见课本 P90。

3.6 项目计划工具

Microsoft Project等。

四、项目估算

4.1 项目估算

项目的复杂性和不确定性，是项目估算的挑战。
对于项目管理者来说，不应该被估算所困扰，而应该勇敢面对项目软件估算的挑战，做出一个相对有价值的估算。

4.2 项目估算的基本内容

  • 规模估算
  • 工作量估算
  • 进度估算
  • 风险估算
  • 其他估算：比如需求稳定因子、资源利用效率等。

4.3 基本估算方法

分解方法：采用分而治之的策略，对项目进行分解，再使用逐步求精的方法进行估算，最后通过累加获得整体的估算结果。
在分解法中，WBS 估算法是最常用的方法。WBS 估算法中，有这样两种估算的模式：

  • 自顶向下估算模式：首先估算出来每一级的工作量，然后再层层向下分摊，把上一层工作量分摊到下一层的阶段、活动或任务。
  • 自底向上估算模式：先估算出底层任务的工作量，再层次向上汇总到阶段和项目级。
    算数模型：通过估算模型来生产估算。
    专家判断或经验法：比如德尔菲法。
    比例法：与过去类似的项目进行类比，直接进行类比当前项目的估算结果。

4.4 软件规模估算

4.4.1 德尔菲法

德尔菲法是一种专家评估技术，适用于在没有足够历史数据的情况下来评定软件采用不同的技术或者新技术带来的差异。由于德尔菲法对专家水平的要求较高，通常观点有局限性，通常把德尔菲法同其他方法结合起来。
德尔菲法的流程如下：

  1. 确定问题：明确需要专家判断的问题或研究主题。
  2. 选择专家组：挑选具备相关领域知识的专家，一般5～20人。
  3. 第一次问卷调查：专家独立填写匿名问卷，提供观点或预测。
  4. 汇总分析：对第一次问卷结果进行统计分析，找出共识与分歧。
  5. 反馈信息并再次调查：将分析结果反馈给专家，进行第二轮（或多轮）调查，专家可修改自己意见。
  6. 重复反馈与修正：多轮迭代，直到意见趋于一致或分歧无法进一步缩小。
  7. 得出结论：最终形成专家共识或预测结果。

4.4.2 代码行估算方法

代码行数可以一定程度上反映软件规模，所以可以根据可执行的源代码行数（LOC，line of code）来反映软件规模。

4.4.3 功能点分析方法

功能点分析方法（FPA）是在需求分析阶段基于系统功能的一种规模估算方法。功能点计算的元素有下：

  • 外部输入数：每个用户输入
  • 外部输出数：计算每个用户输出
  • 内部逻辑文件：计算每个逻辑的主文件
  • 外部接口文件：计算每个可读的接口
  • 外部查询数

功能点的计算步骤如下：

  1. 计算基于以下公式的功能数：
    FC = ΣΣwij × Xij

    wij 指根据不同的复杂度而定的五个部分的加权因子，Xij是应用中每个部分的数量。
  2. 用一个已设计的评分标准和方案来评价 14 种系统特性对应用可能产生的影响，然后将这些特性的分数根据以下公式相加得到修正值因子：
    VAF = 0.65 + 0.01 ΣCi

    Ci 是系统特性分数。
  3. 用以下公式计算功能点：
    FP = FC × VAF

4.4.4 标准构件法

软件由若干不同的“标准构件”组成，而这些构建对一个特定领域是通用的，因此可以根据每一个标准构件的出现次数来估计规模。

4.4.5 综合讨论

先采用分解方法，将项目分解到某个层次上，然后再用对比分析方法和经验方法。

4.5 工作量估算

4.5.1 COCOMO 方法

构造性成本模型（COCOMO）是一种精确，易于使用的基于模型的成本估算方法。分为三个层次：

  1. 基本层次（Basic COCOMO）
    根据软件规模估算开发成本和时间，仅考虑项目规模。
  2. 中级层次（Intermediate COCOMO）
    在基本模型基础上，加入影响开发的15个成本驱动因素（如团队经验、产品复杂度等）。
  3. 高级层次（Detailed COCOMO）
    在中级模型的基础上，进一步细化到各个开发阶段，并对每阶段的成本驱动因素分别加权分析。

COCOMO 模型中的基本量

在 COCOMO 模型中，使用的基本量有下：

  • KLOC：代码规模（以千行源代码计）
  • Effort（人月）：开发所需的工作量
  • Time（月）：项目开发周期
  • 项目类型：有机型、有机嵌入型、嵌入型（影响公式参数）

COCOMO 模型中的影响因素

在中级和高级模型中，还需要考虑 15 种影响软件工作量的因素。这分为以下几类：

产品属性

  • 软件复杂度（Product Complexity）
  • 可靠性要求（Required Software Reliability）
  • 数据规模（Database Size）
  • 程序运行时间限制（Execution Time Constraint）
  • 主存储器限制（Main Storage Constraint）

硬件属性

  • 虚拟机波动性（Virtual Machine Volatility）
  • 运行时间性能需求（Computer Turnaround Time）

人员属性

  • 分析员能力（Analyst Capability）
  • 程序员能力（Programmer Capability）
  • 应用经验（Application Experience）
  • 编程语言和工具经验（Programming Language Experience）

项目属性

  • 软件工具使用程度（Use of Software Tools）
  • 项目开发进度要求（Required Development Schedule）
  • 团队协作程度（Team Cohesion）

4.5.2 多变量模型

根据历史的软件项目数据推导出来的一种动态模型。

4.5.3 基于用例的工作量估计

通过用例描述系统的需求更清楚，可以在功能点和用例之间建立良好的关系。

4.5.4 IBM RMC 估算方法

采用的是定量影响因子估算方法和自底向上估算方法。

4.5.5 不同场景的估算方法

在不同阶段使用不同的方法进行估算。

4.6 资源估算

根据 WBS 进行估算

根据 WBS 的分解结果来估算资源，减少人员的沟通成本和人员之间的依赖性。

由工作量和开发周期来计算

一个简单的估算公式如下：

人员数量（人） = 工作量估算（人日）/ 工期估算（日）

资源特征描述

每一类资源都用四个特征来说明：资源描述、可用性说明、需要该资源的时间、该资源被使用的持续时间。
在项目初期就应该建立资源的可用性，包括人力资源、软硬件和可以复用的构件资源等

资源分配给任务

在资源分配的时候，要对资源的可支配时间进行充分的考虑。

项目角色

根据项目的目标可以确定项目管理需要的工作特征和技能，从而确定角色以及责任。

人员分配

分配时考虑以下问题：

  • 谁最有能力完成这项任务
  • 谁愿意来完成这项任务
  • 谁有时间来完成这项任务

4.7 工期估算和安排

4.7.1 工期估算方法

常用的方法是专家（经验）估算法，基于历史的数据进行类比。
当面临高度不确定任务时，采用三点估算法：

计划时间 =（T乐观 + 4 × T可能 + T悲观）/ 6

实际项目中还需要留出一部分的时间以应对项目风险。

4.7.2 特殊场景

使用历史数据来估算开发周期，在假定人员能力接近，人多力量大，项目就可以越早完成时，可以利用以下的公式：

工期估算（日） = 工作量估算（人日）/ 人员数量（人）

4.8 成本估算

4.8.1 成本估算方法

同样可以使用专家评估方法、经验法、比例法和 WBS 方法等。
在成本估算过程中，要紧密结合项目计划，同时预算要避免过于乐观和过于保守。费时较长的项目中，还应该考虑今后的职工工资结构，设备费用以及管理费用是否有较大变化。
在有新员工的项目中，还应该考虑学习成本。

4.8.2 学习曲线

通过缩短学习曲线，可以降低学习成本。

五、项目进度和成本管理

在全球的软件中只有至多 20% 的软件可以正常交付，其主要原因就是对软件项目进度和成本的管理混乱。

5.1 标识项目活动

项目活动就是把项目的工作量分解为容易管理的具体任务，而每一项任务都要有明确的时间和资源限制，它是项目进度表编制的基础。
标识项目活动的方法如下：

  1. 分解项目范围：根据工作分解结构（WBS），将项目目标分解为具体的可交付成果。
  2. 识别可交付成果的工作任务：将每个可交付成果进一步分解为完成它所需的具体任务或活动。
  3. 定义活动：明确每项任务的具体执行步骤，即项目活动，确保每项活动都是可操作的工作单元。
  4. 核对和确认：与项目团队确认活动完整性，确保无遗漏、无重复。
  5. 记录活动清单：将所有活动列入项目活动清单，作为后续进度计划的基础。

5.2 确定项目活动的次序

5.2.1 项目活动之间的关系

活动间的三种关系

结束————开始（Finish-Start）：活动 A 结束后，活动 B 才开始。
开始————开始（Start-Start）：活动 A 和活动 B 一起开始，或者是两个互动有重叠时间。
结束————结束（Finish-Finish）：活动 A 和活动 B 同时结束，或者是两个活动同时结束有重叠时间。

5.2.2 项目活动排序

前导图法、箭线图法。

5.3 关键路径分析

5.3.1 关键路径和关键分析

项目网络中时间最长的路径决定着项目的工期时间，这就是关键路径。

5.3.2 活动缓冲期的计算

任何关键活动的延迟都会导致项目工期的延迟，因此关键活动的缓冲期必须是 0。
其他的计算方法可以看课本 P132。

5.3.3 压缩工期

压缩关键路径的工期是指在现有的资源、成本和任务不变的前提下，针对关键路径进行优化，直到关键路径不能再压缩为止。

5.3.4 准关键活动的标识

  1. 缓冲期小于自身周期的 10%，不加关注的话这样的活动缓冲期容易用完；
  2. 活动路径上只有一两个活动是非关键活动，这两个延迟时间超过缓冲期的时候就变成了关键活动；
  3. 一些有依赖关系的活动，由于依赖关系特殊，没法保证它之前的活动 100% 都会完成；
  4. 根据项目关系的识别。

5.4 网络模型的遍历

正向遍历

按照活动开始和活动结束的顺序进行遍历。

反向遍历

按照活动结束到活动开始的倒序，对网络中的活动进行遍历。

5.5 里程碑

5.5.1 里程碑的定义

里程碑指的是进度上的重要检查点，标志着上一段工作的结束和下一段工作的开始。

5.5.2 建立里程碑的方法

  • 设立合理的里程碑检查点
  • 设定里程碑的完成目标和验证标准
  • 确认里程碑的利益相关人
  • 标识里程碑的进度百分比