軟件項(xiàng)目快速開發(fā)

1、軟件項(xiàng)目快速開發(fā)歡送閱讀編者按： 越來越多的壓力使得一個(gè)軟件工程無論是最終用戶、企業(yè)、開發(fā)團(tuán)隊(duì)都希望在最短的時(shí)間完成，可事與愿違的是軟件工程的時(shí)間延期問題普遍存在，一些調(diào)查說明，70%的工程超出了估算的時(shí)間。大型工程平均超出方案交付時(shí)間的20%到50%,工程越大，超出方案的時(shí)間越長。 一直以來開發(fā)速度的問題都是軟件開發(fā)業(yè)的頭等問題。那怎樣才能在保證軟件質(zhì)量的同時(shí)又縮短開發(fā)速度呢？本期的？領(lǐng)航人？月刊中我們就將圍繞著有關(guān)軟件的“快速開發(fā)主題來進(jìn)行探討。開發(fā)軟件所需要經(jīng)歷的階段要談“快速開發(fā)我們就需要先來了解一下軟件工程所需要經(jīng)歷的過程：軟件的開發(fā)過程并不僅是一個(gè)編寫、實(shí)現(xiàn)代碼的簡單過程，軟件的開

2、發(fā)需要經(jīng)歷許多的步驟。因此在開始時(shí)我們先用一個(gè)相對(duì)簡單的方式了解一下軟件開發(fā)的常見過程：從上圖可以直觀的看出，一個(gè)軟件的開發(fā)至少是包含了上圖的三個(gè)階段、七個(gè)步驟。而這個(gè)過程中又可能涉及到以下各種參與軟件開發(fā)的角色：并不是任何工程中都會(huì)出現(xiàn)所有角色，角色同實(shí)際的參與人員也并不一定一一對(duì)應(yīng)我們?cè)诖怂接懙能浖翱焖匍_發(fā)為的是在軟件目標(biāo)、外部資源相同的情況下如：同一團(tuán)隊(duì)，同一工程可以縮減整個(gè)開發(fā)周期的各種方式，使軟件工程最終能在一個(gè)更短時(shí)間內(nèi)完成。軟件項(xiàng)目快速開發(fā)歡送閱讀能縮短軟件開發(fā)周期的三種方式縮短軟件開發(fā)周期其實(shí)一直是全世界軟件開發(fā)團(tuán)隊(duì)所長期關(guān)注的話題，把現(xiàn)在已被廣泛認(rèn)可的有效縮短周期的方式歸

3、類一下可劃分為三大類：1. 工具快速2. 模式快速3. 經(jīng)驗(yàn)快速其分別代表著實(shí)現(xiàn)軟件工程“快速開發(fā)的“天時(shí)、地利、人和，同時(shí)也蘊(yùn)藏著“天時(shí)不如地利，地利不如人和的真諦。天時(shí)一一工具快速在一個(gè)軟件工程所經(jīng)歷的各階段中如：需求分析、原型開發(fā)、實(shí)現(xiàn)、測試、完成、需求變更、后期維護(hù)，不同階段選用適當(dāng)?shù)墓ぞ吣芊浅Ｖ苯拥南鄳?yīng)參與人員的工作效率、溝通效率， 縮短單個(gè)步驟所需要的時(shí)間，從而在整體上縮短軟件工程的開發(fā)周期。值得注意的一點(diǎn)是，工具并不僅限于軟件形態(tài)的工具。需求分析：是軟件工程開發(fā)第一個(gè)也是很重要的一個(gè)階段，？需求分析的根本任務(wù)是要準(zhǔn)確地定義新系統(tǒng)的目標(biāo)，為了滿足用戶需要，答復(fù)系統(tǒng)必須“做彳f么的問

