软件项目管理案例教程-韩万江-期末复习

软件项目管理-完整版

第1章

1.5敏捷项目管理

敏捷项目管理的特点

• 可以应对迅速变化的需求，是一种以人为核心的、迭代的、循序渐进的开发方法。
• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 相应变化胜过遵循计划
• 轻量级的软件开发方法

第2章

2.2 项目立项

项目正式启动前需要做哪些工作，

1、识别发起的项目

2、论证项目-做出项目评估报告

3、申请项目-项目股立项申请建议书

4、申请审核

怎样判断是自造还是购买

• 制造差异
• 维护差异
• 判断软件生存周期是否可以承受

2.3项目招投标

项目招投标流程是什么？

1. 甲方招标书定义
2. 乙方项目分析
3. 招标与竞标
4. 合同签署

第3章

要了解下述模型的特点以及各自的优缺点，给你一个项目，你要能判断是采用哪种生存期模型来做

3.2预测型生存期模型

3.3迭代型生存期模型

实践中常常将迭代型生存周期模型直接等同于原型模型

• 原型法又称快速原型法，基本的思想是——在限定的时间内，用最经济的方法开发出一个可实际运行的系统模型，用户在运行使用整个原型的基础上，通过对其评价，提出改进意见，对原型进行修改，统一使用，评价过程反复进行，使原型逐步完善，直到完全满足用户的需求为止

特点：

1. 实际可行
2. 具有最终系统的基本特征
3. 构造方便、快速、造价低

优：

1. 增加用户与开发人员的交流
2. 用户在项目开发中占主导作用
3. 满足用户的动态需求
4. 降低开发风险

缺：

1. 因为用户的参与，使得忽视原型对实际环境的适应性等技术问题，所以不适合大型、复杂项目开发
2. 对于技术层面远大于其分析层面的问题不宜使用原型法

3.4 增量型生存期模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

特点：

1. 最大特点就是将待开发的软件系统模块化和组件化
2. 增量模型是瀑布模型和原型进化模型的综合
3. 如同原型进化模型一样，增量模型逐步地向用户交付软件产品，但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件，而只是新增加的构件

优：

1. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
2. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
3. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整

缺：

1. 待开发的软件系统可以被模块化，如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦
2. 对项目管理人员管理全局水平有较高要求
3. 对开发人员也有要求

3.5 敏捷型生存期模型（重点）

软件项目管理 3.5.敏捷生存期模型 - 知乎 (zhihu.com)

敏捷软件开发过程是不断地进行反馈，动态调整需求，最终达成目标，这种自适应性的特征使得敏捷开发的产品更符合实际的需求。

敏捷的工作模型：

项目需求来自于待开发的功能列表，初始需求可以很粗，但是要有优先级，每个迭代是按照优先级来进行，从中选择部分内容进行迭代。

敏捷模型包括：

SCRUM

SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

Kanban（看板管理）

看板管理在工业企业的工序管理中，以卡片为凭证，定时定点交货的管理制度。

XP（极限编程）

极限编程注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。

DevOps:

DevOps 是通过人、流程和技术的有机整合，以协作、自动化、精益、度量和共享文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。

Scrum模型

分三个部分：

1.两层的项目规划：
体现为远期的计划和近期的计划，始阶段是比较模糊的，随着时间的推移越来越明确。

最高的优先级需求就是冲刺订单，是当前迭代要完成的任务清单。

2.迭代式的软件开发过程：

通过将整个软件交付的过程分为多个迭代周期，一个周期就是一个Sprint。每个迭代的周期2-4周，迭代内任务有详细的分解估算，可以分解到小时。迭代结束时提交一个运行版本。

3.四个管理会议：

包括迭代规划会议，每日站立会议，迭代评审会议，迭代回顾会议。

