簡述何為瀑布式 (waterfall)軟體分析設計文件?!

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

什麼叫做「Waterfall (瀑布式)」文件?

就是文件整理看起來很用心的樣子,經由不斷地開會與確認諸多細節,然後在某次的會議決定階段告一段落,就給予該文件一個版號 (0.1, 0.6, 0.8 .....)。

所以,一個功能模組或作業流程,經過了幾次的版號更新,最終總算得以定案,然後再交付給 PG 據此撰寫程式碼。

不管大或小的單位,稍有組織性重視文件設計 (得以保存與傳承企業資產,其實是好事),幾乎就是採以這類 "瀑布式" 的開發模式。

如果這樣能順暢移轉至程式寫碼,那當然沒有問題。但是,需求分析其實是一種假設與期望,越是要求精確,越是不容易釐清。

那麼,為何精確度的細節非得要在文件分析階段就要求完整呢? 為何不搭配每一個階段的文件分析告一段落甚或當下就寫成程式碼呢?

每一次版號的演進,文件與程式碼從功能框架的較大目標範圍,再逐漸地往細節 (即精確度)貼近。

簡而言之,設計文件與程式碼本來就是「一體兩面」!設計文件引導程式碼的開發;程式碼的修正更新文件原來的假設。

所以,現實上當文件的版號制訂為最終版時,那麼,程式碼應該也是接近完工了。

為何不這樣作?這樣不是輕鬆又愉快? 其中一個很大的問題就在於,諸多實作的程式開發人員不太容易掌握所謂的「不確定性」開發態度。也就是說,如果沒有提供很精確的細節,開發人員已經不知道要如何寫出程式碼。

總之,各類角色的開發人員,對於軟體開發的最重要修煉就是要懂得先學會如何抓到「大」的主題 (topic),再來才是往「細」的程序/邏輯/欄位 作精。

2016_4.14-15_彰化軟件兩日教學行

因為農曆年後彰化某國際鞋業代工大廠購買了 EA UML 工具數百套,同時也針對 RUP (Rational Unified Process)所提出的 4+1 View 請我們規劃三天的軟體教育暨工具使用的課程。

我負責前兩日的課程,授課日期就在上星期四、五 (14/15)。因為一大早就要上課,所以乾脆前一晚就開車下彰化,並先於彰化市區—福泰商務飯店訂房住宿。

軟體教學@寶成鞋業國際

上個星期幾乎全是下雨天,尤其星期三傍晚當我開車到新竹路段時,那個暴風雨下得超級大,加上天色已暗,有夠難開。所以大約開了兩個多小時晚上7:30才到了彰化市區,馬上就入住飯店內。下圖是隔天白天時拍照的。
彰化市福泰商務飯店

閱讀全文 »

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

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

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

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

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

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

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

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

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

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

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

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

閱讀全文 »

簡單聊聊軟體設計的 SRP (Single Responsibility Principle) 原則

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

SRP, Single Responsibility Principle (單一責任原則)

這是上星期課堂中,當我解釋 Multi-tier MVC 分層結構時,聽到學員告訴我的。

哈,這是我第二次遇到學員有告訴我這個術語,看來都蠻熟悉 Martin 在 "Agile Software Development, Principles, Patterns, and Practices" 一書內所提到的幾個軟體設計原則。

不過當我問他們工作上是否至少有把 UI 與 Logic/Data Acess 層分離? 沒有!還是全都攪在一起,沒有人講究上述分層的 "基本責任分派"。

沒有「知行合一」,確實實踐並從實務中體會與調整作法,那麼,學會 "背" 這些術語是沒啥用處的!

其實也只有一個字需要真正了解:責任 (responsibility)。

o Web UI (view & ui controller) / Standalone UI:Presentation (只負責傳送與回傳已運算資訊)。

o Domain Controller:負責控制流程 (control flow)。

o DAO (data access object)/ Adapter:負責連結資料庫/外部系統。

o Entity (或稱 business) Object:負責處理邏輯運算。

確實理解 "responsibility" 這個術語可不是用背的,而是身體力行,從過程當中去體會該術語的「真諦」。

從原點出發,一個詞彙可通一堆觀念。如當確實做好單一類別的責任分派時,所得到的效果就是「高內聚力 (high cohesion)」—責任明確。

「資料導向」vs. 「服務導向」的開發模式

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

傳統且比較直觀的開發方式係採以表單 (form)畫面為單位、然後連結資料庫直接存取資料,這是屬於相當典型的 Client/Server 2-tier 開發模式。

即使轉移到 Web 採所謂廠商提供的 Web MVC 框架 (如 Java Spring MVC),但那也只是 Web 端的一種技術解決方案 (解決 Web Page 狀態控管問題);然後再使用廠商提供如 Java Spring O-R Mapping 機制 (如使用 Hibernate Framework)連結資料庫,這仍是傳統的 Client/Server,重視以資料為導向 (data-oriented)的開發方式。

「資料導向」的開發方式直覺且簡單,當系統規模小且營運需求並不常變動,這樣是行得通的,而且在系統開發的初期會是相當快速的;但當營運規模大得經常會要求系統快速配合商務運作,「資料導向」的開發模式卻往往耗在所謂的「共用性整合」議題上太多等待時間了,那種有著「剪不斷、理還亂」的感覺,不僅讓人苦惱,也是引起紛爭的主要來源。

事實上,「資料導向」實際上早已悖離了軟體開發的第一個最基本原則:「封裝 (encapsulation)」。過早揭露資料與邏輯的細節,而使得系統的複雜度提升。

採以「使用案例 (use case)」搭配 Enterprise MVC,則是屬於「服務導向 (service-oriented)」的開發模式。

閱讀全文 »

簡單描述 SCRUM ~

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

SCRUM,這幾年最夯的開發方法論。

它比較像是團隊版的 GTD (Getting Things Done)時間/工作管理。因為是 Team Work 性質,所以還需要再佐以 Review Meeting (Daily/Weekly) 來檢視與回顧團隊成員的產出。

主要有兩個關鍵字須充分理解:

  • Backlog (訂貨):大訂貨 (product backlog)是由多個小訂貨 (sprint backlog)所組成;每一個小訂貨被視為是可被計量的工作事項 (work item)。
  • Sprint (衝刺):等同於現今所有實務開發均認同的 Iteration (循環,或稱迭代)。這是最重要的成敗關鍵,也是實踐過程中最難以克服的。 (一個 iteration 要涵蓋整個開發步驟,但又要能適時地量化一個工作目標,這不容易。)

特別再強調!SCRUM 只是一種做事的方法,它可能可以調和專案的 時程/規模/成本 三個因子,讓專案目標比較有機會在特定的期限內達成。

但是,SCRUM 與軟體品質完全是兩回事。許多開發人員以為導入 SCRUM/相關工具就能把軟體品質做好,那是不可能的。

軟體品質仍取決於對軟體設計的技能/技術的掌握程度。諸如對需求的分析/收納整理;系統結構的應變設計;實作技術的應用 ...等。

軟體思維顧問

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

Personal