課堂

軟件產品生命週期的階段 高質量軟件的開發需要許多因素：合格的團隊、工作流規劃、產品符合客戶期望、按時完成。 1.需求分析 這個階段可以被認為是最重要的階段之一。項目的成功取決於它。這一切都始於項目目標的形成。然後列出要完成的任務和未來軟件的範圍。之後，明確了項目的條件、期限和預算。在第一階段的最後階段，開發團隊的技術任務得到批准。 2.設計階段 設計從定義應用程序架構、功能、功能要求和接口開始。然後在程序和用戶之間分配功能，考慮各種組件的要求。產品設計必須考慮客戶的期望及其實

級聯模型設備 瀑布模型，也稱為 Waterfall，是最著名的軟件開發方法之一。該模型的作者是溫斯頓羅伊斯。1970 年，他在一篇詳細介紹其優缺點的文章中描述了他的創新的本質。在同一個地方，他解釋瞭如何將這個模型細化為迭代模型。最初，在瀑布模型中，開發階段按以下順序進行： 需求的定義和協調； 立項； 編碼; 創建軟件產品的工作版本； 測試和調試； 軟件安裝； 支持。 根據瀑布模型，開發人員執行的操作是按順序發生的——逐點進行。首先，正在完成工作以確定並同意以待完成列表的形式的

敏捷模型 靈活（敏捷）方法通過將工作流移動到幾個小周期中來幫助降低軟件開發的風險。這些週期稱為迭代，通常持續兩到三週。 迭代就像一個由任務組成的小型軟件項目，每個任務都會改進功能。其中包括：制定計劃、評估需求、就項目達成一致、編寫代碼、測試和創建技術文檔。 對於一個完整的軟件版本來說，一次迭代通常是不夠的。然而，敏捷的好處是項目的一小部分在每次迭代結束時都準備好進行評估。這允許團隊成員更改優先級以進行進一步的工作，而無需等待最終版本。 應用“敏捷”開發方法，您可以在每次迭代後

Scrum 的歷史 自 1970 年溫斯頓·羅伊斯 (Winston Royce) 的“管理大型軟件系統的開發”報告發表以來，許多人都在嘗試尋找一種可以消除瀑布式開發模型缺點的方法。“瀑布”的替代方法是 Scrum 方法，現在將對其進行討論。 Scrum 於 1986 年得名於 Takeuchi 和 Nonaki 的著作《新產品開發的新規則》。本文檔認為，實現目標的最有效方法是為開發人員提供明確的行動計劃。 1995 年，Sutherland 和 Schweiber 出版了另

用戶故事 用戶故事是陳述開發中軟件需求的有效方式。這些故事包含代表軟件用戶的簡短建議。 由於在 Scrum 方法中，設定目標通常是客戶或軟件所有者的特權，因此它們被認為是影響開發過程的主要方式。每個用戶故事在文本量和呈現的複雜性方面都有限制。歷史通常寫在一張小紙上，這本身就限制了體積。 借助用戶故事，您可以記錄客戶的願望并快速響應市場需求。 用戶故事應該被視為一種簡單的需求度量，因為它不包括驗收測試程序。用戶故事的編寫必須符合准入程序。這將確保用戶故事實現其目標。 故事結構如

衝刺計劃 Sprint 計劃是 Scrum 衝刺的初始階段。它決定了衝刺期間的工作範圍和工作方式。整個 Scrum 團隊都參與計劃。 衝刺是明確定義的時間段，在此期間必須完成指定的工作。衝刺需要在開始之前進行計劃。首先，您需要確定衝刺的持續時間和目標。 在規劃研討會上，任務列表和衝刺目標達成一致。為團隊注入正確的工作動力非常重要，這樣每個成員都專注於成功。 如果衝刺計劃不周，那麼這可能會導致團隊失敗。開發人員將無法滿足對他們的期望，因為事實證明這些任務是不切實際的。 計劃衝刺

V型 V 型模型的原理在很多方面與級聯模型相似。大多數情況下，它用於不間斷運行極其重要的系統中。這是醫療機構維護病人生命支持的軟件，緊急封鎖系統和類似的軟件。 該模型的一個特點是它側重於測試處於開發早期階段的軟件，包括設計。測試與開發過程並行進行——例如，在編寫代碼時執行單元測試。 什麼時候應該使用 V 模型？ 如果軟件產品需要嚴格測試，那麼 V 模型（驗證和驗證）的原則在這種情況下是最合理的。 對於具有明確定義要求的中小型項目。 在大量合格的測試人員面前。 增量模型 增量模