軟體工程/過程/生命週期簡介

系統開發生命週期模型

系統開發生命週期模型

系統開發生命週期 (SDLC)，或在系統工程、資訊系統和軟體工程中稱為軟體開發生命週期，是建立或更改系統以及人們用於開發這些系統的模型和方法的過程。該概念通常指的是計算機或資訊系統。

在軟體工程中，SDLC 概念是許多軟體開發方法的基礎。這些方法構成了規劃和控制資訊系統建立的框架：軟體開發過程。

概述

系統開發生命週期 (SDLC) 是系統分析師用來開發資訊系統的過程，包括需求、驗證、培訓和使用者（利益相關者）所有權。任何 SDLC 都應導致一個高質量的系統，該系統滿足或超過客戶期望，在時間和成本估算內完成，在當前和計劃的資訊科技基礎設施中有效且高效地執行，並且維護成本低廉且增強成本效益。

計算機系統很複雜，並且經常（尤其是在面向服務的架構最近興起的情況下）會將多個傳統系統（可能由不同的軟體供應商提供）連結在一起。為了管理這種複雜性，建立了許多 SDLC 模型：“瀑布模型”；“噴泉模型”；“螺旋模型”；“構建和修復”；“快速原型”；“增量模型”；和“同步和穩定”。

SDLC 模型可以在敏捷、迭代和順序的範圍內描述。敏捷方法，如 XP 和 Scrum，專注於輕量級流程，允許在開發週期中進行快速更改。迭代方法，如 Rational Unified Process 和 Dynamic Systems Development Method，專注於有限的專案範圍，並透過多次迭代擴充套件或改進產品。順序模型或大型設計預先 (BDUF) 模型，如瀑布模型，專注於完整的正確規劃，以指導大型專案和風險，以取得成功和可預測的結果。其他模型，如 Anamorphic Development，傾向於專注於由專案範圍和功能開發的適應性迭代引導的開發形式。

在專案管理中，專案可以用專案生命週期 (PLC) 和 SDLC 定義，在此期間會發生略微不同的活動。根據泰勒 (2004) 的說法，“專案生命週期涵蓋了專案的全部活動，而系統開發生命週期專注於實現產品需求”。

歷史

系統生命週期 (SLC) 是一種用於描述構建資訊系統的過程的方法，旨在以非常刻意、結構化和有條理的方式開發資訊系統，重複生命週期的每個階段。系統開發生命週期，根據 Elliott & Strachan & Radford (2004) 的說法，“起源於 1960 年代，用於在大型商業集團時代開發大型功能性商業系統。資訊系統活動圍繞大量資料處理和數字運算例程展開”。

一些系統開發框架部分基於 SDLC，例如 1980 年代為英國政府辦公廳生產的結構化系統分析與設計方法 (SSADM)。從那時起，根據 Elliott (2004) 的說法，“傳統生命週期方法開發系統已被越來越多地替代為替代方法和框架，這些方法和框架試圖克服傳統 SDLC 的一些固有缺陷”。

系統開發階段

系統開發生命週期框架為系統設計人員和開發人員提供了一系列要遵循的活動。它包含一組步驟或階段，其中 SDLC 的每個階段都使用前一個階段的結果。

系統開發生命週期 (SDLC) 遵循對開發人員至關重要的重要階段，如計劃、分析、設計和實施，並在以下部分進行了解釋。建立了許多系統開發生命週期 (SDLC) 模型：“瀑布模型”，“噴泉模型”，“螺旋模型”，“構建和修復”，“快速原型”，“增量模型”和“同步和穩定”。其中最古老、最知名的模型是瀑布模型：一個階段序列，其中每個階段的輸出成為下一個階段的輸入。這些階段可以以不同的方式進行特徵化和劃分，包括以下內容

• 專案規劃，可行性研究：建立對預期專案的概覽並確定其目標。
• 系統分析，需求定義：將專案目標細化為預期應用程式的定義功能和操作。分析終端使用者的資訊需求。
• 系統設計：詳細描述所需的功能和操作，包括屏幕布局、業務規則、流程圖、虛擬碼和其他文件。
• 實施：這裡編寫了真正的程式碼。
• 整合和測試：將所有部分組合到一個特殊的測試環境中，然後檢查錯誤、錯誤和互操作性。
• 驗收、安裝、部署：初始開發的最後階段，軟體投入生產並執行實際業務。
• 維護：軟體生命週期中其餘時間會發生什麼：更改、更正、新增、移動到不同的計算平臺等等。這是所有步驟中最不光彩但也最重要的步驟，它似乎永遠持續下去。

