傳統軟體開發VS敏捷式軟體開發 (Agile Software Development)

標籤：資料庫表   預算   情況   決策   計算   等等   詳細設計   中間   ext   

在上世紀60年代，由於電腦的計算能力顯著提升，人們需要處理問題的複雜程度也得到提升，導致了一系列問題比如項目運行超過預算、項目運行超過時間、軟體十分低效、軟體品質很低、軟體無法滿足需求、項目缺乏管理，代碼難以維護、軟體難以交付，稱為軟體危機。人們意識到，軟體開發不僅僅是讓程式員編寫程式那麼簡單，而是一項工程，需要科學的開發方法，從而人們提出了軟體工程的概念，採用工程化的方法對軟體開發進行管理。而在當今，軟體工程中軟體開發方法主要分為傳統軟體開發和敏捷式軟體開發 (Agile Software Development)。本文主要介紹這兩種軟體開發方法以及他們各自的優缺點。

一、  傳統軟體開發

傳統的軟體開發過程是一個由文檔進行驅動的過程，它將開軟體開發過程分為可行性分析和項目開發計劃、需求分析、概要設計、詳細設計、編碼、測試、維護七個階段，每個階段的輸出是下一個階段的輸入。在每一個階段，開發人員必須要完成這個階段的任務，並編寫文檔，然後才能進入下一個階段。

瀑布式模型就是一個典型的傳統軟體開發過程。它是一個線性開發模型，自上而下，如同瀑布一般緊密串連，環環相扣，每個階段的交流都是以文檔的形式來進行的。

 

瀑布模型軟體開發流程圖

瀑布模型分為定義階段、開發階段、維護階段三個階段。在定義階段，開發人員需要完成對軟體的定義，設計出軟體的基本架構結構，還要完成對軟體的需求分析。開發階段，開發人員需要根據利益相關者的需求進行分析後，構建出設計藍圖，包括UML圖 、資料庫表、API介面等等。值得注意的是，在開發階段，架構師可以做出一些有預見性的假設，除了客戶的需求以外，還要對客戶可能有的需求進行假設，在設計時留有一定的餘地，因為客戶的需求在軟體開發的過程中可能出現變化，導致需要修改程式，所以要規劃好大量的功能需求和非功能需求，以避免重構從軟體架構帶來的損失。在維護階段，開發人員根據使用者使用軟體的反饋，以及客戶對軟體的新增需求對軟體進行維護，以滿足客戶的要求。

在瀑布模型的每個階段結束時，需要進行嚴格的檢查，以確保該階段不會出現問題。當發現問題是，就順藤摸瓜似的不斷向上一層尋找問題，直到尋找到了問題的所在，解決了問題以後再一步步向下進行。

瀑布模型有一定的優點：

1. 瀑布模型按照軟體開發的工序，將大的過程分解成一個個小的過程，便於項目組的開發人員進行協同工作
2. 瀑布模型為每個階段都提供了檢查點，在每個階段結束時都要進行嚴格的檢查，在檢查通過進入下一階段以後，開發人員就只需要關注下一階段。

但同時瀑布模型具有巨大的缺陷：

1. 由於開發過程是線性，開發過程一般不能逆轉，否則代價太大。
2. 實際的項目開發很難嚴格按該模型進行。
3. 客戶往往很難清楚地給出所有的需求，而該模型卻要求如此。 
4. 軟體的實際情況必須到項目開發的後期客戶才能看到，這要求客戶有足夠的耐心。
5. 瀑布模型必須編寫大量的冗餘文檔，而缺乏人與人之間的交流，拉低了工作效率。

因為種種缺點，瀑布模型有很大的局限性，只適用於那些需求明確，並且極少變動的軟體。所以瀑布模型在現在已經很少被使用，而在瀑布模型線性開發過程的基礎上，又產生了其他的一些軟體開發方法，例如增量模型實際上就是分段的線性模型，螺旋模型則是串連的彎曲了的線性模型，在其他很多模型中也能找到線性模型的影子。這些不同的軟體開發方法使用與不同軟體的開發。

快速原型模型：不要求需求預先完備定義，支援使用者參與，支援需求的漸進式完善和確認，能夠適應使用者需求的變化，適用於需求複雜、難以確定、動態變化的軟體系統。

