敏捷軟件開發和傳統軟件工程

1、   傳統軟件工程

從上個世紀60年代開始，人們開始逐漸認識到了確實存在着「軟件危機」 這樣一個事實，軟件開發人員被諸以下列問題困擾：

•  軟件生產不能知足日益增加的須要
•  軟件開發成本和開發進度估計每每不許確
•  軟件開發人員和用戶之間信息交流不充分，用戶對完成的軟件滿意度很低
•  軟件價格昂貴，軟件成本在整個計算機系統中所佔的比例急劇上升，軟件已成爲許多計算機系統中花錢最多的項目
•  軟件質量難以保證
•  軟件可維護性差，程序中的錯誤很難改正，適應性或完善性維護都極其困難

致使危機問題的一個重要緣由，是因爲軟件研製和維護自己是工程性的任務，但軟件人員採起的方式卻未能工程化。爲克服軟件危機，人們開始考慮採用工程化方法和工程途徑來研製和維護軟件。咱們以瀑布模型和螺旋模型兩個模型爲例進行討論。

一、瀑布模型

在傳統的軟件工程模型中，其中瀑布模型是1970年W. Royce提出的最先的軟件開發模型，是經典的預見性軟件開發模型，直到80年代早期，它一直是惟一被普遍採用的軟件開發模型。該模型嚴格規定各階段的任務，上一階段任務輸出做爲下一階段工做輸入。其生命週期劃分爲：

• 可行性研究與計劃（策劃）：對軟件進行可行性分析，估算開發費用和時間等
• 需求分析：向用戶瞭解需求，解決「作什麼」的問題
• 設計：分爲概要設計和詳細設計。對須要解決的問題進行分析，提出解決方案，解決「怎麼作」的問題
• 實現（編碼）：按照設計的結果，採用某種編程語言加以實現
• 測試：編碼結束後，要用大量的數據進行測試，找出其中隱藏的錯誤
• 使用和維護：軟件交付用戶使用後，在運行過程當中仍有可能出錯，並且用戶的需求也有可能改變，所以，軟件須要繼續修改

二、螺旋模型

螺旋模型（Spiral Model）採用一種週期性的方法來進行系統開發。該模型是快速原型法，以進化的開發方式爲中心，在每一個項目階段使用瀑布模型法。這種模型的每個週期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。螺旋模型強調風險分析，使得開發人員和用戶對每一個演化層出現的風險有所瞭解，繼而作出應有的反應，所以特別適用於龐大、複雜並具備高風險的系統。

螺旋模型沿着螺線進行若干次迭代，圖中的四個象限表明瞭如下活動：

• 制定計劃：肯定軟件目標，選定實施方案，弄清項目開發的限制條件；
• 風險分析：分析評估所選方案，考慮如何識別和消除風險；
• 實施工程：實施軟件開發和驗證；
• 客戶評估：評價開發工做，提出修正建議，制定下一步計劃。

螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助於將 軟件質量做爲特殊目標融入產品開發之中。

2、  敏捷開發

雖然傳統軟件工程解決了軟件危機，讓軟件開發變得結構化體系化，但軟件開發的後續依然會產生許許多多的問題，敏捷開發由此誕生。

2001年，敏捷聯盟共同簽署了「敏捷軟件開發宣言」，該宣言聲明：

• 個體和互助高於流程和工具
• 工做的軟件高於詳盡的文檔
• 客戶合做高於合同談判
• 響應變化高於遵循計劃

    敏捷開發強調有效的響應變化，而不是循規蹈矩的遵循制定的計劃，這是敏捷開發與傳統軟件工程最主要的不一樣點。此外敏捷開發將客戶做爲開發團隊的成員以消除隔閡，可以更好更快的交流合做，以期完成項目，由此敏捷開發更能適應客戶的需求變化。

敏捷聯盟爲但願達到敏捷的人們定義了敏捷開發12條原則：

• 咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。
• 即便到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優點。
• 常性的交付能夠工做的軟件，交付的間隔能夠從幾周到幾個月，交付的時間間隔越短越好。
• 在整個項目開發期間，業務人員和開發人員必須每天都在一塊兒工做。
• 圍繞被激勵起來的個體來構建項目。給他們提供所須要的環境和支持，而且信任他們可以完成工做
• 在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。
• 工做的軟件是首要進度度量標準。
• 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該可以保持一個長期的、恆定的開發速度
• 不斷地關注優秀的技能和好的設計會加強敏捷能力。
• 簡單----使未完成的工做最大化的藝術----是根本的。
• 最好的構架、需求和設計出自與自組織的團隊。
• 每隔必定時間，團隊會在如何才能更有效地工做方面進行檢討，而後相應地對本身的行爲進行調整。

咱們以極限編程和scrum爲例進行討論。

