柚子@2010

第8章  项目管理计划
项目管理计划（project management plan，简称PMP）文档是项目经理承担的所有规划任务的核心。
各种规划任务的结果都出现在该文档中，它是指导所有项目执行的基准文档。
不应当将它与详细的项目进度计划混淆起来，后者仅仅表示任务的进度和分配。
用文档记录规划任务的结果，就可以对项目计划进行评审，找出其中存在的缺陷。
在Infosys公司，项目通常由项目经理、SEPG成员和高级管理人员组成的团体进行评审。
很多情况下，项目计划评审会揭示出显著的缺点，如果不纠正它们就有可能给项目添加麻烦。
对管理计划进行全面的评审是将潜在的问题扼杀在萌芽状态的最佳方法之一——对项目经理非常有用，尤其是那些经验不多的项目经理。
该文档还能在交流方面起到重要的作用。
它向高级管理人员提供了项目目标和任务的总体视图，描述了为了实现这些目标应当如何对项目进行管理。
它为项目团队提供了一个综合的项目视图及各团队成员的角色。
尽管我们已经讨论了大部分规划任务，但我们至今还没有讨论团队与沟通问题，本章对它们进行了讨论。
本章还讨论了Infosys公司用于记录计划的模板结构，研究了ACIC项目的项目管理计划。
8.1  团队管理
软件开发是一种团队工作。
只有团队成员全力以赴并保持高度的积极性，并且整个团队稳定而高效的发挥作用，才能够实现高质量和高生产率。
团队管理不仅仅是软件工程和项目管理问题，而且还涉及人员管理问题。
人员管理是项目的一项重要内容，如果忽略它，会给项目和项目经理带来麻烦。
8.1.1  团队结构
在Infosys公司，通常采用层次性团队结构；
•     一个团队由一个项目经理 领导，他向业务经理或者财务经理（或者同时向两者）报告。
•     此外，一个典型的团队由开发人员 （DV ）、配置控制人员 （CC ）和数据库管理人员 组成；所有这些成员都向项目经理报告。
•     一个大型项目可能还有模块领导 ，他们都向项目经理负责，并且他们底下还有一些开发人员。
•     此外，还从现有的团队成员中选出一些人组成一个故障预防团队 。这个团队负责执行与故障预防有关的任务。
前文已经讨论过，每个项目都有一个称为软件质量顾问（software quality adviser，简称SQA）的SEPG成员与之联系。
•    SQA 与项目经理（以及配置控制人员）广泛地沟通，但是不向项目经理报告。
•     相反，SQA 有一个独立的报告渠道。
角色分配是一项复杂的任务。项目经理的目标是建立一个稳定的、自力更生的团队，有助于促进事业的发展，团队成员的才能发挥。
因此，在确定团队结构时，项目经理必须考虑团队成员的个人需求和成长需求以及项目需求。
下面是项目经理应该考虑到的有关人的因素：
•     团队成员的技能、工作背景和经验
•     团队成员的个人抱负和职位升迁
•     顾问和人员发展需要
初始团队结构以及每个团队成员的角色和责任都记录在PMP文档中。
一个团队成员可以承担多重责任。
项目执行期间，尤其是一个长期项目，可以根据各成员担当不同角色时的表现、个人抱负、积极性高低等对团队组织作相应的调整。
8.1.2  沟通
一个团队可能会为了一个共同的目标而在一起工作好几个月，因此团队必须凝成一团，并且团队内部必须有良好的沟通机制。
团队沟通从广义上可以分成两类：
•    与项目相关的沟通
•    缓减压力的沟通。
一个出色的以人为本的项目经理会同时作好两种沟通的计划。
为了使团队成员及时获悉项目的进展和问题，可以让他们了解项目状态报告及客户和业务经理的相关意见。
除了这些正式报告外，根据团队的规模和项目的持续时间，项目经理可用如下方法来增强团队沟通：
•     项目专用的公告牌：发布公告、通知、状态报告等
•     项目邮件列表
•     项目网站：发布文档、团队成员的主页、相关的技术论文和笔记以及自学培训材料
•     项目会议：关于简报和问题解决方案
•     团队成员关于他们的工作的最佳实践会议和讨论
此外，因为最终交付期限往往很短，并且每个人都有时间压力，所以压力会越来越大。
旨在减压的沟通对于确保始终如一的积极性特别重要。
很多项目经理都会计划一些任务，使这种“有趣的”沟通成为可能。
例如，下面就是一些常用的方法：
•     项目晚会（组织预算支持所有团队）
•     生日宴会
•     诸如有奖竞赛和游戏等活动
•     非正式的、随意的“ 面对面” 交谈
8.1.3  团队建设
项目团队通常包含很多年轻人，团队和项目经理有责任加强这些团队成员的个人发展。
帮助各团队成员成长对项目和组织也有好处。
随着团队成员的技术和能力的提高，他们在项目后期的生产率会越来越高，并能承担更多的责任。
当然，他们也变得更能胜任未来项目中的任务。
为此，项目经理应采用如下这些方法：
•    岗位轮换
•    经验比较丰富的团队成员指导初来的成员
•    评审、评估和反馈
•    定期识别项目级的贡献
•    通过辅导、培训等帮助有困难的成员
8.2  客户沟通和问题解决方案
团队沟通旨在使团队及时掌握有关信息，保持团队的积极性。但也要重视客户沟通。
客户是项目的发起人，因而也是一个主要的风险承担者。
很多问题都是由客户和开发者之间的误解而引起的。
开发团队和客户间的定期沟通有助于消除这些问题。
状态报告就是这样的一种沟通方式，旨在让客户清楚地了解正在进行的项目的状态。
然而，这些报告无论多么详细，都是不够的。项目经理应当计划其他沟通方式，包括每周电话会议或者视频会议及定期发送电子邮件。
在每周的虚拟会议上，项目领导与客户一起走查项目的状态报告，并说明项目的限制因素。
讨论的重点是未决问题的解决方案。而客户寻求澄清真相，并在这些会议上阐明其观点。
总之，除了发送报告外，通过定期交流，客户和开发团队就能在思想上保持一致。这样就防止了很多可能因误解而产生的问题。
尽管采用了定期交流的渠道，但是仍然会出现双方代表都不能解决的问题。
这些问题会潜在地延迟项目，因此必须提交它们
为了简化这种问题的解决方式，项目计划规定了客户方和开发方的提交方法。
该计划还明确地表明了有关何时实施这些方法的策略。
除了提供一种解决问题的机制外，这种提交方法和策略的规范也增加了双方的压力，使他们尽快地解决问题，并在需要时把它们提交给上级处理。
8.3  项目管理计划的结构
项目管理计划模板包括四个主要部分。
项目提要（project summary）部分对项目进行了高度综述。它包含项目的开始和结束日期、项目领导、客户方联系方式、项目目标、向客户作出的关于里程碑和交付的软件的承诺，以及所作的假设等信息。所作的假设被显式地列出，因为它们通常充当某种风险源。同时还要描述付款的详情（以便业务经理可以跟踪它们）。无论从客户的角度还是从Infosys公司的角度，都要提及项目的目标，以便每个人都能明白为什么要执行该项目。
项目规划（project planning）部分列出执行各种项目规划程序的结果。它包含正在使用的开发过程、过程裁制备注、需求变更管理过程、需求跟踪能力计划、工作量和进度的估计及其基础，以及按技能、角色、每月工作的人员需求，或者这些需求的组合。它还规定了所需的开发环境、所用的工具以及任何项目专用的培训计划。本部分还给出了质量计划和风险管理计划。
项目跟踪（project tracking）部分定义要采用的度量措施以及用于记录数据的系统、要采取的各种项目跟踪任务、进展报告的频度和性质以及提交程序。
项目团队（project team）部分定义项目团队及其结构，以及各成员的角色和责任。
8.4  ACIC项目计划
本节介绍ACIC项目的项目计划。

PMP的第1部分给出主要参与者、里程碑和一个项目综述。

第2部分包含关于项目规划的详情。
首先，它列出了过程规划的结果。计划表明将要使用的“开发过程”及为项目所做的裁制工作。该项目将使用Rational Rose统一过程（RUP），因为这是客户的要求。
•    RUP包含四个主要阶段：初始阶段、细化阶段、构造阶段和移交阶段。细化和构造阶段通常迭代式地完成。细化阶段的主要任务是分析与设计，而构造阶段的主要任务是编码和测试。项目将进行2次细化迭代和3次构造迭代。
为了满足这种方法，需要对Infosys公司采用的标准开发过程进行裁制。裁制备注规定了对标准过程进行的裁制工作。

对于需求变更管理，计划规定将变更申请记录在哪里以及处理它们的过程。它还规定，如果任何一种变更申请需要总工作量的2%以上，则需要对项目进度和工作量重新进行估计。对于需求可跟踪性，它表明将使用一种工具。
工作量估计子部分给出了工作量估计及估计的基础。（第4章讨论了ACIC项目的估计。）它与工作量估计一起，规定了项目的进度（这与客户要求的里程碑相同）以及满足进度要求所需的人员。人员需求还根据技能进行规定。还给出了团队的培训计划，以及延迟某人进行培训的条件。

质量计划子部分给出了质量目标和故障的中间目标。因为项目本身设定了更高的目标，所以同时也给出实现那些目标的策略，以及项目准备执行的评审。

规划部分也规定了所需的硬件资源和软件资源以及风险管理计划（参见第6章）。

项目跟踪部分（第3部分）提到将用MSP（Microsoft Project）进行任务调度、工作分配和状态监督。
•    BugsBunny 是一个内部开发的工具，将用来跟踪项目所属的问题。项目经理负责评审这些问题并确保解决它们，但是不涉及与业务经理相关的问题。
•    BugsBunny 还将用来跟踪客户投诉和反馈信息。
•     状态报告每2 周发送一次，并且客户将在每个里程碑处接到1 个报告。
•     在里程碑处，计划进行详细分析。在双方都建立了问题的提交渠道。
第4部分规定项目团队结构。
•    团队由项目领导（Project Leader，简称PL）负责（本书别的地方称为项目经理），他管理一个故障预防（DP）团队、一个模块领导及配置控制人员。
•    DP团队负责分析故障并建议预防它们的方案。（第5章讨论了DP规划，第11章说明了DP任务的执行。CC的作用将在第9章作进一步的讨论。）
团队结构规定：软件质量顾问与团队有关，但他不向PL报告。该计划还规定团队中每个人员的角色和责任。
ACIC项目的项目管理计划
ACIC项目的项目管理计划
8.5  小    结
软件项目是一项团队工作。管理团队时，必须考虑到项目的目标以及团队成员的目标。
定期举行团队内交流以及与客户的交流。明确地规划双方的提交渠道，以解决原本很难解决的问题。
将各种规划任务的结果记录在一个综合性计划中。对此文档进行评审，以识别出潜在的规划缺点，并让高级管理人员根据其经验对它进行改进。
用文档记录计划，它必须包含项目的信息、将要采用的过程、变更管理方法、工作量估计、里程碑、风险管理计划、质量计划、项目跟踪和报告计划、项目以外的问题解决的提交渠道，以及团队组织等。

第9章   配 置 管 理
在一个软件项目中，由于工作产品的发展和需求变更而产生的变化，会接连不断地发生。所有这些变化最终将体现在包含源代码、数据或者文档的文件中所发生的变化。
在一个软件项目的大量文件由多人共同创建的情况下，如果他们都可以对这些文件进行变更，则必须对这些变更进行正确地控制，否则问题会复杂化。
考虑下面这些取自各种不同项目的情况：
    假定客户提出了两种不同的变更申请。项目经理将一种申请交给Rao去实现，而将另一种申请交给Meera去实现。两人都必须修改模块X的代码。当Meera完成她的修改时，她保存了模块X的文件，并不经意地地覆盖了Rao几天前完成的修改。
    一个模块由三个团队成员开发代码，其最后交付期限是周五。他们计划在最后2天集成经过单元测试的代码。Subbu是几个关键函数的开发者，他突然在周二晚上离开团队要去办一件紧急事情。次日，模块领导和团队成员花了很长时间来研究Subbu的文件。他们设法标识出那些包含Subbu正在开发的各种函数的文件，但是他们发现这些文件有很多个版本。因此，他们不得不让其中一个团队成员来解决该问题，该团队成员一直到周末才完成该任务。他以Subbu开发的某个版本的程序开始，开发了Subbu的程序单元并对该单元进行了测试，他重做了Subbu离开团队前几乎已经完成的工作。最后，模块的交付时间推迟了3天。
    Srinath团队的精神状态很好。他们按时完成了项目开发，并且最后的测试也没有出现问题。软件被交给客户去实施。次日，Srinath收到了来自用户和客户的气愤的电子邮件，他们报告了软件存在的问题。经过团队紧张的工作，终于找到了原因：软件的发行版中的某个关键组件使用了旧版本。
诸如此类的问题可以在许多组织中发现。配置管理（configuration management，简称CM）也称为软件配置管理（software configuration management，简称SCM），是项目管理的一项内容，主要涉及对变更进行系统的控制以防止此类问题的发生。

本章首先讨论一些与CM有关的基本概念，然后讨论Infosys公司遵循的CM过程。此外，还给出了案例研究的CM计划。

9.1  配置管理概念
CM对于实现项目中的一个基本目标很重要：将高质量的软件产品交给客户。这种交给客户的“软件”是什么呢？它至少包含构成源和对象代码的源和对象文件、从这些文件建立工作系统的脚本及其相关文档。在项目执行期间，文件变更会导致不同版本的软件的建立。在这种情况下，程序管理员如何保证组合了正确版本的源代码文件，而又没有遗漏源代码呢？又如何保证发送了与最终的源代码一致的正确版本的文档呢？所有这一切都通过正确的CM得到保证。
CM的一个主要目标是对软件系统不断变化的配置进行管理。在一个项目中，一个程序的发展要经过很多阶段。
•    最初开发它时，程序处于开发状态（或者“私有”状态）。
•    在程序员对程序感到满意之后，程序就进入了“准备单元测试”状态。
•    只有当程序达到这个状态时，才能对它进行单元测试。
•    在程序经过单元测试后，必须修复发现的所有问题。
•    如果成功地通过了单元测试，则进入“准备系统测试”阶段。
•    只有在所有程序都达到这个状态时，才可以开始系统测试。
•    此外，如果在系统测试阶段发现故障，则程序状态返回到“私有”状态；否则程序进入“准备验收测试”状态。
•    如果验收测试成功，则所有程序的状态改变成“准备发行”状态，表明可以发行它们，并进入“生产使用”状态。
•    程序被发行并处于生产使用状态后，所有程序及相关文档都进入“基准（baselined）”状态，它代表生产系统的状态。
除了正常的软件开发期间发生的变更，需求变更申请还可以通过提交渠道进行提交，并且它们的实施可能会改变程序。当一个项目有大量可以被变更的条目时，可能会要求开发人员采取很多措施；只有在CM过程的正确支持下，才能执行这些措施。
为了更好地理解CM，让我们考虑一下项目要求的各种CM功能。尽管这些需求依赖于项目的性质和具体情况，但是某些基本功能是可以确定的。下面列出了其中一些功能，以及那些可能需要它们的环境。
    给出程序的状态。你需要此信息来决定何时开始测试或者何时发行软件。
    给出程序的最新版本。假设必须对一个程序进行修改。显然，必须在最后一个版本中实现修改；否则，前面的修改可能会被丢失。
    处理并发更新申请。在响应两个不同的变更申请时，两个程序员可能会并发地修改同一个程序。其中一个的修改有可能覆盖另一个的修改。为了避免这种情况的发生，需要有访问控制机制，使得在某一时刻只有一个人能够对程序作出修改。如果允多人并行地修改，则应当实施协调过程以保证最后的版本体现出所有的修改。
    取消一个程序变更。对一个程序作出某种变更后（为了实现某个变更申请），但后来出现某个申请，需要撤消这种变更申请。
    防止未授权的变更或者删除。程序员可以决定变更某些程序，但是发现这种变更有负面影响。为了拒绝接受未授权的变更，需要有访问控制机制。
    提供需求变更申请和程序变更之间的可跟踪性。假设一个需求变更申请规定要对三个程序进行修改，并且这些修改任务已经分配给三个团队成员。项目经理如何保证他们正确地实现了该变更申请呢——即，如何保证所有程序都已被修改过，并且修改过的程序正处于生命期的“准备发行”状态呢？该问题的答案是要求一种跟踪变更申请的机制，它可以规定所有要进行修改的程序以及每个程序的状态。
    取消一个需求变更。某个已经被实现的需求变更申请（通过改变很多程序），事后可能需要被撤消（也许因为客户不喜欢变更后的新特征）。
    显示相关的变更。假设在某个程序中发现了一个bug，并且怀疑这个bug是由于实现某个变更申请而引起的。则必须检查所有因那个变更申请而导致的变更。
    收集当前系统的所有源代码、文档和其他信息，以便在文件遭到破坏或者系统崩溃时能够恢复所有文件。同样，可能需要对现有系统（正在运行的系统）作出某种变更，所以必须收集所有代表当前系统的源文件和文档。

上面所列的情况是一个项目中经常发生的需要CM过程支持的情况。此外，如果某个软件产品有多个版本同时存在，并且每个版本的软件产品使用一个不同版本的程序，则可能出现其他与变更相关的情况，要求CM具备额外的功能（例如，处理变体）。
CM的主要目标是提供处理前面列出的各种情况的机制。
这些机制包括：
    文件命名和组织的约定
    版本控制
    变更申请的可跟踪性
    访问控制
    协调过程
    修改登记程序
根据标准约定命名程序文件（和文档文件），并把文件保存到指定的目录中，这有助于迅速发现某个所需的文件。正确的命名（例如，通过使用标准的扩展名）还有助于开发人员容易地理解文件内容的本质，而不必查看文件内容。此外，将程序根据它们的状态分别保存到不同的目录中，这有助于开发人员轻松地识别出程序的状态。
版本控制是CM的一个关键问题，有许多工具可以帮助管理这个任务。版本控制有助于保护程序的旧版本，而不管程序如何变化。如果没有这么一种机制，则系统不能支持许多必须的CM功能。
变更申请跟踪性机制提供了从一种需求变更申请到随后的程序变更的映射，有助于需求变更的管理。为了找到变更申请之前的变更，一种有效的办法是借助于修改日志。
访问控制机制保证只有被授权的人员才能修改某些文件，并且在某一给定时间只有一个人能够对一个文件进行修改。
协调程序规定了如何合并对一个程序独立进行的两次修改，建立一个新版本，以体现这两次修改。
如果这些机制都被提供了，则可以令人满意地处理前面给定的情况。这些情况中的一些需要采用多种机制。例如，取消一个需求变更牵涉到一种表示从需求变更到随后的程序变更的可跟踪性机制，以及一种版本控制机制以切实地取消变更。
一些CM机制可以得到某个工具的支持，而另一些可能需要用户显式地执行它们。例如，版本控制可以通过一个工具而实现，但是获取一个程序的状态可能要求程序员显式地维护这种信息。CM过程定义了实现这种机制的所有步骤，并说明了如何在项目中使用这些机制。
前面所讨论的内容主要集中于程序。项目所产生的文档（诸如需求文档、设计文档和计划）也需要配置管理。在一个项目的正常执行期间，一个文档往往会经历3个状态：“正在开发”、“正在评审”和“基准状态”。状态转移很明确。CM过程还必须实现文档的状态图。
9.2  配置管理过程
CM过程定义了支持CM机制必须执行的任务序列。
与项目管理中的大多数任务一样，CM过程的第一阶段也是规划，确定那些需要进行配置管理的条目（称为配置项）、保存它们的位置、变更控制的程序等等。项目经理或者配置控制人员（CC）准备这个计划。
然后该过程必须被执行，也许通过部署一个工具（工具的使用也要加以规划）来实施。
最后，因为任何一个CM计划要求项目人员维护版本、将配置项保存到合适的位置，以及正确地作出变更等方面的训练，所以监督配置项的状态和执行CM审计是CM过程的其他任务。
本章讨论CM过程的这三种任务。
9.2.1  配置管理规划
配置管理规划涉及确定配置项和规定用来控制和实现其变更的程序。
确定配置项是任何一种CM的基本任务。
典型的配置项如需求规范、设计文档、源代码、测试计划、测试脚本、测试程序、测试数据、项目使用的标准（诸如编码标准和设计标准）、验收计划、CM计划和项目计划等文档、用户手册等用户文档、以及培训材料等文档、合同文件（包括支持工具，诸如编译器或者内部工具）、质量记录（评审记录、测试记录）和CM记录（版本记录、状态跟踪记录）。客户提供的任何产品或者购买的任何东西，只要它将成为发布的软件的一部分，那么它也是配置项。
规划期间，CM的配置项类型已经被识别出，但是没有准备好这些配置项的详细列表。这说明在CM规划期间，某些配置项可能不为人知（这出现在项目开始时）。
为了使配置项的正确命名更加容易，CM规划阶段制定了CM配置项的命名约定。
除了命名标准外，项目经理还必须计划版本编号。当一个配置项发生变化时，不是用新项替代旧项；而是旧项被保存起来，并建立一个新项。这种方法导致一个配置项存在多个版本，因此需要有版本号分配策略。
如果使用了一种CM工具，则有时可以用它处理版本编码问题。否则，必须在项目中显式地处理编码问题。
规划期间，项目经理必须确定如何维护一个程序的状态。
一种收集不同状态的配置项的方法是为它们建立不同的目录。某个状态的所有配置项都保存在那个状态的目录中。当一个程序的状态发生变化时，则将那个程序从旧状态的目录移到新状态的目录。这是一种基本方法，不要求使用任何工具来维护状态信息。
如果使用CM工具，则管理程序状态的目录结构依赖于工具。在规划阶段，项目经理必须设置用于管理程序状态的目录结构，如果CM工具有一些需求，则必须牢记这些需求。

配置控制人员或者项目经理进行CM规划。只有在项目已经开始，并且已经用文档明确地记录了运行环境和需求规格说明，CM规划才可以开始进行。
该阶段包括如下一些任务：
    标识配置项，包括客户提供的配置项和购买的配置项。
    定义配置项的命名机制和编码机制。
    定义CM所需的目录结构。
    定义访问限制。
    定义变更控制过程。
    标识并定义CC或者配置控制委员会（Configuration Control Board，简称CCB）的责任和权限。
    定义一种配置项状态的跟踪方法。
    定义一种备用过程。
    如果需要，定义一种协调程序。
    定义一个发行程序。
    定义一个存档程序。
    确定配置项将被移入基准库的时机。
这一阶段的结果是CM计划。
CC负责CM计划的实施。
    根据正在开发的系统的规模，CC的角色既可以是一份兼职工作，也可以是一份全职工作。CC也可能负责版本管理、版本归档、在需要时找到并发行合适的版本，等等。
在某些情况下，可能需要一个CCB。这个委员会包括来自每个团队的代表。
•    当团队规模很大时，
•    或者两个或者多个团队或者小组参与软件或者接口系统的相同部分或者不同部分的开发时
CCB（或者一个CC）是CM的基础，并且CM计划必须明确地定义CC或者CCB的角色或者责任。这些任务还取决于文件系统的类型和所用的工具。
前文已经提到过，CM要求限制对某些状态下的某些项目的访问。例如，必须限制程序员访问和修改基准库中程序的权力。因此，规划任务必须规定CC、项目经理和开发人员的访问权力。
规划期间还要建立变更控制的策略和程序。这包括控制生命期中发生的正常变更，以及因需求变更而发生的变更。正常变更通常通过一个电子表格进行跟踪，它列出所有必须被变更的条目以及每个条目的目录（从而给出它的状态）。
如果项目经理允许并发地更新程序，则他们必须规定协调程序。
并发更新有时是需要的。
•     例如，假定正在实现一个变更申请的同时出现一个级别更高的变更申请。显然，在第一个变更申请完成之前，不能执行新的变更申请。
•     同样，如果正在实现一个变更申请时工作系统出现了一个问题，则变更必须立即完成，以确保系统能够继续工作。
•     对于上述情况，需要协调过程来解决。
一种可能的协调程序是将检查原版本和新版本之间差别，并且变更量更少的版本变更将被合并到其他版本中。
如果变更影响程序的不同部分，程序合并是显而易见的；一些CM工具支持这些合并。否则，程序员必须检查重叠部分，然后协调这两种变更。
计划的所有要素都被记录在CM计划文档中。
本章后面将给出ACIC项目的CM计划。
9.2.2  执行配置控制
虽然配置控制任务是在项目执行阶段承担的任务，但我们在这里与CM的其他特征一起讨论它们（配置控制任务）。
配置控制任务主要有两个：
•     一个涉及程序（和文档）的状态转移管理，
•     另一个涉及必须被实现的变更申请的管理。
状态转移管理涉及在状态变更时将配置项从一个目录移到另一个目录，然后在完成变更后建立新版本。
通常用工具来管理项目的状态和版本及对它们的访问。
很多CM工具采用check-in/ check-out(签入/签出)方法进行访问控制和版本控制处理。
这种方法的基本思想如下：当一个程序处于其他程序能够使用它的任何状态下，则认为该程序处于一个被控制的环境中。一旦一个程序进入了被控制的环境，在没有正确授权的情况下就不能修改它，即使最初的作者也不能修改它，因为其他人有可能正在使用它。
为了执行已批准的变更，开发人员必须在被控制的环境外面检查程序。check-out实质上表示在不破坏早期版本的情况下制定配置项的一份拷贝，并标明配置项已经被check-out过。
配置项经过check-out以后，再对它进行修改。然后必须在被控制的环境中反映出配置项的修改，以便能够真正实现变更申请（它可能会强制要求这些变更）。
•    因为其他团队成员可能正在使用这些条目，所以在条目重新回到被控制的环境中之前，要对条目进行一些检查，以确保变更后的条目是合适的。
•    当一个条目重新回到被控制的环境中时，旧版本的条目被破坏；而建立一个新版本的条目。
    通常，只有CC或者项目领导才能check-in条目。这一限制使得在需要时能够撤消变更。
为了提供有关已做出的变更方面的信息，项目经理可以考虑为程序的源代码本身保持一个变更日志。这个日志实质上标识出一个变更的开始日期和结束日期，并包括一个对变更申请的引用。
所有这些任务——check-in、check-out、版本维护和变更日志的建立——都可以用相应的CM工具进行处理。可以用各种各样的工具来执行很多该CM库的功能。
为了实现需求变更，进而触发配置项的变更，首先通过执行影响分析对变更申请进行分析。该分析确定需要进行修改的程序和文档，以及修改所需的成本及其对进度的影响。一旦项目领导和CC同意了此修改，所有在影响分析中标识出的程序和文档都必须作相应的修改。
下面给出了实现一个变更申请时会牵涉到的一些任务：
•     接受变更申请（影响分析之后）
•     建立一种跟踪机制
•    Check-out 需要进行变更的配置项
•     执行变更
•    Check-in 配置项
•     在项目的整个生命期内维护该项目
通常用基于电子表格机制来跟踪变更申请的状态。
•     对于每个变更申请，建立一个电子表格，列出所有需要进行变更的程序以及它们的状态。
•     为了实现一次变更，CC 或者CCB 将不同条目的变更任务分配给团队成员，由他们check-out 项目并完成这些变更。
•     在团队成员完成变更以后，可以将变更后的程序（或文档）看成一个新的程序（或文档），在经历程序生命期各阶段后再成为最终系统的一部分。
•     在所有修改后的程序及相关的文档都到达了基准（在遵循它们的生命期之后），则认为变更申请已经被完全实现了。
9.2.3  状态监督和审计
一个配置项可以存在多种状态。状态集随配置项是程序还是文档以及所用的CM工具类型而变化。
正确地表示每个配置项的状态是重要的，因为与状态相关的错误会引发一些问题。
•     例如，如果一个程序还没有进行单元测试就进入了“ 准备发行” 状态，则是有问题的。
•     同样，如果系统不能反映出已经从基准库中check-out 一个程序并对它实施了变更这个事实，则发行的软件可能没有包含此变更。
•     因此，在实现需求变更申请后，确保用来获取配置项状态的机制正确地表示了配置项的状态，是很重要的
如果项目使用一种基于目录结构的机制来表示一个程序的状态，则发生错误是可能的。
•    这种机制要求在程序状态变化时将程序从一个目录移到另一个目录，并在维护各条目状态的主表中反映出状态变更。
为了使错误最少并尽早地捕获任何错误，项目必须定期对配置项进行状态检查。
可以建立一个关于差异的报告，所有这样的差异都必须被解决。
除了检查条目的状态外，项目还必须检查变更申请的状态。
•     为了实现此目标，必须检查自最后一次CM 状态监督以来收到的变更申请。
•     对于每个变更申请，将变更申请记录中提到的条目的状态与实际状态进行比较。
•     也可以通过检查来确保所有修改后的条目在回到基准库中之前都经历了完整的生命期。
最后，项目可以执行一个配置审计。与其他审计一样，这里的主要目的是确保项目执行确实遵循CM过程。也可以审计系统的基准库，以确保其完整性没有被违反，并且条目的移入和移出与CM计划一致。
通常由项目的配置控制人员执行CM审计。CM审计后通常发布一个报告，列出为了保持CM任务与CM计划一致需要完成的任务。
表9.1例举了一个ACIC项目的CM审计报告（该ACIC项目的CM计划在本章后面给出）。从表中可以看出，除了检查过程外，CM审计主要关心配置项的状态和位置。

9.3  ACIC项目的配置管理计划
这里介绍的CM计划规定CM环境和ACIC项目所遵循的目录结构。
ACIC项目的CM计划表明了目录结构在项目区域下，由Visual Source Safe（VSS）工具管理，所有需要被管理的文档都保存在这里。
源代码文件由Visual Age for Java（VAJ）工具管理。在VSS目录下，规定了各种各样的目录；目录名明确地表明了这些目录将保存些什么。
用户区域未受管理，但也对它进行了规定；每个用户一个目录，并且每个团队成员应该遵循其区域的目录指南。
同样，也对评审区域进行了规定；这是保存要被评审的项目的目录。
接着，该计划列出配置项、它们的名字以及它们的存储位置。
•     这里只列出受控的配置项。
•     诸如测试结果、评审结果、消息、模板、标准等未受控的配置项都被忽略；它们分别被保存在各自未受控区域的目录中
•     对每个配置项，在工作区域中给出开发时应当保存的区域。
•     如果将要对配置项进行评审，则计划表明应当把它移到哪里进行评审，以及评审后它应保存的VSS 下的基准区域。即计划概括了这些项目演变过程的存储区域。
再接着，计划描述了一个文档如何在这些不同的区域中移动——即，文档的配置控制过程。
•     用户操作工作区中的文档。
•     当文档准备评审时，就把它移动到指定的评审区域。
•     如果评审不要求任何返工，文档就成为了基准。
•     计划没有为代码规定类似的过程，因为使用了VAJ 方法。
再接着，计划规定各区域和VSS的访问权。因为该项目的团队规模很小，所以遵循了一种相对较自由的访问机制，所有团队成员对受控区域都有check-in和check-out访问权。
再接着，计划规定变更控制过程。
•     首先，计划规定谁负责记录变更申请、谁评审等等。
•     然后给出变更实现过程。
协调是很多项目中的一个主要问题。
•     前面已经提到过，当多个人同时修改一个配置项时，就需要进行协调。
•     对于文档，不需要这样的协调，因为没有设计并行变更，并且VSS 有正式的注册和检查程序，不允许并行变更发生。
•     然而，源代码的变更协调是需要的。
     在类层次上，协调的责任由类的所有者负责，他将对此使用VAJ 功能。（如果多个人对类进行了修改，VAJ 强调类的不同和不同版本的方法。）
     在每个里程碑处，或者每当需要的时候，为所有资源进行所有协调。
如果在开发地点（脱机）和部署地点（联机）同时作出某些变更，这时可能需要进行协调。如果这种情况发生了，还是要使用VAJ；标识出这些变更存在的差异，然后合并这些变更。
如果多个项目正在使用某些共同的源代码，则项目间的协调也是必须的。
•     通常，所有项目将它们的VAJ 文件发送到一个中央协调程序，由它协调文件并返回它们。
•     然后，这些经过协调的文件就成为了每个项目的基准。
接着，CM计划规定发行区域和备份过程。
•    源代码的发行区域是VAJ仓储，并且在构造里程碑结束时发行源代码。（“发行”在这里表示协调已经完成，并且基准已经建立，这个基准也有可能发送给用户。）
•    概要设计在相应的里程碑结束时从VSS区域发行。
•    对于备份，还规定了其区域和频度。
•    然后，提到配置审计的性质和频度，以及配置控制人员的作用和责任。
     在这个项目中，CC 负责维护工具、确定备份过程、执行审计并帮助团队遵循CM 过程。
•     （完整CM 计划还包含一些这里没有提到的要素。）
    ACIC项目的配置管理计划
9.4  小    结
软件产品通常包括很多程序和文档，在这些项能够成为最终系统的组成部分之前，它们还会发展变化。因此，软件配置管理是一个重要的问题。
下面列出了从Infosys公司遵循的CM过程中吸取的一些经验教训：
    定义CM过程，使项目能够处理并发更新、撤消一个变更、获得一个程序的最新版本、确定一个程序的状态，以及防止未授权的变更。为了支持这些功能，应使用版本控制、变更申请跟踪以及库管理机制。
    开发一个独立于项目管理计划的CM计划。CM计划必须规定环境、配置项及其命名约定、项目在不同状态的存储区域，以及管理项目变更的方法，包括版本编号和协调、访问控制以及发行和备份策略。
    执行CM审计和状态检查，确保CM计划得以遵守。
