【软件开发】不确定度锥-第Cinq部分（更新版）

不确定性锥的概念已经存在了一段时间。Barry Boehm在“软件工程经济学”的著作。普伦蒂斯·霍尔，1981年。下面的帖子来自Steve McConnell的网站，它清楚地说明了一些事情。

但首先，让我们建立一个框架假设。当你听说项目的不确定性没有随着项目的进展而减少时，问一个简单的问题。为什么会出现这种情况？为什么随着项目的进展，新的信息、交付的产品、降低的风险，整体的不确定性没有减少？在声称不确定性没有减少之前，先去找出造成这种情况的根本原因。不确定性作为所有项目的原则，应该通过项目管理的直接行动来减少。如果不确定性没有减少，情况可能是——糟糕的管理，失控的项目，或者你在纯粹的研究世界里工作，诸如此类的事情就会发生。

那么什么是不确定性锥呢？

• Cone是一个项目管理框架，描述了估算（成本和进度）和其他项目属性（成本、进度和技术性能参数）的不确定性方面。与锥体右侧的估计相比，锥体左侧的成本、进度和技术性能估计具有较低的精确性和准确性。这是由于许多原因造成的。一个是项目早期的不确定性水平。解释性和认识性的不确定性，给项目的成功带来了风险。造成风险的其他不确定性包括：
  • 不切实际的绩效期望，缺少有效性衡量标准和绩效衡量标准
  • 对风险的评估不充分，以及通过适当的处理计划未减轻对这些风险的暴露。
  • 与保持有效性的替代计划和解决方案有关的未预料到的技术问题
• 由于所有项目工作都包含不确定性，减少这种不确定性——这降低了风险——是项目团队及其管理层的职责。团队本身、项目经理或项目经理，或大型项目的风险管理所有者。

以下是不确定性锥的简单定义：

不确定性锥描述了项目期间不确定性度量的演变。为了项目的成功，不确定性不仅必须随着时间的推移而减少，而且必须减少其对项目结果的影响。这是通过积极的风险管理，通过概率决策来实现的。在项目开始时，通常对产品或工作结果知之甚少。估计是必要的，但存在很大的不确定性。随着更多的研究和开发工作的进行，人们了解到了更多关于该项目的信息，不确定性随之降低，当所有风险都得到缓解或转移时，不确定性达到0%。这通常发生在项目结束时。

那么问题是？-为了提高项目成功的概率，项目属性（风险、有效性、性能、成本、进度——如下所示）需要在多大程度上减少差异？这是闭环项目控制的基础。对所需不确定性减少的估计、对不确定性可能减少的估计以及对这些减少工作的有效性的估计是闭环项目控制系统的基础。

这是不确定性锥的范式——它是一个计划开发合规性工程工具，而不是事后数据收集工具。

Cone不是项目过去表现的结果。Cone是项目进行过程中所需减少不确定性（或其他性能指标）的计划边界（上限和下限）。当成本、进度和技术性能的实际指标超出计划的不确定性范围时，如果项目要达到成本、进度或技术性能目标，就必须采取纠正措施，将这些不确定性转移到不确定性范围内。

如果你的项目的不确定性在计划范围之外，而此时它们本应在计划范围之内，那么你并没有降低项目成功的风险

在不确定性锥中建模的度量是建立绩效度量目标的控制过程的定量基础。获取实际性能，将其与计划性能进行比较，并遵守控制上限和下限，为进行调整以将变量性能保持在可接受的范围内提供了指导。

使用不确定性锥的好处

计划值、控制上限和下限、实际值的测量值形成闭环控制系统-一个基于测量的反馈过程，通过[1]提高项目管理过程的有效性和效率

分析有助于尽早关注问题领域的趋势——当受控变量开始行为不端时，可以采取干预措施。没有必要等到最后才发现你活不下去了。

• 提供对易出错产品的早期见解，然后可以更早地进行纠正，从而降低成本——当趋势走向UCL和LCL时，可以进行干预。
• 通过及早发现成本超支和进度延误，通过观察违反UCL和LCL的趋势，避免或最大限度地减少成本超支和工期延误。
• 在项目中足以实施纠正措施
• 执行更好的技术规划，并根据计划进度和实际进度之间的差异对资源进行调整。

所有项目工作的一个关键成功因素是风险管理。风险管理包括对各种风险的管理。风险来源于各种不确定性，包括技术风险、成本风险、进度风险、管理风险。这些不确定性及其产生的风险中的每一个都可以采用概率和统计分布函数描述的一系列值。了解哪些范围是可能的，哪些范围是可接受的，是项目成功的关键因素。

