(案例) 公部門・教育・Polish 3D / Polish AI / Polish+

教師於單一平臺查詢場域,完成教學行程規劃

全臺教師安排戶外教學行程時,需要搜尋各場所資訊並交叉比較。平臺整合全臺戶外教育場域,讓教師在地圖上探索場地、評估距離並規劃教學行程。

預約第一場會議

教師於單一平臺查詢場域,完成教學行程規劃
產業
公部門・教育
服務
Polish 3D、Polish AI、Polish+
規模
由 5 個場域起步,近期單週 60+ 場域加入

(挑戰)

場域資訊分布在多個系統,規劃行程需要整合查詢

教師安排戶外教學行程,需要在教務之外抽出時間,搜尋各種場所資訊並反覆交叉比較,也需要參考其餘教師的經驗與口碑,才能確定場地是否適合。

平臺原本的開發重點在建置與管理資料。各縣市各有戶外教育資料,教師規劃一次教學行程,需要在多個系統間切換查詢,搜尋與使用的流程是這次要整合的部分。

平臺入口頁面翻新前後對比。
平臺入口頁面翻新前後對比。

(做法)

向商業平臺學習,把地圖變成探索工具

與教師逐步訪談後發現,戶外教學資源已不限於傳統遊憩場所:文史館、生態場域到社區小店,只要行程安排具教育意義,都能成為合適的教學資源。

團隊研究了商業遊程安排網站,並訪談第一線教育人員,歸納出需求:教師需要知道這個地方適合教什麼、離學校多近;過多細節(如國道交通方式)反而使資訊變複雜;搜尋與挑選場地要簡化,像網路訂飯店一樣方便。

因此重點放在高度客製化的互動地圖,讓使用者好逛且好找。

桌機錄影:縮到單一縣市,點場域,左欄看適合教什麼與距離。

(關鍵設計)

三項關鍵設計

互動地圖

使用者能像使用地圖服務一樣,輕鬆找到並儲存附近的教學場域,也能上傳分享自己的戶外教學安排經驗,探討教育現場情況與處理方式。場域提供方,如博物館與農場,可自行上架活動資訊供參考。

路線體驗:地圖上標出行程路線,左側顯示場域資訊。
路線體驗:地圖上標出行程路線,左側顯示場域資訊。

桌機

清單與地圖並排,篩選即時更新

場域清單與互動地圖並排,可依主題、季節、設施、開放時間、收費、交通與學齡篩選,清單與地圖上的場域隨之更新。放大地圖時,聚合的數字逐步展開為單一場域;畫面右下的專屬動物角色提供即時協助入口。

桌機螢幕錄影:捲動場域清單、以主題與季節篩選,並縮放互動地圖。

專屬角色

為平臺設計一系列專屬動物角色,作為平臺形象。角色適合親子闔家,參考歐、美、日等國戶外教育領域的成功經驗,兼顧觀光宣傳與場館展示;代表陸域教育的山林物種與象徵海洋教育的海洋生物,在筆觸、風格與肢體設計上各有特化。

設計元素:場域卡片、月份切換與角色。
設計元素:場域卡片、月份切換與角色。

積木式模組

系統拆為可重複使用的模組:多角色登入與權限系統、即時更新的互動地圖模板、自動化資料編輯器(一次上傳數百筆資料並自動檢查格式),以及結合公文作業與敏捷開發的工作流程。需求變動時,只需依優先順序調整與部署模組,省下溝通時間與開發成本。

會員系統的個人頁面。
會員系統的個人頁面。

(交付與驗收)

依需求書驗收,並留存維運紀錄

配合主管機關要求的掃描、修補中高風險與誤判申覆,並由設計標承接到工程標。

文件名稱與數量先逐字對齊,再談報價與分工。

驗收依據在需求書,所以雙方的分工從逐字整理需求書開始
需求與報價
履約與維運
驗收
機關
開發團隊
1
機關需求書列出文件名稱、數量與格式
2
開發團隊逐字抄成清單對照構想,三欄都沒有的移出範圍
3
機關監督並定期稽核施行細則第七條
4
開發團隊腳本產出維運檔案完整性、日誌、月報
5
機關初驗與正式驗收留下驗收紀錄
6
開發團隊依字面名稱與數量提交文件義務獨立列項

依政府採購法、施行細則與資通安全法規的委外規定整理

看完整內容 公部門專案的交付與維運證據:需求書、查核條文與唯讀腳本

配合主管機關的掃描,由開發團隊判讀與修補。

掃描結果分兩條路:誤判逐項申覆,中、高風險項目由開發團隊修補
  1. 主機弱點掃描得到掃描結果
  2. 有人判讀掃描器誤報率高
  • 誤判的項目
    申覆一項一項來
  • 中、高風險項目
    修補由開發團隊負責
