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

標籤：共用   時間   缺陷   世紀   原則   使用者需求   程式員   介紹   進度   

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

軟體工程這一術語1968年被提出，之後美國軟體工程專家巴利·玻姆對十多年間研究軟體工程的專家學者們提出的一些準則與信條，於1983年對提出軟體工程的七條基本定理，將軟體工程這一學科具體化，軟體工程中開發與管理軟體的方法也不斷完備。而敏捷式軟體開發 (Agile Software Development)於2001年由Kent Beck和其他16位知名軟體開發人員提出，敏捷開發是人們對於傳統軟體開發方式的一種提出的新的挑戰。本文將具體介紹軟體傳統工程與敏捷式軟體開發 (Agile Software Development)兩種方法，並對兩者進行對比分析。

一、傳統軟體工程

軟體工程的產生與二十世紀六十年代的“軟體危機”有很大的關係，由於當時的軟體開發人員採取的方式未工程化，軟體開發中遇到很多難以解決的問題，如軟體生產不能滿足需求，開發時間與成本難以估計以及軟體可維護性差等。這使得人們開始考慮採用工程化方法來研製與維護軟體，於是軟體工程這一技術就這樣誕生了。軟體工程具有多層次，軟體工程的基礎在於軟體過程，軟體過程是指軟體構建過程中執行的一系列活動、動作與任務的集合。軟體工程的過程架構定義五種活動：溝通、策劃、建模、構建與部署。只有這些活動並不能確定於過程之間的相互關係，因此需要一些模型來定義這些關係。

常見的傳統軟體工程過程模型:

1、 瀑布模型

瀑布模型提出一個系統的軟體開發方法，通過策劃，建模，構建和部署的過程，最終生產一個完整的軟體並提供軟體維護。瀑布模型是軟體工程最早的模型，但是在實際的運用中，出現很多問題。瀑布模型需要客戶明確需求，但是不能適應需求的不確定性，客戶只有在軟體完全完成了之後才能得到能夠執行的軟體，一些早期錯誤需要等到測試階段才能發現，這些問題使得瀑布模型被現代軟體工程界所拋棄。軟體工程開發過程中經常遇到各種的變化，而瀑布模型往往不能夠適應這些工作，但是在工作以線性方式完成時，瀑布模型還是一個非常有用的模型。事實上線性方法是人們最容易掌握並使用的方法，當人們遇到用線性方法解決不了的問題是，往往會考慮將問題分解為一系列線性問題，然後逐個解決。 

2、 增量模型

增量模型實質就是分段的線性模型，增量模型發布一系列稱為增量的版本，逐漸為使用者提供更多的功能。增量模型在每個階段使用線性模型，增量模型在每個增量都能運行，這樣能夠很好的適應變化，客戶也能夠一直看到軟體的開發，早期發生的錯誤能夠得到解決，降低開發風險。增量模型能夠解決瀑布模型的幾個問題，但是仍然還是有一定的缺陷:軟體的體系架構需要保證在新加構件時，能夠對原系統無影響。

3、 螺旋模型

螺旋模型是一種演化過程模型，它結合了原型的迭代性質與瀑布模型的系統性與可控性的特點，能夠有快速開發完善軟體版本。螺旋模型最大的特點是具有其他模型不具備的風險分析，使得軟體在面臨重大風險時能夠停止，減少損失。螺旋模型從圓心開始順時針方向演化，第一圈一般開發出軟體規格說明，在接下來的每次迭代中逐步完善，最終得到最終版本。螺旋的沒圈都會跨過多個地區，需在每個迭代的每個地區中不斷調整專案計劃，直到迭代結束。螺旋模型適合開發大型的系統級應用。螺旋模型每個迭代都植入軟體測試並累計開發成本，使得軟體品質得到嚴格保證，而且開發成本容易掌握。但是螺旋模型的風險管理支出可能會過於龐大。           

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

敏捷開發是一種新型的軟體開發方法，具有應對快速變化的需求的能力。敏捷開發方法來源於2001年的一次軟體開發人員的集會，他們在會上成立“敏捷聯盟”並簽署了“敏捷式軟體開發 (Agile Software Development)宣言”，其中包括以下要點：