9.5  参考文献
    [1] E. H. Bersoff, V. D. Henderson, and S. G. Siegel. Software configuration management: A tutorial. IEEE Computer, Jan. 1979.
    [2] E. H. Bersoff. Elements of software configuration management. IEEE Transactions on Software Engineering, Jan. 1984.
    [3] W. Humphrey. Managing the Software Process. Addison-Wesley, 1989. （“SEI软件工程丛书”之《软件过程管理》，瓦茨•汉弗莱著，其英文影印版由清华大学出版社于2002年出版，中译版由清华大学出版社于2003年出版。）
    [4] D. Whitgift. Methods and Tools for Software Configuration Management. John Wiley and Sons, 1991.
    [5] P. Jalote. CMM in Practice: Processes for Executing Software Projects at Infosys. Addison-Wesley, 2000.

软件项目管理
教材：《软件项目管理实践》
背景
全球每年要完成上百万个软件项目，但有1/3左右的项目在成本和时间上都超出额定限度的125%以上。
这么多的软件项目失败的关键在于软件项目管理不正确
例如，目标不明确、计划不完善、采用新技术、缺乏正确的项目管理方法，以及人员不够等等。
能力成熟度模型（CMM）
第1章  软件项目管理简介
为什么众多软件项目会失败？
有分析认为：1/3左右的项目在成本和时间上超出额定限度的125%以上。
最重要的一条失败原因是软件项目管理不正确。
例如，项目失控的主要原因有目标不明确、计划不完善、新技术、缺乏项目管理方法以及人员不够。显然，其中至少有3个原因（目标不明确、计划不完善、缺乏项目管理方法）与项目管理有关。另外2个原因（人员不足和采用新技术）可以说是风险活动，但风险活动的管理也是项目管理的一部分。
1.1  过程与项目管理
软件项目主要涉及两方面的任务：软件工程和项目管理。
软件工程方面涉及系统的建立，并重点关注如何设计、测试、编码等问题。
项目管理方面涉及如何正确地规划和控制软件工程行为，以满足项目在成本、进度和质量方面的目标。
小规模项目
如果项目的规模较小（比如说由1到2个人组成的团队工作几个星期的项目），可以用不太正规的方法实现它。
–  项目计划可能是一个电子邮件，它规定了项目的交付日期，另外还有可能规定了一些中间里程碑。
–  需求可能通过一个便条甚至口头方式进行通知，
–  而中间工作产品（诸如设计文档）可能是在个人的便条本上草草写就的东西。
大型项目
在大型商业项目中，必须遵循那些经试验证明效果良好的方法，谨慎地执行每个工程任务，并且必须用文档正确地记录工作产品，以便其他人员能够查阅它们。
项目任务必须经过仔细规划，并将它们分配给执行项目的人员，然后在项目执行的同时对它们进行跟踪。
换句话说，要成功地执行较大规模的项目，必须在软件工程和项目管理这两方面增强正规程度和严格程度。
正规方法
正规方法要求用良好定义的过程来执行各种任务，以便结果更加依赖于过程的能力。
如果通过使用合适的度量手段在过程中实现了量化方法，则正规程度得到进一步的加强。
何谓过程？
从技术上讲，对于某个任务的一个过程，它由执行该任务时应当遵循的一个步骤序列组成。
对一个组织而言，建议其工程师和项目经理使用的过程就远非一个步骤序列了；它们涵盖了工程师们和项目经理所掌握的已成功地执行项目的实践。
– 通过过程可以将好的经验同所有人共享，包括新员工。
– 这些过程有助于管理人员和工程师借鉴过去的成功经验，从而避开导致失败的陷阱。
对一个项目而言：
– 软件工程过程通常规定如何执行工程任务，诸如需求规范、设计、测试等等；
– 项目管理过程则规定如何设置里程碑、组织全体人员、管理风险、监督进展等任务。本书重点介绍项目管理过程。
为什么项目经理必须遵循过程？
过程代表着集体的智慧，使用它们可以增加成功的机会。
过程可能会包含一些多余的步骤，但是你事先不可能完全知道哪些步骤是不必要的，因此走捷径可能会增加风险。
如果没有采用过程，就不能很好地预测项目的结果。
如果没有定义过程，你和组织就不能进行有效地学习。而学习和提高是当今知识世界必不可少的事情。
过程减少了须考虑的问题。检查表（checklist）会涵盖80%要做的事情，你只须完成好剩下的20%就行了。
1.2  项目管理与CMM
软件CMM
软件CMM是由卡内基梅隆大学的软件工程研究所（Software Engineering Institute，简称SEI）开发的，它体现了软件组织和其他组织在软件开发管理方面的最佳实践。
– CMM体现了集体的过程经验及很多公司的期望。
软件CMM 规定了过程所必需的特征，但是没有规定专门的过程。
–  不同的过程都可以实现CMM 的要求。
– CMM 可以用来评价一个组织的软件过程，标识出存在的缺陷。
CMM的目标之一是对成熟的过程和不成熟的（或者特设的）过程加以区别。
– 不成熟的软件过程意味着在没有很多指导原则的情况下执行项目开发，而项目的结果极大地依赖于团队和项目领导的能力。
– 在成熟的软件过程下，项目的执行遵循已定义的过程。在这种情况下，项目的结果不再过分地依赖于人员，而更加依赖于过程。
过程越成熟，结果就越可预测，而项目也更好控制。
过程能力与过程绩效
使用一个过程执行项目时能够从中期望得到的结果范围称为项目的过程能力（process capability）。
使用一个过程执行项目时所实现的实际结果称为项目的过程绩效（process performance）。
过程绩效依赖于过程能力。
若要始终如一地改进项目的过程绩效，就必须增强过程能力；而过程本身必须变得更加成熟。
各能力成熟度等级简介
初始级，项目按团队和项目经理认为合适的方式进行开发；
可重复级（第2级），虽然还不存在组织范围的过程，但是利用了既定的项目管理实践；
已定义级（第3级），定义了组织层面的过程，并且得以正确的执行；
已管理级（第4级），过程能力的量化表示使得有可能定量地预测和控制一个项目的过程绩效；
优化级（第5级），过程能力以一种可控的方式在改进，并以定量的方式评估这种改进。
关键过程领域(KPA)
untitled
若一个组织要实现某个成熟度等级，它必须实现那个成熟度等级的所有KPA以及所有更低成熟度等级的KPA。
1.2.2  项目管理与KPA
每个KPA规定了组织为了满足那个KPA必须实现的目标。
此外，KPA规定了一组任务，称为关键实践（key practice），由它们共同实现KPA的目标。

第2级上KPA的目标
第2级的重点几乎全部在项目管理上。
需求用文档正确地记录下来，并对需求的变更进行正确的管理。
所有工作产品都在控制之中，并根据一个事先制定好的配置管理计划正确地管理对产品的变更。
执行评审与审计，确保遵循计划的过程和标准。
如果项目的某些部分被转包给其他软件开发商，则也要对被转包的工作进行正确地监督。

第3级上KPA的目标
重点强调组织管理和过程管理问题。
对于达到第3级能力成熟度的组织中的项目，它使用专用型的标准过程，并重用以往项目的资源、数据和经验进行规划。
执行项目的各小组通过良好定义的接口和机制愉快地合作。
正确地执行评审以标识出工作产品中存在的缺陷，并为执行评审和随后的任务提供充分的支持。

第4级上KPA的目标
重点强调组织的过程能力用量化术语表示。过程能力用于设定一个项目的量化目标。
在当前的基础上收集项目绩效方面的数据,并与以往的绩效进行比较；如果觉察到明显的偏差，则采取正确的行动恢复对项目的控制。
第4级的一个关键特点是在当前基础上使用统计过程控制技术，以便在需要时可以评估每种任务并采取正确的行动。

第5级上KPA的目标
重点强调过程能力的改进。
过程变更管理
技术变更管理
缺陷预防

SEPG对项目的支持
Infosys公司的质量部门有一个软件工程过程小组（software engineering process group，简称SEPG）。
– SEPG负责协调所有过程任务，包括过程定义、改进及部署。
– 它还管理所有与过程使用相关的信息和数据（诸如过程数据库和过程能力基准等，这些将在第2章做进一步讨论）。
虽然提交产品的全部责任（包括质量）属于项目团队，但是SEPG使得项目团队能够轻松地遵循正确的过程。
SEPG还形成了一个独立地监督过程问题和质量问题的渠道，并通过这个渠道向高级管理层报告这些问题。
– SEPG有助于确保已定义的过程得以实现并成为标准的实践。
为此，SEPG除了提供过程培训外，还提供了一个与项目相关的成员，称为软件质量顾问（software quality advisor）。
– 质量顾问帮助定义过程和遵循过程，确保过程得以遵守，帮助分析数据，并提供任何所需的过程培训。
– 因为顾问非常精通于项目过程、指南等等，所以顾问的主要帮助在对项目规划的过程中。
– 顾问还评审项目计划，以确保它包含了全部的关键要素。
除了提供咨询并用过程和度量标准进行帮助外，Infosys公司的SEPG还要制定定期独立审计的计划，并对它们进行管理，以确保已定义的过程和标准得以遵守。
高级管理层参与项目
在提供客户服务方面，Infosys公司有很多业务部门。在业务部门中，一个团队执行一个项目，并由项目经理负责。
– 项目经理全方面负责项目执行，从确定软件需求到最后的安装。
– 项目经理向业务经理负责，而业务经理向业务部门主管负责。
为了处理项目经理不能解决的情况，高级管理层参与项目是有必要的。在Infosys公司，业务经理定期与项目经理进行交流，并通过状态报告和里程碑报告对项目进行监督。
除了定期监督外，业务经理还要帮助解决项目团队不能处理的各种问题，并将这些问题上交。
业务经理还要与客户进行交互，确保他们感到满意，使他们即时地提出各种问题并解决之。
此外，其他高级管理人员也要定期对项目进行评审，他们可以定期参与内部审计工作。
– 通过两个系统——（高级项目评审系统）和（项目集成管理系统），高级管理人员就可以评审里程碑报告和项目计划。
– 所有高级管理人员都必须通过这个系统定期地评审某些项目，并将有关的注意事项反馈给项目领导。
总之，高级管理人员主要通过监督的方式参与项目，确保项目目标得以实现，并且客户完全感到满意。
项目管理过程
项目管理过程是一个非常标准化的过程，有三个主要阶段：
–  项目规划
–  项目执行
–  项目收尾
项目规划
在项目规划阶段，项目经理审阅合同条款并制定一个满足它们的计划。制定严格的项目计划涉及定义一个生命期过程（这是以后要遵守的过程）、估计工作量和进度、准备一个详细的任务进度计划等等。它还涉及规划质量管理和配置管理以及风险管理。
除了项目经理外，该阶段还会牵涉到客户、一个SEPG代表以及项目的业务经理。
开始标志：签定了项目合同，或者得到了项目授权。
结束标志：用文档记录了项目计划，并对其进行了小组评审。
项目执行阶段
第2阶段是项目执行阶段，包括执行项目计划、跟踪项目的状态，并在项目的绩效偏离项目计划设定的绩效时采取措施进行纠正。
– 它将牵涉到项目过程的跟踪和控制。
– 这是项目管理过程中历时最长的一个阶段，
– 它将定期监督项目状态和质量，并采取任何所需措施来纠正偏差
在这一阶段团队的其他成员也要参与。
开始标志：项目计划已经完成，并得到了批准
结束标志：所有交付的工作产品为客户所接受。
项目收尾
项目管理过程的最后一个阶段是项目收尾，主要是在客户接受工作产品之后对项目进行系统的总结。
这里的主要目标是从经验中进行学习，以便能够改进过程
项目完成后的数据分析构成了这一阶段的主要任务；对度量标准进行了分析，过程资源（诸如模板和指南等材料可用于帮助管理过程本身）被收集起来供以后使用，并记录有关的经验教训。
从项目中学习经验是这一阶段的主要目标，所以这是一种群组活动，牵涉到项目经理、SEPG及团队的其他成员。
开始标志：客户接受了工作产品。
结束标志：举行了项目完成后的会议。

第2章  项目规划基础结构
重蹈覆辙
每个项目经理都在努力工作，力争建立最优的项目过程来执行其项目和实现他能够实现的结果
–    尽管其他团队以前已经执行过类似的项目，并且他们的经验和数据能够极大地减轻项目经理的痛苦。
不仅项目经理从头开始重新进行他们的规划工作，而且他们“计划”重蹈他们之前的项目经理犯过的同样的错误。
解决问题的重点
解决这种困境的办法在于：建立一个所有项目的管理人员都能够访问的公共知识库（institutional memory）。
问题的重点在于如何建立这么一个公共知识库，并用它塑造项目规划的基础结构。
–     该知识库的要素是什么？
–     如何系统地记录以往的经验，并使它们可重用？
–    Infosys 公司又如何保持项目规划基础结构最新？
关键要素
过程数据库（process database，简称PDB）：保存已完成项目的绩效数据。
过程能力基准（process capability baseline，简称PCB）：概括了各个项目的绩效，定量地规定了遵循过程所能达到的结果范围。 如果遵循相同的过程，就能预测出项目的结果范围
过程资源 （process asset ）：是一些文档，诸如检查表、模板、方法及所吸取的经验教训。 即总结以往经验的材料，它们能帮助项目经理和工程师有效地使用过程。
2.1  过程数据库
过程数据库(PDB)是项目过程绩效数据的永久性存储库，可以用于项目规划、预测、生产率和质量分析以及其他一些用途。
2.1.1  PDB内容
在项目规划期间使用PDB中的信息时，项目经理经常发现同类项目的信息非常有用。
为了实现相似查询，应当在PDB中保存项目的基本信息，诸如项目所用的语言、平台、所用的数据库、所用的工具、项目规模和工作量等等。
–     有了这些信息以后，项目经理就可以搜索和查找所有项目的信息。
–     例如，专门查找一个特定的应用领域，使用某种特定的数据库管理系统（DBMS）或者语言，或者指定某个特定的平台。
为了帮助项目规划，应当获取关于工作量、故障、进度、风险等方面的数据。如果知道了一个项目所花的总工作量，以及不同阶段的工作量及其分布情况，那么这一数据就可以用于估计新项目的工作量。
2.2  过程能力基准
PDB保存每个项目的有关数据，而过程能力基准表示在某些时间点上过程能力的量化瞬态图。
实质上，过程的能力是指在遵循过程的情况下可对项目期望的结果范围。
如果按规定建立了基准，则可以轻松地获得过程能力的趋势——这就是需要有一个PCB的主要原因。
PCB应当包含哪些内容
–    已交付软件的质量、生产率、进度计划、工作量分布、故障引入率、过程中故障排除效率、质量成本、故障分布
PCB信息可用于项目规划。例如，
–    项目经理可以用生产率和预测的规模来估算项目的工作量，可以用工作量的分布情况预测各阶段的工作量并制定人员分配计划。
–    同样，可以用故障引入率预测总的故障数，用故障分布预测各故障检测任务检测到的故障数。
–    总故障排除效率或者质量可以用来预报软件交付以后可能出现的故障数，并制定维护计划。
2.3  过程资源和知识库系统
过程描述通常包含要执行的步骤序列，标识出谁将执行它们，规定主要步骤的开始标志和结束标志等等。
为了简化过程的使用，通常可以使用指南、检查表和模板提供的支持，这些材料总称为过程资源（process assets）。
过程资源
指南（guidelines）通常给出执行某个步骤的规则和程序。例如，项目规划过程中的一个步骤是“工作量估计”。为了执行这一步骤，项目经理需要参照相应的指南。
检查表（checklists）通常有两种类型：任务检查表和评审检查表。
–    任务（activity）检查表就是构成一个过程步骤的任务列表。
–    评审（review）检查表的目的是使评审人员对可能在产品中发现的故障引起注意。
模板（templates）实质上提供了一个能够记录过程或者步骤结果的文档结构。
过程资源的主要目的
这些过程资源的主要目的是简化过程的使用，减少工作量，从而提高生产率。
–    例如，用模板建立文档比从头开始建立文档要更加容易，而且所需的时间也更少。
这些资源也有助于改进项目的质量。
–    首先通过提供正确的指南和任务检查表，使引入的故障数最少；然后通过辅助评审，从而更加容易地捕获引入的故障。
为了使项目执行从面向过程的方法中取得最大的效益，关键是保存并使用过程资源。
–    在Infosys公司，所有的指南、检查表和模板都放在网上共享，并定期对它们进行更新。

