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

來源:互聯網
上載者:User

標籤:快速開發   並且   等等   檢驗和   個人   透明   規模   設計   發包   

大家都知道軟體工程實在上個世紀60年代末因為軟體危機,人們提出的一種軟體的開發和管理的方法。自從瀑布式開發模式提出之後,軟體工程就走上了正常化的道路。對於一些功能強大,規模較大的軟體,人們可以將開發過程工程化,做好每個階段的規劃,制定相應的標準,這樣可以創造出功能齊全,而且十分安全的軟體。

然而隨著時代的進步和發展,隨著軟體工程的發展,逐步衍生出各種各樣的軟體開發模式。其中最受矚目的就是敏捷開發模式。敏捷開發在短期的發展後,逐步從傳統開發模式中脫離出來,逐漸佔據了軟體開發行業的半壁江山。然而這兩種開發方式究竟誰更強,誰更加優秀呢。

一、首先我們來瞭解一下兩種開發模式。

(一)傳統軟體工程

含有不同種開發模型。其中很常見的就是瀑布式開發模式。其他的還有RAD模型,增量過程模型,原型模型,螺旋模型,並發開發模型,物件導向開發,形式化開發等等。

  1. 瀑布式開發模型

這是一種老舊的開發模式,在現在的軟體開發環境中已經顯得略有過時。瀑布式開發的核心思想就是將功能的設計與實現分開,便於分工協作,即採用結構化的分析與設計方法將邏輯實現與物理實現分開。在瀑布式模型中,軟體生命週期被劃分為需求分析、系統設計、程式設計、程式編寫、聯合測試、系統測試、相容測試和運行維護這幾個模組。這幾項活動是自上而下的,上一級如果不被完成將無法進行下面的後動甚至會返回上一級的活動。

這種開發模式的特點是要求幾項活動有著嚴格的順序,並且每個階段的成果要進行評審,而且需求不允許有不確定性。開發過程難免會有一些阻塞的情況發生,因此要求顧客有著足夠的耐心。所以面對一些經常更改需求,需要短期內完成程式設計的需求,瀑布式開發並不適用。

  1. RAD模型

這個模型是基於構件的一種快速開發的模型。人們根據軟體的構件分成足夠多的組,每組開發一個構件。沒一個構件都分為業務建模、資料建模、處理建模、應用產生和測試及反覆5個步驟。這樣可以在短期內(60-90天)的時間內同時完成不同的構件,進而組成一個完整的軟體工程。但是對於大型的項目來說,這個模型要求的人力十分龐大,而且對於不能夠合理的劃分模組的程式,並不適用。

  1. 增量過程模型、螺旋模型和並發開發模型

這三種都屬於演化軟體過程模型。他們更加體現軟體的變化特徵,突出迭代的思想。增量過程模型力圖儘早佔領市場,逐步發布新的版本。QQ和各種大型網遊都是很好的例子。螺旋模型則致力於不同版本以不同形式的不斷變化,而且需要高水平的風險評估技術。並發開發模型則由使用者要求、管理決策和評審結果驅動。沒一個軟體工程活動都會觸發活動網路的狀態變遷。

(二)敏捷開發

敏捷開發是本世紀提出來的一種開發理論。這種理論遵循的理念是:個體和互動勝過、過程和工具、可以工作的軟體勝過面面俱到的文檔、客戶合作勝過合約談判、響應變化勝過遵循計劃。雖然傳統軟體工程提出的觀點很有價值,但是我們認為在某些情況下,敏捷開發追求的一些東西會更加的有用。敏捷開發包括了SCRUM、XP(極限編程)、crystal、PPD等體系方法。

  1. Scrum開發

這種開發模型要求有

三個角色:流程管理員、產品負責人和Team Dev。

三種工件:產品列表、迭代列表和燃盡圖 (burndown chart)。

四個會議:sprint plan meeting、daily scrum meeting、sprint review meeting和sprint retrospective meeting。

五個步驟:

1) 項目人員根據需求的優先順序確定排序好的product backlog(按需排列的產品需求表)

2) Scrum team 根據列表選出要迭代的目標。完成這個目標需要大約4周

3) Scrum team 每天進行daily scrum meeting。每個人彙報完成情況以及問題。完成sprint burn down圖。

4) 完成所有的迭代目標之後,進行sprint review meeting,所有人員參加,並根據產品負責人員的需求進行調整。

5) 進行sprint retrospective meeting,總結本次sprint,為下一次sprint做準備。

  1. XP開發

XP開發相對於Scrum開發整體思維並沒有太多的差距,但是兩者之間還是有一些細小的差別。XP開發沒一個迭代目標完成的時間設定的更加短,大約1到2周。此外,在XP開發中,如果一個小需求還沒有完成,則可以選擇用等量工作量的需求替換他。相對於Scrum更加的靈活。還有一點,XP開發必須要遵守優先順序的順序,而scrum則考慮人員因事耽誤或這低優先順序是高優先順序的基礎等方面的因素,並不要求一定按照之前約定好的優先順序進行開發。同時,XP是有著嚴格的管理,自動化的測試,結對變成等約束團體的行為。而scrum則是完全靠人員的自覺性來保證整個團隊的開發進程。

 

二、談完了兩種開發方式的一些模型,接下來談一下傳統軟工和敏捷開發兩者之間的區別。

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

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

說白了,就是字面意思,敏捷開發注重的是敏捷,快速。而傳統軟工注重的是工程化的方法,更加註重系統開發,以及保證其完整性和安全性。

而現如今,電腦科學越來越發達,軟體工程的兩種開發方式更應該互取優點,力求在軟體開發方面做出更大的進步。我認為可以將軟體工程的架構方法移植到敏捷開發的沒一個階段,將軟體進行顆粒化,並使每一個顆粒都有一個架構。這樣可以使軟體工程既有傳統軟工的可預見性,又有敏捷開發的便利性和適應性。

當然這種方法也不是絕對的。我們應該學會在不同的情況下考慮究竟是使用這兩種方法中的哪一個。對於一個大型的工程,可能會花費很長的時間才能完成的工程,其中甚至可能會有人員的更換,這種情況下,我們應該果斷的採用傳統軟體工程方法,這樣可以保證工程的預見性和系統性,在長時間的開發過程中,不至於出現過多的因為交流不通暢或者人員變動所導致的錯誤,或者整個工程的失敗。

而如果我們作為一個小型的團隊,在一個實驗室或者辦公室中進行一些小型的開發,而且軟體的需求方又隨時有可能更改軟體需求,那麼敏捷開發便再合適不過了。隨時開發,發現問題能隨時更改,需求變更也可以隨時跟上進度,由於溝通便利,工程的品質也不會出現問題。

根據上面的分析,我認為現如今這兩種方法都會有各自的生命力。兩者不存才誰優誰劣的關係,在選擇開發模式的時候,根據自己的需求,人員的配置,工作的環境等等進行判斷,到底哪種開發方式更加適合自己,這才是最重要的。

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

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.