人月神話（40周年中文紀念版）

[美] 小弗雷德里克·布魯克斯（Frederick，P.Brooks，Jr.） 著，汪穎，UMLChina翻組 譯

• 出版社： 清華大學出版社
• ISBN：9787302392644
• 版次：1
• 商品編碼：12401749
• 品牌：清華大學出版社（Tsinghua University Press）
• 包裝：平裝
• 外文名稱：The Mythical Man-Month：Essays on Software Engineering Anniversary Edition
• 開本：16開
• 出版時間：2015-04-01
• 用紙：膠版紙
• 頁數：369
• 字數：316000
• 正文語種：中文

點此購買

內容簡介

　　在軟件領域，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理復雜項目提供了具有洞察力的見解，既有很多發(fā)人深省的觀點，又有大量軟件工程的實踐。
　　《人月神話（40周年中文紀念版）》內容來自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的項目管理經驗，該項目堪稱軟件開發(fā)項目管理的典范。
　　《人月神話（40周年中文紀念版）》英文原版一經面世，即引起業(yè)內人士的強烈反響，后又譯為德、法、日、俄、中、韓等多種文字，全球銷售數百萬冊。確立了其在行業(yè)內的經典地位。
　　在《人月神話（40周年中文紀念版）》第首次出版40年后的今天，我們重新整理了Brooks博士的經典內容，并將國內軟件開發(fā)領域先行者們對《人月神話》中的實踐及系統(tǒng)理論的使用經驗和心得集結成冊免費贈與大家共享，更使《人月神話（40周年中文紀念版）》成為國內從業(yè)者的必讀經典之一。
　　《人月神話（40周年中文紀念版）》讀者包括：軟件開發(fā)人員、軟件項目經理、系統(tǒng)分析師等IT從業(yè)者。

作者簡介

　　小弗雷德里克·布魯克斯，曾獲得美國計算機領域具聲望的圖靈獎（A.M.Turing Award）。美國計算機協(xié)會（ACM）稱贊他“對計算機體系結構、操作系統(tǒng)和軟件工程做出了里程碑式的貢獻”。
　　布魯克斯博士1956年開始任職于IBM公司，早期擔任Stretch 和Harvest計算機的體系建構師。他被認為是“IBM 360系統(tǒng)之父”，曾擔任360系統(tǒng)的項目經理。憑借在此項目中的杰出貢獻，他與Bob Evans和Erich Bloch在1985年獲得了美國國家技術獎（National Medal of Technology）。
　　布魯克斯博士創(chuàng)立了北卡羅來納大學的計算機科學系，并于1965-1985年擔任系主任。他還曾任職于美國國家科技局和國防科學技術委員會。目前其仍活躍于從事虛擬環(huán)境和科學可視化等方面的研究工作，2010年獲得虛擬現實事業(yè)獎（IEEE Virtual Reality Career Award）。

精彩書評

　　★《人月神話》仍然是計算機書籍中被引用次數多的經典著作，而且即便本書最初出版于20世紀，其內容至今仍未過時。在閱讀的時候，每隔幾頁不說一句“對極了！”是很難受的。
　　——Steve McCormell，Constmx&首席軟件工程師 名著《代碼大全》、《快速軟件開發(fā)》作者
　　
　　★這是一本經典著作，與軟件開發(fā)有關的每一個人都應該不止一遍地讀這本書。
　　——Philippe Kruchten，Rational統(tǒng)一過程首席架構師
　　
　　★我一本讀過很多遍的書，是Fred Brooks的《人月神話》，實際上我每過一兩年都重讀一遍。因為這本書文筆很好，而且書中的忠告很有價值，即使是在40年以后。當然，其在很多細節(jié)上和我們現在做事情的方法有所不同。我們的工作更自動化，計算機的“馬力”更強勁，但書中依然有許多好的忠告，我非常推崇這本書。這是我能想起來的你能從中體會到樂趣和思想的計算機科學書籍。
　　——Briall Kenlighan，名著《C程序設計語言》的合著者之一

目錄

第1章 焦油坑
編程系統(tǒng)產品
職業(yè)的樂趣
職業(yè)的苦惱

第2章 人月神話
樂觀主義
人月
系統(tǒng)測試
空泛的估算
重復產生的進度災難

第3章 外科手術隊伍
問題
Mills的建議
如何運作
團隊的擴建

第4章 貴族專制、民主政治和系統(tǒng)設計
概念的完整性
獲得概念的完整性
貴族專制統(tǒng)治和民主政治
在等待時，實現人員應該做什么

第5章 畫蛇添足
結構師的交互準則和機制
自律——開發(fā)第二個系統(tǒng)所帶來的后果

第6章 貫徹執(zhí)行
文檔化的規(guī)格說明——手冊
形式化定義
直接整合
會議和大會
多重實現
電話日志
產品測試

第7章 為什么巴比倫塔會失敗
巴比倫塔的管理教訓
大型編程項目中的交流
項目工作手冊
大型編程項目的組織架構