第3章  过程规划
引言
在许多其他项目中也会出现与此非常雷同的情况。在实际情况中，几乎不存在某个标准过程或者以往某个项目所用的过程是最适合于当前问题的过程。为了找到最合适的过程，就要根据新问题对现有过程进行裁制。
3.1  Infosys开发过程
软件开发模型
软件开发存在几种过程模型。最常见的模型包括瀑布模型、迭代式增强模型、原型法开发模型和螺旋模型。
使用最广泛的模型是瀑布模型，它按线性顺序组织各开发阶段，但是大多数实现都对这个模型进行了改进, 以使它的缺陷最小。

为了决定使用哪种过程，项目经理必须选择基本过程，同时还要决定如何对它进行裁制以得到适合项目的过程。
3.1.1  标准过程
Infosys公司采用的标准过程类似于瀑布模型，但是原来的各个阶段被划分成更小的阶段，或者说状态，以允许并行地执行某些阶段。
例如，可以将系统测试的规划定义为系统测试 本身的一个独立的阶段，这是一种使团队可以并行地执行系统测试规划阶段和编码阶段的实践，尽管系统测试在编码完成后才进行。
该标准过程的各阶段包括需求分析、概要设计、详细设计、构建、单元测试、集成计划、集成、系统测试计划、系统测试、文档、验收和安装、维护支持。
对于进行迭代式开发或者原型法开发或者仅执行生命期中某些阶段的项目，也可以采用该基本过程。在这些情况下，需要对这个基本过程加以调整才能满足项目的需要。这些调整通过过程裁制（process tailoring）完成。
3.1.2  过程裁制
任何一个已定义的过程（不管是一个组织的标准过程，还是以往某个项目采用的过程）都不能完全满足所有的情况和所有的项目。
已定义的过程需要经过裁制才能满足当前项目的需要。
裁制是指调整组织以前定义的过程以获得一个适用于某个项目的特定业务或者技术需要的过程。
可以将裁制看成添加、删除、修改一个过程中的任务，使得最终的过程更加适于实现项目的目标。
为什么需要裁制指南
不受控制的裁制实际上意味着从头开始建立一个过程。
为了有效地使用以往定义的过程，有必要提供一些裁制指南。
–    这些指南定义了应当对一个标准过程进行修改的条件和类型。
–    实质上，指南定义了标准过程允许的偏差（permitted deviation），希望能够为项目定义一个较优的过程。
裁制的必要性例: 代码评审
为了说明裁制的需要，让我们看看开发过程构建阶段中的一个任务——代码评审。
在许多情况下代码评审会大大地增加价值，但是增加的价值并不与所需的工作量相称。
此外，评审既可以由一个小组完成（遵循小组评审程序），也可以由一个人完成。
标准开发过程没有规定应当如何执行代码评审。
通过只为某种类型的程序（例如复杂程序或外部接口）建议执行代码评审任务和建议较优的评审方式（小组评审，或者个人评审），裁制指南能够为项目经理提供帮助。
Infosys公司采用的裁制方法
Infosys公司采用的裁制方法类似于金斯伯格（Ginsberg）和奎因（Quinn）提出的基于表的方法，项目经理规定过程要素、可裁制的属性、每个属性的选项以及选择特定选项的原因。
项目经理可以在两个层次上执行裁制：概要级裁制和详细级裁制。
概要级裁制（Summary-Level Tailoring）
在概要级裁制，项目经理根据项目特征，应用总体指南对标准过程进行裁制。即，它提供了一些关于某些类型的详细任务的基本规则。执行该步骤时，项目经理首先标识出项目的某些特征。对于开发项目，过程裁制将用到如下特征：
–     团队和项目经理的经验和熟练程度
–     团队人数最多时的人数
–     需求透明度（clarity of the requirement ）
–     项目持续时间
–     应用的关键程度
特征值的确定
如果团队的大部分成员对项目所采用的技术有2年以上的经验，则设定这个团队的经验水平为高；否则为低。
如果应用程序对客户的业务或者Infosys公司的业务有非常显著的影响，则设定应用的关键程度为高，否则为低。
如果项目必须在3个月内完成，则认为项目的持续时间非常短。
对于这些特征的不同值，都提供了概要级裁制指南。概要级裁制指南一般与评审、工作量、进度计划、资源及过程形式化有关。
与评审有关的裁制指南通常规定什么时候执行评审以及应当执行什么类型的评审。这些基本指南规定了详细级过程裁制的环境，并为项目定义了一个合适的过程。
详细级裁制（Detailed Tailoring）
详细级裁制涉及任务的执行、任务的评审和文档化需要。
裁制指南可规定一个任务是可选任务，若任务是可选的，则项目经理可以决定是否执行该任务。
同样，某些文档的准备也可以是可选的，如果文档是可选的，则项目经理可以决定项目是否需要该文档。
对于评审，一般有小组评审、个人评审和不评审。此外，项目经理也可以增加一些新的任务或者可以重复某些任务。
详细级裁制完成后，项目过程要执行的任务序列就定义好了。然后，这些定义就可以用来规划和调度任务，构成项目执行的基础。
因为裁制的执行是项目计划中最重要的任务，所以在评审计划时也要评审过程定义和裁制。
3.1.3  裁制示例：短期项目的裁制
我们通过介绍短期项目的概要级裁制来说明裁制的概念。
Infosys公司注意到软件项目的持续时间在逐年下降，并且对持续时间非常短的项目的需求有所增加。
显然，这种项目要求对标准过程进行裁制，以允许最大程度地并行执行和非常严格的项目监督和控制。
过程裁制取决于需求的透明度、团队和项目领导的经验水平、团队的规模等等。
因为进度计划的主要特征是短期性，所以与进度有关的指南建议采用所谓的时间盒控制法（timeboxing）技术和微型里程碑。
对于时间盒控制法，规划以几周为限的周期，并在每个周期结束后交付一个工作系统。
为了严格控制时间盒，还要设定微型里程碑（周期内的里程碑）。在微型里程碑处，只需进行有限的里程碑分析。
3.2  需求变更管理
需求会发生变化，并且需求的变更可以在项目生命期的任何时间发生（甚至在项目生命期结束后发生）。
需求变更越是在生命期的后期发生，对项目的影响越严重。
除了希望不会发生那样的变更，或者希望初始需求做得非常完善并不需要任何变更外，更好的做法是在出现需求变更时处理变更申请。
不受控制的需求变更会对项目的成本、进度和质量产生有害的影响。需求变更最多可以占总成本的40%。
例1:
拉维意识到迫切需要一个需求变更管理过程。
–     为努力使客户感到满意，他欣然同意客户申请的变更。
–     由于没有对变更申请加以控制，因此项目经历的需求变更越来越频繁。
–     最后，团队成员不得不每周工作60 小时，并且工作量增加100% 以上，拉维才勉强地完成了项目。
–     更糟的是，他发现客户仍然感到不满意，因为他认为变更的越多会使产品更好。
例2:
在另一个项目中，玛丽（Mary）是一位经验丰富的项目经理，她记录客户每次通过电话或者e-mail发出的变更申请，然后告诉客户有关变更申请对工作量和进度产生的影响。
不仅变更申请的频度随时间减少了，而且客户将很多申请转移到下一个版本中去实现。
最终结果如何呢？项目按时完成，客户感到很满意，并且为实现变更申请导致的额外工作量付费。
3.2.1  变更管理过程
在项目规划期间，项目经理决定遵循哪个过程来处理变更申请。计划的过程要与客户进行讨论，以便客户和厂商在如何管理变更方面取得一致意见。
通常，变更管理过程规定如何发出变更申请、何时需要正式批准，等等。在出现需求变更申请时，必须执行需求变更管理过程。
因为变更申请意味着需要额外的工作量，所以必须在额外的工作量支付方面取得一致意见。
通常，在客户认可的情况下，项目必须在实现变更申请方面留有一定的余地（通常占总的项目工作量的小百分比）。
这样一种预算条款简化了实现客户认可的变更申请的管理问题。
Infosys公司常用的变更管理过程
Infosys公司常用的变更管理过程包括如下步骤：
（1）记录变更。
（2）分析变更对工作产品的影响。
（3）估计变更申请所需的工作量。
（4）重新估计交付时间表。
（5）执行累积的成本影响分析。
（6）如果影响超出一定限度，则与高级主管一起评审影响。
（7）客户不再提出变更申请。
（8）修改工作产品。
变更申请日记
维护一个变更申请日记，以跟踪变更申请。
日志中的每条记录包含一个变更申请号、关于变更的简单描述、变更的影响、变更申请的状态以及关键日期。
在评估变更申请的影响时，必须执行影响分析。
影响分析涉及标识出需要进行变更的工作产品，并估算对每种产品的变更量；通过重新查看风险管理计划，重新评估项目风险；评估需求变更蕴涵的总的工作量和进度估计的变化。
客户对分析结果进行评审，并作出答复。
变更申请一般作为需求规格说明文档的附件。有时还要修改文档的有关部分以反映所做的变更。
监督已认可的变更申请并保证它们正确实现，这部分由配置管理过程处理。
实现变更所需的总工作量
如果实现变更所需的总工作量不超过某个预先确定的值（例如，2人日），则认为此变更是次要的。
–    次要变更通常作为项目工作量的一部分，利用计划的估计中预留的缓冲工作量。
主要变更通常对工作量和进度有更大的影响，并且必须得到客户的正式批准。
高级主管通过状态报告和里程碑报告掌握变更情况。
变更的累积影响
需求变更的一种危险是：尽管每种变更本身并不大，但是生命期中所有变更的累积影响却是很大的。因此，除了研究每个变更的影响并对它们进行跟踪外，还必须监督变更的累积影响。
对于累积变更，可以使用变更日志。为了简化这一分析，通常用电子表格对日志进行维护。
从这种类型的电子表格中，你可以直接看出目前已完成的需求变更的总成本。
前面提到过，Infosys公司的项目经理有时为处理变更申请预留一定的余地。
–     只要所有变更累积的工作量不超过这一预留的工作量，就不需要做任何特殊的处理。
–     然而，如果所有变更的累积工作量超过了这一预留的工作量，则再进行变更可能会对总成本和进度安排产生负面影响。在这种情况中，项目经理必须修改估计并使它们得到承认。

3.3  ACIC项目的过程规划
因为ACIC项目是一个开发项目，所以遵循标准的Infosys开发过程。
然而，对它进行了裁制以满足Rational统一过程（Rational Unified Process，简称RUP）方法的需求，因为向客户承诺使用RUP。
–    RUP是一种迭代式开发方法。
Infosys公司采用的过程裁制指南支持迭代式地执行不同阶段，但要在每次迭代中执行分析、设计、编码和测试任务。
对标准过程所做的主要修改
除了进行迭代式开发外，为了满足RUP方法，需对标准过程做如下主要修改：
–    只有在特定迭代中开始使用的用例才在该迭代中进行详细描述。
–    在最初几次迭代中，增量式地开发逻辑对象模型和物理对象模型。
–    物理数据库设计可以在以后的迭代中进行细化。
–    每次迭代将开发一个单元测试计划。
–    记录每次迭代过程发现的故障。
此外，不准备用标准的可跟踪性矩阵机制进行需求跟踪。相反，将用Requisite Pro工具跟踪需求，该工具是开发环境的一部分。
需求变更管理将使用标准过程。
尽管在每次申请时都进行影响分析，但是，如果一个变更申请可能要占总工作量的2%以上时，则必须对影响进行重新估计。
过程规划结果在项目管理计划中进行记录。

第4章  工作量估计和进度计划