4、題。？在這個(gè)階段中包含需要獲取需求、分析需求、編寫規(guī)格說明和需求驗(yàn)證。從獲取需求到需求驗(yàn)證的這個(gè)過程需要編寫文檔、繪制圖形、創(chuàng)立需求模型等，像文檔之類的工具可以使用word、繪制圖形可以使用visio 、建?？梢允褂胷ationalrose等工具軟件，有了這些工具的輔助，可提高編寫文檔的速度，縮短分析階段的周期。除了以上這些軟件形態(tài)的工具外還可為更快的工程參與人員之間的想法溝通，借助一些實(shí)體類工具，如紙制卡片，黑板或一些已經(jīng)成型的系統(tǒng)。原型開發(fā)：在軟件需求分析階段，需要搞清楚的是軟件要“做什么的問題，并把這些需求通過文檔的形式描述出來，這也是目標(biāo)軟件項(xiàng)目快速開發(fā)歡送閱讀系統(tǒng)的邏輯模型。進(jìn)入設(shè)計(jì)

5、階段，那么要把軟件“做什么的邏輯模型變換為“怎么做的物理模型，即著手實(shí)現(xiàn)軟件的需求，并將設(shè)計(jì)的結(jié)果反映在“設(shè)計(jì)規(guī)格說明文檔中，接下來開始設(shè)計(jì)。設(shè)計(jì)的根本任務(wù)包括：軟件結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計(jì)、概要設(shè)計(jì)文檔。開發(fā)一個(gè)大而復(fù)雜的軟件系統(tǒng)，我們可以將它進(jìn)行適當(dāng)?shù)姆纸鈦斫档推鋸?fù)雜性，還可減少開發(fā)工作量，你也可以使用一些能夠提高設(shè)計(jì)速的軟件來幫助你進(jìn)行設(shè)計(jì)，從而提高軟件生產(chǎn)率，降低開發(fā)本錢。所用的工具比方使用UML繪制類圖的工具。實(shí)現(xiàn)：設(shè)計(jì)完成之后進(jìn)入編碼實(shí)現(xiàn)階段，為了提高整個(gè)工程的開發(fā)速度，編寫代碼我們可以借助一些有力的開發(fā)工具來加快速度，例如，如果是用JAVA語言開做開發(fā)的話，可以使用 eclip

6、se、JCreater ,如果是用C#、VB你可以用Visual S ;如果是開發(fā)網(wǎng)站之類的可 以用Dreamweaver 。美工可以使用photoshop或是FireWork之類的工具。節(jié)省工程的開發(fā)時(shí)間。另外一方面由于軟件技術(shù)的快速開展帶來了各種平臺(tái)和引擎，選用適當(dāng)?shù)钠脚_(tái)技術(shù)與引擎能更大程度的縮短周期。測試：軟件的測試也是一個(gè)非常重要的階段，大量的測試，甚至重復(fù)的測試引出了一個(gè)新的問題：全憑手工進(jìn)行測試會(huì)浪費(fèi)大量的時(shí)間。因此，易變的需求對(duì)測試提出了一個(gè)新的要求：自動(dòng)化測試。此類型的工具例如Xunit系列。只有自動(dòng)化的進(jìn)行測試，才可以完成大量的測試工作，節(jié)省時(shí)間和人力方面的投入，加快工程的整

7、體開發(fā)速度。關(guān)于自動(dòng)化測試這方面的問題，大家可以參考相關(guān)的資料，這里我們不作深入的 討論。工匠用釘槍、成型磚塊、涂料噴霧器來建造一個(gè)小屋的話要比他單純用一把榔頭、沙磚、涂料刷來得快。擁有快速交通工具的人可以比擁有普通交通工具的人提前到達(dá)目的地。但不管什么情況下，如果質(zhì)量是非常重要的話，那么即使是強(qiáng)有力的工具也將會(huì)被手工工具所替代或輔助。軟件開發(fā)中使用工具的情況與上述情況也是非常相近的。地利一一模式快速如前所說軟件開發(fā)的過程并不是一個(gè)簡單的過程，一個(gè)軟件的開發(fā)會(huì)被分成很多步驟來實(shí)現(xiàn)，每一個(gè)步驟都有自己的起點(diǎn)和終點(diǎn)。正如此 也使得開發(fā)過程中的每個(gè)步驟起點(diǎn)和終點(diǎn)在不同的軟件工程中出現(xiàn)不同難度的“坎，

