罗伊斯（Walker Royce），是IBM全球服务的副总裁，他管理过许多大型的软件工程项目，为许多软件开发组织提供咨询，在软件管理方面发明了许多创新方法，并编著了《Software Project Management: A Unified Framework》（Addison-Wesley, 1998）一书。<br>    Kurt Bittner，是Ivar Jacobson咨询公司在美国的首席技术官，他在软件行业工作了27年，所从事的工作包括开发人员、团队领导、项目经理、架构师和业务领导，与人合著出版了《Use Case Modeling》（Addison-Wesley, 2003）和《Managing Iterative Software Developme Projects》（Addison-Wesley，2007）。他还撰写过很多篇文章，特别是改进需求和软件开发管理实践等领域的文章。<br>    Mike Perrow，是IBM软件集团中Rational组织的一位撰稿人和编辑，是《The Rational Edge》在线杂志的创办人。

    《软件开发经济学》讲的是如何管理软件开发项目，从经济学的角度介绍了如何有效地管理有限的资源以达到最优结果，描述了在迭代式的项目中频繁修正航向的好处，以及如何统筹兼顾和度量中间结果。《软件开发经济学》第一部分讲述在当今商业气候下软件开发和管理的情景、成功的难点以及失败的结果。第二部分介绍了以迭代式开发原则和实践为基础的软件工程的现代方法。第三部分更详细地讲解了如何通过度量来确定所采用技术的作用。《软件开发经济学》适合商业组织中的各级领导人以及任何希望成功管理软件项目的人员阅读。

    除了这些机构以外，软件业的专业人士们也在频繁地求教于其他行业所公布的一些指南，比如Six Sigma（发源自Motorola公司的一套以降低缺陷为目标的工作规范）和精益制造（丰田公司开创的一种“以减少制造过程中的浪费为目标”的概念）。无论是精益制造还是Six Sigma，都不是专门为软件产业所设计的，但是这种对于解决软件项目管理难点的执著还是一直激励着业界领袖和从业者们去思考各种通用的为项目管理而编制的指南。<br>    此外，自从2000年以来，各种组织和专业联盟已经提出了很多不同的新方法来解决软件项目中天生的难点，比如敏捷联盟、Scrum联盟、极限编程社区，更别说还有如OpenuP（the Open unified Proeess）那样的各种开源的（非商业性的）项目了。每个组织都推出了不同的开发方法，每种方法都对特定的软件开发团队有所帮助，团队的规模、风格、集体的经验程度决定了其中一种方法更适合自己。<br>    尽管这些专业团体和公司的观点和目标不同，但它们的方法都强调了一个共同的目的，那就是：要克服那些从20世纪60年代就开始流行的传统软件开发技术的不足。总结起来说，在这些新方法与那些较传统的方法之间，最主要的差别就是：新方法代表的是迭代式的增量开发的实践，而旧方法代表的是瀑布式的开发实践。这在某种程度上似乎是一种粗略的特征划分，但这一区分足够合理，能够达到我们想要的目的。<br>    ……

前言<br>第一部分 软件驱动的经济<br>第1章 软件项目管理的挑战<br>1.1 软件开发中的高风险<br>1.2 制度上的关注<br>1.3 传统的软件项目管理<br>1.4 瀑布方式的问题<br>1.5 小结<br><br>第2章 达成结果：软件经济学的案例<br>2.1 迭代式开发<br>2.2 基于结果的方式的益处<br>2.3 成功的标志<br>2.4 小结<br><br>第二部分 提高软件开发的经济效益<br>第3章 软件经济学的趋势<br>3.1 软件经济学的简化模型<br>3.2 软件工程：40年历史回顾<br>3.3 改进的关键：平衡的方法<br>3.4 小结<br><br>第4章 降低软件项目的规模或者复杂度<br>4.1 管理范畴<br>4.2 降低人工编写的代码的规模<br>4.3 使用面向服务的架构增强复用<br>4.4 小结<br><br>第5章 改进开发的过程<br>5.1 项目过程<br>5.2 使用迭代式的过程<br>5.3 及早应对重大风险<br>5.4 增量式地改进实践以达到目标<br>5.5 小结<br><br>第6章 提高团队效率<br>6.1 提高个人绩效<br>6.2 改进项目的团队协作<br>6.3 提高组织级能力<br>6.4 小结<br><br>第7章 通过集成工具来提高自动化<br>7.1 提高个人生产力<br>7.2 减少错误源<br>7.3 使过程改进可能进行<br>7.4 小结<br><br>第8章 通过常识来加速文化的改变<br>8.1 成功组织的特征<br>8.2 成功的关键<br>8.2.1 低中级管理者是关键的执行者<br>8.2.2 需求、设计和计划要可变并且具体<br>8.2.3 鼓励进行雄心勃勃的演示<br>8.2.4 项目性能的好坏在生命周期的早期更明显<br>8.2.5 早期的迭代应该是不完全的<br>8.2.6 详细完整的工件在早期不太重要，在后期比较重要<br>8.2.7 真正的问题会系统化地出现，也应系统化地加以解决<br>8.2.8 质量保证是每个人的职责，不是一个单独的行当<br>8.2.9 应该把在自动化方面的投资看作是必要的<br>8.3 建议：选择正确的项目、正确的人、正确的目标<br>8.4 小结<br><br>第三部分 软件工程的实用度量<br>第9章 实用的软件开发度量观<br>9.1 度量与目标<br>9.2 易变性和目标<br>9.3 度量与迭代开发<br>9.4 度量工作何时会出错<br>9.5 事先制定详细计划错在哪里<br>9.6 在每个阶段分别确定要度量什么<br>9.7 小结<br><br>第10章 在起始阶段度量什么<br>10.1 评估财务可行性<br>10.2 评估技术可行性和估计总体项目成本<br>10.3 起始阶段中的迭代<br>10.4 其他度量<br>10.5 小结<br><br>第11章 在细化阶段和构造阶段度量什么<br>11.1 细化阶段的度量工作<br>11.2 如何度量风险的降低<br>11.3 如何度量进展情况<br>11.4 构造阶段的度量工作<br>11.5 如何度量backlog<br>11.6 如何度量测试覆盖率<br>11.7 如何度量构建稳定性<br>11.8 构造阶段的预期进展趋势<br>11.9 小结<br>11.9.1 细化阶段<br>11.9.2 构造阶段<br><br>第12章 在交付阶段度量什么<br>12.1 交付阶段的度量工作<br>12.1.1 度量什么<br>12.1.2 分析趋势和评估测试结果<br>12.1.3 影响可发布性的其他一些需要考虑的事项<br>12.2 如何对交付阶段进行总结<br>12.3 小结<br><br>第13章 在嵌入规划的项目中度量什么<br>13.1 将项目组织起来构成规划<br>13.2 如何度量规划的进阶<br>13.3 小结<br>附录A 迭代式项目管理起步<br>推荐书目