书名：设计原本:计算机科学巨匠Frederick P. Brooks的思考(《人月神话》作者布鲁克斯最新力作)(中英文版同步上市 )
原书名：The Design of Design: Essays from a Computer Scientist Frederick P. Brooks, Jr.
作者：Frederick P. Brooks, Jr.
译者：InfoQ中文站 王海鹏 高 博 译
定价：59.00元
上市时间：2011年1月
出版社：机械工业出版社华章公司

英文版 ：http://www.china-pub.com/197412

中文版 ：http://www.china-pub.com/197442

内容简介：

如果说《人月神话》是作者布鲁克斯刚刚完成若干个改变了全球计算系统格局的重大项目，在人生和事业的巅峰时期的激情之作，那么《设计原本:计算机科学巨匠Frederick P. Brooks的思考》则是作者功成名就之后，在研究和教学中将先前在设计领域中的探索心得和实践经验切磋琢磨、去伪存真、取其精华的反思之作。可以说，比起锐气有余的《人月神话》，《设计原本》更多了几分高屋建瓴的大局观以及数十年如一日积淀而成的丰富材料，是设计领域真正的大师之作。
本书几乎涵盖所有有关设计的议题：从设计哲学谈到设计实践，从设计过程到设计灵感，既强调了设计思想的重要性，又对沟通中的种种细节都做了细致入微的描述，并且谈到了因地制宜做出妥协的具体准则。其中，作者特别强调的是设计的概念完整性，这不仅对于设计过程中步骤流转时的信息传递十分关键，并且也是沟通中最需要重点注意的地方。
全书的案例研究是另一大亮点，在进行抽象的模型和思想论述时，作者时时注意运用图表和案例说话，深入浅出地表达复杂艰涩的思想。并通过层次丰富的案例，展示了设计既能治大国，又可烹小鲜的强大力量和无穷魅力。我们能够从作品的字里行间感受到计算机体系结构刚刚诞生的黄金年代充满了怎样的设计思想和工程实践的生机和活力。而作者也十分擅长专业史料的记载和整理，并且以他独有的方式为读者展示出极为清晰的脉络。

作者简介：
Frederick P. Brooks 北卡罗来纳大学计算机科学系的Kenan教授。他因领导开发IBM System/360计算机家族以及Operating System/360而荣获美国国家技术奖，并因对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献而获得A. M.图灵奖。他是畅销书《人月神话》的作者。

译者简介：
高博，2004年毕业于上海交通大学计算机系，在微软公司和惠普公司有多年项目和管理经验。对程序设计语言、云计算、软件测试方法学、软件架构设计和软件项目管理方向有浓厚兴趣。近年来翻译出版了《C++：99个常见编程错误》、《微软的软件测试之道》、《源码中国：全球IT外包新原点》等多本书籍。联系方式：feedback@gaobo.org，订阅博客：feed.gaobo.org 。
王海鹏，1994年毕业于华东师范大学。拥有双学士学位。咨询顾问、培训讲师、译者和软件开发者。已翻译20本软件开发书籍，主题涵盖敏捷方法学、需求工程、UML建模和测试。拥有15年软件开发经验，目前主要研究领域是软件架构和方法学，致力于提高软件开发的品质和效率。
张龙，同济大学软件工程硕士，InfoQ中文站Java社区编辑，满江红开放技术研究组织成员。热衷于编程，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。目前对Mac、iPhone/iPad、Android开发、动态语言及算法具有浓厚兴趣。翻译出版了《Dojo构建Ajax应用程序》、《Spring高级程序设计》等书籍。拥有5年的Java EE培训讲师经验。联系方式：zhanglong217@yahoo.com.cn，博客地址：http://blog.csdn.net/ricohzhanglong ，新浪微博：http://t.sina.com.cn/fengzhongye ，欢迎follow。
黄璜，2007年毕业于重庆邮电大学。曾在某外包公司工作3年，目前在一家初创公司做开发工作。担任InfoQ中文站社区编辑两年，对于业界新动向和新技术有强烈的兴趣。目前专注于网站架构、分布式以及算法。联系方式：alexhuang1984@gmail.com。

很少有人像Frederick P. Brooks, Jr. 一样对软件开发的实践（而不是学术理论）产生那么大的影响。他在《人月神话》中记录了他作为IBM System/360计算机以及Operating System/360项目领导者的经验，这些经验不断地促使我们形成项目管理的观念。很难找到比他的“没有银弹：软件工程中的根本问题和次要问题”一文被引用更多的文章。“银弹”的概念代表了对困难的软件和编程问题的某种近乎神奇的解决方案，这是我们的词汇表中不可缺少的一个词。
Brooks的这本新书拓展了他以前的思想，添加了对设计的本质和重要性的新领悟。毫无疑问，这本书将会成为所有专业开发者书架上必备的书籍。
《设计原本》的副书名是“计算机科学巨匠Frederick P. Brooks的思考”。书中包含了可以作为独立的文章进行阅读的20章，每一章与其他章的耦合都比较松散。这是好事，因为大多数读者都希望阅读本书的每一章（不一定要按顺序），然后在继续下一章阅读之前思考一下所讲的内容。除了这些文章外，这本书还提供了8个案例，涉及的范围从海滩小屋的设计到IBM System/360的架构。这些案例阐释了本书中的一些重要概念。
什么是设计？Dorothy Sayers（英国作家和戏剧家，Brooks引用了他的话）说设计有3个阶段：概念构造的形成，在真实媒质上的实现，与真正用户的交互。Brooks在他的“银弹”一文中指出，第一个阶段（即概念构造）是软件工程最困难的阶段。但在1986年时，“概念构造”似乎更侧重计算机在执行指令时内部发生了什么。在这本新书中，关注的重点更多地转移到架构、外观，以及程序工件与环境的交互上。有趣的是，Brooks在第1章的开始引用了培根的话：

这清晰地表达了跨学科的灵感和锻炼。Brooks没有深入这个概念，即使在后面的内容中讨论如何“创造”了不起的设计师时，他也没这样做。
有几章讨论了设计和设计过程的模型。Brooks在这里严厉批评了流行的“理性主义者”设计模型（读者可能最熟悉的就是“瀑布方法”），并断言“理性模型过于简单”。书中指出了理性模型的诸多缺陷，包括“对理性模型的最具破坏性的批评可能是，最有经验的设计完全不是这样工作的”。（在本书中提到David Parnas多次，但没有提到他的著名文章“The Rational Design Process: How and why to fake it”，这篇文章也对理性模型提出了严厉批评。）本书对其他一些设计模型也进行了讨论，包括：

• 迭代演进式开发，与此最接近的是Brooks对敏捷方法的讨论。
• Boehm的螺旋模型。
• 开源的、Raymond的“集市模型”。

这些讨论的结论是：设计需要某种过程以及该过程的模型（主要是为了沟通并支持协作），Barry Boehm的螺旋模型是Brooks认为最有希望的模型。
本书中的其他章节关注了以下几个问题：

• 协作与团队设计，包括远程协作所引发的问题。
• 关于“理性主义”与“经验主义”的讨论，Brooks自认是一个经验主义者。
• 约束条件的价值。其中印证了许多“设计”文献，这些文献来自工业、产品和图形设计师。设计草案（用于启动设计过程的文档）必须足够模糊，允许自由思考和表达，但必须清楚定义所有的约束条件。约束条件勾画出边界，创造性的、有想像力的、创新的设计将在这个边界之内发生。
• 讨论美与风格。
• 一些关于设计技术和实践的讨论，Brooks发现它们是有价值的。
• 需求、罪过与合约。
• 一个案例，讲述了为什么任务控制语言（Job Control Language, JCL，如果你没有在大主机上工作的愉快经历的话）可能是“有史以来最糟糕的编程语言”！

本书末尾用两章的篇幅讨论卓越的设计和卓越的设计师的问题。Brooks果断指出，卓越的设计来自卓越的设计师，而非卓越的设计过程。Brooks说，我们教育和培训软件专业人员的方式无助于培养出卓越的设计师。他指出，培养卓越的设计师的一个主要障碍就是缺少持续的实践和批评。

InfoQ有机会对Brooks提出了一些跟进问题，本文包括了这次访谈的内容。问题与回答如下：

开发项目有一个生命周期，要么是经典的线性瀑布式，要么是迭代增量式（敏捷）。设计是在生命周期特定阶段发生的事情，还是分布在所有阶段？
它集中发生在迭代开发的前面几次循环，但有时候发生在所有迭代中。

如果设计发生在所有的开发阶段中，是否在每个阶段中具有不同的形式、实质或要点？
当然是这样的！在第一次迭代中，总体架构是中心问题。在接下来的迭代中，设计工作集中于更精细的层面，除非是在满足最后期限之后的回溯，或者人们意识到需求的改变或新的机会。

约束条件在设计过程中扮演什么角色？（本问题的背景知识：其他领域的设计师常常依赖一份“草案”，他们预期/需要草案中有模糊之处，以便能够自由地“设计”，但他们需要清楚表达约束条件，这些约束条件定义了目标区域，最优设计只能在这个区域中产生。）
它们既促成了整体架构，又在较小程度上促成了细节设计。

是否有明显可以确定的设计“错误”，它们是否能在犯下时就可以意识到？（或者，这样的错误是否像代码中的缺陷，通常需要在犯下之后许久才发现？）
大错是在开始时犯下的，而且很少意识到。如果最终被发现，通常是在现场实施之后。较小的错误是在编码开始时出现，或者是在第一个真正的用户测试原型时被发现。

大多数设计师认为他们的活动是高度协作的，至少是客户与设计师之间的协作，但设计更多时候涉及一个团队。您是否同意设计是一种协作？如果是这样，设计团队的地理分布或临时分布会带来什么影响？（显然，在今天的离岸外包环境中寻求并行设计，以应对软件开发的一般挑战。）
我用了两章讨论协作和远程协作。是的，今天大多数的设计都涉及团队。通用产品的设计不涉及与客户的协作，如iPad。对于为一个客户设计定制的产品，我非常喜欢对原型和代用品（如建筑的虚拟环境模型）尽早地、激烈地、频繁地、不断地进行用户测试。但是，我不认为这是与用户和客户进行协作设计。

