项目管理与案例分析知识点汇总

最新推荐文章于 2024-05-28 14:00:00 发布

a745092253

最新推荐文章于 2024-05-28 14:00:00 发布

阅读量985

点赞数 22

文章标签： python django pygame virtualenv java php

本文链接：https://blog.csdn.net/a745092253/article/details/135758408

版权

第一章

1.1 项目与软件项目的概念

项目定义和特征

项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。特征：目标性相关性周期性独特性约束性不确定性结果的不可逆转性

临时性 项目有明确的开始与截止日期项目合同的起止日期当达到项目的目标时即项目的截止日期；或项目被中止/取消的日期

项目的临时性并不意味着项目所提交的产品或服务也是一次性的（一次性纸杯的生产）项目所面临的市场机遇往往也是临时性的（没有企业愿意在2009年生产北京奥运的徽章）项目组也往往是临时性的，当项目结束时，项目组也随之解散

独特的产品或服务 项目所产生的产品或服务是独一无二的（包括合同的签订人、位置等方面的信息）对于批量生产的商品（例如空调或冰箱）则不具备独特性，而例如北京联通计费项目则具有独特性咨询和会计审计服务

项目与日常运作的区别： 项目是一次性的，日常运作是重复进行的项目是以目标为导向的，日常运作是通过效率和有效性体现的项目是通过与项目经理及其团队工作完成的，而日常运作是职能式的线形管理项目存在大量的变更管理，而日常运作则基本保持持续的连贯性的

软件项目的特点 除了项目的特征，软件项目还具有以下特点：软件是逻辑实体，不是具体的物理实体，具有抽象性软件的开发受计算机系统的限制，对硬件系统有不同程度的依赖

软件具有复杂性特点，其开发成本昂贵，制约因素很多

项目管理的定义 项目管理是以项目为对象，通过使用知识、技能、工具和方法来组织、计划、实施并监控项目，使之满足项目目标需求的过程。

软件危机 就是软件生产能力和业务发展需求不相适应的现象就是弱的软件生产能力和强的业务发展需求之间的矛盾 软件危机表现 开发过程随心所欲时间计划和费用估算缺乏现实的基础管理者主要在应付突发事件对产品质量缺乏客观基础软件开发的成败建立在个人能力基础上

PMBOK 10大过程领域

10、项目干系人管理

识别项目干系人规划项目干系人管理管理干系人参与控制干系人参与

1.3 软件项目生命期与管理过程

软件项目生命期 计划阶段定义系统，确定用户的要求或总体研究目标，提出可行的方案，包括资源、成本、效益、进度等的实施计划。进行可行性分析并制定粗略计划。需求分析阶段确定软件的功能、性能、可靠性、接口标准等要求，根据功能要求进行数据流程分析，提出初步的系统逻辑模型，并据此修改项目实施计划。软件设计阶段它包括系统概要设计和详细设计。在概要设计中，要建立系统的整体结构，进行模块划分，根据要求确定接口。在详细设计中，要建立算法、数据结构和流程图。

编码阶段把流程图翻译成程序，并对程序进行调试。测试阶段通过单元测试，检验模块内部的结构和功能；通过集成测试，把模块连接成系统，重点寻找接口上可能存在的问题；确认测试，即按照需求的内容逐项进行测试；系统测试，就是到实际的使用环境中进行测试。单元测试和集成测试由开发者自己完成，确认测试和系统测试则由用户参与完成。运行维护阶段它一般包括三类工作，为了修改错误而做的改正性维护；为了适应环境变化而做的适应性维护；为了适应用户新的需求而做的完善性维护，有时会成为二次开发，进入一个新的生命期，再从计划阶段开始。

项目生命周期的影响

项目管理过程包括的主要工作 制定技术目标、组建项目组、制订项目计划处理范围变化、控制实际进展、整理、完善技术档案、形成知识网络

影响项目成功的因素 项目的目标、范围是否明确是否获得领导的积极支持项目的组织是否健全、稳定是否建立了有序的、有效的、良好的沟通渠道是否具有有效、全面的项目管理，严格的变更控制是否建立了良好的、积极的、团队合作的工作氛围项目经理PM的经验

