「軟體需求分析與塑模」- 企業層級系統塑模的範疇

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

把企業/組織當成系統作需求分析,其系統功能的實現 (realization),由於涵蓋作業的時間長,且會有多類角色的參與者 (participant) 參與期間,以組成一連串的協力活動 (activities)。

而關於企業多人使用的資訊系統,如 MIS (Management Information System)、ERP (Enterprise Resource Planning)、電子商務 (e-commerce)、電子服務平台 (e-service platform) …等,也常需先分析與描述為達成企業某一特定目的 (specific goal) 需求時,原來傳統人工作業的活動,這往往是未來為分析資訊系統功能的前置引導作業。

所以對於「活動」流程的表達,必然是對於企業本身、企業層級的資訊系統等的系統需求分析,是一種必要的開發儀式。

前一章節已提及,單一特定目的作業流程適於採用 UML 活動圖 (activity diagram) 記錄;而表現多個作業流程之間的關聯性,則適於採以「erikson-penker」uml 流程擴充圖來表達。本章節針對這兩種設計圖,就語法與操作應用上作詳細的說明。

另外特別強調的,需求分析師在描述作業流程,盡量不要加入「資訊系統」的參與, 原因有二 [註1]:

  1. 不容易界定資訊系統的開發/維護範圍。
  2. 不容易瞭解會有幾個資訊系統的參與。

[註1] 資訊系統範圍的界定與系統的切分,係由擔任系統整體架構規劃的架構師 (architect) 所負責。需求分析師在初期並不容易瞭解資訊系統的責任,所以最好不要在作業流程的表達加入資訊系統的角色,以免容易造成混淆。

所以作業流程,適合描述的是傳統的人工作業,也就是所有的參與者必定是「人」或「組織」所擔任的角色 (role)。

至於資訊系統的系統功能 (system functions) 分析,會採以較適合的塑模技術,例如使用案例模型,這在後續章節即會詳述。

企業流程與資訊系統功能的分析與描述,這裡採以「MSS」三層次的塑模分析方法,如此可以有效表達在人工與資訊系統的「活動-系統功能」間的關係,並得以讓設計圖表現得簡潔,自然能形成一種層次分明、井然有序的設計框架。

  • M-Multiple Process (跨多個作業流程)。
  • S-Single Process (單一作業流程)。
  • S-System Function (資訊系統功能)。

「軟體需求分析與塑模」- 流程與活動

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

實現企業層級系統功能的主要組成元素是「人」,也就是多個不同角色的內部工作者 (internal worker) 在不同的時間點合作接續以完成所屬職掌的工作。

當為了履行一個企業需求,可能需一連串的活動 (activities) 循序接力達成。當然活動的執行需要有特定的參與人員,也就是會有多種不同角色 (role) 或組織 (organization) 參與。這一連串的活動即構成作業流程 (business process)。

Jacobson 為企業流程 (business process) 作了一個簡單的定義:

Put simply, a business process is the set of internal activities performed to serve a customer.
Object Advantage》, Ivar Jacobson, 1994
(簡單地說,企業流程就是要能夠服務客戶的一連串企業內部的活動)

而關於「活動 (activity)」的定義 (from Wiki):

Activity is a major task that must take place in order to fulfill an operation contract.
(活動是一個必須履行的主要工作,為以滿足一個操作上的契約。)

參考下圖範例係利用 UML 活動圖 (activity diagram) 繪製傳統人工「訂購-出貨」作業流程。從該案例可以得知,這一連串從訂購到出貨的活動,會有多個不同組織部門的工作人員參與。當完成這一連串活動後,即滿足主要的企業需求-「訂購商品」。

圖例、傳統人工訂購-出貨作業流程

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

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

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

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

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

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

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

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

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

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

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

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

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal