爱华网
Mr. ChuckConnellPro. DavidParnasPro.SteveHomer
软件工程≠计算机科学
Software Engineering ≠ Computer Science
By Chuck Connell, June 04, 2009
作者介绍：Mr. ChuckConnell是一位软件架构师，项目团队负责人，也是一位资深程序员。他有着20年以上多种编程语言，多个开放平台和多套系统的工作经验。他写过一本关于程序设计和程序结构《美丽的软件》的书，他在波士顿大学教《软件工程》，《数据结构》。另外，Chuck过去的软件背景还有，他是IBM第一位Notes的开发经理，也是 Domino, Notes, Sametime, Traveler,Connections和 LotusLive特聘专家。Mr.Chuck Connell在波士顿大学获得硕士学位，并在Tufts大学获得博士学位。
文中提到人名一介绍：Pro. David Parnas被公认为是现代计算机科学技术和软件工程领域的先驱和奠基者之一。获得卡内基梅陇大学电气工程博士学位，获得加拿大专业工程许可证，他是第一位运用传统工程思想进行软件设计的。他在卡内基梅陇大学任教多年，他还在加拿大，德国，瑞士，比利时，爱尔兰等的多所大学任教。2010年10月，Pro.David Parnas来中国访问，与国内多所大学（其中包括电子信息工程学院，上海大学等）有来往。
文中提到人名二介绍：Pro.Steve.Homer是一位波士顿大学计算机科学系艺术与科学学院的教授，主任，信息系统可靠性和网络安全中心主任，计算科学中心的成员。他的研究兴趣是：理论计算机科学，特别是复杂性理论，量子计算，学习理论，并行概率算法。
Software engineering seems different, in afrustrating way, from other disciplines of computerscience 我发现，软件工程学科好像与计算机科学学科有些不同，这是一件令人沮丧的事情。
Chuck Connell is a software consultant. He canbe reached at www.chc-3.com.
A few years ago, I studied algorithms andcomplexity. The field is wonderfully clean, with each conceptclearly defined, and each result building on earlier proofs. Whenyou learn a fact in this area, you can take it to the bank, sincemathematics would have to be inconsistent to overturn what you justlearned. Even the imperfect results, such as approximation andprobabilistic algorithms, have rigorous analyses about theirimperfections. Other disciplines of computer science, such asnetwork topology and cryptography also enjoy similar satisfyingstatus. 几年前，我学习了算法和复杂性。令人惊奇的是这个领域出奇的思路清晰，每个概念都有明确的定义，每个结论都是建立在前人证明基础上的。当你理解了这个领域的每一个事实，你可以把它放到银行里，因为数学与其有不一致的地方，以推翻你刚才了解到的、学到的知识。即使是不完美的结果，如逼近和概率算法，对自己的不完美的算法有着严格的分析。计算机科学的其他学科，如网络拓扑和加密学，还可以享受类似的令人满意的状态。（实际上，不论是计算机科学学科，还是软件工程学科都是后发的，与传统数学还是有着一些（本质上）的区别的，但是它们也是在这基础上发展起来的。搞清楚其中的相互关系，还是可庆可贺，其乐融融的。译者注）
Now I work on software engineering, and this areais maddeningly slippery. No concept is precisely defined. Resultsare qualified with "usually" or "in general". Today's research may,or may not, help tomorrow's work. New approaches often overturnearlier methods, with the new approaches burning brightly for awhile and then falling out of fashion as their limitations emerge.We believed that structured programming was the answer. Then we putfaith in fourth-generation languages, then object-oriented methods,then extreme programming, and now maybe open source. 现在我的工作在软件工程领域，相对而言这个领域令人感到有点不靠谱。许多东西没有明确的概念界定。结果的描述都是“一般”或“大致”。今天的研究可能会或可能不会，有助于明天的工作。新的方法常常推翻旧的方法，当一种新方法闪亮登场的一瞬间觉得如何如何的时尚，然而过了不多久其局限性又出现了。我们坚信，结构化编程就是一个很好的案例。可是随后紧接着又出来了第四代语言，后来面向对象的编程方法，再后来又是极端编程，如今也许又是开源编程了。（编程是一个非常严谨的过程，来不得半点马虎，侥幸。但是指挥或管理这个的过程是一个拿摸不定的过程。首先至今为止还没有一个绝对的高级语言能够一劳永逸，它还在不断地发展着；其次，编程人员的严谨工作需要有人有意识的去调动他们的积极性，说重不行，说轻了也不行。孰轻孰重，很难拿捏，这也是软件开发过程中与传统工程最难拿捏的地方。---译者注）
But software engineering is where the rubber meetsthe road. Few people care whether P equals NP just for the beautyof the question. The computer field is about doing thingswith computers. This means writing software to solve humanproblems, and running that software on real machines. By theChurch-TuringThesis, all computer hardware is essentially equivalent. Sowhile new machine architectures are cool, the real limitingchallenge in computer science is the problem of creating software.We need software that can be put together in a reasonable amount oftime, for a reasonable cost, that works something like itsdesigners hoped for, and runs with few errors. 所以，软件工程就像橡胶粘合跑道。很少有人关心P是否等于NP是完美的问题。在这个领域，是用计算机来做的事情。这意味着编写软件并在真实的机器上运行软件来解决人类的问题。根据当年图灵断言，所有的计算机硬件是完全等价的。因此，尽管新的计算机体系结构中还是一成不变的，真正的限制在计算机科学的挑战是编制怎么样的软件。我们需要的软件，是设计者所期望做的，把在一个适当时间内，有一个合理的成本价，也可能在运行时出现一些错误的那个东西。（计算机程序之前，人类生活在一个经过数千年传承的传统思维的时间里，按部就班，不论封建奴隶社会，还是后来的工业化社会，而如今计算机技术的出现，要用那些看不见摸不着的二进制代码来工作，学习和生活，那是具有前所未有的挑战性的。人类正在挑战这种挑战。---译者注）
With this goal in mind, something has alwaysbothered me (and many other researchers): Why can't softwareengineering have more rigorous results, like the other parts ofcomputer science? To state the question another way, "How much ofsoftware design and construction can be made formal and provable?"The answer to that question lies in Figure 1. 有了这个共同的目标，一直困扰着我（和许多其他研究人员）是：软件工程为什么没有一套像计算机科学那样更严谨的的模式呢？为了解释这个问题的另一种方式，“有多少软件设计和开发是正规的和可以被证明的？”这个问题的答案在于如图1所示。
Usability可用性, Maintainability 可维护性, Requirement 可需求性, Safety安全性, portability 可携带性, Estimation可评估性, testability 可测试性,Modifiability 可修复性, Scalability可量测性, Team Process团队过程, ArchitectureStyles 架构风格, Design Patterns 设计模型.
这里有一条横线（学科分成上半部，下半部）
Computability 可计算性, Queuing Theory排队理论,Algorithms 算法规则, Formal specification形式规, language syntax/semantics语言语法/语义, Cryptography 密码学, Correctness proofs正确性证明, AutomaticProgramming 自动化编程, Network analysis 网络分析, Machine Learning机器学习,Compilers 编译原理, OS Paging Scheduling操作系统的页面调度, Complexity 复杂性.
Figure 1: The bright line in computer science
The topics above the line constitute softwareengineering. The areas of study below the line are the coresubjects of computer science. These latter topics have clear,formal results. For open questions in these fields, we expect thatnew results will also be formally stated. These topics build oneach other -- cryptography on complexity, and compilers onalgorithms, for example. Moreover, we believe that proven resultsin these fields will still be true 100 years from now. 红线上的主题是软件工程的组成结构。红线下的研究领域是计算机科学的核心科目。下面的那些主题是明确的，有正式结果的。对于这些领域里开放性的问题，我们期待新的结果也有正式规定。他们之间还彼此关联建立起来新的主题---例如，密码学的复杂性和编译器算法。此外，我们相信，这些领域要验证他们的真实性，从现在起仍需要100年后才能被证实。
So what is that bright line, and why are none ofthe software engineering topics below it? The line is the property"directly involves human activity". Software engineering has thisproperty, while traditional computer science does not. The resultsfrom disciplines below the line might be used by people, buttheir results are not directly affected by people.那么，什么是红线，为什么它的下面与软件工程的主题无关呢？因为该线是“直接涉及人类活动的”属性。软件工程有这个属性，而传统的计算机科学没有。线下来自学科的结果可能被人类所用，但它们的结果不会直接影响到人类。
Software engineering has an essential humancomponent. Software maintainability, for example, is the ability ofpeople to understand, find, and repair defects in a softwaresystem. The maintainability of software may be influenced by someformal notions of computer science -- perhaps the cyclomaticcomplexity of the software's control graph. But maintainabilitycrucially involves humans, and their ability to grasp the meaningand intention of source code. The question of whether a particularsoftware system is highly maintainable cannot be answered just bymechanically examining the software. 软件工程有人类必不可少的成分。例如，软件的可维护性，人类要有能力去理解，发现和修复软件系统的缺陷。软件的可维护性可能也会受到一些正规的计算机科学概念的影响---也许是该软件控制图的循环复杂度。但是，可维护性的关键涉及到人类，他们有把握源代码含义和目的的能力。问题是是否有这样一种特别的软件系统极具可维护性，只是通过机械性地检查没有什么软件它回答不了的问题。（至此看来，软件工程除了计算机科学技术以外，涉足更多的是人文科学范畴的内容，是人类根据软件系统在现实社会中使用的实际情况，如何来适度调整（或修改）系统使之更好地适应人类活动的需要。比如，微软的视窗操作系统，几乎每隔几年就会有一次升级，以不断满足人类不断高涨的使用需求（当然其中也有现实社会中商业竞争的因素在内。）；苹果智能手机的推出同样也是以另一种形式以满足人类日益高涨消费需求。就是这些二进制代码的出现改变了人类几千年来的的工作，学习和生活方式习惯。---译者注）
The same is true for safety. Researchers have usedsome formal methods to learn about a software system's impact onpeople's health and property. But no discussion of software safetyis complete without appeal to the human component of the systemunder examination. Likewise for requirements engineering. We candevise all sorts of interview techniques to elicit accuraterequirements from software stakeholders, and we can create varioussystems of notation to write down what we learn. But no amount ofresearch in this area will change the fact that requirementgathering often involves talking to or observing people. Sometimesthese people tell us the right information, and sometimes theydon't. Sometimes people lie, perhaps for good reasons. Sometimespeople are honestly trying to convey correct information but areunable to do so. 为安全起见也同样如此。研究人员使用了一些正规的方法来了解软件系统对人类健康和财产的影响。但软件安全完全没有讨论要求对人类组合系统置于监督之下。同样包括需求工程。我们（作为咨询顾问）通过与软件利益相关者的交流得到精确的任务需求，建立所有的需求分类，并创建不同的符号系统，写下咨询顾问对项目的理解。但是，这方面没有大量的研究可以改变这个事实，需求的收集往往涉及到与人谈话或人为观察。有时，这些人告诉我们正确的信息，而有时则不是。有时，人们撒谎，也许找个很好的理由。有时候人们诚实试图传达正确的信息，但是不知道该怎么说是正确的。（这就是软件存在的最大的问题。人们要把一个原来看得见摸得着东西或事情，用近似于天文数字一样的二进制符号加以描述（高级语言就是英语），当事人只是在现实环境中经历过这个过程，如今要在虚拟的环境中实现，原来在传统环境下的需求在虚拟环境下是不是可行，或要作修改，怎样的流程是最佳的，当事人不一定清楚，搞软件的人也不一定知道，这就需要既懂业务，又懂计算机的人参与，这种人就是所谓的咨询顾问。---译者注）
This observation leads to Connell's Thesis:这个观察来自康奈尔的论文：
Software engineering will never be a rigorousdiscipline with proven results, because it involves human activity.结果证明，软件工程从来不是一门缜密的学科，因为它涉及到人类活动。
This is an extra-mathematical statement, about thelimits of formal systems. I offer no proof for the statement, andno proof that there is no proof. But the fact remains that thecentral questions of software engineering are human concerns:这是一个额外的数学声明，关于正式系统的限制。我提供没有证据证明的声明，没有证据表明没有任何证据。但事实仍然是软件工程的核心问题是对人的关注：
All of these problems revolve around people.所有这些问题都是围绕着人展开的。
My thesis explains why software engineering is sohard and so slippery. Tried-and-true methods that work for one teamof programmers do not work for other teams. Exhaustive analysis ofpast programming projects may not produce a good estimation for thenext. Revolutionary software development tools each helpincrementally and then fail to live up to their grand promise. Thereason is that humans are squishy and frustrating andunpredictable. 我的论文诠释了软件工程为什么这么辛苦和具有可塑性。一种可靠的方法就是每个团队的编程人员相对独立，不混搭。过去编程项目的详尽分析，可能不会对下一个编程项目产生一个很好的评估。每次软件开发的革命有助于开发过程有一点点的优化递增，然后失败于他们的说得多做得少。究其原因是，人类是可塑性的和令人沮丧的不可预知性。
Before turning to the implications of my assertion,I address three likely objections:在改变我的主张的影响之前，我持三种可能反对的意见：
The thesis is self-fulfilling. If some area ofsoftware engineering is solved rigorously, you can just redefinesoftware engineering not to include thatproblem.本文是自我实现。如果一些软件工程领域的问题被缜密地解决了，那么你就可以重新定义软件工程，不包括这些问题了。
This objection is somewhat true, but of limitedscope. I am asserting that the range of disciplines commonlyreferred to as software engineering will substantially continue todefy rigorous solution. Narrow aspects of some of the problemsmight succumb to a formal approach, but I claim this success willbe just at the fringes of the central software engineering issues.这个反对意见有点真实，但范围有限。我敢断言，通常被称为软件工程学科的范围将大大地继续无视严谨的解决方案。从狭窄的一面来看问题可能会屈从于一个正规的做法，但我主张这个成就只是在软件工程中央问题的边缘。
Statistical results in software engineering alreadydisprove the thesis. 软件工程统计结果已经否定了我的论文的论断。
These methods generally address the estimationproblem and include Function Point Counting, COCOMO II, PROBE, and others. Despite their mathematicalappearance, these methods are not proofs or formal results. Thestatistics are an attempt to quantify subjective human experienceon past software projects, and then extrapolate from that data tofuture projects. This works sometimes. But the seemingly rigorousformulas in these schemes are, in effect, putting lipstick on apig, to use a contemporary idiom. For example, one of the formulasin COCOMO II is PersonMonths = 2.94 � SizeB,where B = 0.91 + 0.01 � Σ SFi, and SF is aset of five subjective scale factors such as "developmentflexibility" and "team cohesion". The formula looks rigorous, butis dominated by an exponent made up of human factors. 这些方法通常针对的是估计问题，包括功能点计数，COCOMOII（软件开发过程中的财务分析软件系统），PROBE（）以及其他问题。尽管他们都以数学形式出现，但是这些方法都需要被证明或要有正式结果。统计学企图通过现有的软件项目以量化人类的主观上的经验，然后从这些数据推断出未来的项目。时常有这种工作。但这些计划中看似存在许多严谨的公式，实际上，这就好比猪嘴上涂口红，做做样子而已。例如，一个COCOMOII中的公式是PersonMonths= 2.94 SizeB，B =0.91+0.01ΣSFI，SF是一家集诸如“发展灵活性”和“团队凝聚力”等五项主观等级的因素。其计算公式看起来很严谨，但主要还是由人为指数因素组成的。（在软件开发过程中，似乎有许多数学公式在监督着软件开发的过程，有一些符号公式，挺令人目眩的，但是更多的还是人为的因素在起作用。---译者注）
Formal software engineering processes, such ascleanroom engineering, are gradually finding rigorous, provablemethods for software development. They are raising the bright lineto subsume previously squishy software engineering topics.正规软件工程的过程，如洁净室工程，正逐渐找到严谨的，可证明的软件开发方法。他们正在唤起把红线归入先前可塑性的软件工程主题。（这段的意思不太确定。---译者注）
It is true that researchers of formal processes aremaking headway on various problems. But they are guilty of theconverse of the first objection: they define software developmentin such a narrow way that it becomes amenable to rigoroussolutions. Formalmethods simply gloss over any problem centered on humanbeings. For example, a key to formal software development methodsis the creation of a rigorous, unambiguous software specification.The specification is then used to drive (and prove) the laterphases of the development process. A formal method may indeedcontain an unambiguous semantic notation scheme. But no formalmethod contains an exact recipe for getting people to unambiguouslystate their vague notions of what software ought to do.在解决各种软件开发过程中的问题，研究人员采用正式流程正在取得进展是个事实。但使他们感到内疚的第一个反对的逆命题是：他们对软件开发是在这样一个狭窄的层面上，经得起检验的严谨的解决方案。以人类为中心的正规的方法可以诠释任何问题。例如，正规的软件开发方法的关键是如何建立了一整套严格的，明确的软件规范。然后，用这套规范驱动（证明）后期阶段的开发过程。一套正规的方法确实可能包含一个明确的语义符号体系。但没有一个正规的软件开发方法中会包含一个不确切的因素，让人们还软件应该做什么都搞不清楚。
To the contrary of these objections, it is my claimthat software engineering is essentially different fromtraditional, formal computer science. The former depends on peopleand the latter does not. This leads to Connell's Corollary:这些反对意见的反面，我可以断言，软件工程本质上是不同的传统的，正规的计算机科学。前者依赖于人，而后者则没有。从而导致了康奈尔的推论：
We should stop trying to prove fundamental resultsin software engineering and accept that the significant advances inthis domain will be general guidelines. 我们应该停止试图证明软件工程的基本结论，并接受在这个领域里有显著进展的一般准则。
As an example, David Parnas wrote a wonderful paperin 1972, On The Criteria To Be Used in Decomposing Systems intoModules. The paper describes a simple experiment Parnasperformed about alternative software design strategies, oneutilizing information hiding, and the other with global datavisibility. He then drew some conclusions and made recommendationsbased on this small experiment. Nothing in the paper is proven, andParnas does not claim that anyone following his recommendations isguaranteed to get similar results. But the paper contains wisecounsel and has been highly influential in the popularity ofobject-oriented language design. 作为一个例子，大卫·帕尔纳斯在1972年写了一篇精彩的论文中《用标准的方法把系统分解成模块》。文中介绍了一个简单的帕尔纳斯实验用来替代软件设计的策略，一是利用信息隐藏技术，二是利用全球数据可视化技术。然后，他基于这个小实验作出了一些结论，提出了一些建议。没有文章可以证明，帕尔纳斯是没有要求的，任何人都按照他的建议保证得到类似的结果。但文章中包含了许多真知灼见，一直在面向对象的语言设计的普及中极具影响力的。
Another example is the vast body of work known asCMMI from theSoftware Engineering Institute at Carnegie Mellon. CMMI began as asoftware process model and has now grown to encompass other kindsof projects as well. CMMI is about 1000 pages long -- not countingprimers, interpretations, and training materials -- and representsmore than 1000 person-years of work. It is used by many largeorganizations and has been credited with significant improvement intheir software process and products. But CMMI contains not a singleiron-clad proven result. It is really just a set of (highlydeveloped) suggestions for how to organize a software project,based on methods that have worked for other organizations on pastprojects. In fact, the SEI states that CMMI is not even a process,but rather a meta-process, with details to be filled in by eachorganization. 另一个例子是，卡耐基梅隆大学的软件工程研究所为CMMI的问世投入了大量人力物力和财力。CMMI以软件过程模型作为开始，现在已经发展涉及到包含其他类型的项目中去了。 CMMI约有1000页长的资料 –经过许多人工作许多年才加以完成的，解释和培训材料 –已经超过1000人/年的工作量。它适用于许多大型软件开发单位，并使得软件过程和产品质量得到显著的改善。但CMMI的内容不是单一的、铁板一块唯一的结果。它实际上只是一套如何组织一个软件项目（高端开发）的建议，来自根据过去其他团队曾经做过的，成功的项目的经验。事实上，SEI规定，CMMI不仅仅是一个简单的过程，更像一个元过程，不同的项目都有不同的精彩内容在其中。
Other areas of research in this spirit includedesign patterns, architectural styles, refactoring based on badsmells, agile development, and data visualization. In thesedisciplines, parts of the work may include proven results, but theoverall aims are systems that foundationally include a humancomponent. To be clear: Core computer science topics (below thebright line) are vital tools to any software engineer. A backgroundin algorithms is important when designing high-performanceapplication software. Queuing theory helps with the design ofoperating system kernels. Cleanroom engineering contains somemethods useful in some situations. Statistical history can behelpful when planning similar projects with a similar team ofpeople. But formalism is just a necessary, not sufficient,condition for good software engineering. To illustrate this point,consider the fields of structural engineering and physicalarchitecture (houses and buildings). 这种精神在其它研究领域，包括设计模式，架构风格，基于不靠谱的重构，敏捷开发，和数据可视化。在这些学科中，部分的工作可能包括经过证明的结果，但总体目标是一个基于人类组合的系统。要明确：对于任何软件工程师而言，核心计算机科学主题（红线下方）仍是非常重要的工具。设计高性能的应用软件时，具有算法背景还是很重要的。排队论有助于操作系统内核的设计。净化室工程包含了一些方法在某些情况下也是非常有用。当用同一组的人员开发相同的项目时，统计数字（其实就是开发软件时的文档等）还是很有用的。但是，形式主义还是一种必要的，不充分的，条件良好的软件工程。为了说明这一点，还要考虑结构工程和物理体系结构的领域（房屋及建筑）。
Imagine a brilliant structural engineer who is theworld's expert on building materials, stress and strain, loaddistributions, wind shear, earthquake forces, etc. Architects inevery country keep this person on their speed-dial for every designand construction project. Would this mythical structural engineernecessarily be good at designing the buildings he or she isanalyzing? Not at all. Our structural engineer might be lousy attalking to clients, unable to design spaces that people like toinhabit, dull at imagining solutions to new problems, and boringaesthetically. Structural engineering is useful to physicalarchitects, but is not enough for good design. Successfularchitecture includes creativity, vision, multi-disciplinarythinking, and humanity. 请设想一下，如果一名杰出的结构工程师，一位对建筑材料，应力和应变，载荷分布，风切变，地震力等方面了知识如指掌的世界级的专家。每一个国家都有这样的建筑师，这种人可以对每一个设计和建设项目起到一个承上启下的作用。这是一个神话般的结构工程师，在设计一栋建筑物时，由他或她会有一个客观的实事求是的分析或评价？不尽然。我们的结构工程师可能与客户有一个很糟糕的谈话，不能设计一个令人满意的居住的空间，呆谈论审美感了。结构工程物理建筑师是非常有用的，但如果没有良好的设计也是不行的。成功的架构师，包括创意，远见，多学科思维，和人文学科。（搞软件系统就像搞建筑一样，先要由架构师设计软件的架构，而且这个架构师应该是身经百战的，对各方面的软件系统都有熟悉。这类人才要具备多方面的思维和知识，特别是未来的人类将很大程度上工作、学习和生活在软件这个虚拟社会里，如何保持一个软件系统的可持续性至关重要，需要有这类人持续关注整个过程，对软件系统生命周期的管理浮出水面。---译者注）
In the same way, classical computer science ishelpful to software engineering, but will never be the whole story.Good software engineering also includes creativity, vision,multi-disciplinary thinking, and humanity. This observation freessoftware engineering researchers to spend time on what does succeed-- building up a body of collected wisdom for future practitioners.We should not try to make software engineering into an extension ofmathematically-based computer science. It won't work, and candistract us from useful advances waiting to be discovered.以同样的方式，经典的计算机科学是有助于软件工程，但这永远不是它的全部。良好的软件工程还包括创意，远见，多学科思维，和人文学科。这种观察可以让软件工程研究人员把时间花在什么是成功上-以建立了一个机构收集的未来从业者的智慧。我们不企图使软件工程沿着基于计算机科学方面的延伸。它对软件过程中业的发展没有好处，而且会分散我们正在从事的有利于软件工程发展的，等待我们去发现的注意力。
Acknowledgements
My thanks to Steve Homer for a discussion that sparked my interestin this question. 我要感谢史蒂夫·荷马为一次讨论的付出，他激发了我在这个问题上的兴趣。