您是否有一份清单，例如6点建议，可以总结您的书向设计者提供的最重要的经验？
1）专心研究以前设计者的工作，看看他们如何解决问题。
2）尝试弄明白他们为什么做出那样的设计决定，这是对你自己最有启发性的问题。
3）仔细研究以前设计者的风格。最好的方式是尝试用他们的一些风格勾画设计草图。
4）保存一本“草图本”，将您的想法、设计和局部设计记录下来，不论使用何种媒质。
5）在开始设计时，写下您对用户和使用方式的假定。
6）设计、设计、设计！

在您的“银弹”文章中，您谈到了“概念构建”和人类在头脑中完成这项工作时遇到的巨大困难。您觉得在这本书中一些思想是否关注并解决了概念构造这一基本困难？
肯定关注了，肯定没解决。

在第3章中，您漂亮地批评了理性设计过程，特别是瀑布式方法所包含的理性设计思想，并指出这种思想是有害的，必须抛弃。您对这种有害模型的持续存在有何看法？是否人们就是很倔强？或者尽管开发者更了解，但管理层会犯错？是否有一些文化上的偏见（尤其是西方文化上的偏见）阻碍人们抛弃瀑布模型？
第4章讨论了软件工程中的瀑布模型的持续存在（在其他学科中并不常见）是因为设计者过早期望得到有约束力的合同和确定的需求。

在第20章中，您批评了我们的教育系统（温和，但确是事实），并建议设计者需要参与“批评性实践”。Richard Gabriel长期以来一直主张计算机科学/软件工程大纲应该采用他在取得诗歌硕士学位时一样的大纲（他在很久之前获得了计算机科学博士学位）：大量的练习（每天至少一首诗）、大量的批评（来自同学和导师）、勤奋学习大师和大师的诗歌、不断自省、周期性的反省。这似乎与您的建议相似，那么您是否主张大学提供一个“软件好艺术硕士”学位？
不。熊恩在《the Education of the Reflective Practitioner》一书中提出了同样的建议，还有例子，更适合设计。所有的工程学大纲都应该强调这种方式。

哪些其他领域的研究将有助于毕业生变成卓越的软件设计师？
1）算法和数据结构是最重要的基础课程。
2）计算机硬件架构。
3）应用领域，特别是商业数据处理、数据库技术和数据挖掘。
4）心理学，特别是知觉心理学，因为用户是最重要的。

理性设计过程，实际上是所有计算机科学和软件工程，有意识地采用了宇宙的基本模型（20世纪的物理学），即确定性的、机械的、理性的宇宙。如果那就是自然或现实，那么理性的、搜索树式的设计过程模型就很有意义。如果宇宙实际上是复杂的适应性系统，那么理性模型就会失效。您是否走得更远，奠定了复杂系统的设计或修改过程的基础，如文化或商务企业？
我不会自大到建议这样的东西。

IDEO是一家非常有名的设计公司，它的总裁Tom Kelly写了一些关于设计、设计过程和设计思考的书。他最好的一本书是《Ten Faces of Innovation》，其中他确定了每个设计团队需要的10个角色（人类学家、实验员、嫁接能手、跨栏运动员、合作者、指导者、用户体验设计师、布景师、专业护理人员和讲故事的人）。如果您知道这本书，是否类似的角色应该出现在软件设计团队中？怎样做到？
我不了解这本书。听起来有趣，而且有用。

您提到了Christopher Alexander和他的影响并在注释中提到了《The Synthesis of Form and A Pattern Language》一书。那代表了“理性的Alexander”，但“Timeless Way of Building”和他的杰作“Opus, Nature of Order”却更为“神秘化”。“神秘的Alexander”是否对您的设计和设计过程思想有所影响？
我受到了《The Timeless Way of Building》一书的影响。

软件领域的设计将大多数注意力放在人工制品上，即执行程序的计算机。越来越多的实践（但学术界还没开始）开始关注“用户体验设计”，即计算机所处的系统和生态环境。对于用户体验设计者如何从本书中获益，您是否有一些建议？
我觉得前面给出的建议同样适用于用户体验设计，但这个领域与软件工程领域相比，自由式教育更为重要。

您能列举出值得所有人学习的3名设计大师（任何领域）和3名软件设计大师，4至5个设计杰作，并简单说明为什么吗？

• 巴赫，作曲家
• 伦勃朗，画家
• Seymour Cray，超级计算机设计师
• Christopher Wren，建筑，特别是他在伦敦设计的教堂
• Nicholas Wirth，计算机语言
• Donald Knuth，算法

我不认为所有的人都应该学习同样的例子。人们需要接受范例的设计原则方面的基本教育，这样才能深入研究一个范例，欣赏这些设计问题和解决方案。但是，即使是门外汉也能欣赏一致性和设计概念的统一性。

原文网址：http://www.infoq.com/articles/brooks-design-book-review

    大师之作不仅仅是指一部出自大师笔下的著作，更是特指大师的心血凝结之作。Frederick P. Brooks, Jr.，美国“两院”院士、A.M. 图灵奖和IEEE先驱奖获得者、软件工程界至今脍炙人口的奠基之作《人月神话》的作者，这位令人高山仰止的大师，在创作了《人月神话》35年之后，才在2010年初推出了本书。如果说《人月神话》是Brooks刚刚完成若干个改变了全球计算系统格局的重大项目，在人生和事业的巅峰时期的激情之作，那么《设计原本:计算机科学巨匠Frederick P. Brooks的思考》则是Brooks功成名就之后，在研究和教学中将先前在设计领域中的探索心得和实践经验切磋琢磨、去伪存真、取其精华的反思之作。可以说，比起锐气有余的《人月神话》，本书更多了几分高屋建瓴的大局观以及数十年如一日积淀而成的丰富材料，是设计领域真正的大师之作。
    《设计原本:计算机科学巨匠Frederick P. Brooks的思考》几乎涵盖了所有有关设计的议题：从设计哲学到设计实践，从设计过程到设计灵感，既强调了设计思想的重要性（第8章），又对沟通中的种种细节做了细致入微的描述（第6、7章），并且也谈到了因地制宜做出妥协的具体准则（第9、10、11章）。其中，Brooks特别强调的是设计的概念完整性（第6章），这不仅对于设计过程中步骤流转时的信息传递十分关键，并且也是沟通中最需要重点注意的地方。使用同一个术语表达不同的概念，或使用不同的术语表达同一个概念，都会给设计带来剧增的成本，甚至灾难性的后果。这一点是贯穿始终的主线之一。另一条主线就是Brooks对于理性模型的批判（第2、3、5章）。由于在现行的软件工程著作和研究论文中，对理性模型导致的直接模型—瀑布模型的推崇可谓甚嚣尘上。Brooks在此处着了重墨，深入分析了理性模型的工程师心理学渊源，解释了它何以根深蒂固，然后剖析了它的实质—以拓展设计树的方式来暴力遍历问题的解空间，最后对它的种种不足提出了针对性的批评，并指出在哪些受限的条件下方可运用理性模型（瀑布模型），而在其他场合中有哪些更好的设计模型，尤其是Boehm提出的螺旋模型。这些对于设计模型的长篇论述，特别是对其背后的工程思想的深入分析，无疑将对设计界的研究者和实践者起到方向性的指导意义。
    全书的案例研究是另一大亮点，这不仅包括专门的案例章节（第21～27章），而且在进行抽象的模型和思想论述时，Brooks也时时注意运用图表和案例说话，深入浅出地表达复杂艰涩的思想。并通过层次丰富的案例，展示了设计既能治大国，又可烹小鲜的强大力量和无穷魅力。比如，为了论述抵制需求蠕变的必要性时，他首先以和美国军方要员的一段对话切入话题（第4章），给读者以直观且深刻的印象。这不仅表明了即使在军事领域，设计的准则和影响仍然适用，也不经意间揭示了作者和美国国防部—全世界最尖端的科研和工程的研发和实践基地—的深入合作关系。Brooks以揶揄的方式对待这些大企业的高管们的案例并非仅此一隅，在讲述僵死、拙劣的规格如何造成最终产品的可笑妥协时，他又举一例，美国联邦航空局的一个令人匪夷所思的系统规格造成了在最终产品中不得不以禁用一个完整系统的部分功能的方式“凑合”成一个虽然符合规格却造成不小浪费的系统，而这些最终都是由纳税人买单（第11章）。要知道，这些都是动辄涉及上百亿美元的大项目，Brooks在其中的谈笑风生绝对是一种举重若轻的大将风度。可是另一方面，Brooks又会在讲述设计中的约束时，在多处提到对自家房屋进行建筑设计和拟订整修方案时遇到的各种困难，并一一指出如何应对：有些约束只要改变一下思路就会消失，有些约束虽然无可避免但可以最小化，有些约束反映了原始设计方案中的方向性错误，等等（第1、3、17、18章）。这种十分贴近读者生活实际的例子不仅一下拉近了作者和读者的思想距离，同时也更说明Brooks热爱设计工作到何种程度，连一般人视作生活小节之处也不愿意放过，而是把它作为设计工程来研究一番2。顺便说一句，Brooks在建筑设计方面也决非业余，他曾经参与他工作至今的北卡罗来纳大学的西特森厅设计，是设计委员会的正式成员3，这在本书中也有提及（第4章）。
    当然，Brooks毕竟是软件工程业界的先驱，正如在他的《人月神话》或任何一本主要文献中一样，我们都能够在他的作品的字里行间感受到计算机体系结构刚刚诞生的黄金年代充满了怎样的设计思想和工程实践的生机和活力。而Brooks也十分擅长专业史料的记载和整理，并且以他独有的方式为读者展示出极为清晰的脉络。比如，他主持设计的System/360系统不仅是当代操作系统在实际意义上的先祖和典范，而且它本身仍然活跃在历史舞台上：Brooks在书中指出，System/360和OS/360上的应用程序至今仍然可以完全兼容地运行在当今的后续体系结构之上，包括晚至2007年发布的64位IBM Z/90机型—一种System/360体系结构的直接后裔机型（第24章）。正是通过这样上承开天辟地之洪荒巨擘，下接耳熟能详之主流系统和应用的史诗式描述，让我们在充分领略软硬件发展史的无限风光的同时，也深切地感受到用心设计会带来数十年前后一贯的、可持续发展的产品，而这些产品及其反过来促进的设计思想和方法论又怎样彻底地改变了我们每一个人生活、工作和沟通的方式。这不也正是包括我们自己在内的一代代设计师和架构师投身于此的原动力吗？
    本书由我、王海鹏与InfoQ中文站的张龙、黄璜共同翻译完成。虽然与几位的合作还是第一次，但是整个过程进行得非常顺利和愉快。在全书的翻译实践中，我本人收获极大。能够逐字逐句地研读本书，已经是充分的精神享受—Brooks的文字无疑是值得一读再读的。再经过整个团队的协作和努力，把它的内容和意义带给中国的千百万读者，这对我们翻译工作者来说，已经是无上的嘉赏和成就了。当然，由于我们的水平所限，缺点和错误在所难免，希望广大读者不吝指正，以便在再版时予以修订。
    在本书的翻译过程中，机械工业出版社和InfoQ中文站给予了我们很大的支持、鼓励和帮助。UMLChina于2010年6月下旬举办了一场“Brooks新作暨《人月神话》35周年讨论会”，在本书出版前提供了一个与读者交流和讨论的机会。本书译稿成稿之前，多位友人阅读了翻译初稿并给予本人许多可贵的修正意见，尤其是和我一起工作的张龙、黄璜、王海鹏，盛大创新院的郭忠祥院长和刘海平工程师，SAP中国的范德成工程师，MBK Partners私募基金公司的章子琦分析师，富士康中国研发集团的Carl Giardina总监，以及微软总部的米琦工程师，在此一并致谢。当然，家父高学栋博士也通读了全稿并给予了我不少有关文法和表达的中肯意见。我也想借此机会向在工作和生活中给了我莫大支持的父母和家人表达我内心最深处的敬意和谢意，希望本书的出版能给他们带去快乐。

