或許？剛入門的軟體開發者還不一定很清楚軟體的開發流程(Development Process)與UML到底有何關連？
所以我想用簡簡單單的幾句話來概述為何是 UML？又，為何沒有所謂標準的開發流程？

軟體應用系統的開發，通常是以專案(Project)的方式來進行。由包括 PM(Project Manager)、Architect(架構師)、HSD(High-level system designer)、DSD(Detailed system designer, 接近 CTO 的角色)、Programmer(程式設計師)等各種角色所組成的團隊。在一定的時程內，運用有效的資源，來達成有效率的系統開發。

專案開發的期間，在每一個階段會由不同角色的開發人員，依據職責來產出包括需求設計、軟體設計圖、程式碼．．．等。在有限的時程與資源，如何做最有效率的專案控管，團隊之間的 ”溝通”與所制訂的 ”開發製程” 可說是影響整個專案成敗的最重要關鍵了。

UML(Unified Modeling Language)，統一模式語言，已成為標準化、視覺化的塑模工具。無論作為軟體開發團隊內部溝通、或軟體設計與程式寫碼的兩地(如台灣設計、大陸施工)分工模式，UML 是唯一可以跨國界、無縫式地從企業流程分析、系統分析/設計、並銜接到系統開發階段的最佳表示法(Notation)。UML 並已成為軟體業界的國際標準。

至於開發製程，也有業界所推出 RUP(Rational Unified Process)、XP(eXtreme Programming)乃至於所謂的 “Agile Modeling Process”。
每種開發製程理論均有它的核心思維，但其目的均在於期望能在專案的四大變數：”成本”、”品質”、”時程” 與 “規模” 之間達成一定的均衡。

開發製程無法如 UML 一般可以成為所謂的 “國際標準”，原因即在於專案的性質及成員的素質等因素均不盡相同。但上述提及業界所推的開發製程，卻可以成為開發團隊在自訂自己內容開發程序時的最佳參考與範本(Template)，甚而可以成為很好的輔導工具。

這麼說好了，團隊開發成員之間可以講相同的語言(UML)，以利相互的溝通；但每個團隊要如何達成目標，則各有其方法與程序(Process)來達成任務。程序是 “How-to”，每個團隊的 “How-to” 是不會完全一樣的。

又，為何是用 UML 來作為溝通的工具？

由於擔任系統開發的各種不同角色的團隊成員之間需要能做有效率地溝通，傳統的系統開發，大部分是以所謂企業流程圖(Business-flow diagram)或以程式碼來溝通。
前者是從在企業內部擔任高階經理人的角度來看待系統，所表達的往往是系統的功能面需求(Functional Requirement)，並不足以表達軟體系統的內部結構；而後者，又太接近與系統平台面相關的程式碼，且每個程式設計師的程式碼撰寫風格不盡相同，直接以程式碼來作為團隊之間的溝通，對 PM及SA/D等人的解讀障礙度非常高。
前者太粗糙(coarse-grained)；後者又太細緻(fine-grained)，都不足以成為團隊所有成員之間的溝通工具。

俗話說：「一圖勝過千言萬語」。使用圖形(Diagram)的方式來表達內心的設計思維，會是一個很好的溝通工具。
就如同建築業的建築師，在施工前會先以設計的藍圖來表達對建構實體高樓大廈的想法。且設計的藍圖會因為不同的作用而有不同種類的表達，例如鋼架結構設計圖、水電管線配置圖、室內設計圖．．．等，均是設計師與施工人員在施工之前作為溝通及確認施工前的最重要依據。

貝多芬用五線譜來創造音樂，我們用UML(Unified Modeling Language)來設計軟體；UML有如五線譜，兩者都是模式語言，只不過前者通用於軟體界，而後者通用於音樂界。