優良的軟件過程可以為開發高質量的軟件提供有效的實踐方案。隨著軟件開發復雜性的日益增強及軟件行業規范化管理經驗的逐漸積累，通過依托某種軟件過程在開發中產生恰當制品、科 學有效地控制開發節奏與步驟，從而合理調配與使用開發資源、滿足開發愿景，已經成為提高軟件生產率、確保如期按質地提交軟件成果的重要途徑，而這一觀念也正被越來越多的軟件開發公司所認同和采用。

      2. 軟件過程和敏捷建模

      經典軟件工程理論所闡述的軟件過程，特別是瀑布模型，由于其較強的理想化環境條件假設，所以如果在實際軟件開發項目中采用，往往會與實際情況產生較大脫節，使得實施效果大打折扣，故而往往只以具有理論參考意義的面孔出現。而當前在業界，既有完整理論，又有較強可操作性的軟件過程，則以統一過程（the Unified Process,簡稱UP）和極限編程（the eXtreme Programming,簡稱XP）最為令人矚目。

       2.1 統一過程與極限編程及其思想觀念

      2.1.1 UP與XP的特征

      統一過程作為一種重量級的指導性的軟件過程，其基本特征體現在用例驅動、以架構為中心、迭代和增量開發等幾方面。根據對統一過程生命周期的不同劃分方法，統一過程還分為企業統一過程（EUP）、Rational統一過程（RUP）等不同子類型。而極限編程則不同于統一過程，它在本質上屬于更為敏捷的一種軟件過程，并由一系列簡單卻互為補充的實踐所組成。

      2.1.2 統一過程的優勢

      雖然比較XP而言，UP更為傳統一些，其過程控制靈活度也相對較弱，但由于這種軟件過程非常適用于復雜、需求多變、開發難度大的情況，同時也可以根據項目特點進行適當裁剪，所以仍然被許多軟件企業所廣泛采用。特別是，對于一些在軟件過程控制方面依據UP原則已經形成較為固定模式、同時又注重以各階段的指定制品控制開發節奏的公司而言，如何在保持UP基本方法的前提下，提高UP項目開發的敏捷性則是一個非?，F實而重要的課題。

      2.2 以敏捷建模改造統一過程的可行性

      2.1.3 敏捷建模與統一過程在實踐中的內在聯系

      事實上，敏捷建模（Agile Modeling，簡稱AM）所倡導的一系列實踐中有許多做法與UP的實踐是不謀而合的，有的還加強或改進了UP的某些實踐。比如：
      UP和AM都強調“項目關系人積極參與”的重要意義，甚至允許項目關系人參與建模。