在以下示例（參見圖片）中，系統開發生命週期的這些階段被劃分為從定義到 IT 工作產品的建立和修改的十個步驟

第十階段發生在系統被處置時，執行的任務要麼被消除，要麼被轉移到其他系統。每個階段的任務和工作產品將在後續章節中介紹。

並非每個專案都需要按順序執行這些階段。但是，這些階段是相互依賴的。根據專案的規模和複雜性，階段可以合併或重疊。

系統分析

系統分析的目標是確定問題所在，以便嘗試修復系統。此步驟涉及將系統分解成不同的部分來分析情況，分析專案目標，分解需要建立的內容，並嘗試讓使用者參與，以便可以定義明確的需求。

需求分析有時需要來自客戶方和服務提供商方的個人/團隊才能獲得詳細準確的需求； 通常需要進行大量來回溝通才能瞭解這些需求。 需求收集是最關鍵的方面，因為許多時候在這個階段會出現溝通差距，從而導致軟體程式中的驗證錯誤和 bug。

設計

在系統設計中，會詳細描述設計功能和操作，包括屏幕布局、業務規則、流程圖和其他文件。 此階段的輸出將描述新系統作為一個模組或子系統集合。

設計階段以在批准的需求文件中識別的需求作為其初始輸入。 對於每個需求，將透過訪談、研討會和/或原型工作產生一組或多組設計元素。

設計元素詳細描述所需的軟體功能，通常包括功能層次結構圖、屏幕布局圖、業務規則表、業務流程圖、虛擬碼以及包含完整資料字典的完整實體關係圖。 這些設計元素旨在詳細描述軟體，以便熟練的程式設計師可以以最少的額外輸入設計來開發軟體。

實施

模組和子系統程式設計程式碼將在本階段完成。 開發人員在本階段進行單元測試和模組測試。 這個階段與下一個階段交織在一起，因為各個模組需要在整合到主專案之前進行測試。

測試

程式碼在軟體測試的各個級別進行測試。 通常會進行單元測試、系統測試和使用者驗收測試。 這是一個灰色區域，因為關於測試階段是什麼以及迭代多少（如果有的話）存在許多不同的觀點。 迭代通常不是瀑布模型的一部分，但通常在此階段會發生一些迭代。 在測試中，整個系統會一個接一個地進行測試。

以下是測試型別

• 缺陷測試
• 路徑測試
• 資料集測試
• 單元測試
• 系統測試
• 整合測試
• 黑盒測試
• 白盒測試
• 迴歸測試
• 自動化測試
• 使用者驗收測試
• 效能測試

運營和維護

系統部署包括在系統退役或停用之前進行的更改和增強。 維護系統是 SDLC 的一個重要方面。 隨著關鍵人員在組織中的職位變動，將實施新的變更，這將需要系統更新。

系統分析與設計

系統分析與設計 (SAD) 是開發資訊系統 (IS) 的過程，有效利用硬體、軟體、資料、流程和人員來支援公司的業務目標。

系統開發生命週期主題

管理和控制

與管理控制相關的 SDLC 階段。

系統開發生命週期 (SDLC) 階段作為專案活動的程式指南，提供了一種靈活但一致的方式來執行專案，以匹配專案範圍的深度。 本節描述了每個 SDLC 階段的目標，包括關鍵可交付成果、推薦任務的描述以及與有效管理相關的控制目標的摘要。 專案經理必須在每個 SDLC 階段建立和監控控制目標，同時執行專案。 控制目標有助於提供對預期結果或目的的明確陳述，並且應在整個 SDLC 流程中使用。 控制目標可以分為主要類別（域），並與 SDLC 階段相關聯，如圖所示。

為了管理和控制任何 SDLC 計劃，每個專案都需要建立一定程度的工作分解結構 (WBS)，以捕獲和安排完成專案所需的工作。 WBS 和所有程式材料應儲存在專案筆記本的“專案描述”部分。 WBS 格式主要由專案經理決定，以最佳方式描述專案工作。 WBS 中必須定義一些關鍵區域作為 SDLC 政策的一部分。 以下圖表描述了將在 WBS 中以專案經理確定的方式解決的三個關鍵區域。

工作分解結構化組織

工作分解結構。