我们需要知道影响我们项目成功的所有变量的范围的控制上限（UCL）和控制下限（LCL）。我们需要知道这些范围是时间的函数。通过这种范式，我们将项目管理过程与控制系统过程逻辑连接起来。如果由UCL和LCL之外的不确定性造成的差异。这是一篇正在进行的论文“项目管理有一个基本理论吗”，它解决了项目活动控制的一些问题。

以下是一些计划差异和实际差异管理的例子，以确保项目按计划进行。

作为程序成熟度增加的函数的产品重量。在这种情况下，计划基本重量，并将每个主要子系统的计划重量作为时间的函数进行布局。项目基本权重的公差带为管理层提供了有关项目进展的可操作信息。如果车辆超重，则需要金钱和时间来纠正不希望出现的偏差。这是一个闭环控制系统，用于通过技术性能度量（TPM）管理程序。也可以采用成本和进度绩效衡量标准。

下面是具有错误带的“权重减少”属性的另一个示例。在本例中（与上述示例类似的实际车辆），当程序从左向右进行时，必须减轻重量。我们在测试准备审查中的目标重量为23KG。提案中出售了一辆25公斤的汽车，我们需要一个有安全裕度的目标重量，因此23公斤是我们的目标。

随着项目的进行，有UCL和LCL波段遵循计划的重量。橙色圆点是来自各种来源的实际重量——设计模型（3D Catia CAD系统）、详细设计模型、可测量的台式模型、非飞行原型，然后是第一次飞行文章）。随着程序的进行，每个模型到最终产品的每个重量测量值都会与计划重量进行比较。如果我们要坚持计划，我们需要将这些值保持在“需要减肥”的误差范围内。

这是成功项目管理的关键概念

我们必须为项目的关键属性——任务有效性、技术性能、关键性能参数——制定计划。如果这些不符合要求，项目将成为程序性能不足的根本原因之一。我们必须有一个燃耗或燃耗计划，以便在项目过程中为项目产生与这些参数相匹配的最终项目交付物。当然，我们一开始对每一项都有广泛的可能结果。随着程序的进行，这些项目的差异度量朝着符合目标数字的方向发展，在这种情况下为权重。

这是不确定性锥的另一个例子，在这种情况下，不确定性是由工程团队设计的烤箱的温度。UCL和LCL是在项目开始之前定义的。这些信息用于在项目进行过程中告知设计者项目的进展情况。保持在控制范围内是实现最终目标的计划进度路径——在这种情况下是温度。

不确定锥是闭环控制系统的信号边界，用于管理项目的成功

事实证明，圆锥体也可以是一个平坦的范围，具有正在开发的变量的控制上限和控制下限——一种对变量的设计——在本例中是一种性能度量。在这种情况下，当项目通过大门时，需要保持在上限和下限范围内的绩效衡量标准。如果这个变量超出了界限，项目将不得不以某种方式支付费用，才能将其退还给Green。

性能度量表征了在特定条件下测量或估计的与系统运行相关的物理或功能属性。性能度量是（1）确保系统有能力和能力执行的属性；（2）对系统进行评估，以确保其满足设计要求，从而满足有效性度量；（3）当实际性能超出控制上限和控制下限时，采取纠正措施，使实际性能恢复到计划性能。同样，这是简单的统计过程控制，使用反馈采取纠正措施来控制未来的结果——前馈。在概率和统计程序管理范式中，前馈控制使用过去的性能，以及未来的模型（未来行为的蒙特卡洛模型）来确定需要采取哪些纠正措施来保持程序的绿色。

另一种锥形风格是对交货日期的信心锥形。实际情况是低地球轨道飞行器的发射日期。在这种情况下，随着程序从左向右移动，我们需要确保启动日期从低置信度日期移动到有可能正确的日期。蓝色条是当前估计日期的概率范围。随着程序的推进，如果我们要根据需要出现，这些范围必须缩小。计划日期和带边距的日期是生成日期。随着程序的移动，日期的可信度必须增加，并朝着需要的日期移动。

• 概率完成时间随着程序的成熟而变化。
• 产生这些改进的努力必须加以界定和管理。
• 评估点的误差带也必须包括风险缓解活动。
• 计划的活动显示了误差带是如何随着时间的推移而变窄的：
  • 这是风险容忍计划的基础。
  • 随着风险缓解和成熟度评估增加了对计划发射日期的信心，概率区间变得更加可靠。

再次提醒一下——不确定性锥是一条理想的路径，而不是非托管项目结果的结果。

风险管理，如下所示，是成年人管理项目的方式

不确定性锥的目的和价值误区综述

当你听到。。。