高博
2010年11月
于盛大创新院上海总部

    我写这本书是为了刺激设计者和设计项目经理，让他们深入思考设计的过程，特别是设计复杂系统的过程。本书从工程师的视角关注实用性与有效性，同时也关注效率和优雅性。

谁应该阅读这本书
    《人月神话》的目标读者是“职业程序员、职业经理，特别是管理程序员的职业经理”。在那本书中，我讨论了团队开发软件时，实现概念完整性的必要性、困难和方法。
    本书在相当大的程度上扩大了范围，并添加了我35年来学到的经验。设计经验让我确信，各种不同设计领域的设计过程包含一些不变的因素。因此本书的目标读者是：
    1）各类设计者。排除直觉的系统化设计将得到普普通通的跟随式产品和仿冒产品，没有系统的直觉设计将得到充满缺陷的、不切实际的产品。如何将直觉和系统化方法融合在一起？如何成长为一名设计师？如何在一个设计团队中发挥作用？
    虽然我针对非常多的系统进行了论述，但我期望读者是偏重于计算机软件和硬件的设计者，面对这样的读者我可以提供具体的阐述。因此我在这些领域的某些例子中会涉及技术细节。其他读者可以跳过这些细节。
    2）设计项目经理。要避免灾难，项目经理在设计他的设计过程时，必须融合理论与口口相传的经验，而不是仅仅复制某种过于简化的学术模型，也不能临时设定一个过程，而不参考他人的理论或经验。
    3）设计研究人员。对设计过程的研究已经成熟，这是好事，但并不是一切都好。已发表的研究成果越来越关注更狭窄的主题，大问题讨论得越来越少。对精确的期望和对“设计科学”的期望可能使得科学研究之外的出版物受阻。我建议设计思考者和研究者重新关注这些大问题，即便是在社会科学方法没有太大帮助的时候。我相信他们也会思考我的论述是否具有通用性，我的观点是否正确。我希望为他们的学科领域提供服务，将他们的一些研究结果带给实践者。

为什么要再写一本关于设计的书
    创造东西是一种快乐，是一种极大的满足。J. R. R. Tolkien说上帝给了我们发明创造的能力，作为一件礼物，纯粹是为了让我们快乐。毕竟，“千山上的牲畜也是我的。……我若是饥饿，我不用告诉你。”设计本身就是快乐的。
    很多设计者从心理上和实践上都没有对设计过程进行很好的理解。这不是因为缺少研究。许多设计者反思了他们自己的设计过程。研究的动机之一就是，在所有的设计领域，最佳实践和平均实践之间存在着巨大的鸿沟，平均实践和半吊子实践之间也是如此。大部分的设计成本是返工，即纠正错误，这通常达到总成本的1/3。平庸的设计肯定是浪费了世界的资源，破坏了环境，影响了国际竞争力。设计很重要，设计教育也很重要。
    所以，根据推理，系统化设计过程将提升平均实践的水平，而结果也确实如此。德国的机械工程设计者们显然是首先采用了这一规划。
    随着计算机和之后人工智能（AI）的出现，设计过程的研究受到了极大的刺激。最初人们希望，AI技术不仅能够在过去人类主宰的领域中承担许多例行设计的工作，甚至能够产生杰出的设计。这种希望迟迟没有实现，而我本人觉得不可能实现。设计研究形成了一门学科，有一些专门的学术会议、期刊和许多研究项目。
    既然已经有了这么多认真的研究和系统的处理，为什么还要再写一本书？
    首先，设计过程自第二次世界大战以来，有了非常大的变化，而人们很少讨论这些变化。对于复杂产品的设计，团队设计越来越成为常态。团队常常在地理上是分散的。设计者越来越脱离产品的使用和实现，通常他们不再亲手打造他们设计的东西。各类设计者现在都陷在计算机模型中，而不是陷在图纸中。正式设计过程的教育越来越广泛，而且通常是雇主强制要求的。
    其次，仍然存在许多误区。当我们试图教学生怎样做好设计时，我们在理解上的差异就变得很明显了。Nigel Cross是设计研究领域的一位先行者，他追踪了设计过程研究变化的4个阶段。
    1）规定（prescription）一个理想的设计过程
    2）描述（description）设计问题的内在本质
    3）观察（observation）设计活动的现实
    4）反思（reflection）设计的基本概念
    我在我人生的60年时间里涉及了5种设计领域：计算机架构、软件、房屋、图书和组织机构。在每个领域，我都承担过团队中主设计者和协作者的角色。我对设计过程的兴趣由来已久，我在1956年的论文是“The analytic design of automatic data processing systems（自动化数据处理系统的分解设计）”。也许现在是时候进行成熟的反思了。

这是一本怎样的书
    现在令我非常吃惊的是，这些过程极为类似！思维的过程、人与人的交互、迭代、约束条件和劳动，都有很大的相似性。本书中反思的东西可能是隐藏在这些设计活动背后不变的设计过程。
    虽然计算机架构、软件架构的历史不长，对它们的设计过程的反思也不多，但建筑设计和机械设计已经有很长的历史和荣耀的过去。在这些领域，设计理论和设计理论家都很多。
    我是一名职业设计师，我所工作的领域中对设计的反思还不多，而在那些得到长期深入反思的领域，我是一名业余设计师。所以我将尝试从历史较长的设计理论中提取一些经验，应用于计算机和软件的设计。
    我相信“设计科学”是一个不可能完成的目标，实际上也是一个具有误导性的目标。这种解放思想的怀疑论让我们能够从直觉和经验的角度进行探讨，包括其他设计者的经验，他们很客气地和我分享了他们的领悟。
    所以我提供的既不是一本教科书，也不是一本包括一致论证的专著，而是一些观点文章。虽然我试图补充一些有用的参考和注解，探索一些隐秘的小路，但我仍建议读者先从头到尾阅读每篇文章，忽略这些注解和参考，然后再回过头来探索这些小路。所以我将它们藏在每章的末尾。
    某些案例研究提供了一些具体的例子，文章中参考了这些例子。选择这些例子并不是因为它们很重要，而是因为它们体现出了某种经验，我基于这些经验得出了结论和观点。我特别喜欢关于房屋功能设计的那些经验，任何领域的设计者都可以参考它们。
    作为主设计师，我完成了3所房屋的功能设计（详细的平面图设计、照明、电气和管道）。将房屋功能设计过程与复杂计算机硬件和软件的设计过程进行比较和对比，这帮助我提出了设计过程的“精髓”，所以我用它们作为我的案例，并且相当详细地介绍了这些过程。
    通过反思发现，许多案例研究具有惊人的共同特点：最大胆的设计决定，不论是谁做出的，都为优秀的结果作出了巨大的贡献。这些大胆的决定有时是因为远见，有时是因为绝望。它们总是在赌博，要求额外的投入，以期得到好得多的结果。

