軟件項目的快速開發(fā)

1、編者按：越來越多的壓力使得一個軟件項目無論是最終用戶、企業(yè)、開發(fā)團隊都希望在最短的時間完成，可事與愿違的是軟件項目的時間延期問題普遍存在，一些調查表明，70%的項目超出了估算的時間。大型項目平均超出計劃交付時間的20%到50%項目越大，超岀計劃的時間越長。一直以來開發(fā)速度的問題都是軟件開發(fā)業(yè)的頭等問題。那怎樣才能在保證軟件質量的同時又縮短開發(fā)速度呢？本期的領航人月刊中我們就將圍繞著有關軟件的“快速開發(fā)”主題來進行探討。開發(fā)軟件所需要經歷的階段要談“快速開發(fā)”我們就需要先來了解一下軟件項目所需要經歷的過程：軟件的開發(fā)過程并不僅是一個編寫、實現代碼的簡單過程，軟件的開發(fā)需要經歷許多的步驟。因此在開

2、始時我們先用一個相對簡單的方式了解一下軟件開發(fā)的常見過程：從上圖可以直觀的看岀，一個軟件的開發(fā)至少是包含了上圖的三個階段、七個步驟。而這個過程中又可能涉及到下列各種參與軟件開發(fā)的角色：并不是任何項目中都會出現所有角色，角色同實際的參與人員也并不一定一一對應我們在此所探討的軟件“快速開發(fā)”為的是在軟件目標、夕卜部資源相同的情況下（如:同一團隊，同一項目）可以縮減整個開發(fā)周期的各種方式，使軟件項目最終能在一個更短時間內完成。能縮短軟件開發(fā)周期的三種方式縮短軟件開發(fā)周期其實一直是全世界軟件開發(fā)團隊所長期關注的話題，把現在已被廣泛認可的有效縮短周期的方式歸類一下可劃分為三大類：1. 工具快速2. 模式

3、快速3. 經驗快速其分別代表著實現軟件項目“快速開發(fā)”的“天時、地利、人和”，同時也蘊藏著“天時不如地利，地利不如人和”的真諦。天時一一工具快速在一個軟件項目所經歷的各階段中（如：需求分析、原型開發(fā)、實現、測試、完成、需求變更、后期維護），不同階段選用適當的工具能非常直接的相應參與人員的工作效率、溝通效率，縮短單個步驟所需要的時間，從而在整體上縮短軟件項目的開發(fā)周期。值得注意的一點是，工具并不僅限于軟件形態(tài)的工具。需求分析：是軟件項目開發(fā)第一個也是很重要的一個階段，？需求分析的基本任務是要準確地定義新系統(tǒng)的目標，為了滿足用戶需要，回答系統(tǒng)必須“做什么”的問題。？在這個階段中包含需要獲取需求、分

4、析需求、編寫規(guī)格說明和需求驗證。從獲取需求到需求驗證的這個過程需要編寫文檔、繪制圖形、創(chuàng)建需求模型等，像文檔之類的工具可以使用word、繪制圖形可以使用visio、建模可以使用rationalrose等工具軟件，有了這些工具的輔助，可提高編寫文檔的速度，縮短分析階段的周期。除了以上這些軟件形態(tài)的工具外還可為更快的項目參與人員之間的想法溝通，借助一些實體類工具，如紙制卡片，黑板或一些已經成型的系統(tǒng)。原型開發(fā)：在軟件需求分析階段，需要搞清楚的是軟件要“做什么”的問題，并把這些需求通過文檔的形式描述岀來，這也是目標系統(tǒng)的邏輯模型。進入設計階段，則要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型

5、，即著手實現軟件的需求，并將設計的結果反映在“設計規(guī)格說明”文檔中，接下來開始設計。設計的基本任務包括：軟件結構、數據結構及數據庫設計、概要設計文檔。開發(fā)一個大而復雜的軟件系統(tǒng)，我們可以將它進行適當的分解來降低其復雜性，還可減少開發(fā)工作量，你也可以使用一些能夠提高設計速的軟件來幫助你進行設計，從而提高軟件生產率，降低開發(fā)成本。所用的工具比如使用UML繪制類圖的工具。實現：設計完成之后進入編碼實現階段，為了提高整個項目的開發(fā)速度，編寫代碼我們可以借助一些有力的開發(fā)工具來加快速度，例如，如果是用JAVA語言開做開發(fā)的話，可以使用eclipse、JCreater，如果是用C#VB你可以用Visual