1. 每日站立会议是每个迭代的过程当中，每天站着开会，说明昨天做了什么，今天准备做什么，有什么风险。
2. 迭代评审会议是每个迭代结束的时候，团队都会召开迭代复审会议，展示本迭代的运行版本，既得到反馈信息，同时决定下一次迭代的内容。
3. 迭代回顾会议是在每个迭代开始前进行的，要确定任务的目标，理清迭代的需求版本。

敏捷型开发模型：

1. 优点是通过快速、持续地交付有用的软件来满足客户的需求。
2. 面对面交谈是最好的交流方式。
3. 业务人员和开发人员之间的密切日常合作。

缺点：

1. **对于某些软件交付物，特别是大型软件交付物，很难在软件开发生命周期开始时评估所需的工作。 **
2. 缺乏对必要的设计和文件的重视。
3. 如果客户代表不清楚他们想要的最终结果，项目很容易偏离轨道。

第4章

4.2 需求管理过程

需求管理的过程都有哪些？

需求获取、需求分析、需求规格编写、需求验证、需求变更管理

需求管理过程，为什么要做需求变更控制，如何做好变更管理？

因为需求变更是导致项目失败的主要原因之一，所以需求变更控制可以避免频繁变更需求的混乱局面。

1、****建立需求基线

2、****确定需求变更控制过程

3、****建立变更控制委员会

4、****进行需求变更影响分析

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

6、****建立需求基本版本和需求控制版本文档

7、****跟踪每项需求的状态、衡量需求稳定性。

4.4敏捷项目需求分析

什么是产品待办事项列表，什么是用户故事，用户故事的写法？给你一段描述，要能根据描述提炼用户故事。

产品带办事项列表是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕它来进行

As a user

I want some goal

So that some reason

第5章

5.2任务分解过程和方法

给你一个项目描述，你要能对其进行WBS分解，分解有两种形式，一种是按照功能分解一种是按时间线分解

5.4敏捷项目的任务分解

为什么要做任务分解，怎么做任务分解？

为什么：

使项目变得更小更易管理、更易操作，这样可以提高估算成本、时间和资源的准确性，市工作变得更易操作，责任分工更加明确。

步骤

1****、确认并分解项目的组成要素

2****、确认分解标准、按照项目实施管理的方法分解、而且分解的标准要统一

3****、确认分解是否详细，是否可以作为费用和时间估计的标准，明确责任

4****、确定项目交付成果

5****、验证分解正确性，验证分解正确后，建立一套编号系统

第六章

6.1.3成本估算过程

成本估算的过程及成本估算过程中的主要困难都有哪些？

过程：

1. 估算输入
2. 估算处理
3. 估算输出

6.2 成本估算方法

6.2.4，6.2.10, 6.2.12不用看，其他的都有哪些，都看看是怎么样计算的

6.2.1 代码行（LOC）

从软件程序量的角度定义项目规模。
要求功能分解足够详细。
一般是根据经验数据估计实现每个功能模块所需的源程序行数，然后把源程序行数累加起来，得到软件的整体规模。
有一定的经验数据（类比和经验方法）。
与具体的编程语言有关。
优点：

直观、准确（在有代码的情况下）、易于计算（可使用代码行统计工具）。

缺点：

1. 对代码行度量没有公认的标准定义。
2. 代码行数量依赖于所用的编程语言和个人的编程风格。
3. 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。

6.2.2 功能点（FP）

• 用系统的功能数量来测量其规模，与实现产品所使用的语言没有关系。
• 对系统的外部功能和内部功能进行计数。
• 根据技术复杂度因子（权）对它们进行调整，产生产品规模的度量结果。

功能点计算公式

FP =UFC*TCF
UFC(Unadjusted Function Point Count)未调整功能点计数

UFC = 每项计数乘 权重，然后相加。

TCF = 0.65 +0.01（sum(Fi)）

TCF(Technical Complexity Factor) 技术复杂度因子
UFC的计算方法
首先计算功能计数项，对以下五类元素计数：

