第一章 焦油坑
程式設計產品是簡單程式通過通用化，測試，文件，維護等產生的。（保證是乙個完整的程式）
程式設計系統是簡單程式符合規範，功能上相互協作，並能與系統在互動上不出錯。（保證能與系統配合）
程式設計系統產品=程式設計系統+程式設計產品。程式設計系統產品才是大多數系統開發的目標。
程式設計系統產品的成本是簡單程式的9倍。
第二章 人月神話
（1）樂觀主義
系統程式設計的的進度安排背後的第乙個錯誤假設是：一切都將運作良好，每一項任務僅花費它所「應該」花費的時間。
缺陷：一切運轉正常對於單個任務而言具有可實現性，但對於大型程式設計工作而言，任務多，還有先後次序，一切正常的概率變得很小。
（2）人月神話
用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話，因為它暗示數量和時間是可以相互替換的。
缺陷：人數和時間的交換僅限於以下情況：某個任務可以分解給參與的人員，而且他們之間不需要相互的交流。
溝通所增加的負擔由兩個部分組成：培訓和相互的交流。
培訓的成本是隨人數的增加而線性增加的。
溝通的成本隨人數的增加而快速上公升。
（3）系統測試
單元測試和系統測試受到進度安排中的順序限制影響很大，因為預計的缺陷比實際的少很多，所以對測試的估計也是不準確的。
作者的經驗是：1/3計畫，1/6編碼，1/4構件測試和早期系統測試，1/4系統測試，所有構件的完成。
（4）空泛的估算
為了滿足顧客期望的日期而造成的不合理進度安排。
有兩種解決方案：
i、開發並推行生產率圖表，缺陷率圖表、估算規則等
ii、讓專案經理堅持他們的估計
（5）重複產生的進度災難
向進度落後的專案中增加人手，只會使進度更加落後。
人月神話閱讀筆記1
今天開始閱讀人月神話這本書 筆記如下 人月神話 作為軟體工程的經典著作，曾被坊間譽為程式設計師的聖經，但實際上，它並不是教人如何去做好乙個程式設計師，而是 了專案經理或者系統架構師的工作。書中大量舉證了作者開發作業系統 os 360時的專案經驗，其間觀點和論斷大多已經成為當今軟體開發的常識。布魯克斯...
1人月神話閱讀筆記
翻開 人月神話 這本書，我感覺看這本與我們學的相關的書不相似，書中用了很多的形象的比喻，來闡述專案管理中的一些問題，讓人以很輕鬆愉悅心態去閱讀。書開始就形象有有趣的把軟體危機比作 焦油坑。讓我感覺到，軟體開發過的過程中，會有很多困難，很多的挑戰。第一章 焦油坑 岸上的船兒如同海上的燈塔，無法移動 過...
寒假閱讀人月神話1
平邊界以下，程式變成測試 修復和擴充套件的程式。它可以執行在多種作業系統平台上，供多套資料使用。要成為通用的程式設計產品，程式必須按照普遍認可的風格來編寫，特別是輸入的範圍和形式必須擴充套件，以適用於所有可以合理使用的基本演算法。接著，對程式進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這就意...