引言
在很多工程方面，不正确的估计是项目管理失败的根源；软件工程也不例外。
当Infosys公司总经理南丹•尼尔克尼（Nandan Nilekeni）被问及他希望项目所需具有的一样特性时，他回答道：“没有意外”。
–    在客户满意度方面没有意外，
–    在收入和利润方面没有意外。
一个项目出现这两方面的意外多半是由于工作量或者进度估计不准确。
对于估计问题既没有特效的办法，也没有现成的办法。然而，项目经理可以采用经以往的经验和数据验证过的指南来提高估计精度。
4.1  估计和进度安排概念
工作量估计通常在项目的初期进行，即在明确了所要构建的软件时。
但是在项目后期有更多的信息可供参考时，也可能要对工作量进行重新估计。
工作量估计可以根据直觉，也可以根据以往的经验，但是一种更加科学而理想的方法是采用估计模型。
软件项目中合理的估计很容易变成一种自我实现的预言: 人们努力地去满足进度计划（进度计划是从工作量估计中推断出来的）。
–    在软件项目中，甚至没有人能够精确地回答这样一个问题：“这种估计是正确的吗？”因为判断某个估计正确性的惟一办法是将它同实际所需的工作量进行比较。
–    由于人类心理学“在有效的时间内尽量扩大工作量”的原则中反映的基本原则，因此我们不能仅仅因为扩展后的工作量满足了估计的工作量就认为估计是正确的。
因此，项目经理的目标是制定合理的估计，既使目标得到满足，又不至于让项目人员感到筋疲力尽。
4.1.1  工作量估计模型
软件估计模型（estimation model）定义它所需的项目特征（需要这些特征的值或者它们的估计）以及用这些值来计算工作量的方法。
4.1.2  进度估计
在工作量已经知道或者确定以后，根据项目投入的资源（人员）量，就可以制定各种进度计划（即项目的持续时间）了。
–     例如，对于一个工作量估计是56 人月的项目，则一个7 个人工作8 个月的进度计划是可能的。
–     一个由8 个人工作7 个月的进度计划也是可能的，
–     当然由6 个人工作9 个多月的时间也是可以的。
然而，众所周知，在一个软件项目中，人力和月工作时间并非总是可以互换的。
–     例如，在上述例子中，一个56 个人工作1 个月的进度计划是不可能的，尽管其工作量“ 满足” 需求。
–     同样，也不会有人制定让2 个人工作28 个月的进度计划。
–     换句话说，在工作量确定以后，通过合理分配项目所需的人员，就可以灵活地设置进度计划。但是这种灵活性也不是毫无限制的，事实表明在工作量和进度计划之间不存在符合经验数据的简单方程。
“拉长”进度很容易；你只要投入更少的人员即可（尽管在很长一段时间内完成项目可能没有多大价值）。
然而，压缩进度却不容易。前面所举的例子已明确表明：你不能将一个56人月的项目进度压缩成1个月完成的项目，即使增加足够的人员也不行。
一种确定正常（或者额定）进度的方法是使用合适的函数从工作量中确定它。而一种确定合适的函数的方法是研究已完成项目的模式。
例如，你可以画出已完成项目的工作量和进度的分布图，然后通过此分布图拟合一条回归曲线。此曲线一般是非线性的，因为进度并非随工作量线性增长的。然后你就可以用曲线方程确定已知估计工作量的项目的进度计划。
许多模型遵循这种方法。
4.2  工作量估计
在Infosys公司，工作量估计一般在需求分析之后进行。
–     在项目经理估计工作量之际，已经对需求有了很好的理解。
–     需求分析阶段有时可以作为软件开发项目的一个独立的项目进行执行。
在Infosys公司，提出了多种估计方法，本节将讨论其中的一些方法。
项目经理可以根据工作性质选择使用任何一种估计方法。
在某些情况下，项目经理可以用多种方法进行估计，即可验证其主要估计方法的正确性，也可减少风险；
–     尤其在以往同类项目的数据有限的情况下，更要采取多种方法进行估计。
4.2.1  自底向上的估计方法
因为Infosys公司所承担的项目千变万化，所以自底向上方法倍受青睐，并且公司也推荐使用这种自底向上的方法。
在已知上述三种复杂性类别的单元数并选定了每个程序估计的构建工作量后，就可以求得项目构建阶段的总工作量。
根据构建工作量，其他阶段和任务所需的工作量就可以根据它们占编码工作量的百分比而求得。
这种方法必须做到经验和数据的有机结合。
如果没有合适数据（例如一种新的项目类型），可以在对项目进行分析以后，并且在知道各种程序单元的情况下，根据经验估计构建工作量。
估计了构建工作量之后，根据以往项目的工作量分布数据，就可以求得其他任务的估计工作量。
该方法甚至还能解决那些在项目初期很难列出并且确实很费劲的任务的工作量估计。
在项目的工作量分布中，“其他”分类通常用来处理混杂的任务。
综上所述，估计过程可以用如下步骤进行概括：
（1）标识出系统中的程序，并分类为简单程序、中等复杂程序或者复杂程序（Simple, Medium, or Complex, 简称S/M/C）。尽量采用标准定义或者以往项目的定义进行上述分类。
（2）如果存在项目专用的基准，则根据基准求得S/M/C程序的平均构建工作量。
（3）如果不存在项目专用的基准，则用项目类型、技术、语言及其他属性查找过程数据库中类似的项目。然后，用这些类似项目中的数据定义S/M/C程序的构建工作量。
（4）如果过程数据库中不存在类似项目，也不存在项目专用的基准，则应用基本过程能力基准中S/M/C程序的平均构建工作量。
（5）用项目特有的因素精化S/M/C程序的构建工作量。
（6）用S/M/C程序的构建工作量及其程序数求得总的构建工作量。
（7）用能力基准中给定的工作量分布情况或者过程数据库中给定的类似项目，估计其他任务的工作量和总工作量。
（8）基于项目特有的因素精化估计。
4.2.2  自顶向下的估计方法
与任何一个自顶向下的估计方法相同，Infosys公司采用的方法从以功能点为单位的软件规模估计开始。
功能点可以用标准的功能点计数规则进行计数。
–     另外，如果已知以LOC 为单位的估计规模，则可以将它转换为功能点规模。
除了规模估计外，自顶向下的方法还要估计生产率。基本方法是以同类项目的生产率水平开始（这种数据可以从过程数据库中得到）或者以标准生产率值开始（这种数据可以从过程能力基准中得到），然后根据需要对那些值进行调整，满足项目的需要。
然后，使用生产率估计来计算总的工作量估计。
利用总的工作量估计，根据各阶段工作量的百分比分布求得各阶段估计的工作量。（同自底向上的方法一样，这些工作量分布数据从过程数据库或者能力基准中得到。）
总结: 自顶向下估计方法涉及如下步骤：
（1）求得以功能点为单位的软件的总规模。
（2）使用项目专用的能力基准、基本的过程能力基准或者同类项目的生产率数据，确定项目的生产率水平。
（3）根据生产率和规模估计求得总的工作量估计。
（4）使用过程能力基准或者同类项目中的工作量分布数据估计各阶段的工作量。
（5）考虑项目特有的因素，精化工作量估计。
同自底向上的估计一样，自顶向下的估计方法允许用项目特有的因素进行精化。
–     实际上，这种精化没有定义确定的因素，而是承认每个项目都有特殊性，它们可以有一些其他项目所没有的特征。
–     列出这些特征对生产率的影响，或者形式化地表示这些特征对生产率的影响，这也许是不可能的。因此，必须由项目经理确定应当考虑哪些项目因素，以及它们如何影响项目。
4.2.3  用例点方法
Infosys公司采用的用例点方法基于Rational公司的方法，并且类似于功能点方法。如果将用例用于需求规范，则可以应用这种方法。这种方法的基本步骤如下：
（1）将每个用例分类可以分为简单用例、中等复杂用例和复杂用例。
–     这种分类的基础是用例中的事务数，包括辅助脚本。
–     事务定义为任务的原子集，要么全部执行，要么一个都不执行。
–     一个简单用例有3 个或者3 个以下事务，一个中等复杂用例有4 ～7 个用例，而一个复杂用例有7 个以上的事务。
–     其中简单用例分配因子为5 ，中等复杂用例分配因子为10 ，而复杂用例分配因子为15 。
（2）根据应用中用例因子的加权和求得总的未经调整的用例点（unadjusted use case point，简称UUCP）。
–     即，对于三种复杂性用例分类中的每一类，首先求出某个特定复杂度的用例数与该复杂度的因子的乘积，然后求出三个乘积的总和即为应用的UUCP 。
（3）调整原始UUCP以反映项目的复杂性和项目工作人员的经验。
–     为此，首先通过查阅表4.2 中给定的因素并用0 ～5 评定每个因素，计算技术复杂性因子 （technical complexity factor ，简称TCF ）。
评定值为0 表明因素与项目无关；而5 则表示必不可少的因素。
–     对于每个因素，用表中的权重乘以其评定值；然后将这些结果值加起来就得到了TFactor ，然后就可以用如下方程求TCF ：
TCF = 0.6 + (0.01 × TFactor)
（4）同样，通过查阅表4.3并用0～5评定每个因素，计算出环境因子（environment factor，简称EF）。
–    对于与经验有关的因素，0表示没有该主题的经验，5表示专家水平，而3则表示平均水平。
–    对于积极性，0表示没有项目积极性，5表示积极性高，而3则表示平均水平。
–    对于需求的稳定性，0表示非常不稳定的需求，5表示不变的需求，而3则表示中等稳定程度。
–    对于兼职型工作人员，0表示兼职型技术人员，5表示全职工作人员，而3则表示平均值。
–    对于编程语言的难度，0表示易掌握的编程语言，5表示非常难的编程语言，而3则表示一般难度的编程语言。
–    上述因素的加权和给出EFactor，而EF可以通过如下方程求得：
EF = 1.4 + (-0.03 × EFactor)
表4.3  团队的环境因素及其权重
（5）用上述两个因子，用下式求出最终的用例点（use case point，简称UCP）：
UCP = UUCP × TCF × EF
进行工作量估计时，一般在整个生命期中为每个UCP分配20人时，由此得出的估计是很粗的。
需要对它按如下步骤做进一步精化。
–     计算有多少个因素的值小于3 ，有多少个因素的值大于3 。
–     如果值小于3 的因素总数很少，则每个UCP 分配20 人时是合适的。
–     如果有很多，则每个UCP 分配28 人时。
–     换句话说，每个UCP 分配20 ～28 人时，而项目经理可以根据各种因素决定使用哪个值。
4.2.4  估计方法的有效性
分析估计方法有效性的一般方法是比较估计的工作量与实际工作量。
前文已经讨论过，这种比较只能给出一般的估计精度；它不能指明估计方法有多优。
为了获得这种信息，必须研究估计对程序员的影响（例如，他们是“过分紧张”还是“未充分发挥作用”。）
如图，估计方法效果很好；大部分数据点接近于45度线（如果所有估计都匹配实际工作量，则所有点都将落在45度线上。）
图中的数据还表明：50%以上的项目的估计工作量误差不超过25%。
数据表明估计工作量通常低于实际工作量；
–     注意大部分点在45 度线以上，而不是在45 度线以下。
–     人们更易出现估计不足—— 这通常使软件业倍受折磨。
–     实际工作量平均比估计的工作量高25% 。
–     尽管还有改进的余地，但是估计方法已是相当有效了。
4.2.5  ACIC项目的工作量估计
现在，我们通过例子说明估计方法，说明其在ACIC项目中的应用。
ACIC项目采用用例驱动的方法。因此，主要根据用例进行分解，而不是根据模块。
为了对用例进行分类，项目经理采用了分类标准。
为了估计不同类型用例的构建情况，ACIC项目经理借鉴了Synergy项目的数据。
–    Synergy项目有21个简单用例、11个中等复杂用例和8个复杂的用例。
根据不同用例的详细构建数据，估计平均构建工作量。
–    （总的构建工作量大约为143人日。简单用例、中等复杂用例和复杂用例的平均构建时间分别是1人日、5人日和8人日。总的估计构建工作量为140人日，非常接近于实际的构建工作量。）
在这个项目中，除了按自底向上估计方法进行估计外，项目经理还采用了用例点方法。
–    前文已经讨论过，每个简单用例分配因子为5，每个中等复杂用例分配因子为10，每个复杂用例分配因子为15，所以据此可以得出UUCP。
–    因为简单用例、中等复杂用例和复杂用例分别有5个、9个和12个，所以可以得到：
UUCP = 5×5 + 9×10 + 12×15 = 295
因为需要考虑各种因素，
首先，ACIC项目经理要为技术复杂性分配权重，并求得技术复杂性因子。他选择了如下因子值（按表4.2给定的顺序）：4，3，5，3，4，5，5，0，4，1，2，0和5，计算TFactor值为40（8+3+5+3+4+2.5+2.5+0+4+1+2+0+ 5），TCF为1.0。
接着，他计算环境因子。他为环境因素分配了如下因子值：3，1，3，4，5，5，0和3；最终的EFactor为22（4.5+0.5+3+2+5+10+0-3），EF为0.74。
根据上述条件，他计算出总用例点如下：
UCP = 295×1.0×0.74 = 218.3
使用标准工作量值20人时/UCP，求得了工作量估计如下：
218×20=4 360人时=499人日（8.75小时/天）
或者
513人日（8.5小时/天）
这些估计惊人地接近于当初的估计，增强了项目经理对估计的信心。
4.3  进度计划
Infosys公司的进度安排任务可以分解成两个子任务：一个子任务是确定总的进度计划（项目持续时间）及主要里程碑，另一个子任务是制定各种任务的详细进度计划。
4.3.1  总的进度计划
在本章前面已经讨论过，通过控制人员分配情况可以灵活地确定进度计划，但是这种灵活性是有限的。
–     由于这种灵活性的存在，因此建立严格的进度计划指南可能并非可取；
严格的指南失去了项目或者客户应有的灵活性优势。
–     此外，项目进度计划通常在更大的商业计划环境中进行确定，这就会强加一些进度要求。
只要有可能，你应当灵活地利用进度来满足这种需求。
–     一种可取的方法是使用进度计划指南 来检查进度计划的灵活性，而不是用来确定进度本身。
图4.2给出了Infosys公司的一些已完成的开发项目的进度和工作量的分布图，同时给出了此分布图非线性回归拟合曲线。
图4.2中的曲线方程如下：
进度=23.46(工作量)0.313
从数据点的分布情况可以看出，显然进度不仅仅是工作量的函数。
所确定的进度可以用作进度合理性的标准或者凭据，这也可以根据其他因素来决定。
同类项目的进度和工作量数据可以用来检查任何建议进度的合理性。
项目经理通常用所谓的平方根检验经验方法来检查中等规模项目的进度。
–     其原则是建议的进度应当在以人月为单位的总工作量的平方根左右；如果资源分配给项目，则进度能够得到满足。
–     例如，如果估计的工作量为50 人月，则一个由7 ～8 个专职人员工作7 ～8 个月的进度计划比较合适。
由于进度和资源之间的关系，只有在项目所属的业务部门的主管同意提供所需的资源时，才能接受一个进度计划。
如果没有所需的资源，则必须对进度计划作出调整。
在接受一个进度计划前还要检查项目的依赖性。
–     如果项目执行依赖于外部因素（诸如另一个项目的完成或者存在某种软件），则必须对进度作出调整以适应这些因素。
一旦确定了项目的总期限，就必须确定主要里程碑的进度计划。
为确定里程碑，首先必须理解一个项目中经常出现的人力分配情况。
软件项目中的人数基本上遵循瑞利曲线。
–    在项目开始和结束时，项目的工作人员很少；而在项目中期前后达到团队最多的人数（peak team size，简称PTS）。
–    这种行为之所以发生是因为在需求分析和设计的初始阶段只要几个人参加就可以了。而在编码和单元测试时人力资源达到顶峰。在系统测试和集成时，所需的人员更少。
–    在许多情况下，人员分配情况不会经常变动，但是近似于瑞利曲线：在开始时分配几个人员，在构建阶段达到顶峰，然后只需留下少数人进行集成和系统测试。
如果将设计、构建和测试作为三个主要阶段，并且它们的需求分析已经完成，则项目的人力分配情况通常类似于图4.3所示的函数。
在Infosys公司，通常遵循这种资源分配方法。
–     在开始和结束阶段只分配很少一部分人，而在构建阶段分配最多人数。在构建阶段，通常达到项目的PTS 。
为了使进度安排更加容易，尤其是更小规模的项目，所有需要的人员通常在项目开始时分配。
这种方法会导致一些人在开始和临近结束时比较空闲。这时通常用于培训。
–     通常需要对项目所用的技术和业务领域进行培训，并且这一培训会占用大量工作量，这可以从PCB( 过程能力基准) 给定的工作量分配情况中看到。
–     同样，项目临近结束时的空闲时间可用于文档处理和其他结尾任务。
进度分配不同于工作量分配。
–    构建阶段占进度的百分比少于其占工作量的百分比，因为这一阶段牵涉到更多的人员。
–    设计和测试阶段占进度的百分比大于它们占工作量的百分比。
确切的进度依赖于计划的人力分配。在给定一个阶段的工作量估计的情况下，知道了人力分配后就可以确定各阶段的持续时间。
一般而言，设计大概占进度的40%（20%用于概要设计，20%用于详细设计），构建占40%，而集成和系统测试占20%。
设计、构建、集成和测试阶段的人力分配分别是1∶2∶1（因此这些阶段的工作量分配为1∶2∶1）。
这些指南提供了确定里程碑的标准，当然里程碑也可以根据其他约束进行设置。
必须考虑到，即使将一个人专门分配到一个项目中，他通常也会从事一些既耗时又于项目无益的任务。
–     这些任务包括休假、公司任务、基本培训（不是项目特设的培训）、其他项目的评审等等。
4.3.2  估计方法的有效性
与工作量估计一样，一种检查进度估计好坏的方法是画出估计的进度与实际的进度，并查看这些点离45度线有多近。
–    如果所有点都非常接近45度线，则可以认为进度安排方法是有效的。
可以看出，进度安排方法将产生与实际进度非常匹配的进度。
可用其他因素来确定是否满足了估计的进度。
4.3.3  详细的进度计划
一旦确定了里程碑和资源，就该设置详细的进度安排。
项目经理将任务分解成可调度的任务，形成一个层次结构。
对于每个详细的任务，项目经理估计完成它所需的时间并分配合适的资源，以满足总进度。
在分配资源方面，必须考虑各种因素，诸如团队成员的休假计划、个人成长计划和职位升迁、个人技能和经验、培训和顾问需要、任务的紧急程度，以及从某个任务中获取经验以后对项目有什么价值。
进行每一级精化时，项目经理在详细的进度计划中根据工作量估计检查总任务的工作量。
如果需要，对详细估计进行调整。
–     例如，可能将详细设计阶段分解成多个任务，诸如开发每个模块的详细设计、评审每个详细的设计、修复所发现的故障，等等，并且还可以对上述任务做进一步分解。然后，为这些任务安排时间，并分配在某个时间段内所需的资源。
如果这种详细的进度计划与详细设计的总进度和工作量估计不一致，则必须变更详细进度计划。
如果发现最好的详细进度计划不能满足里程碑的工作量和进度，则必须修改早期的估计。
因此，进度计划是一个迭代过程。
通常，项目经理将任务细化到一定程度，使最低级的任务不会对一个单独的资源占用很多天。
此外，还要增加基本任务，诸如项目管理、协调、数据库管理和配置管理等。
–     这些任务对进度基本上没有直接影响，因为它们是附属的任务。
–     另外，由于它们消耗资源，因此必须在项目的进度计划中考虑它们。
项目经理几乎不太可能一次性完成整个项目的详细的进度计划。
一旦确定了总进度，就有可能只在每个阶段开始时执行那个阶段的详细进度计划。
对于编制详细的进度计划，项目经理通常采用Microsoft Project（MSP）或者电子表格。
–     对于每个最低级的任务，它们规定工作量、持续时间、开始日期、结束日期和资源。
–     对于每个任务，他们还规定任务代码、程序代码以及模块代码。
–     他们还可以规定任务间的依赖性，要么是内在的依赖（例如，你只能在程序编码完成以后才能对它执行单元测试计划），要么是与资源有关的依赖（同一个资源分配给两个任务）。
一个详细的项目进度计划绝不可能是静态的，有时可能需要做某些变更，因为项目的实际进展可能不同于计划，
–     可能是为了满足变更申请的需要增加新的任务，
–     或者因为发生其他不可预见的情况。
–     总之，只在需要的时候才变更。
根据MSP或者其他一些工具所记录的那样，最后的进度计划是最“有效的”项目计划文档。
在项目执行期间，如果必须修改计划，必须完成其他任务，则在做出决策后，任何修改都反映在详细的进度计划中。
因此，详细的进度计划成为跟踪任务和进度的主要文档。
详细进度计划也是项目监督的主要输入，我们将在第11章进行讨论。
4.3.4  ACIC项目的进度计划
让我们以ACIC项目为例。
前文已经讨论过，ACIC项目估计的工作量是501人日，即大约24人月。客户要求用大约5.5个月完成该项目（从5月15日到11月3日）。
–     该期限大于以人月为单位的工作量的平方根( 比较松),
–     并且需求收集必须在项目开始前完成( 一部分工作先完成了) ，
–     所以接受了这一进度计划。