1. 用户输入：由用户输入的面向应用的数据项。
2. 用户输出：向用户提供的输出数据项。
3. 用户查询：要求系统回答的交互式输入。
4. 外部接口文件：与其它系统的接口数据文件。
5. 内部文件：系统使用的内部固定文件。
6. 然后对各功能计数项加权并求和，得到UFC。

功能点度量的优缺点

优点：

1. 软件系统的功能与实现该软件系统的语言无关；
2. 在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，因而该方法可以较好地克服基于代码行的软件项目规模表示方法的不足。

缺点：

1. 功能点计算主要靠经验公式，主观因素比较多；
2. 没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；计算功能点所需的数据不好采集。

6.2.3 用例点估算

太多了，可以考虑pass,详细看链接：

软件项目管理 6.3.用例点估算法_因子_级别_权值 (sohu.com)

6.2.5 自下而上估算

自下而上估算法的前提是任务分解完成，既WBS完成。估算的时候从最低层的工作包开始估算，然后自下而上，将估算值进行累加，最后得出上一层的估算结果。

自下而上估算—特点：

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

软件项目管理 6.5.自下而上估算法 (qq.com)

6.2.6.三点估算法

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

这三种估算值分别是：最可能成本，最乐观成本，最悲观成本。

6.2.7.参数估算法

软件项目管理 6.7.参数估算法 (qq.com)

6.2.8.专家估算法

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

其中Deiphi专家估算法是著名的专家估算法：

1. 这些专家互相不见面。
2. 专家详细研究软件规格说明后，进行无记名估算。

Deiphi专家估算法基本步骤如下：

1. 组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格，请专家估算。
2. 每个专家详细研究软件规格说明后，对该软件提出3个规模的估算值，即最小值ai、最可能值mi、最大值bi。
3. 组织者对专家表格中的答复进行整理，计算每位专家的估算值Ei=（ai+4mi+bi）/6。然后计算出所有专家的期望值Ei=(E1+E2+…+En)/n。
4. 综合结果后，再组织专家无记名填表格，比较估算偏差，并查找原因。
5. 上述过程重复多次，最终可以获得一个多数专家共识的软件规模。

6.2.9.猜测估算法

一个比较古老的估算方法，看名字。

6.3敏捷项目成本估算

看看快速故事点估算方法

6.5案例分析里面的6.5.1和6.5.2

第七章

项目计划：进度计划（核心）

知识点：

1.关于进度估算

时间是一种特殊的资源，以其单向性，不可重复性，不可替代性而有别于其他资源。
时间是项目规划中灵活性最小的因素，进度问题又是项目冲突的主要原因，尤其在项目的后期。

2.任务确认

一个工作包可以通过多个活动完成。
任务之间的依赖关系：
项目各项活动之间存在相互联系与相互依赖关系
任务（活动）之间的排序依据主要有强制性依赖关系、软逻辑关系、外部依赖关系等。
外部依赖关系指的是项目活动与非项目活动之间的依赖关系。
“软件编码完成之后，我才可以对它进行软件测试”，这句话说明了强制性依赖关系

3.进度管理图示

甘特图 可以显示任务的基本信息，使用该类图能方便地查看任务的工期，开始和结束时间
以及资源的信息。
PDM 网络图中箭线表示的是任务之间的逻辑关系，节点表示的是活动。
ADM网络图中，箭线表示 活动或者任务 。

4.任务历时估计

工程评估评审技术采用加权平均的公式是 （O+4M+P）/6，其中 O 是乐观值，P 是悲观值，M 是最可能值。
当估算某活动时间，存在很大不确定性时应采用 PERT估计。

5.进度计划编排

（1）关键路径法
关键路径决定了项目在给定的紧前关系和资源条件下完成项目所需的最短时间。
在项目的进行过程中，关键路径（最早时间和最晚时间相同的任务，组成的路线）是可变的。
基本术语：

