(案例) 政府与公共部门・教育・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 系统之开发流程,及网络与基础设施之运维与管理。

到认证机构网站查证