SDLC 快速指南

SDLC - 概述

軟體開發生命週期 (SDLC) 是軟體行業用來設計、開發和測試高質量軟體的過程。SDLC 的目標是產出滿足或超過客戶期望、在時間和成本估算範圍內完成的高質量軟體。

SDLC 是軟體開發生命週期 (Software Development Life Cycle) 的縮寫。
它也稱為軟體開發過程。
SDLC 是一個框架，它定義了在軟體開發過程中每個步驟中執行的任務。
ISO/IEC 12207 是軟體生命週期過程的國際標準。其目標是成為定義開發和維護軟體所需所有任務的標準。

什麼是 SDLC？

SDLC 是軟體組織內軟體專案遵循的過程。它包含一個詳細的計劃，描述如何開發、維護、替換和更改或增強特定軟體。生命週期定義了一種改進軟體質量和整體開發過程的方法。

下圖是典型 SDLC 各個階段的圖形表示。

典型的軟體開發生命週期包括以下階段：

階段 1：規劃和需求分析

需求分析是 SDLC 中最重要和最基礎的階段。它由團隊高階成員執行，並參考客戶意見、銷售部門資訊、市場調查以及行業領域專家的意見。然後，這些資訊將用於規劃基本專案方法，並在經濟、運營和技術領域進行產品可行性研究。

規劃質量保證要求以及識別與專案相關的風險也在規劃階段進行。技術可行性研究的結果是定義可以遵循的各種技術方法，以成功實施專案並最大限度地降低風險。

階段 2：定義需求

完成需求分析後，下一步是明確定義和記錄產品需求，並獲得客戶或市場分析師的批准。這透過一份**SRS（軟體需求規格說明書）**文件完成，其中包含專案生命週期中需要設計和開發的所有產品需求。

階段 3：設計產品架構

SRS 是產品架構師提出最佳產品架構的參考。根據 SRS 中指定的需求，通常會提出並記錄在 DDS（設計文件規範）中多個產品架構設計方案。

此 DDS 將由所有重要的利益相關者進行審查，並基於風險評估、產品穩健性、設計模組化、預算和時間限制等各種引數，選擇最佳的產品設計方案。

設計方案明確定義了產品的全部架構模組，以及其與外部和第三方模組（如有）的通訊和資料流表示。DDS 中應明確定義所提出架構的所有模組的內部設計，直至最細微的細節。

階段 4：構建或開發產品

在這個 SDLC 階段，實際開發開始，產品被構建。在此階段根據 DDS 生成程式程式碼。如果設計工作細緻而有條理，則程式碼生成可以順利完成。

開發人員必須遵循其組織定義的編碼準則，並使用編譯器、直譯器、偵錯程式等程式設計工具來生成程式碼。C、C++、Pascal、Java 和 PHP 等不同的高階程式語言用於編碼。程式語言的選擇取決於正在開發的軟體型別。

階段 5：測試產品

此階段通常是所有階段的子集，因為在現代 SDLC 模型中，測試活動主要涉及 SDLC 的所有階段。但是，此階段僅指產品的測試階段，在此階段，產品缺陷會被報告、跟蹤、修復和重新測試，直到產品達到 SRS 中定義的質量標準。

階段 6：市場部署和維護

產品經過測試並準備部署後，它將正式釋出到相應的市場。有時，根據組織的業務戰略，產品部署會分階段進行。產品可能首先在有限的細分市場中釋出，並在真實的業務環境中進行測試（UAT-使用者驗收測試）。

然後，根據反饋，產品可能會按原樣釋出，或者在目標市場細分市場中釋出帶有建議的增強功能。產品釋出到市場後，將為現有客戶群進行維護。

SDLC 模型

已定義和設計了各種軟體開發生命週期模型，這些模型在軟體開發過程中被遵循。這些模型也稱為“軟體開發過程模型”。每個過程模型都遵循一系列與其型別獨有的步驟，以確保軟體開發過程的成功。

以下是業界最常用和最流行的 SDLC 模型：

瀑布模型
迭代模型
螺旋模型
V 模型
大爆炸模型

其他相關方法包括敏捷模型、RAD 模型、快速應用開發和原型模型。

SDLC - 瀑布模型

瀑布模型是第一個引入的過程模型。它也稱為**線性順序生命週期模型**。它非常易於理解和使用。在瀑布模型中，必須完成每個階段才能開始下一個階段，階段之間沒有重疊。

瀑布模型是最早用於軟體開發的 SDLC 方法。

