用UML統一開發團隊 UML模型
為了提高生產效率并獲得成功,開發團隊的成員需要擁有通用過程,通用的術語表和相應的支持工具。這篇文章討論了UML如何能夠幫助你達到這個目標。
在現代的軟件開發中存在這一種基本上相互矛盾的論點。一方面組織面對著更加快速的響應市場的要求;另一方面,在相同的組織中還面臨著以更低的成本交付高質量系統的壓力。在這兩者之間維持一個平衡是非常難的:匆忙的將軟件系統推向市場,系統的質量勿庸置疑的會受到指責;而僅僅考慮質量問題,你也可能因為花費了過長的時間交付系統給用戶而導致失敗。
隨著軟件開發的本質發生的改變,融合這對相互矛盾的論點也成為了現實。從歷史的觀點來看,許多信息系統從體系架構上是非常簡單的:應用被建立在中間層的基礎上,中間層典型的封裝了商業規則和數據訪問,并且中間層被建立在永久存儲之上,通常使用關系型的數據庫系統。關系型數據庫(或者數據庫)本質上是系統的中心,它獲取系統問題領域的詞匯表并作為系統狀態的存儲服務??蛻舳?服務器架構的出現幫助了劃分3層分離的結構,對于組織來說可以以一種可控的方式來應對系統相應的變化。尤其是,應用要能被快速的創建和修改,同時還要保存系統的狀態,新的業務規則應該能夠被引入而不會使系統受到影響,并且數據應該可以隨著時間的流逝以一種新的或未預期的方式被挖掘。已被證明的且穩定的體系架構指引著很多組織以相應的方式構建他們的團隊:分析人員與領域專家一起工作將用戶的需要裝化成需求,數據建模人員構建滿足這些客戶功能需求的領域模型,應用開發人員通過快速的構建和分解來建立滿足系統行為需求的的新系統。
然而,隨著Web的出現,軟件開發的世界發生的翻天覆地的變化。在傳統的客戶端/服務器形式的系統中,一個系統典型的擁有可控數量的用戶,通常用戶的數量在幾百到幾千人之間;而在Web系統的情況下,一個系統也許會有幾百萬的用戶,這些用戶中的很多都是不在軟件開發組織的控制之下的。在傳統的客戶端/服務器的系統中,從應用到數據的概念性的距離是非常小的;而在Web環境下,多數系統是由成千上萬的移動的部分組成,這些移動部分通常是一些腳本的和一些編譯過的代碼,通過使用這些機制,使得應用和關系型的存儲在距離上是相當遠的。在傳統的客戶機/服務器系統中,變化是不可避免的,但變化可以被適當的管理,而在Web環境下,變化是連續的,并且變化發生在系統體系架構和實現技術的每一個層面上。在傳統的客戶機/服務器系統中,成功的開發并發布系統的涉眾數量相對來說是比較少的;而在Web環境下,有很多新的涉眾參與到了系統的開發當中,從內容的創建者到信息架構到網絡設計,所有這些人都必須與傳統的軟件開發團隊共同工作以克服軟件開發中的矛盾。
成功的處理軟件開發中的矛盾的組織與哪些在這方面失敗的組織在組織運作的方法上存在著本質的不同。特別的,高生產效率的組織將軟件開發看作為一項團隊運動,在這樣的組織中很多不同的對系統的開發和部署作出貢獻的涉眾通過使用通用的過程,通用的表達語言并使用支持和鼓勵與過程和語言相關的最佳實踐的工具來實現統一。
Rational統一過程(RUP)是一種已經被證明對大多數面臨著軟件開發中的矛盾的組織來說是非常有用的。RUP是一種鼓勵以增量和迭代的方式交付系統的可執行版本的過程。RUP是風險和用例驅動的,這就意味著RUP傾向盡早的識別和處理防礙系統成功的風險,并且它的迭代是被來自于系統不同涉眾透視圖的用例指導的。此外,RUP是一種架構先行的過程,無論在哪里,系統的架構都是在早期就被穩定下來的,這樣便可以建立和驗證策略性的設計決定,然后在每一個新的迭代中進行不斷的細化。
原文轉自:http://www.anti-gravitydesign.com