软件项目估算的两个世界

乍一看，软件项目估算有两个世界, 为简单起见, 我将称之为“混乱”和“受控”世界. 混乱世界的特点是大多数组织的项目经常超出时间和预算, 或者完全失败. 受控世界的示范组织数量要少得多，这些组织声称其项目按时按预算交付. 有趣的问题是，为什么混沌世界中的组织不会或不能简单地学习和复制受控世界中的人的行为，从而为自己节省很多钱.
本文探讨了这两个世界，旨在解释部分内在和不可避免的差异, 部分原因是文化的混合, 工艺和技术因素, 其中一些可以通过足够的努力和毅力克服.
第一, 两个世界的证据.

混乱的世界

已经进行了多次调查, 涵盖数千个软件项目的成果, 主要在美国和英国，主要是商业应用软件领域的项目, 在公共或私营部门. 严格来说，我们应该指的是“软件密集型系统项目”, 因为对于许多此类项目，软件的交付只是必须交付硬件/软件系统以及经常组织变革的项目的一部分. 为简单起见，我使用“软件项目”. 结果各不相同，但表明之间 10% – 30% 的软件项目完全失败, 即. 他们在提供任何有用的东西之前就被阻止了. 另一个大致 50% 按时和/或预算超支至少 10%. 这仅留下 20% – 40% 按时和按预算交付的项目.

然而, 这些数字并未反映许多项目交付的功能或业务价值低于原计划的事实. 更远, 那些“按时按预算”完成的项目中的未知比例很可能一开始就被高估了，因此本可以更快地以更低的成本交付. Abdel-Hamid 观察到帕金森定律适用于软件项目，就像任何其他活动一样, 即. 工作扩展以填补其完成可用的时间.

这些超支和失败的代价是巨大的. 有据可查的分析 105 十年内完成的承包软件项目 2007 英国公共部门客户与外部供应商之间的总价值为 295 亿英镑. 这些, 30% 被终止, 57% 经历平均成本超支 30.5% (总计 90 亿英镑的超支), 同时 33% 遭遇重大延误. 需要注意的重要一点是，所有这些项目都是由在全球范围内运营的外部供应商承担的，并声称他们的营销是“世界一流的”. 更远, 供应商在合同上的利润率几乎总是超过 10%, 范围高达 25%.

这些失败和超限的相同原因被反复引用, 至少回去 30 如《崩溃》一书中所述的年! 他们分为两大类.

1. 缺乏高级管理层的承诺和用户参与, 导致目标不明确, 这导致利益相关者冲突, 以及不明确和不断变化的要求.
2. 项目管理不善 (例如. 在进度和变化的管理中), 员工缺乏经验, 特别是当涉及新技术时, 和人员流动.

虽然硬件上的注销可能会严重影响故障和超额运行的成本, 雇用额外员工的成本, 失去的利益, 等等, 原因几乎总是由于指定和开发软件的问题.

在关于软件项目失败或过度运行的所有各种分析中, 将“估算不佳”列为原因之一的情况并不常见. 这对于失败的项目并不奇怪. 一个糟糕的估计似乎不太可能是放弃一个项目的原因. 更有可能是因为自开始以来优先级发生了变化而停止，并且它将不再提供任何有用的东西, 或者它已经超出了最初的预算，管理层决定减少损失. 但是如果, 说, 57% 的所有软件项目平均超过 30%, 必须问“在这些环境中，估计过程是否存在系统性错误”?’

被控制的世界

当一个组织发布显示其在软件项目估算方面取得成功的结果时，我们不时会瞥见另一个世界. 我将使用的示例是雷诺, 法国汽车制造商, 已发布其在成功软件项目估算方面的进展, 最近在 2014.

一辆现代普通家用车大约有 50 电子控制单元 (ECU的), 形成分布式网络以监视和/或控制几乎所有功能的小型处理器, 例如. 引擎, 灯, 空调, 胎压, 导航, 司机资料, 等等. ECU 及其嵌入式软件大多是从带有相关传感器的组件供应商处购买的, 受雷诺发布的规格限制.
雷诺几年来一直在收集有关其 ECU 软件供应商的成本和性能的数据. 其签订合同以采购 ECU 的过程是简要的:

• 雷诺软件部门, 按车辆功能区专业化 (例如. 动力总成), 为新的或增强的 ECU 软件开发规范并将其存储在 Matlab Simulink 工具中;
• 雷诺开发的工具然后自动计算每个规格的功能大小 (或尺寸增加，如果增强) 使用 ISO 标准 COSMIC 方法;
• 过去的测量和统计建立的关系用于预测供应商开发软件所需的工作量 (见图. 1) 及其内存大小 (无花果. 2);
• 采购部门使用此信息来协商 ECU 的价格. 更远, 雷诺可获得的信息现在已经足够完善，可用于协商年度价格变化，就像汽车制造商定期协商其他材料（如钢铁）价格一样, 油漆等, 和其他组件. (无花果. 3);
• COSMIC 功能大小也用于监控内部软件部门的绩效, 因为雷诺已经为他们的工作建立了规范-规模/员工级别的关系.

雷诺表示，在新软件开发结束时, 从已建立的相关性中初步估计的工作量与实际值之间的差异“必须低于 5%” (见图. 4).

软件项目估算的混沌世界和受控世界之间的差异

在下面的, 因为无论项目管理方法如何，都需要对整个生命周期进行项目估算, 为方便起见，我将使用项目阶段的瀑布模型. 使用迭代或敏捷模型时的差异将在出现时提及. 我们还必须假设，在混沌世界和受控世界的比较中, 两个世界的组织都有合理可重复的流程，并使用他们合理熟悉的技术, 即. 我们将忽略流程不成熟和与使用新技术相关的风险几乎没有机会开发任何准确估计方法的环境.

估计的不同条件. 在某种意义上, 在这两个世界之间进行任何比较是不公平的，因为它们之间存在一些内在差异.

第一个也是最明显的区别是在混沌世界, 业务应用程序项目在其生命周期的早期通常需要整个生命周期的成本估算, 在详细了解要求之前, 为了告知软件的成本/收益分析.

相比之下, 在完全指定软件设计之前，不会进行雷诺受控世界中的估计完成项目, 即. 它们并不是真正的一生估计. 到这个阶段, 估计也可以在较低的分解层次上进行 (雷诺案例中的 Simulink 模块) 在汇总到整个 ECU 的成本之前.

显然，人们期望雷诺的估计比在典型业务应用程序项目的早期阶段所做的估计要准确得多. 话说回来, 那么问为什么在项目生命周期的早期进行估算是合理的, 当还有那么多的不确定性, 被接受为固定的，以至于经常出现超支. 更远, 对业务案例有贡献的持续维护和支持成本通常比早期阶段的预测高得多.

文化差异. Jorgensen 对估算实践的研究告诉我们很多关于混沌世界的文化. 他的研究发现，“专家估算”是估算全生命周期开发项目努力的主导策略. 他将专家估计定义为“由公认的任务专家进行的工作, 并且估计过程的很大一部分是基于非明确和不可恢复的推理过程, 即. '直觉''. 虽然这项研究发表在 2004, Jorgensen 最近告诉我，他知道没有任何已发表的数据可以改变专家估算仍然主导项目工作量估算的观点。.

相比之下, 我的非正式观察是，在受控世界中发布数据表明项目估算的准确性很高的组织大多是高科技制造公司, 经常生产安全关键或任务关键的软件. 这些项目需要高度重视质量, 所以他们从“真正的”工程心态的好处开始, 依靠数据而不仅仅是判断.

这些文化差异影响项目估算的准确性. 丹尼尔·卡尼曼, 一位获得过该奖项的心理学家 2002 诺贝尔经济学奖描述了人类的两种思维方式, 直觉和理性. 大多数时候我们凭直觉思考; 以理性的方式思考需要真正的纪律. 他与估算相关的最重要发现是，直觉思维几乎总是乐观的，倾向于忽略统计数据和过去的经验 (例如. 相信“这次我们会做对”). 他建议最终的预测决策应该留给公式, 最好是简单的变量很少.