第5章  质量规划
直到最近几年，软件工程才经受到了制造业在很早以前就已经受过的悲剧般的质量概念——质量是在装配/开发过程结束之后但在产品即将交付使用前完成的任务。
一些有质量意识的项目经理通常计划在开发过程结束后进行系统测试，但是在开发时却不重视质量控制任务，而另一些项目经理甚至连正确的系统测试计划都没有，这是很常见的情况。
结果怎样呢？系统测试往往会发现比期望的故障多得多的故障。而修复这些故障所需的工作量也往往比计划的要更多，最终导致软件的bug很多，并且交付日期也比计划的要晚。
随着情况的好转，项目经理开始作评审与单元测试的规划。
但他们不知道如何判断这些措施的有效性及其所需的成本。
换句话说，项目仍然缺乏明确的质量目标、令人信服的目标实现计划，以及监督诸如单元测试等质量控制任务的有效性的机制。
在合理利用度量标准和以往数据的情况下，就有可能在对待质量问题上如同对待另外两个重要的参数那样：工作量和进度。
即，可以设置定量化的质量目标，以及有助于跟踪项目的质量目标实现情况的子目标。
本章讨论Infosys公司的项目经理如何设置项目的质量目标，如何制定实现这些目标的计划（这些计划用中间质量目标监督质量目标的实现情况）。
在描述Infosys公司采用的方法之前，我们先简单地讨论一些有关质量管理的基本概念。
5.1  质量概念
确保最终交付的软件高质量是项目经理最关心的事情之一。但是，如何定义软件质量呢？
软件质量概念不容易定义，因为软件有很多质量特征。
实际上，质量管理通常围绕故障而展开。因此，我们用已交付软件的故障密度作为软件质量的定义——即，已交付软件中每个单位规模的故障数。
此定义是当前业界的事实标准。之所以用它定义软件质量，是为了表明软件项目的目标是使交付的软件具有尽量少的故障。
那么，何谓故障呢？
同样，也没有关于故障的通用的且广为接受的精确定义（如果一个软件拼错了一个词，是否认为该软件有一个故障呢？）。
通常，我们认为软件的故障是某种使软件表现出与客户的要求或者需要不一致的方式进行运转的问题。
在考虑质量的管理技术之前，必须先知道故障引入和排除周期。
软件开发是一种高度依赖于人的任务，因此很容易出现错误。
故障可以在软件过程的任何阶段引入。
这些引入阶段主要有需求规格说明、概要设计、详细设计和编码。
对于高质量的软件，要求最终产品含有的故障数应尽可能地少。
因此，为了发行高质量的软件，必须积极排除故障；这可以通过评审和测试等质量控制任务而实现。
故障排除的成本随着故障潜伏时间（从故障引入到检测到这个故障的时间间隔）的增长而增加，任何成熟的过程都将在每个可能引入故障的阶段之后执行质量控制任务。
故障排除任务包括需求评审、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试（我们没有包括计划文档的评审，但是这种评审也有助于改进软件的质量）。

质量管理的任务是规划合理的质量控制任务，然后正确地执行和控制它们，以实现项目的质量目标。
5.1.1  质量管理的过程化方法
前文已经提到过，通过执行评审或者测试可以检测故障。
评审是结构化的、面向人的过程，而测试是以一种试图识别出故障的方式执行软件（或者软件的一部分）的过程。
在质量管理的过程化方法中，评审与测试任务的过程和指南是既定的。
在一个项目中，这些任务都经过规划（即，执行哪个任务及什么时候执行是确定的）；执行时，根据已定义的过程实现这些任务。
总之，过程化方法在已定义的点上执行某些检测故障的过程。
过程化方法不支持声明已排除了多少故障或者故障排除过程结束后的软件质量。
换句话说，只执行一系列的故障排除过程不能提供判断它们的有效性或者评价最终代码质量的基础。
此外，这种方法高度依赖于过程的质量及过程执行的质量。
–    例如，如果周详地完成了测试计划，并且对该计划进行了全面的评审，则在执行测试后的软件质量与经过测试但是测试计划考虑不周并评审草草完成的软件质量相比，显然前者要比后者的质量更高。
过程化方法的一个主要缺点是项目经理缺乏定量化的手段来评价软件的质量。项目经理惟一能够看到的因素就是质量控制任务是否已经执行了。
5.1.2  质量管理的定量化方法
为了更好地评估故障检测过程的有效性，不仅要问“已经执行这种方法了吗？”还要根据指标数据进行评估。基于这种数据分析，你可以决定是否需要进一步的测试和评审。如果执行项目时应用的控制基于定量数据实现定量化的质量目标，则我们认为项目使用了定量化的质量管理方法。
定量化质量管理涉及到2个主要问题：一个是设置定量化的质量目标，另一个是定量化地管理软件开发过程以满足这一质量目标（具有高可信度）。
一个良好的质量管理方法应当在项目早期发出警告信号，而不仅仅是在临近项目收尾时发出警告信号，这是在可选方案有限的情况下采取的策略。为了实现这一目标，关键是预测一些参数在各阶段的值，以便在执行项目时通过对它们的控制就可以确保最终产品具有期望的质量。如果可以实现这种预测，则可以用收集到的实际数据判断过程是否得到了有效的应用。采用这种方法，故障检测过程在过程执行完后并没有结束；相反，有关过程执行的数据用来保证过程执行时完全发挥了其潜能。
一种定量化控制软件质量的方法是使用软件可靠性（software reliability）模型。大多数这样的模型用最后测试阶段的故障数据来估计软件的可靠性。这些模型可以表明可靠性是否可接受，是否需要进一步的测试。可惜的是，它们没有提供项目早期的中间质量目标，并且它们还存在其他局限性。总之，虽然这种模型在估计软件产品的可靠性方面是有用的，但是它们对质量管理的作用却是有限的。（有关的更多信息，请参见可靠性模型。[4,5,6]）
关于软件的另一种公认的质量概念是故障排除效率（defect removal efficiency，简称DRE）。对于一种质量控制（quality control，简称QC）任务，我们将故障排除效率（DRE）定义为：QC任务检测到的故障数占现有总故障数的百分比。[5]项目的整个生命期的 DRE（即，在交付软件前执行的所有任务）表示过程的过程中效率（in-process efficiency of the process）。如果已知项目的总故障引入率，则整个生命期的DRE也定义了软件的质量（已交付软件的故障密度）。
虽然故障排除效率是评估一个过程和鉴别出改进领域的一个有用的指标，但它本身不适于质量管理，主要原因是一个QC任务或者整个过程的DRE只有在项目收尾时（即，在知道了所有的故障及其起源时）才可以计算。因此，它没有提供项目执行时直接控制质量的方法。
另一种定量化质量管理的方法是故障预测（defect prediction）。这种方法根据已交付软件的故障密度设定质量目标。通过估计各故障检测任务可能识别出的故障数设定中间质量目标；然后将实际故障数与估计的故障数相比较。
这种质量管理方法非常雷同于工作量和进度的管理（项目成功的另外2个重要的参数）。首先设定软件交付时的质量目标。根据这个目标，估计项目各阶段所选参数的值；即，确立里程碑。这些里程碑的选择要使得在估计都得到满足的情况下，最终软件的质量可能满足期望的目标。在项目执行期间，度量参数的实际值，并与估计的值进行比较，以确定项目是否遵循期望的路线，或者是否需要采取某些措施以确保最终的软件具有期望的质量。
这种方法的有效性取决于你在项目各阶段预测故障数的精确程度。众所周知，故障率遵循与工作量比率相同的模式，两者均遵循瑞利曲线。[5,7,8]换句话说，项目开始时发现的故障数较少，但是随着项目的进展故障数一直在增多，直到单元测试时达到颠峰，然后开始下降。因为过程已经定义了故障检测点，所以你也可以根据各阶段检测到的故障数占总故障数的百分比规定该曲线。根据故障引入率和规模的估计，就可以估计总故障数。这种故障数预测方法既类似于基本故障模型，又类似于IBM的联邦系统划分（Federal Systems Division）[5]方法。
还有一种方法是用统计过程控制（statistical process control，简称SPC）管理质量（第7章简单地讨论了SPC）。这种方法根据控制界限设置各QC过程期望的绩效，诸如测试和评审等。如果QC任务的实际绩效不在界限内，则分析情况并采取合理的措施。控制界限犹如根据以往的绩效预测故障数，但也可以用于在更细粒度上监督质量任务，诸如一个模块的评审或者单元测试。
当采用绩效预测方法并且实际故障数低于目标时，这种方法有太多的不确定性，使你不能肯定地说故障排除过程没有得到正确的执行。因此，你必需查看其他指标以确定原因。[5]换句话说，如果实际数据超出了范围，项目经理将查看其他指标以确定实际情况怎样以及需要采取什么措施。

第6章  风 险 管 理
•    软件项目是一项复杂的任务。很多不可预见的事件会对项目的成本、进度或者质量产生负面影响。
•    风险管理（risk management）试图使由于意外事件而导致项目失败的概率降到最小。
•    风险管理的目标不是避开研究有风险的项目，而是使风险对正在从事的项目的影响最小。
•    拿Infosys公司的CEO奈良亚那•墨西（Narayana Murthy）的话来讲：“任何值得一做的事情都有风险，领导者面临的问题不是避开它们，而是通过解除风险的策略有效地管理它们。”
•    不正确的风险管理是很多项目失败的根源，主要是由于过于乐观的通病造成的。
•    例：瓦苏（Vasu）被任命为一个著名的跨国公司所承担的一个大型项目的项目经理。该项目的任务是构建全球人力资源综合管理系统的多个部件。对于最终系统，瓦苏团队准备要开发的软件必须与另一个软件商开发的系统相集成。客户提供了专门供项目使用的工具，不久以后该工具就发行了新版本。瓦苏团队有35人，他们在1年略多的时间内交付了软件。尽管项目雇佣了一个良好的团队，并且项目经理作出了合理的估计，但是该系统晚了6个月才正式投入使用，Infosys 公司为此项目承受了50%的工作量蔓延。
•    为什么该项目会失败呢？有两个原因是很明显的。
–     首先，另一个软件商开发的软件没有按时完成，并且提供给瓦苏团队的接口不断改变。
–     第二，开发期间客户发行了一个新版工具，并要求软件使用这个新版工具。
•    这两个事件显然都是没有得到正确管理的风险实例。这些风险在开始时是显而易见的，然而，如同任何一个风险一样，它们是否会成为实际的危险却是不确定的。项目开始时，项目经理、业务经理和客户都希望那个软件商会按时交付软件，并且新版工具不会对项目产生影响。
•    事后，瓦苏认识到如果当时成立了一个指导小组（由两个项目的项目经理和一个客户代表组成），以正确地协调这两个项目及其软件交付时间，很可能会使延迟时间最短。
–     对于第2 个风险，他认为软件应先用旧版工具进行开发，然后通过另一个新项目将它移植到新版工具上。
–     解决第1 个风险的方案所需的额外工作量最小，并且客户的成本的微不足道。
–     解决第2 个风险的方案要客户付出额外的成本。也许为了避免客户感到不满意，所以没有强调该风险，也没有规划缓和该风险的措施。
•    本章先讨论风险和风险管理的基本概念，然后讨论Infosys公司进行风险评估和风险控制的方法——这是两个主要的风险管理步骤。
6.1  风险和风险管理概念
•    风险是那些可能发生的事件或者条件，如果它确实发生了，则它的发生会对项目产生有害的或者负面的影响。
•    风险不应与需要管理层干预或者行动的事件和条件相混淆。项目经理必须处理和规划那些有可能发生但是其确切性质却不能预先知道的情况；然而，这种情况不是风险。
–     例如，几乎在软件测试期间总是会发现故障，因此一个合理的项目必须作好发现故障时对它们进行修复的计划。
–     同样，几乎总是会出现某些变更申请，因此项目管理必须相应地准备好变更和计划，以处理这些正常的事件。
•    风险是一种概率事件——它可能发生也可能不会发生。因此，我们通常会表现出很乐观，不是看不到风险就是希望它们不会发生。
•    社会与组织因素也可能会对风险产生误解，并失去明确地标识出风险的勇气。如果风险真的出现了，这种态度会使项目陷入困境，这是一个大型项目中很可能发生的事情。
•    因此，风险管理被认为是管理大型软件项目的最佳实践之最。
•    风险管理旨在识别出风险，然后采取措施使它们对项目的影响最小。风险管理是软件管理中相对较新的领域。
•    在讨论软件环境中的风险之前，先用一个例子     来进一步辅助说明风险这个概念。
•    考虑一个计算机展览会，其关键目标是提供不间断的计算机服务。为此，一个明显的风险是电源故障
–     电源可能发生故障，也可能不会发生故障。
–     如果它确实发生了故障，即便只断电1 秒钟，它对计算机服务的影响也是巨大的（机器不得不重新启动，数据可能丢失等等）。
•    如果这种情况是不能接受的（即，断电成本很高），则可以部署一个UPS使其后果最小。
•    如果怀疑电源会长时间断电，则必须准备一个备用的发电机使这一问题最小化。
•    有了这些风险管理系统后，在电源断电的情况下，即便是长时间断电，则与展览相关的目标也不会受到影响。
•    从这个例子中应当认识到的第一件事情是：风险管理需要付出额外的成本。
•    在这个例子中，UPS和发电机的成本是额外的，因为在不存在电源故障时这些设备是不需要的（例如，如果电力公司保证不会断电）。
•    因此，只有在风险管理的成本大大低于风险真正发生时招致的损失的情况下，才认为风险管理是划算的。
–    （实际上，风险管理的成本应当小于损失的期望值，稍后将定义期望值概念。）
–    例如，如果断电的损失很小，则UPS的成本是不划算的——例如，家庭照明就不用UPS。
•    其次，风险管理的价值不容易度量，尤其是事后度量。
–    如果在展览期间电源断电达半个小时，则UPS和发电机提供的价值可以根据电源断电情况下使计算机继续运转而实现的“补偿”进行计算。
–    然而，假设连1秒钟电也没有断过，因此UPS和发电机没有使用过。这是否意味着这些设备的开销是一种浪费呢？否！因为可能会断电。
•    如果风险没有真正发生，则风险管理的价值不能直接根据产生的价值或者结果来度量。因为风险事件很可能不会经常发生，所以在项目期间不启用风险管理系统的可能性很高。
–    正是由于风险的这种概率特性及其并非总能实现风险缓和工作的价值，使得风险管理很困难。
•     从这个例子可以看出：
–    风险管理的第一步是识别出可能的风险（本例为电源故障），
–    并评价可能出现的后果（丢面子或失去客户）。
–    在完成了风险评估以后，就可以开发一个风险管理计划（例如，配备一个UPS）。
•    总之，风险管理牵涉到两个关键问题：风险评估和风险控制。每个问题都涉及不同的任务，如图6.1所示。

•    风险评估任务的目的是识别风险、对它们进行分析，然后划分它们的等级。
•    在划分风险的等级时，识别出应当进行管理的风险。换句话说，优先等级确定了应当将风险管理的额外工作放在哪里才能使效益最大。有两个重要因素：
–     一个是风险发生的可能性 ；发生的可能性较大的风险自然是风险管理的侯选目标。
–     另一个是风险的影响 ；影响非常大的风险也是风险管理合适的侯选。
•    因此，一种划分风险等级的方法是估计其发生的概率以及发生后造成的后果。这两个值的乘积就是风险损失的期望值，可以用于划分风险的等级。
•    这个期望值称为风险暴露度（risk explosure，简称RE）。
•    假设Prob(R)是风险R发生的概率，Loss(R)是风险R发生时造成的总损失，则风险R的风险暴露度RE由如下公式给出：
RE（R）=Prob(R) × Loss(R)
•    一旦划分了风险的等级，就必须决定对它们采取什么措施。
•    对哪些风险进行管理是一个管理决策问题，也许只须处理项目中优先级最高的几个风险。

•    一种方法是采取预防措施或者回避措施，使观察到的风险不再成为风险。
–    例如，如果新硬件是一个风险，则用可靠的硬件实现项目就可以避免它了。
•     然而，这种措施并非总能奏效的
–     例如，如果使用新硬件是客户的一个要求。
–     在这种情况下，必须正确地处理项目的风险。
•    对于要处理的每个风险，必须先设计风险管理计划，然后再行处理。因为风险认识随时间而变化，所以还必须对风险及其管理计划的执行进行监督，使风险造成的后果最小。
•    在一个项目中，可以任由风险自然发展，也可能通过风险管理计划减少风险。
•    在任何情况下，必须连续不断地测量风险及其管理计划的状态。
•    风险管理本身可以集成到开发过程中，软件开发的螺旋模型就是这么做的。
–     若将风险管理看成一个独立的过程，则必须理解其与项目执行的关系，如图6.2 所示。
–     如图所示，风险评估和监督利用项目执行的信息以及其他因素来确定要管理的风险。
–     另一方面，风险管理任务使风险的后果最小的同时也将影响项目的过程。

