系统分析师学习笔记（二十一）

项目管理

项目开发计划

项目的生命周期可划分为四个基本阶段，分别是概念阶段（定义阶段）、开发阶段、实施阶段和结束阶段（收尾阶段）。

项目开发计划概述

1.项目开发计划的目的和作用

（1）计划是促使管理者展望未来，预见未来可能发生的问题，制订适当的对策，来减少实现目标过程中的不确定性。通过项目开发计划确定并描述为完成项目目标所需的各项任务范围，落实责任体系，并制订各项任务的时间表，阐明每项任务必需的人力、物力、财力和确定预算。保证项目的顺利实施和目标的实现。
（2）计划是实施的依据和指南。通过科学的组织和安排，可以保证有秩序地实施项目。通过计划能合理、科学地协调各种资源之间的关系，能充分利用时间和空间，提高资源利用率，从而提高项目的整体效益。同时，项目开发计划确定了项目实施工作的规范，经批准后就作为项目实施工作的指导性文件。
（3）确定项目团队各成员、各项工作的责任范围和地位，以及相应的职权，以便按要求去指导和控制项目工作，减少风险。
（4）促进项目团队成员、项目委托人和管理部门之间的交流与沟通，增加项目干系人的满意度，并使项目各工作协调一致。
（5）使项目团队成员明确自己的奋斗目标、实现目标的方法、途径及期限，并确保以时间、成本和其他资源需求的最小化实现项目目标。

2.项目开发计划的内容

（1）工作计划。也称为实施计划，是为保证项目顺利开展，围绕项目目标的最终实现而制订的实施方案。工作计划主要说明采取什么方法组织实施项目，研究如何最佳地利用资源，用尽可能少的资源获取最佳效益。具体包括工作细则、工作检查及相应措施等。工作计划也需要时间、物资、技术资源，必须反映到项目总计划中去。
（2）人员组织计划。表明工作分解结构图中的各项工作任务应该由谁来承担，以及各项工作间的关系如何。其表达形式主要有框图式、职责分工说明式和混合式三种。
（3）设备采购和资源供应计划。在项目管理过程中，多数的项目都会涉及到设备的采购、订货等供应问题。设备采购问题会直接影响到项目的质量和成本。如果是一个大型项目，由于不仅需要设备的及时供应，还有许多项目建设所需的材料、半成品、物件等资源的供应问题。因此，预先安排一个切实可行的资源供应计划，将会直接关系到项目的工期和成本。
（4）配置管理计划。由于信息系统项目的特点，在项目实施过程中，计划与实际不符的情况是经常发生的，因此，配置管理是一项十分重要的工作。配置管理计划通常要涉及到项目对配置管理的要求，实施配置管理的责任人、责任组织及其职责，开展的配置管理活动、方法和工具等。
（5）进度安排计划。根据实际条件和合同要求，以拟开发项目的交付使用时间为目标，按照合理的顺序安排实施日程。其实质是把各活动的时间估计值反映在逻辑关系图上，通过调整，使得整个项目能在工期和预算允许的范围内合理地安排任务。进度安排计划也是资源供应计划编制的依据，如果进度安排计划不合理，将导致人力、物力使用的不均衡，影响项目的实施。
（6）成本投资计划。包括各层次项目单元计划成本、时间-计划成本曲线和时间-累计计划成本曲线、现金流量（包括支付计划和收入计划）、资金筹集（贷款）计划等。
（7）质量保证计划。包括识别与项目相关的质量标准，以及确定如何满足这些标准。由识别相关的质量标准开始，通过参照或者依据实施项目组织的质量策略、项目的范围说明书、产品说明书等作为质量保证计划的依据，识别出项目相关的所有质量标准而达到或者超过项目的客户和其他项目干系人的期望和要求。一般来说，项目质量保证计划应该包括编制依据、质量宗旨与质量目标、质量责任与人员分工、项目的各个过程及其依据的标准、质量控制的方法与重点、验收标准等内容。
（8）风险管理计划。描述如何为项目处理和执行风险管理活动。在风险管理计划中，需要定义风险管理活动、风险级别、风险类型等内容。
（9）文档编制计划。由一些能保证项目顺利完成的文件管理方案构成，需要阐明文件控制方式、细则，负责建立并维护好项目文件，以供项目组成员在项目实施期间使用。包括文件控制的人力组织和控制所需的人员、资源数量。
（10）支持计划。项目管理有众多的支持手段，主要有软件工具支持、培训支持和行政支持，还有项目考评、文件、批准或签署、系统测试、安装等支持方式。

3.项目开发计划的监督和控制
项目监督和控制的手段主要是通过在预定的里程碑处（或项目进度表、工作分解结构中的控制级别），将实际的工作产品和任务属性、工作量、成本，以及进度与计划进行对比来确定进展情况。适当的可视性使得项目与计划发生重要的偏差时能够及时采取纠正措施。重要的偏差是指如果不解决就会妨碍项目达成其目的的偏差。

项目控制可采取正规和非正规两种方式。正规控制通过定期的和不定期的进展情况汇报和检查，以及项目进展报告进行。根据项目进展报告，与会者讨论项目遇到的问题，找出和分析问题的原因，研究和确定纠正、预防的措施，决定应当采取的行动；非正规则是项目经理频繁地到项目管理现场，与项目团队成员交流，了解情况，及时解决问题。

根据控制时间的先后，项目控制可分为事前控制、事中控制和事后控制。根据控制对象的不同，项目控制可分为直接控制和间接控制。这有两个方面的含义，一个方面是指，直接控制着眼于产生偏差的根源，而间接控制着眼于偏差本身。

项目开发计划的编制

项目开发计划是对开发过程中承担各项工作的人员，预计的进度，所需的经费，以及所需计算机软硬件资源等方面的问题做出安排的重要文档，是项目管理与监控的基本依据。

1.编写指南
一般来说，项目开发计划应该包括以下几个部分的内容：

（1）引言。包括项目开发计划的编写目的、背景，用到的专门术语的定义和外文首字母组词的原词组，以及参考资料等。
（2）项目概述。对项目进行一个概要性描述，以使团队内每个成员都对项目有一个总体性的了解。
（3）实施计划。对项目的实施进行详细的安排与计划。
（4）支持条件。列举项目开发所需要的各种配套的条件和设施，其中主要包括计算机软硬件和专用设备资源、用户所需承担的配合工作、外单位提供的条件等。
（5）专题计划要点。对于项目开发中的配套过程进行计划，通常包括分合同计划、开发人员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等。其编写的详略程度需要根据项目的规模决定，针对较大的项目可以考虑将其中的一些内容作为专项计划。

2.编制过程
项目开发计划的编制是一个逐渐求精的过程。通常在项目的可行性分析之后，项目开发计划的初稿就应该形成，这时的计划应该是粗略的，只是针对WBS中的较高层进行初步的进度估算、资源安排。得出来的各种计划值应该是一个区间估计值，例如，3～5人月，而不应该是一个精确值。随着项目的开展，开发计划需要得到逐步细化。每一次迭代，就会将工作任务切出一个小块，然后对这个小块进行相对精确的估算。并且在执行的过程中，根据实际的进度进行动态调整。

范围管理

范围管理就是要确定项目的边界，也就是说，要确定哪些工作是项目应该做的，哪些工作不应该包括在项目中。

范围计划的编制

在信息系统项目中，实际上存在两个相互关联的范围，分别是产品范围和工作范围（项目范围）。产品范围是指产品（或服务）所应该包含的功能，工作范围是指为了能够交付项目所必须要做的工作。一般而言，范围管理计划应包括如下内容：

（1）根据项目初步范围说明书编制详细项目范围说明书的过程；
（2）能够根据详细的项目范围说明书制作WBS，并确定如何维持与批准该WBS的过程；
（3）规定如何正式核实与验收项目已完成可交付成果的过程；
（4）控制详细项目范围说明书变更请求处理方式的过程，该过程与整体变更控制过程有直接联系。

创建工作分解结构

WBS把项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目，子项目需要继续分解为工作包。持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和就是项目的所有工作范围。

1.目的和用途

