軟體方法閱讀筆記（一）

標籤：

《軟體方法》講的是用UML語言來輔助我們進行軟體的從0到1的過程。這個過程的結果並不是最終運行在電腦螢幕上的那個介面，而是一堆圖紙，可視化的圖紙。
是的，確實是圖紙。建築行業有設計和施工圖紙，電工行業有設計和實施圖紙，城市規劃有圖紙··· ···任何你看得到的工程都有圖紙，你要寫的軟體居然沒有。
“圖紙在我腦子裡呢”，我也曾經說過。直到看到這本書。
這本書的直接受眾應該有兩類人：
1.程式員
這類人一般的工作思路就是提功能的人說要做什麼，嗯嗯哦哦之後，迫不及待的開啟編輯器開始寫代碼，調試，然後發現做完的東西，總是被告知要修改，沒玩沒了的改。
2.專案管理者
這類我們稱之為“IT包工頭”，他們既要跟客戶聊需求，轉頭還要跟程式員轉述。作為一個中間人，兩邊都要溝通，現實是兩邊都沒溝通好。使用者說的不就是這樣的嗎？怎麼做出來的東西就是不對呢！面對需求和變更，他們是最無奈的，因為他們面對的並不只是程式，而是公司的成本和效益。
我甚至推薦產品經理也來看看這本書，因為一個產品到底要滿足誰的需求，提供什麼樣的功能是一開始就要想清楚的事情。精益思想的逐步迭代改進是沒錯，但是也要求你在產品之初，能想明白你產品到底能帶來什麼樣實實在在的客戶價值。
很慶幸能在工作的第8個年能看到這本書，更榮幸的是，和自己的團隊在一起用了7個課時一起討論學習，一起做作業。最讓人興奮的，是每一次在進行項目討論的時候，我們都開始用《軟體方法》中學到的知識，用新的方法在做我們每天都該去的的事情：內部溝通更加有條理了；需求變更更加謹慎了，和客戶的溝通更加有效率了··· ···

讀完潘老師的這本大作，我的總體印象是：
概念不清，用詞不當，東拉西扯，邏輯錯亂。
全書中那些令人啼笑皆非的荒唐錯誤結論和缺陷主要有：
- 設計約束是需求，但既不是功能需求，也不是非功能需求（潘老師不懂最簡單的二元邏輯？）；
- 全書對於“涉眾”（Stakeholder）這個基本術語的理解幾乎通篇是錯誤的，而且前後矛盾；
- UML 模型不是用來和涉眾溝通的！（很難相信這是一位 UML 首席專家的言論）；
- 涉眾沒有資格、也沒有責任提供需求；
- 把 Actor 譯成“執行者”，導致許多違反中文常識的語病，如：人民銀行是商業銀行的執行者，患者是醫院的執行者；
- 系統 Actor 和重要無關，和重要有關的概念是涉眾；
- 觀眾（涉眾）在台下看，Actor 在台上表演（其實呢，台上的演員也是涉眾）；
- 需求或用例的“粒度”、“層次”這些概念其實並不存在，對開發人員的誤導相當嚴重；
- 設計就是代碼，所以設計工作流程不推薦畫 UML 圖；
- 介面組件不是需求。人有眼睛不是需求；
- 只用兩三章介紹了 UML 的使用案例圖和業務順序圖表，未強調商務活動圖，也未詳細介紹 UML 需求分析中常用到的其他圖形，如系統順序圖表、活動圖表、狀態圖等（內容單薄、片面）；
- 第 2 章所謂的“願景”，只是區區幾個“老大”或涉眾的目標，名曰“度量指標”，卻連一個數量也沒有說明，實質內容與願景文檔差距甚遠；
- 作為需求分析的名著，從第 3 章到第 6 章的重點章節只介紹了以用例為主的動態建模，未詳細介紹需求分析的另一半——靜態建模（如領域建模、概念建模）；

1-組織建模(業務建模): 記住你開發的系統只是要替換掉組織中的人工成本，所以建模的對象是組織而不是系統。
    關鍵步驟：
    1.確定建模組織：（組織的選取需要站在主要利益方和渉利群眾的角度考慮，勿草率選取公司這種大範圍的組織。對於互連網項目，應該選取項目的目標人群做組織。）畫一個圈，把大多數責任可能被（部分/全部）替換的系統（人肉系統/電腦系統...）包在裡邊。
    2.畫出組織（業務）使用案例圖和順序圖表：（從外部看，可以用業務使用案例圖表示組織。從內部看，可以用業務順序圖表表示組織。）
      研究組織的目的：把系統的價值和組織的價值掛上鉤，給組織一個購買系統的理由。
 1). 業務使用案例圖：
     a.確定業務執行者：尋找組織的執行者（業務執行者），在組織之外和組織互動的人。（業務執行者是一個組織或人群，而非系統。）
       思考方式：攝像機對準組織邊界，誰找組織辦事、誰發郵件給組織...等等，誰就有可能是業務執行者。
     b.確定業務工人和業務實體：業務工人是位於組織內部（業務執行者在組織外部）的人肉系統，即組織內的工人，而業務實體就是組織內部的非人工的系統。
       業務工人和業務實體是組織的成本而非價值，所以其不在業務使用案例圖中出現，而是放在“業務對象”的包裡。識別業務執行者時不需要畫業務工人和業務實體，在畫業務順序圖表時候加上即可。
            c.業務用例和商務程序：把商務程序看作是業務用例的實現，將其組織在業務用例下面。組織裡發生的一切都為了給業務執行者提供價值。
       識別業務用例：第一條路線，也是主要路線，方法是從業務執行者開始，思考業務執行和組織打交道的目的。思考的焦點是“執行者對組織的期望和組織對執行者的承諾”的平衡點。第二條路是通過觀察組織的內部活動，一直問為什麼，向外推到組織外部的某個業務執行者。
       主要執行者和次要執行者：執行者指向用例，這種執行者為主要執行者；用例指向執行者則為次要執行者。如：“出版社→推廣書籍→外部譯者”可以這樣解讀：為了給出版社提供推廣書籍的服務，組織靠自己的力量不足以完成，需要找外部譯者幫忙。
       注意：業務用例是組織為組織服務，在不同的情境中，兩個組織的系統形成不同的互動。業務用例是組織的，而不是組織內某個系統的用例。       

 2). 業務順序圖表：商務程序有三種描述方式：文本方式、商務活動圖方式、業務順序圖表方式。文本方式生動感欠佳不推薦，商務活動圖是主流方式，但推薦的是業務順序圖表。UML的互動概述圖是採用活動圖表的形式將各個情境的順序圖表串起來，相當於結合了活動圖表和順序圖表的特點。

軟體方法閱讀筆記（一）