中文字幕二区_国产精品免费在线观看_黄色网站观看_人人草人人澡_日本真实娇小xxxx

開發(fā)軟件所需要經(jīng)歷的階段

　　要談“快速開發(fā)”我們就需要先來了解一下軟件項目所需要經(jīng)歷的過程：

　　軟件的開發(fā)過程并不僅是一個編寫、實現(xiàn)代碼的簡單過程，軟件的開發(fā)需要經(jīng)歷許多的步驟。因此在開始時我們先用一個相對簡單的方式了解一下軟件開發(fā)的常見過程：

　　從上圖可以直觀的看出，一個軟件的開發(fā)至少是包含了上圖的三個階段、七個步驟。

　　而這個過程中又可能涉及到下列各種參與軟件開發(fā)的角色：

［并不是任何項目中都會出現(xiàn)所有角色，角色同實際的參與人員也并不一定一一對應(yīng)］

　　我們在此所探討的軟件“快速開發(fā)”為的是在軟件目標(biāo)、外部資源相同的情況下（如：同一團(tuán)隊，同一項目）可以縮減整個開發(fā)周期的各種方式，使軟件項目最終能在一個更短時間內(nèi)完成。

能縮短軟件開發(fā)周期的三種方式

　　縮短軟件開發(fā)周期其實一直是全世界軟件開發(fā)團(tuán)隊所長期關(guān)注的話題，把現(xiàn)在已被廣泛認(rèn)可的有效縮短周期的方式歸類一下可劃分為三大類：

1. 工具快速
2. 模式快速
3. 經(jīng)驗快速

　　其分別代表著實現(xiàn)軟件項目“快速開發(fā)”的“天時、地利、人和”，同時也蘊(yùn)藏著“天時不如地利，地利不如人和”的真諦。

天時——工具快速

　　在一個軟件項目所經(jīng)歷的各階段中（如：⑴需求分析、⑵原型開發(fā)、⑶實現(xiàn)、⑷測試、⑸完成、⑹需求變更、⑺后期維護(hù)），不同階段選用適當(dāng)?shù)墓ぞ吣芊浅Ｖ苯拥南鄳?yīng)參與人員的工作效率、溝通效率，縮短單個步驟所需要的時間，從而在整體上縮短軟件項目的開發(fā)周期。值得注意的一點是，工具并不僅限于軟件形態(tài)的工具。

　　⑴需求分析：是軟件項目開發(fā)第一個也是很重要的一個階段， 需求分析的基本任務(wù)是要準(zhǔn)確地定義新系統(tǒng)的目標(biāo)，為了滿足用戶需要，回答系統(tǒng)必須“做什么”的問題。 在這個階段中包含需要獲取需求、分析需求、編寫規(guī)格說明和需求驗證。從獲取需求到需求驗證的這個過程需要編寫文檔、繪制圖形、創(chuàng)建需求模型等，像文檔之類的工具可以使用word、繪制圖形可以使用visio、建�？梢允褂胷ational rose等工具軟件，有了這些工具的輔助，可提高編寫文檔的速度，縮短分析階段的周期。除了以上這些軟件形態(tài)的工具外還可為更快的項目參與人員之間的想法溝通，借助一些實體類工具，如紙制卡片，黑板或一些已經(jīng)成型的系統(tǒng)。

　　⑵原型開發(fā)：在軟件需求分析階段，需要搞清楚的是軟件要“做什么”的問題，并把這些需求通過文檔的形式描述出來，這也是目標(biāo)系統(tǒng)的邏輯模型。進(jìn)入設(shè)計階段，則要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型，即著手實現(xiàn)軟件的需求，并將設(shè)計的結(jié)果反映在“設(shè)計規(guī)格說明”文檔中，接下來開始設(shè)計。設(shè)計的基本任務(wù)包括：軟件結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計、概要設(shè)計文檔。開發(fā)一個大而復(fù)雜的軟件系統(tǒng)，我們可以將它進(jìn)行適當(dāng)?shù)姆纸鈦斫档推鋸?fù)雜性，還可減少開發(fā)工作量，你也可以使用一些能夠提高設(shè)計速的軟件來幫助你進(jìn)行設(shè)計，從而提高軟件生產(chǎn)率，降低開發(fā)成本。所用的工具比如使用UML繪制類圖的工具。

