prototype 與 pre-β 的差異

這幾天頗為忙碌，但卻總覺得在實質上沒有取得什麼進展。

上週五實驗室 meeting。項老師說，希望以我目前的 prototype 為基礎，弄個「系統」讓歷史系的一些人試用看看。聽到這樣的「需求」，我的臉一下子就綠了。哎，prototype 與 pre-β 差異是「很大」的耶！

對我而言，prototype 的幾項主要功能是：提供團隊成員研究討論的基底、素材、與系統概貌，並在原型開發中，辨識出系統開發前期可能產生的風險。pre-β 版本，目的則在於提供真實的使用者試用，取得良好的回饋，並提供對正式系統的建議。要給他人試用，需要考慮相當多不同的層面。例如，安全性的控管，要做到什麼程度？是否要建立個人的 profiles？連線是否採取 session-oriented 的機制？系統可以提供多少人同時上線？還有，資料的品質，必須處理到什麼地步？

因而，這幾天幾乎又都是在重複做資料處理、資料轉換的工作。要給真實的使用者試用，資料就必須有相當的品質，不能含有「難以忍受」的錯誤。之前不是花了很多錢，建立了 metadata 來詮釋文件嗎？應用這些人工處理過的 metadata，應該比自動擷取的方法，有較好的資訊的品質吧。

但事情沒有這麼簡單。Metadata 既然是人工處理，就會有人為的疏失。舉個例子好了，「光緒十一年」竟然可以對應到西元 1866、1885、1886 年（1866 年應該是錯誤的）？還有，依日期欄位的規定，資料應該至少有「年份」的資訊，但為什麼可以看到「七日」、「五月二十三日」、甚至「署福建巡撫閩浙總督崔應階」這樣的資料呢？

在資訊處理的流程中，上游的資訊一旦品質不夠好，下游的處理就會事倍而功半。這時，就彰顯出傳統的 Waterfall（瀑布式）開發流程的缺點了。在瀑布式開發流程裡，每個開發階段都是明確的，上游必須經過嚴格的品質控管，才能將資料（或程式）轉給下一步的開發者。因此，下游不應該收到品質不夠好的東西。但實務上，我們也都知道，要保證上游資訊的品質，成本非常高；下游的處理者，就是會收到品質不夠好的半成品。

那麼，我們該怎麼辦呢？把責任推給撰寫 metadata 的人員，責怪她們不夠用心，並且等到她們將資料都修改好，才進行下一個開發步驟；還是把不夠好的系統丟給使用者，讓使用者自己去過濾篩選資料，並說明「自己只是中介者、只負責程式開發」呢？

因為兩邊都無法接受，我就只能在中間階段的處理中，盡量加上錯誤篩檢的機制。這樣一來，當然就會消耗許多寶貴的時間了。

我想，在方向上，項老師是對的：系統終究必須讓 real users 測試。然而，沒有經過良好的規劃，以為 prototype 與 pre-β「感覺起來差不多」，其實是很大的失誤。系統開發人員，還真是「苦命」啊！

而這下子，自己事情也變多了。至少，已經超過我原先的預期了（我原本只想做個 prototype，之後就由其他人接手）。我必須花時間思考一下，自己想將這個 pre-β 版本定位在何處。即使這個版本的使用說明是由別人負責的，即使這個版本只需做非常陽春的安全控管、連線控制、profile 管理、使用者介面調整、效能調校、或者系統品管與程式除錯，要考慮的事情都比單純的 prototype 複雜許多。