（1）明确和准确说明项目范围，项目组成员能够清楚地理解任务的性质和需要努力的方向。
（2）为各独立单元分派人员，规定这些人员的相应职责，可以确定完成项目所需要的技术和人力资源。
（3）针对各独立单元，进行时间、费用和资源需求量的估算，提高估算的准确性。
（4）为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度测量和控制的基准。
（5）将项目工作与项目的财务账目联系起来。
（6）清楚地定义项目的边界，便于划分和分派责任，自上而下将项目目标落实到具体的工作上，并将这些工作交给项目内外的个人或组织去完成。
（7）确定工作内容和工作顺序。可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际进展情况进行调节和控制。
（8）估计项目整体和全过程的费用。
（9）有助于防止需求蔓延。当用户或其他项目干系人试图为项目增加功能时，在WBS中增加相应工作的同时，也就能够很容易地让他们理解，相关费用和进度必须也要做相应的改变。

2.分层结构
WBS是面向可交付物的项目元素的层次分解，它组织并定义了整个项目范围。当一个项目的WBS分解完成后，项目相关人员对完成的WBS应该给予确认，并对此达成共识。然后，才能据此进行时间和成本的估算。

范围确认和控制

1.范围确认
范围确认主要是确认项目的可交付成果是否满足项目干系人的要求。把项目的可交付成果列表提交给项目干系人，同时，也应该展示项目的进度安排。项目干系人进行范围确认时，要检查：

（1）可交付成果是否是确定的、可核实的。
（2）每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可。
（3）是否有明确的质量标准，也就是说，可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确的联系。
（4）审核和承诺是否有清晰的表达。项目投资人必须正式地同意项目的边界，项目完成的产品（或服务），以及项目相关的可交付成果。项目组必须清楚地了解可交付成果是什么。所有这些表达必须清晰，并取得一致同意。
（5）项目范围是否覆盖了需要完成的产品（或服务）进行的所有活动，有没有遗漏或者错误。
（6）项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

2.范围控制
项目范围定义了项目应该做的和不应该做的，那么对于范围变更，就不能随意进行。对于用户不断提出的新要求和建议，项目组应该坚持“决不让步，除非交换”的原则，尽可能减少范围蔓延的可能性，所有的范围变更必须在项目的工期、费用或者质量要求上得到相应的变更。

所有的变更必须记载，范围控制必须能够对造成范围变更的因素施加影响，估算对项目的资金、进度和风险等影响，以保证变化是有利的。同时，需要判断范围变更是否发生，如果已经发生，则就要对变更进行管理。

对范围变更进行控制时，要以WBS、项目进展报告、变更请求和范围管理计划为依据。对于有合同的项目而言，项目范围变更必须遵守项目合同的相关条款。进行范围变更控制必须经过范围变更控制系统。

进度管理

进度管理就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现
工期目标。具体来说，包括以下过程：

（1）活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
（2）活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
（3）活动资源估算：估算完成各项活动所需要的资源类型和数量。
（4）活动历时估算：估算完成各项活动所需要的具体时间。
（5）进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素，制订项目进度计划。
（6）进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。

活动排序

1.前导图法
前导图法（Precedence Diagramming Method，PDM）也称为单代号网络图法（Active on the Node，AON），它用方格或矩形（节点）表示活动，用箭线表示依赖关系。在PDM中，每项活动都有唯一的活动号，注明了预计工期。每个节点的活动有最早开始时间（Early Start，ES）、最迟开始时间（Late Start，LS）、最早结束时间（Early Finish，EF）和最迟结束时间（Late Finish，LF）。

PDM包括四种依赖关系或先后关系：

（1）完成对开始（FS）：后一活动的开始要等到前一活动的完成。
（2）完成对完成（FF）：后一活动的完成要等到前一活动的完成。
（3）开始对开始（SS）：后一活动的开始要等到前一活动的开始。
（4）开始对完成（SF）：后一活动的完成要等到前一活动的开始。

在PDM中，FS是最常用的逻辑关系，而SF关系很少用。在绘制PDM时，需要遵守下列规则：

（1）必须正确表达项目中活动之间的逻辑关系，图中不能出现回路。
（2）图中不能出现双向箭头或无箭头的连线，不能出现无箭尾节点的箭线或无箭头节点的箭线。
（3）图中只能有一个起始节点和一个终止节点。当图中出现多项无内向箭线的活动或多项无外向箭线的活动时，应在PDM的开始或者结束处设置一项虚活动（不占用任何资源，只表示逻辑关系的活动），作为该PDM的起始节点或终止节点。

2.箭线图法
箭线图法（Arrow Diagramming Method，ADM）也称为双代号网络图法（Active On the Arrow，AOA），它用节点表示事件，用箭线表示活动，并在节点处将其连接起来，以表示依赖关系。在ADM中，给每个事件而不是每项活动指定一个唯一的号码。活动的开始（箭尾）事件叫做该活动的紧前事件（precede event），活动的结束（箭头）事件叫做该活动的紧后事件（successor event）。在ADM中，有三个基本原则：

（1）每一个事件必须有唯一的一个代号，即ADM中不会有相同的代号。
（2）任何两项活动紧前事件和紧后事件代号至少有一个不相同，节点序号沿箭线方向越来越大。
（3）流入（流出）同一事件的活动，均有共同的后继活动（或先行活动）。

3.确定依赖关系
在项目进度管理中，通常使用3种依赖关系来进行活动排序，分别是强制性依赖关系、可自由处理的依赖关系和外部依赖关系。

（1）强制性依赖关系。也称为硬逻辑关系、工艺关系。这是活动固有的依赖关系，这种关系是活动之间本身存在的、无法改变的逻辑关系。
（2）可自由处理的依赖关系。也称为软逻辑关系、组织关系、首选逻辑关系、优先逻辑关系，这是人为确定的一种先后关系。
（3）外部依赖关系。这种关系涉及到项目与非项目活动之间的关系。

逻辑关系的表达可以分为平行、顺序和搭接3种形式。

（1）平行关系。也称为并行关系，两项活动同时开始即为平行关系。例如，在图20-3中，活动A和B是平行关系。
（2）顺序关系。相邻两项活动先后进行即为顺序关系。如前一活动完成后，后一活动马上开始则为紧连顺序关系。如后一活动在前一活动完成后隔一段时间才开始则为间隔顺序关系。
（3）搭接关系。两项活动只有一段时间是平行进行的则称为搭接关系。

活动资源估算

活动资源估算包括决定需要什么资源（例如，人员、工具、设备等）和资源的数量，以及何时使用资源来有效地执行项目活动。它必须和成本估算相结合。

进行资源估算时，必须要对资源的可用性进行评价，否则，将只能是纸上谈兵。包括考虑资源地理位置的改变，以及资源数量和级别在项目进行过程中可能会改变。

进行活动资源估算的方法主要有专家判断法、替换方案的确定、公开的估算数据、估算软件和自下而上的估算。

（1）专家判断法。专家判断法通常是由项目成本管理专家根据以往类似项目的经验和对本项目的判断，经过周密思考，进行合理预测，从而估算出项目资源。进行预测的专家可以是任何具有专门知识或经过特别培训的组织和个人。
（2）替换方案确定。资源估算是为了给项目预算明确空间，为早期的资源筹备提供数据，如果某项活动存在替代方案，或提供的资源有替代支持可能，则需要明确声明。
（3）公开的估算数据。有些公司会定期地公开一些生产率或人工费率数据，其中包括很多国家和地区的劳动力交易、材料和设备信息。这些数据可以作为资源估算的参考。
（4）估算软件。依靠软件的强大功能，可以定义资源可用性、费率，以及不同的资源日历。
（5）自下而上的估算。把复杂的活动分解为更小的工作，以便于资源估算。将每项工作所需要的资源估算出来，然后汇总即是整个活动所需要的资源数量。

活动历时估算

活动历时估算直接关系到各项具体活动、各项工作网络时间和完成整个项目所需要总体时间的估算。活动历时估算通常同时要考虑间隔时间。在估算时，要在综合考虑各种资源、人力、物力、财力的情况下，把项目中各工作分别进行时间估计。

1.软件项目的工作量
软件项目通常用LOC（Line Of Code，代码行）来衡量项目规模，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。