　　⑶實現(xiàn)：設(shè)計完成之后進(jìn)入編碼實現(xiàn)階段，為了提高整個項目的開發(fā)速度，編寫代碼我們可以借助一些有力的開發(fā)工具來加快速度，例如，如果是用JAVA語言開做開發(fā)的話，可以使用eclipse、JCreater，如果是用C#、VB你可以用Visual Studio.net；如果是開發(fā)網(wǎng)站之類的可以用Dreamweaver。美工可以使用photoshop或是FireWork之類的工具。節(jié)省項目的開發(fā)時間。另外一方面由于軟件技術(shù)的快速發(fā)展帶來了各種平臺和引擎，選用適當(dāng)?shù)钠脚_技術(shù)與引擎能更大程度的縮短周期。

　　⑷測試：軟件的測試也是一個非常重要的階段，大量的測試，甚至重復(fù)的測試引出了一個新的問題：全憑手工進(jìn)行測試會浪費大量的時間。因此，易變的需求對測試提出了一個新的要求：自動化測試。此類型的工具例如Xunit系列。只有自動化的進(jìn)行測試，才可以完成大量的測試工作，節(jié)省時間和人力方面的投入，加快項目的整體開發(fā)速度。關(guān)于自動化測試這方面的問題，大家可以參考相關(guān)的資料，這里我們不作深入的討論。

　　工匠用釘槍、成型磚塊、涂料噴霧器來建造一個小屋的話要比他單純用一把榔頭、沙磚、涂料刷來得快。擁有快速交通工具的人可以比擁有普通交通工具的人提前到達(dá)目的地。但不論什么情況下，如果質(zhì)量是非常重要的話，那么即使是強(qiáng)有力的工具也將會被手工工具所替代或輔助。軟件開發(fā)中使用工具的情況與上述情況也是非常相近的。

地利——模式快速

　　如前所說軟件開發(fā)的過程并不是一個簡單的過程，一個軟件的開發(fā)會被分成很多步驟來實現(xiàn)，每一個步驟都有自己的起點和終點。也正如此使得開發(fā)過程中的每個步驟起點和終點在不同的軟件項目中出現(xiàn)不同難度的“坎”，使其難于達(dá)到該步驟開始或是終結(jié)的條件，開發(fā)過程也就不會一帆風(fēng)順。

　　不同的開發(fā)模式其實就是將步驟的起點和終點重新定義，甚至重新組合排列，雖然任何一個開發(fā)模式最終目的都是完成軟件項目的開發(fā)，但期間所經(jīng)歷的過程不一樣，過程步驟之間的起點和終點的的定義不同所帶來的“坎”也就不一樣，項目周期自然各不相同，因此，根據(jù)軟件項目的實際情況選擇一個適合的開發(fā)模式能減少開發(fā)周期中“坎”的出現(xiàn)次數(shù)與難度，非常大程度的縮短開發(fā)周期。

瀑布模型

　　在本專題開始時我們所示范的開發(fā)流程，實際就是一種典型的瀑布模型（又稱線形模型）：

　　瀑布模型是由W.W.Royce在1970年最初提出的軟件開發(fā)模型，在瀑布模型中，開發(fā)被認(rèn)為是按照需求分析，設(shè)計，實現(xiàn)，測試 (確認(rèn))， 集成，和維護(hù)堅定地順暢地進(jìn)行。

　　在最初的文章中，Royce提倡重復(fù)地使用瀑布模型，以一種迭代的方式。但是，大多數(shù)人并不知道這一點，一些人也不相信它能夠作為一種真實世界的過程使用。在實踐中，過程很少能夠以純線性的方式進(jìn)行。 通過回到前面的階段或改便前一階段的結(jié)果的迭代是非常普遍的。

　　線性模型太理想化，太單純，以至很多人認(rèn)為瀑布模型已不再適合現(xiàn)代的軟件開發(fā)模式，幾乎被業(yè)界拋棄。偶而被人提起，都屬于被貶對象，未被留一絲惋惜。但我們應(yīng)該認(rèn)識到，“線性”是人們最容易掌握并能熟練應(yīng)用的思想方法。當(dāng)人們碰到一個復(fù)雜的“非線性”問題時，總是千方百計地將其分解或轉(zhuǎn)化為一系列簡單的線性問題，然后逐個解決。一個軟件系統(tǒng)的整體可能是復(fù)雜的，而單個子程序總是簡單的，可以用線性的方式來實現(xiàn)，否則干活就太累了。線性是一種簡潔，簡潔就是美。當(dāng)我們領(lǐng)會了線性的精神，就不要再呆板地套用線性模型的外表，而應(yīng)該用活它。

