软件项目管理总结（全）

软件项目管理知识综述

第一章知识总结

软件项目管理的作用和重要性

项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。项目管理通过合理

运用与整合特定项目所需的项目管理过程得以实现。项目管理使组织能够有效且高效地开展项目。

有效的项目管理能够帮助个人、群体以及公共和私人组织

达成业务目标；

满足相关方的期望；

提高可预测性；

提高成功的概率；

在适当的时间交付正确的产品；

解决问题和争议；

及时应对风险；

优化组织资源的使用；

识别、挽救或终止失败项目；

管理制约因素（例如范围、质量、进度、成本、资源）；

平衡制约因素对项目的影响（例如范围扩大可能会增加成本或延长进度）；

以更好的方式管理变更。

项目管理不善或缺乏项目管理可能会导致：

超过时限；

成本超支；

质量低劣；

返工；

项目范围扩大失控；

组织声誉受损；

通用产品项目立项过程
微软公司的新产品项目立项阶段的步骤：
1、  新产品项目的提议
2、  市场分析预测
3、  技术可行性分析
4、  确定产品研发实施步骤
5、  高层论证和审批
通用产品项目立项的一般过程

1.产品构思
立项建议小组要在宏观上搞清楚“开发什么”、“怎样开发”、“怎样赚钱”等重要问题。
产品构思的主要内容：
待开发产品的主要功能；
待开发产品的技术方案；
Make-or-Buy分析；
开发计划；
市场营销计划。
Make-or-Buy分析
确定产品中的哪些部分应当自行研发、采购或外包开发。
做Make-or-Buy决定的依据包括：
成本（包括初始成本和后续维护成本）；
风险；
工作效率；
知识产权；
……
2.立项调查
立项调查的目的是为产品构思和可行性分析提供充分的、有价值的信息。
立项调查的主要内容有：
用户和市场调查；
政策调查；
竞争对手和同类产品调查。
立项调查的方式
常见的立项调查的方式有：
•从Internet上搜索相关资料；
•从出版物中提取信息；
•与用户交谈；
•向用户群体发调查问卷；
•与同行、专家交谈，听取他们的意见。
立项调察要坚持客观性。
对调查得到的信息进行整理，最好形成一份《调查报告》。
3.申请立项
立项建议小组根据产品构思、立项调查和可行性分析结果完成《立项建议书》，提交给有决策权的机构领导。
4.立项评审
机构领导组织立项评审委员会，并确定一位主席。立项评审委员会一般由机构领导、各级经理、市场人员、技术专家、财务人员等组成。
主席应当具有比较丰富的评审经验，负责主持评审会议，并负责撰写《立项评审报告》。
立项评审的一般步骤
第一步：评审准备
（1）评审委员会主席确定评审会议的时间、地点、设备和参加会议的人员名单（包括评审委员会成员、立项建议小组、记录员、旁听者等），并通知所有人员。
（2）主席将《立项建议书》及相关材料发给所有评委，各评委必须在举行评审会议之前阅读完毕，并及时与立项建议小组交流。
第二步：举行评审会议。
（1）主席宣布本次评审会议的议程、重点、原则、时间限制等。
（2）立项建议小组陈述《立项建议书》的主要内容。
（3）答辩。评审委员会提出疑问，立项建议小组解答。双方应对有争议的内容达成一致意见。记录员记录答辩过程的重要内容，包括问题、结论、建议等。
第三步：评估。
（1）立项建议小组退席。
（2）每个评审委员会成员认真评估该项目，给出同意或不同意立项的结论和意见建议。
第四步：评审会议决议
评审委员会根据少数服从多数的原则，给出评审结论。
主席撰写《立项评审报告》并递交给机构领导。
第五步：机构领导终审
此时机构领导具有一票否决权，可在《立项评审报告》中签署最终审批结论和意见。

项目计划的主要内容

项目计划（Project Planning）也称项目规划，其目的是为项目的开发和管理工作制定合理的行动纲领，使所有人员按照该计划有条不紊地开展工作。
谁在什么时候进行项目计划？
当项目经理完成了项目筹备，必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目计划小组，开始进行项目计划。

项目计划的步骤
1.项目估计
做项目计划之前，应该对软件规模、项目工作量进行估计。如果这些要素估计得比较准确的话，那么后续制定的项目计划就比较合理。对于一些外包项目而言，项目估计得到的数据是双方讨价还价的依据。
项目估计几乎不可能成为一门精确的科学。但依据某种方法（规则）进行估计显然比随意进行项目计划好得多。
2.制定项目计划
项目计划分为两类：一是全局的计划书（OverallPlan），通常就称为《项目计划》；二是一些下属计划书（SubordinatePlan），例如配置管理计划、质量管理计划、阶段开发计划和测试计划等。
下属计划书是对《项目计划》的补充，其内容不可与《项目计划》冲突。通常《项目计划》由项目经理负责制定，由机构领导审批。而下属计划书一般由项目成员制定，由项目经理审批即可。
项目计划的主要内容
项目目标与范围；
过程模型与技术方法；
人力资源计划；
软硬件资源计划；
财务计划；
进度计划；
下属计划。
3.项目计划审批
项目经理把《项目计划》递交给机构领导。
机构领导认真阅读该《项目计划》，如果没有异议，就签字批准，使其成为正式文件；如果有不同意之处，就和项目经理沟通，并请项目经理及时修改。
如果是合同项目，要请甲方代表共同审批项目计划。
4.项目计划变更控制
《项目计划》不是一成不变的。
一般的，若下列情况发生，应当变更《项目计划》：
•进度偏差超过了容许的误差，如20%；
•费用偏差超过了容许的误差，如20%；
•项目过程模型发生了显著的变化；
•用户需求发生了重大的变化；
•发生了不可抗拒的变化，如公司裁员、机构调整、产品发展战略调整等。
项目计划的变更应遵循严格的变更控制流程。

怎样选择项目的过程模型和技术方法等
选择项目方法有时也称为“项目分析”或“技术策划”。
1.分析项目特征
2.选择过程模型
3.制定技术计划
1.分析项目特征
（1）系统的需求是否明确和固定？
有一些软件产品的需求是比较明确的，而且随着时间的推移不会产生太大的变化；而另外一些软件产品的需求会频繁地变更，且隐含着很多的不确定性。

（2）系统的规模和复杂性如何？
系统要解决的问题的规模和复杂性对项目方法的选择有很大影响。

（3）项目团队的经验和技能如何？
项目团队是否有开发类似系统的经验？是否有可供复用的软件资产？是否具有开发系统所需的技能？

（4）软件产品是什么类型？
不同类型的软件产品要用不同的方法学和技术来实现，对软硬件平台的要求也有很大差别。例如实时控制系统可能要使用时态逻辑、Petri网这样的技术，嵌入式控制系统要求软件对存储器的使用要严格控制，管理信息系统通常是面向数据的，需要使用数据库和合适的开发平台。

（5）系统是不是安全性关键的？
如果系统的故障会造成巨大的经济损失，甚至会危及人的生命，那么系统的安全性和可靠性要求就很高，测试工作必须做得非常充分，在开发过程中可能还需使用诸如Z和VDM之类的形式化方法，并考虑使用n版本技术。

2.选择过程模型
过程模型特征总结
线性模型是计划驱动的，强调严格按照计划执行，要求在项目之初就明确需求和解决方案。
迭代型/适应型/极限型模型是价值驱动的，强调不断为用户提供实际价值以及过程的适应性和敏捷性，允许随着项目的进展逐渐明晰需求和解决方案。
3.制订技术计划
技术计划一般包含如下内容。
•待开发系统的特征；
•选择的过程模型；
•开发方法；
•需要的软件工具；
•系统运行的硬件/软件环境；
•需要的培训。

软件项目范围管理综述--软件项目管理第3章总结回顾

一、获取需求和定义范围

需求获取工作的任务就是收集项目干系人的需求信息，为定义项目的范围奠定基础。由于需求获取可能是软件开发中最困难、最关键、最易出错和最需要交流的活动，故其只能通过用户与开发人员之间进行高度的合作和交流才能成功。在需求获取活动中，开发人员并不是简单地照抄用户所说的话，而是要从用户所提供的大量信息中分析和理解用户真正的需求。

把需求分为不同的类别，有利于对需求进行完善和细化。软件项目的需求分类一般包括以下几种。

1.界面需求:描述软件系统的外部特性，即系统如何从外部得到数据输人，如何向外部输出数据。

2.功能需求:列出软件系统必须完成的所有功能。

3.性能需求:响应时间、吞吐量、处理时间、存储空间等方面的限定。

4.质量需求:对安全性、保密性、可靠性、可维护性、可移植性、易用性等方面的要求。

5.资源使用需求:对硬件、支持软件、数据通信接口等方面的要求。

6.软件成本消耗与开发进度需求:即对时间和经济方面的要求。

7.异常处理要求:在运行过程中出现异常情况（如临时性或永久性的资源故障，不合法或超出范围的输人数据、非法操作等）时应采取的行动以及希望显示的信息。

获取需求的常用方法包括访谈、会议、观察用户工作流程、问卷调查、快速原型法等，以下分别作简要介绍。

1.访谈

访谈是通过与干系人直接交谈来获取信息。访谈的典型做法是向被访者提出问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的一对一谈话，但也可包括多个访谈者或多个被访者。访谈有经验的项目参与者、发起人以及主题专家，有助于识别和定义项目可交付成果的特征和功能。

2.讨论会

讨论会把主要项目干系人召集在一起，通过集中讨论来定义项目需求。讨论会是快速定义跨职能需求和协调干系人差异的重要方法。由于群体互动的特点，被有效引导的讨论会有助于参与者之间建立信任、改善关系、改进沟通，从而有利于干系人达成一致意见。在每次讨论会中，都必须记录所讨论的内容，并在会后加以整理。值得注意的是，在讨论会上必然会涉及某些细节问题，特别是有些问题的回答需事先做准备。因此，在召开讨论会之前，提前发给参加人员有关讨论会的议题和内容等材料将有助于提高讨论会的效率。

3.观察用户工作流程

直接观察用户在其实际环境中怎样执行工作是一种行之有效的获取需求方法。当产品使用者难以清晰说明他们的需求时,就特别需要通过观察了解他们的工作细节。观察也称为“工作跟踪",通常由观察者从外部来观看业务专家如何执行工作。也可以由“参与观察者”来观察，他通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

4.问卷调查

问卷调查是指设计一系列书面问题,向众多受访者收集信息。当需要调查大量人员的意见时，向被调查人分发调查问卷是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。调查者应仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。

5.快速原型法

快速原型法是指在软件开发的早期快速建立目标软件系统的原型，并据此征求用户对需求的反馈。由于原型是可以操作的，它使得用户可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述，从而可以获得更为准确和清晰的需求。快速原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息。

范围定义

范围定义就是制定项目和产品的详细描述，从而定义项目的范围。由于在获取需求过程中识别出的所有需求未必都包含在项目中，所以范围定义过程就是从所获取的需求中选取最终的项目需求，然后制定出项目及其产品的详细描述。

在软件项目中，可能需要多次反复开展范围定义过程。随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。在迭代型生命周期的项目中，先为整个项目确定一个高层级的范围，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

范围定义的结果记录在项目范围说明书中。

软件产品范围和项目范围

软件项目的目标是开发某软件系统或产品，软件产品是项目的最终交付物，因此软件产品范围是软件项目范围中最重要的一部分。

在软件项目中,产品范围通常表现为软件需求规格说明书( SRS )，它一般包括下面三部分内容。

功能特征描述。

即软件系统向使用者提供什么样的功能。

系统接口描述。

即描述软件系统与其他软硬件系统之间的接口。随着企业信息化水平的提高和软件技术的发展，软件系统之间呈现越来越复杂的关系，软件系统的接口数量也在快速增长。在描述系统范围时，明确接口是非常必要的。

质量特征描述。

主要的质量特征包括性能、可靠性、可移植性、机密性、可维护性等。不同程度的质量要求对项目的工作范围会有很大影响，例如一般性能要求的系统不需要额外的设计，而如果对性能要求非常高，则需要在设计阶段就进行特殊的设计，在开发后期对系统性能做专门的优化，在测试阶段对性能作相应的测试。而且，此处定义的系统质量特性也是项目开展质量控制工作的依据。

除了产品范围外，项目范围经常包含更多的内容。比如一些软件项目的交付物中会包含系统需求规格说明书、系统设计说明书、使用手册等，还要为用户提供培训。那么，项目经理就必须把编写满足要求的文档、为用户提供培训作为项目范围中的工作，并编排到进度计划中。

就软件项目而言，项目范围中较难把握的一部分就是软件产品的范围。软件本身是抽象的，也没有找到一种简单的、可以避免歧义和理解偏差的系统功能描述方法，因此对软件系统的描述经常会有模糊性和二义性，基于此定义出的系统范围也是模糊的，这也是软件项目范围难于管理的重要原因。

项目范围说明书

项目范围说明书是范围定义的工作成果，它详细描述了项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。在实际的软件项目中，可能不会出现一份叫做《项目范围说明书》的文档，但其中的内容可能会被多个文档包含，如《项目合同》《项目计划》《需求规格说明书》等。项目范围说明书一般包括以下内容。

产品范围描述。

即项目所创造的产品的特性。

验收标准。

可交付成果通过验收前必须满足的一切条件。

可交付成果。

在某一过程、阶段或项目完成时，必须产出的可核实的产品和成果。

项目的除外责任。

通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理项目干系人的期望。

制约因素。

需要列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件。例如，客户或执行组织事先确定的预算，强制性日期或进度里程碑。如果项目是根据协议实施的,那么合同条款通常也是制约因素。

假设条件。

在制定计划时，一些未经验证就被视为正确、真实或确定的因素。由于假设条件未经验证，因此构成项目的风险。对假设条件还应描述如果条件不成立，可能造成的潜在影响。

二、WBS的作用和创建方法

创建工作分解结构就是把项目分解成具有内在联系的、更小、更详细、易于管理、易于控制的组成部分。通过创建工作分解结构，不仅使项目范围更为明确，而且为制定进度计划、成本计划等提供了基础。

工作分解结构（Work Breakdown Structure，WBS)是对项目团队为实现项目目标、创建可交付成果而需实施的全部工作范围的层级分解。项目是由一系列活动构成的，WBS就是这一系列活动的结构化组织。因为WBS是一种层次化的结构，通过WBS把握项目的工作可以让项目变得更加清晰和易于理解。一个描述了全部项目工作的WBS就是项目的范围。因此在项目结束后，很多软件组织都会把项目的WBS保存起来，供以后的项目参考。在项目初期，项目经理也经常参考类似项目的WBS来把握尚不明确的项目。

WBS最低层次的组件被称为工作包，它是项目中最小的可控单元。每个工作包是一些短期的活动，有明确的起点和终点，需要消耗一定的资源，占用一些成本。同时，每个工作包又是一个可控制点，可以进行进度的监督和检查。

创建WBS的方法

创建WBS 就是对项目进行分解的过程，常见的分解方法有类比法、自顶向下的分解、自底向上的归纳3种。

1．类比法

类比法就是参考类似的已经完成的项目的WBS 和项目经验，根据当前项目特点做必要的调整，从而得到当前项目的WBS。这种方法容易把握，而且可以在WBS分解中融入上一项目的经验和教训,从而得到结构更为良好的WBS,有利于项目质量的改进。但类比法也有一定的局限性,需要有较完整的历史数据的支持，在缺乏历史数据的时候很难完成整个项目的分解工作或分解的质量较低。这时就需要采用其他的分解方法作为辅助。一般来说，如果软件组织经常性地在某一行业或某一产品中重复多个项目，则项目过程的重合度比较高，很容易参考历史数据，类比法的使用效果较好。

2.自顶向下的分解

自顶向下的分解方法是把项目从粗粒度的轮廓逐层细化，得到整个项目的分解结构。这种方法符合人们理解和思考复杂问题的过程,因为在面对复杂项目的时候，人们通常会采用逐步分解，化整为零并分而治之的方法。自顶向下的分解质量直接决定于分解者对项目的理解，经验丰富的分解者更容易得到结构良好的WBS。

3．自底向上的归纳

自底向上归纳是一个通过对细粒度工作的逐层归纳以得到整个项目WBS的方法。在采用这种方法时，通常会召集相关人员通过头脑风暴的方式完成。参加分解工作的人员根据自己的理解识别项目中的工作，尽可能详细地列出完成项目所涉及的各项具体的工作任务，然后对各项工作任务进行分类整合，归并到一个或者若干个更大的活动中，并构成WBS的上一级内容。这种方法较其他两种方法更适合不熟悉的项目，对于那些没有历史数据或不能找到有丰富经验的专家的项目更适合。通过自底向上归纳团队中不同成员的想法，更容易发挥团队的力量。但这种方法的缺点也是明显的，即分解过程的投人太大，会花费较多的时间和成本，因此这种方法很少独立使用。

以上介绍的3种分解WBS 的方法各有优缺点，需要根据不同的情况选用。对于一些项目，需要综合使用几种方法才能得到结构良好的WBS。

创建WBS 时，对相同的项目存在着不同的分解策略，最常用的两种策略是根据交付物进行分解和根据项目阶段进行分解。

根据交付物进行分解的策略是根据项目中必须产生的交付物来划分项目中的工作。例如，在一个软件开发项目中，规定必须交付需求规格说明书、概要设计说明书、详细设计说明书、软件系统、系统测试报告、系统试运行报告、用户手册这些交付物。在创建WBS 时，把这些交付物作为分解的第二层，确定整个WBS 的架构，然后通过类比、自顶向下或自底向上的方法继续分解。例如，为了创建需求规格说明书这个可交付物，需要执行需求收集、需求分析和文档编写工作，可把这3项工作作为wBS 中“需求规格说明书”的下一级的活动。

由于WBS本身就是面向交付物的，因此根据交付物逐层分解可以很自然地得到结构良好的WBS，不会遗漏项目必需的工作包。

根据项目阶段分解就是首先确定整个项目必须经历的阶段，然后再逐步细化每一阶段工作的细目。WBS就是按照项目阶段分解得到的。这种分解策略是从工程的角度进行项目分解，使WBS结构与项目工程过程较为一致，但该策略对使用者的项目工程经验要求较高，项目工程经验不足则较容易遗漏项目中必须的工作包。

WBS工作分解的细致程度根据项目具体情况的不同而会有差异。工作分解得越细致，对工作的规划、管理和控制就越有力;但是，过细的分解会造成管理工作的无效耗费，资源使用效率低下，工作实施效率降低。因此WBS的层数不宜太多。

在创建WBS 时，要注意分解的活动至少要满足四点要求。

1.分解出的工作对于完成上层相应交付物来说是必要且充分的。

2.工作的独立性。即工作一旦开始，就可以在不中断的条件下完成。

3.工作完成度的可判断性。即可以清楚地判断工作是否已经开始，工作完成了多少，以及工作是否完成。

4.工作的交付成果。即明确工作完成后将得到什么样的成果。

三、范围确认和控制

范围确认

范围确认是指正式验收已完成的项目可交付成果，从而确认项目可交付成果是否可以让项目干系人满意。即使由于某些原因造成项目提前终止，也需要通过范围确认来验证项目的完成度，了解哪些内容已经完成而哪些内容尚未完成。

范围确认容易同质量控制混淆到一起。质量控制工作关心的是交付物是否满足质量标准，而范围确认工作关注的是交付物是否满足项目范围说明书中规定的项目范围。通常在进行范围确认前，项目组需要先进行质量控制工作，如系统测试等工作，以确保范围确认工作的顺利完成。

范围确认工作一般由客户、发起人等关键项目干系人负责。

范围控制

软件项目充满着各种各样的变化，用户业务过程、组织机构、系统运行环境等方面的变化都可能导致项目范围的变更，而项目范围的变更必然会造成项目进度计划、人员安排、成本等各方面的变化，处理不当则会增加项目风险，甚至造成项目陷入混乱的状态。范围控制就是为了解决这样的问题，消除范围变更造成的不利影响。

范围控制就是指监控项目的范围状态,管理范围变更。范围控制的目的不是阻止变更的发生，而是在出现范围变更需求后，管理相关的计划、资源安排以及项目成果，使得项目各部分可以很好地配合在一起，避免变更带来的负面影响。

未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更是不可避免的，为防止范围蔓延，在每个项目上，都必须强制实施某种形式的变更控制。

范围控制通过变更控制系统和配置管理系统来完成。当出现范围变更需求时，通常要执行一个严格的变更控制流程，该流程包括变更请求、变更评估、变更实现等多个步骤。变更实现涉及配置项（如需求规格说明书)的修改，要遵守配置管理规范。在软件项目中，变更是必然且频发的，在项目初期就建立起完整的变更控制和配置管理的流程可以使项目在有序的变化中不断前进。

四、不同过程模型中的范围管理的区别

生命周期模型	预测型生命周期	适应型/敏捷型生命周期
总体模式	在项目开始时对项目可交付成果进行定义，范围变化要走正式变更流程	每次迭代开始时定义和批准详细的范围。因此，整体范围被分解成一系列的未完成清单
何时定义范围	在项目开始时收集需求、定义范围、创建WBS，变更需要走正式流程	每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建WBS
范围基准是什么	根据预先定义的范围基准来确认范围和控制范围	使用未完成清单（包括产品需求和用户故事）来反映当前需求。
何时确认范围和控制范围	在每个可交付成果生成时或在阶段审查点时确认范围，而控制范围是持续的过程。	每次迭代中，都会重复开展两个过程：确认范围和控制范围。
基本特征	需求稳定，技术成熟。	应对大量变更，相关方持续参与

软件项目进度管理综述--软件项目管理第4章总结回顾

一、进度管理的目标和主要内容

软件项目进度管理是软件项目管理的一个重要方面，它是保证项目如期完成、合理安排资源供应及节约工程成本的重要措施之一。

项目的成本管理、进度管理、质量管理是相互关联、相互制约的。通常，加快项目实施进度需要增加项目投资，而项目提前完成又可能提高投资效益;严格控制质量标准可能会影响项目实施进度，增加项目投资，而严格的质量控制又可避免返工，从而防止项目进度计划的拖延和投资的浪费。所以对项目的成本管理、进度管理和质量管理不能片面强调某一方面，而是要相互兼顾、相辅相成，这样才能真正实现项目管理的总目标。

什么是项目进度管理

项目进度管理也被称作项目时间管理、工期管理，是指在项目实施过程中，对各阶段的工作进展程度和项目最终完成的期限所进行的管理，是为了确保项目按期完成所需要的过程。