2.软件生产率
从理论上来说，一项软件开发任务由一个人单独开发，生产率最高。但是，在实际开发中，这是不现实的。稍大的软件开发，都必须组织一个开发小组。软件开发组的规模不能太大，人数不能太多，一般在2～8人左右为宜。

3.人员和时间的关系
Putnam模型假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程式”，把已交付的源代码行数与工量和开发时间联系起来，用下面的公式表示：

其中，t是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以LOC计），C是技术状态常数，它反映出“妨碍程序员开发的限制”，并因开发环境而异，通常取值在2000～28000之间。

4.德尔菲法
德尔菲法对减少数据中人为的偏见、防止任何人对结果不适当地产生过大的影响尤其有用，其具体实施步骤如下：

（1）组织者发给每位专家一份软件系统的规格说明书（略去名称和单位） 和一张记录估算值的表格，请他们进行估算。
（2）专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：
ai：该软件可能的最小规模（最少源代码行数）。
mi：该软件最可能的规模（最可能的源代码行数）。
bi：该软件可能的最大规模（最多源代码行数）。
无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论，但可以向组织者提问。
（3）组织者对专家们填在表格中的数据进行整理，计算各位专家的估算期望值Ei，并综合各位专家估算值的期望中值E（这种方法通常也称为三点估算法）。
（4）将各位专家第一次判断意见汇总，列成图表，进行对比，再分发给各位专家，让专家比较自己与他人的不同意见，修改自己的估算和判断。然后比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。
（5）上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组讨论。在向专家进行反馈的时候，只给出各种意见，但并不说明发表各种意见的专家的具体姓名。
（6）通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。

5.类比估算法
类比估算法的基本步骤是：

（1）整理出项目功能列表和实现每个功能的代码行。
（2）标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方。
（3）通过步骤（1）和（2）得出各个功能的估计值。
（4）产生规模估计。

6.功能点估算法
功能点（Function Point，FP）估算是在需求分析阶段基于系统功能的一种规模估计方法。FP估算并不是集中于功能上，而是通过研究初始应用需求，确定各种输入、输出、数据文件、查询和外部接口，以及一些复杂度调整值。通常的步骤是：

（1）计算输入、输出、查询、数据文件与接口的数目。
（2）将这些数据进行加权乘。
（3）根据对复杂度的判断，总数可以用复杂性调节因子进行调整。

7.COCOMO模型
COCOMO模型（COnstructive COst MOdel）是一种结构型估算模型，是一种精确、易于使用的估算方法。在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种，分别是组织型、嵌入型和半独立型。COCOMO模型按其详细程度分成3级，分别是基本COCOMO模型、中间COCOMO模型和详细COCOMO模型。

（1）基本COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数为自变量的（经验）函数来计算软件开发工作量。
（2）中间COCOMO模型。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
（3）详细COCOMO模型。详细COCOMO模型包括中间COCOMO模型的所有特性，但用各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（例如，分析、设计等）的影响。

进度控制

项目进度控制就是将实际进度与计划进度进行比较并分析结果，以保持项目工期不变，保证项目质量和所耗费用最少为目标，做出有效对策，进行项目进度更新。

1.分析进度偏差的影响
当出现进度偏差时，需要分析该偏差对后续活动及总工期的影响。主要从以下几方面进行分析：

（1）分析产生进度偏差的活动是否为关键活动。若出现偏差的活动是关键活动，则无论其偏差大小，对后续活动及总工期都会产生影响，必须进行进度计划更新；若出现偏差的活动为非关键活动，则需根据偏差值与总时差和自由时差（本活动总时差-紧后活动总时差的最小值）的大小关系，确定其对后续活动和总工期的影响程度。
（2）分析进度偏差是否大于总时差。如果活动的进度偏差大于总时差，则必将影响后续活动和总工期，应采取相应的调整措施；若活动的进度偏差小于或等于该活动的总时差，表明对总工期无影响；但其对后续活动的影响，需要将其偏差与其自由时差相比较才能做出判断。
（3）分析进度偏差是否大于自由时差。如果活动的进度偏差大于该活动的自由时差，则会对后续活动产生影响，如何调整，应根据后续活动允许影响的程度而定；若活动的进度偏差小于或等于该活动的自由时差，则对后续活动无影响，进度计划可不进行调整更新。

2.项目进度计划的调整
项目进度计划的调整往往是一个持续反复的过程，一般分几种情况：

（1）关键活动的调整。对于关键路径，由于其中任一活动持续时间的缩短或延长都会对整个项目工期产生影响。因此，关键活动的调整是项目进度更新的重点。第一种情况：关键活动的实际进度较计划进度提前时的调整方法。若仅要求按计划工期执行，则可利用该机会降低资源强度及费用。实现的方法是，选择后续关键活动中资源消耗量大或直接费用高的予以适当延长，延长的时间不应超过已完成的关键活动提前的量；若要求缩短工期，则应将计划的未完成部分作为一个新的计划，重新计算与调整，按新的计划执行，并保证新的关键活动按新计算的时间完成；第二种情况：关键活动的实际进度较计划进度落后时的调整方法。调整的目标就是采取措施将耽误的时间补回来，保证项目按期完成。调整的方法主要是缩短后续关键活动的持续时间。这种方法是指在原计划的基础上，采取组织措施或技术措施缩短后续工作的持续时间以弥补时间损失，确保总工期不延长。
（2）非关键活动的调整。当非关键路径上某些工作的持续时间延长，但不超过其时差范围时，则不会影响项目工期，进度计划不必调整。为了更充分地利用资源，降低成本，必要时可对非关键活动的时差做适当调整，但不得超出总时差，且每次调整均需进行时间参数计算，以观察每次调整对计划的影响。
（3）增减工作项目。由于编制计划时考虑不周，或因某些原因需要增加或取消某些工作，则需重新调整网络计划，计算网络参数。由于增减工作项目不应影响原计划总的逻辑关系，以便使原计划得以实施。因此，增减工作项目，只能改变局部的逻辑关系。
（4）资源调整。若资源供应发生异常时，应进行资源调整。资源供应发生异常是指因供应满足不了需要，例如，资源强度降低或中断，影响到计划工期的实现。资源调整的前提是保证工期不变或使工期更加合理。资源调整的方法是进行资源优化，提高资源利用率。

成本管理

项目成本管理包括成本估算、成本预算和成本控制三个过程。成本估算是对完成项目所需成本的估计和计划，是项目计划中的一个重要的、关键的、敏感的部分；成本预算是把估算的总成本分配到项目的各个工作包，建立成本基准计划以衡量项目绩效；成本控制保证各项工作在各自的预算范围内进行。

成本估算

1.自顶向下的估算
自顶向下估算的主要思想是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所消耗的总成本（或总工作量），来推算将要开发的软件的总成本（或总工作量），然后按比例将它分配到各开发任务单元中去。

2.自底向上的估算
自底向上估算的主要思想是把系统进行细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到系统开发的总工作量。这是一种常见的估算方法。

3.差别估算法
差别估算法综合了自顶向下估算和自底向上估算的优点，其主要思想是把项目与过去已完成的项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法（例如，德尔菲法等）进行估算。

成本预算

成本预算的基本步骤如下：

（1）分摊项目总成本到WBS的各个工作包中，为每个工作包建立总预算成本。在将所有工作包的预算成本相加时，结果不能超过项目的总预算成本。
（2）将每个工作包分配得到的成本再二次分配到工作包所包含的各项活动上。
（3）确定各项成本预算支出的时间计划，以及每个时间点对应的累积预算成本，编制项目成本预算计划。

1.直接成本与间接成本
在进行成本预算时，除了要考虑项目的直接成本，还要考虑其间接成本和一些对成本有影响的其他因素，可能包括以下一些：

