讀書心得 (一)

Proof of Concept (POC)

將設計概念實作出雛形 ( prototype ) 品，以供客戶或評鑑單位檢驗。

為了推銷產品，廠商往往把產品說得無所不能，然而天花亂墜的說詞背後，可能隱藏許多誇大不實的成分，為避免導入後才發現產品名不副實，可要求廠商POC（Proof Of Concept）以檢驗真實度。POC的意思是請廠商證明他們的說法，多數廠商針對潛在客戶均同意試用一段時間，以確認符合需求。


軟體測試

軟體生命週期中，大致有分析、設計、開發、測試、上線、維護、更版等階段，任何階段的工作與產出皆有可能犯錯。越晚發現問題，修正錯誤所付出的代價就 越大，甚至可能演變成無法解決的錯誤。因此，Agile方法論中的「以測試驅動開發（Test-Driven Development；TDD）」提倡：在分析的初始，就應該先撰寫測試案例（Test Case）程式碼，測試程式碼寫不出來了，而後再寫實做功能的程式 碼；接著又回去寫測試程式碼，直到執行測試沒有錯誤，使用者需求功能也都完成為止。

換句話說，無法測試的功能不用寫；亦即以測試來驗證對需求的了解程度，同時驗證程式碼的正確性。在如何開發與如何驗證的雙向思辨下，會更了解問題，並規範接下去的設計與開發不至於偏離。

現今絕大部分的軟體開發雖未採用TDD，但隨著系統越來越大，在開發流程中， 測試的時程也越來越提前，以防範在前述的需求、設計、開發、部署等過程之中所隱含的錯誤。若能早期發現，解決成本也將較低。很多的想法與設計必須經過測試的驗證，方能修正至可行。尤其對於系統架構，如：安全、可用性、效能、容量、擴充、易用性、整合、重用性⋯等，各個架構面的設計往往彼此衝突。舉例而言，若徹底要求安全可能傷及效能、易用、整合⋯等，若強調使用介面友善易用、未來的擴充彈性等，也可能損傷效能。

實作系統功能面的技巧與技術也日益繁雜，不管是程式語言的Framework、物件導向設計、平行執行架構/多執行緒、Web 技術、Mobile 平台、使用者介面、資料庫功能、伺服器平台、雲端運算⋯等，要整合新舊想法與技術，本身就包含了許多不成熟與不穩定的因素。諸此種種，每一項架構規劃其底線為何，設計與施行的方式是否符合需求且不牴觸其他的架構設計、是否有實作上的缺陷等，往往需要有詳盡完善的測試來驗證與矯治。

To Be continued  (Next)