目前分類:他山之石 (5)

瀏覽方式: 標題列表 簡短摘要

前言:美國政府數位服務教戰手冊(U.S. Digital Service Playbook)(上)

  1. 帶入有經驗的團隊成員(Bring in experienced teams)
  • 此處所謂的經驗包含了專案管理、軟體工程跟設計的經驗,例如團隊裡面應該有這些成員:
  • 打造過受歡迎且高流量的數位服務
  • 處理過數位服務的資安議題
  • 評估過不同第三方技術選項或管理過委外專案
  • 開發過行動與網頁應用程式
  • 使用過自動測試框架,有系統部署(DevOp)經驗(例如知道什麼是Continuous Integration)
  • 另外也必須有外部夥伴支援預算處理及法律議題

如果不把乙方算進我們的團隊,且將第一點的「打造」跟第二點的「處理」解釋成「委外處理」,我想甲方團隊勉強能滿足前三項,而最後一項通常有其他部門(總務、法規會)支援;如果連乙方團隊都算進去,我想還是沒辦法滿足倒數第二項,可能是我看得太少,至少我之前接觸過跟聽過的廠商,沒人在做自動化測試(有手動迴歸測試就要偷笑了),更不用說Continuous Integration或較新的DevOp觀念了(當然,甲方也不懂)。

  1. 選擇現代化的解決方案架構(Choose a modern technology stack)

我們數位服務的技術架構必須與時俱進,才能讓專案有效率及省成本地進行,並且容易擴充。不管是在選擇基礎架構、資料庫、開發框架、程式語言或其它技術選項時,都應該選擇符合潮流、避免被單一廠商綁定、且現今大多數企業用來打造類似服務時所採取的方案。

資訊人在政府 發表在 痞客邦 PIXNET 留言(0) 人氣()

[20150925 更新] 美國政府最近更發布了官方網站設計指南相關中文報導

2013年10月,美國政府的HealthCare.gov網站上線,目的是讓沒有自行營運網站的各州,其居民能夠輸入資料、搜尋配對適合自己的醫療保險公司以及相關補助,也是俗稱Obamacare健保政策的一部分。結果這個花了五百萬美金打造的網站,竟無法應付龐大的流量,上線後的一週內只有1%的人能夠完成他們的查詢及送件,且就算資料送到了後端,很多醫療保險公司反應收到的資料並不齊全,更不用說網路上數百個假健保網站橫行,媒體還報導網站本身會將民眾個資分享給廣告公司,總之這個網站是個大災難,最後請了一位在google工作八年的可靠度工程師Mikey Dickerson來解決,而事後評估整個網站的成本高達17億美金,此事件詳情可參照維基百科

有了這個慘痛的教訓後,2014年8月,美國政府啟動了國家數位服務小組(U. S. Digital Service),由Mikey Dickerson領導,讓其他政府部門在數位服務設計的初期就能要求諮詢,以免HealthCare.gov的災難重演。同時白宮也釋出了一本「數位服務最佳實務(U.S. Digital Service Playbook)」,內容包含了打造數位服務的13個最佳實務,每一項都附有觀念說明、檢核項目(checklist)與關鍵問題(key questions),可說是內外功兼備,非常值得我們政府及資訊人員參考。

文章標籤

資訊人在政府 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近讀到一份 "2014 Federal Plain Language Report Card",是一份由民間機構檢驗美國聯邦政府各行政部門對於 ”Plain Writing Act” 的遵循程度的報告。該報告從法案遵循 (compliance)、書寫 (writing)、及資訊設計 (info design) 三個項目評估各部門是否能夠以簡單明瞭的方式說明政府的服務或法規,提出改進建議,並將結果公諸大眾檢視,以督促政府繼續改善。值得我國參考。

此報告所謂何來?這就要追溯到美國國會在 2010 年通過的 “Plain Writing Act“ (暫譯為「直白書寫法案」)。此法案規定美國政府的行政部門必須以直白的方式書寫公開的政府文件,以增進人民對政府資訊跟服務的了解。該法案有以下幾點規定:

  1. 以直白的方式書寫公開的政府文件 (Plain writing)
  2. 訓練員工以 plain writing 的方式寫文件
  3. 機關內部需建立一套流程自我檢測對該法案的遵循程度,對外則需在機關網站設置專區說明此事,且至少一位聯絡人,接受公眾反饋。

什麼是以直白方式書寫?wiki 上給了一個清楚的例子。原文是這樣:

資訊人在政府 發表在 痞客邦 PIXNET 留言(0) 人氣()

對於國防所需的軟體及其開發流程,或許有不少人認為有保密及封閉的必要,但美國國防部在2011年5月釋出的技術報告Open Technology Development: Lessons Learned and Best Practices for Military Software中卻指出,開放式技術發展 (Open Technology Development, OTD) 才是對於機關長期有利的作法。藉由分散且協同的開發方式,及遵循開放資料格式而打造的開源軟體 (Open Source Software, OSS),或至少是政府內可自由流通的軟體(Open Government Off-the-Shelf Software, OGOTS),不僅能增加專案的敏捷性、彈性及安全性,也能讓政府內有限的人力資源專注於創新、免去重新造輪子的白工,更能降低專案成本,有效維持公部門開發之軟體的競爭力,因為承包商知道他們是可以被替換的。

資訊人在政府 發表在 痞客邦 PIXNET 留言(0) 人氣()

網路上充斥著許多描述雲端運算的文章,在我看過的說明中,NIST這一篇算是相當簡明且完整的,可資參考。這篇文章中提到雲端運算由5個基本特徵、3種服務模式及4種佈署模式組成。5個基礎特徵分別是:

  1. 自助式隨需服務(On-demand self-service):客戶可以依其需求索取計算資源(例如伺服器或儲存空間),且整個過程是單方面自動化的,無須與資源提供者互動。
  2. 廣泛網路接取(Broad network access):服務是經由網路提供,且有標準機制能讓不同的客戶端平台(如智慧型手機及筆電等)都可以使用。 
  3. 共享資源池(Resource pooling):服務者所提供的計算資源,例如儲存空間、網路頻寬、計算能力、虛擬機器數量等,可類比為一個大水池,能隨時依需要(重新)分配給不同平台的多個使用者。使用者不需了解資源的實體位置,只要有抽象概念即可(如資源是在哪個國家或哪個資料中心)
  4. 快速的彈性(Rapid elasticity):計算資源不僅可以快速且有彈性地被提供或釋放,且對客戶而言,資源是取之不盡且可以恣意購買的。
  5. 可量測的服務(Measured service):計算資源可依其所提供的服務特性被自動控管及最佳化。提供者與使用者雙方都可透明地監控資源使用情形。

3種服務模式指的是SaaS、PaaS及IaaS,這部份就無庸贅言了。最簡單的例子:

  • SaaS:Gmail、Saleforce CRM
  • PaaS:Google App Engine、MS Azure
  • IaaS:Amazon EC2

 4種佈署模式則是指私有雲、社群雲(community cloud,數個組織因共同利益考量所建構者)、公有雲及混合雲,這部份也很簡單易懂。原文在NIST IT Lab網頁的這裡,;國網中心也有翻譯這篇文章的一部分。另外,ptt的Cloud板也有板友提出了雲端服務的4A2S特性,我認為也很恰當:

文章標籤

資訊人在政府 發表在 痞客邦 PIXNET 留言(0) 人氣()

找更多相關文章與討論