首先，實際軟體開發中有很多變數，開發者會犯錯，環境也會改變，客戶也可能犯錯，因此就有各種各樣的模型用以減小變數帶來的損失。
1.首先是進化樹模型，它等價與增量-迭代模型，可以理解為最終結果是由不斷新增元件所組成的（增量），而每次新增元件的過程中需要不斷優化，更新元件（迭代）。每個增量與迭代都擁有屬於自己的測試，設計，實現等階段，而每次迭代過程不必擁有每個階段，但一定擁有其中的一部分。
目前我認為適用性最強的就是增量-迭代模型，這個模型可以將錯誤細化到最小的迭代過程中，從而限制其造成的危害。而增量-迭代模型也非常符合我們物件導向的程式設計思想，其中每個增量都是乙個物件，擁有其對外的介面，增量內部的迭代或錯誤對外部的影響是較小的。
2.瀑布模型：瀑布模型具有非常多的成功案例，其方法核心已經非常穩定，同時由文件驅動也賦予了其一定的嚴謹性。
但有乙個非常致命的問題：瀑布模型的客戶在最初可能收到乙份根本看不懂的專業文件，而一般情況下客戶會同意這個不一定合乎自己需求的開發，從而導致最終結果偏離使用者目標（這就是非常大的損失了）。
3.快速原型生命週期模型：這個模型的使用者會先開發乙個小的demo，使開發團隊摸清需求，同時也可以讓使用者評估方向是否偏離需要，這樣一來就大大減少了最終產品偏離需求的可能。但其實快速原型生命週期模型中存在這與敏捷過程相同的問題，即如果乙個缺乏經驗的團隊面對乙個大的專案，能夠開發乙個demo並不意味著可以勝任整個專案
4.開源生命週期模型：其實書中有一句話非常好：任何開源專案最終都會趨於不可維護。這其實說明了開源專案的成功是不可複製的，因此在面向客戶需求時這種模型顯然時不穩妥的。
5.敏捷過程：這應該是乙個非常大膽的嘗試，他的核心可能不在於對開發流程的規劃，而在於強調開發組成員間的配合，這種方法強調時間，即期限到來時必須交付給使用者乙個版本。這樣做有很多好處：使用者不會在期限到來前隨意修改計畫（期限一般比較短），使用者可以有更多的時間適應產品，開發組可以快速響應使用者需求。但是就如書中所說，這種方法還過於年輕，目前無法考察其有效性，而且有人認為這種方式不能勝任較為大型的開發。即便如此，敏捷過程中的一些思想或許還是可以為我們所用。
6.同步穩定生命週期模型
這個沒看太明白它的特點，再加上比較短，直接上圖
7.螺旋生命週期模型：這是一種風險驅動模型，它的優勢很明顯，就是可以實時控制風險。但是問題在於不是所有風險都是可以預估，或者可以正確預估的，同時預估風險也會造成一些開銷，這對於小型開發顯然是不合理的。另一方面如果我們面向內部開發，那麼我們可以靈活控制風險，隨時暫停專案，但如果我們是面向客戶開發，暫停專案可能會帶來法律上的爭端。
最後貼上書中的對比：
軟體工程 第二章
2.1 問題定義 軟體生命週期的計畫階段 問題定義，可行性研究，需求分析三個階段。2.2 可行性研究 2.2.1可行性研究的任務 可行性研究的根本目的並不是解決問題，而是確定問題是否值得去解決，也就是判斷系統原定的目標和規模是否能實現，軟體使用所能帶來的效益是否值得使用者去投資開發。因此，可行性研究...
軟體工程第二章作業
1.在軟體開發的早期階段為什麼要進行可行性研究？應該從哪些方面研究目標系統的可行性？答 因為我們需要在軟體開發前確定其是否具有價值，乙個沒有價值的軟體開發出來也沒有意義 五個方面 技術可行性 經濟可行性 操作可行性 執行可行性 法律可行性 2.為方便儲戶，某銀行擬開發計算機儲蓄系統。儲戶填寫的存款單...
軟體工程複習 第二章
第二章 可行性分析 1 定義 用最小的代價在盡可能短的時間內確定問題是否能解決 不是解決問題，而是確定問題是否值得去解決 主要包括四個方面 技術可行性 經濟可行性 操作可行性 法律 社會效益可行性 2 基本過程 複查系統規模和目標 研究目前正在使用的系統 匯出新系統的高層邏輯模型 進一步定義問題 匯...