敏捷軟件開發與傳統軟件工程概述比較

敏捷軟件開發與傳統軟件工程概述比較

翁鬆秀

北京航空航天大學計算機學院

　　摘要：軟件工程的開發過程當中有兩種大相徑庭的管理和開發體系，一種是基於「瀑布模型」的預設性傳統軟件工程，另外一種是輕量級的適應性敏捷軟件開發，本文簡單闡述傳統軟件工程的開發方法與敏捷軟件開發的異同，並經過「瀑布模型」和SCRUM方法的比較來探析傳統軟件工程與敏捷軟件開發的異同。最後得出結論，把傳統軟件工程和敏捷軟件開發相結合，將軟件架構「顆粒化」，在簡單可快速交付的敏捷軟件開發中嵌套系統的傳統軟件開發方法，實現預見性和適應性折中。

關鍵詞：敏捷軟件開發；傳統軟件工程；瀑布模型；SCRUM方法；嵌套；顆粒化

　　0 前言

　　隨着計算機的發展，對軟件的需求愈來愈大，軟件的規模也變得愈來愈大，結構愈來愈複雜，軟件開發管理困難而複雜，在這個「軟件危機」背景下產生的傳統軟件工程，用工程化的方法構建和維護有效和高質量的軟件。暫時解決了軟件的兵荒馬亂時代，但隨着社會和科技的發展，對軟件的需求變化愈來愈快，傳統的軟件工程很難再適應瞬息萬變的客戶需求，敏捷軟件開發應運而生，其輕量級、簡單、可快速交付、適應性強收到開發團隊的青睞，與傳統軟件工程並肩，造成軟件工程中的兩大開發體系。

　　1 傳統軟件工程

1.1 傳統軟件工程概述

　　基於「瀑布模型」的傳統軟件開發方法中，以軟件架構(software architecture)爲核心，採用結構化的設計和分析方法將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動。並規定他們自上而下，相互銜接的順序，如同瀑布的流水通常，各個階段的經過文檔相互流通。前期就要設計好整個軟件大廈的框架來指導和支撐後面各個方面的開發和維護工做，後面再根據前期設計的藍圖來逐步實現。由架構師完成軟件架構設計，開發人員再根據軟件大廈的藍圖進行軟件開發。這種開發方法的優勢是，超前的預見性和每一階段都要經過嚴格的審查才能進行下一個階段，保證了軟件的質量。缺點是，軟件的框架一旦肯定下來就很難改變，甚至會牽一髮而動全身，難以適應變化莫測的客戶需求。因爲各個階段要自上而下相互銜接，各個階段的溝通要經過大量臃腫、複雜的文檔來傳遞信息。

　　1.2 瀑布模型

　　瀑布模型是Winston Royce在1970年提出的一種軟件開發模型，瀑布式開發是一種傳統的計算機軟件開發，是最典型的預見性軟件開發方法，嚴格遵照計劃、分析、設計、編碼、測試、維護的步驟。階段之間經過文檔流通，每一個階段結束時要進行嚴格的審查，檢查功能設計和實現是否符合上階段流下來的文檔的要求，若是不符合就逆流到上個階段檢查並修正，以此往復，直到流到最後階段產品經過測試後進行發佈以及運行期間的維護。

• 瀑布模型開發過程（如圖）

• 三個階段：定義階段、開發階段和維護階段。開發階段架構師要有預見性地分析客戶如今的需求以及之後可能變更的需求，設計規劃好大量的功能需求和非功能需求，儘量多地知足客戶後面需求的變更，避免往後重構軟件框架帶來的成本虧損。設計包括UML圖，API接口，數據庫表等。開發階段開發人員根據架構師的對客戶需求分析之後設計的藍圖進行軟件的開發和測試，實現用戶的需求。運維階段開發團隊根據用戶使用軟件的體驗、反饋、軟件存在的BUG和新增功能需求對軟件進行維護，保證軟件在保證魯棒性的前提下能儘量地知足客戶的需求。
• 六個流程：制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護。

• 瀑布模型的特色
  • 強調文檔。瀑布模型每一個階段之間的溝通和交流就是文檔，上一個階段的輸出就是下一個階段的輸入，文檔就是先後階段銜接的介質。缺乏開發人員之間面對面的溝通與交流，形成文檔臃腫現象。
  • 結構明顯。按需求分析將整個工程劃分爲完整的階段集合，每個階段都有明確的檢查點，當出現問題可使用順藤摸瓜式往上檢查。當一個階段結束後經過嚴格審查，就能夠只關注下個階段，出現問題再逆流檢查。

　　2 敏捷軟件開發

　　1.2 敏捷軟件開發概述