工作分解結構 (WBS) 的上半部分應以摘要形式識別專案的主要階段和里程碑。 此外，上半部分應提供對專案完整範圍和時間表的概述，並將作為專案描述的初始工作的一部分，從而導致專案批准。 WBS 的中間部分基於七個系統開發生命週期 (SDLC) 階段，作為 WBS 任務開發的指南。 WBS 元素應包含里程碑和“任務”，而不是“活動”，並且具有明確的期限（通常為兩週或更長時間）。 每個任務都必須有一個可衡量的輸出（例如，文件、決策或分析）。 WBS 任務可能依賴於一個或多個活動（例如，軟體工程、系統工程），並且可能需要與其他任務密切協調，無論是在專案內部還是外部。 專案中任何需要承包商支援的部分都應有一個工作說明 (SOW)，其中包含來自 SDLC 階段的適當任務。 SOW 的開發不是在 SDLC 的特定階段進行的，而是開發用來包含可能由外部資源（如承包商和結構）進行的 SDLC 流程中的工作。

SDLC 中的基線

基線是系統開發生命週期 (SDLC) 的重要組成部分。 這些基線是在 SDLC 的五個階段中的四個階段之後建立的，對於模型的迭代性質至關重要。 每個基線都被視為 SDLC 中的里程碑。

• 功能基線：在概念設計階段之後建立。
• 分配基線：在初步設計階段之後建立。
• 產品基線：在詳細設計和開發階段之後建立。
• 更新的產品基線：在生產構建階段之後建立。

補充 SDLC

補充系統開發生命週期 (SDLC) 的軟體開發方法有：

• 軟體原型
• 聯合應用設計 (JAD)
• 快速應用開發 (RAD)
• 極限程式設計 (XP)； 是早期原型和 RAD 工作的擴充套件。
• 開源開發
• 終端使用者開發
• 面向物件程式設計

方法論方法比較（Post & Anderson 2006）

	SDLC	RAD	開源	物件	JAD	原型	終端使用者
控制	正式	MIS	弱	標準	聯合	使用者	使用者
時間範圍	長	短	中等	任何	中等	短	短
使用者	很多	很少	很少	變化	很少	一到兩個	一個
MIS 員工	很多	很少	數百	分割	很少	一到兩個	無
事務/DSS	事務	兩者	兩者	兩者	DSS	DSS	DSS
介面	最小	最小	弱	Windows	至關重要	至關重要	至關重要
文件和培訓	至關重要	有限	內部	在物件中	有限	弱	無
完整性和安全性	至關重要	至關重要	未知	在物件中	有限	弱	弱
可重用性	有限	一些	也許	至關重要	有限	弱	無

優勢和劣勢

在現代計算領域，很少有人會嚴格使用瀑布模型來進行系統開發生命週期 (SDLC) [11]，因為許多現代方法已經取代了這種思維方式。有些人會爭辯說 SDLC 不再適用於像敏捷計算這樣的模型，但它仍然是科技界廣泛使用的術語。SDLC 實踐在傳統的軟體開發模型中具有優勢，這使其更適合結構化的環境。使用 SDLC 方法的缺點是，當需要迭代開發或（例如網頁開發或電子商務）利益相關者需要定期審查正在設計的軟體時。與其從優勢或劣勢的角度看待 SDLC，不如從 SDLC 模型中汲取最佳實踐，並將它們應用於最適合正在設計的軟體的任何方面。

SDLC 的優缺點比較

SDLC 的優缺點

優勢	劣勢
控制。	開發時間增加。
監控大型專案。	開發成本增加。
詳細步驟。	系統必須在前期定義。
評估成本和完成目標。	僵化性。
文件。	難以估計成本，專案超支。
定義明確的使用者輸入。	使用者輸入有時受限。
易於維護。
開發和設計標準。
容忍 MIS 人員的變化。

SDLC 的替代方案是快速應用開發，它結合了原型設計、聯合應用開發和 CASE 工具的實施。RAD 的優勢包括速度、降低開發成本和使用者積極參與開發過程。

進一步閱讀

• Blanchard, B. S., & Fabrycky, W. J.(2006) 系統工程與分析 (第 4 版) 新澤西州：Prentice Hall。
• Cummings, Haag (2006)。資訊時代的管理資訊系統。多倫多，麥格勞-希爾·瑞爾森出版社
• Beynon-Davies P. (2009)。商業資訊系統。帕爾格雷夫，貝辛斯托克。 ISBN 978-0-230-20368-6
• 計算機世界，2002，從全球資訊網上檢索於 2006 年 6 月 22 日
• 管理資訊系統，2005，從全球資訊網上檢索於 2006 年 6 月 22 日

外部連結

• 幻燈片影片
• 敏捷系統開發生命週期
• 養老金保障公司 - 資訊科技解決方案生命週期方法
• HHS 企業績效生命週期框架