|
|
|
2003年7月-8月
|
导航：Mypm.net>PMTW>2003年7月-8月期
栏目：Notices-Papers-Reports 通知-论文-报告
译者：余兆成、左剑,PMU翻译组
校对：郭守华,PMU翻译组
|
|
欢迎您志愿参加该杂志的翻译与校对工作，请联系translation@mypm.net
|
|
关注对管理人员信息需求的测量，识别测量过程的需求
Peter C. Baxter
|
建立测量过程的演进，是从最初的“如果发生变动就进行记录”时期开始的，经历了目标问题标准体系时期，一直发展到今天的基于信息需求识别和定义测量目标的阶段。ISO和PSSM（实用软件和系统测量）为建立一个健壮而灵活的测量过程提供了框架指导。但遗憾的是，它们只是说管理者的“信息需求”是测量的目标，而没有进一步说明这些信息需求具体是什么？本文描述了识别组织内信息需求的基本技术。信息需求将成为测量过程的需求，这会使测量过程变得有价值而且有效率。
在许多组织中，测量过程是各种管理技术中的必备元素。为了满足这一要求，许多工作组启动项目来研究建立这种测量过程的“最佳实践”，并对其进行标准化。在过去的两年中，测量过程的定义汇合了来自三个标准的测量指南：制定中的ISO标准—《ISO/IEC15939软件测量过程》；《实用软件和系统测量指南第四版》[PSM2000]和SEI的《软件成熟度模型集成项目（CMMI）》[SEI2000]。在这三个文献中，其测量的指导原则是一致的，图1就是基本的测量过程模型。
Figure 1: Measurement Process Model（pmforum.com上也没找到此图，译者注）
从图1可以看出，“信息需求”驱动着测量过程中的计划、性能和评估等活动。“信息需求”就是“核心测量过程”中的基本测量活动的要求。一旦界定了信息需求，就可以将信息需求分解成为“分析结果和性能度量”（信息产品）--它包括了测量标准和相关的指导，从而制定出“测量计划”。这些信息产品将被递交给管理人员并将驱动着“改进活动”。
把信息需求从核心测量过程中分离出来，测量过程就可以用来支持广泛的管理和执行功能。虽然这使得测量过程灵活了，但还是需要在启动或者扩大测量过程前对信息需求进行明确的评审、确定优先级并形成文档。由于信息需求的界定是测量过程成功的关键步骤，组织应当投入相当的时间来正确地选择和定义他们的管理信息需求。
本文提出了信息需求的一般类型，这些类型的需求在涉足系统和软件工程建设的商业机构和政府组织中都存在。另外，这其中的多个类型是对CMMI关键实践中信息需求的描述。这些一般类型应该激励着你，去挖掘本组织在管理、系统或软件和支撑过程中潜在的测量过程需求。
1.识别当前管理实践中的信息需求
许多组织通常建有一种以技术管理和工程功能为中心的文化。这种文化随着过程、架构和习惯的进化而发展。例如，在一个系统购置计划中，每月都可能召开例会来审核供应商的进度并应对潜在的风险。这个会议就是组织内文化和过程的结果，人们发现它定期的进度审核可以使按期交付的可能性更高。从测量的角度来看，这个定期的会议就提供了一系列候选的信息需求，一旦这些需求能被满足，企业将会取得的效益会更高。定期会议上的信息需求就是测量过程的正式的“信息需求”。
采用测量过程的主要障碍之一就是管理人员工作方式与测量过程所提供的信息没有良好的衔接。通过调查管理人员的实际工作方式，并以此驱动测量过程，测量过程就更有可能被采纳并成功实施。
2.识别“需求”的测量
毫无例外，系统和软件管理者都必须对生命周期中的需求工程活动进行测量。需求工程的测量包括了对从概念到公式化表达、设计、测试等整个过程的软件需求的量化。应该对这些需求进行评估，以确保产品具备要求的所有功能。
通常，对软件需求的评估是项目计划和启动的基础，它也是估算软件大小的基础。由于对需求的评估在制定最初项目计划中扮演着如此重要的角色，对需求是否按照所预期的那样处理实施监控就是势在必行的了。假设这样的一个场景，你开发的功能比需求计划多出25%，那么生命周期中的所有活动的进度和费用就都会超出计划和预算25%，甚至更多。
对每个软件过程产生的或接受的需求的数目进行测量才是明智之举。对系统或顶层需求的数目（即“特性”或“能力”），以及系统需求分解后的更细化的需求的数目，都要进行测量。对需求的测量有助于将注意力集中于项目范围内，因为通过对需求的测量通常发现的问题就是“需求蔓延” —— 一种不断的向项目增加需求而不考虑它将消耗多少额外的资源带来多少额外风险的趋势。
为了追踪计划的需求与实际开发的需求之间的差异，有必要测量每个需求在整个生命周期的不同活动中的变化状态。常见的需求状态有：已定义、已确认、已分配、已设计、已实现、已测试和已验证。举例说，在CMMI的需求管理过程域中，子过程1.3“需求变更管理”有代表性的工作成果之一就是“需求状态”。在[Caputo 1998]中，可以看到如何定义需求状态并管理状态变更的实际例子。
在项目状态监控中，能够显示所有需求状态的测量是必需的，它起着记分卡的作用，表明：需求正在实现中。在项目的进度计划执行初期，必须确保，随着系统架构的完成，需求经历了已定义、已确认、已分配等状态。在进度计划即将执行完毕的时候，应该看到需求状态已转变为已测试、已验证的状态。测量不仅对检测“需求挥发”很有价值，还支持工作量监控、配置管理和质量管理等过程。
3.识别危害过以往项目的风险
在许多组织内部，以及是许多管理者的经验中，都有一段包含项目教训的、不应重蹈覆辙的历史。比如，项目不能完成的教训，或延期交付、超出预算、必备功能不全等方面的教训。在最近的、类似的软件项目中的历史风险应该成为下一个项目（也就是当前这个项目）测量工作的首要测量对象。
对于这些历史风险，应该将注意力集中于识别风险发生的原因，而不是风险的外在表现或者风险的应对措施。比如，对于延期交付的软件项目，应设法回忆并找到导致软件延期交付的特定软件组件。导致整个软件延期交付的原因有可能只是一个关键的COTS组件没有到位，或者集成所花费的时间超出原来的预期。
同样要考虑这种情况，软件经理经常是察觉到了软件的诸多问题，但是只是当进度需要迟期的时候才采取措施。在我们自己的软件开发项目中，我们曾经为与COTS厂商有关的技术问题和进度问题而怒火中烧，本质上我们是让他们的问题影响到我们的项目。现在，我们采取“未雨绸缪”的做法，一旦发现问题，我们的产品经理就立即考虑替代技术。在你的环境中，你应当考虑是采用测量作为检测技术问题的监控手段，还是对已知的问题采用管理措施。有时候，在你的测量计划中，应该两种做法齐施并用。
4.识别当前项目的风险
在项目计划制定阶段，应该建立一个风险管理计划。对于每一个风险，通常应当考虑风险识别方法、规避风险的办法、风险可能带来的危害以及风险发生的概率等。测量过程可以识别需要规避的风险并对规避措施的效果进行量化，对风险管理计划起了支撑的作用。从测量的角度看，风险可以成为驱动测量过程的信息需求。测量过程能够也应该能够满足这些需求。
由于测量也需要费用（风险管理也是这样），你可能会选择对风险的一个子集进行测量。在选择要测量的风险时，可以使用概率和预期规避成本（或风险的危害）作为鉴别因子。例如，你可以选择规避成本大于10万美元、出现概率处于中高级水平的风险进行测量。
在组织中普遍存在的一种风险是，开发人员花费在某一产品基线上的时间并没有计划的那么多。在过去，我们曾发现资深的开发人员有被临时“借调”到其他产品开发或支持活动上去的现象。比如，被借调去对来自客户的行业报告进行原因调查上。为了应对这个风险，我们设置了一种根据业务优先级保证资源投入的信息需求，亦即，要事第一。
5．测量你试图改进的工作
笔者有很多这样的经验，很多组织实施大规模的、组织性的变化却缺乏管理结果过程的相关方法。在软件管理界中，经常可以听到Tom DeMarco的一句口头禅：“如果你不能够很好的进行测量，你就不能够很好的进行管理”。[Demarco 1982]所以，无论你是仅仅改进一个单独的软件任务，还是对整个过程进行大踏步的改进，在此之前必须确保你已经知道如何说明对过程的实际改进程度。
除了希望能够更好的管理新的或者被改动的软件程序，请注意，还有一个更加重要的原因促使你去测量那些你准备改进的过程。即更好地、定量的理解为什么你的软件过程是如此运转的。这就要求能够用数学方法来描述主要的过程要素。一旦建立这种数学关系，下一步就要去监视、控制这些过程要素的影响。而且，你的估计将会随着理解的加深而越来越精确。
许多实施测量的人把对过程一般意义上的定量理解与CMM第4级中的定量管理能力相混淆。然而，在实践上，组织虽然为包括需求分析、检查、检错纠错、软件发行版本系统测试等在内的各种活动都开发了定量模型，但很少有达到CMM第4级水平的。这里的关键在于通过测量更好地了解你的过程，你能够更好的估计、控制、管理他们，避免主观臆断。（换句话说，不要等到尝试CMM第4级评审的时候才开始测量。现在就开始，你将会在竞争中占据优势。）
6．识别软件质量测量标准
几年前，一家曾经在市场上领先的科技公司为了应付其市场的衰退决定聘请一位技术副总裁。在第一次会议上，这位副总裁先围着桌子走了一圈，在每个与会者的面前放了一个晕机袋，然后说“你们的计划让我很不舒服。”他告诉与会者，缺乏质量的计划等于没有计划。从根本上来说，如果客户认为系统或产品使用性差，那么无论你如何坚持按照计划实施都是无济于事的。这位副总裁非常了解市场需求，但是非常不幸的是，很多公司并不是很重视质量。如果他们重视质量的话，他们会集中精力去制造一个高质量的产品，而不会匆匆忙忙地向市场推出不合规格的产品。
系统或软件的质量比评估最终产品的质量更重要。最终产品的质量只是系统和软件开发过程中质量活动的结果。如果你忽视系统和软件开发过程中的质量因素，任何人都可能会怀疑其最终产品的质量。
使用“质量门”是保证软件质量的一种技术。它包括在开发过程的几个关键点建立合理的、可以测量的阀值，然后保证软件或者工作的产品只有满足这些阀值才能够继续进行到下一步。一个质量门意味着所有的要求都满足、所有的单元测试都获得通过、所有的代码都经过检查、所有的要求（或者子集）都经过测试。比如，为了发布Windows NT的beta测试版本，微软公司要求开发人员在其编写的代码中没有明显的错误（bug[Zachary 1994]）。微软的管理者们在产品的开发过程中计划了若干个零缺陷的发行版本。你应该采用相应的措施满足这些质量门的要求。
7．识别准备项目计划中所做的假设
一个典型的系统或软件的开发项目，在制定计划时包含了很多关于进度、质量、资源的假设。在整个计划过程中的假设是测量过程的重要信息。如果没有意识到假设的重要程度，则进度、资源的规划及其结果都需要检查或者重新规划。
例如，在使用费用建设模型（COCOMO）进行估计时，估计的代码的行数（或者诸如功能点这样的其他的测量软件大小的标准），是决定付出多大努力的主要根据。如果你的项目在开发过程中超过计划的代码行数，这可能意味着在“下游”软件开发活动中你需要付出更加多的努力，如单元测试、系统测试或者整合。
8．识别消耗的资源以及生产的产品，从而了解过程性能
在你开始一个测量过程的时候，你的组织一般不会有什么历史数据。在这种情况下，你的目标之一就是了解这些过程在系统或软件生命周期中的表现。考虑一下在生命周期中每个程序所耗费的资源以及生产的产品（不管是给内部用户使用的还是给外部用户使用的），你应该建立基本的测量标准以确定消耗了多少资源，又生产了多少产品。你可能会考虑那些耗费大量预算的过程。
9. 识别那些用以满足组织政策的信息
在很多系统或软件生产机构中，要求管理人员使用特殊的技术去监视、控制他们的计划。在大型的军事项目中，则需要使用一种叫挣值法的方法。当要求管理人员使用特殊技术时，组织会提供管理人员需要的、能够更有效的应用这些技术的相关数据。测量过程是这样一种方法，组织能够用来传递管理人员需要的信息。
例如，许多军事组织必须使用一个挣值法管理系统。在这个系统的支持下，测量程序可以按照费用性能指标、进度性能指标、完工性能指标、挣值法及其组件以及完成变量等指标来传递所需要的费用、进度状态的信息。如果没有一个测量程序保证按时收集、分析、传递到挣值法数据，即使是象挣值法这样有用的技术也可能得不到正确的应用。
计划或场合的政策和标准文档为测量过程提供了大量信息。在设置一个测量过程时，要分析系统与软件管理标准以及政策以了解何种管理技术已被（或者将要被）使用。然后，从这些强制标准中找到信息需求并在测量程序的实施过程中满足这些需求。
小结
识别信息需求是建立高效的测量过程的第一步。这种技术提供工具把真正有用的信息从你的组织中提取出来。如果你需要平衡信息需求和测量程序可用资源，一旦信息需求得到识别，你就可以分配一个相关属性给他们。测量程序将重新为各个测量活动、特殊测量指标以及信息产品修改这些信息需求。随着公司采用新的技术以及程序，你还需要检查这些信息产品的有效性以及个体的信息需求。
这种识别信息需求的方法保证你以及其他管理人员收到的测量信息对你监视、控制你的过程有很大帮助。通过在实际的信息需求中关注测量，管理人员能够更好的被武装来监视、控制他们的系统，获知按照费用、进度计划完成的可能性。另外，节省了在收集与分析他们需要管理的信息的大量的时间，管理人员能够将其大部分时间花在他们真正的角色——决策上。
作者简介
Pete Baxter是Distributive Software的研发经理，主管对服务、产品以及培训的测量。在过去的八年时间里，他帮助众多的政府以及商业组织计划、实施测量系统。他经常以“测量在软件、IT以及系统工程中的应用”为主题进行演讲与培训。他是SEI, ISO, IEEE, INCOSE, Practical Software and Systems Measurement (PSM)以及其他专业组织的成员，是INCOSE Measurement Working Group的现任主席，是ISO 系统与软件工程分委会的成员。作者欢迎对本文进行评价与讨论。
作者联系方式：
Peter C. Baxter, Development Manager Distributive Software 2300 Fall Hill Avenue, Suite 100 Fredericksburg, Virginia 22401 540-372-4500 / 6497 fax
pbaxter@distributive.com
http://www.distributive.com
|
原文位置：http://www.pmforum.org/pmwt03/papers03-078.htm
"Instant access to
worldwide project management information
is a competitive advantage"
|
|
项目管理者联盟授权翻译，请勿转载
|
|