8、使其難于到達(dá)該步驟開始或是終結(jié)的條件，開軟件項(xiàng)目快速開發(fā)歡送閱讀發(fā)過程也就不會(huì)一帆風(fēng)順。不同的開發(fā)模式其實(shí)就是將步驟的起點(diǎn)和終點(diǎn)重新定義，甚至重新組合排列，雖然任何一個(gè)開發(fā)模式最終目的都是完成軟件工程的開發(fā)，但期間所經(jīng)歷的過程不一樣，過程步驟之間的起點(diǎn)和終點(diǎn)的的定義不同所帶來的“坎也就不一樣，工程周期自然各不相同，因此， 根據(jù)軟件工程的實(shí)際情況選擇一個(gè)適合的開發(fā)模式能減少開發(fā)周期中“坎的出現(xiàn)次數(shù)與難度，非常大程度的縮短開發(fā)周期。瀑布模型在本專題開始時(shí)我們所示范的開發(fā)流程，實(shí)際就是一種典型的瀑布模型又稱線形模型：在最初的文章中， Royce提倡重復(fù)地使用瀑布模型，以一種迭代的方式。但是，大多數(shù)人

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

10、美。當(dāng)我們領(lǐng)會(huì)了線性的精神，就不要再呆板地 套用線性模型的外表，而應(yīng)該用活它。瀑布模型解決了軟件工程上面的根本管理需求，但是對(duì)于我們所提的軟件工程的“快速開發(fā)瀑布模型并沒有什么優(yōu)勢。2 . RUP Rational Unified Process瑞理統(tǒng)一過程RUP是建立在非常優(yōu)秀的軟件工程原那么根底上的，例如迭代，需求驅(qū)動(dòng)，基于結(jié)構(gòu)化的過程開發(fā)。它提供了幾個(gè)方法，例如每一次迭軟件項(xiàng)目快速開發(fā)歡送閱讀代產(chǎn)生一個(gè)工作原型，在每一個(gè)階段的結(jié)束決定工程是否繼續(xù)，這些方法提供了對(duì)開發(fā)過程的非常直觀的管理。RUP采用了萬維網(wǎng)技術(shù),可以增強(qiáng)團(tuán)隊(duì)的開發(fā)效率，并為所有成員提供了最正確的軟件實(shí)現(xiàn)方案。RUP處理過

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

12、個(gè)方面：, 開發(fā)復(fù)用。減少開發(fā)人員的工作量，并保證軟件質(zhì)量，在工程初期可降低風(fēng)險(xiǎn)。 對(duì)需求進(jìn)行有效管理。 可視化建模。 使用組件體系結(jié)構(gòu)，使軟件體系架構(gòu)更具彈性。 貫穿整個(gè)開發(fā)周期的質(zhì)量核查。 對(duì)軟件開發(fā)的變更控制。RUP可以縮短軟件工程的開發(fā)周期，實(shí)現(xiàn)大型工程的快速開發(fā)，對(duì)于中小型工程RUP就顯的過于龐大，其需要投入的本錢也很非常觀。3.敏捷開發(fā)，極限編程2001年，為了解決許多公司的軟件團(tuán)隊(duì)陷入不斷增長的過程泥潭，一批業(yè)界專家一起概括出了一些可以讓軟件開發(fā)團(tuán)隊(duì)具有快速工軟件項(xiàng)目快速開發(fā)歡送閱讀作、響應(yīng)變化能力的價(jià)值觀和原那么，特征驅(qū)動(dòng)軟件開發(fā)他們稱自己為敏捷聯(lián)盟。敏捷開發(fā)過程的方法很多,主

13、要有：SCRUM ,Crystal,FeatureDriven Development,簡稱FDD，自適應(yīng)軟件開發(fā)(Adaptive Software Development,簡稱ASD),以及最重要的極限編程(eXtreme極限編程是一套能快速開發(fā)高質(zhì)量軟件所需的價(jià)值觀、 益。XP在很多方面都和傳統(tǒng)意義上得軟件工程不同，同時(shí),Programming,簡稱 XP)。原那么和活動(dòng)的集合，使軟件能以盡可能快的速度開發(fā)出來并向客戶提供最高的效它也和傳統(tǒng)得管理和工程方案得方法不同。這些方法在軟件工程和其他管XP。理活動(dòng)中都有借鑒意義。XP具有12個(gè)過程，只有完全使用12個(gè)過程才是真正使用了XP,只是簡