• ES（最早开始时间）
• LS（最晚开始时间）
• EF（最早结束时间）
• LF（最晚结束时间）
• 浮动时间：浮动是在不影响项目完成日期的条件下，一个活动可以延迟的时间量。

EF = ES + duration
LS = LF - duration
（总浮动）TF = LS - ES = LF - EF
ES = EF + Lag
TF可以决定进度的灵活性
Lag将延长项目的进度

（2）确定CPM网络图（正推法和逆推法）

正推法：确定最早开始时间ES和最早完成时间EF

逆推法：确定最晚开始时间LS和最晚完成时间LF

TF = Total Flow = 总浮动时间 = 一个活动本身的LS - ES 或 LF - EF
FF = Free Flow = 自由浮动时间=后置活动的ES - 本活动的EF

正推法和逆推法详细链接

---

（3）时间压缩法、关键链法
赶工（应急法）和快速跟进都是时间压缩法。
用应急法压缩压缩项目一定要是在关键路径上选择.当关键路径不止一条时,每条路径上都要选择项目进行压缩
快速跟进是指采用并行执行任务，加速项目进展

其他知识点

在资源冲突问题中，过度分配也属于资源冲突
敏捷项目一般采用远粗近细的计划模式，敏捷的发布计划相当于远期计划，迭代计划相当于近期计划。

第2题

知识点：

甘特图 可以显示任务的基本信息，使用该类图能方便地查看任务的工期，开始和结束时间
以及资源的信息。
PDM 网络图中箭线表示的是任务之间的逻辑关系，节点表示的是活动。
ADM网络图中，箭线表示 活动或者任务 。

第3题

PERT(Program Evaluation and Review Technique)即计划评审技术。PERT网络是一种类似流程图的箭线图。它描绘出项目包含的各种活动的先后次序，标明每项活动的时间或相关的成本。

构造PERT图，需要明确三个概念：事件、活动和关键路线。

1、事件(Events)表示主要活动结束的那一点；

2、活动(Activities)表示从一个事件到另一个事件之间的过程；

3、关键路线(Critical Path)是PERT网络中花费时间最长的事件和活动的序列。

P:最悲观的估计

O:最乐观的估计

M:最可能估计

PERT历时 = （O + 4*M + P）/ 6

解：E1=(2+6+4 * 3)/6=20/6，E2=(4+8+4 * 6)/6=6，E3=(3+6+4*4)/6=25/6

任务方差、标准差分别为：
标准方差δ方差δ^2任务一4/616/36任务二4/616/36任务三3/69/36项目路径1.0741/36
所以，E= E1+ E2+ E3=13.5天，δ=1.07

E-δ=12.43，E+δ=14.57 [12.43，14.57]的概率为：68.3%

E-2δ=11.36，E+2δ=15.64 [11.36，15.64]的概率为：95.5%

E-3δ=10.29，E+3δ=16.71 [10.29，16.71]的概率为：99.7%

所以，项目在14.57天内完成的概率为：50%+68.3%/2=84.15%

第4题

关键路径：A—>E—>C—>D—>G (最早时间和最晚时间相同的任务，组成的路线)
关键路径长度：4+8+7+5+3=27 天
F的自由浮动FF=ES(s)-EF-lag=24-20-0=4 （lag:本任务与后任务之间的滞后时间）
F的总浮动时间TF=LS-ES=LF-EF=4

例题3-关于时间压缩

第八章

8.1.3质量成本

软件质量成本都有哪几部分组成？

预防成本和缺陷成本

8.3质量管理活动

软件生命周期内的哪些活动属于质量保证，哪些活动属于质量控制，质量保证和质量控制的关系是什么？

质量保证的主要活动是：

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

质量控制的主要活动是：

• 检验产品质量，保证产品符合客户需求。

二者之前的关系：
质量控制质量保证针对具体产品或者具体活动的质量管理针对一般的、具有普遍性的问题质量控制是从具体环节上提高产品的质量质量保证促进了质量的改善，促进企业的性能产生一个突破，质量保证是从总体上提供质量信心
通过质量保证和质量控制可以提高项目和产品的质量，最终达到满意的目标。