一、極限編程（XP）

極限編程是敏捷軟件開發中應用最爲普遍的一個方法，是一個輕量級的、靈巧的軟件開發方法，是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比較簡單的小週期；經過積極的交流、反饋以及其它一系列的方法，開發人員和客戶能夠很是清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際狀況及時地調整開發過程。

極限編程的過程分爲4步：

• 策劃：傾聽用戶故事，肯定軟件須要的輸入輸出及功能特徵並判斷其優先級。
• 設計：嚴格遵照KIS(keep it simple)原則，使用簡單的描述。
• 編碼：團隊開發一系列用於檢測本次發佈的包括全部故事的單元測試，一旦編碼完成當即進行測試來向開發者提供反饋。
• 測試：將我的的測試組織到一個通用測試集，天天進行集成和確認測試，最後進行驗收測試。

 

二、Scrum

Scrum 是當今被普遍應用的敏捷開發模式之一。

Scrum 開發過程是以Sprint 爲增量的迭代開發過程。Sprint 開始時，團隊從已按優先級順序排列好的產品訂單中選擇適合本團隊的項目，與PO 澄清需求並生成一樣按優先級順序排列好的Sprint 訂單，而且保證在本次Sprint 結束前作完。每一個工做日團隊都要收集彙報彼此的任務進程和餘下的任務量。Sprint 結束時小組展現最終的項目果並收集來自團隊以外的反饋，用如下一個Sprint 的自我提高。

3、  兩者對比

傳統軟件工程產生於軟件危機，它使得軟件的開發結構化工程化，起初的確給軟件開發帶來很大收益，但隨着時間的增長，傳統軟件工程循規蹈矩的特色給軟件開發帶來了很大的麻煩：

• 各個階段的劃分徹底固定，階段之間產生大量的文檔，極大地增長了工做量。
• 因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發風險。
• 經過過多的強制完成日期和里程碑來跟蹤各個項目階段。
• 不適應用戶需求的變化。這也是瀑布模型最核心的缺點。

 

由此爲了不傳統軟件工程的弊端，也出現了諸如螺旋模型等軟件開發模型，下降開發風險，加強靈活性。

• 相對於傳統軟件開發，再來看看敏捷開發的優勢
• 客戶成爲開發團隊的一部分;
• 可以頻繁提交能夠工做的中間增量產品;
• 能夠不斷更改項目的需求以適應用戶需求的變化;
• 不需制定詳盡的不切實際的計劃和編寫冗長的文檔使得團隊更加靈活自如
• 強調可應用的軟件，開發週期短

敏捷開發與傳統軟件工程在成本費用方面區別很大，，傳統軟件開發變動成本費隨機化的進展呈現非線性增加，隨時間的增長增加速率也在變快，而敏捷開發而不一樣，其變動成本費用前期隨着時間的增長，增加速率變慢，但某時間節點事後也會增加變快，但遠小於傳統軟件工程。

敏捷開發可以帶來多方面的好處可是它並不適用於全部的項目，全部的產品，全部的人和全部的狀況，也不是徹底對立與傳統軟件工程實踐。敏捷開發也有其缺點：

• 需求易變。太太重視客戶需求，可能會致使爲實現一個需求從而打亂整個軟件工程的計劃。
• 矛盾的客戶需求。客戶需求量過大可能會致使需求的矛盾。
• 需求的非正規表示。需求不少是口頭的非正式的，不能及時發現遺漏或不一致的錯誤
• 正規設計的缺少。開發複雜系統時不能保證軟件體系結構的質量和可維護性。

綜上所述，敏捷開發的確可以在響應用戶需求上比傳統軟件工程更加合適，但並非軟件開發的萬金油，而傳統軟件開發因爲其結構化正規化的設計是的其依然可以有一席之地。

參考資料

一、《軟件工程：實踐者的研究方法（第七版）》Roger S.Pressman

二、Scrum敏捷軟件開發方法實踐中的改進和應用

     陳國棟，羅省賢 計算機技術與發展 第21卷 第12期 2011年12月

三、百度百科 瀑布模型

http://baike.baidu.com/link?url=kfptsC14xgQbv-hojxqBCp6nzel0njgl8waMDUr4E0FI27tDM0cnWS96aZFAOdj9n3KhKU51aFSCVI5j3riFRqhVcnezRUXtUkLaCN3q-blfT59btSlZ2Jb4VUPK-8zk

四、百度百科 螺旋模型

http://baike.baidu.com/link?url=Fo9hNjpfVbhGPXqGsawygcXpk97pqrmHXIth4e1SXeYqLq5FiSF-6qPEwoaXvWMfBCEDTXRYbWLhM0YJm0NVxvibwMgx86uZDAJm6Vnwnx4I0UhIkzfS1A1SmoHZ4_DV