系統開發生命週期的不同階段是什麼?
Context:系統開發生命週期  條款 談談 閱讀 編輯 檢視歷史記錄  工具 來自維基百科,自由百科全書 這篇文章是關於系統開發生命週期的. 對於IBM的計算機通訊協議,請參閱同步資料鏈控制.  軟體開發生命週期模型,強調維護階段 在系統工程,資訊系統和軟體工程中,系統開發生命週期 (SDLC),也稱為應用程式開發生命週期,是規劃,建立,測試和部署資訊系統的過程. SDLC 概念適用於一系列的硬體和軟體配置,因為一個系統可以由硬體,軟體或兩者的組合組成. 這一迴圈通常有六個階段:需求分析,設計,開發和測試,實施,文件和評估.  概述 系統開發生命週期由系統工程師和系統開發人員用於提供資訊系統的不同工作階段組成. 像在裝配線上製造的任何東西一樣,SDLC的目標是通過在預定時間和成本估計範圍內交付系統,以滿足或超過預期的高質量系統. 計算機系統是複雜的, 已經建立了各種SDLC方法,如<unk>布式,螺旋式,敏捷式,快速原型,增量式,同步和穩定.  SDLC 方法適合從敏捷到<unk>代到順序的靈活性範圍. 敏捷方法,如XP和Scrum,專注於輕量級的流程,允許快速變化. <unk>代方法,如理性統一流程和動態系統開發方法,專注於穩定專案範圍,並<unk>代擴充套件或改進產品. 順序或大設計前置 (BDUF) 模型,如<unk>布,專注於完整和正確的規劃,以指導大型專案,並限制風險以成功和可預測的結果. 無形開發是由專案範圍和適應<unk>代指導的.  在專案管理中,一個專案可以包括一個專案生命週期 (PLC) 和一個SDLC,在這個過程中,一些不同的活動發生. 根據泰勒 (2004) 的說法",專案生命週期涵蓋了專案的所有活動,而系統開發生命週期則專注於實現產品要求".  SDLC本身並不是一種方法,而是方法應解決的階段的描述. 階段列表不是最終的,但通常包括規劃,分析,設計,構建,測試,實施和維護/支援. 例如,在Scrum框架中, 一個使用者故事可以在兩週的時間內經歷SDLC的所有階段. 相比之下,<unk>布方法論,其中每個業務要求[需要引用]都被轉化為功能/功能描述,然後在幾個月或更長的時間內實現. [需要引用]  歷史 根據埃利奧特和斯特拉坎和拉德福德 (2004年) 的說法,SDLC"起源於20世紀60年代,在大型商業集團時代開發大規模的功能業務系統. 資訊系統活動圍繞著大量的資料處理和數量處理程式.  結構化系統分析和設計方法 (SSADM) 是20世紀80年代為英國政府商務辦公室製造的. 從那時起,根據Elliott (2004) 的說法",系統開發的傳統生命週期方法越來越多地被替代的方法和框架所取代,這些方法和框架試圖克服傳統SDLC的一些固有的缺陷.  模型  系統開發生命週期的十個階段版本 SDLC 提供了一組階段/步驟/活動,供系統設計師和開發人員遵循. 每個階段都建立在前一個階段的成果之上. 不是每一個專案都要求階段是順序的. 對於較小,更簡單的專案,可以將階段結合/重疊.  <unk>布 最古老和最著名的就是<unk>布模型, <unk>布有不同的品種. 一種品種如下:  進行初步分析 進行初步分析,考慮其他解決方案,估計成本和收益,並提交初步計劃和建議.  進行初步分析:確定組織的目標,並確定專案的性質和範圍. 確保專案符合目標. 考慮其他解決方案: 採訪員工,客戶,供應商和顧問以及競爭分析可能會提供替代方案. 成本效益分析:分析專案的成本和效益. 系統分析,要求定義 將專案目標[需要澄清]分解為定義的功能和操作. 這包括收集和解釋事實,診斷問題,並建議改變. 分析終端使用者資訊需求,解決不一致和不完整的問題:  收集事實:通過文件審查,客戶訪談,觀察和問卷,獲取終端使用者的要求. 檢查現有系統:確定優缺點. 分析擬議的系統:尋找問題的解決方案,並準備規範,並納入適當的使用者建議. 系統設計 在此步驟中,詳細描述了所需的功能和操作,包括螢幕布局,業務規則,流程圖,虛擬碼和其他交付結果.  發展 寫一個程式碼.  整合和測試 在測試環境中組裝模組. 檢查錯誤,錯誤和互操作性.  接收,安裝,部署 將系統投入生產. 這可能涉及使用者培訓,部署硬體和從以前的系統載入資訊.  維護 監測系統以評估其持續的適用性. 根據需要做些小的修改.  評價 系統和流程進行了審查. 相關問題包括新實施的系統是否符合要求並實現專案目標,系統是否可用,可靠/可用,適當擴充套件和容錯. 過程檢查包括對時間表和費用以及使用者接受的審查.  處理 在使用壽命結束時,制定停止系統的計劃,並轉向其替代品. 相關資訊和基礎設施必須重新使用,存檔,丟棄或銷燬,同時適當保護安全.  在下面的圖中,這些階段被分為10個階段,從定義到建立和修改IT工作產品:  系統分析和設計 系統分析和設計 (SAD) 可以被視為一個超級開發活動,用於設定階段並限制問題. 這樣做有助於平衡競爭的高層要求. SAD與分散式企業架構,企業IT架構和業務架構進行互動,並嚴重依賴分割槽,介面,角色和角色以及部署/操作建模等概念,以達到高層次的系統描述. 這種高層次描述隨後被分解為元件和模組,這些元件和模組可以單獨分析,設計和構建,並整合以實現業務目標. SDLC和SAD是產品和系統全生命週期規劃的基石.  物件導向的分析和設計 物件導向的分析和設計 (OOAD) 是分析問題領域以開發一個概念模型的過程,然後可以用來指導開發. 在分析階段,程式設計師通過與利益相關方的採訪,制定書面要求和正式的願景檔案.  由OOAD產生的概念模型通常由用例,類和互動圖組成. 它也可能包括一個使用者介面模型.  輸出工件不需要完全定義才能作為物件導向設計的輸入;分析和設計可以並行進行. 在實踐中,一個活動的結果可以在<unk>代過程中為另一個活動提供食物.  一些典型的OOAD輸入器件:  概念模型:概念模型是物件導向分析的結果. 它捕捉了問題領域的概念. 概念模型顯然獨立於實施細節. 使用案例:使用案例是對事件序列的描述,這些事件一起完成了所需的任務. 每個用例都提供了情景,說明系統應該如何與參與者 (使用者) 進行互動. 參與者可能是終端使用者或其他系統. 使用案例可以通過圖表進一步闡述. 這些圖表可以識別行為者及其所執行的過程. 系統序列圖:系統序列圖 (SSD) 是一個圖片,用於特定的用例,顯示行為者生成的事件,他們的順序,包括系統間事件. 使用者介面文件:展示和描述使用者介面的文件. 資料模型:資料模型描述了資料元素之間的關係. 在設計階段之前建立資料模型. 物件導向的設計直接從資料模型繪製. 關係設計更復雜. 系統生命週期 系統生命週期是對系統或擬議系統的檢視,它涉及其存在的所有階段,包括系統構想,設計和開發,生產和/或建造,分銷,運營,維護和支援,退役,逐步淘汰和處置.  概念設計 概念設計階段是檢查已識別的需求,定義潛在解決方案的要求,評估潛在解決方案,並制定系統規範的階段. 系統規範代表了技術要求,將為系統設計提供總體指導. 由於該檔案決定了所有未來的發展,因此在概念設計審查確定系統規範正確地解決了激勵需求之前,該階段無法完成.  概念設計階段的關鍵步驟包括:  需要識別 可行性分析 系統要求分析 系統規格 概念設計審查 系統初步設計 在系統生命週期的這一階段,執行所需系統功能的子系統按照系統規範進行設計和規範. 定義了子系統之間的介面,以及總體測試和評估要求. 在此階段完成後,製作出足以進行詳細設計和開發的開發規範.  在初步設計階段的關鍵步驟包括:  功能分析 要求分配 詳細的權衡研究 系統選項的綜合 工程模型的初步設計 開發規格 設計初步審查 例如,作為維蒂銀行系統分析師, 維蒂銀行是斐濟發展最快的銀行. 偏遠農村地區的客戶難以獲得銀行服務. 他們需要幾天甚至幾周的時間才能到達一個地方, 為了滿足客戶的需求, 銀行請您檢查現有系統, 並提出解決方案或建議, 如何為現有系統提供滿足其需求.  詳細設計和開發 這一階段包括詳細設計的開發,將初始設計工作帶入完成的規範形式. 這項工作包括系統與預期環境之間的介面的規範,以及系統的後勤,維護和支援要求的全面評估. 詳細設計和開發負責生產產品,工藝和材料規格,並可能導致開發規格的重大變化.  詳細設計和開發階段的關鍵步驟包括:  詳細設計 詳細的綜合 工程模型和原型模型的開發 開發規範的修訂 產品,工藝和材料規格 關鍵設計審查 生產和建設 在生產和/或施工階段,產品按照產品,工藝和材料規格所規定的要求進行製造或組裝,並在目標操作環境中部署和測試. 系統評估是為了糾正缺陷並使系統適應持續改進.  產品構建階段的關鍵步驟包括:  系統元件的生產和/或建造 驗收測試 系統的分佈和執行 執行測試和評估 系統評估 使用和支援 一旦完全部署,該系統將用於預期的操作作用,並在其操作環境中進行維護.  使用和支援階段的關鍵步驟包括:  使用者環境中的系統操作 變化管理 改進系統修改 系統評估 逐步淘汰和處置 系統的有效性和效率必須不斷評估,以確定產品何時達到其最大有效生命週期. 考慮因素包括:持續存在的運營需求,運營要求與系統效能之間的匹配,系統逐步淘汰與維護的可行性,以及替代系統的可用性.  階段  本部分包含參考文獻,相關閱讀或外部連結列表,但其來源仍然不清楚,因為它缺乏內聯引用. 請通過引入更精確的引用來幫助改進這一部分. (2023年1月) (瞭解如何以及何時刪除此模板訊息) 系統調查 在此步驟中,考慮當前可能受到影響的優先事項以及應如何處理它們. 可行性研究確定是否建立一個新的或改進的系統是合適的. 這有助於估計成本,效益,資源需求和特定使用者需求.  可行性研究應解決運營,財務,技術,人力因素以及法律/政治方面的問題.  分析 分析的目標是確定問題所在. 這一步涉及將系統分解成部分,分析專案目標,分解需要建立的內容,並讓使用者定義要求.  設計 在系統設計中,功能和操作被詳細描述,包括螢幕布局,業務規則,流程圖和其他文件. 模組化設計減少了複雜性,並允許輸出將系統描述為子系統集合.  設計階段將已經定義的要求作為輸入. 每個要求都需要一組設計元素.  設計文件通常包括功能層次圖,螢幕布局,業務規則,流程圖,虛擬碼和完整的資料模型與資料字典. 這些元素描述了系統的足夠細節,使開發人員和工程師可以在最小的額外投入下開發和交付系統.  測試 在軟體測試中, 程式碼在不同級別進行測試. 通常會進行單元,系統和使用者驗收測試. 已經採用了許多測試方法.  以下型別的測試可能是相關的:  測試路徑 資料集測試 單元測試 系統測試 整合測試 黑盒測試 白盒測試 迴歸測試 自動化測試 使用者驗收測試 軟體效能測試 培訓和過渡 一旦通過測試穩定了系統,SDLC確保在系統轉換為支援員工和終端使用者之前準備並執行適當的培訓. 培訓通常包括支援人員的操作培訓以及終端使用者的培訓.  培訓後,系統工程師和開發人員將系統過渡到其生產環境.  運營和維護 維護包括更改,修復和增強.  評價 SDLC的最後階段是測量系統的有效性,並評估潛在的改進.  生命週期 管理和控制  與管理控制相關的SDLC階段 本部分描述了SDLC階段目標,主要成果,建議任務的描述,以及有關控制目標的總結,以實現有效管理. 專案經理在執行專案時建立和監控控制目標至關重要. 控制目標是對所期望的結果或目的的明確陳述,應該在整個專案中定義和監控. 控制目標可以分為主要類別 (領域),並與SDLC階段相關,如圖所示.  為了管理和控制一個重要的SDLC計劃,工作分工結構 (WBS) 捕獲和安排工作. 專案經理應在專案筆記本的"專案描述"部分儲存WBS和所有程式材料.專案經理選擇最能描述專案的WBS格式.  圖表顯示覆蓋範圍涵蓋了SDLC的多個階段,但相關的MCD顯示了SDLC階段的對映. 例如,分析和設計主要作為採購和實施領域的一部分,而系統構建和原型主要作為交付和支援的一部分.  工作分工結構組織  工作分工結構 在WBS的上部分提供了專案範圍和時間表的概述. 它還應該總結主要階段和里程碑. 中間部分是基於SDLC階段. 業務經營計劃的要素包括要完成的里程碑和任務,而不是要進行的有截止日期的活動. 每個任務都有可測量的輸出 (例如分析文件). 一個WBS任務可能依賴於一個或多個活動 (例如編碼). 需要承包商支援的專案的部分應該有一個工作宣告 (SOW). SOW的開發不是在SDLC的特定階段進行的,而是為了包括承包商可能進行的SDLC過程中的工作而進行的.  基線 在SDLC的五個階段中的四個階段之後建立了基線,並且對模型的<unk>代性質至關重要. 基線成為里程碑.  功能基線:在概念設計階段後建立. 分配的基線:在初步設計階段後確定. 產品基線:在詳細設計和開發階段後建立. 更新的產品基線:在生產構建階段後建立.
系統開發生命週期有7個階段. 它們是系統調查,分析,設計,測試,培訓和過渡,運營和維護和評估