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

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

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

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

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

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

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

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

因?yàn)閺男睦韺W(xué)上看，以上四點(diǎn)，最能符合用戶的心理習(xí)慣，不容易給用戶抗拒，用戶十分熟悉，一看就明白，溝通起來(lái)自然得心應(yīng)手。

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

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

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

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

【編輯推薦】

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