第一章

  • 上课不是一个项目
  • 项目管理是一系列伴随着项目的进行而进行、目的是为了确保项目能够达到期望结果的一系列管理行为。
  • 项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。
  • 每个项目都有自己的独特性

日常运作存在大量的变更管理，而项目则基本保持连贯性的。（错误）

1. PMBOK

图片.png

项目管理包括： 启动 - 计划 - 执行 - 控制 - 结束 5 个过程组。

项目管理知识体系（PMBOK）包括 ； 管理十个知识领域。
集成 = 范围 = 时间 = 成本 = 质量 = 人力 = 沟通 = 风险 = 采购 = 干系人

2. 软件项目管理过程

项目初始 = 项目计划 = 项目执行控制 = 项目结束
图片.png
2.1 项目初始
项目确立 = 生存期模型
图片.png

2.2 项目计划包括**：
范围 = 成本 = 进度 = 质量 = 配置管理 = 人员与沟通 = 风险 = 合同 = 集成
图片.png

2.3 项目执行控制
集成计划执行控制= 核心计划执行控制= 辅助计划执行控制
图片.png

2.4 项目结束

3 实现项目目标的制约因素有

  • 工作范围
  • 成本
  • 进度计划
  • 客户满意度

第二章 项目初始之项目确立

项目立项 = 项目招投标 = 项目授权

1. 项目立项

1.1 立项流程 ：
开始 -> 识别发起的项目 -> 论证项目(项目评估报告) -> 申请项目(立项建议书)
-> 申请审核(立项评审报告) -> 确定项目立项 -> 结束

1.2 明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可
（不包括项目风险！！！）

1.3 Make or Buy 决策 ：由项目负责人完成

2.项目招投标

招标书主要包括：技术说明、商务说明、投标说明
技术说明主要对采购的产品或者委托项目进行详细的描述。
商务说明主要包括合同条款。
投标说明主要是针对项目背景、标书提交格式、内容、提交时间等做出规定。

2.1 项目招标过程： 甲方招标书定义 -> 乙方项目分析 -> 招标与竞标 -> 合同签署
招标书定义不属于乙方招投标阶段的任务
招标过程中，
甲方包括： 招标书定义、乙方选择、合同签署
乙方包括： 项目分析（建议书）、竞标、合同签署

2.2 乙方项目分析过程：
招标书 - 需求分析 - 技术方案 - 项目规模估算 - 用户评估 - 可行性分析 - 项目风险分析 - 项目初步实施规划

3.项目授权（项目经理 & 项目发起人）

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

3.2 项目经理的主要责任是：开发计划、组织实施、项目控制

第三章 软件生存期模型

生存期模型定义 = 传统生存期模型 = 敏捷生存模型 = 案例分析

  • 描述了开发的主要阶段
  • 定义每一个阶段要完成的主要过程和活动
  • 确定每一个阶段的输入和输出

2. 常用传统生存模型

瀑布 = v型 = 原型 = 增量 = 渐进式

2.1 瀑布： 需求分析 - 设计 - 实施 - 测试 - 维护

  • 需求、方案很明确
  • 短期项目

2.2 v型：用户需求(接受测试) = 需求分析（系统测试） = 系统设计(集成测试) = 详细设计(单元测试) = 编码调试

  • 需求、方案很明确

  • 系统性能、安全等有严格要求


    2.3 原型： 需求分析 = 原型开发 = 原型评价 = 最终系统设计 = 最终系统实现

  • 需求不明确

  • 希望减少项目需求的不明确

2.4 增量：

  • 需求明确，可能发生变动
  • 对于市场和用户把握需要逐步了解
  • 需要一步一步实施

2.5 渐进式开发

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

3. 敏捷生存期模型

  • 敏捷组织提出的一个灵活开发方法
  • 应对迅速变化需求的快速软件开发方法
  • 是一种迭代、循序渐进的开发方法
  • 敏捷开发通过 迭代 和 快速用户反馈 应对管理不确定性和变更

