軟體專案的要求：目標、使用者手冊、內部文件、進度、預算、組織機構圖和工作空間分配。即使是小型專案，專案經理也應該在專案早期規範化上述的一系列文件。
對於大多數專案，第乙個開發的系統並不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是個必須完成的步驟，如果將開發的第乙個系統丟棄原型發布給使用者，可以獲得時間，但是它的代價很高。對於使用者，使用極度痛苦；對於重新開發的人員，分散了精力；對於產品，影響了聲譽，即使最好的再設計也難以挽回名聲。 使用者的實際需要和使用者感覺會隨著程式的構建、測試和使用而變化。 軟體產品易於掌握的特性和不可見性，導致了它的構建人員面臨著永恆的需求變更。目標和開發策略上的一些正常變化無可避免，事先為它們做準備總比假設它們不會出現要好得多。 對於乙個廣泛使用的程式，其維護總成本通常是開發成本的40％或更多。 維護成本受使用者數目的嚴重影響。使用者越多，所發現的錯誤也越多。 缺陷修復總會以（20－50）%的機率引入新的bug。 在每次修復之後，必須重新執行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。 同樣，設計實現的人員越少、介面越少，產生的錯誤也就越少。所有修改都傾向於破壞系統的架構，增加了系統的混亂程度。即使是最熟練的軟體維護工作，也只是放緩了系統退化到不可修復混亂的程序。
由於我們是每個人負責自己的那一部分。而現在這種情況，大家都在自己的家中。每個人和每個人的軟體配置都是不一樣的。所以當匯入別人的專案的時候，會出現很多的錯誤。導致我們很多時間都在用來解決這個錯誤，分散了精力。而且我們這個，帶來的使用者體驗也就沒有了那麼好。當我們開始做這個專案的時候，就會預想到哪一部分是比較難實現的。這也就是未雨綢繆。認識到自己所處的現狀，發現自己的不足，然後再去學習。
沒有任何技術或管理上的進展，能夠獨立地許諾十年內使生產率、可靠性或簡潔性獲得數量級上的進步。
人月神話閱讀筆記03
人月神話拜讀完了，真的感覺學到了很多，受益匪淺，書開始就形象有有趣的把軟體危機比作 焦油坑，交流至關重要，實踐是最好的老師，文件撰寫是軟體人的必修課，這本書讓我們對軟體工程有了更深一步的理解，有了全新的認識，軟體工程焦油坑在相當長時間內仍會存在，我們必須努力學習，不斷創新，獲得更大的進步。一 我過去...
人月神話閱讀筆記03
今天我閱讀的是貫徹執行一節。假設乙個專案經理已經擁有行事規範的結構師和許多程式設計實現人員，那麼他如何確保每個人聽從 理解並實現結構師的決策？對於乙個由 1000 人開發的系統，乙個 10 個結構師 的小組如何保持系統概念上的完整性？首先要有文件化的規格說明，即手冊。手冊或者書面規格說明，是乙個非常...
人月神話閱讀筆記03
人狼這種民間傳說中存在的怪物，會在月圓之夜由我們熟悉的人類面孔變成可怕的狼臉。我們熟悉的軟體專案也有著人狼的特性，看似簡單明瞭的外表，但是卻可能隨時變成乙個進度落後 超出預算 存在大量缺陷的怪物。在民間傳說中對付人狼唯一可靠的 就是銀彈。所以銀彈在軟體專案中就是比喻這種使得軟體成本像計算機硬體成本一...