（1）非直接成本。包括租金、保险和其他管理费用。例如，如果项目中有些任务是项目组成员在项目期限内无法完成的，那么就可能需要进行项目的外包或者聘请专业的顾问；如果项目需要专业的工具或者设备，而又没有必要采购这些设备，那么采用租用的方式就必须付租金。
（2）隐没成本。隐没成本（沉没成本）是当前项目的以前尝试已经发生过的成本。例如，一个系统的上一次失败的产品花费了N元，那么这N元就是为同一个系统的下一个项目的隐没成本。考虑到已经投入了许多的成本，人们往往不再愿意继续投入，但是在项目选择时，隐没成本应该被忘记，不应该成为项目选择的理由。
（3）学习曲线。在信息系统项目中，如果采用了项目组成员未使用过的技术和方法，那么，在使用这些技术和方法的初期，项目组成员有一个学习的过程，许多时间和劳动投入到尝试和试验中。这些尝试和试验会增加项目的成本。同样，对于项目组从未从事的项目要比对原有项目的升级的成本高得多，也是由于项目组必须学习新行业的术语、原理和流程。
（4）项目完成的时限。一般来说，项目需要完成的时限越短，那么成本就越高，压缩信息系统的交付日期，不仅要支付项目组成员的加班费用，而且如果过于压缩进度，项目组可能在设计和测试上就会减少投入，项目的风险会提高。
（5）质量要求。显然，成本估算要根据产品质量要求的不同而不同。例如，登月火箭的控制软件和微波炉的控制软件不但完成的功能不同，而且质量要求也大相径庭，其成本估算自然有很大的差异。
（6）保留。保留是为风险和未预料的情况而准备的预留成本。遗憾的是，有时候管理层和客户会把保留成本进行削减。没有保留，将使项目的抗风险能力降低。

2.管理储备
管理储备是为范围和成本的潜在变化而预留的预算，它们是未知的，项目经理在使用之前必须得到批准。管理储备不是项目成本基线的一部分，但包含在项目的预算中。它们未被作为预算进行分配，因此，不是挣值分析的一部分。

3.零基准预算
零基准预算是指在项目预算中，以零作为基准，估计所有的工作任务的成本。

成本控制

项目成本控制是按照事先确定的成本基准计划，通过运用多种恰当的方法，对项目实施过程中所消耗费用的使用情况进行管理和控制，以确保项目的实际成本限制在项目成本预算范围内。在项目成本控制中，主要采用挣值分析方法。挣值分析是一种进度和成本测量技术，可用来估计和确定变更的程度和范围，因此，也称为偏差分析法。挣值分析通过测量和计算已完成工作的预算费用、已完成工作的实际费用和计划工作的预算费用，得到有关计划实施的进度和费用偏差，而达到判断项目预算和进度计划执行情况的目的。

软件配置管理

配置管理概述

配置管理是标识和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和变动要求，验
证配置项的完整性和正确性。并对下列工作进行技术和行动指导与监督的一套规范：

（1）对配置项的功能特性和物理特性进行标识和文件编制工作。
（2）控制这些特性的变动情况。
（3）记录并报告这些变动进行的处理和实现的状态。

1.配置管理过程

（1）编制软件配置管理计划。在项目启动时，项目经理首先要制订整个项目的开发计划，它是整个软件开发工作的基础。配置管理计划是项目开发计划的一部分。
（2）配置标识。确定哪些内容应该进入配置管理，形成配置项，并确定配置项如何命名，用哪些信息来描述配置项。配置标识是配置管理的基础性工作，是进行配置管理的前提。
（3）变更管理和配置控制。配置管理最重要的任务就是对（配置项的）变更加以控制和管理，其目的是对于复杂而无形的软件，防止在多次变更下失控，出现混乱。
（4）配置状态说明。配置状态说明也称为配置状态报告，其任务是有效地记录、报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
（5）配置审核。配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明，尽管对配置项做了标识，实现了变更控制和版本控制，但如果不做检查或验证，仍然会出现混乱。配置审核的实施是为了确保软件配置管理的有效性，体现配置管理的最根本要求，不允许出现任何混乱现象。
（6）版本控制和发行管理。在配置管理中，版本包括配置项的版本和配置的版本，这两种版本的标识应该各有特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分。另外，还需要对重要的版本做一些标识，例如，对纳入基线的配置项版本就应该做一个标识。

2.配置管理计划
配置管理计划应该包括以下几个部分的内容：

（1）引言。包括配置管理计划的标识、系统概述、文档概述、组织和职责、配置管理活动所需的各种资源等。
（2）引用文件。列出配置管理计划中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）管理。描述在各阶段中负责SCM的机构和任务，以及要进行的评审和检查工作，指出各阶段的产品应存放在哪一类配置库中；指出各机构的职责和它们之间的关系，描述相关的接口控制；规定实现SCM计划的主要里程碑；指明SCM适用的标准和规范，以及这些标准和规范要实现的程度。
（4）SCM活动。描述配置标识、配置控制、配置状态记录与报告、配置检查与评审等四个方面的SCM活动。
（5）工具、技术和方法。指明为支持特定项目的SCM所使用的软件工具、技术和方法，以及它们的目的，并在开发人员所有权的范围内描述其用法。
（6）对供货单位的控制。规定对供货单位进行控制的规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的SCM需求。
（7）记录的收集、维护和保存。规定要保存的SCM文档，以及用于汇总、保护和维护工程文档的方法和设施（其中包括要使用的后备设施），并说明要保存的期限。
（8）配置项和基线。根据企业的有关规范，对不同类型的配置项建立命名规则，列出识别到的所有配置项和所属的配置基线，并明确配置项的标识、作者（或负责人）和配置时间。描述配置项和基线变更、发布的流程，以及相应的批准权限。
（9）备份。说明配置库和配置管理库的备份方式、频率和责任人。
（10）日程表。列出SCM活动的日程表，并确保配置管理活动的日程表与项目开发计划、质量管理计划保持一致。
（11）注解。包含有助于理解配置管理计划的一般信息，例如，背景信息、词汇表、原理等。一部分应包含为理解配置管理计划需要的术语和定义，所有缩略词和它们在配置管理计划中的含义的字母序列表。
（12）附录。提供那些为便于维护配置管理计划而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。

配置标识

1.确定配置项

（1）识别配置项。可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码/模块、工具、接口描述等。
（2）配置项命名。确定了配置项后，还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构，树状结构上结点之间存在着层次的继承关系。
（3）配置项的描述。由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此，它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息（名字、描述、一组资源、实现）唯一地标识。配置项间的关系有整体和部分的关系及层次关系，也有关联关系。

2.基线
基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的（通过了正式的技术评审）阶段产品。如果把软件看做是系统的一个组成部分，以下3种基线是最受人们关注的，分别是功能基线、分配基线和产品基线。

3.建立配置管理系统
在配置管理中，要建立并维护配置管理系统和变更管理系统。建立配置管理系统的主要步骤如下：

（1）建立适用于多控制等级配置管理的管理机制。软件生存周期中不同时间所需的控制等级不同，不同的系统类型所需的控制等级也不同。
（2）存储和检索配置项。
（3）共享和转换配置项。
（4）存储和复原配置项的归档版本。
（5）存储、更新和检索配置管理记录。
（6）创建配置管理报告。
（7）保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文档的建档、从配置管理的差错状态下复原。
（8）权限分配。配置管理员为每个项目成员分配对配置库的操作权限。配置管理员的权限最高，一般项目成员可拥有添加、检入/检出（check in/check out）、下载的权限，但是不能有删除的权限。

4.配置库
配置库有三类：

（1）开发库。存放开发过程中需要保留的各种信息，供开发人员个人专用。开发库中的信息可能有较为频繁的修改，只要使用者认为有必要，无需对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统（开发者系统、开发系统、工作空间）。
（2）受控库。在开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的和人工可读的文档资料。应该对受控库内的信息的读写和修改加以控制。受控库也称为主库，对应配置管理系统中的主系统（受控系统）。
（3）产品库。在开发的产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。产品库内的信息也应加以控制。产品库也称为备份库，对应配置管理系统中的静态系统。

变更控制

变更是指在项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。变更产生的原因主要有以下几个方面：

（1）项目外部环境发生变化，例如，政府政策的变化等。
（2）项目总体设计、需求分析不够周密详细，有一定的错误或遗漏。
（3）新技术的出现，设计人员提出了新的设计方案或新的实现手段。
（4）建设单位由于机构重组等原因造成业务流程的变化。

