軟件方法

核心工作流

?

1. 業務建模（組織建模）：描述組織內部各個系統如何協作，使得組織可以為其他的組織提供有價值的服務，新系統只不過是組織為了對外提供更好的服務，對自己的內部重新設計而購買的一個零件。
2. 需求：聚焦于待開發系統的邊界，消息描述系統要賣的出去必須具有的表現-功能和性能。
3. 分析：提煉系統內需要封裝到核心領域機制。
4. 設計：將核心領域知識和非核心領域知識結合，最終實現系統。

?

尋找老大

1. 老大是買方。
2. 系統改善哪個組織的流程，老大就是該組織的負責人。
3. 系統好壞的度量指標在他的大腦里嗎。
4. 如果國王之給你幾分鐘時間把正在做的系統賣出去，而且只有一次推銷的機會，如果失敗了就會被槍斃。您會向誰推銷？推銷的時候說什么話保住自己的性命可能性做大？這個答案就是老大和愿景。
5. 愿景是改善組織的指標，而不是做某事，要達到這個目標，需要各個崗位分別使用XXX，XXXX等功能。
6. 愿景不是問系統有什么功能，而是回答買了這個系統，對組織有什么好處。
7. 愿景是老大針對系統的目標
8. 用例使用“執行者Actor”和涉眾代替了原來的用戶，這是一個非常大的突破；
9. 計算機系統不只是簡單的把紙里的東西往電腦里般；

?

業務建模之業務用例圖

1. 業務建模的目的是從組織的角度來定位系統應該提供的價值，所以說“業務建模”應該更名為“組織建模”。
2. 業務執行者：BusinessActor。首先來尋找組織的執行者，也就是業務執行者，業務執行者的定義是：在組織之外和組織交互的人群或組織。（組織：某商業銀行； 業務執行者：儲戶（存錢）、企業（貸款）、人民銀行（監督））
3. 業務工人（Business Worker）：組織內的人肉系統，業務執行者和業務工人的區別就是，一個在組織內部，一個在組織里面，一個是組織不可替換的，一個是組織可以替換的。
4. 業務工人可能被新的業務工人替換，但更多的是可能被新的業務實體（BusinessEntity）替換，業務實體就是組織中的非人系統。
5. 開發人員說，“我在開發一個新系統”，其實是說“我在開發一個新的業務實體”，取代現有的業務工人或業務實體的一些責任。

?

探索需求的思路就出來了：

• 畫好現狀的業務序列圖
• 把待開發的系統作為一個新的業務實體空降到列圖中
• 尋找改進點，取得該業務實體的責任
• 直接映射到待開發系統的系統用例

?

業務工人和業務實體不再業務用例圖中出現，因為他們不是組織的價值，而是成本。在識別業務執行者時，不需要畫業務工人和業務實體，在接下來畫業務用例的實現-業務序列圖的時候加上就可以。

?

1. 業務工人和業務實體協作完成業務用例，系統類協作完成系統用例。
2. 業務執行者是一個組織（或人群），而不是系統。因為研究對象是組織，和它對應的概念也應該是組織。
3. 業務用例指業務執行者希望通過和組織交互達到，而且組織能提供的價值。
4. 業務用例是為業務執行者服務，不是為業務工人服務。或者說，因為無用例表達組織的本質價值。
5. 改進業務流程的思路：先歸納出組織對外提供什么價值，再思考如何更好地優化組織內部流程來實現這些價值。

?

總結

1. 業務用例是組織的、而不是組織內某個系統的用例。
2. 組織的用例不會因為某個人肉系統或者電腦系統的存在或消失而改變。所以，“這個系統的業務用例是什么”這樣的說法是錯誤的，業務用例圖，研究對象都是組織。
3. 為什么要研究組織的用例呢？因為我們想要把系統的價值和組織的價值掛上鉤，給組織一個購買系統的理由。也就是說，業務用例不是思考系統提供什么“功能”，而是思考組織購買了這個系統，對組織本來就是有哪些“功能”會帶來一點點幫助。

?

需求之系統用例圖

1. 系統執行者的定義：在所研究系統外，與該系統發生功能性交互的其他系統。
2. 系統用例的定義：系統能夠為執行者提供的、涉眾可以接受的價值。
3. 用例之前的許多需求方法學，把需求定義為思考系統“做”什么，用例把需求提升到思考系統“賣什么”的高度。
4. 做需求的目的不是為了安慰自己或走過場，而是讓產品更加好賣。不以這個為出發點的需求工作是沒有意義的。
5. 老老實實去研究業務流程，做好業務建模，盡量從業務序列圖中映射出系統用例，這樣得到的系統用例是不會騙人的。新增、修改、刪除、查詢、管理、改變狀態這樣的詞語是數據庫里面的“鳥語”，不是領域里面的“人話”。業務流程中不會有人說，小張你等一下，我要到系統哪里去做一下發票管理，只會說，我去開一張發票，我去作廢一張發票，我去開一張紅字發票。。。

?