图书前言

前言

说起来容易,做起来难,总有一些事情如此。

——《IEEE 软件》

记得有一次,我们乘坐的飞机正在跑道上等待起飞,突然听到机长紧急播报:“飞机的空调系统有问题,无法向机舱正常供氧,我们需要在起飞之前确保空调系统能够恢复正常。我刚刚尝试了重启空调系统,但没有成功,现在必须重新启动整个飞机系统。众所周知,现代飞机由计算机控制,是不太靠谱的。”

飞机熄火,重新启动。随后,我们的航班顺利起飞了,没有发生任何异常。最后飞机落地,走出机舱的那一刻,我悬着的心终于放了下来。

这是一个最好的时代,也是一个最坏的时代。

优秀的软件组织能够有效控制项目,以达到既定的质量目标,并准确预测软件的交付时间,不论是年份还是月份。他们能在预算范围内完成软件项目,不断提升生产力,保持员工士气高涨,让客户非常满意。

● 一家电信公司需要修改大约3 000 行代码,而整个代码库大约有100 万行。他们需要小心翼翼地进行修改,确保至少一年内不会出现任何错误。他们总共花费了9 个小时来完成所有工作,包括需求、分析、设计、实现和测试。

● 一个为美国空军开发软件的团队承诺只需要1年时间和200万美元预算就能完成项目,而另一个知名团队对这个项目的报价却高达2 年和1 000 万美元。当低价中标的项目团队提前一个月交付项目时,项目经理透露了一个关键信息:团队的成功主要得益于使用了一种已存在多年但并不常用的技术。

● 一家航天公司采取固定价格合同策略为其他企业开发商业软件,结果表明,只有3% 的项目超出预算,97% 的项目都成功控制在预算之内。

● 一家致力于实现卓越品质的软件公司连续9 年每年平均产品缺陷率降低39%,累计减少99% 的缺陷率。

除了这些成功案例外,软件行业在经济上每年仍为全球带来超过10 亿美元的额外收入,无论是通过软件销售直接获得,还是间接通过提高效率和创造与软件相关的产品与服务实现。

创建良好软件所需的实践已经确立了,并且可以在今后的10 年至20 年或更长时间里使用。虽然某些项目取得了卓越成就,但软件行业整体未能充分挖掘出软件的全部潜力。平均项目水平与顶尖项目水平之间存在巨大差距,许多领域的软件实践要么严重过时,要么不够高效。软件项目的平均表现远远达不到预期,看看下面这些知名的失败案例。

● 美国国税局(IRS)在其软件现代化项目上浪费80 亿美元,导致美国纳税人每年损失高达500 亿美元。

● 美国联邦航空管理局的高级自动化系统计划的预算超支30 亿美元。

● 行李处理系统的问题导致丹佛国际机场的开放时间推迟了一年多。据估计,延误造成的损失高达每天110 万美元。

● 阿丽亚娜5 号火箭因为1 个软件错误导致火箭在首次发射时爆炸。

● B-2轰炸机(译注:这样的战略轰炸机最大起飞重量接近170 吨,但只有0.1 平方米的雷达反射面积,大小相当于普通鸟类。B-2 在设计上使用了诸多先进的隐身技术手段,如锯齿边缘的机翼和尾翼、特殊涂料吸收雷达波等。在作战能力方面,B-2 也具备长时间独立作战能力,其最大载弹量达20 吨,不加油的情况下作战半径可达1.2 万千米。如果可以进行一次空中加油,其作战半径将大幅提升至1.8 万千米,差不多可以覆盖全球大部分区域。此外,B-2 还配备了当时最先进的电子设备,如相控阵雷达、综合电子战系统等,因而可以在复杂环境下有效地执行任务。B-2 参与过多场实战考验,均保持零损失的记录。)因软件问题而未能按时执行首飞。

● 西雅图渡轮的计算机系统故障导致了十几次的码头碰撞,造成的损失超过700 万美元。华盛顿州计划投资超过300 万美元,将渡轮的自动控制系统改回手动控制。

● 虽然很多项目没有发生重大失误,但仍然引发了诸多问题。大约25% 的软件项目彻底失败,12 而项目在被取消时一般已经多花了一倍的预算,约50% 的项目经历了延期、超预算或被迫缩减功能。

在企业层面,这些失败的项目意味着巨大的机会损失。想象一下,如果在只花费了10% 的预算而不是200% 的预算时就能够识别出那些最终会失败的项目并提前砍掉它们,让公司把这些资源重新分配给那些有潜力成功的项目上。

在国家层面,这些被叫停的项目意味着巨大的浪费。粗略估计,这样的软件项目给美国经济造成了400 亿美元的损失。