第8章 胸有成竹
Portman的數據
Aron的數據
Harr的數據
OS／360的數據
Corbató的數據

第9章 削足適履
作為成本的程序空間
規(guī)?？刂?br>空間技能
數據的表現形式是編程的根本

第10章 提綱挈領
計算機產品的文檔
大學科系的文檔
軟件項目的文檔
為什么要有正式的文檔

第11章 未雨綢繆
試驗性工廠和增大規(guī)模
唯一不變的就是變化本身
為變更設計系統(tǒng)
為變更計劃組織架構
前進兩步，后退一步
前進一步，后退一步

第12章 干將莫邪
目標機器
輔助機器和數據服務
高級語言和交互式編程

第13章 整體部分
剔除bug的設計
構件單元調試
系統(tǒng)集成調試

第14章 禍起蕭墻
里程碑還是沉重的負擔
“其他的部分反正會落后”
地毯的下面

第15章 另外一面
需要什么樣的文檔
流程圖
自文檔化的程序

第16章 沒有銀彈
摘要
介紹
根本困難
以往解決次要困難的一些突破
銀彈的希望
針對概念上根本問題的頗具前途的方法

第17章 再論“沒有銀彈”
人狼和其他恐怖傳說
存在著銀彈——就在這里
含糊的表達將會導致誤解
Harel的分析
Jones的觀點——質量帶來生產率
那么，生產率的情形如何
面向對象編程——這顆銅質子彈可以嗎
重用的情況怎樣
學習大量的詞匯——對軟件重用的一個可預見但還沒有被預言的問題
子彈的本質——形勢沒有發(fā)生改變
……

第18章 《人月神話》的觀點：是與非
第1章 焦油坑
第2章 人月神話
第3章 外科手術隊伍
第4章 貴族專制、民主政治和系統(tǒng)設計
第5章 畫蛇添足
第6章 貫徹執(zhí)行
第7章 為什么巴比倫塔會失敗
第8章 胸有成竹
第9章 削足適履
第10章 提綱挈領
第11章 未雨綢繆
第12章 干將莫邪
第13章 整體部分
第14章 禍起蕭墻
第15章 另外一面
第1版結束語

第19章 20年后的《人月神話》
為什么要出版20周年紀念版本
核心觀點——概念完整性和結構師
開發(fā)第二個系統(tǒng)所引起的后果——盲目的功能和頻率猜測
圖形界面的成功
沒有構建舍棄原型——瀑布模型是錯誤的
增量開發(fā)模型更佳——漸進地精化
關于信息隱藏，Parnas是正確的，我是錯誤的
人月到底有多少神話色彩？Boehm的模型和數據
人就是一切（或者說，幾乎是一切）
放棄權力的力量
最令人驚訝的新事物是什么？數百萬的計算機
全新的軟件產業(yè)——塑料薄膜包裝的成品軟件
買來開發(fā)——使用塑料包裝的成品軟件包作為構件
軟件工程的狀態(tài)和未來
結束語：令人向往、激動人心和充滿樂趣的50年
注解與參考文獻

附錄：人月落地實戰(zhàn)體驗
一、名家談人月
1．年金
2．《人月神話》與實踐
3．Frank Chance評人月
4．軟件尚方寶劍（Silver Bullet）何在
二、名著評人月
三、讀者感言
1．讀書有感——人月神話
2．我這幾天很煩（產品概念完整性）
3．關于我們的思考——“項目開發(fā)”及讀《人月神話》有感
4．我的“人月神話”
5．《人月神話》軟玉生香

精彩書摘