　　瀑布模型解決了軟件工程上面的基本管理需求，但是對于我們所提的軟件項目的“快速開發(fā)”瀑布模型并沒有什么優(yōu)勢。

2．RUP（Rational Unified Process 瑞理統(tǒng)一過程）

　　RUP是建立在非常優(yōu)秀的軟件工程原則基礎(chǔ)上的，例如迭代，需求驅(qū)動，基于結(jié)構(gòu)化的過程開發(fā)。它提供了幾個方法，例如每一次迭代產(chǎn)生一個工作原型，在每一個階段的結(jié)束決定項目是否繼續(xù)，這些方法提供了對開發(fā)過程的非常直觀的管理。RUP采用了萬維網(wǎng)技術(shù)，可以增強(qiáng)團(tuán)隊的開發(fā)效率，并為所有成員提供了最佳的軟件實現(xiàn)方案。

　　RUP處理過程為軟件開發(fā)提供了規(guī)定性的指南、模板和范例。它可以通過提供一個應(yīng)用于整個軟件開發(fā)周期的、可定制的最佳開發(fā)方案架構(gòu)，RUP可以對整個開發(fā)小組的工作進(jìn)行指導(dǎo)和安排。RUP將項目管理、商業(yè)建模、需求管理、分析和設(shè)計、測試以及變更控制等，統(tǒng)一到了一個一致的、貫穿整個開發(fā)周期的處理過程。

　　RUP正如其名，它使團(tuán)隊中每個開發(fā)人員的見解和思想得到統(tǒng)一，使開發(fā)小組成員的溝通更為容易，而這正是任何項目要取得成功的關(guān)鍵因素；它增強(qiáng)了開發(fā)人員對軟件的預(yù)見性，最終的好處就是提高了軟件質(zhì)量，并有效縮短了軟件從開發(fā)到投放市場的時間，全面提高了開發(fā)速度。

　　RUP是嚴(yán)格按照行業(yè)標(biāo)準(zhǔn)UML開發(fā)的，它的特點主要表現(xiàn)為如下六個方面：

• 開發(fā)復(fù)用。減少開發(fā)人員的工作量，并保證軟件質(zhì)量，在項目初期可降低風(fēng)險。
• 對需求進(jìn)行有效管理。
• 可視化建模。
• 使用組件體系結(jié)構(gòu)，使軟件體系架構(gòu)更具彈性。
• 貫穿整個開發(fā)周期的質(zhì)量核查。
• 對軟件開發(fā)的變更控制。

　　RUP可以縮短軟件項目的開發(fā)周期，實現(xiàn)大型項目的快速開發(fā)，對于中小型項目RUP就顯的過于龐大，其需要投入的成本也很非常觀。

3.敏捷開發(fā)，極限編程

　　2001年，為了解決許多公司的軟件團(tuán)隊陷入不斷增長的過程泥潭，一批業(yè)界專家一起概括出了一些可以讓軟件開發(fā)團(tuán)隊具有快速工作、響應(yīng)變化能力的價值觀和原則，他們稱自己為敏捷聯(lián)盟。敏捷開發(fā)過程的方法很多，主要有：SCRUM，Crystal,特征驅(qū)動軟件開發(fā)（Feature Driven Development，簡稱FDD），自適應(yīng)軟件開發(fā)(Adaptive Software Development，簡稱ASD)，以及最重要的極限編程(eXtreme Programming,簡稱XP)。

　　極限編程是一套能快速開發(fā)高質(zhì)量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發(fā)出來并向客戶提供最高的效益。XP在很多方面都和傳統(tǒng)意義上得軟件工程不同，同時，它也和傳統(tǒng)得管理和項目計劃得方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。

　　XP具有12個過程，只有完全使用12個過程才是真正使用了XP，只是簡單使用了其中一個方法并不代表使用了XP。