14、單使用了其中一個(gè)方法并不代表使用了現(xiàn)場客戶On-site Customer方案博弈Planning Game 系統(tǒng)隱喻System Design 簡化設(shè)計(jì)Simple Design 集體擁有代碼 Collective Code Ownership結(jié)對(duì)編程Pair Programming 測試驅(qū)動(dòng)Test-driver小型發(fā)布Small Release重構(gòu)Refactoring 持續(xù)集成Continous integration每周40小時(shí)工作制40-hour Weeks 代碼標(biāo)準(zhǔn)Coding Standards卜面是極限編程的有效實(shí)踐:軟件項(xiàng)目快速開發(fā)歡送閱讀1. 完整團(tuán)隊(duì)XP工程的所有參與者

15、開發(fā)人員、客戶、測試人員等一起工作在一個(gè)開放的場所中，他們是同一個(gè)團(tuán)隊(duì)的成員。這 個(gè)場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進(jìn)度的東西。2. 方案游戲方案是持續(xù)的、循序漸進(jìn)的。每 2周，開發(fā)人員就為下2周估算候選特性的本錢，而客戶那么根據(jù)本錢和商務(wù)價(jià)值來選擇要 實(shí)現(xiàn)的特性。3. 客戶測試作為選擇每個(gè)所期望的特性的一局部，客戶可以根據(jù)腳本語言來定義出自動(dòng)驗(yàn)收測試來說明該特性可以工作。4. 簡單設(shè)計(jì)團(tuán)隊(duì)保持設(shè)計(jì)恰好和當(dāng)前的系統(tǒng)功能相匹配。它通過了所有的測試，不包含任何重復(fù)，表達(dá)出了編寫者想表達(dá)的所有東西，并且包含盡可能少的代碼。5. 結(jié)對(duì)編程所有的產(chǎn)品軟件都是由兩個(gè)程序員、并排

16、坐在一起在同一臺(tái)機(jī)器上構(gòu)建的。6. 測試驅(qū)動(dòng)開發(fā)編寫單元測試是一個(gè)驗(yàn)證行為，更是一個(gè)設(shè)計(jì)行為。同樣，它更是一種編寫文檔的行為。編寫單元測試防止了相當(dāng) 數(shù)量的反應(yīng)循環(huán)，尤其是功功能能驗(yàn)證方面的反應(yīng)循環(huán)。程序員以非常短的循環(huán)周期工作，他們先增加一個(gè)失敗的測試，然后使 之通過。7. 改良設(shè)計(jì)隨時(shí)利用重構(gòu)方法改良已經(jīng)腐化的代碼，保持代碼盡可能的干凈、具有表達(dá)力。8. 持續(xù)集成團(tuán)隊(duì)總是使系統(tǒng)完整地被集成。一個(gè)人拆入Check in后，其它所有人責(zé)任代碼集成。9. 集體代碼所有權(quán)任何結(jié)對(duì)的程序員都可以在任何時(shí)候改良任何代碼。沒有程序員對(duì)任何一個(gè)特定的模塊或技術(shù)單獨(dú)負(fù)責(zé)，每個(gè)人都可以參與任何其它方面的開發(fā)。

17、10. 編碼標(biāo)準(zhǔn) 系統(tǒng)中所有的代碼看起來就好似是被單獨(dú)一人編寫的。11. 隱喻 將整個(gè)系統(tǒng)聯(lián)系在一起的全局視圖；它是系統(tǒng)的未來影像，是它使得所有單獨(dú)模塊的位置和外觀變得明顯直觀。如果模塊 的外觀與整個(gè)隱喻不符，那么你就知道該模塊是錯(cuò)誤的。12. 可持續(xù)的速度 團(tuán)隊(duì)只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把工程看作是馬拉松長 跑，而不是全速短跑。極限編程是一組簡單、具體的實(shí)踐，這些實(shí)踐結(jié)合在形成了一個(gè)敏捷開發(fā)過程。極限編程是一種優(yōu)良的、通用的軟件開發(fā)方法，工程團(tuán)隊(duì)可以拿來直接采用，也可以增加一些實(shí)踐，或者對(duì)其中的一些實(shí)踐進(jìn)行修改后再采用。4.NoahWeb&#