UP和AM都強調“用代碼驗證”、“并行創建多個模型”。即使是UP，在必要情況下也可調整決定同時執行源于不同規程的活動。
      UP和AM都遵循“增量建?！钡膶嵺`，但AM通過減小增量的幅度，改善了UP的迭代實踐。
      AM“有危害時才更新模型”的實踐改進了UP及時同步各階段不同制品的要求。
      AM“使用合適的制品”的實踐改進了UP對UML建模制品的過分依賴。
      AM“集體所有”的實踐改進了UP項目中有關配置管理的觀念，通過營造開放、交流的團隊文化，使所有項目成員都能訪問和修改各自想處理的制品，包括模型和文檔。
      AM“使用最簡單的工具”的實踐拓展了UP只注重使用CASE工具的局限。

      2.1.4 實踐敏捷建模的主要原則

      與UP、XP相比，AM本身則是一種基于實踐的、不完整的、有序與混亂并存的軟件過程。通常，軟件的開發可將UP、XP等作為基礎軟件過程，用AM增強這些更加完整的軟件過程。

      AM的概念吸收了敏捷開發聯盟（Agile Software Development Alliance）所倡導的若干原則（限于篇幅，這些條款將不在文中詳述），并形成了自己的一系列原則與實踐?？v觀AM論壇發起人Scott W. Ambler所提出的涉及AM的11條核心原則和13條核心實踐，筆者認為，體現AM精髓的原則主要集中在如下幾個方面：
      (1）明確最終目標：即軟件本身才是應當確保的工作目標；
      (2）快速迭代反饋：明確各階段問題焦點，快速修訂前一階段過程中的制品，并推回后一階段；
      (3）多種模型建模：即要勇于突破傳統軟件過程所規定的建模工具的約束，根據效果特點采用適用的建模模型描述軟件；
      (4）簡化工作過程：任何階段都要以最簡單的解決方案來達至工作目標，不要追求形式、不要過度構建軟件。
      雖然按照Ambler的觀點，必須完全執行所有11條核心原則和13條核心實踐才能算得上是在敏捷建模，但筆者認為，由于AM本身就是一種不完整的軟件過程，況且AM本身必定會在行業實踐中進一步得到充實，所以可以認為，在目前階段，實踐上面總結出來的四條原則即可基本反映出AM的精髓。

      3. 太原同城系統開發中的敏捷建模實踐

      在上述方針的指導下，可以利用敏捷建模對統一過程施行改造。以下將以山西省太原市人民銀行同城票據清算系統v2.0（以下簡稱“太原同城系統”）為例，說明應用AM原則與實踐在改造一個UP開發項目過程中的一些體會。

      3.1太原同城清算系統介紹

      3.1.1開發背景

      太原同城系統是在金融體制改革的形勢下，由北京市泰通電子技術公司承擔開發的，在太原市轄區范圍內建設的一個連接該市各個商業銀行和與人民銀行清算中心的票據實時清算系統。通過實時處理貸記、借記票據交換業務，可以改變傳統的票據手工交換方式，以電子流代替票據流，使資金可即時抵用，為各商業銀行提供統一、快捷、安全、可靠的資金清算渠道，也為人民銀行提供了監控資金流量與流向的現代化手段。

       3.1.2系統體系結構

       太原同城系統是一個基于交易中間件、復合平臺、多語言聯合開發的三層C/S結構系統。其三層架構分別為：
      (1）數據層：運行在人行結算中心的數據庫服務器上，OS為TurboLinux Enterprise 8.0，DBMS為Oracle9i Enterprise for linux。
      (2）中間層：運行在人行結算中心的應用服務器上，OS為TurboLinux Enterprise 8.0，用C++語言實現了核心商業服務，開發工具選用Borland C++BuilderX 1.0 Enterprise。
      (3）表示層：運行在各商業銀行的PC前端機（SCO UNIX 5.05平臺，270臺）及人行結算中心的PC前端機（Win2000/RedflagLinux4.0平臺，5臺）上。商行前端程序用C語言實現；人行前端程序用JAVA語言實現，開發工具選用Borland JBuilder 7 Enterprise。
      上述三個層次分別安裝了東方通科技公司的消息中間件TongEASY 4.5 for Linux/SCO UNIX/Windows，整個系統的事務處理功能即由它保證。TongEASY作為一個基于三層C/S體系結構的中間件，其構成的交易管理平臺提供了交易管理、負載均衡、應用調度等功能。其包含的通訊管理模塊還提供了可靠的數據傳輸、網絡監控、流量控制等功能。

      3.2太原同城系統開發中的敏捷建模實踐

      本人作為太原同城系統的項目經理，按照上文所述觀點，將敏捷實踐中“明確最終目標、快速迭代反饋、多種模型建模、簡化工作過程”這四方面的內容與實際開發的過程控制進行了結合。以下是對其中這幾方面實踐內容的總結。

      3.2.1太原同城系統的快速迭代與增量式開發實踐

      這一實踐體現了“快速迭?蠢　鋇木??。???竅低車幕?救砑??灘捎肦UP。按照Rational公司對UP的定義，軟件開發的生命周期被劃分為初始、細化、構造、交付四個階段，每個階段結束于定義良好的里程碑――即某些關鍵決策必須做出的時間點。為了更好地控制變更、減少開發風險，太原同城系統的開發遵循了RUP所規定的從一個迭代過程到下一個迭代過程的遞增式增長，從而形成了最終系統。具體而言，這些迭代過程包括：
      (1）第一次迭代（歷時一個半月）：
      跨越UP所定義的初始階段。該次迭代實現的UP規程主要包括：初步業務建模、捕獲業務需求、建立開發環境等。通過該次迭代，完成了架構方案的確定，實現了部分子系統中最關鍵的業務用例的分析設計與編碼、測試――比如票據發送、票據接收、票據文件生成等。同時，通過測試比較，項目組明確了系統的體系結構，即：立足于基于消息中間件的三層C/S結構系統。此外，還根據上述體系結構的特點，確定了開發語言與開發工具。值得一提的是，該次迭代的初衷并非單純針對太原同城系統，但太原同城系統事實上成為了此次迭代過程的第一個受益者。
      (2）第二次迭代（歷時兩個半月）：
      跨越了UP所定義的細化階段和構造階段。該次迭代實現的UP規程包括業務建模、需求分析、體系結構設計、編碼實現，它所包括的數次小的迭代過程分別側重于分析、設計和編碼實現。首先，通過本次迭代，基本完成了對所有概要級別用例、用戶級別用例及大部分子功能級別用例的分析，同時，還完成了類設計、基本數據靜態結構設計與數據動態流向設計。系統架構的整體搭建也在此階段完成。之后，在上述架構的基礎上實現了相應的編碼工作。
      (3）第三次迭代（歷時兩個半月）：
      跨越了UP所定義的構造階段和移交階段。該次迭代實現的UP規程包括補充業務建模、補充需求分析、補充編碼實現、系統測試、運行和支持等。通過該次迭代，完成了對各級別用例的修改、補充，補充完善了各功能模塊的代碼，完成了系統測試和部署準備。

      當然，系統最終迭代次數的變更結果取決于太原同城系統的實際部署效果和部署后用戶的意見反饋。
同時，系統在進行某一階段的建模工作時，還注意盡量避免在該階段只專注于一個制品的制作。比如，在用例建模階段，還同時進行了用戶界面原型的設計工作；在數據建模階段，還將設計會議包括進來。

       3.2.2太原同城系統的多種模型建模實踐

      太原同城系統的過程控制實踐很注重改造系統啟動時組織內部因沿襲UP思維方式而可能存在的不符合AM原則的文化障礙。比如，根據AM“多種模型建?！钡木?，太原同城系統的建模過程就沒有受限于UML規定的若干建模制品。
      雖然UML定義了一系列的建模制品，但很顯然，完整創建其定義的所有建模制品是沒有必要的。另一方面，UML建模制品至少在分析需求時并不完備，也存在盲點。比如，UML無法滿足用戶界面建模需求、UML的活動圖無法描述一個信息存儲的位置信息等等。因此，在太原同城系統的開發中對UML制品根據需要進行了取舍。針對UML建模制品的不足，還補充了其它一些制品，包括一些UML問世之前就存在了的建模制品（如數據流圖），甚至包括一些有獨創性的建模制品（如數據流向設計）。下面是太原同城系統分析設計過程中一些制品的制作情況描述：

      ⑴ 編寫有效用例，透徹描述和分解需求規格說明書中提出的各項功能需求。
比如，對于“中心日初始化”這一功能而言，我們需要清楚地說明人行結算中心在每個工作日業務開始時，日初始化功能涉及到的主執行者、目標、前置條件、觸發條件、主要場景、意外情況處理等細節情況。其有效用例主要部分摘要如下：
“中心日初始化”處理用例
n 主執行者：人行結算中心系統管理員
n 語境中的目標：人行結算中心系統能開始處理稅票信息。

原文轉自：http://www.kjueaiud.com