项目生命期中的几个概念 检查点(Check Point) 它指在规定的时间间隔内对项目进行检查，比较实际现状与计划之间的差异，并根据差异进行调整里程碑(Mile Stone) 它是完成阶段性工作的标志，不同类型的项目里程碑不同基线(Base Line) 它指一个(或一组)配置项在项目生命期的不同时间点上，通过正式评审而进入正式受控的一种状态

第四章

质量的定义

软件内在质量，即产品本身的缺陷率和可靠性。客户满意度，即产品与用户需求的一致性。过程质量，即为了确保产品的内在质量和客户满意度，而对产品的设计与开发过程中所进行的监管和改进措施的效果。

软件质量的定义尚无统一认识

　　Donald Reifer：软件质量就是软件产品满足明示需求程度的一组属性的集合。 Norman E. Fenton：软件质量是软件产品满足明示或暗示需求能力的特性和特征的集合，该定义不仅关注明示需求，还要求关注暗示需求。 IEEE Std729-1983：软件质量是与软件产品满足规定的和隐含的需求的能力有关的特征或特征的集合。

软件质量反映三个方面的问题

软件需求是度量软件质量的基础，不符合需求的软件就不具备质量。应在各种标准中定义开发准则，用于指导软件人员采用工程化的方法来开发软件产品. 往往会有一些隐含的需求没有明确地提出来，若忽略了这些隐含需求将无法保证软件的质量。

软件质量及相关控制和管理工作非常复杂

理解用户的需求难度很大用户未发现自己真正的需求用户需求多为隐形需求用户需求多样化用户需求不断变化软件研发人员需跨行业学习和理解软件产品使用领域的相关行业知识

制定和遵循标准的难度很大知识密集型行业，难以实现大规模流水线生产不重视文档，缺乏规范和足够的文档不重视单元测试，单元代码质量不高

软件质量保证的定义 IEEE：软件质量保证是一种有计划的、系统化的行动模式，是设计用来评价开发或制造产品过程的一组活动 Faidey：软件质量保证包括过程和产品的保证，其基本任务是保证项目履行其对产品和过程的承诺软件质量保证是为了提供信用，从而证明项目将会达到有关质量标准，而在质量体系中开发的有计划、有组织的工作活动

软件质量保证的目标 合理监控软件和软件开发过程，来保证产品质量保证软件和软件开发过程完全遵循建立的相关标准和规范保证软件产品、开发过程和标准中的不足能引起管理部门的充分注意，并得到及时处理保证项目组制定的计划、相关标准和规范符合项目组的需要收集项目开发中的经验和教训，为企业内部软件开发的整体标准和规范提供依据，并为其他项目组的开发过程提供先进方法和范例

模型分类 基于经验的模型层次模型：MaCall模型，Boehm模型，ISO9126模型关系模型：Perry模型基于构建的模型 Dromey模型

软件质量度量的内容

软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程。软件质量度量就是软件内在质量度量、过程质量度量和维护质量度量的总和。

软件质量度量的内容

缺陷密度软件缺陷在一定软件规模下的分布缺陷密度 = N / L ×100% 平均失效时间两次失效之间的时间间隔复杂性度量文本复杂度（即Halstead复杂度）以程序中出现的操作符和操作数为基本计数对象，以它们的种类和数量作为计数目标对程序容量和涉及的代码编写工作量进行测算程序长度N＝N1+N2 程序容量V=N × log2n 环复杂度对程序结构复杂情况的一种度量三种计算方法：观察法、公式法和判定节点法（4）文档缺陷密度计算文档评审中发现的各种文档中的缺陷包括：与文档规范相关的缺陷和文档内容方面的缺陷

需求分析过程质量度量 需求文档（即需求规格说明书）的质量一般采用评审需求规格说明书的形式来展开针对需求的完整性、正确性、可理解性、可测试性、一致性、可追踪性、可修改性、精确性和可复用性等特性进行评审需求稳定性（即需求变更）需求稳定引子（Requirements Stability Index，RSI）

（2）开发过程质量度量从过程效率、过程工作量及质量角度来度量典型指标过程生产率累计缺陷总数

