閱讀這個書所需的知識基礎應該超越了之前的任何一本書，目前很難領會精髓，只能先寫一點感想了：
首先，實際軟件開發中有很多變數，開發者會犯錯，環境也會改變，客戶也可能犯錯，因此就有各種各樣的模型用以減小變數帶來的損失。
1.首先是進化樹模型，它等價與增量-迭代模型，可以理解爲最終結果是由不斷添加組件所組成的（增量），而每次添加組件的過程中需要不斷優化，更新組件（迭代）。每個增量與迭代都擁有屬於自己的測試，設計，實現等階段，而每次迭代過程不必擁有每個階段，但一定擁有其中的一部分。
目前我認爲適用性最強的就是增量-迭代模型，這個模型可以將錯誤細化到最小的迭代過程中，從而限制其造成的危害。而增量-迭代模型也非常符合我們面向對象的編程思想，其中每個增量都是一個對象，擁有其對外的接口，增量內部的迭代或錯誤對外部的影響是較小的。
2.瀑布模型：瀑布模型具有非常多的成功案例，其方法內核已經非常穩定，同時由文檔驅動也賦予了其一定的嚴謹性。
但有一個非常致命的問題：瀑布模型的客戶在最初可能收到一份根本看不懂的專業文檔，而一般情況下客戶會同意這個不一定合乎自己需求的開發，從而導致最終結果偏離用戶目標（這就是非常大的損失了）。
3.快速原型生命週期模型：這個模型的使用者會先開發一個小的demo，使開發團隊摸清需求，同時也可以讓用戶評估方向是否偏離需要，這樣一來就大大減少了最終產品偏離需求的可能。但其實快速原型生命週期模型中存在這與敏捷過程相同的問題，即如果一個缺乏經驗的團隊面對一個大的項目，能夠開發一個demo並不意味着可以勝任整個項目
4.開源生命週期模型：其實書中有一句話非常好：任何開源項目最終都會趨於不可維護。這其實說明了開源項目的成功是不可複製的，因此在面向客戶需求時這種模型顯然時不穩妥的。
5.敏捷過程：這應該是一個非常大膽的嘗試，他的內核可能不在於對開發流程的規劃，而在於強調開發組成員間的配合，這種方法強調時間，即期限到來時必須交付給用戶一個版本。這樣做有很多好處：用戶不會在期限到來前隨意修改計劃（期限一般比較短），用戶可以有更多的時間適應產品，開發組可以快速響應用戶需求。但是就如書中所說，這種方法還過於年輕，目前無法考察其有效性，而且有人認爲這種方式不能勝任較爲大型的開發。即便如此，敏捷過程中的一些思想或許還是可以爲我們所用。
6.同步穩定生命週期模型
這個沒看太明白它的特點，再加上比較短，直接上圖
7.螺旋生命週期模型：這是一種風險驅動模型，它的優勢很明顯，就是可以實時控制風險。但是問題在於不是所有風險都是可以預估，或者可以正確預估的，同時預估風險也會造成一些開銷，這對於小型開發顯然是不合理的。另一方面如果我們面向內部開發，那麼我們可以靈活控制風險，隨時暫停項目，但如果我們是面向客戶開發，暫停項目可能會帶來法律上的爭端。
最後貼上書中的對比：