8.4敏捷项目的质量活动

敏捷项目的质量活动都有哪些，要能列举出来

1. 结对编程
2. 测试驱动开发
3. 持续集成与测试
4. 不同层面自动化测试
5. 验收测试驱动开发
6. 迭代评审
7. 迭代回顾会议
8. 重构

第九章

第9章

9.1配置管理概述

配置管理的定义和作用是什么？什么是配置项，什么是基线

软件项目管理软件开发和维护及其中各种中间软件产品的方法和规格，同时是提高软件质量的重要手段。

软件配置管理通过在特定的时刻选择软件配置来系统地控制对配置的修改

9.2软件配置管理过程

掌握软件配置管理的流程

9.4配置管理工具

常见的配置管理工具都有哪些？

9.1配置管理概述

配置管理的定义和作用是什么？

配置管理是软件项目管理软件开发和维护及其中各种中间软件产品的方法和规格，同时是提高软件质量的重要手段。

软件配置管理通过在特定的时刻选择软件配置来系统地控制对配置的修改，并在整个软件生命周期中维护配置的完整性和可追踪性。

随着软件开发规模的不断扩大，一个项目的中间软件产品的数日越来越多，中间软件产品之间的关系也越来越复杂，对中间软件产品的管理也越来越困难，有效的软件配置管理有助于解决这一系列问题。

配置管理在系统周期中对一个系统中的配置项进行标识和定义，这个过程是通过控制某个配置项及其后续变更，记录并报告配置项的状态及变更要求，以及证明配置项的完整性和正确
性实现的。

配置管理相当于软件开发的位置管理，它回答了下面的问题：

• 我（他）是谁(Who am I)？
• 为什么我（他）在这里( Why am I here)？
• 为什么我（他）是某某(Why am I who I am)？
• 我（他）属于哪里 (Where do I belong)?

配置管理是软件项目能顺利进行的基础。

什么是配置项，什么是基线

配置项：是项目定义其受控于软件配置管理的项。

基线：基线是一个或者多个配置项的集合，其内容和状态已经通过技术的复审，并在生命周期的某一阶段被接受了。（引入原因：开发过程中可能的各种变动，为了有效控制变动，软件配置管理引入了“基线”。）

9.2软件配置管理过程

掌握软件配置管理的流程：

1. 配置项标识、跟踪。
2. 项目管理环境建立
3. 基线变更管理
4. 配置审计
5. 配置状态审计
6. 配置管理计划

9.4配置管理工具

常见的配置管理工具都有哪些？

1. Rational ClearCase
2. Hansky Firefly
3. CVS
4. SVN
5. Git
6. Microsoft VSS

第十章

第10章

10.1人力资源计划

项目组织结构都有哪几种，各自特点是什么？我们一般根据什么要求选择团队成员？

10.3项目沟通计划

项目实施过程中常见的沟通问题，及怎样解决这些问题？常见的沟通方式有哪些？

10.1人力资源计划

项目组织结构都有哪几种，各自特点是什么？我们一般根据什么要求选择团队成员？

主要有三种组织结构形式，分别是:

