如何從巨觀的需求流程分析,可以直覺無縫的橋接至程式寫碼?

本文同步發表於「FB 軟體設計鮮思維」社團。

這裡採用個人所發表關於需求分析的「MSS」與 程式寫碼的「SSD」三層次分析與實作方法。

需求分析階段的 MSS 三層次

關於 MSS,可以參考原來寫的這篇:「大業務流程塑模的MSS三層次原則」。

o M(multiple) Process。
o S(ingle) Process。
o S(ystem Function)。

    以「請購-採購」作業流程 (business process)為例:

  • Multipole Process:「請購」與「採購」兩個作業流程的表達,焦點擺在「請購」作業內部的一連串活動 (activity)分析。
  • Single Process:「請購」作業流程的內部活動表達,焦點擺在「進行供應商評等及比價」的系統功能對應。
  • System Function:「採購」資訊系統的系統功能界定 (利用使用案例)。焦點擺在「比價」的系統功能實現 (realization),實現的步驟主計有「列出廠商資訊」、「評等列出優先順位供應商」、「儲存比價交易紀錄」。

程式寫碼的 SSD 三層次實作

可以參考「實作 Enterprise MVC 巨觀結構的 POC-觀念篇」內關於「控制類別」的說明。

o S(ubject) 主題。
o S(TEP) 實現主題的步驟。
o D(etail) 實作每一步驟相關的細節 (欄位明細與業務邏輯)。

    承接上述例子關於「比價」使用案例的實現。

  • Subject:「比價」使用案例-對應至「比價Control」控制類別。
  • STEP:「比價Control」類別內的 Function (Method)對應為:
    「ListSuppliers()」、「ComparativePrice()」、「SaveComparativePriceTransaction()」。
  • Detail:「ListSuppliers()」列出廠商的清單與欄位資訊From資料庫;「ComparativePrice()」處理比價的邏輯與評等;「SaveComparativePriceTransaction()」儲存本次比價的交易結果至資料庫。

「軟體需求分析與塑模」- 什麼是系統功能

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

系統 (system) 是由一組互動 (interacting) 或獨立的元件 (component) 所組成的整合體 (integrated whole)。

系統功能 (system functions),即為某一整合體所提供給外界 (參與者或外部系統)的一連串服務 (services)。

把企業 (business) 當成一個整合體,並藉以分析該整合體所提供的功能需求,以及組成該整合體的組成元素。這樣以企業為標的的分析塑模方式,稱為「企業塑模 (business modeling)」。

把資訊系統 (information system) 當成一個整合體,並藉以分析該整合體所提供的系統功能,以及組合該整合體的結構元素。這樣以資訊系統為標的的分析塑模方式,稱為「資訊系統塑模 (information system modeling)」。

把企業或資訊系統當為一個整合體,便可以採用相同的手法,如利用 UML (Unified Modeling Language) 語法,來分析系統需求。

「企業」與「資訊系統」兩者的關係即為,「資訊系統」為組成「企業」內部結構的其中之一的元素 (element)。而當把焦點轉移至資訊系統,探究其中所提供的系統需求 (系統功能)時,則再將「資訊系統」這個結構元素放大,並從「外」的需求分析,與「內」的結構設計來看待資訊系統的分析、設計,乃至於實作了。

參考上節範例,「診療服務」為企業的系統需求,如果企業架構師規劃了三個資訊系統 (組成元素) 的支援,參考如下圖,架構師可以利用 UML 使用案例圖表 (use case diagram) 規劃每一個資訊系統各有其需實現的系統功能,以及資訊系統之間的關係是透過介面 (interface)的連接達成所謂的「SOA (service-oriented architecture)」架構。

圖例、表達資訊系統的系統功能

至於資訊系統是如何實現系統功能,又如何連接其它外部系統,那就是所謂的系統 (這裡就是指資訊系統了) 結構設計與實作的議題了。

「軟體需求分析與塑模」– 企業需求源自於企業價值

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

企業需求要能提供價值 (value),如此才得以讓企業有獲利行為而能永續經營。

「價值」的呈現取決於在創新、成本、效率等因子的調和。這些因子經常是由內部工作者 (internal-worker)、產品、系統、軟體與流程 (process)等所提供並滿足其需求。最終目的當然在於讓企業創造「利潤 (profit)」。

例如,「仁心慈善醫院」是一家企業 (business),其中最主要的核心價值係提供 「醫療」的服務 (service)。為了提供「醫療」這個主要服務,企業內部必然會有多個內部工作者的協同合作,包括「醫師」、「護士」、「藥劑師」、「行政人員」… 等;涵蓋的作業流程可能有「掛號」、「看診」、「住出院」、「領藥」… 等;且為了增進處理效率與節省人力,會導入由 產品/軟硬體 所組成的資訊系統 (information system),成為工作者的協力夥伴。

除了文字陳述紀錄外,可以藉由視覺化的圖形塑模 (visualization diagram modeling),更容易表達焦點。

例如,我們可以使用 UML「使用案例圖 (use case diagram)」表達企業所提供的主要服務 (企業層級的系統功能),以及使用「業務流程圖 (business process diagram)」表達實現 (realize) 企業系統功能的主要組成元素 (內部工作者、資訊系統、主要作業流程)。

