業務建模

業務建模（ ）建模集合，業務建模。包括業務流程建模，業務組織建模，改業務流程，領域建模。

 ，各式各系統（  ）歷修修改改，非，群怪獸，馴服。

，         .（（系統）改潮流頑石）。

對很多企業而言，有一個統合企業各部門的信息系統的心愿似乎已經成了一種奢望。企業中或多或少都會有一些應用系統在輔助企業的自動化運作，當企業信息主管希望能夠對信息系統進行整合，能夠配合企業的發展的時候，他們失望了。大多數的應用缺乏一個統一的介面，難以進行整合。

在我們進行項目開發的銀行中，我們也同樣發現了這個問題，不同部門的系統之間無法進行互聯，跨部門的業務流程必須經過手工的處理。

以前，應用程序的開發都是基於部門的功能的而建的。單純只是為了解決目的而建立應用系統。所以這種方式建立的應用系統是針對特定的功能區域（Function Area）而建立的。至於如何使企業內的多個應用系統共同運作，就不在設計者的考慮之列了。隨著企業的發展，就會發現企業需要變化以適應市場變化，業務發展的時候，原有的一系列應用系統卻成了企業發展的攔路虎，這使得企業不得不回到手工的時代。

針對這種情況，有沒有相應的解決之道呢？解決的方法就是從業務建模入手，而不是從較低層次（部門級或以下）入手。通過用例分析技術，建立企業的業務模型，進行適當的切割，選取穩定的軟體架構，分析出企業的業務實體（Business Entity企業中微小不可分的事物，抽象或具體的，如帳戶，契約等，又被稱為Business Object），以此為基礎，組裝出組件（Component），落實到相應的三層結構，建立針對特定功能區域的應用系統。

以這樣的流程做出來的企業應用系統，不論規模是部門級的，還是企業 級的，都有擴展的餘地。以組件為基礎的軟體三層構架，也能夠較好的配合企業的業務變化而變化（相應變化的代價較小）。而整個流程的第一步，就是業務建模。

在前一段時間，中國很流行企業流程再造BPR(Business Process Re-engineering)這個名詞。BPR這一名詞中的R(Re-engineering)一詞是由Dr. Hammer提出，說明企業必須推動四個層面的重新設計：Re-position、Re-organization、Re-system、Re-vitalizing之再造工程；名稱中的P(Process)，更是管理上由銷售、採購到財務、生產各層次，力求降低成本、提高產出，所必須精密設計的企業管理流程或程序。這個詞都是和ERP串聯在一起，成了ERP的前置工程，更成為保證ERP能建立企業完美管理體系，以支持高績效的最重要因素。實際上呢，這個BPR就是我們所談到的業務建模。

可以看出，業務建模在ERP工程中被著重強調，而且ERP中的BPR已經成為一門獨立的學科。不僅如此，即便是在普通的信息系統中，業務建模也是非常重要的，所不同的，僅僅是它們的規模而已。這一點上，可能大家會不理解，如果你只是為企業的業務自動化建立應用，直接照搬企業模式不就行了嗎。這裡有兩點原因，一是企業原有的業務模式在以人為主的環境中可能運行的很好，可是把這套模式原本不動的搬到計算機上就未必會適合了。人的能力和計算機的能力有很大的出入，所以流程必須經過調整以適應計算機；第二個原因是上面已經提到過的避免產生部門級的，部分功能區域的應用系統。

在RUP中，業務建模被作為下游流程的輸入重點強調：業務模型是需求工作流程的一種重要輸入，用來了解對系統的需求。（RUP）

了解目標組織（將要在其中部署系統的組織）的結構及機制。

了解目標組織中當前存在的問題並確定改進的可能性。

確保客戶、最終用戶和開發人員就目標組織達成共識。

導出支持目標組織所需的系統需求。

為實現這些目標，業務建模工作流程說明了如何擬定新目標組織的前景，並基於該前景來確定該組織在業務用例模型和業務對象模型中的流程、角色以及職責。

作為對這些模型的補充，還開發了以下工件：

補充業務規約

辭彙表

與其他工作流程的關係

業務建模工作流程與其他工作流程的關係如下：

業務模型是需求工作流程的一種重要輸入，用來了解對系統的需求。

實體類。

環境工作流程開發並維護支持工件，例如“業務建模指南”。

根據環境和需求的不同，業務建模工作可能有不同的規模。以下列出了六種這樣的場景。

您可能需要構建組織及其流程的簡圖，以便更好地了解對正在構建的應用程序的需求。在這種情況下，業務建模就成了軟體工程項目中的一部分，它主要是在先啟階段執行的。通常，這些工作在開始時僅僅是畫出組織圖，其目的並不是對組織進行變更。但實際上，構建和部署新的應用程序時往往會進行一定程度的業務改進。

如果您構建應用程序時的主要目的是管理和提供信息（例如，訂單管理系統或銀行系統），那麼您可能選擇在業務級別上構建該信息的模型，而不考慮該業務的工作流程。這就稱為領域建模。請參見工作流程明細：開發領域模型。通常，領域建模是軟體工程項目的一部分，它是在項目的先啟階段和精化階段中執行的。