项目的重要特征之一是具有时间期限，要在一定的时间和预算内完成一定的工作，并使客户满意。因此为了使项目能够按时完成，在项目开始之前制定一份项目的进度计划非常有必要，这里的进度计划就是使项目的每项活动的开始及结束时间具体化的计划。

项目进度管理就是要采用一定的方法对项目范围所包括的活动及其之间的相互关系进行分析，对各项活动所需要的时间进行估计，并在项目的时间期限内合理地安排和控制活动的开始和结束时间。显然，这对保证项目按照时间期限完成项目全部工作范围具有重要的作用。

项目进度管理的内容

项目进度管理在内容上可概括为6个主要部分。

1.活动定义:确定为完成各种项目可交付的成果所必须进行的各项具体活动。

2.活动排序:确定各项活动之间的依赖关系，并形成文档。

3.估算活动资源:估算执行各项活动所需的人员、设备等资源的种类和数量。

4.估算活动持续时间:估算完成单项活动所需要的时间长度。

5.制定进度计划:在分析活动顺序、活动持续时间和资源需求的基础上编制项目进度计划。

6.进度控制:监督项目活动状态，控制项目进度计划的变化，保证项目按时完成。

项目进度管理的6个主要部分是相互影响、相互关联的，这些部分在实际的项目管理中通常表现出相互交叉和重叠的关系。在某些项目中，特别是一些小型项目中，一些管理过程甚至可以合并在一起视为一个阶段。例如一些小型项目中的活动排序、活动持续时间估算和进度计划编制之间的关系极为密切，可以由一个人在较短时间内完成，因此可以视为一个过程。

二、活动定义和排序

完成每一个项目，无论项目的规模大小，都必须要完成一系列的具体工作，即活动。项目进度管理就是使用一定的方法定义、分析项目范围所包括的所有活动及其相互关系，估计各项活动所需要的时间和资源，并在项目的时间期限内合理地安排和控制活动的开始和结束时间。

为了有效地实现项目，在整个项目管理过程中对活动作出准确的定义是非常必要的。活动定义就是要确定WBS 工作分解结构中各工作包对项目团队的要求是什么，怎样工作才能取得该工作包所要求的成果。

活动定义的依据主要包括工作分解结构、项目范围说明、历史信息以及相应的约束条件等方面的内容。活动的定义是在工作分解结构的基础上，进一步将工作包分解成更小的、更容易控制的、更具体的活动序列，从而确定实现项目目标所需要的全部活动。在活动定义时必须考虑范围说明中列出的项目合理性说明和目标说明，使所确定的活动在项目范围之内。定义活动时还需要考虑历史信息，这既包括项目前期的各种信息、与项目有关的以前类似项目的信息和其他组织开发的类似项目的各种信息，这些历史信息对工作分解和活动定义是有指导作用和参考价值的。活动定义时，必须考虑对项目的限制条件和限制因素，例如活动允许持续的最大时间、可以支付的最大成本等。

活动定义的一般方法有活动分解法和参照模板法等。

活动分解法是在WBS 的基础上，将项目工作任务按照一定的层次结构逐步分解而成，以期分解成更小的、更容易控制的和更具体的活动,产生项目的活动清单。

参照模板法法是将已经完成的类似项目的活动清单或者其中的一部分作为一个新项目活动清单的参考模板,根据新项目的实际情况，在模板上调整项目活动，从而定义出新项目的所有活动。虽然每个项目都是独一无二的，但仍有许多项目彼此之间存在着某种程度的相似之处，许多应用领域都有标准的或半标准的活动分解可以作为参考模板。因此在定义项目活动时，模板法是一种简洁、高效的活动分解技术。

当完成活动定义后,其输出的结果为活动清单。活动清单包括了整个项目将进行的所有活动，它是工作分解结构的必要扩充。活动定义的关键是分解的活动清单完整而又不包括多余的活动，既能完成WBS中所定义的可交付成果，同时又能满足项目范围说明。

活动定义过程在WBS形成后即可开始，它是项目时间管理后续几个过程的基础。

活动排序是分析项目活动之间的相互依赖关系，确定活动的逻辑顺序，以便在所有项目约束条件之下获得最高的项目工作执行效率。活动排序可以使用计算机辅助工具(如MS Project )，也可以手工完成，在实际应用中，手工推算和计算机工具可以结合使用。

在进行活动排序前需具备以下条件:

①活动清单，这是活动排序的主要基础，排序就是对清单中的活动进行相互关系的分析和安排。

②产品描述，是项目生产的产品和提供的服务的描述文档，产品和服务的功能、性能等特性会对活动排序产生影响。

③项目的约束条件，会制约资源的使用，也会对活动排序产生影响。如果没有对资源的要求，许多活动是可以并行的，而一旦增加了这些约束后，就可能需要变成串行了。

④里程碑，它是项目实施过程中一些必须发生的标志性的事件，例如一些标志性工作任务的完成，或者一些可交付的阶段产品或服务的提交等。安排活动顺序必须将里程牌事件作为活动的一部分，以确保里程碑的发生。

确定活动之间的逻辑关系

在进行活动排序时，必须了解活动之间可能存在的逻辑关系，例如哪些活动可并行执行，哪些活动一定要在某些活动完成后才能开始。活动之间的逻辑关系一般有下列几种。

1.结束-开始(Finish-Start)，是指一个活动结束后，另一个活动才能开始。这是一类最普遍也是最常用的活动关系类型。例如，插好网线后才可连接网络。

2.开始-开始（Start-Start)，是指一个活动开始后，另一个活动才能开始。这种关系类型常表示某种并行而且具有一定依赖关系的活动。例如，在软件项目中，软件质量保证活动开始后，才能进行缺陷的计数。

3.结束-结束(Finish-Finish)，一个活动结束后，另一个活动才能结束。例如，只有完成文档的编写，才能完成文档的编辑排版。

4.开始-结束(Start-Finish )，一个活动开始后，另一个活动才能结束。例如，只有第二位保安人员开始值班，第一位保安人员才能结束值班。这种逻辑关系在实际的项目中很少出现。

确定活动之间逻辑关系的依据是活动之间的依赖关系，依赖关系可分为以下两种。

1.强制性依赖关系。强制性依赖关系是指由工作内在性质决定的固有的依赖关系，或由法律或合同所强制规定的依赖关系。这种关系通常与客观限制有关，例如只有在软件编码完成后，才能进行构建和测试。强制性依赖关系又称为硬依赖关系。

2.选择性依赖关系，又称首选逻辑关系、优先逻辑关系或软逻辑关系。项目人员根据项目的实际情况，从优化项目方案的角度来确定选择性依赖关系。因此，选择性依赖关系的确定带有主观性。

明确了活动之间的逻辑关系后，就可以进行活动排序了，活动排序的结果用网络图来表示。常用的绘制网络图的方法有前导图法( Precedence Diagramming Method, PDM )和箭线图法(ArrowDiagramming Method，ADM )。

前导图法(PDM)是用节点（方框或者圆)代表一项活动，用带箭头的线段表示活动间的依赖关系。这种表示法也称为AOV网，是多数项目管理软件所采用的方法。在前导图法中，结束-开始关系是最常见的逻辑关系。方框表示活动，带箭头的线段表示活动顺序。活动框中的标识和活动名称需与活动清单一致。

箭线图法(ADM):用带箭头的线段表示活动，通过节点将活动连接起来，表示结束-开始的依赖关系。这种表示法也称为AOE 网，用带箭头的线段表示活动，而节点表示事件。二者之间的关系是，只有带箭线表示的活动完成后，箭线终点处节点代表的事件才能发生;而只有箭线起点处节点代表的事件发生后，该活动才能开始。即当某个事件发生后，起始于它的活动才能开始;而只有当某个事件的所有前续活动都结束后，该事件才能发生。例如，事件2发生，活动A2、A3才能开始;事件6的发生条件必须是活动A5、A6的完成。

在箭线图法中，当正常的活动箭线已不能全面或正确描述逻辑关系时，需要使用虚拟活动。虚拟活动在图形中用虚线箭头表示。例如 ,虚拟活动v1表示事件4的发生必须是在事件3发生后。

活动排序的成果主要包括两个方面:

①项目网络图。即项目活动及其相互关系的示意图。除此之外，还应当有对活动的简单描述、重要活动说明等。

②更新的活动清单:在活动排序过程中，需要对活动之间的逻辑关系进行分析和确认，可能会对某些活动进行重新分解和定义，需要更改项目活动清单，甚至工作分解结构。活动排序的结果是进度计划编制的基础。

三、估算活动资源

估算活动资源的目的是明确完成活动所需的资源的种类、数量和性质，以便作出更准确的成本和持续时间估算。项目的一大特征就是资源约束性，即项目只能够得到有限的资源支持。因此，对于任何活动而言，不考虑该活动所需的资源配置情况就讨论其持续时间长短是没有任何实际意义的。对每项活动应该在什么时候使用多少资源必须有一些估算，即估计项目活动的资源需求以及能否按时、按量、按质提供，这对项目活动的历时估计具有直接的影响。

在估算资源需求情况时，需要了解在活动进行期间内哪些资源（如人力资源、设备等)可用、何时可用以及可用多久，这些信息通常记录在“资源日历”中。此外，还需要考虑更多的资源属性，如经验和技能水平、来源地等。

由于人力资源是软件项目最重要的资源，因此必须很好地了解每个人的可用性和时间限制，如时区、工作时间、休假时间、当地时间、当地节假日等。

在估算活动资源时，历史数据（特别是类似项目的活动资源需求情况）有重要的参考价值。

四、活动历时估计方法

估算活动持续时间就是在给定的资源条件下，估计完成每个活动所需花费的时间量，为制订进度计划过程提供主要输入。估算活动持续时间的方法有多种，如专家判断、类比估算、三点估算、参数估算等，以下各小节分别进行介绍。

专家判断

当实施的项目涉及新技术或不熟悉的领域时，项目管理人员由于不具备专业技能，一般来说很难作出合理的时间估算，这就需要借助特定领域专家的知识和经验。通过借鉴历史信息，专家判断能提供持续时间估算所需的信息，或根据以往类似项目的经验，给出活动持续时间的上限。此外，专家判断也可用于决定是否需要联合使用多种估算方法，以及如何协调各种估算方法之间的差异。

类比估算

类比估算是通过与以往类似项目相类比得出估算。为了使这种方法更为可靠和实用，作为类比对象的以往项目不仅在形式上要和新项目相似，而且在实质上也要非常趋同。在这种情况下，类比估算是一种非常简便有效的方法。

类比估算是一种粗略的估算方法，有时需要根据项目复杂性方面的已知差异进行调整。在项目详细信息不足时（例如在项目初期)，经常使用这种技术来估算项目持续时间。

三点估算

三点估算源于计划评审技术PERT。对于一些具有高不确定性的活动，估算持续时间可能会产生较大的误差，失去时间估算的意义，而三点估算可以尽可能地降低单一估算所产生的误差，它采用3种估算值来界定活动持续时间的近似区间。

1.最可能时间——Tm:根据以往的经验，这项活动最有可能用多少时间完成。

2.最乐观时间——T:当一切条件都顺利时该项活动所需时间。

3.最悲观时间——T。:在各项不利因素都发生的最不利条件下，该项活动需要的时间。则活动持续时间的期望值T。的计算公式为:Te=( Ta+4×Tm+Tb)/6。

用三点估算得到的估计值有较大的不确定性，因此必须注意时间期望值的风险评估。

参数估算

参数估算是一种基于历史数据和项目参数，使用某种数学模型来计算成本或持续时间的估算技术。这种技术是利用历史数据之间的统计关系和其他变量(如活动的工作量)来估算诸如成本和持续时间等活动参数。

最简单的一种参数估算方法就是把需要实施的工作量（或规模）乘以完成单位工作量（或规模）所需的工时，即可计算出活动持续时间。例如，一个软件模块的规模是2个功能点，根据软件组织的历史数据，一个开发人员完成一个功能点平均需要2天时间，那么一个开发人员完成该软件模块需要4天时间。

参数估算法需要积累历史数据，根据历史数据运用建模技术建立模型。许多由历史经验数据导出的参数估算模型的形式为:D=a×E，其中D为持续时间，E为工作量（通常用人月表示),a和b为依赖于项目自然属性的参数。例如Pubnam模型的公式为D=2.4×E13，基本COCOMO模型的公式为D=2.5×E，其中b是0.32~0.38之间的参数。

参数估算的准确性取决于参数估算模型的成熟度和历史数据的可靠性。

五、制定进度计划

制定进度计划就是分析项目活动顺序、持续时间、资源需求和进度制约因素，创建包含各个活动计划日期的进度模型。制定进度计划的相关技术包括甘特图法、关键路径法、关键链法、资源优化、进度压缩。

甘特图法

甘特图（Gantt Chart）又称横道图、条形图（ Bar chart )。它通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。使用甘特图能方便地看到任务的工期、开始和结束时间以及资源的信息。

甘特图表示方法简单，横轴表示时间，纵轴表示活动，用横条表示活动的时间跨度，横条的左端表示活动的开始时间，右端表示活动的结束时间。实心横条表示实际进度，空心横条表示计划进度，因此一项活动需要占用两行空间。有时为了所绘制的甘特图更加紧凑，用方向向上三角形表示开始时间，向下三角形表示结束时间，计划时间和实际时间分别用空心三角形和实心三角形表示。如此，一个活动只需要占用一行的空间。

甘特图可以直观地表明任务计划在什么时候进行，以及实际进展与计划要求的对比。管理者由此极为便利地搞清楚一项任务（项目）还剩下哪些工作要做，并可评估工作进度。然而甘特图也有以下主要缺点。

1.不能明显地描述各项作业间的依赖关系。

2.进度计划的关键部分不明确，难以判断哪些部分应当是关键活动;不能反映某一项活动的进度变化对整个项目的影响。

如今，大部分项目管理人员都选择使用项目管理软件来创建复杂的甘特图。实际上，现代项目管理软件将甘特图进行了许多改进，在原来甘特图的基础上发展出了列表甘特图、跟踪甘特图等形式，因而可以更容易地显示和更新项目信息。

关键路径法

关键路径法(Critical Path Method，CPM )由柱邦公司提出，它通过对网络图进行时间参数的计算，找出计划中的关键活动和关键路径，并且计算其他路径可以浮动的时间，进而明确所有活动在时间安排上的灵活性。

活动的时间参数

项目的每个活动都具有以下时间参数。

1.最早开始时间（Early Start，ES )，指一个活动最早可以开始的时间。

2.最早结束时间（Early Finish，EF)，指一个活动最早可以完成的时间。

3.最迟开始时间(Late Start )，在不影响项目完工时间的情况下，一项活动最晚必须开始执行的时间。

4.最迟结束时间(Latc Finish，LF )，指在不影响项目工期的情况下，该活动最晚必须完成的时间。

5.超前(Lead );两个活动的逻辑关系所允许的提前后置活动的时间。例如，在需求分析完成之前两天，总体设计就可以开始,则总体设计活动有两天的超前。

6.滞后( Lag ):两个活动的逻辑关系所允许的推迟后置活动的时间。例如，刷房子时，刷油漆后要刷涂料，刷油漆完成后要等待一天，等油漆干了以后才能刷涂料，则剧涂料活动有一天的滞后。

7.总浮动时间（Total Float，TF )，是一个活动在不影响项目最早完成时间的情况下可以延迟的时间量。TF-LS-ES或TF一LF-EF。

8.自由浮动(Free Float，FF)是一个活动在不影响其所有后置活动的最早开始时间的情况下，可以延迟的时间量。FF=min ( TI ), min表示取最小值，TI的含义为：

TI=后置活动的ES-本活动的EF一Lag

在用关键路径法制定进度计划时,需计算或使用上述时间参数

正推法和逆推法

关键路径法使用正推法来确定项目各活动的最早开始时间和最早结束时间，使用逆推法来确定项目中各活动的最晚开始时间和最晚结束时间。

正推法从网络图的起始点（开始活动）按照时间顺序正向经过整个网络图至结束点，计算出所有活动的最早开始时间和最早结束时间。其执行过程如下。

1.首先建立项目的开始时间。项目的开始时间是网络图中第一个活动的最早开始时间。 2.按网络图从左到右的顺序逐个计算活动的最早开始和结束时间。所用的公式为:EF=ES+Duration( Duration是活动的持续时间）。

ES(s一EF+Lag 或ES(s)-EF-Lead ( ES(s)表示后置活动的最早开始时间)。

3.当一个活动有多个前置活动时，选择其中最大的最早结束时间作为其最早开始时间。

逆推法从网络图结束点（终止活动）逆向经过网络图至开始点计算出所有活动的最迟结束时间LF和最迟开始时间LS。此方法的执行过程如下。

1.首先建立项目的结束时间，项目的结束时间是网络图中最后一个活动的最迟结束时间，而最后一个活动的最迟结束时间就等于其最早结束时间，即LF=EF。

2.按网络图从右到左的顺序进行计算。所用公式为:

LS=LF-Duration

LS-Lag-LF(p)或LS+Lead-LF(p). LF(p)表示前置活动的最迟结束时间。

3.当一个活动有多个后置活动时，选择其中最小的最迟开始时间作为其最迟结束时间。

关键路径

如果活动的总浮动时间为0，则称之为关键活动，网络图中由代表关键活动的节点组成的路径，称为关键路径。关键路径是在所有从开始活动到终止活动的路径中，路径上所有活动持续时间相加最大的那些路径。一个项目的关键路径可能不只一条，关键路径决定了项目的总工期，由于关键路径上的活动浮动时间为0，因此，关键路径上任何活动的延期都会引起项目的延期，这些活动是项目风险的重要来源。而在非关键路径上的活动则可以根据其浮动时间的长短作灵活安排。

明确关键路径后，可以合理安排进度，调配资源。对非关键路径上的活动进行调整，合理利用它们的浮动时间，往往可以安排出既节省资源又不影响项目完工时间的进度表。

关键链法

关键链法(Critical Chain Method，CCM)是由美国管理学专家艾利·高德拉特（Eli Goldratt )提出的一种项目管理方法。该方法自1997年提出后，在实际应用中取得很大成功,引起了广泛重视。关键链法建立在关键路径法基础之上，它对关键路径法主要做了以下几方面的改进。

关键路径法是在不考虑任何资源限制的情况下，在给定活动持续时间和逻辑关系的条件下，分析项目的关键路径，而关键链法考虑了资源限制对项目活动逻辑关系及关键路径的影响。

2.关键链法引人了缓冲和缓冲管理来应对项目的不确定性。

3.关键链法考虑了人的心理行为因素和工作习惯，因为人是项目实施的主体，是项目最关键的资源。

关键链法是一种根据有限的资源来调整项目进度计划的进度网络分析技术。首先，根据持续时间估算和给定的依赖关系绘制项目进度网络图;然后，计算关键路径。在确定了关键路径之后，再考虑资源的可用性，制定出资源约束型进度计划，该进度计划中的关键路径常与原先的不同。资源约束型关键路径就是关键链。

关键链法增加了持续时间缓冲来应对不确定性。放置在关键链末端的缓冲称为项目缓冲(Project Buffer )，用来保证项目不因关键链的延误而延误;放置在非关键链和关键链接合点处的缓冲称为汇人缓冲(Feeding Buffer )，用来保护关键链不受非关键链延误的影响。应该根据相应活动链的持续时间的不确定性，来决定每个缓冲时段的长短。如果一些活动不能在计划时间内完成，缓冲时间就会被占用。在项目实施过程中，要监控缓冲时间被占用的情况。可建立一种预警机制，例如当缓冲时间被占用三分之一时，发出预警信号;被占用三分之二时，要立即采取纠正措施。

关键链法的理论依据之一是“帕金森定律”。帕金森定律是指:工作总是拖延到它所能够允许最迟完成的那一天。也就是说，如果工作允许拖延、推迟完成，往往这个工作就会推迟到它能够最迟完成的那一天，很少有提前完成的。所以在大多数情况下都会造成项目延期、工作延期，或勉强按期完成工作。

在项目实践中，人们在估算一项活动的持续时间时，为保证活动能按时完成，总是习惯于安排一定的时间浮动和安全裕量，那么根据帕金森定律，在执行活动时，往往会推迟到它所允许的最后一天为止，这一期间整个工作就没有充分发挥它的效率，造成了资源和时间的浪费，而且很容易导致项目工期的推迟。关键链法要求在进行项目估算的时候，把个人估算当中的一些隐藏的裕量剔除，把富余的时间压缩出来，作为缓冲，成为项目管理的一个公共资源统一调度、统一使用，使备用的资源有效运用到真正需要它的地方，这样就可以大大缩短原来项目的工期。

六、进度控制

项目实施过程中会遇到各种客观的或主观的不确定性因素，导致进度计划的执行出现偏差。进度控制就是指监督项目活动的状态，发现实际进度与计划进度的偏离，分析发生偏离的原因和程度，评估这些偏差对未来工作的影响,并决定是否采取纠正或预防措施。

常用的进度控制技术

常用的进度控制技术有以下几种。

1.进度偏差分析。这种技术是将项目实际进度和进度基准计划利用图形的形式直观地进行比较分析。例如在甘特图上可以用不同颜色的横道线来表示计划和实际进度,可以非常直观地看到进度偏差。

2.关键路径法中的进度分析。通过比较关键路径的进展情况来确定进度状态。关键路径上的差异将对项目的结束日期产生直接影响。评估次关键路径上的活动的进展情况，也有助于识别进度风险。

3.关键链法中的进度分析。比较剩余缓冲时间与所需缓冲时间，有助于确定进度状态。是否需要采取纠正措施,取决于所需缓冲与剩余缓冲之间的差值大小。

4.挣值管理。采用进度绩效测量指标，如进度偏差（SV)和进度绩效指数(SPI)，评价偏离初始进度基准计划的程度。有关挣值管理,请参见本书第5.5节的内容。

5.项目管理软件。可借助项目管理软件，对照进度计划，跟踪项目执行的实际日期，报告与进度基准相比的差异和进展,并预测各种变更对项目进度模型的影响。

项目进度计划变更

当项目的实际进度与计划进度之间的偏差超过了一定程度，对项目进度计划的总目标或后续工作产生影响时，就要根据项目实施的现有条件和约束，对项目进度计划加以变更，以保证进度目标的实现。项目进度计划变更会对项目进度产生如下一些影响。