1. 职能型组织结构> > > 特点：> > 优点：> > > 1. 职能部门为主体，有资源集中的优势，可保障项目的能源供给和项目成果质量，人员使用具有灵活性> 2. 技术转件可被不同项目共享，节约人力，减少资源浪费> 3. 同一职能部门便于交流、支援，项目成员在事业上具有连续性> 4. 项目成员离开项目或公司时，可保持技术的连续性> 5. 可减少项目临时性给项目成员带来不确定性> > 缺点：> > > 1. 客户利益与部门利益冲突时，项目及客户利益往往得不到优先考虑。> 2. 当项目需要多个部门协作完成时，资源的平衡会出现问题。> 3. 当项目需要多个部门协作完成时，权利分割不利于智能部门的沟通交流，且项目经理没有足够权利控制项目进展。
2. 项目型组织结构> > > 特点：> > 优点：> > > 1. 项目经理对项目可全权负责> 2. 项目组织目标单一，决策、客户需求都可快速响应，团队精神充分发挥。> 3. 项目经理对项目成员有全部权利，项目成员只对项目经理负责。> 4. 组织结构简单，易于操作。> > 缺点：> > > 1. 资源不能共享，会造成一定程度的资源浪费。> 2. 项目型组织处于相对封闭环境，公司政策很难落实，影响公司长远发展。> 3. 项目完成后，项目成员去处不稳定，对成员而言缺乏事业上的连续性和安全感。> 4. 项目之间处于一种条块分割状态，项目之前缺乏信息交流。
3. 矩阵型组织结构。> > > 特点：> > 优点：> > > 1. 专职的项目经理负责整个项目，可迅速解决问题；可最短时间内调度人才，组成团队。> 2. 多个项目可共享各个职能部门的资源。> 3. 既有利于项目目标实现，又有利于公司目标方针的贯彻。> 4. 项目成员顾虑减少，项目完成仍可回到原来部门。> > 缺点：> > > 1. 容易引起职能经理和项目经理的权利冲突。> 2. 资源共享可能引起项目之前的冲突> 3. 项目成员有多位领导，需要接收双重领导，因此经常有焦虑和压力。

我们一般根据什么要求选择团队成员？

通过制定 人员职责计划。

人员职责计划说明每个人员的角色和职责。例如，一个软件团队的主要角色有项目经理、系统分析员、系统设计员、数据库管理员、支持工程师、程序员、质量保证人员、配置管理人员、业务专家（用户）、测试人员等角色

10.3项目沟通计划

项目实施过程中常见的沟通问题，及怎样解决这些问题？常见的沟通方式有哪些？

第十一章

第11章:

11.3风险评估: 重点看下决策树分析这类题怎么做

11.4风险应对策略: 常见的几种风险应对策略都有哪些

11.7案例分析

表11-10风险计划

风险评估-决策树

风险应对策略

风险应对策略一般有几种基本类型:

1. 风险规避> 风险规避是改变项目计划来消除特定风险事件的威胁。
2. 风险转移> 风险转移是转移风险的后果给第三方，通过合同的约定，由保证策略或者供应商担保。
3. 风险减轻> 风险减轻是减少不利的风险事件的后果和可能性到一个可以接受的范围。
4. 风险接受> 准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。

11.7案例分析

表11-10 风险计划

第十二章

第12章

12.3合同类型

都有哪几种合同类型，这几种合同金额怎么计算的，哪方承担风险比较大，表12-2。

12.3 合同类型及计算方式及承担风险

合同类型：