•    下面 描述Infosys公司的项目经理如何用简单、有效的技术管理风险。
•    风险管理任务可以综合为两个任务：
–    风险评估和风险控制
•    我们将分别讨论每一个任务。
6.2  风险评估
•    一般情况下，风险评估任务包括两个传统的组成部分：风险识别和风险等级划分。
•    风险识别任务主要列举出项目可能存在的风险，基本任务是尽量想象出可能使项目出现差错的所有情况。
•    风险等级划分任务考虑所有风险的所有特征，然后划分它们的等级（为了风险管理）。
•    尽管这是两个不同的任务，但是往往同时执行它们。即，项目经理可以在识别出风险的同时对它进行分析。
6.2.1  风险识别
•    对于一个项目来说，任何可能发生并危及项目成功的条件、情况或者事件都构成一个风险。
•    因此，识别风险就是设想出那些会出现差错的任务。
•    帮助风险识别的方法包括可能存在的风险的检查表、调查表、会议和自由讨论，以及计划、过程和工作产品的评审。
•    经常发生的风险的检查表可能是最常见的风险识别工具。SEI还对风险进行了分类以帮助风险识别。
•     Infosys公司根据对以往项目的调查，汇编了经常发生的项目风险表。
•    该表成为了当前项目识别风险的起点。
•    通常，当前项目的风险可能在列表上。
•    项目经理也可以用过程数据库获得有关同类项目的风险和风险管理信息。
–    评估和考虑以前遇到过的风险也有助于识别出其他对项目有害的但在表中没有列出的风险。
•    项目经理也可以根据他们的判断和经验对情况进行评估以识别出潜在的风险。
•    另外也可以根据项目管理计划的评审和讨论会来引出其他人员对风险的观点。
6.2.2  风险等级划分
•    已识别出的项目风险只是给出了有可能阻碍项目实现目标的事件。
•    但是各种风险的后果不可能是相同的。
•    在继续进行风险管理之前，必须划分它们的等级，以便管理精力能够集中在最高等级的风险上。
•    风险等级划分要求分析风险事件真正发生时可能产生的影响。
–    如果风险真的发生了，项目会受到什么损失呢？
–    损失包括直接损失、由于失去商业机遇或者未来的业务而造成的损失、由于雇员信心下降而造成的损失等等。
–    根据可能造成的后果和风险事件发生的概率，可以计算风险暴露度，然后就可以用它划分风险等级。
•    该方法要求定量化评估风险概率和风险后果。
•    通常，能够帮助你定量化估计这些参数的历史数据很少。因为风险是概率事件，它们并不经常发生，因此很难收集到关于它们的数据。此外，必须正确地解释任何这样的数据，因为管理风险的行为对它们有影响。
•    这一事实表明风险等级划分将基于经验，而不是基于以往的硬数据。
•    在这种情况下，对风险发生的概率和可能造成的后果进行分类有助于区分高等级的风险和低等级的风险。
•    在Infosys公司，风险发生的概率分成低、中和高三个等级。
•    表6.1给出了每种风险类别的概率范围。
表6.1  风险分类
•    为了评定某个风险对项目的影响，必须选择一个影响单位。
•    为了简化风险管理，Infosys公司的项目经理用1到10之间的数值来衡量风险影响。在该数值范围内，风险影响可以被评价为低、中、高和非常高。
•    表6.2给出了这些等级中每个等级的影响范围。
表6.2  影响分类
有了这些等级以及每个等级的范围之后，就可以规定如下简单的风险等级划分方法：
（1）对每个风险，将其发生概率表示成低、中、高。需要时为每个等级分配给定范围内的概率值
（2）对于每个风险，用低、中、高或非常高评价其对项目的影响。如果需要，分配一个从1到10的权重。
（3）基于风险发生概率及其对项目的影响，划分风险的等级；
–    例如，一个发生概率为高、影响为高的风险条目的风险等级，与一个发生概率为中、影响为高的风险条目的风险等级比，显然前者高于后者。
–    在出现冲突的情况下，充分利用你的判断力（或者分配数字以计算风险暴露度的数值）。
（4）选择几个风险等级最高的风险条目，缓和它们的风险并对它们进行跟踪。
•    风险管理的主要目标是识别出几个最危险的风险条目，然后集中解决它们。
•    因此，使用分类方法可以起到良好的效果。
•    显然，一个发生概率为高和影响等级为高的风险是一个具有高风险暴露度的风险，因此具有较高的风险管理等级。
•    在对风险进行分类时，如果风险概率和风险影响等级是（高，中）或者（中，高）时会出现一个等级划分难题。
–    此时，哪个风险应当被评价为更高的等级是不明确的。
–    此时，简单的处理方法是同时缓和这两种风险。
–    如果需要，可以用实际数值区分这些类型的风险等级。
•    这种划分风险等级的方法有助于将重点放在高风险的条目上，但是它不能帮你分析哪种风险缓和策略的成本效益比最好。
–    即，这种方法根据一个标量来说明风险影响，而不用货币价值，所以它不支持你根据货币来计算期望的损失。
–    因此，你不能分析某种需要付出一定成本的风险缓和策略是否值得采用。
–    然而，这种分析一般情况下是不需要的，因为风险管理的重点往往在于以最低的成本管理风险，而不在于风险管理本身是否有益。
•    当然，如果必须决定是否应当管理一个风险，或者不对它进行管理是否是经济上最明智的选择，则你必须知道风险的经济影响。
6.3  风险控制
•    在项目经理识别出风险并划分其风险等级之后，问题就变成了如何处理它们。
•    只有在能够准备一个风险缓和计划使风险的后果最小的情况下，知道了风险才有意义——这是风险管理的基本目标。
•    风险管理的第2步：风险控制，它将使风险的影响最小。
•    这一步牵涉到制定缓和风险的计划，然后执行计划和监督风险。
6.3.1  风险管理规划
•    在识别出风险并划分了它们的风险等级之后，项目经理应当处理哪些风险就很清楚了。
•    为了管理风险，正确的规划是必不可少的。
•    风险管理规划的主要任务是确定使风险后果最小所需的措施，通常称为风险缓和措施（risk mitigation step）。
•    与风险识别一样，可以查阅一个常用的风险缓和措施表，并针对每个风险选择一种合适的风险缓和措施。
•    Infosys公司所用的风险缓和措施表如表6.3所示。
•    该表不仅是识别风险的起点，也是在划分风险等级后选择风险缓和措施的起点。
•    与风险识别一样，风险缓和措施并不局限于表6.3提到的措施。你也可以使用过程数据库来识别风险和选择风险缓和措施。

•    表6.3的大多数风险和缓和措施都是显而易见的。
•    从中可看出，前几个风险都与人力和需求相关。
•    这里的许多条目与勃姆和霍尔给出的最危险的风险表中的那些条目相类似。
•    选择一个风险缓和措施不仅仅是一种智力任务，还必须执行（和监督）风险缓和措施。
•    为了确保正确地执行了所需的措施，必须在项目的进度计划中提到它们。
–    换句话说，必须更新项目的进度计划（它列出各种任务，并规定了它们将在什么时候执行），使它包含与所选的风险缓和措施相关的任务。
6.3.2  风险监督和跟踪
•    风险等级划分及随后的规划都是基于执行风险分析时对风险的认识。
•    第一次风险分析在项目规划期间发生，而初步的风险管理计划反映了那时对情况的看法。
•    因为风险是概率事件，通常依赖于外部因素，所以由风险引起的危险可以因因素的改变而随时间发生变化。
•    显然，风险认识也可以随时间而变化。
•    风险缓和措施可能会影响风险认识。
•    不应当把项目中的风险看成静态，而是必须定期对它们进行重新评估。
•    除了监督计划的风险缓和措施的进展外，还必须定期重新确定整个项目的风险认识
•    这种评审的结果在每次里程碑分析报告中进行报告（参见第11章）；报告风险缓和措施的状态以及当前的风险认识和策略。
•    为了准备这个报告，必须重新进行风险分析以确定风险等级是否已经发生变化。
6.4  实    例
•    本节包括两个风险管理计划：
–    一个是ACIC项目的风险计划
–    另一个是另一个项目的计划（XYZ）
•    正如你将会看到的，风险管理计划都比较小——通常是一页纸上的一个表。
•    缓和计划中提到的任务成为项目任务的一部分，并且有可能显式地调度它们。
6.4.1  ACIC项目
•    ACIC项目经理选择用数字进行风险等级划分和分析。
•    如表6.4所示，前面几个风险条目具有从8到3的影响等级，同时还要显示每个风险的缓和措施。

•    例如，第2个风险是使用了RUP方法。
–    即，项目引入了一个风险，因为这种方法对于项目人员来说是一种新方法。
–    此外，似乎其他项目还没有用过RUP。
•    其中一种风险缓和计划是最明显的缓和措施：制定RUP方法的培训计划。
•    此外，缓和计划建议咨询R&D实验室的人员，因为他们掌握了RUP及相关概念的知识，必须持续不断地与客户进行交流，并且及时提交任何问题。
•    注意，一旦这些计划作为风险缓和措施被接受了，它们将影响项目的详细进度计划；进度计划必须包含相应的培训和概念证明（proof-of-concept）构建任务的时间。这些需要将随着很多风险缓和措施而出现。
•    因为它们代表了行动，并且因为详细的项目进度计划表示项目要采取的大部分措施，所以风险缓和措施通常会改变详细的进度计划，增加项目的总工作量需求。
proof-of-concept（POC）
（概念证明，概念验证）
•    POC是根据特定客户的特定业务需求而设计的软件、硬件原型的解决方案。
•    POC 的目的是为客户确定合适的系统组成、系统或软件产品版本、方案的服务需求，或者看看建议的方案是否可行。
•    POC 不仅能确定应该做什么，也确定不应该做什么。
•    有时POC的最大价值在于在正式大规模实施方案以前，提前发现应该这个方案可能是无法工作的。
6.4.2  XYZ项目
•    该项目用等级系统进行风险管理。
•    表6.5给出了各种等级评定方法和风险缓和措施。
•    此风险管理计划是项目管理计划的一部分，也是从它那里提取出来的。

•    在里程碑处执行风险分析的方法基本上与前面所述的一样，但是将更加注意项目计划中列出的风险（即，更加强调项目早期风险分析的结果）。
•    风险分析期间，项目经理可以划分风险等级。
•    在XYZ项目中，大约在制定初步风险管理计划后3个月进行里程碑分析时，风险认识已经发生了某些变化。
•    表6.6列出一些暴露度发生了变化的风险

•    基于迄今具有的项目经验，项目经理认为变更协调的结果还不算太差。
–    这种情况是有可能出现的，因为协调问题比预想的要简单多了。
•    同样，人员流失的风险认识已提高了（可能是由于团队成员的经验），而团队成员在项目中期离去的事实，现在与项目开始时比被看成一个更大的问题。
•    每当分析风险时，根据项目的当前事实和风险的性质，风险缓和计划也可能发生变化。
•    在这个项目中，风险缓和计划没有改变。
6.5  小    结
•    项目风险是这样一种条件，其发生是不确定的，但可以对项目产生负面影响。风险管理要求识别出风险，划分它们的等级，并对几个最主要的风险采取缓和措施使它们的影响最小。在风险没有实际发生时，风险缓和的成本看起来好象是一种浪费，但是必须引入它们以使风险真正发生时的损失最小。
下面列出了从Infosys公司的风险管理方法中吸取的关键教训：
•    为了帮助识别出风险，可以用一个经常发生的风险列表作为风险管理的起点。此外，预先作好准备并设想出项目中可能出错的任何东西。
•    对于风险等级划分，简单而有效的机制是将风险的概率以及它们的影响按低、中、高几个类别进行分类，然后管理具有高概率和高影响的风险。
•    对于几个最主要的风险，计划风险缓和措施，并确保项目期间正确地执行它们。
•    监督风险并定期重新评估风险（也许在里程碑处），检查风险缓和措施是否有作用，并重新评估风险认识。
•    关于CMM，
–    CMM-2 的项目规划KPA 要求一个项目有一个风险管理计划。
–     正确的风险管理和监督过程是CMM-3 的集成软件管理KPA 的一个需求。
6.6  参考文献
•    [1] R. N. Charette. Large-scall project management is risk management. IEEE Software, July 1996.
•    [2] N. Brown. Industrial-Strength Management strategies. IEEE Software, July 1996.
•    [3] B. Boehm. Tutorial: Software Risk Management. IEEE Computer Society, 1989.
•    [4] R. Charette. Software Engineering Risk Analysis and Management. McGraw Hill, 1989.
•    [5] E. M. Hall. Managing Risk: Methods for Software System Development. Addison-Wesley, 1998.（“SEI软件工程丛书”之《风险管理》，伊莱恩•M•霍尔著，其英文影印版和中译版均由清华大学出版社于2002年出版。）
•    [6] B. Boehm. A spiral model of software development and enhancement. IEEE Computer, May 1988.
•    [7] M. Carr et al. Taxonomy-based Risk Identification. Technical Report, CMU/SEI-93-TR-006, 1993.
Add starShareShare with noteEmail

第7章  计划的度量和跟踪
项目管理计划仅仅是一个可以用来指导项目执行的文档。除非根据计划对项目执行的实际绩效进行跟踪，否则计划所起的作用是有限的。
而对于项目跟踪，某些关键参数的值必须在项目执行期间得到度量。
跟踪不是一项轻松的任务，并且与其他任务一样，如果要正确地执行它，必须制定跟踪计划。
制定跟踪计划时，必须确定如何跟踪任务、工作量和故障等问题、使用什么工具、遵循什么报告结构以及多长时间报告一次，等等。
本章讨论Infosys公司的项目如何进行度量，同时还描述了项目跟踪规划和绩效变化阈值的选择，阈值用于触发管理行为。
7.1  度量概念
项目度量的基本目的是有效地控制项目。本节讨论与指标和度量有关的概念，以及控制一个项目时应当度量的基本指标。
过程控制的一种方法是统计过程控制（SPC）。本节还讨论了一些与SPC相关的概念以及SPC在软件中的使用方法。
7.1.1  指标与度量
软件指标可用于定量表示软件过程或者软件产品的各种特征。
过程指标使软件过程或者开发环境定量化，而产品指标是软件产品的度量。产品指标独立于生产产品所用的过程。
•     例如，生产率、质量、资源指标、故障引入率以及故障排除效率就是过程指标；
•     而产品的规模、可靠性、质量（质量既可以看成产品指标，也可以看成过程指标）、代码复杂性和功能就是产品指标。
要使用指标必然要求制定度量方法以获取数据。
•    对于任何一个指标方案，必须明确地理解收集数据的目标以及基于这些数据的判断模型。
•    通常，使用哪些指标及采取哪些度量方法将取决于项目和组织目标；可以使用一个框架（诸如目标-问题-指标模式）来确定需要度量的指标。
大多数情况只要几个指标就足够了，只有在特殊情况下才需要特殊的指标。
进度、规模、工作量和故障都是项目的基本度量，它们形成了一个稳定的指标集。
进度是最重要的指标之一，因为大多数项目都是在进度和最后期限驱使下进行的。
进度是最容易度量的，因为它通常使用日历时间。
工作量是软件项目消耗的主要资源。因此，工作量跟踪是监督项目执行时的关键任务；它对于评价项目是否在预算内执行很重要。
•     即，工作量数据是声明诸如“ 项目的成本可能比以前的项目高出30% 左右” 或者“ 项目有可能在预算内完成” 所需的。
因为故障直接关系到项目质量，所以故障跟踪对于确保质量很重要。
一个大型软件项目可能包含上千个故障，它们由不同的人在不同阶段发现。通常修复故障的人并不是发现故障或者报告故障的人。
项目经理希望在最后发行软件之前排除大部分或全部故障。此时，故障报告和结论不能用非形式化的方法完成
•    使用非形式化的方法会导致发现过的故障又被忘记了，因此故障不但没有被排除而且还花额外的时间去再次发现它们。
•    因此，至少必须记录故障并跟踪它们的排除。
•    对于这个过程，你需要信息，诸如故障的表示、故障的位置、发现故障的人的名字和排除故障的人的名字。
•    只要记录了发现的每一个故障（随后再排除它），就可以重点分析迄今已发现了多少个故障、百分之多少的故障还没有排除以及其他一些问题。
故障跟踪被认为是管理一个项目的最佳实践之一。
仅仅记录故障并对它们进行跟踪并不足以支持其他必不可少的分析。
为了知道在哪里发现了百分之多少故障，还需要记录发现故障阶段的信息。
为了理解各质量控制任务的故障排除效率并因此改进它们的绩效，不仅必须知道故障是在哪里发现的，而且还要知道是在哪里引入的。
•     即，对于记录的每个故障，还应当提供关于引入故障阶段的信息。
项目规模是另一个基本指标，因为很多数据（例如，已交付软件的故障密度）都是根据规模进行标准化。
没有规模数据，就不能用以往的数据预测绩效。
如果不根据某个标准的规模度量进行标准化，就没有了绩效比较的基准。
项目规模的两个常用的度量单位是代码行（lines of code，简称LOC）和功能点。
如果使用代码行作为度量单位，生产率会随编程语言而不同。而功能点度量不会因编程语言而变
7.1.2  通过统计过程控制的监督过程
统计过程控制（SPC）已经在制造业取得了成功应用，并且其在软件领域的应用也在逐年上升。
这里我们简单地讨论SPC的一些基本概念；更多信息可以参考任何关于统计质量控制的教材。
过程用于生产产品，而产品的质量可以根据某些质量特征进行定义。
很多因素影响这些特征值的可变性。
这些因素可以分成两类：可变性的自然（即内在）因素和指定的（即特殊）因素。
•    自然因素是那些总是存在的原因，并且其中的每一个都对可变性有影响。除非过程本身发生了变化，否则控制这些因素是不切实际的。
•    而指定因素是那些偶尔出现的原因，对过程绩效的可变性有很大的影响，并且可以控制它们。
图7.1说明了这些原因和质量特征间的联系。

