《软件开发生产率改进：软件管理的有效领导力与量化方法.html.pdf》由会员分享，可在线阅读，更多相关《软件开发生产率改进：软件管理的有效领导力与量化方法.html.pdf（138页珍藏版）》请在三一文库上搜索。
1、对本书的赞誉 “大多数进步的组织都会采用先进的技术或者严密的流程，力求提高他们的整体效益。而往往被忽略的是那些开明的领导 者，他们能够激励并构建一个能够充分利用组织所引入的新技术和新流程的环境。某些流程和技术能够让优秀的团队更卓越，某 些流程和技术可以防止平庸者误入歧途。正是开明的领导者告诉我们哪些方法是必需的，然后构建起一个能最大限度提高团队绩 效的环境。本书也讨论了这些能力，并把它们有效地包含在评估组织生产率潜力的量化过程中。” 格里高利H.米克尔逊，美国雷神公司集成防御系统部 译者序 软件行业里，生产率度量历来都是非常困难的事情。首先，没有合适的度量指标来衡量软件的规模和研发的工作量。软
2、件行 业并不存在诸如“每小时生产一辆汽车”这样明确、令人信服而又普遍适用的软件生产率度量指标。人们最常用的源代码行指 标，由于种种弊端，饱受诟病。其他指标，比如用例、用户故事、对象点、特性点等，由于种种原因，适用领域非常有限。虽然 功能点方法可横向对比，但难以使用，仍未广泛普及。敏捷方法普遍使用最流行的用户故事，但由于用户故事基点定义的随意性 使得敏捷项目的基准度量变得几乎不可能。别说不同项目/团队的横向对比，就连同一个团队不同时期的纵向对比都非常不可 靠。 其次，即便存在历史数据，研发团队的人员变动之大，也使软件团队的能力始终处于变动之中。人是敏捷开发中的核心要 素，但也是最难以度量的因素。
3、无论是老员工离职还是新员工加入，都会让团队的效率在短时间内出现较大波动。人的性格、过 往经验以及对开发语言、环境、工具、流程、编程规范等的使用和理解千差万别。对于同一个开发任务，不同的开发人员、开发 组织使用不同的实践方法，所得出的软件规模、工作量、成本和进度估计也相差巨大。开发组织的能力同样难以直观地进行量化 度量和比较。 再者，软件研发是研发人员的脑力劳动，是智力活动的外在表现。软件行业的历史也就几十年，而软件行业的很多实践和方 法均来自建筑和工程行业。与建筑和工程行业相比，软件研发更注重人的智力活动。正如德鲁克所说的，IT行业是知识密集型行 业，IT从业者是知识工作者。以往工程实践的管理
4、方法并不完全适用于知识工作者。敏捷实践的兴起、自组织、跨职能团队的流 行、Y理论管理理念的大行其道，都说明管理理念的变革势在必行。软件规模、生产率和开发工作量度量，本质上都是对人的智 力活动和产物的度量。 正如作者在书中所分析的，几十年来，软件行业出现了各种各样的银弹，每种银弹都声称成倍提高生产率。而事实却并非如 此。兰达尔的研究与另一位行业领袖卡帕斯琼斯（Capers Jones）对软件开发生产率的研究结果基本一致，近几十年来，软件行 业并不存在能成倍提高软件生产率的银弹。 “如果你不能度量它，你就没法儿管理它。”尽管软件生产率度量和改进困难重重，但仍有很多人迎难而上，并做出了卓越 的贡献和
5、非凡的成就。兰达尔W.延森（Randall W.Jensen）就是这些“明知山有虎，偏向虎山行”的勇者之一。在本书中，基于过 去几十年的研究和实践，兰达尔详细阐述了一种有效度量软件开发者能力的概念性模型及其商业实现模型，仔细分析了影响软件 开发生产率的各种要素，研究了度量软件规模的有效指标，从管理和沟通的角度分析了人员和环境在软件项目中的重要性。作者 给出了一套度量软件开发组织能力、软件项目成本和进度估算、有效规模估算方面的可靠量化方法，并结合具体示例，给出了可 行的改进措施和建议。 无论是软件开发人员、项目经理，还是软件组织的CTO等管理人员，阅读本书都会给你带来很多具有启发性的想法。译者
6、阅读本书，对比自己曾经历过的团队、项目和工作环境，常常会有一种恍然大悟的感觉。在阅读、翻译及与作者讨论的过程中， 深切地感受到国外研究者在软件开发基础领域的扎实研究功底。他们从软件项目数据的收集、整理、分析和总结中去芜存菁、抽 丝剥茧地寻找软件开发的本质，透过重重迷雾，认真、详细地提取能够改善项目生产率的各种因素，逐步建立数学模型并为将来 的估算和规划提供量化指导。这种严谨的科学精神也值得中国的IT从业者和研究者学习。 兰达尔是国际知名的软件工程度量大师，是软件生产率度量领域的先行者之一。从20世纪50年代开始尝试提高生产率的各种 措施。通过在休斯飞机公司的工作，他开创性地建立了概念性有效性公
7、式，从管理、技术和沟通三个方面度量个体员工和组织的 有效性。而后又提出了Seer、SEER-SEM等模型，尝试量化软件项目涉及的方方面面，定量度量软件组织的能力、对生产率的影 响、项目成本及进度估算等。本书正是兰达尔工作、研究和咨询的结晶。 兰达尔是一位非常有耐心的长者。在翻译的过程中，译者每次遇到不明白或不太理解的地方，都会给Randy（兰达尔的昵 称）发邮件询问。Randy每次都很认真、细致地予以解释和澄清。有时候我们还会来回讨论具体的内容。本着真实传递作者核心 思想的原则，译者尽最大努力忠实于原书，尽全力准确翻译，对某些词句反复推敲和研读。另外，作者在书中所说的“能力计算 器”电子表格在
8、InformIT的网站上需要用英文书籍的ISDN注册后才能下载。译者向Randy索要了该工具，并获得授权可以分享给 需要的读者。如果需要该工具，也可给我发邮件。同时也可登录华章网站（）下载。 限于译者的知识水平、经验资历、英文理解和中文表达能力所限，再加翻译时间仓促，存在翻译错误在所难免。如果读者在 阅读的过程中对本书的内容有任何疑问，或者发现任何地方的翻译并不准确，或者对有关软件项目生产率度量和改进的话题感兴 趣，希望就这些话题进行讨论，均可发送电子邮件到。译者会仔细阅读每一封邮件并逐一回复。译者将整 理翻译方面的问题，并在重印版本中予以更正。敬请广大读者提供宝贵的反馈意见，以帮助译者进一步
9、提高今后译著的质量。 感谢郭茵熙、赵晓辉、侯景慧、孙挺挺、孔喜梅认真阅读了翻译稿并给出了大量中肯的改进建议。感谢陈佳媛编辑、吴怡编 辑的帮助和她们为本书所做的辛勤付出。 IBM中国开发中心全球化项目经理 吴舜贤 2015年6月于北京 作译者介绍 兰达尔W.延森（Randall W.Jensen） 1955年，当还是电气工程专业的一年级学生时，兰达尔W.延森就首次开展了生产率改进实验。在休斯飞机公司空间与通信 事业部工作时，他获得了博士学位，并想方设法提高生产率。同时，他被要求开发一个计算机模型来估算大型软件开发项目的成 本和进度。完成后的计算机模型提供了一个工具，软件开发管理人员可以用这个工
10、具来度量组织的能力，定量预测与人员、管理 方式和开发环境有关的管理决策对生产率的影响。他和查克托尼斯（Chuck Tonies）在1979年Prentice Hall出版社出版的软件 工程中发表了生产率的关键属性沟通、管理和技术。在这3个属性和本书中所阐述内容的基础上，兰达尔在生产率领域的 多年研究最终让他在1990年建立了一个改进的基于计算机的估算模型。 吴舜贤 IBM中国开发中心全球化项目经理，CSM、CSPO、PMP。2005年吉林大学计算机硕士毕业后在微软从事软件测试工作，参 与并带领团队测试了多款重量级软件，包括SQL Server 2008。2009年加入CA，参与和带领团队测试了
11、多款企业级IT管理软件。 2012年加入IBM软件全球化团队，从事IBM软件全球化、本地化等方面的工作，带领团队与全球30多个国家和地区的测试人员合 作完成多个软件国际化项目。目前专注于软件全球化、敏捷项目管理、软件质量与测试。软件工程译作2本。 序言 有些书只需浅尝，有些书可以狼吞，有些书则要细嚼慢咽，慢慢消化。 弗朗西斯培根 论读书 生产率（productivity）是对某种产出（output）与所需投入（input）的数量或质量的度量。在某种意义上，生产率就是效率 和（或）质量的度量。幸运的是，在过去的50多年里，软件行业持续地以每个人月所交付的源代码语句数量的方式度量软件开发 生产率。
12、这里所说的语句是实际交付的代码语句数，而不是开发期间所编写的语句数。源代码语句是以软件开发者所使用的编程 语言来描述的。在开发过程中，很多语句编写出来之后随即就被丢弃了。实际交付的语句可能包括多种语言，比如统一建模语言 （UML）和C+。以编程语言编写的语句，即使是1个UML语句也可能相当于40个C+语句。投入的工作就是产生单个代码语句 所需要的工作量。 我对生产率改进的兴趣最早始于1955年，那时我还是犹他州立大学（Utah State University）电气工程专业的一名学生。当时 要完成繁重的全日制四年本科课程，还从事着一份兼职工作，对校园政治也充满了兴趣，同时又在一个大学生联谊会担
13、任职务。 我自己的时间管理不足以应付这些繁忙的工作，所以我不得不想办法降低课后作业和实验室报告对我的影响（提升生产率）。显 然，我发现了一个既简单而又符合逻辑的办法来提高自己的效率。数年之后，我应用同样的办法，一边攻读电气工程博士学位， 一边全职教书，一边经营着一份咨询业务，还写了两本书。我可不认为自己有什么杰出的才智，也不是一名优秀出众的学生。我 只是在解决问题的时候，受到了“三个臭皮匠，赛过诸葛亮”这一理念的影响。它使我终生对组织管理充满了兴趣。 20世纪70年代中期，我开始认真研究管理技术及其在软件开发成本和进度方面的影响。早期的研究成果让我相信，软件开发 中的人力方面对软件生产率和质量
14、有着重大影响。我在软件开发团队上的第一次认真实验始于1975年，在生产率上取得了175% 的提高并减少了近3个数量级的错误。几个同事告诉我，1975年的实验是首次有记载的结对编程实践。 查克托尼斯（Chuck Tonies）和我在1979年出版的教科书Software Engineering1中写道，软件工程师对于组织的价值V依赖 于有效性公式的3个属性：沟通技能C、管理理念认知M和技术能力T，即： V=CM（T） 毫无疑问，有效性公式已经成为当今那些广为流行的敏捷开发方法的基础。它也是传统软件开发方法中质量和生产力改进的 基础。人、激励（motivation）和沟通是所有成功项目的关键因素。
15、 本书的第一个目的就是要探究那些推动高产环境的主要因素和理念，提供评估组织开发环境有效性的手段，揭示项目经理们 在其软件开发项目初期和执行期间所做出的决策对生产率的影响。 在过去的几十年里，很多技术变化都已成为业界的标准规范，而生产率的影响却远远超过了这些技术变化的影响，并且包括 了更多富有戏曲性的影响，它们都是有效性公式中管理和沟通属性的一部分。 我将探讨有效性数值评级的组成部分，以及能够在组织里提高这些评级并改善组织的生产率、有效性和估算能力的手段、方 法。同等重要的是，我会让你对开发流程及管理方式与环境的相互作用有一个更好的理解，以使你能极大地提高开发生产率。除 了使用环境参数来计算开发
16、成本和进度，这些度量指标还可以用来评估任何管理决策对环境的影响。 本书可以帮助回答关于项目环境的某些问题，比如“办公室隔间的使用耗费多少项目成本？”“选择从Ada变更为C+，改 变项目编程语言的成本是多少？”或者“依靠将我们的能力成熟度评级（CMMI）从3级提升为5级，生产率能提升多少？” 本书的第二个目的是，建立一个估算方法，用以在各种各样的项目和环境条件下，在经过训练的分析师手中，能够产生软件 开发进度与所需资源的现实可行的估计。 很明显，本书最有可能的读者就是软件开发人员。这里的软件开发人员包括所有的管理人员和对生产率提升感兴趣的专业人 士。这里所描述的理念，也可等效地应用于敏捷和传统软
17、件开发。沟通、团队协作和环境的运用成为结对编程（Pair Programming）的一部分，而结对编程正是敏捷开发的一个实例。 由于软件行业产生了超过50年的丰富文档资料和历史数据，软件开发成为解释生产率相关概念的最理想工具。 当我尽力编制将会从本书所展示的材料中获益的读者列表时，我回忆起了第一个受益人，一个苦苦挣扎尽力完成电气工程专 业大学学业，同时又要兼职工作的学生。本书中所讨论的所有关于沟通、团队协作和环境的概念都是能够使人梦想成真的原因之 一。基于这一点，我扩展了本书中各种想法的受益者名单，不仅包括软件经理、工程师和程序员，还包括任何需要人员介入并有 效、高效使用这些人员的行业（信息技
18、术、制造业、通信、教育等）的人员。20世纪初期著名的霍桑实验将这些想法应用于装备 制造业并取得成功。因此，这些想法真正具有普适性。 正如汤姆狄马克（Tom DeMarco）和蒂莫西李斯特（Timothy Lister）在他们所著的书人件2中所讲述的那样，软件 开发流程是以人为中心的，而不是自20世纪50年代就开始流行的传统的以技术为中心。尽管传统开发流程依然是当今一些大型组 织中使用的主要开发流程，但本书提供了一个路线图，定量地支持软件组织从传统向现代软件开发方式与环境转变。如果要实现 生产率和质量的大幅提高，全面质量管理（Total Quality Management，TQM）理念，包括软
19、件开发团队和Y理论（Theory Y）管理 的运用，都成为应该考虑的显而易见的管理技术。然而，这种转变并不全是牛奶和蜂蜜。任何过程转变都会付出短期代价，无论 是最新、最先进的计算机辅助软件工程（Computer-Aided Software Engineering，CASE）工具、新的开发语言、CMMI，还是开发 团队方法。 我在软件成本与进度估算领域的工作始于1978年支持一个大型空基软件系统的投标。我的任务是为休斯飞机公司的空间与通 信事业部（我的雇主）开发一套仿真模型，仿真结果将用作他们软件开发估算的基准。我建立了一个数学模型，通过使用包括开 发人员能力和项目实施约束在内的环境参数，生成
20、准确逼真的估算结果。从远自20世纪60年代3开始以来的多个数据来源累积的 完整的软件开发项目数据帮我创建了这个数学模型和本书中使用的组织能力计算器。令人惊讶，甚至是令人害怕的是，这个在 1980年制定出来的数学模型仍然能够应用于当今的软件开发方法且产生准确的工作量与进度估算结果。 本书的大部分篇幅都会探究这样一个简单概念及其对软件开发生产力的重要性。简单地讲，开发环境的生产率及其导致的软 件开发成本与进度，取决于3个重要属性的驱动：沟通、管理和技术。尽管本书聚焦于软件，但书中的原则也可不加修改地应用 于其他领域。 本书主要由两部分组成：有效领导力和定量方法。 有效领导力 本书前7章重点关注有效
21、领导力和组织能力度量。 第1章，软件开发问题。该章讨论“软件危机”和自20世纪60年代以来持续用来解决软件危机问题的技术方法。尽管人们 在软件工具、语言和开发方法上已经取得了巨大进步，但从1970年到现在，软件生产率的提高却非常缓慢。 第2章，有效性公式。该章讨论有效性公式的3个属性（沟通、管理和技术）在生产力改进中的重要性。同时也会讨论有 效沟通的机理及一些阻碍软件开发有效提升的重要文化问题。 第3章，软件管理的重要性。该章探讨有效开发中的两个人事管理原则霍桑效应（Hawthorne Effect）和X理论/Y理论 管理原则。这些原则也是现代人事管理的基础原则。该章还会举例探讨敏捷软件开发与
22、这些原则的相互关系。 第4章，从历史中我们学到了什么。该章讲述我们从有关软件开发生产率、技术对生产率的贡献、CMMI对生产率的影响 及乐观的开发预算和进度所产生后果等历史经验、教训中学到了什么。 第5章，软件开发团队。在该章中，我们会探讨一下软件开发团队。好的团队、差的团队、丑陋的团队以及他们对软件生 产率的影响都会有所讨论。 第6章，组织能力度量。该章介绍软件开发生产率度量的一个流程，该流程可应用到你的软件开发组织以揭示组织的内在 能力、恒定不变的基础技术以及组织在行业中的相对位置。该章还包括一个用于支持上述评估的工具。 第7章，完美软件公司案例研究。该章将介绍能力评估的一个研究案例，总结本
23、书前7章的所有内容。 定量软件开发管理 本书剩余部分将会讨论定量管理在成本和进度约束条件下的软件产品交付中的应用。 第8章，产品复杂度。该章分析软件系统复杂度在软件开发成本与进度约束方面的影响。 第9章，人员配置问题。该章介绍软件开发中最佳开发人员配置的一个评估方法。最佳人员配置是产品复杂度的函数，与 软件开发方法无关。 第10章，Seer软件模型介绍。该章介绍用于软件开发定量管理的Jensen软件模型，该模型也是SEER-SEM和Sage估算工具 的基础模型。 第11章，开发环境。该章将讨论软件开发环境对产品成本和开发进度的影响。环境评估包含与经验、不稳定性和其他管 理约束有关的考虑因素。
24、第12章，产品特性。该章详细论述产品特性和需求等约束条件在生产率和软件开发环境方面的影响。 第13章，开发进度与成本估算。该章通过介绍完美软件公司研究案例讲述软件开发成本与进度的估算流程。这些估算受 组织能力及环境等施加约束条件的限制。 第14章，有效规模估算。有效规模并不是新写或修改的软件源代码行数的简单估计。该章探讨了预测开发成本与进度估 算所需要的有效规模。 第15章，功能点规模估算。该章介绍传统软件产品开发中的功能点规模估算方法。作为基于对象软件开发方法规模估算 的一种替代方法，该章还讨论对象点的使用。 第16章，维护估算。维护估算可不是简单的软件增强估计。作为软件产品支持的重要补充，
25、软件维护方面知识留存的影 响在该章也会有所讨论。 第17章，总结。该章回顾本书前16章中所介绍的信息，并将这些概念应用到非软件开发环境中。 附录A，软件估算模型。该附录讨论定量软件评估模型的演化历史以及每一种主要估算方法的估算能力。 附录B，参考读物。该附录包含一个广泛的补充读物列表，涵盖有效领导力（沟通、人力管理方法和问题以及技术）、定 量管理和估算等主题。 附录C，名词术语。该附录列举本书中所使用的名词术语的一般定义。 获取能力计算器。全书用来支持组织能力计算及软件工作量和进度估算的能力计算器（Capability Calculator）电子表格可 从华章网站（）上免费下载。 致谢 我要感
26、谢为本书的写作提供帮助的人。首先感谢休斯飞机公司空间与通信事业部（SCG）的查克托尼斯（Chuck Tonies） 和肯哈伯德（Ken Hubbard）的贡献，他们支持我开发出Jensen模型，鼓励我展开试验，这些试验已成为本书所讨论的管理理念 的实践基础。感谢我的项目经理弗兰克沃尔夫（Frank Wolfe）对我在软件估算研究方面的积极支持，以及空间与通信事业部的 执行经理丹福斯特（Don Forster）授权我负责估算技术，鼓励我将Jensen模型商业化并开展软件估算咨询工作。在我研究Jensen 模型并开展估算咨询的冒险之旅中，常年和我一起工作的另一位关键人物是苏珊娜卢卡斯（Suzann
27、e Lucas）。 4位来自希尔空军基地（Hill AFB）美国空军软件技术支持中心（USAF STSC）的工程师：莱斯杜派克斯（Les Dupaix）、 马克伍尔西（Mark Woolsey）、汤姆罗杰斯（Thom Rogers）和布伦特巴克斯特（Brent Baxter），他们是我在软件技术支持 中心工作时软件估算团队的成员和贡献者，也是所有估算、培训和技术推广方面有价值的协作者。 最后，感谢我的妻子玛吉（Marge），感谢她多年来对我本书写作生涯的所有支持。为完成本书，我们只花了25年的时间。 兰达尔W.延森（Randall W.Jensen） 1 Jensen, R.W., and C
28、. Tonies, Software Engineering, Englewood Cliffs, NJ: Prentice Hall, 1979. 2 DeMarco，T., and T. Lister, Peopleware（ New York, NY: Dorset House, 1987）。（中文版人件（原书第3 版）已由机械工业 出版社于2014 年9 月出版发行。译者注） 3 Wolverton, R.W.,“ The Cost of Developing Large-Scale Software.” IEEE Transactions on Computers, June 197
29、4. 第1章 软件开发问题 “当我使用一个词时，”小胖墩儿Humpty Dumpty用一种很轻蔑的腔调说，“它只意味着我选择它要意味的那个意思不 多，也不少。” 刘易斯卡罗尔 爱丽丝镜中奇遇记 开篇第1章是绪论，将重点介绍自大约20世纪60年代至今软件行业里一直普遍存在的某些软件问题。不管是因为从未宣扬过 而被忽略，抑或是因为我们不愿让它们蒙蔽我们的思想而有意忽视，历史就是历史。 当翻开本书，我希望跃入你脑海的第一个问题是，你能做些什么来提高你组织的软件开发效率。在过去的40多年里，你不 是第一个问这个问题的人。尽管人们已使用类似的方法进行了所有的尝试，但在实际生产率提升上仍然收效甚微。 自2
30、0世纪70年代起，从我的经理正式指派我负责寻找一种方式以提高我们组织的软件开发生产率时起，我就一直尽力研究 软件生产率问题。因为我是组织的新人，我没有受到任何约束而仅考虑与组织的标准和文化保持一致的潜在方案。这使得我能够 以局外人的身份观察在那个开发环境中所使用的常规开发方法和工具。 自那时起，我竭尽所能地研究生产率问题，在生产率改进方面较早地取得了一些成功，尽管大多数研究任务的成果都因为不 符合组织的文化而被组织丢弃了。 我也犯过很多你在阅读本书之前可能已经犯过的同样的错误。带着每一种新技术都会对开发生产率有显著而积极影响的期 望，我尝试了这些新技术方案中的大多数。第一批被尝试的技术之一是程
31、序员工作台（Programmers Workbench，PWB），它使软件代码的所有当前和以前版本易于访问、可复查和可测试，因而能够减少错误并极大地提高产品 质量。PWB产生了效果并解决了一些产品问题，但它并没有真正改进生产率。我们的组织采用PWB作为软件开发的一种标准配 置，希望它能在软件质量和生产率改进方面为财务投资带来显著而良好的回报。由于能够更加高效地处理源代码并快速修复错 误，产品质量和开发流程确实得到了改善。快速修正错误也使无需思考太多就可做出变更成为可能。但开发生产率只是略有提 高。 在我的研究生涯中，我曾参与过的很多开发工作还包括实时软件系统开发。我所学到的使用Hatley/P
32、irbhai实时系统功能规 格说明方法的技术对开发工作的质量提供了非常积极的贡献。然而，尽管最终设计要更好一些，但该方法也没有显著提高生产 率。 20世纪70年代中期，我开始收集数据以研究环境对软件开发成本和进度的影响。最初，环境只包括组织办公设施、工具和 流程。但随着时间流逝，我开始严肃地将组织管理和文化也囊括进来。随着数据数量和质量的提高，数据成了生产率改进领域重 点关注的成本与进度估算模型的基础。注意：尽管大多数出版物都关注于技术方面，而很多管理者也相信技术的推动作用，但在 软件开发环境诸要素中，技术所带来的生产率提升最小。 最终，我构建了一个模型，整本书里将使用这个模型来帮助解释开发环
33、境的各个要素以及作为管理人员所做的有关你的环境 的决策对生产率的影响。 1.1 软件危机 术语“软件危机”是指软件开发的现有方法中强调需要如何应对变化的一系列问题。该术语起源于20世纪60年代，大概是 1968年在北大西洋公约组织（NATO）的软件会议的一篇文章Software Engineering1中提出来的。在这次会议上，作为软件 开发的主要关注点，与会者提出了一系列软件问题，包括： 不可靠 交付延迟 修改成本过高 不可维护 执行水平不足 超出预算成本 顺便说一句，这一系列问题在当今软件开发行业的很多地方仍然存在。上述问题出现的概率，在很多组织中已经大大减少 了，但当我们审视这个列表中的
34、单个问题时，我们仍能观察到一个常见的线索缺乏现实可行的进度（交付延迟）。 那次会议上到处弥漫着的一个观念是，我们可以解决这些问题。由此，有人杜撰出了“软件工程”这个术语。软件工程必须 是解决这些问题的潜在方案，但我们不得不看看在这个词杜撰出来之后发生了什么。本次会议的一个重要会议成果是软件工程大 学课程。然而，制作出来的这个课程恰好与当时的计算机科学课程一模一样。将学科名称从“计算机科学”更改为“软件工 程”所取得的进步微乎其微。 危机是个色彩很强烈的词。它暗含需要一个解决方案的某种形势。代表那种危机的状况将会发生改变，要么转向有利的方 面，或者转向某种潜在灾难。根据韦氏词典的定义，危机是“一
35、个关键性的或决定性的时刻或局面”。心脏病发作就是一个 危机，我们要么活下来，要么死去。到目前为止，那个危机应当以一种或多种方式被解决了。回顾过去，术语危 急2（exigence）比危机更适合那种情形，因为没有变好或变坏的明显可辨别的时刻。皮疹就是件急迫的事情。 稍微深入研究一下上面的问题列表，我们会发现，能够感觉到的这些软件开发问题的解决方案就是技术。根据图1-1中来自 2013年度Standish CHAOS报告3（Standish Chaos Manifesto）的结果可知，技术并不是项目成功的全部解决方案。 图1-1 CHAOS 2012软件项目调查结果 这份CHAOS报告把软件项目分为
36、3类：成功的、有问题的和失败的。在2004年的研究中，所有被评估的项目中仅有大约 29%的项目被归类为成功。53%的项目交付了，但成本严重超支、进度严重延误，同时平均只交付了原始需求64%的功能（有问 题的）。进度延误平均大约为84%，成本超支平均为56%。剩余18%的项目在交付之前就被取消了（失败）。 2012年评估的项目中大约39%是成功的。43%交付了，但有平均将近59%的项目严重成本超支，平均74%的项目存在严重 进度延误，同时仅交付了原始需求的69%（有问题的）。同样，18%的项目在交付之前即被取消（失败）。 从该报告可以观察到，在过去的10年里，由于包括采用更优秀的进度与成本估算方
37、法、流程、技术和团队效益等开发环境 的转变，成功完成的软件项目比例提高了10%。大多数项目都有问题，但大多数情况下这些都是与文化有关的人的问题而非技术 问题。 图1-2中显示的第二个研究结果包括了大量重大航空航天（地面和空间）软件项目4，它说明了软件规模和开发时间之间的 关系。很明显，这些历史数据说明了三件事情。第一，在完成并交付的那些软件项目中，可见的最大规模达到了200000源代码 行。 图1-2 1996年航空航天软件项目完成情况研究 第二，对于软件系统组件开发，还存在一个可见的最长开发周期。但关于这个需要超过4年才能完成的软件项目的详细数据 非常少。 第三，这个报告暗含了与开发生产率有
38、关的两个重要信息。如果开发项目持续时间超过5年，它就变得过时而不再有用处。 当软件项目规模超过200000源代码行时，开发团队需要的人员数量将压垮生产该产品的团队能力。 生产率与软件估算工具之间有着紧密的联系。上一个开发项目所实现的实际生产率非常接近于将用于确定下一个项目的成本 和进度的预估生产率。此外，估算工具所使用的参数也是能够或者应该用于确定软件开发生产率改进的管理措施的指标。自软件 项目历史数据记录存在之始，软件开发生产率的标准度量指标就是交付的软件源代码行数，而与开发语言、每人月（Person Month，PM）工作量等无关。 对软件估算工具开发者有所帮助的一种情况是，估算工具使用的
39、“交付的源代码行”这个指标与软件产品规模的度量指标是 一致的。这不是一个完美的度量指标，因为它没有精确地考虑返工等情形，但自20世纪60年代以来，软件行业就一直在使用 它。它还能清晰说明我们通常所观察到的生产率趋势。 今天我们广泛使用的软件估算工具是由20世纪70年代晚期到80年代早期开发的模型演变而来的，开发那些模型使用了当时 可用的历史项目数据。今天广泛使用的估算工具包括COCOMO II5、Price-S6、Sage7以及SEER-SEM。需要重点指出的 是，这些成熟工具在今天与30年前首次开发出它们时一样有用。说来也奇怪，20世纪80年代初为Seer8和COCOMO9开发的 输入数据参
40、数集（分析师和程序员能力、应用领域经验、现代实践方法与工具使用，等等），用于描述组织状况，在今天仍然准 确和适用。组织参数定义变化很小，而这些参数的数值也变化不大。幸运的是，对于软件估算工具的开发者来说，传统软件开发 文化的变化非常缓慢。敏捷软件开发引入了重大的开发文化转变，已经产生了高效开发的新思想方法。 在过去的40多年里，开发技术的几项突破性进展显著地降低了软件产品的开发成本。例如，由于实现给定的相同产品功能 所需要的源代码行数量大大降低，FORTRAN和COBOL的使用使得开发成本降低到了使用汇编语言开发所需成本的三分之一。 因为需要的源代码行数不断减少，从C+到新的可视化编程语言的变
41、迁以及面向对象结构的出现极大地节约了软件开发成本。 然而如图1-3所示，当我们研究任何给定的编程语言（新的和旧的）里生成单行代码所需要的工作量时，我们看到，虽然略有波 动，传统软件开发生产率（以从开发开始到交付或软件系统集成来度量）几乎每年以少于每人月2行源代码（SLOC/PM）的速 率线性增长。 图1-3 1960到1990期间的传统软件开发生产率提升 这段时间里，我们学到了关于软件开发的一些新事物。在20世纪60年代和70年代早期，开发环境中的所有焦点几乎完全在 产品上。一旦需求建立起来，主要活动就是编程，或者应该说是编码。程序员就仅仅是程序员。随着软件需求的增加和任务复杂 度的提高，软件
42、开发技术，也就是编程语言随之改进。软件开发平台也得以改进以适应软件系统规模的不断增长。 我遇到的第一个大型软件系统是一个实时机载武器系统，它具有大约100000行汇编语言源代码。该系统的开发开始于20世 纪60年代早期，几乎3年之后才最终交付。该系统既包括雷达软件也包含武器软件。在今天看来，除了某些约束条件现在没有 外，这个系统的规模并不令人记忆深刻。首先，该系统实现单一组件所需的穿孔卡片达到了50箱之多。软件开发流程和标准根 本不存在。而起始于结构化编程的现代软件方法在数年之后才出现。也没有工具来管理源代码及其他开发和测试产品。文档是用 老式打字机手打出来的。开发团队大概有35名工程师，其中
43、20位是程序员。大部分工作是在实验室环境里与硬件工程师一起执 行的。该项目的生产率达到了略高于每人月70行源代码（SLOC/PM）。 10年以后，与20世纪60年代的实时软件系统相比，20世纪70年代的软件系统呈现出了完全不同的特征。开发和目标计算机 都变得更大，也更快。程序员已变成了软件工程师。主流的第三代编程语言有FORTRAN、COBOL、PL/I、PASCAL以及C语 言。尽管DEC公司的程序员工作台（PWB）仅包含了实验性的开发环境，键控穿孔机已变成了数字文件。开发标准尚处于初级 阶段，但其必要性已经显而易见。结构化编程是重要的新开发策略。项目管理正成为开发中一个重要的因素。 如果使
44、用可用的第三代编程语言来实现上述20世纪60年代的机载武器系统的话，其规模将缩减至33000源代码行，使用25 个人力就能提早一年交付该产品。由于规模缩减，导致了交付周期的缩短和开发成本的降低。 编程语言已被归类为那些持续改变以使产品有效规模保持在可控水平的技术分支之一。从第一代汇编编程语言到第三代语 言，程序规模减少到了原来的1/3。诸如Visual C和Visual Basic之类的基于对象语言能够进一步减小软件规模，具有构建大规模 对象的能力。与C+语言相比，当前能够自动生成C+代码（自动代码产生器）的通用建模语言（Universal Modeling Language，UML）和状态图
45、的使用，实现了近40倍的规模提升。但我们仍然只基于项目手写源代码量来度量软件生产率。 从1960年到1990年的这段时间是软件开发技术急剧改进的历史时期。阿尔文托夫勒（Alvin Toffler）在他的书Future shock10中将这一现象描述为需求变更快速加速的一种时间压缩（time compression）。技术变化反哺自己，使得变化更加频 繁。敏捷软件开发就代表了开发文化的重大转变。 文化转型不仅仅只发生在开发文化上，还发生在那些构成开发文化的人员身上（程序员、设计师等）。在Future shock这 本书出版的那个时代，如果不继续学习，大学工科毕业生在学校所学的技能，毕业5年之后才
46、会过时。而目前软件世界的这个时 间少于2年。新的大学毕业生处于所有问题都要在一两个小时内解决的环境中。新的工具和编程语言使一夜之间创建出一个网站 或手机应用成为可能。软件开发正迈向艺术设计，而不再是软件工程。这种转变也给大规模系统开发者带来了文化问题。 编写一行源代码所需要的工作几乎与一行源代码的计算能力无关。用键盘编写软件指令并不是真正的开发工作。真正的开发 工作是理解用户需求、制定和测试设计方案、纠正错误逻辑、协调相同任务上其他同事的工作以及编制文档。莫里斯威尔克斯 （Maurice Wilkes），1967年图灵奖获得者，曾指出过一个重要的相关评论11： 一开始编程，我们就会惊讶地发现，
47、让程序正确运行并没有我们想象得那么容易。你不得不进行很多调试。我还清楚地记得 当我意识到我生活的很大一部分从此将花费在寻找我自己程序中的错误的那一刻。 软件的规模和复杂度让使用流程来管理软件开发工作变得非常必要。需求分析、软件设计、编码、测试和集成这样早期的瀑 布流程已成为软件开发的标准流程。 如图1-3所示，技术改进沿着图中直线进行。每一种新技术变革都提供了新的并且通常更好的解决方法来处理软件开发流程 的复杂性。诸如由玻姆12提出的软件螺旋模型和吉尔伯13提出的演化（evolutionary）交付模型等开发流程方面的新方法为管 理需求的复杂性和波动性提供了很多方案。随着新技术的出现，传统软件
48、开发生产率也有所提高，但提高的幅度只有大约每年每 人月1.5个交付源代码行（SLOC/PM）。 1 Naur, P., and Brian Randell, Software Engineering: Report on a Conference sponsored by the NATO Science Committee. Garmish, Germany, October 711, 1968. 2 Exigence (or exigency)：危急、紧急或者紧迫的情况；迫切需求；紧迫的事；紧迫的必要性。 3 Standish 国际集团，CHAOS 报告（West Yarmouth, MA
49、: Standish Group International, 2013）。 4 Long, L.G., and R.H. Lucas, “ Cost Estimating Relationships for Software Development, ”Aerospace Report No.TOR-96(8504)-3 (El Segundo, CA: Aerospace Corporation, May 22,1996). 5 Boehm, B.W., A. Egyed, B. Clark, E. Horowitz, C.Westland, R. Madachy, and R. Selby,“ Cost Models for Future Software Life Cycle Processes: COCOMO 2.0.” Annals of Software Engineering