軟體開發生命週期 - tw511教學網

軟體開發生命週期，SDLC 是的縮寫形式。這是一個定義良好的結構化的軟體工程預定的產品軟體開發中的階段序列.

SDLC活動

軟體開發生命週期提供了一系列的步驟，為設計和開發一個軟體產品有效地要遵循。SDLC 框架包括以下步驟:

這是的第一步在哪裡使用者啟動的請求所需的軟體產品。他聯絡服務提供商，並試圖通過談判條款。他提交請求給服務提供商.

這一步將進行軟體開發團隊。團隊從問題域持有與各利益攸關者進行討論，並試圖帶出盡可能多的資訊可能對他們的要求。要求都是設想和隔離到使用者需求、系統需求和功能需求。下列是使用的一些做法 -

需求收集後，球隊又發表了軟體過程的一個粗略的計劃。在此步驟中該球隊的分析，如果軟體可以製成以滿足使用者的所有要求，並且如果存在的軟體是沒有更多的有用的任何可能性。據發現，如果該專案在財務上，實際上和技術上可行的組織以。有很多演算法可用，這有助於開發人員得出結論：一個軟體專案的可行性.

在這一步的開發者決定他們計劃的路線圖，並嘗試提出適合該專案的最好的軟體模型。系統的分析包括了解軟體產品的限制，學習系統相關的問題或變化將在現有的系統中之前進行，識別並解決專案對組織人事等團隊專案的影響分析專案的範圍，並計劃進度和相應的資源。.

下一步是關閉的要求，整個知識和分析的桌子上，設計出的軟體產品。從使用者和資訊聚集在需求收集階段的輸入是該步驟的輸入。該步驟的輸出可以有兩種設計形式;邏輯設計和物理設計。工程師產生的後設資料和資料字典，邏輯圖，資料流圖並在某些情況下偽碼.

這個步驟也被稱為程式設計階段。軟體設計的執行開始在寫程式程式碼中的適當的程式設計語言和有效顯影無差錯的可執行程式的條款.

估計說，整個軟體開發過程中的50％應被測試。錯誤可能會毀了從關鍵級軟體自身刪除。軟體測試是同時由開發商編碼和全面的測試由測試專家在不同級別的程式碼，如模組測試，程式測試，產品測試，內部測試和測試產品在使用者端進行完成的。早期發現的錯誤和他們的補救措施是關鍵可靠的軟體.

軟體可能需要使用的庫，資料庫和其它程式(次)進行整合。 SDLC的這個階段是參與的軟體與外部世界的實體的結合.

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

此階段確認了軟體的操作中的更高的效率和更低的錯誤條件。如果需要，使用者進行培訓，或者資助對如何操作軟體，以及如何保持軟體業務的文件。該軟體被維持及時通過根據發生在使用者端的環境或技術的變化更新的程式碼。這個階段可能會面臨來自隱藏的bug和現實世界的挑戰.

隨著時間的經過，該軟體可以拒絕對效能前方。它可能會完全過時或可能需要強烈了層次。因此，迫切需要消除系統的主要部分就產生了。這個階段包括資料歸檔和必要的軟體元件，逼搶系統，規劃組態的活動，並在終端系統的適當時間終止系統.

軟體開發模式可以幫助開發人員選擇的策略來開發軟體。軟體開發範型有自己的一套工具，方法和程式，這是明確表示，並定義軟體開發生命週期。軟體開發模式或流程模型的一些定義如下:

瀑布模型是最簡單的軟體開發正規化的模型。它說，SDLC的各個階段都會起作用了一個又一個線性的方式。即，當第一階段完成後，然後僅在第二階段將開始等.

該模型假設所有被執行並且發生完全按計劃在前一階段，沒有必要考慮可能出現在下一階段，過去的問題。如果有留在上一步驟中的一些問題，這種模式並不順利。模型的有序性不允許我們回去撤消或重做我們的行動.

這種模式是最適合當開發人員已經設計並在過去開發的同類軟體，並意識到它的所有域.

這種模式導致在疊代的軟體開發過程。它突出的發展中迴圈的方式重複SDLC過程的每一個迴圈後的每一步的處理.

軟體首次開發上非常小的規模，並且隨後所有的步驟，這是考慮到。然後，對每一個後續疊代中，更多的功能和模組設計，編碼，測試，並加入到該軟體。每個周期產生的軟體，它是完整的，並具有比前一個的多個特徵和功能.

每次疊代後，管理團隊可以做的工作的風險管理和為下一次疊代做準備。因為一個迴圈包括整個軟體過程的小部分，這是更容易管理的發展過程，但是它消耗更多的資源.

螺旋模型是兩個，疊代模型和軟體開發生命週期模型的一個組合。可以看出，如果你選擇一個SDLC模型，並與迴圈過程(疊代模型)組合起來作為.

該模型考慮了風險，這往往就未注意到了大多數其他車型。模型開始確定目標和軟體的限制，在一個疊代的起始位置。下一階段是原型設計的軟體。這包括風險分析。然後一個標準的SDLC模型來構建軟體。在下一疊代的計劃的第四階段是製備.

瀑布模型的主要缺點是我們移動到只有前一個結束，也沒有機會回去，如果事情被發現錯誤的後期階段的下一個階段。 V模型提供的軟體在相反的方式各階段的測試手段.

在每一個階段，測試計劃和測試用例被建立，以驗證和根據該階段的要求驗證的產品。例如，在需求收集階段，測試團隊在準備對應於要求所有的測試用例。後來，當產品開發，並準備進行測試，這一階段的測試用例驗證針對其有效性的軟體實現在此階段的要求.

這使得雙方核查和驗證進去並行。該模型也被稱為驗證和確認的模式.

這個模型是最簡單的模型中其形式。它需要很少的規劃，大量的程式設計和大量的資金。該模型概念化圍繞宇宙的大爆炸。科學家說，經過大爆炸很多星系，行星和恆星的演變，就像一個事件。同樣，如果我們放在一起大量的程式設計和資金，你可以達到最佳的軟體產品.

對於這個模型需要非常少量的規劃。它不遵循任何程式，或者有時客戶是不確定的需求和未來的需求。這樣的輸入要求是任意的.

這種模式不適合大型軟體專案，但好的學習和試驗.

對於深度閱讀的SDLC和它的各種模型, 這裡點選.