1.项目活动的增加和制除;

2.项目活动的重新排序;

3.项目活动持续时间估算的变更或者项目要求完工时间的更新;

4.项目活动时间属性的重新计算;

5.资源〔人力、物力、资金）的重新分配。

项目进度计划的变更通常要遵循一定的变更控制程序:首先要提出变更申请，然后由项目管理人员和相关项目干系人对变更进行评估，经过客户方及上级管理部门的确认和批准后，对项目进度计划进行修改。

软件项目成本管理综述--软件项目管理第5章总结回顾

一、软件项目规模、工作量、成本的概念

软件项目规模一般是指所开发软件的规模大小，通常可以简单地用软件的代码行数来表示，也可通过软件功能的多少来衡量。

软件项目工作量是指为了提供软件的功能而必须完成的软件工程任务量，其度量单位为人月、人天、人年等，即人在单位时间内完成的任务量。工作量与软件规模是紧密相关的，此外它还与项目和产品特性（如团队的技术和能力、所使用的语言和平台、团队的稳定性、项目中的自动化程度等）相关。在不会引起混淆的情况下，有时把工作量也称作规模。

软件项目成本是指完成软件项目所付出的代价，即待开发软件项目所需要的资金，通常用货币单位（如美元、人民币等）衡量。软件项目成本与工作量有密切联系，用单位工作量所消耗的成本乘以总工作量，就得到了完成项目工作量所消耗的成本。完成项目工作量所消耗的成本是项目成本最主要的部分。因此，项目工作量的估算和成本估算一般同时进行。

软件项目成本的构成

软件项目通常是资产和技术密集型项目，其成本构成与一般的建设项目有很大区别，成本的构成中较多的部分体现为系统设备、人工、维护等技术含量较高的部分，其中最主要的成本是指在项目开发过程中所花费的工作量及相应的代价，它不包括原材料及能源的消耗，主要是人的劳动消耗。一般来讲，软件项目的成本构成主要包括以下几种。

(1)设备、软硬件购置成本

开发人员需要使用计算机网络环境、系统软件等来实施创建和测试工作，硬件设备的购置费由设备的价格加上合理的运输费用组成。软件购置费包括操作系统、数据库系统和其他外购的应用软件购置费。这些费用虽然可以作为企业的固定资产，但因技术折旧太快，需要在项目开发中分摊一部分费用。

(2)人工成本（软件开发、系统集成费用)

人工费用，主要是指开发人员、操作人员、管理人员的工资福利费等。在软件项目中，人工费用总是占有相当大的份额，有的可以占到项目总成本的80%以上。通常，不同级别的项目管理者及不同技术级别的开发人员，其小时薪金水平是不同的，即人工费用标准是不同的。按照不同类别的小时工资标准和相应的人工工作小时数就可以估算项目的人工总成本。

(3)维护成本

维护成本是在项目交付使用之后，承诺给客户的后续服务所必需的开支。可以说，软件业属于服务行业，其项目的后期服务是项目必不可少的重要实施内容。因此，维护成本在项目生命周期成本中占有相当大的比例。软件项目后期维护对整个企业的形象非常关键，就像一般消费品的保修维修承诺一样，而且要比一般消费品的维修服务要求更高，因为它常常直接涉及客户方日常经营管理的各个环节，一旦出问题，影响面极大。所以很多软件企业为项目的后期维护投入了大量的资源保证。对于一个项目而言，全面合理地估算并有效控制维护成本对项目的整体收益和企业的经营绩效也相当重要。

(4)培训费

培训费是项目完毕后对使用方进行具体操作的培训所花的费用。因为软件项目的技术专业性极强，而客户通常是非计算机领域的外行，项目成果的应用需要专业的培训才能进行。所以几乎每一个软件项目都要向客户制作操作手册并进行现场培训。这部分费用必须考虑到项目的总费用中去。

(5)业务费、差旅费

软件项目常以招投标的方式进行，并且会经过多次的谈判协商才能最终达成协议，在进行业务洽谈过程中所发生的各项费用（比如业务宣传费、会议费、招待费、招投标费等）必须以合理的方式进行预算，计入项目的总成本费用中去。对于处在同一个城市的客户，当然会有比较少的差旅支出，但异地客户的服务就需要大量的差旅费用，这在IT项目中是相当常见的。

(6)管理及服务费

这部分费用是指项目应分摊的公司管理层、财务及办公等服务人员的费用。

(7)其他费用

除上述所列费用外，软件项目的成本中可能还会包含一些其他费用，包括:基本建设费用，如新建、扩建机房、购置计算机机台、机柜等的费用;材料费，如打印纸、磁盘等购置费;水、电、气费;资料、固定资产折旧费及咨询费等。

从财务角度看，可将项目成本构成按性质划分为两种。

(1)直接成本

直接成本是可直接归于项目组织或项目实施的有关成本，包括直接人工费、直接材料费、直接设备费及其他直接费用。例如，如果购进的一批设备全部用于某项目，则该设备成本归于直接成本。

(2)间接成本

间接成本不直接归于任何组织内的特定领域，往往是在组织执行项目时发生的，包括管理成本、保险费、融资成本（手续费、承诺费、利息）等。间接成本中还可包括员工薪金、原材料成本以及其他费用，这些支出是不能直接和项目或项目支出联系在一起的，所以这些费用被规划到间接成本。间接成本主要是由固定成本构成，但是有时也会包含一些可变成本。

二、软件规模度量

软件的规模是影响软件项目成本和工作量的主要因素。最常用的度量软件规模的方法是代码行(Lines of Code，LOC)和功能点(Function Point，FP)，分别利用代码行数和功能点数来表示软件系统的规模。

代码行（LOC)

代码行是从软件程序员的角度来定义软件规模。直观地说，一个软件的代码行数越多，它的规模也就越大。软件代码行的数目易于度量，多数软件开发组织和项目组都会对以往开发的软件项目代码行数目进行备案，当开发类似项目时，便可借助这些经验数据，在此基础上对当前软件的规模进行度量。一般是根据经验数据估计实现每个功能模块所需的源程序行数，然后把源程序行数累加起来，得到软件的整体规模。

用代码行的数目来表示软件项目的规模简单易行、自然、直观。但是其缺点也非常明显:在软件项目初期需求不稳定、设计不成熟、实现不确定的情况下很难较为精确地估算出最终软件系统的代码行数;软件项目代码行的数目通常依赖于程序设计语言的功能和表达能力，采用不同的开发语言，代码行数可能不一样。

功能点（FP)

由于代码行规模度量存在上述问题，人们提出用软件系统的功能数目来表示软件系统的规模。1979年 IBM公司的Alan Albrecht提出了计算功能点的方法。功能点以一个标准的单位来度量软件产品的功能，与实现产品所使用的语言和技术无关。该方法需要对软件系统的两个方面进行评估，即评估软件系统所需的内部基本功能和外部基本功能，然后根据技术复杂度因子对这两个方面的评估结果进行加权量化,产生软件系统功能点数目的具体计算值。以下是软件系统功能点的计算公式:

FP=UFC×(0.65+0.01xSUM(F))( i=1,…-,14 )

其中，UFC (Unadjusted Function Point Count)即未调整功能点计数值，是5个参数的“加权和”，FK=1,2,3,…,14)是14个技术因素的“权重调节值”，常数0.65和0.01是经验常数。

计算UFC所涉及的5个参数如下。

·用户输入数:是指由用户提供的、用来输入的应用数据项的数目。

·用户输出数:是指软件系统为用户提供的、向用户输出的应用数据项的数目。·用户查询数:是指要求回答的交互式输入的项。

·文件数:是指系统中主文件的数目。

·外部接口数:是指与其他系统的接口数据文件数。

每个参数都可按复杂度分为“简单”“一般”“复杂”3个级别，分别分配不同的权重，如表3.1所示。UFC的计算方法是将所有参数计数项加权求和。即 UFC=(简单用户输人数×3十一般用户输入数×4+复杂用户输人数×6)+(简单用户输出数×4+一般用户输出数×5+复杂用户输出数×7)+(简单用户查询数×3+一般用户查询数×4+复杂用户查询数×6)+(简单文件数×7+一般文件数×10+复杂文件数×15)+(简单外部界面数×5+一般外部界面数×7+复杂外部界面数x10 )。

F;的取值是根据它所对应的技术因素对软件的影响程度，取值范围是0~5的任意整数。举一个简单的例子，假设待开发一个软件项目X。根据用户的需求描述，该软件项目的UFC的计算结果--数据项表示各参数在各种复杂级别下的取值与权重值的乘积。UFC的计算结果为341。进一步假设该软件项目的14个权重调节值全部取平均程度,即取值为3,则14个权重调节值的累加值SUMF)=42，因而根据公式FP=UFC×(0.65+0.01×SUMF))( i=1,…,14)可知，该软件项目的功能点FP=341× (0.65+ 0.01×42)=364.87，即该软件的规模大致为364个功能点。

用功能点来表示软件项目规模的好处:

软件系统的功能与实现该软件系统的语言和技术无关，而且在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，因而该方法可以较好地克服基于代码行的软件项目规模表示方法的不足。功能点方法的缺点主要体现在:功能点计算主要靠经验公式，主观因素比较多;该方法没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统;此外计算功能点所需的数据不好采集。

大量实践表明:针对特定的程序设计语言，软件系统的功能点和代码行二者之间存在某种对应关系.

根据数据，一个功能点如果用汇编语言来实现大约需要320行代码，如果用C语言来实现大约需要150行代码，如果用smalltalk语言来实现大约需要21行代码。从另一个角度上看，该表反映了不同程序设计语言的描述能力是不一样的。

软件规模度量发生在项目实施之前，因而度量的结果与实际的结果有所偏差是不可避免的。但是，如果度量的偏差过大，那么度量的结果将会对软件项目的实施和管理产生消极的影响。因此，在对软件项目的规模、成本和工作量等进行度量的过程中，应尽可能获得合理和准确的度量数据。

三、成本估算方法

成本估算就是对完成项目所需资金进行近似估算。对于一个大型的软件项目，由于项目的复杂性及独特性,成本的估算不是一件容易的事。

成本估算的依据

成本估算的依据（输入）包括工作分解结构、资源需求、资源单价、进度计划和历史信息等内容。

根据工作分解结构(WBS)，可将整体成本分解到各工作包中，使成本的估算能够分项进行，各个工作包的成本估算能够做到尽量准确合理。

资源需求（Demand of Resource，DR）是进行成本估算的基础，用来说明所需资源的类型和数量以及分配情况。

资源单价(Price of Resource，PR)与该种资源的需求量相乘即可得到该资源的成本。如果某项资源的单价不清楚，则必须首先对资源单价进行估价。

进度计划中的活动持续时间会影响项目成本估计。

历史信息是保证项目成本估算顺利进行的重要参考，包括过去项目的规模、进度、成本数据等。通常历史信息的来源主要有项目文档、商业成本估算数据库、项目成员的经验知识3个方面。

有了上述的基础输人资料，项目的成本估算就可以进行了。但项目的成本估算不仅涉及大量的基础数据，还会涉及许多比较复杂的计算和评估过程。由于影响软件成本的因素很多，目前并不存在一种适用于所有软件类型和开发环境的估算方法或模型。

与项目活动持续时间估算一样，成本估算也可使用专家判断和类比估算方法，此外还有自底向上估算、参数估算等。

1.专家判断

专家判断就是以专家为获取信息的对象，组织专家运用专业方面的经验和理论，对项目的成本进行估计。此处专家是指具有专门知识和经验，或经过专业培训的团体或个人。

2.类比估算

类比估算就是通过把当前项目与以往一个或多个项目比较来进行成本估算。该方法运用类似项目的成本资料进行新项目的成本估算，并根据新项目与类似项目之间的差异对估算进行调整。

类比法依靠相似项目的实际经验来估计，需要对以往项目的特性了解得足够清楚，以便确定它们和新项目之间的匹配程度。在新项目与以往项目只有局部相似时,可行的方法是“分而治之”,即对新项目适当地进行分解，以得到更小的任务、工作包或单元作为类比估算的对象。通过这些项目单元与有项目的类似单元对比后进行类比估算，最后，将各单元的估算结果汇总得出总的估计值。

类比估算法成本较低，耗时较少。在项目详细信息不足时，例如在项目的初期阶段，经常使用类比估算法来估算成本数据。

3.自底向上估算

自底向上估算方法首先对单个工作包或活动的成本进行最具体、细致的估算，然后把这些细节性成本向上汇总到更高的层次。自底向上估算的准确性和其本身所需的成本，通常取决于单个活动或工作包的规模和复杂程度。

这种估算方法的优点在于，因为每项工作的执行者负责对该项工作进行成本估算，比起高层管理人员来讲，这些直接参与项目建设的人员更清楚项目涉及活动所需要的资源量，估算的专业性和准确性都较高。但缺点是通常花费时间长，工作代价高。

另外，自底向上估算方法在实施中可能会遇到人为的障碍。企业较高层的管理人员很容易认为自底向上的预算具有风险，他们对下级上报的预算并不十分信任，认为下级人员会强调自己负责部分的重要性而且夸大所需要的资源数量;另外，高层管理人员通常不会将资金分配的权力轻易转给下属，这种现象较为普遍，这就不可避免地以人为因素影响了费用的估算。在这种情况下，成本估算往往是由申请预算开始,从最高层起每一层管理人员均让下一层人员申报下一层的预算，而后逐层汇总。伴随成本估算过程往往存在从上而下的指示，下层是根据上层的指示确定自己的预算，这和真正的自底向上完全不同，结果也截然不同。当然，如果公司管理人员能够更为民主，则有助于在此过程中形成良性的协商过程。

4.参数估算

参数估算是利用历史数据之间的统计关系和其他变量(如软件的规模)来进行项目成本估算。参数估算的准确性取决于参数估算数学模型的成熟度和历史数据的可靠性。

常用的参数估算模型有Putnam模型、SLIM模型、COCOMO模型等，下面对COCOMO模型做一简单介绍。

构造型成本模型(Constructive Cost Model，COCOMO)方法是一种精确、易于使用、应用广泛的基于模型的成本估算方法。最早由勃姆(Boehm)基于对63个项目的研究，于1981年提出。

在COCOMO模型中，根据项目规模、开发环境等因素，可把项目分为以下3种。

·有机模式:指规模较小的、简单的软件项目;

·半有机模式;指在规模和复杂性上处于中等程度的软件项目;

·嵌入模式:指必须在一组紧密联系的硬件、软件及操作约束下开发的软件项目。cOCOMO模型按其详细程度也被分为3级。

(1)基本COCOMO，是一个静态单变量模型，它用一个以代码行数为自变量的函数来计算软件开发工作量。成本估算公式为:E=a( KDSI )'。其中:E为开发工作量，以人月为单位;DSI,定义为源代码行数，不包括注释行数;KDSI即为千代码行数，即1KDSI=1 024DSI。a、b为两个常数，具体值与项目的种类有关:

有机模式:E=2.4 (KDSr) 1.05半有机模式:E=3.0( KDSr ) 1.12嵌入模式:E=3.6 ( KDSr) 1.20

(2)中间COCOMO，在用以源代码行数为自变量的函数计算软件开发工作量的基础上，再使用一些与项目规模和类型无关的因素来调整成本的估算。成本估算公式:E=a(KDSTr)'×乘法因子。其中，a、b的具体取值为:

有机模式:a=3.2b=1.05半有机模式:a=3.0b=1.12嵌人模式:a=2.8b=1.20

COCOMO方法重点考虑15种影响成本估算的因素，并通过定义乘法因子，准确、合理地估算软件的工作量，这15种因素分为以下4类。

1.产品因素,包括软件可靠性、数据库规模、产品复杂性。

2.硬件因素，包括执行时间限制、存储限制、虚拟机易变性、环境周转时间。

3.人的因素，包括分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验。

4.项目因素，包括现代程序设计技术、软件工具的使用、开发进度限制。

根据每种因素影响大小，这些因素从低到高，在6个级别上取值，根据取值级别来确定乘法因子。

(3)详细COCOMO，包括中间COCOMO 的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑这些因素对软件工程过程中分析、设计、编码、测试等各阶段的影响。软件生命周期中的有些阶段的影响可能会相对其他阶段更大。详细COCOMO提出了“阶段敏感工作权数”对成本估算进行调整。

参数估算方法需要大量历史数据作为支撑，而且数学模型的建立要使用特定的分析技术(如回归分析)，因此具有较强的学术性，在许多实际软件项目中的可操作性并不好，所以很多项目管理者更倾向于选择更为简单实用的成本估算方法，比如“分解-累计”方法。

5.“分解-累计”估算方法

软件工程专家林锐提出了一种简单直观的软件项目成本估算方法，即分解-累计方法，下面对该方法作介绍。

首先估算产品规模，步骤如下。

(1)项目规划小组先分解产品的功能，制定“产品功能分解与规模估算表”。软件规模的度量单位可以使用代码行，也可以使用对象数、页面数等。

(2)规划小组成员独立填写产品功能分解与规模估算表。

(3)汇总每个成员的表格，进行对比分析。如果各人估计得差额小于20%，则取平均值;如果差额大于20%，则转向第(2)步，让各成员重新估计产品的规模，直到各个成员估计得差额小于20%为止。然后估算项目工作量，步骤与产品规模估算相同。先估算开发工作量，再估算管理工作量，填写工作量估算表。

一般可以把开发过程划分为需求开发、系统设计、实现、测试等阶段，分别估计每个阶段的工作量，然后汇总得到总的开发工作量。一般来说，软件项目80%以上的工作量用于开发，20%以下的工作量用于项目管理。

有了工作量估算值后，就可以比较容易地计算项目的人力成本了，计算公式为:

项目人力成本-项目工作量×平均人力资源单价×成本系数

平均人力资源单价可由人员的工资确定，例如人员平均年薪为8万元，则平均人力资源单价为8万元/人年，之所以要乘以成本系数，是因为人力资源的成本要高于工资，企业除了要为人员支付工资外，还要支付各种保险金、福利、资源消耗等。对软件企业来说，成本系数是1.5~2.0。

四、成本预算

成本预算是一项制定项目成本控制标准的项目管理工作。它是将批准的项目总成本估算按照进度分配到项目各项具体工作中，进而确定成本基准。成本基准是按时间段分配的预算，用于与实际成本支出结果进行比较，从而对成本实施情况进行监控。所以成本预算又称为之制定成本计划。

成本估算和成本预算既有区别又有联系。成本估算的目的是估计项目的总成本和误差范围，而成本预算是将项目的总成本分配到各项工作上.成本估算的输出结果是成本预算的基础与依据，而成本预算则是将批准的项目成本估算（有时因为资金的原因需砍掉一些工作来满足总预算的要求，或因为追求经济利益而缩减成本额)进行分摊。

成本预算的依据之一是项目进度计划。项目进度计划包括项目活动、里程碑和工作包的计划开始和完成时间，可根据这些信息，把计划成本分配到相应的日历时段中。

成本基准的表示方式有两种。第一种根据单位时间（例如每个月)内完成的工作量或投人的人力、物力和财力，计算单位时间的成本，然后以立方图的形式绘制出来。第二种是计算时间t的累计成本，然后绘制成时间-成本累计曲线。

五、成本控制方法

成本控制

成本控制是指监督项目状态，发现实际成本支出与成本基准计划之间的差异，以便采取纠正措施，降低风险，实现项目的成本目标。对于以项目为基本运作单位的企业或组织来说，成本控制能力直接关系企业的赢利水平,因此,多数企业或组织都将成本控制放在一个非常重要的地位。

成本控制的基本方法

在项目管理中，成本控制、进度控制和质量控制贯穿于项目实施的整个过程，其基本控制原理如下：

要实施控制，首先要制定一个合理的行动计划，在根据这个计划实施的同时，收集和分析实际数据，比较计划和实际之间的偏差，如果存在偏差，采取纠正措施，必要时调整原计划。这是一个循环的过程。

成本控制的工作过程。项目的工作范围、成本预算和进度计划是成本控制的依据。项目具体工作开始实施后，就要进行检查和跟踪，然后对检查跟踪的结果进行分析，预测其发展趋势，做出费用进展情况和发展趋势报告，再根据这个报告，作出进一步的决策，即采取措施纠正成本偏差。

“分析预测”是成本控制的核心，常采用挣值分析技术。

挣值分析

挣值分析（Earned Value Analysis)是一种项目绩效衡量技术，是最常用的成本控制方法，它综合了范围、时间和成本数据。给定成本基准计划，项目经理和他的团队可以通过输人实际的信息，然后将其与基准计划进行比较，就能够决定在多大程度上满足了范围、时间和成本目标。基准计划是最初计划加上已被批准的变更。实际信息包括项目工作是否完成或大约完成多少，工作什么时候实际开始或结束，完成的工作实际花费是多少。

挣值分析涉及计算项目的3个基本值。

·计划工作预算成本 BCWS ( Budgeted Cost of work Scheduled ):也称为预算成本，它是指根据批准认可的进度计划和预算，到某一时刻应当完成的工作所需投人资金的累计值。

·已完成工作实际成本ACWP ( Actual Cost of Work Performed ):也称为实际成本，它是指到某一时刻已经完成的工作所消耗的实际成本。

·已完成工作预算成本 BCWP ( Budgeted Cost of Work Performed ):也称为挣值，它是指到某一时刻已经完成的工作的预算成本。

为了对项目的实际进展情况作出测定和衡量，实现对项目的监控，可对3个基本值进行如下的分析。

对计划工作预算成本（BCWS）和已完成工作预算成本（ BCWP)进行比较。2对已完成工作预算成本（BCWP)和已完成工作实际成本（ACWP)进行比较。③根据①、②的比较结果识别成本、进度变动情况，并分析引起较大变动的原因。分析的过程中可导出下列重要的指标。

(1)成本偏差（Cost Variance，CV):CV=BCWP-ACwP

如果成本偏差是负数，则意味着执行工作所用成本多于预算成本，说明工作执行效果不好;如果成本偏差是正数，则意味着执行工作成本少于预算成本，节省了资金;如果成本偏差为0，则说明项目工作按照预算执行。

(2)进度偏差（Schedule Variance，sV):SV=BCwP-BCwS

进度偏差显示了工作计划完成情况与实际完成情况的差异。正的进度偏差说明实际进度比计划提前，负的进度偏差说明实际进度比计划落后，进度偏差为0说明实际进度与计划一致。

(3)成本效能指数（Cost Performance Index，CPI):CPI=BCWPIACWP

