軟件方法

核心工做流

 

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. 老老實實去研究業務流程，作好業務建模，儘可能從業務序列圖中映射出系統用例，這樣獲得的系統用例是不會騙人的。新增、修改、刪除、查詢、管理、改變狀態這樣的詞語是數據庫裏面的「鳥語」，不是領域裏面的「人話」。業務流程中不會有人說，小張你等一下，我要到系統哪裏去作一下發票管理，只會說，我去開一張發票，我去做廢一張發票，我去開一張紅字發票。。。