瀑布模型以線性順序流的方式說明了軟體開發過程。這意味著開發過程中的任何階段只有在上一階段完成之後才能開始。在這個瀑布模型中，階段不重疊。

瀑布模型 - 設計

瀑布方法是第一個廣泛應用於軟體工程的 SDLC 模型，以確保專案的成功。“瀑布”方法將整個軟體開發過程劃分為單獨的階段。在這個瀑布模型中，通常，一個階段的結果作為下一個階段的輸入，依次進行。

下圖顯示了瀑布模型的不同階段。

瀑布模型中的順序階段是：

**需求收集和分析** - 此階段捕獲要開發的系統的所有可能需求，並將其記錄在需求規格說明書中。
**系統設計** - 此階段研究第一階段的需求規格，並準備系統設計。此係統設計有助於指定硬體和系統要求，並有助於定義整體系統架構。
**實現** - 使用系統設計中的輸入，系統首先在稱為單元的小程式中開發，這些單元在下一階段整合。每個單元都經過其功能的測試，這稱為單元測試。
**整合和測試** - 實現階段中開發的所有單元在每個單元測試後集成到一個系統中。整合後，將對整個系統進行故障和錯誤測試。
**系統部署** - 完成功能和非功能測試後，產品將部署到客戶環境或釋出到市場。
**維護** - 客戶環境中出現了一些問題。為了解決這些問題，會發布補丁。為了增強產品，還會發布更好的版本。維護是為了在客戶環境中交付這些更改。

所有這些階段都相互級聯，其中進度被視為穩定地向下流動（像瀑布一樣）穿過各個階段。只有在實現上一階段的既定目標並簽字後，才會開始下一個階段，因此得名“瀑布模型”。在這個模型中，階段不重疊。

瀑布模型 - 應用

每個開發的軟體都是不同的，需要根據內部和外部因素選擇合適的 SDLC 方法。瀑布模型最適用的一些情況是：

需求記錄良好、清晰且固定。
產品定義穩定。
技術易於理解且不動態。
沒有模稜兩可的需求。
有充足的具有所需專業知識的資源來支援產品。
專案時間短。

瀑布模型 - 優點

瀑布開發的優點是可以進行部門劃分和控制。可以設定一個帶有每個開發階段截止日期的時間表，並且產品可以逐個透過開發過程模型階段。

開發從概念、設計、實現、測試、安裝、故障排除開始，最終到操作和維護。每個開發階段都嚴格按順序進行。

瀑布模型的一些主要優點如下：

簡單易懂且易於使用
由於模型的嚴格性，易於管理。每個階段都有具體的交付成果和審查流程。
階段一個接一個地處理和完成。
適用於需求非常明確的小型專案。
階段定義明確。
里程碑清晰。
易於安排任務。
流程和結果有據可查。

瀑布模型 - 缺點

瀑布模型的缺點是它不允許太多的反思或修改。一旦應用程式進入測試階段，就很難返回並更改在概念階段沒有很好記錄或考慮的內容。

瀑布模型的主要缺點如下：

在生命週期後期之前不會產生可工作的軟體。
高風險和高不確定性。
不適用於複雜的面向物件專案。
不適用於長期和持續的專案。
不適用於需求存在中等至高風險變化的專案。因此，此流程模型的風險和不確定性很高。
難以衡量各個階段的進度。
無法適應變化的需求。
在生命週期中調整範圍可能會終止專案。
整合是在最後階段“一次性”完成的，這無法儘早識別任何技術或業務瓶頸或挑戰。

SDLC - 迭代模型

在迭代模型中，迭代過程從軟體需求的小集合的簡單實現開始，並迭代地增強不斷發展的版本，直到完整的系統實現並準備好部署。

迭代生命週期模型不會嘗試從完整的需求規範開始。相反，開發從指定和實現軟體的一部分開始，然後對其進行審查以識別進一步的需求。然後重複此過程，在模型的每次迭代結束時生成新版本的軟體。

迭代模型 - 設計

迭代過程從軟體需求子集的簡單實現開始，並迭代地增強不斷發展的版本，直到實現完整的系統。在每次迭代中，都會進行設計修改並新增新的功能。此方法的基本思想是透過重複的迴圈（迭代）和一次較小的部分（增量）來開發系統。

下圖是迭代和增量模型的表示：

