
2.8.1 软件历史数据的泄漏
作为一系列软件成本估算工具的开发人员,本书的一位作者经常被问到一个似乎很简单的问题:“估算与历史数据相比,有多准确?”
这个问题的答案出人意料。通常估算要比历史数据准确得多,因为历史数据是不完整的且遗漏了大部分累积的实际成本和工作量。在有些案例中,历史数据只捕捉到所消耗总工作量的30%甚至更少。
因此,当将来自准确的软件成本估算工具的输出和所谓的历史数据相比时,其结果常常很惊人。估算工具的输出经常比历史数据显示出更高的成本、更多的工作量和更长的工期。极少有人认识到其差别是因为历史数据自身的主要不足和遗漏,而不是因为估算的错误。
公平来讲,如果历史数据是不完整的,怎么可能知道真正的数值,并判断项目历史数据收集中所丢失的数据量呢?
为了纠正成本跟踪系统中普遍存在的不足和遗漏,有必要对开发团队成员以及项目管理人员进行访谈。在这些访谈会议期间,会将为项目收集的历史数据内容与一个类似项目的完整工作分解结构进行比较。对于工作分解结构中的每项活动和任务(它们不在历史数据中),询问开发人员该活动是否发生了。如果确实发生了,则要求开发人员根据记忆或他们非正式的记录重建所丢失活动用掉的小时数。
软件成本跟踪系统中的错误和“泄漏”问题与软件行业一样古老。本书一位作者的Applied Software Measurement一书第1版出版于1991年,第3版出版于2008年。但是2011年成本跟踪系统中错误的量级本质上和1991年的是相同的。按重要性排序,历史数据中最为常见的遗漏,包括以下这些。
并不是所有这些错误都会发生在同一个项目里,但是其中有足够的错误发生得很频繁,以至于对于严肃的经济学研究,对于公司间的基准点比较,或者对于判断增长率的基线分析而言,来自项目跟踪系统的普通成本数据基本上是无用的。
一个更基础的问题是大多数企业完全不记录任何数据,除了实际执行的活动中的一小部分。在与项目管理人员和项目团队的关于确认和纠正历史数据的访谈中,该作者观察到下列不完整和丢失的数据模式,使用了他的表(见表2-17)中的40种活动作为参考。
由于DoD(美国国防部)合同的规则,DoD软件项目所保存的数据比90%的平民项目更加准确。因此,DoD项目的生产力似乎都要比相同规模和类型的平民项目低得多。当度量特定的活动(如编码)时,DoD项目实际上和平民项目相同,有时甚至会更好。
然而,DoD项目创建的文档数大约是类似平民项目的两倍,并且文档大小也几乎是平民项目的两倍。要理解这些问题,需要有活动级别的度量。
当本书作者及其同事收集数据时,他们要求管理人员和员工尝试重现任何可能遗漏的成本元素。虽然来自记忆的重现数据明显不够准确,但是也好于完全丢掉被遗漏的数据。
遗憾的是,大多数软件文献和很多历史研究只记录了整个项目级别的信息,而不是特定活动级别的信息。这种粗糙的“底线”数据不容易得到确认,而且对于严肃的经济学目的而言几乎没有用处。
为说明软件跟踪系统“泄漏”的影响,考虑一个样本项目中完整的开发周期会是什么样子。样本是一个使用C语言编写的PBX交换系统。表2-18说明了全套的活动和成本。
现在考虑一下,同样的项目如果只有编码和单元测试被公司的跟踪系统记录的话,将会是什么样子。表2-19给出了结果。
表2-19指出生产率为每人月21个功能点,而不是表2-18中的每人月6个功能点。表2-19指出工期少于7个自然月,而不是表2-18中的将近25个自然月。并且,报告的成本只有525000美元,而不是1874910美元。
如此重大的错误不应当发生,但是令人遗憾的是,它们不仅发生了,而且还发生在将近90%的软件生产力度量报告中。
而且表2-18和表2-19是在度量同一个项目。遗憾的是,“历史数据”所记录的信息和表2-19中展示的部分结果而不是表2-18中展示的完整结果更加匹配。
开发组织被定义为成本中心的内部软件项目,在收集软件数据方面是最不完整和最不准确的。很多公司和政府机构的内部开发项目缺乏有用的历史数据。因此,这样的组织往往对其内部估算非常乐观,因为没有可靠的比较基础。如果切换到商用的估算工具,他们常常会惊讶于结果是多么的昂贵。
合同约束下构建的外部项目以及开发组织作为盈利中心的项目,有着更强的激励机制去捕捉准确的成本。因此合同工和外包厂商可能比内部软件组保存有更好的记录。
表2-20给出了本书的一位作者曾访问过的150多家公司跟踪方法的大概分布。
成本跟踪系统的遗漏和在应该包含哪些活动方面的巨大分歧是目前软件行业的主要问题。当有如此多的报告数据都不完整并且所记录的活动很不相同时,完成统计分析或创建准确的基准是非常困难的。
“历史数据”中的不足和分歧解释了为什么作者和他们的同事认为,在接受历史数据之前,有必要去现场和项目管理人员及技术专家面谈。未经确认的历史数据经常是如此的不完整,以至于其对基准点和行业研究的价值全无。
这些表格所说明的问题仅仅是一个深层问题的表面现象。50多年来,软件行业缺乏任何与收集历史数据的标准表格类似的东西。现实生活中,实际所执行的活动存在很多差别,使得这种缺乏更加严重。差别的原因包括应用程序的规模、类型和方法论。
众所周知,瀑布项目和敏捷项目所执行的活动集是不同的。但是,和记录下来的相比,瀑布项目和敏捷项目往往都遗漏了很多工作量,并且都没有跟踪活动级别的成本和工作量。