（3）测试过程质量度量从测试工作和测试结果两方面来度量典型指标：测试用例深度、测试用例效率、测试用例质量、测试用例执行质量、测试用例执行效率、缺陷报告有效性、缺陷报告质量、缺陷清除率（4）软件维护质量度量侧重于提高用户满意度典型指标：缺陷积压处理度量、缺陷修复响应时间度量、缺陷修复响应度量、缺陷修复质量度量

为了对软件质量进行度量，从而对软件质量管理相关活动进行跟踪记录，实现质量的控制，往往需要利用多种类型的质量工具 数据库、图形、报告工具数据收集工具统计分析工具估计模型（1）表格类工具检查表（Checklist），又称调查表、统计分析表是一种列表形式，列表中列出了需要进行检查的所有项目广泛用于软件开发各个阶段的同行评审过程中，主要用于问题识别分类面向项目组的检查表面向用户的检查表局限性简单收集和积累数据，无法直观反映软件质量特性，不利于基于统计的软件质量分析，更不支持预测（2）柱状图类工具将统计后的数据绘制成矩形或者长方体形状的图形直方图对一个群体或一个样本集出现频率的图形表示主要用于问题分析优势：直观表示某个参数的分布特性，有助于加强对参数的理解局限性：所选参数不含时间变化信息，未充分利用数据的统计特性，难以从直方图深入分析导致某现象的本质原因，对过程改进的推动作用不大，也无任何预测能力（3）折线图类工具控制图是游程图的一个高级形式，是通过测量、记录和评估过程质量特性值来判断过程是否处于控制状态主要用于问题分析，是一种基于统计方法所设计的图（4）枝状图类工具以树枝一样的形状来展示因果图：也称鱼骨图（Fishbone），用来表示一个质量属性（即结果）与影响该属性的因素（即原因）之间的关系，其分布像鱼的骨架

软件评审： 是一组人员对特定软件项目某项活动的状态和产品进行检查和评价的过程目的：找出活动状态和产品中存在的缺陷并对质量进行评估一般过程：按照项目计划中的规定，在预定的里程碑处进行定期检查评审的分类：包括教育评审、管理评审、同行评审、项目后的评审、状态评审等

软件测试过程模型 典型的测试过程模型 V模型

V模型特点反映了动态测试行为与开发行为的对应关系，即每个测试阶段的基础是对应开发阶段的提交物（即文档）局限性测试滞后测试与开发文档难以一一对应缺少静态测试质量折扣

W模型

W模型特点强调尽早测试强调不断测试体现静态测试局限性将软件开发看成是需求分析、设计和编码等一系列串行的活动。开发、测试之间保持着线性的前后关系，无法支持迭代的开发模型，无法支持变更调整。未体现测试流程的完整性。

H模型

H模型特点体现“尽早测试、不断测试”的原则体现测试流程的完整性体现测试流程的独立性充分体现了测试过程（并非技术）的复杂性，强调了过程管理的重要性

第五章

软件项目团队管理的定义 软件项目团队管理就是运用现代化的科学方法，对项目组织结构和项目全体参与人员进行管理，在项目团队中开展一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作，使项目组织各方面人员的主观能动性得到充分发挥，以实现项目团队的目标。

软件项目团队管理的任务 软件项目团队管理主要包括：团队组织计划指确定、记录与分派项目角色、职责，并对请示汇报关系进行识别、分配和归档。团队人员获取指获得项目所需的并被指派到项目的人力资源（个人或集体）。团队建设既包括提高利害关系者作为个人做出贡献的能力，也包括提高项目团队作为集体发挥作用的能力。个人的培养（管理能力与技术水平）是团队建设的基础。团队的建设是项目实现其目标的关键。

软件项目团队管理的重要性 是软件项目管理中至关重要的组成部分是有效地发挥每个参与项目的人员作用的过程人员的组织管理是影响软件开发项目质量的决定性因素

如果企业要想在软件开发项目上获得成功，他们就需要认识到项目人力资源管理的重要性，了解项目人力资源管理的知识体系及范畴，并将有效的管理理论和方法引入项目管理的过程中，充分发挥项目人员的积极性与创造力来实现企业的目标。