迭代和增量開發是迭代設計或迭代方法和增量構建模型的結合。“在軟體開發過程中，軟體開發週期的多個迭代可能同時進行。”此過程可以描述為“演化獲取”或“增量構建”方法。

在這個增量模型中，整個需求被分成多個構建。在每次迭代中，開發模組都會經歷需求、設計、實現和測試階段。模組的每個後續版本都會向之前的版本新增功能。該過程持續進行，直到根據需求準備好完整的系統。

成功使用迭代軟體開發生命週期的關鍵是對需求進行嚴格驗證，以及在模型的每個週期內根據這些需求驗證和測試每個版本的軟體。隨著軟體在連續週期中不斷發展，必須重複和擴充套件測試以驗證每個版本的軟體。

迭代模型 - 應用

與其他SDLC模型一樣，迭代和增量開發在軟體行業中也有一些具體的應用。此模型最常用於以下場景：

完整系統的需求已明確定義並理解。
必須定義主要需求；但是，某些功能或請求的增強功能可能會隨著時間的推移而發展。
存在上市時間限制。
正在使用一項新技術，並且開發團隊在專案中工作時正在學習該技術。
所需技能的資源不可用，並計劃在特定迭代中以合同形式使用。
有一些高風險的功能和目標，未來可能會發生變化。

迭代模型 - 優缺點

此模型的優點是在開發的非常早期階段就有一個可工作的系統模型，這使得更容易發現功能或設計缺陷。在開發的早期階段發現問題能夠在有限的預算內採取糾正措施。

此SDLC模型的缺點是它僅適用於大型和龐大的軟體開發專案。這是因為很難將小型軟體系統進一步分解成小的可服務增量/模組。

迭代和增量SDLC模型的優點如下：

可以在生命週期的早期快速開發一些可工作的功能。
儘早並定期獲得結果。
可以規劃並行開發。
可以衡量進度。
更改範圍/需求的成本更低。
在較小的迭代期間進行測試和除錯很容易。
在迭代期間識別和解決風險；並且每次迭代都是一個易於管理的里程碑。
更容易管理風險 - 首先完成高風險部分。
每次增量都會交付可執行的產品。
可以將從每個增量中識別出的問題、挑戰和風險用於/應用於下一個增量。
風險分析更好。
它支援更改需求。
初始執行時間較短。
更適合大型和關鍵任務專案。
在生命週期中，儘早生成軟體，這有助於客戶評估和反饋。

迭代和增量SDLC模型的缺點如下：

可能需要更多資源。
雖然更改成本較低，但不非常適合更改需求。
需要更多管理關注。
可能會出現系統架構或設計問題，因為並非所有需求都在整個生命週期的開始就收集。
定義增量可能需要定義完整的系統。
不適用於小型專案。
管理複雜性更高。
專案結束時間可能未知，這是一個風險。
需要高技能的資源進行風險分析。
專案進度高度依賴於風險分析階段。

SDLC - 螺旋模型

螺旋模型結合了迭代開發的思想和瀑布模型的系統化、受控方面。該螺旋模型是迭代開發過程模型和順序線性開發模型（即瀑布模型）的組合，非常強調風險分析。它允許產品的增量釋出或透過螺旋的每次迭代進行增量改進。

螺旋模型 - 設計

螺旋模型有四個階段。軟體專案在迭代中反覆經歷這些階段，稱為螺旋。

識別

此階段從在基線螺旋中收集業務需求開始。在隨後的螺旋中，隨著產品的成熟，系統需求、子系統需求和單元需求的識別都在此階段完成。

此階段還包括透過客戶和系統分析師之間的持續溝通來理解系統需求。在螺旋結束時，產品部署在已識別的市場中。

設計

設計階段從基線螺旋中的概念設計開始，包括架構設計、模組邏輯設計、物理產品設計和後續螺旋中的最終設計。

構建

構建階段是指在每個螺旋中實際軟體產品的生產。在基線螺旋中，當產品剛剛被構思並且正在開發設計時，此階段會開發POC（概念驗證）以獲得客戶反饋。

然後在隨後的螺旋中，對需求和設計細節有更高的清晰度，會生成具有版本號的稱為構建的可工作軟體模型。這些構建被髮送給客戶以獲取反饋。

評估和風險分析

風險分析包括識別、評估和監控技術可行性和管理風險，例如進度延誤和成本超支。測試構建後，在第一次迭代結束時，客戶會評估軟體並提供反饋。

下圖是螺旋模型的表示，列出了每個階段的活動。

