用戶 優勢 困難 原型 開發需求 工具 大量 復用 生成

銀彈

《No Silver Bullet - Essence and Accidents of Software Engineering》的作者Brooks主張並斷言從這篇論文發表(1986年)開始計算的十年之內，不會有任何單一的軟件工程上的突破，能夠讓程序設計的生產力得到一個數量級的提升。這是因為軟件工程中的不可避免的幾個性質：復雜性（complexity）、隱匿性（invisibility）、配合性（conformity）以及易變性（changeability）。Brooks將軟件的開發分為accidental task和essential task，之前出現的高級語言、面向對象程序設計、人工智能等只是減少了accidental task的困難，而上述提到的幾個性質都屬於essential task，因此他才會做出如此斷言，即軟件工程沒有“銀彈”。
而《There Is a Silver Bullet》

的作者Brad J Cox認為面向對象編程可以成為軟件工程的“銀彈”。因為他認為大量可以復用的組件（輪子）可以使得軟件和其他制造業的產品一樣，通過程序員（工人）按部就班的進行組裝，而程序員們也不需要去關註輪子內部的東西，只需要知道接口怎麽用就行。
就我個人而言，我更加贊同Brooks的觀點，軟件工程沒有“銀彈”，面向對象編程確實是一個強有力的工具，但總是要有造輪子的人才行，盡管現在什麽輪子都有，也不能保證隨著軟件開發需求的不斷變化，它們是否還能繼續使用。因此我認為面向對象編程只能說在很大程度上緩解了軟件工程的一些難題，並不能說正真解決了。

大泥球

所謂大泥球，是指雜亂無章、錯綜復雜、邋遢不堪、隨意拼貼的大堆代碼。毫無疑問，我的編譯器就是，特別是生成目標代碼時就是毫無設計，自己瞎寫。
解決方法：

我覺得最重要的是一開始就要做好設計，多花點時間在設計上；另外，在代碼風格比較好的情況下，一些大泥球還是可以挽救的；最後，在代價允許的情況下，我選擇重構。

大教堂和集市

大教堂相當於軟件工程的傳統開發模式：軟件只能由一組人開發，是封閉的、垂直的、集中式的模式；
集市是相對於大教堂的另一種新的模式：是並行的、點對點的、動態的多人協同開發模式，開發者之間通常僅僅靠互聯網聯系。
我們團隊采用的是大教堂。
據我所知，應該是沒有遇上過類似於迷失的情況。

Worse?Better?

我認為具體情況應該具體分析。對於一些精密度要求不高的軟件遵循“worse is better”的設計理念還是可以的，但對於那些精度要求很高的軟件，比如說航空領域的軟件，我覺得顯然不能為了追求simple而放棄其他的一致性和完整性。當然放在平時我們開發的軟件，如果時間要求緊迫的話，我還是非常信奉“worse is better”的觀點的，也許這就是導致我編譯出現大泥球的原因。

瀑布

瀑布模型遵循"系統需求-->軟件需求-->分析-->程序設計-->編碼-->測試-->運行"這個流程，在設計大型系統時，需要做相鄰步驟的回溯，解決上一階段未能解決的問題。
其在軟件工程實踐中有一點給的局限性：①各步驟之間是分離的，但是軟件工程生產過程中的各個步驟不能這樣嚴格分離開來；②回溯修改很困難甚至不可能，但是軟件生產的過程需要時時回溯；③最終產品知道最後才出現，但是軟件的客戶、甚至軟件工程師本人都需要盡早知道產品的原型並試用。

敏捷

①盡早並持續的交付有價值的軟件以滿足顧客的需求；
②歡迎需求的變化，並利用這種變化來提高用戶的競爭優勢；
③可用的軟件是衡量項目進展的主要指標；
④每日立會，討論項目進展，今日工作進展以及明日工作安排；

方法論

軟件工程的方法論在一定程度上可以幫助我們管理項目，但是我不認為在實際中強行硬套一個方法論會很有用，具體問題還是要具體分析，真正適合自己項目、團隊的才是最好的。

個人閱讀作業+個人總結