　　2001年由17位業界專家構成的敏捷開發聯盟成立，聯盟起草了敏捷宣言：個體與交互賽過過程和工具；可用的軟件高於複雜的文檔；客戶的合做賽過合同的談判；響應變化賽過遵循計劃。敏捷軟件開發是一組重視人的主觀能動性和開發人員、管理層和產品負責人的溝通，經過迭代式和增量式軟件，追求便捷，可快速交付，及時響應客戶需求變更的軟件開發管理方法。

　　敏捷軟件開發方法體系主要包括：SCRUM、XP（極限編程）、CRYSTAL（水晶編程）、PDD（特性驅動開發）等。敏捷軟件開發的一個精髓就是「剛剛夠（Just enough）」思想。用逐步實現的思想替代完整構架，每一步的需求和人員及其溝通、開發成本都剛恰好，經過不斷地迭代，在迭代過程當中響應客戶需求的變化，實現最緊緻成本，體現「剛恰好」思想。同時對每次迭代的反饋進行討論和思考，總結經驗和吸收教訓。

　　2.2 SCRUM方法

　　在敏捷軟件開發中，軟件項目被切分紅不少個子項目，經過選取優先級較高的一組子項目做爲敏捷迭代的球心進行迭代，每次迭代都有明確的需求、目標、人員、而且每次迭代以後都要有可交付的產品。就比如從山頂滾雪球，選取優先級較高的需求做爲首次迭代的球心，通過增量式迭代，每次迭代加帶必定的需求滾下山，下山就能夠造成可交付的產品。

• 三個角色：管理層（Scrum Master）、產品負責人（Product Owner）和開發團隊（Team）。
• 三種工件：產品列表（Product Backlog）、迭代列表（Sprint Backlog）和燃盡圖（Burn Down Chart）。
• 四個會議：Sprint Plan Meeting（Sprint 計劃會議）、Daily Scrum Meeting（Scrum每日會議）和Sprint Review Meeting（Sprint評審會議）和Sprint Retrospective Meeting（Sprint回顧會議）。

• 五個步驟

　　　　(1)Product Owner根據需求的優先級肯定一個排序好的Product Backlog；

　　　　(2)Scrum Team經過Sprint Plan Meeting根據Product Backlog按優先級選出一組需求做爲迭代的目標，即Sprint Backlog。這個階段通常的時間是4周。

　　　　(3)Scrum Team完成Sprint Backlog過程當中須要天天都要進行Daily Scrum Meeting，每一個人都要彙報所完成的進度和遇到的問題，總結經驗，經過Burn Down Chart記錄工做的整個過程。

　　　　(4)當本次Sprint把Sprint Backlog都實現完以後進行Sprint Review Meeting，這個會議中管理層和產品負責人以及開發團隊都要參加，討論本次Sprint交付的產品，以及根據產品負責人的需求變更及時調整。

　　　　(5)最後進行Sprint Retrospective Meeting，回顧本次Sprint整個過程當中開發遇到的問題，以及解決的方案，爲下一輪Sprint作準備。

 

　　3 結束語

　　3.1 敏捷開發與軟件架構的比較

　　敏捷開發的優勢是輕量級、簡單、可快速交付，最大的特色是高度透明、檢驗和適應，注重開發團隊之間以及開發團隊與客戶的及時溝通，主張響應需求變化，可是不夠系統。

　　傳統軟件架構的優勢在於預見性和系統性，能在正式開發前預見軟件的功能需求和非功能需求，最大的特色是重視文檔和結構明顯，主張固定流水開發，很難響應客戶需求的變化，難以保證開發的靈活性。

　　3.2 敏捷開發與軟件架構的融合

　　將具備系統性和預見性的軟件架構嵌套到敏捷開發的每次輕量級的迭代中，將軟件架構顆粒化，嵌套到整個敏捷開發，使軟件工程兼具軟件構架的預見性和敏捷開發的適應性，根據項目的大小來調整嵌套的程度，根據每次迭代項目的大小來選擇不一樣的架構，實現敏捷開發與軟件架構融合的共贏。

　　參考文獻：

[1]王玉璽.淺談敏捷軟件開發.設計開發.2014

[2]孫嘉瑞.敏捷開發方法綜述.科技創新.2015

[3]聶華北,沈劍翹.幾種常見的敏捷軟件開發方法綜述.計算機系統應用.2008

[4]王瓊.敏捷軟件開發過程研究及應用.技術探討.2015

[5]李聲威,王愛景.敏捷開發與軟件架構概述比較.萬方數據.2015

[6]孫宗旺,藍金球.基於Web服務組合的敏捷軟件開發研究.軟件導刊.2015