圖 2 采用全程建模方法描述的分工組成結構可以
細化到原子級工作步驟
圖 3是采用UML的Use Case 圖來描述組織結構，它只能描述到崗位職責，對崗位職責中的工作步驟無法描述。對業務的描述粗枝大葉，結果需求也是粗枝大葉，但用戶往往不知道需要特別重視這一點，更不知道這種粗枝大葉會給項目帶來災難。這是糾纏不清的胡子工程問題點之一。
圖 3 采用UML描述的分工組成結構至多只能描述到職責級
2 UML難以從宏觀把控業務流程的完整與準確
圖 4是用全程建模方法順序圖描述的業務協作流程——“采購”，它將業務事件序列與業務活動有機地集成在一個圖形中，用戶可以直觀地判斷軟件開發人員描述的業務流程是否正確、完整。
圖 4 采用全程建模方法的順序圖描述業務協作流程
圖 5與圖 6分別用UML順序圖和活動圖描述的業務協作流程——“采購”，問題其一是用戶需要左一眼、右一眼、上一眼、下一眼地對照兩張圖，費時費力，檢查兩種圖時在所難免地會出現遺漏、不一致；問題其二是UML順序圖缺少條件分支的表達方法，表達內容不完整；問題其三是UML順序圖和活動圖從形式上到內容上不存在等價關系。
使用UML描述業務流程很難讓人放心，因為描述業務流程時產生的遺漏、不一致、不完整，同樣會給項目帶來災難。這是糾纏不清的胡子工程問題點之二。
3 UML無法從微觀把控業務信息的操作過程
圖 7從微觀上用全程建模方法PAD圖描述了職責細化流程——庫管員如何“入庫”，它不僅描述了崗位職責展開的具體邏輯步驟，同時也描述了如何對業務信息進行操作，如對“入庫單”的 “實際入庫數量、入庫日期”等欄目進行填寫操作，對“入庫單”的 “商品規格、采購數量”等欄目及“采購計劃”的等“商品規格、計劃采購數量”等欄目進行讀取操作。
圖 7 采用全程建模方法的PAD圖描述的職責細化流程
UML根本無法從微觀上描述業務信息的操作過程，只能等到編程時再由有經驗、責任心強的程序員去了解，這無疑于邊蓋樓邊考慮在哪里開窗戶，最后各種問題盤根錯節，摁倒葫蘆起了瓢。軟件公司練就了不少救火高手，但不容否認的是充滿了救火隊員項目常常意味著滅頂之災。這是糾纏不清的胡子工程問題點之三。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