如果您正在構建一個大的系統（即一系列的應用程序），那麼一個業務建模工作可能成為數個軟體工程項目的輸入。業務模型幫助您找出功能性需求，並且也作為構建應用程序系列構架的輸入。詳情請參見概念：從業務模型到系統。在這種情況下，通常將業務建模工作本身當做一個項目。

如果您正在構建一個供多個組織使用的應用程序（例如，銷售支持應用程序或結賬應用程序）。一種有效的做法是：從頭到尾進行一次業務建模工作，從而按這些組織的經營方式對它們進行調整，避免一些對於系統來說過於複雜的需求（業務改進）。但如果無法對組織進行調整，那麼業務建模工作能夠幫助您了解並管理這些組織使用該應用程序時存在的差別，並使您更容易確定應用程序功能的優先順序。

如果某個組織決定要啟動一項全新的業務（業務創建），並將構建信息系統來支持該業務，那麼就需要進行業務建模工作。在這種情況下，業務建模的目的就不僅僅是要找出對系統的需求，而且還要確定新業務是否可行。在這種情況下，通常將業務建模工作本身當做一個項目。

如果某個組織決定要對其經營方式進行徹底修改（業務重建），那麼業務建模通常本身就是一個或多個項目。通常，業務重建分數個階段完成：新業務展望、對現有業務實施逆向工程、對新業務實施正向工程以及啟動新業務。

項目涉眾的共同願景：要想項目成功，可離不開項目涉眾的支持。在項目一開始，不論是項目涉眾還是開發人員，對項目的任務、範圍都是模糊不清的。但隨著項目的深入，原 來模糊的景象會慢慢清晰、立體起來。但是為了不浪費時間，我們有必要在項目導入之前，先在項目涉眾中豎立一個共同的願景。

共同願景的豎立可沒有想象中的那麼簡單，因為每位涉眾都關心自己的利益，都有自己的評判標準。你可以把大家的意見都列在白板上，然後逐項集中討論，做出修正，直到大家的意見一致的時候為止。在共同遠景的豎立過程中，其實有兩件事情也已經同時做了，項目範圍（scope）和高階（high-level）需求。

項目範圍：項目該做什麼，不該做什麼，需要在一開始就有明確的定義。對於項目範圍內的需求，一個也不要放過，而項目之外的，一個也不要去關心。雖然有的時候，範圍的變化會有利於項目本身，例如客戶的合理要求或是市場目標客戶的變化，但是這種變化應該要在"資源能夠支持"和"得到審批"的前提下進行。

項目範圍的描述可以通過陳述和圖示來進行。我建議大家使用圖示。因為陳述語句比較含糊不清。例如常常聽到有客戶說。"我要建立我公司的電子商務系統。"這句話就是含糊不清的，你的電子商務系統是銷售什麼產品？面向什麼客戶？是否要支持在線支付？根據這些疑問，這個陳述句可以做進一步的修改，"建立在線訂貨系統，針對當前的目標客戶銷售公司的目前產品。"這樣就清楚許多了。不過圖示的方法會更好一些，在圖的選擇上，你可以使用DFD圖或是用例圖。根據經驗，DFD圖比較容易為客戶所接受。

高階需求：這個部分我們在下面會詳細討論。既然是高階需求，就不能討論過多的細節。在討論高階需求的時候，盡量保證快速的討論出系統的概貌，建立需求模型，得到項目涉眾的一致通過。

取得支持：為了保證需求計劃的順利進行，取得項目涉眾的支持至關重要。你可以選擇在這個時候告訴項目涉眾他們的權利和義務，以及開發人員的權利和義務。在這個方面，具體的我不想多說，大家可以參考『軟體需求』的第二章。主要的就是"涉眾有改變需求的權利，同時要承擔向開發人員講解需求的義務。"開發人員的權利和義務正好和涉眾相反。

業務建模會議：所有的這一切都通過業務建模會議進行，和其它會議不同的是，這個會議需要所有的項目涉眾參加，如果不能獲取所有項目涉眾的意見，那就不是完美的。會議中最重要的工具就是白板，一位出色的速記員也是必須的。

業務建模是需求工程中最初始的階段，也是整個項目的初始階段。需要指出的是，業務建模時間的跨度在不同的項目中有很大的差別的。在有些項目中，例如大型ERP系統，可能需要幾個月的時間。而對於普通的項目，業務建模的時間可能僅僅需要幾天的時間。

需求是技術無關（technology independent）的。在需求階段討論技術是沒有任何意義的。那隻會讓你的注意力分散。技術的實現細節是在後面的分析、設計階段才需要考慮的事情。而在業務建模階段，不但要保證需求的技術無關性，還要保證你的需求不要深入細節。因為在業務建模階段，最重要的事情就是要了解業務的全貌，深入細節會浪費時間和精力。要知道，討論一個企業里的業務細節，就算給你一個月的時間也未必能夠結束。

