軟體開發生命週期定義v1.0
sdlc模型 (software development lifecycle model)
從第乙個也是最古老的「瀑布式」sdlc模型演變而來，它們的種類顯著擴大。sdlc模型的多樣性由眾多產品型別預先確定 - 從簡單的**到複雜的醫療軟體。如果你採用下面提到的sdlc模型之一作為基礎 - 無論如何，它應該根據產品，專案和公司的特徵進行調整。下面給出了最常用，最受歡迎和最重要的sdlc模型。
瀑布sdlc模型
瀑布 - 是乙個級聯sdlc模型，其中開發過程看起來像流程，一步一步地進行分析，**，實現，測試，實施和支援階段。該sdlc模型包括完全逐步執行每個階段。該過程嚴格記錄並預定義，具有該軟體開發生命週期模型的每個階段所期望的功能。
好處
劣勢
簡單易用和理解
只有在最後乙個階段結束後，軟體才會準備就緒
由於其剛性，管理簡單：每個階段都有明確的結果和流程審查
高風險和不確定性
發展階段逐一進行
不是複雜和物件導向專案的最佳選擇
適用於要求明確且不模稜兩可的小型或中型專案
不適合長期專案
易於確定開發周期中的關鍵點
階段的進展很難衡量，但仍處於發展階段
易於分類和確定任務的優先順序
整合在最後完成，不提供預先識別問題的選項
wate***ll sdlc模型的特點：
準確記錄了這些要求
產品定義穩定
技術堆疊是預定義的，這使得它不是動態的
沒有模稜兩可的要求
該專案很短
迭代sdlc模型
在專案開始之前，迭代sdlc模型不需要完整的需求列表。開發過程可以從對功能部件的要求開始，可以在以後擴充套件。該過程是重複的，允許為每個迴圈製作新版本的產品。每次迭代（持續兩到六周）都包括開發系統的單獨元件，然後，將此元件新增到之前開發的功能中。說到數學術語，迭代模型是順序逼近方法的實現; 這意味著逐漸接近計畫的最終產品形狀。
好處
劣勢
某些功能可以在開發生命週期的開始階段快速開發
迭代模型比瀑布模型需要更多資源
可以應用並行開發
需要持續管理
進展很容易衡量
可能會出現架構或設計問題，因為在短期規劃階段並未預見到所有要求
較短的迭代是
- 更容易的測試和除錯階段
小專案的糟糕選擇
由於首先完成高風險任務，因此更容易控制風險
這個過程很難管理
在下乙個
sprint
中可以防止在一次迭代中定義的問題和風險
即使在專案的最後階段，風險也可能無法完全確定
靈活性和準備變化的要求
風險分析需要高素質專家的參與
迭代模型的用例：
螺旋sdlc模型
螺旋模型 - 是sdlc模型，它分階段結合了架構和原型。它是iterative和wate***ll sdlc模型的組合，具有重要的風險分析重點。螺旋模型的主要問題是確定進入下一階段的正確時機。建議將初步設定的時間範圍作為此問題的解決方案。即使前一階段的工作尚未完成，也將根據計畫完成向下一階段的轉變。該計畫是根據統計資料引入的，即使從個人開發人員的經驗來看，也可以在之前的專案中收到。
好處
劣勢
生命週期分為小部分，如果風險集中度較高，則可以提前完成階段以解決問題
可能相當昂貴
開發過程準確記錄，可根據變化進行擴充套件
風險控制需要高技能專業人員的參與
可伸縮性允許在相對較晚的階段進行更改並新增新功能
對小專案可能無效
早期的工作原型已經完成
- 使用者可以更快地指出這些缺陷
大量的中間階段需要過多的文件
旋模型的用例
客戶不確定要求
預計在開發周期中會進行重大編輯
具有中級或高階風險的專案，防止這些風險非常重要
應該在幾個階段發布的新產品，以獲得足夠的客戶反饋
v形sdlc模型
v形sdlc模型是經典瀑布模型的擴充套件，它基於每個開發階段的相關測試階段。這是乙個非常嚴格的模型，下一階段僅在前一階段之後開始。這也稱為「驗證和驗證」模型。每個階段都有當前的過程控制，以確保可以轉換到下乙個階段。
好處
劣勢
v形模型的每個階段都有嚴格的結果，因此很容易控制
缺乏靈活性
測試和驗證在早期階段進行
小專案的糟糕選擇
適用於需求穩定且清晰的小型專案
相對較大的風險
v形模型的用例：
敏捷sdlc模型
在每次開發迭代之後的敏捷方法中，客戶能夠看到結果並理解他是否滿意或不滿意。這是敏捷軟體開發生命週期模型的優勢之一。其缺點之一是，由於缺乏明確的要求，很難估計資源和開發成本。極限程式設計是敏捷模型的實際應用之一。這種模型的基礎包括每週短暫的會議 - sprint是scrum方法的一部分。
好處
劣勢
功能需求的更正被實施到開發過程中以提供競爭力
由於永久性變化而無法衡量最終成本
專案按短而透明的迭代劃分
團隊應該是高度專業和客戶導向的
靈活的變更過程使風險最小化
新要求可能與現有架構衝突
快速發布第乙個產品版本
通過所有更正和更改，專案可能會超出預期時間
敏捷模型的用例：
使用者需求動態變化
由於許多迭代，實施的更改的**更低
與瀑布模型不同，它只需要初始計畫來啟動專案
階段一.計畫和需求分析 (planning and requirement analysis)
每個軟體開發生命週期模型都從分析開始，與專案干係人討論對最終產品的要求。此階段的目標是系統要求的詳細定義。此外，還需要確保所有流程參與者都清楚地了解任務以及每個需求將如何實施。通常，討論涉及質量保證專家，如果有必要，他們甚至可以在開發階段干預過程中的新增。
階段二.設計專案架構 (project architecture)
在軟體開發生命週期的第二階段，開發人員實際上正在設計架構。所有專案干係人（包括客戶）都會討論此階段可能出現的所有不同技術問題。此外，還定義了專案中使用的技術，團隊負載，限制，時間範圍和預算。最合適的專案決策是根據定義的要求做出的。
第3階段。開發和程式設計 (development and coding)
在批准要求後，該過程進入下一階段 - 實際開發。程式設計師從這裡開始編寫源**，同時牢記先前定義的需求。系統管理員調整軟體環境，前端程式設計師開發程式的使用者介面以及與伺服器互動的邏輯。程式設計本身假設有四個階段
演算法開發
源**編寫
彙編測試和除錯
階段4.測試 (testing)
測試階段包括除錯過程。開發過程中遺漏的所有**缺陷都會在此處檢測到，記錄下來並傳回給開發人員進行修復。重複測試過程，直到刪除所有關鍵問題並且軟體工作流程穩定。
階段5.部署/維護 (deployment)
當程式最終確定並且沒有關鍵問題時 - 是時候為終端使用者啟動它了。新程式版本發布後，技術支援團隊加入。該部門提供使用者反饋; 在利用期間諮詢和支援使用者。此外，此階段還包括所選元件的更新，以確保軟體是最新的，並且不會受到安全漏洞的影響。
RUP軟體開發生命週期
rup rational unified process 統一軟體開發過程，統一軟體過程是乙個物件導向且基於網路的程式開發方 1.起始階段 為專案建立乙個業務案例 1 意圖 建立業務模型用例 明確專案的範圍 2 結果 專案的實際需求 初始的業務案例。包括 成功準則，風險評估，所需資源評估，顯示主要里...
軟體開發生命週期（二）
根據軟體專案型別的不同，有很多的軟體開發周期模型。每種模型都遵循一系列操作的步驟，以適應專案需要，從而確保軟體開發順利進行。流水線模型，可迭代模型，敏捷開發模型，快速開發模型是最受歡迎的模型，而且已經被廣泛應用於生產環境中，如下，他們將會被一一介紹 1.流水線模型 流水線模型是最早的，最為人所熟知的...
軟體開發生命週期模型比較
1 瀑布模型 原理 根據軟體生存週期由立項 需求 策劃 設計 程式設計 測試 發布 維護 退役等階段組成，把每個階段當作瀑布中的乙個台階，把軟體生存過程比喻成瀑布中的流水。開發人員按照階段開發，管理人員按照階段管理。特點 a 文件驅動 b 過程逆轉性很差 適用物件 早期的面向過程的結構化分析 設計 ...