如果成本效能指数等于1，则说明成本支出按预算进行;如果成本效能指数小于1，则说明成本支出超出预算;如果成本效能指数大于1，则说明成本支出在预算范围内，并且有节支。

(4)进度效能指数(Schedule Performed Index，SPI ):SPI=BCWPIBCWS

如果进度效能指数等于1，表示工作按照计划进度进行;如果进度效能指数小于1，表示落后于计划进度;如果进度效能指数大于1，表示超前于计划进度。

用挣值分析法得到的评价曲线。横坐标表示时间，纵坐标表示费用的累计。成本偏差CV<0，进度偏差SV<0，表示项目运行的效果不好，成本超支、进度拖延，应采取一定的补救措施。

在项目的实际执行过程中，最理想的状态是 BCWP、BCWS、ACWP 3条曲线紧密相靠，平稳上升，这表示项目的实际情况和期望的走势差不多，向着良好的方向发展。若3条曲线偏离很大，则表示项目实施过程有重大问题隐患，或已经发生了严重问题，应对项目重新评估和安排。

挣值分析是评估项目进展、进行管理决策的一项重要技术，也是项目经理和高级管理人员评估项目执行绩效的有力工具。

软件项目质量管理综述--软件项目管理第6章总结回顾

一、软件质量的概念

要实施软件项目质量管理，首先要明确什么是软件质量，在此基础上确定合理的质量管理目标。

什么是软件质量

软件质量就是软件与用户需求相一致的程度。具体地说，软件质量是软件符合明确叙述的功能和性能需求、以及所有专业开发的软件都应具有的隐含特征的程度。因此衡量软件质量好坏的标准不是技术的优劣，而是是否满足用户需求。

软件质量是软件的一个综合特征,不能靠单一的指标来衡量,它是许多质量属性的综合体现。软件的质量属性有很多，常见的有正确性、健壮性、可靠性、性能、易用性、安全性、可扩展性、兼容性、可移植性等。以下是这些质量属性的简要描述。

质量属性

正确性（Correctness ):软件按照需求正确执行任务的能力。这是软件第一重要的质量属性。健壮性(Robustness ):软件在异常情况下能够正常运行的能力。健壮性有两层含义:一是容错能力，二是恢复能力。

可靠性(Reliability):在一定环境下，在一定的时间段内，程序不出现故障的概率。可靠性也可用平均无故障时间来衡量。

性能(Performance ):软件的时间-空间效率，用来衡量软件的运行速度和占用资源的多少。易用性（ Usability ):用户使用软件的容易程度。

安全性 ( Security ):防止系统被非法人侵的能力。

可扩展性(Extendibility ):软件为适应变化而可被扩充和改变的能力。兼容性( Compatibility ):与其他软件系统相互交换信息的能力。

可移植性(Portability ):软件不经修改或稍加修改就可以运行于不同软硬件环境之上的能力。

质量要素

什么是软件质量要素

（1）技术角度：对软件整体质量影响最大的那些质量属性才是质量要素；

（2）商业角度，客户最关心的、能成为卖点的质量属性才是质量要素。

只有质量要素才值得开发人员下功夫去改善。

正确性是指软件按照需求正确执行任务的能力。 “正确性”的语义涵盖了“精确性”。是第一重要的软件质量属性。机器不会主动欺骗人，软件运行出错通常都是人造成的。

全面软件质量管理

软件项目质量管理的目标

软件项目质量管理的目标无疑是保证软件产品的质量。但是,对于一个具体的软件项目来说，保证软件产品的质量并不意味着追求“完美的质量”。在本书的第一章中就曾强调，要以系统的观点分析软件项目管理问题。产品质量与项目进度、成本等因素是密切相关的，提高产品质量往往意味着延长进度和增加成本。项目管理者必须站在系统整体的高度权衡各方面的因素，找到最佳平衡点，从而达到针对项目目标的全局最优，而非片面追求局部最优。

对航空航天、医疗设备控制等领域的关键性软件，需要不惜代价地追求“零缺陷”，因为这些软件的缺陷有可能造成巨大损失，甚至危及人的生命。但对于绝大多数普通软件来说，则没有必要付出巨大代价追求“零缺陷”,如果由于追求完美质量而造成严重的成本超支和进度拖延，而获得的质量提升为用户所带来的效益又极为有限，就得不偿失了。

在软件项目中，对于软件的各种质量属性并不是放在同等重要的位置上，项目组织应该把关注点放在那些用户最关心的，对软件整体质量影响最大的质量属性上，这些质量属性称为“质量要素”。只有明确了质量要素，才能给出提高质量的具体措施，而不是试图把所有的质量属性都做好;否则不仅做不好，还可能造成损失。

因此，软件项目质量管理的目标是在项目整体目标的约束之下，使软件质量满足用户需求。

怎样保证软件的质量

软件工程专家林锐提出了一个全面的解决方案，称为“全面软件质量管理”。

在全面软件质量管理中，通过制定质量管理计划来规划软件项目中的各种质量管理活动，通过技术评审和软件测试发现软件缺陷，通过过程检查保证软件过程和产品符合既定的规范，通过缺陷跟踪保证发现的缺陷和问题被正确记录、跟踪和处理。软件过程改进的目的是提高软件组织的技术水平和规范化水平,从而为保证软件质量提供基础,它是面向整个组织的,而不仅仅针对某个项目。

因此，在全面软件质量管理中，软件组织的所有人员(包括开发人员、测试人员、管理人员、质量保证人员等）都对质量负有责任,都参与到了质量管理活动中。

缺陷跟踪

所谓缺陷跟踪是指从缺陷被发现开始到被改正为止的整个跟踪流程。缺陷跟踪的目的是确保所发现的缺陷被正确地处理。

一个状态转换图，每个圆角矩形表示缺陷的一个状态，箭头线表示引起缺陷状态变

化的事件。一个缺陷被报告后，其状态被设置为“打开(Open)";它被分配给一个开发人员进行修复，此时缺陷状态设置为“已分配（Assigned )";然后开发人员开始修复缺陷，修复完毕后，将缺陷状态设置为“已解决(Resolved )";此时测试人员可以开始回归测试，如果回归测试通过，确认缺陷已被修复，则将缺陷处理状态设置为“已验证( Verified )";否则退回给开发人员重新进行修复。一个缺陷结束了其生命周期后，可将其关闭，其处理状态变为“已关闭(Closed )"。已被关闭的缺陷如果在某些情况下被发现仍有问题，可以将其重新打开，使其处理状态变为“重新打开( Reopened )”，以便再分配给开发人员进行修复。

不同的软件组织的缺陷跟踪流程可能会有所差别，但都与上述典型流程相类似。

缺陷跟踪通常需要工具的支持，靠手工执行不仅非常烦琐、效率很低，而且难以共享信息。缺陷跟踪工具有多种可以使用。

缺陷预防

无论是测试还是各种技术审查,都只是一种被动的缺陷检测方法,无法防止缺陷最初的引入，也无法保证能够检测到所有缺陷。此外检测和排除缺陷的过程会消耗大量成本（特别是在软件项目后期，如系统测试和维护阶段)。因此，为了最大程度地减少缺陷并实现软件项目的效益，还需采取主动的预防措施，分析缺陷产生的根本原因，有针对性地消除这些原因，防止将缺陷引入到软件中，即通常所说的“缺陷预防”(Defect Prevention)。

缺陷预防的核心任务是原因分析，也就是找到导致软件缺陷产生的根本原因和共性原因。在这里首先要明确软件缺陷的含义。一个软件缺陷是指软件对其期望属性的偏离，它包含三个层面的信息，即失效(Failure)、错误(Fault)和差错（Error)。失效是指软件系统在运行时其行为偏离了用户的需求，即缺陷的外部表现;错误是指存在于软件内部的问题，如设计错误、编码错误等，即缺陷的内部原因;差错是指人在理解和解决问题的思维和行为过程中所出现的问题，即缺陷的产生根源。一个差错可导致多个错误，一个错误又可导致多个失效。软件缺陷原因的分析不能只停留在“错误”这一层面上，而要深入到“差错”层面，才能防止一个缺陷（以及类似缺陷)的重复发生，因此软件缺陷的根本原因往往与过程及人员问题相关，缺陷预防总是伴随着软件过程的改进。

软件缺陷原因分析过程一般包括选择缺陷数据、分析缺陷数据、识别公共原因并提出改进措施3个步骤。采用该方法的软件组织通常是在软件项目的每个开发阶段结束后，或者定期(如每个月末）进行缺陷原因分析，提出改进措施，从而促进组织的过程改进。软件缺陷原因分析通常是以会议的形式进行，会议人员应包括开发团队中的重要成员，如项目管理人员、过程管理人员、技术人员（特别是那些报告和修复缺陷的人员）等，这样才能更好地理解和分析软件缺陷，并产生最佳的解决方案。

对于中小规模的软件项目，缺陷数据的选择较为简单，可选择某一时期或某一项目阶段所发现和处理的所有缺陷作为待分析的数据集，但对于大型项目来说，由于缺陷数量庞大，而缺陷原因分析又是一个费时的任务，只能选择一个具有统计显著性的缺陷样本集合，选择时需考虑的因素包括缺陷的严重程度、复杂性、相对于软件模块和开发团队的分布等。在进行缺陷分析之前，还要对所选择的缺陷数据集进行检查和预处理,即修补不完整和不一致的数据,清理错误数据(如误报的缺陷）和重复数据。

对所选择的缺陷数据，要逐个进行分析，确定缺陷的触发条件、在哪一个开发阶段被引入以及为什么会引入等。随着软件组织经验的增长和数据的积累，可对分析结果进行分类，从而有利于更为快速和准确地进行分析。例如 Motorola公司将软件缺陷引入的根本原因分为开发阶段相关(Phase-related)、人员相关( Human-related).项目相关( Project-related )和复审相关(Review-related )四类。又把人员相关问题分为通信障碍、缺少相关知识、协作失误和人为疏忽等类。在这些分类的基础上，可很方便地使用一些工具来确定缺陷产生的根本原因，例如因果图可作为辅助工具来分析一个缺陷的根本原因。因果图又称鱼骨图，图中每一个分支都代表一类缺陷原因，分支越细，原因就越具体，对于一个具体的缺陷，沿着图中的分支逐步进行分析，就可以确定缺陷的根本原因。

在逐个分析了缺陷之后，还要对缺陷数据的总体趋势进行分析，识别出公共问题及其产生原因，并制定有关过程、技术和人员管理方面的改进措施。例如，如果经统计发现由人员通信问题所引起的软件缺陷占有较大的比例，就要调整开发团队的结构，改善人员交流的方式;如果由需求问题引起的软件缺陷较多，就要改进需求管理过程和技术。

常用的质量度量

成熟的软件组织会采用软件质量度量来定量地评价和控制软件质量。正如本章开头所述，软件质量是一个综合属性，不能用单一的度量指标来衡量，软件组织通常是根据具体需要和度量目的选择度量指标。下面介绍几个常用的软件质量度量指标。

(1）缺陷密度

缺陷密度指单位规模的软件所包含的缺陷的数量。缺陷密度用下式计算:

缺陷密度=已知缺陷的数量/软件规模

上式中的软件规模可以用代码行数或功能点数等方式度量。缺陷密度还可以进一步细化为更具体的度量指标，例如:

·每千行代码中的高级设计缺陷;

·每千行代码中的编码缺陷;

·每千行代码中的用户发现的缺陷。

(2）平均失效时间（Mean Time to Failure，MTTF)

MTTF指软件在失效前（两次失效之间)正常工作的平均统计时间，它常用来度量软件的可靠性。MTTF度量常用于安全性要求较高的系统，例如航班监控系统、航空电子系统以及武器系统等。

(3）平均修复时间（Mean Time to Reparation，MTTR)

MTTR指软件失效后，使其恢复正常工作所需要的平均统计时间。MTTR用来度量软件的可维护性。

(4）初期故障率

指软件在初期故障期（一般以软件交付给用户后的3个月内为初期故障期）内单位时间的故障数。初期故障率用来评价交付使用的软件的质量，预测什么时候软件运行达到基本稳定。一般以每100小时的故障数为单位。

指软件在偶然故障期（一般以软件交付给用户后的4个月以后为偶然故障期）内单位时间的故障数。偶然故障率用来度量软件处于稳定状态下的质量，一般以每 1000小时的故障数为单位。

软件配置管理综述--软件项目管理第7章总结回顾

一、软件配置管理的概念和作用:

软件配置管理的概念:

我国的国家标准《GB/T 11457 ( 2006）软件工程术语》对软件配置管理的定义是:软件配置管理是标志和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和起动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性。

在IEEE 610.12—1990标准中，软件配置管理的描述则比较详细，包括以下内容。

标志:识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。

控制:通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，确定哪些修改会在软件的最新版本中实现。

状态统计:记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，修改这个错误将影响多少个文件。

审计和复审:确认产品的完整性并维护构件间的一致性,并确保产品是一个严格定义的构件集合。例如，确定目前发布的软件产品所用的文件的版本是否正确?

生产:对产品的生产进行优化管理,它将解决最新发布的产品应由哪些版本的文件和工具.来生成的问题。

从以上定义可以看出，软件配置管理贯穿整个软件生命周期，对软件产品进行标志、控制和管理，它系统地控制对配置项的修改，以维护配置项的完整性、一致性和可追踪性。软件配置管理应包括版本控制、系统集成、变更管理、配置状态统计和配置审计等功能，其中版本控制是软件配置管理的主要思想和核心内容。

软件配置管理的作用：

在软件项目中，可能会遇到以下问题。

找不到某个文件的历史版本;

开发人员使用错误的程序版本;

开发人员未经授权修改代码或文档;

人员流动，交接工作不彻底，造成一些开发成果的丢失;

无法重新编译软件的某个历史版本;

因协同开发,或者异地开发，版本变更混乱导致整个项目失败。

造成以上问题的根本原因是软件项目面临着持续不断的变化，源代码、文档、数据、可执行文件、配置文件等配置项都处在不断的变更过程中。而软件配置管理正是用于控制变化的，它通过一套管理方法、规则和相关工具来控制软件系统的演变，明确记录了各种配置项在什么时候做了哪些修改，从而确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。

软件配置管理对程序员、项目管理者(项目经理）和企业高层领导来说都是必要的。对于程序员来说，配置管理系统可以安全地保护他每一天的工作成果，同时使他能够及时准确地得到所需的配置项及相关信息;对于项目管理者来说,通过配置管理能够方便地了解到项目的进展情况，协调各项目成员之间的开发，提高整个开发团队的协同工作能力;对于企业高层领导来说，则可以通过软件配置管理了解整个组织的当前状态，有助于对整个组织实施全局控制，以保证产品能及时交付给客户，并且能够对客户提出的问题报告作出及时的响应。

软件配置管理系统相当于软件企业的产品“仓库”和“调度中心”，可对工作成果进行有效保护，保存待开发软件系统的状态供开发者随时提取，简化开发过程的管理工作，有助于提高软件产品质量,保持软件开发和维护工作的有序化。因此软件配置管理是软件项目管理中其他领域的基础。

二、版本控制

前面提到过，软件配置管理的主要思想和核心内容就是版本控制。版本控制是对配置项的不同版本进行标志和跟踪的过程。一个版本是配置项的一个实例，在内容和功能上与其他版本有所不同，或是修正、补充了前一版本的某些不足。版本控制系统把什么时候、什么人更改了配置项的什么内容忠实地记录下来，每一次配置项的改变，其版本号都会增加，从而保证可以在任何时刻取得任何一个配置项的任何一个版本，实现了版本的可追踪性。

版本控制包括了对配置项版本的一系列操作控制，例如检入检出控制、记录版本历史信息、更新工作空间、取得历史版本、分支的创建与合并等。

版本控制的具体操作有很多种，除了前面讲过的检入和检出操作外，还有记录版本信息、更新工作空间、取得历史版本、标志软件整体版本、保存安装包等。通过适用的版本控制工具，这些操作都可以很方便地执行。

开发人员在完成了一个配置项的修改并检入时，版本控制工具会自动记录下检入的时间和执行检人的人员，除此之外，开发人员通常还需要输入一些附加信息，例如本次修改的目的、修改的内容及产生的影响等，这些信息都会被记录在配置库里，可以用配置管理工具很方便地查看。

开发人员在自己的本地机的工作空间中工作时，配置库中可能已有了很大的变化，其他开发人员已向配置库提交了很多代码。这样，开发人员自己的工作空间中的代码就有过时的风险，使得自己开发的代码不能与其他人最新的代码共同工作。因此，开发人员要适时更新（Update )自己的工作空间，使其与配置库保持同步。一般在开始一个新任务的时候，如开发一个新功能模块,修改一处代码等，要执行一次更新操作，以建立关于这个任务的初始工作环境。在任务完成后，即将检人的时候，也要做一次更新，并简单测试一下，以保证自己新写的代码，可以与别人的代码一起工作。在完成任务期间，如果任务持续时间较长，也应进行若干次更新。当然，更新操作也不需要过分频繁，以免影响开发效率。

在软件开发和维护的过程中，经常需要取得配置项的某个历史版本。由于配置库中详细记录了配置项的每次修改，因此使用版本控制工具可以迅速得到配置项的任一历史版本。

在软件项目周期的不同时期会产生不同的软件产品版本，且在同一时期也会有不同用途的版本，因此需要记录软件的整体版本，明确软件产品的每个整体版本都包含哪些特定版本的源程序文件。有两种方法可以完成这一任务:第一种方法是在软件开发过程中，当某一产品版本形成时，复制其所有源代码，保存在一个合适的地方。一些版本控制工具提供的复制(Copy )命令即可完成这一操作。另一种方法是在软件的整体版本所包含的所有相关文件的特定版本上打个标签( Lable/Tag )，标签的名字就是整体版本的名字，将来在需要该版本的软件时，只需搜索所有打上这个标签的文件，就可以找到这个整体版本对应的所有源文件的正确版本。

软件的安装包包含了所有对用户有用的配置项，包括可执行程序、数据和用户文档。在发布软件之前,或在对软件进行系统测试或验收测试之前,都需要生成安装包。安装包同样需要保存，并标上相应的版本号，原因有两个:首先，如果保存了各版本的安装包，将来在需要某一安装包时，可以迅速而准确地得到它，而不必重新执行编译、链接和打包过程（对于大型项目来说，这一过程可能会持续数小时)，从而能节省时间。其次，用户或系统测试人员发现的软件 Bug，有可能是由安装包的生成过程造成的，例如，两次使用的编译参数不同，导致上次生成的安装包和这次生成的安装包不一样。为了找出问题，保存上次生成的安装包就很重要，把两次(或多次）生成的安装包进行对比，容易定位问题所在。

三、系统集成

系统集成(System Integration )，简称集成，就是把软件产品的各个组成部分组合在一起，使产品作为一个整体是可以运行的。系统集成首先要保证各模块能够在一起编译链接通过，然后进行一个粗略测试，也称冒烟测试(Smoking Test )，证明系统基本可运行，可以送交进行详细的测试。系统集成是保证软件产品完整性和软件模块间一致性的手段，也是软件配置管理的一个重要内容。

开发人员要适时更新自己的工作空间，使自己开发的模块能够与产品整体协调工作，这实际上也是一种系统集成工作，但这种系统集成关注的是开发人员本人所负责的模块能否与其他人员开发的模块协调运行。严格意义上的系统集成是由“集成工程师”所执行的全局性的集成，这种集成通过一系列严格规范的步骤，确保产品整体是集成的，并且具有一定的质量（产品是否完全符合质量标准是由随后的测试过程检验的)。

系统集成过程一般包括以下几个步骤。

第1步，确保开发人员都提交了本次将要集成的源代码。

第2步，冻结或者标识将要集成的源代码。每次集成必须明确要集成哪些内容，即集成了哪些文件，以及文件的哪些版本。为此需要冻结源代码，在集成前禁止开发人员向配置库提交，或者用打标签的方式把当前的软件整体版本标志出来。

第3步，取出要集成的源代码。最好将代码存放在一个全新的文件夹中，不包含一些杂项，如编译的中间文件和结果文件,尚未提交的本地修改等。

第4步，编译、链接和打安装包。这一过程通常称为构建。如果在构建过程中遇到了问题，需要修改源代码,回到第1步。

第5步，安装并粗略测试。如果发现问题，修改了源代码后，回到第1步。

第6步，标志和储存集成成果。集成成果有两个:一个是源代码的整体版本(基线)，另一个是生成的安装包。通常还要生成一个“发布说明”，说明本次集成了哪些功能和修改。

第7步，通知相关人员本次集成完成。例如通知项目经理和测试人员。

四、分支管理

分支可以形象地看作是配置项演化图中的一条独立路径。例如，配置项演化图中就包含3条分支:在中间的一条分支上，配置项版本从1.0、1.l，一直演化到2.1;从这条分支的1.1版本处产生了一条新的分支（标记为B)，在这条分支上配置项的初始版本为B1.0;从第一条分支的1.2版本处也产生了一条新分支(标记为A)，在该分支上配置项的初始版本为A1.0。

虽然任何配置项版本的演化都可形成分支，但软件配置管理中所说的“分支”通常是指软件整体版本演化过程中产生的分支。

分支的创建是一种复制操作，也就是在分支的起点处，将原分支上的内容进行复制，形成新的分支，并对新分支进行标记，这一过程可通过版本控制工具来完成。每个分支在创建后都是独立生长的，一个分支上内容的修改,不会对其他分支产生任何影响。

虽然一个软件的版本演化会产生多个分支，但这些分支并不是完全处于同等地位的。在众多的分支中，有一个被称为“主线”或“主干”，例如用粗线标出的那条中间的分支就是主线。其他的分支大多是从主线上产生的，并有可能再合并回主线上。软件开发团队应该集中精力于主线的开发，只在必要的时候迁移到分支上工作。

分支的作用

在软件开发过程中之所以要使用分支，主要是由于以下两个原因。

开发者需要创建软件的不同用途的版本。一个软件在不同时期或针对不同的用户群，会产生不同用途的版本。例如 Windows Vista有7个版本:家庭类的初学者版、家庭基础版、家庭标准版和家庭终极版，商务类的小企业版、专业版和企业版，分别针对不同的用户群。在这种情况下，需要为不同的版本创建分支，使各版本能够并行开发，互不干扰。

在软件开发过程中，有时需要创建一个相对独立的开发环境。例如，软件在主线上演化到版本A时，需要由一组人员来协作完成一个大的任务（例如实现一组密切相关的功能)。这个大的任务与软件的其他开发任务关联不大，但在该任务内部，不同人员的工作是密切相关的，他们之间必须频繁地进行交互。如果让这一组人员在主线上完成这一任务，他们就需要频繁地往主线上提交工作内容和从主线上更新工作空间，因此他们的工作必然与软件团队中其他人员之间的工作互相干扰，影响开发效率。此时，应该在A版本处创建一个分支M,让这一组人员在M分支上完成他们的任务，使他们的开发工作与其他人员在主线上的开发工作互不干扰，当他们的任务完成后，再把他们的工作成果合并到主线上。在软件项目中，这样的情况是经常发生的，有时还要为测试过程和系统集成过程提供独立的开发环境。由于分支是独立演化的，因此它为独立开发环境的创建提供了支持。

分支的合并是指把一条分支上的内容合并到另一条分支上。有两种情况:第一种是将一条分支上的所有工作成果都合并过去，例如B分支在演化到B1.1版时完全合并到了主线上的2.0版，该分支停止生长。第二种情况是只将分支上的一部分工作成果合并过去。例如，在一条分支上进行的一些缺陷修复工作如果对其他分支也是有意义的，则只将这些缺陷修复合并到其他分支。分支的合并同样也是—种复制行为，也就是说执行合并后，被合并的分支上的内容不会受任何影响。

使用分支的注意事项

分支的使用要有所规划，适当管理,通常需要注意以下几点。

(1)分支不能随意创建，要规划好何时创建，从何处创建。每个分支都应该有一个明确的目的，要用分支的名字来简要说明该目的。

(2）分支要规划好是否合并，合并到哪里。分支上所有的工作成果都要合并，还是有选择地合并。

〔3)分支要规划相关角色和权限:谁有权读取分支上的内容或向分支提交，分支的合并及分支上的集成工作由谁负责，谁负责创建、删除和重新命名分支。

( 4)不管版本树的分支有多少，都应该有一条主线，作为开发工作的主流，集中精力于主线的演进，其他分支以主线为基础进行开发。例如，在为一个软件

开发多个不同用途的版本（变体)时，不能不分主次地为每一个版本创建一个分支，各自独立开发。因为一个软件的不同变体有许多公共的特性，如果各个变体之间没有共享，各自独立演化，必然会产生大量重复劳动。正确的分支策略，A、B、…、G都是软件的变体，开发团队在主线上开发一个“标准版”，包含各变体公共的特性，从主线上的特定版本处创建分支，来开发变体，在分支上主要进行变体特殊功能的开发。这样就避免了重复劳动,而且使版本演化策略更为清晰，易于管理。