1.变更控制系统
变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件、责任追踪，以及变更审批制度、人员和权限。

2.变更控制委员会
变更控制委员会（Change Control Board，CCB）也称为配置控制委员会（Configuration Control Board），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。

3.变更控制的流程

（1）变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
（2）变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
（3）变更决策。由CCB决定是否实施变更。
（4）变更实施。由管理者指定的工作人员在受控状态下实施变更。
（5）变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
（6）沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。

4.利用配置库实现变更控制
配置项可以有三种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于工作状态下（自由状态、草稿状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库，开始冻结，此时，开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。

版本控制

一般来说，版本控制的流程如下：

（1）创建配置项。
（2）修改处于工作状态的配置项。
（3）技术评审或领导审批。
（4）正式发布。
（5）变更，修改版本号。

配置审核

配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明，尽管对配置项做了标识，实践了变更控制和版本控制，但如果不做检查或验证仍然会出现混乱。这种验证包括：

（1）对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。
（2）配置标识的准则是否得到了遵循。
（3）变更控制规程是否已遵循，变更记录是否可供使用。
（4）在规格说明、软件产品和变更请求之间是否保持了可追溯性。

1.配置审核的时机和步骤
一般来说，应该选择以下几种情况实施配置审核：

（1）产品交付或是产品正式发行前。
（2）开发的阶段工作结束之后。
（3）在维护工作中，定期地进行。

配置审核的步骤如下：

（1）由项目经理决定何时进行配置审核工作。
（2）质量保证组或项目组的配置管理组指定该项目的配置审核人员。
（3）项目经理和配置审核员决定审核范围。
（4）配置审核员准备配置审核检查单。
（5）配置审核员审核文档和记录，审核活动可能涉及到项目范围、配置项的检入/检出、评审记录、配置项的变更历史、测试记录、文件的命名、变更请求、版本的编号等。
（6）配置审核员在审核中发现不符合现象，并作记录。
（7）由项目经理负责消除不符合现象。
（8）配置审核员验证所有发现的不符合现象，确保已得到解决。

2.配置审核与正式技术评审
配置审核的目的就是要证实整个项目生存期中各项产品在技术上和管理上的完整性。同时，还要确保所有文档的内容变动不超出当初确定的软件需求范围。使得配置具有良好的可跟踪性。

正式的技术评审着重检查已完成修改的配置项的技术正确性，评审者评价配置项，决定它与其他配置项的一致性，是否有遗漏或可能引起的副作用。正式技术评审应针对所有的变更进行。

配置状态报告

配置状态报告的内容一般包括以下各项：

（1）各变更请求概要：变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期。
（2）基线库状态。
（3）发行信息。
（4）备份信息。
（5）配置管理工具状态。
（6）配置管理培训状态。

质量管理

软件质量模型

1.内部和外部质量的质量模型

2.使用质量的质量模型
使用质量是指软件产品使指定用户在特定的使用环境下达到满足有效性、生产率、安全性和满意度要求的特定目标的能力。

3.McCall质量模型

4.质量特性度量
软件质量特性度量有两类，分别是预测型和验收型。预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量的比较精确的估算值。验收度量是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它是对开发过程中的预测进行评价。

质量管理计划

1.计划的内容

（1）引言。包括质量管理计划的标识、系统概述、文档概述、组织和职责、资源等方面的内容。
（2）引用文件。列出质量管理计划引用的所有文档的编号、标题、修改版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）管理。描述负责质量管理（质量保证、质量控制）的机构、任务及其有关的职责。
（4）文档。列出在软件的开发、验证与确认，以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则。
（5）标准、规程和约定。列出软件开发过程中要用到的标准、规程和约定，并列出监督和保证执行的措施。
（6）评审和检查。规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。至少要进行下列各项评审和检查工作：软件需求规格评审、系统/子系统设计评审、软件设计评审、软件验证与确认计划评审、功能检查、物理检查、综合检查、管理评审。
（7）项目计划阶段的质量管理活动。描述质量管理负责人参与制订项目开发计划和配置管理计划的活动，以及它们三者之间的关系。
（8）评审和审核。包括过程的评审、工作产品的评审和不符合问题的解决。
（9）软件配置管理。必须编制有关软件配置管理的条款，或单独制订文档。
（10）工具、技术和方法。指明用以支持软件质量管理工作的工具、技术和方法，描述它们的用途。
（11）媒体控制。指出保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化。
（12）对供货单位的控制。规定对供货单位进行控制的规程，从而保证项目承建单位从软件销售单位购买的、其他开发单位（或子开发单位）开发的或从开发单位（或子开发单位）现存软件库中选用的软件能满足规定的需求。
（13）记录的收集、维护和保存。指明需要保存的软件质量管理活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限。
（14）日程表。列出软件质量管理活动的日程表，并确保质量管理的日程表与项目开发计划、配置管理计划保持一致。
（15）注解。包含有助于理解质量管理计划的一般信息，例如，背景信息、词汇表、原理等。一部分应包含为理解质量管理计划需要的术语和定义，所有缩略词和它们在质量管理计划中的含义的字母序列表。
（16）附录。提供那些为便于维护质量管理计划而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。\

2.PDCA循环

（1）P（Plan）：计划，确定方针和目标，确定活动计划。
（2）D（Do）：执行，实现计划中的内容。
（3）C（Check）：检查，总结执行计划的结果，注意效果，找出问题。
（4）A（Action）：行动，对总结检查的结果进行处理，成功的经验加以肯定并适当推广、标准化；失败的教训加以总结，以免重现，未解决的问题放到下一个PDCA循环。

质量保证与质量控制

1.质量保证

（1）制订SQA计划。SQA计划在制订项目计划时制订，由相关部门审定。它规定了软件开发小组和质量保证小组需要执行的质量保证活动。有关该计划的详细内容，请阅读20.7.2节。
（2）参与开发该软件项目的软件过程描述。软件开发小组为将要开展的工作选择软件过程，SQA小组则要评审过程说明，以保证该过程与企业政策、内部的软件标准、外界所制订的标准以及项目开发计划的其他部分相符。
（3）评审。评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA小组识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。
（4）审计。审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向项目负责人报告工作结果。
（5）记录并处理偏差。确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。
（6）报告。记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。

2.质量控制
质量控制指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何能够去除造成不合格结果的根源。质量控制应贯穿于项目的始终。项目管理层应当具备关于质量控制的必要统计知识，尤其是关于抽样与概率的知识，以便评估质量控制的输出。其中，项目管理层尤其应注意明确以下事项之间的区别：

（1）预防（保证过程中不出现错误）与检查（保证错误不落到顾客手中）。
（2）特殊抽样（结果合格或不合格）与变量抽样（按量度合格度的连续尺度衡量所得结果）。
（3）特殊原因（异常事件）与随机原因（正常过程差异）。
（4）许可的误差（在许可的误差规定范围内的结果可以接受）和控制范围（结果在控制范围之内，则过程处于控制之中）。

3.质量保证与质量控制的关系
质量保证一般是每隔一定时间（例如，每个阶段末）进行的，主要通过系统的质量审计和过程分析来保证项目的质量。质量控制是实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案，以消除产生质量问题的原因。一定时间内质量控制的结果也是质量保证的质量审计对象。质量保证的成果又可以指导下一阶段的质量工作，包括质量控制和质量改进。

人力资源管理

人力资源计划编制

1.层次结构图

2.分配责任矩阵

组建项目团队

1.内部谈判
项目经理需要进行谈判的对象包括：

（1）与职能经理谈判，以保证项目在规定期限内获得足以胜任的工作人员。
（2）与企业中其他项目管理团队谈判，以争取稀缺或特殊人才。

2.事先分派
在某些情况下，人员可能事先被分派到项目上。这种情况往往发生在项目是方案竞争的结果，而且事先已许诺具体人员指派是获胜方案的组成部分。或者是项目为企业内部服务项目，人员分派已在项目章程中就明确规定了。此时，项目经理“别无选择”，只能在已有人员的基础上，加强团队建设和管理，提高项目绩效。

3.外部招聘
在企业缺乏完成项目所需的内部人才时，就需要动用采购手段（招聘、雇佣、转包等）。