致谢
    本书的书名借鉴自40多年前Gordon Glegg的一部著作，他是一位富于创新精神的机械设计师、一个有风度的人、一位有吸引力的剑桥讲师。我很荣幸地在1975年与他共进午餐，感受到了他对设计的热情。他的书名准确地概括了我的尝试，所以我怀着感激与尊敬之情，沿用了这一书名。
    我感谢Ivan Sutherland对我的鼓励，他在1997年建议将一本讲义发展成一本书，并在10多年后对草稿提出了尖锐的批评，促进了巨大的改进。这使我后来的智力发展历程受益良多。
    如果没有北卡罗来纳大学教堂山分校资助的3个研究项目以及系主任Stephen Weiss和Jan Prins的支持，这本书是不可能完成的。我在剑桥大学受到了Peter Robinson的亲切接待，在伦敦大学学院受到了Mel Slater以及他们的系主任和同事的亲切接待。
    美国国家科学基金会（NSF）的计算机与信息科学工程（CISE）理事会的设计科学（Science of Design）项目由助理理事长Peter A. Freeman发起， 该项目为本书的完成和相关网站的准备提供了最有用的资助。这笔资助让我能够访谈许多设计者，并能够在过去几年里将主要工作集中在这些文章上。
    我非常感谢许多真正的设计师，他们与我分享了他们的领悟。我用一张致谢表列出了受访者，并在末尾列出了评阅者。有几本书提供了特别多的信息，对我产生了很大的影响，我在第28章中列出了这些书。
    我的妻子Nancy是其中一些工作的共同设计者，她一直为我提供支持和鼓励，我的孩子Kenneth P. Brooks、Roger E. Brooks和Barbara B. La Dine也是一样。Roger对手稿进行了仔细的复查，并对每章内容提出了几十项建议，从概念到标点符号都有。
    我要感谢在北卡罗来纳大学获得的强大后勤支持，这种支持来自Timothy Quigg、Whitney Vaughan、Darlene Freedman、Audrey Rabelais和David Lines。Peter Gordon是Addison-Wesley的出版合作者，他提供了特别的鼓励。Julie Nahil是Addison-Wesley的全职产品经理，Barbara Wood是文字编辑，他们提供了无比专业的技能，付出了特别的耐心。
    John H. Van Vleck是诺贝尔物理奖获得者，当我在哈佛大学工程和应用学院Aiken的实验室读研究生时，他是那儿的院长。Van Vleck非常注重工程实践要建立在牢固的科学基础之上。他领导了美国工程教育从设计向应用科学的转变，这种转变富有朝气。就像钟摆摆到极点，反作用就会出现，教授设计从那时起一直引起争论。我非常感谢我在哈佛的3位老师，他们从未丧失对设计重要性的深刻理解并教授设计。他们是Philippe E. Le Corbeiller、Harry R. Mimno和我的导师Howard H. Aiken。

第1章  设计之命题
1.1  培根所言是否正确
1.2  什么是设计
1.3  何为真实？设计的概念
1.3.1  价值何在
1.4  对于设计过程的思考
1.5  设计类别
1.5.1  系统设计与艺术设计
1.5.2  常规，适应性，原创设计
第2章 工程师怎样进行设计思维——理性模型
2.1  模型概览
2.2  该模型的构思从何而来
2.3  理性模型有哪些长处
第3章 理性模型有哪些缺陷
3.1  我们在初始阶段并不真正地知道目标是什么
3.2  我们通常不知晓设计树的样子——一边设计一边探索
3.3  （设计树上的）节点实际上不是设计决策，而是设计暂定方案
3.4  有用性函数无法以增量方式求值
3.5  必要条件及其权重在持续变化
3.6  约束在持续变化
3.7  对于理性模型的其他批评
3.8  但是，尽管有这些缺陷和批评，理性模型仍然不屈不挠地存在
3.9  那又如何？我们的设计过程模型真的那么事关紧要吗
第4章  需求、罪念以及合同
4.1  一段恐怖往事
4.2  殊为不幸，无独有偶
4.3  抵制需求膨胀和蠕变
4.4  罪念
4.5  合同
4.6  一种合同模型
第5章  有哪些更好的设计过程模型
5.1  为什么要有一个占主导地位的模型
5.2  共同演化模型
5.3  Raymond的集市模型
5.3.1  运作机理
5.3.2  模型优势
5.3.3  什么时候可以采用集市模型
5.4  Boehm的螺旋模型
5.5  设计过程模型：第2 ~ 5章的讨论小结

培根所言是否正确

弗朗西斯·培根爵士的假设正是我们所面临的挑战。设计过程本身是否存在那些适用于广泛设计载体的不变的属性？如果答案是肯定的，那么在一个设计载体中，设计人员就可能在攻克该载体特有的困难的过程中积累经验，从而具有比其他人对一些原则的更为清晰的理解。此外，某些载体比其他载体拥有更长远的设计及元设计（即设计之设计）的历史，比如建筑。如果这些都是正确的，并且培根的结论正确，那么不同载体中的设计人员就可以通过比较自己的经验与见解而在他们自己所处的技艺领域中学到新知识。

什么是设计

《牛津英文词典》对设计这个动词作了如下定义：

这一定义的精髓在于计划、思维和后续执行。所以，一个设计（名词）是一种被创造出来的事物，它先于被设计的事物出现且与之相关，但又有所区别。英国作家、戏剧家Dorothy Sayers在她那本发人深省的著作《The Mind of the Maker》里，将创作的过程分为了三个不同的阶段，她称之为构想（Idea）、精神（Energy）（或实现（Implementation））以及交互（Interaction）。

这代表着：
1）概念性构想的形成；
2）在真实的媒体中实现；
3）在真实的体验中与用户交互。
在这一概念中，无论是一本书，或是一台电脑、一个程序，首先是一种概念性的构造，它独立于时间和空间，而其精髓是在作者的脑海中完成的。然后通过钢笔、墨水和纸或者硅和金属在真实的时间和空间中得以实现。当某人读到这本书、使用了这台计算机或运行了此程序时，用户与创作者的思想达到了交互，这种创作就完成了。
在我之前的一篇文章中，我将构建软件的工作分为根本的（essence）和次要的（accident）。

这一亚里士多德语言并非要贬低软件构建的次要部分。在现代语言中更易理解的术语应当是essential和incidental。）我称之为根本的软件构造部分是形成其概念性结构的心智过程，称之为次要的部分是其实现过程。交互，也就是Sayers所说的第三步，发生在软件使用之时。
因此，设计就是脑力的构思，即Sayers称之为“构想”的部分。它可以在任何的实现开始之前完成。曾有一次，莫扎特的父亲询问他关于三周内要交付公爵的一部歌剧进度如何，莫扎特当时的回应既让我们感到震惊，又清晰地阐明了这一概念：

 对大多数的创作者来说，构思的不完整性和不一致性只有到了实现的时候才变得明显起来。因此，记录、实验和“解决”成为了理论家们的关键原则。
构想、实现和交互这三个阶段的操作是循环进行的。实现为另一轮必须完成的设计周期创造了空间。因此，莫扎特使用钢笔和纸实现了他的歌剧构思，而指挥家通过与莫扎特的作品进行交互，理解并形成了自己的演绎，又通过乐队和歌手将其实现。最终通过观众参与的交互而完成整个过程。
一个设计是一个被创造出的事物，与之相关的是一个设计过程，我将此过程称之为设计，不加任何修饰。还有一个是动词意义的设计，即进行设计。这三者是紧密相关的，我相信在具体的环境中就不会混淆它们的含义了。

何为真实？设计的概念

在2008年的第7届设计思想研讨会上，每个发言人都对四个同样的设计小组会议作报告。

视频和打印件都提前很好地分发下去了。
来自雷丁大学的Rachael Luck在架构会谈中提出一个之前没有引起任何人注意，而后又被大家一致认同的实体：设计概念。
毫无疑问，架构师和客户总是不断提到这一共享的不可见的实体。演讲者时常会对着画面作出各种含糊的手势，但显然他们并不是在指向画面的某一部分或者那其中的某一特定事物。通常，他们所关注的是开发中的设计概念的完整性。
Luck的见解让设计概念拥有了其自身的地位，这于我本人的经验有着强烈的共鸣。在开发IBM System/360大型计算机家族的单一架构的时候（1961～1963），尽管从来没有正式命名过，但这样的实体始终存在于架构小组内部。得益于Gerry Blaauw的远见卓识，我们将System/360的设计活动明确地分成了架构、履行和实现三个部分。

其基本思想是整个计算机家族对程序员呈现统一的接口，即架构；而根据性能和价格的不同可以有多个并行的实现（见第24章）。
多个实现的同时性伴随着几个工程经理的竞争，这些驱动着形成一个统一漂亮的架构，并且避免了为节约成本而作出较小的妥协。然而这种力量仅是来自于架构师们的本能和愿望，他们每个人都想做出一台漂亮的机器。

随着架构设计的不断发展，我发现了一件乍一看很奇怪的现象。对于架构小组而言，真正的System/360是设计概念本身—一台柏拉图式的理想机器。那些在工程车间建造中的机械式的或电子的Model 50、Model 60、Model 70和Model 90等，只不过是模仿那台真正的System/360的柏拉图式机器的影子。真正System/360的最完整最忠实的体现，不在那些以硅、铜或者钢的形式组成的物理计算机上，而是存在于《IBM System/360操作原理》这本程序员的机器语言手册的文字和图表里。

后来在View/360海滨小屋（见第21章）的建造中，我也有类似的体验。它的设计概念在构建活动开始的很早以前就已经成型。历经了许多版本的绘图与纸板模型搭建，其概念始终贯穿其中。

非常有趣的是，我从未在OS/360软件家族中感觉到这样的设计概念实体。也许它们的架构师有这种感受，又或许我对其概念框架的理解还没有到了如指掌的程度。也许设计概念没有在我这里萌发的一个原因是OS/360实际上是分别由四个部分混合而成的：一个主控制器、一个调度器、一个I/O控制器以及一个庞大的编译器和实用工具软件包（见第25章）。

价值何在

在设计对话中将不可见的设计概念转化为真正的实体是否会带来积极的价值呢？我认为是的。
首先，良好的设计具有概念性的完整性—统一、经济、清晰。它们不仅可以工作，而且能带来快乐，正如维特鲁威首次阐述的那样。8 我们使用诸如优雅、利落、漂亮这样的术语来形容桥梁、奏鸣曲、电路、自行车、计算机以及iPhone。辨析出设计概念这样一个实体，可以帮助我们在自己独自设计时去追寻这种完整性，有助于在团队设计时围绕这一概念一起工作，也有助于将它传授给年轻人。
其次，以这样的方式经常提及设计概念，对于一个设计团队内的沟通有极大的帮助作用。概念的统一是一种目标，它只有通过大量的对话才能达到。
就设计概念本身而言，比起由它衍生而出的表达或是部分细节，会话要直接得多，也是焦点所在。
因此，电影制片人使用故事板来保持其设计会话始终关注设计概念而不是实现细节。
关注细节，当然就会将不同版本的概念之间的冲突暴露出来，并迫使其得到解决。例如，System/360架构需要一个十进制数据类型，以桥接拥有成千上万用户的IBM十进制机器。我们所开发的架构中已经有了几个数据类型，包括32位的定点补码整数和可变长的字符串。

