軟件開發生命週期 (SDLC) 概述 - IT 觀察者隨筆

Table of Contents hide

軟件開發生命週期通過收集新產品的初始需求，為組織提供了一種系統的、逐步的方法來開發成功的軟件。它是構建軟件的系統過程，以確保所構建軟件的質量和正確性，並滿足客戶的期望。

主要開發模型包括瀑布模型、增量模型、螺旋模型、噴泉模型、智能模型、V模型、RAD模型、CBSD模型、原型法、XP法、RUP法等。

瀑布模型

瀑布模型，又稱生命週期法，是生命週期法中最常用的開發模型。它將軟件開發過程分為六個階段：軟件規劃、需求分析、軟件設計、程序編碼、軟件測試和運維。為了實現它們從上到下的固定順序，它們就像瀑布一樣，一步一步地落下。

軟件計劃：主要確定軟件的開發目標和可行性。
需求分析：在確認軟件開發可行後，對軟件需要實現的各種功能進行詳細分析。需求分析階段是一個非常重要的階段。這個階段的工作做好，將為整個軟件開發項目的成功打下良好的基礎。
軟件設計：根據需求分析的結果，設計整個軟件系統，如係統框架設計、數據庫設計等。軟件設計一般分為總體設計（大綱設計）和詳細設計。
程序代碼：將軟件設計的結果轉化為計算機可以運行的程序代碼。在編程過程中，必須制定統一的、符合標準的編程規範，以保證程序的可讀性，便於維護，提高程序的運行效率。
軟件測試：軟件設計完成後，必須經過嚴格的測試，在整個設計過程中發現並糾正軟件中的問題。在測試過程中，要製定詳細的測試計劃，嚴格按照測試計劃進行測試，減少測試的隨意性。軟件維護：
軟件維護 是軟件生命週期中最長的時期。軟件開發並投入使用後，由於各種原因，軟件無法繼續滿足用戶的要求。要延長軟件的使用壽命，必須對軟件進行維護。

轉型模式

轉換模型（進化模型）是基於原型的快速發展。根據用戶在調用原型的過程中提出的反饋和建議，對原型進行改進以獲得新版本的原型，並重複這個過程，直到演變成最終的軟件產品。

螺旋模型

螺旋模型結合了瀑布模型和變換模型。它結合了兩者的優點並增加了風險分析。它以原型為基礎，沿螺旋線由內向外旋轉。每次輪換都需要計劃、風險分析、實施工程、客戶評估等活動，並開發出新版本的原型。經過幾次螺旋，得到最終系統。

噴泉模型

噴泉模型為生命週期中多種開發活動的軟件復用和集成提供支持，主要支持面向對象的開發方式。“噴泉”一詞本身就體現了迭代和無間隙的特點。系統的某一部分經常重複工作多次，在每次迭代中向演化的系統添加相關功能。所謂gapless是指在開發活動中分析、設計和編碼之間沒有明顯的界限。

V型

在開發模式中，測試往往作為事後補救的手段，但也有一種以測試為中心的開發模式，即V模式。V 模型在軟件行業只是模糊地被認可。V 模型聲稱測試不是事後的想法，而是與開發過程一樣重要的過程。

V 模型描述了一些不同的測試級別，並解釋了與這些級別對應的生命週期中的不同階段。圖中，左邊的下降是開發過程的各個階段，對應的是右邊的上升部分，即測試過程的各個階段。

請注意，測試階段的命名在不同的組織中可能會有所不同。V模型的價值在於，它清楚地展示了測試過程中存在的不同層次，並清楚地描述了這些測試階段與開發過程中各個階段的對應關係：

單元測試的主要目的是處理編碼過程中可能存在的各種錯誤。例如：用戶在驗證過程中輸入了一個錯誤的邊界值。
集成測試的主要目的是解決詳細設計中可能出現的問題，特別是檢查每個單元與其他程序部分之間的接口可能出現的錯誤。
系統測試主要是進行概要設計，檢查系統整體是否有效運行。例如：產品設置中是否達到預期的高性能。
驗收測試通常由業務專家或用戶進行，以確認產品能真正滿足用戶的業務需求。

增量模型

增量模型，如原型實現模型和其他進化方法，本質上是迭代的。但與原型實現不同的是，增量模型強調每個增量都會發布一個可操作的產品。早期的增量是最終產品的“可拆卸”版本，但它們確實提供了用戶服務功能，並為用戶提供了一個評估平台。