在實際中，這兩點都是很難做到的。例如企業原先有一個系統，這就不得不由你討論和新舊系統的兼容問題。這時候就要注意，如果你是討論就有系統的架構的話，那還是屬於技術無關的範疇，如果你一旦進而討論各具體模塊/組件的細節，那就非但不是技術無關，而且也深入細節了。在不深入細節的問題上，往往你很難禁止項目涉眾（Stakeholder）①不去討論一些相關的業務細節。這個時候你可以將這些細節記錄下來，然後再回到業務建模上。

①A stakeholder is definedasanyone who is materially affected by the outcome of the project.

涉眾是所有會受到項目結果重大影響的人。

摘自《IBM DeveloperWorks》

在上一篇中我們討論了很多用例的知識，可是落實到企業中的時候，我們往往會感覺難以把握企業的用例，這一點我們在用例的誤區中也有提到。在實際的情況中，你可能會對角色的歸類，用例的劃分，力度的把握等很細節的方面都沒有底，偏偏這些實際的東西對你的項目有非常大的影響。

RUP中，有多種的概念來支持用例的實現：業務主角（Business Actor）、業務實體（Business Entity）、業務用例（Business Use Case）、業務角色（Business Worker）、業務用例實例（Business Use-Case Instance）。為了能夠比較清楚的展示出業務建模，我們採用了UP方法的代表――RUP。但在實際中，要視大傢具體的情況而定，這裡所講到的概念，都是為了幫助大家理解建模過程，並不是讓大家生搬硬套。

業務用例以及業務用例實例在RUP中的定義如下：

業務用例實例是在業務中執行的一系列動作，這些動作為業務的個體主角產生具有可見價值的結果。業務用例定義了一組業務用例實例。業務用例具有名稱。

剛開始大家可能會對業務用例以及業務用例實例有所疑問。其實可以把他們看成基類和子類的關係。在一個企業中，具體的工作流程可能有很多很多，比如你去麥當勞的時候，點漢堡和點薯條的工作流程就不一樣。眾多的流程給需求的調查工作造成了一定的難度。即使是最古老的哲學也告訴我們，表面現象是複雜的，本質是簡單的。為了簡化需求工作，我們就把點漢堡和點薯條歸納為點餐。這樣，點餐就是一個業務用例，而點漢堡、點薯條就是相對應的業務用例實例。

業務角色和業務主角的概念也很容易讓人摸不著頭腦。其實看它們的英文願意會更容易理解它們的區別：Business Worker，Business Actor。Worker有工人的意思，而Actor有參與者的意思。所以它們的區別就是一個在內部，一個在外部。業務角色是實現業務用例的人，業務主角是和業務有關的人。例如，對銀行的押匯業務而言，客戶就是業務主角，他和業務有關。而押匯人員就是業務角色，因為他們是實現業務用例的人。在RUP中，二者定義如下：

業務角色代表業務中的一個或一組角色。參與業務用例實現時，一個業務角色和其他角色進行交互，並操縱業務實體

業務主角代表了與業務有關的角色，此角色由業務環境中的某個人或物來擔任。

分辨業務角色和業務主角要看環境而定。當你開發企業的ERP系統時，部門的員工都屬於業務角色，而你開發一個部門級的應用時，其他部門的員工可能屬於業務主角。

業務實體，在一些文章中被稱為商業對象（BusinessObject）。不論怎麼叫，所表示的意義都是一樣的。例如在銀行信貸這個例子中，我們就涉及到很多業務實體：契約、單筆貸款、客戶等。所以業務實體就是企業中那些很基本的要素。如果覺得銀行押匯的例子不好理解。可以想象餐廳中的菜單、漢堡等都是業務實體。在RUP中，業務實體被定義為：

業務實體代表業務角色處理或使用的"事物"。

在很早以前，我們討論過需求易變性。相對於需求的不斷變化，可是業務實體對象在一段相當長的時間內都存在。航空公司今天打折，明天又不打，還有明折、暗折。可是機票從來沒見有什麼大的變化，從來也只有那幾樣屬性：價格、航班、出發地、目的地。所以業務實體是比較穩定的。這對於我們是有很大的意義的：

"一個業務實體經常代表某個對多個業務用例或用例實例有價值的事物，因此，業務實體對象的生存期相當長。一般而言，一個好的業務實體不包含關於其使用主體和使用方法的信息。"（RUP）

由業務實體組成的業務用例會穩定很多。在以前，開發方式採用模塊為基礎的方法，需求變化的時候，只好改寫模塊。如果採用穩定的業務實體來實現業務用例的話，業務用例的改變只需要對業務實體進行重新的組合。當然，這裡還需要很多的技術來實現，並沒有那麼簡單。要知道，四個現代化可不是一天就能夠實現的。

還有一個使用業務實體的重要原因：業務實體的特性決定它具有天生的重用性。就像麥當勞的銷售系統中有漢堡實體，生產系統中也有，供應鏈系統中也有。天哪，這世界真是美好！

使用業務實體一個很大的困惑是應該把它做為類還是屬性。這個取決於業務環境對這個實體的重視程度。一個客戶在銀行信貸部門是一個很重要的類，而在押匯部門就只是信用證實例的一個屬性。這個問題非常的重要。設計時的失誤可能會導致今後系統改進的極大痛苦。例如本該設計為類的業務實體設計成了屬性，在今後增加屬性的時候不得不面對著資料庫的調整和系統的修改。