我有数据表明，不确定性（或任何其他需要的属性）不会减少，因此COU是一个假的。。。或者。。。我看到我的项目数据，随着我们的前进，差异越来越大，而不是像计划COU告诉我们的那样缩小，应该实现我们的目标。。。

……然后该项目就失去了控制，从一个缺失的指导目标开始，这意味着它是开环控制，而且会迟到，超出预算，很可能无法达到所需的有效性和性能参数。当你看到这些失控的情况时，去寻找根本原因并制定纠正措施。

这些数据是对一个项目没有得到管理的观察，正如Tim Lister所建议的那样——风险管理就是成年人如何管理项目。

如果这些观察结果是在没有对绩效不足的根本原因采取纠正措施的情况下进行的，那么管理层的行为就很糟糕。他们只是对即将发生的火车事故的观察者。

不确定锥模型的工程原因及其对设计人员的价值

不确定性锥不是项目行为的输出，到那时已经太晚了。

不确定锥是管理框架的指导目标，用于增加项目成功的可能性。

这是项目的程序管理，以支持项目的技术管理。过程是一门工程学科。系统工程、风险工程、安全和任务保证工程是我们工作的典型角色。

否则的建议就是颠倒范式，从项目绩效的事后观察中去除任何价值。到那时已经太晚了，马已经离开了，再也回不来了。

在项目中的计划点定义计划和所需的方差水平是闭环控制系统的基础，需要提高成功的概率。

当出现计划差异之外的差异时，必须找到这些差异的根本原因并采取纠正措施。

以下是Galorath演示中的一个例子，使用了不确定性锥的框架，以及如何将这些放在一起的实际项目锥。再次重申，不确定性锥是

计划减少项目关键绩效指标的不确定性。

如果你的项目没有按计划减少这些关键性能指标（成本、进度和技术性能）的不确定性，那么它就会陷入麻烦，你甚至可能不知道。

Resources

[1] Systems Engineering Measurement Primer, INCOSE

[2] System Analysis, Design, and Development Concepts, Principles, and Practices, Charles Wasson, John Wiley & Sons

[3] SMC Systems Engineering Primer & Handbook: Concept, Processes, and Techniques, Space & Missle Systems Center, U.S. Air Force

[4] Defense Acquisition Guide, Chapter 4, Systems Engineering, 15 May 2013.

[5] Program Managers Tool Kit, 16^th Edition, Defense Acquisition University.

[6] "Open Loop / Close Loop Project Controls"

[7] "Reducing Estimation Uncertainty with Continuous Assessment: Tracking the 'Cone of Uncertainty'," Pongtip Aroonvatanaporn, Chatchai Sinthop, Barry Boehm. ASE’10, September 20–24, 2010, Antwerp, Belgium. 

[8] Boehm, B. “Software Engineering Economics”. Prentice-Hall, 1981.

[9] Boehm, B., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D. J., and Steece, B. Software Cost Estimation with COCOMO II, Prentice-Hall,

2000.

[10] Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J., and Madachy, R. "Using the WinWin Spiral Model: A Case Study," IEEE Computer, Volume 31, Number 7, July 1998, pp.  33-44 

[11] Cohn, M. Agile Estimating and Planning, Prentice-Hall, 2005

[12] DeMarco, T. Controlling Software Projects: Management, Measurement, and Estimation, Yourdon Press, 1982.

[13] Fleming, Q. W. and Koppelman, J. M. Earned Value Project Management, 2nd edition, Project Management Institute, 2000

[14] Galorath, D. and Evans, M. Software Sizing, Estimation, and Risk Management, Auer-bach, 2006

[15]Jorgensen, M. and Boehm, B. “Software Development Effort Estimation: Formal Models or Expert Judgment?” IEEE Software, March-April 2009, pp. 14-19

[16] Jorgensen, M. and Shepperd, M. “A Systematic Review of Software Development Cost Estimation Studies,” IEEE Trans. Software Eng., vol. 33, no. 1, 2007, pp. 33-53

[17] Krebs, W., Kroll, P., and Richard, E. Un-assessments –reflections by the team, for the team. Agile 2008 Conference

[18] McConnell, S. Software Project Survival Guide, Microsoft Press, 1998

[19] Nguyen, V., Deeds-Rubin, S., Tan, T., and Boehm, B. "A SLOC Counting Standard," COCOMO II Forum 2007

[20] Putnam L. and Fitzsimmons, A. “Estimating Software Costs, Parts 1,2 and 3,” Datamation, September through December 1979

[21] Stutzke, R. D. Estimating Software-Intensive Systems, Pearson Education, Inc, 2005. 

Related articles