增量模型的特點是引入了增量包的概念。不需要等到所有需求都出來了，只要某個需求的增量包出來了，就可以開始開發了。雖然某個增量包可能需要進一步適應客戶的需求，需要改變，但只要增量包足夠小，它對整個項目的影響是可以承受的。

RAD 模型快速應用程序開發 (RAD) 模型是一種增量軟件開發過程模型，它強調非常短的開發週期。

RAD模型是瀑布模型的“高速”變體，通過大量使用可重用組件和基於組件的構造方法贏得快速發展。如果需求被很好地理解並且項目的範圍受到限制，那麼這個模型可以用來快速創建一個功能齊全的“信息系統”。

該流程從業務建模開始，然後是數據建模、流程建模、應用程序生成、測試和迭代。使用RAD模型的軟件流程如下圖所示。

RAD模型的每個活動期要完成的任務如下。

業務建模：哪些信息驅動業務流程的運行？要生成什麼信息？誰生成的？信息流到哪裡去了？誰來處理？可輔以數據流圖。

數據建模：為了支持業務流程的數據流，找到數據對象的集合，定義數據對象的屬性，形成與其他數據對象的關係的數據模型，可輔以ER圖.

流程建模：使數據對象能夠完成信息流中的各種業務功能。創建過程描述了數據對象的添加、修改、刪除和查找，也就是數據流圖中處理框的細化。

應用程序生成：使用第四代語言（4GL）編寫處理程序，重用現有組件或創建新的可重用組件，利用環境提供的工具自動生成和構建整個應用系統。

測試交付，由於重用量大，一般只做整體測試，但是新創建的組件還是需要測試的。

基於組件的模型

組件（Component）是具有可重用價值和相對獨立功能的軟件單元。基於組件的軟件開發（CBSD）模型是採用模塊化的方式將整個系統模塊化，並在一定的組件模型的支持下，復用組件庫中的一個或多個軟件組件，通過組合構建應用軟件的過程高效、高質量的系統。

基於組件的開發模型融合了螺旋模型的諸多特點，本質上是進化的，開發過程是迭代的。基於組件的開發模型包括五個階段：軟件需求分析和定義、架構設計、組件庫建立、應用軟件構建、測試和發布。

原型法

軟件原型是提議的新產品的部分實現。建立原型的主要目的是解決產品開發初期需求不確定的問題。其目的是明確和改進需求，探索設計方案，並開發成最終產品。

有很多方法可以對原型進行分類。從原型是否實現其功能來看，軟件原型可以分為橫向原型和縱向原型兩種。

水平原型也稱為行為原型，用於探索預期系統的一些具體行為，達到細化需求的目的。水平原型通常只是功能的導航，但實際上並沒有實現功能。橫向原型主要用在界面上。

垂直原型也稱為結構化原型，它實現了它們的部分功能。垂直原型主要用於復雜算法的實現。

XP方法

XP 是一種輕量級（敏捷）、高效、低風險、靈活、可預測、科學和有趣的軟件開發方法。與其他方法論相比，最大的不同在於：

在更短的時間內儘早提供具體和持續的反饋。
迭代規劃，一開始就快速生成總體規劃，然後在整個項目開發過程中不斷發展。
依靠自動化測試程序來監控開發進度並及早發現缺陷。
依靠口頭交流、測試和源程序交流。
提倡持續進化設計。
依靠開發團隊內部的密切協作。
盡量平衡程序員的短期利益和項目的長期利益。

統一過程（UP）方法

統一過程是一個通用的過程框架，可以應對范圍廣泛的軟件系統、不同的應用領域、不同的組織類型、不同的績效水平和不同的項目規模。UP是基於組件的，即它所開發的軟件系統是由組件組成的，組件之間通過定義良好的接口相互連接。在準備軟件系統的所有藍圖時，UP使用統一的建模語言UML。

與其他軟件過程相比，UP具有三個顯著特點：用例驅動、以基礎架構為中心、迭代和增量。Rational Unified Process 中的軟件過程在時間上被分解為四個連續的階段，即初始階段、細化階段、構建階段和交付階段。在每個階段結束時，必須安排一次技術審查，以確定該階段的目標是否已達到。如果審查結果滿意，可以允許項目進入下一階段。