業務用例模型（business use-case model），在RUP中定義為：

業務用例模型是說明業務預期功能的模型。作為一個核心輸入模型，業務用例模型用於確定組織的各個角色和可交付工件。

從業務用例模型的定義可以看出，它是企業最核心，最概括的業務說明。它主要是由業務用例和業務主角構成的，其主要目的是說明客戶和合作夥伴是如何開展業務的，它描述業務的主要方式是通過業務用例的方式。下圖為RUP中業務用例模型的圖示。

從圖中我們也可以很清楚的看出業務用例模型包括一組的業務用例。這是因為企業中的業務通常都會由多個的業務用例的多個實例構成。這些業務用例形成的企業工作流程可能會由業務主角所引發，也可能會由業務規則②所引發。

②業務規則（Business Rules）：業務規則是必須遵守的政策或條件的聲明。

業務用例模型實際上就是企業經營業務的一種描述，為了建立完整、準確的企業用例模型，應該將注意力專註於企業的業務做了些什麼事情，而不應該集中於如何做。雖然這樣可能會產生一些業務用例相衝突，相重複的情況，但是RUP的思想在於迭代，這項工作完全可以在接下去的迭代周期內完善。

業務用例模型是和企業業務最貼近的計算機模型。它的很多思想和企業日常經營如出一轍。在企業的日常活動中，業務的種類可能有很多種。在一些講述ERP思想的文章中，通常會強調三類：

一種是和主營業務密切相關的工作，例如銀行的營業部、信貸部、押匯部等。這種工作通過人的勞動，將一種資源轉變為另一種資源，產生價值。

一種是管理型的工作，例如公司的管理層，財務部門等。這種工作本身並不產生價值，但是它通過指導、管理、檢測第一種工作，加大第一種工作的產出價值。

還有一種稱為支持工作，例如系統管理、安全等。它並不是很重要，具有支持其他工作的性質。

業務模型同樣可以使用這種分類。通過這種分類，可以更好的把握核心業務用例，為下一步的工作打好基礎。

有很多業務用例是由業務主角觸發的，RUP中也把和業務主角有關聯關係的業務用例稱為核心業務用例（Core Business Use Case）。這強調了構建業務模型的目的是為了提供以用戶為中心的服務。這也是我們建立業務用例的時候應該注意的。

當然，有時候業務用例的觸發是為了產生用戶需要的結果。例如企業的市場調查行為就不是由業務主角觸發，而是企業積累了大量用戶請求的結果。而對於管理型、支持型的，不直接和業務主角的客戶類發生聯繫，但是也有其特定的業務主角，如管理型的業務用例需要和董事會為發生聯繫，支持型的業務用例可能和供應商發生聯繫。

在建立了基本的業務用例模型之後，對此模型進行精化是非常有必要的，這時候，在上一章中我們介紹的用例的擴展關係和使用關係就有了用武之地。除了這兩種關係，還有一種新的關係。

業務建模中使用關係

泛化關係（Generalization）：根據我的理解，可以把它看作我們比較熟悉的繼承關係很相似的一種關係。Generalization一詞含有一般化、概括的意思。它是一個相對抽象的詞。雖然它和繼承關係非常相似，但是它們在使用環境和產生目的方面都有相異之處。下圖描述了四個業務實體之間的泛化關係：當你去麥當勞的時候（不要誤會，我並不是很經常去的），會選擇麥香雞漢堡、麥香魚漢堡或是吉士漢堡。但是分別對這三種漢堡建立業務實體就非常沒有意義。所以可以將它們概括為漢堡這個業務實體。同樣的道理，企業的業務流程中也可以概括出一些共有的屬性和行為。為了避免多次說明同一個工作流程，您可以將共有的行為放在一個單獨的業務用例中。稱為父用例，執行子用例的用例實例將遵循父用例的事件流，同時插入附加行為或修改在子用例事件流中定義的行為。

方法的選擇

以上的原理我採用了UP的方法。但是除了UP方法，還有XP、FDD等方法。所以在做業務建模的時候，也要根據不同的方法選擇適當的工件。例如素材和功能。方法的好壞並不是我們這片文章討論的重點，我會在另一篇文章中討論方法。再一次需要強調的是，上面討論的RUP的工件只是為了學習，所以才定義了比較複雜的工件，區分了它們之間的區別。但是在實際中，並不需要這麼多的工件，那隻會使你的項目涉眾和開發人員糊塗。這些工件的區別只要在你心中就可以了。

