IT需要預防民國百年蟲嗎？

在經過西元兩千年千禧蟲（Y2K）的危機與挑戰後，許多企業與資訊系統業者對此已不敢掉以輕心，面對即將到來的民國一百年有可能引發的「民國百年蟲」危機，有人擔心「民國百年蟲」可能會威脅台灣的資訊系統，各界若不及早正視此問題，屆時所產生的年序問題恐怕不只是對資訊系統造成影響而已，對企業的營運勢將產生不小的衝擊。

同樣是年序問題，Y2K時，當時各行各業的資訊單位如臨大敵般地投入許多資源與人力解決相關問題，特別是在1999年與2000年的跨年夜，所有資訊人員均無心歡慶新年的到 來，取而代之的是徹夜未眠的緊盯著每一個資訊系統，深怕一不小心被這隻千禧巨蟲給咬傷，幸好結果是令人歡喜的，多數的企業均在平安中順利度過千禧危機。

千禧危機之後，許多人認為千禧蟲問題被資訊廠商過度渲染了，事實也證明情況根本沒有想像中嚴重，也因此當民國一百年腳步逐漸逼近時，多數企業的資訊單位仍未著手處理相關問題，「民國百年蟲」問題似乎被大家忽略了。儘管如此，我們卻要在此呼籲大家務必再重新檢視所屬企業的資訊系統，這是因為「民國百年蟲」是專屬於台灣地區才 會發生的問題，不像千禧蟲問題受到全世界資訊專家的關注，因此，如果有使用以民國年作為系統日期欄位者，須及早因應以防止「民國百年蟲」問題的發生。

所謂「民國百年蟲」的問題是台灣地區民國紀年即將破百所引起的資料儲存與運算方面的障礙！自從1960年到1980年後期，許多電腦軟體的設計都採行2位數來代表民國年份 ，而非4位數，因此，到了民國一百年時，電腦系統可能會錯將民國100年解讀成"0"，?A進而造成電腦應用系統的錯誤！或許對於一般產業而言，因有些系統是在後期開發，所以較無這方面的問題，不過對於一些E化較早的產業來說，風險就相對提高許多，其內部應用系統更容易受到民國一百年問題的影響，尤其是在MainFrame大型主機上早期開發處 理的應用系統。

民國一百年的問題主要是在於系統設計時多半以2位數來代表年份，然而遇到一百年時，將造成資料輸出入與程式運算邏輯等問題，例如使用者輸入欄位，或是計算利息與放款日數等等，而這包含了五個影響系統層面：
1.資料庫與檔案儲存空間
2.資料輸出入
3.資料對外交換傳輸格式
4.程式邏輯判斷與運算
5.報表輸出項目的顯示

這些系統影響都存在於我們的應用系統當中，相對於我們應用系統的複雜度，在面臨一百年的修正問題時，我們常常會去思考以下一些關鍵性的問題點：

• 我們現行的資訊系統有沒有民國一百年的問題？
• 需要多少人力、資源解決這些問題？何時該開始著手？
• 從何開始？
• 內部資源是否足夠？
• 需要多少預算成本？
• 該如何解決？

面對民國一百年的影響與產生的問題點，我們提出四大面向的思考方向，藉此能有效率的解決問題，也能找出關鍵性問題的答案，更是對自身的系統做一次詳細的檢視。

一、檢視分析

過去在修正應用程式時，大多以手動檢視為主，利用人員過往之經驗找出可能必須修正之處，包括資料儲存格式在內，唯相關程式影響邏輯，隨著應用系統架構之複雜，使得確認的工作無法百分百的被完成，連帶也無法正確評估出修改後的風險與影響之範圍。

針對此，資訊人員可藉由Compuware公司的程式關聯架構分析工具（XPEDITER/DevEenterprise）產生的架構圖，快速了解程式間的關聯性、欄位與欄位、欄位與程式的關係，並可主動分析出修改之欄位對整體應用系統的影響。另外，此工具亦可模擬出修改邏輯之程式流程與資料流向，有效確認出整體影響之範圍，協助評估風險與人力分配，同時可將程式或系統架構分析製成文件，做為日後變更時的依據與維護之用。對應到「民國百年蟲」的問題，XPEDITER/DevEenterprise不僅能明確找出應用系統民國一百年修正的影響範圍，也可當做日後系統架構分析的確認依據與文件。

