總結一下經常可以見到的系統開發週期模型。
在過去的幾年裏，可以很奇葩的碰到類似於“創業項目庫”這種需求非常明確，工作量十分可控，對質量要求比較低，業務建模比較easy，功能構成比較少的“面子項目”。類似於這種項目，採用傳統意義上的瀑布模型就非常合適了，如果範圍控制和風險控制做的比較好的話，真的如同一個瀑布一樣，會“飛流直下三千尺”，直接將項目送到客戶的小機上，部署運行，大家歡樂的拿到績效獎金，回家happy去了。
但是僅僅注重“面子”的項目很難碰到幾次，另一方面，即便是“面子型”的項目，也應當極其重視質量環節。項目管理的幾個要素：質量，成本，時間，範圍。質量是項目最重要的一環，如果喪失了質量，可以說項目產品就變成了無根之樹，空中樓閣。所以，加強質量的把控是非常重要的，也需要對每一個階段進行質量方面的控制，因此，V模型就是這樣一種將開發過程與驗證過程想對應的一種對稱型的結構。
在項目實踐中，用戶的需求總是隨着項目進展而更加明確，控制用戶的需求變得非常的重要。爲了讓用戶能在項目的起始階段就深入的對自己的需求有一個明確的理解，原型就變得非常的重要，我們經常在開發中看到的LOW-FI的頁面原型、其他類似項目的DEMO就算這種類型，用戶對將來的產品有了直觀的瞭解。建立在這種基礎上的分析開發，會減少很多後面流程中可能出現的風險。在瀑布模型以及V模型當中，在需求分析階段採用原型化，是目前非常有效甚至是必須要採用的手段。
現在的軟件項目越來越大，同項目可能由相互聯繫的若干個子系統構成的，這樣僅憑開發一個模型或者多個模型是滿足不了項目對於多方面的要求，於是就衍生出了螺旋模型，螺旋模型適合於大型的軟件的原因是，它更加註重風險的控制，強調風險的識別、風險的分析、以及風險的消除。
工作的後幾年裏，經常會按照Sprint（衝刺短跑）爲週期的進行開發。這種敏捷的方式，是屬於迭代式開發的一種實現。所謂迭代式模型就是在項目的每一個小的階段中，都會執行一個傳統的、完整的串行過程，執行一次就是一次迭代，每次迭代都可能會包含需求分析、設計、編碼、測試等其中的全部或者部分活動。
這樣就對軟件的四種開發模型有了簡單的瞭解：瀑布模型，V模型，原型化模型、螺旋模型、迭代模型。
下面對幾個開發模型，結合理論逐一分析。
1.迭代模型
迭代模型，摒棄了傳統的需求分析，設計，編碼，測試的流程，而是將整個生命週期變成若干個衝刺（Sprint）階段，而每一個階段都是由以上若干或者全部傳統的流程組成，在每一個階段中，都會包含下面四個階段：初始階段，細化階段，構建階段，交付階段。在初始階段中，確認本次衝刺的範圍，邊界，系統選擇的架構，計劃，以及所需要的資源等信息。在細化階段中，對問題進行建域，創建開發案例，創建模板以及準備工具等。在構建階段的主要任務就是完成構建的開發並且進行測試，將完成的構建集成爲產品，並且測試所有的功能（CI）。在交付階段，主要是完成本次衝刺，將軟件產品交付給相關的干係人。
2.螺旋模型
螺旋模型，尤其重視風險分析階段，特別適用於龐大並且複雜，非常高風險的項目。通常螺旋模型由四個階段組成：制定計劃、風險分析、實施工程和客戶評估。螺旋模型中，發佈的第一個模型甚至可能是沒有任何產出的，可能僅僅是紙上談兵的一個目標，但是隨着一次次的交付，每一個版本都會朝着固定的目標邁進，最終得到一個更加完善的版本。
3.原型化模型
原型化模型第一步就是創建一個快速原型，能夠滿足項目干係人與未來的用戶可以與原型進行交互，再通過與相關干係人進行充分的討論和分析，最終弄清楚當前系統的需求，進行了充分的瞭解之後，在原型的基礎上開發出用戶滿意的產品。在實際的項目過程中，藉助於組織過程資產以及快速模型軟件，一般在需求分析的時候，就可以建立一些簡單的原型，例如在第一家YH公司中，因爲是“行業軟件提供商”，所以擁有各個地域的行業解決軟件方案，慣用的伎倆就是將其他地市的項目拿到本次項目實施地，作爲原型化模型。原型化模型是極具意義的項目實踐。
4.V模型
V模型從整體上看起來，就是一個V字型的結構，由左右兩邊組成。左邊的下劃線分別代表了需求分析、概要設計、詳細設計、編碼。右邊的上劃線代表了單元測試、集成測試、系統測試與驗收測試。看起來V模型就是一個對稱的結構，它的重要意義在於，非常明確的表明了測試過程中存在的不同的級別，並且非常清晰的描述了這些測試階段和開發階段的對應關係。
5.瀑布模型
瀑布模型是一個特別經典，甚至有點老套的週期模型，一般情況下將其分爲計劃、需求分析、概要設計、詳細設計、編碼以及單元測試、測試、運行維護等幾個階段。瀑布模型的週期是環環相扣的。每個週期中交互點都是一個里程碑，上一個週期的結束需要輸出本次活動的工作結果，本次的活動的工作結果將會作爲下一個週期的輸入。這樣，當某一個階段出現了不可控的問題的時候，就會導致返工，返回到上一個階段，甚至會延遲下一個階段。
在過去的幾年裏，可以很奇葩的碰到類似於“創業項目庫”這種需求非常明確，工作量十分可控，對質量要求比較低，業務建模比較easy，功能構成比較少的“面子項目”。類似於這種項目，採用傳統意義上的瀑布模型就非常合適了，如果範圍控制和風險控制做的比較好的話，真的如同一個瀑布一樣，會“飛流直下三千尺”，直接將項目送到客戶的小機上，部署運行，大家歡樂的拿到績效獎金，回家happy去了。
但是僅僅注重“面子”的項目很難碰到幾次，另一方面，即便是“面子型”的項目，也應當極其重視質量環節。項目管理的幾個要素：質量，成本，時間，範圍。質量是項目最重要的一環，如果喪失了質量，可以說項目產品就變成了無根之樹，空中樓閣。所以，加強質量的把控是非常重要的，也需要對每一個階段進行質量方面的控制，因此，V模型就是這樣一種將開發過程與驗證過程想對應的一種對稱型的結構。
在項目實踐中，用戶的需求總是隨着項目進展而更加明確，控制用戶的需求變得非常的重要。爲了讓用戶能在項目的起始階段就深入的對自己的需求有一個明確的理解，原型就變得非常的重要，我們經常在開發中看到的LOW-FI的頁面原型、其他類似項目的DEMO就算這種類型，用戶對將來的產品有了直觀的瞭解。建立在這種基礎上的分析開發，會減少很多後面流程中可能出現的風險。在瀑布模型以及V模型當中，在需求分析階段採用原型化，是目前非常有效甚至是必須要採用的手段。
現在的軟件項目越來越大，同項目可能由相互聯繫的若干個子系統構成的，這樣僅憑開發一個模型或者多個模型是滿足不了項目對於多方面的要求，於是就衍生出了螺旋模型，螺旋模型適合於大型的軟件的原因是，它更加註重風險的控制，強調風險的識別、風險的分析、以及風險的消除。
工作的後幾年裏，經常會按照Sprint（衝刺短跑）爲週期的進行開發。這種敏捷的方式，是屬於迭代式開發的一種實現。所謂迭代式模型就是在項目的每一個小的階段中，都會執行一個傳統的、完整的串行過程，執行一次就是一次迭代，每次迭代都可能會包含需求分析、設計、編碼、測試等其中的全部或者部分活動。
這樣就對軟件的四種開發模型有了簡單的瞭解：瀑布模型，V模型，原型化模型、螺旋模型、迭代模型。
下面對幾個開發模型，結合理論逐一分析。
1.迭代模型
迭代模型，摒棄了傳統的需求分析，設計，編碼，測試的流程，而是將整個生命週期變成若干個衝刺（Sprint）階段，而每一個階段都是由以上若干或者全部傳統的流程組成，在每一個階段中，都會包含下面四個階段：初始階段，細化階段，構建階段，交付階段。在初始階段中，確認本次衝刺的範圍，邊界，系統選擇的架構，計劃，以及所需要的資源等信息。在細化階段中，對問題進行建域，創建開發案例，創建模板以及準備工具等。在構建階段的主要任務就是完成構建的開發並且進行測試，將完成的構建集成爲產品，並且測試所有的功能（CI）。在交付階段，主要是完成本次衝刺，將軟件產品交付給相關的干係人。
2.螺旋模型
螺旋模型，尤其重視風險分析階段，特別適用於龐大並且複雜，非常高風險的項目。通常螺旋模型由四個階段組成：制定計劃、風險分析、實施工程和客戶評估。螺旋模型中，發佈的第一個模型甚至可能是沒有任何產出的，可能僅僅是紙上談兵的一個目標，但是隨着一次次的交付，每一個版本都會朝着固定的目標邁進，最終得到一個更加完善的版本。
3.原型化模型
原型化模型第一步就是創建一個快速原型，能夠滿足項目干係人與未來的用戶可以與原型進行交互，再通過與相關干係人進行充分的討論和分析，最終弄清楚當前系統的需求，進行了充分的瞭解之後，在原型的基礎上開發出用戶滿意的產品。在實際的項目過程中，藉助於組織過程資產以及快速模型軟件，一般在需求分析的時候，就可以建立一些簡單的原型，例如在第一家YH公司中，因爲是“行業軟件提供商”，所以擁有各個地域的行業解決軟件方案，慣用的伎倆就是將其他地市的項目拿到本次項目實施地，作爲原型化模型。原型化模型是極具意義的項目實踐。
4.V模型
V模型從整體上看起來，就是一個V字型的結構，由左右兩邊組成。左邊的下劃線分別代表了需求分析、概要設計、詳細設計、編碼。右邊的上劃線代表了單元測試、集成測試、系統測試與驗收測試。看起來V模型就是一個對稱的結構，它的重要意義在於，非常明確的表明了測試過程中存在的不同的級別，並且非常清晰的描述了這些測試階段和開發階段的對應關係。
5.瀑布模型
瀑布模型是一個特別經典，甚至有點老套的週期模型，一般情況下將其分爲計劃、需求分析、概要設計、詳細設計、編碼以及單元測試、測試、運行維護等幾個階段。瀑布模型的週期是環環相扣的。每個週期中交互點都是一個里程碑，上一個週期的結束需要輸出本次活動的工作結果，本次的活動的工作結果將會作爲下一個週期的輸入。這樣，當某一個階段出現了不可控的問題的時候，就會導致返工，返回到上一個階段，甚至會延遲下一個階段。