根據客戶評估，軟體開發過程進入下一個迭代，隨後遵循線性方法來實施客戶建議的反饋。沿著螺旋的迭代過程貫穿軟體的整個生命週期。

螺旋模型應用

螺旋模型廣泛應用於軟體行業，因為它與任何產品的自然開發過程同步，即學習成熟，這為客戶和開發公司都帶來了最低的風險。

以下要點解釋了螺旋模型的典型用途：

當存在預算限制並且風險評估很重要時。
對於中高風險專案。
由於經濟優先順序的潛在變化，隨著需求隨時間變化而導致的長期專案承諾。
客戶不確定他們的需求，這通常是這種情況。
需求複雜且需要評估才能獲得清晰度。
應分階段釋出的新產品線，以獲得足夠的客戶反饋。
預計產品在開發週期中會發生重大變化。

螺旋模型 - 優缺點

螺旋生命週期模型的優點是它允許在產品元素可用或已知時新增進去。這確保不會與之前的需求和設計衝突。

此方法與具有多個軟體構建和釋出的方法一致，這允許有序地過渡到維護活動。此方法的另一個積極方面是螺旋模型迫使早期使用者參與系統開發工作。

另一方面，完成此類產品需要非常嚴格的管理，並且存在無限迴圈螺旋的風險。因此，變更的紀律和接受變更請求的程度對於成功開發和部署產品非常重要。

螺旋SDLC模型的優點如下：

可以適應不斷變化的需求。
允許廣泛使用原型。
可以更準確地捕獲需求。
使用者儘早看到系統。
開發可以分為較小的部分，並且可以儘早開發風險較大的部分，這有助於更好地進行風險管理。

螺旋SDLC模型的缺點如下：

管理更加複雜。
專案結束時間可能無法儘早得知。
不適用於小型或低風險專案，對於小型專案來說可能成本很高。
過程複雜
螺旋可能無限期地繼續下去。
大量的中間階段需要過多的文件。

SDLC - V 模型

V模型是一種SDLC模型，其中程序的執行以V形方式按順序進行。它也稱為**驗證和確認模型**。

V 模型是瀑布模型的擴充套件，其基礎是為每個對應的開發階段關聯一個測試階段。這意味著開發週期中的每個階段都有一個直接關聯的測試階段。這是一個高度規範的模型，只有在完成前一個階段後才能開始下一個階段。

V 模型 - 設計

在 V 模型中，開發階段的對應測試階段是並行規劃的。因此，‘V’的一側是驗證階段，另一側是確認階段。編碼階段連線了 V 模型的兩側。

下圖描述了 SDLC V 模型中的不同階段。

V 模型 - 驗證階段

V 模型中包含多個驗證階段，下面將詳細解釋每個階段。

業務需求分析

這是開發週期的第一個階段，在這個階段中，從客戶的角度理解產品需求。此階段涉及與客戶進行詳細溝通，以瞭解客戶的期望和確切需求。這是一項非常重要的活動，需要妥善管理，因為大多數客戶並不確定他們到底需要什麼。在此階段進行驗收測試設計規劃，因為業務需求可以用作驗收測試的輸入。

系統設計

一旦您擁有清晰且詳細的產品需求，就可以開始設計完整的系統。系統設計將包含對正在開發的產品的完整硬體和通訊設定的理解和詳細說明。系統測試計劃是基於系統設計制定的。在早期階段這樣做可以為以後的實際測試執行留下更多時間。

架構設計

在這個階段，理解和設計架構規範。通常會提出不止一種技術方案，並根據技術和財務可行性做出最終決定。系統設計進一步分解成承擔不同功能的模組。這也被稱為高層設計 (HLD)。

在此階段，清楚地理解和定義內部模組之間以及與外部世界（其他系統）的資料傳輸和通訊。利用這些資訊，可以在此階段設計和記錄整合測試。

模組設計

在此階段，指定所有系統模組的詳細內部設計，稱為低層設計 (LLD)。重要的是，設計要與系統架構中的其他模組和其他外部系統相容。單元測試是任何開發過程中必不可少的部分，有助於在早期階段消除大部分故障和錯誤。可以根據內部模組設計在此階段設計這些單元測試。

編碼階段

在編碼階段，進行在設計階段設計的系統模組的實際編碼。根據系統和架構要求決定最合適的程式語言。

編碼是根據編碼指南和標準執行的。程式碼經過多次程式碼審查，並在最終構建簽入儲存庫之前針對最佳效能進行了最佳化。