二、開發修正

在開發修正階段，以往都是憑藉著人員的經驗或以加上旗標的方式來進行除錯，因此，不論是資料錯誤或是邏輯錯誤等問題，總是消耗開發人員大部份的時間，進而也影響到測試階段的時程安排。其實這樣的問題，開發人員可以利用分析除錯工具（XPEDITER/TSO/CICS）解決(如圖三)，TSO/CICS能協助開發人員一步一步按照指令執行，了解資料流向與程式邏輯，快速找出錯誤點，節省開發除錯的時間。另外，開發人員亦可搭配資料管理工具（FILE-AID）的輔助，清楚且直接看到資料庫檔案內容與準備測試的資料，有效縮短程式開發修正的時程。

三、資料測試

以往資訊人員在進行單元測試時，總為了測試環境與整理測試資料而傷透腦筋，反反覆覆的測試徒浪費許多開發資源，尤其是在整合測試階段，資訊單位總是需要重新整理出另一測試環境並增派更多人力協助，但是測試結果卻往往只能憑信心程度來評估軟體開發品質，影響整體軟體開發時程。

針對上述問題，可利用Compuware公司的自動化測試工具（QACenter及XPEDITER/Xchange）解決。在進行單元測試時，資訊人員可直接就真實資料進行測試，非但不需另外建立測試環境，甚至還允許在非尖峰時間進行自動化測試。在進行整合測試時，利用自動化測試工具的輔助，將可降低人員反覆測試的人力成本，亦可藉由測試涵蓋度分析工具（XPEDITER/Code Coverage）(如圖五)，找出哪些程式段落還未測試，進而評估系統上線風險與控管軟體開發品質，不但如此，Code Coverage還能進行自動化同步多個模擬真實情況的測試，以及搭配效能分析管理工具（STROBE），以雙管齊下的方式協助資訊人員了解此變更開發帶給系統面的效能影響。資訊人員利用這套自動化測試的方法論，不僅能解決民國一百年的問題，若能運用在平常的專案開發上，更能有效降低人力資源的消耗與建立良好的軟體品質。

如圖四之測試方法論：藉由系統時間之不同，將原輸入資料（測試個案）執行程式後，比較其輸出資料，並直接指出程式錯誤點，經修正後再反覆執行其原測試個案，減少測試人力消耗，並可測試修改與未修正之程式段落。（Compuware XPEDITER/Xchange；File-Aid/MVS/DB2；QACenter）

四、錯誤管理

在營運系統上當有錯誤發生時，找出問題並解決問題總是在和時間賽跑著，而處理問題的急迫性也總是讓第一線人員傷透腦筋。此時若有錯誤管理工具（Abend-AID）如圖六的協助，就能讓上述問題迎刃而解。Abend-AID能在問題發生的第一時間隨即攔截錯誤訊息，並分析錯誤發生點，處理人員即可藉由分析列表中的資訊，明確掌握錯誤碼與程式問題點，並迅速解決，此外，系統人員也能藉由錯誤彙總列表，清楚系統狀況，建立系統故障記錄，以縮短營運停工時間，降低企業營運成本的支出與消耗。

結論

有句話說：「計畫趕不上變化」，每一次的變化與變更其實都包含著許多的意義在內。我們都同意變更是必然的，但又不容易處理，而需求也總是隨著時間不斷的變化（新增或刪除），如民國一百年是否會對系統運作產生影響？是否會對企業造成傷害？面對一連串引發出來的問題，我們該如何修正？而其中的關鍵問題點是什麼？又該如何評估呢？

民國一百年的影響，從系統層面到計劃修正所衍生出的關鍵性問題，再到從四大面向（即檢視分析、開發修正、資料測試、錯誤管理）思考如何有效率地解決系統問題，讓資訊系統不再受民國一百年所困擾；而身處在台灣的我們也可以藉機對資訊系統重新檢視與盤點，期許在資訊系統管理、軟體品質控管與錯誤分析管理等層面上有一番新作為， 讓我們可以更安心的度過民國一百年。