我們說客戶是上帝，是因為客戶的重要性，客戶佔有決定性的地位。可是在軟體開發中，到底是誰有決定權呢？是出資方，還是項目經理，或是程序員？職責不清，是業務建模失敗的主要原因之一。我們可以很容易的看見客戶把自己的要求用幾句話高度濃縮之後扔給開發人員，或是開發人員按照自己的意思開發程序。難道說，客戶和開發人員之間真的是"心有靈犀"，完全不用溝通的嗎。我在前文中已經提到過項目涉眾和開發人員的權利和義務，我想這裡還有必要再次強調。Scott W. Ambler說： it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them. 在我一次開發過程中，遇到過一個很有意思的涉眾，他在他的需求分析中這樣寫："總之，要實現那種能夠想到就能做到功能。"我想，這位涉眾對我們的計算機工業有著非常遠大的抱負。但我不得不客氣的告訴他實現是不太現實的。大家聽了可能會覺得好笑，但是在我自己和客戶打交道的生涯中，這種客戶不在少數。現實就是這樣，你要怎麼做？是一笑之後，棄之不顧嗎？我想大多數人會這樣做。因為他的要求太荒唐了嘛。可是，你有沒有花時間去了解一下，他這句荒唐的話背後代表了他的什麼意思呢？我覺得，軟體開發人員負有教育涉眾的義務，你需要引導你的涉眾，讓他們說出自己的心聲。我在看到這位涉眾的這句話后，就花了一些時間去了解，其實呢，事情很簡單，他就是想要一個能夠定製報表模板的功能。而在項目結束后，我和這位涉眾有幸再一次的合作，這時候，他已經成為了一個出色的客戶方的項目領導者了。這個例子說明了什麼呢？涉眾往往都是領域專家，對自己的工作有很深的認識，可是由於對軟體開發的不了解，涉眾往往表達不清，甚至表達不出自己的需求。這時候，就是體現你的功力的時候了。記住，象對待上帝一樣對待你的客戶。

明白了誰是“上帝”，那就要耐心的對待上帝。學理工科的人，一般在邏輯思維上會比較好，可是對於涉眾來說，可不一定是這樣。我就遇到過一位做檔案工作的涉眾，在了解需求的時候，扯東扯西，含糊不清。明明一分鐘前才否定的方法，下一分鐘又提出來了。我覺得我的脾氣應該是不錯的，可到最後也幾乎發飈。所幸，最後我終於撐了下來。我想，在經歷過這件事情之後，我的耐心指數又會有一個很大的提高了吧。

我有一位同事的耐性是我所佩服的，在一個網站項目中，他負責系統分析。他整整花了三天的時間，和網站項目的負責人住在一起。最後系統分析出來之後，他的精神還不錯，可是那位負責人已經快不行了。當然，這只是個笑話，並不是去鼓勵大家拚命。勞逸結合還是很重要的，身體是革命的本錢嘛。但是這告訴我們，如果缺少耐心，需求是很難成功的。例如在業務建模的討論會上，你雖然規定了這次的會議討論的是高階需求，可是與會者總會時不時的爭辯一些芝麻綠豆的小事兒。你怎麼辦？我相信這種情況是很普遍的。

耐心最後會仍會體現為溝通，只有耐心的溝通，你才能揭開需求的重重面紗。人的行為總是會受到思想的指導，如果你解不開涉眾的心結，你就不可能了解他真正需要的。

我的一位項目涉眾的表現很奇怪，她總是在不停的說一件事情："她要實現報表自動生成。"她的需求講來講去好像總脫不出這個範圍，可是我從她那裡幾乎聽不到別的東西了。這時候，我決定放棄了，我想從她哪裡可能已經沒有更多的資料了。但在我了解到她的工作中報表處理佔用了她大量的時間之後，我改變了想法。在我花了一些時間幫她理清了報表處理的思路之後，她還在其他方面給了我很大的幫助。

XP方法的一個重要實踐，就是提倡“現場客戶”（on-site customer）。也就是說，客戶應該隨時和開發人員在一起，隨時提供資料和做出決策。而這個客戶，也必須領域專家，而且能夠有權做出決策。

這種現場客戶相信國內的軟體組織多半還做不到。但是一定要往這方面努力。我認為，這種現場客戶有兩種人：一種是項目涉眾，還有一種是行業專家。其實很多軟體公司都會配備一些管理諮詢人員，這些人就是行業專家。有數據統計說，廣東省軟體公司中的諮詢人員和開發人員的比例達到了3：1。我覺得這是好事。項目涉眾往往對自己的工作中的事務性部分有很深的認識，但是很難將之提升到一個理論的水平。這時候就需要一些行業專家來幫助了。讓行業專家和項目涉

眾共同探討，還能夠激發項目涉眾的靈感，想到原來他想不到的方面。這就是“潛在需求”的開發。另一方面，參與還意味著需要項目涉眾全身心的投入到業務建模的過程中來，要能夠調動他們的積極性。因此呢，太複雜的流程會阻礙涉眾的參與。所以，使用一些簡單的、能夠為客戶所接受的工件（Artifact）來進行業務建模是很有必要的。我說過前面討論的那些“主角”啊“用例”啊，那是理論，是給開發人員看的，讓開發人員心裡有個底。你給涉眾看這些，他們能懂嗎？等他們了解了這套機制，恐怕黃花菜都涼了吧。素材（User Story）、特性（Feature）、CRC卡片這些都是很不錯的工件，既簡單，又能夠滿足需要。知識點：素材和特性都表述了用戶的一個簡單的要求，它能夠在較短的時間內完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的縮寫，它是一張分為三個部分的卡片，分別標記了類名，類的責任，以及類之間的合作關係。非常的貼近客戶，甚至可以在做遊戲的過程中完成卡片的填寫，能帶來很強的客戶參與度。

