UML軟體方法大綱

 利潤=需求-設計

缺乏清晰、共用的願景往往是項目失敗的主要原因。

願景回答這樣一個問題:在老大看來,引進這個系統的目的是什麼? 

尋找老大：

• 要點:老大是買方。典型錯誤:老大就是我們開發公司老總(或者研發總監、產品經理等)。 
• 要點:系統改善哪個組織的流程?老大就是該組織的負責人。典型錯誤:老大是××局信息中心主任李××。 
• 要點:系統好壞的度量指標藏在他的大腦里嗎?典型錯誤:老大是某位大領導(可能是集團董事長,也可能是省長,甚至是總理)。 

可度量的目標：

揣摩目標度量：老大心底裡是有度量指標的,否則,系統擺在他面前的時候,他拿什麼來判斷系統好不好?不過, 要得到度量指標不容易。  

涉眾利益 :願景是老大針對系統的目標,那其他人的目標難道不重要嗎?其他人的目標也是要關註的,我們 把它叫做涉眾利益。願景實際上就是系統最重要涉眾的利益。  

業務建模——描述組織內部各系統(人肉系統、機械繫統、電腦系統......)如何協作,使得組 織可以為其他組織提供有價值的服務。新系統只不過是組織為了對外提供更好的服務,對自己的內部 重新設計而購買的一個零件。組織引進一個軟體系統,和招聘一名新員工沒有本質區別。如果能學會 通過業務建模去推導新系統的需求,而不是拍腦袋得出需求,假的“需求變更”會大大減少 

業務用例圖：軟體是組織的零件

【業務建模步驟 1-1】:選定要改進的組織 

【業務建模步驟 1-2】:組織的業務用例圖 

• 業務執行者
• 業務工人和業務實體
• 識別業務執行者
• 業務用例 

業務序列圖：描述業務流程的手段

業務序列圖要點 ：

• 消息代表責任分配而不是數據流動
• 聚焦於系統之間的協作
• 只畫核心域相關的系統
• 把時間看作特殊的業務實體 

【業務建模步驟 1-3】:現狀業務序列圖

• 錯誤:把“現狀”誤解為“純手工”
• 錯誤:把“現狀”誤解為“規範” 
• 錯誤:以待開發系統為中心拼湊流程 

【業務建模步驟 1-4】:改進業務序列圖 

• 改進一:物流變成信息流
• 改進二:改善信息流轉
• 改進三:封裝領域邏輯
• 阿布思考法：(1)假設有充足的資源去解決問題,得到一個完美的方案;(2)用手上現有的資源去山寨這個完美方案。 

 需求——聚焦於待開發系統的邊界,詳細描述系統要賣得出去必須具有的表現——功能和性能。 這項技能的意義在於強迫我們從“賣”的角度思考哪些是涉眾(Stakeholder)在意的、不能改變的契 約,哪些不是,嚴防“做”污染“賣”。需求工作流的結果——需求規約是“賣”和“做”的銜接點 

需求-系統用例圖：

系統執行者要點：在所研究系統外,與該系統發生功能性交互的其他系統。

系統用例要點 ：系統能夠為執行者提供的、涉眾可以接受的價值。  

【需求步驟 2-1】識別系統執行者 

• 不要把執行者和許可權管理混淆 

【需求步驟 2-2】識別系統用例 

• 錯誤:玩弄“復用” 
• 錯誤:玩弄“層次” 
• 錯誤:玩弄“子系統”
• 錯誤:模糊的價值
• 提示:大用例無妨小用例
• 提示:用例的命名 （動賓結構）

需求-系統用例規約

【需求步驟 2-3】書寫系統用例規約 

需求-需求啟發 

分析——提煉系統內需要封裝的核心領域機制。可運行的系統需要封裝各個領域的知識,其中 只有一個領域(核心域)的知識是系統能在市場上生存的理由。對核心域作研究,可以幫助我們獲得 基於核心域的復用 

設計——將核心域知識和非核心域知識結合,最終實現系統。說“代碼就是設計”指的是這裡 說的“設計”。代碼確實是設計,但代碼不是分析,不是需求,不是業務建模。