十进制数据类型可以被定义成类似于这两者当中的任意一个。那么哪一个才更适合System/360的设计概念呢？两方面对此都拿出了强有力的论据，这背后的力量直接依赖于个人对于设计概念不同的理解。一些架构师脑海中的设计概念反映的是早期的科学计算机，而其他架构师脑海中的概念反映的是早期的商务计算机。System/360有明确的设计目标，对于这两种应用都应提供良好的支持。
我们选择以字符串数据类型为基础来建模十进制数据类型，对于绝大部分特定的十进制数据类型用户群体，即IBM 1401的用户来说，这是最熟悉的数据类型。如果再给我一次机会，我仍会做出这样的决定。

对于设计过程的思考

关于设计的思想由来已久，至少可以追溯到维特鲁威（逝于公元前15年）。他于古典时期（Classical period）写就的《建筑十书》（De Architectura）被奉为设计的奠基之作。而随后达·芬奇的《达·芬奇笔记》（Notes）（1452—1529）及Andrea Palladio的《建筑四书》（Four Books of Architecture）（1508—1580）则可称作是这一领域里的里程碑。

而对于设计过程本身的思考则是近现代的事。Pahl和Beitz将其追溯到1852年由Redtenbacher所带来的德国思潮，这一思潮是由机械化的兴起而激发的。

对于我本人而言，关键的里程碑要数Christopher Alexander的《形式综合论》（Notes on the Synthesis of Form） （1962）、Herbert Simon的《人工科学》（The Sciences of the Artificial）（1969）、Pahl和Beitz的《机械制造》（Konstructionslehre）（1977），以及设计研究学会（Design Research Society）的成立和《设计研究》（Design Studies）（1979）这本杂志的创刊。
Margolin和Buchanan所编撰的《The idea of Design》（1995）收录了来自《Design Issues》期刊的23篇文章，大部分是关于设计评论与理论的，并“对理解设计有所影响的哲学问题作了少许探讨”（p.xi）。

我的《人月神话》（1975, 1995）反映了IBM OS/360的设计过程，它后来发展成为了MVS及其后继的产品系列。这本书着重描述该设计与开发项目中人、团队与管理等方面的内容。与当下工作密切相关的是这些文章的第4～6章，阐述了如何在团队设计中从概念性上达到完整与统一。
Blaauw及Brooks（1997）的《计算机架构：概念与演化》这本书对IBMSystem/360（以及System/370-390-z）的架构设计和相互关系，乃至许多设计决策背后的理论都作了广泛的讨论。该书并未全面涉及设计中的过程与人工活动。但该书1.4节关于良好的计算机架构性设计标准的讨论，与这部分工作有着特别密切的关系。

设计类别

系统设计与艺术设计

这本书介绍的是关于复杂系统的设计，并且是从工程师的视角出发的。工程师关心效用和功能，但同时也注重效率和优雅。
这与艺术家和作者所做的许多设计形成了对比，他们更强调设计所带来的愉悦和所要传达的意境。当然，建筑师和工程设计师同时属于这两种阵营。

常规、适应性、原创设计

我们通常认为桥梁设计是高超的工程设计之一，在桥梁设计中，概念或者技术的突破无论从成本、功能，还是审美的角度都能带来非常明显而又具有戏剧性的影响。
然而，一大部分的高速公路桥梁都较短，推出一个50英尺的混凝土桥梁设计已是一种常规且自动化的过程。对于短桥梁，土木工程师成竹在胸，很早以前就将各种决策树、约束变量和必要条件编撰成册了。同样的情况对于为成熟的语言设计新平台下的编译器也成立。在许多领域都有这种常规的自动化设计。

这本书重点强调的是原创设计，这与因参数变更而进行的对目标的重新设计，或者对先前的设计或目标进行修改以适应新目标的适应性设计，有着明显的区别。

模型概览

工程师们对于设计过程似乎有一个清晰但通常来说也是隐含的模型。这是一个关于有序过程的有序模型，也就是工程师的构思过程。我可以举一个海滨小屋设计（在第21章给出其草图）的例子来说明这是怎么回事。
目标。首先从主要目标或目的开始：“某人想要建立一个海滨小屋，以享用面向大海的一块海滨场地的风浪。”
必要条件。和主要目标相关的是一组必要条件或者说是次要目的：“海滨小屋应该加固，以抵御飓风来袭；它应该具备至少14个人躺卧和就座的空间；它应该为宾客提供令人难忘的视野”，等等。
效用函数。人们会根据一些效用或有用性函数来为若干必要条件依其重要性加权，以对设计进行优化。到目前为止，我知道的情况是，在大多数设计师的想象中，所有的项是由线性相加的方式组合起来的，但在单独构思每一个有用性函数时，则并非使用线性方式，而是以渐近曲线的方式趋于饱和。举个例子，必要条件之一是更大的窗户面积，这是在小屋设计中所需要考虑的问题。但是由窗户面积每平方英尺的额外增加所带来的效用是递减的。对于电源插座的数量来说，这也一样成立。窗户面积以及插座数量的总效用，看起来却仅仅是每个项的简单之和。
约束。每种设计以及每种优化都是受到一些约束限制的。其中有一些约束是二元的，只有满足或不满足的结果—“这所小屋必须位于海滨场地的边界线并再向后退至少10英尺”。其他约束则更有弹性，不过在接近限额时所付出的代价会急剧增加，比如日程表就是这样一类约束—主人可能急切地要求该海滨小屋在温暖气候来临之前完工。有些约束是简单的，比如退后尺寸的限额。另一些则在不经意间隐藏着令人生畏的复杂性—“该小屋必须满足所有的建筑法规”。
资源分配、预算和关键预算。许多约束的形式是固定资源在各个设计要素之间的分配。最常见的是一揽子成本的预算。但是，此类约束绝不仅仅只有这么一种，而且在特定的项目中，总预算约束也并不一定就是最大限度地决定了设计师注意力的约束。例如，在海滨小屋的楼层规划中，占支配地位的定量因素是临海建筑距离的英尺数（甚至要精确到英寸）。在计算机体系结构的设计中，关键预算可能是控制寄存器或指令格式所占用的比特数，或总内存带宽的用量。而当人们解决软件的“千年虫”问题时，日程表上的工作天数成为了可分配资源中的关键项。
设计树。这么一来，按照理性模型的思路，设计师们形成设计决策。然后，在由于该决策而缩编后的设计空间中，他又形成另一决策。在每一个节点处，他都可以选取一条或多条路径，因此设计的过程可以认为是一种对于以树型结构组织的设计空间的系统化探索。
在这样一个模型中，设计在概念上（至少在概念上）是个简单的过程。人们对以树型结构组织的设计空间进行搜索，以可行性约束为依据对每种方案进行检验，从而优化效用函数。搜索算法是众所周知的，并且可以清晰地描述。
这种清晰性仅存在于对所有路径进行的穷举搜索中，其目的在于寻找一个真正的最优解。设计师们通常只去寻找一个“足够好”的最低限度满足解。许多工程师似乎采用了某种深度优先策略进行近似估算，并在每个节点上选择最有前途或最有吸引力的方案，并采用探索到底的办法来达成目的。如果遇到死胡同，他们会采用回溯的办法并尝试另一条路径。预感、经验、连贯性和审美旨趣引导着每一次的方案选择。

该模型的构思从何而来

将设计过程建模为一种系统化的、按部就班的过程的观念，似乎肇端于德国机械工程社团。Pahl和Beitz在他们7次修改其稿的伟大论著中阐发了目前被最广泛地接受的观点。他们对达·芬奇（1452—1519）的《Notebooks》中关于设计备选方案的系统化搜索过程施以实践观点的考察，而并非只泛泛阅读那显式写出的陈述。
Herbert Simon在其著作《The Sciences of the Artificial》（1969, 1981, 1996）中独立地提出设计就是一个搜索过程的主张。他提出的模型及相关讨论远比这里的要复杂。Simon乐观地认为设计过程就是搜索人工智能意义下的合适标的（只要有足够的处理能力到位），他也投身于严格化理性设计模型的筹划，因为这样一种模型对于设计过程自动化而言乃是不可或缺的先驱力量。他的模型仍然有影响力—即使到了今天，我们已经认识到，其原始设计中的“险恶问题”可以说是在人工智能中最没前途的候选之一。
在软件工程领域，Winston Royce对于因为采用“先写了再说”的方法而造成的大型软件系统的项目失败而深感震惊，于是独立地引介了一种由7个步骤组成的瀑布模型，以将流程加以整顿，如第3章的第1插图所示。事实的情况是，Royce是把他的瀑布模型当做一个假想的批评对象提出来的，但是有很多人已经引用并追随这个假想的批评对象，他提出的更为复杂精妙的模型反而被晾在一边儿了。我在年轻的时候也犯过那样的错误，并在之后公开地为其忏悔。即使有那么一点儿讽刺的味道，Royce的7步模型仍然必须看做是设计的理性模型的基础性表述之一。
Royce强调，他的7个步骤是彼此泾渭分明的，需要分别地规划并各有专人负责。其中确有重叠的部分，但这部分被仔细地限定在一定范围之内：
各个步骤的顺序安排乃是基于以下的概念：每前进一步，设计就变得更加详尽，在（邻接的）前一步和后一步之间有一定的重叠，但是在序列中距离较远的步骤就不太会有什么重叠之处了……我们拥有一种有用的退路，这往往可以将早期工作中仍然可资利用的以及得到保留的部分尽可能地最大化。

设计空间可以表达为树型结构的观念，是在Simon的著作中隐含地提出的。这个观念在Gerry Blaauw和我合著的《Computer Architecture》一书中有具体的描述和图解。在该书中，我们将处理器架构的设计方案以严格的层阶架构形式组织在一个巨大的树型结构中，以83个链接子树来表示。有关闹钟的设计树可以作为一个简单的例子，如图2-1所示。其中，人们可以看到两种分别以开放和封闭的根型表示的分支。第一种，如“闹铃”节点所示，表示的是细分单元，每一个分支都是一种特定的设计属性，且必须指定其值。此即所谓属性分支。而备选方案分支，由“铃声”节点所示，则枚举了所有的备选方案，人们必须从中选择适当的方案。

图2-1   闹钟的设计树（部分），选自Blaauw和Brooks(1997)，所著的《Computer Architecture》的图1-12和图1-14