看完整內容 弱點掃描與滲透測試的差別:法規頻率與配合公部門的經驗

有需求書與資安義務的專案,可由第一場會議逐項對照範圍。

(成果)

場域由 5 個起步,近期單週 60+ 場域加入

平臺草創之初只有 5 個場域進駐。隨著平臺建置成熟,教師持續給予設計回饋,參與度與資料上傳量明顯增加,近期達到單週 60+ 場域加入。

專案涉及多個部門與較複雜的決策層級,與主管機關共同導入新的工作方式:訊息改以可追蹤、可分類的協作平台傳遞,文件全面採用可線上協作的版本,並建立任務卡片,讓每項更改、開發與調整的進度一目了然。

溝通效率與協作文化因此提升,合作關係也由委外廠商轉為平臺的夥伴團隊。

平臺手機版展示:地圖、場域頁與月份切換。
平臺手機版展示:地圖、場域頁與月份切換。

手機

手機以清單為主,地圖按需展開

手機先以清單瀏覽場域,點選地圖顯示後展開全螢幕地圖,場域聚合、名稱標籤與類別圖示隨縮放更新,左下角的「返回列表」可隨時回到清單。

手機螢幕錄影:由清單開啟全螢幕地圖,縮放並拖曳。
手機錄影:地圖與清單按需展開。

(工程紀錄)

做法與實測,逐張可展開

弱點掃描與滲透測試的差別:法規頻率與配合公部門的經驗

弱點掃描列出可能的問題,滲透測試看能走到哪裡
弱點掃描列出可能的問題,滲透測試看能走到哪裡

弱點掃描

  • 辨識系統作業系統、應用程式、開放的通訊埠
  • 對照已知弱點資料庫過期版本、缺漏修補、錯誤設定
  • 列出清單誤報率高,要有人判讀
掃描結果

滲透測試

  • 找出可能的標的常從弱點掃描的結果開始
  • 串接多個弱點模擬真實攻擊
  • 看能走到哪裡能拿到多大權限,防守者能否偵測

依 NIST SP 800-115 意譯整理。

看完整內容
法規規定的檢測頻率
責任等級弱點掃描滲透測試
A 級全部核心資通系統每年辦理二次全部核心資通系統每年辦理一次
B 級全部核心資通系統每年辦理一次全部核心資通系統每二年辦理一次
C 級全部核心資通系統每二年辦理一次全部核心資通系統每二年辦理一次
看完整內容

公部門專案的交付與維運證據:需求書、查核條文與唯讀腳本

維運檢查有週期,每週兩項、每月一項
維運檢查有週期,每週兩項、每月一項
每週執行每月產出
第一個月第二個月
  • 完整性
    每週,與上一週比對
  • 日誌彙整
    每週,彙整近一週
  • 系統月報
    每月 1 份

只畫來源記載週期的三項;磁碟用量警示依門檻觸發,還原演練另述於正文,均不畫入。位置僅示意頻率。

看完整內容
配合主管機關的掃描與申覆

弱點掃描報告拿到之後:修補優先序、誤判申覆與複測

掃描與複測在第三方,分類與修補在開發團隊,業主在中間確認
掃描與複測在第三方,分類與修補在開發團隊,業主在中間確認
報告
分類
修補
複測
第三方
業主
開發團隊
1
第三方掃描與檢測,出具報告由具備資格的第三方執行
2
業主收下報告,轉交開發團隊
3
開發團隊逐條重現,分為真問題與誤判每一條附上理由
4
業主確認分類結果與申覆內容
5
業主確認本輪範圍與暫不修補的項目
6
開發團隊依可被利用的程度修補保留修補前後的對照
7
第三方複測,判定各條是否通過
8
開發團隊說明每一條的修補,並提出證據

分工示意;實際分工依各專案的合約與機關要求而定。

看完整內容
先確認是不是真的,再看能不能被利用,每一條發現只會走向三條路之一
先確認是不是真的,再看能不能被利用,每一條發現只會走向三條路之一
  1. 重現這條發現在測試環境照報告的請求重送
  2. 對照系統的實際設定版本、路徑與現有緩解措施是否與報告相符
  • 可重現,且能從外部直接利用
    立即修補修補前後各留一份請求與回應的對照
  • 可重現,但需要特定前提,或已有緩解措施
    排入下一輪記錄前提與排後的依據
  • 無法重現,或與系統的實際設定不符
    提出誤判申覆附上重現過程與設定證據
看完整內容

軟體外包廠商的評估表與簽約前查核項目

