關於軟體需求變動的一個小案例思考

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

一個發生在昨天輔導單位的一個小小的案例,應該也可以藉此讓許多開發人員反思下...。

某一技術高深的程式開發人員 (就簡稱 PG)對一已進行開發至一半時間的專案,突然 User 代表 (關係利益人,就簡稱 User)丟了一個針對要計算折扣代碼的邏輯的需求進來,而且看來好像挺複雜的樣子。

PG 心態上不是很愉快,都已進行至一半,現在才突然有這樣的需求,需要為此多花一至兩天的時間來撰寫它,而這會影響到既定的上線時間。

嗯,我的判斷是當然會多花一時間,但不至影響到預定的時間。心態上的不適 (為何這麼重要的需求到中後期才提出來)遠比實作的難度大很多!

我能作的是什麼? (在這個極小型的專案我兼職擔任 PM),幫開發人員多爭取一天的休息時間,讓他們心理好過些。

然後昨天這位 PG 花了很多時間在撰寫相關這邏輯的實作,甚至很認真的透過 SA 與 User 提相關的問題。

嘿!這時刻我給他制止了。。

閱讀全文 »

[範本] 一個最基本的 C#.NET 單元測試程式碼骨架 for VS.NET 2015

所謂的單位測試框架 (Unit Test Framework),其作用在於讓開發人員可以輕易地撰寫以「類 (Class)」為單位的測試程式,並隨時可以執行自動化的重複性測試 (automation repeatable test),以確保該單一類別的正確性。

單位測試的創始者為 Kent Beck,其理論與方法已被各程式開發語言所接受並多以開源方式 (Open Source)釋出,作為xUnit家族的單元測試框架 (unit test framework)。

多數測試框架 (如 MSTest, Junit)已直接內建於 IDE (如 VS.NET 2015, Eclipse)開發環境內,使得開發人員撰寫與執行單元性的測試程式是一件輕易的工作;自 Visual Studio 2015,尤以免費釋出的 Visual Studio Community 2015 版本,均已內建更具多功能、擴展性佳的單元測試機制。

透過 Unit Test Generator,可以:

  • 支援內建 ( MSTest)與 3rd Party (NUnit, XUnit)測試框架 (Test Framework)。
  • 依據測試框架產出對應的單元測試專案與測試程式碼骨架 (skeleton)。
  • Test Explorer 可以支援任一測試框架,只要有實現 (implement) Test Explorer Adatper 介面,如此得以執行任一測試框架所撰寫的測試程式。

底下即為個人利用內建的 MSTest 測試框架 (Test Framework)所撰寫的最基本的測試程式碼骨架 (skeleton),參考如下:

閱讀全文 »

[個案研討] 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」的作法?其實這與實作技術沒有太大關係,而是因為當要與外部單位的系統作整合時,外部單位總會有「安全性」的考量,不一定願意釋放出可讓系統直接呼叫的介面。

閱讀全文 »

簡述何為瀑布式 (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)。
  • 過早把資訊系統角色帶入。

閱讀全文 »

軟體思維顧問

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

Personal