将此建议应用于基于直觉思维的项目成本估算, 例如. 类推, 表明如果环境具有上述英国公共部门项目的跟踪记录, 那么商业案例应该考虑 30% 完全失败的风险, 并且任何直观的成本估算都应自动增加 15% – 20% 随着不确定性的相应增加.

Kahneman 有其他建议对于在缺乏硬数据时进行估算很重要, 例如. 宽带Delphi等进程的使用 (或敏捷世界中的“规划扑克”), 而不是依靠个人的专业知识.

了解参与估算的各个参与者的角色. 估算员的职责是根据最佳可用数据生成项目工作量数据, 适当说明估计的不确定性范围. 就这样.

理解估算器的假设是经理的工作, 评估风险和不确定性, 并最终决定项目预算. 如果管理者的心态是依赖估算而忽视风险 (例如. 以迪尔伯特经理“给我一个号码”的态度) 该项目注定要错过预算.

更远, 当客户发出 ITT 以从外部供应商采购软件时, 客户必须了解影响供应商如何得出其估算和投标价格的其他因素.

外包软件系统的供应商依赖于对其生存的可靠估计——我们在上面提到，他们通常在盈利能力方面有良好的记录. 因此，他们通常非常重视软件度量的收集及其用于估计的用途。, 远远超过典型的内部 IT 部门或客户保留的管理其外包 IT 供应商的 IT 职能.

在供应商, 基于客户 ITT 中包含的需求信息的成本估算由其销售团队转换为以价格取胜. 在这个过程中, 他们会考虑许多明显的因素，例如预期客户的预算, 可能的竞争, 未来现金流, 期望的盈利能力, 等等.

还考虑了另外两个不太受重视但很重要的因素. 第一, 随着项目的进展, 客户将不可避免地想到新的或更改的要求，这些要求可能会超出投标价格. 第二, 初始开发项目的获胜者最有可能赢得系统生命周期内的持续维护和支持工作. 这些额外的和持续的活动都可以比最初的开发工作更有利可图. 最后, 供应商可能会为初始开发出价低以确保获胜.

不幸, 二十多年前，当英国公共部门 IT 外包的第一波大浪潮开始时, 大多数软件度量和估算的经验都根据长期合同外包给了供应商. 这导致了客户与其供应商之间严重的“信息不对称”，几乎可以肯定是英国公共部门 IT 项目预算超支的主要原因.

对于汽车制造商, 采购是其最重要的功能之一. 在英国公共部门 IT 采购的情况下, 游戏管理员有效地将其度量专业知识交给了偷猎者.

项目超支的另一个原因可能是应急储备的管理方式. 这些应该由项目组合级别的经理持有，并根据需要发布给项目经理, 而不是一开始就分配给单个项目. 第一, 了解估算中包含的意外事件可以让项目经理感到安心，并且帕金森定律确保它会被使用. 外包关系也是如此, 卡尼曼引用“预算储备是给承包商的，就像红肉和狮子一样; 他们吃掉它’.

估算技术. 受控世界中的许多软件项目估算, 以雷诺为例, 试图回答主要的成本驱动问题“它有多大”?’通过对源代码行数进行基于经验的估计 (SLOC). 众所周知的 COCOMO II 估计方法和大多数商业上可用的估计工具已经使用 SLOC 大小作为输入进行了校准. 尽管有许多, SLOC 尺寸的经常公开的缺点, 基于详细设计的专家判断的估计准确性通常声称准确到 10% 在组件级别.

在混沌世界, 如果仅存在大纲要求时，估计需要的不仅仅是直觉或专家判断, 最常见的是首先使用功能点分析来估计需求的大小 (FPA). 然后使用从以前的类似项目中得出的生产力基准将规模转换为工作量. Albrecht 在 1970 年代后期提出的 FPA 最初的想法是根据软件系统的功能需求提出衡量软件系统规模的方法，这是横向思维的绝妙作品. 但是这个方法, 现在由 IFPUG 组织开发和支持, 暴露年龄.

