所有的項目都有業務建模時期
1. 業務建模是什么
業務建模（Business Modeling），業務建模是一個復雜的過程，對其下一個準確的定義是困難的事情。在RUP的詞匯表中將其解釋為：
"包含您可用來對業務進行可視化建模的所有建模方法。這些是您可用于執行業務工程的方法的子集。"
從定義中可以看出，它是一種建模方法的集合，目的是對業務進行建模。這方面的工作可能包括了對業務流程建模，對業務組織建模，改進業務流程，領域建模等方面。 2. 為什么要業務建模
Brooks 大師說，三十多年來各式各樣的應用系統（Application Programs AP）歷經多次的修修改改，已經變得面目全非，如同一群的怪獸，難以馴服。
Rogerson大師也說，The application is a rock in the river of change.（應用（系統）成為改變之潮流中的頑石）。
對很多企業而言，有一個統合企業各部門的信息系統的心愿似乎已經成了一種奢望。企業中或多或少都會有一些應用系統在輔助企業的自動化運作，當企業信息主管希望能夠對目前的信息系統進行整合，能夠配合企業的發展的時候，他們失望了。大多數的應用缺乏一個統一的接口，難以進行整合。 在我們進行項目開發的銀行中，我們也同樣發現了這個問題，不同部門的系統之間無法進行互聯，跨部門的業務流程必須經過手工的處理。
以前，應用程序的開發都是基于部門的功能的而建的。單純只是為了解決目的而建立應用系統。所以這種方式建立的應用系統是針對特定的功能區域（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）
3. 需求和業務建模
業務建模是需求工程中最初始的階段，也是整個項目的初始階段。需要指出的是，業務建模時間的跨度在不同的項目中有很大的差別的。在有些項目中，例如大型ERP系統，可能需要幾個月的時間。而對于普通的項目，業務建模的時間可能僅僅需要幾天的時間。
需求是技術無關（technology independent）的。在需求階段討論技術是沒有任何意義的。那只會讓你的注意力分散。技術的實現細節是在后面的分析、設計階段才需要考慮的事情。而在業務建模階段，不但要保證需求的技術無關性，還要保證你的需求不要深入細節。因為在業務建模階段，最重要的事情就是要了解業務的全貌，深入細節會浪費時間和精力。要知道，討論一個企業里的業務細節，就算給你一個月的時間也沒必能夠結束。 在實際中，這兩點都是很難做到的。例如企業原先有一個系統，這就不得不由你討論和新舊系統的兼容問題。這時候就要注意，如果你是討論就有系統的架構的話，那還是屬于技術無關的范疇，如果你一旦進而討論各具體模塊/組件的細節，那就非但不是技術無關，而且也深入細節了。在不深入細節的問題上，往往你很難禁止項目涉眾（Stakeholder）①不去討論一些相關的業務細節。這個時候你可以將這些細節記錄下來，然后再回到業務建模上。
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉眾是所有會受到項目結果重大影響的人。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