我想這一點會遭到開發人員點一致指責。畢竟，需求變化是開發人員最討厭的一件事了。不錯，我也討厭。可是，就像我們常說“哭不能解決問題”一樣，討厭能解決問題嗎？拒絕客戶的變更要求，要求客戶在需求規格說明書上簽字。這些做法只能是適得其反。沒有任何正面的、積極的意義。

必要的需求變更管理是重要的。因為無休止、無控制的變化必然會造成資源的極大浪費。但從另一方面說，需求變更被接受的評判標準應該是“是否合理”，而需求變更要求我們的開發工作要迭代式進行，包括需求、設計、實現等階段。這樣才能將變更風險減到最小。這一點我們在討論具體需求建模的時候會進一步討論。

擁抱變化的更高一個層次是提前預估變化。制定一個可能的變化清單來記錄可能出現的變化。最簡單的例子就是一個企業在開發了進銷存系統之後又希望能夠開發財會系統與之相連。如果你能夠預先留下伏筆，相信能夠省不少力氣。預估變化的另一種做法是通過使用模式。但是切記，模式的使用也不能過頭。這些是題外話，如果有機會我會在其他的文章中集中討論這方面的問題。七、業務建模的實踐（Practice）

會議是業務建模最重要的手段。儘管會議在中國總是背負著一些罵名，但是只要組織得好，它是一種相當有效的溝通（Communication）手段。建模會議是一種大範圍的會議，換句話說，所有的相關人員都應該參加會議。因為在業務建模時期，主要的目的就是建立對系統的高階需求，這就要求眾多項目涉眾的共同參與，以保證需求的廣泛性。所以呢，建模會議的規模是相當大的。出資方、高級經理、經理、直接用戶、開發人員，各方各面的人都應該參加或是派代表參加建模會議。

如果大家有過參加大型會議的經驗都知道，越是大型的會議，它的決策效率就越低。這是正常的。因為一個人的時候，不需要溝通，決策效率最高。等到兩個人的時候，他們需要溝通的時間來進行決策。等到三個人的時候，這個溝通並達成一致的時間就更長。如果人數到了四個人、五個人甚至一二十個人，那麼大部分的時間都會花在溝通上。更何況，人和人之間還有觀念不同、利益之爭。所以呢，為了保證會議的效率和效果，應該遵循一定的規則：

·做好準備：如果你要開會，與會者連內容都不清楚，那你會怎麼辦。你必須首先花很多的時間來說明你開會的目的，是不是。要事先將會議的主題、議程連同會議通知發送給與會者，讓他們先有個準備，會議開始時就能夠迅速進入正題。

·盡量邀請最多的人：我已經說過，如果建模會議不能夠聽取最廣泛的意見，它就不是一個成功的會議。可是在現實中，這點往往難以做到。因為目標組織做為客戶，往往都很"拽"，在沒有充分認識會議的重要性之前，要做到全部到場簡直就是不可能。而客觀上也會有出差、休假、有要事等原因做不到這一點。這裡，一方面你需要向目標組織的決策者闡明利害，讓他們重視。另一方面，你也需要積極主動的邀請項目涉眾參與。因為邀請所有的人是不可能的，所以就儘可能的多吧。

·分出與會者的級別：我很喜歡那種有一個內圈、一個外圈的會議室。因為我邀請所有人是件無法做到的事情，所以我首先要保證核心人員能夠全部到場，坐在內圈，然後才是次要的人員，坐在外圈。核心人員是和你的項目息息相關的那種人。比如，財務系統，財務主管就是核心人員。要保證核心人員全員到場，至於次要人員，越全越好。

·從底層開始：中國人有個比較不好的習慣，就是老闆說一的時候，他決不會說二。所以要先讓底層先說話，然後才輪到中層，再到上層。開發人員是不說話的，他們要麼聽，要麼引導大家說話。如果我們一開始就先讓領導來訓話一番，那底層的人也就不用再說什麼了。

·列舉所有涉眾的所有觀點：首先要讓大家能夠對新的系統暢所欲言，然後把所有的觀點都羅列在白板上。這裡頭可能會有一些觀點會是非常荒唐的，但沒有關係，儘管寫上去。這是一個腦力激蕩的過程，很容易產生出新的idea。主持的開發人員的主要工作就是引導和鼓勵大家說出更多的想法，並記錄下來。這裡我們稍微離題一下，有人說中國人在會議上大都不願意發表意見，我看在這種建模會議上不必過於擔心此事。為什麼呢，因為項目涉眾不需要為他們的發言擔任何的責任，說了，白說，白說誰不說。

·將觀點分類：想必你的項目涉眾已經有些累了，創意也差不多了，你的白板估計也滿了。但是你看看白板上的觀點，有很多是重複的，有很多是類似的。所以你需要用邏輯的觀念將這些觀點歸類整理。這個工作也可以由你引導大家去做。

·確定優先順序：對觀點排出優先順序也是非常重要的，它能夠幫助你識別出重大的風險，並為你在制定迭代計劃時提供指導。同樣，這項工作也應該由項目涉眾來確定。

