《软件管理沉思录》试读：第一章：交付高质量的产品

1.1　软件质量的挑战 软件质量改进的需求是巨大的，并且这种改进已经不能单纯地靠延续过去那种基于测试的方法来实现。 1.2　什么是软件质量 如果一件产品提供了对用户而言是最重要的功能，那么这就是一件高质量的产品。 1.3　缺陷并非“漏洞” 与漏洞相比，缺陷更像是定时炸弹。尽管不是所有的缺陷都会带来爆炸性影响，但是有一些缺陷的确会。 1.4　质量是永无终点的旅程 只要技术还在不断进步，并且这种进步能引起新的和不同类型用户的兴趣，我们就会面临新的质量需求。 1.5　以明确目标为起点 为了完成重要的工作，首先要精确地知道什么是你要努力去实现的。 1.1　软件质量的挑战 今天，我们生活所依赖的众多系统都是由软件支撑运转的。无论是乘飞机、纳税申报或携带心脏起搏器，我们的安全和健康都依赖于软件。每个系统都在增强，其规模和复杂性也在不断增加，与此同时，发生严重问题的可能性也在加大。视频游戏、座位预订系统或者记账程序中出现缺陷，给我们生活带来的可能只是不便，而飞机、汽车、空中交通管制系统、核电站、武器装备系统中的软件缺陷则会带来灾难性的后果。 我们每个人都离不开交通网络、医院、医疗器械、公共设施、国际金融基础设施，而这些系统都建立在复杂性不断增加、有潜在缺陷的软件系统之上。不管这些规模庞大、性命攸关的系统是新开发的还是对原有系统进行修改，为了确保安全性或可靠性，它们都必须满足每百万部件只能有极少数缺陷的质量要求。 现代的大规模系统通常都有大量的需求文档、庞大而复杂的设计以及数百万行的程序代码。设计和开发过程中的任何未修正错误，通常都会导致运行系统中出现缺陷。衡量这类操作系统的缺陷等级，一般用每千行代码出现的缺陷数。举例来说，对于一个有一百万行代码、质量等级为每千行代码出现一个缺陷的系统，它最多只能有1000个未发现的缺陷；而对于类似规模的安全系统而言，缺陷数量必须更少，一定不能超过10个。 在责备编程人员工作马虎之前，请先考虑一下其他类型的平面媒体对质量的要求吧。粗略浏览一下书籍、杂志或者报纸，你会发现一般每页至少有一处错误，甚至还会更多。然而，即使是质量低劣的软件，也绝不可能允许每页代码清单中都有一个缺陷。也就是说，即便是质量低劣的软件，其质量也要高于其他类型的人类书面文字。编程是一项严谨的工作，所有从事此项工作的专业人员都是在完成对质量要求极为苛刻的任务。唯一的问题是，根据历史发展趋势，未来的软件将远比今天的软件更大、更复杂，这就意味着即使保持目前的缺陷等级，我们在未来的工作也必须达到更高的质量要求。 为了能对每百万行代码只出现10个甚至更少缺陷的质量挑战有直观的认识，我们来看看此类规模的程序源码清单会是怎样的。大约每1000行代码就会占40页，那么一百万行代码就会是40 000页。很明显，40 000页中只找出10个缺陷的水平不是人力所能完成的。然而，我们目前复杂的性命攸关的系统就是这个规模的，而且在不远的将来可能会更庞大。 在软件开发过程中，为了保证质量始终如一，必须遵循以下8个步骤： (1) 确立质量控制的策略、目标和计划； (2) 正确训练、指导和支持开发人员及其团队； (3) 确立和维护软件需求的质量管理过程； (4) 确立和维护软件工程过程的统计控制； (5) 审查、检查并评估所有的产品制品； (6) 评估所有缺陷，加以更正并用以识别、纠正和预防其他类似问题； (7) 确立和维护配置管理和变更控制系统； (8) 持续改进开发过程。 我们面临着改进软件质量的巨大挑战，同时也面临着大量的、不断增长的质量要求。几乎每一位从事软件工作的人都应当很清楚地认识到，目前这种基于测试的质量策略已经走到了尽头。各种软件开发组织经过多年的努力，通过尝试不同的测试策略和方法、试验改进测试工具以及更勤奋地工作，仅使软件质量提高了大约10%~20%。 软件质量改进的需求是巨大的，并且这种改进已经不能单纯地靠延续过去那种基于测试的方法来实现。尽管上文所提出的8步措施并没有在软件开发中得到完全证实，但是越来越多的证据表明它们的确有效—— 至少要比我们现行的方法好。而且，这种质量策略利用的是各种基于数据的、可以指导长期质量改进的方法。除了提高质量之外，已证明这种策略还可以帮助我们节约时间和金钱。 最后，同时也是非常重要的，软件质量应当是我们每个人都关心的问题。今天，劣质软件只是浪费了我们的时间和金钱，而在不远的将来，则很有可能危及我们的生活和生计。我们每个人，无论是开发人员、管理者还是最终用户，都应当重视质量工作，这也是得到所有人都需要的优质软件的唯一方法。 1.2　什么是软件质量 软件质量对开发成本、发布日期和用户满意度都有影响。软件质量是如此重要，因此我们需要首先讨论质量（quality）究竟是指什么。软件产品的质量应当被定义为产品对用户的有用性。因此，如果一件产品提供了对用户而言是最重要的功能，那么这就是一件高质量的产品。用户的需求通常以需求文档的形式表述。由于需求实在是太重要了，因而需求的构想、阐述、提炼本身就是重要的课题。 必须要记住，只有得到了清晰的需求，才可能开发出高质量的程序。倘若你一开始时的需求尚不明确，你只有首先理解清楚需求，才有可能完成任务。 个人软件过程（PSP）提供了一些理解其中缺陷所需的技能和实践，这将帮助你有效地发现和修正绝大部分缺陷。它还提供了数据支持，以避免这些缺陷再出现。最后，一旦你能够有效地管理缺陷，就可以在其他影响程序实用性和价值的质量问题上投入更多精力。 软件工程师的工作就是在计划成本和计划进度内交付高质量的产品。软件产品必须满足用户的功能需求，同时也要能可靠、始终如一地完成用户的工作。能完成用户的工作是关键。尽管对于程序的使用者来说软件功能非常重要，但是只有在软件能够运行时，这些功能才可以使用。所以为了能让软件良好地运行，必须消除其中的缺陷。因此，虽然软件质量包括很多方面，但是首先应当关注的质量问题就是软件的缺陷。当然，这并不意味着软件的缺陷是你唯一需要重视的，甚至不能认为它们就是最重要的，而是说在你实现程序的其他任何目标之前，软件自身的大部分缺陷必须是你首先要解决的问题。即使软件能够运行了，如果其中仍然存在大量缺陷，那么不论其他方面质量有多好，该软件都不能用于大型系统当中，而且也没有人会去使用它。 缺陷之所以如此重要，是因为人类会犯很多错误。事实上，即使是经验丰富的程序员，通常每编写7到10行代码也会犯一次错。虽然大多数情况下他们会在编译和测试过程中发现并更正其中的绝大部分缺陷，但是仍然会有一些缺陷残留在了最终交付的产品中。因此很明显，你首先要做的是了解这类在开发过程中引入的缺陷，并且尽最大努力防止它们出现。要想做到这一点，你必须熟练运用所使用的编程语言，全面了解你的开发支持系统，并且精通将要开发的这类应用程序。这些步骤和其他一些措施对于减少引入的缺陷是十分必要的。 缺陷（defect）是指程序中的错误，例如语法错误、拼写错误、标点符号错误，也就是不正确的程序语句。缺陷在编程、设计，甚至在需求报告、技术说明书以及其他文档中都有可能出现。缺陷可能是重复的、多余的或者是不正确的语句，也可能是被漏掉的程序段。实际上，缺陷可以理解为削弱程序性能，使其不能有效并且完全地满足用户需求的所有因素。因此，缺陷是一种客观存在的事物，是可以识别、描述和统计的。 简单的代码错误可能会导致毁灭性的或是难以察觉的缺陷。相反，许多复杂的设计缺陷通常却能被轻易发现。因此，设计错误的复杂性与其导致的缺陷所产生的影响，在很大程度上是不相关的。即使是十分细微的实现错误也有可能导致严重的系统问题。事实上，绝大部分软件缺陷都可以归结为程序员的疏忽或失误。虽然设计问题总是很重要，但在第一次写成的程序中通常更多的是那些简单的疏忽、打字错误和明显错误，而较少有设计缺陷。由此可以看出，要想提高程序质量，软件工程师必须要学会管理他们在程序中引入的各种缺陷，这一点极为重要。 把发现或识别缺陷的问题与确定其原因的问题分开，是十分必要的。简单地统计和记录软件产品中出现的缺陷，并不需要具体说明原因或者进行指责。当然，凡是缺陷必有原因。可能是你拼错了一个参数名称、漏掉了一个标点符号，或者错误地调用了一段程序，所有这些错误都是导致缺陷的原因。事实上，所有的软件缺陷都来自人为的过失，而正是软件工程师的这些过失导致了程序缺陷。 过失（error）是指人做的不正确的事，不论是什么人在什么时间做的，而缺陷则是程序中的故障性因素。也就是说，人类犯下过失或错误，程序就会出现缺陷。当软件工程师犯了导致缺陷的过失时，我们把这称为引入缺陷。这就意味着为了减少产品中引入的缺陷数量，就必须改变你的行为习惯。而一般情况下，你只要能找出产品中的缺陷，就能消除它们。因此，消除缺陷实际上是一个比预防缺陷更简单的过程。预防缺陷是一个重大课题，要想深入了解它就需要全面研究整个软件开发过程。 除非软件工程师发现并纠正了引入的缺陷，这类缺陷才会在他们的最终产品中完全消除。但问题是，发现并改正软件中的这些缺陷通常需要花费很长的时间和大量的金钱。为了减少缺陷，你必须从过去曾经引入的缺陷中总结经验，分析导致这些缺陷的错误，并且努力在今后的工作中避免重复类似的错误。由于有缺陷的产品在测试时可能代价会很高，更正起来也很难，甚至有可能使用起来很危险，因此，学会最大限度减少遗留在产品中的缺陷数量是非常重要的。 对每一位软件工程师而言，缺陷都是应当高度关注的，不仅因为它们会影响软件产品的使用，而且一般软件公司超过一半的精力都用于发现和修复这些缺陷。由于用于测试的时间非常昂贵，并且很难事先预计，所以缺陷通常是导致项目成本和时间进度出现问题的最主要原因。 1.3　缺陷并非“漏洞” 有一些人错误地把软件缺陷当做漏洞（bug）。当我们提到bug（小虫）时，脑子里想到的是一些拍拍打打就能除去的、让人讨厌的小东西，有时甚至是可以被忽略的。这会让人们把一个危急的问题视为无足轻重，并助长了一种错误的对待态度。因此，当某位软件工程师说在程序中仅存在少数几个漏洞时，通常人们的反应是如释重负。然而设想一下，我们把它们称为定时炸弹而不是漏洞时会是什么情形？如果有一名程序员告诉你，他已经对程序进行了彻底的测试，其中仅有个别定时炸弹，你的心情还会是同样的宽慰吗？仅仅是换了一种表达方式就完全改变了你的态度。 与漏洞相比，缺陷更像是定时炸弹。尽管不是所有的缺陷都会带来爆炸性影响，但是有一些缺陷的确会。当软件程序得到了广泛的应用，特别是以一些设计者事先没有预想到的方式应用时，那些表面看起来十分细微的错误就可能会产生无法预知的后果。特别是对广泛应用的软件系统进行扩展以满足新的需求时，那些潜伏的问题就有可能暴露出来，一个看似微小的缺陷都有可能会引起灾难性的后果。 对于这一点，可能一些已经有一定编程经验的读者不太同意我的观点，认为我是夸大其辞了。在某种程度上，我的确有点夸张了，绝大多数小缺陷带来的后果都是微不足道的。然而不幸的是，有一些（虽然所占比例很小）看起来傻乎乎的错误，却可能产生非常严重的问题。我曾经见过一个非常简单的初始化错误使得缓冲区溢出，而正是这个小小的错误导致一个铁路控制系统数据丢失。因此，当发生电力中断时，该系统将无法快速重新启动，数千公里铁道线上的所有列车就只好全部停止运行数小时，直到重新得到所需数据。 还有一些缺陷带来的后果根本无法预测。如果能事先知道哪些缺陷属于此类，那么我们就能更正它们，并且也不用太担心其他缺陷。不幸的是，我们无法做到这一点，而任何被忽视的缺陷都有可能导致严重后果。尽管许多程序并不会被用于那类一旦失败后果就很严重的应用中，但是这类应用中的程序数目正在增加。因此，有些缺陷目前对你来说也许并不是一个非常重要的问题，但很快它们就会是了。如果从现在开始学习管理缺陷，那么就可以说你已经为开发高质量的程序作好了准备。 软件工程师是发现和更正自己所编写程序里的缺陷的最佳人选。因此，软件工程师为自己的程序质量承担个人责任是十分重要的。当然，学习编写无缺陷的程序是一个巨大的挑战。它并不是一件任何人都可以迅速和轻易完成的任务，它需要数据、有效的技术和娴熟的技巧作为支撑。然而，如果不去努力开发无缺陷的产品，那么你将永远也不可能达到这样的要求。 1.4　质量是永无终点的旅程 人们常常把软件质量看做是最终的结果或终点。事实并非如此，这是一段永远都没有终点的旅程。在测评和管理质量时，你就会对此有更清楚的认识了。每一步质量改进都会为下一步质量改进提供所需的知识、经验以及数据。因此，应当聚焦于持续不断的质量改进，并且帮助你的项目团队成员真正相信并且遵循这些质量管理原则。由于每个人的需求都会有所不同，你必须要清醒地认识到项目团队中每一位开发人员在这段旅程中所处的阶段，并在此基础上帮助他们所有人更进一步。这段质量旅程中的阶段有以下几个： (1) 测试并更正。起初，几乎所有的软件开发团队都是把精力集中于让产品能够工作。开发人员的目标是尽一切可能让产品尽快进入测试环节，接下来就是测试、更正（之后还是测试、更正、测试、更正……），直到软件工作良好，足以交付给用户为止。在这一阶段，项目组成员所知道的提高质量的唯一方法就是在测试上花费更多的时间和金钱。在这一阶段，你要想方设法尽快让项目团队进入旅程的第2至第8阶段。 (2) 检查。接下来的阶段就是，开发者和管理者在测试之前就开始消除缺陷，这通常需要进行各类走查和检查。这一阶段最典型的挑战是如何让开发人员以正确的方式完成所有需要的检查。 (3) 局部测评。当检查程序成熟之后，一些团队开始着手进行测评，并且使用检查得到的数据一方面来改进检查过程，另一方面把检查聚焦在最具破坏性的产品缺陷上。这一阶段面临的挑战是如何得到足够的数据并利用这些数据改进产品。 (4) 质量到人。当开发人员参加检查后，他们对自己所犯的错误将会变得更加敏感，而且他们会提前审查自己的工作以尽可能地消除类似错误。一旦开发人员能这样做，他们的产品质量将会迅速地提高。 (5) 个人测评。要想提高个人工作质量，开发人员需要客观的数据，他们需要了解自己引入及消除的缺陷、产品的规模以及他们花费的时间。这一阶段面临的挑战是如何让他们收集这些数据并加以利用。当开发人员开始研究关于那些在检查、测试阶段以及最终用户都没有发现的缺陷的数据时，产品质量会再次得到迅速提高。 (6) 设计。一旦开发人员学会了管理他们的编码缺陷，他们就可以开始关注设计缺陷。这需要精确的、定义良好的设计规范和正确的设计确认方法。这一阶段面临的挑战是如何对所有大大小小的程序使用正确的设计方法，以及如何在所有的设计检查和个人设计审查中运用正确的设计确认方法。 (7) 缺陷预防。运用正确的设计和测评方法后，引入的缺陷数量将会大大降低，与之前相比大约会降低一半。但更进一步，有效的缺陷预防程序通过结构化的步骤确认过程问题，并在需要时对过程进行调整以消除更多的缺陷。这一阶段面临的挑战是如何引入缺陷预防程序，进而对其进行维护和拓展，从而覆盖产品的整个生命周期。 (8) 基于用户的测评。最终，质量评估过程应当是由基于用户的质量测评来驱动。这时面临的主要挑战是如何理解那些对用户来讲最重要的质量特征，并且使用一种对你以及对用户都有意义的方式来测评这些特征。 美铝公司的一位行政高管曾经邀请我参观了他们的一个铝平板制造工厂，他说这家工厂生产的是全世界质量最好的铝平板。在与现场的工程师交谈的过程中，我惊奇地发现他们的质量测评与铝平板的生产无关，而是测评用铝板制造的罐子。举个例子来说，铝材越厚，那么罐子的成本就越高。但是铝材越薄，铝平板中的缺陷就越可能导致代价高昂和耗费时间的“洞穿”现象，从而会中断整个生产。美铝公司是铝平板市场的领先者，这主要得益于他们的产品质量非常好，用他们公司生产的铝材可以把罐子做得更薄。 质量提高的旅程永远没有终点，这个例子就很能说明问题。只要技术还在不断进步，并且这种进步能引起新的和不同类型用户的兴趣，我们就会面临新的质量需求。以上8个阶段的质量旅程中反映出的最主要信息是必须要循序渐进。开发人员在第5阶段取得合理进展之前，他们不可能有足够的数据来支持进行第6、7、8阶段。因此，既然要用一种更长远的目光来看待软件质量，你就应该让你的团队把注意力集中到这段质量旅程中的下一步。 1.5　以明确目标为起点 目标提供了一个任务和焦点，帮助我们确定优先次序并忽略那些不重要的细节。为了完成重要的工作，首先要清晰地知道什么是你要努力去实现的。方向模糊，目标不明确，就是在浪费时间。 很多年前我在管理一个软件团队时，营销人员找到我，向我提出了一个紧迫的项目需求。他们要求对我们新近发布的一个产品做一项重大的改进，此前他们已经与软件工程师就需求问题争论了好几个星期。他们需要在当年的十一月拿出产品，但却始终无法达成一致。在听完双方陈述后，我认为关键问题在于他们缺乏紧迫感。因此，我告诉工程师和营销人员，要么在两周之内拿出计划，要么我就否决这个项目。由于两个小组都想完成此项工作，所以他们跳过了常规的营销和设计审查环节，并很快就工作计划达成一致。之后我为该项目拨款，开发人员也按计划展开了工作。 当接近十一月时，他们准备发布新产品了。项目组草拟了一份发版说明，送到营销人员那里进行审查。看完这个说明，营销人员马上意识到该产品并不是他们想要的东西。由于项目匆忙启动，软件工程师开发了一个他们认为是满足需求的产品，但实际上他们错误地理解了营销人员的需求，导致开发出的产品是一个错误的产品。所有的努力全部都白费了，产品也不得不被废弃。 这里的核心问题就是目标出现了失误。我一直认为是工程师和营销人员没有进行严肃认真的交流，所以不能达成一致，基于此我就想当然地给了他们一个时限。这两个小组迅速彼此妥协，形成了一个让项目能够得到资金的模糊陈述，而没有真正花费时间去理解对方的想法。由于我要求时间优先，这种关注带来了苦果。他们的确是按我给出的时间完成了工作，却开发了一个错误的产品。 目标之所以重要，主要是基于以下两条原因：它们提供了努力的焦点，而且建立了一种优先次序。如果没有一个清晰的、得到一致认可的目标，开发人员很难能高标准地完成工作。而如果有了一个明确的目标，你就知道了什么是要做的，同时还有了清晰的工作方向。 目标还设定了优先次序。目标是第一位的，任何其他事情都是次要的。一个适当的目标对整个工作十分有益，不过如果目标不恰当，它通常就会是问题之所在。在上面所举的例子里，我把关注点放在了两周时间这个目标上。我以为他们会生产出优质的产品，但是我没有强调同样重要的是生产一个切实可用的产品，所以最后项目失败了。 目标不明确是软件工程领域一个带有普遍性的问题。在我职业生涯的早期，那时我还是一名工程师，管理者经常要求我以看似不可能的进度交付产品。有一个问题是我当年应该要问的：“这是必须要完成的吗？”对此通常可能会有一个不耐烦的回复：“当然是了。”但是接着我应当继续问：“那么它可以有缺陷吗？如果可以，是多少？”尽管这样的问题会让管理者心中不快，但是至少会让我们开始就所有工作中隐性的质量目标进行讨论。 当有人告诉你想让你做什么的时候，一般情况下他们心中已经有了一个目标，但是可能没有想办法清晰地表达出来。或者更加普遍的是，他们凭直觉知道什么是他们想要的，但是不能明确地定义它们。对于你将要做的事，只有你自己才知道是不是已经有了一个清晰的目标。即使你的同伴和管理者认为目标已经十分清楚，只要你对它有任何疑问，那么一定要大声地提出来。 要坚持让你的问题得到解决。很多情况下你会发现，其他人遇到的问题和你的几乎完全一样，只是他们羞于开口询问罢了。通过向你的管理者请教，明白无误地了解他们想让你达到的目标是什么，只有这样你才能真正履行好自己的职责。如果他们不能做到这一点，那么在开始工作之前，把你对目标的理解整理出来，然后与他们核对。之后要确信你和他们达成了共识。 资料来源 1.1. CrossTalk，2008年6月，“The Software Quality Challenge”。这篇文章最早发表于2008年6月出版的美国国防部软件工程杂志CrossTalk。 1.2. Introduction to the Personal Software ProcessSM，第12章。 1.3. Introduction to the Personal Software ProcessSM，第12章。 1.4. TSPSM: Leading a Development Team，第11章。 1.5. Introduction to the Team Software ProcessSM，第16章。