软件项目组织计划编制

组织分解结构(OBS) OBS（组织分解结构）是一种特殊的组织结构图，它建立在一般组织结构图的基础上，根据公司各部门的具体单元或者子公司的组织单元将一般组织结构图再进行更详细地分解。项目经理通常使用OBS来分配工作任务。责任分配矩阵(RAM) RAM 就是将工作分解结构图(WBS)中的每一项工作指派给OBS中的执行人而形成的一个矩阵。

三种组织结构的优缺点及比较

线性组织结构的优点包括迅速灵活的反应能力、较低的运营成本以及指令的唯一性和责任明确性。这种结构下，决策可以快速传达并执行，组织的运作效率较高。然而，线性组织结构也存在一些缺点，例如高层信息超载、决策制定缓慢、高层经理容易陷入日常经营而无法进行长期资源配置等问题。

职能制组织结构的优点包括人员利用的弹性和适应性、专家知识和经验的共享以及技术上的延续性。在这种结构下，各个职能部门拥有自己的专业领域，可以灵活调配人员，并在项目之间共享资源和知识。然而，职能制组织结构也存在一些缺点，如常规工作优先于项目考虑、项目责任分散、协调性差以及难以形成对项目的系统化管理系统等问题。

矩阵制组织结构的优点包括项目经理对项目负责、方便人力资源管理、利用职能部门的技术优势以及对客户的快速响应能力。这种结构下，项目经理负责项目管理，同时可以充分利用职能部门的专业技能。然而，矩阵制组织结构也存在一些缺点，如项目决策权力平衡困难、项目间资源竞争、上级命令不统一等问题。

七、软件项目开发计划

项目分解目的 —— 明确项目所包含的各项工作；项目分解的结果就是WBS （任务分解结构）图项目分解意义 ——WBS（任务分解结构）图是实施项目、创造最终产品或服务所必须进行的全部活动的一张清单，也是进度计划、人员分配、预算计划的基础项目分解内容 ——项目分解就是先把复杂的项目逐步分解成一层一层的要素（工作），直到具体明确为止项目分解工具 ——项目分解的工具是工作分解结构ＷＢＳ原理，它是一个分级的树型结构，是一个对项目工作由粗到细的分解过程

WBS —— Work Breakdown Structure主要是将一个项目分解成易于管理的几个部分或几个细目，以便确保找出完成项目工作范围所需的所有工作要素它是一种在项目全范围内分解和定义各层次工作包的方法 WBS —— Work Breakdown Structure结构层次越往下层则项目组成部分的定义越详细，WBS最后构成一份层次清晰，可以具体作为组织项目实施的工作依据 WBS ——Work Breakdown Structure通常是一种面向“成果”的“树”，其最底层是细化后的“可交付成果”，该树组织确定了项目的整个范围。但WBS的形式并不限于“树”状，还有多种形式。

WBS分解类型 基于可交付成果的划分上层一般为可交付成果为导向下层一般为可交付成果的工作内容基于工作过程的划分上层按照工作的流程分解下层按照工作的内容划分

WBS分解注意事项 WBS分解的规模和数量因项目而异收集与项目相关的所有信息参看一下类似的项目的WBS,与相关人员讨论可以参照相关模板最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层，软件项目推荐分解到40小时的任务每个Work package必须有一个提交物

进度编制的基本方法

关键路径法（CPM： Critical Path Method） CPM是根据指定的网络顺序逻辑关系和单一的历时估算，计算每一个活动的单一的、确定的最早和最迟开始和完成日期计算网络图中完成时间最长的路径计算浮动时间

浮动时间(Float) 浮动时间是一个活动的机动性,它是一个活动在不影响其它活动或者项目完成的情况下可以延迟的时间量 Float>0：时间安排比较合理 Float=0：比较紧张 Float<0：项目进度会推迟

八、项目风险

