概念地圖・整合成熟度等級
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
整合成熟度等級：沿著介面補齊交接證據
儀器吐出的檔案能開，報告系統也顯示匯入成功；校正實驗室的技師盯著單位欄，發現「毫伏」在交接時變成了「伏」。資料有送到，意思在半路走失。整合成熟度等級（Integration Readiness Level，IRL）把兩項技術之間的介面拆成九級證據：從辨識關係、確認相容，到資訊轉譯、系統環境測試與任務實證。它讓交接會議有一個具體追問——這條介面，在什麼條件下，已經證明到哪裡？
九級證據，沿著介面逐步補齊
先圈定一對技術及其交接邊界，再沿著定義查證。右欄是校正實驗室可以準備的紀錄示例，完整性仍須由具體應用決定。
| 級別 | 定義重點 | 可留存的證據示例 |
|---|---|---|
| 1．介面辨識 | 辨識介面，細節足以描述兩項技術的關係。 | 儀器匯出端與報告匯入端的介面關係圖。 |
| 2．互動特徵 | 具體描述透過介面產生的互動及影響。 | 資料由誰送出、何時送出、如何影響報告欄位。 |
| 3．相容 | 以共同語言支持有秩序、有效率的整合與互動。 | 檔案格式、欄位名稱與單位語意的共同約定。 |
| 4．品質保證 | 整合的品質與保證已有充分細節。 | 資料完整性、錯誤檢出與品質檢查規格。 |
| 5．控制 | 具備建立、管理與終止整合所需的控制。 | 啟動匯入、管理交接狀態、停止處理的測試紀錄。 |
| 6．資訊處理 | 能接受、轉譯與結構化預定應用所需資訊。 | 毫伏轉伏、空值與異常值的處理結果。 |
| 7．驗證確證 | 整合已完成驗證與確證，足以支持取得或導入決定。 | 對照需求與使用目的的驗證、確證報告。 |
| 8．系統環境合格 | 完成實際整合，經系統環境的測試與展示而任務合格。 | 在指定整體環境執行端到端作業的測試結果。 |
| 9．任務實證 | 由成功的任務運作證明整合。 | 在聲明範圍內完成實際工作任務的可追溯紀錄。 |
這裡採用 Sauser 等人於 2010 年提出的九級定義，見 NASA 2016 年技術成熟度評估研究報告第 6.8 節、第 46 頁。該報告把其他成熟度量尺列作參考，當時未建議採為 NASA 官方量尺，研究建議也未必獲機構接受。圖中三個括弧只是本文的導讀分組，右欄亦為應用示例——別把圖旁的文件名稱誤讀成新的認證要求。
認列一個等級，要追問四個細節
一、先把評估對象縮到一條交接線。「實驗室系統整合完成」太大。這次要看的是哪台儀器的哪個匯出程式，接到哪一版報告系統的哪個匯入模組？把資料方向和邊界寫下來，工程師才知道該拿哪份紀錄——隔壁儀器順利匯入的結果，適用範圍另算。自問：被評估的是哪一對技術，以及它們之間哪一條介面？
二、每項主張都有一份對得上的紀錄。螢幕顯示匯入成功，只說明這次處理走到了那個訊息。技師還要把來源毫伏、目標伏、預期結果與實際結果並排，檢查資訊如何轉譯。若主張已到驗證確證，就補上需求、使用目的及相應結果——把證據接到定義的動詞上。自問：手上的證據，具體支持哪一項等級定義？
三、把「測過」展開成可重現的工況。實驗室保留正常資料以外，還要測空欄、超出範圍的讀值、不同單位和中斷後重送。測試紀錄寫清楚操作順序、環境設定與結果簽署者。下一班看到記錄就能照做，才有辦法確認前一班留下的結論——順利的截圖少了這些前提，查起來很慢。自問：證據是在什麼測試工況與操作情境下取得的？
四、更新一次，就重查受影響的範圍。儀器韌體改了欄位、匯入模組更新了換算方式，或報告範本換了單位顯示，都可能改變原本的交接假設。先用變更差異圈出要重驗的部分，再保留仍適用的舊證據——紀錄上的版本號，在這時才真正派上用場。自問：版本或使用條件改變後，原證據還適用到哪裡？
校正實驗室的報告介面，停在單位轉換這一關
底下這家台灣中部的校正實驗室，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。
- 先追回那筆數值：技師從原始檔找到毫伏欄，沿匯入對照表追到報告的伏欄。兩個欄位名稱看似都指向電壓，途中少了明確的單位換算處理。畫面上同一串數字，已經換了意思。
- 限定這次發現能說明什麼：團隊記下這組版本與資料路徑的異常，標示與第六級資訊轉譯有關的證據待補，再清查影響範圍與既有測試。一筆錯誤先成為可追查的問題紀錄。
- 讓測試碰到容易漏掉的地方：修正後重跑毫伏與伏的對照資料，加入空值、負值、超出設定範圍的讀值及重送情境；每筆保留預期結果、實際結果與處理方式。只重跑剛才那筆，其他路徑仍有待確認。
- 把驗收交回使用結果的人：資訊人員整理欄位定義、異常值規則、兩端版本與操作情境，技師核對報告用途，再由約定的結果簽署者留下紀錄。匯入端、使用端與責任人終於看見同一份證據。
這件事值得記住的接縫，是檔案格式與數值意義之間那一步。單位錯置揭露了資訊轉譯的待補證據；介面的確切等級，仍須連同既有紀錄、適用版本與測試範圍一起評估。團隊也要追查哪些報告經過同一路徑，依內部程序處理受影響結果，保留調查和修正過程。等級討論因此有了起點——先讓下一位接手的人重現這次錯誤，再讓他看懂修正後的結果。以上為說明結構用的示意情境，僅供理解框架之用。
整合成熟度什麼時候會騙你
- 借單機文件替交接背書。儀器自身的測試紀錄與報告系統各自的品質文件，都有原來的適用範圍。兩端接起來後，欄位、單位與例外處理還需要成對確認。開會時把每份文件畫回它覆蓋的邊界，空白處就留下待補項目——各自做得好，仍要檢查交接處。
- 把階梯當成按日曆升級。排程可以寫月底完成某項測試，等級要等證據支持才認列。日期到了、整合負責人換了，或投入工時增加，都不會自動完成轉譯與驗證。每次追進度請對方拿出新增紀錄，連同失敗與未測項目一起看——走了多久，留在專案日誌裡。
- 幾筆順利資料就宣稱任務實證。實驗室挑熟悉的檔案演示，容易避開單位混用、缺欄與重送。第九級涉及成功的任務運作，必須先說清任務和適用範圍，再檢視實際紀錄。示範成功可以留作證據的一部分，外推時要把條件一併帶上——換了工況，結論就需要重查。
交接成功的訊息背後還有誰在補洞
報告等著簽名，介面的決定也該讓技師在場。
匯入成功的提示跳出來後，技師還得逐欄對照、打電話問單位，再等資訊人員確認。這些補救動作若散在私人筆記與口頭交代裡，下次值班的人還得重走一次。《痛點》的 P.A.I.N. 提醒我們，把承受後果的人放回分析中心：誰在查錯、誰在等報告、誰要向使用結果的人說明？這張圖畫得出整合證據的位置，畫不出簽名之前那份不敢相信數字的遲疑。成熟度要對使用者有價值，證據就得走到他手上，讓他知道哪些結果已被檢查、遇到異常該找誰、何時能停止人工補洞。今晚找出最近一次匯入錯誤，把當時技師的核對步驟帶進下一份測試紀錄——連同他最後確認結果的那一刻一起留下。
常見問題
整合成熟度 IRL 和技術成熟度 TRL 有什麼差別？
TRL 關心一項技術在指定條件下的成熟證據；本篇 IRL 關心兩項技術透過介面互動的證據。套到校正實驗室，儀器本身經過哪些測試是一條線，資料如何轉入報告系統又是一條線。實務上可以把兩種評估並排，但要各自標清對象、版本及環境，避免把儀器成熟的結論直接搬到匯入流程。
這套九級 IRL 是 NASA 的官方認證嗎？
本篇引用的是 Sauser 等人的九級架構，以及 NASA 2016 年研究報告所列的參考表。該報告第 6.8 節說明，研究團隊當時未建議把這些其他成熟度量尺採為 NASA 官方尺度。使用時應註明採用的定義、評估方式和適用範圍；這張圖提供的是討論與查證架構，不能拿來宣稱取得 NASA 認證。
遇到一次單位錯誤，就表示整條介面沒到第六級嗎？
先把它記為特定版本、資料與工況下的異常，追查資訊轉譯的證據缺口。要認列整條介面的等級，還需要檢視評估邊界、既有紀錄、錯誤影響及修正後測試。只靠這一筆資料不足以給出精確等級，也不足以宣判所有歷史測試失效——先限縮能支持的結論，再安排需要補做的查證。
第六級到第七級，還要多準備什麼？
第六級聚焦預定應用所需的資訊能被接受、轉譯與結構化；第七級要求整合完成驗證與確證，足以支持取得或導入決定。除了欄位與換算測試，還要把整合需求、實際使用目的、相應測試結果和未解問題接起來。決策者才能評估：這份證據涵蓋了哪些用途，哪些使用條件還需要補查。
換到元件本身就讀技術成熟度；提案桌上的投資準備度則使用另一套 IRL。回到手邊那份報告，沿著一個數字往前追，讓每次單位轉換都有紀錄可找。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。