4.虚拟团队
虚拟项目是一种新的研发模式，它借助于计算机网络和通信技术，超越了地理空间的限制，加强了企业内、外部各种研发机构和资源的联系，促进了人力资源、开发设备、软件、硬件、知识等资源的优势互补和互利共享，在更大范围内实现了资源的优化组合，更经济地达到了企业的技术目标和市场目标。

项目团队建设

1.团队发展过程
项目团队从开始到终止，是一个不断成长和变化的过程，这个发展过程可以描述为四个时期，分别是形成期、震荡期、正规期、表现期。

2.团队建设理论

（1）需要层次理论。马斯洛（A.Maslow）首创了需要层次理论，该理论把人的需要分为五个层次，分别是生理上的需要、安全的需要、社交的需要、尊重的需要和自我实现的需要。
（2）激励保健理论。赫兹伯格（Hertz Berg）提出的激励保健理论（也称为双因素理论）认为引起人们工作动机的因素主要有两个，分别是保健因素和激励因素。
（3）X理论和Y理论。麦格雷戈（McGregor）提出的X理论和Y理论是管理学中关于人们工作源动力的理论。这是一对基于两种完全相反假设的理论，X理论认为人们有消极的工作源动力，而Y理论则认为人们有积极的工作源动力。

管理项目团队

1.资源负荷和资源平衡
资源负荷是指在特定的时间内现有的进度计划所需要的各种资源的数量。如果在特定的时间内分配给某项工作的资源超出了项目的可用资源，则称为资源超负荷。资源平衡是一种延迟项目任务来解决资源冲突问题的方法，是一种网络分析法，它将以资源管理因素为主进行项目进度决策。

2.绩效考核
项目的人力资源绩效考核的流程如下：

（1）项目经理根据人力资源部提供的数据、行情、历史经验、专家评定，确定人员按天计算基准工资、公司管理系数（例如，目前的行业管理系数为2.8），物资基准价格、服务的基准价格、劳动生产率基准，以组织制订项目的预算。
（2）人力资源部门制订各岗位考评标准。员工的绩效评价参考人一般为员工所在项目组的项目经理。
（3）根据各项目经理送报的项目出工表确定员工的工作量。
（4）结果应用。绩效考核结果与员工在公司的利益相挂钩，包括与年度绩效考核挂钩、与年终奖金和内部股票的发放挂钩、与技术任职资格和管理任职资格挂钩、为晋升、加薪、辞退等人力资源职能提供有力的证据。

沟通管理

1.把握项目沟通基本原则

（1）沟通内外有别。团队同一性和纪律性是对项目团队的基本要求。项目团队作为一个整体，对外意见要一致，一个团队要用一种声音说话。实际工作中，在客户面前出现项目团队成员表现出对项目信心不足、意见不统一、争吵等都是比较忌讳的情况。
（2）非正式的沟通有助于关系的融洽。在需求获取阶段，常常需要采用非正式沟通的方式，以与客户拉近距离。在私下的场合，人们的语言风格往往是非正规和随意的，反而能获得更多的信息。
（3）采用对方能接受的沟通风格。注意肢体语言、语态给对方的感受。沟通中需要传递一种合作和双赢的态度，使双方无论在问题的解决上还是在气氛上都达到“双赢”。
（4）沟通的升级原则。需要合理把握横向沟通和纵向沟通关系，以有利于项目问题的解决。“沟通四步骤”反映了沟通的升级原则：第一步，与对方沟通；第二步，与对方的上级沟通；第三步，与自己的上级沟通；第四步，自己的上级和对方的上级沟通。
（5）扫除沟通的障碍。职责定义不清、目标不明确、文档制度不健全、过多使用行话等都是沟通的障碍。必须进行良好的沟通管理，逐步消除这些障碍。

2.进行良好的冲突管理
良好的沟通技能是解决一切冲突的基础，解决冲突的五种基本策略如下：

（1）问题解决：利用问题解决的方法，允许受到影响的各方一起沟通，以消除他们之间的分歧。通过这种方法，团队成员直接正视问题，正视冲突，要求得到一种明确的结局。直接面对冲突是克服分歧、解决冲突的最积极的有效途径，也称为面对模式（Confrontation Mode）。
（2）妥协：项目经理利用妥协的方法解决冲突，他们讨价还价、寻求解决方法，使冲突双方能在一定程度上满意。协商并寻求冲突双方在一定程度上都满意的方法是该策略的实质，其主要特征是寻求一种折中方案。尤其在两个方案势均力敌，均分优劣时，妥协也许是较为恰当的解决方式，但这种方法不一定总是可行。
（3）圆滑：“求同存异”是该策略的本质，即尽力在冲突中强调意见一致的方面，最大可能地忽视差异。作为一种缓和或调停冲突的方式，并不利于问题的彻底解决。
（4）强迫：采用“非赢即输”的方法来解决冲突，通过牺牲别人的观点来推行自己的观点。认为在冲突中获胜要比勉强保持人际关系更加重要。这是一种积极解决冲突的方式。当然，有时也可能出现一种极端的情形，例如，用权力进行强制处理，可能会导致团队成员的怨恨，恶化工作的氛围。
（5）撤退：是指卷入冲突的某方从一个实际的或可能的不同意见中撤退或让步。这是最不令人满意的冲突处理模式。

3.召开高效的会议

（1）事先制订一个例会制度。在项目沟通计划里，确定例会的时间，参加人员范围及一般议程等。
（2）放弃可开可不开的会议。在决定召开一个会议之前，首先要明确会议是否必须举行，还是可以通过其他方式进行沟通。
（3）明确会议的目的和期望结果。不要召开没有目的的会议，每次会议都必须有一个期望取得的结果（解决方案）。
（4）发布会议通知。在会议通知中要明确会议目的、时间、地点、参加人员、会议议程和议题。有一种被广泛采用的决策方法是“广泛征求意见，少数人讨论，核心人员决策”。由于许多会议不需要项目团队全体人员参加，因此，需要根据会议的目的来确定参会人员的范围。事先应明确会议议程和讨论的问题，可以让参会人员提前做准备。
（5）在会议之前将会议资料发到参会人员。对于需要有背景资料支持的会议，应事先将资料发给参会人员，以提前阅读，直接在会上讨论，可以有效地节约会议时间。
（6）可以借助视频设备。对于有异地成员参加或者需要演示的场合，借用一些必要的视频设备，可以使会议达到更好的效果。
（7）明确会议规则。指定主持人，明确主持人的职责，主持人要对会议进行有效控制，并营建一个活跃的会议气氛。主持人要事先陈述基本规则，例如，明确每个人的发言时间，每次发言只有一个声音等。主持人根据会议议程的规定控制会议的节奏，保证每一个问题都得到讨论。
（8）会议后要总结，提炼结论。主持人在会后总结问题的讨论结果，重申有关决议，明确责任人和完成时间。
（9）会议要有纪要。如果将工作的结果、完成时间、责任人都记录在案，则有利于督促和检查工作的完成情况。
（10）做好会议的后勤保障。很多会议兼有联络感情的作用，因此，需要选择一个合适的地点，提供餐饮、娱乐和礼品，制订一个有张有弛的会议议程。对于有客户或合作伙伴参加的会议更要如此。

风险管理

风险管理的概念

1.风险的定义

（1）关心未来：风险是否会导致项目失败?
（2）关心变化：在用户需求、开发技术、目标机器、以及所有其他与项目及工作和全面完成有关的实体中会发生什么样的变化?
（3）关心选择：应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求?

2.风险的特点
风险具有两个基本属性，分别是随机性和相对性。随机性是指风险事件的发生及其后果都具有偶然性；相对性是指风险总是相对项目活动主体而言的，同样的风险对于不同的主体有不同的影响。另外，项目风险还具有以下特点：

