《人月神話》作者最新力作:《設計原本:計算機科學巨匠Frederick P. Brooks的思考》

>>>  小城故事吳儂軟語溫婉人心的力量  >>> 簡體     傳統

書名:設計原本:計算機科學巨匠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. 論設計原本 Top

很少有人像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

《設計原本》譯者序(by高博) Top

司馬遷在《史記·孔子世家》中寫道:
……《詩》有之:“‘高山仰止,景行行止’。雖不能至,然心向往之。”

    大師之作不僅僅是指一部出自大師筆下的著作,更是特指大師的心血凝結之作。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月
于盛大創新院上海總部

 

《設計原本》前言(by布魯克斯) Top

    我寫這本書是為了刺激設計者和設計項目經理,讓他們深入思考設計的過程,特別是設計復雜系統的過程。本書從工程師的視角關注實用性與有效性,同時也關注效率和優雅性。

誰應該閱讀這本書
    《人月神話》的目標讀者是“職業程序員、職業經理,特別是管理程序員的職業經理”。在那本書中,我討論了團隊開發軟件時,實現概念完整性的必要性、困難和方法。
    本書在相當大的程度上擴大了范圍,并添加了我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。

第一部分 設計之模型 Top

第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章的討論小結

第1章 設計之命題 Top

弗朗西斯·培根在《學術的進展(全二卷)》卷二第10章寫道:
(新思想來自于)將對一門藝術的領悟聯系并應用到另一門藝術中,歷經若干次這樣的經歷而有所悟,腦海里自然就孕育出了(新思想)。
赫伯特·西蒙在《the Sciences of the Artificial》中 寫道:

很少有工程師和創作者……能夠通過探討對方的專業領域而互有所得。我的建議是,他們可以相互探討設計……(然后)彼此分享在這種專業的創造性設計過程中的經驗。

培根所言是否正確

弗朗西斯·培根爵士的假設正是我們所面臨的挑戰。設計過程本身是否存在那些適用于廣泛設計載體的不變的屬性?如果答案是肯定的,那么在一個設計載體中,設計人員就可能在攻克該載體特有的困難的過程中積累經驗,從而具有比其他人對一些原則的更為清晰的理解。此外,某些載體比其他載體擁有更長遠的設計及元設計(即設計之設計)的歷史,比如建筑。如果這些都是正確的,并且培根的結論正確,那么不同載體中的設計人員就可以通過比較自己的經驗與見解而在他們自己所處的技藝領域中學到新知識。

什么是設計

《牛津英文詞典》對設計這個動詞作了如下定義:

To form a plan or scheme of, to arrange or conceive in the mind ... for later execution.
對……形成計劃或模式,運用思維整理或考量……以便后續執行。

這一定義的精髓在于計劃、思維和后續執行。所以,一個設計(名詞)是一種被創造出來的事物,它先于被設計的事物出現且與之相關,但又有所區別。英國作家、戲劇家Dorothy Sayers在她那本發人深省的著作《The Mind of the Maker》里,將創作的過程分為了三個不同的階段,她稱之為構想(Idea)、精神(Energy)(或實現(Implementation))以及交互(Interaction)。

這代表著:
1)概念性構想的形成;
2)在真實的媒體中實現;
3)在真實的體驗中與用戶交互。
在這一概念中,無論是一本書,或是一臺電腦、一個程序,首先是一種概念性的構造,它獨立于時間和空間,而其精髓是在作者的腦海中完成的。然后通過鋼筆、墨水和紙或者硅和金屬在真實的時間和空間中得以實現。當某人讀到這本書、使用了這臺計算機或運行了此程序時,用戶與創作者的思想達到了交互,這種創作就完成了。
在我之前的一篇文章中,我將構建軟件的工作分為根本的(essence)和次要的(accident)。

這一亞里士多德語言并非要貶低軟件構建的次要部分。在現代語言中更易理解的術語應當是essential和incidental。)我稱之為根本的軟件構造部分是形成其概念性結構的心智過程,稱之為次要的部分是其實現過程。交互,也就是Sayers所說的第三步,發生在軟件使用之時。
因此,設計就是腦力的構思,即Sayers稱之為“構想”的部分。它可以在任何的實現開始之前完成。曾有一次,莫扎特的父親詢問他關于三周內要交付公爵的一部歌劇進度如何,莫扎特當時的回應既讓我們感到震驚,又清晰地闡明了這一概念:

一切都譜成了,只是還沒寫下來而已。

 對大多數的創作者來說,構思的不完整性和不一致性只有到了實現的時候才變得明顯起來。因此,記錄、實驗和“解決”成為了理論家們的關鍵原則。
構想、實現和交互這三個階段的操作是循環進行的。實現為另一輪必須完成的設計周期創造了空間。因此,莫扎特使用鋼筆和紙實現了他的歌劇構思,而指揮家通過與莫扎特的作品進行交互,理解并形成了自己的演繹,又通過樂隊和歌手將其實現。最終通過觀眾參與的交互而完成整個過程。
一個設計是一個被創造出的事物,與之相關的是一個設計過程,我將此過程稱之為設計,不加任何修飾。還有一個是動詞意義的設計,即進行設計。這三者是緊密相關的,我相信在具體的環境中就不會混淆它們的含義了。

何為真實?設計的概念

柏拉圖(公元前360年),《理想國》第十卷寫道:
如果許多個體有著共同的名字,那么我們可以認為它們同樣有著相應的概念或形式—明白我所說的嗎?
明白。
讓我們以任意一個普通的事物為例。我們的世界中有許許多多的床和桌子,是嗎?
是的。
但這里僅僅存在兩個它們的概念或形式:一個是床的概念,一個是桌子的概念。
確實如此。
而任何工匠都是遵循這種概念來制作我們所使用的床和桌子的。

在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英尺的混凝土橋梁設計已是一種常規且自動化的過程。對于短橋梁,土木工程師成竹在胸,很早以前就將各種決策樹、約束變量和必要條件編撰成冊了。同樣的情況對于為成熟的語言設計新平臺下的編譯器也成立。在許多領域都有這種常規的自動化設計。

這本書重點強調的是原創設計,這與因參數變更而進行的對目標的重新設計,或者對先前的設計或目標進行修改以適應新目標的適應性設計,有著明顯的區別。

 

第2章 工程師怎樣進行設計思維—理性模型 Top

Herbert Simon(1969),《The Sciences of the Artificial》 寫道
……因為設計的理論即一般的搜索理論……對象是巨大的組合空間。

模型概覽

