软件项目管理

C1 软件项目管理概述

• 项目管理是指一定的主体为了实现其目标，利用各种有效的手段，对执行中的项目周期的个阶段工作进行计划、组织、协调、指挥、控制，以取得良好经济效益的各项活动的总和。
• 软件项目管理是为了使软件项目能够按照预定的成本，进度，质量顺利完成，而对成本，人员，进度，质量，风险等进行分析和管理的活动。
• 日常运作：连续不断、周而复始的活动，通过效率和有效性体现。
• 项目：临时性、一次性的活动，以目标为导向。
  • 特性：目标性、相关性、临时性、独特性、资源约束性、不确定性
• 项目目标实现的制约因素：项目范围、成本、进度计划和客户满意度。
• 项目管理包括启动过程组、计划过程组、执行过程组、控制过程组、收尾过程组等5个过程组。
• 项目管理知识体系(PMBOK)10个知识领域：
  • 项目整体管理，项目范围管理，项目时间管理，项目成本管理，项目质量管理，项目人力资源管理，项目沟通管理，项目风险管理，项目采购管理，项目干系人管理。

C2 项目确立

• 自造-购买决策

  • 在立项阶段，产品负责人进行自造-购买决策，确定待开发的产品的哪些部分应当采购、外包开发或者自主研发。除了需要考虑自造或者购买的成本，还需要考虑后续的大量费用（维护费、保险费..）。

• 项目经理的职责：①开发计划 ②组织实施 ③项目控制

• 在招投标阶段，甲方过程包括招标书定义、供方选择、合同签署，乙方过程包括项目分析、竞标、合同签署。

C3 生存期模型

• 瀑布模型：适用于软件需求很明确的项目。要求项目所有的活动都严格按照顺序进行，一个阶段的输入是下一个阶段的输入。
• V模型：瀑布模型的一个变种。
• 快速原型模型：从核心方面开始设计和实施最初原型，根据用户反馈改进原型直到被接受。
• 增量式模型：首先构造系统的核心功能，然后逐步增加功能和完善性能。
• 渐进式阶段模型(迭代)：适用于中型或者大型项目，将大项目分成几个小项目来做。

C4软件项目范围计划 - 需求管理

• 需求管理包括需求获取、需求分析/建模、需求规格编写、需求验证、需求变更 5个过程。

  • 需求获取：软件需求具有模糊性、不确定性、变化性和主观性的特点。
  • 需求分析(/建模)：任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型。
  • 需求规格编写：完成的标志是提交一份完整的**软件需求规格说明书(SRS)**。
  • 需求验证：验证需求的正确性、一致性、完整性、可行性、必要性、可验证性、可跟踪性和最后的签字。
  • 需求变更：需求变更的主要工作如下
    • 建立需求基线
    • 确定需求变更控制过程
    • 建立变更控制委员会(SCCB)
    • 进行需求变更影响分析
    • 跟踪所有受需求变更影响的工作产品
    • 建立需求基准版本和需求控制版本文档
    • 跟踪每项需求的状态

• 需求分析方法：①结构化分析方法 ②面向对象的用例分析方法 ③功能列表方法

  • 结构化分析方法：数据流图、数据字典、实体联系图
  • 面向对象的用例分析方法：用例视图、顺序视图、活动视图etc
  • 功能列表方法：对项目的功能需求进行详细说明，基于功能特性及层次关系来描述需求的方法

C5 软件项目范围计划 - 任务分解

• 任务分解的过程：

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

• 任务分解的结果：**WBS(任务分解结构)**。其中，工作包是WBS的最低层次的可交付成果。

  • 工作包应当由唯一主体负责，另外一位项目经理进行计划和执行，或者通过子项目的方式完成。
  • 工作包可进一步分解为子项目的WBS或各个活动。

• 任务分解步骤：

  1. 确认并分解项目的组成要素
  2. 确定分解标准
  3. 确定分解是否详细
  4. 确定项目交付成果
  5. 验证分解的正确性(建立编号)

• WBS类型 分级的树形结构

  • 清单形式
  • 图表形式

• 任务分解方法：

  • 模版参照方法
  • 类比方法：许多项目有相同或者相似的周期。
  • 自顶向下方法：从项目的大局着手，逐步分解子细目。
  • 自底向上方法：首先定义项目的一些特定任务，然后将这些任务组织起来。

• 检验分解结果的标准：

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

• WBS的应用

  • OBS(组织分解结构)
  • CBS(成本分解结构)
  • RBS(风险分解结构)
  • OBS(责任矩阵)
  • CBS(费用分解矩阵)
  • RBS(风险矩阵)

C6 软件项目成本计划

• 成本管理过程：

  • 资源计划编制：确定项目需要的资源种类和数量。
  • 成本估算(中心环节)：编制一个为完成项目各活动所需要的资源成本的近似估算。
  • 成本预算(项目进度)：将总成本估算分配到各单项工作活动上。
  • 成本控制(项目跟踪)：控制项目预算的变更。

• 估算不是很准确的，有误差的。经验(历史)数据非常重要，不要太迷信数学模型。

• 项目规模的单位：

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

• 成本的单位：

  • 货币单位：人命币，美元。

• 软件项目成本：项目规模是成本的主要因素

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

• 成本估算过程：

  • 估算输入：
    • 项目需求、 WBS
    • 历史项目度量
    • 资源要求(资源编制计划)
    • 资源消耗率:如人员成本: 100元/小时
    • 进度规划:项目总进度(一般是合同要求)
    • 学习曲线
  • 估算处理：
    • 直接成本：与具体项目相关的成本。
    • 间接成本：不能归属于一个具体的项目，是企业的运营成本。
  • 估算输出
    • 估算文件：资源、资源的数量、质量标准、估算成本等信息，一般是货币单位。
    • 估算说明：工作范围、估算的基础和依据、估算的假设、估算的误差变动等。

成本估算方法：

• 估算的基本方法

  • 代码行、功能点、对象点、用例点估算法
  • 类比 (自顶向下)估算法
  • 自下而上估算法
  • 参数法估算法
  • 专家估算法

• 代码行估算法：从软件程序量的角度定义项目规模。

  • 要求功能分解足够详细的，有一定的经验数据(类比和经验方法)，与具体的编程语言有关。
  • 缺点：
    • 对代码行没有公认的可接受的标准定义，代码行数量依赖于所用的编程语言和个人的编程风格。
    • 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。
    • 代码行强调编码的工作量，只是项目实现阶段 的一部分。

• 功能点估算法：用系统的功能数量来测量其规模。

  • 与实现产品所使用的语言和技术没有关系。
  • 功能点计算公式：􏰀FP = UFC * TCF
    • UFC: 未调整功能点计数
    • TCF: 技术复杂度因子(调整系数) P105
  • 功能计数项：外部输入，外部输出，外部查询，外部文件，内部文件。

• 类比 (自顶向下)估算法

  • 根据以往的完成类似项目所消耗的总成本(或工作量)，来推算将要开发的软件的总成本(或工作量)，然后按比例将它分配到各个开发任务单元中。
  • 使用情况
    • 有类似的历史项目数据
    • 信息不足(要求不是非常精确)
    • 在合同期和市场招标时
  • 特点：简单易行，花费少。有一定的局限性，准确性差,可能导致项目出现困难

• 自下而上估算法：

  • 利用任务分解结构图，对各个具体工作包进行详细的成本估算，然后将结果累加起来得出项目总成本。
  • 使用情况
    • 项目开始以后，WBS的开发阶段
    • 需要进行准确估算的时候
  • 特点：相对较准确，费时，可能发生虚报现象。

• 参数法估算法：

  • 一种使用项目特性参数建立数据模型来估算成本的方法，是一种统计技术，如回归分析和学习曲线。一个模型不能适合所有情况。
    • 静态单变量模型：面向LOC的估算模型，面向FP的估算模型
    • 动态多变量模型：把工作量看作软件规模和开发时间这两个变量的函数。
  • 理论导出：不成熟阶段。 经验导出：软件估算常常采用。
  • 使用情况
    • 存在成熟的项目估算模型
    • 应该具有良好的数据库数据为基础
  • 特点：比较简单，准确。如果模型选择不当或者数据不准，也会导致偏差。
  • COCOMO模型：
    • COCOMO 81 3个等级的模型：基本，中等，高级。
    • COCOMO 81模型将项目的模式分为有机型、嵌入型和半嵌入型。

• 专家估算法：

  • 由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值,最后得出综合的估算值。
  • 组织者发给每位专家一份软件系统的规格说明 和一张记录估算值的表格，请他们估算 专家详细研究软件规格说明后，对该软件提出3 个规模的估算值：
    • 最小 ai
    • 最可能的mi
    • 最大bi
  • 计算每位专家的 E_i = ( ai + 4mi + bi ) / 6
  • 综合结果后，计算期望值: E_i = E₁ + E₂ + … E_n / n

估算方法总结

• 􏰀初期：类比 专家估算
• 计划阶段 ：自下而上 􏰀 参数模型
• 实施阶段(包括变更发生)： 􏰀 自下而上 􏰀 参数模型

主要考虑三种模型：类比法，自下而上法，参数法。自下而上法费时费力，参数法比较简单。自下向上法与参数法的估计精度相似。类比法通常用来验证参数法和自下而上法的结果。

各种方法不是孤立的，应该注意相互的结合使用

成本预算

• 成本预算是将项目的总成本按照项目的度分摊到各个工作单元中去。
• 成本预算将总的成本安排到各个任务中。
• 􏰁 成本预算的目的是产生成本基线
• 分配项目成本预算主要包括3种情况：
  • 分配资源成本
  • 分配固定资源成本
  • 分配固定成本

C7 项目进度计划

• 任务之间的4种关系：

  • 结束 -> 开始
  • 结束 -> 结束
  • 开始 -> 开始
  • 开始 -> 结束

• 任务间关系的依据：

  • 强制性依赖关系：固有，不可违背的逻辑关系
  • 软逻辑关系：人为，主观，由项目管理人员确定的项目活动之间的关系
  • 外部依赖关系：项目活动与非项目活动之间的依赖关系。如环境测试依赖于外部提供的环境设备等。

• 进度管理图示：

  • 网络图：活动排序的一个输出，展示项目中的各个活动以及活动之间的逻辑关系，可以表达活动的历时。

    • PDM：优先图法 ,节点法 (单代号)网络图。节点表示活动，箭线表示各活动之间的逻辑关系。
    • ADM：箭线法 (双代号)网络图。箭线表示活动，结点表示前一个任务的结束，也表示后一个任务的开始。两个代号唯一确定一个任务。
    • ADM - 虚活动：不是一个实际活动，为了表达逻辑关系而引入的。

  • 甘特图

    • 显示基本的任务信息
    • 可以查看任务的工期、开始时间和结束时间以 及资源的信息。
    • 只有时标，没有活动的逻辑关系

  • 里程碑图

    • 显示项目进展中的重大工作完成
    • 里程碑不同于活动：活动是需要消耗资源的，里程碑仅仅表示事件的标记。

  • 资源图

任务历时估计

• 定额估算法
  • 公式：T = Q / ( R * S )
    • T: 活动持续时间。
    • Q: 活动的工作量。
    • R: 人力或设备的数量。
    • S: 效率，以单位时间完成的工作量表示。
  • 方法比较的简单，容易计算。适合对某个任务的历时估算或者规模比较小的项目。
  • 局限性：没有考虑任务之间的关系。
• 经验导出模型
  • 公式：D = a * E^b
    • D: 月进度
    • E: 人月工作量
    • a: 2~4之间的参数
    • b: 1/3左右的参数，依赖于项目的自然属性。
• 工程评价技术(PERT)
  • 利用网络顺序图逻辑关系和加权历时估算来计算项目历时的技术。当估算项目中某项单独的活动，存在很大的不确定性时采用。
  • 公式：期望值 E = ( O + 4m + P ) / 6
    • O是最小估算值，M是最大可能估算值， P是最大估算值。
• 基于进度表的估算：①可能的最短进度表 ②有效进度表 ③普通进度表
• 基于承诺的进度估算：从需求出发去安排进度，不进行中间的工作量(规模)估计。
• Jones的一阶估算准则：取得功能点的总和，从幂次表中选择合适的幂次将它升幂。
• 其他方法：专家估计方法、类推估计方法、模拟估计方法

进度计划编排

关键路径法： 正推法，逆推法 P143

• 步骤

  • 根据指定的网络图逻辑关系和单一的历时估算， 计算每一个活动的单一的、确定的最早和最迟 开始和完成日期。
  • 计算浮动时间。
  • 计算网络图中最长的路径。
  • 确定项目完成时间

• 概念：

  • ES：最早开始时间 EF：最早完成时间 LS：最晚开始时间 LF：最晚完成时间

  • TF：总浮动 TF = LS - ES = LF -EF

  • FF：自由浮动 FF = ES(S) - EF - lag 即某任务的自由浮动等于它的**(S)**后置任务的ES减去它的EF，再减去它的lag。

    TF(总浮动)：在不影响项目最早完成时间，本任务可以延迟的时间

    FF(自由浮动)：在不影响后置任务最早开始时间，本任务可以延迟的时间。

  • lead：超前 lag：滞后 Duration：任务历时

  • 关键任务：一个任务的最早时间和最迟时间相同。

  • 关键路径：一系列不同任务链条上的关键任务链接成为项目的关键路径。关键路径在网络图中浮动为0，是网络图中的最长路径。

• 正推法

  • 首先建立项目的开始时间
  • 项目的开始时间是网络图中第一个活动的最早开始时间
  • 从左到右，从上到下进行任务编排
  • 当一个任务有多个前置时，选择其中最大的EF作为其后置任务的最早开始日期
  • ES + Duration = EF
  • EF + Lag = ES(s) 后置任务的最早开始时间

• 逆推法

  • 首先建立项目的结束时间
  • 项目的结束时间是网络图中最后一个活动的最晚结束时间
  • 从右到左，从上到下进行计算
  • 当一个前置任务有多个后置任务时，选择其中最小的LF作为其前置任务的最晚完成日期
  • LF - Duration = LS
  • LS - Lag = LF(p)

时间压缩法：应急法/赶工，平行作业/快速跟进法

• 应急法 P146

  • 在不改变活动的前提下，通过压缩某一个或者多个活动的时间来达到缩短整个项目工期的目的。
  • 在最小相关成本增加的条件下，压缩关键路经上的关键活动历时的方法。
  • 进度压缩单位成本 = ( 压缩成本 - 正常成本 ) / ( 正常进度 - 压缩进度 )

• 平行作业法

C8 软件项目质量管理计划

• 质量是产品或者服务满足明确和隐含需要能力的性能特性的总体。等级是对具有相同功能的实体按照不同技术特征进行分类或者分级。无论等级高低，都可以实现自己等级内的高质量。

• 质量管理是确定质量方针、目标和职责，并在质量体系中通过诸如质量计划、质量控制、质量保障和质量改进使质量得以实现的全部管理活动。

• 质量方针是由组织的最高管理者正式发布的一个组织总的质量宗旨和质量方向，是质量管理的核心和出发点。

• 质量体系是为实施质量管理所需的组织结构、程序、过程和资源的总称。

• 质量计划是确定质量的目标和要求， 以及确定采用质量体系要素的目标和要求的活动的过程。

