以後我們做項目，一個純粹完整的項目的先決條件？他們是否有1、清晰的目標 2、人力 3、材料 4、足夠的時間 5、足夠的技術

那麽，既然已經具備了所有的這些條件，為什麽項目還會失敗呢？他們還缺乏些什麽？兩個方面-交流，以及交流的結果-組織。他們無法相互交流，從而無法合作。當合作無法進行時，工作陷入了停頓。我們推測交流的缺乏導致了爭辯，沮喪和群體猜忌。很快，部落開始分裂-大家選擇了孤立，而不是相互爭吵。

空間預算的多少和控制並不能使程序規模減小，為實現這一目標，他還需要一些創造性和技能。

計算機系統的硬件維護包括了三項活動-替換損壞的器件、清潔和潤滑、修改設計上的缺陷。

軟件維護不包括清潔、潤滑和對損壞器件的修復。它主要包含對設計缺陷的修復。和硬件維護相比，這些軟件變更包含了更多的新增功能，他通常是用戶能察覺的。

不同用戶需要不同級別的文檔。某些用戶僅僅偶爾使用程序，有些用戶必須依賴程序，還有一些用戶必須根據環境和目的的變動對程序進行修改。

使用程序：每用戶都需要一段對程序進行描述的文字。可是大多數文檔只提供了很少的總結性內容，無法達到用戶要求，就像是描繪了樹木，形容了樹葉，但卻沒有一幅森林的圖案。為了得到一份有用的文字描述必須要有目的、環境、範圍、實現功能和實用的算法、輸入-輸出格式、操作指令、選項、運行時間。

驗證程序：除了程序的使用方法，還必須附帶一些程序正確運行的證明，及測試用例。

每一份發布程序拷貝應該包括一些可以例行運行的小測試用例，為用戶提供信心-他擁有了一份可信賴的拷貝，並且正確地安裝到了機器上。

然後，需要得到更加全面的測試用例，在程序修改之後，進行常規運行。這些用例可以根據輸入數據的範圍劃分成三個部分。

1、針對遇到的大多數常規數據和程序主要功能進行測試的用例。他們是測試用例的主要組成部分。

2、數量相對較少的合法數據測試用例，對輸入數據範圍邊界進行檢查，確保最大可能值、最小可能值和其他有效特殊數據可以正常工作。

3、數量相對較少的非法數據測試用例，在邊界外檢查數據範圍邊界，確保無效的輸入能有正確的數據診斷提示。

修改程序：和一般用戶一樣，修改者迫切需要一切清晰明了的概述，不過這一次是關於系統的內部結構。那麽這份概述的組成部分是什麽呢？

1、流程圖或子系統的結構圖，對此以下有更詳細的論述。

2、對所用算法的完整描述，或者是對文檔中類似描述的引用。

3、對所有文件規劃的解釋。

4、數據流的概要敘述-從磁盤或者磁帶中，獲取數據或程序處理的序列--以及在每個處理過程完成的操作。

5、初始設計中，對已預見修改的討論；特性、功能回調的位置以及出口；原作者對可能會擴充的地方以及可能處理方案的一些意見。另外，對隱藏缺陷的觀察也同樣很有價值。

流程圖：流程圖是被吹捧的最過分的一種程序文檔。事實上，很多程序甚至不需要流程圖，很少有程序需要一頁紙以上的流程圖。

流程圖顯示了程序的流程判斷結構，他僅僅是程序結構的一個方面。當流程圖繪制在一張圖上時，他能非常優雅地顯示程序的判斷流向，但當它被分成幾張時，也就是說需要采用經過編號的出口和連續符來進行拼裝時，整體結構的概觀就嚴重的被破壞了。

卓越的設計人員-關鍵的問題是如何提高軟件行業的核心，一如既往的是-人員。

人月神話之閱讀筆記二