1、個人與這些個人之間的交流勝過了開發流程與工具

2、可以工作的軟體勝過了詳盡的文檔

3、客戶合作勝過了詳細的文檔

4、對變化的響應勝過了嚴格地遵循計劃

敏捷聯盟定義了12條原則：

1、對我們而言，最重要的是通過儘早和不斷交付有價值的軟體滿足客戶需要。

2、我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。

3、經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。

4、業務人員和開發人員應該在整個項目過程中始終朝夕在一起工作。

5、 圍繞鬥志高昂的人進行軟體開發，給開發人員提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。

6、在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。

7、可以工作的軟體是進度的主要度量標準。

8、 敏捷過程提倡可持續開發。出資人、開發人員和使用者應該總是維持不變的節奏。

9、對卓越技術與良好設計的不斷追求將有助於提高敏捷性。

10、簡單——儘可能減少工作量的藝術至關重要。

11、最好的架構、需求和設計都源自自我組織的團隊。

12、每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。

敏捷開發相比於其他方法更強調軟體的適應性，而不是預見性。從本質上來講，敏捷式軟體開發 (Agile Software Development)是為了克服傳統軟體工程中的弱點而形成的。在現實生活中，使用者需求不斷改變，很多情況下，完全無法充分定義需求。

極限編程是敏捷開發使用最廣泛的一個方法，。極限編程包括策劃、設計、編碼、測試4個階段。極限編程有12個實踐原則：

1.計劃的制定：包括客戶選擇的項目大小、程式功能的優先順序、各個版本的合成和發布日期。 

2.小版本：用最少的代碼工作量帶來最大的業務價值。 

3.簡單設計：通過所有測試，沒有重複和費解的邏輯代碼，簡單的設計能保證代碼的簡單。

4.測試：一個功能存在的前提是有一個測試能夠驗證它，任何有被破壞的可能的代碼就必須有一個對應的測試。 

5.持續整合：大量減少在整合中耗費的時間，減少團隊開發問題。 

6.重構：確保加入新功能後代碼仍保持簡單，從而保證簡單的代碼仍然能夠運行所有的測試。 

7.配對編程：提供持續的資訊反饋和確保正在編程的人進行重構、測試和遵守編碼通訊協定，實現代碼共用目的。 

8.代碼共用：在通過測試的前提下，任何一個人都能夠對系統做出修改。

9.每周只工作40小時：充分利用你的時間，一個星期工作40小時已經足夠了。 10.現場客戶：討論，使用程式員和客戶都能夠的語言描述功能。

11.隱喻：普通語言和術語的集合，用來預見項目中的功能。

12.編碼通訊協定：遵守編碼通訊協定，讓其它程式員明白代碼，減少不必要的溝通。

所有敏捷過程模型中使用最廣泛的就是極限編程，當然也有很多其他模型，比如自適應軟體開發、Scrum、動態系統開發方法等，這裡就不加以討論了。

三、傳統軟體工程與敏捷式軟體開發 (Agile Software Development)的對比

敏捷式軟體開發 (Agile Software Development)相對傳統軟體開發的優勢：

1、 敏捷開發強調適應性，因此軟體開發適應性更加強。就拿軟體變化的成本來說，敏捷開發比傳統軟體工程少得多，這就是因為敏捷開發適應性更強。

2、 敏捷開發交付周期短，強調儘早將可用的功能交付使用，這樣有利於軟體在整個項目中持續改善。

3、 敏捷開發的工作效率更加高，人力資源得到更充分使用。

敏捷式軟體開發 (Agile Software Development)相比傳統軟體工程的劣勢：

1、敏捷開發文檔也傳統軟體工程相比顯著減少，因此團隊之間的交流就需要增加，而一旦工程很大的話，團隊之間的交流會變得很困難。

2、對個人能力要求很高，團隊人員要求開發能力強，團隊之間溝通能力也不能弱。

 

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