18、39;'增量迭代"模式軟件項(xiàng)目快速開發(fā)歡送閱讀以RUP和極限編程中的增量所不同的的是NoahWeb “增量迭代模式僅適用于B/S軟件工程。考慮 B/S工程中的人員配置、工作重心與C/S工程截然不同的特殊性，因此該模式專門針對(duì)B/S工程而提出。從以往的很多B/S應(yīng)用開發(fā)案例來看，用戶的需求并不會(huì)在需求分析階段和原型開發(fā)階段就可以準(zhǔn)確獲得，時(shí)，往往在應(yīng)用系統(tǒng)接近發(fā)布用戶才會(huì)提出各種各樣具體的需求。B/S應(yīng)用開發(fā)過程中各階段中用戶需求變化圖導(dǎo)致這樣的原因很簡單：在需求分析階段，最終用戶不可能通過開發(fā)文檔就能想象出應(yīng)用系統(tǒng)運(yùn)行時(shí)的實(shí)際情況，而系統(tǒng)接近成型時(shí),用戶通過真實(shí)使用會(huì)感覺到系

19、統(tǒng)存在的問題和設(shè)計(jì)缺陷。由于用戶需求在發(fā)布前頻繁變更這一特性，使用傳統(tǒng) B/S解決方案的設(shè)計(jì)人員和開發(fā)人員將會(huì)此階段面臨需求變更的各種考驗(yàn)，工程周期和開發(fā)本錢也會(huì)在發(fā)布階段由于需求變更急劇擴(kuò)大，有時(shí)甚至可能之前工作推倒從來。 考慮B/S工程的特殊性軟件項(xiàng)目快速開發(fā)歡送閱讀B/S工程以往一直采用同 C/S軟件工程一樣的開發(fā)模式和流程管理。但由于 B/S工程同C/S工程太多的不同之處，使得 B/S工程開發(fā)周期很難控 制。B/S 一方面要面臨著需要短時(shí)間獲取需求，需求不明確。另一方面 B/S開發(fā)中美工和界面設(shè)計(jì)美化的重要性也不同于 C/S工程，B/S工程往往由 美術(shù)和程序兩方面的人員來決定需求并且相

20、互制約，這些巨大區(qū)別似的不能將 B/S工程等同與C/S工程來進(jìn)行管理。NoahWeb ”增量迭代開發(fā)模式的各步驟特點(diǎn)如下：r 用“迭代探索需求o 需求分析階段：設(shè)計(jì)人員關(guān)注的不是程序結(jié)構(gòu)設(shè)計(jì)，而是用戶流程，在需求分析階段就可以邀請(qǐng)用戶一起參與“動(dòng)作分解圖的設(shè)計(jì)，讓用戶從一開始就可以感受到軟件使用的流程，讓所開發(fā)的軟件從一開始就貼近用戶需求； 原型階段：原型階段將整個(gè)軟件工程的數(shù)據(jù)輸入界面和輸出按照動(dòng)作流程呈現(xiàn)給用戶，讓用戶可以直觀的從輸入輸出的具體細(xì)節(jié)體驗(yàn)軟件，反應(yīng)修改意見，讓開發(fā)的軟件再次貼近需求。 實(shí)現(xiàn)階段在此階段，還可以讓用戶通過至少兩個(gè)階段性的演示讓用戶體會(huì)軟件的流程和真實(shí)的數(shù)據(jù)輸入輸出，體驗(yàn)真實(shí)的軟件使用感覺，為項(xiàng)目開發(fā)團(tuán)隊(duì)反應(yīng)出更準(zhǔn)確的需求。 發(fā)布階段軟件項(xiàng)目快速開發(fā)歡送閱讀在發(fā)布階段軟件已經(jīng)能非常貼近最終用戶需求，即使發(fā)布后更意外的需求變更，也能輕松應(yīng)變。使用