3.1 Scrum模型
3.2 XP(eXtreme Programming)极限编程模型

  • 快速反馈 (Rapid feedback)
  • 假设简单 (Assuming simplicity)
  • 包容变化 (Embracing change)

第四章 软件需求（项目计划 - 范围计划）

软件需求的定义 = 软件需求管理过程 = 需求集建模的基本方法
用户不断增加需求、变更需求

1. 需求的定义：

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

2. 软件需求管理过程

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

2.1 需求获取的方法： 用户要求

2.2 需求分析：
用户的原始需求 = 用户认为的需求 = 用户表述的需求 = PM理解的需求 = 需求分析的结果

需求分析模型： 当前系统 -（模型化）- 物理模型 - （具体化）- 目标系统

2.3 需求规格说明书

2.4 需求验证
正确的、一致的、完全的、实际可行的、必要的、可检验的、可追踪的、最后签字

2.5 需求变更管理
确定需求变更过程

建立SCCB变更控制委员会
影响分析
跟踪受影响的工作产品
建立需求基准版本和需求控制版本文档
维护变更历史记录
跟踪每项需求的状态
衡量需求稳定性

3. 需求集建模的基本方法

原型 = 结构化分析 = 面向对象 = 功能列表法

3.1 原型开发
3.2 结构化分析

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

第5章 任务分解（范围计划）

定义 = 方法 = 基本步骤

第6章 成本估计 （成本计划）

估算过程概念 = 估算方法 = 成本预算

软件项目规模：
软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。
单位有人月、人天、人年

项目规模即工作量

直接成本：与具体项目相关的成本
间接成本：可以分摊到各个具体项目中的成本

2. 估算基本方法

2.1 代码行估算法

2.2 功能点估算法
  • 适合于信息系统估算
  • 与项目使用的语言无关
  • 功能点公式： FP = UFC*TCF

FP：功能点
UFC：未调整功能点计数
TCF：技术复杂度因子

  • 规模 = FP*PE （工时）

PE：生产效率

UFC统计： 外部输入数 外部输出数 外部查询表 外部接口 文件内部逻辑文件

RET 记录元素类型
DET
各个工作单元的成本是预算

2.3 用例点估算法

用例点方法通过分析用例角色、场景和技术与环境因子等来进行软件估算。

对每个角色加权，计算权值
计算未调整的用例权值
计算未调整用例点
计算 技术 和环境因子

计算 调整的用例点

计算工作量

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

类比估算法是从项目的整体出发，进行类推，即估算人员根据 以往完成类似项目 所消耗的总成本(或工作量)来推算
将要开发的软件的总成本(或工作量)，然后按比例将它分配到各个开发任务单元中，是种自上而下的估算形式，也称为自顶向下方法

2.5 参数估算法

COCOMO 81 ？？？？？？？？？？

2.6 专家估计法

1最小ai 2最可能的mi 3最大bi
Ei=(ai+4mi+bi)/6
如果各个专家的估算差异超出规定的范围（例如：15%），则需重复上述过程
E=E1+E2+…En/n

3. 成本预算

成本预算的目的是产生成本基线

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

  • 给任务分配资源成本
  • 给任务分配固定资源成本
  • 给任务分配固定成本

成本 = 直接成 + 间接成本 = 规模 * 成本系数

第七章

