详情
本书主要讲解了如何构建预估模型和怎么查验预估模型的质量。全书共有3部分13个章节。第一部分是第1到3章，首先介绍了一些常见的项目预估观点，然后讲解了预估过程的各个环节，最后介绍了一些相关的概念。第二部分是4到7章，介绍了在预估过程中有哪些环节需要被核实。第三部分是8到13章，主要介绍了构建预估模型的过程。
书名：软件项目估算
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] 阿兰·阿布兰（Alain Abran）
译 徐丹霞 郭 玲 任甲林
责任编辑 罗子超
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Title:Software Project Estimation by Alain Abran, ISBN:9781118954089
Copyright © 2015 by the IEEE Computer Society. All rights reserved. This translation published under license.
Authorized translation from the English language edition published by John Wiley & Sons, Inc.
本书中文简体字版由John Wiley & Sons公司授权人民邮电出版社出版，专有出版权属于人民邮电出版社。
版权所有，侵权必究。
本书主要讲解如何构建估算模型和验证估算模型的质量。本书分为3个部分，共13章。第一部分（第1～3章）介绍估算过程的结构，估算中必须予以考虑的大量的经济学概念；第二部分（第4～7章），介绍有关估算结果质量的概念和技术，根据估算目的增加的调整因子的局限性；第三部分（第8～13章）介绍建立估算模型过程中的问题。
本书理论知识全面、严谨，并给出了工程化的软件工作量估算方法和大量的实战经验。
本书适合软件经理、软件项目估算的审计人员和其他IT行业从业者，以及学习“软件项目管理”相关课程的学生阅读。
这本书需要仔细阅读。
目前，很难找到一本能与本书在讲解如何建立生产率模型方面的严谨性与实用性相媲美的图书。本书讲的不是用经验法估算工作量，而是用模型法估算工作量。
本书理论完备、严谨，并给出了工程化的软件工作量估算方法和大量的实战经验。
在为客户提供咨询的过程中，我帮助客户识别并建立了大量的预测模型与控制模型，积累了丰富的经验，但是，当我读到Abran博士的这本书时，我深深地被打动了。他的实践经验比我更多，思考得比我更深入，他的理论更完备、更严谨，拓宽了我的视野，让我意识到了自己学识上的狭隘与浅薄。
没有大量的实践经验，没有深厚的理论功底，没有多年的潜心研究，是写不出这本书的。
它明确区分了估算与预算，前者是项目组对成本的预测，后者是管理者对成本的决策。
它明确区分了估算、调整、决策阶段，明确了软件成本估算的生命周期。
它把估算模型区分成黑盒模型与白盒模型，强调了白盒模型是可验证的，具有更高的可信度。
它把估算模型区分成外来的模型与自己的模型，强调了自己的模型才是最合适的，不能迷信业内的一些参考模型。
它提出了分段建立生产率模型的策略，针对非正态分布的数据、非直线相关的模型，也给出了解决方案。
它对看似散乱的楔形分布趋势，提出了分类建立模型的策略，需要识别其他隐藏的自变量。
它指出了建立包含多个变量的复杂生产率模型不如建立多个简单的生产率模型更实用。
它给出了建立模型时需要的样本点的经验数值。
它对如何验证生产率模型的有效性给出了多个案例。
学会了本书的内容，相信你能在软件成本估算领域练就一双“火眼金睛”，达到“一览众山小”的境界。相信你可以快速、准确地识别各种生产率模型的正确性和实用性！
我也很喜欢Abran博士在每章之后设计的作业与思考题，这对我们深入理解本书的内容有很大帮助。本书也是全球多所大学软件工程专业的研究生教材。
本书由徐丹霞和郭玲担任主要翻译工作，徐丹霞负责翻译第1～5章，郭玲负责翻译序言、第6～13章。两位译者还进行了交叉评审，最后由任甲林进行通稿校对。译者在翻译过程中把握的基本原则就是：在翻译每句话时，首先准确理解原文的含义，然后确保中文的正确与通俗易懂。在翻译过程中，译者也和作者Abran博士做了大量的沟通，老先生耐心地解释了某些语句的内涵。
由于我们水平有限，错误之处在所难免，请各位读者不吝指正。有兴趣的读者可以加入COSMIC的QQ群（群号：309842452），与本书的三位译者讨论本书或规模度量与软件估算的话题。
任甲林
2019年7月8日
徐丹霞 麦哲思科技高级咨询顾问，软件度量与量化管理专家，COSMIC度量手册中文译者，COSMIC方法资深讲师，认证的软件成本造价师，认证的大规模敏捷（SAFe）咨询顾问（SPC），CMMI研究所授权的CMMI-DEV教员。具有多年的软件度量和功能点应用领域经验，曾协助多家企业导入功能点方法以解决项目成本估算难题。
郭玲 麦哲思科技高级咨询顾问，香港城市大学信息系统管理硕士，COSMIC度量手册中文译者，COSMIC功能点讲师，PMI-PMP、PMI-ACP认证专业人士，为多家软件公司提供了功能点方法导入的咨询与培训。
任甲林 麦哲思科技（北京）有限公司总经理，CMMI研究所授权高成熟度主任评估师、CMMI教员，CMMI中国咨询委员会（CAC）成员，COSMIC实践委员会、国际咨询委员会成员，中国区主席，AgileCxO研究所授权的敏捷性能合弄模型（APH）评估师、教练，认证的Scrum Master、大规模敏捷（SAFe）咨询顾问（SPC），具有超过25年的软件工程经验，20年过程改进经验和十多年软件项目管理咨询经验。2014年出版专著《术以载道—软件过程改进实践指南》。
Alain Abran博士是加拿大蒙特利尔市魁北克大学高级技术学院（ETS）的软件工程教授。
Abran博士拥有20年以上的信息系统开发和软件工程行业经验，以及20年的大学教学经验。Abran博士拥有加拿大蒙特利尔理工大学电子与计算机工程博士学位（1994年）、加拿大渥太华大学管理科学硕士学位（1974年）和电气工程硕士学位（1975年）。
Abran博士是通用软件度量国际联盟（Common Sofeware Mesurement International Consortium，COSMIC）的主席。他在2010年出版了《软件计量学与软件度量学》，2008年出版了《软件维护管理》 [1]，均在Wiley & IEEE CS出版社出版，并共同编辑了2004年版《软件工程知识体系指南》。
Abran博士的研究方向包括软件生产率、估算模型、软件质量、软件度量、功能规模度量方法、软件风险管理以及软件维护管理。
Abran博士的联系方式是alain.abran@etsmtl.ca。
[1] 合作者是Alain April。
项目估算不仅对大多数软件企业是一项挑战，而且对他们的客户也是一件非常头疼的事情，因为客户需要承受项目严重超支、进度延迟、软件功能没有达到预期以及质量问题等多方面风险。
目前的软件估算水平是否比40年前有提高呢？目前的估算模型是否更好用呢？
在这段时间里，软件估算方面一成不变的是什么？
40年来，关于软件估算的书籍和工具层出不穷，提出了很多解决方案（估算工具、模型、技术）以应对软件估算带来的挑战。
项目经理对他们的估算过程的质量、市场上的估算工具的性能了解多少呢？通常并不多！然而，管理层还是会根据这些估算工具提供的结果进行很多决策活动。
在估算中，软件估算人员和管理者分别扮演着不同的角色。
当一个组织已经收集了自己的数据并且有能力来分析数据、记录估算模型质量时，该组织便具备了以下两个优势：
当一个组织没有度量其历史项目的生产率时，它在以下很多方面都是未知的。
很多软件组织都处于这样的一个局面，即使用的估算模型来源于生产率不同的环境，无法提供真正的价值。当人们对以下两种情况了解甚少时，更是如此。
这些模型具有花哨的功能和成本因子，而那些对这些模型感觉良好的人，却在这些“黑盒”数据上自欺欺人。
本书将教授开发估算信息（估算数据+估算环境）的方法。该估算信息可以帮助管理者在不确定的环境下制定项目预算决策。
本书不包含以下内容：
本书将介绍软件项目估算中的工程实践，具体内容如下：
如果没有牢固的统计学基础，就不会有工程化方法，也无法进行软件估算！
本书不适合那些寻找快速的、一次性解决方案的读者。本书面向的读者是那些希望通过学习工程实践来获得软件估算方面长久且持续竞争优势的读者，并且他们也乐于学习具体实现的方法（包括在探索更复杂的统计方法之前，例如机器学习技术或模糊逻辑，使用简单且完备的统计学方法进行数据收集和数据分析的必要工作）。
本书主要分享了作者在设计可靠的软件估算流程方面多年的丰富经验。这些估算流程可以作为管理者的决策支持工具。
本书还介绍了一些基本的统计学和经济学概念。这些概念是理解如何设计、评价和改进软件估算模型的基础。
因为量化数据和量化模型是工程、科学和管理领域的基础，所以对于各种规模的软件组织而言，本书将非常有帮助。同时管理者将会在本书中找到在软件项目估算中进行量化改善相关的有效策略。书中还提供了大量的实例，供读者参考与学习。
本书适合软件经理、软件项目估算的审计人员和其他IT行业从业者，以及学习“软件项目管理”相关课程的学生阅读。
本书分为3个部分，共13章。
| 第一部分 |
第二部分 |
第三部分 |
|---|---|---|
| 理解估算过程 |
估算过程：必须验证什么 |
建立估算模型：数据收集和分析 |
| 第1～3章 |
第4～7章 |
第8～13章 |
第一部分：“理解估算过程”（第1～3章）介绍在设计和使用软件估算模型进行决策时，估算人员和项目经理都需要知晓的软件估算的多个视图。该部分解释了估算过程的结构，包括嵌入在估算过程内的生产率模型，并澄清了估算人员和项目经理在角色和职责上的区别。最后，介绍估算中必须予以考虑的大量经济学概念，比如规模经济/非规模经济、固定成本/变动成本。
第1章介绍了估算过程及其各个阶段，以及软件估算人员和管理者的不同角色和职责。
第2章介绍了一些重要的经济学概念，这些概念有助于理解并建立基于生产率模型的开发过程性能模型，特别是解释了产品模型中的规模经济/非规模经济和固定成本/变动成本的概念。本章同时展示了软件工程的一些典型和非典型数据集合的特征，并解释了生产率模型中的显式变量和隐式变量。
第3章讨论了从估算结果的区间范围中挑选一个单点值作为预算可能造成的影响，包括各种场景及其对应发生概率的识别，以及在项目投资组合层级进行应急措施的识别和管理。
第二部分：“估算过程：必须验证什么”（第4～7章）介绍一些必要的概念和技术，以理解估算结果的质量取决于其输入的质量和其所使用的生产率模型的质量，并介绍了根据估算目的增加的调整因子的局限性。
第4章介绍了当建立和使用生产率模型时，如何识别出在估算流程中必须理解和验证的多个成分。我们是从工程化角度，而非从“手工艺”角度来看待模型的。
第5章介绍分析数学模型的直接输入值的质量所需的准则，即在估算中用于预测因变量的自变量。
第6章介绍了分析数学模型质量所需的准则，以及模型的输出结果，并通过图解展示了如何使用这些质量准则来评价业内推荐的模型和工具的性能。
第7章介绍在度量活动和多因子之间的关系模型中，不确定性和误差是固有的。本章还介绍了不确定性和误差的一些来源，并阐述了当在估算过程中引入其他因子时，这些不确定性和误差是如何累加的。
第三部分：“建立估算模型：数据收集和分析”（第8～13章）介绍建立估算模型过程中的问题，包括数据收集和国际标准的使用，以便在项目间、组织内、国家间横向对比；如何使用质量数据作为输入并基于一系列经济学概念来建立具有多个自变量的模型。
第8章介绍在估算流程中应用业界模型，应基于已完整定义并规范化的参数定义。本章介绍了国际软件基准标准组（International Software Benchmarking Standards Group，ISBSG）定义的一些软件项目数据收集标准。显然，规范化的定义对于内部基准、外部基准以及建立生产率和估算模型都是至关重要的。
第9章演示了如何建立只有一个自变量的模型，需要首先识别最重要的变量，即待交付的软件规模；介绍如何使用ISBSG数据库中的项目数据进行建模，包括数据准备和对描述性变量的相应取值的识别，例如开发环境。
第10章展示了一个案例研究。该案例是关于如何应用行业数据建立以项目规模为主要因子并包含少量其他类别变量的项目模型，以及如何分析和理解该类模型的质量。
第11章介绍了如何识别出项目最好和最坏情况的生产率，以及如何从性能分析中吸取经验教训并用于估算。
第12章通过探讨规模经济和非规模经济、过程性能能力和对生产率制约条件的影响等概念，分析如何从同一数据集中识别出多个模型。
第13章介绍在一个软件项目生命周期中，有很多影响生产率的因素，比如功能的增加或修改、风险实质化等。因此，项目经常需要在生命周期的各个阶段重新进行估算。本章介绍建立重估算模型的方法。
表1为软件经理阅读的指导方案。
表1 软件经理阅读指导方案
| 推荐阅读方式 |
推荐理由 |
可实现的目标 |
|---|---|---|
| 第1章（完整阅读） |
估算过程包括多个阶段，估算人员和管理者的职责不同，且互相补充 |
验证你的估算过程是否包含本章中描述的所有阶段，并且相关职责是否明确 |
| 第2章（完整阅读） |
经济学概念对于估算目的非常有帮助：它们可以解释软件成本结构中的基础性问题，比如固定成本/变动成本、规模经济/非规模经济 |
询问一下你的软件工程师：①在软件项目中的固定成本/变动成本是什么？②在我们的软件开发过程中是否存在规模经济或非规模经济 |
| 第3章（完整阅读） |
估算人员应该提供场景和可能的估算范围。管理层可以在项目集管理的层面上，根据这些信息分配项目预算以及应急资金 |
管理者需要从一个估算范围中选择一个值作为项目预算，并且分配应急资金以管理固有的估算风险 |
| 第4～7章（快速阅读） |
估算模型应该给出“值得信赖的数字”：必须验证并记录估算模型的质量，如若不然，估算将沦为“垃圾进，垃圾出” |
要求估算人员记录估算过程中的质量控制，并且要对估算过程进行审计 |
| 第8～13章（快速阅读） |
通过标准化定义收集的数据可以在组织内及行业内进行性能比较。在进行数据分析和建立估算模型时需要使用工程化技术。当项目预算出现偏差时，一般的估算模型将不再适用；需要使用重估算模型 |
验证组织在进行数据收集时，使用的是最佳行业标准。估算人员根据这几章推荐的最佳实践来实施估算，要求估算人员建立重估算模型 |
表2为IT从业人员、IT审计人员及对如下主题感兴趣的大学生的阅读指导方案：
表2 IT从业人员、IT审计人员及对估算感兴趣的大学生阅读指导方案
| 推荐阅读方式 |
推荐理由 |
可实现的目标 |
|---|---|---|
| 第1～3章（完整阅读） |
估算模型必须基于对组织性能的了解：软件开发中的固定成本/变动成本、规模经济/非规模经济 |
当准备进行项目估算时，使用组织关于固定成本/变动成本方面的历史数据作为估算过程的基础；明确估算人员与管理者各自的职责 |
| 第4～7章（完整阅读） |
估算模型应该提供“信息”而不仅仅是数字。这4章说明了在验证组织目前的生产率模型或待使用的生产率模型时，需要验证哪些方面，并且在记录模型质量时需要使用哪些准则。同时还将介绍增加更多的因子并不会增加模型的确定性 |
对于决策制定，必须提供相关信息，如数据和背景信息，包括记录生产率模型输入的质量，以及可能的估算范围 |
| 第8～13章（完整阅读） |
为了设计一个值得信赖的估算过程，需要具备以下要素：数据收集的标准；统计异常值的识别；选择相关的样本进行数据分析；建立单变量模型或多变量模型；在重估算时，需要考虑其他限制条件 |
在估算时，基于相关的数据集，使用所推荐的技术建立合理的估算模型；在重估算时，包含其他相关的生产率因子 |
多年来，许多业内的同事以及来自世界各地多所大学的同事、以前的研究生都帮忙厘清了本书中的许多章节（详见表3），感谢他们。
表3 本书部分章节的撰稿人
| 章 名 |
撰 稿 人 |
|---|---|
| 第2章 理解软件过程性能所需的工程和经济学概念 |
Juan Cuadrado-Gallego, University of Alcala（西班牙） |
| 第3章 项目场景、预算和应急计划 |
Eduardo Miranda, Carnegie Mellon University（美国） |
| 第7章 对调整阶段的验证 |
Luca Santillo, Agile Metrics（意大利） |
| 第 8 章 数据收集与业界标准：ISBSG数据库 |
● David Déry（加拿大） |
| 第9章 建立并评价单变量模型 |
● Pierre Bourque, ETS – U. Québec（加拿大） |
| 第10章 建立含有分类变量的模型 |
Ilionar Silva and Laura Primera（加拿大） |
| 第11章 生产率极端值对估算的影响 |
Dominic Paré（加拿大） |
| 第12章 对单一数据集建立多个模型 |
● Jean-Marc Desharnais, ETS – U. Québec（加拿大） |
| 第13章 重新估算：矫正工作量模型 |
Eduardo Miranda, Carnegie Mellon University（美国） |
特别感谢以下人员：
最后，本书谨献给以下人员：
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
估算绝对不是拍脑袋想出来一个魔幻数字，并让每个人冒着失去工作的风险去承诺达成这个数值（这会导致团队成员需要加班来努力达成一个不切实际的交付日期）。
本书的第一部分由第1～3章组成，主要介绍了估算流程的一些关键概念。
第1章介绍估算流程，内容如下：
第2章介绍软件开发生命周期过程和传统的过程模型之间的关系，以及在软件项目背景下的多个经济学概念，内容如下：
第3章讨论从估算结果区间中选择一个单点预算值的影响，包括各种场景的识别及其对应的可能性，以及项目群级别的应急策略的识别和管理。
本章主要内容
如果一个组织没有度量本组织的历史项目的生产率，那么该组织将无法洞悉以下信息：
在很多软件组织中都存在这一现象——使用了与本组织生产率性能不同的其他组织的生产率模型，从而根本无法提供真正的价值。当对以下两种情况知之甚少时，更是如此：
当一个组织已经收集了自己的数据，并且有能力来分析数据、记录生产率模型质量时，则该组织具备了以下优势：
估算绝对不是拍脑袋想出来的一个魔幻数字，并让每个人都要冒着失去工作的风险去做出承诺达成这个数值（这会导致团队成员需要加班来努力达成一个不切实际的交付日期）。
本章简要介绍估算过程的各个阶段，并阐述生产率模型和将其应用于估算过程的区别。
采用数学模型进行估算，是将多个显性成本因子（这些因子为定量参数或分类参数）代入一个精确的数学等式进行运算，从而得到估算结果。然而与之相反，实际上，业界普遍使用的估算技术（也被称为专家经验法）一般都不会记录使用了哪些参数，或者明确描述如何将这些参数进行组合。
专家经验判断法的整个估算过程与本章接下来介绍的估算过程类似，只是不那么透明，当然，也无法追溯专家经验模型背后的历史数据。此外，也不可能对专家经验模型的性能进行评价，因为没有把关键的项目参数客观地进行量化和标准化，例如软件规模：
一个项目如果按照“官方”预算去管理，可能会成功。但是，如果无法验证交付了所承诺的所有功能，便不能认为估算结果正确：当只交付了要求的部分功能时，预期收益便无法收回，即与项目启动初期的成本收益分析存在出入。
我们从中可以得到结论，如果无法对功能交付情况进行相应的分析，对基于专家经验的估算结果进行性能分析的价值将十分有限。
当然，专家经验判断法高度依赖于估算人员的专业经验，并且它也会随项目的不同而发生变化，导致对该方法的性能评估十分具有挑战性。
对于专家经验的依赖为估算过程赋予了更多的技艺特征。该方法主要依赖于人的能力，而非某种经过全面测试并且完整定义的工程技术。
在决定应该包含哪些成本驱动因子，以及每个成本因子影响的特定区间范围时，基本上是完全根据一组甚至是一个估算工具的开发者的判断。
实践者通常也会尝试改进传统的软件估算模型，采用如下的类似方法：
这意味着改进过程一般是主观的，并且这种改进一般都缺少统计分析技术作支持。
从工程化的角度来看，建立软件模型是基于：
工程化建模方法首先分别研究分析每一个因子，之后再进行各因子的组合研究。
依靠这种方法当然无法找到一个适用于所有情况的模型，但是，可以找到符合部分约束条件的合理的模型。
本书正是使用这种方法作为建立生产率模型的基础：找到变量与工作量的关系，并对所有变量进行逐个研究以获得深入理解。
采取这种方法意味着首先需要找到每个变量对应的生产率模型，并且承认：
首先我们概要地介绍一下估算过程，然后介绍一些现行的实践和期望的做法。
软件估算方法的概略描述如图1.1所示。
（1）图1.1的左边部分是软件估算过程的输入条件。这些输入一般包括以下内容。
（2）图1.1的中间部分表示以生产率模型为基础的估算过程，包含以下内容。
（3）图1.1的右边部分通常是预期的估算成果物，包括软件交付所需工作量（成本或项目工期）的估算结果，以及交付的软件应满足在输入中规定的待交付软件需满足的质量水平要求。
图1.1 估算过程的示意图
在很多文献中都会用大量的篇幅介绍项目估算知识，尤其是软件项目估算方面的知识。然而，实际上，软件行业一直被大量的糟糕估算实践困扰着，如图1.2所示。
图1.2 业界一些糟糕的估算实践
（1）估算输入。
（2）估算模型。
估算模型有正式或者非正式的模型。依据该模型可以通过如下黑盒操作方式对这些未完整定义的需求进行估算。
（3）估算输出。
综上所述，在这种最糟糕的实践做法中，不管是客户还是管理层都期望他们的员工（及供应商）会承诺不超时、不超预算地交付预期的软件功能，并且还是在他们自己都不清楚期望获得什么样的具体产品功能的情况下。这种不确定性也同样会遗留到所有的新项目中。
换句话说，一方面客户和管理层期待奇迹发生，另一方面太多的软件从业者进行着糟糕的单点值估算，表现得好像他们可以持续地创造奇迹一样！
业界的一些最佳估算实践
成熟的软件组织把估算看作一个能给他们带来竞争优势的过程。为了得到这种竞争优势，他们研究估算过程并掌握了其中的关键因素，包括以下内容：
业界的一些最差估算实践
以下是一些糟糕的估算实践的例子，如图1.3所示。
图1.3 梦想：一个“准确的”估算结果
（1）估算模型的输入。
（2）模型建立过程。
（3）生产率模型。
……
（4）估算输出。
在全世界大大小小的组织中，软件项目估算是一个重复发生且重要的活动。在过去的50年里，人们对软件项目估算已做了大量的研究，并提出了无数个业界模型。那么，业内的软件估算到底怎么样呢？
答案是，不怎么出色（Jorgensen and Molokken 2006; Jorgensen and Shepperd 2007; Petersen 2011），如图1.4所示。
图1.4 项目成功趋势图（基于Standish Group数据）（改编自Miranda 2010）
著名的不确定性锥以模型的方式展示了在项目整个生命周期过程中预期的偏差范围，如图1.5所示。
（1）在项目的早期，即可行性研究阶段，对于未来的项目（ t = 0）：
项目的估算偏差最大可能达到实际值的400%，最小为实际值的25%。
（2）在项目结束的时候（ t = 项目的结束）：
图1.5 项目生命周期中的不确定性水平（改编自Boehm et al. 2000，图1.2, p. 10）
我们称这个阶段为生产率模型阶段（ t = 项目结项的时间）。图1.5中不确定性锥的最右端没有达到完全准确的原因是该图中的所有值基本上都是由专家法得到的推算值。
图1.6是一个二维生产率模型草图（假设是对于已经完成的项目），横轴是已完成项目的规模，纵轴是已完成项目的实际工作量。图上的每个点都对应一个已完成的项目（该项目的规模和实际工作量），而斜率就是表示这组已完成项目的统计学方程，也就是相应的生产率模型。
图1.6 只有一个自变量的模型
换句话说，生产率模型表示图中的两个变量间的关系，即自变量（软件的规模）和因变量（已完成的项目工作量）间的关系。
从图1.6中可以观察到，大部分项目的实际值都没有正好落在数学方程的那条线上，而是有一定的距离。这意味着生产率模型不能准确地模型化规模-工作量之间的关系：即使估算过程的输入信息没有任何的不确定性，也只有部分实际值很接近那条线，而其他实际值却离得很远。
关于模型化规模-工作量关系的生产率模型（有一个或者多个自变量），在文献中经常提到这类模型的当前性能目标，如图1.7所示，即80%的项目落在距离方程曲线20%的偏差范围内，而20%的项目落在这个范围外（但是不超过某个偏差范围上限）。
图1.7 模型准确度目标
用于建立生产率模型的背景（以及已收集的数据）与需要进行估算的背景有很大的区别：在实践中，一个项目必须在整个项目生命周期的早期进行估算（事前估算）。在这个阶段，哪些是需要开发的软件功能以及如何开发这些功能都存在很大的不确定性。
在1.5节和1.6节中，将更详细地讲解生产率模型及其在估算过程中的应用。
研究者在建立数学模型时一般都是使用已完成的项目数据。这意味着他们是基于一组已知的事实而没有任何不确定性，如图1.8所示。因此，文献中的大多数所谓估算模型实际上是生产率模型。
图1.8 生产率模型的原理示意图
待建立模型的输入内容如下。
总之，这些来自于已完成项目的输入条件可以包括以下两个方面。
（1）数学方程模型。
估算人员可以使用一系列的数学方法来帮助他们从大量已完成项目中量化地确定目标因变量（例如，项目工作量或项目工期）与自变量（产品规模和各种成本因子）之间的关系。
这些历史项目生产率的数学模型主要优势如下。
因此，生产率模型是基于已知信息建立的历史项目模型，同时：
（2）专家判断法。
专家判断法一般是非正式的，无记录的，并且专家判断法是基于对过去项目的主观回忆而得到的历史经验，通常是没有参考已交付软件的精确量化数据或者精确成本因子数据。
唯一可获得的精确数据一般是关于因变量（工作量和工期）的，而不是自变量（例如，产品规模，尤其是已交付的功能）。
此外，一般没有历史项目生产率的精确数据，也没有能够展示一组项目性能的图形。
典型的估算过程通常都是在项目早期需求不明确的时候进行的：
……
上述情况导致无法在该阶段准确地度量需求规模，最多只可以近似度量。
……
……
事实上，对于新软件项目的估算，经常是发生在这样的背景下：信息不全面、未知情况较多、存在大量风险。本章将通过一个工程化过程解决以上估算需求，并形成一套估算流程处理以下问题：
首先，根据历史项目建立的生产率模型是估算过程的核心，不管这个模型是以正式的数学方程形式描述的，还是隐藏在人的经验中以专家判断法得到的软件估算。
其次，图1.8中的生产率模型是应用于以后的项目估算中的（图1.5中的估算锥的左边），而这种情况下，输入（包括产品需求的规模和成本因子）都是无法精确知晓的并且它们很有可能存在大范围的偏差和不确定性。
横轴上预期的输入（未来的项目），其偏差范围会对变量估算结果输出（比如，纵轴上的项目工作量或项目工期）的偏差范围造成决定性影响，导致其与根据历史项目建立的生产率模型相比，可能存在更大的偏差。
估算过程包括如下5个主要阶段，如图1.9所示。
图1.9 估算过程
（1）阶段A——收集估算过程的输入：
（2）阶段B——生产率模型的使用（作为一种模拟模型）。
（3）阶段C——调整过程，对生产率模型没有包含的那些变量和信息的考虑，包括：
（4）阶段D——预算决策：确定最终的预算单点值（在项目级和项目群级别）。
（5）阶段E——在项目监控需要时进行重新估算。
下面对每个阶段进行详细的介绍。
图1.10 阶段A：估算过程中输入数据的收集
分析项目信息和收集数据，以便识别出成本因子（资源、过程和产品），作为一个具体项目的估算输入。
对识别出的成本因子值的估算：
使用生产率模型进行估算一般有两个步骤。
（1）使用生产率模型作为一种模拟模型，通常只关注输入值的估算结果（而不考虑输入值的不确定性）：
图1.11 阶段B：在估算过程中使用生产率模型
（2）利用所估算的输入值的不确定性和偏差范围数据，来调整上面第一步中所估算的输出值范围。一般来说，这一步会增大生产率模型所生成的估算值的预期偏差范围。
图1.12 阶段C：调整阶段
估算过程不仅限于盲目地使用生产率模型的输出值：
软件估算人员必须识别出这样的因子，因为它们可能对项目造成影响，因此需要在调整过程中予以考虑。
调整过程需要考虑在估算过程中还没有使用的变量和信息，包括：
注意，这个过程经常是在专家判断的基础上进行的，并且通常不仅会影响生产率模型的理论估算，而且会影响估算结果的上限和下限，并且可能会提供定性的信息，比如：
因此，估算过程的输出是一组数值，即一组信息。这些信息将应用于下一阶段的预算和项目资源分配。
图1.13 阶段D：预算决策
预算决策阶段包括从估算结果的初始范围中选择一个具体值或一组值（工作量和工期），并分配到项目中。这一阶段也是决定项目预算的阶段。
当然，对一个具体值的选择，经常被不准确地称为“估算”。预算决策主要取决于业务经理（即决策者）的策略：
应急资金的管理经常在项目投资组合层级进行，参见第3章。
对一个具体项目的预算决策（在实践中被错误地叫作“项目估算”）不应该只基于生产率模型得出的结果。
估算和预算的其他概念在1.7节中有讨论。
图1.14 阶段E：重新估算
由于估算过程内在的不确定性，项目必须监控这些值以便验证其是否按照计划进行，包括预算、进度和预期的质量。一旦与计划相比出现重大偏离，项目应该重新进行估算（Farley2009；Miranda and Abran 2008）。关于这方面内容将在第3章和第13章进行详细讲解。
在项目层级上，项目经理的直接职责只包括上述的5个估算阶段，之后他们便可以进行下一个项目了。
图1.15 估算过程的反馈环路
图1.16 阶段F：估算过程的改进
还有一个阶段一般是在组织级执行而不是项目级，包括在项目结束时利用初始估算参数来分析估算过程本身的性能，以及改进从阶段A到阶段E估算过程的各个阶段。这个阶段我们称之为“阶段F：估算过程的改进”（见图1.15中本阶段的位置、图1.16中包含的所有输入和输出汇总说明）。
估算过程的技术部分通常包括一系列场景、可能性和“估算参数”。
在该阶段必须决策出一个具体值。该值在固定价格管理模式中通常被称为“项目预算”或“项目合同额”。
软件项目的单点估算 = 糟糕的估算文化
目前，在软件行业有众多实践者和管理者提供“单点估算”。
然而，这种做法是对估算概念的常见误解。估算的目的是提供一个推测范围（从最小值到最大值以及介于这两者间的所有值——每个值对应一个相对较低的发生概率），这是估算者的职责，详见第2章和第3章。
另一个对估算概念的误解是把估算与选择具体的预算值（这是经理的职责，详见1.7.2节和1.7.3节）联系在一起，这是不合适的。预算值的选择需要承担风险并预留应急资金。该决策需要由比项目经理更高的行政层级来解决，详见第3章。
当然，这个预算值可能比整个估算范围内的其他值更受重视，主要是因为在整个项目周期过程中，需要以此为目标做各种妥协，比如减少交付功能或跳过一些评审和测试来降低质量。
预算值尽管是一个单点值，它也是由多个概念组成的：比如在某个时间点、以某一质量水平、交付响应成果物所需的预估成本和工作量。事实上，即使在项目结束时，实际成本和工作量等于预算值，也不能证明估算是对的。这里没有考虑可能有很多功能被推迟到了下一期交付，而且可能有很多质量问题遗留到了维护阶段，导致以后的成本增加。
项目预算选择（和分配）策略将取决于组织的管理文化和行业背景。
（1）过于乐观的文化（或激进的商业文化）。
在很多情况下，项目预算的决策基准都是“价格取胜”（采用最低可能价格作为报价，以确保项目批准），尽管达成这个预算的可能性基本为零。
（2）非常保守的文化。
在一个政府组织中，有多个决策层级以及很长的审批周期。管理层可能提出一个包含大量应急费用的预算，以避免因某些方面的预算不足而需要重新走一遍审批流程。这种情况可能会发生，比如在处于非竞争环境的组织中（比如商业垄断机构或政府机构）。
（3）介于以上两个极端之间的任何文化。
软件估算者在软件项目估算过程中的角色（和职责）有以下几种。
（1）建立生产率模型：包括收集历史项目数据、建立自变量和因变量之间的精确模型，并记录生产率模型的质量参数。
当组织缺少历史数据时，估算者必须找到替代方案（例如使用业界数据，或者获取可用的商业化估算工具，并分析其性能）。
（2）执行图1.9～图1.12中所述的估算过程A～C阶段，具体包括：
经理的职责是承担风险并管理风险，同时利用可用资源获得尽可能多的信息来降低风险。
经理必须基于多方信息做出决策，为某个具体场景下的项目选择一个“最佳”预算：从生产率模型以及相应的估算过程提供的区间范围内选择一个单点值作为预算。显而易见，预算决策是管理职责，而非工程职责。
当经理强迫其技术人员承诺一个单点估算值时，他就把本应是他的职责转移给了他的员工。这就是在不确定性和存在风险的背景下进行决策的内在风险。经理基于估算者提供的信息，把本应属于经理的决策职责转移给估算者。
当软件人员对一个单点估算值做出承诺时，他在其专家领域和职责范围两方面都越界了。他实际上是在做一个经理该做的事，并开始承担风险。而且他没有得到足够的报酬来履行这些管理职责。
在实践中，商业估算过程比估算过程要宽泛很多，并且不局限于某一个项目或者某一个软件项目视角。前期软件项目估算的输出不能作为决策过程的唯一输入。
从组织级角度必须考虑项目群管理，并且在决策某个具体项目之前，经理们应该考虑：
对于单个项目的决策必须在公司利益最大化的策略下进行，同时要追求所有项目的风险最小化。
经理（即决策者）的其他职责如下。
高风险项目的例子
在一个高风险项目中，考虑潜在的可观收益，决策者会想要留出应急资金储备来保证项目的完成，以防止项目超出预算。
这种应急资金可能不会跟项目管理人员交代。
本部分内容将在第2章详细讨论。
除了前面章节中描述的估算和预算的实践和概念，被（错误地）称之为“估算”技术的还有很多其他的实践，比如“抢占市场份额”这种所谓的“估算技术”。
定价策略的例子：抢占市场份额
为了抢占市场份额，一个项目可能做出低价竞标的商业决策，给客户提供一份比预期项目成本低很多的“项目预算”。
这样的市场策略背后可能隐藏着另外两个商业策略：
这会导致一种情况，忽略经过验证的技术性估算给出的范围区间，转而迎合商业策略，结果项目预算变得不切实际且不可能达成。
客户—供应商：估算中的风险转嫁游戏
几乎所有软件项目的客户都希望找到一个成本固定的项目，并且保证按时、按预算地完成，然而这里同时隐含着也要达成质量目标的期望。
事实上，除了在高度竞争的市场环境中，或是可获得海量且免费的经济指标信息时，这种情况是不常发生的。因为在客户和生产商之间存在信息不对称性。
在软件开发领域，有两个比较通用的定价模式——它们之间有很多不同之处。
（1）时间和材料计费模式。
在这种商业定价模式中，客户所付价格以其项目所花费的软件开发团队的工作量计算。人员单价已经经过协商且覆盖整个开发生命周期。这意味着，尽管供应商可能已提前分配好预算，但是没有在合约中限定供应商在某个预算内、某个时间点内、以某种质量水平交付哪些软件功能。此时供应商必须遵循最佳实践，而不是未知的预算。在这种情况下，是由客户来承担预算相关风险。因此，为超预算做准备完全是客户的责任：客户基本上是在承担全部的商业风险。
（2）固定价格合同。
在这种商业定价模式中，供应商受到法律上的约束，在具体的预算、时间点和质量水平内交付所有功能。在这种模式下，供应商承担所有风险，这些风险也相应地包含在合同中，并在合同中根据双方认可的价格预先支付应急资金以处理相关风险。在这种情况中，客户以成本为代价，理论上已将所有风险转移给了供应商。
在客户和供应商之间的经济利益得到很好的平衡的环境中，可以有效地管理这两种模式中的风险，但事实上这种情况在软件开发领域不常见。
在固定工期条件下，在预算过程的早期，精确地估算出一个固定的工作量预算，从工程化的角度来说是不可行的。
尽管存在以上问题，但很多使用者仍然坚持以一个确定的成本来给软件项目定价，并保证按时按预算完成项目；很多项目经理也承诺能够在一个固定成本下完成项目，并保证按时按预算完成。
这显示出，在估算过程以外存在一个商业估算过程，并明显有别于工程化估算过程。
在进行商业决策时，必须考虑商业目标、实践和方针。
因此，基于工程化的估算值和基于商业的估算值常常是存在显著差异的。
从公司的角度考虑，应该分别识别与管理以下两种估算类型：
这有助于清晰地区分决策职责，并且随着时间的推移，推动改进整个估算过程。
从工程化的角度考虑，软件估算过程：
本章介绍了建立一个可靠且经得起审计的估算过程应该包含的实施部件。
关键经验教训总结
本章讨论了估算过程不应该只是提供一个难以解读的单点值，而是应该提供：
再次强调不要对估算过程抱有不切实际的期望，同时也要了解估算过程包含以下两点：
1．如果你没有关于软件项目交付性能方面的组织级量化数据，是否能期望以后的项目做出合理的估算？请阐述你的答案。
2．软件估算的两个主要方法是什么？它们的区别是什么？
3．请描述几个在估算过程输入方面的最差实践。
4．请描述几个在估算过程输入方面的最佳实践。
5．请描述在处理估算过程的输出方面有哪些不好的做法。
6．业界调查显示，软件项目在达成其预算和交付期方面的表现如何？
7．“生产率模型”和“估算过程”的区别是什么？
8．如果一个生产率模型的准确度是已知的，那么将其应用于估算中的预期准确度是多少？
9．如何设计一个生产率模型？
10．如何评价一个生产率模型的性能？
11．量化生产率模型的好处有哪些？
12．在估算中，如何处理那些没有包含在生产率模型中的成本因子？
13．在估算中，如何处理那些没有包含在生产率模型中的风险因子？
14．在使用生产率模型进行估算时，组织级如何将潜在的范围变化考虑在内？
15．请阐述提供项目估算与决定项目预算的主要区别，及其在估算中的角色和职责。
16．估算的主要特征是什么？考虑到这些特征，当组织希望你提供一个准确的估算时，你能做什么？在这种情况下，为你的领导提供一个更好的“准确度”的定义。
17．当经理从估算区间中选择了一个值作为项目预算时，他应该同时做出哪些其他决策？
18．在估算过程中，组织级如何将实际范围变化考虑在内？
19．为什么组织级不但需要有一般估算模型，还需要有二次估算模型？
1．请写出你所在组织的估算流程。
2．将你们的项目性能与业界调查结果相比较，比如Standish Group Chaos报告中描述的项目。
3．将你所在组织的估算流程与图1.2、图1.15相比较，指出哪些是你所在组织的估算流程需要优先改进的地方。
4．为影响组织级软件估算流程的前三项改进点制订行动计划。
5．找到一个文献记载的估算模型，并将其与图1.15的估算流程相比较，评价其相似点和不同点，并指出所分析的生产率模型的强项和弱项。
6．找到一个供应商使用的估算模型，并将其与图1.15中的估算流程相比较，评价其相似点和不同点，并指出所分析的生产率模型的强项和弱项。
7．找到一个网上免费的估算模型，并将其与图1.15中的估算流程相比较，评价其相似点和不同点，并指出所分析的生产率模型的强项和弱项。
本章主要内容
对于一个开发过程来说，如果其现在和过去的性能以及性能偏差情况都是未知的，怎么能估算出它未来的性能呢？
本章将从经济学的角度深入探讨以下问题：
一个开发过程可以按照生产过程的形式建模。这一过程可以粗略地分解为以下主要步骤（见图2.1）：
图2.1 一个生产过程
（1）在工业中一个加工订单的例子可以是一个汽车厂商生产100辆汽车——这些汽车是完全相同的，或者有细微的差别。如果以建造房屋举例，加工订单可能包括建造一所房子所需的精确建筑细节和工程计划，那么，对软件来说，加工订单则对应待开发软件产品的一组需求描述。
（2）对一个开发过程来说，其输入主要是对软件的人力资源投入：那些参与开发项目的团队成员，他们执行整个过程中所有的子过程任务。这些输入一般是用工时（或人天、人周、人月）来度量。
（3）软件开发的一系列活动，一般是根据项目经理选择的开发方法（从瀑布模型到敏捷方法）进行安排。这些活动由开发人员完成，从而将需求转化为软件产品。在这一背景下，对于生产过程的每个活动都有一定的控制，使其满足整个生产过程乃至每一个活动的预期。这包括一组描述预期产品及其特性的需求，以及对产品或者过程的约束，即项目优先级要求（成本、质量和交付日期）。
（4）软件开发过程的输出是可运行的软件，其功能应该满足所描述的需求（软件产品）。
从工程角度来说，生产过程更为复杂，并且也需要有“监督和控制”流程，如图2.2所示。
图2.2 生产过程——工程和管理视图
此监督和控制流程必须包含以下内容：
项目目标和组织级目标是有显著区别的。
项目目标是限定在本项目上的具体目标。
这些目标可能包括根据项目范围中识别出的优先级来交付项目，通常并不考虑除项目周期外的其他组织级约束。每个项目都有计划结束日期。当项目结束时，整个开发团队就会解散，同时每个项目也有结束日期。
一般来说有多个项目目标[1]，并且都是并发的。比如需要交付：
在资源有限的经济环境中，常常假设软件项目目标能以非常不切实际的最优表现达成（基本上是以非常乐观的视角看待过程性能能力）。这些目标也不可能立刻全部达成。
那么就必须明确定义优先级：
组织级目标不受项目目标的限制。组织级目标通常是长远考虑，且范围更广。
同样地，在评价组织级目标的达成情况时，进行项目性能的对比很重要，不论项目是否使用相似的技术和开发环境：可以在组织级使用这类数据进行高效或低效的因子分析，同时进行原因调查、提出纠正措施并制订改进计划。改进计划的实施周期可能长于大部分项目的生命周期。
最后，组织级收集到的每个项目的信息可供外部标杆对比使用并用于建立和改进生产率模型。
项目优先级：一种平衡行为
在经济学及工程领域中，生产率和单位成本是两个不同的但是相关的概念。
生产率一般被定义为一个过程的输出与其输入的比率。
经济学研究中，输出的度量数据应该跟生产出的产品相关，而与交付的产品或服务所使用的技术无关。
图2.3 生产率
源代码行数（SLOC）并不是生产率研究的最佳度量元，因为其高度依赖于编程语言以及很多其他因素，比如程序员的风格和标准。
SLOC在项目开发使用单一编程语言的组织中是有帮助的，但在混合使用多种编程语言的软件项目中帮助较少。
【例2.1】 软件开发组织A，基于网页开发的项目平均生产率是30功能点/人月，而软件组织B同类项目的生产率是33功能点/人月。
两个组织的输入和输出变量使用同样的度量单位，而它们在同一应用领域的生产率有10%的差别。这一差别说明组织B比组织A的生产能力高10%，但这并不是差异的原因。引起这种差异的原因通常为生产率公式外的其他因子。
生产率通过两个显式变量（输入和输出）将过程性能量化表达，但对于过程本身或所开发的产品，该公式不包括任何文字说明信息或量化说明信息。也就是说，流程只是隐含在这个比率公式中。
生产率之间的对比是有意义的，因为它不依赖于产品开发所使用的技术和其他资源。
单位工作量一般定义为生产率的倒数，即输入除以输出。
【例2.2】 接例2.1，如果1人月有210工时，对于基于网页开发的软件组织A来说，每月30个功能点对应的单位工作量是210h/30功能点，也就是7h/功能点的单位工作量。对于另一个从事银行资金转账功能的软件开发组织来说，每月10个功能点，210工时的单位工作量是210h/10功能点，也就是21h/功能点的单位工作量。
单位工作量比率经常用于文献研究和基准研究中。在国际软件基准标准组织（ISBSG）的定义中，单位工作量比率也被称为“项目交付率”（PDR），参见第8章。
软件开发中的生产率和效率
亨利和查尔斯在60h内，各自编写了3个同样功能的函数，其规模为10个功能点。亨利写了600SLOC（源代码行数），而查尔斯写了900SLOC，他们使用的是同一种编程语言。
生产率：亨利和查尔斯的生产率都是在60工时内完成10功能点（或每6h1个功能点）。因此，他们的单位工作量比率（生产率的倒数）是6h/功能点。
效率：对于同一组功能亨利用了600SLOC，他的效率比查尔斯（用了900SLOC）高。在使用同一种编程语言把需求转化为SLOC的情况下：亨利的效率是60SLOC/功能点，而查尔斯的效率是90SLOC/功能点。
因此，在将需求转化为SLOC方面，尽管他们的生产率相同并且有相同的单位工作量比率，但亨利比查尔斯的效率更高。
这个例子只是展示了在项目生命周期内的短期效率，而不是跨越整个维护周期的长期效率：如果某个功能用了过度简化的代码行实现，其维护工作可能极其困难，使得长期效率降低。
重要发现如下：
（1）SLOC可以定量地表示使用某项技术是怎么做的，而不能表示使用某项技术产出了什么。因此，SLOC不足以作为生产率计算和研究的度量元。但是，在使用同一技术的前提下，SLOC可以作为效率研究的度量元；若使用不同的技术，SLOC则可以作为效率对比的度量元。
（2）交付的软件功能的度量元可以量化给用户交付了什么。并且，这些度量元与软件开发过程的输出相对应。因此可以形成一个完善的概念，用于生产率的度量和分析。软件功能度量的国际标准有助于我们在不同的开发背景和环境间进行生产率的比较和分析。
效率（Efficiency）和性能（Performance）
效率与性能是不一样的，后者是一个更宽泛的概念。效率指的是用更少的资源，或更低的成本生产某样产品。
举例来说，一个汽车生产商可能比其竞争对手生产一辆汽车的效率更高，但是也许在市场销售情况不乐观；或是该生产商的汽车对购买者来说不那么有吸引力，人们更喜欢其竞争对手的汽车，即使对方的价格更高。同样，一个汽车生产商可能效率不高，但在汽车销售方面成绩却有成效，因此尽管其单位成本高，但可能获得更多的利润。
在软件领域，判断两个程序员的表现或是两个软件组织的性能时，代码可读性、可维护性、易测试、交付产品缺陷密度、内存使用率等都是需要考虑的重要因素。
本节将介绍一个用一组历史项目的平均生产率建立的生产率模型。
求均值是大家熟知的一个数学方法，有其相应的特性（以及局限性）。平均生产率的建立过程如下：
注意：这个平均值描述的是所有样本，而不是样本中的某个项目。
除此之外，在求得均值的同时，可以获得以下有关的特征值：
用平均生产率建立的生产率模型见图2.4，其平均值、四分位数、最小值、最大值在图中构成一个箱线图：样本的均值即是图中灰色箱子内的那条水平线[2]；最大值和最小值分别在四分位数以外。
图2.4 箱线图：平均值和四分位数
标准差（σ，读作西格玛）代表与均值的偏差有多大，或者叫作离散程度：标准差很低意味着数据点与均值距离很近，而标准差高则意味着数据点分布在一个很大的范围内。图2.5展示了正态分布（或高斯分布）的标准差对应的位置。
1σ = 68.27%意味着68.27%的数据点在均值上下1σ的区间内。
2σ = 95.45%意味着95.45%[3]的数据点在均值上下2σ的区间内。
图2.5 正态分布及其标准差
软件工程行业中，一组数据的分布不一定是正态的，甚至经常相差很远。相对于正态分布的偏离程度一般定义为偏度和峰度。
偏度度量了随机变量概率分布的不对称性，是一个实数。它可能是正数，也可能是负数，如图2.6所示。
图2.6 相对于正态分布的偏度
峰度是对分布“尖度”的描述，如图2.7所示：与偏度类似，峰度也是对概率分布形状的描述。在图2.7中，蓝色和红色两个分布的均值相同，但是B曲线有一个很高的尖顶，即较高的峰度，并且其位于1σ区间内的数据点都离均值很近。而A曲线与B曲线均值相同但尖顶比较低，即峰度较低，而其位于1σ区间内的数据点都离均值较远。
图2.7 正态分布的峰度
综上所述，用均值建立的生产率模型较为适用，但是有限制条件：数据分布是正态的，并且在偏度受限、峰度较高的情况下，如图2.7所示。在其他情况下，当用作估算时，因为估算误差的范围可能会很大，因此均值可能会误导我们。
图2.8所示的是一个非线性模型。如何从一组项目数据中得到一个线性模型呢？我们应该使用什么统计技术呢？
图2.8 指数大于1（实线）或者指数小于1（虚线）的幂函数模型
有一种技术叫作统计线性回归（可参考任意一本有关于回归技术内容的统计学书籍）。在统计学软件中，输入一组数据点，通过多次循环能够计算出一个最能描述这组数据的回归方程（当设置为线性回归时，输出的是一条直线）。
最小二乘法是得到回归方程的典型方法，因其相对简单且能生成较为适用的方程。
在文献中还有很多其他类型的回归模型，比如指数模型和二次方程模型。
当然，一个生产率模型不一定必须是线性的：由于生产过程不同，其模型可能表现为任何形状。目前的统计技术可以建立各种形状的生产率模型。
举例来说，一个幂函数模型，公式如下：
Y（工作量）= A × 规模B
图2.8是两个指数模型：一个模型的指数大于1，另一个模型的指数小于1。
注意：当指数等于1时，它表示为一条“直线”的模型，即线性模型。
当然，也有其他更复杂形状的模型，如二次方程模型，如图2.9所示。
Y = A + BX + CX2
图2.9 一个二次方程模型
甚至可能有随着规模的增加、总成本减少的模型。在这样的案例里，模型的斜率是负的，如图2.10所示。
图2.10 一个斜率为负数的生产率模型
这在实践中是很反常的，一旦发现这样的模型，实践者应该检验用于建模的数据的质量。
模型中带有负数 = 警告
不管模型中的负数是常量还是斜率，都相当于给实践者和研究者亮了红灯。在这种情况下，应该仔细检查数据集，以验证量化数据的质量，同时注意是否存在明显的离群点。
实践者应注意不要使用模型的负数区域——因为这一区域的估算值没有意义。
同样，实践者也不应该使用模型中超出建模数据范围的区域，因为这些区域没有数据支持。
图2.11所示的一个简单模型，一般代表历史项目的性能：
可以看到，图2.11上的数据点代表已完成项目所交付的功能规模对应花费的时间（小时）[4]。
图2.11 为包含固定成本和变动成本的生产率模型（Abran和Gallego[2009]，经Knowledge Systems Institute Graduate School许可后引用）
关于生产过程性能的量化模型经常是基于已完成项目的数据建立的，即此时：
图2.11中的斜线是表示生产过程的量化模型。在生产过程中，通常有两种主要的成本类型使得输出分成两部分。
图2.11中，变动成本对应线性模型的斜率，即斜率=a（表示为h/功能点）。
图2.11中，固定成本对应为b（多少小时），代表当横轴的规模=0时，量化模型与纵轴的交叉点。
术语：变动成本和固定成本
在模型中，固定成本代表成本中不随自变量而增加的部分，本书也采纳这一通用术语。
软件项目中固定成本的例子
独立于项目规模，软件组织的运营制度中要求的一些基本的内部交付物（项目管理计划、变更管理流程、质量控制、审计等）。
在一个典型的生产过程中，这些交付物大部分会被认为是项目运作的固定成本。同样对于一个软件项目，项目管理计划不依赖于所交付软件的功能规模变化。
线性模型是对工作量和规模之间关系的刻画，其公式如下：
Y（工作量，以工时为单位）= f (x) = a × 规模 + b
其中，
根据以上参数的单位，这个方程基于图中历史项目性能给出一条斜线，代表此生产过程的性能。
Y（小时）=（小时/功能点）× 功能点 + 小时 = 小时
图2.12和图2.13展示了另外两种生产过程。
图2.12 无固定成本的生产率模型
图2.13 固定成本（理论上）为负的生产率模型
这种情况可以用统计数学模型表达出来，但是实践者如果用业界数据建出了这种初始常量为负的模型，使用时要尤其小心！
带有负数常量的线性回归模型
对于规模小于线性模型所覆盖的横轴范围的项目，这种模型没有意义。
对于规模大于模型起始点的项目，模型是有意义的（算出的工作量是正的）。
当然，对规模接近模型正负交叉点的项目的解读要格外小心。
实践相关建议如下：
（1）识别出模型所覆盖的横轴规模范围。
（2）将数据分成两组。
B1——项目规模从0到与横轴交叉点的规模阈值。
B2——规模大于这个阈值的项目。
（3）对每组数据单独建模（B1，规模小于阈值的项目；B2，规模大于阈值的项目）。
（4）估算时，依据所要估算的项目规模，选择模型B1或B2。
在生产过程中，可能存在以下情况：
当增加单位输出所需的单位输入增加较小时，这一生产过程被称为是规模经济型，如图2.14中的直线A与直线C比较。
输出增加相同的量时，直线A代表的生产过程增加的工作量（y轴）要明显少于直线B或C代表的生产过程增加的工作量。
相反地，当增加单位输出所需的单位输入增加较大时，此生产过程被称为非规模经济型：每增加一个单位的产出，生产过程的效率就更低一些，如图2.14所示的直线C。
图2.14 规模经济（直线A）和非规模经济（直线C）
覆盖整个规模范围，输出呈相似增长的生产过程如图2.14的直线B所示。
关于规模经济和非规模经济，也可参见Abran和Gallego（2009）。
在这种图形中，x轴是规模、y轴是工作量（或工期），负斜率表明，大规模的项目与小项目相比，过程总投入反而减少了（这里是工作量或工期）。当然，这种情况在经济学中没有实际场景能够解释清楚。如果发现此情况，建议检查是否是数据收集的问题。
本节将讨论在各种软件工程文献中以及各个领域公开数据库中记载的数据分布的不同类型。
图2.15所示的项目分布经常出现在软件工程文献中。我们可以看到，随着x轴规模的增加，y轴的数据点相应地呈扩散性增加。
图2.15 软件工程中的楔形数据分布
这一图形经常被称为楔形数据集。
这种情况（规模增加时，工作量呈扩散形增加）说明在这些数据集中，当所有项目汇总在一个库里，单靠规模不能充分说明与工作量的关系，所以需要其他自变量的加入。
这种在软件生产率方面扩大的分散形态一般是由以下单个原因或多种混合原因引起的。
另一种项目分布类型如图2.16所示。图中工作量的分散程度与规模的增加是高度一致的。这通常称为同质化数据集，在这种情况下，软件规模的增加能够充分地解释工作量方面的增加。这种软件项目数据分布在文献中也有过记载，例如，Abran和Robillard（1996）、Abran et al.（2007）、Stern（2009）、Lind和Heldal（2008，2010）。在这样的分布中，80%～90%的工作量增加的情况都能用功能规模的增加解释，剩余的10%～20%则由其他因素引起。
在这些数据集中，数据点间距更小，并且规模的增加使得工作量保持一致的增加，与楔形数据集相比，其工作量的增加保持在相同的范围内，却没有呈现出典型的楔形数据集模式（当规模增加时）。
图2.16 软件工程中同质化数据集的规模-工作量模型
这种在项目生产率方面的低离散形态一般是由以下单个原因或多种混合原因引起的。
注意在图2.17和图2.18中展示的两个案例有以下两个共同特征：
图2.17 Telon分布（Abran et al. 2007，经John Wiley & Sons, Inc.允许后引用）
图2.18 21个项目数据构成的同质化数据集（Abran和Robillard 1996，经IEEE publication允许后引用）
以二维方式表达的线性生产率模型（可能是一条直线或者指数曲线），不管是以图2.8～图2.16的图形形式，还是一元方程形式，都是只对两个显式变量建模：
在使用和解读这类模型时，经常被忽略的是还有一个潜在的、非常重要的、隐含的维度，就是过程本身。
过程由多个变量组成/过程被多个变量影响，每个变量都可能对开发过程的生产率造成影响。
过程中隐式变量的例子
然而，如果在一组项目样本中，大部分变量都是相似的，那么它们对单位成本的影响就很小：在这样的数据集中，可以合理地认为功能规模将是影响规模的主要变量。
下面通过两个例子进一步解释该情况，如图2.17和图2.18所示。
【例2.3】 图2.17所使用的相对同质的数据集，这些数据来自同一个组织的多个项目，这些项目是在20世纪90年代末期使用TELON平台开发的应用。所有项目都遵循一套完善的开发和项目管理流程，由同一个团队完成，且全部属于财务系统领域。在这组数据中，只用规模增长便可以解释75%的工作量增长。
【例2.4】 图2.18中的项目来自同一个组织：
这个组织在那时候已经满足了CMM模型3级的所有关键过程域（除了一个），并且已经充分具备5级的实践证据。
因此，在这个组织中，开发流程被认为是可控的，且有能力进行充分的估算，以满足在功能数量、交付期和质量水平方面的项目承诺。
此外，这些项目大多是由同一个项目经理进行管理，并且由同一组成员完成。员工流动性不高，并且员工是在同一应用领域（银行软件）下，使用基本一致的软件开发环境和开发平台。
总之，当数据来自多个组织的项目（比如ISBSG的数据库）时，呈现显著差异的大部分变量通常会在当前开发环境中被固定下来（成为常量）。这种情况下，规模可以解释因变量（也就是项目工时）中的大部分波动就不足为奇了。
当这么多成本驱动因子或自变量，在所有项目中没有较明显的区别时，便可以认为它们是常量，对项目单位成本没有显著影响。
软件估算的圣杯
一个通用的模型，它可以在任何时间点、任何情况下，十分精确地预测任何项目。
在业界及文献中建立软件工程估算模型的经典方法，就是建立一个多变量的估算模型，其中包含尽量多的成本驱动因子（自变量）（一个“万能”模型）。
估算模型的建立者通常希望从已完成的项目数据集或文献中挖掘尽可能多的变量：
这种方法，当然会导致生成一个具有多个变量“n”的复杂的模型，然而该模型又无法在n维空间进行表示。在第10章中，我们将讨论另一种建立多变量估算模型的方法。
业界还有一种常见的建模方法是基于实践者对各种变量的理解以及每个变量对开发过程的影响预估来建立模型。这种基于观点建模的方法，称为“专家经验法”，通常用于组织没有收集数据的情况。
我们真正关心的问题是：这些模型有多好用？详见第4～7章，如何分析估算模型的质量。
“感觉良好”的估算模型
包含多个经验判断成本因子的模型通常被刻画为“感觉良好”的模型。
管理者认为很多重要的成本因子已经被考虑在内了，因此他们相信已经降低了估算的风险。
但是，这些模型的质量是通过经验来支持的，这会导致很多不确定性。
在本书中，我们将采用一种折中的（也有可能是更实际的）方法。
目前业界和实践中的研究无法证明一个通用的模型是实际可行的。
专家和研究人员都已意识到这些模型没有太多共同点，并且大多数模型无法在其建立的背景环境之外的情况下使用。
让我们回顾一下软件项目中常见的楔形数据集（见图2.15）。当从规模经济和非规模经济理论的角度进行剖析时，我们看到一个楔形数据集可以被分成3组数据进行分析，如图2.19所示。
图2.19 楔形数据集中代表规模经济/非规模经济的3组数据（Abran和Cuadrado 2009，经Knowledge Systems Institute Graduate School许可后引用）
对于这组数据，规模方面的小幅增长将导致工作量（固定成本或变动成本，或二者同时）大幅增加。
这可能意味着在这组数据中会有3个生产率模型：
f1(x) = a1 x + b1，对应区域1的数据样本；
f2(x) = a2 x + b2，对应区域2的数据样本；
f3(x) = a3 x + b3，对应区域3的数据样本。
这3个模型都有各自的斜率（ai）和各自的固定成本（bi）。
导致规模经济和非规模经济可能的原因
在非规模经济效应较明显的这组数据中，每个项目都有极高的保密要求和安全约束。
在规模经济效应较明显的这组数据中，每个项目都利用了历史数据库的信息，即不需要生成和验证新数据，而且复用代码比例都很高，也没有保密要求。
下一步的问题是：是什么导致这3个模型完全不同？
当然，只通过图形分析不可能找到答案。
下一步，需要对每组数据进行分析以确定：
注意：其中一些值可以被分类（按照定类来区分，比如一组项目使用了一个特定的数据库管理系统（DBMS），另一组项目使用了另一个DBMS。）
我们可以根据不同值的特征进行数据分组并建立参数，这些参数用于在估算的时候从3个生产率模型中做出选择，参见第11章。
本章详细探讨了一些在生产过程中起关键作用的经济学概念，包括固定成本、变动成本和规模经济、非规模经济，并结合软件工程数据中的楔形数据集或同质化数据集，从规模与工作量关系的方面，详细解释了这些概念。
1．通过增加软件项目的输入、活动及输出，更加具体地阐述图2.1的生产过程。
2．通过增加目标、度量元和行动措施，更加具体地阐述如图2.2所示的评价和控制过程。
3．举例说明哪些组织级目标看起来与项目目标矛盾。讨论一下当出现这种情况时，项目经理应该采取什么措施。
4．SoftA为一个软件开发子公司，该公司的平均生产率是30个功能点/人月（基于网页的开发）。而另一个子公司SoftB的生产率是10功能点/人月（现金转账处理软件的开发）。这两个子公司使用相同的度量单位衡量它们的输入和输出。请比较它们的生产率，即网页开发的生产率与现金转账处理开发的生产率有何差别？
5．基于代码行计算的生产率有什么问题？讨论一下这一比率的优势和劣势。
6．根据下面的表格计算亨利和查尔斯的生产率和效率。
| 成员 |
输出（功能规模） |
输入（h） |
LOC |
生产率（基于？） |
效率（基于？） |
|---|---|---|---|---|---|
| 亨利 |
10 |
60 |
600 |
||
| 查尔斯 |
10 |
60 |
900 |
7．对于一组数据，除了均值，还应该观察哪些其他特征？
8．什么是正态分布（或高斯分布）？
9．对于一组有明显倾斜的数据，取其平均值用于估算是否合理？
10．当你对一组数据的详细信息不了解时，是否应该取其均值用于估算？
11．如果一个幂模型的指数是1.05，它跟一个线性模型是否有很大的不同？
12．当一个幂模型的指数是0.96时，意味着什么？
13．如果一个线性回归模型的常量为负时，这个模型是错的吗？
14．如果你的模型的斜率为负，意味着什么？你该怎么办？
15．如何确定一个开发过程产生了规模经济？
16．请用图形表示一个非规模经济的软件开发过程的生产率模型。
17．在哪一成熟度等级能够观察到楔形数据集和同质化数据集的数据？这样的模型对于组织来说意味着什么？
1．图2.2提到的评价和控制流程是针对整个项目的。然而，这样的流程也可以在项目的各个阶段实施，从可行性调研阶段一直到维护阶段。请描述你的组织是如何在项目的每个阶段实施（或应该实施）评价和控制流程的。
2．收集你的组织在过去一两年中已完成的项目信息，并把数据画在一个二维图形上，功能规模是自变量，工作量是因变量。这组数据生成的二维图形是什么形状？这个形状说明你们的开发过程性能是什么样的？
3．你参与的最近3个项目的单位成本是多少？如果你没有这些数据，为什么你的组织不收集这些基础数据？
4．在你的组织中怎样确定软件项目的固定成本？
5．你的组织使用的估算模型是一个万能模型吗？如果是，这个模型好用吗？
6．你的组织有多少数据可用于建立生产率模型？如果没有数据，管理层不收集这些数据的理由是什么？
7．如果你的组织没有现成的数据，那如何进行收集？你的组织愿意花费多少代价得到这些数据？如果你的组织没有打算做任何投入，是不是说明数据对他们没有价值？
[1] 在敏捷方法中，目标是指冲刺目标。
[2] 此处是箱线图的另一种画法，即采用平均数作为箱子的中间线，而非中位数，和通常的画法有所不同。——译者注
[3] 此处和原著作者Alain做了讨论，修订了原文中的数字。——译者注
[4] 或工时单位，如人天、人月、人年。