圖例、表達企業提供的主要服務

圖例、表達實現企業需求內部的主要組成元素

關於 UML (unified modeling language) 的基本介紹,以及應用在企業與資訊系統需求面的分析 Know-how,參閱後述的章節內容。

[個案研討] FTP Server 是否可為企業系統的外部系統?

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

月初在內湖某大電視購物/網購平台總部的資訊單位授課。喔,先誇讚下,約有50來位的學員,上課過程大都蠻踴於提問且活潑,可說上得挺順暢愉快。

其中在談及使用案例模型 (use case model)的需求架構分析時,關於外部系統的定義,個人特別強調會是透過介面 (interface)的整合,如透過 web service or message service 等),而不會是透過資料庫的整合方式。

然後其中有位學員就問了,如果連結外部系統是透過 FTP,也就是開發中的系統這邊為 FTP Client,然後以批次定時處理的方式,傳送到外部單位的 FTP Server,對方也是採用批次自動處理的作法,把接收下來的檔案作解析處理。

這樣 FTP Server 是否是開發中系統的外部參與者 (actor)?我倒是沒想到現在會有這樣的作法,最初的直覺當然不會是。

不過課程休息時,再仔細想想,回歸到所謂外部系統整合的定義,是否有透過介面來連結? 事實上,FTP 的 Client/Server 是有的 (當然就是透過 FTP 協定),且兩邊系統之間並未透過手動操作,而確實是系統對外部系統之間有達成自動化的整合 (雖然是透過批次處理的方式)。

為何會有這麼「low」的作法?其實這與實作技術沒有太大關係,而是因為當要與外部單位的系統作整合時,外部單位總會有「安全性」的考量,不一定願意釋放出可讓系統直接呼叫的介面。

閱讀全文 »

[系統分析] 從 GUI 畫面分析使用者的操作目的 (Use Cases) – 以 Twitter 為例

這是上一期「系統分析設計與實作」課程的一位美女學員-Isis 的案例作品。她對 Use Case (使用案例)用於系統需求分析情有獨鍾,而且相當積極的學習與詢問問題。

不過可能待在業界許久,一開始對 Use Case 這類講究目標導向的分析方法並不容易理解,總是不自覺就鑽入到細節,或是聯想到實作面議題。所以就不容易抓到 Use Case 的分析主軸-界定參與者 (actor)使用系統的操作目的,以及實現該目的的操作程序。

我使用了幾種方法,包括如何從企業流程的分析找出使用案例,或要求綜覽閱讀 Use Case 的經典名著「Writting Effective Use Case」(再針對她提問的問題回應),甚至乾脆從某一個實際的專業問題領域 (problem domain)著手,但效果仍不彰。

畢竟大部分軟體人員少對所謂的「抽象 (abstraction)」技能下功夫。抽象是需要經由思考、閱讀、觀察等長期日積月累才得以鍛鍊而成的。

所以換一種較具象的方法,從現實各網站的使用者操作畫面中,完成下列的系統分析工作:

  • 界定系統範圍 (system boundary),並給予系統命名。
  • 規劃功能模組 (functional module),這是邏輯性的功能分類。
  • 從每一張畫面表單,透過所提供的資訊,以及要求使用者輸入的資料欄位中,藉以分析其背後的操作目的,也就是使用案例。

我先給她系統規模較小的 Twitter 案例,要她完成上述三項重點工作,而先不用撰寫使用案例陳述 (use case description)。雖然使用案例陳述才是實現系統功能的主要程序,但可以先等系統功能的界定有了初步釐清與共識後再來描述相對的實現步驟,這對使用 Use Case 分析的 SA 而言,比較能有循序的分析節奏,才不致亂了套。

耶!!這方法還真對 IS 的性向,不到兩天就完成了我看了也覺得很有創意的分析。經由她的首肯,我就把她的案例作品分享上來。

圖、範例-從Twitter畫面操作找出 Use Cases

圖、範例-從Twitter畫面操作找出 Use Cases

閱讀全文 »

[案例] 推特(Twitter)系統分析使用案例

這是前年底至大陸「深圳」的「中國移動」軟體部門授課的案例。當時我們花了兩個多星期的時間製作此案例,並包含可執行的雛形應用系統與手機 App 的前端介面。因也事隔一年多了,所以無保密問題,在此就把基本的系統分析使用案例 (use case)提供分享參考,同時也把 EA Model 檔供下載參考,可作為一個小型專案的範本參考。讀者可至 EA Saprx System 下載免費的 EA Viewer 以讀取該 Model 檔。

o 推特 (Twitter) 系統分析 Model 檔。
o EALite.exe (free, EA UML Viewer)

推特系統功能模組 (System Functional Modules)

圖 1、推特系統功能模組
(點擊圖片鏈接看原圖)圖 1、推特系統功能模組

推特系統模組-General

圖 2、推特系統模組-General
(點擊圖片鏈接看原圖)圖 2、推特系統模組-General

閱讀全文 »

軟體思維顧問

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

Personal