• 現(xiàn)場客戶（On-site Customer）
• 計劃博弈（Planning Game）
• 系統(tǒng)隱喻（System Design）
• 簡化設(shè)計（Simple Design）
• 集體擁有代碼（Collective Code Ownership）
• 結(jié)對編程（Pair Programming）
• 測試驅(qū)動（Test-driver）
• 小型發(fā)布（Small Release）
• 重構(gòu)（Refactoring）
• 持續(xù)集成（Continous integration）
• 每周40小時工作制（40-hour Weeks）
• 代碼規(guī)范（Coding Standards）

　　下面是極限編程的有效實踐：

1. 完整團(tuán)隊 XP項目的所有參與者（開發(fā)人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團(tuán)隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進(jìn)度的東西。
2. 計劃游戲計劃是持續(xù)的、循序漸進(jìn)的。每2周，開發(fā)人員就為下2周估算候選特性的成本，而客戶則根據(jù)成本和商務(wù)價值來選擇要實現(xiàn)的特性。
3. 客戶測試作為選擇每個所期望的特性的一部分，客戶可以根據(jù)腳本語言來定義出自動驗收測試來表明該特性可以工作。
4. 簡單設(shè)計團(tuán)隊保持設(shè)計恰好和當(dāng)前的系統(tǒng)功能相匹配。它通過了所有的測試，不包含任何重復(fù)，表達(dá)出了編寫者想表達(dá)的所有東西，并且包含盡可能少的代碼。
5. 結(jié)對編程所有的產(chǎn)品軟件都是由兩個程序員、并排坐在一起在同一臺機(jī)器上構(gòu)建的。
6. 測試驅(qū)動開發(fā)編寫單元測試是一個驗證行為，更是一個設(shè)計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當(dāng)數(shù)量的反饋循環(huán)，尤其是功功能能驗證方面的反饋循環(huán)。程序員以非常短的循環(huán)周期工作，他們先增加一個失敗的測試，然后使之通過。
7. 改進(jìn)設(shè)計隨時利用重構(gòu)方法改進(jìn)已經(jīng)腐化的代碼，保持代碼盡可能的干凈、具有表達(dá)力。
8. 持續(xù)集成團(tuán)隊總是使系統(tǒng)完整地被集成。一個人拆入（Check in）后，其它所有人責(zé)任代碼集成。
9. 集體代碼所有權(quán)任何結(jié)對的程序員都可以在任何時候改進(jìn)任何代碼。沒有程序員對任何一個特定的模塊或技術(shù)單獨負(fù)責(zé)，每個人都可以參與任何其它方面的開發(fā)。
10. 編碼標(biāo)準(zhǔn) 系統(tǒng)中所有的代碼看起來就好像是被單獨一人編寫的。
11. 隱喻 將整個系統(tǒng)聯(lián)系在一起的全局視圖；它是系統(tǒng)的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的。
12. 可持續(xù)的速度 團(tuán)隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。 極限編程是一組簡單、具體的實踐，這些實踐結(jié)合在形成了一個敏捷開發(fā)過程。極限編程是一種優(yōu)良的、通用的軟件開發(fā)方法，項目團(tuán)隊可以拿來直接采用，也可以增加一些實踐，或者對其中的一些實踐進(jìn)行修改后再采用。

4.NoahWeb"增量迭代"模式

　　以RUP和極限編程中的增量所不同的的是NoahWeb“增量迭代”模式僅適用于B/S軟件項目�？紤]B/S項目中的人員配置、工作重心與C/S項目截然不同的特殊性，因此該模式專門針對B/S項目而提出。

　　從以往的很多B/S應(yīng)用開發(fā)案例來看，用戶的需求并不會在需求分析階段和原型開發(fā)階段就可以準(zhǔn)確獲得，往往在應(yīng)用系統(tǒng)接近發(fā)布時，用戶才會提出各種各樣具體的需求。

[B/S應(yīng)用開發(fā)過程中各階段中用戶需求變化圖]

　　導(dǎo)致這樣的原因很簡單：在需求分析階段，最終用戶不可能通過開發(fā)文檔就能想象出應(yīng)用系統(tǒng)運行時的實際情況，而系統(tǒng)接近成型時，用戶通過真實使用會感覺到系統(tǒng)存在的問題和設(shè)計缺陷。由于用戶需求在發(fā)布前頻繁變更這一特性，使用傳統(tǒng)B/S解決方案的設(shè)計人員和開發(fā)人員將會此階段面臨需求變更的各種考驗，項目周期和開發(fā)成本也會在發(fā)布階段由于需求變更急劇擴(kuò)大，有時甚至可能之前工作推倒從來。

