要確定業務實體，首先必須確定角色，并從角色的行為找出業務實體。角色需要我們對目標組織進行討論。以我個人的經驗，尋找業務角色一般比較簡單，但是要記住，一個人可能擔任好幾個的業務角色，這是經常發生的情況。從業務角色的行為，我們可以找出業務角色所處理的事物，這些就是我們所需要的業務實體。業務實體是一個單獨的業務實體還是業務實體的一個屬性是值得研究的。一個本該是屬性的事物被判斷成業務實體只是會帶來一些開銷，可是一個本該單獨列出的業務實體卻只是被判定為其它業務實體的一個屬性就有可能會帶來災難性的后果，最大的可能是系統難以擴展。
在一個人力資源管理系統中，員工類可能是非常重要的一個業務實體，它可能有非常多的屬性。而在其它的系統中，例如進銷存，員工類只是起到一個記錄、權限管理的作用罷了。再比如，在一些企業內部的自動化處理系統中，客戶可能只是其它一些實體的屬性，而以客戶為中心的設計大行其道的現在，這種設計就有它的致命缺陷。
要確定業務實體的屬性和行為，主要是要確定每個類（業務實體）要做的事情，屬性則是為了能夠更好的描述類和類要做的事情。利用CRC卡片是一個不錯的辦法。
CRC是"類"（class），"責任"（responsibility）及"輔助者"（collaborator）三者的簡稱，這些資料常呈現在一張卡片上。
類名稱
責任1 責任1的輔助者1
責任2 責任2的輔助者2
… …
通過制作這樣的CRC卡片，可以比較容易的找出每個業務實體的行為（責任）和屬性（輔助者）。您可能會問，為什么不直接找出屬性和行為，而要多此一舉呢。這個問題是我們一直在強調的。在建模階段，我們面對的是可能對計算機技術完全不懂的涉眾，所以，采用大家易于接受的方法，可以夠保證需求的完整和正確。 8. 準備計劃
目前在軟件開發中，關于計劃有兩個極端的誤解。
在有些軟件組織中，一般不做計劃，或是做一些籠統的、沒什么用處的計劃。一些開發人員認為，"做計劃是虛的，還不如做些實際的事。"對于項目經理，或是對這種情況沒有辦法，或是發布的計劃開發人員陽奉陰違，讓計劃成為一紙空文。項目執行中隨意性極大，偏離方向的事情時有發生。
而在另外一些組織中，計劃被視為重中之重，需要花費大量的時間、人力，做出來的計劃可謂事無巨細，算無遺策。而寫的出這種計劃的項目經理也被視為高級人才。開發人員嘆口氣說，"寫程序的不如寫文檔的。"可是在執行的時候，原來精密的計劃往往漏洞百出，項目的進度一拖再拖。
我們所有人都知道那句明言：在軟件開發中，要花90%的時間完成90%的項目，然后再用90%的時間完成剩下的10%的項目。為什么呢？計劃不科學。
在管理學中，計劃，也有叫規劃的，定義是"為組織確定目標、實現目標的戰略與手段、步驟、程序的過程。"打個比方說，我想要把一個箱子推倒一個地方，這個地方就是我的目的，我為了到達那里，我是不是要估計一下按什么路線推，要推多快。然后我就開始推，還要不時的和原先的計劃比較比較，需不需要調整路線和速度。這個估計就是計劃。
計劃的目標不是消除錯誤，而是讓所有錯誤變成一堆經過細心規劃后的小錯誤。研究四種設計方式后，最終放棄三種，最多不過是三個小錯誤而已，但因沒有做好設計而將程序重寫三遍，卻可能造成三個大錯誤。
然而為什么會出現上面提到的兩個極端呢？第一種情況其實是軟件行業最早期的一種形態，沒有計劃，資源分配混亂，軟件的開發過程處于混沌、無序、自發的狀態。項目的成功全憑運氣和項目成員的個人能力。而第二種情況其實一個前進了的形態，最典型的代表就是我們之前提到過的瀑布模型。那這種考慮周密的計劃為什么也容易失敗呢？很簡單，你認為你考慮周密，可是實際上卻不一定。我就見過標榜自己考慮周詳的計劃中排出的時間表是一周7天的�？磥硭婚_始就沒打算讓開發人員休息了。計劃是對未來的一種估計，哪一個人能夠準確的說出6個月后的情況，恐怕沒人能行吧。9月11號之前，有幾個人能料到那天會發生這么大的事情？那你憑什么推算出半年，甚至一年后的事情呢？另外，你是不是真的非常了解你的開發人員，以至于有信心代替他們制定計劃呢？
有人說，計劃沒有變化快。這句話說得很對，它提醒我們，沒有計劃是不行的，不具備可執行性的計劃也是不行的。計劃不是拿來炫耀的，是要用來執行的。我們定計劃的時候，可以沒有華麗的詞藻，美好的構想。但是我們不能沒有一些要素：
什么(WHAT)：按順序列出達到目標所需完成的工作；
何時(WHEN)：完成工作所需要的時間；
做到的程度(HOW-WELL)：要完成的工作以何標準來度量；
資源(RESOURCES)：完成工作需要的人員/資金等；
誰(WHO)：由誰負責完成任務。
但是我們仍然逃不開現實和計劃的背離的問題。我們雖然對預計一年后的事情把握不大，對把握開發人員在想什么把握也不大。但是如果你自己想想自己兩個星期后的事情應該還是能夠猜的八九不離十吧。這就引出了迭代的概念。一個項目由幾個甚至幾十個的迭代周期組成，每個迭代周期都是比較容易估算并制定計劃的。這就是迭代的思想，也是軟件工程技術的一個大飛躍。說到這里，我又要吊大家的胃口了。關于具體制定迭代計劃的討論，我們會留到下一章節討論細節需求建模的時候再談。
9. 培訓
我很難想象一個項目沒有培訓該如何進行。兵書有云，"三軍未動，糧草先行。"我們可以理解為事先做好充分的準備。項目也是一樣，在一開始就要指定好培訓的計劃，留出培訓的時間。我想，除非是一個非常完美的團隊，否則他的成員一定也還是有不懂的東西吧，如果沒有培訓計劃，把學習的任務推倒個人頭上，項目的風險就會變得難以控制。 說起培訓，大家可能就會認為是大家正兒八經的坐在那里，聽一位老師上課。并不是這樣的，這里說的培訓是一個廣義范圍的培訓，達到一組課程、一次會議，小到一次討論、一次交流，都可以是培訓。而其目的，就是為了讓團隊成員擁有足夠的知識和技能，來完成項目。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