確認階段

下面將詳細解釋 V 模型中的不同確認階段。

單元測試

在此確認階段，對程式碼執行在模組設計階段設計的單元測試。單元測試是在程式碼級別進行的測試，有助於儘早消除錯誤，儘管並非所有缺陷都能透過單元測試發現。

整合測試

整合測試與架構設計階段相關聯。執行整合測試以測試系統內內部模組的共存和通訊。

系統測試

系統測試直接與系統設計階段相關聯。系統測試檢查整個系統的功能以及正在開發的系統與外部系統的通訊。大多數軟體和硬體相容性問題都可以在此係統測試執行期間發現。

驗收測試

驗收測試與業務需求分析階段相關聯，它涉及在使用者環境中測試產品。驗收測試發現與使用者環境中其他系統存在的相容性問題。它還會發現實際使用者環境中的非功能性問題，例如負載和效能缺陷。

V 模型 ─ 應用

V 模型的應用與瀑布模型幾乎相同，因為這兩個模型都是順序型別的。專案開始之前，需求必須非常明確，因為通常情況下，返回並進行更改的成本很高。此模型用於醫療開發領域，因為它是一個嚴格規範的領域。

以下要點是一些最適合使用 V 模型應用的場景。

需求已明確定義、清晰記錄且固定不變。
產品定義穩定。
技術不是動態的，專案團隊對其有很好的理解。
沒有模稜兩可或未定義的需求。
專案時間短。

V 模型 - 優缺點

V 模型方法的優點是易於理解和應用。該模型的簡單性也使其更易於管理。缺點是模型不靈活，難以應對變更，萬一需要更改需求（這在當今動態世界中非常常見），更改的成本將非常高。

V 模型方法的優點如下：

這是一個高度規範的模型，各階段一個接一個地完成。
適用於需求非常明確的小型專案。
簡單易懂且易於使用。
由於模型的嚴格性，易於管理。每個階段都有具體的交付成果和審查流程。

V 模型方法的缺點如下：

高風險和不確定性。
不適用於複雜的面向物件專案。
不適用於長期和持續的專案。
不適用於需求存在中等或高變更風險的專案。
一旦應用程式進入測試階段，就很難返回並更改功能。
在生命週期後期之前不會產生可工作的軟體。

SDLC - 大爆炸模型

大爆炸模型是一種 SDLC 模型，在這種模型中，我們不遵循任何特定流程。開發只是以所需的資金和精力作為輸入開始，輸出是開發的軟體，該軟體可能符合也可能不符合客戶的需求。大爆炸模型不遵循任何流程/程式，只需要很少的規劃。甚至客戶也不確定自己到底想要什麼，需求是在沒有經過太多分析的情況下即時實現的。

通常，此模型適用於開發團隊非常小的小型專案。

大爆炸模型 ─ 設計和應用

大爆炸模型包括將所有可能的資源集中在軟體開發和編碼上，而很少或沒有規劃。需求隨著出現而被理解和實現。任何所需的更改可能需要也可能不需要徹底修改整個軟體。

此模型非常適合只有一兩個開發人員一起工作的小型專案，也適用於學術或實踐專案。對於需求不明確且未給出最終釋出日期的產品，這是一個理想的模型。

大爆炸模型 - 優缺點

大爆炸模型的優點是它非常簡單，幾乎不需要任何規劃。易於管理，不需要正式程式。

然而，大爆炸模型是一個非常高風險的模型，需求變更或誤解的需求甚至可能導致專案完全反轉或取消。它非常適合具有最小風險的重複性或小型專案。

大爆炸模型的優點如下：

這是一個非常簡單的模型
幾乎不需要規劃
易於管理
所需資源很少
為開發人員提供靈活性
對於新手或學生來說，這是一個很好的學習工具。

大爆炸模型的缺點如下：

非常高的風險和不確定性。
不適用於複雜的面向物件專案。
不適用於長期和持續的專案。
如果誤解了需求，可能會變得非常昂貴。

SDLC - 敏捷模型

敏捷 SDLC 模型是迭代和增量過程模型的結合，它側重於過程適應性和客戶滿意度，透過快速交付可工作的軟體產品來實現。敏捷方法將產品分解成小的增量構建。這些構建以迭代方式提供。每次迭代通常持續約一到三週。每次迭代都涉及跨職能團隊同時處理各個領域，例如：

規劃
需求分析
設計
編碼
單元測試和
驗收測試。