• 质量控制是为达到质量要求所采取的作业技术与活动。 其内容包括 ：确定控制对象、规定控制标准、制定控制方法、 选用检验技术、 处理事故(失控)等等。

• 质量保障是为了保障实体能够满足质量要求 , 并􏰃供足够的证明以表明实体保障能够满足质量要求，而在质量体系中实施，并根据需要进行证实的、全部有计划和有系统的活动。

• 质量改进是为向本组织及其顾客􏰃供更多的收益，在整个组织内所采取的旨在􏰃高活动和过程的效益和效率的各种措施。

• 质量模型：

  • Boehm质量模型：软件产品的质量从3方面考虑— 软件的可用性、可维护性、可移植性。
  • McCall质量模型：通过定义的评价准则对反映质量特征的软件属性进行分级，依此来估计软件质量特征的值。
  • ISO/IEC 9126质量模型：”质量特征—质量子特征—度量因子”的三层结构模型

• 质量控制的7种工具

  • 旧7种工具：统计分析法、数据分层法、散布图、 帕累托图、 􏰂 因果分析图、 􏰂 直方图、 控制图。
  • 新7种工具：关联图法、系统图法、 矩阵图法、 数据矩阵分析法、 网络图法、 PDPC( 过程决策程序图 ) 法、KJ(喜田二郎 ) 法。

PDCA循环

• PDCA 循环的概念最早是由美国质量管理专家戴明􏰃出来的，所以又称 “ 戴明环 ”
• P(plan) — 计划
• D(do) — 执行
• C(check) — 检查
• A(action) — 处理

C9 软件配置管理计划

• 配置管理：记录软件产品的演化过程，确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。最终保证软件产品的完整性、一致性、追朔性、可控性。

  • 主要功能：版本管理，变更管理。

• 软件配置项是项目需定义其受控于软件配置管理的项。每个项目的配置项也许会不同，配置项也有不同的版本。

  • eg. 系统规格说明书，软件需求规格说明书，设计规格说明书，源代码，测试规格说明书

• 基线提供了软件生存期中各个开发阶段的一个特定点，一个(些)配置项形成并通过审核，即形成基线。

  • 基线标志开发过程一个阶段的结束和里程碑。
  • 基线修改只能通过正式的变化控制过程改变。

• 配置控制委员会(SCCB)具体责任如下：

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

• 配置管理的基本过程

  • 配置项标识、跟踪
  • 配置管理环境建立
  • 基线变更管理：变更请求，变更评估，变更批准/拒绝，变更实现
  • 基线审核
  • 配置状态统计
  • 配置管理计划

• 配置管理工具

  • 好的配置管理工具应该具备的功能：并行开发支持，履历管理，版本控制，过程控制，产品发布管理。
  • 常见的配置管理软件
    • Rational ClearCase
    • Hansky Firefly
    • CVS
    • SVN
    • Microsoft VSS

C10 软件项目人员与沟通计划

• 项目组织结构

  • 特点：临时性，目标性
  • 类型：职能型，项目型，矩阵型

• 职能型：项目是以部门为主体来承担项目的，一个项目由一个或者多个部门承担。

  • 优点：

    1.可以充分发挥职能部门的资源集中优势

    2.部门的专家可以同时为部门内不同项目使用

    3.便于相互交流， 相互支援

    4.可以随时增派人员

    5.可以将项目和本部门的职能工作融为一体

  • 缺点：

    1.项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标

    2.资源平衡会出现问题

    3.权利分割不利于各个职能部门的交流和团结协作

    4.行政隶属关系使得项目经理没有充分的权利

• 项目型：部门完全按照项目设置，每个项目以项目经理为首，项目工作会运用到大部分的组织资源。

  • 优点：

    1.项目经理对项目可以负全责

    2.项目目标单一，可以以项目为中心,有利于项目顺利进行

    3.避免多重领导

    4.组织结构简单，交流简单,快速

  • 缺点：

    1.资源不能共享

    2.各个独立的项目处于相对封闭状态,不利于公司政策的贯彻

    3.对项目组织的成员缺少一种事业上的连续性和安全感

    4.项目组织之间处于分割状态,缺少信息交流

