天時——工具快速

　　在一個軟件項目所經歷的各階段中（如：⑴需求分析、⑵原型開發、⑶實現、⑷測試、⑸完成、⑹需求變更、⑺后期維護），不同階段選用適當的工具能非常直接的相應參與人員的工作效率、溝通效率，縮短單個步驟所需要的時間，從而在整體上縮短軟件項目的開發周期。值得注意的一點是，工具并不僅限于軟件形態的工具。

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

　　⑵原型開發：在軟件需求分析階段，需要搞清楚的是軟件要“做什么”的問題，并把這些需求通過文檔的形式描述出來，這也是目標系統的邏輯模型。進入設計階段，則要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型，即著手實現軟件的需求，并將設計的結果反映在“設計規格說明”文檔中，接下來開始設計。設計的基本任務包括：軟件結構、數據結構及數據庫設計、概要設計文檔。開發一個大而復雜的軟件系統，我們可以將它進行適當的分解來降低其復雜性，還可減少開發工作量，你也可以使用一些能夠提高設計速的軟件來幫助你進行設計，從而提高軟件生產率，降低開發成本。所用的工具比如使用UML繪制類圖的工具。

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

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

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

地利——模式快速

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

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

瀑布模型

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

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

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

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

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

?

2．RUP（Rational Unified Process 瑞理統一過程）

　　RUP是建立在非常優秀的軟件工程原則基礎上的，例如迭代，需求驅動，基于結構化的過程開發。它提供了幾個方法，例如每一次迭代產生一個工作原型，在每一個階段的結束決定項目是否繼續，這些方法提供了對開發過程的非常直觀的管理。RUP采用了萬維網技術，可以增強團隊的開發效率，并為所有成員提供了最佳的軟件實現方案。

　　RUP處理過程為軟件開發提供了規定性的指南、模板和范例。它可以通過提供一個應用于整個軟件開發周期的、可定制的最佳開發方案架構，RUP可以對整個開發小組的工作進行指導和安排。RUP將項目管理、商業建模、需求管理、分析和設計、測試以及變更控制等，統一到了一個一致的、貫穿整個開發周期的處理過程。

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

　　RUP是嚴格按照行業標準UML開發的，它的特點主要表現為如下六個方面：

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

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

3.敏捷開發，極限編程

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

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

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

• 現場客戶（On-site Customer）
• 計劃博弈（Planning Game）
• 系統隱喻（System Design）
• 簡化設計（Simple Design）
• 集體擁有代碼（Collective Code Ownership）
• 結對編程（Pair Programming）
• 測試驅動（Test-driver）
• 小型發布（Small Release）
• 重構（Refactoring）
• 持續集成（Continous integration）
• 每周40小時工作制（40-hour Weeks）
• 代碼規范（Coding Standards）

?

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

?

4.NoahWeb"增量迭代"模式

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

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

[B/S應用開發過程中各階段中用戶需求變化圖]

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

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

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

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

• 用“迭代”探索需求

• • 需求分析階段：

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

• 原型階段：

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

• 實現階段

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

• 發布階段

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

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

　　更多有關NoahWeb“增量迭代”開發模式的詳細介紹，可查看：

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

?

?

人和——經驗快速

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

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

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

?

后記：

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