　　《人月神話（40周年中文紀念版）》：
　　作為成本的程序空間
　　程序有多大？除了運行時間以外，它所占據的空間也是主要開銷。這同樣適用于專用開發(fā)的程序，用戶支付給開發(fā)者一筆費用，作為必要分擔的開發(fā)成本。考慮一下IBMAPL交互式軟件系統(tǒng)，它的租金為每月400美元，在使用時，它至少占用160K字節(jié)的內存。在Model165上，內存租金大約是12美元／每月·千字節(jié)。如果程序在全部時間內都可用，他需要支付400美元的軟件使用費和1920美元的內存租用費。如果某個人每天使用APL系統(tǒng)4小時，他每月需要支出400美元的軟件租金和320美元的內存租用費。
　　常常聽到的一個“可怕的”談論是在2M內存的機器上，操作系統(tǒng)就需要占用400K內存。這種言論就好像批評波音747飛機，僅僅因為它耗資2700萬美元一樣無知。我們首先必須問的是“它能干什么？”對于所耗費的資金，獲得的易用性和性能（高效的系統(tǒng)利用）是什么？投資在內存上的每月4800美元的租金能否比用在其他硬件、編程人員、應用程序上更加有效？
　　當系統(tǒng)設計者認為對用戶而言，常駐程序內存的形式比加法器、磁盤等更加有用時，他會將硬件實現中的一部分移到內存上。相反，其他的做法是非常不負責任的。所以，應該從整體上進行評價。沒有人可以在自始至終提倡更緊密的軟硬件設計集成的同時，又僅僅就規(guī)模本身對軟件系統(tǒng)提出批評。
　　由于規(guī)模是軟件系統(tǒng)產品用戶成本中如此大的一個組成部分，開發(fā)人員必須設置規(guī)模的目標，控制規(guī)模，考慮減小規(guī)模的方法，就像硬件開發(fā)人員會設立元器件數量目標，控制元器件的數量，想出一些減少零件的方法。同任何開銷一樣，規(guī)模本身不是壞事，但不必要的規(guī)模是不可取的。
　　規(guī)?？刂?br>　　對項目經理而言，規(guī)模控制既是技術工作的一部分，也是管理工作的一部分。他必須研究用戶和用戶需求，以設置待開發(fā)系統(tǒng)的規(guī)模。接著，把這些系統(tǒng)劃分成若干部分，并設定每個部分的規(guī)模目標。由于“規(guī)模一速度”權衡方案的結果在很大的范圍內變化，規(guī)模目標的設置是一件頗具技巧的事情，需要對每個可用方案有深刻的了解。聰明的項目經理還會給自己預留一些空間，在工作推行時分配。
　　在OS/360項目中，即使所有的工作都完成得相當仔細，我們依然從中得到了一些痛苦的教訓。
　　首先，僅對核心程序設定規(guī)模目標是不夠的，必須把所有方面的規(guī)模都編入預算。在先前的大多數操作系統(tǒng)中，系統(tǒng)駐留在磁帶上，長時間的磁帶搜索意味著它無法自如地運用在程序片段上。OS/360和它的前任產品Stretch操作系統(tǒng)和1410-7010磁盤操作系統(tǒng)一樣，是駐留在磁盤上的。它的開發(fā)者對自由、廉價的磁盤訪問感到欣喜。而如果使用磁帶，會給性能帶來災難性的后果。
　　在為每個單元設立核心規(guī)模的同時，我們沒有同時設置訪問的預算。正如大家能想到的一樣，當程序員發(fā)現自己的單元核心未能達到要求時，他會把它分解成覆蓋模塊。這個過程本身增加了程序整體的規(guī)模，并降低了運行速度。最重要的是，我們的管理控制系統(tǒng)既沒有度量，也沒有捕獲這些問題。每個人都匯報了內核的大小，由于都在目標范圍之內，所以沒有人發(fā)現規(guī)模上的問題。
　　幸運的是，OS/360性能模擬程序投入使用的時間較早。第一次運行的結果反映出很大的麻煩。FortranH在帶磁鼓的Model65上，每分鐘模擬編譯5條語句。嵌入的例程顯示控制程序模塊進行了很多次磁盤訪問。甚至使用頻繁的監(jiān)控模塊也犯了很多同樣的錯誤，結果很類似于頁

前言/序言

　　在很多方面，管理一個大型的計算機編程項目與管理其他行業(yè)的大型工程很相似——比大多數程序員所認為的還要相似；在另外一些方面，它又有差別——比大多數職業(yè)經理人所認為的差別還要大。
　　這個領域的知識在于累積。現在，AFIPS（美國信息處理學會聯合會）已經有了一些討論和會議，也出版了一些書籍和論文，但是還沒有成形的方法對這一領域來進行系統(tǒng)地闡述。提供這樣一本主要反映個人觀點的小書看來是合適的。
　　雖然我原來從事計算機科學的編程方面的工作，但是在1956-1963年，自動控制程序和高級語言編譯器開發(fā)出來的時候，我主要參加的是硬件構架方面的工作。1964年，我成為操作系統(tǒng)OS/360的經理，我發(fā)現前些年的進展使編程世界改變了很多。
　　雖然是失敗的，但管理OS/360的開發(fā)仍是一次很有幫助的經歷。負責這次開發(fā)項目的團隊，包括我的繼任經理F.M.Trapnell，有很多值得自豪的東西。該系統(tǒng)在設計和執(zhí)行方面都很出色，并被成功地應用到很多領域，特別是設備獨立的輸入輸出和外部庫管理，在很多技術革新中被廣泛復制?，F在，這一系統(tǒng)是十分可靠的，相當有效且非常通用。
　　但是，并不是所有的努力都是成功的。所有OS/360的用戶很快就能發(fā)現它應該能夠做得更好。設計和執(zhí)行上的缺陷在控制程序中特別普遍，相比之下，語言編譯器就好得多。大多數缺陷發(fā)生在1964-1965年的設計階段，所以這肯定是我的責任。此外，這個產品發(fā)布推遲了，需要的內存比計劃中的要多，成本也是估計的好幾倍，而且第一次發(fā)布時并不能很好地運行，直到發(fā)布了幾次以后，問題才得以解決。

點此購買