• 矩阵型：从不同的部门中选择合适的项目人员组成一个临时项目组，项目结束后买这个项目组也解体了。

  • 优点：

    1.专职的项目经理负责整个项目 , 以项目为中心,

    2.公司的多个项目可以共享各个职能部门的资源

    3.即利于项目目标的实现,又利于公司目标方针的贯彻

    4.项目成员的顾虑减少了

  • 缺点：

    1.容易引起职能经理和项目经理权力的冲突

    2.资源共享也能引起项目之间的冲突

    3.项目成员有多位领导

• 沟通渠道：N ( N - 1 ) / 2 ，其中N为人员总数。

C11 项目风险计划

• 风险的定义：损失发生的不确定性；对潜在的，未来可能发生损害的一种度量。

• 项目风险的三要素：一个事件，事件发生的概率，事件的影响。

• 风险类型：

  • 预测角度：已知风险，可预测风险，不可预测风险。
  • 范围角度：商业风险，技术风险，管理风险，人员风险，开发环境风险，客户风险，产品风险，过程风险。

• 风险识别的方法：

  • 德尔菲方法
  • 头脑风暴法
  • 情景分析法
  • 风险条目检查表
  • 面谈法，SWOT分析

• 风险评估：确定风险发生概率的估计和评价，项目风险后果严重程度的估计和评价，项目风险影响范围的分析和评价，以及对于项目风险发生时间的估计和评价。

  风险R是该风险发生的概率 P 和影响程度 I 的函数，即R = F ( P , I )。

  • 定性风险评估
    • 风险概率：概率值(0~1)，风险概率度量(极高、高、中、低、极低)
    • 风险后果：风险影响项目目标的严重程度(无影响~无穷大)，风险后果度量(极高、高、中、低、极低)
  • 定量风险评估：在定性评估的逻辑基础上，给出各个风险源的量化指标及其发生概率
    • 访谈：确定概率分布模型， 领域专家访谈，信息采集。
    • 盈亏平衡分析
    • 决策树分析

• 风险规划的主要策略：回避风险，转移风险，损失控制，自留风险。

决策树分析

• 决策树分析是一种图表分析方法，提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率，提供选择一个最佳的方案的依据。
• **损益期望值(EMV)**是决策树的一种计算值，根据风险发生的概率计算出一种期望的损益
  • EMV = P(概率) * outcome(收益)
• 利用决策树风险分析技术来分析如下两种情况，并选择其中一种方案：
  • 随机投掷硬币两次，如果两次投掷的结果都是硬币正面朝上，你将获得10元；投掷的结果背面每朝上一次你需要付出1.5元。
  • 随机投掷硬币两次，你需要付出2元； 如果两次投掷的结果都是硬币正面朝上，你将获得10元。

C13 项目集成计划

• 软件项目管理4要素：C = F(S , Q , T)
  • 范围(S) 质量(Q) 进度(T) 成本(C)
  • S 与 C 成一定正比关系
  • Q 与 C 成一定正比关系
  • T 与 C 成一定反比关系
• 项目集成计划的内容
  • 确定项目概貌、团队
  • 明确项目团队内、外的协作沟通
  • 规划开发环境和规范，项目范围说明，编制项目进度计划，项目成本计划，项目质量计划，项目沟通计划，风险计划，项目合同计划，配置管理计划，制定其他辅助计划。

C15 项目核心计划执行控制

• 进度、成本、资源控制：输入计划与实际的进度成本资源，输出进度成本资源的修改决定。

  • 图解控制法
  • 挣值分析法

• 图解控制法：

  • 进度：甘特图

  • 成本：累计费用曲线图

  • 人力物力资源：资源载荷图

    • 优点：可以一目了然地确定项目情况

    • 缺点：只能提供视觉印象，但本身不能提供其他重要的量化信息。