預想的功能表最後才看,範圍靠逐項對照定下來 相關做法
預想的功能表最後才看,範圍靠逐項對照定下來
依序讀
逐項對照
結果
客戶資料
開發團隊
1
客戶資料義務文件客戶對第三方的義務與查核條文
2
客戶資料既有系統
3
客戶資料預想功能表通常比合理範圍大 1.5–3 倍
4
開發團隊逐項對照有無要求、報價有無涵蓋
5
開發團隊移出範圍兩者都沒有的項目
看完整內容
查核資安與維運:實績、複測紀錄、SLA 依序確認 相關做法
查核資安與維運:實績、複測紀錄、SLA 依序確認
  1. 同類專案實績規模與擔任的角色
  2. 掃描與複測紀錄發現項目如何修補
  3. SLA 寫進合約
  • 三項都對得上
    進入報價比較
  • 說不出紀錄
    請廠商補件

SLA 的內容依專案約定,重點是寫進合約。

看完整內容
評估表:逐列向廠商確認 相關做法

接手既有系統的全碼健檢流程:從候選問題到可交付的報告

約七十條候選問題,反證後近一成被駁回,其餘進報告 相關做法・數字來自其餘專案
約七十條候選問題,反證後近一成被駁回,其餘進報告
  1. 候選問題約七十條七個面向平行掃描後合併,逐條回程式碼驗證
  2. 反證時被駁回近一成多半是前人刻意留下的補丁
  3. 進入報告約六十條分成紅燈、黃燈、綠燈

一次完整的健檢;數字為約略值

看完整內容
每一條發現都要判定去向:立即修、排程修,或留著並記錄 相關做法
每一條發現都要判定去向:立即修、排程修,或留著並記錄
  1. 回程式碼驗證確認問題確實存在
  2. 刻意找理由推翻查證是否為前人刻意留下的補丁
  • 會傷到人、掉資料或被攻擊
    立即修列為紅燈,寫明誰該修與估時
  • 有風險,但還不到紅燈
    排程修列為黃燈,排進接手後的維運
  • 看起來像缺陷,查證後是刻意的補丁
    留著並記錄寫下為什麼不能拆,避免後人誤修
看完整內容
第一個月先看清現況、先處理紅燈,舊問題不翻修 相關做法
第一個月先看清現況、先處理紅燈,舊問題不翻修
接手前
健檢
紅燈
新程式
客戶
開發團隊
1
客戶備妥資料原始碼或其存取權、目前的部署方式、最近半年出過的問題
2
開發團隊掃描、驗證、反證七個面向平行掃描,逐條回程式碼驗證,再刻意找理由推翻
3
客戶閱讀報告並定次序誰該修、估時都寫在紅燈條目裡
4
開發團隊先修紅燈每個修正附一個壞了會失敗的檢查
5
開發團隊新程式守規則參數化查詢、擁有者檢查、回呼驗簽

階段表示先後順序,不是固定天數

看完整內容

(Client note)

戶外教育資源平臺很幸運能遇到磨人團隊來協助架設網站,過程中他們善用各種工具軟體,一步步引導我們討論並釐清問題。特別讓人安心的是,他們不只是處理表面狀況,而是透過細緻的討論與分析,有效地帶領我們掌握到核心問題,最後才能順利推出目前這個令人滿意的戶外教育資源平臺。
LaiPlatform PO・NUTC

第一場會議 15 至 30 分鐘,取得做法方向、預算區間與時程草案。

Polish 3DPolish AIPolish+下一項專案:棟、層、戶到室內 360,整合為一條看屋路徑

(聯絡)

Start a project.

三個步驟,取得可判斷的做法與預算區間。

  1. 01預約第一場會議:選擇時段,不需要完整規格。
  2. 02線上諮詢 15 至 30 分鐘:取得做法方向、預算區間與時程草案。
  3. 03檢視素材後,約 3 至 5 個工作天提供報價單暨交付規格明細表。
信箱
hello@polish-design.com.tw
通訊地址
(104) 台北市中山區植福路191-1號3F

預約第一場會議

週一至週五 16:00–18:00線上 30 分鐘

先選時段,再用 Google 帳號或信箱確認,預約完成可加入行事曆。

選擇時段

或先送出資料

還沒想好時段,可以先留下專案內容,專人以信箱回覆。送出後也能接著預約。

補充資料(選填):服務項目、目前階段、現有連結、得知管道

資料僅用於本次專案評估。

ISO/IEC 27001:2022 證書

(Certificate)

ISO/IEC 27001:2022

驗證機構
ARES International Certification
驗證範圍
互動沉浸式 3D 系統之開發流程,及網路與基礎設施之維運與管理。

到驗證機構網站查證