如果质量特征的可变性仅仅由于自然原因引起的，则认为过程在统计控制下。
SPC的目标是保持生产过程在统计控制下。
控制图是一种应用SPC的工具。
为了建立一幅控制图，将一个过程的结果看成一个代表感兴趣的特征值的数值流。
•    子组数据取自这一数值流，并且子组数据的平均值在图上绘出，形成一幅X-柱状统计图。
•    还要确定控制下限（LCL）和控制上限（UCL）。
•    如果点落在控制极限外面，则认为这种大的变化是由于指定的原因造成的。
还有一幅图称为R 图，绘出所选子组数据的范围（最小值与最大值的差）。
•     在R 图的控制极限已知的情况下，落在这些控制极限外面的点也被认为由指定原因造成的。
根据约定，LCL和UCL通常被设为3∑平均值，其中∑是仅有正常可变性的数据（即，由自然原因造成的可变性）的标准差。
有了这些极限后，一次错误报警（具有自然可变性的点落在极限外）的概率仅为0.27%。
如果生产过程不能重复地产生相同的项目，就如软件过程那样，形成子组并没有多大意义；因此必须考虑单值。
对于这种过程，可以使用XMR图。在一幅XMR图中，两个连续值的取值范围被看成R图的范围。
对于X柱形图，绘出各单独的值；然后，用平均取值范围确定控制极限。
注意控制极限不同于规范极限。
•     规范极限根据需求规定过程所必须的绩效。
•     而控制极限基于过程的实际数据确定过程的实际绩效—— 即，过程真正能够达到的绩效。
•     显然，如果控制极限都在规范极限内（规范极限范围大于控制极限），则过程能够在大部分时间内提交满足规范的结果。
•     另一方面，如果规范极限在控制极限内，则过程生产的结果不满足需求的概率增大。根据控制极限和规范极限间的关系，就可以形式化地定义一个过程的能力。
可以使用控制图连续地监督过程的绩效，并识别出失控的情况。另外，在表示结果的点落在控制极限外的情况下，必须决定采取什么措施。
通常可以采用两种类型的措施：
•     对结果进行返工，以便它具有可接受的特征—— 即，采取纠正措施 。
•     执行进一步的分析以识别出指定的原因并从过程中删除它们—— 即，采取预防措施 。
为了利用软件过程的控制图，必须先确定能够应用SPC的过程。
一种是选择整个过程，其结果就是最后要提交的软件产品。
对于这一过程的结果值得研究的特征包括生产率、已交付软件的故障密度和故障引入率，以及其他一些特征。
对于总体过程的大部分结果的特征值只有在项目收尾时才能得到，因此总体过程的SPC对项目监督和控制所起的作用是有限的。它的作用主要在于理解和改进软件过程的能力。
为了控制一个项目，可以对在项目期间执行的“微型过程”利用SPC，诸如评审过程或者测试过程等。
在SPC控制下，过程一执行就可以分析其结果。
如果需要，就可以采取纠正措施或者预防措施实施控制。
•     通过纠正措施，使界限外的结果变成可接受；
•     预防措施有助于改进项目其余任务的执行绩效。
给定绩效变化很大的软件过程的绩效变化概率，要确定只有自然可变性的点以便控制极限，这不是一件容易的事情。
因此，为了根据以往的绩效数据计算控制极限，必须使用判断力来确定应当排除哪些点。
有见识的管理层必须始终支持使用以往数据，但不应盲目地使用这些数据。
•    例如，不能仅仅因为绩效不在根据以往数据计算的范围之内，就认为过程已经失败了。
一种更加合理的方法是用绩效范围引起对绩效偏差的注意，然后分析引起偏差的原因。
7.2  度    量
对一个项目的任何定量控制主要取决于项目执行期间的度量。
为了在项目期间执行度量，必须仔细地规划度量什么、何时度量以及如何度量。
因此，度量的规划是项目规划的一个关键要素。
本节讨论Infosys公司的项目所执行的标准度量方法。项目经理可以在他们的项目需要时增加这些度量。
7.2.1 工作量数据收集
为了帮助项目经理监督工作量，每个雇员用一个周任务报告（WAR）系统记录各种任务所花的工作量。
•     这是内部开发的一个联机系统，所有提交的WAR 都保存在一个中心数据库中。
•     每人每周提交其WAR 。
•     提交时，报告送到各人的监督人那里以得到批准。
•     批准之后，WAR 提交就结束了，并且不能修改。
•     每个人都提交一个WAR ，包括CEO 在内。如果某人在指定的时间内没有提交WAR ，则认为他休假了。
一个WAR记录项由一个记录序列组成，每周1个记录。每个记录是一个条目列表，每个条目包含如下字段：
•    程序代码
•    模块代码
•    任务代码
•    任务描述
•    从周一到周日的工作小时数
任务代码表示任务类型的特征。
程序代码和模块代码的工作量数据根据模块或者程序进行划分，这在考虑组件级监督是重要的。
为了支持分析和项目比较，根据报告的工作量对任务进行标准化是很重要的。
拥有一个标准化的任务代码集有助于实现此目标。
表7.1给出了Infosys公司的项目采用的任务代码。

任务代码为很多阶段的返工提供了专门的代码。
这种分类有助于计算质量成本。
达到这一级精化后，就可以按阶段分析工作量数据或者按子阶段分析工作量数据。
项目规定的程序代码和模块代码用于记录项目的不同单元的工作量数据，从而简化对单元的分析。
为了简化项目级计划的工作量和实际所花工作量的分析，WAR系统与项目的MSP（Microsoft Project）描述相连接。
项目人员只有在提交了项目的MSP后才开始提交项目的WAR（一旦提交了MSP，系统就知道了哪些人应该从事该项目）。
计划的任务被定义成那些在MSP中列出的任务，并分配给项目中一个被授权的人。
没有计划的任务都归属于“其他”项目任务。
输入一周的WAR时，用户根据屏幕进行操作，屏幕被分成两部分：计划的任务和未计划的任务。
•     在MSP 中，每周分配给某个特定的人的所有任务都显示在那个项目的计划的任务部分。
用户不能增加或者修改该部分中显示的任务。
她只能输入不同的任务每天所花的时间。
•     为了登记没有在计划的部分中列出的任务所花的时间，用户可以在该项目的未计划的部分输入任务代码、其描述以及这些任务每天所花的时间。
7.2.2  故障记录和跟踪
在Infosys公司的一个项目中，故障检测和排除任务如下进行：
•    故障提交者发现并记录故障，这时故障就处于“已提交”状态。
•    接着，项目经理将修复故障的工作分配给某个人，通常是那个存在故障的文档或者代码的作者。
•    这个人执行调试并修复报告的故障，于是故障就进入了“已修复”状态。
•    已修复的故障仍然不能算被排除掉了，还要经其他人（通常是提交故障的人）验证故障已经被修复了。
•    验证以后，故障就可以被标志为“已排除”状态。
即一个故障的基本生命期有三个状态：已提交的状态、已修复的状态和已排除的状态（参见图7.2）。
一个没有被排除的故障仍然称为未被排除的故障（open）。

故障控制系统（DCS）在项目中用来记录和跟踪故障。
该系统允许进行各种类型的分析。
表7.2给出了该系统记录的每个故障的的信息。

为了确定故障引入阶段，需要对故障进行分析。
故障检测阶段包括评审和测试任务，故障引入阶段包括生产工作产品的阶段，如设计和编码等。
基于故障的性质，可以判断故障是何时引进的。
故障引入阶段与故障检测阶段不一样，故障检测阶段是确定的，而故障引入阶段却更加不明确；需要根据故障的性质和其他相关信息进行估计。
使用引入阶段和检测阶段信息，就可以计算故障排除效率、百分比分配以及其他指标。
有时不希望根据故障阶段来理解故障的性质，而是根据故障分类来理解其性质，这也是必要的。
这样一种分类有助于理解各类故障的分配情况。因此，还要记录故障的类型。
表7.3给出了可能存在故障类型及对应例子。
一个项目也可以定义它自己的类型分类。

最后，还要记录故障的严重性。
此信息对项目经理很重要。
•    例如，如果一个故障很严重，很可能要为它安排修复时间。
•    否则，可以决定在交货时间很紧的情况下暂不修复次要的或者不重要的故障。
表7.4给出了Infosys公司使用的故障严重性分类。

根据此信息进行各种分析是可能的。例如，
•    可以根据类型、严重性或者模块分解故障；
•    根据模块、严重性或者总故障数绘出故障引入和排除的趋势；
•    确定周故障引入率；
•    确定故障排除效率；
•    确定不同阶段的故障引入率；等等。
在第11章中将会看到这些数据在监督质量和预防故障方面的一些应用，同时该章还描述了案例研究中要求的故障数据。
7.2.3  进度度量
因为使用日历时间，进度度量比较简单直接。
详细的任务和进度计划通常包含在MSP进度计划中，因此在MSP中给出了估计的任务日期和任务的持续时间。
知道了一个任务的实际日期后，就可以轻松地确定它的实际持续时间。
7.2.4  规模度量
如果采用自底向上估计技术，则根据不同复杂度的程序数估计规模。
尽管这一指标对估计是有用的，但它不支持一种能够在项目间有针对性地进行比较的标准的生产率定义。
如果用代码行（LOC）作为规模度量，也会出现同样的问题：生产率随编程语言的不同而不同。
为了建立一个基准并根据该基准进行绩效比较，必须对规模度量单位进行标准化，采用一种经标准化的统一的规模度量单位。
可以将功能点作为规模度量单位。
已交付软件的规模一般以LOC为度量单位，这可以用常规的编辑器和行计数器计算。
•    在项目已经完成并准备提交时执行这种计算。
前文已经讨论过，根据以LOC为单位的规模度量，可以用已经公布的转换表计算功能点的规模度量。
7.3  项目跟踪
项目跟踪的主要目标是让项目经理掌握项目执行情况，以便他们能够确定是否需要采取什么措施以确保项目目标得到满足。
因为满足既定的项目目标是基本要求，所以必须监督所有能够影响达到目标的项目特征，并且必须制定这种监督任务的计划。
项目经理通常制定如下跟踪计划：
•     任务跟踪
•     故障跟踪
•     问题跟踪
任务跟踪检查哪些计划的任务已经完成。
如果任务的粒度很小，则可以把它看成两种最底层任务的状态之一：
•    没有完成
•    全部完成
对于更高层的任务，可以根据最底层任务的状态以及它们的估计计算高层任务的完成情况。
故障跟踪必须与故障记录同时进行。
问题跟踪确保那些有可能延迟项目的澄清和其他问题不会失去控制。
第11章说明了如何执行这些跟踪任务。
规划期间，项目经理规定他们计划采用什么类型的跟踪，以及他们将使用什么工具或者方法。
此外，为了跟踪项目的工作量状态、进度状态和质量状态，项目经理还必须制定如下计划：
•     任务级监督
•     状态报告
•     里程碑报告
任务级监督保证正确地完成每个任务。
可以使用统计过程控制定量地监督任务。
•    基于以往的绩效，可以确定某些任务的主要绩效参数的极限。
•    然后，将一个任务的实际绩效与既定的极限相比较。
•    如果绩效不在可接受的极限内，可能要采取某些措施。
在Infosys公司，评审和测试是两个采用这种方法的主要任务。
状态报告一般每周准备一次，帮助你估计哪些任务已经发生及哪些任务需要完成。
在项目的里程碑处，你要执行一种更加复杂的任务，即定量地检查工作量、进度和故障的实际数据和估计数据。
此外，你还要监督风险、培训、评审、客户投诉等等。
里程碑分析在控制项目方面有着重要的作用。
为了确保里程碑分析的频度足以支持及时干预，在客户要求的里程碑相距太远时，计划内部里程碑，以每3～5周执行一次里程碑分析为宜。

在里程碑处，要分析实际的工作量、进度和故障以及估计的工作量、进度和故障。
•     如果两者相差甚远，则需要采取某种纠正措施。
•     为了区分正常偏差和重大偏差，必须规定可接受的偏差范围；为了设定这些极限，可以利用控制图概念。
•    Infosys 公司为工作量和进度偏差（实际值与估计值之间的差）定义了控制极限。这些值最初基于判断和经验，现在都基于以往的数据并且按与其他控制极限相同的方式进行计算。
•    Infosys 公司以前的工作量偏差的极限是35% ，而进度极限是15% ；随着过程的改进，这些极限已减少到20% 和10% 。
•     图7.3 和7.4 给出了进度和工作量偏差的控制图。

如果在里程碑处进度和工作量偏差超过了这些极限，可能意味着项目遇到了麻烦，并且有可能不能满足其目标；在时间压力下，项目团队可能会采取不符合要求的捷径。
在这种情况下，要求项目经理弄清楚引起偏差的原因，并根据需要采取纠正措施和预防措施。
这些控制极限都基于以往的数据和经验。你必须在制定计划时设定项目本身的极限，这些极限有可能高于组织的极限。
7.4  ACIC项目的度量和跟踪计划
ACIC项目对规模、工作量、故障和进度的标准指标都进行了度量。
该计划对规模度量使用行计数器，对工作量度量使用WAR系统，对故障度量使用一个称为BugsBunny的故障控制系统，而对进度度量使用MSP。
项目经理计划用MSP进行任务跟踪，并定期举行会议以监督各种任务的状态。
问题分别被分类为联机问题、客户问题、业务经理问题和支持服务问题，并分别对它们进行跟踪。
客户反馈信息（投诉和表扬）都被记录下来。
每周向业务经理和客户发送状态报告。
对于前5个里程碑处的偏差极限，工作量和进度设为10%而故障设为20%。对于其余里程碑处的偏差极限，工作量和进度设为5%而故障设为20%。
里程碑报告也发给业务经理和客户。
跟踪和度量规划的最终结果包括在ACIC项目的项目管理计划中，有关内容请参见第8章。
7.5  小    结
在项目规划阶段，必须决定打算如何监督项目的进展。
进展监督对于保证项目朝着目标发展并在情况允许时采取纠正措施是必不可少的。
项目监督通常要求执行某些度量。
下面是从Infosys公司的度量和跟踪规划中提取的一些经验教训：
制定规模度量、进度度量、工作量度量和故障度量的计划。这些指标对于大多数软件项目已经足够了。
将工作量进行分类，并用自动化系统按每类任务的代码收集工作量数据。为了避免因记忆问题引起的不正确性，必须及时记录工作量数据。
记录故障并跟踪它们，直到项目收尾。对于一个故障，还要记录其类型、检测阶段、引入阶段和严重性，以支持诸如故障排除效率、已交付项目的质量以及故障引入率等分析。
对于里程碑处的绩效分析，建立工作量、进度和故障的可接受的绩效变化极限。项目执行时，如果绩效超出这些极限，则必须保证管理干预。
与CMM的关系
虽然项目跟踪和度量是CMM-2的项目跟踪和监督KPA、CMM-3的综合项目管理KPA以及CMM-4的两个KPA所要求的，但是CMM模型没有明确地表明需要规划这些度量。CMM的基本原则规定必须对要执行的主要任务进行规划，因此这些KPA蕴涵了对度量进行规划。
7.6  参考文献
[1] S. D. Conte, H. E. Dunsmore, and V.Y. Shen. Software Engineering Metrics and Models. Benjamin/Cummings, 1986.
[2] S. H. Kan. Metrics and Models in Software Quality Engineering. Addison-Wesley, 1995.
[3] V. R. Basili and D. M. Weiss. A methodology for collecting valid software engineering data. IEEE Transactions on Software Engineering, 10(6), 1984.
[4] V. R. Basili, G. Caldiera, and H. D. Rombach. Goal question metric paradigm. In Encyclopedia of Software Engineering, John J. Marciniak, editor. John Wiley and Sons, 1994.
[5] R. Grady and D. Caswell. Software Metrics: Establishing a Company-wide Program. Prentice Hall, 1987.
[6] Carnegie Mellon University/Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, 1995.
[7] N. Brown. Industrial-strength management strategies. IEEE Software, July, 1996.
[8] W. A. Florac and A. D. Carleton. Measuring the Software Process: Statistical Process Control for Software Process Improvement. Addison-Wesley, 1999.
[9] D. C. Motgomery. Introduction to Statistical Quality Control, third edition. John Wiley and Sons, 1996.
[10] D. J. Wheeler and D. S. Chambers. Understanding Statistical Process Control, second edition. SPS Press, 1992.
[11] W. Humphrey. Managing the Software Process. Addison-Wesley, 1989. （“SEI软件工程丛书”之《软件过程管理》，瓦茨•汉弗莱著，其英文影印版由清华大学出版社于2002年出版，中译版由清华大学出版社于2003年出版。）
[12] C. Jones. Applied Software Measurement: Assuring Productivity and Quality, second edition. McGraw Hill, 1996.