挣值分析法 / 已获取价值分析

• 挣值分析法：对项目实施的进度、成本状态进行绩效评估的有效方法。是计算实际花在一个项目上的工作量，以及预计该项目所需成本和完成该项目的日期的一种方法。

• 输入：

  • BCWS：到目前为止的总预算成本。
  • ACWP：到目前为止所完成工作的实际成本。
  • BCWP：已完成工作的预算成本。
  • BAC：预计总成本，项目计划中的成本估算结果。
  • TAC：预计总耗时，项目计划中完成时间的估算结构

• 输出：

  • 进度差异 SV = BCWP - BCWS
    • =0: 按照进度进行 <0: 落后于进度 >0: 超前于进度
  • 进度效能指标 SPI = BCWP / BCWS * 100%
    • 已完成工作百分比
    • =1: 按照进度进行 >1: 超前于进度 <1: 落后于进度
  • 费用差异 CV = BCWP - ACWP
    • =0: 按照预算进行 >0: 低于于预算 <0: 超出于预算
  • 成本效能指标 CPI = BCWP / ACWP * 100%
    • 费用的支出速度
    • =1: 按照预算进行 >1: 低于预算 <1: 超出预算
  • 项目完成的预测成本：EAC = BAC / CPI
  • 项目完成的成本差异：VAC = BAC - EAC
  • 项目完成的预测时间：SAC = TAC / SPI
  • 未完工的成本效能指标：TCPI = ( BAC - BCWP ) / (Goal - ACWP) = 剩余工作 / 剩余成本
    • Goal是项目希望花费的数目

• BCWP的计算

  • Way1：自下而上 — 很麻烦
  • Way2：规则计算
    • 50/50规则: 当一项工作开始时，假定已经获得一半的价值。
    • 0/100规则: 当一项工作开始时，没有产生价值，直到结束获得全部的价值。
  • Way3：经验加加权法

质量计划控制执行

• 质量保证的管理

  • 3个要点：在项目进展过程中，定期对项目各方面的表现进行评价，通过评价来推测项目最后是否能够达到相关的质量标准，通过质量评价来帮助项目相关的人建立对项目质量的信心。
  • 主要活动
    • 产品审计：根据质量保证计划对项目过程中的工作产品进行质量审查的过程。
    • 执行过程审计：对项目质量管理活动的结构性复查。

• 质量控制的管理

  • 3个要点：检查控制对象是项目工作结果，进行跟踪检查的依据是相关质量标准，对于不满意的质量问题进一步分析原因并确定采取何种措施来消除这些问题。
  • 方法：技术评审，代码走查，测试，返工
  • 策略手段：趋势分析，抽样统计，缺陷追踪

• 质量保证与质量控制的关系：

  • 质量保证着重于过程和产品提交之后的质量监管。— 管理职能
    • 针对一般的、具有普遍性的问题
    • 从总体上提供质量信心
  • 质量控制着重于产品推出前的质量把关。— 检查职能
    • 针对具体产品或者具体活动的质量管理
    • 从具体环节上提高产品的质量

C16 团队人员计划的执行控制

• 项目团队建设：组建阶段、磨合阶段、规范阶段和执行阶段。
• 项目成员的激励：
  • 马斯洛的需求层次理论：生理，安全，社会归属，自尊，自我实现。
  • 海兹伯格的激励理论
    • 激励因素（内在因素）：成就感，责任感，晋升，被赏识、认可
    • 保健因素（外在因素）：工作环境，薪金，工作关系，安全等
  • 麦克勒格的 X理论：用马斯洛的底层需求（生理和安全）进行激励
  • 麦克勒格的Y 理论 ：用马斯洛的高层需求（自尊和自我实现）进行激励
  • 期望理论：相信他们的努力很可能会产生成功的结果，他们也相信自己会因为成功得到相应的回报