在迭代結束時，將向客戶和重要的利益相關者展示可工作的產品。

什麼是敏捷？

敏捷模型認為，每個專案都需要不同的處理方式，並且需要根據專案需求調整現有方法。在敏捷方法中，任務被劃分為時間框（短時間段）以交付特定版本的特性。

採用迭代方法，每次迭代後都會交付可工作的軟體版本。每個版本在特性方面都是增量的；最終版本包含客戶所需的所有特性。

以下是敏捷模型的圖形說明：

敏捷思想過程很早就開始在軟體開發中應用，並且由於其靈活性和適應性而隨著時間的推移越來越流行。

最流行的敏捷方法包括 Rational 統一過程 (1994)、Scrum (1995)、Crystal Clear、極限程式設計 (1996)、自適應軟體開發、特性驅動開發和動態系統開發方法 (DSDM) (1995)。在 2001 年釋出敏捷宣言後，這些方法現在統稱為敏捷方法。

以下是敏捷宣言的原則：

個人與互動 − 在敏捷開發中，自組織和積極性非常重要，協同辦公和結對程式設計之類的互動也很重要。
可工作的軟體 − 演示可工作的軟體被認為是與客戶溝通以瞭解其需求的最佳方式，而不是僅僅依賴文件。
客戶協作 − 由於各種因素，無法在專案開始時完全收集需求，因此持續的客戶互動對於獲取正確產品需求非常重要。
響應變化 − 敏捷開發專注於快速響應變化和持續開發。

敏捷與傳統 SDLC 模型

敏捷基於自適應軟體開發方法，而傳統的 SDLC 模型（如瀑布模型）基於預測方法。傳統 SDLC 模型中的預測團隊通常使用詳細的規劃，並對未來幾個月或產品生命週期內要交付的確切任務和特性進行完整的預測。

預測方法完全依賴於週期開始時進行的需求分析和規劃。任何要合併的更改都要經過嚴格的變更控制管理和優先順序排序。

敏捷使用自適應方法，其中沒有詳細的規劃，並且只有關於需要開發哪些特性才能明確未來的任務。存在特性驅動開發，團隊動態地適應不斷變化的產品需求。產品透過釋出迭代非常頻繁地進行測試，最大限度地降低了未來出現重大故障的風險。

客戶互動是這種敏捷方法的核心，開放的溝通和最少的文件是敏捷開發環境的典型特徵。敏捷團隊緊密合作，通常位於同一地理位置。

敏捷模型 - 優缺點

敏捷方法最近在軟體領域被廣泛接受。但是，這種方法並不總是適用於所有產品。以下是敏捷模型的一些優缺點。

敏捷模型的優點如下：

是一種非常現實的軟體開發方法。
促進團隊合作和交叉培訓。
功能可以快速開發和演示。
資源需求最少。
適用於固定或變化的需求
交付早期部分可執行的解決方案。
適用於穩定變化的環境。
規則最少，文件易於使用。
能夠在整體規劃的背景下進行併發開發和交付。
幾乎不需要規劃。
易於管理。
為開發人員提供靈活性。

敏捷模型的缺點如下：

不適合處理複雜的依賴關係。
可持續性、可維護性和可擴充套件性風險更大。
必須要有整體計劃、敏捷領導者和敏捷專案管理實踐，否則無法執行。
嚴格的交付管理決定了要交付的範圍、功能以及為滿足截止日期而進行的調整。
嚴重依賴客戶互動，因此如果客戶不明確，團隊可能會被引導到錯誤的方向。
由於生成的文件最少，因此個人依賴性非常高。
由於缺乏文件，將技術轉移給新的團隊成員可能非常具有挑戰性。

SDLC - 快速應用開發模型 (RAD)

快速應用開發 (RAD) 模型基於原型和迭代開發，無需任何具體的規劃。軟體本身的編寫過程包含開發產品所需的規劃。

快速應用開發側重於透過研討會或焦點小組收集客戶需求，客戶使用迭代概念對原型進行早期測試，重用現有原型（元件），持續整合和快速交付。

什麼是RAD？

快速應用開發是一種軟體開發方法，它使用最少的規劃來支援快速原型設計。原型是功能上等效於產品元件的工作模型。

在RAD模型中，功能模組作為原型並行開發，並整合以建立完整的最終產品，從而實現更快的產品交付。由於沒有詳細的預先規劃，因此更容易在開發過程中合併更改。