即使项目成功,仍然可能给公共安全或公共福利带来风险。莲花(Lotus)公司的项目负责人曾经接到一位外科医生的电话,说他当时正在进行心脏手术,需要使用电子表格来分析患者数据。《新闻周刊》发表过一张照片,显示战场上的士兵们使用Excel 来规划军事行动。微软公司的Excel 技术支持团队确实接到过士兵们从前线打来的电话。

本书的目的

软件开发应该是可预测、可控制、经济上可行且可以管理的。通常,软件开发通常不会以满足这四个要求为目标,但它有潜力同时满足这些要求。本书主要聚焦于软件工程这一新兴行业的发展,探讨如何建立高效且经济的专业软件开发实践。

本书讨论了以下几个主题:

● 什么是软件工程?

● 软件工程与计算机科学有何关系?

● 为什么传统的计算机编程不够好?

● 为什么我们需要软件工程这一职业?

● 为什么要为软件开发专业设计最佳模型?

● 不同的项目或公司在采纳成功策略上存在哪些差异与共性?

● 软件组织可以采取哪些措施来支持专业软件开发方法?

● 软件开发人员如何成长为成熟的专业人士?

● 软件行业应该如何建立真正意义上的软件工程职业发展路线?

本书的组织

本书将从当前计算机编程实践的现状出发,逐步过渡到探索未来可能出现的软件工程职业。

第Ⅰ部分“软件‘焦油坑’”将阐述软件领域是如何发展到现在这种状态的。显然,软件领域的现状受到多种因素的影响,我们需要充分理解这些因素,从而促进而不是阻碍软件项目的革新,让人们主动为项目的成功而努力。

第Ⅱ部分“个人专业化”将介绍个人层面上可以采取哪些行动来进一步提高个人的软件专业化水平。

由于软件项目的复杂性,许多关键因素无法仅通过个人努力有效解决。第Ⅲ部分“软件组织专业化”深入讨论了实现软件项目专业化的实践方法。

第Ⅳ部分“行业专业化”将探讨整个软件行业必须采取哪些措施来推动个人层面和组织层面的专业化进程。

自1999年以来,我学到了什么

我从1999 年以来获得了下面这些经验教训。

● 对软件开发人员实行许可证制度的提议引发的争议远超我的预期。我依然认为,对一小部分软件工程师进行认证,是保护公众安全和福祉的重要步骤。我曾经试图解释,许可证是改善软件开发专业水平所需要的许多举措之一,但它不是最重要的。

● 软件工程师的培训不必与许可证申请紧密关联。在本科和研究生的教育课程中,可以培养软件开发人员的工程思维,但不必强迫他们成为持证专业工程师。事实上,如果只有不到5% 的软件开发人员需要获得许可证,那么将大部分教学的焦点集中在许可证上似乎不太合适。

● 当2000 年1 月1 日来临时,世界并未陷入混乱。尽管我不曾认为千年虫(Y2K,即日期从两位数扩展到四位数,比如从99 变为1999)会引发灾难,但我确实认为,解决Y2K 问题的过程比这个问题本身更重要。软件行业采取的补救措施比我预期的更有效。除此之外,Y2K 问题在某种意义上是软件成功开发实践的结果。如果有这么多软件系统的生命周期都超过预期,那么Y2K 一开始就应该成为问题。

● 现代软件开发在许多方面所取得的成果令人印象深刻,在讨论软件领域的专业化时,我们不应忘记领域内的众多成功案例。

我们必须留意,在改善那些有缺陷的做法时,不应该一并舍弃那些已被证明有效的方法。

谁应该阅读这本书

如果你以开发软件为生,可以通过本书了解如何才能成为一名真正的专业软件开发人员。

如果你是软件项目的管理者,可以通过本书了解好项目和不成功的项目之间的区别,探讨如何才能成功完成项目。

如果你是软件企业的管理者,可以通过本书了解系统化的软件开发方法有哪些好处以及如何获得这些效益。

如果你是一名希望在软件领域工作的学生,可以通过本书了解软件工程领域的知识体系,以及软件工程领域的职业前景。

软件开发的专业化

行业研究人员通过长期以来的观察发现,在同一行业内,不同组织的生产效率有高达10 倍的差异。最近的研究甚至显示,这种差异可能高达惊人的600 倍。18 那些最高效的软件组织的确表现优异。

真正的软件工程专业化所带来的好处是不言而喻的。传统观点认为,任何变化都伴随着巨大的风险。然而,在软件领域,最大的风险实际上是保持不变,并继续固守不健康的高成本开发实践,而不是开始采用那些多年前就已被证明更加有效的实践方法。

应该如何改变呢?这正是本书剩余部分的核心主题。

编注:为了方便广大读者进一步查阅和拓展相关资源,我们对本书英文版中的所有原文注释进行了统一处理。大家可以扫描二维码,查看和下载全书的所有注释。