1. 总价合同1. 固定总价合同（FFP） 总价一旦确定不会改变，无论亏损2. 总价加激励费用合同（FPIF） 双方就合同产品协商价格,其中包括对卖方的奖励金。> 举例：合同的目标成本20000，目标费用2000，风险分担比率70：30，较高价24000。> > 情况1：实际成本16000.> > 情况2：实际成本25000.> > 买方应支付的总价和卖方的佣金计算如下：> > 情况1：买方支付总价：16000+2000+（20000-16000）*30%＝19200> > 卖方的佣金：19200-16000＝3200> > 情况2：买方支付总价：只支付较高价24000，因为实际成本25000高于较高价24000.> > 卖方的佣金：24000-25000＝-1000.3. 总价加经济价格调整合同（FP－EPA）它允许根据条件变化（如通货膨胀、某些特殊商品的成本增加或降低），以事先确定的方式对合同价格进行最终调整。
2. 成本补偿合同1. 成本加固定费用合同（CPFF）> 举例：合同的估计成本20000，固定费用2000。> > 如果发生为情况1：实际成本16000.> > 情况2：实际成本25000.> > 买方应支付的总价计算如下：> > 情况1：买方支付总价：16000+2000＝18000> > 情况2：买方支付总价：25000+2000＝270002. 成本加激励费用（CPIF）> 它增加了激动的机制，> 在此类合同中，如果最终成本低于或高于原始估算成本，则买方和卖方需要根据事先商定的成本分推比例来分享节约部分或分担超支部分。> > 例如，基于卖方的实际成本，按照 80/20 的比例> 分担（分享）超过（低于）目标成本的部分。> > 假设估计的成本是 10 万元，利润是1 万元，如> 果实际成本是 10万元，则合同金额为 11万元；> > 如果实际成本是8万元，则合同金领为 8+1+> 2×20% =9.4（万元)，即将节约的2 万元成本的 20% 作为激勋。> > 在这种合同类型中，甲方承担成本超出的风险，但是又进一步约束了乙方，甲方的风险在降低，乙方的风险在增加。3. 成本加奖励费用（CPAF）> 成本加奖励费用 （CPAF）合同为卖方报销一切合法成本，但只有在卖方满足合同规定的某些笼统主观的绩效标准的情况下，才向卖方支付大部分费用。> > 奖勋费用完全由买方根据自己对卖方绩效的主观判断来决定，并且通常不允许申诉。> > 例如某项目，买方根据自己对卖方绩> 效的判断，只支付成本 10 万元作为项目费用。另外一种情况是买方认为卖方的绩效可以给子3万元的奖励费用，这样合同金额为13 万元。
3. 工料合同> 工料合同或者称为时间与材料 (time and material) 合同，是兼具成本补偿合同和总价合同特点的混合型合同。> > 在这种合同往往适用于：在无法快速编制出淮确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持。在这种合同中，客户必须为每一个单位（如每一个员工> 时）的工作量付出一定的报酬。> > 例如，合同中工程师单价为 130 美元/工时，则合同总价根据工程师的具体工作时间来确定。> 例如，某项目合同与功能点相关，如果每个单位的功能点价格确定了，最终价格就是每个单位的功能点价格乘以功能点数量，表12-1 是某项目的价格表。> >

第十六章

第16章

16.2项目结束的具体过程

项目结束的过程？项目总结的目的和主要工作？

项目结束的具体过程

失败终止：指已经可以确定项目目标无法完全实现，不得已而为之。
成功终止：指项目目标已经实现、项目成功完成而终止项目。

项目结束的具体过程：

1. 项目验收与产品交付>
2. 合同终止> 合同结束说明完成丁合同所有条款或者合同双方认可终止，同时解决了所有问题。合同是甲乙双方的事情，合同结束也应该由甲乙双方共同完成。> 当项目满足结束条件时，合同管理者应该及时宣布项目结束，终止合同的执行，并通过合同终止过程告知各方合同终止。> 甲方具体活动描述如下：> 1）按照企业文档管理规范将相关合同文档归档> 2）合同管理者向有关人员通知合同终止。> 3）起草项目总结报告。> 4） 在项目的末期，与乙方的合同如果还有尚末解决的索赔，项目经理可以在合同收尾之> 后，采取法律行动。> 在合同终止过程中，乙（供）方应该配合甲 （需）方的工作，包括项目的最后验收、双> 方签字认可、总结经验教训、获取合同的最后款项、开具相应的发票、将合同相关文件归档等> 过程
3. 项目最后评审> 项目结束中一项重要过程是项目的最后评审，即对项目进行全面的评价和审核> > > - 确定是否实现项目目标> - 是否遵循项目进度计划> - 是否在预算成本内完成项目> - 项目过程中出现的突发问题及解决措施是否合适，问题是否得到解决
4. 项目总结> > - 项目总结是一个把实际运行情况与项目计划不断比较以提炼经验教训的过程。> - 通过项目总结，项目过程中的经验和教训将得到完整的记录和升华，成为“组织财富”