历时估计 PERT = (O+4M+P)/6ba
风险 =
标准差（P-O）/6
方差 (（P-O）/6）^2

自由浮动 FFF = ES - EF

总浮动 = LS - ES

3. 任务关联

3.1 任务间的关系
图片.png
3.2 依赖关系：
强制（不可违背）、软依赖（人为制定）、外部依赖（项目与非项目活动间的依赖）
内部依赖

4. 进度管理图示

4.1 甘特图：方便显示开始于结束、不便查看项目间的依赖
4.2 网络图： PDM（节点是活动） ADM（箭线是活动） CDM

6. 历时估计

6.1 定额估计 T = Q/(R*S)
Q 总额 R人 S开发效率

6.2 经验导出模型 图片.png
图片.png左右的参数
6.3 工程评估评审技术（PERT）
图片.png
图片.png
图片.png
西格玛 范围： 68.3 95.5 99.7 99.9

7 进度计划编制

7.1 关键路劲法（CPM）
关键路劲可变

TF 总浮动 FF自由浮动 lag滞后 lead超前
FF 不影响其他活动
TF 不延误项目
TF >=FF
TF = LS -ES = LF - EF
FF = 紧后 ES - 当前 EF

8 进度优化

工期 = 资源 =费用

第八章 质量计划

基本概念 = 过程 = 计划 = 建议

质量管理是项目管理的最高统一 。

1. 概念

质量：质量是满足要求的程度，包括符合规定的要求和满足顾客隐含需求。
软件质量定义：软件质量是软件满足明确说明或者隐含的需求的程度
质量与质量等级

质量标准： 企业或国家定制
质量策略：组织自身的质量指导方针
质量责任：整个组织都有，需要细化

质量成本： 质量成本是由于产品的第一次工作不正常而衍生的附加花费，包括两部分

  • 预防成本： 评估费用、预防费用
  • 缺陷成本： 内部费用、外部费用

2. 质量模型

Boehm = McCAll ISO/IEC9126

2.1 Boehm
可移植性 = 可使用性 = 可维护性
图片.png

2.2 McCall
产品修改 = 产品转移 = 产品运行
图片.png

2.3 ISO/IEC9126模型
图片.png

3. 质量管理过程

对象： 过程、产品
过程：质量计划 = 质量保证= 质量控制

3.1

软件质量计划

  • 确定项目应达到的质量标准(目标)
  • 决定如何满足质量标准的计划安排和方法

质量保证

  • 对项目进行评价
  • 推测能否达到质量指标
  • 建立对项目的信心

质量控制

  • 确定项目结果与质量标准是否相符
  • 确定消除不符的原因和方法

3.2
质量控制QC（前期） 质量保证QA（后期）

  1. 质量保证的焦点在过程；
  2. 质量控制的焦点在产品推出前的质量把关。
  3. 质量保证是通过采取组织、程序、方法和资源等各种手段的保证来得到高质量的软件结果的过程，属于管理职能。
  4. 质量控制是直接对项目工作结果的质量进行把关的过程，属于检查职能。

3.3
质量保证活动

  • 项目执行过程审计
  • 项目产品审计

要点：

  • 对项目进行评价
  • 推测能否达到质量指标
  • 建立对项目的信心

3.4

质量控制活动

  • 技术评审
  • 代码走查
  • 测试

质量控制的要点

  • 检查工作结果
  • 按照标准跟踪检查
  • 确定措施消灭质量问题

4. 质量计划方法

实验计划 = 基准对照 = 质量成本分析 = 流程图法 = 因果分析法

软件质量保证（SQA）计划是在软件开发中 为保证质量水平 所采取的有关质量 控制手段 的大纲

质量计划中可以确定质量保证人员的特殊汇报渠道 。

  1. 实验设计法是一种统计学方法，确定哪些因素可能会对特定变量产生影响。
  2. 基准对照是一种寻找最佳实践的方法，是利用其他项目的实施情况作为当前项目性能衡量的标准。
  3. 质量成本分析也是常用的方法。
  4. 流程图方法可以显示系统各种成分之间的相互关系。
  5. 对于复杂的项目，编制项目计划时可以采用因果分析图。

第九章 质量管理计划（项目计划 - 配置管理计划）

概述 = 管理过程 = 敏捷配置管理 = 配置工具

版本管理、变更管理 是配置管理的主要功能 。
版本控制是软件配置管理的核心功能。

软件配置管理无法确保软件产品的正确性

配置管理最终保证软件产品的 完整性、一致性、追溯性、可控性

变更控制主要关注的是：标识变更，提出变更，管理变更
**
常见的软件配置项：
1.软件需求规格说明书。
2.设计规格说明书。
3.源代码。
4.测试规格说明书等。

1. 概念

1.1 配置项：
指基础架构组件或基础架构有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议电信服务等。

1.2 配置基准线：（相当于存档）
指一个产品或系统在某一特定时刻的配置状况，这种配置不仅体现了其产品或系统的结构，还反映了其具体内
容，使得以后可以按照上述配置重建该产品或系统。

1.3 配置管理数据库：
是指包含每个配置项及配置项之间重要关系的详细资料的数据库。

1.4 最终软件库
是一个存放和保管所有 已批准的最终版本的软件配置的地方，是软件正本存放的物理性仓库或逻辑性存储空间。

1.5 配置管理：
是描述、跟踪、控制和汇报所有IT基础架构中所有设备或系统的管理流程。

1.6 配置控制委员会（也叫变更控制委员会）
负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议的组织。

1.7 软件项目配置管理的责任

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

1.8 软件项目配置管理的目标
1: 软件配置管理的各项工作是有计划进行的。
2: 被选择的项目产品 得到识别，控制 并且可以被相关人员获取。
3: 已识别出的项目产品的更改得到控制。
4: 使相关组别和个人及时了解软件基准的状态和内容。

2. 基本过程

2.1 配置项 标识符：
配置标识是确定哪些内容应该进入配置管理形成配置项，并确定配置项如何命名，用哪些信息来描述该配置项。

步骤（识别 = 命名 = 描述）
(1)识别配置项
(2)配置项命名
(3)配置项的描述

基线也称为里程碑，是为了把各开发阶段的工作划分得更加明确
三种基线最受人们关注：功能基线、分配基线和产品基线

  • 功能基线是指在系统分析与软件定义阶段结束时所确定的各种规格说明。
  • 分配基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求说明。
  • 产品基线是指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发软件产品的全部配置项的规格说明。

一个 些 配置项形成并通过审核，即形成基线 。

实例：表示方法为“项目名称—所属阶段产品名称—版本号”。
“教务管理系统—软件设计—详细设计说明书—V2.2.1“

2.2 配置管理环境 建立

  • 软件配置管理库是用来存储所有基线配置项及相关文件的等内容的系统
  • 是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。
  • 配置库存储配置项（SCI）、修改请求、变化记录等，并提供对库中所存储文件的版本控制。
  • 为不同的人员分配不同的访问配置库的权限。
  • 配置库中的配置项每经历一次改变将形成一个新的版本并被分配相应的版本标志

2.3 基线变更管理

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

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

评估：

  • 软件变更分类
  • 技术影响分析
  • 接口影响分析
  • 进度影响分析
  • 预算影响分析

2.4 配置管理审计
配置审计确认最终的基线和文件是否遵照特定标准或需求，并适当记录审计结果

检查内容至少包括
1 配置库的目录结构是不是符合要求
2 基线对应的必须文件是不是到位
3 达成基线的前提要素（比如里程碑评审，变更申请，问题，bug）是否OK

2.5 配置状态统计
配置状态统计的主要对象是软件配置项的状态、更改申请和对已批准的更改的
实现情况，其任务就是将上述信息持续、完整地记录下来。

2.6 配置管理计划
软件配置管理计划过程是确定软件配置管理的解决方案。
1 配置管理计划角色

2 配置管理计划模板

3. 敏捷项目的配置管理

3.1 全面配置管理: 就是对项目所有的相关产物及其之间的关系都要进行有效管理。

3.2 分支管理策略
基于分支：

  • 开发人员可以随时将自己符合要求的代码提交到主线上，如果在没有必要的条件下，不开分支。同时对主线做持续集成验证，最大程度上保证主线的稳定性。
  • 对每次成功的持续集成都同时对库和集成环境做标签操作,发挥标签库的强大作用。 最大量的减少了合并操作，降低了误差。
  • 配置管理需要随时了解预览版的分支是否需要保留，以为下一次发布升级等做准备。
  • 如果有大型的变更，主线可能会被破坏。
  • 配置管理，变更管理，持续集成，质量管理，发布管理每一个模块要求较高。

基于主干开发

  • 可以随时保证主线上的东西的稳定性，使主线随时可用；
  • 大部分开发人员不会去触碰主线，用分支的方式解决实际开发过程中的一些变更(需求变更或设计变更等) ；  可以从主线上随时拿到已发布的任意一个版本。
  • 开发的时候，持续集成一 直在验证着分支上的稳定性和正确性，而对于发布完成后合并到主线上后，没有对主线进行集成验证，难以保证主线的稳定性；
  • 违背了SVN的规范，把主线库当成了标签库去使用；
  • 采用这种模式发布，主线上的东西是不能损坏的，随时是好的，即使偶尔出现问题也能及时修正，但主线已经完全失去了它做为主干的意义，也很难保证SVN库的一致性。

第10章 软件项目人员与沟通计划（人员与沟通计划）

项目人员计划 = 干系人管理计划 = 沟通计划

团队是一定数量的个体成员组织的集合，包括自己组织的人、供应商、分包商、客户等

1. 组织结构的主要类型

矩阵型：

  • 涉及很多的领域和特性

职能型：

  • 标准的金字塔型组织形式
  • 目前最普遍的项目组织形式

1.1 职能型
项目下面分部门，每个部门有一个经理

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

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

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

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

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

缺点：
1. 容易引起职能经理和项目经理权力的冲突
2. 资源共享也能引起项目之间的冲突
3. 成员面对多重领导

人力资源管理计划描述了项目团队的人员什么时候如何加入到团队中和离开团队。作为项目计划一部分，详细程度因项目而异

2. 干系人管理计划

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

2.2 干系人态度：
首倡者、内部支持者、较积极者、参与者、无所谓者、不积极者、反对者

2.3 识别出干系人，分析和记录他们的相关信息。例如联络信息、他们的利益、参与度、影响力、以及对项目成功的潜在影响。

3. 沟通计划

主要方式： 书面、口头、语言、非语言、正式、非正式、单向、双向
沟通计划包括确定谁需要信息， 需要什么信息， 何时需要信息， 以及如何接收信息等
对于紧急的信息应该通过口头的方式沟通，对于重要的信息采用书面的方式沟通。

3.1 项目沟通的过程
1）沟通需求：需要什么信息，谁需要，何时需要
2）沟通内容：确定沟通格式，内容，详细程度
3）沟通方法
4）沟通职责：谁发谁收
5）沟通时间安排
6）计划维护

3.2 项目沟通的基本原则：及时性 、 准确性、完整性、可理解性

3.3 项目沟通的方式
1.书面沟通和口头沟通
2.语言沟通和非语言沟通
3.正式沟通和非正式沟通
4.单向沟通和双向沟通
5.网络沟通

3.4 沟通渠道 I = E(E-1)/2

3.5 编制项目沟通计划

  • 沟通计划: 确定谁需要信息，需要什么信息，何时需要信息，以及

如何将信息分发给他们

  • 沟通需求分类: 沟通内容、沟通方法 、沟通职责、沟通进度

  • 编制沟通计划的基础是 沟通需求分析

    责任分配矩阵

第11章 软件项目风险计划

概念 = 管理过程 = 管理计划

1. 概念

2. 管理过程

风险识别 = 风险评估 = 风险控制

2.1 风险识别：是试图通过系统化地确定对项目计划的威胁，识别已知和可预测的风险。
德尔菲方法
头脑风暴法
情景分析法
利用风险条目检查表

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

定性风险评估方法
定量风险评估方法

  • 访谈
  • 盈亏平衡分析
  • 决策树分析
  • 模拟法
  • 敏感性分析

3. 风险控制

策略
回避风险

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

注意事项

  • 对风险有足够的认识
  • 当其他风险策略不理想的时候，可以考虑
  • 可能产生另外的风险
  • 不是所有的情况都适用的

转移风险

  • 是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法。
    • 例如:分包、开脱责任合同、保险

自留风险

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

损失控制

  • 损失预防
    • 例如：项目技术培训，预防技术失败
  • 损失抑制
    • 例如：项目人员储备，抑制人员流失的损失

第12章 合同管理

12.1 合同类型
总价合同

  • 固定总价合同
  • 总价加激励费用合同
  • 总价加经济价格调整合同

成本补偿合同

  • 成本加固定费用
  • 成本加激励费用合同
  • 成本加奖励费用合同

工料合同

第13章 集成计划

项目集成计划具有几个特点：综合性 、全局性、内外兼顾性

项目管理过程中的进度目标、成本目标、质量目标、范围目标等各个目标之间是 相互关联和制约的

软件项目管理的最重要的四个要素
范围（S）
质量（Q）
进度（T）
成本（C）

作用
指导项目的实施；
记录项目计划的各种假设前提条件；
提供绩效度量和项目控制的基准；
项目相关利益者之间沟通的基础；
规定项目跟踪评估的时间、内容和范围。

各种信息的综合分析
项目集成计划初步方案的编制
项目集成计划最终方案的编制
项目集成计划的全面综合平衡和审批

项目集成计划风险

  • 缺乏分析和给出项目各方面科学配置关系的方法
  • 缺乏基于全面优化的系统性集成计划与控制的方法
  • 缺乏按公平与效率最佳配置的项目集成管理体制

第14章：核心计划执行控制

项目进展到 20%时， CPI稳定

14.1 范围计划执行控制

  • 范围核实
  • 变更控制

14.2 进度与成本执行控制

  • 图解控制法
  • 挣值分析法
    • 已获取价值分析法，是一种计算实际花在一个项目上的工作量，以及预计该项目所需成本和完成该项目的日期的方法

图片.png
BCWS 计划工作预算费用 Budgeted ，Scheduled
ACWP 已完工作实际成本 Actual，Performed
BCWP 已完成工作量的预算费用 Budgeted，Performed

SV 进度差异 = BCWP - BCWS 已完成工作的预算 - 计划工作的预算
CV 费用差异 = BCWP - ACWP 已完成工作的预算 - 已完成工作的实际预算
SPI 进度效能指标 = BCWP/BCWS 100% （此指标表示完成任务的百分比）
CPI 成本效能指标 =BCWP/ACWP 100% （此指标表示花钱的速度）

项目进展到20%左右，CPI 应该趋于稳定，如果这时CPI的值不理想，则应该采取措施，否则这个值会一直持续下去。

BAC 工作完成的预算成本 （项目计划中的成本估算结果）
TAC 计划完成时间

EAC 项目完成的预测成本 = BAC/CPI。
SAC 项目完成的预测时间 = TAC/SPI
VAC 项目完成的成本差异 = BAC - EAC
VAT 项目完成的时间差异 = TAC - SAC。

TCPI 未完工的成本效能指标 =剩余工作/剩余成本= (BAC - BCWP)/ (Goal - ACWP)

  • 敏捷项目进度与成本控制
  • 偏差管理

14.3 质量计划执行控制
从质量控制图的控制上限和控制下线，可以知道可以接受的过程的偏差范围

  • 质量执行控制
  • 质量保证管理
  • 质量控制管理
  • 质量控制数据分析手段

项目团队中一般有： 项目经理，系统分析员，系统设计员，数据库管理员，支持工程师，程序员，质量保证工程师，业务专家（用户），测试人员等等。