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