案例研討-關於客戶單位維修作業流程的系統分析

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

這是月初的授課—「系統需求分析與整理」,其中一位上課學員拿他們的實際案例提供參考的。

先來瞧瞧這張看似很複雜的作業流程圖,主要是要描述當客戶單位提出報修需求時,維修單位的報價與維修的相關作業活動。

圖、原稿—客戶維修報價作業流程

圖、原稿—客戶維修報價作業流程

這是一張典型 SA 所繪製的業務流程 (business process)圖,是否使用 UML 語法來表示,那並不重要。最主要的問題是,大多單位往往都認為這類業務流程的表達,必須要描述得很「精確」,才可以轉移到實作的階段。所以為了要能取得「精確」的結果,就需要不斷地開會與確認 (還含時常爭執各據的論點),秏上個把個月才能有產出,然後再轉移到實作階段。

但是無論再如何精細,我發現到有一個相當有趣的現象,在這類環境下的 Programmer,往往都還是覺得不夠精細。

越是想表達得精確,Programmer 越會嫌不夠精確!

這就是典型的瀑布式 (waterfall)系統分析。這類所謂「精確」的業務流程圖,耗費太多在需求分析的時間,且由於描述了太多細節,反而讓實作寫碼不容易抓到適切的焦點,因而導致 Programmer 不知道如何寫出較具「彈性」可包容變動細節的程式碼,當然相對日久也就會把不精確的細節當成是一種無法 Coding 的藉口。

所以,上述如此好像「鉅細靡遺」的設計圖,主要的問題在哪裡? 其實簡單的說,它早已違背了軟體設計至高無上的原則—封裝 (encapsulation)。

  • 把資料細節呈現出來 (資料導向的思維)。
  • 設計圖內描述了企業邏輯 (business logic)。
  • 過早把資訊系統角色帶入。


先前針對上圖幾個問題,個人以前就發表過:「大業務流程塑模的MSS三層次原則」。簡而言之,設計圖要能:

  • 讓設計表現簡潔易讀並易於調整修正。
  • 具有層次感,每一個層級適時表現出焦點。

好的設計與呈現,是要能包容會變化的「細節」。不是一開始就要做精,而是懂得如何掌握可以獨立持續開發與實作的目標框架,以此為主軸,逐漸地往精確度收斂,卻又可以包容「善變的細節—欄位資訊與業務邏輯」。

這裡仍是以個人所發表的「MSS (Multiple/Single Process, System Functions」塑模三層次,就從多個作業流程的表達—利用火箭圖,以及單一作業流程的活動 (activity)這兩個層次,並以 UML 語法來重整原稿。至於系統功能的使用案例圖 (use case diagram),先略過未提。如何從單一作業流程的活動圖,以此為引導轉為資訊系統的使用案例模型,可以參考個人另一篇文:「從企業流程(活動)圖找出資訊系統的使用案例」。

第一層:火箭圖

原稿的作業流程看似很複雜? 但過濾掉資料與業務邏輯後,其實作業活動相當單純,也只有三類的作業流程而已:報修、報價、維修 作業流程。

圖、重整後的活箭圖—客戶維修報價作業流程 Overview

圖、重整後的活箭圖—客戶維修報價作業流程 Overview

從上述火箭圖主要是要表達有幾個作業流程、它們之間的主要輸入—輸出的關係為何。還有更重要的是,突顯出各自作業流程所要達成的目標 (goal)與價值 (value)為何。

第二層:活動圖

每一個作業流程,當然有各自細部的作業活動,這時就是利用「封裝」的觀念,把相對各自流程的活動表達在下一個相對細部的層級。下列三張為利用 UML 活動圖 (activity diagram)所繪製而成。

圖、重整—報修作業流程活動圖

圖、重整—報修作業流程活動圖

圖、重整—報價作業流程活動圖

圖、重整—報價作業流程活動圖

圖、重整—維修作業流程活動圖

圖、重整—維修作業流程活動圖

每一個作業流程的內部活動有各自要表達的操作目的,彼此之間只透過起點 (entry point)與終點 (end point)的事件啟始與產出 (artifacts)來關聯,但每一個作業流程的活動均有著各自的獨立與單一性 (atomic),所以才得以各自維護與延展功能活動,焦點也相對明確許多。

一直重複提醒的問題,活動圖當然是以「活動 (activity)」為主體,而表單資料則是被「封裝」在各自的活動細節內部。同理,業務邏輯當然也是與資料同時被「封裝」在各自所屬的活動內部。不要再把資料當成活動主體,那是導致業務流程圖紊亂的元兇!

再則一個重點再次的提醒,作業流程圖的活動係以「人本」的角度來看來人工作業的流程,此時最好也不要「資訊系統」這個角色放進來。因為,「系統」這個字眼其實沒有想像得簡單,SA 往往都是把「功能模組」看待為單一系統,因而導致流程活動內有好幾個所謂的「系統」參與,這樣錯誤的解讀當然會造成未來實作的謬誤。

簡而言之,SA 不要也不應該自作主張把「系統」加入作業流程活動內;單純一些,僅以「人本」的角度來表達作業活動,不用管是否這些活動是否未來需要資訊系統的參與,如此反而可以讓活動圖很單純。

總之,系統的定義,應是團隊基於「架構 (architecture)」整體性的考量來決定出來的。當決定了系統的開發/維護範圍 (boundary)後,SA 即可以以此作為界限,來找出該系統應實現 (realize)的系統功能(system functions)了。如此第三個層級—資訊系統所提供的功能表達,如利用使用案例模型 (use case model),就更能進一步清晰明確地表達出來;利用這個層級所分析出的系統功能,更易於橋接到實作寫碼的階段,反之也相對易於調整與維護。

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *