目录
Frederick P. Brooks Jr. 论设计的本质
译者序
前言
作者简介
第一部分 设计之模型
第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章的讨论小结
第二部分 协作与电信协作
第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章 推荐阅读
致谢
参考文献
【展开】
【收起】
内容简介
无论是软件开发、工程还是建筑,有效的设计都是工作的核心。《设计原本:计算机科学巨匠Frederick P. Brooks的思考》将对设计过程进行深入分析,揭示进行有效和优雅设计的方法。
本书包含了多个行业设计者的特别领悟。Frederick P. Brooks, Jr.精确发现了所有设计项目中内在的不变因素,揭示 了进行优秀设计的过程和模式。通过与几十位优秀设计者的对话,以及他自己在几个设计领域的经验,作者指出,大胆的设计决定会产生更好的结果。
作者追踪了设计过程的演进,探讨了协作和分布式设计,阐明了哪些条件造就了真正卓越的设计者。他探讨了设计过程的具体细节,包括多种预算约束条件、美学考虑、设计经验主义及工具。同时,他将这些讨论与现实中的案例结合起来,这些案例从房屋建造到IBM的Operating System/360。成功的关键因素贯穿全书,每个设计者、设计项目经理和设计研究者都应该知道。
【展开】
【收起】
下载说明
1、追日是作者栎年创作的原创作品,下载链接均为网友上传的的网盘链接!
2、相识电子书提供优质免费的txt、pdf等下载链接,所有电子书均为完整版!
下载链接
热门评论
-
爱奇艺娱乐的评论【包贝尔婚礼团队发微博证其未说谎】#柳岩当伴娘被捉弄# 3月30日,包贝尔与包文婧在巴厘岛举办婚礼,因伴娘柳岩险被伴郎团扔入水中视频,在网络上引起很大争议。4月1日,柳岩终以录制视频道歉回应此事,随后,包贝尔公开道歉,但指出“婚礼的游戏设计原本要玩撕名牌,但是因为衣服被海关扣了,只能临时
-
新浪福建的评论【柳岩当伴娘被捉弄:包贝尔发声回应 被海关打脸啪啪啪[doge]】4月1日晚,@包贝尔 在微博发长文详述当天情形并致歉。称婚礼的游戏设计原本要玩撕名牌,但是因为衣服被海关扣了,只能临时修改环节,变成双方对抗下水……对此,@广州海关12360 表示:这个锅,海关不背[拜拜]
-
段郎说事的评论【广州海关回应包贝尔婚礼:游戏玩不成玩伴娘的解释,我们不背】[嘻嘻]4月1日晚,包贝尔发博文解释,长文中他向柳岩道歉,认为柳岩哭是因为大家不了解情况,婚礼游戏设计原本要玩撕名牌,但因衣服被海关扣了。2日,广州海关回应称,原本打算玩游戏后来玩不成玩伴娘的解释,海关不背广州海关回应包贝尔婚...
-
新浪河南的评论#包贝尔撒谎#【柳岩当伴娘被捉弄:包贝尔发声回应 被海关打脸啪啪啪[doge]】4月1日晚,@包贝尔 在微博发长文详述当天情形并致歉。称婚礼的游戏设计原本要玩撕名牌,但是因为衣服被海关扣了,只能临时修改环节,变成双方对抗下水……对此,@广州海关12360 表示:这个锅,海关不背![拜拜]
-
旅行者橙乘N_Raido的评论新版LOFTER(5.0.0版)实在是丑到爆,于是我又换回旧版了。 虽然图片显示的问题一直都没有解决。 Lofter是个丢作品的好地方,界面设计原本很具宁静、文艺气息。新版界面简直像空间和微博,太喧闹了。忍无可忍。
-
臺華設計ANDY_LEUNG的评论按照甲方思路走,是正确的,甲方价值取向嘛。甲方的思路出错,而导致设计走弯路,那就是做设计的悲哀。设计原本对甲方,却中途出现施工方指指点点,那设计只能被设计。设计,变死路。 东莞·鸿福路口
-
听说跟你不熟的评论今天偶然的一个瞬间,如果中国的钢筋水泥能被若干年后形成的海绵城市所接纳,那么它会不会像泥土一般接纳钢筋水泥呢?设计原本就是环环相扣。若钢筋水泥遍地都是的时候,我们又会生活在哪儿。 北京·六圈
-
康小V啊V的评论做设计原本是件快乐又幸福的事,发现美创造美。然而这个过程中,总是有太多人为的不美好干涉那份好心情,能够安安稳稳专心做设计简直不要太幸福!
-
每日经济新闻的评论【包贝尔婚礼“柳岩被扔下水”是因为衣服被扣?广州海关出来表态了!】4月1日晚,包贝尔在微博上发表道歉长文向柳岩道歉并解释称,婚礼的游戏设计原本要玩撕名牌,但因衣服被海关扣了,只能临时修改环节......后一天,微博认证为广州海关“咨询投诉中心”的@广州海关12360 发文称:“原本打算玩游戏,
-
李小盆的评论"婚礼的游戏设计原本要玩撕名牌,但是因为衣服被海关扣了,只能临时修改环节,变成双方对抗下水…… ”--不知道这个修改是否经过伴郎伴娘的同意。如果伴娘明知道有被推下水的风险还要穿裙子,我不太相信这些伴娘没有替自己考虑的一点智商。