10.干將莫邪sharp tools
主要講述項目中管理好各種工具的重要性，項目經理首先要制定一種策略，讓各種工具成為公用的工具，這樣才能使開發、維護和使用這種工具的開發人員的效率更高，這種工具可能是開發人員開發出來的，也可能是使用現有的，可能是通用的，也可能是專用的或個人偏好的。比如：文檔編寫工具、開發工具（包括各種不同開發平台）、調試工具、測試工具、資料庫工具、版本管理、項目管理工具等。
11.整體部分the whole and the parts
一讀這一章，就讓我感觸頗深，特別是這句話＂bell實驗室監控系統項目的v.a.vyssotsky提出，＇關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方＇，細緻的功能定義，詳細的規格說明，規範話的功能描述說明以及這些方法的實施，大大減少了系統中必須查找的bug數量＂。雖然這句話的意思只是說明精確定義產品將減少bug的數量，但我看到了系統分析的最重要的工作——產品定義。現在，許多 開發人員嘴裡口口聲聲說也做過需求調研、系統分析、系統設計，但大多數沒有涉及到產品定義的深度，嚴格意義上不能叫做系統分析。這句話對我的以後想從事系統分析工作有很大的幫助。
這一章餘下的內容，也值得一看，雖然有些地方有些過時，但剔除bug的設計以及部分測試/調試方法仍值得一看。
12.禍起蕭牆hatching a catastrophe
這章節說明使項目進度拖後的最大原因不是重要的事件，如新技術、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以後，將使項目的進度嚴重拖後。
項目對於公司就如程式對測試工程師一樣，如果不了解它，它就是一個黑盒子，如果不打開這個黑盒子，你可能永遠不知道盒子裡面有什麼。這部分描寫項目經理以及小組主管的一些心理，值得一看。
13.另外一面the other face
本章說明程式的另一面——文檔。
不了解，就無法真正擁有——歌德，作者引用的歌德的話來描述文檔對客戶的重要性，提出客戶需要什麼樣的文檔以及文檔的格式和包含的內容，指出當時存在的大多數文檔只描述了樹木，形容了樹葉，但沒有整個森林的圖案。
想想，這種情況在現在仍然沒有改變。於是作者提出了兩個觀點：
&n
bsp;1.流程圖：流程圖是被吹捧得最過分的一種程式文檔。許多程式甚至不需要流程圖，很少程式需要一頁以上的流程圖
2.自文檔化（self-documenting）的程式：提出文檔與程式合為一體，能很好的解決文檔與程式分開造成的文檔過時的問題，並說明了在程式中加入文檔的一些方法和技巧。XX年，我看到一位網友關於文檔與程式合一的文章，當時就覺得是個好方法，沒想到70年代，老美已經提出來了。
14.沒有銀彈-軟體工程中的根本和次要問題(no silver bullet-essence and accident in software engineering)