原型製作的8大原則

整理小記錄，看到一張N年前留下來的【原型製作的8大原則】，是Nation Instruments的發布的文章，這篇也是提出很基本的概念，紀錄一下：

核心：以終為始(亦即符合可驗證的市場需求)

補充個人想法在每一點之後。

1. 理念一毛不值：在20年後AGI/AI的極速進展，第一點可真是一針見血。

2. 從紙上談兵開始：先從MVP on paper開始，或者是透過簡易的雛型設計開始。

3. 只做必要的工作：測試硬體/軟體的可行性；展示初步成果獲取回應意見(來自終端使用者最好)。

4. 預期多重選擇：考量其模組性(Modularity)，加入擴充性、效能、包裝等選擇。

5. 設計時要考慮到最終產品的再使用性：以效能換取彈性、預留能將原型從實驗室延伸到市場的架構，這也是後來常說的可製造性，或者Design for Manufacture。

6. 避免過早把焦點放在成本上：原先概念是以證明可行性為主，但經過這十幾年，我認為成本的考量依然是商業化的必要性之一(各產業可能有不同的考量)，免得成本過高而無法進行商品化(實際案例)。

7. 對抗回歸平均：意思就是打造出的產品是讓人不經意發出【啊哈】的創新創意產品，而非僅打造出平庸簡易的產品。(各行業對於"啊哈"的定義也會有所不同)

8. 確定該原型經得起展示：言下之意，就是DEMO的時候不要開天窗，通常的經驗是要準備至少三個方案(一主、兩備)。

以上就是不知多少年前的文章，經過十來年再看一遍，蠻多點都是經典值得反思與落實在各種開發案當中。

百日計畫：084-研究/研發分享-6-微機電氣相層析儀

2008年畢業後，因為當兵有個小插曲，所以需要等待入伍，那時候研究所的老師與一間新創公司合作，希望將當時從密西根大學所發展的微小化氣相層析儀進行商品化。所以詢問我是否有想要參與，所以就回來實驗室協助。

整個專案在當時（公司甚至還沒在台灣登記）人數也少，除了新創公司本身有幾位電子電機相關的高手外，我們實驗室除了我之外，還有三位碩士生參與。

微機電氣相層析儀，是利用半導體製程，將原本巨觀的裝置，如感測器、分離流道、前濃縮管與加熱裝置等微型化晶片，也就是所謂的Lab-on-Chip的一種。

三位學弟妹各自處理感測器、分離流道與前濃縮管元件，我主要進行系統設計/整合、控制軟體撰寫以及協助個別零件所遭遇的問題，當然還有整合後的實際樣品測試。過程中也遇到許多小細節需要去處理並重新設計晶片或者電路部分。

在我接到兵單準備入伍前，也終於順利在兩個月內完成實驗室等級的原型機，且也測試了樣品。這個專案原本要應用在肺結核的呼氣檢驗，所以我們用的樣品就是根據醫療文獻中得知的幾種揮發性有機氣體化學成分。也在測試後順利得到很好的分離效果與偵測能力。然後後續的部分就在我當兵去了之後，交付給實驗室的學弟妹繼續接手了。

後記： 微機電氣相層析儀的完整開發，在實務上還是有許多障礙，例如無法將所有的元件皆“微型化”，不管是設計的難度，或者是設計出來的能力有線外，如何將每個“微型”元件完整的整合在一起，都是後續試量產將面臨的問題。當然上述是在2009年，已過了八年的現在，微機電技術又更成熟，應該有更佳的設計能力可以達成。只是“達成後”是否真的在市場上有所用途呢？這就是商業策略需要思考的了～

對Micro-GC有興趣的可以由參考文獻前往得知： 

1. Ted Zeller教授的實驗室網頁：https://lnkd.in/evgk4ki 

2. Google search: MEMS + micro + GC, 有非常多的新資訊

百日計畫：065-半年的紀錄_H.Spectrum & 初步里程碑

過去半年，是個很有趣的時光。
從去年底意外參與H. Spectrum，再往前追溯到去了趟紐西蘭開始。

今年開啟了一個有趣的新模式生活。

自動化軟體測試&非自動化軟體測試

前言：
撰寫了許多Code，還需要人為一項一項測試嗎？可能非常的耗費人力、時間，而且“也不能確保每次的”再現性、重複性。這時候利用軟體本身的優點，使用軟體進行軟體的測試就是一種必須行為。網路上討論自動化軟體測試的文章千千百百種，以下參考另一篇文章所提及的關鍵點。

三個原因：Regression, Some tasks cannot be done manually, Parallel testing.

其中第一項的『Regression』，利用軟體自動化地去重復複雜、重復的行為，以得到低誤差性的測試，是很關鍵的一點，因為人為測試總是會無法百分百遵行“（精密）標準操作流程”，而軟體則可以使程序依照所傳寫好的法則去運行數百數千萬次以上而有著非常低的誤差（正常條件下＊）

第二項與第一項其實也是有點相似，但著重在測試項目的複雜性質，文中提出類似影像判別（某方面而言也是一種極大量數據）。

第三項則是建立虛擬的使用者，而非真實的使用多測試者去進行測試。

以上三點是大多建議、推崇、遵循自動化軟體測試中的幾項，其它還有更多原因就不在此討論，不過同時我想提出的則是相反的建議：什麼情況下則不適合自動化軟體測試。

1. 沒有被妥善定義的最終需求。

2. 沒有被良好設計的精密與精確標準操作流程(PPSOP)。

第一點的提出，則是衍生於醫療器材的發展，醫材法規專家林秋雄博士曾說：『Drug by discovering; Device by designing』，而推廣醫療開發領域的Stanford教授-Dr. Mochly-Rosen，在其衍生的Bio-design課程裡面也提到，『Intended Need』，在還沒被妥善定義的需求前，設計與做過多的自動化軟體測試是不恰當的。

第二點我特別定義PPSOP則是一般SOP著重在儀器/設備/實驗的成熟操作流程，但一個成熟的SOP早已經過不斷的測試與驗證，但在專案開發初期，其實定義這種SOP容易疏忽掉細節(魔鬼藏在細節裡)。所以我認為開發初期，更重要的是精密與精確標準操作流程(PPSOP)，而PP的意思是包含所有操作流程的細節外，如基本的順序、時間、數量外，還有與前後相同試驗的相關性、先後順序、測試者/研究者的操作習慣等等，都必須被記錄下來。而這就回歸到Design of Experiment (DOE)的設計是否正確、測試者/研究者是否遵循以及回饋等等。

其實第二點與第一點有重復到，都是著重在需求（Intended Need or DOE）的定義，而這兩點則分別屬於兩個不同開發階段，而這兩個階段與自動化軟體測試的交集仍然有一段距離。

此篇文僅描述一些方法概念，如何進行則又有許多眉眉角角。希望藉此記錄下來提醒自己也提醒自己參與的團隊，勿過度技術化，所謂Garbage in, garbage out，設計不良的架構/DOE，用了再好的自動化軟體測試，得到的也只是一堆”無用的大數據“而已。

*不考慮撰寫不良的程式碼、錯誤的演算法等等

Ref:
1. 3 reason to automate software testing
2. Biodesign