• 考慮B/S項目的特殊性

　　B/S項目以往一直采用同C/S軟件項目一樣的開發(fā)模式和流程管理。但由于B/S項目同C/S項目太多的不同之處，使得B/S項目開發(fā)周期很難控制。B/S一方面要面臨著需要短時間獲取需求，需求不明確。另一方面B/S開發(fā)中美工和界面設(shè)計美化的重要性也不同于C/S項目，B/S項目往往由美術(shù)和程序兩方面的人員來決定需求并且相互制約，這些巨大區(qū)別似的不能將B/S項目等同與C/S項目來進(jìn)行管理。

　　NoahWeb“增量迭代”開發(fā)模式的各步驟特點如下：

• 用“迭代”探索需求

• 需求分析階段：

　　設(shè)計人員關(guān)注的不是程序結(jié)構(gòu)設(shè)計，而是用戶流程，在需求分析階段就可以邀請用戶一起參與“動作分解圖”的設(shè)計，讓用戶從一開始就可以感受到軟件使用的流程，讓所開發(fā)的軟件從一開始就貼近用戶需求；

• 原型階段：

　　原型階段將整個軟件項目的數(shù)據(jù)輸入界面和輸出按照動作流程呈現(xiàn)給用戶，讓用戶可以直觀的從輸入輸出的具體細(xì)節(jié)體驗軟件，反饋修改意見，讓開發(fā)的軟件再次貼近需求。

• 實現(xiàn)階段

　　在此階段，還可以讓用戶通過至少兩個階段性的演示讓用戶體會軟件的流程和真實的數(shù)據(jù)輸入輸出，體驗真實的軟件使用感覺，為項目開發(fā)團(tuán)隊反饋出更準(zhǔn)確的需求。

• 發(fā)布階段

　　在發(fā)布階段軟件已經(jīng)能非常貼近最終用戶需求，即使發(fā)布后更意外的需求變更，也能輕松應(yīng)變。

　　使用該模式項目實施B/S項目的效果將很大程度上區(qū)別于其他模式效果。軟件項目的開發(fā)中需求分析與編碼實現(xiàn)已經(jīng)被融為一體，而且在開發(fā)的任意階段，開發(fā)人員都已經(jīng)準(zhǔn)備好應(yīng)付后續(xù)階段可能出現(xiàn)的任何變化。變化成為計劃一部分。

　　更多有關(guān)NoahWeb“增量迭代”開發(fā)模式的詳細(xì)介紹，可查看：

• 適合1月以下的“增量迭代”管理流程
• 適合1月以上的“增量迭代”管理流程

人和——經(jīng)驗快速

　　經(jīng)驗所能帶來的效率提升與工具和模式所帶來的提升完全不同。項目參與人員經(jīng)驗越多軟件項目摸索的過程就越短、彎路越少。但是不同參與人員的相關(guān)經(jīng)驗只能通過長時間的積累和一些“強(qiáng)化訓(xùn)練”的學(xué)習(xí)方式獲得。

　　不同的項目參與角色來的相應(yīng)經(jīng)驗對軟件項目的效率提升面也各不相同，以下我們列表出各參與角色的經(jīng)驗對軟件開發(fā)周期縮短所起的一些直接作用：

　　經(jīng)驗一方面雖然很好，可也會導(dǎo)致模式化，壞的模式化的會給軟件項目帶來不良的損失。

后記：

　　天時（工具），地利（模式），人和（經(jīng)驗）在軟件項目的快速開發(fā)各自起著決定性的作用，如果希望軟件項目能按計劃完成、甚至縮短項目周期則三方優(yōu)勢缺一不可。工具、模式、經(jīng)驗綜合應(yīng)用才能對軟件的開發(fā)做到運籌帷幄、千萬不要只一味的追求或依靠某一方面導(dǎo)致最終的全局失敗。

　　您是否愿意更多的了解NoahWeb？是否愿意全面深入的體會和了解NoahWeb？是否愿意參與到“真實”的開發(fā)團(tuán)隊中使用NoahWeb進(jìn)行實際的項目開發(fā)，在“實戰(zhàn)”中，與其他同仁組成的開發(fā)團(tuán)隊一起感受NoahWeb的魅力，點擊這里回答幾個簡單的問題，讓我們了解你的想法，讓我們帶給你更多精彩。