（1）风险存在的客观性和普遍性。风险不以人的意志为转移，并超越人们主观意识的客观存在，而且在项目的全生命周期内，风险是无处不在、无时没有的。人们只能在有限的空间和时间内改变风险存在和发生的条件，降低其发生的概率，减少损失程度，而不能也不可能完全消除风险。（2）某一具体风险发生的偶然性和大量风险发生的必然性。任一具体风险的发生都是诸多风险因素和其他因素共同作用的结果，是一种随机现象。个别风险事件的发生是偶然的、杂乱无章的，但对大量风险事件资料的观察和统计分析，发现其呈现出明显的运动规律，这就使人们有可能用概率统计方法和其他现代风险分析方法去计算风险发生的概率和损失程度。
（3）风险的可变性。在项目实施的过程中，各种风险在质和量上是可以变化的。随着项目的进行，有些风险得到控制并消除，有些风险会发生并得到处理，同时在项目的每一阶段都可能产生新的风险。
（4）风险的多样性和多层次性。大型项目周期长、规模大、涉及范围广、风险因素数量多且种类繁杂，致使其在生命周期内面临的风险多种多样。而且大量风险因素之间的内在关系错综复杂、各风险因素之间与外界交叉影响又使风险显示出多层次性。

风险的主要类型

风险管理的过程

1.风险管理计划编制
风险管理计划描述的是如何安排与实施项目风险管理，它是项目开发计划的从属计划。风险管理计划主要包括角色与职责、预算、风险类别、风险概率和影响的定义、汇报格式、风险跟踪等内容。

2.风险识别
风险识别包括确定风险的来源、风险产生的条件，描述风险特征和确定哪些风险事件有可能影响整个项目。风险识别应当在项目的生命周期自始至终定期进行。风险识别可分为三步进行：收集资料、估计项目风险形势、根据直接或间接的症状将潜在的风险识别出来。

3.风险定性分析

（1）风险可能性与影响分析。可能性评估需要根据风险管理计划中的定义，确定每一个风险的发生可能性，并记录下来。除了风险发生的可能性，还应当分析风险对项目的影响。风险影响分析应当全面，需要包括对时间、成本、范围等各方面的影响。其中不仅仅包括对项目的负面影响，还应当分析风险带来的机会。
（2）确定风险优先级。在确定了风险的可能性和影响后，需要进一步确定风险的优先级。风险优先级是一个综合的指标，优先级的高低反映了风险对项目的综合影响，也就是说，高优先级的风险最可能对项目造成严重的影响。
（3）确定风险类型。在进行风险定性分析的时候需要确定风险的类型，这一过程比较简单。根据风险管理计划中定义的风险类型列表，可以为分析中的风险找到合适的类型。如果经过分析后，发现在现有的风险类型列表中没有合适的定义，则可以修订风险管理计划，加入这个新的风险类型。

4.风险定量分析
风险定量分析是在不确定的情况下进行决策的一种量化方法，该过程主要采用灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟等技术。

5.风险应对计划编制
制订风险应对计划时有多种不同的策略，对于相同的风险，采用不同的应对策略会有不同的应对方法。通常可以把风险应对策略分为两种类型，分别是防范策略和响应策略。防范策略指的是在风险发生前，项目团队会采取一定的措施对风险进行防范；而响应策略则是在风险发生后采取的相应措施以降低风险带来的损失。

6.风险监控
风险监控是指跟踪已识别的风险，监测残余风险和识别新的风险，保证风险计划的执行，并评价这些计划对减轻风险的有效性。

信息（文档）管理

软件文档概述

1.文档的作用
在软件的生命周期中，清晰、正确、规范的软件文档将起到十分重要的作用，主要体现在以下几个方面：

（1）管理依据。在软件开发过程中，管理人员必须了解开发进度、存在的问题和预期目标。开发文档规定若干个检查点和进度表，使管理人员可以评定项目的进度。
（2）任务之间联系的凭证。大多数软件开发项目通常被分成若干项任务，并由不同的小组去完成。这些小组之间的互相联系是通过文档资料的复制、分发和引用而实现的。
（3）质量保证。SQA人员和评估系统性能的人员需要程序规格说明、测试和评估计划、测试系统用的各种标准，以及关于期望系统完成什么功能和系统怎样实现这些功能的清晰说明；必须制订测试计划和测试规程，并报告测试结果。
（4）培训与参考。使系统管理员、用户和其他项目干系人了解系统如何工作，以及为了达到他们各自的目的，如何使用系统。
（5）软件维护支持。维护人员需要系统的详细说明以帮助他们熟悉系统，找出并修正错误，改进系统以适应用户需求的变化或适应系统环境的变化。
（6）历史档案。软件文档能够为团队建立经验模型和可复用库，作为未来项目的一种资源。

2.文档计划
文档计划一般包括以下几方面的内容：

（1）列出应编制文档的目录。
（2）提示编制文档应参考的标准。
（3）指定文档管理员。
（4）提供编制文档所需要的条件，落实文档编写人员、所需经费以及编制工具等。
（5）明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，例如，评审、鉴定等。
（6）绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。

3.文档编制的要求
而高质量的文档包括以下几个主要特点：

（1）针对性：文档编制时需要根据面向的读者选择描述的手段，例如，针对开发人员，就应该尽量使用形式化语言，采用专业的术语和图表；针对用户，则应该尽量使用自然语言，使用用户领域的术语。
（2）无二义性：文档中的描述必须做到无二义性，否则，不同的人阅读相同的文档就会产生不同的理解，将带来很大的麻烦。
（3）易读性：文档应该尽量做到简明，尽量采用图表等直观的形式进行说明，以保证其清晰、易懂。
（4）完整性：每个文档都应该自成体系，不要过多的互相依赖，以免造成要理解一个问题，需要在多个文档中来回翻看的现象。
（5）灵活性：虽然针对每种文档，国家标准或行业经验中有许多可以借鉴的模块，但是在编制的时候不可形而上学地生搬硬套，应该根据项目的规模、复杂程度等因素进行适当和必要的剪裁，灵活处理。
（6）可追溯性：项目各开发阶段之间提供的文档必定存在着可追溯的关系。例如，某一项软件需求，必定在设计说明书、测试计划，甚至用户手册中有所体现。必要时应能做到跟踪追查。

4.文档的控制

（1）在项目团队中，应设置一位专职的文档管理员（或者项目秘书兼职管理）；在开发过程中，应该集中保管项目现有全部文档的两套主文档。这两套主文档的内容必须完全一致。其中有一套是可供出借的，另一套是绝对不能出借的，以免发生万一；可出借的主文档在出借时必须办理出借手续，归还时办理注销出借手续。
（2）提交给文档管理员的每份文档都必须具有编写人、审核人和批准人的签字。
（3）项目团队成员根据工作需要，可以持有一些个人文档，包括为完成他承担的任务所需要的文档，以及他在完成任务过程中所编制的文档；但这种个人文档必须是主文档的复制品，必须同主文档完全一致，若要修改，必须首先修改主文档。不同开发人员所拥有的个人文档通常是主文档的各种子集；所谓子集是指把主文档的各个部分根据承担不同任务的人员或部门的工作需要加以复制、组装而成的若干个文档的集合；文档管理员应该列出一份不同子集的分发对象的清单，按照清单及时把文档分发给有关人员或部门。
（4）一份文档如果已经被另一份新的文档所代替，则原文档应该被注销。文档管理员要随时整理主文档，及时反映出文档的变化和增加情况，及时分发文档。
（5）当项目的开发工作临近结束时，文档管理员应逐个收回每个团队成员的个人文档，并检查这些个人文档的内容；经验表明，这些个人文档往往可能比主文档更详细，或者与主文档的内容有所不同，必须认真监督有关人员进行修改，使主文档能真正反映实际的开发结果。

软件文档标准

1.GB/T 16680-1996
（1）开发文档。开发文档是描述软件开发过程（包括软件需求、软件设计、软件测试、软件质量保证）的一类文档，也包括软件的详细技术描述（例如，程序逻辑、程序间相互关系、数据格式和存储等）。开发文档是软件开发过程中包含的所有阶段之间的通信工具，描述开发小组的职责，用作检验点而允许管理人员评定开发进度，形成了维护人员所要求的基本软件文档，记录软件开发的历史。基本的开发文档有可行性研究和项目任务书、需求规格说明、功能规格说明、设计规格说明（包括程序和数据规格说明）、开发计划、软件集成和测试计划、质量保证计划/标准/进度、安全和测试信息。
（2）产品文档。产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。产品文档为使用和运行软件产品的任何人规定培训和参考信息，使得那些未参加本软件开发的程序员能够维护它，促进软件产品的市场流通或提高可接受性。产品文档主要用于用户、运行人员和维护人员，内容包括用于管理者的指南和资料、宣传资料和一般信息。基本的产品文档有培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。
（3）管理文档。管理文档建立在项目信息的基础上，包括开发过程的每个阶段的进度和进度变更的记录、软件变更情况的记录、相对于开发的判定记录、职责定义等。这种文档从管理的角度规定涉及软件生存的信息