该 宇宙方法 雷诺使用的软件由国际软件度量专家小组设计，适用于业务, 实时和基础设施软件, 基于基本的软件工程原理. 生产近似尺寸的方法的变化可用于测量要求，然后才能获得足够详细的信息以进行精确测量, 并且该方法已经或正在通过各种方式自动化. (自动化测量对雷诺至关重要; 手动计数对于他们的开发过程来说太慢了。) 该方法非常适合测量敏捷开发中任何聚合级别的需求, 例如. 用户故事. 迭代次数, 发布, 等等, 和分布式系统的组件.

使用 COSMIC 方法可以避免的问题的一个例子出现在一个主要的欧洲养老基金中，该基金曾使用 IFPUG FPA 方法作为估算的基础. FPA 规模仅提供范围狭窄的交易规模; COSMIC 方法在没有上限的比率尺度上进行测量. 对一个项目进行了调查，以查明它是如何被严重低估的. 一些交易的 IFPUG 最高得分为 6 要么 7 使用 COSMIC 方法重新测量了 FP，发现已经结束 60 COSMIC FP. 超过大小的交易 40 COSMIC FP 几乎占了 80% 预算超支.

可以做些什么来弥合从混沌世界到受控世界的估计差距?

强烈推荐 Jorgensen 关于如何充分利用专家判断估计的建议，并且必须考虑 Kahneman 对基于直觉判断的预测的观察. 但如果混沌世界要弥合差距, 它必须做的不仅仅是依靠直觉估计. 它必须收集已完成项目的硬性能数据，并使用现代测量要求方法开发简单的估算方法. 如果从外部供应商处购买, 客户必须了解供应商如何确定他们的投标价格.

即使有了这些步骤, 在混沌世界中仍然存在一个内在问题，即经常需要估计并且必须在软件系统生命周期的早期建立预算，然后才能详细了解需求. 在这个阶段，估计必须不可避免地具有非常广泛的不确定性. 那么可以做些什么来减轻这一挑战的影响?

答案是一个开发过程 15 多年前由澳大利亚维多利亚州政府提出但从未广泛应用.
在简化的轮廓, 当客户发出 ITT 并附有初始要求声明时, 要求供应商估计最终的总尺寸，并对每单位功能尺寸的固定价格进行投标. 总投标价格是这两个因素的乘积. 何时授予合同以及随着需求的发展, 单价保持不变, 但总价会根据需求的大小成比例变化. 实际大小由独立的 Scope Manager 监控, 软件的“数量测量员”. 因此，客户承担改变需求大小的风险; 供应商承担基于其对客户需求和自身能力的了解而投标正确单价的风险. 通过这个过程, 客户和供应商之间的信息和风险不对称大大减少.

澳大利亚流程在芬兰进行了完善，在那里被称为“北方范围”. 它正在多个国家应用或试用. 该方法的支持者声称可以将成本超支减少到 10%.

但声称的最大好处是大大降低了软件的单位成本和提高了软件项目的交付速度. 衡量需求的能力在这里发挥的作用比想象的更广泛, 即作为质量控制因素. 如果需求不够精确以至于无法测量, 该软件当然不能可靠地构建和测试! 可以看出，雷诺管理其 ECU 嵌入式软件供应的流程和 Northern Scope 流程都依赖于软件单位定价作为关键特征.

结论, 这些工具可用于混沌世界，以在很大程度上缩小与受控世界在软件项目估算方面的差距. 但没有银弹, 没有快速和现成的答案. 工程思维和投资于收集和分析实际性能数据的准备是必不可少的.

 

关于作者

查尔斯·西蒙斯 (Charles Symons) 是该组织的创始人和前任主席 通用软件评估国际联盟. 您可以通过 cr.symons@btinternet.com 与他联系. 这篇文章以前出现在 2015 冬季通讯 的 成本分析与预测学会.

 

博文代表作者个人观点
而并不一定与官方NESMA政策一致.