6、;如果是開發(fā)網站之類的可以用Dreamweaver。美工可以使用photoshop或是FireWork之類的工具。節(jié)省項目的開發(fā)時間。另外一方面由于軟件技術的快速發(fā)展帶來了各種平臺和引擎，選用適當的平臺技術與引擎能更大程度的縮短周期。測試：軟件的測試也是一個非常重要的階段，大量的測試，甚至重復的測試引岀了一個新的問題：全憑手工進行測試會浪費大量的時間。因此，易變的需求對測試提岀了一個新的要求：自動化測試。此類型的工具例如Xunit系列。只有自動化的進行測試，才可以完成大量的測試工作，節(jié)省時間和人力方面的投入，加快項目的整體開發(fā)速度。關于自動化測試這方面的問題，大家可以參考相關的資料，這里我們不

7、作深入的討論。工匠用釘槍、成型磚塊、涂料噴霧器來建造一個小屋的話要比他單純用一把榔頭、沙磚、涂料刷來得快。擁有快速交通工具的人可以比擁有普通交通工具的人提前到達目的地。但不論什么情況下，如果質量是非常重要的話，那么即使是強有力的工具也將會被手工工具所替代或輔助。軟件開發(fā)中使用工具的情況與上述情況也是非常相近的。地利模式快速如前所說軟件開發(fā)的過程并不是一個簡單的過程，一個軟件的開發(fā)會被分成很多步驟來實現，每一個步驟都有自己的起點和終點。也正如此使得開發(fā)過程中的每個步驟起點和終點在不同的軟件項目中岀現不同難度的“坎”，使其難于達到該步驟開始或是終結的條件，開發(fā)過程也就不會一帆風順。不同的開發(fā)模式其

8、實就是將步驟的起點和終點重新定義，甚至重新組合排列，雖然任何一個開發(fā)模式最終目的都是完成軟件項目的開發(fā)，但期間所經歷的過程不一樣，過程步驟之間的起點和終點的的定義不同所帶來的“坎”也就不一樣，項目周期自然各不相同，因此，根據軟件項目的實際情況選擇一個適合的開發(fā)模式能減少開發(fā)周期中“坎”的岀現次數與難度，非常大程度的縮短開發(fā)周期。瀑布模型在本專題開始時我們所示范的開發(fā)流程，實際就是一種典型的瀑布模型（又稱線形模型）：瀑布模型是由在1970年最初提岀的軟件開發(fā)模型，在瀑布模型中，開發(fā)被認為是按照需求分析，設計，實現，測試（確認），集成，和維護堅定地順暢地進行。在最初的文章中，Royce提倡重復地使

9、用瀑布模型，以一種迭代的方式。但是，大多數人并不知道這一點，一些人也不相信它能夠作為一種真實世界的過程使用。在實踐中，過程很少能夠以純線性的方式進行。通過回到前面的階段或改便前一階段的結果的迭代是非常普遍的。線性模型太理想化，太單純，以至很多人認為瀑布模型已不再適合現代的軟件開發(fā)模式，幾乎被業(yè)界拋棄。偶而被人提起，都屬于被貶對象，未被留一絲惋惜。但我們應該認識到，“線性”是人們最容易掌握并能熟練應用的思想方法。當人們碰到一個復雜的“非線性”問題時，總是千方百計地將其分解或轉化為一系列簡單的線性問題，然后逐個解決。一個軟件系統(tǒng)的整體可能是復雜的，而單個子程序總是簡單的，可以用線性的方式來實現，否

10、則干活就太累了。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神，就不要再呆板地套用線性模型的外表，而應該用活它。瀑布模型解決了軟件工程上面的基本管理需求，但是對于我們所提的軟件項目的“快速開發(fā)”瀑布模型并沒有什么優(yōu)勢。2.RUP（RationalUnifiedProcess瑞理統(tǒng)一過程）RUF是建立在非常優(yōu)秀的軟件工程原則基礎上的，例如迭代，需求驅動，基于結構化的過程開發(fā)。它提供了幾個方法，例如每一次迭代產生一個工作原型，在每一個階段的結束決定項目是否繼續(xù)，這些方法提供了對開發(fā)過程的非常直觀的管理。RUP采用了萬維網技術，可以增強團隊的開發(fā)效率，并為所有成員提供了最佳的軟件實現方案。RUP