风险定义与分类 美国软件工程研究所将风险定义为损失的可能性。风险同人们有目的的活动有关，同未来的活动有关，同人们变化的行为方式有关。风险具有两大属性：可能性和损失，可能性是风险发生的概率，损失是指预期与后果之间的差异，我们用可能性(Likelihood)和损失(Loss)的乘积来记录风险损失。风险的根源在于事物的不确定性，虽然无法避免不确定性，但是可以通过适当的方法对其进行控制与管理。从范围角度上看，风险主要分为下述三种类型：项目风险、技术风险和商业风险。软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。软件风险又可区分为软件项目风险、软件过程风险和软件产品风险。

风险管理 风险管理是指在项目进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的实现。风险管理可以分为四个层次：危机管理：是在风险已经造成麻烦后才着手处理它们。风险缓解：事先制定好风险发生后的补救措施，但不制定任何的防范措施。着力预防：将风险识别与风险防范作为软件项目的一部分加以规划和执行。消灭根源：识别和消灭可能产生风险的根源。风险管理策略有两种：救火模式和主动模式。

风险管理的意义 项目实施风险管理的意义可归纳如下：通过风险分析，可加深对项目和风险的认识和理解，澄清各个方案的利弊，了解风险对项目的影响，以便减少或分散风险。为以后的规划与设计工作提供反馈，以便采取措施防止与避免风险损失。通过风险管理可以使决策更科学，从总体上减少项目风险，保证项目的实现。可推动项目管理层和项目组织积累风险资料，以便改进将来的项目管理。

风险识别过程 风险识别或称风险辨识，是寻找可能影响项目的风险以及确认风险特性的过程。风险识别的目标是：辨识项目面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。风险识别的输入与输出输入可能是项目的WBS、工作的陈述（Statement Of Work，SOW）、项目相关信息、项目计划假设、历史项目数据，其他项目经验文件、评审报告、公司目标等。风险识别的输出是风险列表。包括以下活动风险识别方法的确定；风险定义及分类；风险文档编写。

风险识别的方法 1、风险条目检查表 ——风险条目检查表是最常用也是比较简单的风险识别方法，它是利用一组提问来帮助管理者了解项目在各方面有哪些风险。在风险条目检查表中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险(如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等)。风险条目检查表一般根据风险要素进行编写，包括项目的环境、管理层的重视度、技术情况以及内部因素(如团队成员的技能或技能缺陷等)。 2、德尔菲（Delphi）法德尔菲方法又称专家调查法，它起源于20世纪40年代末期，最初是美国兰德公司首先使用，很快就在世界上盛行起来，目前此法的应用已遍及经济、社会、工程技术等各领域。我们在进行成本估算的时候也用到这种方法。用德尔菲方法进行项目风险识别的过程，是由项目风险小组选定与该项目有关的领域专家，并与这些适当数量的专家建立直接的函询联系，通过函询收集专家意见，然后加以综合整理，再匿名反馈给各位专家，再次征询意见。这样反复经过四至五轮，逐步使专家的意见趋向一致，作为最后识别的根据。 3、情景分析法情景分析法是根据项目发展趋势的多样性，通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系统发展态势做出自始至终的情景和画面的描述。当一个项目持续的时间较长时，往往要考虑各种技术、经济和社会因素的影响，对这种项目进行风险预测和识别，就可用情景分析法来预测和识别其关键风险因素及其影响程度。 4、会议法定期的项目组会议，如项目转折点或重要变更时举行的会议，项目月、季度总结会，项目专家会议都适宜于谈论风险信息，将风险讨论列为会议议题。

风险评估过程

风险评估的过程包括以下步骤：

确定风险类别。
确定风险驱动因素。
判定风险来源。
定义风险度量准则。
预测风险影响。
评估风险。
对风险进行排序。
归档风险分析结果。

风险评估的方法包括定性风险评估和定量风险评估。

定性风险评估是对风险概率和后果进行非量化的评估，可以使用历史资料法、概率分布法和风险后果估计法等方法。
定量风险评估是对风险进行量化分析，包括访谈、盈亏平衡分析、决策树分析和模拟法等方法。

