Common voice 句子庫 === 來源：2017-06-03 報稅軟體後續規劃會 --- https://sayit.pdis.nat.gov.tw/2017-06-03-%E5%A0%B1%E7%A8%85%E8%BB%9F%E9%AB%94%E5%BE%8C%E7%BA%8C%E8%A6%8F%E5%8A%83%E6%9C%83 有英文的部份： --- 大家認為 OK 的時候 找專家研訂UI、UX規格及公開徵求民眾協作 像 Java 廠商已經不建議使用 不使用 Java 的替代方案是什麼？ 但你們的 Web 版是已經在身分認證之後的 不可能全部的人丟掉 Windows 離線版 然後去用 Web 版 第二個是目前 3G 的合約 會不會因為 connection 太大，造成民眾等待時間過久 是不是把後面的scale做大一點 因為其實很多人不知道有 Web 版 所以還沒有看到以 Web 版流程為主的設計 把 CSS 、字形換掉跟你們的壓力測試是沒有關係 當然財資中心是絕對不可能幫 Oracle 補漏洞 北部的 AP server 有六部 中部有四部 AP server 接下來有兩個報稅的 DB server 另外一個是我們真正報稅的所得資料 server 純中文： --- 我是財政資訊中心鞏小花 針對上次的協作會議 整個討論的成果丶議題牽涉到很多對象 打算成立一個工作小組 對這七項建議研討及規劃 整個規劃跟運作的時程就如下列的期程 像七月會成立工作小組 八月至十一月進行整個需求的研討、規劃及開發 十二月會進行第一次的系統驗證 一至二月會針對系統驗證再提出一些精進修改 三月份會進行第二次驗證 接著是針對協作會議所提出的問題 建議及改進的方式 我們擬訂一些具體規劃及時程報告 提供白話說明 申報網站登入畫面 只留畫面上最重要的訊息 這一個部分我們規劃在一百零六年八月份 會邀請使用者代表、賦稅署、國稅局 共同研議相關的內容及說明 由部落客宣導 我們會透過工作小組運作 於一百零六年七月起 五區國稅局服務科 請針對系統改善進程 與網路部落客互動 一個人差不多三十分鐘左右 會規劃邀請部落客參與兩次驗證作業 這一項作業會納入經常性的辦理事項 每一年四月份會加強這一部分的宣導 進行參與式工作坊 規劃一百零六年八月份依工作小組時程 適時邀請部落客、首報族等二十人 藉由開放式的研討，蒐集有效、可行建議 作為系統改善參考 納入一百零六年規劃綜合所得稅辦理 有關於報稅流程的部分 目前反應到的問題 不知道要準備什麼東西 元件安裝跟介面老舊的問題 增加流程引導機制 提示簡單的流程進度 並提示完成百分比 在一百零六年八月份邀集使用者代表、賦稅署及五區國稅局 共同研議修改及相關說明 一百零六年綜合所得稅結算申報時會上線 就是明年？ 解決方式是有各個平台安全元件、認證標章取得 參考大廠設計、不需要讓使用者進行安全性設定更改 這個部分我們規劃在一百零六年七月起 邀請賦稅署去國稅局研商 納入一百零八年開發標案需求規劃書中 這個部分沒有？ 我們等一下再討論 第四期的部分 在一百零八年綜合所得稅結算申報上線 這個部分會納入工作坊的研討議題來作規劃參考 有關於易用性的部分 也就是讓用戶感覺放心、要有使用者測試 美感與設計感、整合所有環境元件一次安裝 邀請使用者代表、賦稅署及五區國稅局 溝通研議修正內容及相關說明修改 訂定相關需求，進行全面整體規劃設計 我作一個補充 不是要驗證，而是現在就要開始規劃 把需求規格訂出來 只是花一年跟花兩年看到的差別而已？ 接著是簡化報稅查詢碼的部分 我們是戶政、申報資料及健保卡資訊作為核發查詢碼之身分辨識 申報的時候會配合戶號跟出生日期申報 這個納入工作坊討論議題 這只是初步的構想 這個是針對大家討論之後作為規劃設計的參考 這個是免讀卡機的部分？ 第三個是以限定操作次數為前提的設計 因為有前、中、後三層滿意度調查 並且清楚說明滿意度調查的目的 目前先將滿意度的部分移到申報完成時再詢問 在系統雛形建置完成之後 納入專家及使用者建議 關於遙測的部分 是每一年申報一次 並不是經常性改版 開發標案是從你開標、招標到得標 開發期是多久？ 這個標案不僅是綜所稅申報而已 包括所有的國稅網路申報 例如營所稅、遺產稅、贈與稅及營業稅等等 所有的國稅申報都在這一個標案中，所以是很大的系統 補充說明 營業稅是營業人，營所稅是營利事業 各稅範圍及其使用者本身的特性不太一樣 可能就不會認為我們講得不夠白話 對稅務法令或專有名詞已經有一定程度的熟悉 我們會根據使用者不同而做不同的考量修正 例如遺產稅、贈與稅網路申報軟體 使用者可能多屬一般民眾 網路申報軟體使用者 對於稅法可能不瞭解 對於慣用的專用名詞也不是很清楚 我們盡量朝淺顯易懂的方向來改進 很多是委託專業代理人 如記帳士或者是會計師，他們都是專業人士 反而需要一個比較精準的法律說明 實務上透過每年檢討機制，不斷在改進當中 其實每一年都有精進 協作會議建議的解決方式 不要以書面的邏輯來設計介面 可以分為簡單版及完整版 辦理介面設計競賽 新舊介面並行 並使用最新軟體工具建教合作 是找產官學合作 想問比較簡單的點 在整個案子當中有納入協作精神在裡面 所以不使用這個 有提到了請使用者代表及外界的專家學者來討論協作 我們注意到這一次政府跟外界合作看起來是比較密切的 那麼這些民間朋友會不會得到相對的報酬 比如車馬費這一類的 至於額外的報酬，政府有一些限制 採用的技術不要彈出不安全警告的技術 那個幾乎是不可能的事情 我們後段的機器可不可以承載這麼長時間的連結 這個是我們要考量的地方 現在的設備是不是可以支援前端程式改寫 本來測試的時候只有好比像千分之三的人來報稅 並沒有一半的使用者突然用手機報稅的量 你們現在測試的量是多少？ 不到一萬個。 我們一般是壓測三倍到七倍 在行動版的合約裡面是沒有要求壓測作業 但是我們實際上有做 所以像剛剛中心長官說的 大概是在五萬上下 長期觀察市場使用的狀況 使用者大概是一萬上下而已 假設沒有做任何改變的時候，很難瞬間飆高 這上面還有身分認證元件的設計考量 這不是單一方面關貿配合就可以解決 我是在另外一個畫面取得完身分認證查詢碼才輸入 理論上這邊的壓力，是從取得查詢碼開始算 還是要花三十分鐘安裝 裝完之後會有很舒服的過程 但是已前面經花了三十分鐘 這樣我們做其他的意義好像滿小的 如果真的大改是牽涉到兩個合約 第一個是行動版的合約 為什麼考慮離線版？ 現在遠端很多機房的概念 到底用離線版的效益比較大，或者是用線上版 使用者認證我想暫時不改要用讀卡機 我們是用查詢碼的方法來做 我們是不是可以用預備金來解決 我覺得是有可能性的 我們再跟關貿洽談這一件事 人力的調度 當然會有一段時間需要學習、轉銜之類的 理論上同時連線的人數不太是問題 因為大部分的運算量其實非常小 只是要有一個連結在那邊 並不是伺服器幫使用者作運算 都只是做加減乘除的事情 所以重點是在之前的壓測，看那個瓶頸在哪裡 看是否能克服 把動態式的後端機器變多的方式來調節 比較好的網頁伺服器有比較好的連線量 技術團隊先不看合約的問題 因為合約的問題，中心會處理 我們現在先看技術面的部分 我們希望是不是可以再給中心一個禮拜的時間 假設接下來有兩百萬人同時上線的話，可負載嗎？ 你們提出來的都是合約的問題 瓶頸的部分還是要回去找原因 畢竟這個跟連線數、點擊方式及動態設計都會有關係 至少給我們兩週的時間 現在同仁都還在忙下稅後的事情 關貿完全不改程式 設計師只是調整字體大小、流程、動畫 這一些在技術上是可以脫鉤的 不會影響到他們的壓力測試 由民間來看介面上如何規劃並優化 如果要讓部落客或者是民眾知道有一個講法 很簡單就是因為「資安考量」 上次有幾個教授來給予這些寶貴的資訊 設計完之後的雛形 大家一起來檢視是否符合基本的原則 真正上線的時候，再做一次問卷調查 是不是可以達到需求 如果不滿意再修 這個案子沒有在第五階段電子化裡面 那些還有經費嗎？ 整個機器都是為了電子報稅購買的 空間設置在中華電信機房 上面還要架網路設備組 設備量不是那麼大
Last changed by  
 
Robert Wei (Freedman)
523
Published on HackMD