·調查主要業務邏輯：什麼叫主要業務邏輯？包括了企業的主要業務流程、主要的業務規則、重大的演演算法。這些都是需要在一開始就十分明確的資料，需要在建模會議上了解清楚。當然，你不能對你的項目涉眾說，"這個，接下來，大家談一談主要的業務邏輯吧。"下面的涉眾一定摸不著頭腦。你還是應該引導涉眾，從涉眾的話語中捕捉你需要的信息。

·注意會議時間：人不是機器，是會累的。所以控制好會議的長度很關鍵。一般，這種會議會有四五個小時，根據統計，兩個小時內的會議不會讓人產生疲勞感。所以應該把會議分成幾小段。另外，你還可以根據會議的進展來決定每小段會議參與的人數。因為，會議越往後，一些與會者就不太重要了。

·避免細節：建模會議主要的目標是建立高階需求。如果把過多的時間花在討論雞毛蒜皮的小事，那就會浪費大家的時間。而在此時調查需求細節是沒有很大的意義的。因為你對很多的事情都還不了解，需要進一步的深入。這時候的細節對你並沒有太多的幫助。

·迴避技術：我在一次建模會議的時候，遇到一位負責技術的涉眾，他總是不停的詢問系統的技術架構，推銷他的設計理念。使得我不得不好幾次重申，"技術問題我們會單獨找時間談。"我想，那位技術人員應該是有比較好的理念，也很希望能夠表現一把，這點無可厚非。但是這個時候還不是討論技術的時候，需求尚未明確，討論技術實現不是本末倒置么？

·做好記錄：俗話說，好記性不如爛筆頭。所以在會議上做好記錄是非常關鍵的。因為這種會議的代價相當高昂，你的項目涉眾不可能每天不幹活，陪你開會的，就算他們肯，他們的老闆也不肯。所以要充分利用好會議的成果，所以一個優秀的速記員絕對是必要的。另外，根據研究顯示，如果使用錄音機的話，會使得與會者心存芥蒂而不願開口，所以，不要使用錄音機。

在需求的初始階段提到測試可能會覺得有些奇怪。凡是項目，總會有一個標準來考核是否成功。這裡的測試指的是考核軟體項目是否成功的一個"執行性目標"。

這個目標將會是軟體開發最終要滿足的條件，軟體成功與否的判定標準。很多企業在信息化建設的時候沒有一個比較明確的目標。所以在被問道這方面的問題時，他的答案往往是我的目標是建成企業的ERP系統，建設企業的信息化平台等空洞的話。這樣的軟體怎麼開發？連結束的標準都沒有。是費用用完結束呢，還是決策者說停就停了呢。目標應該有一個可以量化的標準。例如，開發物流系統的目的是為了縮短產品周轉周期，降低庫存；開發供應鏈系統是為了加強和供應商的聯繫，降低庫存。這些和具體業務有關的指標都是可以通過細化，用多種分指標來度量的，所以是可以做到的。

我們把這種目標稱為測試就是要提醒開發人員，要把滿足這種目標當作最終的測試。你的軟體做得再好，不是涉眾想要的，又有什麼用？這是很淺顯的道理，可是在實際中，涉眾方和開發方往往因為一些具體的因素看不到這一點。其實，這個目標在上一篇中我們也講過，那時我們是把它叫做願景、範圍。在本質上是一樣的。這種“可執行性目標”可以使用一些因素來衡量：

業務實體（business entity）是企業中的一些起到關鍵作用的類別。客戶、供應商、員工、訂單、憑證，這種業務實體的例子可以舉出很多很多。業務實體往往會成為一個很關鍵的因素，因為在系統中，角色操作業務實體的行為往往會分配給業務實體，例如“根據訂單計算價格”會成多個業務實體相互合作完成的。所以業務實體設計的好壞會對系統有很大的影響作用。

業務實體設計的主要工作包括找出業務實體，確定業務實體的屬性和行為。

要確定業務實體，首先必須確定角色，並從角色的行為找出業務實體。角色需要我們對目標組織進行討論。以我個人的經驗，尋找業務角色一般比較簡單，但是要記住，一個人可能擔任好幾個的業務角色，這是經常發生的情況。從業務角色的行為，我們可以找出業務角色所處理的事物，這些就是我們所需要的業務實體。業務實體是一個單獨的業務實體還是業務實體的一個屬性是值得研究的。一個本該是屬性的事物被判斷成業務實體只是會帶來一些開銷，可是一個本該單獨列出的業務實體卻只是被判定為其它業務實體的一個屬性就有可能會帶來災難性的後果，最大的可能是系統難以擴展。

在一個人力資源管理系統中，員工類可能是非常重要的一個業務實體，它可能有非常多的屬性。而在其它的系統中，例如進銷存，員工類只是起到一個記錄、許可權管理的作用罷了。再比如，在一些企業內部的自動化處理系統中，客戶可能只是其它一些實體的屬性，而以客戶為中心的設計大行其道的21世紀，這種設計就有它的致命缺陷。要確定業務實體的屬性和行為，主要是要確定每個類（業務實體）要做的事情，屬性則是為了能夠更好的描述類和類要做的事情。利用CRC卡片是一個不錯的辦法。 CRC是“類”（class），“責任”（responsibility）及“輔助者”（collaborator）三者的簡稱，這些資料常呈現在一張卡片上。類名稱 責任1 責任1的輔助者1 責任2 責任2的輔助者2 … … 通過製作這樣的CRC卡片，可以比較容易的找出每個業務實體的行為（責任）和屬性（輔助者）。您可能會問，為什麼不直接找出屬性和行為，而要多此一舉呢。這個問題是我們一直在強調的。在建模階段，我們面對的是可能對計算機技術完全不懂的涉眾，所以，採用大家易於接受的方法，可以夠保證需求的完整和正確。