五、变更管理

变更管理的作用

引起变更的因素有很多，例如需求的变化、功能的扩充、运行环境的变化、改正错误、新技术的采用等。对于这些变更，如果不能很好地控制和管理，必然会造成软件开发和维护的混乱，其结果是使软件质量恶化、项目进度拖延、项目成本增加。因此变更管理是软件项目的一项非常重要的工作。

并非对配置项的所有修改都要进行变更管理。一个配置项在被完成并提交测试或发布之前，要频繁地进行修改，这些修改通常不被视为“变更”，也不需要进行变更管理。软件配置管理中所谓的“变更”是指配置项开发完成后在正式测试或使用时所提出的修改，特别是那些影响较大的修改。

变更管理的具体方法与变更的特性（规模、发生时间等）和项目特性（过程模型、团队规模等）密切相关。但一般来说，对于那些影响面比较小的变更，如缺陷修复、功能的少量增强等，可以采用缺陷跟踪（参见第6.5.2节)的方式进行管理;对于规模较大、影响面也较大的变更，例如需求基线和设计基线的修改，就要执行更为严格的变更控制过程，从而将变更可能造成的负面影响降到最小。

严格的变更控制过程

为了更好地执行严格的变更控制，一个常见的做法是设立“配置控制委员会”，包含开发人员、测试人员、配置管理人员、质量保证人员和用户等各方面的代表，负责对变更进行评估和决策。

严格的变更控制过程如下。相关人员提出变更请求后，CCB组织人员对变更进行充分的评估，根据评估的结果决定批准或拒绝变更，对于批准的变更，要分配一定的人员去实施，实施完毕并验证无误后，及时通知受该变更影响的人员。

对于提交上来的变更请求, CCB要进行评估,评估内容主要包括:变更的必要性和替代方案，该变更对项目的进度、成本、软件结构等方面的影响，实施该变更的代价和风险等。在评估过程中要征求各方面人员的意见。

CCB要根据评估结果对变更做出决策:如果拒绝变更应通知变更申请人;如果批准了变更，要指定相应的负责人去实现变更，安排他们的任务。

实现变更的过程首先要设计一个实现变更的方案，这对于那些规模比较大的变更是尤其必要的，可能会包括需求分析和设计过程。然后从配置库中检出需要修改的配置项，具体实现变更。实现的变更必须经过测试人员和质量保证人员的测试和验证，被证明正确无误后，在配置管理人员的指导下将配置项检入到配置库中，形成新的版本。

在实现变更的整个过程中，变更执行人员、配置管理人员、QA人员都应该对变更负责，并在变更请求表上留有记录，因此该表能反映变更控制的全面情况。变更执行人员还应该在具体实现变更的模块代码或文档上，留下反映变更情况的信息。

对于实现的变更，要及时通过E-mail、项目网站信息发布等形式通知受变更影响的人员，使他们作出响应的调整。

需要注意的是，上述变更控制过程只应在确实需要的时候才使用，如果对变更不作区分地应用这种严格的控制过程，很容易形成繁文缛节，挫伤开发者的工作积极性，妨碍他们创造性的发挥。

六、配置审计和配置状态报告

配置状态报告和统计

“配置状态报告”用来记录和报告配置项变更处理过程的相关信息，这些信息包括一个已批准的配置清单，变更请求当前的处理状态以及已批准的变更的实现情况。

正如前面所介绍的，变更在其处理过程中会经历不同的状态:首先变更请求被提交，然后进人评估和审批状态。对已经被批准的变更，仍要搞清楚它处在什么状态，例如工程师是否已经开始实现变更?是否已完成?是否经过了测试和验证?是否已经提交?这些信息是被许多人所关心的，例如变更提出者、项目经理、受变更影响的开发人员、测试验证人员等，因此需要被记录和报告，以利于管理。

由于许多配置项都处在不断的变更过程中，相关人员必须及时准确地了解发生了哪些变更，以及这些变更的当前处理状态，从而保证人员之间协调一致地工作。配置状态报告通过改善相关人员之间的通信来达到以上目的。

有关变更的信息和数据，有时需要经过统计分析而得到综合数据，例如每月或每周产生的变更请求数、处理的缺陷数，当前处在某一状态的变更数等。统计分析结果可以用分布图、趋势图等形式直观地显示出来。这些综合数据对软件项目管理有着重要意义。

其实除了有关变更的信息外，软件配置管理所记录的许多其他信息也是很有价值的，例如配置库信息、产品和发布信息、文件版本信息、检入检出信息等，对这些信息进行适当的统计和分析，可对项目管理和过程改进提供有力的支持。

配置审计

配置审计的目的是验证配置项符合特定的标准或要求。通常在软件开发每个阶段结束后，或产品发行之前，都要进行配置审计，它是正式技术复审的一种补充。

正式技术复审关注配置项的正确性、完整性和一致性（例如需求、设计、代码配置项之间的一致性)，而配置审计关注的是配置项的特性是否满足标准和计划的要求，例如,配置库中是否已纳入了所有已标志的配置项，配置项的名称和版本标志是否符合规范，其在配置库中的存储位置是否符合规定,分支的创建是否符合版本演化策略,是否在配置项中显著标明了每次所作的修改，

是否注明了修改时间和修改者，软件发行版本所应实现的所有变更请求是否都有源代码的实际修改相对应等。因此配置市计也是保证软件质量的一个重要环节。

不要把配置审计误解为“对配置库中的每个配置项都检查―遍”，那样做代价太大了。配置审计的对象是项目的主要配置项，如果主要配置项符合规范，就可以认为配置管理符合既定的规范。反之，如果质量人员在审计的时候发现主要配置项比较混乱，那么应当告知当事人及时更正。

七、配置管理过程

配置软件管理实施的流程

1.规划、调整网络开发环境

一个规划良好的开发环境，是实施配置管理系统的前提。此阶段要对配置管理系统做出规划，主要考虑以下问题：

网络的带宽、拓扑结构

服务器的选择、命名规范

存储区的定位

开发人员及组的命名规约等。

2.设计配置管理库

　　根据项目开发的要求，设计开发资源的存储模式，良好的存储模式有利于减轻管理上的负担，增强配置管理库的访问性能，同时便于控制访问权限，保护软件资产。

3.定义配置管理系统的角色

需要确定与配置管理相关的所有角色，包括他们的相应的活动。在开发过程中，一个开发人员可能兼任多种角色，但一项任务在同一时刻只能由一个角色来执行。

一般配置管理中的角色主要包括：

项目经理

配置管理员

软件开发人员

集成人员

QA人员

4.制定配置管理流程

配置管理实施的一个重要阶段，主要目的是根据项目开发的需要，制定相应的配置管理流程，以更好地支持开发，主要活动包括：

定制并行开发策略。合理的并行开发策略应该具有以下特点：协调项目的复杂性和需求，统一创建分支类型和元数据，为开发过程中的变更集成制定有效的规范，适时反映开发过程中方法和需求的变化：

发布版本管理。软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以至始至终管理、跟踪部件版本间的关联。

5.相关人员的培训

实施配置管理系统，相关人员需要接受培训：

管理员培训：针对配置管理员，主要学习配置管理工具管理相关内容：

开发人员培训：针对开发人员，主要学习配置管理工具与开发相关的常用操作

管理流程培训：针对全体人员，目的是了解配置管理策略和流程，以及如何与开发管理、项目管理相结合。

八、配置管理工具
根据IDC1的1999年SCM工具市场调查,排名第一的正是Rational ClearCase,第二位则是CA公司的CCC/Harvest,第三位就是MERANT公司的PVCS系列,微软排名第六.Visual Source Safe不能算是一个完整的软件配置管理工具,只是版本控制做的很好,当然对于国内目前大多数的软件工程实践而言已经足够.而pvcs和 clearcase是比较完整意义上的SCM软件,称为full-fledged SCM Tools.

此外配置管理工具比较流行的还有: CCC/HARVEST, Continuus, Change Man,

Source Integrity, TRUEchange, TeamConnect等. 对于PVCS的配置管理工具叫 PVCS Process Manager. 当然上面列的是一些可运行于WINDOWS/NT平台的工具, 在UNIX下还有一些.

VSS只是一个版本管理的工具, 如果用于做配置管理的话, 有些勉为其难。

比如说, 我们无法在VSS中输出有关的配置报告, 不易做到对变更的审查及控制. 当然如果你另外再制定一套完善的配置管理制定, 并将相应的文档用VSS统统管理起来也是可以的.做为版本管理工具而言, VSS还是很不错的, 我们一直都用它, 它也有象分支, 版本合并, Multi-checkout等功能.

PVCS有两个版本, 一个也是与VSS相同的, 用于进行版本管理另一个是"Process Management"的版本,是一个配置管理的工具.

Rational ClearCase也是配置管理工具, 拥有配置管理中的各类基本功能,但输出报告的能力不是很强.

软件项目团队管理综述--软件项目管理第8章总结回顾

软件项目团队管理的概念和主要内容：

什么是软件项目团队

软件项目团队是由软件项目的不同干系人所组成的，具有共同目标、紧密协作的集体。软件项目团队包括所有项目干系人:项目发起人、资助者、项目组（开发团队)、供应商、客户等。有时，软件项目团队也特指项目组（开发团队)。

与一般的人力资源相比，软件项目团队具有以下特点。

·临时性。团队因项目而组织在一起，项目结束后，团队通常也会解散。·团队成员的不稳定性。在软件项目的不同阶段，人员会加人和退出。年轻化程度较高。

·是高度集中的知识型团队。

·成员的业绩不易量化考核。由于软件开发的复杂性和软件产品的不可见性,简单的计件和计时等量化考核方式通常不能满足团队成员绩效考核的要求。

项目组织的规划:确定项目中的角色、职责和组织结构。

(2)团队人员获取:获得项目所需的人力资源（个人或集体)。

(3)团队建设:提高团队成员个人为项目做出贡献的能力;提高团队作为集体发挥作用的能力。

(4)团队日常工作管理:跟踪团队成员工作绩效，解决问题和冲突，协调变更事宜。

(5)沟通管理:对在项目干系人之间传递项目信息的内容、方法和过程进行综合管理。保证项目干系人及时得到所需的项目信息。

(6)项目干系人管理:识别项目干系人，分析他们对项目的期望和影响力，采取措施有效调动他们参与项目的决策和执行。

团队协作的重要性

团队管理的根本任务是促进团队协作，良好的团队协作对项目成功是至关重要的，因为它能够发挥出集体的力量。

开源软件运动的领导者之一Eric Steven Raymond 曾在他的著作《大教堂与市集》中解释了Linux 作为一个开源项目为什么会有如此之高的开发效率和软件质量。他把原因总结为“Linus法则”:只要眼球足够多，所有臭虫都好捉。意思是Linux 的开发充分利用了全世界开发者的集体智慧，使得系统中的缺陷能够被迅速发现和修复，而Linux项目的负责人Linus通过在 Internet上频繁地发布Linux版本来不断地向开发者反馈其开发成果，使遍布全世界的开发者总是能够看到系统的最新状态。Raymond还使用了一个“蚂蚁觅食”的类比来说明他的观点:蚂蚁依靠群体觅食，众多蚂蚁各自分散地寻找食物，使找到食物的概率大了很多，找到后用一种非常高效的、可扩展的通信机制互相通信。对于Linux项目来说，寻找Bug就相当于蚂蚁觅食，遍布全世界的志愿开发者就相当于众多的蚂蚁，而Internet就相当于蚂蚁之间的通信机制。

实际上，这种蚂蚁觅食式的开发方式所带来的好处绝不仅仅局限在发现和排除 Bug 上。在软件的高层设计中，在产品和项目的许多决策中，发挥集体智慧都是极为重要的，一个人往往按照其习惯的和擅长的思维方式和解决问题的方式，在一条路径上探索。而许多人在一个问题空间里进行多路径的探索，其效能远远超过单个人。所以 Raymond甚至认为，Linus最重要的贡献不是创建了Linux 内核本身，而是开创了Linux的开发模式。

小到一个项目，大到一个企业，要想取得成功，都必须通过团队协作发挥集体的力量，而不能仅靠少数精英人物的贡献。

通过项目组织的规划，可确定项目团队的角色，明确汇报关系（组织结构)，分配人员职责，制定人员配置管理计划。

项目团队角色

项目团队是由不同角色的人员组成的,不同角色之间要形成―种相互配合、相互制约的关系，共同促进项目目标的实现。所谓“相互制约”是指当一种角色的工作偏离了项目目标的时候，另一种角色会发现并促使其采取措施加以纠正。例如，当开发人员所开发的软件出现质量问题时，测试和质量保证人员会及时发现，并配合开发人员解决质量问题。

软件项目团队中常见的角色包括:项目经理、系统分析人员、架构师、开发人员、测试人员、质量保证人员、项目管理和支持人员、市场人员、用户支持人员等。不同规模、不同类型的软件项目所包含的角色是有区别的。例如，微软的一个软件产品项目团队通常由一个“产品单元经理”"( Product Unit Manager ）领导，包含各种角色。

什么是软件项目团队管理

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

软件项目团队管理主要包括以下内容。

在产品团队中，开发人员负责开发软件;测试人员通过执行测试来发现软件质量问题;项目管理人员负责团队内部的沟通协调，保证项目在进度、成本等方面的约束下顺利进行;用户培训人员负责培训客户;产品管理人员负责获取和定义用户需求、市场分析和研究、产品推销和公共关系;后勤管理人员对项目所需的设备、材料、软件工具等资源进行管理，保证项目能够平稳地进展。注意，这些角色的地位是平等的，从而形成一个检查和平衡机制，使任何一种角色的工作失误都能很快被发现和纠正。

在小型项目中，可以简化团队的组成，压缩团队的规模，也就是说，可以把一些角色组合在一起，由相同的一组人员来担当。例如，各种角色中，项目管理和后勤管理角色可以组合在一起,软件测试、产品管理和用户培训人员可以组合在一起。

项目经理是整个项目团队的核心角色，对项目的成败起着关键作用。项目经理的责任主要包括以下几点。

(1)制定开发计划。

(2)组织项目实施。组建项目团队，为项目团队成员分配任务，有效调动每个人的能力去完成项目任务。

(3)项目控制。监控项目的运行，积极预防问题的发生，纠正偏差。

项目经理为了履行其责任，必须有一定的权力，包括项目事务的决策权，项目资源的分配权和适当的财务权。一些企业的领导在项目经理的授权上有太多的限制，特别是在财务权上。项目经理用钱时需要上级领导层层审批，不能自己做主。没有财务权的项目经理不是完整意义上的项目经理。企业不给项目经理财务权的初衷是为了控制成本，防止不适当的财务支出，但实际上效果适得其反，由于项目经理没有财务权，他们就不会关心成本也无法控制成本。

项目经理的能力和素质要求主要包括以下几点。

(l)管理能力。管理能力体现在对项目团队的组织、沟通、协调，充分发挥每个成员的能力和集体智慧;完成项目团队与外部组织的沟通和协调;很好的口才和写作能力。

(2)一定的技术能力。软件项目是知识和技术密集型的活动，项目计划、人员的使用、技术评审等均需要项目经理有一定的技术能力。

(3)一定的商业头脑。项目经理需要理解产品需求、市场策略、盈利模式、企业战略等，这需要有一定的商业头脑。

(4)其他素质。例如责任心、热情、抗压能力等。

项目组织结构的确定：项目组织角色构成、项目组织类型及其特征、不同小组结构的特征

项目组织角色构成

项目的组织结构是项目团队所有成员为了进行分工协作，而在职务范围、权力和责任方面所形成的结构体系。所以组织结构的本质是团队成员的分工协作关系，组织结构的内涵是人们在职、责、权方面的结构体系，确定了团队成员及部门之间的汇报关系，因此组织结构又称为权责结构。

没有什么好的或坏的组织结构，只有适合或不适合的组织结构。要根据具体的企业情况和项目情况来设计项目的组织结构。

项目组织类型及其特征

常见的项目组织结构有3种类型:职能型、项目型和矩阵型。

1．职能型组织结构

这种组织结构是在组织当前的职能型等级结构下加以管理，项目组成员从各职能部门中抽调。职能部门是按照专业职能和业务来划分，例如研发部门、销售部门、财务部门等。项目可以由一个或多个职能部门承担，项目成员分别受他所在的职能部门的经理管辖。项目整体的协调工作主要在各部门经理之间进行。虽然也可能有项目经理，但其权力非常有限，通常只负责各部门间的沟通、协调和监督作用，对项目成员没有完全的领导权。

职能型项目组织结构主要有以下优点:以职能部门作为承担项目任务的主体，可以充分发挥职能部门的专业优势和资源集中优势,有利于保障项目需要资源的供给和项目可交付成果的质量。职能部门内部的技术专家可以同时被该部门承担的不同项目所使用，节约人力，减少了资源的浪费。同一职能部门内部的专业人员便于相互交流、相互支援，对创造性地解决技术问题很有帮助。此外，项目成员可以将完成项目和完成本部门的职能工作融为一体，可以减少因项目的临时性给项目成员带来的不确定性。

职能型项目组织结构的缺点主要包括:不能完全做到以项目目标作为驱动力和导向，职能部

门往往集中精力于对本部门]有益的工作上，而项目和客户的利益可能得不到优先考虑。项目决策过程要经过多个管理层，过程繁琐，因此对客户和市场的需求反应迟钝而且容易失真。当项目需要由多个部门共同完成时，权力分割不利于各职能部广]之间的沟通交流、资源调配、团结协作。

项目成员在行政上仍隶属于各职能部门的领导，项目经理对项目成员没有完全的领导权。

2.项目型组织结构

项目型组织结构就是指完全根据项目需要创建独立项目部门，项目部门]的经营与其他单位分离，企业分配给项目部门-定的资源，然后授予项目经理管理项目的最大自由。项目型组织结构是一种面向项目目标的垂直组织方式，存在一个项目就有一个项目部门，如图8.3所示。

在这种组织结构中，项目经理具有高度独立性、对项目享有完全的领导权。

项目型组织结构的优点在于:项目经理对项目可以全权负责，可以根据项目需要灵活调动项目组织的内部资源或者外部资源。项目型组织的目标单- -，完全以项目为中心安排工作，能够对客户的要求作出及时响应，有利于项目的顺利完成。组织结构简单，项目成员直接属于同一个部门，彼此之间的沟通交流简洁、快速，提高了沟通效率，同时也加快了决策速度。

项目型组织结构的缺点在于:当一个公司有多个项目时，每个项目有自己一套独立的班子,这将导致类似项目的重复努力和规模经济的丧失。项目团队自身是- -个独立的实体，容易与其他组织之间出现- -条明显的分界线，从而削弱组织之间的有效融合。没有强大的职能群体，技术支持困难，也阻碍了企业能力的持续提高。在项目完成以后,项目型组织的使命即完成，项目成员有可能闲置甚至被解雇，对项目成员来说，缺乏一种事业上的连续性和安全感。

矩阵型组织结构同时具有职能型组织结构和项目型组织结构的特征，试图把两者的优点结合起来。在该组织结构中，根据项目的需要，从不同的职能部门中选择合适的人员组成一个临时项目组织，由项目经理领导，他对项目的成功负有全部责任。职能部门有责任向项目提供最好的技术支持。

矩阵型组织结构的性质有强弱之分，这取决于项目经理对所拥有的职能资源的影响力。当项目经理比职能经理对职能资源的使用有更大影响力时，矩阵结构才是强有力的。此时项目经理有能力提供技术指导、委派职责，对项目成员的工作成效有很大影响。如果职能经理比项目经理更有影响力，那么矩阵结构就是弱的。

矩阵型组织结构的优点是:专职的项目经理负责整个项目，以项目为中心，能迅速解决问题。企业的多个项目可以共享各个职能部门的技术骨干和其他资源，节约成本。项目的组织结构既有利于项目目标的实现，也有利于公司宏观目标方针的贯彻。此外，项目成员在事业稳定性上的顾虑减少了。

