Brooks認為，一個整潔、優雅的變成產品必須向它的每位使用者提供一個條理分明的概念模型，這個模型描述了應用，實現應用的方法以及用來指明操作和各種引數的使用者介面使用策略。概念的完整性是易用性中最重要的因素。而架構師，則是負責保證產品所有方面的概念完整性的，架構師設計的是能夠讓使用者理解產品概念的模型，這包括所有的功能的詳細說明以及呼叫和控制的方法。它就像電影的導演一樣。

　　我的理解：這裡的概念完整性其實應該說的是這個軟體理念上的業務流程的前後連貫，也就是使用者在使用產品的過程中，能夠按照唯一的一個的最高抽象的思路來使用這整個系統。

開發第二個系統的後果——盲目的功能和頻率猜測

　　所謂第二個系統，指的是產品的第二個實際釋出。開發第一個釋出的時候會因為各種原因去消減不必須的功能，所以會簡化問題，而在第二個版本的時候則常常想其中新增各種各樣的功能（也許源於使用者的功能建議）但是，卻導致了災難性的後果。

　　所以，在這種情況下，使用者群越大，越不穩定，我們就更加應該明確的定義使用者群，以獲得概念的完整性。我們必須為整個設計團隊定義一個共同的使用者影象，記錄下使用者群的屬性：

1.他們是誰

2.他們need什麼

3.他們認為自己need什麼

4.他們want什麼

而另一方面，對於任何產品，任何使用者群屬性都是一種概率上的分佈的，也就是每個屬性都有各種可能的值，所以我們能做的是，架構師去猜測（guess）或者假設（postulate）一系列完整的屬性和頻率值。這裡，清晰和錯誤都將比模糊不清好得多。

不同的社會經驗，不同的思想狀態，對讀後的心得也會不一樣.比如：

1.外科手術隊伍TheSurgicalTeam專案經理在專案的初期必須清楚的估計專案的人月運作模式（時間、人力在專案各階段的分配），例如什麼時候需要出什麼樣成果，決定了什麼時候需要什麼樣的人加入專案，這是專案經理的責任，讀後感《【轉】人月神話讀後感2》。

2.如何才能與實現人員就技術說明的瑣碎細節充分溝通，以確保設計被正確地理解，並精確地整合到產品中。

3.貫徹執行Passingtheword印象比較深刻的是”體系結構設計人員必須為自己描述的任何特性準備一種實現方法，但他不應該支配具體的實現過程。”

4.胸有成竹CallingtheShot主要講述如何計算程式設計時間，以及提出幾個人的經驗演算法。講述的各種演算法可能都不太適合與現在的高階語言，但Portman的觀點仍然適合現在，即程式設計人員實際的程式設計時間只有50％，其他的時間都花在了無關的瑣碎事情上。

5.整體部分TheWholeandtheParts一讀這一章，就讓我感觸頗深，特別是這句話”BELL實驗室監控系統專案的V.A.Vyssotsky提出，’關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方’，細緻的功能定義，詳細的規格說明，規範話的功能描述說明以及這些方法的實施，大大減少了系統中必須查詢的BUG數量”。雖然這句話的意思只是說明精確定義產品將減少BUG的數量，但我看到了系統分析的最重要的工作——產品定義。現在，許多開發人員嘴裡口口聲聲說也做過需求調研、系統分析、系統設計，但大多數沒有涉及到產品定義的深度，嚴格意義上不能叫做系統分析。這句話對我的以後想從事系統分析工作有很大的幫助。這一章餘下的內容，也值得一看，雖然有些地方有些過時，但剔除BUG的設計以及部分測試/除錯方法仍值得一看。

		　　〔【轉】人月神話讀後感2〕隨文贈言：【這世上的一切都借希望而完成，農夫不會剝下一粒玉米，如果他不曾希望它長成種粒；單身漢不會娶妻，如果他不曾希望有孩子；商人也不會去工作，如果他不曾希望因此而有收益。】