在軟體開發中，關於計劃有兩個極端的誤解。在有些軟體組織中，一般不做計劃，或是做一些籠統的、沒什麼用處的計劃。一些開發人員認為，"做計劃是虛的，還不如做些實際的事。"對於項目經理，或是對這種情況沒有辦法，或是發布的計劃開發人員陽奉陰違，讓計劃成為一紙空文。項目執行中隨意性極大，偏離方向的事情時有發生。

而在另外一些組織中，計劃被視為重中之重，需要花費大量的時間、人力，做出來的計劃可謂事無巨細，算無遺策。而寫的出這種計劃的項目經理也被視為高級人才。開發人員嘆口氣說，“寫程序的不如寫文檔的”。可是在執行的時候，原來精密的計劃往往漏洞百出，項目的進度一拖再拖。我們所有人都知道那句明言：在軟體開發中，要花90%的時間完成90%的項目，然後再用90%的時間完成剩下的10%的項目。為什麼呢？計劃不科學。

在管理學中，計劃，也有叫規劃的，定義是“為組織確定目標、實現目標的戰略與手段、步驟、程序的過程”。打個比方說，我想要把一個箱子推倒一個地方，這個地方就是我的目的，我為了到達那裡，我是不是要估計一下按什麼路線推，要推多快。然後我就開始推，還要不時的和原先的計劃比較比較，需不需要調整路線和速度。這個估計就是計劃。

計劃的目標不是消除錯誤，而是讓所有錯誤變成一堆經過細心規劃后的小錯誤。研究四種設計方式后，最終放棄三種，最多不過是三個小錯誤而已，但因沒有做好設計而將程序重寫三遍，卻可能造成三個大錯誤。

然而為什麼會出現上面提到的兩個極端呢？第一種情況其實是軟體行業最早期的一種形態，沒有計劃，資源分配混亂，軟體的開發過程處於混沌、無序、自發的狀態。項目的成功全憑運氣和項目成員的個人能力。而第二種情況其實一個前進了的形態，最典型的代表就是我們之前提到過的瀑布模型。那這種考慮周密的計劃為什麼也容易失敗呢？很簡單，你認為你考慮周密，可是實際上卻不一定。我就見過標榜自己考慮周詳的計劃中排出的時間表是一周7天的。看來他一開始就沒打算讓開發人員休息了。計劃是對未來的一種估計，哪一個人能夠準確的說出6個月後的情況，恐怕沒人能行吧。9月11號之前，有幾個人能料到那天會發生這麼大的事情？那你憑什麼推算出半年，甚至一年後的事情呢？另外，你是不是真的非常了解你的開發人員，以至於有信心代替他們制定計劃呢？

有人說，計劃沒有變化快。這句話說得很對，它提醒我們，沒有計劃是不行的，不具備可執行性的計劃也是不行的。計劃不是拿來炫耀的，是要用來執行的。我們定計劃的時候，可以沒有華麗的詞藻，美好的構想。但是我們不能沒有一些要素：

·什麼(WHAT)：按順序列出達到目標所需完成的工作；

·何時(WHEN)：完成工作所需要的時間；

·做到的程度(HOW-WELL)：要完成的工作以何標準來度量；

·資源(RESOURCES)：完成工作需要的人員/資金等；

·誰(WHO)：由誰負責完成任務。

但是我們仍然逃不開現實和計劃的背離的問題。我們雖然對預計一年後的事情把握不大，對把握開發人員在想什麼把握也不大。但是如果你自己想想自己兩個星期後的事情應該還是能夠猜的八九不離十吧。這就引出了迭代的概念。一個項目由幾個甚至幾十個的迭代周期組成，每個迭代周期都是比較容易估算並制定計劃的。這就是迭代的思想，也是軟體工程技術的一個大飛躍。

我很難想象一個項目沒有培訓該如何進行。兵書有雲，“三軍未動，糧草先行。”我們可以理解為事先做好充分的準備。項目也是一樣，在一開始就要指定好培訓的計劃，留出培訓的時間。我想，除非是一個非常完美的團隊，否則他的成員一定也還是有不懂的東西吧，如果沒有培訓計劃，把學習的任務推倒個人頭上，項目的風險就會變得難以控制。說起培訓，大家可能就會認為是大家正兒八經的坐在那裡，聽一位老師上課。並不是這樣的，這裡說的培訓是一個廣義範圍的培訓，達到一組課程、一次會議，小到一次討論、一次交流，都可以是培訓。而其目的，就是為了讓團隊成員擁有足夠的知識和技能，來完成項目。