矩阵型组织结构的缺点是:容易引起职能经理和项目经理权力的冲突，资源共享也可能引起项目之间的冲突。项目成员（处在矩阵行和列的交织处)有多头领导。他们的任用、升迁、解雇的权力仍由职能部门经理把持,而职能部门经理对他们的绩效考核又必须通过项目经理才能完成。当职能部门经理和项目经理的命令相冲突时，可能会出现无所适从的情况。

在使用矩阵型组织结构时，要注意以下几点。

(1)横向的项目组织与纵向的职能部门各自负责的工作和管理内容要明确，否则容易造成责任不清、双重指挥的混乱局面。因此矩阵型组织良好运作的关键是这两类部门的协调。

(2)由于项目经理和职能经理都有各自的权力和责任，他们必须站在项目大局的高度进行良好的沟通和协调。避免出现以下情况:项目经理只考虑什么对自己的项目有利(（而不关心其他任何方面)，职能经理则认为自己的部门比任何项目都重要。

(3)由于项目成员往往来自不同的职能部门，其工作目标和工作方法可能有所差异，在项目初期的磨合阶段可能会产生矛盾。要求项目经理及时识别矛盾，并控制和疏导由此产生的对抗。

(4)由于项目成员从属于某个职能部门，项目经理必须解决好以下问题:如何才能激励成员为项目工作，并保证对项目忠诚。当项目指令和规则与部门政策相冲突，尤其是当成员感到自己的职能部门上司可能会对自己不满时，如何说服他按项目的要求做?

从以上介绍可以看出，没有一种组织结构类型是万能的，要根据项目的实际要求和项目所处的企业环境进行选择。

项目组织结构的设计

选择了项目组织结构的类型，只是在宏观上确定了项目组织结构的性质。在此基础上，还要设计项目组织的各组成部分及其报告关系、责任关系。设计结果通常用项目组织结构图表示。

对于大型项目，可以分层次进行设计，即先考虑整体的组织结构，再逐层细化。

软件开发小组结构

在大型软件项目中，通常根据软件的功能模块将从事开发的人员划分为若干小组（Team ),每个小组负责一个功能模块的开发。小组的组织结构对小组的工作效率和工作质量有很大影响。

软件开发小组的人员要“少而精”。人数太多的小组会产生较大的沟通开销和沟通问题,影响工作效率和软件质量。

软件开发小组的结构形式可分为3类。

(1)民主分散型(Democratic Decentralized，DD )。小组没有固定的领导，而是根据不同的任务来指定临时的任务协调员。决策由小组通过协商来共同制定，小组成员之间的通信是水平的。

(2)控制集中型( Controlled Centralized，CC)。顶层的问题解决和小组内部协调由小组领导负责。小组领导和小组成员之间的交流是垂直的。

(3)控制分散型（Controlled Decentralized，CD)。这种结构形式综合了前两种结构形式的特点。小组有一个固定的领导，来协调不同的任务。问题的解决是集体行为，但解决方案的实现由小组领导划分给不同的成员或成员组。个人和成员组内部的交流是水平的，同时也存在沿着控制层次的垂直交流方式。

以上几种软件开发小组的结构形式各有其特点和适用范围。集中式的小组结构有权威指导和统一管理，能以较快的速度完成任务，适用于处理简单问题。分散式的小组结构能够激发人员的创造力和集体智慧，产生更多、更好的解决方案，因此更适合于解决困难的问题。

民主分散型(DD)的小组容易产生更高的士气和工作满意度，因此适用于那种生存期较长的小组。民主分散型的结构内部通信路径较多，通信开销也较大，但适用于解决那种可模块化程度较低的问题,因为解决这样的问题需要大量的通信和交互。如果需解决的问题可以被高度模块化,控制集中型(CC）和控制分散型(CD)小组结构则比较适合。此外，有经验表明，CC和CD型小组产生的软件缺陷比 DD型小组少。

因此，选择软件开发小组结构时，主要应考虑以下因素。

团队人员获取方法

获取团队人员的方法获取团队人员一般采取以下几种方法。

(1)预分派

在某些情况下，一些成员已预先分派到项目中工作，例如在竞标过程中承诺分配特定人员到项目中，或项目的成功依赖于特定人员的专有技能。

(2)谈判

大多数人员的获取需要经过谈判。项目经理需要与职能部门经理或其他部门负责人谈判，以获得所需要的人员。在谈判时，项目的影响力会起作用，例如，一位职能经理在决定把一个各项目都抢着要的优秀人才分配给哪一个项目时，会考虑本部门能得到哪些益处和项目的知名度。

(3)招募

当企业缺少完成项目所需的内部人才时，就需要从外部获得所需服务，包括招聘和分包。在获取和任用项目团队人员时，除考虑人员的专业技能外，最好能结合人员的性格特征和兴趣，做到“知人善任”。

在获取团对人员后，应确定人力资源可利用情况。人力资源可利用情况记录了项目团队成员在项目上可工作的时间，明确了项目团队成员在时间安排上的冲突，包括休假时间和承诺给其他项目的时间。这些信息是制定可靠的项目进度计划所必需的。

实际的项目人员分配很少能够完全符合最初的人员配置管理计划，因此在获取团对人员后，往往需要对人员配置管理计划进行必要的变更。

虚拟团队

虚拟团队为项目团队人员的招募提供了新的可能性。虚拟团队是指拥有共同目标，但工作地点分散，在工作过程中很少或完全不面对面交流的一组人员。

现代电子通信设施的完善（电子邮件、即时通信、视频会议等）使虚拟团队成为可能。虚拟团队有以下优点。

(1)可以组建在同一组织工作，但工作地点十分分散的团队。

(2)雇用方式更为灵活，可以为项目团队增加特殊技能和专业知识，即使项目人员不在同一地理区域。

(3)可以纳入在家办公的员工。不仅节省了工作空间和设备的费用，而且可能提高工作效率。

(4)可以安排不同时区的人员的任务分工来减少任务的持续时间。例如，一个虚拟团队包括了在中国的软件开发人员和在美国的测试人员，那么中国的软件开发人员在今天下班的时候提交新的集成版本给美国的测试人员，第二天早上上班的时候就可以得到测试结果。

(5)可以把行动不便的人纳入项目团队。

但虚拟团对也有以下约束。

(1)由于虚拟团对成员之间的交流受到限制，因此分配给虚拟团队员工的任务需求要十分明确。

(2)要做好协调工作。协调分散的员工也许很难，特别是跨国和跨时区的情况。

(3)计算工作量和付费也许需要按件或按量计算，而不是按工时计算，因为对于分散的团队，计算工时很困难。

(4)远程或者素不相识的协作者之间也许缺乏信任感。

项目团队的建设：培训、绩效管理、激励、冲突管理

团队建设和日常管理

项目团队建设是指提高团队成员的技能，以加强他们完成项目活动的能力;提高团队成员的信任感和凝聚力，以促进团队协作。项目团队日常管理是指通过观察团队的行为、管理冲突、解决问题，以及评估团队成员的绩效,来促进项目的进展。

团队建设和日常管理涉及到人际关系和人的情感、动机等因素,因此不仅需要制度上的保障，

还需要项目管理者的“情商”，进行“人性化管理”。

团队建设和日常管理工作主要包括培训、人员激励、绩效考核、冲突管理等。8.4.1 培训

培训的目的是提高项目团队成员的能力。培训可以是正式或非正式的，培训方式包括课堂培训、在线培训、计算机辅助培训、在岗培训（由其他项目团队成员提供)、辅导及训练。

如果项目团队成员缺乏必要的管理或技术技能，可以把对这种技能的培养作为项目工作的一部分。应该按人员配置管理计划中的安排来实施预定的培训,也应该根据管理项目团队过程中的观察、交谈和绩效评估的结果来开展必要的计划外培训。培训可以由组织内部或外部培训师来执行。

人员激励

激励就是通过一定的引导行为来激发团队成员的工作动机和工作热情。常见的激励方式有薪酬激励、机会激励和情感激励等。由于每个人的需要可能都有特殊性，所以激励措施要因人而异。

根据马斯洛的需要层次理论，人有不同层次的需要。在软件企业中，知识型员工普遍追求高层次的需要，因此企业管理者不能只停留在满足员工低层次的需要上。例如，知识型员工的自尊心强，需要被人尊重，因此不要在公开场合批评和贬低员工的工作。软件开发人员是追求自我实现的群体，企业管理者可以帮助他们制定职业生涯规划，尽力提供培训、工作锻炼的机会来帮助员工实现其职业发展需要。

绩效评估

绩效评估就是工作行为的测量过程，即用过去制定的标准来比较工作绩效的记录及将绩效评估结果反馈给职工的过程。绩效评估的根本目的是发现问题，完善工作，并使员工更好地发展，而不是为了惩罚绩效不好的员工。

按照目的划分，绩效评估的类型有:奖金分配评估、提薪评估、业绩评估、人事评估、职务评估和晋升评估等。

绩效评估一般程序如下。

(1)建立业绩考核体系。

(2)将业绩期望告知员工。

(3)测量实际业绩。

(4)比较实际业绩和考核标准。

(5)进行矫正。

冲突管理

项目的高压环境、责任模糊、技术上的不同观点等都可能引起团队成员之间的冲突。如果适当管理，冲突的解决会带来益处，有助于提高创造力和做出好的决定，相反则会带来负面影响。

要管理冲突，应回答下面几个问题:

·为什么会产生冲突?

·该怎样处理冲突?

·能否预测和防范冲突?

冲突的诱发因素有很多，常见的有项目管理方式方法、技术见解、人力资源分配、成本估计和进度规划等。各种原因的冲突在项目的不同阶段，其表现强度是不同的。例如，技术冲突和管理方式方法冲突在项目后期的表现强度较弱，而在项目的中期则相对较强。

冲突的处理方式主要有以下几种。

(1)问题解决( Problem Solving ):也称为“正视”(Confrontation )。双方一起积极地定义问题，收集问题信息，开发并且分析解决方案，直到最后选择一个最合适的方法来解决问题。这是冲突管理中最有效、最可取的一种方法。

(2)妥协(Compromising ):双方协商并且都做出一定程度的让步，寻找一种能使双方都可接受的方法。

(3)求同存异( Smoothing ):双方都关注他们同意的观点，而避免冲突的观点。

(4)撤退（ Withdrawal ):把眼前的问题搁置起来，等以后再解决。

(5)强迫（Forcing ):采用一方的观点，否定另一方的观点。属于“赢-输”式的处理方式，除非有特殊情况，一般不推荐这种方法。

采用哪种处理方式视冲突的具体情况（为什么冲突?与谁冲突?)而定。

在项目初期就应该对冲突管理进行计划,分析在项目的各阶段会出现哪些冲突,该怎样避免，怎样处理。但不适合在整个企业层次上建立冲突管理的政策和程序，因为每个项目产生冲突的情况和解决冲突的方法都有特殊性。

沟通管理的主要内容

沟通管理

沟通是人与人之间的思想和信息的交换。沟通从一定意义上讲，就是管理的本质。据统计，项目经理80%以上的时间用于沟通管理。沟通失败是项目失败的重要原因。

沟通管理就是确定项目干系人的信息需要，并保证以合适的方式，把信息及时传递给他们。

沟通需求分析

通过沟通需求分析可以明确各种项目干系人的信息需求。例如开发人员需要用户需求信息和技术信息，高层管理者需要项目总体进度、成本、质量信息，用户则需要进度信息和发布信息。信息需求包括信息的类型和格式以及该信息的价值。不要向项目干系人传递对他没有价值的信息。

为降低通信开销，应限制通信渠道。因此沟通需求分析需要依据项目组织结构图和项目团队成员的职责关系。

沟通方式

沟通方式可按不同的标准进行分类。例如，按传播媒介的方式可划分为书面沟通、口头沟通和电子媒介﹔按组织系统可分为正式沟通和非正式沟通;按信息传播方向可分为上行沟通、下行沟通、平行沟通和越级沟通。采用什么沟通方式取决于信息的内容、对信息需求的紧迫性以及项目环境等。

(1)正式沟通是通过项目组织明文规定的渠道进行信息传递和交流的方式。正式沟通的一种主要形式是“项目评审”。项目评审以会议的方式进行，用来检查项目当前的执行情况，并确定采取的管理措施。项目评审可分为3种:定期评审、阶段评审和事件评审。

①定期评审是根据项目计划和跟踪采集的数据定期（例如每周)召开评审会议，对项目的执行状态进行评审，检查项目规模的变化、各项责任落实情况、项目进度是否得以保证、资源调配是否合理等，对于出现的偏差制订纠正措施。不同的项目人员可以在定期评审会议上正式地交流沟通。

②阶段评审也称里程碑评审，是指在项目计划中规定的时间点（或里程碑处)，对该阶段的任务完成情况和产品进行评审，目的是检查当前计划的执行情况，检查产品是否合格，对项目风险进行分析处理，并对下一阶段的项目计划进行必要的调整。

③事件评审是指对项目进行过程中相关人员提交的事件报告(主要指对项目进度、成本、质量有影响的事件)进行评审，分析事件性质和影响范围，讨论事件处理方案，并判断是否影响项目计划，必要时采取纠正措施。

以上各种项目评审结束后，要产生一个评审报告，包括评审结果和所发现的问题，评审报告要及时发布，这样可以使项目相关人员了解项目的当前状态、进展以及下一步的工作计划。项目周报是一种很常用的定期评审报告，本书附录A.7给出了软件项目周报的模板。

(2)非正式沟通指在正式沟通渠道之外进行的信息传递和交流，它具有随意性和灵活性，人员可多可少,时间可长可短，沟通的媒介也多种多样，并没有一个固定的模式或方法。例如聊天、非正式的面谈或聚会等都是非正式沟通。

软件项目团队中存在着大量非正式沟通。非正式沟通补充了正式沟通的不足（正式沟通缺乏灵活性，且可能给项目人员带来压力)，满足了项目人员的需要。因此作为管理者，应该为项目成员间的非正式沟通提供条件。

项目沟通管理计划

项目沟通管理计划确定项目相关人员的信息和沟通需求:谁需要什么信息、什么时候需要、怎样获得、选择的沟通方式等。沟通管理计划是整个项目计划的一个附属部分，应在项目的前期阶段完成。在项目进行过程中，要根据沟通需求随时对其进行检查和修订，以保证它的持续有效性和适用性。

项目沟通管理计划一般包括以下内容。

(1)项目干系人的沟通需求:他们需要什么信息，什么时候需要，这些信息对他们有什么价值。

(2)沟通方式。描述传达信息所需的技术和方法。

(3)人员联系方式。

(4)工作汇报方式:明确表达项目组成员对项目经理或项目经理对上级和相关人员的工作汇报关系和汇报方式，明确汇报时间和汇报形式。

(1)项目干系人的沟通需求:他们需要什么信息，什么时候需要，这些信息对他们有什么价值。

(2)沟通方式。描述传达信息所需的技术和方法。

(3)人员联系方式。

(4)工作汇报方式:明确表达项目组成员对项目经理或项目经理对上级和相关人员的工作汇报关系和汇报方式，明确汇报时间和汇报形式。

(5)沟通时间安排。确定一些正式沟通的时间和频率。

(6）沟通计划维护人:明确本计划在发生变化时，由谁进行修订，并对相关人员发送。

软件专业人员的非技术素养的培养
软件专业人员在其职业生涯中，不但要发展其技术能力，还要培养一些非技术素养（或称为人文素质)。只有具备了必要的非技术素养，才能在团队中有良好表现，进而促进个人和团队的发展。非技术素养包括很多方面，这里仅谈一下对个人发展和团队协作都非常重要的团队意识、主人翁精神、写和说的能力以及管理能力。

团队意识

团队意识就是团队成员为了团队的整体利益和目标而相互合作、共同努力的意愿和作风。团队意识具体表现在以下几点。

·对团队的强烈归属感和一体感;

·团队成员间的相互协作从而形成有机的整体;·对团队事务的尽心尽力和全方位投人;

·使团队目标优先于个人目标;

·愿意分享信息，理解别人的行为并产生适当的反馈;·当其他成员需要时给予帮助;

对别人的反馈作出积极的反应。而违反团队意识的两种常见做法是:

·不愿把自己的技术知识与别人分享，怕别人威胁自己的职位;

不喜欢与别人交流，不愿求助于别人，有问题后孤军奋战。

当工作在一个团队中时,要善于利用集体的智慧解决难题,如果你试图自己去做每一件事情，结果必然是既慢又不是最好的。例如微软公司的软件团队就善于发挥集体智慧，当一个员工遇到一个自己无法解决的难题时，他会将问题描述清楚，然后通过E-mail或会议的形式告诉大家，请大家一起来解决。通常很快就会有人告诉他解决办法。

主人翁精神

主人翁精神是指对团体及其产品有一种“拥有”意识，因此主动关心团体的利益并愿意为之付出努力。主人翁精神还表现在发挥主观能动性、敢于负责、勤于思考、勇于做出判断并表达自己的意见。这样一种态度和那种被动消极的工作态度迥然不同，产生的效果也大相径庭。

当你加入一个产品开发团队以后，无论团队是只有一两个人，还是成百上千人，你都是产品的一个负责人(Owner )，都要有这样一种精神和意识:“这是我的作品，我将制作它，我希望它能成功!”

员工的主人翁精神的培养并不只是员工个人的事。企业领导也应采取适当的措施来促进员工形成主人翁精神。例如，适当放权，使员工能够在工作中做出决定，能够对自己的工作负责。再如，一些企业给员工配发股权，使员工成为企业股权的拥有者,收入与企业的经营效益息息相关，这样可增强员工对企业的拥有意识。

写和说的能力

写和说是人们向外界表达自己能力和才华的最重要途径，可是表达能力低下却是许多研发人员的通病。要提高写和说的能力，首先要破除“表达能力不重要，而技术才能才是最重要的”错误观念。软件专业人员在团队中要不断与别人沟通，如果表达能力差，就无法与别人良好协作，也无法胜任需求开发、系统设计、管理等高层次的工作。

培养写和说的能力没有什么捷径，只有通过多练。要珍惜每一次写文档、会议发言、作报告的机会，保证质量完成任务，通过多练逐步提高。在写文档时要注意内容充实、逻辑清晰、证据充分、措辞准确。在当众发言（会议、演讲、报告、讲课等)之前要做充分准备，发言时要仪表整洁，声音响亮，用语恰当。

管理能力

管理能力是指带领团队完成目标的能力。软件专业人员的职业生涯发展到一定阶段后，不仅要关注怎样把自己的工作做好，还要关注怎样引导和影响别人把工.作做好。

在软件行业，很多管理者都是先搞技术，有了技术经验和能力后再逐步转向管理，这是一种稳扎稳打的职业发展模式。因为软件行业的大部分职位都有很强的技术性，不懂技术往往很难胜任管理工作。

但需要注意的是，要做好管理工作，不仅要用脑，而且要用心，不仅要有智商（IQ)，而且要有情商（EQ)。因为管理的对象是人，人都有心理和感情。软件专业人员都擅长程序式的逻辑思维，但切忌试图用程序式的逻辑思维来解决所有关于人员管理的问题。

怎样培养管理能力?答案是学习加实践。首先要学习本行业基础的管理知识，主要包括软件

项目管理知识和软件过程改进方面的知识（如CMM)。其次要不断实践，从底层管理者做起,积累经验,提高能力。

软件项目风险管理综述--软件项目管理第9章总结回顾

风险和风险管理的概念：

风险及其属性

比较经典的风险(Risk)定义是由美国人韦氏(Webster)给出的:“风险是遭受损失的一种可能性”。这个定义包含两层含义:第一，风险会造成损失。对一个项目来说，损失可能有各种不同的后果形式，如产品质量的降低，费用的增加或进度的推迟等。第二，风险的发生是一种不确定性随机现象，可用概率表示其发生的可能程度。

完整地描述风险的属性对于风险管理来说是非常必要的，一般来说，风险具有以下属性。风险事件;

·风险发生的原因;

·风险发生的概率;

·风险的影响（风险一旦发生，将对项目产生什么影响);

·风险发生的频率;

·与其他风险相比较的重要程度;

·风险防范策略和应对策略;

·风险责任人。

项目中的风险源于项目中存在的不确定性。从广义的角度说，不确定性既可以给项目带来消极影响，也可以带来积极影响。因此在经典的项目管理理论中（例如PM-BOK )，把那种可以给项目带来积极影响的不确定性事件也称为风险，也是风险管理的对象。但从务实的角度来看，在项目中大量存在的是产生消极影响的风险，风险管理主要关注的也是这一类风险。

软件项目风险管理