增量模型：軟體產品是被增量式地一塊塊開發的，允許開發活動並行和重疊，適用於技術風險較大、使用者需求較為穩定的軟體系統。

迭代模型：不要求一次性地開發出完整的軟體系統，將軟體開發視為一個逐步擷取用廣需求、完善軟體產品的過程，適用於需求難以確定、不斷變更的軟體系統。

螺旋模型：結合瀑布模型、快速原型模型和迭代模型的思想，並引進了風險分析活動，適用於需求難以擷取和確定、軟體開發風險較大的軟體系統。

二、  敏捷式軟體開發 (Agile Software Development)

雖然傳統軟體開發在一定程度上解決了軟體危機，但是其冗長複雜的開發流程卻飽受開發人員的詬病，因此人們又提出了一種快速、靈巧、輕量級的開發方法，即敏捷式軟體開發 (Agile Software Development)。

2001年，由17位軟體開發專家組成的敏捷聯盟簽署了敏捷式軟體開發 (Agile Software Development)聲明，他們認為：個人和個人之間的交流勝過開發工具和過程、可啟動並執行軟體勝過寬泛發文檔、客戶合作勝過合約談判、對變更的良好響應勝過按部就班地遵循計劃。

在敏捷式軟體開發 (Agile Software Development)的過程中，要求團隊能夠有效地響應變化，同時它鼓勵團隊溝通，強調軟體的交付而不是中間產品，將客戶也作為團隊中的一員。

敏捷式軟體開發 (Agile Software Development)的擁護者們強調“人的因素”，根據特定人員和團隊來塑造過程。它對團隊成員有以下要求：基本能力、共同目標、精誠合作、決策能力、模糊問題解決能力、、相互信任和尊重、自組織。

在敏捷開發的過程中，使用最廣泛的一個方法就是極限編程。它更加看重Team Dev和客戶之間的口頭交流而不是大量的文檔。

為了簡潔和能夠有效地響應變化，極限編程要求開發人員只需要對即時需求做出設計，而不考慮長遠需求，從而使得代碼簡單並且當需求變化時能夠實現重構。

 

極限編程過程

極限編程使用物件導向方法作為開發範型，包含了策劃、設計、編碼、測試4個架構活動的規則和實踐。

策劃活動是團隊技術成員理解軟體的商業背景和客戶需求的階段，在這個階段，開發人員傾聽一系列“使用者故事”，描述需要的功能，並對其分配相應的優先順序。

在設計活動中，開發人員遵循保持簡潔原則，不鼓勵額外的設計。並使用CRC卡來確定與當前軟體增量相關的物件導向類。

在編碼活動中，開發人員首先開發本次編碼所需要的測試單元，編碼人員則以實現功能已通過測試單元為目標，而不需要其他的任何東西。

在測試階段，根據客戶所規定的技術條件，向客戶展示軟體的功能。

除了極限編程以外，還有許多其他的敏捷編程模型，比如自適應軟體開發、Scrum、動態系統開發方法、Crystal、特徵驅動開發、精益軟體開發、敏捷建模、敏捷統一過程，本文在此不一一介紹了。

與傳統軟體開發方法相比，敏捷式軟體開發 (Agile Software Development)有著一些很明顯的優點。它以人為本，更加註重人與人之間的交流而不是生硬的文檔。客戶也作為團隊的一員參加到軟體開發過程中來，這樣可以與客戶進行更好的溝通交流，以便更好地響應需求的變化。但是，敏捷式軟體開發 (Agile Software Development)也有一些缺陷，它是一種輕量級的開發方法，它的快速是犧牲問題分析和方案設計來實現的，因此只適用於小規模的軟體工程，在面對大規模的工程是就有可能出現混亂。

參考資料

1. 智庫百科：瀑布模型
2. CSDN部落格：敏捷式軟體開發 (Agile Software Development)與傳統軟體工程的比較
3. 《軟體工程實踐者的研究方法》
4. 愛編程部落格：傳統軟體開發VS.敏捷式軟體開發 (Agile Software Development)

傳統軟體開發VS敏捷式軟體開發 (Agile Software Development)