UML及項目管理建模解析
本節(jié)和大家學習一下UML及項目管理建模，建模有用例建模，結構建模，行為建模，軟件系統體系架構建模。下面就讓我們一起來看一下UML及項目管理建模的詳細介紹吧。
UML及項目管理建模學習心得
總算學完一個學期的UML建模，自覺也學的不大好，老師講的也快，用的是經典的《UML模式與應用》一書，所以打算暑假花點時間再次邊研究邊總結，并且打算結合項目管理的課程，一邊復習一邊寫點心得，每次都打算以最簡單的進行概括。
首先想談下的是需求分析過程。其實這應該理解為兩個過程：1需求的獲取2、需求的分析。這兩部十分重要的，需求的獲取，往往不受到重視，特別是國內目前的情況，項目工期緊，公司往往想方設法先把項目拿下來，然后就拿自己公司以往做過的項目做藍本，然后再根據顧客的需求改動，再次開發(fā)，測試，交付就完工了。但如果需求的獲取，做不好，往往對后面的步驟流程造成很大的影響，造成太多的改動和損失。所以，在需求獲取階段，應該做好如下幾點：
1、盡可能在需求的獲取階段有行業(yè)專家或行業(yè)專門人員提供咨詢和參與，往往在大型項目中，適當在這方面予以投資，產出比是很高的（當然，目前大多數企業(yè)很難做到，但建議十分大的項目的話，起碼要找熟悉的行業(yè)人員做個幫手，呵呵）
2、UML及項目管理建模時設法得到用戶的協同和認可，特別要盡量得到用戶方高層的認可。目前很多企業(yè)外包系統開發(fā)，特別是一些國家單位，事業(yè)單位和企業(yè)，都有這樣的意識：認為項目一旦簽了出去，事情就讓公司開發(fā)去了，自己省了很多事，因此態(tài)度在需求分析階段不是那么好，高高在上的態(tài)度，認為開發(fā)方老是去煩著他們，浪費他們的時間（要知道，不是所有用戶的公司都有負責IT的專業(yè)人員的，很多都是業(yè)務部門拍拍腦袋說了算），這個時候要怎么辦？這時候，應將公關的重點放在與用戶的溝通上，開發(fā)方要以充分的證據，最好以成功，失敗的案例（無的話呢，編也要編出來給用戶知道，一定要充分和開發(fā)方進行很好的配合。之前我在一個監(jiān)理項目中，就建議開發(fā)方這樣做，因為當時甲方是大型的國家單位，高高在上，也有高級IT人員，領導整天忙，流程也不好，一開始態(tài)度也一般，所以后來開發(fā)方在項目的一個有領導參與的大會上，通過PPT演示和講解了用戶方和開發(fā)方配合的重要性，果然引起了領導的重視，為后來項目的成功打下很好的基礎。記住，要通過案例的形式來讓用戶特別是用戶的領導充分意識到：用戶領導重視的重要性。
3與客戶的需求調研時，要以客戶為中心，要選擇好和用戶溝通的語言。很多人喜歡在調研后，畫出UML用例圖給用戶看，我覺得這是不恰當的。試想，用戶的領導，一般業(yè)務人員，有多少會看UML圖呢？所以，UML及項目管理建模在調研后，給用戶看的應該：
A業(yè)務流程圖
B對業(yè)務流程圖的文字闡述
C用戶方原有系統（組織）的架構圖
D用圖表，表格等形式對用戶需求的調研反映
因為從心理學上看，以上四點，最能符合用戶的心理習慣，不容易給用戶抗拒，用戶十分熟悉，一看就明白，溝通起來自然得心應手。
4、在確定每個需求后，要用戶和開發(fā)方簽名確認。很多用戶不喜歡這樣做？怎么辦？這個時候，公關要出動了！要讓用戶知道，只有雙方都同意了，對大家雙方都有好處，開發(fā)方可以加快進度，完成高質量的產品，用戶方在思考一定時間后的確認，則保證了項目的健康發(fā)展。
5、在每次調研時，要注意筆記和錄音，起碼兩人，一人詢問，一人記錄
6、每次調研需求后，將需求分類別，分為最容易實現的需求，可以實現的需求，需要較長時間才能實現的需求，目前不可能實現的需求，該項目不可能實現的需求，對需求運用需求管理工具進行分類管理，然后下次展示給用戶看。要注意一點的是：不要單獨在一次會議上向用戶大吐苦水，說哪些哪些需求是實現不了的（即使用戶很多不要的要求甚至無理的要求），要以列表的形式，象上文所的那樣，列出哪些是用戶好的需求（甚至要贊揚用戶的需求提的好，讓用戶樂一下，呵呵），哪些是本公司一定能實現的，哪些是目前暫時不能實現的，哪些是有可能實現不了的。如果用戶很多無理要求，也不要一次全盤說出來，以免引起用戶的反感，盡量分幾次說出來，每次都讓用戶覺得，開發(fā)方能最大限度滿足用戶的需求，這樣，用戶從心理上就不會那么抗拒了，即使用戶提出了不合理的要求。這樣的辦法，可以很好地拒絕用戶不合理的要求，水到渠成，不會讓用戶懷疑開發(fā)方的能力，大家都高興。
以上是需求調研階段要注意的一些東西。本節(jié)關于UML及項目管理建模的內容就簡單介紹到這里。
【編輯推薦】