RAD專案遵循迭代和增量模型，並擁有小型團隊，這些團隊由開發人員、領域專家、客戶代表和其他IT資源組成，他們逐步處理其元件或原型。

為了使該模型成功，最重要的方面是確保開發的原型可重用。

RAD模型設計

RAD模型將分析、設計、構建和測試階段分配到一系列短的迭代開發週期中。

以下是RAD模型的各個階段：

業務建模

正在開發的產品的業務模型是根據資訊流和各種業務渠道之間資訊的分發來設計的。進行完整的業務分析以查詢業務的重要資訊，如何獲取，如何以及何時處理資訊以及驅動資訊成功流動的因素。

資料建模

審查和分析在業務建模階段收集的資訊，以形成對業務至關重要的資料集。標識和定義所有資料集的屬性。這些資料物件之間的關係根據業務模型進行詳細建立和定義。

流程建模

將資料建模階段中定義的資料物件集轉換為建立實現特定業務目標所需的業務資訊流（根據業務模型）。在此階段定義任何更改或增強資料物件集的流程模型。給出了新增、刪除、檢索或修改資料物件的流程描述。

應用程式生成

使用自動化工具將流程和資料模型轉換為實際原型來構建實際系統並進行編碼。

測試和移交

在RAD模型中，整體測試時間減少了，因為原型在每次迭代期間都經過獨立測試。但是，需要對所有元件之間的資料流和介面進行徹底測試，並確保完整的測試覆蓋率。由於大多數程式設計元件已透過測試，因此降低了出現重大問題的風險。

下圖詳細描述了RAD模型。

RAD模型與傳統SDLC

傳統的SDLC遵循嚴格的流程模型，在編碼開始之前非常重視需求分析和收集。它給客戶帶來壓力，要求在專案開始之前簽署需求，並且客戶在很長一段時間內沒有可用的工作版本，因此無法感受到產品的實際情況。

客戶在看到軟體後可能需要一些更改。但是，更改過程非常嚴格，在傳統的SDLC中可能無法實現對產品進行重大更改。

RAD模型專注於向客戶迭代和增量地交付工作模型。這導致向客戶快速交付，並在產品的整個開發週期中參與客戶，從而降低了不符合實際使用者需求的風險。

RAD模型 - 應用

RAD模型可以成功地應用於可以進行清晰模組化的專案。如果專案無法分解成模組，RAD可能會失敗。

以下要點描述了可以使用RAD的典型場景：

只有當系統可以模組化以增量方式交付時，才應使用RAD。
如果建模人員高度可用，則應使用它。
只有在預算允許使用自動程式碼生成工具的情況下，才應使用它。
只有在有具備相關業務知識的領域專家時，才應選擇RAD SDLC模型。
應在專案期間需求發生變化且需要以2-3個月的小迭代向客戶展示工作原型的情況下使用。

RAD模型 - 優缺點

RAD模型由於元件的可重用性和並行開發而縮短了整體開發時間，從而實現了快速交付。只有在有高技能工程師且客戶也致力於在給定的時間框架內實現目標原型的情況下，RAD才能有效執行。如果任何一方缺乏承諾，模型可能會失敗。

RAD模型的優點如下：

可以適應不斷變化的需求。
可以衡量進度。
使用強大的RAD工具可以縮短迭代時間。
在短時間內用較少的人員提高生產力。
縮短開發時間。
提高元件的可重用性。
快速進行初步審查。
鼓勵客戶反饋。
從一開始就整合解決了大量的整合問題。

RAD模型的缺點如下：

依賴技術能力強的團隊成員來識別業務需求。
只有可以模組化的系統才能使用RAD構建。
需要高技能的開發人員/設計師。
高度依賴建模技能。
不適用於廉價專案，因為建模和自動程式碼生成的成本非常高。
管理複雜性更高。
適用於基於元件且可擴充套件的系統。
需要使用者參與整個生命週期。
適用於需要較短開發時間的專案。

SDLC - 軟體原型模型

軟體原型是指構建軟體應用程式原型，這些原型顯示正在開發的產品的功能，但可能並不完全保留原始軟體的精確邏輯。

軟體原型正在成為一種非常流行的軟體開發模型，因為它能夠在開發的早期階段瞭解客戶的需求。它有助於從客戶那裡獲得寶貴的反饋，並幫助軟體設計師和開發人員瞭解對正在開發的產品的期望。

什麼是軟體原型？

原型是具有某些有限功能的軟體工作模型。原型並不總是保留實際軟體應用程式中使用的精確邏輯，並且是努力估計中需要考慮的額外努力。

