1:啟動階段
在這一階段,公司或項目組將確定軟件的大方向,開發,將對軟件的功能、性能、可靠性和接口給出想法,研究完成項目的可行性,并評估各種資源、成本和預期效益,以便于開發任務的相應實施計劃。
2.需求階段
軟件的開發方面和需求方一起討論,以確定軟件的開發目標和可行性。至于軟件應該具備什么功能,初的需求必須由用戶提供,然后解決方案才會產生。
3.設計階段
UI設計人員根據產品原型進行界面渲染,提供界面標注。較后根據主界面,他們提供了一套《UI設計規范》。UI設計規范主要定義了常見的界面形式和大小,便于開發快速開發UI設計往往涵蓋交互內容。
4.開發舞臺
在這個階段,軟件設計的結果被轉換成計算機可執行的程序代碼。在程序編碼之前,需要制定一個統一的、標準的編碼規范。確保程序的可讀性和可維護性。提高程序的運行效率。雖然這個過程的大部分用于編寫代碼,但它可能需要再次進行技術預研和需求確認。一般編碼過程也需要服務器和手機聯合調試。編碼后需要進行功能審查。
5.測試階段
測試人員對已完成或部分完成的軟件模塊進行嚴格的測試,通常由獨立的團隊進行,工作分為單元測試、集成測試和系統測試。
6:操作和維護
與客戶或上級達成協議后,系統將投入試運行,穩定后上線。
瀑布模型是1970年羅伊斯提出的軟件開發模型。從模型的名字可以知道,模型遵循從上到下一次完成整個軟件產品的開發方式。瀑布模型將軟件開發過程分為六個階段:計劃需求分析軟件設計編碼測試運維。開發過程如圖1-1所示。
圖1-1瀑布模型
在瀑布模型中,軟件開發的活動是嚴格按照這條線進行的,下一個階段只有在一個階段的任務完成后才能開始。軟件開發的每個階段都必須產生結果,結果經過驗證后可以作為下一階段的輸入,然后下一階段才能順利進行。如果結果驗證失敗,您需要返回修改。
瀑布模型為整個項目劃分了清晰的檢查點。當一個階段完成時,它只需要把所有的精力放在它后面的開發上。它有利于大型軟件開發人員的組織和管理以及工具的使用和研究,并能提高開發的效率
但是瀑布模型嚴格按照線性方式進行,不能適應用戶需求的變化。用戶只能等到較后才能看到開發的結果,這就增加了開發的風險如果開發人員和客戶對需求的理解有偏差,終開發完成后,終的結果可能會和客戶的需求相差甚遠。在使用瀑布模型開發軟件時,如果在項目完成后發現早期錯誤,修改原始錯誤將花費大量成本。瀑布模型要求每個階段都必須產生結果,這將不可避免地增加文檔的數量并增加軟件開發的工作量
此外,對于現代軟件來說,軟件開發不同階段之間的關系大多不是線性的,因此很難使用瀑布模型開發軟件。因此,瀑布模型不再適合現代軟件開發,已經逐漸被拋棄。
猜猜你喜歡什么: