鑑於軟體測試在面試階段總是提及軟體開發模型的緣故,於是粗略的總結一下軟體開發模型,請指正!
瀑布模型將軟體生命週期的各項活動規定為依固定順序聯接的若干階段工作，形如瀑布流水，最終得到軟體產品。
優點：
a.強調開發的階段性；
b.強調早期計畫及需求調查；
c.強調產品測試。
缺點：
a.依賴於早期進行的唯一一次需求調查，不能適應需求的變化；
b.由於是單一流程，開發中的經驗教訓不能反饋應用於本產品的過程；
c.風險往往遲至後期的開發階段才顯露，因而失去及早糾正的機會。
演化模型主要針對事先不能完整定義需求的軟體開發。使用者可以給出待開發系統的核心需求，並且當看到核心需求實現後，能夠有效地提出反饋，以支援系統的最終設計和實現。軟體開發人員根據使用者的需求，首先開發核心系統。當該核心系統投入執行後，使用者試用之，完成他們的工作，並提出精化系統、增強系統能力的需求。軟體開發人員根據使用者的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、測試、整合等階段組成，為整個系統增加乙個可定義的、可管理的子集。
在開發模式上採取分批迴圈開發的辦法，每迴圈開發一部分的功能，它們成為這個產品的原型的新增功能。於是，設計就不斷地演化出新的系統。 實際上，這個模型可看作是重複執行的多個「瀑布模型」。
「演化模型」要求開發人員有能力把專案的產品需求分解為不同組，以便分批迴圈開發。這種分組並不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有經驗指出，每個開發迴圈以六周到八周為適當的長度。
螺旋模型基本的做法是在「瀑布模型」的每乙個開發階段之前，引入非常嚴格的風險識別、風險分析和風險控制。直到採取了消除風險的措施之後，才開始計畫下一階段的開發工作。否則，專案就很可能被取消。
另外，如果有充足的把握判斷遺留的風險已降低到一定的程度，專案管理人員可作出決定讓餘下的開發工作採用另外的生命週期模型，如「演化模型」，「瀑布模型」，或自定的混合模型。
優點：a.強調嚴格的全過程風險管理。
b.強調各開發階段的質量。
c.提供機會檢討專案是否有價值繼續下去。
缺點：a.引入非常嚴格的風險識別，風險分析，和風險控制，這對風險管理的技能水平提出了很高的要求。這需要人員，資金，和時間的投入。
螺旋模型是瀑布模型與演化模型相結合，並加入兩者所忽略的風險分析所建立的一種軟體開發模型。該模型於2023年由美國trw公司（b.w.boehm）提出。軟體專案風險的大小作為指引軟體過程的乙個重要因素，引入這一概念有可能使得軟體開發被看作一種元模型，因為它能包容任何乙個開發過程模型。
快速原型是指
在進行了基本需求分析之後，快速開發出產品的原型，然後基於這個原型，同客戶溝通、交流，更好地了解客戶需求，不斷修改這個原型，到了雙方認可的程度，再做詳細地分析、設計和程式設計，最終開發出令客戶滿意的產品。
一般步驟如下：
–(1) 先定義軟體的總體目標，根據已知的需求來規劃出可實現的區域。
–(2) 然後是「快速設計」，集中於系統的總體框架、基本功能和直觀的輸入方式和輸出格式等。
–(3) 有了原型，使客戶對系統實現哪些具體功能、功能實現到什麼程度有更好的理解。開發者可以邊開發邊評估，不斷細化軟體的需求，逐步調整原型使其滿足客戶的要求。這形成乙個迭代的過程。
即使開始建立的原型過於簡單或效能很差，難以使用，但為下一次建立適用的模型積累了經驗，而浪費的成本、時間有限。
原型模型的優點是使使用者能夠感受到實際的系統，使開發者能夠快速地構造出系統的框架。
原型模型的缺點是產品的先天性不足，因為開發者常常需要做實現上的折中，可能採用不合適的作業系統或程式語言，以使原型能夠盡快工作。
rad模型還有一種改進型，將「編碼」從v字型的頂點移到左側，和單元測試對應，從而構成水平的對應關係。
從水平對應關係看
左邊是設計和分析，右邊是驗證和測試。右邊是對左邊結果的檢驗，即對設計和分析的結果進行測試，以確認是否滿足使用者的需求。如：
需求分析和功能設計對應驗收測試，說明在做需求分析、產品功能設計的同時，測試人員就可以閱讀、審查需求分析的結果，從而了解產品的設計特性、使用者的真正需求，可以準備用例（use case）。
當系統設計人員在做系統設計時，測試人員可以了解系統是如何實現的，基於什麼樣的平台，這樣可以事先準備系統的測試環境，包括硬體和第三方軟體的採購。因為這些準備工作，實際上要很長時間才能完成。
在做詳細設計時，測試人員就可以準備測試用例（test case，以有效地發現軟體缺陷的最小測試執行單元）。
一面程式設計，一面進行單元測試，是一種很有效的辦法，使我們可以盡快找出程式中的錯誤。充分的單元測試可以大幅度提高程式質量、減少成本。
從圖可以看出，rad模型避免了瀑布模型所帶來的誤區——軟體測試是在**完成之後進行。rad模型說明軟體測試的工作很早就可以開始了，專案一啟動，軟體測試的工作也就啟動了。
從垂直方向看
水平虛線上部表明，其需求分析、功能設計和驗收測試等主要工作是面向使用者，要和使用者進行充分的溝通和交流，或者是和使用者一起完成。水平虛線下部的大部分工作，相對來說，都是技術工作，在開發組織內部進行，由工程師完成。
所以rad模型一般適合資訊系統應用軟體的開發，而不適合高效能、技術風險高或不易模組化的系統開發。如果乙個系統難以被適當地模組化，那麼就很難建立rad所需的構件；如果系統具有高效能的指標，且該指標必須通過調整介面使其適應系統構件才能達到，使用rad方法可能會導致整個專案失敗。
軟體開發模型
軟體開發模型 software development model 是指軟體開發全部過程 活動和任務的結構框架。軟體開發包括需求 設計 編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰 直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體專案工作的基礎。對於不同的軟體系統...
軟體開發模型
前提 在介紹軟體開發模型之前，要說一下軟體的生命週期，如同人的一生一樣，要經過嬰兒期，兒童期，少年期，青年期，老年期直到衰老死亡的過程。同樣，乙個軟體產品也要經過計畫，分析，設計，程式設計，測試和維護直到被淘汰的過程，軟體的這一過程稱為軟體生命週期。定義 軟體開發模型 software develo...
軟體開發模型
常見的軟體開發模型有瀑布模型 演化模型 螺旋模型 噴泉模型。1.瀑布模型 wate ll model 將軟體生命週期劃分為需求分析 軟體設計 程式編寫 軟體測試和執行維護等基本活動，並且規定了它們自上而下 相互銜接的固定次序，如同瀑布流水，逐級下落。不適應使用者需求的變化，開發模型是線性的，使用者只...