原型用於允許使用者評估開發人員的建議並在實現之前嘗試它們。它還有助於理解特定於使用者的需求，而這些需求在產品設計期間開發人員可能並未考慮過。

以下是設計軟體原型的分步方法。

基本需求識別

此步驟涉及瞭解非常基本的產品需求，尤其是在使用者介面方面。在此階段可以忽略內部設計的更復雜細節以及外部方面（如效能和安全性）。

開發初始原型

在此階段開發初始原型，其中展示了非常基本的需求並提供了使用者介面。這些功能在開發的實際軟體中內部的工作方式可能並不完全相同。同時，使用變通方法為開發的原型中的客戶提供相同的外觀和感覺。

原型審查

然後將開發的原型提交給客戶和專案中的其他重要利益相關者。以有組織的方式收集反饋，並將其用於進一步改進正在開發的產品。

修改和增強原型

在此階段討論反饋和審查意見，並根據時間和預算限制以及實際實施的技術可行性等因素與客戶進行一些協商。接受的更改再次合併到開發的新原型中，並重復此迴圈，直到滿足客戶的期望。

原型可以具有水平或垂直維度。水平原型顯示產品的使用者介面，並提供整個系統的更廣泛檢視，而不關注內部功能。另一方面，垂直原型是對產品中特定功能或子系統的詳細闡述。

水平和垂直原型的目的不同。水平原型用於獲取有關使用者介面級別和業務需求的更多資訊。它甚至可以在銷售演示中展示以獲得市場業務。垂直原型具有技術性，用於獲取子系統精確功能的詳細資訊。例如，給定子系統中的資料庫需求、互動和資料處理負載。

軟體原型 - 型別

行業中使用了不同型別的軟體原型。以下是廣泛使用的主要軟體原型型別：

一次性/快速原型

一次性原型也稱為快速原型或封閉式原型。這種型別的原型使用很少的努力和最小的需求分析來構建原型。一旦理解了實際需求，原型就會被丟棄，並且在對使用者需求有了更清晰的理解後，就會開發實際系統。

演化式原型

演化式原型也稱為試驗板原型，它基於在開始時構建具有最小功能的實際功能原型。開發的原型構成了未來原型（在其之上構建整個系統）的核心。透過使用演化式原型，將已理解的需求包含在原型中，並在理解需求時新增需求。

增量原型

增量原型法是指構建各個子系統的多個功能原型，然後將所有可用的原型整合起來形成一個完整的系統。

極限原型法

極限原型法用於Web開發領域。它包括三個連續的階段。首先，使用HTML格式呈現包含所有現有頁面的基本原型。然後，使用原型服務層模擬資料處理。最後，實現服務並將其整合到最終原型中。此過程稱為極限原型法，用於強調該過程的第二階段，其中開發了一個完全功能的UI，而很少考慮實際的服務。

軟體原型 - 應用

軟體原型法在開發具有高度使用者互動的系統（例如線上系統）方面最為有用。需要使用者填寫表單或在資料處理之前瀏覽各種螢幕的系統，可以使用原型法非常有效地提供精確的外觀和感覺，甚至在實際軟體開發之前。

涉及大量資料處理且大部分功能是內部的，使用者介面很少的軟體通常不會從原型法中受益。原型開發在這種專案中可能會增加額外的開銷，並且可能需要付出更多努力。

軟體原型 - 優缺點

軟體原型法用於典型案例，應非常謹慎地做出決定，以便在構建原型上花費的精力為最終開發的軟體增加相當大的價值。該模型有其自身的優缺點，如下所述。

原型模型的優點如下：

在產品實施之前，增加使用者參與度。
由於顯示了系統的可執行模型，使用者可以更好地理解正在開發的系統。
減少時間和成本，因為可以更早地檢測到缺陷。
可以更快地獲得使用者反饋，從而獲得更好的解決方案。
可以輕鬆識別缺失的功能。
可以識別令人困惑或難以使用的功能。

原型模型的缺點如下：

由於過於依賴原型，可能導致需求分析不足的風險。
使用者可能會混淆原型和實際系統。
實際上，這種方法可能會增加系統的複雜性，因為系統的範圍可能會超出最初的計劃。
即使在技術上不可行的情況下，開發人員也可能嘗試重用現有原型來構建實際系統。
如果不對構建原型的努力進行適當的監控，則投入的精力可能會過多。

列印頁面