簡介
相信很多人在編寫程式時，都是偏向邊做邊修改的模式去進行撰寫，而非是先撰寫初一整個程式的架構再去進行編程，這樣的其況下或許速度很快，但是當你需要測試時，總在你全部編輯完畢時，才開始測試，這樣的話，當你遇到bug時，你總需要重頭開始檢查或是全部刪掉重新撰寫，這樣的話你必須花費更多的時間，來完成你的程式，在這時間當中你必須持續地修改，所以這是一項很累人並且重複性過高的編成行為。
以下整理初三點此種沒有思考就編成的壞處：
- 沒有經過設計，程式架構並不完善
- 忽略未來添增模塊時的可填充性
- 不容易維護
而接下來就來對各種叫常見模型進行介紹
瀑布模型
瀑布模型得核心架構是為了讓在編成的時候更加的簡化，畫繁為簡，將功能與設計分開，便於分工協調工作。也就是將所謂的編成與美編等等團隊分開，如同瀑布一樣，一個接著一個的去進行，所以在當前一項目未完成時，下一個項目負責人將無法開始進行活動
活動流程
他的製作流程分為六個基本活動:
- 製定計劃
- 需求分析
- 軟體設計
- 程序編寫
- 程式測試
- 運行維護
優點：
- 可在各階段設定一結束日期與檢查點
- 當前一階段完成後即不須理會，只須處理下一個階段任務
缺點：
- 各個階段的劃分完全固定，階段之間產生大量的檔案，增加了工作量；
- 由於開發模型是線性的，用戶只有等到整個過程的末期才能看到開發成果，從而增加了開發的風險
- 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。
- 各個軟件生命週期銜接花費時間較長，團隊人員交流成本大。
- 瀑布式方法在需求不明確且在項目進行過程中可能變化的情況下基本是不可行的。
迭代模型
迭代模型簡單來說，就是一個版本一個版本的分開來，一次次的進行更新，新增程式碼，也可以看成是小型的瀑布模型，每一個小項目（小版本）都包含了完整的過程，以下將介紹他的活動方式
活動流程
- 第一次迭代：
1. 需求分析
2. 設計
3. 實現
4. 測試 - 第二次迭代：
1. 需求分析
2. 設計
3. 實現
4. 測試 - 第三次迭代：
1. 需求分析
2. 設計
3. 實現
4. 測試
從這邊來看可以更仔細的發現，在每次迭代中都含了一個完整的開發流程，這也使得迭代較瀑布多了幾個優點
使用時機
- 在項目開發早期需求可能有所變化。
- 分析設計人員對應用領域很熟悉。
- 高風險項目。
- 用戶可不同程度地參與整個項目的開發過程。
- 使用面向對象的語言或統一建模語言（Unified Modeling Language，UML）。
- 使用CASE（Computer Aided Software Engineering，計算機輔助軟件工程）工具，如Rose（Rose是非常受歡迎的物件軟體開發工具。）。
- 具有高素質的項目管理者和軟件研發團隊。
優點：
- 降低程式重複開發、市場性、時間等風險
- 在程式早期即可得到用戶反饋
- 持續的測試減少累積到一定量時，一次爆發的可能性
- 更加容易的去進行更改與增加可用性與彈性
敏捷開發模型
基本上敏捷開發可以看成是一種，注重人與人之間溝通的一種規劃模式，故他在於文本與版本的交替是十分平常的，它非常適合緊湊型的團隊進行使用，下面將統整優點。
開發流程
作為一個整體工作；按短迭代周期工作；每次迭代交付一些成果；關注業務優先級；檢查與調整。
優點
- 人與人之間的溝通重於過程和工具，以來減少程式連接時得錯誤發生。
- 客戶協作重於合同談判，以來減少與客戶間的摩擦。
- 可以更加容易的去隨時應對變化。
快速原形模型
快速原形顧名思義就是要快速，用最快速的方式先做出一個原形來讓客戶參考，在依照客戶的要求去更改內容，直到滿足客戶要求。由此來看快速原形模型基本定理便是去了解客戶到底要什麼，在去進行開發程式。
所以快速原形模型在製作原形的時候，並不要求程式架構框架是否可以持續的去更新等等，而是在於能快速的去達到客戶的要求，在第二次確定客戶需求時，才會在寫程式時，不須考慮其他位在因素，只須將程式與其架構撰寫完成即可。
這便是一種邊做邊改與瀑布模型的整合，既可以減少瀑布模型帶來的不可預測性，又可以有邏輯性系統性的去撰寫程式。
增量模型
增量模型就像是蓋房子，一層一層的疊起來，每次撰寫程式都會去依照一系列的設計、實現、集成、測試，來完成程式，每一個結構都是由多種的模塊相互作用所形成的特定功能而構成。
增量模型在將程式提交給客戶時，提供一個完整的系統，而是只提供一個其中的一個功能，讓客戶可以去笑對這功能是否滿足需求，這樣做的好處是，程式在開發時，可以更加的因地制宜，從而降低了開發的風險
優點
- 因地制宜，降低風險
缺點
- 由於他是一個一個模塊進行編成，所以在將新模塊與舊模塊合併時，必須不能破壞到舊有的模塊，這也就代表程式必須具有開放式架構
- 在開發的過程中，需求的變化是不可免俗的，增量模型的靈活性，可以應變這個問題沒錯，但是當程式失去了整體性時，便會退化回去邊做邊改的情況
使用時機
而在使用增量模型時，往往將第一個模塊的目的便是整個程式中的核心項目，在將核心項目完成並交付給客戶之後，再去完成下一個增量（模塊）的開發，最終完成一系列的產品
螺旋模型
介紹
螺旋模型是由瀑布模型與快速模型所結合而來，他將風險分析特別拿出來進行強調，因此他也特別適合用來大型複雜系統中進行開發。
螺旋模型在編寫程式時，不一定需要將所有事情都了解的明明白白，只需要知道最重要的功能即可，然後我們的目標便是先將它給完成，聽取客戶意見 -> 修改，然後開始進入下一個階段，接下就是不段的去循環上面的步驟，直到最終成品產生。
螺旋模型最重要的便是去評估風險，因為在每個階段執行之前，都必須進行風險評估。
流程
- 制定計劃：確定程式目標，選定開發方案，弄清處項目開發的限制條件；
- 風險分析：分析評估所選方案，考慮如何發現和消除風險；
- 實施工程：實施程式開發和驗證；
- 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。
限制條件
- 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟件開發。
- 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟件項目。
- 軟件開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險
演化模型
主要是用於不可明確了解需求定義的程式開發時使用，客戶只需先給出一個核心需求即可，程式員必須先依照目前得核心要求開發出核心之後，將他投入運行當中，客戶使用之後會給出反饋，在依照反饋去進行開發，一代接著一代的去演化進化，慢慢的去進行精進系統。
而每次的更新進化都是一次的迭代，一次的迭代過程，而這一次迭代目的是為了增加系統的可定義性與可管理性:
- 需求
- 設計
- 編碼
- 測試
- 集成
然而這一次次的迭代過程也可看成是重複去執行瀑布模型，開發人員在開發時，必須先將項目需求給分成多個組，以便可以分批循環開發，而分組必須依照功能的重要性與總體設計結構去進行判斷，有經驗指出，每個開發循環以六到八周為最恰當的時間長度。
混合模型
簡單來說，就是將不同模型組合在一起，這便叫做混合模型，它允許一個項目在開發的時候，能夠沿著最有效的方式去發展，這便是混合模型的意義。
V-模型
介紹
V-模型的誕生是為了改良瀑布模型，因瀑布模型的不可回頭性，使得許多問題再求才會發現，這常常造成許多的問題。而V-模型則是開發與測試同時進行，這使bug與error能及時解除，不會在後期才發現。以此來看v-模型是一個平行parallel運算的一種模式。
而根據維基V模型可分為三大類：
- 德國的Das V-Modell
- 泛用的測試模式
- 美國政府標準
開發
v-模型 共分成三個階段，分別為生存期、分配模型、功能性工具
- 生存期:
What has to be done?
需求
產生結果 - 分配模型
How is it be done
方法 - 功能性工具
What is used to do it
工具
而在實作上又分成四個模塊進行操作，項目管理模塊(PM)，系統開發模塊(SD)，品質保證模塊(QA)，配置管理模塊(CM)
測試
- 單元測試
主要發現程式和詳細設計階段時的錯誤，測試計劃在詳細設計階段製定，在程式階段後完成 - 集成測試
主要發現設計階段時所產生的錯誤，測試計劃在概要設計階段製定，在詳細設計階段完成 - 確認測試
計劃在需求分析階段製定，在概要設計階段完成。