随着项目管理理论和实践的发展，人们更多地意识到项目中风险的存在及有意识地进行风险管理的必要性。20世纪80年代后期，风险管理正式被列为项目管理的一个专门领域，其标志是134美国项目管理学会(PMI）确认风险管理是其核心项目管理知识体系的组成部分之一。

风险管理是指项目管理组织对项目可能遇到的风险进行规划、识别、估计、评价、应对、监控的动态过程，是以科学的管理方法实现最大安全保障的实践活动的总称。风险管理的目标是控制和处理项目风险，减轻或消除风险的不利影响，以最低的成本取得对项目保障的满意结果，从而保障项目的顺利进行。

风险管理要求项目管理组织采取主动行动，而不应仅在风险事件发生之后才被动地应付。风险管理应贯穿于项目始终，在项目早期要识别出风险并确定有效的应对措施，在随后的项目执行过程中，还要持续地关注和反复评估风险。

风险管理可分为以下5个主要活动。

风险规划:对风险管理进行系统规划和顶层设计，制定项目风险管理计划。
风险识别:识别出项目中的风险，并对其进行描述和分类。
风险评估:采用定性或定量的方法对风险发生的概率和产生的影响进行分析和评估。
风险应对:确定应对风险的方案和措施。
风险监控:在整个项目生命周期中跟踪已识别的风险，监测残余风险，识别新风险，实施风险应对方案并对其有效性进行评估。

风险规划是在项目启动之前或启动初期执行的活动，在进行风险规划的过程中，要对项目的主要风险进行识别、评估和制定应对方案。在随后的项目执行期间，不仅要监控已识别出的风险，还要不断地去识别和评估新的风险。

风险分类：

不同的风险有不同的表现，因此人们在项目管理活动中，通常按照一定的标准对风险进行分类，以便于对其进行管理，常用的风险分类方法包括以下几种。

按风险的后果划分:纯粹风险、投机风险;

按风险的来源划分:技术风险、行为风险、经济风险、组织风险;

按风险是否可管理划分:可管理风险、不可管理风险;

按风险影响范围划分:局部风险、总体风险;

按风险的可预测性划分:已知风险、可预测风险、不可预测风险;

按风险后果的承担者划分:项目业主风险、承包方风险、投资方风险、设计单位风险、监理单位风险、担保方风险、政府风险等。

对于软件项目来说，也可根据需要采用上述某种方法对风险进行分类。此外，人们在大量的软件项目实践中，还总结出了以下最常见的、对项目目标影响最大的软件项目风险类别，可供项目管理者参考。

(1)需求风险。软件项目极为显著的特点就是信息的不对称性，掌握技术的开发者对用户业务缺乏理解，而熟悉业务的用户则对技术不了解，因此双方在沟通时会产生障碍。软件项目在初期确定的需求往往都是模糊的、不确定的，而且随着项目的进展，需求还可能不断变化，这些问题如果没有得到及时解决，就会对项目的成功造成巨大的潜在威胁，很可能产生无法交付的结果或者埋下危险的隐患。常见的与需求相关的风险有:需求不够明确、准确;缺少有效的需求变更管理措施，对需求变更缺少相关的分析评估;对用户不切实际的承诺;用户对产品需求缺少认同;用户对产品需求缺少清晰的认识;用户对产品的需求无限制地膨胀;用户不能经常性地参加需求分析和阶段性评审;用户与项目团队之间没有建立直接、快速的通信渠道;用户不具有基本的技术和信息化知识，等等。

(2)过程和标准方面的风险。规范的软件过程和软件工程标准是取得软件项目成功的重要保障。常见的有关过程和标准的风险有:组织没有建立适用于本组织的软件过程规范或标准;没有管理机制保证项目团队按照软件工程标准来工作;流程的重组和标准的改变使开发人员不适应，甚至有抵触情绪;没有采用配置管理来跟踪和控制软件工程中的各种变更，等等。

(3)组织和人员管理风险。软件项目最大的资源是人力资源，但一个不争的事实是IT行业的人员流动性大，个性较强，难于管理。一旦项目组织和人员发生变动，往往会关系到整个项目的成败，因此组织和人员管理是软件项目管理的一个重要课题。组织和人员管理方面的常见风险有:采用了不符合项目特征的组织结构和管理模式;人员离职或因特殊原因而不能参加项目工作;人员之间的沟通和协调产生障碍;人员之间产生冲突;因绩效评估、奖惩等方面的不当措施而挫伤员工的工作积极性;将项目的一部分外包给其他开发商，但与承包商之间缺乏良好的合作和沟通，等等。

(4)技术风险。软件项目所涉及的技术往往十分复杂，同时由于软件技术飞速发展，在项目中经常需要适当采用一些新技术，以更好地实现项目的目标。因此软件项目中经常隐含着技术风险，应在项目初期就识别出这些风险，以便下一步采取合适的预防措施。软件项目中可能涉及的技术风险很多，比如:团队对项目中的技术和工具缺少充分理解;缺少应用领域的经验和背景知识;采用了错误的技术和方法;需要对技术进行更新，但对新技术不熟悉;所采用的新技术不够成熟，等等。

风险规划

风险规划(Risk Planning）就是制定项目风险管理的一整套计划，主要包括定义项目组及其成员风险管理的行动方案和方式，选择适合的风险管理方法，确定风险判断的依据，指定风险管理的角色和职责，概括风险识别和评估的结果并制定相应的风险应对策略等。风险规划的结果就是正式的“风险管理计划”(Risk Management Plan，RMP )，有时也可将风险识别和评估结果以及相应的应对策略抽取出来，单独形成一份“风险规避计划”。

风险规划的依据

为了进行合理的风险规划，需参考各方面的信息，主要包括以下方面。

1)项目计划中所包含或涉及的有关内容，如项目目标、项目规模、项目利益相关者情况、项目复杂程度、所需资源、项目进度、约束条件及假设前提等。

(2)项目组织及个人的风险管理经验及实践。

(3)决策者、责任方及授权情况。

(4)项目干系人对项目风险的敏感程度及可承受能力。

(5)可获取的数据及管理系统情况:丰富的数据和运行良好的计算机辅助管理系统，将有助于风险识别、评估、定量化及对应策略的制定。

软件项目风险管理计划

风险管理计划是针对整个项目生命周期而制定的如何组织和进行风险识别、风险评估、风险应对、风险监控的计划，它详细说明了如何把风险管理步骤应用于整个项目之中，并说明了项目整体风险评价基准是什么，应当使用什么样的方法以及如何参照这些风险评价基准对软件项目整体风险进行评价。风险管理计划一般应该包括以下几方面的内容。

(1)方法:确定风险管理使用的方法、工具和数据资源，这些内容可随项目阶段及风险评估情况作适当的调整。

(2)角色与职责划分:明确项目中进行风险管理活动的角色定位、任务分工和相关责任人。

(3)风险承受程度:即风险承受限度标准。不同的项目团队对于风险所持的态度也不相同,这将影响其对风险认知的准确性，也将影响其应对风险的方式。应当为项目制定适合的风险承受标准，对风险的态度也应当明确地表述出来。

(4)项目风险管理时间与频率:界定项目生命周期中实施风险管理活动的各个阶段，以及风险管理过程的评价、控制和变更的次数或频率等，并把风险管理活动纳入到软件项目进度计划中去。

(5)预算:风险管理活动必然要产生一些成本，占用一些资源，因此应对风险管理进行成本预算。

(6)风险类别:风险类别清单可以保证对项目进行风险识别的系统性和一致性，并能保证识别的效率和质量，还可以为其他的风险管理活动提供一个统一的框架。

(7)基准:明确定义由谁在何时以何种方式采取风险应对行动，明确的定义可以确保项目团队与所有项目干系人都能够准确、有效地应对风险，防止对风险管理活动的理解出现不必要的分歧。

(8)汇报形式:规定风险管理各过程中应汇报和沟通的内容、范围、渠道及方式、格式等。汇报与沟通应包括项目团队内部之间的沟通及项目外部与投资方等利益相关者之间的沟通。

(9)跟踪和数据记录:确定如何以文档的方式记录项目进行过程中的风险和风险管理活动。风险管理数据文档可以有效地应用于对项目进行管理、监控、审计和总结经验教训等。例如，风险识别结果的记录、风险分析过程和结果的记录、风险应对策略及决策的依据和结果的记录、风险发生和处理的记录等一系列数据记录。

(10)风险概率和影响的定性等级:为了按照统一的标准管理项目中的风险,需要定义风险发生概率与影响程度的定性等级。

(11)项目的主要风险及其特性:识别出的项目的主要风险及其特性描述，包括风险事件、发生概率、影响、原因、应对措施等。这一部分内容也可写在一份单独的“风险规避计划”中。

风险识别方法:

风险识别(Risk Identification )是软件项目风险管理的基础和重要组成部分，其任务就是确定何种风险事件可能影响项目，并对风险的特性进行描述。

风险识别通常至少需要确定风险的3个相互关联的要素:第一，风险来源，如进度、成本、技术、人员等;第二，风险事件，即给项目带来消极影响的事件;第三，风险征兆，即风险事件的外在表现，如苗头和前兆等。

风险识别的依据包括以下几个方面。

(1)风险管理计划:其中确定的风险管理方法、风险承受程度、风险类别等都是风险识别最重要的依据。

(2)项目计划:其中的项目目标、任务、范围、进度计划、费用计划、资源计划、采购计划及项目参与各方和其他利益相关者对项目的期望值等都是项目风险识别的依据。

(3)历史资料:从以前相关项目的历史资料中可以获取对本项目有借鉴作用的风险信息。

(4)制约因素和假定:项目的一些制约因素和假设的前提条件中可能隐藏着风险。

核对表法

核对表将软件项目可能发生的许多潜在风险列于一张表上，供风险识别人员进行检查核对，用来判别某项目是否存在表中所列或类似的风险。核对表中所列都是从大量项目实践中总结出的常见风险，是项目风险管理经验的结晶。一个成熟的软件组织应掌握丰富的风险核对表信息。

软件项目风险核对表一般是根据风险来源编写的，它包括项目的技术、人员、进度、成本、需求、产品质量等方面的风险。

利用核对表进行风险识别的优点是快速而简单，可以用来对照软件项目的实际情况，逐项排查，从而帮助识别风险。但是这种方法受到可比性的限制比较大，很难做到全面周到，因为每个软件项目都有其特殊性。在软件项目的收尾过程中，应通过总结项目经验，对风险核对表进行检查和改进。

头脑风暴法

头脑风暴法又叫集思广益法，它是通过营造一个无批评的自由的会议环境，使与会者畅所欲言，互相启迪，从而产生出大量创造性意见的过程。头脑风暴法是解决问题的一种常用方法，它可以充分发挥集体智慧，保证群体决策的创造性，提高决策质量。将头脑风暴法应用于软件项目风险识别时，要将项目的主要参与人员代表召集在一起，然后利用他们对项目不同部分的认识，识别项目可能出现的各种问题，提出尽可能多的威胁和风险。

头脑风暴法的具体做法是:参加会议的人员轮流发言，无条件接纳任何意见，不加以评论。由一个记录人员记录提出的每一条意见，并写在白板上，可被所有参会人员看到。由于思想的互.相启发，一些人可能会根据前面其他人的意见提出新的或改进的意见。在轮流发言过程中，任何一个成员都可以先不发表意见而跳过。这一过程循环进行，直到所有人员都没有新的意见或限定时间到。

应用头脑风暴法时要遵循的重要原则是:不进行讨论，没有任何判断性评论。对各种意见、观点的评判要放到事后进行，否则会影响会议的自由气氛。要认真对待任何一种意见，而不管其是否正确。

用头脑风暴法进行风险识别的优点是善于发挥相关专家和分析人员的创造性思维，从而可对软件项目的风险进行全面的识别，并可在此基础上根据一定的标准对软件项目风险进行分类。

德尔菲法

德尔菲（Delphi)法是一种匿名反馈的函询法，它被广泛应用于经济、社会、工程技术等领域，对一些问题进行预测或估算。该方法用于风险识别的具体做法是:把需要做风险识别的软件项目的情况分别匿名函询专家的意见，然后对意见进行整理、归纳、统计;再匿名反馈给各专家，再次征求意见，再集中，再反馈;直至各专家的意见趋向一致，作为最后的结论。

德尔菲法与其他的专家判断、访谈等方法有着明显的不同，要使用好该方法需要注意它的3个主要特点。

(1)德尔菲法中征求意见是匿名进行的，这有助于排除若干非技术性的干扰因素。

(2)德尔菲法要反复进行多轮的咨询、反馈，这有助于逐步去伪存真，得到稳定的结果。

(3)工作小组要对每轮的专家咨询结果进行统计、归纳，这样可以综合不同专家的意见，不断求精,最后形成统一的结论。

德尔菲法的优点是既能广泛征求专家意见，又可避免个人因素对软件项目风险识别的结果产生不良影响。

SWOT分析法

所谓的SWOT 是英文的Strength(优势)、Weakness(劣势)、Opportunity(机遇）和Threat(挑战）的简写。SWOT 分析法的基准点是对企业内部环境之优劣势的分析，在了解企业自身特点的基础之上,判明企业外部的机会和威胁,然后对环境作出准确的判断,作出合理决策。SWOT分析法作为一种分析工具，应用非常广泛，也常用于项目风险的分析识别。

SWOT分析法需使用道斯矩阵表。在分析时通常分为以下5步:

列出项目的优势和劣势，可能的机会与威胁，填入道斯矩阵表的Ⅰ、ll 、、Ⅳ区。
将内部优势与外部机会相组合，形成SO 策略，制定抓住机会、发挥优势的战略，填入道斯矩阵表的V区。

(3)将内部劣势与外部机会相组合，形成WO策略，制定利用机会克服弱点的战略，填人道斯矩阵表的VI区。

(4)将内部优势与外部威胁相组合，形成ST 策略，制定利用优势减少威胁战略，填入道斯矩阵表V区。

(5)将内部劣势与外部挑战相组合，形成WT策略，制定弥补缺点、规避威胁的战略，填入道斯矩阵表的I区。

由于SWOT分析法明确了项目的优势和劣势，以及机会和威胁，因此可以多角度地、合理地分析识别项目的风险。

其他方法

风险识别的形式和方法是很灵活的，除了以上介绍的4种方法外，还可以用其他各种各样的方法来识别风险，如文档评审、阶段评审、挣值分析、情景分析、环境分析、面谈等。

对软件项目的计划、方案等文档和每个项目阶段的工作过程及其成果进行评审，可识别出项目的许多风险。

挣值分析将计划的工作与已完成的工作进行比较，确定项目是否符合计划的费用和进度要求，如果偏差较大，则需要进一步进行项目的风险识别、评估和量化。

情景分析是通过有关数据和图表等，对项目未来的某个状态或某种情况进行详细的描绘和分析，从而识别引起项目风险的关键因素及风险的影响程度。它注重说明某些事件引发风险的条件和因素，并且还要说明当某些因素发生变化时，又会出现什么样的风险，会产生什么样的后果。

环境分析是对项目的环境（包括客户、竞争者、合作者、政府管理者等）进行分析，从而识别出项目风险，并重点考虑它们相互联系的特征和稳定性。

与软件项目的团队成员、有经验的项目干系人、有关专家和有类似项目经验的人进行有关风险的面谈，将有助于识别那些在常规方法中未被识别的风险。

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

软件项目风险评估

软件项目风险评估就是对每个已识别出的风险进行分析,具体地可分为定性评估和定量评估。定性评估是确定风险发生的概率和发生后产生的影响程度，并按照风险的潜在危险性大小对其进行优先级排序;定量评估是针对那些对项目有潜在重大影响而排序在前的风险进行量化分析，从而为风险应对和项目管理决策提供依据。

风险概率和影响程度评估

风险概率和影响程度评估是根据软件项目风险管理计划中定义的标准，评估项目中每一个风险发生的可能性和它对项目目标（时间、成本、质量等)所造成的影响。

在软件项目风险管理计划中应该为风险发生的概率和影响程度制定一个统一的分级标准。例如，根据风险事件发生的可能性，可以把它定性地分为几个等级，并用“很低”“低”“中等”“高”“很高”等词汇来描述风险发生的可能性的高低,还可以为每个等级赋予一个数值,表示概率等级,形成风险发生概率的定性等级。

同样，根据风险发生后对软件项目目标的影响程度不同，也可以把它定性地分为几个等级，并为每个等级赋予一个数字。

软件组织可针对每个项目目标（成本、进度或质量等）单独评定一项风险的影响程度等级，也可制定相关方法为每项风险确定一个总体的等级水平。

同样，根据风险发生后对软件项目目标的影响程度不同，也可以把它定性地分为几个等级，并为每个等级赋予一个数字。

软件组织可针对每个项目目标（成本、进度或质量等）单独评定一项风险的影响程度等级，也可制定相关方法为每项风险确定一个总体的等级水平。

可以组织包括软件项目团队成员、项目干系人和项目外部的专业人士等在内的人员，采用召开会议或进行访谈等方式，对风险发生概率和影响程度进行分析。每项风险的发生概率和影响程度值可由每个人定性地估计，然后汇总平均，得到一个有代表性的值。

在对软件项目风险发生的概率等级及其影响程度进行评估的过程中，需要注意记录相关的影响因素，包括确定发生概率和影响程度所依赖的假设和约束条件等，这些相关因素在应对风险时具有很重要的参考作用。

可采用下式为每个风险计算出一个“风险值”。

风险值=风险发生概率×风险影响程度

风险值代表了风险的危险程度，可根据风险值的大小对风险进行排序，风险值较大的排在前面。风险排序可为风险应对措施提供指导，排在前面的高风险需要重点关注，并采取积极的应对策略，而排在后面的低风险，只需将之放入待观察风险清单，不需要采取任何积极的管理措施。软件工程专家Boehm建议管理者将管理重点放在排在前十的风险上。实际上对小型项目来说，可以关注比10个更少的风险。

对于排序在先的高风险，可能还需采用决策树分析或蒙特卡洛仿真等方法进行定量分析，对项目决策提供支持。

决策树分析法

决策树是一种直观、形象、易于理解的图形分析方法。将该方法应用到软件项目风险评估中时，可将不同的方案、风险发生概率及其后果都用树状的图形清晰地表示出来，用以指导项目管理者的决策。

决策树是以方框和圆圈为节点，由直线连接而成的一种树状图形结构。

决策树一般包括以下几个部分。

(1)——决策节点。从它引出的分支称为方案分支，分支数量与方案数相同。决策节点表明从它引出的方案要进行分析和决策，在分支上要注明方案的名称。

(2)O———状态节点。从它引出的分支称为状态分支或概率分支，分支数量等于状态数量，在每一分支上注明状态名称及其出现的概率。

(3)——结果节点。将不同方案在各种状态下所取得的结果标注在结果节点的右端。用决策树评估项目风险时，其评估准则可以是期望损益值、效用期望值或其他指标值。下面举例说明决策树分析法的应用。

某软件公司有一款办公软件，现在需要决定是否研发该办公软件的新版本。据分析测算，如果市场需求量大,只销售老版本的软件可获利50万元,开发出新版本软件并销售可获利100万元。如果市场需求量小，只销售老版本软件仍可获利20万元，开发和销售新版本软件将亏损10万元(以上损益值均指一年的情况)。另据市场分析可知，市场需求量大的概率为0.8，需求量小的概率为0.2。试分析和确定是否应该研发该办公软件的新版本。

为分析研发新版本办公软件的风险并作出决策，第一步，绘制出决策树。

第二步，计算各节点的期望损益值，计算顺序是从右向左进行。

节点2:100×0.8+(-10)×0.2=78（万元)

节点3:50×0.8+20×0.2=44（万元)

决策点1的期望损益值为:max {78,44}=78（万元)

第三步，剪枝。决策点的剪枝从左向右进行，因为决策点的期望损益值为78万元，是“研发新版本”这一方案的期望损益值，因此剪掉“不研发新版本”这一分支，保留“研发新版本”这一分支。因此根据年度获利最多这一评价准则，合理的决策是开发新版本办公软件。

模拟分析法

模拟分析法是运用概率论及数理统计的方法来预测和研究各种不确定因素对软件项目的影响，分析系统的预期行为和绩效的一种定量分析方法。大多数模拟都以某种形式的蒙特卡洛分析为基础。

蒙特卡洛模拟法是一种最经常使用的模拟分析方法，它是随机地从每个不确定因素中抽取样本，对整个软件项目进行一次计算，重复进行很多次，模拟各式各样的不确定性组合，获得各种组合下的很多个结果。通过统计和处理这些结果数据，找出项目变化的规律。

例如，把这些结果值从大到小排列，统计每个值出现的次数，用这些次数值形成频数分布曲线，就能够知道每种结果出现的可能性。然后，依据统计学原理，对这些结果数据进行分析，确定最大值、最小值、平均值、标准差、方差、偏度等，通过这些信息就可以更深入地、定量地分析项目，为决策提供依据。

在软件项目中经常用蒙特卡洛模拟法来模拟仿真项目的日程、制作项目日程表。通过对项目的多次“预演”，可以得到项目进度日程的统计结果。一个项目进度日程的蒙特卡洛模拟中的曲线显示了完成项目的累积可能性与项目持续时间的关系。横坐标表示进度，纵坐标表示完成的概率，虚线的交叉点显示:在项目启动后120天之内完成项目的可能性为50%。项目完成期越靠左，则风险越高（完成的可能性低)，反之风险越低。

另外，蒙特卡洛模拟法也常被用来估算项目成本可能的变化范围。

风险应对方法:

风险应对就是对项目风险制定应对策略和处置办法的过程。可以从改变风险发生的概率、改变风险后果的大小、改变风险的作用对象3个角度来提出不同的风险应对策略。常见的策略有回避、减小、转移、接受和预留，具体采用哪一种或哪几种，需要由项目团队根据当前软件项目及其所面临的风险的实际情况来决定。

回避风险

回避风险是指当项目风险发生的可能性太大，不利后果也很严重，又无其他策略可用时，主动放弃或改变会导致风险的行动方案。回避风险包括主动预防风险和完全放弃两种。

人们不可能排除所有的风险，但可以通过分析找出发生风险的根源，通过消除这些起因来避免相应风险的发生，这是通过主动预防来回避风险。例如，如果在客户验收软件系统时存在着客户与开发者对软件需求的理解不一致的风险，该风险的根本原因是需求不明确，双方未就需求达成一致。为了避免这个风险，可以开发原型系统向客户演示，直到客户满意，并记录下来形成需求基线。

回避风险的另一种策略是完全放弃。例如在互联网泡沫破灭的时候，许多公司关闭了网站，防止造成进一步的损失;又如在软件开发过程中发现采用的新技术风险太大,因此放弃了新技术。这些都是完全放弃的风险应对策略，是最彻底的风险回避方法，但也是一种消极的应对手段，在放弃的同时也可能会失去发展的机遇。

在采取回避策略之前，必须要对风险有充分的认识，对威胁出现的可能性和后果的严重性有足够的把握。另外，采取回避策略，最好在行动方案尚未实施时，若放弃或改变正在执行的方案。

减小风险

减小风险策略就是指降低风险发生的可能性或减小风险后果的不利影响。例如，为了减轻项目的进度风险，可以压缩关键活动时间、加班或采取“快速跟进”;为了减小软件配置的丢失和损坏的风险，可由配置管理员定期对配置库进行备份。

减轻风险策略的有效性与风险的可预测性密切相关。对于那些发生概率高、后果也可预测的风险，项目管理者可以在很大程度上加以控制，可以动用项目现有资源降低风险的严重性后果和风险发生的概率。而对于那些发生概率和后果很难预测的风险，项目管理者很难控制，有必要采用迂回策略。对于这类风险，仅仅靠动用项目资源一般无济于事，还必须进行深入细致的调查研究，降低其不确定性。例如，在决定开发一个新产品之前，应先进行市场调研，对市场容量、市场前景、现有同类产品的信息等都有详细了解，理解用户使用需求、偏好以及价格倾向等，在这样的基础上提出的项目才有较大的成功机会。

在实施减小风险策略时，应尽可能将项目每一个具体风险都减轻到可接受的水平。项目中各个风险都减轻了，项目的整体风险程度也就降低了，项目失败的概率就会减小。