文档的质量可以按文档的形式和列出的要求划分为四级。

（1）最底限度文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
（2）内部文档（2级文档）：可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
（3）工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
（4）正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质的程序需要4级文档。4级文档应遵守GB 8567的有关规定。

2.GB/T 8567-2006
GB/T 8567-2006规定了文档过程，包括软件标准的类型（含产品标准和过程标准）、源材料的准备、文档计划、文档开发、评审、文档编制要求、文档编制格式。

GB8567-2006把软件生存周期划分为六个阶段，并规定了每个阶段需要完成的文档：

数据需求说明

数据需求说明应该包括以下几个部分的内容：

（1）引言。包括数据需求说明的标识（包括标识号、标题、缩略词语、版本号、发行号）、系统概述、文档概述等方面的内容。
（2）引用文件。列出数据需求说明引用的所有文档的编号、标题、修改版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）数据的逻辑描述。根据数据的逻辑属性不同，可以分为动态数据和静态数据。
（4）数据的采集。这一部分具体展开说明数据如何获取。
（5）注解。包含有助于理解数据需求说明的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解数据需求说明需要的术语和定义，所有缩略词和它们在数据需求说明中的含义的字母序列表。
（6）附录。提供那些为便于维护数据需求说明而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。

软件测试计划

软件测试计划应该包括以下几个部分：

（1）引言。包括软件测试计划标识、系统概述、文档概述、与其他计划的关系、基线等。
（2）引用文件。列出软件测试计划中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）软件测试环境。描述每一项预计的测试现场的软件测试环境，可以引用项目开发计划中所描述的资源。对每一项软件测试环境，需要包括测试现场名称、软件项、硬件及固件项、其他材料；所有权种类、需方权利与许可证；安装、测试与控制；参与组织、人员；定向计划、要执行的测试。
（4）计划。描述计划测试的总范围并分条标识，并且描述软件测试计划适用的每个测试。包括总体设计（描述测试的策略和原则，包括测试类型和测试方法等信息）、计划执行的测试（分条描述计划测试的总范围，每一条的描述包括被测试项标识符和测试用例）。
（5）测试进度表。包含或引用指导实施软件测试计划中所标识测试的进度表。包括描述测试被安排的现场或指导测试的时间框架的列表或图表，以及每个测试现场的进度表。
（6）需求的可追踪性。包括从软件测试计划所标识的每个测试到它所涉及的配置项需求和软件系统需求的可追踪性，以及从软件测试计划所覆盖的每个配置项需求和软件系统需求到针对它的测试的可追踪性。
（7）评价。包括评价准则、数据处理和结论。
（8）注解。包含有助于理解软件测试计划的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解软件测试计划需要的术语和定义，所有缩略词和它们在软件测试计划中的含义的字母序列表。
（9）附录。提供那些为便于维护软件测试计划而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。

软件测试报告

软件测试报告应该包括以下几个部分的内容：

（1）引言。包括软件测试报告的标识（包括标识号、标题、缩略词语、版本号、发行号）、系统概述、文档概述等方面的内容。
（2）引用文件。列出软件测试报告引用的所有文档的编号、标题、修改版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）测试结果概述。包括对被测试软件的总体评估、测试环境的影响和改进建议三个部分。第一个部分根据报告中所展示的测试结果，提供对软件的总体评估。标识在测试中检测到的任何遗留的缺陷、限制或约束；第二个部分对测试环境与操作环境的差异进行评估，并分析这种差异对测试结果的影响；第三个部分对被测试软件的设计、操作或测试提供改进建议，应讨论每个建议及其对软件的影响。
（4）详细的测试结果。提供每个测试的详细结果，就每个结果，可分为以下几条叙述：测试的项目唯一标识符、测试结果小结、遇到的问题、与测试用例/过程的偏差（偏差的说明、偏差的理由、偏差对测试用例有效性的影响）。
（5）测试记录。尽可能以图表或附录形式给出一个软件测试报告所覆盖的测试事件的按年月顺序的记录。测试记录应该包括执行测试的日期、时间和地点；用于每个测试的软硬件配置；执行测试活动的人和见证者的身份。
（6）评价。包括经测试证实的软件能力、缺陷和限制，针对每项缺陷提出改进建议，给软件一个定性的最后结论，即开发是否达到预定目标，是否可以交付使用等。
（7）测试活动总结。总结主要的测试活动和事件。
（8）注解。包含有助于理解软件测试报告的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解软件测试报告需要的术语和定义，所有缩略词和它们在软件测试报告中的含义的字母序列表。
（9）附录。提供那些为便于维护软件测试报告而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。

技术报告

编制技术报告的主要目的是将项目开发中技术研究工作做一个总结性的汇报，以文档化的结果将其中的所得保存起来。通常包括以下几个部分：

（1）引言。对技术报告进行概要性的描述，说明技术报告的编写目的、项目背景，并且对其中所使用的专业术语、缩略语建立专门的词汇解释表。
（2）项目解决的技术问题。这一部分主要是针对项目中解决了的技术问题进行一个描述，通常可以分为两部分。第一个部分是项目的重要技术成果，也就是在项目中最重要的技术研究突破。应该对成果进行规范化描述；第二个部分是主要技术指标的说明。对于项目中各项技术指标，例如，稳定性、可靠性、安全性、响应时间等方面，进行详细的说明与解释，并且主要应说明如何达到这些指标。
（3）系统的主要功能描述。概要性地描述软件系统的主要功能。
（4）在项目研发过程中遇到的技术问题和解决方法。这是技术研究报告中最重要的一部分，也是最有价值的一部分。在这一部分中，应该对每个技术问题作为一个单独的小节，在每个小节里充分地描述技术问题的现象、影响、发生环境等，然后进行充分的分析，尽量将导出解决方法的思路写出来。这样才能够为下次遇到相类似问题提供良好的支持。
（5）系统目前达到的水平、现状、存在的问题及解决方案。第（4）部分是对已经解决的问题进行描述，而这一部分则是在前面的基础上进行提升。总结性地评价系统目前达到的水平，对并该系统的现状进行分析，指出还存在的问题，以及预期的解决方案，并说明为什么现有系统未能有效解决的原因与限制。
（6）项目总结。最后，在以上的所有信息的基础上，做出客观、有效、总结性的描述，以便有关人员能够更好的了解项目的总体情况。
（7）注解。包含有助于理解技术报告的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解技术报告需要的术语和定义，所有缩略词和它们在技术报告中的含义的字母序列表。
（8）附录。提供那些为便于维护技术报告而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。

项目开发总结报告

项目开发总结报告应该包括以下几个部分的内容：

（1）引言。包括项目开发总结报告的标识（包括标识号、标题、缩略词语、版本号、发行号）、系统概述、文档概述等方面的内容。
（2）引用文件。列出项目开发总结报告引用的所有文档的编号、标题、修改版本和日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
（3）实际开发结果。对已经完成的工作进行一个概要性的总结。
（4）开发工作评价。针对开发工作的情况进行一个简要性的评价。
（5）缺陷与处理。分别列出在需求评审阶段、设计评审阶段、代码测试阶段、系统测试阶段和验收测试阶段发生的缺陷及处理情况。
（6）经验与教训。这是项目开发总结报告中最有价值的部分，列出从本次开发中获得的主要经验与教训，以及对今后的项目开发工作的建议。
（7）注解。包含有助于理解项目开发总结报告的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解项目开发总结报告需要的术语和定义，所有缩略词和它们在项目开发总结报告中的含义的字母序列表。
（8）附录。提供那些为便于维护项目开发总结报告而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。