理性模型有哪些长处

“先开始编码再说，先开始构建再说”的行为相比，任何将设计过程系统化的工作都可以视为一种长足的进步。它为设计项目的规划提供了清晰的步骤。它为日程规划和进度评估定义了明确的阶段里程碑。它为项目组织和人员配备指明了方向。它改进了设计团队的内部沟通。而在设计团队和其项目经理之间以及项目经理和其他利益攸关者之间而言，它对于沟通的改进尤为显著。新手很容易就可以上手。掌握了它，新手在面对分派给他的第一个设计任务时，就知道从何入手了。
理性模型在特定的情形下会体现出更多的长处。在项目早期就给出目标的显式陈述、相关的必要条件以及约束说明，这有助于避免让团队陷于举棋不定的局面，也促使团队形成关于项目宗旨的统一认识。在开始编码或正式的制图工作开始之前做好整体的设计过程规划，就能够规避大量麻烦，也避免让许多努力付之东流。将设计过程打造成对于设计空间的系统化搜索，可以拓宽设计师个人的眼界，并把他们的视界提升到远远超过其先前的个人经验的程度。
不过，理性模型太过简化了，即使是Simon洋洋洒洒、高度成熟的版本也不免于此。因此，我们必须对其缺陷加以审查。

实情况是，设计师只把理性模型视为一种理想化的东西。它以某种方式描述了在我们的认识中设计过程应该如何运作，但在现实生活中，并不是那么一回事。
事实上，不是每个工程师都会大方地承认在他的心目中有这么一个很天真很理想的模型。但我认为我们中的大多数人都有这样的想法，我自己心中的这种想法持续了很长时间。因此，让我们对理性模型进行仔细彻底的剖析，以确切地了解它究竟在哪些方面脱离了现实。

我们在初始阶段并不真正地知道目标是什么

理性模型最严重的缺陷在于，设计师们往往只有一个模糊不清的、不完整的既定目标，或者说是主要目的。在此情形之下：
设计中最困难的部分在于决定要设计什么。
在我还是学生的时候，有一个暑假里去替一家很大的军火商打工，在那里我被指定去做设计和构建一个小型数据库系统的工作，用以跟踪某个雷达子系统的上万张图纸以及其中每一张图纸的更新状态。
过了几个星期，我做出来了一个能运行起来的版本。我自豪地向我的客户演示了一个输出报告的样例。
“做得不错，这的确是我想要的，不过你可否把这里改一下？那样我们就可以……”
在接下来的数个星期，每天早上我都给客户演示输出报告，每次都是顺应了前一天提出的要求之后的修订结果。每天早上，他都会对产品报告研习一番，然后使用一成不变的、彬彬有礼的口头禅提出另一项系统修订的要求。
系统本身很简单（是在打孔卡片机上实现的），而且那些修订在概念上看起来也是平淡无奇的。就算是最影响全局的变化也只是将图纸列表按照内部等级排序或缩进，而等级是用卡片上单独一个0～9的数字来表示的。其他的改进包括多级局部汇总—当然有例外情况要处理—以及自动地为不同的值得注意的值标注上星号。
有那么一阵子，我很是愤愤不平：“为什么他不可以就想要的内容下定决心？为什么他不能把想要的对我一口气说完，而偏偏要每天挤一点出来呢？”
然后，我一点点地认识到，我为客户提供的最有用的服务，乃是帮助他决定什么是他真正想要的。
那么，如今的软件工程原则要复杂得多了。我们认识到，快速原型是一种进行精准的需求配置的必要工具。不仅整个设计过程是迭代的，就连设计目标的设定过程本身也是迭代的。
软件工程领域的复杂化不仅没有停止的势头，甚至连明显的放缓也看不到，在汗牛充栋的文献资料中，“产品需求”仿佛是给定设计过程的常规假设前提。不过，我要提出一点异议，那就是，在初期就能了解整个产品需求属于相当罕见的例外，而远非常态：
设计师的主要任务乃是帮助客户发现他们想要的设计。
至少在软件工程领域，快速原型的概念有其地位及其公认的价值，但在计算机（体系结构）设计或是建筑架构设计中，它的地位与在软件工程中并不总是相当。但无论如何，在目标迭代的方面，我在这些设计领域都看到了相同的现象。越来越多的设计师们为计算机构建模拟器，为建筑构建虚拟环境演练，作为快速原型，以促成目标的收敛。目标的迭代必须作为设计过程的固有组成部分加以考虑。

我们通常不知晓设计树的样子—一边设计一边探索

在复杂结构的初始设计，如计算机、操作系统、航天飞机以及建筑等，每一项主要设计工作在如下方面都有足够的新意：

• 目标
• 必要条件和效用函数
• 约束
• 可用的加工技术

这些步骤中，设计师很少有机会能坐下来先验地绘制出一个设计树来。

此外，在高技术领域的设计中，甚至很少有设计师能够拥有足够的知识以绘制出该领域中基本的决策树来。设计项目往往会进行两年以上。设计师在此期间会得到升迁，从而脱离一线的设计工作。这样导致的后果就是，很少有设计师会在其职业生涯中将其一线工作深入到参与上百个项目的程度。这意味着，对于设计个人来说他就失去了探索其设计科目的所有分支的宝贵机会。因为这是工程领域的设计师的特点，和科学家大相径庭的是，他们很少会去触碰那些不能一眼看出是通往解决方案的备选途径。
相反地，设计师们会一边做着设计，一边进行设计树的探索—做出某个决策，然后查看由它启发或否决的备选方案，继而依此做出排在下一个的设计决策。

（设计树上的）节点实际上不是设计决策，而是设计暂定方案

事实上，特定的设计树自身只是在树形结构中搜索的简化模型。如图2-1所示，有并列的属性分支，也有备选分支。在一个分支中的各个备选方案彼此紧密联系—或彼此相斥或相辅相成或平分秋色。我们在《Computer Architecture》一书中给出的大块头设计树其实还是过分简化了；那样的一个设计树中所展示出来的“计算机众生相”对于阐明决策之间的联系乃是必不可少的。
这意味着，在设计树的每一个节点处，设计师所要面对的不仅仅是为单独一个设计决策准备的若干简单备选方案，而是为多个设计暂定方案准备的备选方案了。
此外，设计树中的决策排列顺序事关重大，可以参见Parnas在其经典论文“Designing software for ease of extension and contraction”中所阐述的真知灼见。
以树型结构表示的设计模型，其复杂性带来的组合爆炸是人们思维中的难以承受之重。（这情形就像是国际象棋中的棋子移动所构造出来的状态空间树。）该困境在第16章会有进一步的探讨。

有用性函数无法以增量方式求值

理性模型的假定是，设计是对于设计树的搜索，并且在每个节点处人们可以对若干下一级分支的有用性函数求值。
事实上，除非探索到所有分支的所有叶节点的程度，否则人们就很难做到这一点，因为大量的有用性指标（比如性能、成本等）对于随后的设计细节有着强烈的依赖。因此，虽然对有用性函数的求值在原则上是可行的，但是在实践上，人们就会在这里再次遭遇组合爆炸。
那么，设计师该怎么做？估算！理所当然，正式的也好，非正式的也罢，都要做估算。在求精的步骤中，人们必须对设计树进行剪枝。
经验。很多辅助信息都能够促进该过程中的直觉判断。其中之一是经验，无论是直接还是间接的：“OS/360的设计师们将OS/360操作系统中在整个系统范围内共享的控制块的格式细节暴露出来，这后来成为了维护工程师的噩梦。我们会将其封装为对象。”“宝来B5000系列在很久以前就探讨过基于叙词的计算机体系结构。由于本质性能损失实在太大，我们不打算继续深入设计子树了。”当然，工艺方面的权衡早已日新月异，但是上面的例子仍然很好地说明了经验教训。研习设计史的最有力的原因是去了解怎么样的设计方案是行不通的以及为什么这些设计方案行不通。
简单估算量。设计师们经常在进行设计树探索的早期就例行地采用简单估算量。建筑师们在得知目标预算以后，会粗略地估算一个平均到每平方英尺的成本，得出一个每平方英尺的目标，并使用它进行设计树的剪枝。计算机架构设计师们则会根据指令组合来对计算机性能做粗略的初步估算。
当然，这样做的危险在于，粗略的估算有可能会将本来可行但由于某个特定的估算量所采用的估算方法而看上去不可行的分支剪掉。我见过一个建筑师，他以过高的成本为理由，把一个早已指定的房顶结构之下的一堵墙壁给取消了，纯粹基于例行的平方英尺估算量他就作了这样的决定。而实际情况是，为增加的空间而付出的成本主要在于房顶，但那个是已经计算在内的了，所以这么一来边际成本会非常低。
将欲免费取之，必先无偿予之。

必要条件及其权重在持续变化

简而言之，在对于权衡的沉思中，一种对于整体设计问题的新理解逐渐浮现，即它是诸多因素以错综复杂、彼此牵制而又彼此交互的方式组合的结果。由此，对于诸项必要条件的权重计算方法就发生了变化。客户方—如果有—也逐渐地接受了这种理解，以此为出发点来形成对他将得到的成果的期望以及他将如何使用这个成果的预见。
例如，在我们的房屋改造设计中（详见第22章），一个在原始项目中看似简单的问题，在设计推进的过程中突显出来，原因就在于我和我的妻子将用例场景应用到了原始设计时的一个发问：“来参加会议的客人们该将他们脱下的外套搁在什么地方呢？”这个看起来权重不高的必要条件产生的影响规模很大，结果是把主卧从房间的一端迁移到了另一端。
此外，对于那些必须进行分块加工的设计，比如建筑和计算机的设计，设计师们从建造者处一点一滴地学习到有关设计和加工是如何交互的理解。大量的必要条件和约束条件被变更和改进。加工工艺也会有演进的过程，这对于计算机设计而言就是老生常谈的事了。
由于许多必要条件（如速度）是以性价比为权重的，这就会导致另一种现象的发生。随着设计向前推进，人们会发现在只需负担极少的边际成本的前提下，就可以增加某些特定的有用性的机会。在此情形下，在原始的必要条件清单中根本不存在的项目就会被添加进来，而这往往会使其后的设计变更中要求保留的预算余地被挤占。
例如，只有北卡罗来纳大学的西特森厅在设计、建造和投入使用的过程中，计算机科学系作为该建筑的用户，才学会如何在由楼下大堂、楼上大堂、学院会议室、讲演厅和走廊的成套空间内，将所有这些漂亮地组合成一个能够举办多至125人参加的会议的基础设施，同时把因其施工而对大楼内其他工作的影响减至最低。这个成功也可谓有着各种机缘巧合，因为在最初的建筑方案中并未考虑该厅所拥有的功能。然而，这是价值颇高的特色：任何对于西特森厅的未来修订肯定会把保留这些功能作为目标。

