從系統工程探討數位身分證的問題 廖宏祥＠自由 20210125

【縛雞之見】

最令人擔心的，實在是潛艦各商售管道籌獲的次系統整合問題：個別測試沒問題（供應商就拍拍屁股沒責任），不代表放在一起沒問題。
未來必將是錢坑。

從系統工程探討數位身分證的問題    廖宏祥＠自由 20210125

在爭議多時之後，行政院於日前決議，將以專法來規範換發數位身分證。在取得社會共識後，再依法辦理。本文從歐美國家在採購大型科技系統時所運用的系統工程，檢討我國數位身分證招標時的不足，並建議未來的數位發展部應倡導系統工程並落實「獨立驗證與確認」。

台灣缺乏系統工程實踐

系統工程是美國在一九六○年代為了阿波羅登月計畫創立的方法論，讓一個看似不可能的人類創舉順利且精準的完成任務。數十年來不但美國聯邦政府採用，西方科技業界也已將系統工程視為設計、建構、整合實務系統的基礎，不但是大型系統開發所必需，也推廣到中小企業。它是由系統概念開始，至系統處置的整個生命週期，完整解決管理和科技問題的方法論。西方跨國公司除了自定系統工程規範，也有如IEEE 12207（軟體生命週期）、IEEE 15288（系統生命週期）、和ISO/IEC 29110（適合小型企業）等國際標準可遵循。

數位身分證可帶動數位經濟，需整合各種系統，進而創造高效能的政府服務模式。技術上除了硬體、軟體、網路外，更重要的是應以系統工程為基礎，進行研製與整合。我國在開發資訊系統時，多聚焦軟體工程的運用，但缺乏系統工程對用戶需求、軟體、硬體、通訊等不同場域介面的國際標準實踐。如何將各個系統整合並安全運營維護，系統工程正是不可或缺的關鍵。而這與台灣過去四十餘年硬體製造薄利多銷的商業模式截然不同；亦即台灣缺乏高附加價值的系統整合經驗。

儘管系統工程已在歐美各國廣泛運用半世紀以上，但我國政府似乎沒有注意到世界運用系統工程的趨勢，更不瞭解軟體資訊產業的本質。因此政府大型系統的招標與合約執行，都沒有融入系統工程的要求，也導致軟體與系統整合業、國防與航太等產業，都普遍缺乏系統工程的觀念與實踐。業界為了配合不合時宜的「政府採購法」，在工程實踐、制度、文化等面向甚少能與國際接軌，連帶也弱化這些產業在國際的競爭力。

招標前政府（甲方）應執行的系統工程

附圖「系統工程生命週期V-model」和軟體工程實踐類似。但系統工程還擴展到左上角與右上角標示「甲方工作」的部分。

美國聯邦政府在採購科技系統時，於圖的左上角，也就是招標前的「任務觀念」階段，通常運用系統工程至少執行下列工作：

1.  差距分析：描述現有系統或制度當前作業狀態，和未來系統欲達成目標的差距；同時指出實現任務的阻礙。

2.  技術路線圖：為了達成目標，需要哪些技術，以及必須構建哪些環境框架，如法律、標準等。

3.  作業運營概念（Concept of Operations）：最終用戶及所有利益相關者的組織、角色、責任等，並整合各方如何使用未來系統的模型與情境。這份文件是後續制定系統頂層需求的依據。

4.  替代方案：根據作業運營概念，描述可以構建哪些可能的替代技術解決方案、系統架構等。

5.  成本分析：運用ROM、BOE、WBS、COCOMO II、SLIM等方法，估算每種替代方案的初始成本和生命週期成本，作為編列預算與發包議價的依據。

6.  緩解風險和利用機會：列出所有技術和管理風險，和可資利用的潛在機會。

7.  業務案例（Business Case）：整合成本分析、風險和機會，分析每一個替代解決方案的成本效益，俾便決策者做出決定。

系統工程最重要的工作之一就是需求定義與管理。為了制定招標文件的系統頂層需求，甲方的系統工程師根據「任務觀念」階段產出的成果，進入「系統需求」階段。也就是運用模式、模擬、量化、非量化、使用案例（Use Case） 及建構原型等方法，定義系統的功能需求、性能需求（Performance Requirements）、非功能性需求、和內部與外部界面需求等。而這些最終要放入招標書與合約的文件，與「作業運營概念」之間要有可追溯性，並確保一致性與完整性。

一般政府官員對科技不見得精通 ，因此甲方有必要聘請公正第三方的系統工程顧問執行「獨立驗證與確認」（Independent Verification & Validation, IV&V）。除了分析上述各項工作，也協助政府監督全部生命週期履約進展、驗證系統符合需求規格、及早發現問題、降低專案風險、並確保開發流程符合規範。

沒有系統工程的數位身分證

因為系統工程的產出物既不是硬體，也不是軟體，所以台灣政府似乎不瞭解這些工作的重要性，更不願撥款執行。然而根據美國蘭德公司的研究，大型系統的系統工程費用可高達全部專案預算的四分之一，其重要性不言而喻。

從數位身分證的軟體需求文件來看，內政部與其委託的顧問公司沒有執行系統工程。例如：

1.  沒有整合未來數位經濟的重要利益相關者，如負責勞保、監理、年金、稅務、電子商務等單位的意見；也就是沒有整體的「作業運營概念」。

2.  內政部將硬體定為三十三億台幣，但遠為複雜的軟體卻只有不到九億，令人懷疑其「成本分析」的合理性。也無怪乎國內沒有廠商願意投標。

3.  把硬體和軟體分開招標是沒有系統整合概念的作法。工程實施與運營維護時出問題的話，負責硬體和軟體的廠商將沒有統一權責，甚至互相推諉。

4.  軟體需求文件敘述未來系統的架構，完全違反系統工程的原則。

5.  沒有要求如NIST或其他完整的資安標準，反而提供所謂的「賞金獵人」。須知白帽駭客是資訊安全的手段之一，但絕非全部。

6.  既沒有性能需求，也沒有諸如系統安全、資訊安全、可靠性、維護性等非功能性需求。

7.  招標書的系統需求為得標廠商合約的一部分，驗收時將逐條測試。但需求文件卻有些無法測試、驗證、或近乎盼望的條文。

8.  需求文件有些條文不夠明確，容許將來甲、乙雙方有任意解釋的空間，甚至造成諸多履約爭議的可能。

9.  沒有外部界面需求（Interface Requirements Document），如：與數位政府相關的T-Road資料交換系統界面定義。

10. 國發會網站敘述跨機關資料交換的T-Road結構。從其描述來看，應是模仿世界上數位身分證實施最成功的愛沙尼亞X-Road系統，但卻沒有向他們汲取經驗，空有其名。捨實戰成功的科技不用而閉門造車，徒增技術風險而已。