转移风险

转移风险又称为合伙分担风险，其目的是借用合同或协议，在风险事故一旦发生时将损失的全部或一部分转移到项目以外的有能力承受或控制风险的个人或组织。这种策略要遵循两个原则:;第一，必须让承担风险者得到相应的回报;第二，对于各具体风险，谁最有能力管理则让谁分担。当项目的资源有限、不能实行减轻和预防策略，或风险发生频率不高、但潜在损失或损害很大时可采用此策略。转移风险主要有4种方式:出售、外包、开脱责任合同、保险与担保。

(1)出售:通过买卖契约将风险转移给其他组织。这种方法在出售项目所有权的同时也就把与之有关的风险转移给了其他组织。

(2)外包:目前在软件业中非常流行的软件外包就是一种很好的风险转移策略，外包就是向本项目组织之外分包产品的开发，从而把风险转移出去。例如，某软件项目中要使用某种特殊的技术，承扭项目的组织对该技术不熟悉，与其自行开发，不如与有此种技术经验的开发商签订合同，委托对方开发，从而转移自己在这方面的技术风险。

(3)开脱责任合同:在合同中列入开脱责任条款，要求甲方(客户)在风险事故发生时，不令乙方(项目承担者）承担责任。

(4)保险与担保:保险是转移风险最常用的一种方法。项目承担者只要向保险公司缴纳一定数额的保险费，当风险事故发生时就能获得保险公司的补偿，从而将风险转移给保险公司。除了保险，担保也是常用的风险转移策略，所谓担保，指为他人的债务、违约或失误负间接责任的一种承诺。在项目管理上是指银行、保险公司或其他非银行机构为项目风险负间接责任的一种承诺。

接受风险

接受风险是指项目团队选择由自己来承担风险后果。当项目团队认为自己可以承担风险发生后造成的损失，或采取其他风险应对方案的成本超过风险发生后所造成的损失时，可以采用接受风险策略。

有的风险是没有办法消除的，如地震等自然灾害，当风险发生的时候，只能接受风险造成的后果。例如，为了避免不可抗力造成的后果，在一些重要的软件项目中，可以建立异地备份中心,当风险真的发生时，可以接受事实，启用备份中心。这是主动地接受风险，即在风险识别和分析阶段已对风险有了充分的准备，所以当风险事件发生时马上执行应急计划。

接受风险也有可能是被动的，即在风险造成的损失数额不大，不至影响项目大局的情况下，将其损失列为项目的一种费用。例如在某些情况下不得不接受用户提出的一些新的需求或需求变更。一般在风险评估阶段对风险进行优先级排序后，可以决定忽略（接受）一些风险，以便于将资源投入到发生概率较高、危险较大的风险上。

风险预留

风险预留是指事先为项目风险预留一部分后备资源，一旦风险发生，就启动这些资源以应对风险。风险预留一般应用在大型项目中，因为大型项目复杂性很高，项目周期长，不可控因素也很多，风险造成的损失也很大，因此有必要对风险进行预留。

项目的风险预留主要有风险成本预留、风险进度预留和技术后备措施3种。(1)风险成本预留

预留的风险成本是在项目经费预算中事先准备的一笔资金，用于补偿差错、疏漏及其他不确定性对项目费用估计精确性的影响。虽然预留的风险成本在项目初期就已经预算出来，但是究竞何时用在何处，以及需要花费多少，在编制项目成本预算时并不能具体确定。

风险成本预留在项目预算中要单独列出，不能分散到具体费用项目下，否则项目管理组很容易失去对支出的控制。同时，项目团队在进行风险成本预留时要根据风险评估的结果来进行，不可盲目地在各个具体费用中预留成本。盲目的预留会在项目进行过程中增加许多浪费，减少项目收益，同时也可能由于项目预算过高而在市场竞争中错失机会。

风险成本预留又可分为实施应急费和经济应急费两类。实施应急费用于补偿估价和实施过程中的不确定性,经济应急费用于应付通货膨胀、价格或汇率等的波动。

(2)风险进度预留

对于项目进度方面的不确定性，项目各有关方一般不希望以延长时间的方式来解决，因此项目管理者就要设法制定出一个较紧凑的进度计划，争取项目在要求完成的日期前完成。从网络计划的观点来看，风险进度预留就是在关键路径上设置一段时差或机动时间。当项目进行过程中出现了一些不利事件引起进度拖延时，项目管理者可以用这些机动时间或者时间差去补偿进度的延迟，从而在总体上保证项目的整体进度。

可以通过压缩关键路径上活动的持续时间或者改变活动之间的关系来预留项目的进度，比如赶工法、快速跟进法等。但是，这样的方法一般都会增加资源的投入，甚至带来新的风险。

(3)技术后备措施

技术后备措施专门用于应对项目的技术风险，它是预留的一段时间或一笔资金。只有当技术风险发生，并需要采取补救行动时，才动用这段时间或这笔资金。

风险监控的作用和常用方法:

风险监控包括对风险发生的监控和对风险管理的监控，前者是对已识别的风险源进行监督和控制，以便及早发现风险事件的征兆，从而将风险事件消灭在萌芽中或采取紧急应急措施以尽量减小损失;后者是在项目实施中监督人们认真执行风险管理的组织措施和技术措施，以消除风险发生的人为诱因。

风险监控贯穿在软件项目执行过程的始终，其目的是监视项目风险的状况，例如风险是已经发生、仍然存在还是已经消失，风险决策的结果是否与预期的相同，识别新出现的风险，并发现细化和改进风险管理计划的机会，把信息反馈给有关决策者。

风险预警

风险监控的一个良好开端和有效措施是建立一个预警系统，及时觉察计划的偏离。所谓风险预警，是指对于项目管理过程中有可能出现的风险，采用超前或预先防范的管理方式，一旦有发生风险的征兆，就及时发现并发出预警信号，以便采取矫正行动，从而最大限度地控制不利后果的发生。

当计划与现实之间发生偏差时，这种偏差可能是积极的，也可能是消极的。例如，计划之中的项目进度与实际完成日期的区别显示了计划的提前或延误,前者通常是积极的,后者是消极的。这样，计划进度与实际进度之间的区别就是系统会探测到的一个偏差，可作为进度风险的预警。另一个关于计划的预警是活动浮动时间的减少，项目中浮动越少，风险产生影响的可能性就越大，因此活动的浮动时间越少，活动就越应该被关注。

此外，预算与实际支出之间的差别也一定要监控，两者之间的偏离表明完成工作花费得较少或太多，后者通常是消极的。

通过风险预警，可从“救火式”风险监控向“消防式”风险监控发展，从注重风险应对向风险事前控制发展。

风险监控方法

风险监控的方法有很多，以下简要介绍几种常用方法，包括阶段性评审与过程审查、风险再评估、挣值分析、技术绩效衡量。

(1)阶段评审与过程审查

阶段评审和过程审查是软件项目中经常性的活动，通过这样的评审活动来评估、确认前一个阶段的工作及其交付物，评价软件过程的有效性，并提出补充修正措施，调整下―阶段工作的内容和方法。

阶段评审和过程审查可以让风险的征兆尽早被发现，从而可以尽早地预防和应对。风险发现地越早，越容易防范，应对的代价也越小。阶段评审和过程审查可以有效地检验工作方法和工作成果，并通过一步步地确认和修正中间过程的结果来保证项目过程的工作质量和最终交付物的质量，从而大幅度地降低了软件项目的风险。

(2)风险再评估

风险监控过程通常要使用本章前面介绍的方法对新风险进行识别和评估，或对已经评估的风险进行重新评估，检查其优先次序、发生概率、影响范围和程度等是否发生了变化，如果发生了变化，要考虑怎样调整其应对措施。应该安排定期进行项目风险再评估，每次重新评估的内容和详细程度可根据软件项目的具体情况而定。

(3)挣值分析

挣值分析不仅可以用于风险识别，也可用于风险监控，因为挣值分析的结果反映了软件项目在当前检查点上的进度和成本等指标与项目计划的差距。如果存在偏差，则可以对原因和影响进行分析，这有助于对进度和成本风险进行监控。

(4)技术绩效衡量

该方法将项目执行期间的技术成果与项目计划中预期的技术成果进度进行比较，如果出现偏差，则可能会导致风险发生。例如，在某里程碑处未实现计划规定的功能，有可能意味着项目范围的实现存在着风险。

软件项目收尾和验收--软件项目管理第10章总结回顾

项目收尾概述

项目收尾过程是项目干系人和客户对最终产品进行验收，使项目有序地结束的过程。项目收尾阶段是项目的最后阶段，这一阶段仍然需要进行有效的管理，适时作出正确的决策，总结项目的经验教训，为今后的项目管理提供有益的经验。

当项目满足一定的结束条件时，就可以进行项目收尾工作了。在项目收尾过程中，客户方要按合同的有关条款对开发方交付的软件产品和服务进行确认，终结合同和完成项目后评价。项目收尾工作对项目的最终成败有着重要影响。

项目收尾过程

项目结束时，结果或是成功或是失败，评定项目成功与失败的标准主要是:是否有可交付的合格成果，是否实现了项目目标,是否达到项目客户的期望。

结束一个项目的原因有多种，例如:

1.项目计划中确定的可交付成果已经出现，项目的目标已经成功实现。

2.项目已经不具备实用价值。

3.由于各种原因导致项目无限期延长。

4.项目所有者的战略发生了变化，项目与项目所有者组织不再有战略的一致性。

5.项目已没有原来的优势，同其他更领先的项目竞争难以生存。

项目收尾过程包括如下活动:

(1)范围确认:项目结束前，重新审核工作成果，检验项目的各项工作范围是否完成，或者完成到何种程度。如果项目提前结束，则应查明有哪些工作已经完成，完成到了什么程度，并将核查结果记录在案，形成文件。

项目范围确认完成后，参加项目范围确认的项目班子和接收方人员应在事先准备好的文件上签字，表示接收方已正式认可并验收全部或阶段性成果。一般情况下，这种认可和验收可以附有条件，例如软件开发项目的移交和验收时，可规定以后发现软件有问题时仍然可以找该软件项目开发人员解决。

质量验收:质量验收是控制项目产品最终质量的重要手段，依据质量计划和相关的质量标准进行验收，不合格不予接收。

质量验收的范围包括以下两方面:

项目规划阶段的质量验收:主要检验设计文件的质量,同时项目的全部质量标准及验收依据也是在规划设计阶段完成的，因此，规划阶段的质量验收也是对质量验收评定标准与依据的合理性、完备性和可操作性的检验。

项目实施阶段的质量验收:项目实施阶段是项目质量产生的全部过程。实施阶段的质量验收要根据范围规划、工作分解和质量规划对每一个工序进行单个的评定和验收，然后根据各单个工序质量验收结果（如可以把单项工序的质量等级分成不合格、合格、良好、优四级）进行汇总统计，形成上级工序的质量结果(合格率或优良率)，以此类推，最终形成整个项目的质量验收结果。

(3)费用决算:是指对项目开始到项目结束全过程所支付的全部费用进行核算，编制项目决算表的过程。费用决算的结果形成项目决算书，经项目各参与方共同签字后作为项目验收的核心文件。决算书由两部分组成:文字说明和决算报表。文字说明主要包括工程概况、设计概算、实施计划和执行情况、各项技术经济指标的完成情况、项目的成本和投资效益分析、项目实施过程中的主要经验、存在的问题、解决意见等。而决算报表分大中型项目和小型项目两种。大中型项目的决算表包括:竣工项目概况表、财务决算表、交付使用财产总表、交付使用财产明细表;小型项目决算表将上述内容简化为项目决算总表和交付使用财产明细表。

(4)合同终结:整理并存档各种合同文件，包括项目的各种商品采购和劳务承包合同。这项管理活动中还包括有关项目或项目阶段的遗留问题解决方案和决策的工作。

(5)项目资料检查和归档:检查项目过程中的所有文件是否齐全，然后进行归档。项目资料是项目竣工验收和质量保证的重要依据之一，项目资料也是项目交接、维护和后评价的重要原始凭证，在项目验收工作中起着十分重要的作用，因此，项目资料验收是项目竣工验收前提条件，只有项目资料验收合格，才能开始项目竣工验收。

(6)项目后评价:是指对已完成的项目的目的、执行过程、效益、作用和影响所进行的系统的、客观的分析，通过项目活动实践的检查总结，确定项目预期的目标是否达到，项目或规划是否合理有效,项目的主要效益指标是否实现,通过分析评价找出成功失败的原因，总结经验教训,为新项目的决策和提高完善投资决策管理水平提出建议，为项目实施运营中出现的问题提供改进意见，从而达到提高投资效益的目的。

项目成功的要素

为了确保项目成功，在项目收尾阶段，要注意以下要素。

(1)通过正式验收

项目通过正式验收，代表客户认可了项目组的工作，这是项目成功收尾的一个基本的前提，只有具备了这个前提，项目才有可能成功。

(2)项目保障利润、资金落实到位

软件企业运作项目就是要赢利，要保证项目能产生利润，各种资金周转顺畅，必须进行认真的核算，一方面客户的应付项目款要结清，另一方面，项目组的开发实施费用要盘结清楚。

(3)项目总结

当前项目在管理方面、技术方面、开发过程等方面的经验对其他项目、特别是对类似的项目有很好的借鉴意义。因此要认真进行项目总结,积累经验。

(4)客户关系保持良好

软件系统的业务需求经常是在不断变化的，软件系统要进行维护和升级，保持良好的客户关系，使软件企业和客户保持合作关系，从而为软件企业的收益赢得新的增长点。

项目移交与清算

在项目收尾阶段，如果项目达到预期的目标，就执行正常的项目验收、移交过程;如果项目没有达到预期的效果，并且由于种种原因已不能达到预期的效果，项目已没有可能或没有必要进行下去，而提前终止，这种情况下的项目收尾就是清算，项目清算是非正常的项目终止过程。

1．项目移交

软件项目的移交成果包括以下一些内容。

·已经配置好的系统环境;

·软件产品;

·项目成果规格说明书;

·系统使用手册;

·项目的功能、性能技术规范;

·测试报告等。

移交阶段具体的工作包括以下几个方面。

·检查各项指标，验证并确认项目交付成果满足客户的要求。

·对客户进行系统的培训，以满足客户了解和掌握项目结果的需要。

·安排后续维护和其他服务工作，为客户提供相应的技术支持服务，必要时另行签订系统的维护合同。

·签字移交。

项目清算

项目清算是在项目非正常终止的情况下进行的收尾工作，项目非正常终止的原因包括以下几点。

(1)项目规划阶段已存在决策失误，例如，可行性研究报告依据的信息不准确，市场预测失误，重要的经济预测有偏差等诸如此类的原因造成项目决策失误。

(2)项目规划、设计中出现重大技术方向性错误，造成项目的计划不可能实现。

(3)项目的目标已与组织目标不能保持一致。

(4)环境的变化改变了对项目产品的需求，项目的成果已不适应现实需要。

(5)项目范围超出了组织的财务能力和技术能力。

(6)项目实施过程中出现重大质量事故,项目继续运作的经济或社会价值基础已经不复存在。

(7)项目虽然顺利进行了验收和移交，但在软件运行过程中发现项目的技术性能指标无法达到项目设计的要求，项目的经济或社会价值无法实现。

(8)项目因为资金或人力无法近期到位，并且无法确定可能到位的具体期限，使项目无法进行下去。

项目清算程序如下:

步骤一:组成项目清算小组，主要由投资方召集项目团队、工程监理等相关人员。

步骤二:项目清算小组对项目进行的现状及已完成的部分，依据合同逐条进行检查。对项目已经进行的并且符合合同要求的，免除相关部门和人员责任;对项目中不符合合同目标的，并有可能造成项目失败的工作，依合同条款进行责任确认。

步骤三:找出造成项目非正常终止的所有原因，总结经验。

步骤四:明确责任，确定损失，协商索赔方案，形成项目清算报告，合同各方在清算报告上签证,使之生效。

步骤五:协商不成则按合同的约定提起仲裁。

项目后评价

项目后评价就是在项目完成后，对项目进行分析，评价项目的得失，总结经验教训。项目后评价的方法有如下几种。

(1)影响评价法:项目完成后测定和调研在各阶段所产生的影响和效果，以判断决策目标是否正确。

(2)效益评价法:把项目产生的实际效果或项目的产出，与项目的计划成本或项目投入相比较，进行盈利性分析，以判断项目当初决定投资是否值得。

(3)过程评价法:把项目从立项决策、设计、采购直至建设实施各程序的实际进程与原订计划、目标相比较，分析项目效果好坏的原因，找出项目成败的经验和教训，使以后项目的实施计划和目标的制定更加切合实际。

实践中，常常将上面3种评价方法有机地结合起来，进行综合评价，才能取得最佳评价结果。

项目后评价的基本内容

项目后评价的内容主要包括:项目的技术经济评价、项目的社会效益评价、项目数据总结和项目问题总结。

(1)项目的技术经济评价

项目的技术评价主要是对设计方案、采用的技术的可靠性、适用性、先进性、经济合理性的再分析。在决策阶段认为可行的技术和方案，在使用中有可能与预想的结果有差别，许多不足之处逐渐暴露出来，在评价中就需要针对实践中存在的问题、产生的原因认真总结经验，在以后的设计或项目中选用更好、更适用、更经济的方案，或对原有的技术方案进行适当的调整，发挥其潜在的效益。

项目的经济（财务）评价与项目规划阶段的经济分析在内容上基本是相同的，都要进行项目的盈利性分析、清偿能力分析等。在盈利性分析中要通过全投资和自有资金现金流量表，计算全投资税前内部收益率、净现值，自有资金税后内部收益率等指标，通过编制损益表，计算资金利润率、资金利税率、资本金利润率等指标，以反映项目和投资者的获利能力。清偿能力分析主要通过编制资产负债表、借款还本付息计算表，计算资产负债率、流动比率、速动比率、偿债准备率等指标，反映项目的清偿能力。

(2）项目的社会效益评价

通过社会效益评价，既分析项目对企业的贡献与影响，又分析项目对社会政策贯彻的效用，研究项目与社会的相互适应性，从项目的社会可行性方面为项目决策提供科学分析依据。

一般从以下几个方面进行项目的社会效益评价。

项目的文化与技术的可接受性:

分析项目是否适应企业的需求，企业在文化与技术上能否接受此项目，有无更好的成本低、效益高、更易为企业接受的方案等。通过这些分析，可明确项目是否使员工的工作效率和质量得到提高，系统是否成为组织核心竞争力的重要组成部分，是否成为组织实现战略目标、获得竞争优势的工具。

项目的参与水平:

分析企业各类人员对项目的态度、要求、可能的参与水平。分析新建系统是否能使管理创新，形成信息时代的经营管理，新建系统是否使组织体系发生改变。

项目的持续性:

主要是通过分析研究项目与社会的各种适应性，存在的社会风险等问题，研究项目能否持续实施,并持续发挥效益。

(3)项目数据总结

对项目的资料数据进行总结，形成对今后新项目进行估算和管理的依据。资料数据包括项目中各任务的进度、规模和工作量数据，资源分配利用数据，软件变更数据等。

(4)项目问题总结

重新思考项目实施过程中出现的问题，重新评估项目管理流程的有效性，寻找问题发生的根源，并把分析结果反馈给高层管理者。总结项目中关键的成功因素，考虑是否将这些成功经验应用到组织级的管理,供今后项目实施时采用。

项目后评价的实施项目后评价的工作程序如下:

步骤一:成立后评价小组、制定评价计划。

步骤二:设计调查方案、聘请有关专家。

步骤三:阅读文件、收集资料。

步骤四:开展调查、了解情况。

步骤五:分析资料、形成报告。

步骤六:提交后评价报告、反馈信息。

项目后评价报告的编写要真实反映情况，客观分析问题，认真总结经验。为了让更多的组织和个人受益，评价报告的文字要求准确、清晰、简练，少用或不用过分专业化的词汇。评价结论要与未来的规划和政策的制定联系起来。为了提高信息反馈速度和反馈效果，让项目的经验教训在更大的范围内起作用，在编写评价报告的同时，还必须编写并分送评价报告摘要。

项目后评价报告（也称项目总结报告）是反馈经验教训的主要文件形式，评价报告的编写需要有相对固定的内容格式，但被评价的项目类型不同，评价报告所要求书写的内容和格式也不完全一致。

合同收尾

合同收尾就是结束合同并结清账目，解决所有遗留问题。

合同收尾过程支持项目收尾过程，因为两者都涉及验证所有工作和可交付成果是否可以接受的工作。合同收尾过程也包括诸如对记录进行更新以反映最终结果，将更新后的记录进行归档供将来项目使用的管理活动。合同收尾考虑了项目或项目阶段适用的每项合同。

在多阶段项目中，合同条款可能仅适用于项目的某个特定阶段。在这些情况下，合同收尾过程只对该项目阶段适用的合同进行收尾。在合同收尾后，未解决的争议可能需进入诉讼程序。合同条款可规定合同收尾的具体程序。

合同提前终止是合同收尾的一项特例，可因双方的协商一致产生或因一方违约产生。双方在提前终止情况下的责任和权利在合同的终止条款中规定。依据这些合同条款，买方可在一定条件下，有权终止整个合同或部分项目。但是，基于这些合同条款和条件，买方可能需要就此对卖方的准备工作进行赔偿，并就与被终止部分相关的已经完成和被验收的工作支付报酬。

合同收尾的依据包括采购管理计划、合同管理计划、合同文件和合同收尾程序。

合同收尾阶段常采用的一种方法是采购审计，采购审计就是对从采购规划到合同管理的整个采购过程进行系统的审查，其目的是找出可供本项目其他采购合同或组织内其他项目借鉴的成功与失败的经验。

合同收尾过程的成果包括以下几个方面:

(1)合同收尾

买方通过其授权的合同管理员向卖方发出合同已经完成的正式书面通知。合同条款中一般规定合同正式收尾的要求并将其包括在合同管理计划中。

(2)组织过程资产

合同文档。一套完整的编有索引的合同文件（包括已收尾的合同)，并将其纳人项目最终档案之中。

可交付成果验收。买方通过其授权的合同管理员向卖方发出可交付成果被验收或被拒收的正式书面通知。合同条款中一般规定可交付成果的正式验收要求，以及如何解决不符合要求的可交付成果的程序。

经验教训记录。进行经验教训分析并提出过程改进建议,以供将来的采购规划和实施过程借鉴。