工程師們對于設計過程似乎有一個清晰但通常來說也是隱含的模型。這是一個關于有序過程的有序模型,也就是工程師的構思過程。我可以舉一個海濱小屋設計(在第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洋洋灑灑、高度成熟的版本也不免于此。因此,我們必須對其缺陷加以審查。

 

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

實情況是,設計師只把理性模型視為一種理想化的東西。它以某種方式描述了在我們的認識中設計過程應該如何運作,但在現實生活中,并不是那么一回事。
事實上,不是每個工程師都會大方地承認在他的心目中有這么一個很天真很理想的模型。但我認為我們中的大多數人都有這樣的想法,我自己心中的這種想法持續了很長時間。因此,讓我們對理性模型進行仔細徹底的剖析,以確切地了解它究竟在哪些方面脫離了現實。

我們在初始階段并不真正地知道目標是什么

理性模型最嚴重的缺陷在于,設計師們往往只有一個模糊不清的、不完整的既定目標,或者說是主要目的。在此情形之下:
設計中最困難的部分在于決定要設計什么。
在我還是學生的時候,有一個暑假里去替一家很大的軍火商打工,在那里我被指定去做設計和構建一個小型數據庫系統的工作,用以跟蹤某個雷達子系統的上萬張圖紙以及其中每一張圖紙的更新狀態。
過了幾個星期,我做出來了一個能運行起來的版本。我自豪地向我的客戶演示了一個輸出報告的樣例。
“做得不錯,這的確是我想要的,不過你可否把這里改一下?那樣我們就可以……”
在接下來的數個星期,每天早上我都給客戶演示輸出報告,每次都是順應了前一天提出的要求之后的修訂結果。每天早上,他都會對產品報告研習一番,然后使用一成不變的、彬彬有禮的口頭禪提出另一項系統修訂的要求。
系統本身很簡單(是在打孔卡片機上實現的),而且那些修訂在概念上看起來也是平淡無奇的。就算是最影響全局的變化也只是將圖紙列表按照內部等級排序或縮進,而等級是用卡片上單獨一個0~9的數字來表示的。其他的改進包括多級局部匯總—當然有例外情況要處理—以及自動地為不同的值得注意的值標注上星號。
有那么一陣子,我很是憤憤不平:“為什么他不可以就想要的內容下定決心?為什么他不能把想要的對我一口氣說完,而偏偏要每天擠一點出來呢?”
然后,我一點點地認識到,我為客戶提供的最有用的服務,乃是幫助他決定什么是他真正想要的。
那么,如今的軟件工程原則要復雜得多了。我們認識到,快速原型是一種進行精準的需求配置的必要工具。不僅整個設計過程是迭代的,就連設計目標的設定過程本身也是迭代的。
軟件工程領域的復雜化不僅沒有停止的勢頭,甚至連明顯的放緩也看不到,在汗牛充棟的文獻資料中,“產品需求”仿佛是給定設計過程的常規假設前提。不過,我要提出一點異議,那就是,在初期就能了解整個產品需求屬于相當罕見的例外,而遠非常態:
設計師的主要任務乃是幫助客戶發現他們想要的設計。
至少在軟件工程領域,快速原型的概念有其地位及其公認的價值,但在計算機(體系結構)設計或是建筑架構設計中,它的地位與在軟件工程中并不總是相當。但無論如何,在目標迭代的方面,我在這些設計領域都看到了相同的現象。越來越多的設計師們為計算機構建模擬器,為建筑構建虛擬環境演練,作為快速原型,以促成目標的收斂。目標的迭代必須作為設計過程的固有組成部分加以考慮。

我們通常不知曉設計樹的樣子—一邊設計一邊探索

在復雜結構的初始設計,如計算機、操作系統、航天飛機以及建筑等,每一項主要設計工作在如下方面都有足夠的新意:

  • 目標
  • 必要條件和效用函數
  • 約束
  • 可用的加工技術

這些步驟中,設計師很少有機會能坐下來先驗地繪制出一個設計樹來。

此外,在高技術領域的設計中,甚至很少有設計師能夠擁有足夠的知識以繪制出該領域中基本的決策樹來。設計項目往往會進行兩年以上。設計師在此期間會得到升遷,從而脫離一線的設計工作。這樣導致的后果就是,很少有設計師會在其職業生涯中將其一線工作深入到參與上百個項目的程度。這意味著,對于設計個人來說他就失去了探索其設計科目的所有分支的寶貴機會。因為這是工程領域的設計師的特點,和科學家大相徑庭的是,他們很少會去觸碰那些不能一眼看出是通往解決方案的備選途徑。
相反地,設計師們會一邊做著設計,一邊進行設計樹的探索—做出某個決策,然后查看由它啟發或否決的備選方案,繼而依此做出排在下一個的設計決策。

(設計樹上的)節點實際上不是設計決策,而是設計暫定方案

事實上,特定的設計樹自身只是在樹形結構中搜索的簡化模型。如圖2-1所示,有并列的屬性分支,也有備選分支。在一個分支中的各個備選方案彼此緊密聯系—或彼此相斥或相輔相成或平分秋色。我們在《Computer Architecture》一書中給出的大塊頭設計樹其實還是過分簡化了;那樣的一個設計樹中所展示出來的“計算機眾生相”對于闡明決策之間的聯系乃是必不可少的。
這意味著,在設計樹的每一個節點處,設計師所要面對的不僅僅是為單獨一個設計決策準備的若干簡單備選方案,而是為多個設計暫定方案準備的備選方案了。
此外,設計樹中的決策排列順序事關重大,可以參見Parnas在其經典論文“Designing software for ease of extension and contraction”中所闡述的真知灼見。
以樹型結構表示的設計模型,其復雜性帶來的組合爆炸是人們思維中的難以承受之重。(這情形就像是國際象棋中的棋子移動所構造出來的狀態空間樹。)該困境在第16章會有進一步的探討。

有用性函數無法以增量方式求值

理性模型的假定是,設計是對于設計樹的搜索,并且在每個節點處人們可以對若干下一級分支的有用性函數求值。
事實上,除非探索到所有分支的所有葉節點的程度,否則人們就很難做到這一點,因為大量的有用性指標(比如性能、成本等)對于隨后的設計細節有著強烈的依賴。因此,雖然對有用性函數的求值在原則上是可行的,但是在實踐上,人們就會在這里再次遭遇組合爆炸。
那么,設計師該怎么做?估算!理所當然,正式的也好,非正式的也罷,都要做估算。在求精的步驟中,人們必須對設計樹進行剪枝。
經驗。很多輔助信息都能夠促進該過程中的直覺判斷。其中之一是經驗,無論是直接還是間接的:“OS/360的設計師們將OS/360操作系統中在整個系統范圍內共享的控制塊的格式細節暴露出來,這后來成為了維護工程師的噩夢。我們會將其封裝為對象。”“寶來B5000系列在很久以前就探討過基于敘詞的計算機體系結構。由于本質性能損失實在太大,我們不打算繼續深入設計子樹了。”當然,工藝方面的權衡早已日新月異,但是上面的例子仍然很好地說明了經驗教訓。研習設計史的最有力的原因是去了解怎么樣的設計方案是行不通的以及為什么這些設計方案行不通。
簡單估算量。設計師們經常在進行設計樹探索的早期就例行地采用簡單估算量。建筑師們在得知目標預算以后,會粗略地估算一個平均到每平方英尺的成本,得出一個每平方英尺的目標,并使用它進行設計樹的剪枝。計算機架構設計師們則會根據指令組合來對計算機性能做粗略的初步估算。
當然,這樣做的危險在于,粗略的估算有可能會將本來可行但由于某個特定的估算量所采用的估算方法而看上去不可行的分支剪掉。我見過一個建筑師,他以過高的成本為理由,把一個早已指定的房頂結構之下的一堵墻壁給取消了,純粹基于例行的平方英尺估算量他就作了這樣的決定。而實際情況是,為增加的空間而付出的成本主要在于房頂,但那個是已經計算在內的了,所以這么一來邊際成本會非常低。
將欲免費取之,必先無償予之。

必要條件及其權重在持續變化

Donald Schön,已故麻省理工學院的都市研究與教育教授、設計理論家如是說:
(當設計師)按初始狀況進行設計改造的時候,狀況本身會“抵觸”,而他只能就這種狀況反彈做出回應。
在健康的設計過程中,這種狀況交互是自反的。在回應狀況反彈時,設計師會將問題的構造、行動的策略以及現象的模型納入行動的考量,在每一步的推進中都隱含了這些考量。

簡而言之,在對于權衡的沉思中,一種對于整體設計問題的新理解逐漸浮現,即它是諸多因素以錯綜復雜、彼此牽制而又彼此交互的方式組合的結果。由此,對于諸項必要條件的權重計算方法就發生了變化。客戶方—如果有—也逐漸地接受了這種理解,以此為出發點來形成對他將得到的成果的期望以及他將如何使用這個成果的預見。
例如,在我們的房屋改造設計中(詳見第22章),一個在原始項目中看似簡單的問題,在設計推進的過程中突顯出來,原因就在于我和我的妻子將用例場景應用到了原始設計時的一個發問:“來參加會議的客人們該將他們脫下的外套擱在什么地方呢?”這個看起來權重不高的必要條件產生的影響規模很大,結果是把主臥從房間的一端遷移到了另一端。
此外,對于那些必須進行分塊加工的設計,比如建筑和計算機的設計,設計師們從建造者處一點一滴地學習到有關設計和加工是如何交互的理解。大量的必要條件和約束條件被變更和改進。加工工藝也會有演進的過程,這對于計算機設計而言就是老生常談的事了。
由于許多必要條件(如速度)是以性價比為權重的,這就會導致另一種現象的發生。隨著設計向前推進,人們會發現在只需負担極少的邊際成本的前提下,就可以增加某些特定的有用性的機會。在此情形下,在原始的必要條件清單中根本不存在的項目就會被添加進來,而這往往會使其后的設計變更中要求保留的預算余地被擠占。
例如,只有北卡羅來納大學的西特森廳在設計、建造和投入使用的過程中,計算機科學系作為該建筑的用戶,才學會如何在由樓下大堂、樓上大堂、學院會議室、講演廳和走廊的成套空間內,將所有這些漂亮地組合成一個能夠舉辦多至125人參加的會議的基礎設施,同時把因其施工而對大樓內其他工作的影響減至最低。這個成功也可謂有著各種機緣巧合,因為在最初的建筑方案中并未考慮該廳所擁有的功能。然而,這是價值頗高的特色:任何對于西特森廳的未來修訂肯定會把保留這些功能作為目標。

約束在持續變化

即使設計目標固定而且已知,所有的必要條件皆已枚舉清楚,設計樹已經刻畫成很精確的樣子,并且有用性函數也有著明確無誤的定義,設計過程也仍然會是迭代的,因為約束在持續變化。
通常情況下是環境變了—市政廳會通過令人沮喪的規定給設計投下新的陰霾;電氣規范每年都會更新,本來計劃要用的芯片被供應商召回了,等等。一切都在不斷變化,即使在我們的設計向前推進的過程中也并未留步。
約束也會由于設計過程中甚至加工過程中的新發現而發生變化—建筑工人碰到了無法鑿穿的巖層,分析結果表明芯片的冷卻問題成為了新近的約束,等等。
并非所有的約束變化都是增長型的。約束也經常消弭于無形。如果這種約束變化是偶發的,而不是人為的,熟練的設計師就能利用這樣的新機遇,發揮其設計的靈活性,以繞過該約束。
并非所有的設計都有靈活性。更為常見的是,當我們深入一個設計過程時,就意識不到原來某個約束已經消失不見,也想不起來由于它的消失而早已排除的設計備選方案了。
重要的是要在設計過程的一開始就明確地列出已知的約束,作為架構師所謂的設計任務書的組成部分。設計任務書是一個文檔,需要與客戶共同完成,它規定了目標、必要條件以及約束。本書的網站給出了一個設計任務書的示例。設計任務書和正式需求描述文檔不是一回事,后者通常是具有合同約束力的、定義某個設計方案的接受標準的文檔。
將約束明確列出,是把丑話說在前面,這就可以避免日后突然爆發令人不快的局面。這同時也是在設計師的腦海中烙下對于這些約束的印象,從根本上提高某一約束消失時被設計師發現的可能性。
我們都是圍繞著約束來做設計的,該過程要求對于設計空間中少有人問津的犄角旮旯有著很多創新和探索的精神。這是設計之樂的部分所在,這也是設計之難的大部分所在。
在設計空間之外的約束變化。然而,有時,設計的突破性進展來自于完全跳出設計空間的囚籠,在那里將設計的約束加以消除。在設計廂房的時候(見第22章),我努力了很久均未果,就為了一個令人心情灰暗的靠后尺寸需求約束以及音樂室的必要條件(要放置兩架三角鋼琴、一架管風琴以及一個正方形的空間以容納弦樂八重奏樂隊,加上一英尺寬的教學之用的余地)。如圖3-1所示,這是設計過程的一次迭代以及其約束。

圖3-1   依約束進行的設計

這個設計過程中遇到的棘手問題最終是在設計空間之外得到了徹底解決—我從鄰居處買下了另外五英尺的地皮。這比向市政廳申請靠后尺寸變更—另一種設計空間之外的解決途徑—來得可能更經濟,并且肯定更富效率。它同樣給設計方案的其他部分帶來了解放,對于F書房的西北角的定位貢獻尤其明顯(見圖3-2)。

圖3-2   約束被放松了

將設計任務書中的已知約束明確列出的好處,在此處也有體現。設計師們可以定期地檢視這個清單,自問:“現在有些東西已經變化了,這個約束能夠去掉了嗎?能不能通過在設計空間之外想出辦法來規避它呢?”

對于理性模型的其他批評

理性模型是一種自然的思維模型。理性模型,如上所述、如上所評,似乎看上去相當幼稚。但它是人們能夠自然而然地想到的一種思維模型。其思維自然程度可以從Simon版本、瀑布模型版本以及Pahl和Beitz版本分別獨立地提出而得到強烈的印證。然而,從最早的時候開始,設計界就有了對于理性模型有說服力的批評。
設計師們根本不那樣做事。也許對理性模型最具解構性的批評—盡管也許亦是最難以證明的—就是經驗最豐富的設計師根本不那樣做事。雖然已經發表出來的批評只是偶爾才會有“皇帝沒有穿衣服耶!”這樣指出該模型并未反映出專業實踐做法的嗆聲,但是人們還是可以感覺到不厭精細的分析背后的這種壓倒性的主張。
Nigel Cross,其紳士般的言論,也許是最具張力的不同意見。引經據典之下,他毫不諱言地說:

有關問題求解的習慣思維,往往看起來和專家級設計師們的行為背道而馳。不過,設計活動和使用習慣思維進行問題求解的活動有著相當多的不同之處……我們必須在從其他領域引入設計行為模型時倍加小心。對于設計活動的實證研究經常會發現,“有直感力的”設計能力乃是最有成果的,也是和設計的內廩性質最密切相關的。不過,設計理論的有些方面就是企圖針對設計行為開發出反直覺的模型和處方來。

又及,

在絕大多數設計過程的模型中都忽視了性質上處于同等地位的設計推理。在有著公論的關于設計過程的模型中,比如說由德意志工程師協會頒布的模型中(VDI,1987)……就主張設計活動應該分成一系列的階段進行……在實踐中,設計活動似乎是以在子解域和子問題域的區間振蕩的方式進行,同時也是將問題分解,爾后合并所有的子解決方案的過程。

我發現,這個爭鳴意見本身以及其實證材料都很具說服力。此處提及的振蕩的確可以說是我所有設計經驗的特點所在。“外套在哪里擺放?”這樣的需求發掘了我們房屋設計過程的深層次內容就是個典型例證。
Royce對于瀑布模型的批評。Royce在他的論文原稿中描述了瀑布模型,以便他能夠演示其不足之處。他的基本觀點在于,盡管在毗鄰方塊之間有反向箭頭表示逆向的工作流,但是該模型仍然行不通。不過,他的對策僅僅是采取了容許逆工作流箭頭指回兩個前向方塊的模型罷了。治標不治本。
Schön歸納的批評小結。

[Simon]發現在專業知識和現實世界的要求之間有著一道鴻溝……Simon提出……采用科學化設計的方式彌補這個鴻溝,他的科學化方法只能應用于對從實踐中總結的、良好構建的問題。
如果這種所謂的技術化理性模型未能考慮到實踐能力的“發散”情景,用了還不如不用。那么,還是讓我們轉而追尋一種基于實踐的認識論,它隱含在藝術的、直觀的實踐過程中,而這樣的過程已經被一些實踐者用以應對不確定性、不穩定性、單一性和價值觀沖突。

但是,盡管有這些缺陷和批評,理性模型仍然不屈不撓地存在

通常來講,某種理論或技術的原始創意提出人都比后繼的追隨者更了解其承諾所在、其局限所依以及其正確的應用范圍。由于天資有限、熱忱有余,他們的一腔熱情卻導致了思維僵化、應用偏差和過分簡化等。
遺憾的是,理性模型的諸多應用亦是如此。近至2006年的文獻,設計研究員Kees Dorst亦不得不承認,

盡管從彼時到現在已經有了長足的進步,但是Simon所著的探討問題求解以及具有病態結構的問題本質的原始著作,仍然在設計方法論領域有著難以忽視的影響。基于Simon提出的概念框架的理性問題求解范式,在該領域仍然占主導地位。

誠哉斯言!在軟件工程領域,我們仍然太過盲從瀑布模型—理性模型在我們領域的衍生品。
德意志工程師協會標準VDI-2221。德意志工程師協會于1986年采納了理性模型,本質上如同Pahl和Beitz所介紹的那樣,作為德國機械工程業界的官方標準。我見過很多由于這場運動引發的思想僵化。但Pahl自己一直在盡力設法澄清如下:

在VDI準則2221-2223以及Pahl和Beitz(2004)中給出的過程并非“按部就班”式的,它只能被視為有明確目的的基礎行動的指導性準則。在實際行動中有用的解決方案可能或是選擇一種迭代途徑(即那種帶有“前進或回退”步驟的途徑),或在采用更高信息層次上的反復途徑。

美國國防部標準2167A。類似地,美國國防部于1985年將瀑布模型正式納入其標準2167A。直至1994年,在Barry Boehm的領導下,他們才開放了其他模型的準入門檻。

那又如何?我們的設計過程模型真的那么事關緊要嗎

為什么就過程模型講了這么多?我們或是別人用來進行設計過程的思維真的會影響我們的設計本身嗎?我認為的確是這樣的。
并非所有的設計思想家都同意我的觀點。劍橋大學教授Ken Wallace與Pahl和Beitz著作的所有三個版本的英文譯者,相信一個主要的進步會是某種讓人能夠輕而易舉地理解和溝通的模型。他指出這一點對于設計的初學者來說是多么重要。Pahl和Beitz的模型為新手做設計準備了一個入手的空間,這樣他們就不會徒陷彷徨。“我把Pahl和Beitz的圖(他們書中的圖1-6)放在我的講義上,并解釋了一下。在我緊接著下一張幻燈片上就寫道:‘但現實中設計師是不那樣工作的。’”
不過,我担心是否有更年輕的、個人設計經驗更少的教育工作者總是會這樣說。
蘇珊娜·羅伯遜和詹姆斯·羅伯遜夫婦有著國際化咨詢的實戰經驗,并且著有需求規劃的重要作品,他們認為理性模型的不足之處并不值得大驚小怪。“更了解設計的人也更有智慧。”
無論如何,我相信我們帶有缺陷的模型以及對其的盲從,將導致臃腫、笨重、功能過多的產品以及時間表、預算和性能的災難。
右腦型的設計師。絕大多數設計師是右腦型的,是視覺-空間導向的。事實上,我在考察未來設計師的天賦時,用于投石問路的問題就是:“下一個11月在什么地方?”當聽我說話的人顯出莫名其妙的表情時,我會進一步地解釋,“你有一個日歷的空間思維模型嗎?很多人都有的。如果你也有,能給我描述一下嗎?”幾乎每一個有競爭力的候選人都會有這樣一個模型,但這些模型彼此大相徑庭。
類似地,軟件設計團隊總是在他們共用的白板上畫草圖,而不是寫文字和代碼。而建筑師則把在描圖紙上用的美工筆視為一個不可或缺的溝通工具,但是在獨立思考時則用得更多。
因為我們設計師是空間思維導向的人,我們的過程模型在腦海中是以圖表的形式深深植根的,無論其具體形式是Pahl和Beitz的垂直式矩形,還是Simon的樹型結構,抑或是Royce繪制和批評的瀑布狀圖形。這些圖表在潛意識層面大大地影響著我們的思維。因此,我認為一種先天不足的過程模型會以我們不能完全知曉、只有一知半解的方式阻礙我們前進。
一個由于采用了理性模型而造成的明顯損害就是我們無法對接班人進行恰當的教育。我們教給他們連我們自己都不遵循的工作模式。結果,在他們形成自己在現實世界中采用的工作模式的過程中,我們就沒能提供有用的幫助。
我認為,對于更資深的,尤其是那些有在業界設計經驗的教師來說,情況就會大不一樣。我們很清醒地認識到,這些模型是有意簡化過,以幫助我們解決真實生活中遇到的問題,后者往往復雜得令人生畏。因此,我們在教給學生的時候也會提出“這只是地圖,而不是真實的地形”的警告,因為只有模型是不夠的,即使在可以適用的場合,它們也仍然有失精確。
在軟件工程實踐領域,還可以很容易地發現另一種不利因素—理性模型,無論以何種面目出現,都會導向一種先驗的設計需求描述。它導致我們盲目相信這種需求真的是可以預先制訂的。它也導致我們在對于項目一無所知的基礎之上就彼此簽訂了合同。一種更加現實的過程模型將使得設計工作更富效率,并省卻許多客戶糾紛和返工努力。第4章和第5章將闡述需求問題。

瀑布模型是錯誤的、有害的,我們必須發展并摒棄之。

第二部分 協作與電信協作 Top

第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  視頻會議

第三部分 設計觀點 Top

第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:一個誘人的工具

 

第四部分 計算機科學家設計房屋的夢想系統 Top

第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  可行性

第五部分 卓越的設計師 Top

第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平方英尺房屋的建筑平面圖

第六部分 設計空間之旅:案例研究 Top

第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的思考》 2013-12-22 04:35:44

[新一篇] 中國古代不存在“農民起義”

[舊一篇] 創意領袖 vs. 權威領袖:一張表告訴你它們的區別
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表