风险计划 ——针对风险分析的结果，为提高实现项目目标的机会并降低风险的负面影响而制定风险应对策略和应对措施的过程，即通过制定一系列的行动和策略来对付、减少以至于消灭风险事件。降低风险的主要策略回避风险、转移风险、损失控制以及自留风险。风险计划的结果项目风险计划或风险管理方案。风险计划的应该提供一个风险分析表，包括：项目风险的来源、类型，项目风险发生的可能时间、范围，项目风险事件带来的损失，以及项目风险可能影响的范围等。

九、跟踪控制

项目跟踪控制 保证项目能够按照预先设定的计划轨道行驶，使项目不要偏离预定的发展进程。跟踪控制是一个反馈过程，需要在项目实施的全过程对项目进行跟踪控制。项目跟踪控制的基本步骤建立标准即建立项目正确完成应该达到的目标观察项目的性能建立项目监控和报告体系，确定为控制项目所必需的数据测量和分析结果将项目的实际结果与计划进行比较采取必要措施当实际的结果同计划有误差时，必要时修正项目计划控制反馈如果修正计划，应该通知有关人员和部门 项目跟踪控制的重要性 如果没有项目控制，则可能出现：项目的范围会很大成本会成倍增长风险也会增加进度也会推迟

建立控制标准 ——在对项目进行跟踪控制时，应该确定偏差的接受准则，比如进度、成本、质量等计划与实际的偏差比例等。三个主要的基准计划范围（质量）计划进度计划成本计划基准计划是优化后并批准的计划，它作为项目实施考核的依据

项目信息采集 ——建立项目监控和报告体系的首要任务是项目信息跟踪采集。跟踪采集是依据规定的规范对项目开发过程中的有关数据进行收集和记录，作为观察分析项目性能、标识偏差的依据。跟踪采集主要是在项目生存期内，根据项目计划中规定的跟踪频率按照规定的步骤对项目管理、技术开发和质量保证活动进行跟踪监控项目实际情况，记录反映当前项目状态的数据项目度量实施过程

确立采集对象 ——采集对象主要是对项目有重要影响的内部和外部因素。内部因素指项目基本可以控制的因素，例如变更、范围、进度、成本、资源、风险等外部因素指项目无法控制的因素，比如法律法规、市场价格、外汇牌价等一般要根据项目的具体情况选择采集对象。如果项目比较小，可以集中在进度、成本、资源、产品质量等内部因素；只有项目比较大的时候才可以考虑外部因素。跟踪采集的具体对象可以参见度量计划中的相关度量指标。

采集过程实例 依据项目计划的要求确定跟踪频率和记录数据的方式按照跟踪频率记录实际任务完成的情况（包括进度或完成时间，质量等）按照跟踪频率记录完成任务所花费的人力和工时根据实际任务进度和实际人力投入计算实际人力成本和实际任务规模记录除人力成本以外的其他成本消耗记录关键资源的使用情况记录项目进行过程中风险发生的情况及处理对策按期按任务性质统计项目任务的时间分配情况收集其它的要求的采集信息以及必要的度量信息等

范围控制注意点 ——防治不合理的范围扩张范围蔓延（ Scope Creeping ）客户无限制地增加需求镀金（ Gold-plating ）开发人员无限制地美化功能项目进度、成本、资源控制根据跟踪采集的进度、成本、资源等数据，并与原来的基准计划比较，对项目的进展情况进行分析，以保证项目在可以控制的进度、成本、资源内完成。

项目性能分析方法 图解控制法能清楚确定项目状况，但没有量化信息进度---甘特图成本—累计费用曲线图人力物力资源—资源载荷图挣值分析法（盈余分析法、已获取价值分析法） Earned Value Analysis 利用成本会计评估项目进展情况的一种方法，可以提供更多量化的信息

分析未来趋势 一切顺利：ACWP,BCWP,BCWS,应该重合或接近重合项目在控制下按照计划进行： ACWP, 接近BCWS BCWP的计算 ——已获价值分析的难点是计算BCWP 方法一：自下而上-很麻烦方法二：公式计算方法 50/50规则当一项工作开始时，假定已经获得一半的价值。 0/100规则当一项工作开始时，没有产生价值，直到结束获得全部价值。经验加权法

