设计原本txt,chm,pdf,epub,mobi下载 作者: [美]Jr·Frederick P·Brooks 出版社: 机械工业出版社 副标题: 计算机科学巨匠Frederick P. Brooks的思考 原作名: The Design of Design: Essays from a Computer Scientist 译者:InfoQ中文站/王海鹏/高博 出版年: 2011-1-1 页数: 268 定价: 55.00元 装帧: 平装 丛书: 计算机科学丛书 ISBN: 9787111325574 内容简介 · · · · · ·无论是软件开发、工程还是建筑,有效的设计都是工作的核心。《设计原本:计算机科学巨匠Frederick P. Brooks的思考》将对设计过程进行深入分析,揭示进行有效和优雅设计的方法。 本书包含了多个行业设计者的特别领悟。Frederick P. Brooks, Jr.精确发现了所有设计项目中内在的不变因素,揭示 了进行优秀设计的过程和模式。通过与几十位优秀设计者的对话,以及他自己在几个设计领域的经验,作者指出,大胆的设计决定会产生更好的结果。 作者追踪了设计过程的演进,探讨了协作和分布式设计,阐明了哪些条件造就了真正卓越的设计者。他探讨了设计过程的具体细节,包括多种预算约束条件、美学考虑、设计经验主义及工具。同时,他将这些讨论与现实中的案例结合起来,这些案例从房屋建造到IBM的Operating System/360。成功的关键因素贯穿全书,每个设... 作者简介 · · · · · ·Frederick P. Brooks 北卡罗来纳大学计算机科学系的Kenan教授。他因领导开发IBM System/360计算机家族以及Operating System/360而荣获美国国家技术奖,并因对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献而获得A. M.图灵奖。他是畅销书《人月神话》的作者。 目录 · · · · · ·Frederick P. Brooks Jr. 论设计的本质译者序 前言 作者简介 第一部分 设计之模型 第1章 设计之命题 · · · · · ·() 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, Jr. 一样对软件开发的实践(而不是学术理论)产生那么大的影响。他在《人月神话》中记录了他作为IBM System/360计算机以及Operating System/360项目领导者的经验,这些经验不断地促使我们形成项目管理的观念。很难找到比他的“没有银弹:软件工程中的根本问题和次要问题”(《Information Processing 1986, Proceedings of the IFIPS Tenth World Compute... |
出新了自然都买
作者视角观点都是很独特,现在只看了一部分,相信不会辜负自己的
近乎平淡的笔触
好的话也推荐别人看