????? 業(yè)務(wù)建模（Business Modeling）是一種建模方法的集合，目的是對(duì)業(yè)務(wù)進(jìn)行建模。這方面的工作可能包括了對(duì)業(yè)務(wù)流程建模，對(duì)業(yè)務(wù)組織建模，改進(jìn)業(yè)務(wù)流程，領(lǐng)域建模等方面。
一、為什么要業(yè)務(wù)建模
????? Brooks 大師說，三十多年來各式各樣的應(yīng)用系統(tǒng)（Application Programs AP）歷經(jīng)多次的修修改改，已經(jīng)變得面目全非，如同一群的怪獸，難以馴服。
????? Rogerson大師也說，The application is a rock in the river of change.（應(yīng)用（系統(tǒng)）成為改變之潮流中的頑石）。
????? 對(duì)很多企業(yè)而言，有一個(gè)統(tǒng)合企業(yè)各部門的信息系統(tǒng)的心愿似乎已經(jīng)成了一種奢望。企業(yè)中或多或少都會(huì)有一些應(yīng)用系統(tǒng)在輔助企業(yè)的自動(dòng)化運(yùn)作，當(dāng)企業(yè)信息主管希望能夠?qū)δ壳暗男畔⑾到y(tǒng)進(jìn)行整合，能夠配合企業(yè)的發(fā)展的時(shí)候，他們失望了。大多數(shù)的應(yīng)用缺乏一個(gè)統(tǒng)一的接口，難以進(jìn)行整合。
????? 在我們進(jìn)行項(xiàng)目開發(fā)的銀行中，我們也同樣發(fā)現(xiàn)了這個(gè)問題，不同部門的系統(tǒng)之間無法進(jìn)行互聯(lián)，跨部門的業(yè)務(wù)流程必須經(jīng)過手工的處理。
????? 以前，應(yīng)用程序的開發(fā)都是基于部門的功能的而建的。單純只是為了解決目的而建立應(yīng)用系統(tǒng)。所以這種方式建立的應(yīng)用系統(tǒng)是針對(duì)特定的功能區(qū)域（Function Area）而建立的。至于如何使企業(yè)內(nèi)的多個(gè)應(yīng)用系統(tǒng)共同運(yùn)作，就不在設(shè)計(jì)者的考慮之列了。隨著企業(yè)的發(fā)展，就會(huì)發(fā)現(xiàn)企業(yè)需要變化以適應(yīng)市場(chǎng)變化，業(yè)務(wù)發(fā)展的時(shí)候，原有的一系列應(yīng)用系統(tǒng)卻成了企業(yè)發(fā)展的攔路虎，這使得企業(yè)不得不回到手工的時(shí)代。
????? 針對(duì)這種情況，有沒有相應(yīng)的解決之道呢？解決的方法就是從業(yè)務(wù)建模入手，而不是從較低層次（部門級(jí)或以下）入手。通過用例分析技術(shù)，建立企業(yè)的業(yè)務(wù)模型，進(jìn)行適當(dāng)?shù)那懈睿x取穩(wěn)定的軟件架構(gòu)，分析出企業(yè)的業(yè)務(wù)實(shí)體（Business Entity 企業(yè)中微小不可分的事物，抽象或具體的，如帳戶，契約等，又被稱為Business Object），以此為基礎(chǔ)，組裝出組件（Component），落實(shí)到相應(yīng)的三層結(jié)構(gòu)，建立針對(duì)特定功能區(qū)域的應(yīng)用系統(tǒng)。
????? 以這樣的流程做出來的企業(yè)應(yīng)用系統(tǒng)，不論規(guī)模是部門級(jí)的，還是企業(yè)級(jí)的，都有擴(kuò)展的余地。以組件為基礎(chǔ)的軟件三層構(gòu)架，也能夠較好的配合企業(yè)的業(yè)務(wù)變化而變化（相應(yīng)變化的代價(jià)較小）。而整個(gè)流程的第一步，就是業(yè)務(wù)建模。
????? 在前一段時(shí)間，中國很流行企業(yè)流程再造BPR(Business Process Re-engineering)這個(gè)名詞。BPR這一名詞中的R(Re-engineering)一詞是由Dr. Hammer提出，說明企業(yè)必須推動(dòng)四個(gè)層面的重新設(shè)計(jì)：Re-position、Re-organization、Re-system、Re-vitalizing之再造工程；名稱中的P(Process)，更是管理上由銷售、采購到財(cái)務(wù)、生產(chǎn)各層次，力求降低成本、提高產(chǎn)出，所必須精密設(shè)計(jì)的企業(yè)管理流程或程序。這個(gè)詞目前都是和ERP串聯(lián)在一起，成了ERP的前置工程，更成為保證ERP能建立企業(yè)完美管理體系，以支持高績效的最重要因素。實(shí)際上呢，這個(gè)BPR就是我們所談到的業(yè)務(wù)建模。
????? 可以看出，業(yè)務(wù)建模在ERP工程中被著重強(qiáng)調(diào)，而且ERP中的BPR已經(jīng)成為一門獨(dú)立的學(xué)科。不僅如此，即便是在普通的信息系統(tǒng)中，業(yè)務(wù)建模也是非常重要的，所不同的，僅僅是它們的規(guī)模而已。這一點(diǎn)上，可能大家會(huì)不理解，如果你只是為企業(yè)的業(yè)務(wù)自動(dòng)化建立應(yīng)用，直接照搬企業(yè)模式不就行了嗎。這里有兩點(diǎn)原因，一是企業(yè)原有的業(yè)務(wù)模式在以人為主的環(huán)境中可能運(yùn)行的很好，可是把這套模式原本不動(dòng)的搬到計(jì)算機(jī)上就未必會(huì)適合了。人的能力和計(jì)算機(jī)的能力有很大的出入，所以流程必須經(jīng)過調(diào)整以適應(yīng)計(jì)算機(jī)；第二個(gè)原因是上面已經(jīng)提到過的避免產(chǎn)生部門級(jí)的，部分功能區(qū)域的應(yīng)用系統(tǒng)。
????? 在RUP中，業(yè)務(wù)建模被作為下游流程的輸入重點(diǎn)強(qiáng)調(diào)：業(yè)務(wù)模型是需求工作流程的一種重要輸入，用來了解對(duì)系統(tǒng)的需求。業(yè)務(wù)實(shí)體是分析設(shè)計(jì)工作流程的一種輸入，用來確定設(shè)計(jì)模型中的實(shí)體類。（RUP）
二、業(yè)務(wù)建模的目的
????? 了解目標(biāo)組織（將要在其中部署系統(tǒng)的組織）的結(jié)構(gòu)及機(jī)制。
????? 了解目標(biāo)組織中當(dāng)前存在的問題并確定改進(jìn)的可能性。?
????? 確保客戶、最終用戶和開發(fā)人員就目標(biāo)組織達(dá)成共識(shí)。
????? 導(dǎo)出支持目標(biāo)組織所需的系統(tǒng)需求。
????? 為實(shí)現(xiàn)這些目標(biāo)，業(yè)務(wù)建模工作流程說明了如何擬定新目標(biāo)組織的前景，并基于該前景來確定該組織在業(yè)務(wù)用例模型和業(yè)務(wù)對(duì)象模型中的流程、角色以及職責(zé)。
????? 作為對(duì)這些模型的補(bǔ)充，還開發(fā)了以下工件：
????? 補(bǔ)充業(yè)務(wù)規(guī)約
????? 詞匯表
????? 與其他工作流程的關(guān)系
????? 業(yè)務(wù)建模工作流程與其他工作流程的關(guān)系如下：
????? 業(yè)務(wù)模型是需求工作流程的一種重要輸入，用來了解對(duì)系統(tǒng)的需求。
????? 業(yè)務(wù)實(shí)體是分析設(shè)計(jì)工作流程的一種輸入，用來確定設(shè)計(jì)模型中的實(shí)體類。
????? 環(huán)境工作流程開發(fā)并維護(hù)支持工件，例如“業(yè)務(wù)建模指南”。
三、業(yè)務(wù)建模的規(guī)模
????? 根據(jù)環(huán)境和需求的不同，業(yè)務(wù)建模工作可能有不同的規(guī)模。以下列出了六種這樣的場(chǎng)景。
????? 場(chǎng)景 #1 - 組織圖
????? 您可能需要構(gòu)建組織及其流程的簡圖，以便更好地了解對(duì)正在構(gòu)建的應(yīng)用程序的需求。在這種情況下，業(yè)務(wù)建模就成了軟件工程項(xiàng)目中的一部分，它主要是在先啟階段執(zhí)行的。通常，這些工作在開始時(shí)僅僅是畫出組織圖，其目的并不是對(duì)組織進(jìn)行變更。但實(shí)際上，構(gòu)建和部署新的應(yīng)用程序時(shí)往往會(huì)進(jìn)行一定程度的業(yè)務(wù)改進(jìn)。
????? 場(chǎng)景 #2 - 領(lǐng)域建模
????? 如果您構(gòu)建應(yīng)用程序時(shí)的主要目的是管理和提供信息（例如，訂單管理系統(tǒng)或銀行系統(tǒng)），那么您可能選擇在業(yè)務(wù)級(jí)別上構(gòu)建該信息的模型，而不考慮該業(yè)務(wù)的工作流程。這就稱為領(lǐng)域建模。請(qǐng)參見工作流程明細(xì)：開發(fā)領(lǐng)域模型。通常，領(lǐng)域建模是軟件工程項(xiàng)目的一部分，它是在項(xiàng)目的先啟階段和精化階段中執(zhí)行的。
????? 場(chǎng)景 #3 - 單業(yè)務(wù)多系統(tǒng)
????? 如果您正在構(gòu)建一個(gè)大的系統(tǒng)（即一系列的應(yīng)用程序），那么一個(gè)業(yè)務(wù)建模工作可能成為數(shù)個(gè)軟件工程項(xiàng)目的輸入。業(yè)務(wù)模型幫助您找出功能性需求，并且也作為構(gòu)建應(yīng)用程序系列構(gòu)架的輸入。詳情請(qǐng)參見概念：從業(yè)務(wù)模型到系統(tǒng)。在這種情況下，通常將業(yè)務(wù)建模工作本身當(dāng)做一個(gè)項(xiàng)目。
????? 場(chǎng)景 #4 - 通用業(yè)務(wù)模型
????? 如果您正在構(gòu)建一個(gè)供多個(gè)組織使用的應(yīng)用程序（例如，銷售支持應(yīng)用程序或結(jié)賬應(yīng)用程序）。一種有效的做法是：從頭到尾進(jìn)行一次業(yè)務(wù)建模工作，從而按這些組織的經(jīng)營方式對(duì)它們進(jìn)行調(diào)整，避免一些對(duì)于系統(tǒng)來說過于復(fù)雜的需求（業(yè)務(wù)改進(jìn)）。但如果無法對(duì)組織進(jìn)行調(diào)整，那么業(yè)務(wù)建模工作能夠幫助您了解并管理這些組織使用該應(yīng)用程序時(shí)存在的差別，并使您更容易確定應(yīng)用程序功能的優(yōu)先級(jí)。
????? 場(chǎng)景 #5 - 新業(yè)務(wù)
????? 如果某個(gè)組織決定要啟動(dòng)一項(xiàng)全新的業(yè)務(wù)（業(yè)務(wù)創(chuàng)建），并將構(gòu)建信息系統(tǒng)來支持該業(yè)務(wù)，那么就需要進(jìn)行業(yè)務(wù)建模工作。在這種情況下，業(yè)務(wù)建模的目的就不僅僅是要找出對(duì)系統(tǒng)的需求，而且還要確定新業(yè)務(wù)是否可行。在這種情況下，通常將業(yè)務(wù)建模工作本身當(dāng)做一個(gè)項(xiàng)目。
????? 場(chǎng)景 #6 - 修改
????? 如果某個(gè)組織決定要對(duì)其經(jīng)營方式進(jìn)行徹底修改（業(yè)務(wù)重建），那么業(yè)務(wù)建模通常本身就是一個(gè)或多個(gè)項(xiàng)目。通常，業(yè)務(wù)重建分?jǐn)?shù)個(gè)階段完成：新業(yè)務(wù)展望、對(duì)現(xiàn)有業(yè)務(wù)實(shí)施逆向工程、對(duì)新業(yè)務(wù)實(shí)施正向工程以及啟動(dòng)新業(yè)務(wù)。
四、業(yè)務(wù)建模時(shí)期的主要任務(wù)
????? 項(xiàng)目涉眾的共同愿景：要想項(xiàng)目成功，可離不開項(xiàng)目涉眾的支持。在項(xiàng)目一開始，不論是項(xiàng)目涉眾還是開發(fā)人員，對(duì)項(xiàng)目的任務(wù)、范圍都是模糊不清的。但隨著項(xiàng)目的深入，原來模糊的景象會(huì)慢慢清晰、立體起來。但是為了不浪費(fèi)時(shí)間，我們有必要在項(xiàng)目射入之前，現(xiàn)在項(xiàng)目涉眾中豎立一個(gè)共同的愿景。
????? 共同愿景的豎立可沒有想象中的那么簡單，因?yàn)槊课簧姹姸缄P(guān)心自己的利益，都有自己的評(píng)判標(biāo)準(zhǔn)。你可以把大家的意見都列在白板上，然后逐項(xiàng)集中討論，做出修正，直到大家的意見一致的時(shí)候?yàn)橹埂Ｔ诠餐h(yuǎn)景的豎立過程中，其實(shí)有兩件事情也已經(jīng)同時(shí)做了，項(xiàng)目范圍（scope）和高階（high-level）需求。
????? 項(xiàng)目范圍：項(xiàng)目該做什么，不該做什么，需要在一開始就有明確的定義。對(duì)于項(xiàng)目范圍內(nèi)的需求，一個(gè)也不要放過，而項(xiàng)目之外的，一個(gè)也不要去關(guān)心。雖然有的時(shí)候，范圍的變化會(huì)有利于項(xiàng)目本身，例如客戶的合理要求或是市場(chǎng)目標(biāo)客戶的變化，但是這種變化應(yīng)該要在"資源能夠支持"和"得到審批"的前提下進(jìn)行。
????? 項(xiàng)目范圍的描述可以通過陳述和圖示來進(jìn)行。我建議大家使用圖示。因?yàn)殛愂稣Z句比較含糊不清。例如常常聽到有客戶說。"我要建立我公司的電子商務(wù)系統(tǒng)。"這句話就是含糊不清的，你的電子商務(wù)系統(tǒng)是銷售什么產(chǎn)品？面向什么客戶？是否要支持在線支付？根據(jù)這些疑問，這個(gè)陳述句可以做進(jìn)一步的修改，"建立在線訂貨系統(tǒng)，針對(duì)當(dāng)前的目標(biāo)客戶銷售公司的目前產(chǎn)品。"這樣就清楚許多了。不過圖示的方法會(huì)更好一些，在圖的選擇上，你可以使用DFD圖或是用例圖。根據(jù)經(jīng)驗(yàn)，DFD圖比較容易為客戶所接受。
????? 高階需求：這個(gè)部分我們?cè)谙旅鏁?huì)詳細(xì)討論。既然是高階需求，就不能討論過多的細(xì)節(jié)。在討論高階需求的時(shí)候，盡量保證快速的討論出系統(tǒng)的概貌，建立需求模型，得到項(xiàng)目涉眾的一致通過。
????? 取得支持：為了保證需求計(jì)劃的順利進(jìn)行，取得項(xiàng)目涉眾的支持至關(guān)重要。你可以選擇在這個(gè)時(shí)候告訴項(xiàng)目涉眾他們的權(quán)利和義務(wù)，以及開發(fā)人員的權(quán)利和義務(wù)。在這個(gè)方面，具體的我不想多說，大家可以參考『軟件需求』的第二章。主要的就是"涉眾有改變需求的權(quán)利，同時(shí)要承擔(dān)向開發(fā)人員講解需求的義務(wù)。"開發(fā)人員的權(quán)利和義務(wù)正好和涉眾相反。
????? 業(yè)務(wù)建模會(huì)議：所有的這一切都通過業(yè)務(wù)建模會(huì)議進(jìn)行，和其它會(huì)議不同的是，這個(gè)會(huì)議需要所有的項(xiàng)目涉眾參加，如果不能獲取所有項(xiàng)目涉眾的意見，那就不是完美的。會(huì)議中最重要的工具就是白板，一位出色的速記員也是必須的。
五、需求和業(yè)務(wù)建模
????? 業(yè)務(wù)建模是需求工程中最初始的階段，也是整個(gè)項(xiàng)目的初始階段。需要指出的是，業(yè)務(wù)建模時(shí)間的跨度在不同的項(xiàng)目中有很大的差別的。在有些項(xiàng)目中，例如大型ERP系統(tǒng)，可能需要幾個(gè)月的時(shí)間。而對(duì)于普通的項(xiàng)目，業(yè)務(wù)建模的時(shí)間可能僅僅需要幾天的時(shí)間。
????? 需求是技術(shù)無關(guān)（technology independent）的。在需求階段討論技術(shù)是沒有任何意義的。那只會(huì)讓你的注意力分散。技術(shù)的實(shí)現(xiàn)細(xì)節(jié)是在后面的分析、設(shè)計(jì)階段才需要考慮的事情。而在業(yè)務(wù)建模階段，不但要保證需求的技術(shù)無關(guān)性，還要保證你的需求不要深入細(xì)節(jié)。因?yàn)樵跇I(yè)務(wù)建模階段，最重要的事情就是要了解業(yè)務(wù)的全貌，深入細(xì)節(jié)會(huì)浪費(fèi)時(shí)間和精力。要知道，討論一個(gè)企業(yè)里的業(yè)務(wù)細(xì)節(jié)，就算給你一個(gè)月的時(shí)間也沒必能夠結(jié)束。
????? 在實(shí)際中，這兩點(diǎn)都是很難做到的。例如企業(yè)原先有一個(gè)系統(tǒng)，這就不得不由你討論和新舊系統(tǒng)的兼容問題。這時(shí)候就要注意，如果你是討論就有系統(tǒng)的架構(gòu)的話，那還是屬于技術(shù)無關(guān)的范疇，如果你一旦進(jìn)而討論各具體模塊/組件的細(xì)節(jié)，那就非但不是技術(shù)無關(guān)，而且也深入細(xì)節(jié)了。在不深入細(xì)節(jié)的問題上，往往你很難禁止項(xiàng)目涉眾（Stakeholder）①不去討論一些相關(guān)的業(yè)務(wù)細(xì)節(jié)。這個(gè)時(shí)候你可以將這些細(xì)節(jié)記錄下來，然后再回到業(yè)務(wù)建模上。
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉眾是所有會(huì)受到項(xiàng)目結(jié)果重大影響的人。
摘自《IBM DeveloperWorks》
六、業(yè)務(wù)建模中的用例
在上一篇中我們討論了很多用例的知識(shí)，可是落實(shí)到企業(yè)中的時(shí)候，我們往往會(huì)感覺難以把握企業(yè)的用例，這一點(diǎn)我們?cè)谟美恼`區(qū)中也有提到。在實(shí)際的情況中，你可能會(huì)對(duì)角色的歸類，用例的劃分，粒度的把握等很細(xì)節(jié)的方面都沒有底，偏偏這些實(shí)際的東西對(duì)你的項(xiàng)目有非常大的影響。
RUP中，有多種的概念來支持用例的實(shí)現(xiàn)：業(yè)務(wù)主角（Business Actor）、業(yè)務(wù)實(shí)體（Business Entity）、業(yè)務(wù)用例（Business Use Case）、業(yè)務(wù)角色（Business Worker）、業(yè)務(wù)用例實(shí)例（Business Use-Case Instance）。為了能夠比較清楚的展示出業(yè)務(wù)建模，我們采用了UP方法的代表――RUP。但在實(shí)際中，要視大家具體的情況而定，這里所講到的概念，都是為了幫助大家理解建模過程，并不是讓大家生搬硬套。
在我們對(duì)系統(tǒng)還絲毫不了解的時(shí)候，我們就會(huì)把系統(tǒng)看成一個(gè)很大很大的黑盒，這個(gè)大黑盒子我們會(huì)叫他業(yè)務(wù)域（Business Domain），把它的外部看成一個(gè)業(yè)務(wù)環(huán)境（business environment）。而那些在業(yè)務(wù)環(huán)境中和業(yè)務(wù)域有關(guān)系的人（也可能是物）就被稱為業(yè)務(wù)主角（Business Actor）。在實(shí)際的例子中，我們可能會(huì)把信貸業(yè)務(wù)（注意不是信貸業(yè)務(wù)系統(tǒng)，這里是業(yè)務(wù)建模，系統(tǒng)還不存在。）稱為業(yè)務(wù)域，我們經(jīng)過調(diào)查，發(fā)現(xiàn)平時(shí)和信貸業(yè)務(wù)打交道的有客戶，人民銀行，外匯管理局，其他銀行，信貸部門使用的其他系統(tǒng)，銀行內(nèi)部的其他部門。所以這些人（物）就是業(yè)務(wù)主角。業(yè)務(wù)主角的實(shí)例一般包括了客戶、供應(yīng)商、合作伙伴、潛在客戶（"市場(chǎng)"）、當(dāng)?shù)卣⒃跇I(yè)務(wù)中未建模部分工作的同事等。必須注意的是，業(yè)務(wù)主角表示的特定類型的用戶，而不是某一個(gè)具體的用戶。一個(gè)角色可能會(huì)有很多實(shí)際用戶擔(dān)任，一個(gè)實(shí)際的用戶也可能會(huì)擔(dān)任很多的角色。
業(yè)務(wù)用例以及業(yè)務(wù)用例實(shí)例在RUP中的定義如下：
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business. A business use case defines a set of business use-case instances. A business use case has a name.
業(yè)務(wù)用例實(shí)例是在業(yè)務(wù)中執(zhí)行的一系列動(dòng)作，這些動(dòng)作為業(yè)務(wù)的個(gè)體主角產(chǎn)生具有可見價(jià)值的結(jié)果。業(yè)務(wù)用例定義了一組業(yè)務(wù)用例實(shí)例。業(yè)務(wù)用例具有名稱。
剛開始大家可能會(huì)對(duì)業(yè)務(wù)用例以及業(yè)務(wù)用例實(shí)例有所疑問。其實(shí)可以把他們看成基類和子類的關(guān)系。在一個(gè)企業(yè)中，具體的工作流程可能有很多很多，比如你去麥當(dāng)勞的時(shí)候，點(diǎn)漢堡和點(diǎn)薯?xiàng)l的工作流程就不一樣。眾多的流程給需求的調(diào)查工作造成了一定的難度。即使是最古老的哲學(xué)也告訴我們，表面現(xiàn)象是復(fù)雜的，本質(zhì)是簡單的。為了簡化需求工作，我們就把點(diǎn)漢堡和點(diǎn)薯?xiàng)l歸納為點(diǎn)餐。這樣，點(diǎn)餐就是一個(gè)業(yè)務(wù)用例，而點(diǎn)漢堡、點(diǎn)薯?xiàng)l就是相對(duì)應(yīng)的業(yè)務(wù)用例實(shí)例。
業(yè)務(wù)用例
業(yè)務(wù)角色和業(yè)務(wù)主角的概念也很容易讓人摸不著頭腦。其實(shí)看它們的英文愿意會(huì)更容易理解它們的區(qū)別：Business Worker，Business Actor。Worker有工人的意思，而Actor有參與者的意思。所以它們的區(qū)別就是一個(gè)在內(nèi)部，一個(gè)在外部。業(yè)務(wù)角色是實(shí)現(xiàn)業(yè)務(wù)用例的人，業(yè)務(wù)主角是和業(yè)務(wù)有關(guān)的人。例如，對(duì)銀行的押匯業(yè)務(wù)而言，客戶就是業(yè)務(wù)主角，他和業(yè)務(wù)有關(guān)。而押匯人員就是業(yè)務(wù)角色，因?yàn)樗麄兪菍?shí)現(xiàn)業(yè)務(wù)用例的人。在RUP中，二者定義如下：
A business worker represents a role or set of roles in the business. A business worker interacts with other workers and manipulates business entities while participating in business use-case realizations.
業(yè)務(wù)角色代表業(yè)務(wù)中的一個(gè)或一組角色。參與業(yè)務(wù)用例實(shí)現(xiàn)時(shí)，一個(gè)業(yè)務(wù)角色和其他角色進(jìn)行交互，并操縱業(yè)務(wù)實(shí)體
A business actor represents a role played in relation to the business by someone or something in the business environment.
業(yè)務(wù)主角代表了與業(yè)務(wù)有關(guān)的角色，此角色由業(yè)務(wù)環(huán)境中的某個(gè)人或物來擔(dān)任。
業(yè)務(wù)角色
業(yè)務(wù)主角
分辨業(yè)務(wù)角色和業(yè)務(wù)主角要看環(huán)境而定。當(dāng)你開發(fā)企業(yè)的ERP系統(tǒng)時(shí)，部門的員工都屬于業(yè)務(wù)角色，而你開發(fā)一個(gè)部門級(jí)的應(yīng)用時(shí)，其他部門的員工可能屬于業(yè)務(wù)主角。
業(yè)務(wù)實(shí)體，在一些文章中被稱為商業(yè)對(duì)象（Business Object）。不論怎么叫，所表示的意義都是一樣的。例如在銀行信貸這個(gè)例子中，我們就涉及到很多業(yè)務(wù)實(shí)體：契約、單筆貸款、客戶等。所以業(yè)務(wù)實(shí)體就是企業(yè)中那些很基本的要素。如果覺得銀行押匯的例子不好理解。可以想象餐廳中的菜單、漢堡等都是業(yè)務(wù)實(shí)體。在RUP中，業(yè)務(wù)實(shí)體被定義為：
A business entity represents a "thing" handled or used by business workers.
業(yè)務(wù)實(shí)體代表業(yè)務(wù)角色處理或使用的"事物"。
業(yè)務(wù)實(shí)體
在很早以前，我們討論過需求易變性。相對(duì)于需求的不斷變化，可是業(yè)務(wù)實(shí)體對(duì)象在一段相當(dāng)長的時(shí)間內(nèi)都存在。航空公司今天打折，明天又不打，還有明折、暗折。可是機(jī)票從來沒見有什么大的變化，從來也只有那幾樣屬性：價(jià)格、航班、出發(fā)地、目的地。所以業(yè)務(wù)實(shí)體是比較穩(wěn)定的。這對(duì)于我們是有很大的意義的：
"一個(gè)業(yè)務(wù)實(shí)體經(jīng)常代表某個(gè)對(duì)多個(gè)業(yè)務(wù)用例或用例實(shí)例有價(jià)值的事物，因此，業(yè)務(wù)實(shí)體對(duì)象的生存期相當(dāng)長。一般而言，一個(gè)好的業(yè)務(wù)實(shí)體不包含關(guān)于其使用主體和使用方法的信息。"（RUP）
由業(yè)務(wù)實(shí)體組成的業(yè)務(wù)用例會(huì)穩(wěn)定很多。在以前，開發(fā)方式采用模塊為基礎(chǔ)的方法，需求變化的時(shí)候，只好改寫模塊。如果采用穩(wěn)定的業(yè)務(wù)實(shí)體來實(shí)現(xiàn)業(yè)務(wù)用例的話，業(yè)務(wù)用例的改變只需要對(duì)業(yè)務(wù)實(shí)體進(jìn)行重新的組合。當(dāng)然，這里還需要很多的技術(shù)來實(shí)現(xiàn)，并沒有那么簡單。要知道，四個(gè)現(xiàn)代化可不是一天就能夠?qū)崿F(xiàn)的。
還有一個(gè)使用業(yè)務(wù)實(shí)體的重要原因：業(yè)務(wù)實(shí)體的特性決定它具有天生的重用性。就像麥當(dāng)勞的銷售系統(tǒng)中有漢堡實(shí)體，生產(chǎn)系統(tǒng)中也有，供應(yīng)鏈系統(tǒng)中也有。天哪，這世界真是美好！
使用業(yè)務(wù)實(shí)體一個(gè)很大的困惑是應(yīng)該把它做為類還是屬性。這個(gè)取決于業(yè)務(wù)環(huán)境對(duì)這個(gè)實(shí)體的重視程度。一個(gè)客戶在銀行信貸部門是一個(gè)很重要的類，而在押匯部門就只是信用證實(shí)例的一個(gè)屬性。這個(gè)問題非常的重要。設(shè)計(jì)時(shí)的失誤可能會(huì)導(dǎo)致今后系統(tǒng)改進(jìn)的極大痛苦。例如本該設(shè)計(jì)為類的業(yè)務(wù)實(shí)體設(shè)計(jì)成了屬性，在今后增加屬性的時(shí)候不得不面對(duì)著數(shù)據(jù)庫的調(diào)整和系統(tǒng)的修改。
6. 建立業(yè)務(wù)用例模型
業(yè)務(wù)用例模型（business use-case model），在RUP中定義為：
The business use-case model is a model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.
業(yè)務(wù)用例模型是說明業(yè)務(wù)預(yù)期功能的模型。作為一個(gè)核心輸入模型，業(yè)務(wù)用例模型用于確定組織的各個(gè)角色和可交付工件。
從業(yè)務(wù)用例模型的定義可以看出，它是企業(yè)最核心，最概括的業(yè)務(wù)說明。它主要是由業(yè)務(wù)用例和業(yè)務(wù)主角構(gòu)成的，其主要目的是說明客戶和合作伙伴是如何開展業(yè)務(wù)的，它描述業(yè)務(wù)的主要方式是通過業(yè)務(wù)用例的方式。下圖為RUP中業(yè)務(wù)用例模型的圖示。
業(yè)務(wù)用例模型
從圖中我們也可以很清楚的看出業(yè)務(wù)用例模型包括一組的業(yè)務(wù)用例。這是因?yàn)槠髽I(yè)中的業(yè)務(wù)通常都會(huì)由多個(gè)的業(yè)務(wù)用例的多個(gè)實(shí)例構(gòu)成。這些業(yè)務(wù)用例形成的企業(yè)工作流程可能會(huì)由業(yè)務(wù)主角所引發(fā)，也可能會(huì)由業(yè)務(wù)規(guī)則②所引發(fā)。
②業(yè)務(wù)規(guī)則（Business Rules）：業(yè)務(wù)規(guī)則是必須遵守的政策或條件的聲明。（Business Rules are declarations of policy or conditions that must be satisfied.）
業(yè)務(wù)用例模型實(shí)際上就是企業(yè)經(jīng)營業(yè)務(wù)的一種描述，為了建立完整、準(zhǔn)確的企業(yè)用例模型，應(yīng)該將注意力專注于企業(yè)的業(yè)務(wù)做了些什么事情，而不應(yīng)該集中于如何做。雖然這樣可能會(huì)產(chǎn)生一些業(yè)務(wù)用例相沖突，相重復(fù)的情況，但是RUP的思想在于迭代，這項(xiàng)工作完全可以在接下去的迭代周期內(nèi)完善。
業(yè)務(wù)用例模型是和企業(yè)業(yè)務(wù)最貼近的計(jì)算機(jī)模型。它的很多思想和企業(yè)日常經(jīng)營如出一轍。在企業(yè)的日常活動(dòng)中，業(yè)務(wù)的種類可能有很多種。在一些講述ERP思想的文章中，通常會(huì)強(qiáng)調(diào)三類：
一種是和主營業(yè)務(wù)密切相關(guān)的工作，例如銀行的營業(yè)部、信貸部、押匯部等。這種工作通過人的勞動(dòng)，將一種資源轉(zhuǎn)變?yōu)榱硪环N資源，產(chǎn)生價(jià)值。
一種是管理型的工作，例如公司的管理層，財(cái)務(wù)部門等。這種工作本身并不產(chǎn)生價(jià)值，但是它通過指導(dǎo)、管理、檢測(cè)第一種工作，加大第一種工作的產(chǎn)出價(jià)值。
還有一種稱為支持工作，例如系統(tǒng)管理、安全等。它并不是很重要，具有支持其他工作的性質(zhì)。
業(yè)務(wù)模型同樣可以使用這種分類。通過這種分類，可以更好的把握核心業(yè)務(wù)用例，為下一步的工作打好基礎(chǔ)。
有很多業(yè)務(wù)用例是由業(yè)務(wù)主角觸發(fā)的，RUP中也把和業(yè)務(wù)主角有關(guān)聯(lián)關(guān)系的業(yè)務(wù)用例稱為核心業(yè)務(wù)用例（Core Business Use Case）。這強(qiáng)調(diào)了構(gòu)建業(yè)務(wù)模型的目的是為了提供以用戶為中心的服務(wù)。這也是我們建立業(yè)務(wù)用例的時(shí)候應(yīng)該注意的。
當(dāng)然，有時(shí)候業(yè)務(wù)用例的觸發(fā)是為了產(chǎn)生用戶需要的結(jié)果。例如企業(yè)的市場(chǎng)調(diào)查行為就不是由業(yè)務(wù)主角觸發(fā)，而是企業(yè)積累了大量用戶請(qǐng)求的結(jié)果。而對(duì)于管理型、支持型的，不直接和業(yè)務(wù)主角的客戶類發(fā)生聯(lián)系，但是也有其特定的業(yè)務(wù)主角，如管理型的業(yè)務(wù)用例需要和董事會(huì)為發(fā)生聯(lián)系，支持型的業(yè)務(wù)用例可能和供應(yīng)商發(fā)生聯(lián)系。
在建立了基本的業(yè)務(wù)用例模型之后，對(duì)此模型進(jìn)行精化是非常有必要的，這時(shí)候，在上一章中我們介紹的用例的擴(kuò)展關(guān)系和使用關(guān)系就有了用武之地。除了這兩種關(guān)系，還有一種新的關(guān)系。
7. 在業(yè)務(wù)建模中使用關(guān)系
泛化關(guān)系（Generalization）：根據(jù)我的理解，可以把它看作我們比較熟悉的繼承關(guān)系很相似的一種關(guān)系。Generalization一詞含有一般化、概括的意思。它是一個(gè)相對(duì)抽象的詞。雖然它和繼承關(guān)系非常相似，但是它們?cè)谑褂铆h(huán)境和產(chǎn)生目的方面都有相異之處。下圖描述了四個(gè)業(yè)務(wù)實(shí)體之間的泛化關(guān)系：
當(dāng)你去麥當(dāng)勞的時(shí)候（不要誤會(huì)，我并不是很經(jīng)常去的），會(huì)選擇麥香雞漢堡、麥香魚漢堡或是吉士漢堡。但是分別對(duì)這三種漢堡建立業(yè)務(wù)實(shí)體就非常沒有意義。所以可以將它們概括為漢堡這個(gè)業(yè)務(wù)實(shí)體。同樣的道理，企業(yè)的業(yè)務(wù)流程中也可以概括出一些共有的屬性和行為。為了避免多次說明同一個(gè)工作流程，您可以將共有的行為放在一個(gè)單獨(dú)的業(yè)務(wù)用例中。稱為父用例，執(zhí)行子用例的用例實(shí)例將遵循父用例的事件流，同時(shí)插入附加行為或修改在子用例事件流中定義的行為。
8. 方法的選擇
以上的原理我采用了UP的方法。但是除了UP方法，還有XP、FDD等方法。所以在做業(yè)務(wù)建模的時(shí)候，也要根據(jù)不同的方法選擇適當(dāng)?shù)墓ぜ＠缢夭暮凸δ堋７椒ǖ暮脡牟⒉皇俏覀冞@片文章討論的重點(diǎn)，我會(huì)在另一篇文章中討論方法。再一次需要強(qiáng)調(diào)的是，上面討論的RUP的工件只是為了學(xué)習(xí)，所以才定義了比較復(fù)雜的工件，區(qū)分了它們之間的區(qū)別。但是在實(shí)際中，并不需要這么多的工件，那只會(huì)使你的項(xiàng)目涉眾和開發(fā)人員糊涂。這些工件的區(qū)別只要在你心中就可以了。
?
六、業(yè)務(wù)建模的原則（Principle）
1. 誰才是"上帝"
我們說客戶是上帝，是因?yàn)榭蛻舻闹匾裕蛻粽加袥Q定性的地位。可是在軟件開發(fā)中，到底是誰有決定權(quán)呢？是出資方，還是項(xiàng)目經(jīng)歷，或是程序員？
職責(zé)不清，是業(yè)務(wù)建模失敗的主要原因之一。我們可以很容易的看見客戶把自己的要求用幾句話高度濃縮之后扔給開發(fā)人員，或是開發(fā)人員按照自己的意思開發(fā)程序。難道說，客戶和開發(fā)人員之間真的是"心有靈犀"，完全不用溝通的嗎。
我在前文中已經(jīng)提到過項(xiàng)目涉眾和開發(fā)人員的權(quán)利和義務(wù)，我想這里還有必要再次強(qiáng)調(diào)。Scott W. Ambler說：
it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them.
在我一次開發(fā)過程中，遇到過一個(gè)很有意思的涉眾，他在他的需求分析中這樣寫："總之，要實(shí)現(xiàn)那種能夠想到就能做到功能。"我想，這位涉眾對(duì)我們的計(jì)算機(jī)工業(yè)有著非常遠(yuǎn)大的抱負(fù)。但我不得不客氣的告訴他目前實(shí)現(xiàn)是不太現(xiàn)實(shí)的。
大家聽了可能會(huì)覺得好笑，但是在我自己和客戶打交道的生涯中，這種客戶不在少數(shù)。現(xiàn)實(shí)就是這樣，你要怎么做？是一笑之后，棄之不顧嗎？我想大多數(shù)人會(huì)這樣做。因?yàn)樗囊筇奶屏寺铩？墒牵阌袥]有花時(shí)間去了解一下，他這句荒唐的話背后代表了他的什么意思呢？我覺得，軟件開發(fā)人員負(fù)有教育涉眾的義務(wù)，你需要引導(dǎo)你的涉眾，讓他們說出自己的心聲。我在看到這位涉眾的這句話后，就花了一些時(shí)間去了解，其實(shí)呢，事情很簡單，他就是想要一個(gè)能夠定制報(bào)表模板的功能。而在項(xiàng)目結(jié)束后，我和這位涉眾有幸再一次的合作，這時(shí)候，他已經(jīng)成為了一個(gè)出色的客戶方的項(xiàng)目領(lǐng)導(dǎo)者了。
這個(gè)例子說明了什么呢？涉眾往往都是領(lǐng)域?qū)＜遥瑢?duì)自己的工作有很深的認(rèn)識(shí)，可是由于對(duì)軟件開發(fā)的不了解，涉眾往往表達(dá)不清，甚至表達(dá)不出自己的需求。這時(shí)候，就是體現(xiàn)你的功力的時(shí)候了。記住，象對(duì)待上帝一樣對(duì)待你的客戶。
2. 耐心是首要的
明白了誰是"上帝"，那就要耐心的對(duì)待上帝。學(xué)理工科的人，一般在邏輯思維上會(huì)比較好，可是對(duì)于涉眾來說，可不一定是這樣。我就遇到過一位做檔案工作的涉眾，在了解需求的時(shí)候，扯東扯西，含糊不清。明明一分鐘前才否定的方法，下一分鐘又提出來了。我覺得我的脾氣應(yīng)該是不錯(cuò)的，可到最后也幾乎發(fā)飚。所幸，最后我終于撐了下來。我想，在經(jīng)歷過這件事情之后，我的耐心指數(shù)又會(huì)有一個(gè)很大的提高了吧。
我有一位同事的耐性是我所佩服的，在一個(gè)網(wǎng)站項(xiàng)目中，他負(fù)責(zé)系統(tǒng)分析。他整整花了三天的時(shí)間，和網(wǎng)站項(xiàng)目的負(fù)責(zé)人住在一起。最后系統(tǒng)分析出來之后，他的精神還不錯(cuò)，可是那位負(fù)責(zé)人已經(jīng)快不行了。
當(dāng)然，這只是個(gè)笑話，并不是去鼓勵(lì)大家拼命。勞逸結(jié)合還是很重要的，身體是革命的本錢嘛。但是這告訴我們，如果缺少耐心，需求是很難成功的。例如在業(yè)務(wù)建模的討論會(huì)上，你雖然規(guī)定了這次的會(huì)議討論的是高階需求，可是與會(huì)者總會(huì)時(shí)不時(shí)的爭(zhēng)辯一些芝麻綠豆的小事兒。你怎么辦？我相信這種情況是很普遍的。
耐心最后會(huì)仍會(huì)體現(xiàn)為溝通，只有耐心的溝通，你才能揭開需求的重重面紗。人的行為總是會(huì)受到思想的指導(dǎo)，如果你解不開涉眾的心結(jié)，你就不可能了解他真正需要的。
我的一位項(xiàng)目涉眾的表現(xiàn)很奇怪，她總是在不停的說一件事情："她要實(shí)現(xiàn)報(bào)表自動(dòng)生成。"她的需求講來講去好像總脫不出這個(gè)范圍，可是我從她那里幾乎聽不到別的東西了。這時(shí)候，我決定放棄了，我想從她哪里可能已經(jīng)沒有更多的資料了。但在我了解到她的工作中報(bào)表處理占用了她大量的時(shí)間之后，我改變了想法。在我花了一些時(shí)間幫她理清了報(bào)表處理的思路之后，她還在其他方面給了我很大的幫助。
3. 參與是重要的
XP方法的一個(gè)重要實(shí)踐，就是提倡"現(xiàn)場(chǎng)客戶"（on-site customer）。也就是說，客戶應(yīng)該隨時(shí)和開發(fā)人員在一起，隨時(shí)提供資料和做出決策。而這個(gè)客戶，也必須領(lǐng)域?qū)＜遥夷軌蛴袡?quán)做出決策。
這種現(xiàn)場(chǎng)客戶相信國內(nèi)的軟件組織多半還做不到。但是一定要往這方面努力。我認(rèn)為，這種現(xiàn)場(chǎng)客戶有兩種人：一種是項(xiàng)目涉眾，還有一種是行業(yè)專家。其實(shí)很多軟件公司都會(huì)配備一些管理咨詢?nèi)藛T，這些人就是行業(yè)專家。有數(shù)據(jù)統(tǒng)計(jì)說，目前廣東省軟件公司中的咨詢?nèi)藛T和開發(fā)人員的比例達(dá)到了3：1。我覺得這是好事。項(xiàng)目涉眾往往對(duì)自己的工作中的事務(wù)性部分有很深的認(rèn)識(shí)，但是很難將之提升到一個(gè)理論的水平。這時(shí)候就需要一些行業(yè)專家來幫助了。讓行業(yè)專家和項(xiàng)目涉眾共同探討，還能夠激發(fā)項(xiàng)目涉眾的靈感，想到原來他想不到的方面。這就是"潛在需求"的開發(fā)。
另一方面，參與還意味著需要項(xiàng)目涉眾全身心的投入到業(yè)務(wù)建模的過程中來，要能夠調(diào)動(dòng)他們的積極性。因此呢，太復(fù)雜的流程會(huì)阻礙涉眾的參與。所以，使用一些簡單的、能夠?yàn)榭蛻羲邮艿墓ぜˋrtifact）來進(jìn)行業(yè)務(wù)建模是很有必要的。我說過前面討論的那些"主角"啊，"用例"啊，那是理論，是給開發(fā)人員看的，讓開發(fā)人員心里有個(gè)底。你給涉眾看這些，他們能懂嗎？等他們了解了這套機(jī)制，恐怕黃花菜都涼了吧。
素材（User Story）、特性（Feature）、CRC卡片這些都是很不錯(cuò)的工件，既簡單，又能夠滿足需要。
知識(shí)點(diǎn)：素材和特性都表述了用戶的一個(gè)簡單的要求，它能夠在較短的時(shí)間內(nèi)完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的縮寫，它是一張分為三個(gè)部分的卡片，分別標(biāo)記了類名，類的責(zé)任，以及類之間的合作關(guān)系。非常的貼近客戶，甚至可以在做游戲的過程中完成卡片的填寫，能帶來很強(qiáng)的客戶參與度。
4. 擁抱變化
我想這一點(diǎn)會(huì)遭到開發(fā)人員點(diǎn)一致指責(zé)。畢竟，需求變化是開發(fā)人員最討厭的一件事了。不錯(cuò)，我也討厭。可是，就像我們常說"哭不能解決問題"一樣，討厭能解決問題嗎？拒絕客戶的變更要求，要求客戶在需求規(guī)格說明書上簽字。這些做法只能是適得其反。沒有任何正面的、積極的意義。
必要的需求變更管理是重要的。因?yàn)闊o休止、無控制的變化必然會(huì)造成資源的極大浪費(fèi)。但從另一方面說，需求變更被接受的評(píng)判標(biāo)準(zhǔn)應(yīng)該是"是否合理"，而不是"是否易于實(shí)現(xiàn)"。
需求變更要求我們的開發(fā)工作要迭代式進(jìn)行，包括需求、設(shè)計(jì)、實(shí)現(xiàn)等階段。這樣才能將變更風(fēng)險(xiǎn)減到最小。這一點(diǎn)我們?cè)谟懻摼唧w需求建模的時(shí)候會(huì)進(jìn)一步討論。
擁抱變化的更高一個(gè)層次是提前預(yù)估變化。制定一個(gè)可能的變化清單來記錄可能出現(xiàn)的變化。最簡單的例子就是一個(gè)企業(yè)在開發(fā)了進(jìn)銷存系統(tǒng)之后又希望能夠開發(fā)財(cái)會(huì)系統(tǒng)與之相連。如果你能夠預(yù)先留下伏筆，相信能夠省不少力氣。預(yù)估變化的另一種做法是通過使用模式。但是切記，模式的使用也不能過頭。這些是題外話，如果有機(jī)會(huì)我會(huì)在其他的文章中集中討論這方面的問題。
七、業(yè)務(wù)建模的實(shí)踐（Practice）
5. 建模會(huì)議
會(huì)議是業(yè)務(wù)建模最重要的手段。盡管會(huì)議在中國總是背負(fù)著一些罵名，但是只要組織得好，它是一種相當(dāng)有效的溝通（Communication）手段。建模會(huì)議是一種大范圍的會(huì)議，換句話說，所有的相關(guān)人員都應(yīng)該參加會(huì)議。因?yàn)樵跇I(yè)務(wù)建模時(shí)期，主要的目的就是建立對(duì)系統(tǒng)的高階需求，這就要求眾多項(xiàng)目涉眾的共同參與，以保證需求的廣泛性。所以呢，建模會(huì)議的規(guī)模是相當(dāng)大的。出資方、高級(jí)經(jīng)理、經(jīng)理、直接用戶、開發(fā)人員，各方各面的人都應(yīng)該參加或是派代表參加建模會(huì)議。
如果大家有過參加大型會(huì)議的經(jīng)驗(yàn)都知道，越是大型的會(huì)議，它的決策效率就越低。這是正常的。因?yàn)橐粋€(gè)人的時(shí)候，不需要溝通，決策效率最高。等到兩個(gè)人的時(shí)候，他們需要溝通的時(shí)間來進(jìn)行決策。等到三個(gè)人的時(shí)候，這個(gè)溝通并達(dá)成一致的時(shí)間就更長。如果人數(shù)到了四個(gè)人、五個(gè)人甚至一二十個(gè)人，那么大部分的時(shí)間都會(huì)花在溝通上。更何況，人和人之間還有觀念不同、利益之爭(zhēng)。所以呢，為了保證會(huì)議的效率和效果，應(yīng)該遵循一定的規(guī)則：
·做好準(zhǔn)備：如果你要開會(huì)，與會(huì)者連內(nèi)容都不清楚，那你會(huì)怎么辦。你必須首先花很多的時(shí)間來說明你開會(huì)的目的，是不是。要事先將會(huì)議的主題、議程連同會(huì)議通知發(fā)送給與會(huì)者，讓他們先有個(gè)準(zhǔn)備，會(huì)議開始時(shí)就能夠迅速進(jìn)入正題。
·盡量邀請(qǐng)最多的人：我已經(jīng)說過，如果建模會(huì)議不能夠聽取最廣泛的意見，它就不是一個(gè)成功的會(huì)議。可是在現(xiàn)實(shí)中，這點(diǎn)往往難以做到。因?yàn)槟繕?biāo)組織做為客戶，往往都很"拽"，在沒有充分認(rèn)識(shí)會(huì)議的重要性之前，要做到全部到場(chǎng)簡直就是不可能。而客觀上也會(huì)有出差、休假、有要事等原因做不到這一點(diǎn)。這里，一方面你需要向目標(biāo)組織的決策者闡明利害，讓他們重視。另一方面，你也需要積極主動(dòng)的邀請(qǐng)項(xiàng)目涉眾參與。因?yàn)檠?qǐng)所有的人是不可能的，所以就盡可能的多吧。
·分出與會(huì)者的級(jí)別：我很喜歡那種有一個(gè)內(nèi)圈、一個(gè)外圈的會(huì)議室。因?yàn)槲已?qǐng)所有人是件無法做到的事情，所以我首先要保證核心人員能夠全部到場(chǎng)，坐在內(nèi)圈，然后才是次要的人員，坐在外圈。核心人員是和你的項(xiàng)目息息相關(guān)的那種人。比如，財(cái)務(wù)系統(tǒng)，財(cái)務(wù)主管就是核心人員。要保證核心人員全員到場(chǎng)，至于次要人員，越全越好。
·從底層開始：中國人有個(gè)比較不好的習(xí)慣，就是老板說一的時(shí)候，他決不會(huì)說二。所以要先讓底層先說話，然后才輪到中層，再到上層。開發(fā)人員是不說話的，他們要么聽，要么引導(dǎo)大家說話。如果我們一開始就先讓領(lǐng)導(dǎo)來訓(xùn)話一番，那底層的人也就不用再說什么了。
·列舉所有涉眾的所有觀點(diǎn)：首先要讓大家能夠?qū)π碌南到y(tǒng)暢所欲言，然后把所有的觀點(diǎn)都羅列在白板上。這里頭可能會(huì)有一些觀點(diǎn)會(huì)是非常荒唐的，但沒有關(guān)系，盡管寫上去。這是一個(gè)腦力激蕩的過程，很容易產(chǎn)生出新的idea。主持的開發(fā)人員的主要工作就是引導(dǎo)和鼓勵(lì)大家說出更多的想法，并記錄下來。這里我們稍微離題一下，有人說中國人在會(huì)議上大都不愿意發(fā)表意見，我看在這種建模會(huì)議上不必過于擔(dān)心此事。為什么呢，因?yàn)轫?xiàng)目涉眾不需要為他們的發(fā)言擔(dān)任何的責(zé)任，說了，白說，白說誰不說。
·將觀點(diǎn)分類：想必你的項(xiàng)目涉眾已經(jīng)有些累了，創(chuàng)意也差不多了，你的白板估計(jì)也滿了。但是你看看白板上的觀點(diǎn)，有很多是重復(fù)的，有很多是類似的。所以你需要用邏輯的觀念將這些觀點(diǎn)歸類整理。這個(gè)工作也可以由你引導(dǎo)大家去做。
·確定優(yōu)先級(jí)：對(duì)觀點(diǎn)排出優(yōu)先級(jí)也是非常重要的，它能夠幫助你識(shí)別出重大的風(fēng)險(xiǎn)，并為你在制定迭代計(jì)劃時(shí)提供指導(dǎo)。同樣，這項(xiàng)工作也應(yīng)該由項(xiàng)目涉眾來確定。
·調(diào)查主要業(yè)務(wù)邏輯：什么叫主要業(yè)務(wù)邏輯？包括了企業(yè)的主要業(yè)務(wù)流程、主要的業(yè)務(wù)規(guī)則、重大的算法。這些都是需要在一開始就十分明確的資料，需要在建模會(huì)議上了解清楚。當(dāng)然，你不能對(duì)你的項(xiàng)目涉眾說，"這個(gè)，接下來，大家談一談主要的業(yè)務(wù)邏輯吧。"下面的涉眾一定摸不著頭腦。你還是應(yīng)該引導(dǎo)涉眾，從涉眾的話語中捕捉你需要的信息。
·注意會(huì)議時(shí)間：人不是機(jī)器，是會(huì)累的。所以控制好會(huì)議的長度很關(guān)鍵。一般，這種會(huì)議會(huì)有四五個(gè)小時(shí)，根據(jù)統(tǒng)計(jì)，兩個(gè)小時(shí)內(nèi)的會(huì)議不會(huì)讓人產(chǎn)生疲勞感。所以應(yīng)該把會(huì)議分成幾小段。另外，你還可以根據(jù)會(huì)議的進(jìn)展來決定每小段會(huì)議參與的人數(shù)。因?yàn)椋瑫?huì)議越往后，一些與會(huì)者就不太重要了。
·避免細(xì)節(jié)：建模會(huì)議主要的目標(biāo)是建立高階需求。如果把過多的時(shí)間花在討論雞毛蒜皮的小事，那就會(huì)浪費(fèi)大家的時(shí)間。而在此時(shí)調(diào)查需求細(xì)節(jié)是沒有很大的意義的。因?yàn)槟銓?duì)很多的事情都還不了解，需要進(jìn)一步的深入。這時(shí)候的細(xì)節(jié)對(duì)你并沒有太多的幫助。
·回避技術(shù)：我在一次建模會(huì)議的時(shí)候，遇到一位負(fù)責(zé)技術(shù)的涉眾，他總是不停的詢問系統(tǒng)的技術(shù)架構(gòu)，推銷他的設(shè)計(jì)理念。使得我不得不好幾次重申，"技術(shù)問題我們會(huì)單獨(dú)找時(shí)間談。"我想，那位技術(shù)人員應(yīng)該是有比較好的理念，也很希望能夠表現(xiàn)一把，這點(diǎn)無可厚非。但是這個(gè)時(shí)候還不是討論技術(shù)的時(shí)候，需求尚未明確，討論技術(shù)實(shí)現(xiàn)不是本末倒置么？
·做好記錄：俗話說，好記性不如爛筆頭。所以在會(huì)議上做好記錄是非常關(guān)鍵的。因?yàn)檫@種會(huì)議的代價(jià)相當(dāng)高昂，你的項(xiàng)目涉眾不可能每天不干活，陪你開會(huì)的，就算他們肯，他們的老板也不肯。所以要充分利用好會(huì)議的成果，所以一個(gè)優(yōu)秀的速記員絕對(duì)是必要的。另外，根據(jù)研究顯示，如果使用錄音機(jī)的話，會(huì)使得與會(huì)者心存芥蒂而不愿開口，所以，不要使用錄音機(jī)。
6. 測(cè)試
在需求的初始階段提到測(cè)試可能會(huì)覺得有些奇怪。凡是項(xiàng)目，總會(huì)有一個(gè)標(biāo)準(zhǔn)來考核是否成功。這里的測(cè)試指的是考核軟件項(xiàng)目是否成功的一個(gè)"執(zhí)行性目標(biāo)"。
這個(gè)目標(biāo)將會(huì)是軟件開發(fā)最終要滿足的條件，軟件成功與否的判定標(biāo)準(zhǔn)。很多企業(yè)在信息化建設(shè)的時(shí)候沒有一個(gè)比較明確的目標(biāo)。所以在被問道這方面的問題時(shí)，他的答案往往是我的目標(biāo)是建成企業(yè)的ERP系統(tǒng)，建設(shè)企業(yè)的信息化平臺(tái)等空洞的話。這樣的軟件怎么開發(fā)？連結(jié)束的標(biāo)準(zhǔn)都沒有。是費(fèi)用用完結(jié)束呢，還是決策者說停就停了呢。目標(biāo)應(yīng)該有一個(gè)可以量化的標(biāo)準(zhǔn)。例如，開發(fā)物流系統(tǒng)的目的是為了縮短產(chǎn)品周轉(zhuǎn)周期，降低庫存；開發(fā)供應(yīng)鏈系統(tǒng)是為了加強(qiáng)和供應(yīng)商的聯(lián)系，降低庫存。這些和具體業(yè)務(wù)有關(guān)的指標(biāo)都是可以通過細(xì)化，用多種分指標(biāo)來度量的，所以是可以做到的。
我們把這種目標(biāo)稱為測(cè)試就是要提醒開發(fā)人員，要把滿足這種目標(biāo)當(dāng)作最終的測(cè)試。你的軟件做得再好，不是涉眾想要的，又有什么用？這是很淺顯的道理，可是在實(shí)際中，涉眾方和開發(fā)方往往因?yàn)橐恍┚唧w的因素看不到這一點(diǎn)。其實(shí)，這個(gè)目標(biāo)在上一篇中我們也講過，那時(shí)我們是把它叫做愿景、范圍。在本質(zhì)上是一樣的。
這種"可執(zhí)行性目標(biāo)"可以使用一些因素來衡量：
7. 業(yè)務(wù)實(shí)體
業(yè)務(wù)實(shí)體（business entity）是企業(yè)中的一些起到關(guān)鍵作用的類別。客戶、供應(yīng)商、員工、訂單、憑證，這種業(yè)務(wù)實(shí)體的例子可以舉出很多很多。業(yè)務(wù)實(shí)體往往會(huì)成為一個(gè)很關(guān)鍵的因素，因?yàn)樵谙到y(tǒng)中，角色操作業(yè)務(wù)實(shí)體的行為往往會(huì)分配給業(yè)務(wù)實(shí)體，例如"根據(jù)訂單計(jì)算價(jià)格"會(huì)成為訂單的一個(gè)行為。這樣，工作流程的實(shí)現(xiàn)往往是多個(gè)業(yè)務(wù)實(shí)體相互合作完成的。所以業(yè)務(wù)實(shí)體設(shè)計(jì)的好壞會(huì)對(duì)系統(tǒng)有很大的影響作用。
業(yè)務(wù)實(shí)體設(shè)計(jì)的主要工作包括找出業(yè)務(wù)實(shí)體，確定業(yè)務(wù)實(shí)體的屬性和行為。
要確定業(yè)務(wù)實(shí)體，首先必須確定角色，并從角色的行為找出業(yè)務(wù)實(shí)體。角色需要我們對(duì)目標(biāo)組織進(jìn)行討論。以我個(gè)人的經(jīng)驗(yàn)，尋找業(yè)務(wù)角色一般比較簡單，但是要記住，一個(gè)人可能擔(dān)任好幾個(gè)的業(yè)務(wù)角色，這是經(jīng)常發(fā)生的情況。從業(yè)務(wù)角色的行為，我們可以找出業(yè)務(wù)角色所處理的事物，這些就是我們所需要的業(yè)務(wù)實(shí)體。業(yè)務(wù)實(shí)體是一個(gè)單獨(dú)的業(yè)務(wù)實(shí)體還是業(yè)務(wù)實(shí)體的一個(gè)屬性是值得研究的。一個(gè)本該是屬性的事物被判斷成業(yè)務(wù)實(shí)體只是會(huì)帶來一些開銷，可是一個(gè)本該單獨(dú)列出的業(yè)務(wù)實(shí)體卻只是被判定為其它業(yè)務(wù)實(shí)體的一個(gè)屬性就有可能會(huì)帶來災(zāi)難性的后果，最大的可能是系統(tǒng)難以擴(kuò)展。
在一個(gè)人力資源管理系統(tǒng)中，員工類可能是非常重要的一個(gè)業(yè)務(wù)實(shí)體，它可能有非常多的屬性。而在其它的系統(tǒng)中，例如進(jìn)銷存，員工類只是起到一個(gè)記錄、權(quán)限管理的作用罷了。再比如，在一些企業(yè)內(nèi)部的自動(dòng)化處理系統(tǒng)中，客戶可能只是其它一些實(shí)體的屬性，而以客戶為中心的設(shè)計(jì)大行其道的現(xiàn)在，這種設(shè)計(jì)就有它的致命缺陷。
要確定業(yè)務(wù)實(shí)體的屬性和行為，主要是要確定每個(gè)類（業(yè)務(wù)實(shí)體）要做的事情，屬性則是為了能夠更好的描述類和類要做的事情。利用CRC卡片是一個(gè)不錯(cuò)的辦法。
CRC是"類"（class），"責(zé)任"（responsibility）及"輔助者"（collaborator）三者的簡稱，這些資料常呈現(xiàn)在一張卡片上。
類名稱
責(zé)任1 責(zé)任1的輔助者1
責(zé)任2 責(zé)任2的輔助者2
… …
通過制作這樣的CRC卡片，可以比較容易的找出每個(gè)業(yè)務(wù)實(shí)體的行為（責(zé)任）和屬性（輔助者）。您可能會(huì)問，為什么不直接找出屬性和行為，而要多此一舉呢。這個(gè)問題是我們一直在強(qiáng)調(diào)的。在建模階段，我們面對(duì)的是可能對(duì)計(jì)算機(jī)技術(shù)完全不懂的涉眾，所以，采用大家易于接受的方法，可以夠保證需求的完整和正確。
8. 準(zhǔn)備計(jì)劃
目前在軟件開發(fā)中，關(guān)于計(jì)劃有兩個(gè)極端的誤解。
在有些軟件組織中，一般不做計(jì)劃，或是做一些籠統(tǒng)的、沒什么用處的計(jì)劃。一些開發(fā)人員認(rèn)為，"做計(jì)劃是虛的，還不如做些實(shí)際的事。"對(duì)于項(xiàng)目經(jīng)理，或是對(duì)這種情況沒有辦法，或是發(fā)布的計(jì)劃開發(fā)人員陽奉陰違，讓計(jì)劃成為一紙空文。項(xiàng)目執(zhí)行中隨意性極大，偏離方向的事情時(shí)有發(fā)生。
而在另外一些組織中，計(jì)劃被視為重中之重，需要花費(fèi)大量的時(shí)間、人力，做出來的計(jì)劃可謂事無巨細(xì)，算無遺策。而寫的出這種計(jì)劃的項(xiàng)目經(jīng)理也被視為高級(jí)人才。開發(fā)人員嘆口氣說，"寫程序的不如寫文檔的。"可是在執(zhí)行的時(shí)候，原來精密的計(jì)劃往往漏洞百出，項(xiàng)目的進(jìn)度一拖再拖。
我們所有人都知道那句明言：在軟件開發(fā)中，要花90%的時(shí)間完成90%的項(xiàng)目，然后再用90%的時(shí)間完成剩下的10%的項(xiàng)目。為什么呢？計(jì)劃不科學(xué)。
在管理學(xué)中，計(jì)劃，也有叫規(guī)劃的，定義是"為組織確定目標(biāo)、實(shí)現(xiàn)目標(biāo)的戰(zhàn)略與手段、步驟、程序的過程。"打個(gè)比方說，我想要把一個(gè)箱子推倒一個(gè)地方，這個(gè)地方就是我的目的，我為了到達(dá)那里，我是不是要估計(jì)一下按什么路線推，要推多快。然后我就開始推，還要不時(shí)的和原先的計(jì)劃比較比較，需不需要調(diào)整路線和速度。這個(gè)估計(jì)就是計(jì)劃。
計(jì)劃的目標(biāo)不是消除錯(cuò)誤，而是讓所有錯(cuò)誤變成一堆經(jīng)過細(xì)心規(guī)劃后的小錯(cuò)誤。研究四種設(shè)計(jì)方式后，最終放棄三種，最多不過是三個(gè)小錯(cuò)誤而已，但因沒有做好設(shè)計(jì)而將程序重寫三遍，卻可能造成三個(gè)大錯(cuò)誤。
然而為什么會(huì)出現(xiàn)上面提到的兩個(gè)極端呢？第一種情況其實(shí)是軟件行業(yè)最早期的一種形態(tài)，沒有計(jì)劃，資源分配混亂，軟件的開發(fā)過程處于混沌、無序、自發(fā)的狀態(tài)。項(xiàng)目的成功全憑運(yùn)氣和項(xiàng)目成員的個(gè)人能力。而第二種情況其實(shí)一個(gè)前進(jìn)了的形態(tài)，最典型的代表就是我們之前提到過的瀑布模型。那這種考慮周密的計(jì)劃為什么也容易失敗呢？很簡單，你認(rèn)為你考慮周密，可是實(shí)際上卻不一定。我就見過標(biāo)榜自己考慮周詳?shù)挠?jì)劃中排出的時(shí)間表是一周7天的。看來他一開始就沒打算讓開發(fā)人員休息了。計(jì)劃是對(duì)未來的一種估計(jì)，哪一個(gè)人能夠準(zhǔn)確的說出6個(gè)月后的情況，恐怕沒人能行吧。9月11號(hào)之前，有幾個(gè)人能料到那天會(huì)發(fā)生這么大的事情？那你憑什么推算出半年，甚至一年后的事情呢？另外，你是不是真的非常了解你的開發(fā)人員，以至于有信心代替他們制定計(jì)劃呢？
有人說，計(jì)劃沒有變化快。這句話說得很對(duì)，它提醒我們，沒有計(jì)劃是不行的，不具備可執(zhí)行性的計(jì)劃也是不行的。計(jì)劃不是拿來炫耀的，是要用來執(zhí)行的。我們定計(jì)劃的時(shí)候，可以沒有華麗的詞藻，美好的構(gòu)想。但是我們不能沒有一些要素：
·什么(WHAT)：按順序列出達(dá)到目標(biāo)所需完成的工作；
·何時(shí)(WHEN)：完成工作所需要的時(shí)間；
·做到的程度(HOW-WELL)：要完成的工作以何標(biāo)準(zhǔn)來度量；
·資源(RESOURCES)：完成工作需要的人員/資金等；
·誰(WHO)：由誰負(fù)責(zé)完成任務(wù)。
但是我們?nèi)匀惶硬婚_現(xiàn)實(shí)和計(jì)劃的背離的問題。我們雖然對(duì)預(yù)計(jì)一年后的事情把握不大，對(duì)把握開發(fā)人員在想什么把握也不大。但是如果你自己想想自己兩個(gè)星期后的事情應(yīng)該還是能夠猜的八九不離十吧。這就引出了迭代的概念。一個(gè)項(xiàng)目由幾個(gè)甚至幾十個(gè)的迭代周期組成，每個(gè)迭代周期都是比較容易估算并制定計(jì)劃的。這就是迭代的思想，也是軟件工程技術(shù)的一個(gè)大飛躍。說到這里，我又要吊大家的胃口了。關(guān)于具體制定迭代計(jì)劃的討論，我們會(huì)留到下一章節(jié)討論細(xì)節(jié)需求建模的時(shí)候再談。
9. 培訓(xùn)
我很難想象一個(gè)項(xiàng)目沒有培訓(xùn)該如何進(jìn)行。兵書有云，"三軍未動(dòng)，糧草先行。"我們可以理解為事先做好充分的準(zhǔn)備。項(xiàng)目也是一樣，在一開始就要指定好培訓(xùn)的計(jì)劃，留出培訓(xùn)的時(shí)間。我想，除非是一個(gè)非常完美的團(tuán)隊(duì)，否則他的成員一定也還是有不懂的東西吧，如果沒有培訓(xùn)計(jì)劃，把學(xué)習(xí)的任務(wù)推倒個(gè)人頭上，項(xiàng)目的風(fēng)險(xiǎn)就會(huì)變得難以控制。
說起培訓(xùn)，大家可能就會(huì)認(rèn)為是大家正兒八經(jīng)的坐在那里，聽一位老師上課。并不是這樣的，這里說的培訓(xùn)是一個(gè)廣義范圍的培訓(xùn)，達(dá)到一組課程、一次會(huì)議，小到一次討論、一次交流，都可以是培訓(xùn)。而其目的，就是為了讓團(tuán)隊(duì)成員擁有足夠的知識(shí)和技能，來完成項(xiàng)目。
?