输出——已获值导出度量-1 进度差异:SV（Schedule Variance）=BCWP-BCWS =0：按照进度进行 <0：落后于进度

大于0：超前于进度

费用差异:CV（Cost Variance )=BCWP-ACWP =0：按照预算进行

0：低于于预算 <0：超出于预算

输出——已获值导出度量-2 成本效能指数：CPI(Cost Performance Index)=BCWP/ACWP 费用的支出速度 =1：按照预算进行

=1：低于预算 <1：超出预算进度效能指标： SPI(Schedule Performance Index)=BCWP/BCWS 已完成工作百分比 =1：按照进度进行 1：超前于进度 <1：落后于进度

十一、项目中止

项目终止的条件 ——下列条件之一出现，可以终止项目。项目计划中确定的可交付成果已经出现，项目的目标已经成功实现项目已经不具备实用价值项目由于各种原因而导致无限期拖长项目出现了环境的变化，它负面影响项目的未来项目所有者的战略发生了变化项目无竞争力，难以生存

成功与失败的标准 项目最后执行的结果只有两个状态：成功与失败评定项目成功与失败的标准主要看三项可交付成果如何是否实现目标是否达到项目业主的期望

项目文件整理 这个阶段的主要工作有：鉴别未完成的工作和工序核对所有任务和活动的相关记录是否准确、齐备确认所有与项目收尾相关的资料是否完整检查项目管理计划中的工作是否实际完成完成资料的整理工作，为项目的最终移交做准备，资料主要包括：产品文档、开发文档、用户手册、培训文档、项目测试报告、外包合同、变更文件、会议纪要、项目总结报告等。

项目结束过程 ——当项目接近生命期末期时，项目资源开始转向其他活动或项目，项目经理和项目团队成员所面临的工作也开始转向项目收尾活动。制定项目结束计划完成收尾工作项目最后评审项目结束总结

项目收尾工作内容 范围确认项目接收前，重新审核工作成果，检验项目的各项工作范围是否完成，或者完成到何种程度，最后，双方确认签字质量验收质量验收是控制项目最终质量的重要手段，依据质量计划和相关的质量标准进行验收，不合格不予接收费用决算费用决算是指对从项目开始到项目结束全过程所支付的全部费用进行核算，编制项目决算表的过程合同终结整理并存档各种合同文件资料验收检查项目过程中的所有文件是否齐全，然后进行归档

项目最后评审 —— 项目结束中一个重要的过程是项目的最后评审，它是对项目进行全面的评价和审核。是否实现项目目标是否遵循项目进度是否在预算成本内完成项目项目进度过程中出现的突发问题以及解决措施是否合适，问题是否得到解决对特殊成绩的讨论和认识回顾客户和上层经理人员的评论从该项目的实践中可以得到哪些经验和教训

项目验收意义 项目的验收标志着项目的结束(或阶段性结束) 若项目顺利地通过验收，项目的当事人就可以终止各自的义务和责任，从而获得相应的权益。同时，项目团队可以总结经验，接受新的项目任务项目验收是保证合同任务完成，提高质量水平的最后关口通过项目验收，整理档案资料，可为项目最终交付成果的正常使用提供全面系统的技术文档和资料

项目验收标准和依据 项目验收一般标准作为项目验收的标准，一般选用项目合同书；也有选用国标、行业标准和相关的政策法规、国际惯例等。项目验收主要依据对项目进行验收时，主要依据项目的工作成果和成果文档。

项目验收收尾与移交 项目验收收尾项目验收完成后，如果验收的成果符合项目目标规定的标准和相关的合同条款及法律法规，参加验收的项目团队和项目接收方人员应在事先准备好的文件上签字。这时项目团队与项目业主的项目合同关系基本结束，项目团队的任务转入对项目的支持和服务阶段项目移交当项目通过验收后，项目团队将项目成果的所有权交给项目接收方，这个过程就是项目的移交。当项目的实体移交、文件资料移交和项目款项结清后，项目移交方和项目接收方将在项目移交报告上签字，形成项目移交报告 —— 项目验收是项目移交的前提；移交是项目收尾的最后工作内容，是项目管理的完结。