约束在持续变化

即使设计目标固定而且已知，所有的必要条件皆已枚举清楚，设计树已经刻画成很精确的样子，并且有用性函数也有着明确无误的定义，设计过程也仍然会是迭代的，因为约束在持续变化。
通常情况下是环境变了—市政厅会通过令人沮丧的规定给设计投下新的阴霾；电气规范每年都会更新，本来计划要用的芯片被供应商召回了，等等。一切都在不断变化，即使在我们的设计向前推进的过程中也并未留步。
约束也会由于设计过程中甚至加工过程中的新发现而发生变化—建筑工人碰到了无法凿穿的岩层，分析结果表明芯片的冷却问题成为了新近的约束，等等。
并非所有的约束变化都是增长型的。约束也经常消弭于无形。如果这种约束变化是偶发的，而不是人为的，熟练的设计师就能利用这样的新机遇，发挥其设计的灵活性，以绕过该约束。
并非所有的设计都有灵活性。更为常见的是，当我们深入一个设计过程时，就意识不到原来某个约束已经消失不见，也想不起来由于它的消失而早已排除的设计备选方案了。
重要的是要在设计过程的一开始就明确地列出已知的约束，作为架构师所谓的设计任务书的组成部分。设计任务书是一个文档，需要与客户共同完成，它规定了目标、必要条件以及约束。本书的网站给出了一个设计任务书的示例。设计任务书和正式需求描述文档不是一回事，后者通常是具有合同约束力的、定义某个设计方案的接受标准的文档。
将约束明确列出，是把丑话说在前面，这就可以避免日后突然爆发令人不快的局面。这同时也是在设计师的脑海中烙下对于这些约束的印象，从根本上提高某一约束消失时被设计师发现的可能性。
我们都是围绕着约束来做设计的，该过程要求对于设计空间中少有人问津的犄角旮旯有着很多创新和探索的精神。这是设计之乐的部分所在，这也是设计之难的大部分所在。
在设计空间之外的约束变化。然而，有时，设计的突破性进展来自于完全跳出设计空间的囚笼，在那里将设计的约束加以消除。在设计厢房的时候（见第22章），我努力了很久均未果，就为了一个令人心情灰暗的靠后尺寸需求约束以及音乐室的必要条件（要放置两架三角钢琴、一架管风琴以及一个正方形的空间以容纳弦乐八重奏乐队，加上一英尺宽的教学之用的余地）。如图3-1所示，这是设计过程的一次迭代以及其约束。

图3-1   依约束进行的设计

这个设计过程中遇到的棘手问题最终是在设计空间之外得到了彻底解决—我从邻居处买下了另外五英尺的地皮。这比向市政厅申请靠后尺寸变更—另一种设计空间之外的解决途径—来得可能更经济，并且肯定更富效率。它同样给设计方案的其他部分带来了解放，对于F书房的西北角的定位贡献尤其明显（见图3-2）。

图3-2   约束被放松了

将设计任务书中的已知约束明确列出的好处，在此处也有体现。设计师们可以定期地检视这个清单，自问：“现在有些东西已经变化了，这个约束能够去掉了吗？能不能通过在设计空间之外想出办法来规避它呢？”

对于理性模型的其他批评

理性模型是一种自然的思维模型。理性模型，如上所述、如上所评，似乎看上去相当幼稚。但它是人们能够自然而然地想到的一种思维模型。其思维自然程度可以从Simon版本、瀑布模型版本以及Pahl和Beitz版本分别独立地提出而得到强烈的印证。然而，从最早的时候开始，设计界就有了对于理性模型有说服力的批评。
设计师们根本不那样做事。也许对理性模型最具解构性的批评—尽管也许亦是最难以证明的—就是经验最丰富的设计师根本不那样做事。虽然已经发表出来的批评只是偶尔才会有“皇帝没有穿衣服耶！”这样指出该模型并未反映出专业实践做法的呛声，但是人们还是可以感觉到不厌精细的分析背后的这种压倒性的主张。
Nigel Cross，其绅士般的言论，也许是最具张力的不同意见。引经据典之下，他毫不讳言地说：

又及，

我发现，这个争鸣意见本身以及其实证材料都很具说服力。此处提及的振荡的确可以说是我所有设计经验的特点所在。“外套在哪里摆放？”这样的需求发掘了我们房屋设计过程的深层次内容就是个典型例证。
Royce对于瀑布模型的批评。Royce在他的论文原稿中描述了瀑布模型，以便他能够演示其不足之处。他的基本观点在于，尽管在毗邻方块之间有反向箭头表示逆向的工作流，但是该模型仍然行不通。不过，他的对策仅仅是采取了容许逆工作流箭头指回两个前向方块的模型罢了。治标不治本。
Schön归纳的批评小结。

但是，尽管有这些缺陷和批评，理性模型仍然不屈不挠地存在

通常来讲，某种理论或技术的原始创意提出人都比后继的追随者更了解其承诺所在、其局限所依以及其正确的应用范围。由于天资有限、热忱有余，他们的一腔热情却导致了思维僵化、应用偏差和过分简化等。
遗憾的是，理性模型的诸多应用亦是如此。近至2006年的文献，设计研究员Kees Dorst亦不得不承认，

诚哉斯言！在软件工程领域，我们仍然太过盲从瀑布模型—理性模型在我们领域的衍生品。
德意志工程师协会标准VDI-2221。德意志工程师协会于1986年采纳了理性模型，本质上如同Pahl和Beitz所介绍的那样，作为德国机械工程业界的官方标准。我见过很多由于这场运动引发的思想僵化。但Pahl自己一直在尽力设法澄清如下：

美国国防部标准2167A。类似地，美国国防部于1985年将瀑布模型正式纳入其标准2167A。直至1994年，在Barry Boehm的领导下，他们才开放了其他模型的准入门槛。

那又如何？我们的设计过程模型真的那么事关紧要吗

为什么就过程模型讲了这么多？我们或是别人用来进行设计过程的思维真的会影响我们的设计本身吗？我认为的确是这样的。
并非所有的设计思想家都同意我的观点。剑桥大学教授Ken Wallace与Pahl和Beitz著作的所有三个版本的英文译者，相信一个主要的进步会是某种让人能够轻而易举地理解和沟通的模型。他指出这一点对于设计的初学者来说是多么重要。Pahl和Beitz的模型为新手做设计准备了一个入手的空间，这样他们就不会徒陷彷徨。“我把Pahl和Beitz的图（他们书中的图1-6）放在我的讲义上，并解释了一下。在我紧接着下一张幻灯片上就写道：‘但现实中设计师是不那样工作的。’”
不过，我担心是否有更年轻的、个人设计经验更少的教育工作者总是会这样说。
苏珊娜·罗伯逊和詹姆斯·罗伯逊夫妇有着国际化咨询的实战经验，并且著有需求规划的重要作品，他们认为理性模型的不足之处并不值得大惊小怪。“更了解设计的人也更有智慧。”
无论如何，我相信我们带有缺陷的模型以及对其的盲从，将导致臃肿、笨重、功能过多的产品以及时间表、预算和性能的灾难。
右脑型的设计师。绝大多数设计师是右脑型的，是视觉-空间导向的。事实上，我在考察未来设计师的天赋时，用于投石问路的问题就是：“下一个11月在什么地方？”当听我说话的人显出莫名其妙的表情时，我会进一步地解释，“你有一个日历的空间思维模型吗？很多人都有的。如果你也有，能给我描述一下吗？”几乎每一个有竞争力的候选人都会有这样一个模型，但这些模型彼此大相径庭。
类似地，软件设计团队总是在他们共用的白板上画草图，而不是写文字和代码。而建筑师则把在描图纸上用的美工笔视为一个不可或缺的沟通工具，但是在独立思考时则用得更多。
因为我们设计师是空间思维导向的人，我们的过程模型在脑海中是以图表的形式深深植根的，无论其具体形式是Pahl和Beitz的垂直式矩形，还是Simon的树型结构，抑或是Royce绘制和批评的瀑布状图形。这些图表在潜意识层面大大地影响着我们的思维。因此，我认为一种先天不足的过程模型会以我们不能完全知晓、只有一知半解的方式阻碍我们前进。
一个由于采用了理性模型而造成的明显损害就是我们无法对接班人进行恰当的教育。我们教给他们连我们自己都不遵循的工作模式。结果，在他们形成自己在现实世界中采用的工作模式的过程中，我们就没能提供有用的帮助。
我认为，对于更资深的，尤其是那些有在业界设计经验的教师来说，情况就会大不一样。我们很清醒地认识到，这些模型是有意简化过，以帮助我们解决真实生活中遇到的问题，后者往往复杂得令人生畏。因此，我们在教给学生的时候也会提出“这只是地图，而不是真实的地形”的警告，因为只有模型是不够的，即使在可以适用的场合，它们也仍然有失精确。
在软件工程实践领域，还可以很容易地发现另一种不利因素—理性模型，无论以何种面目出现，都会导向一种先验的设计需求描述。它导致我们盲目相信这种需求真的是可以预先制订的。它也导致我们在对于项目一无所知的基础之上就彼此签订了合同。一种更加现实的过程模型将使得设计工作更富效率，并省却许多客户纠纷和返工努力。第4章和第5章将阐述需求问题。

瀑布模型是错误的、有害的，我们必须发展并摒弃之。

