2019年6月25日13:37:3121.2K

设计原本 计算机科学巨匠Frederick P.Brooks的反思 内容简介

《设计原本：计算机科学巨匠Frederick P.Brooks的反思（珍藏版）》从工程师和架构师的视角深入地探讨了设计的和过程，尤其是复杂系统的设计过程，旨在提高产品的实用性与有效性，以及设计的效率和优雅性。全书共28章，分为6个部分：第一部分（1~5章）主要讨论了什么是设计、设计过程的思考、设计的类别、理性模型及其缺陷、以及对一些好的设计过程模型的探讨；第二部分（6~7章）主要讨论了协作设计与远程协作；第三部分（8~16章）全面总结了设计中的各种原则、经验和教训，包括设计中理性主义与经验主义、用户模型、资源预算、约束、设计中的美学与风格、设计中的范本、设计的分离、设计的演变途径和理由，以及专业设计者为何会犯错；第四部分（17~18）探讨了建筑设计与计算机软硬件设计在设计思想和方法上的一些共同点和不同之处；第五部分（19~20章）探讨了设计和设计师之间的关系，以及如何培养设计师；第六部分（21~28章）通过各个领域的各种类型的案例进行了分析和研究，旨在深刻揭示隐藏在这些案例背后不变的设计过程和思想。

除了从事计算机软硬件相关工作的读者应该阅读本书之外，其他领域的设计者、设计项目经理和设计理论研究人员也都能从《设计原本：计算机科学巨匠Frederick P.Brooks的反思》中找到大量宝贵资料。

设计原本 计算机科学巨匠Frederick P.Brooks的反思 目录

前言

第一部分 设计之模型

第1章 设计的疑问

1.1 培根的结论对吗

1.2 什么是设计

1.3 何为实在？设计理念

1.4 对设计过程的思考

1.5 设计面面观

1.6 注释和参考文献

第2章 工程师怎样进行设计思维-理性模型

2.1 模型概览

2.2 该模型的构思从何而来

2.3 理性模型有哪些长处

2.4 注释和参考文献

第3章 理性模型有哪些缺陷

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

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

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

3.4 效用函数无法以增量方式求值

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

3.6 约束在持续变化

3.7 对理性模型的其他批评

3.8 尽管存在诸多缺陷和批评，理性模型依然顽固存在

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

3.10 注释和参考文献

第4章 需求、罪念以及合同

4.1 一段恐怖往事

4.2 殊为不幸，无独有偶

4.3 抵制需求膨胀和蠕变

4.4 罪念

4.5 合同

4.6 一种合同模型

4.7 注释和参考文献

第5章 有哪些更好的设计过程模型

5.1 为什么要有一个占主导地位的模型

5.2 共同演化模型

5.3 Raymond的集市模型

5.4 Boehm的螺旋模型

5.5 设计过程模型：第2～5章的讨论小结

5.6 注释和参考文献

第二部分 协作与远程协作

第6章 协作设计

6.1 协作在本质上是好的吗

6.2 团队设计是现代标准

6.3 协作的成本

6.4 挑战在于保持概念完整性

6.5 如何在团队设计中获得概念完整性

6.6 协作何时有帮助

6.7 对设计本身而言，协作何时无用

6.8 两人团队很神奇

6.9 对于计算机科学家意味着什么

6.10 注释和参考文献

第7章 远程协作

7.1 为什么要远程协作

7.2 就地取材-IBM System/360计算机系列的分布式开发（1961～1965）

7.3 让远程协作有效

7.4 远程协作的技术

7.5 注释和参考文献

第三部分 设计面面观

第8章 设计中的理性主义与实证主义之争

8.1 理性主义与实证主义

8.2 软件设计

8.3 我是一个根深蒂固的实证主义者

8.4 其他设计领域中的理性主义、实证主义与正确性验证

8.5 注释和参考文献

第9章 用户模型-宁错勿淆

9.1 定义明确的用户模型和使用模型

9.2 团队设计

9.3 如果实际情况难以预料，有什么对策

9.4 注释和参考文献

第10章 英寸、盎司、比特与美元-预算资源

10.1 何谓预算资源

10.2 钱不是万能的

10.3 同一种资源也会有不同风格，甚至有替代品

10.4 预算资源并非一成不变

10.5 那我们究竟该怎么办

10.6 注释和参考文献

第11章 约束是友非敌

11.1 约束

11.2 归结于一点

11.3 设计悖论：通用产品比专用产品更难设计

11.4 注释和参考文献

第12章 技术设计中的美学与风格

12.1 技术设计中的美学

12.2 揭开逻辑之美的面纱

12.3 技术设计中的风格

12.4 何谓风格

12.5 风格的特点

12.6 若要使风格保持一致，请将它写成文档

12.7 如何形成良好的风格

12.8 注释和参考文献

第13章 设计中的范例

13.1 全新的设计是罕见的

13.2 范例所扮演的角色

13.3 计算机和软件设计中的问题

13.4 研究范例的设计原理

13.5 应该用什么样的方式来改进基于范例的设计

13.6 范例-惰性、创新与自满

13.7 注释和参考文献

第14章 智者千虑，必有一失

14.1 错误

14.2 曾经最糟糕的计算机语言

14.3 JCL何至于此

14.4 经验教训

14.5 注释和参考文献

第15章 设计的分离

15.1 设计与使用和实现的分离

15.2 为什么分离

15.3 分离的结果

15.4 补救措施

15.5 注释和参考文献

第16章 展现设计的演变轨迹和理由

16.1 简介

16.2 知识网线性化

16.3 我们的设计演变轨迹记录

16.4 我们研究房屋设计过程的过程

16.5 深入设计过程

16.6 决策树与设计树

16.7 模块化与紧密集成的设计

