關於「銀子彈」的傳說：
當我們程式設計的時候總是會遇到這個問題，那個問題，比如效率低下，功能欠缺等等等等，這個時候總會有人想，是否有個「萬金油」似的解決方案，能夠一勞永逸？然而，這是不現實的。這麼多年來，有太多太多的失敗例子，從一開始就吹噓著它們的優勢，如4gls，又如case，可是事實證明，它們都無法達到革命性的突破，要不就是效果不明顯，要不就是有一定的侷限。我以為，作為乙個成熟的開發人員，並不應該迷信所謂的「銀子彈」，應該腳踏實地，將問題挨個解決，而非妄想一步登天。切記，一口吃不成胖子！
我理解的「瀑布模型」：
定義：該模型將軟體開發周期分為制定計畫、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
在乙個純瀑布模型中，以上各階段之間既不連續也不重疊，每乙個階段的結果都是乙個文件，這樣可以幫助開發者及早發現問題，並且在每乙個階段都無需再考慮欠乙個階段的內容，全心投入，使得開發更加穩定，提高開發效率。
當然，這樣的開發也有其侷限性。由於其中規中矩的運作，使得專案開發缺乏靈活性。當使用者需求改變時，整個過程都需要修改，難以回溯。然而，作為乙個開發團隊，開發的產品功能應由自己設計，而非單單由使用者指定（若是如此，相信其它團隊也能勝任），因此在開發過程中功能的增設應是常有的事，這就使得這一模型逐漸被「迭代模型」取代。該模型僅適合於技術力量較弱，缺乏開發經驗的團隊，或者是一些很複雜的問題（有乙個正確的匯流排指引就不易走上岔道）。
如何對待「大泥球」：
我對於大泥球的理解是，在開發過程中，由於沒有做好前期的設計，導致在程式執行時出現bug，於是開發者為了盡快解決這一bug，就會查詢出錯點，然好僅對那一段程式進行修改，直到該bug消除。在以前搞oi時經常會有這樣的事，為了趕時間嘛，所以當發現有錯時趕緊去修改那個錯，試圖盡快ac，然而，大多數時候都是徒勞的。就像設計一條衣服，先把每個部分做出來——袖子，領子，主體，口袋，扣子。然後將它們組合起來，最後發現，袖子和主體沒有完全縫合，扣子不對成，口袋有洞，甚至主體有缺陷。於是，我們將袖子和主體的縫合處重疊一下，勉強縫合，扣子調整一下位置，再補張布上去……這樣打補丁，試圖使得最終的衣服，不求好看，至少能穿，然而，最後的結果是你或許能套上去，但是遇到一些突發情況，如要去打球時，衣服就可能「喀嚓」一聲，四分五裂。真正的問題在於最初的設計！現在的設計尚未發現「大泥球」，也有可能是因為分工，互相都不知道各自的程式中是否有些「小泥巴」。對於這種情況，我的建議是重新設計一番。因為打補丁是乙個無底洞，有時你補了這邊，另一邊可能就出錯了。
「大教堂與集市」
這是兩種自由開發軟體的模式，它們都是基於**「開源」這一條件。我們團隊應該現在的專案屬於「大教堂」模式吧（畢竟是在上乙個清華團隊的源**基礎上改進功能及介面）……
losts in catb
關於這一問題，我持之前的觀點，僅僅依靠集市的市民們的自覺是無法建立乙個社會的，沒有一定的制度、秩序，光靠補丁是無法將一件衣服完善的。1+1<1的情況屢見不鮮，2種迥異的風格不僅使得程式的可讀性大大降低，甚至會由於之間的衝突導致程式無法執行。因此，過度的迷信集市是無法成功的，需要一座教堂為市民們引導方向。
敏捷開發
我們團隊要採用的敏捷開發做法有如下幾種：
（2） 迭代：第乙個階段的「阿爾法」版本即將出世，而「貝塔」版的設計即將提上日程
（3） 優先實現主要功能：其它的一些想法根據任務程序再決定是否實現
軟工第二次閱讀筆記
到底誰該負責？首先，對於 有人負責，才有質量 寫給在集市中迷失的一代 一文中的觀點，我只贊成其中一部分，對於另一部分我保留自己的意見。當然文中一些觀點對我還是很有啟發的。以下內容僅是我個人的拙見，如有不對，歡迎指正。我所贊同的 1 現在的軟體越來越複雜，大型軟體構件在無數小軟體 或者庫 上，但是現在...
軟工個人部落格作業
專案 內容這個作業屬於哪個課程 2020春季計算機學院軟體工程 羅傑 任健 這個作業的要求在 個人部落格作業 我在這個課程的目標是 學習敏捷開發的流程，對軟體工程有乙個系統的認識和實踐 這個作業在哪個具體方面幫助我實現目標 閱讀教材 構建之法 對軟體工程的含義初步了解 1.在personal sof...
第二次軟工實驗
課程 班級學 號 姓 名 實驗時間 軟體工程導論 12電信1 120705102 黃磊2013.12.10 軟體工程實驗報告 二 課表系統概要設計 完成課表系統概要設計，建立概要設計模型 系統掌握軟體開發過程中概要設計過程和內容。根據需求分析的結果，建立概要設計模型，構建系統業務和模組 或者類 之間...