11、處理過程為軟件開發(fā)提供了規(guī)定性的指南、模板和范例。它可以通過提供一個應用于整個軟件開發(fā)周期的、可定制的最佳開發(fā)方案架構，RUP可以對整個開發(fā)小組的工作進行指導和安排。RUP將項目管理、商業(yè)建模、需求管理、分析和設計、測試以及變更控制等，統(tǒng)一到了一個一致的、貫穿整個開發(fā)周期的處理過程。RUPE如其名，它使團隊中每個開發(fā)人員的見解和思想得到統(tǒng)一，使開發(fā)小組成員的溝通更為容易，而這正是任何項目要取得成功的關鍵因素；它增強了開發(fā)人員對軟件的預見性，最終的好處就是提高了軟件質量，并有效縮短了軟件從開發(fā)到投放市場的時間，全面提高了開發(fā)速度。RUP是嚴格按照行業(yè)標準UML開發(fā)的，它的特點主要表現為如下六個方

12、面：開發(fā)復用。減少開發(fā)人員的工作量，并保證軟件質量，在項目初期可降低風險。對需求進行有效管理?？梢暬！Ｊ褂媒M件體系結構，使軟件體系架構更具彈性。貫穿整個開發(fā)周期的質量核查。對軟件開發(fā)的變更控制。RUF可以縮短軟件項目的開發(fā)周期，實現大型項目的快速開發(fā)，對于中小型項目RUP就顯的過于龐大，其需要投入的成本也很非常觀。3.敏捷開發(fā)，極限編程2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭，一批業(yè)界專家一起概括岀了一些可以讓軟件開發(fā)團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發(fā)過程的方法很多，主要有：SCRUMCrystal,特征驅動軟件開發(fā)(Featu

13、reDrivenDevelopment，簡稱FDD，自適應軟件開發(fā)(AdaptiveSoftwareDevelopment，簡稱ASD)，以及最重要的極限編程(extremeProgramming,簡稱XP)。極限編程是一套能快速開發(fā)高質量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發(fā)岀來并向客戶提供最高的效益。XP在很多方面都和傳統(tǒng)意義上得軟件工程不同，同時，它也和傳統(tǒng)得管理和項目計劃得方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。XP具有12個過程，只有完全使用12個過程才是真正使用了XP,只是簡單使用了其中一個方法并不代表使用了XPo現場客戶(On-site

14、Customer)計劃博弈(PlanningGame)系統(tǒng)隱喻(SystemDesign)簡化設計(SimpleDesign)集體擁有代碼(CollectiveCodeOwnership)結對編程(PairProgramming)測試驅動(Test-driver)小型發(fā)布(SmallRelease)重構(Refactoring)持續(xù)集成(Continousintegration)每周40小時工作制(40-hourWeeks)代碼規(guī)范(CodingStandards)下面是極限編程的有效實踐：1. 完整團隊XP項目的所有參與者(開發(fā)人員、客戶、測試人員等)一起工作在一個開放的場所中，他們是同一個

15、團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。2. 計劃游戲計劃是持續(xù)的、循序漸進的。每2周，開發(fā)人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。3. 客戶測試作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義岀自動驗收測試來表明該特性可以工作。4. 簡單設計團隊保持設計恰好和當前的系統(tǒng)功能相匹配。它通過了所有的測試，不包含任何重復，表達岀了編寫者想表達的所有東西，并且包含盡可能少的代碼。5. 結對編程所有的產品軟件都是由兩個程序員、并排坐在一起在同一臺機器上構建的。6. 測試驅動開發(fā)編寫單元測試是一個驗證行為

16、，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環(huán)，尤其是功功能能驗證方面的反饋循環(huán)。程序員以非常短的循環(huán)周期工作，他們先增加一個失敗的測試，然后使之通過。7. 改進設計隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的干凈、具有表達力。8. 持續(xù)集成團隊總是使系統(tǒng)完整地被集成。一個人拆入(Checkin)后，其它所有人責任代碼集成。9. 集體代碼所有權任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發(fā)。10. 編碼標準系統(tǒng)中所有的代碼看起來就好像是被單獨一人編寫的。11. 隱喻

17、將整個系統(tǒng)聯系在一起的全局視圖；它是系統(tǒng)的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的。12. 可持續(xù)的速度團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。極限編程是一組簡單、具體的實踐，這些實踐結合在形成了一個敏捷開發(fā)過程。極限編程是一種優(yōu)良的、通用的軟件開發(fā)方法，項目團隊可以拿來直接采用，也可以增加一些實踐，或者對其中的一些實踐進行修改后再采用。"增量迭代”模式以RUP和極限編程中的增量所不同的的是NoahWe“增量迭代”模式僅適用于B/S軟

18、件項目?？紤]B/S項目中的人員配置、工作重心與C/S項目截然不同的特殊性，因此該模式專門針對B/S項目而提岀。從以往的很多B/S應用開發(fā)案例來看，用戶的需求并不會在需求分析階段和原型開發(fā)階段就可以準確獲得，往往在應用系統(tǒng)接近發(fā)布時，用戶才會提岀各種各樣具體的需求。B/S應用開發(fā)過程中各階段中用戶需求變化圖導致這樣的原因很簡單：在需求分析階段，最終用戶不可能通過開發(fā)文檔就能想象出應用系統(tǒng)運行時的實際情況，而系統(tǒng)接近成型時，用戶通過真實使用會感覺到系統(tǒng)存在的問題和設計缺陷。由于用戶需求在發(fā)布前頻繁變更這一特性，使用傳統(tǒng)B/S解決方案的設計人員和開發(fā)人員將會此階段面臨需求變更的各種考驗，項目周期和開

19、發(fā)成本也會在發(fā)布階段由于需求變更急劇擴大，有時甚至可能之前工作推倒從來?？紤]B/S項目的特殊性B/S項目以往一直采用同C/S軟件項目一樣的開發(fā)模式和流程管理。但由于B/S項目同C/S項目太多的不同之處，使得B/S項目開發(fā)周期很難控制。B/S一方面要面臨著需要短時間獲取需求，需求不明確。另一方面B/S開發(fā)中美工和界面設計美化的重要性也不同于C/S項目，B/S項目往往由美術和程序兩方面的人員來決定需求并且相互制約，這些巨大區(qū)別似的不能將B/S項目等同與C/S項目來進行管理。NoahWe“增量迭代”開發(fā)模式的各步驟特點如下：用“迭代”探索需求o需求分析階段：設計人員關注的不是程序結構設計，而是用戶流

20、程，在需求分析階段就可以邀請用戶一起參與“動作分解圖”的設計，讓用戶從一開始就可以感受到軟件使用的流程，讓所開發(fā)的軟件從一開始就貼近用戶需求；原型階段：原型階段將整個軟件項目的數據輸入界面和輸岀按照動作流程呈現給用戶，讓用戶可以直觀的從輸入輸岀的具體細節(jié)體驗軟件，反饋修改意見，讓開發(fā)的軟件再次貼近需求。實現階段在此階段，還可以讓用戶通過至少兩個階段性的演示讓用戶體會軟件的流程和真實的數據輸入輸岀，體驗真實的軟件使用感覺，為項目開發(fā)團隊反饋岀更準確的需求。發(fā)布階段在發(fā)布階段軟件已經能非常貼近最終用戶需求，即使發(fā)布后更意外的需求變更，也能輕松應變。使用該模式項目實施B/S項目的效果將很大程度上區(qū)別于其他模式效果。軟件項目的開發(fā)中需求分析與編碼實現已經被融為一體，而且在開發(fā)的任意階段，開發(fā)人員都已經準備好應付后續(xù)階段可能出現的任何變化。變化成為計劃一部分。更多有關NoahWe“增量迭代”開發(fā)模式的詳細介紹，可查看：人和一一經驗快速經驗所能帶來的效率提升與工具和模式所帶來的提升完全不同。項目參與人員經驗越多軟件項目摸索的過程就越短、彎路越少。但是不同參與人員的相關經驗只能通過長時間的積累和一些“強化訓練”的學習方式獲得。不同