16.8 Compendium和可选工具

16.9 DRed：一个诱人的工具

16.10 注释和参考文献

第四部分 一套计算机科学家梦寐以求的房屋设计系统

第17章 计算机科学家梦寐以求的房屋设计系统-从头脑到电脑

17.1 挑战

17.2 愿景

17.3 输入机构的愿景：从头脑到电脑

17.4 指定动词

17.5 指定名词

17.6 指定文字

17.7 指定状语

17.8 指定视点和视图

17.9 注释和参考文献

第18章 计算机科学家梦寐以求的房屋设计系统-从电脑到头脑

18.1 双向通道

18.2 视觉显示-多个并列显示的窗口

18.3 听觉展示

18.4 触觉展示

18.5 推而广之

18.6 可行性

18.7 注释和参考文献

第五部分 卓越的设计师

第19章 伟大的设计来自伟大的设计师

19.1 伟大的设计与产品过程

19.2 产品过程-优点和不足

19.3 观点碰撞：过程扼杀创新，但又不可避免，如何是好

19.4 注释和参考文献

第20章 伟大的设计师从哪里来

20.1 我们必须教会他们设计

20.2 我们必须为伟大设计而招募人才

20.3 我们必须有意识地培养他们

20.4 我们必须在管理他们时发挥想象力

20.5 我们必须积极地保护他们

20.6 把自己培养成一名设计师

20.7 注释和参考文献

第六部分 设计空间之旅：案例研究

第21章 案例研究：海滨小屋“View/360”

21.1 亮点和特性

21.2 背景介绍

21.3 目标

21.4 机会

21.5 约束条件

21.6 设计决定

21.7 考虑正面

21.8 小屋的尺寸

21.9 设想的开始

21.10 在设计之后，构建之前的设计改动

21.11 在框架和外墙完成和初次入住之后的设计改动

21.12 结果评估（在项目验收37年后）

21.13 学到的一般经验

第22章 案例研究：增加厢房

22.1 亮点和特性

22.2 背景介绍

22.3 目标

22.4 约束条件

22.5 非约束条件

22.6 事件

22.7 设计决定和迭代

22.8 结果评估-成功与缺憾

22.9 学到的一般经验

22.10 注释和参考文献

第23章 案例研究：厨房重新建模

23.1 亮点和特性

23.2 背景介绍

23.3 目标

23.4 机会

23.5 约束条件

23.6 关键宽度预算的推理

23.7 长度预算的推理

23.8 其他设计决定

23.9 结果评估

23.10 满足的其他迫切需求

23.11 在设计中使用图纸、CAD、模型、仿真模型和虚拟环境

23.12 学到的一般经验

23.13 注释和参考文献

第24章 案例研究：System/360体系结构

24.1 亮点和特性

24.2 项目介绍和相关背景

24.3 目标

24.4 机遇（截至1961年6月）

24.5 挑战和限制

24.6 最重大的设计决策

24.7 里程碑事件

24.8 结果评估

24.9 学到的一般经验

24.10 注释和参考文献

第25章 案例研究：IBM Operating System/360操作系统

25.1 亮点和特性

25.2 项目介绍和相关背景

25.3 接受挑战

25.4 设计决策

25.5 结果评估

25.6 设计师团队

25.7 学到的一般经验

25.8 注释和参考文献

第26章 案例研究：《Computer Architecture： Concepts and Evolution》 图书设计

26.1 亮点和特性

26.2 项目介绍和相关背景

26.3 项目目标

26.4 机遇

26.5 约束

26.6 设计决策

26.7 结果评估

26.8 经验教训

第27章 案例研究：联合计算中心组织：三角区大学计算中心

27.1 要点和特点

27.2 项目介绍和相关背景

27.3 目标

27.4 机遇

27.5 限制

27.6 设计决策

27.7 备选的董事会投票方案

27.8 结果评估

27.9 经验教训

27.10 注释和参考文献

第28章 推荐读物

致谢

参考文献

设计原本 计算机科学巨匠Frederick P.Brooks的反思 精彩文摘

资源分配、预算和关键预算。许多约束的形式是固定资源在各个设计要素之间的分配。最常见的是一揽子成本的预算。但是，此类约束绝不仅仅只有这么一种，而且在特定的项目中，总预算约束也并不一定就是最大限度地决定了设计师注意力的约束。例如，在海滨小屋的楼层规划中，占支配地位的定量因素是临海建筑距离的英尺数（甚至要精确到英寸）。在计算机体系结构的设计中，关键预算可能是控制寄存器或指令格式所占用的比特数，或总内存带宽的用量。而当人们解决软件的“千年虫”问题时，日程表上的工作天数成为了可分配资源中的关键项。

设计树。这么一来，按照理性模型的思路，设计师们形成设计决策。然后，在由于该决漂而缩减后的设计空间中，他又形成另一决策。在每一个节点处，他都可以选取一条或多条路径，因此设计的过程可以认为是一种对于以树型结构组织的设计空间的系统化探索。

在这样一个模型中，设计在概念上（至少在概念上）是个简单的过程。人们对以树型结构组织的设计空间进行搜索，以可行性约束为依据对每种方案进行检验，从而优化效用函数。搜索算法是众所周知的，并且可以清晰地描述。

这种清晰性仅仅是指对所有路径进行的穷举搜索，寻找一个真正的最优解。设计师们通常只去寻找一个“足够好”的满足解。许多工程师似乎采用了某种深度优先搜索策略进行近似估算，并在每个节点上选择最有前途或最有吸引力的方案，并采用探索到底的办法来达成目的。如果遇到死胡同，他们会采用回溯的办法并尝试另一条路径。预感、经验、连贯性和审美观引导着每一次的方案选择。