本節(jié)和大家學(xué)習(xí)一下UML及項目管理建模，建模有用例建模，結(jié)構(gòu)建模，行為建模，軟件系統(tǒng)體系架構(gòu)建模。下面就讓我們一起來看一下UML及項目管理建模的詳細(xì)介紹吧。

UML及項目管理建模學(xué)習(xí)心得

總算學(xué)完一個學(xué)期的UML建模，自覺也學(xué)的不大好，老師講的也快，用的是經(jīng)典的《UML模式與應(yīng)用》一書，所以打算暑假花點時間再次邊研究邊總結(jié)，并且打算結(jié)合項目管理的課程，一邊復(fù)習(xí)一邊寫點心得，每次都打算以最簡單的進(jìn)行概括。

首先想談下的是需求分析過程。其實這應(yīng)該理解為兩個過程：1需求的獲取2、需求的分析。這兩部十分重要的，需求的獲取，往往不受到重視，特別是國內(nèi)目前的情況，項目工期緊，公司往往想方設(shè)法先把項目拿下來，然后就拿自己公司以往做過的項目做藍(lán)本，然后再根據(jù)顧客的需求改動，再次開發(fā)，測試，交付就完工了。但如果需求的獲取，做不好，往往對后面的步驟流程造成很大的影響，造成太多的改動和損失。所以，在需求獲取階段，應(yīng)該做好如下幾點：

1、盡可能在需求的獲取階段有行業(yè)專家或行業(yè)專門人員提供咨詢和參與，往往在大型項目中，適當(dāng)在這方面予以投資，產(chǎn)出比是很高的（當(dāng)然，目前大多數(shù)企業(yè)很難做到，但建議十分大的項目的話，起碼要找熟悉的行業(yè)人員做個幫手，呵呵）

2、UML及項目管理建模時設(shè)法得到用戶的協(xié)同和認(rèn)可，特別要盡量得到用戶方高層的認(rèn)可。目前很多企業(yè)外包系統(tǒng)開發(fā)，特別是一些國家單位，事業(yè)單位和企業(yè)，都有這樣的意識：認(rèn)為項目一旦簽了出去，事情就讓公司開發(fā)去了，自己省了很多事，因此態(tài)度在需求分析階段不是那么好，高高在上的態(tài)度，認(rèn)為開發(fā)方老是去煩著他們，浪費他們的時間（要知道，不是所有用戶的公司都有負(fù)責(zé)IT的專業(yè)人員的，很多都是業(yè)務(wù)部門拍拍腦袋說了算），這個時候要怎么辦？這時候，應(yīng)將公關(guān)的重點放在與用戶的溝通上，開發(fā)方要以充分的證據(jù)，最好以成功，失敗的案例（無的話呢，編也要編出來給用戶知道，一定要充分和開發(fā)方進(jìn)行很好的配合。之前我在一個監(jiān)理項目中，就建議開發(fā)方這樣做，因為當(dāng)時甲方是大型的國家單位，高高在上，也有高級IT人員，領(lǐng)導(dǎo)整天忙，流程也不好，一開始態(tài)度也一般，所以后來開發(fā)方在項目的一個有領(lǐng)導(dǎo)參與的大會上，通過PPT演示和講解了用戶方和開發(fā)方配合的重要性，果然引起了領(lǐng)導(dǎo)的重視，為后來項目的成功打下很好的基礎(chǔ)。記住，要通過案例的形式來讓用戶特別是用戶的領(lǐng)導(dǎo)充分意識到：用戶領(lǐng)導(dǎo)重視的重要性。

3與客戶的需求調(diào)研時，要以客戶為中心，要選擇好和用戶溝通的語言。很多人喜歡在調(diào)研后，畫出UML用例圖給用戶看，我覺得這是不恰當(dāng)?shù)?。試想，用戶的領(lǐng)導(dǎo)，一般業(yè)務(wù)人員，有多少會看UML圖呢？所以，UML及項目管理建模在調(diào)研后，給用戶看的應(yīng)該：

A業(yè)務(wù)流程圖
B對業(yè)務(wù)流程圖的文字闡述
C用戶方原有系統(tǒng)（組織）的架構(gòu)圖
D用圖表，表格等形式對用戶需求的調(diào)研反映

因為從心理學(xué)上看，以上四點，最能符合用戶的心理習(xí)慣，不容易給用戶抗拒，用戶十分熟悉，一看就明白，溝通起來自然得心應(yīng)手。

4、在確定每個需求后，要用戶和開發(fā)方簽名確認(rèn)。很多用戶不喜歡這樣做？怎么辦？這個時候，公關(guān)要出動了！要讓用戶知道，只有雙方都同意了，對大家雙方都有好處，開發(fā)方可以加快進(jìn)度，完成高質(zhì)量的產(chǎn)品，用戶方在思考一定時間后的確認(rèn)，則保證了項目的健康發(fā)展。

5、在每次調(diào)研時，要注意筆記和錄音，起碼兩人，一人詢問，一人記錄

6、每次調(diào)研需求后，將需求分類別，分為最容易實現(xiàn)的需求，可以實現(xiàn)的需求，需要較長時間才能實現(xiàn)的需求，目前不可能實現(xiàn)的需求，該項目不可能實現(xiàn)的需求，對需求運用需求管理工具進(jìn)行分類管理，然后下次展示給用戶看。要注意一點的是：不要單獨在一次會議上向用戶大吐苦水，說哪些哪些需求是實現(xiàn)不了的（即使用戶很多不要的要求甚至無理的要求），要以列表的形式，象上文所的那樣，列出哪些是用戶好的需求（甚至要贊揚用戶的需求提的好，讓用戶樂一下，呵呵），哪些是本公司一定能實現(xiàn)的，哪些是目前暫時不能實現(xiàn)的，哪些是有可能實現(xiàn)不了的。如果用戶很多無理要求，也不要一次全盤說出來，以免引起用戶的反感，盡量分幾次說出來，每次都讓用戶覺得，開發(fā)方能最大限度滿足用戶的需求，這樣，用戶從心理上就不會那么抗拒了，即使用戶提出了不合理的要求。這樣的辦法，可以很好地拒絕用戶不合理的要求，水到渠成，不會讓用戶懷疑開發(fā)方的能力，大家都高興。

以上是需求調(diào)研階段要注意的一些東西。本節(jié)關(guān)于UML及項目管理建模的內(nèi)容就簡單介紹到這里。
 

【編輯推薦】

1. UML統(tǒng)一建模語言的主要特點和應(yīng)用領(lǐng)域解析
2. 統(tǒng)一建模語言UML概念和功能簡介
3. 九大UML建模誤區(qū)如何避免
4. 解析UML類圖符號意義
5. 九大UML視圖專家解析