第6章  协作设计
6.1  协作是在本质上是好的吗
6.2  团队设计是现代标准
6.2.1  为什么工程设计从个人转向团队
6.3  协作的成本
6.4  挑战是概念完整性！
6.4.1  异议
6.5  如何在团队设计中获得概念完整性
6.5.1  现代设计是各学科间的协商吗
6.5.2  系统架构
6.5.3  一名用户界面设计师
6.6  协作何时有帮助
6.6.1  确定利益相关人的需求和愿望
6.6.2  概念探索—激进的可选方案
6.6.3  设计复查
6.7  协作何时无用—对设计本身
6.7.1  概念设计尤其不应该协作
6.8  两人团队很神奇
6.9  对于计算机科学家意味着什么
第7章  电信协作
7.1  为什么要电信协作
7.1.1专业化
7.1.2 家
7.1.3整天工作不停
7.1.4成本
7.1.5政策
7.2  到那里，做那事—IBM System/360计算机系列的分布式开发，1961–1965
7.3  让电信协作有效
7.3.1  面对面的时间很重要
7.3.2  干净的接口
7.4  电信协作的技术
7.4.1  低科技常常足够
7.4.2  视频会议

第8章 设计中的理性主义与经验主义
8.1  理性主义与经验主义
8.2  软件设计
8.3  我是个铁杆的经验主义者
8.4  其他设计领域中的理性主义、经验主义与正确性
第9章 用户模型——错误胜过含糊不清
9.1  明确的用户与用例模型
9.2  果真如此吗
9.3  团队设计
9.4  假如事实不可用该如何是好
9.4.1  猜测
9.4.2  错误胜过含糊不清
第10章 英寸、盎司、位与美元——预算资源
10.1  何谓预算资源
10.2  美元并非万灵丹
10.3  即便美元也有不同，替代品剖析
10.4  预算资源是可变的
10.5  那又如何
10.5.1  明确确认
10.5.2  公开跟踪
10.5.3  严格控制
第11章 约束是我们的朋友
11.1  约束
11.2  不完全如此
11.3  设计悖论：通用的产品要比特定用途的更难以设计
11.4  小结
第12章 技术设计中的美学与风格
12.1  技术设计中的美学
12.2  何谓逻辑美
12.2.1  简约
12.2.2  结构清晰
12.2.3  一致性
12.2.4  什么才是好的计算机架构
12.4.5  一致性的更多优点
12.6  技术设计中的风格
12.7  何谓风格
12.8  风格的属性
12.9  要想获得一致的风格——记录下来
12.10  如何获得良好的风格
第13章 设计中的范本
13.1  很少会有全新的设计
13.2  范例的角色
13.3  计算机与软件设计呢
13.3.1  你使用何种范本
13.4  学习范本的设计原理
13.4.1  第一代计算机
13.4.2  第三代计算机
13.4.3  虚拟内存
13.4.4  小型计算机的变革
13.4.5  微型计算机与RISC的变革
13.5  如何训练才能改进基于范本的设计
13.5.1  范例集合
13.5.2  超越集合
13.5.3  软件设计怎样呢
13.6  范本——懒惰、创意与自满
13.6.1  一些观点
13.6.2  懒惰
13.6.3  创意与自满
第14章 专业设计者缘何犯错
14.1  错误
14.2  曾经最糟糕的计算机语言
14.2.1  何谓JCL
14.2.2  JCL到底怎么了
14.2.3  JCL缘何是这个样子的
14.3小结
第15章  设计的分离
15.1  设计与使用和实现的分离
15.2  为什么分离
15.3  分离的结果
15.4  补救措施
15.4.1  补救措施1：用户场景体验
15.4.2  补救措施2：通过增量式设计和增量式交付与用户密切交互
15.4.3  补救措施3：并发工程
15.4.4  补救措施4：设计者的教育
第16章  展现设计的演变途径和理由
16.1  简介
16.2  知识网线性化
16.3  我们的设计演变途径记录
16.4  我们研究房屋设计过程的过程
16.4.1  什么是设计树
16.5  深入设计过程
16.5.1  设计不只是满足需求，也是发现需求
16.5.2  设计不是简单地选择可选方案，也是意识到它们的存在
16.5.3  设计变化时树也变化—如何展现演进过程
16.6  决策树与设计树
16.7  模块化与紧密集成的设计
16.8  Compendium和可选工具
16.8.1  Task Architect
16.8.2  项目管理工具
16.8.3  IBIS和它的衍生品
16.8.4  Compendium
16.9  DRed：一个诱人的工具

第17章  计算机科学家的建筑设计理想系统——从思维到机器
17.1  挑战
17.2  一个设想
17.2.1  渐进完善
17.2.2  模型库
17.2.3  渐进完善模式的不足
17.3  从思维到机器输入的设想
17.3.1  名词-动词组合
17.4  说明动词
17.5  说明名词
17.6  说明文字
17.7  说明助词
17.8  说明视点和视图
17.8.1  内部视图
17.8.2  外部视图
第18章  计算机科学家的建筑设计理想系统——从机器到思维
18.1  双向通道
18.2  视觉显示——多并发窗口
18.2.1  制图桌和绘图视图
18.2.2  2D内容视图
18.2.3  3D视图
18.2.4  外部视图
18.2.5  工作手册视图
18.2.6  规格视图
18.3  声音展示
18.4  触觉展示
18.5  泛化
18.6  可行性

第19章  卓越的设计来自卓越的设计师
19.1  卓越的设计和产品过程
19.2  产品过程：优点和不足
19.2.1  产品过程抑制了卓越的设计吗
19.2.2  为什么要有产品过程
19.3  观点碰撞：过程抑制，过程不可避免；怎么做
19.3.1  卓越的设计来自卓越的设计师，去找到他们
19.3.2  卓越的设计需要大胆的领导者，他们要求创新
19.3.3  如何设计一个鼓励卓越设计的过程
19.3.4寻求概念完整性：信任一名主设计师来完成设计
第20章  卓越的设计师从哪里来
20.1  我们必须教他们设计
20.2  我们必须为卓越设计而招募人才
20.3  我们必须深思熟虑地培养他们
20.3.1  让两架梯子真实而体面
20.3.2  规划正式的教育经历
20.3.3  规划不同的工作经历
20.3.4  规划离开组织机构去休假
20.4  管理他们时必须发挥想象力
20.5  必须严密地保护他们
20.5.1  防止他们分心
20.5.2  保护他们不受管理者干扰
20.5.3  防止他们去做管理
20.6  把自己培养成一名设计师
20.7  不断画设计草稿
20.8  寻求有知识的人对您的设计的批评
20.9  研究教学示例和先例
20.10  一个自我教育项目：1000平方英尺房屋的建筑平面图

第21章  案例研究：海滨小屋“View/360”
21.1  亮点和特性
21.2  背景介绍
21.3  目标
21.4  机会
21.5  约束条件
21.7  设计决定
21.8  考虑正面
21.9  小屋的尺寸
21.10  设想的开始
21.11  在设计之后，构建之前的设计改动
21.12  在框架和外墙完成和初次入住之后的设计改动
21.13  评估（在37年后）
21.13.1  乐事
21.13.2  实用性
21.13.3  牢固性
21.13.4  如果我“废弃一个计划”呢
21.14  学到的一般经验
第22章  案例研究：增加厢房
22.1  亮点和特性
22.2  背景介绍
22.2.1  背景
22.3  目标
22.3.1  最初目标
22.3.2  后来发现的目标
22.4  约束条件
22.5  非约束条件
22.6  事件
22.7  设计决定和迭代
22.7.1  考察
22.7.2  分割设计问题
22.7.3  东部
22.7.4  西部一半的功能安排
22.7.5  方式变化：忘掉预算是设计约束条件
22.7.6  新发现的需求：
22.7.7  功能安排的会合
22.7.8  构建期间的改动
22.8  评估——成功与未解决的缺点
22.8.1  新功能
22.9  学到的一般经验
第23章  案例研究：厨房重新建模
23.1  亮点和特性
23.2  背景介绍
23.2.1  背景
23.3  目标
23.4  机会
23.5  约束条件
23.6  关键宽度预算的推理
23.6.1  从北到南需要的宽度
23.6.2  试验性的设计
23.6.3  另一些宽度解决方案
23.6.4  最终的宽度设计
23.7  长度预算的推理
23.8  其他设计决定
23.8.1  照明
23.9  评估
23.10  满足的其他迫切需求
23.11  在设计中使用图纸、CAD、模型、仿真模型和虚拟环境
23.11.1  虚拟环境的发现
23.12  学到的一般经验
第24章  案例研究：System/360体系结构
24.1  亮点和特性
24.2  项目介绍和相关背景
24.2.1  相关背景
24.3  目标
24.3.1  主要目标
24.3.2  其他重要目标
24.4  机遇（截至1961年6月）
24.5  挑战和限制
24.6  最重大的设计决策
24.7  里程碑事件
24.8  结果评估
24.8.1  稳定性
24.8.2  有用性——竞争力，各个市场的分析
24.8.3  闪光点
24.9  取得的经验教训
第25章 案例研究：IBM Operating System/360操作系统
25.1  亮点和特性
25.2  项目介绍和相关背景
25.2.1  System/360系列机型
25.2.2  1961年的软件格局
25.3  接受挑战
25.4  设计决策
25.4.1  系统架构
25.5  结果评估
25.5.1  成功之处
25.5.2  设计中的不足
25.5.3  流程中的不足
25.6  设计师团队
25.7  取得的经验教训
第26章  案例研究：《Computer Architecture: Concepts and Evolution》图书设计
26.1  亮点和特性
26.2  项目介绍和相关背景
26.2.1  相关背景
26.3  项目目标
26.4  机遇
26.5  约束
26.6  设计决策
26.7  结果评估
26.8  经验教训
第27章  案例研究：联合计算中心组织：三角区大学计算中心
27.1  亮点与特性
27.2  介绍与内容
27.2.1  内容
27.3  目标
27.3.1  主要目标
27.3.2  其他目标
27.4  机会
27.5  约束
27.6  设计决策
27.7  董事会所考虑的投票方案
27.7.1  权力均衡的限定
27.8  测量评估
27.8.1  牢固性
27.8.2  实用性
27.8  经验总结
第28章 推荐阅读
致谢
参考文献