軟體開發生命週期

---

---

軟體開發生命週期，簡稱SDLC，是軟體工程中一個定義明確、結構化的階段序列，用於開發預期的軟體產品。

SDLC活動

SDLC提供了一系列步驟，以便高效地設計和開發軟體產品。SDLC框架包括以下步驟：

溝通

這是第一步，使用者在此發起對所需軟體產品的請求。他聯絡服務提供商並試圖協商條款。他以書面形式向服務提供機構提交請求。

需求收集

從這一步開始，軟體開發團隊開始執行專案。團隊與來自問題領域的各種利益相關者進行討論，並嘗試儘可能多地獲取有關其需求的資訊。需求被考慮並分為使用者需求、系統需求和功能需求。需求是使用許多實踐收集的，如下所示：

• 研究現有或過時的系統和軟體，
• 對使用者和開發人員進行訪談，
• 參考資料庫或
• 收集問卷調查的答案。

可行性研究

在需求收集之後，團隊會提出一個軟體過程的粗略計劃。在此步驟中，團隊分析是否可以開發軟體來滿足使用者的所有需求，以及軟體是否有可能不再有用。它確定了該專案在財務上、實際上和技術上是否可行，以便組織承擔。有許多可用的演算法可以幫助開發人員得出軟體專案的可行性結論。

系統分析

在此步驟中，開發人員確定其計劃的路線圖，並嘗試提出最適合專案的軟體模型。系統分析包括瞭解軟體產品的侷限性，預先了解系統相關的問題或需要在現有系統中進行的更改，識別和解決專案對組織和人員的影響等。專案團隊分析專案的範圍，並相應地計劃進度和資源。

軟體設計

下一步是將所有需求和分析知識都放在桌面上，並設計軟體產品。來自使用者的輸入和在需求收集階段收集的資訊是此步驟的輸入。此步驟的輸出以兩種設計形式出現：邏輯設計和物理設計。工程師生成元資料和資料字典、邏輯圖、資料流圖以及在某些情況下生成虛擬碼。

編碼

此步驟也稱為程式設計階段。軟體設計的實現以使用合適的程式語言編寫程式程式碼並有效地開發無錯誤的可執行程式的形式開始。

測試

據估計，整個軟體開發過程的50%應該進行測試。錯誤可能導致軟體從嚴重級別到被刪除。軟體測試由開發人員在編碼時完成，並且測試專家在程式碼的各個級別（例如模組測試、程式測試、產品測試、內部測試以及在使用者端測試產品）進行徹底的測試。及早發現錯誤並進行糾正是可靠軟體的關鍵。

整合

軟體可能需要與庫、資料庫和其他程式整合。SDLC的這一階段涉及將軟體與外部實體整合。

實施

這意味著在使用者機器上安裝軟體。有時，軟體需要在使用者端進行安裝後配置。軟體的移植性和適應性以及整合相關問題在實施過程中得到測試和解決。

執行和維護

此階段確認軟體執行在更高效、更少錯誤的情況下。如果需要，將對使用者進行培訓，或提供有關如何操作軟體以及如何保持軟體正常執行的文件。透過根據使用者端環境或技術的變化更新程式碼來及時維護軟體。此階段可能會面臨隱藏錯誤和現實世界中未識別問題的挑戰。

處置

隨著時間的推移，軟體的效能可能會下降。它可能完全過時，或者可能需要進行大量升級。因此，迫切需要消除系統的主要部分。此階段包括存檔資料和所需的軟體元件、關閉系統、計劃處置活動並在適當的系統結束時間終止系統。

軟體開發正規化

軟體開發正規化幫助開發人員選擇開發軟體的策略。軟體開發正規化有一套自己的工具、方法和程式，這些工具、方法和程式表達得非常清楚，並定義了軟體開發生命週期。一些軟體開發正規化或過程模型定義如下：

瀑布模型

瀑布模型是軟體開發正規化中最簡單的模型。它表示SDLC的所有階段將以線性方式一個接一個地執行。也就是說，當第一階段完成後，才會開始第二階段，依此類推。

該模型假設所有事情都按照先前階段的計劃完美地執行和發生，並且無需考慮在下一階段可能出現的過去問題。如果在先前步驟中遺留了一些問題，則此模型無法順利執行。模型的順序性質不允許我們返回並撤消或重做我們的操作。

當開發人員過去已經設計和開發過類似的軟體並且瞭解其所有領域時，此模型最適合。

迭代模型

此模型以迭代方式引導軟體開發過程。它以迴圈方式投影開發過程，在SDLC過程的每個週期之後重複每個步驟。

軟體首先在非常小的規模上開發，並考慮所有步驟。然後，在每個後續迭代中，都會設計、編碼、測試和新增到軟體中更多功能和模組。每個週期都會生成一個軟體，該軟體本身就是完整的，並且具有比前一個軟體更多功能和能力。

在每次迭代之後，管理團隊可以進行風險管理工作併為下一次迭代做好準備。因為一個週期包含整個軟體過程的一小部分，所以管理開發過程更容易，但它會消耗更多資源。

螺旋模型

螺旋模型是迭代模型和SDLC模型之一的組合。可以將其視為選擇一個SDLC模型並將其與迴圈過程（迭代模型）組合。

此模型考慮了風險，而大多數其他模型往往會忽略風險。該模型從一開始就確定一個迭代的軟體目標和約束。下一階段是軟體的原型設計。這包括風險分析。然後，使用一個標準的SDLC模型來構建軟體。在第四階段，準備下一次迭代的計劃。

V模型

瀑布模型的主要缺點是我們只有在完成上一個階段後才能進入下一個階段，如果在後續階段發現錯誤，則沒有機會返回。V模型提供了一種以相反方式在每個階段測試軟體的方法。

在每個階段，都會建立測試計劃和測試用例，以根據該階段的要求驗證和確認產品。例如，在需求收集階段，測試團隊會根據需求準備所有測試用例。稍後，當產品開發完成並準備進行測試時，此階段的測試用例會根據此階段的要求驗證軟體的有效性。

這使得驗證和確認並行進行。此模型也稱為驗證和確認模型。

大爆炸模型

此模型在其形式上是最簡單的模型。它需要很少的計劃、大量的程式設計和大量的資金。此模型的概念化圍繞著宇宙大爆炸。正如科學家所說，大爆炸之後，許多星系、行星和恆星都像事件一樣演化。同樣，如果我們將大量的程式設計和資金放在一起，您可能會獲得最好的軟體產品。

對於此模型，需要很少的計劃。它不遵循任何流程，或者有時客戶不確定需求和未來的需求。因此，輸入需求是任意的。

此模型不適合大型軟體專案，但對於學習和實驗來說是一個不錯的選擇。

有關SDLC及其各種模型的深入閱讀，點選此處。