"软件工程"是指我们在学校中学习的那些理论，经过多年的开发实践和技术交流中，我们不断在对传统的软件工程理论进行反思。

问题的提出

在将软件开发分为3个阶段（需求分析、设计和编程）时，我们很自然地会提出一个问题，"软件开发者应该继续提高专业化程度吗？"毕竟，劳动的分工是工业革命的基础。正是由于将制造业分解成多个精确定义的小任务，一组工人的生产率才能得到突飞猛进。所以，我们想当然地认为：对于软件开发，这种"专业化"的方式也将同样有效。

这看起来显而易见，不是吗？让一些人成为专业的分析师，专门获取和记录用户的需求；让一些人成为设计师，负责从需求文档制造出设计规格文档；程序员则负责根据设计规格进行编码。很显然，这应该是一种更加高效的工作方式，不是吗？答案是否定的。

问题的分析

1. 忽略了沟通的成本

同一件任务被切分而成的小步骤越多，人与人之间传递信息所耗费的时间总量就越多。因此，在不需要大量交流工作中（例如制造业中的很多体力劳动）中，流水式生产线能够运转得很好；但在需要大量交流的脑力劳动（尤其是软件开发）中，这种方式一败涂地。

软件开发的绝大部分工作都是在团队成员的头脑中完成的。如果要强迫每个人专门从事某一项特定的工作，那么任何一个简单的项目都会需要传递更多额外的中间产品。每一次的传递都可能带来潜在的错误和缺陷，因此，每次传递都是相当昂贵的。没错，如果要求每个人都编写大量的文档，以降低其他人作出错误理解或假设的风险，我们当然可以将"由于交流而出错"的可能性降到最低。但是，"编写更多文档"的工作量同样也是计算在项目的开销中的。正如Fred Brooks所指出的，如果决定某项任务成败的因素是项目组成员之间的交流效率，那么加入更多的人就只会延缓项目的进展。

当同一个开发者对需求、设计和源代码都有着深入的理解时，软件开发就能够获得最好的效果。Steven Levy所采访的所有黑客都是独自进行设计和编码的。在对"影响了（个人）计算机产业的19个程序员"的采访中，Susan Lammers也提到了同样的现象。在这些伟大的程序员中，没有任何一个使用过软件工程风格的分工方式，他们通常都是独自深入整个设计和编码工作。很有趣的是，他们几乎每个人都有自己独特的工作风格。

2. 导致混乱

将传统的劳动分工强加于软件开发，结果是导致分析师、设计师、程序员、测试员、用户界面专家、文档工程师、技术支持工程师之间不断地传递信息。过多的交流极大地降低了效率，项目被不断拖延。任何一点变化出现时，都必须将信息沿整条开发链传递下去，并导致一片混乱。项目结束后不久，软件就变成了"遗留系统"，因为没人清楚它究竟时如何工作的。

软件工程对技术进行人为的细分，结果导致任何一个人都不可能了解整个应用程序。软件工程解决这个问题的办法不是再开发者之间进行交叉培训，让他们了解全局，而是不断强调文档的神话－良好的文档能让任何人理解整个应用程序。不幸的是，尽管文档能够很好地记录软件中的抉择和协议，但却无法有效地保留、传递关于具体问题的详细信息，而这些具体细微的知识才是最重要的。

软件工程的另一个贻害是：它把文档搞得声名狼藉。很多项目实际上根本没有任何文档，因为年轻的开发者们本能地拒斥这种"软件工程的产物"。

3. 缺乏科学量化的手段

"科学管理"用科学取代了经验法则。在"科学管理"的方法中，数字支配一切。如果要改进什么东西，你首先必须对它进行度量。如果什么东西不能被度量，就不可能对它进行改进。管理者知道一切。任何工作都必然有一条最佳途径。

所以，看到软件工程师发明了许许多多软件开发的度量方法，我们也就不会觉得太惊奇了。甚至，由"科学管理"带来的"时间－动作研究"（time-and-motion study）已经被用于研究软件的使用情况了。在某些特定的问题上，人们已经规定出一些定量法则，例如将光标移动到按钮上需要多长时间（Fitts 法则）、在概率相当的行为之间作出选择需要多长时间（Hick法则）等等。

在对量化管理的狂热之中，人们常常忽视了机械活动与智力活动之间的差异。Fitts法则主要时针对机械活动的－尽管移动鼠标、点击按钮的动作需要眼睛和手的协调，但它仍然只是一个（比较复杂的）机械活动。Hick法则则试图度量人大脑中的活动。这正是软件工程犯下的一个经典错误：它认为能够度量的东西时最重要的，但情况并非如此。

从根本上来说，软件开发还是一项智力活动。打字的速度从来不是、也永远不可能是软件开发的瓶颈。要谈论一项智力活动，唯一的方式就是通过不精确的讨论，因为你能度量的东西对于提升效率根本无济于事。软件工程之所以有害，因为它忽视了开发者之间讨论的价值－而那是我们理解软件开发、提高开发效率的唯一途径。

软件工厂总是表现出一种倾向：它们试图模仿制造业从前的模式。但是，就连制造业也在不断发展。现在，哪怕是最热衷于生产线的人也早已不再谈论"完全集成的制造业"了。如今，汽车企业不再拥有钢铁工厂、煤矿和橡胶种植园。他们不再自己制造轮胎，而是向擅长制造轮胎的企业购买轮胎。对于软件组件，道理也是一样：借助于唾手可得的组件，小型团队也可以开发出优秀的软件。

"软件工厂"的概念没有真正流行，因为软件的制造实在太容易了。如何与用户协作、交流，创建一个良好的设计，并使其不断演进发展，这才是软件业中真正的难题。

忠告

如果你的项目拥有实际上无限的资源，那么软件工程就是一条有效的软件开发途径。但是，如果你的资源有限，如果你养不起数百名软件工程师，请及时放弃软件工程。你必须认识到：软件开发更多地是一项智力的、社会性的工作，而非机械性的工作。认识到这一点之后，你将可以从软件工程中学到有用的东西。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号