มาตรฐานแอปพลิเคชันภาครัฐสำหรับอุปกรณ์เคลื่อนที่

มาตรฐานแอปพลิเคชนั ภาครฐั ส�ำหรบั อุปกรณ์เคลอื่ นท่ี Government Mobile Application Standard Version 1.0



มาตรฐานแอปพลิเคชนั ภาครฐั ส�ำหรบั อุปกรณเ์ คลอื่ นท่ี Government Mobile Application Standard Version 1.0 ISBN: 978-616-8001-02-8 พมิ พค์ รั้งที่ 1 (กนั ยายน 2558) จำ� นวนพมิ พ์ 1,000 เลม่ เม่ือน�ำเน้ือหาในหนงั สอื เล่มนี้ไปใช้ ควรอ้างถงึ แหลง่ ที่มา โดยไม่นำ� ไปใช้เพ่ือการคา้ และยนิ ยอมให้ผูอ้ ่นื นำ� ไปใชต้ ่อได้ จดั ทำ� โดย ส่วนมาตรฐาน ฝ่ายนวตั กรรม ส�ำนักงานรฐั บาลอเิ ลก็ ทรอนกิ ส์ (องค์การมหาชน) (สรอ.) ช้ัน 17 อาคารบางกอกไทยทาวเวอร์ 108 ถนนรางน้�ำ แขวงถนนพญาไท เขตราชเทวี กรุงเทพฯ โทรศัพท์ 0 2612 6000 โทรสาร 0 2612 6010-12 http://www.ega.or.th e-Mail: [email protected] จดั พมิ พโ์ ดย บรษิ ทั พ.ี เอม็ . มีเดีย พริน้ ท์ จำ� กดั 1575/1 อาคารชยั สงวน ถนนเพชรบุรีตัดใหม่ แขวงมักกะสัน เขตราชเทวี กรุงเทพฯ 10400 โทรศัพท์ 0 2253 6350-1, 08 1467 8559 โทรสาร 0 2253 6352 e-Mail: [email protected]

> ค�ำน�ำ 01 กรอบนโยบายเทคโนโลยีสารสนเทศและ การส่ือสาร ระยะ พ.ศ. 2554 – 2563 ใน ยุทธศาสตร์ที่ 6 กลยุทธ์ท่ี 6.5 “ส่งเสริม ให้เกิดชุมชนหรือสังคมเรียนรู้ออนไลน์ และ การรวมกลุ่มทางสังคมท่ีเข้มแข็ง” ได้ มกี าร กล่าวถึงการส่งเสริมและการพัฒนาการจัดท�ำ เว็บท่า (Portal) ในการเข้าถึงแหล่งข้อมูล ความรหู้ รอื ขอ้ มลู ทเี่ ปน็ ประโยชนแ์ กป่ ระชาชน และสังคม โดยใช้ความร่วมมือและการสนับสนุนของหน่วยงานภาครัฐและภาคเอกชนใน การพัฒนาการให้บริการ ส�ำนักงานรัฐบาลอิเล็กทรอนิกส์ (องค์การมหาชน) (สรอ.) ได้ให้ ความส�ำคัญในการพัฒนาการให้บริการตามกรอบแนวทางของรัฐบาล จึงได้จัดท�ำโครงการ พัฒนาช่องทางการเข้าถึงข้อมูลและบริการภาครัฐ (Government Access Channels) โดยมุ่งเน้นให้มีระบบการให้บริการในรูปแบบ Mobile Applications แก่ภาครัฐ ดว้ ยการจดั ตงั้ ศนู ยก์ ลางของแอปพลเิ คชนั ภาครฐั (Government Application Center: GAC) ในการรวบรวม Mobile Application ของหนว่ ยงานภาครฐั เพอื่ ให้บรกิ ารแก่ประชาชนทำ� ให้ ประชาชนผู้รับบริการภาครัฐสามารถเข้าถึงได้สะดวก ทุกท่ี ทุกเวลา จากอุปกรณ์เคลื่อนที่ (Mobile Devices) ต่าง ๆ ได้ จากที่กล่าวมาข้างต้น สรอ. จึงเห็นความส�ำคัญเป็นอย่างย่ิงในการจัดท�ำมาตรฐาน แอปพลิเคชันส�ำหรับอุปกรณ์เคลื่อนที่ เพื่อให้การพัฒนา Mobile Application เป็นไปใน ทิศทางเดียวกัน รวมถึงการก�ำหนดมาตรฐานเชิงเทคนิคและข้อก�ำหนดในด้านต่าง ๆ เช่น การคุ้มครองข้อมูลส่วนบุคคล (Privacy Information) การรักษาความมั่นคงปลอดภัย (Security Policy)



สารบญั หน้า หัวขอ้ คำ� นำ� 1 มาตรฐานแอปพลิเคชนั สำ� หรบั อปุ กรณ์เคลื่อนที่ (MOBILE APPLICATION STANDARD) 1. คณุ สมบัตดิ า้ นการให้บรกิ าร 2 (APPLICATION FUNCTIONAL REQUIREMENT) 1.1. ลักษณะทั่วไปของแอปพลิเคชนั สว่ นตดิ ต่อผใู้ ช้งานและการใช้งานแอปพลิเคชัน 2 (User Interface and Usability) 1.1.1. ทั่วไป (General) 2 1.1.2. โครงสร้าง (Structure) 2 1.1.3. การควบคุมการเขา้ ถงึ /และการเปลยี่ นหนา้ จอ (Navigation) 3 1.1.4. การรองรบั ขนาดหน้าจอ (Supported Resolution) 4 1.1.5. ปมุ่ และองค์ประกอบทส่ี ัมผัสเพื่อควบคุมได้ (Buttons & Touchable elements) 5 1.1.6. ความสามารถในการอา่ นได้ (Readability) 5 1.1.7. ความสอดคลอ้ งกับแอปพลเิ คชนั อื่น ๆ (Platform Consistency) 7 1.1.8. คุณภาพของภาพและกราฟิก (Visual Quality) 7 1.1.9. การตอบสนองของส่วนรับขอ้ มลู จากผูใ้ ชง้ าน (Application Speed) 8 1.1.10. การตดิ ต่อกับระบบแม่ขา่ ย (Acknowledge and Notice) 9 1.1.11. การแสดงขอ้ ความแจง้ (Notification) 9 1.1.12. ข้อความแจง้ เตอื น (Warning) และแสดงข้อผดิ พลาด (Error) 10 1.1.13. การแสดงสญั ลกั ษณ์ประจำ� หนว่ ยงาน (Symbol) 10 1.1.14. ส่วนการใหค้ วามช่วยเหลือผ้ใู ชง้ าน (Help and Support) 10 1.1.15. การท�ำงานรว่ มกบั แอปพลิเคชันภายนอก (Using and Transferring Application) 11 1.1.16. การโทรศัพทแ์ ละการส่งอีเมล (Contact Data) 12 1.1.17. การเข้าเวบ็ ไซตจ์ ากภายในแอปพลิเคชนั (Browsing Website in-application) 12

หัวข้อ หน้า 1.1.18. ขอ้ มลู ที่อยแู่ ละตำ� แหนง่ ทีต่ งั้ ต่าง ๆ (Location Data) 13 1.1.19. แบบฟอรม์ กรอกข้อมลู (Text field) 14 1.1.20. การลงทะเบียนเพอ่ื สมัครเขา้ ใชง้ านและเพ่อื เขา้ ใช้งาน 16 (User Registration) 16 1.1.21. การใช้ส่อื ภาพวีดโี อและเสยี งตา่ ง ๆ (Multimedia) 17 1.1.22. การทำ� งานในโหมดเบอ้ื งหลงั (Background Process) 18 19 1.2. การรกั ษาข้อมูลส่วนบุคคล (Privacy) 19 1.2.1. ทัว่ ไป (General) 20 1.2.2. สิทธขิ องผู้ใช้งานความเป็นสว่ นตัวของผูใ้ ชง้ าน 21 และข้อตกลงในการใชง้ าน (User’s Right) 22 1.2.3. การเก็บขอ้ มลู ช่วั คราวไวใ้ นอุปกรณ์ของผใู้ ช้งาน (Cache Data, Caching) 1.2.4. การเก็บข้อมูลถาวรไว้ในอปุ กรณ์ของของผใู้ ช้งาน (Local Storage) 1.2.5. การใช้งานชุดเคร่อื งมอื ในการพฒั นาซอฟตแ์ วรจ์ ากภายนอก (3rd Party Software Development Kit; SDK) 1.3. ส่วนติดตอ่ เพ่อื พฒั นาโปรแกรม (Application Programming Interface; API) 23 และการเปิดขอ้ มลู เพือ่ พฒั นาตอ่ ยอด (Open Data) 1.3.1. ท่วั ไป (General) 23 1.3.2. API เพ่อื การเข้าถึงและการแสดงข้อมูลสาธารณะ (Public Contents’ Accessing API) 23 1.3.3. API เพอ่ื เขา้ ถงึ ขอ้ มูลทจ่ี �ำเพาะเจาะจงเฉพาะผู้ใช้งาน เฉพาะแอปพลิเคชนั และ/หรือเฉพาะผู้พัฒนา (Specific Content’s Focused API) 25 1.3.4. การเปล่ียนแปลง API (Changing API) 25 1.3.5. การก�ำหนดขอ้ ตกลงในการใช้งาน API (API Agreement)) 26

หวั ขอ้ หนา้ 1.4. การทดสอบคณุ สมบตั ขิ องแอปพลิเคชัน (Functional Testing) 27 1.4.1. ทัว่ ไป (General) 27 1.4.2. การทดสอบสว่ นติดต่อกับผู้ใช้งาน (User Interface Testing) 27 1.4.3. การทดสอบการทำ� งานร่วมกบั ระบบแจง้ เตือน 28 (Notification System) 29 1.4.4. การทดสอบการท�ำงานกับระบบเครือข่าย 29 (Network delay and loss of connection) 1.4.5. การทดสอบการท�ำงานกบั API และ/หรือระบบแม่ข่ายข้อมูล (API Testing) 1.5. สทิ ธิและข้อตกลงในการใช้เคร่อื งมอื และองค์ประกอบตา่ ง ๆ จากภายนอก 29 (3rd Party) 1.5.1. ทั่วไป (General) 29 1.5.2. การใชง้ านโปรแกรมตา่ ง ๆ (Developer’s Right and Permission) 30 1.5.3. การใชง้ านภาพภาพถา่ ยภาพกราฟิกเพลงและสือ่ ต่าง ๆ (Media’s Right) 30 1.5.4. การใชฟ้ อนต์ (Font) 31 1.5.5. การใช้งาน API และ SDK จากภายนอก (External API/SDK) 32 2. คณุ สมบัติด้านความมนั่ คงปลอดภยั 33 (SECURITY FUNCTIONAL REQUIREMENT) 2.1. ความม่นั คงปลอดภัย (Security) 33 2.1.1. การจดั การขอ้ มลู ทม่ี ีความสำ� คัญ (Sensitive Information) 32 2.1.2. มาตรการรองรบั สำ� หรับความปลอดภยั เมือ่ อุปกรณส์ ญู หาย 34 (Security on loss devices) 34 2.1.3. การติดต่อกับระบบแม่ข่ายข้อมลู (Networking) 35 2.1.4. การระบตุ ัวตนผูใ้ ช้งาน (Authentication)



1 มาตรฐานแอปพลิเคชนั ภาครฐั สำ� หรบั อุปกรณเ์ คลื่อนท่ี เวอร์ชนั 1.0 > มาตรฐาน 02 แอปพลเิ คชนั ส�ำหรับอุปกรณ์เคล่อื นท่ี (Mobile Application Standard) เพอื่ ใหแ้ อปพลเิ คชนั สำ� หรบั อปุ กรณเ์ คลอื่ นท่ี (Mobile Application) เปน็ ไปในทศิ ทาง เดียวกัน ผู้พัฒนาแอปพลิเคชัน ต้องน�ำมาตรฐานแอปพลิเคชันส�ำหรับอุปกรณ์เคลื่อนท่ี (Mobile Application Standard) ใชร้ ว่ มกบั การพฒั นาแอปพลเิ คชนั ของผพู้ ฒั นา โดยมหี วั ขอ้ ท่เี กี่ยวขอ้ งดังตอ่ ไปนี้ 01 Mต้อuงsปtฏ(บิMตั )ติ าม 02 Sคhวรoปuฏldิบัต(Sติ )าม

2Government Mobile Application Standard Version 1.0 1 คุณสมบตั ิด้านการใหบ้ รกิ าร (Application Functional Requirement) 1.1. ล(Uักsษeณr ะInทtว่ั eไrปfaขcอeงแaอnปdพUลsเิ คaชbันilitสyว่ )นตดิ ตอ่ ผใู้ ชง้ านและการใชง้ านแอปพลเิ คชัน 1.1.1. ทัว่ ไป (General) A. ส่วนติดต่อกับผู้ใช้งานต้องออกแบบโดยยึดถือ User Interface Guideline (UIG) หรือ Human Interface Guideline (HIG) ของแต่ละ แพลตฟอร์ม B. ส่วนติดต่อกับผู้ใช้งาน ผ้พู ฒั นาฯ ตอ้ งคำ� นงึ ถึงความสะดวกในการใช้งาน ความชัดเจนในการท�ำความเข้าใจ ความคุ้นเคยของผู้ใช้งานจากการ ใชง้ านแอปพลเิ คชันของแตล่ ะแพลตฟอรม์ C. ต้องมีการแสดง Status Bar เสมอ ไมซ่ ่อนจากการแสดงผล นอกเสยี จาก การซ่อน Status Bar น้ัน เป็นประโยชน์ต่อการใช้งานของผู้ใช้งาน โครงสรา้ ง 1.1.2. โครงสร้าง (Structure) A. แอปพลิเคชันต้องจัดล�ำดับความส�ำคัญ ของหน้าจอโดยค�ำนึงถึงความต้องการ ของผู้ใช้งานหรือรับบริการต่าง ๆ ผ่าน แอปพลเิ คชันเป็นหลกั B. แต่ละหนา้ จอต้องมปี า้ ยช่ือก�ำกับหนา้ จอ อยา่ งชัดเจน C. หน้าหลักของแอปพลิเคชันควรแสดงให้ เห็นถึงภาพรวมความสามารถหลักของ แอปพลิเคชันและมีช่องทางการเข้าถึง ความสามารถหลกั อยา่ งชัดเจน

3 มาตรฐานแอปพลเิ คชันภาครฐั ส�ำหรับอปุ กรณ์เคล่อื นที่ เวอรช์ นั 1.0 1.1.3. การควบคุมการเขา้ ถงึ และการเปลย่ี นหนา้ จอ (Navigation) A. การออกแบบการเข้าถึงหน้าจอและการเปล่ียนหน้าจอ ต้องอ้างอิงจาก UIG หรือ HIG ของแต่ละแพลตฟอรม์ อยา่ งเครง่ ครัด นอกเสียจากกรณที ่ี จ�ำเปน็ ในเชงิ การใชง้ าน B. ใชส้ ัญลักษณ์ด้ังเดมิ (Native Icon) ใหส้ อดคล้องกับมาตรฐานของระบบ ในการสื่อถึงรูปแบบการท�ำงานและฟังก์ชันที่เป็นมาตรฐานเช่น การแบ่งปนั การเข้าถงึ เนอ้ื หายอ่ ยเป็นต้น C. การย้อนกลับไปหน้าจอก่อนหน้าต้องใช้รูปแบบมาตรฐานของแต่ละ แพลตฟอรม์ ทัง้ รปู แบบลกั ษณะการท�ำงาน และการออกแบบสว่ นตดิ ตอ่ ผู้ใชง้ านบนหนา้ จอ

4Government Mobile Application Standard Version 1.0 D. หากแพลตฟอร์มแนะน�ำให้ใชป้ ุม่ ย้อนกลับ (Back) ปุม่ ดังกล่าวควรอยูใ่ น ต�ำแหนง่ ทเ่ี หมาะสม E. ตำ� แหน่งของปุ่มตา่ ง ๆ ทใ่ี ช้สำ� หรบั การเขา้ ถงึ เนอ้ื หาหรอื เปลีย่ นหนา้ จอ ที่ถูกก�ำหนดขึ้นในแต่ละแพลตฟอร์ม ไม่ควรถูกใช้งานเพื่อวัตถุประสงค์ อนื่ ๆ เชน่ ตำ� แหนง่ ทคี่ วรจะเปน็ ปมุ่ ยอ้ นกลบั ไดไ้ มค่ วรนำ� ปมุ่ อน่ื วางแทนท่ี เป็นต้น 1.1.4. การรองรบั ขนาดหนา้ จอ (Supported Resolution) A. ภาพกราฟิกต่าง ๆ ควรจัดเตรียมไว้รองรับทุกระดับความละเอียดของ หน้าจออย่างเหมาะสมไม่ก่อให้เกิดการย่อหรือขยายภาพผิดระดับ ความละเอยี ดจนสญู เสียความชัดเจน

5 มาตรฐานแอปพลเิ คชนั ภาครัฐส�ำหรับอปุ กรณ์เคล่อื นท่ี เวอร์ชนั 1.0 1.1.5. ปมุ่ และองคป์ ระกอบทสี่ ัมผัสเพ่ือควบคุมได้ (Buttons & Touchable elements) A. ปมุ่ และองคป์ ระกอบทสี่ มั ผสั เพอ่ื ควบคมุ ได้ ต้องมขี นาดไม่เล็กเกนิ ไป B. ปมุ่ และองคป์ ระกอบทสี่ มั ผสั เพอ่ื ควบคมุ ได้ ตอ้ งถกู ปดิ สถานะการอนญุ าตใหก้ ด เมื่อไม่สามารถกดได้ด้วยเงื่อนไข บางอย่างในขณะนน้ั (เชน่ ผใู้ ช้งานยงั กรอกข้อมลู ไม่ครบ) และตอ้ งยงั คงเห็น ปมุ่ หรอื องคป์ ระกอบนน้ั ๆ ในหน้าจอ แตม่ กี ารใชส้ เี พอ่ื แสดงสถานะทแี่ ตกตา่ ง ไปอยา่ งชัดเจน C. ปมุ่ และองคป์ ระกอบทสี่ มั ผสั เพอื่ ควบคมุ ได้ ควรมีการแสดงผลตอบรับ เม่ือมี การสัมผัสก่อนที่ฟังก์ชันท่ีเก่ียวข้อง จะถูกเรยี กใชง้ าน D. การใช้ภาพกราฟิกเพ่ือประกอบปุ่ม และองค์ประกอบที่สัมผัสเพ่ือควบคุม ได้ ให้เลือกใช้ภาพท่ีผู้ใช้งานคุ้นเคย สอื่ ความหมายไดช้ ัดเจน 1.1.6. ความสามารถในการอา่ นได้ (Readability) A. ขนาดขององค์ประกอบต่าง ๆ ต้องถูกค�ำนวณให้มีขนาดเหมาะสม กับเนื้อหาไม่ท�ำให้เน้ือหาถูกตัดโดยไม่จ�ำเป็น เว้นแต่กรณีอยู่ใน หน้าจอแสดงรายการที่ผู้ใช้งานสามารถเข้าไปอ่านเน้ือหาต่อได้ใน หน้าจอแสดงรายละเอยี ด B. การจัดวางองค์ประกอบต่าง ๆ ของหน้าจอควรให้ความส�ำคัญ กับความสามารถในการอา่ นได้

6Government Mobile Application Standard Version 1.0 C. หากแอปพลิเคชันรองรับการเปล่ียนขนาดตัวอักษร ควรมีการค�ำนวณ ขนาดขององคป์ ระกอบตา่ ง ๆ โดยขนึ้ กบั ขนาดของตวั อกั ษรทจี่ ะใชแ้ สดง และมกี ารคำ� นวณใหม่เมอ่ื มีการเปลีย่ นแปลงขนาดตวั อักษร D. หากแอปพลิเคชันมีการเปลี่ยนหน้าจอโดยอัตโนมัติ ควรก�ำหนดเวลาให้ เหมาะสมส�ำหรับการอ่านข้อมูลท่ีจ�ำเป็นบนหน้าจอ ก่อนท่ีจะท�ำ การเปลีย่ นหน้าจอ

7 มาตรฐานแอปพลเิ คชนั ภาครฐั ส�ำหรบั อุปกรณเ์ คลื่อนท่ี เวอร์ชัน 1.0 1.1.7. ความสอดคล้องกับแอปพลเิ คชันอ่นื ๆ (Platform Consistency) A. การใช้สญั ลักษณ์และข้อความตา่ ง ๆ ตอ้ งสอดคลอ้ งกับ UIG/HIG หรอื สอดคลอ้ งกับแอปพลิเคชนั มาตรฐานในแต่ละแพลตฟอร์ม B. แอปพลเิ คชนั ไมค่ วรเปลยี่ นภาพสญั ลกั ษณข์ องการกระทำ� ทเี่ ปน็ มาตรฐาน ในแตล่ ะแพลตฟอรม์ (เชน่ การสง่ อเี มลควรใชส้ ญั ลกั ษณท์ เ่ี ปน็ มาตรฐาน ในแตล่ ะแพลตฟอร์มมากกว่ากำ� หนดเอง) C. แอปพลเิ คชนั ไมค่ วรเปลยี่ นการกระทำ� พนื้ ฐาน (Action) ในแตล่ ะแพลตฟอรม์ ท่ีก�ำหนดที่มีความเช่ือมโยงกับสัญลักษณ์ (เช่น สัญลักษณ์ท่ีใช้ส�ำหรับ แบง่ ปนั ขอ้ มลู ไมค่ วรถูกกำ� หนดใหน้ ำ� ไปใช้อยา่ งอ่ืน) 1.1.8. คณุ ภาพของภาพและกราฟิก (Visual Quality) A. การแสดงผลของภาพตัวอักษรและองค์ประกอบส่วนติดต่อกับผู้ใช้งาน ต่าง ๆ ต้องถกู แสดงผลโดยไม่มกี ารบดิ เบย้ี วของอัตราส่วน B. การเลือกใชส้ ีควรค�ำนงึ ถงึ ความสามารถในการอา่ นและการมองเหน็ ของ ผใู้ ชง้ านเปน็ หลกั ควรหลกี เลยี่ งการใชส้ ตี วั อกั ษรและสขี องพนื้ หลงั ทร่ี บกวน ความสามารถในการอ่าน แม้ว่าจะเป็น สีประจ�ำของหน่วยงานกต็ าม C. สีประจ�ำหน่วยงานสามารถน�ำมาใช้เป็น สีประจ�ำแอปพลเิ คชัน (Application Key Color) ได้ โดยอาจใช้เป็นสีของพ้ืนหลัง หรอื สีของตวั อักษร ขึ้นกับความเหมาะสม ทง้ั นีไ้ ม่ควรทำ� ใหค้ วามสามารถในการอ่าน ลดลง

8Government Mobile Application Standard Version 1.0 1.1.9. การตอบสนองของสว่ นรบั ข้อมูลจากผใู้ ชง้ าน (Application Speed) A. แอปพลเิ คชนั ตอ้ งเตรยี มการรองรบั หรอื การกดปมุ่ และองคป์ ระกอบควบคมุ ต่าง ๆ บนหน้าจออย่างรวดเร็วและพร้อม ๆ กัน (Input Flooding) เชน่ เตรยี มป่มุ Submit ไมใ่ หผ้ ใู้ ช้งานสามารถกดซ�้ำไดเ้ ป็นต้น B. ทกุ ๆ การกระทำ� (Action) จากผใู้ ชง้ านควรมีการแสดงการตอบสนอง (Response) ท่เี หมาะสม เชน่ การตอบสนองเมอื่ มีการกดปมุ่ การแสดง สญั ลกั ษณเ์ คลอื่ นไหวเมอ่ื ผใู้ ชง้ านสง่ั ใหโ้ หลดขอ้ มลู การแสดงแถบเคลอ่ื นไหว ตามสถานะการประมวลผล เป็นต้น

9 มาตรฐานแอปพลิเคชันภาครัฐสำ� หรับอปุ กรณ์เคล่อื นที่ เวอร์ชัน 1.0 1.1.10. การตดิ ตอ่ กบั ระบบแม่ขา่ ย (Acknowledge and Notice) A. ในขณะที่ท�ำการโหลดข้อมูลต้องมีการแสดงสัญลักษณ์ของสถานะ (Indicator) อยา่ งชดั เจนวา่ มีการโหลดขอ้ มลู B. การโหลดขอ้ มลู จากแมข่ า่ ยตอ้ งทำ� ใน Background เพอื่ ไมใ่ หร้ บกวนการ ใชง้ านแอปพลเิ คชัน และมีการแสดงสญั ลักษณแ์ สดงสถานะ (Indicator) ท่เี หมาะสมในสว่ นการตดิ ตอ่ กับผูใ้ ช้งาน C. หากระบบแมข่ า่ ยไมส่ ามารถใหข้ อ้ มลู ทถ่ี กู ตอ้ งหรอื ไมท่ ำ� งาน แอปพลเิ คชนั ตอ้ งมกี ารตอบสนองทเี่ หมาะสม เชน่ แสดงขอ้ ความแจง้ เตอื นใหแ้ กผ่ ใู้ ชง้ าน และแอปพลเิ คชนั ตอ้ งไมป่ ดิ ตวั เองโดยเดด็ ขาด D. หากมกี ารเชอ่ื มตอ่ กบั ระบบแมข่ า่ ยขอ้ มลู ควรใหม้ กี ารโหลดขอ้ มลู เปน็ ชว่ ง และข้อมูลสามารถโหลดข้อมูลเพ่ิมได้เม่ือจ�ำเป็นเช่นเมื่อผู้ใช้งานเลื่อนดู รายการจนสดุ เป็นตน้ E. การโหลดข้อมูลในแต่ละหน้าอาจแยกการโหลดเป็นหลายส่วนเพ่ือให้น�ำ ขอ้ มลู ทม่ี ขี นาดเลก็ โหลดไดเ้ รว็ มาแสดงไดก้ อ่ น (เชน่ ขอ้ ความตา่ ง ๆ) และ จากน้นั ค่อย ๆ อปั เดตสว่ นข้อมลู ท่มี ีขนาดใหญ่ (เช่น รปู ภาพ) มาแสดง เพม่ิ เติมไปในส่วนต่าง ๆ ที่เตรียมไว้เมอ่ื โหลดขอ้ มูลเหลา่ นนั้ เสร็จแล้ว F. ควรพิจารณาการเก็บข้อมูลท่ีโหลดจากแม่ข่ายไว้ชั่วคราวภายใน แอปพลเิ คชนั (Caching) เพอื่ ลดการโหลดข้อมูลทไ่ี มจ่ ำ� เปน็ และท�ำให้มี การแสดงผลขอ้ มลู ที่ทำ� การโหลดมาแล้วอย่างรวดเรว็ ขนึ้ 1.1.11. การแสดงขอ้ ความแจ้ง (Notification) A. ผู้ใช้งานต้องสามารถปิดการรับ ข้อความแจง้ เตือนต่าง ๆ ได้ โดย มีช่องทางให้ปิดการแจ้งเตือนได้ โดยตรงจากภายในแอปพลิเคชัน ด้วยนอกเหนือจากช่องทางที่ มาตรฐานในแต่ละแพลตฟอร์ม เตรียมไว้ให้แล้ว

10Government Mobile Application Standard Version 1.0 B. ควรใชร้ ะบบการสง่ ขอ้ ความแจง้ เตอื น (Notification) ของแตล่ ะแพลตฟอรม์ ในการส่งขอ้ ความแจ้งเตือนต่าง ๆ ที่ส�ำคญั ใหก้ บั ผ้ใู ชง้ าน C. การสง่ ข้อความแจ้งเตอื นต่าง ๆ ควรสง่ ในปรมิ าณ และความถท่ี ไี่ มเ่ ปน็ การรบกวนผ้ใู ชง้ านยกเวน้ เป็นขอ้ มลู ท่เี กี่ยวขอ้ งกบั ผใู้ ชง้ านโดยตรง เช่น การสนทนาการรบั แจง้ เตอื นพบสง่ิ ของหายทปี่ ระกาศไว้เปน็ ตน้ D. การส่งข้อความแจ้งเตือนท่ีไม่เก่ียวข้องกับผู้ใช้งานโดยตรง ควรส่งเมื่อ ผใู้ ชง้ านแสดงความจ�ำนงท่ีจะรบั ข้อความเหลา่ นน้ั 1.1.12. ข้อความแจง้ เตือน (Warning) และแสดงขอ้ ผิดพลาด (Error) A. การแสดงข้อความแจ้งเตือนและข้อความผิดพลาดท่ัวไป ควรแสดงโดย ใช้สว่ นตดิ ต่อกบั ผใู้ ชง้ านปกติ ไมม่ กี ารแสดงกล่องขอ้ ความแยก (Dialog Box) ยกเวน้ กรณที เี่ ปน็ ขอ้ ผดิ พลาดทส่ี ำ� คญั หรอื เปน็ ขอ้ ความทไี่ มส่ ามารถ แสดงไวใ้ นส่วนติดต่อกับผ้ใู ชง้ านปกติได้ B. ข้อความท่ีใช้ควรแสดงให้ชัดเจนว่าเป็นการเตือนเปน็ ค�ำแนะน�ำหรือเป็น ขอ้ ผิดพลาด C. ข้อความที่ใช้แจ้งเตือนข้อผิดพลาด ควรระบุข้อผิดพลาดให้ชัดเจน เขา้ ใจงา่ ย และระบุแนวทางแก้ไขเบื้องตน้ 1.1.13. การแสดงสญั ลักษณ์ประจ�ำหน่วยงาน (Symbol) A. การแสดงสัญลักษณ์ของหน่วยงานให้แสดงได้ในหน้าก่อนเข้า แอปพลเิ คชัน (Splash Screen) 1.1.14. สว่ นการใหค้ วามช่วยเหลือผู้ใชง้ าน (Help and Support) A. ไม่ควรมีโหมดตัวอย่างการใช้งาน (Tutorial Screen) ที่เป็นภาพน่ิง หลายภาพ และมีการแสดงลูกศรถึงต�ำแหนง่ ตา่ ง ๆ ยกเวน้ กรณีที่จ�ำเปน็ จริง ๆ เท่านัน้ B. อาจมีหนา้ ค�ำถามเกีย่ วข้องกบั การใช้งานทพ่ี บบอ่ ย (Frequency Asked Questions) เพ่ือให้ผู้ใช้งานสามารถศึกษารูปแบบการใช้งานบางอย่าง เพมิ่ เติมได้

11 มาตรฐานแอปพลเิ คชนั ภาครฐั ส�ำหรบั อปุ กรณเ์ คล่อื นที่ เวอร์ชัน 1.0 C. อาจมีการท�ำ Video Clip ท่ีมีรูปแบบการใช้งานเบ้ืองต้นอัปโหลด ไว้ในเว็บหน่วยงานหรือเว็บแบ่งปัน Video ออนไลน์ที่เข้าถึงได้ง่าย เพ่ือให้ผู้สนใจสามารถเห็นรูปแบบการใช้งานเบื้องต้นได้ก่อนเข้า ใชง้ านจรงิ D. ควรมีช่องทางในการติดต่อผู้พัฒนาหรือผู้ท่ีมีส่วนเกี่ยวข้องโดยตรงเพื่อ ตอบค�ำถามข้อสงสยั ในการใชง้ านแอปพลเิ คชัน 1.1.15. การทำ� งานร่วมกับแอปพลเิ คชนั ภายนอก (Using and Transferring Application) A. ในกรณีท่ีแอปพลิเคชันต้องท�ำงานร่วมกับแอปพลิเคชันอ่ืน ๆ ในระบบ ปฏิบัติการและยังส่งผลให้มีการเปล่ียนข้ามไปยังแอปพลิเคชันอื่น ๆ จะต้องท�ำการถามความประสงค์ของผู้ใช้งานก่อนท�ำการเปล่ียนข้าม เสมอ

12Government Mobile Application Standard Version 1.0 1.1.16. การโทรศพั ทแ์ ละการสง่ อเี มล (Contact Data) A. แอปพลิเคชันต้องมีการแสดง เบอร์โทรศัพท์และอีเมลท่ี เก่ียวข้องกับการบริการต่าง ๆ ของหน่วยงาน ที่สามารถ ติดตอ่ ได้ B. ข้อมูลที่เป็นเบอร์โทรศัพท์ ตอ้ งมกี ารแสดงผลทช่ี ดั เจนและ สามารถกดเพอื่ ทำ� การโทรออก ยกเว้นแอปพลเิ คชันท�ำงานบน อปุ กรณท์ ไ่ี มส่ ามารถใชฟ้ งั กช์ นั ของโทรศัพทไ์ ด้ C. การกดเบอร์โทรศัพท์เพ่ือท�ำการโทรออกต้องท�ำการถามความประสงค์ ของผู้ใช้งานเสมอว่าต้องการโทรออกไปยังเบอร์นั้น ๆ จริงหรือไม่ หา้ มท�ำการโทรทนั ทโี ดยผู้ใชง้ านไมไ่ ดย้ นื ยันก่อน D. ข้อมูลท่ีเป็นอีเมลต้องมีการแสดงผลที่ชัดเจนและสามารถกดเพ่ือท�ำการ ส่งอเี มลได้ E. การส่งอีเมลจากอีเมลของผู้ใช้งานผู้ใช้งานต้องเห็นข้อความท้ังหมดท่ีจะ ส่ง และเป็นผู้ยืนยันการส่งด้วยตัวเองเสมอ ท้ังนี้อาจมีการใส่ข้อความ เบ้ืองต้นในอีเมลแบบอัตโนมัติ เพ่ืออ�ำนวยความสะดวกให้ผู้ใช้งาน ใสข่ อ้ ความเพ่มิ เติมได้ 1.1.17. การเขา้ เว็บไซตจ์ ากภายในแอปพลเิ คชัน (Browsing Website in-application) A. แอปพลเิ คชนั ตอ้ งมกี ารแสดงทอี่ ยขู่ องเวบ็ ไซตห์ นว่ ยงาน (Website URL) และเวบ็ ไซตบ์ ริการตา่ ง ๆ ที่เก่ียวข้อง B. ข้อมูลลิงก์เว็บไซต์ (Website URL) ต้องมีการแสดงผลที่ชัดเจน และ สามารถกดเพือ่ เขา้ ชมเวบ็ ไซต์ได้

13 มาตรฐานแอปพลิเคชันภาครฐั ส�ำหรบั อปุ กรณเ์ คลอื่ นท่ี เวอรช์ ัน 1.0 C. การเข้าชมเว็บไซต์อาจท�ำได้โดยอาศัยแอปพลิเคชันส�ำหรับท่องเว็บ (Web Browser) อ่นื ๆ ทีม่ ีอยู่ในเครอื่ งหรอื แสดงผลหน้าเว็บไซตน์ น้ั ๆ จากภายในแอปพลิเคชันเอง D. กรณใี ช้ Web Browser ภายนอกแอปพลเิ คชนั ควรเรยี กถามความประสงค์ ในการเปลย่ี นข้ามแอปพลเิ คชันจากผใู้ ช้งานเสมอ E. กรณีไม่เปล่ียนข้ามไปใช้ Web Browser ภายนอกแต่มีการพัฒนา หนา้ จอเพอ่ื แสดงหนา้ เวบ็ ภายในแอปพลเิ คชนั ควรมสี ว่ นตดิ ตอ่ กบั ผใู้ ชง้ าน เพ่ือท�ำการควบคุมการท�ำงานของหน้าเว็บเช่นย้อนกลับถัดไปโหลดใหม่ อกี ครง้ั และหยดุ การโหลดหน้าเวบ็ เสมอ 1.1.18. ขอ้ มูลทอ่ี ยู่และตำ� แหน่งทตี่ ง้ั ตา่ ง ๆ (Location Data) A. แอปพลิเคชันต้องมีการแสดงข้อมูลที่อยู่ ท่ีตั้งหน่วยงาน หรือ สถานที่ต่าง ๆ ทีเ่ กย่ี วขอ้ งทส่ี ามารถตดิ ต่อได้ B. ข้อมูลท่ีเป็นท่ีอยู่หรือต�ำแหน่งที่ตั้งของหน่วยงานหรือสถานท่ีต่าง ๆ ทีเ่ กย่ี วขอ้ งกับสิ่งท่ีแสดงผลอยตู่ ้องพฒั นาใหท้ ำ� งานรว่ มกบั แอปพลิเคชัน แผนทที่ อี่ ย่ใู นเครือ่ งได้

14Government Mobile Application Standard Version 1.0 C. แอปพลเิ คชนั ไมจ่ ำ� เปน็ ตอ้ งแสดงพกิ ดั ภมู ศิ าสตรใ์ หผ้ ใู้ ชง้ านเหน็ อยา่ งชดั เจน ยกเว้นในกรณีที่ช่วยให้ประสบการณ์ผู้ใช้งานดีข้ึนและมีการระบุกรณี ยกเวน้ ดงั กล่าวอยา่ งชดั เจน D. กรณีเปล่ียนข้ามไปใช้แอปพลิเคชันแผนท่ีอ่ืน ๆ ในเครื่อง ควรมี การเรียกถามความประสงค์ของผ้ใู ชง้ านกอ่ นทกุ ครง้ั 1.1.19. แบบฟอรม์ กรอกข้อมูล (Text Field) A. แบบฟอร์มกรอกขอ้ มูลตอ้ งมีการแสดงปา้ ยชอ่ื อยา่ งชัดเจนและป้ายชอ่ื นี้ ควรจะเห็นตลอดเวลา B. ข้อมูลที่จ�ำกัดรูปแบบต้องมีการตรวจสอบรูปแบบของข้อมูลที่ผู้ใช้งาน กรอกเสมอ C. ในช่องกรอกข้อมูลท่ีมีการจ�ำกัดรูปแบบจะต้องมีการแสดงแป้นพิมพ์ท่ี เหมาะสม เช่น ข้อมูลที่เป็นตัวเลขเท่าน้ันควรแสดงแป้นพิมพ์ท่ีเป็น เฉพาะตวั เลข D. ข้อมูลรหัสผ่านต้องถูกแทนที่ด้วยตัวอักขระอื่น (เช่น *) และต้องมี ปุ่มแสดงรหัสผ่านข้อมูลท่ีสามารถแสดงรหัสผ่านที่ถูกซ่อนไว้ เพื่อให้ ผใู้ ชง้ านมองเหน็ และยืนยนั ได้ E. ผู้ใช้งานต้องไม่สามารถใส่ข้อมูลที่เป็นไปไม่ได้ (เช่น ต้องไม่สามารถ ใส่ปีเกดิ เปน็ ปีในอนาคต)

15 มาตรฐานแอปพลเิ คชนั ภาครฐั สำ� หรบั อปุ กรณ์เคล่อื นท่ี เวอร์ชนั 1.0 F. แบบฟอร์มกรอกข้อมูลควรมีการใช้ร่างข้อมูล (Placeholder Information) ในช่องดังกล่าวเพื่อระบุรูปแบบข้อมูลและ/หรือตัวอย่าง ข้อมลู G. ไม่ควรใช้ร่างข้อมูล(Placeholder Information) แทนการใช้ป้ายช่ือ เพราะร่างข้อมูลจะถูกแทนท่ีด้วยข้อมูลจริง และท�ำให้ไม่รู้ว่าข้อมูลนี้คือ ข้อมลู ส�ำหรบั อะไร H. หากผู้ใช้งานท�ำการปิดหน้าจอกรอกแบบฟอร์มหรือข้อมูลต่าง ๆ และ ขอ้ มลู ไมม่ กี ารบนั ทกึ ไวส้ ง่ ผลใหผ้ ใู้ ชง้ านตอ้ งกรอกขอ้ มลู ใหมค่ วรมขี อ้ ความ แจง้ เตอื นแสดงให้ผูใ้ ช้งานทราบและยืนยันการปดิ หน้าจอเสมอ

16Government Mobile Application Standard Version 1.0 1.1.20. การลงทะเบยี นเพอื่ สมคั รเขา้ ใชง้ านและเพอื่ เขา้ ใชง้ าน (User Registration) A. แอปพลเิ คชนั ทต่ี อ้ งการให้ ผู้ใช้งานลงทะเบียนเพื่อ ใช้งานต้องท�ำแบบฟอร์ม ส� ำ ห รั บ ล ง ท ะ เ บี ย น โดยอ้างอิงจากส่วนของ “แบบฟอรม์ กรอกขอ้ มลู ” เปน็ หลกั B. ต้องมีระบบช่วยเหลือ ในกรณผี ใู้ ชง้ านลมื รหสั ผา่ น จากหน้าจอลงทะเบียน ส�ำหรับวิธีการช่วยเหลือ น้ันขึ้นกับหน่วยงาน เช่น อาจจะใช้วิธีการถามค�ำถามลับ เพื่อต้ัง รหสั ผา่ นใหม่ หรอื ส่งลงิ กส์ �ำหรับตง้ั รหัสผา่ นใหมไ่ ปยงั อีเมลทีใ่ ห้ไว้ หรอื วธิ กี ารอ่ืนๆ C. ในแอปพลิเคชันควรมีหน้าจอให้ผู้ใช้งานปรับข้อมูลและตัวเลือกต่าง ๆ ที่กรอกไปในการลงทะเบียนใช้งานครั้งแรก โดยเป็นหน้าจอที่เข้าถึง ไดง้ ่าย 1.1.21. การใช้ส่ือภาพวดี โี อและเสยี งต่าง ๆ (Multimedia) A. แอปพลิเคชันตอ้ งไม่มีการเลน่ ไฟล์ Video หรือไฟล์ Audio เม่อื เริม่ ต้นใช้ งานแอปพลเิ คชันอัตโนมตั ิ B. การเล่นไฟล์ Video หรือไฟล์ Audio ใด ๆ ตอ้ งเป็นความประสงค์ของ ผู้ใช้งานเทา่ นนั้ ผูใ้ ช้งานตอ้ งเป็นผู้กดป่มุ เริ่มเลน่ ด้วยตวั เอง C. การแนบไฟล์ Video และไฟล์ Audio ต่าง ๆ ไปกับแอปพลิเคชัน เพ่ือให้ไม่ต้องดาวน์โหลดภายหลังควรค�ำนึงถึงขนาดของแอปพลิเคชัน เป็นส�ำคัญ ขนาดของแอปพลิเคชันเมื่อดาวน์โหลดคร้ังแรกไม่ควรมี ขนาดใหญ่เกนิ ไป โดยเฉพาะอย่างยิ่งถา้ ไฟลต์ า่ ง ๆ เหลา่ นัน้ อาจไม่ไดใ้ ช้ เปน็ ประจ�ำ

17 มาตรฐานแอปพลเิ คชนั ภาครฐั สำ� หรับอปุ กรณ์เคลอื่ นที่ เวอรช์ ัน 1.0 1.1.22. การทำ� งานในโหมดเบื้องหลงั (Background Process) A. แอปพลิเคชันควรมีการจัดการการท�ำงานท่ีค้างอยู่ก่อนเข้าสู่โหมด เบ้ืองหลังอย่างเหมาะสม เช่น หยุดการโหลดข้อมูลไว้ช่ัวคราว หยุดการท�ำงานบางอยา่ งท่ีคา้ งอยู่บันทึกขอ้ มูลที่จ�ำเป็นต้องใช้ เม่ือกลบั เขา้ สโู่ หมดการทำ� งานปกตหิ ยดุ เลน่ ไฟลว์ ดี โี อและ/หรอื ไฟลเ์ สยี งนอกจาก เป็นฟังก์ชันการท�ำงานหลัก และเป็นความประสงค์ของผู้ใช้งานเท่านั้น ในกรณีเช่นนั้นใหม้ ตี วั เลอื กทสี่ ามารถตัง้ คา่ ได้อยา่ งชดั เจน B. เม่ือกลับเข้าสู่โหมดการท�ำงานปกติแอปพลิเคชันควรท�ำงานต่อเนื่อง อยา่ งเหมาะสมจากสถานะก่อนทีจ่ ะเขา้ สู่โหมดการท�ำงานเบื้องหลัง C. แอปพลิเคชันท่ีมีการท�ำงานในโหมดเบื้องหลังควรมีการท�ำงานเฉพาะ เทา่ ทจี่ ำ� เปน็ ตอ่ ฟงั กช์ นั การทำ� งานหลกั ตอ่ ผใู้ ชง้ านและทำ� ใหป้ ระสบการณ์ ใช้งานของผใู้ ชง้ านดีข้นึ เท่านนั้ D. แอปพลิเคชันไม่ควรเก็บข้อมูลที่ละเมิดความเป็นส่วนตัวของผู้ใช้งาน ไม่ว่ากรณีใด ๆ ทั้งสิ้น โดยเฉพาะอย่างย่ิงกรณีท่ีไม่เก่ียวกับฟังก์ชัน การทำ� งานหลักและไม่ทำ� ให้ประสบการณใ์ ช้งานของผใู้ ชง้ านดีขึ้น

18Government Mobile Application Standard Version 1.0 1.2. การรักษาข้อมูลส่วนบคุ คล (Privacy)

19 มาตรฐานแอปพลิเคชันภาครัฐส�ำหรบั อุปกรณ์เคลื่อนที่ เวอร์ชนั 1.0 1.2.1. ทว่ั ไป (General) A. เนอ้ื หาหรอื ขอ้ มลู ทแ่ี สดงในแอปพลเิ คชนั ตอ้ งไมล่ ะเมดิ กฎหมายทเี่ กยี่ วขอ้ ง กับความเปน็ สว่ นตวั ของบคุ คล B. การเก็บข้อมูลต่าง ๆ ท่ีเกี่ยวข้องกับความเป็นส่วนตัวของผู้ใช้งาน ต้องกระทำ� โดยความยินยอมของผู้ใช้งานเท่านน้ั C. การเก็บข้อมูลต่าง ๆ ที่เกี่ยวข้องกับความเป็นส่วนตัวของผู้ใช้งาน ตอ้ งเปน็ ขอ้ มลู ทเ่ี กยี่ วขอ้ งกบั การทำ� งาน และใชง้ านแอปพลเิ คชนั โดยตรง เทา่ น้นั D. ข้อมูลที่เกี่ยวข้องกับความเป็นส่วนตัวของผู้ใช้งานต้องไม่ถูกเปิดเผย นอกจากกรณีที่จ�ำเป็นต่อการใช้งานแอปพลิเคชันโดยตรงและเปิดเผย เปน็ การชวั่ คราวตอ่ ผทู้ เ่ี กยี่ วขอ้ งเทา่ นนั้ (เชน่ แอปพลเิ คชนั ทรี่ ะบตุ ำ� แหนง่ ขอความช่วยเหลือที่มีการระบุตัวตนและต�ำแหน่งจะเปิดเผยตัวตนและ ตำ� แหนง่ ใหแ้ กเ่ จา้ หนา้ ทท่ี เ่ี กยี่ วขอ้ งในระยะเวลาทท่ี ำ� การชว่ ยเหลอื เทา่ นนั้ เปน็ ต้น) 1.2.2. สทิ ธขิ องผูใ้ ช้งานความเปน็ ส่วนตวั ของผูใ้ ชง้ านและขอ้ ตกลงในการใชง้ าน (User’s Right) A. ผู้ใช้งานต้องสามารถเข้าถึงหน้าจอเพื่อ แสดงสทิ ธใิ์ นการใชง้ าน (User’s Right) ความเป็นส่วนตัวของผู้ใช้งาน (User’s Privacy) และข้อตกลงในการใช้งาน (Service Agreement หรอื Term of Uses) ได้โดยง่ายจากภายใน แอปพลเิ คชนั B. แอปพลเิ คชนั ทม่ี กี ารเกบ็ ขอ้ มลู สว่ นบคุ คล ของผู้ใช้งานต้องระบุในหน้าจอแสดง สิทธ์ิและความเป็นส่วนตัวของผู้ใช้งาน ให้ผู้ใช้งานทราบอย่างชัดเจนว่ามี การเกบ็ ขอ้ มลู อะไรบา้ ง

20Government Mobile Application Standard Version 1.0 C. ผใู้ ชง้ านตอ้ งสามารถลบหรอื แก้ไขข้อมูลส่วนบุคคล ท่ีไมถ่ กู ต้องไมส่ มบรู ณ์ หรือ ไมเ่ ป็นปัจจบุ ันได้ D. หากมกี ารเปลีย่ นแปลงสทิ ธิ์ ของผู้ใช้งาน ความเป็น ส่วนตัวของผู้ใช้งาน หรือ ขอ้ ตกลงในการใชง้ านตอ้ งมี การแจ้งผู้ใช้งานให้ทราบ อย่างชดั เจนเสมอ E. หากแอปพลิเคชันมีการให้ ผู้ใช้งานยอมรับในสิทธ์ิผู้ใช้งาน ความเป็นส่วนตัวของผู้ใช้งาน หรือ ข้อตกลงในการใช้งานในการลงทะเบยี นเขา้ ใช้งานครัง้ แรก และภายหลัง มีการเปลี่ยนแปลงเงื่อนไขดังกล่าวต้องมีการแสดงหน้าจอให้ผู้ใช้งาน ยอมรบั สทิ ธท์ิ ี่มีการเปล่ยี นแปลงทกุ คร้งั F. แอปพลิเคชันต้องมีช่องทางให้ติดต่อผู้เก่ียวข้องเพื่อสอบถาม หรือ ตรวจสอบสิทธิ์และการใช้ข้อมูลที่เกี่ยวข้องกับความเป็นส่วนตัว ของตวั เองได้ 1.2.3. การเก็บขอ้ มูลชว่ั คราวไว้ในอุปกรณข์ องผู้ใชง้ าน (Cache Data, Caching) A. แอปพลิเคชันจะต้องไม่มีการเก็บข้อมูลใด ๆ ของผู้ใช้งานท่ีไม่เก่ียวข้อง กบั การทำ� งานโดยตรงของแอปพลเิ คชันแมว้ ่าจะเป็นเพยี งข้อมูลชัว่ คราว ก็ตาม B. แอปพลเิ คชนั อาจเกบ็ ขอ้ มลู ไวใ้ นอปุ กรณข์ องผใู้ ชง้ านชว่ั คราว (Caching) ควรมีวัตถุประสงค์เพ่ิมประสิทธิภาพการท�ำงานของแอปพลิเคชัน และลดการติดตอ่ กบั ระบบแม่ขา่ ยข้อมลู เท่านน้ั C. เมื่อเข้าสู่โหมดการท�ำงานเบื้องหลัง แอปพลิเคชันควรมีการบันทึก ข้อมูลช่ัวคราวที่จ�ำเป็นในการท�ำงานต่อ เมื่อกลับสู่โหมดการท�ำงาน ปกติ

21 มาตรฐานแอปพลเิ คชนั ภาครฐั สำ� หรับอปุ กรณ์เคลอื่ นที่ เวอรช์ ัน 1.0 D. แอปพลิเคชันท่ีรองรับการลงทะเบียนเข้าใช้งาน และมีการเก็บข้อมูล เนื้อหาไว้เป็นข้อมูลชั่วคราวต้องระมัดระวังไม่ให้ข้อมูลชั่วคราวท่ีเก็บไว้ ของผู้ใช้งานแต่ละคนปรากฏแก่ผู้ใช้งานคนอื่น ๆ ในเคร่ืองเดียวกัน ควรใช้วิธีการแยกเก็บข้อมูลชั่วคราวเป็นรายคนหรือลบข้อมูลช่ัวคราว เมื่อมกี าร Sign out เกิดขึน้ หรอื วิธีการอ่นื ๆ ทใ่ี หผ้ ลลัพธ์ถกู ต้อง E. แอปพลิเคชันจะไม่มีการเก็บข้อมูลท่ีอาจเป็นอันตรายต่อความปลอดภัย ของผู้ใช้งานเป็นข้อมูลช่ัวคราวโดยไม่มีการเข้ารหัสโดยเด็ดขาด เช่น รหัสผ่านตา่ ง ๆ หรอื หมายเลขบตั รเครดติ เป็นต้น 1.2.4. การเกบ็ ข้อมลู ถาวรไวใ้ นอุปกรณข์ องของผูใ้ ช้งาน (Local Storage) A. แอปพลิเคชันอาจมีการเก็บข้อมูลเน้ือหาบางอย่างในลักษณะข้อมูล ถาวร ทั้งนี้ให้พิจารณาถึงความจ�ำเป็น และประเภทข้อมูลใน การจัดเก็บ

22Government Mobile Application Standard Version 1.0 1.2.5. การใช้งานชดุ เครอื่ งมือในการพัฒนาซอฟต์แวรจ์ ากภายนอก (3rd Party Software Development Kit; SDK) A. แอปพลิเคชันท่ีมีการพัฒนาโดยใช้ชุดเครื่องมือในการพัฒนาซอฟต์แวร์ จากภายนอกต้องไม่ขัดต่อนโยบายที่เก่ียวข้องกับการเก็บข้อมูล ความเป็นส่วนตัวของผู้ใช้งานในแต่ละแพลตฟอร์มและของ SDK น้ัน ๆ B. ในกรณที ี่ SDK ทน่ี ำ� มาใชม้ กี ารเกบ็ ขอ้ มลู ของผใู้ ชง้ านและสง่ ไปยงั แมข่ า่ ย ภายนอกผพู้ ฒั นา ต้องแน่ใจวา่ ตวั SDK น้ัน ๆ ไม่มีการเกบ็ ข้อมูลท่ลี ะเมดิ ความเป็นส่วนตัวของผู้ใช้งานและต้องมีการแจ้งให้ผู้ใช้งานทราบถึง การเก็บและการใช้ขอ้ มลู ดังกลา่ วเสมอ

23 มาตรฐานแอปพลิเคชนั ภาครฐั สำ� หรับอุปกรณ์เคลอ่ื นที่ เวอร์ชัน 1.0 1.3. สว่ นติดต่อเพื่อพฒั นาโปรแกรม (Application Programming Interface; API) และการเปดิ ขอ้ มลู เพื่อพฒั นาต่อยอด (Open Data) 1.3.1. ท่ัวไป (General) A. แอปพลเิ คชนั ทมี่ กี ารตดิ ตอ่ กบั ระบบแมข่ า่ ยขอ้ มลู ตอ้ ง มีการพัฒนาส่วนของ API ท่ีระบบแม่ข่ายข้อมูล ขึ้นมาท�ำงานควบคู่กันไป ดว้ ยเสมอ B. แอปพลเิ คชนั ทม่ี กี ารตอ่ ตดิ กับระบบแม่ข่ายข้อมูล ไม่ว่าจะเป็นการติดต่อเพื่อขอข้อมูลส่งข้อมูลหรือขอให้ระบบแม่ข่าย ดำ� เนนิ การประมวลผลตอ้ งทำ� งานผา่ น API เสมอ C. API ท่ีพัฒนาข้ึนควรรับส่งข้อมูลโดยใช้รูปแบบและเทคโนโลยีท่ีใช้กัน อยา่ งกวา้ งขวาง (เปน็ De Facto Standard) ในขณะพัฒนา เชน่ รบั ส่ง ข้อมูลในรปู แบบ JSON ในปัจจบุ นั เปน็ ต้น D. หน่วยงานเจ้าของข้อมูลควรพิจารณาการใช้งาน API เพื่อส่งข้อมูล ให้แอปพลิเคชันต่าง ๆ น�ำไปใช้งานแทนการดึงข้อมูลจากหน้าเว็บของ หนว่ ยงาน หรอื การดึงหนา้ เวบ็ หน่วยงานไปแสดง E. หน่วยงานควรสนับสนุนให้มีการใช้งาน API ในการสร้างแอปพลิเคชัน อื่น ๆ ต่อยอดให้ข้อมูลมีประโยชน์หลากหลายยิ่งขึ้น มีคุณค่า มากยง่ิ ขึน้ 1.3.2. API เพ่อื การเข้าถึงและการแสดงขอ้ มูลสาธารณะ (Public Contents’ Accessing API) A. แอปพลิเคชันท่ีมีการแสดงข้อมูลสาธารณะ (เช่น ข่าวสารสาธารณะท่ี สำ� คญั ขอ้ มลู ทางสถติ ทิ เี่ ปน็ สาธารณะรายการตา่ ง ๆ ทเ่ี ปน็ ขอ้ มลู สาธารณะ) ท่ีประชาชนและผู้ใช้งานทั่วไปสามารถเข้าถึงได้ ควรขอข้อมูลดังกล่าว

24Government Mobile Application Standard Version 1.0 ไปยัง Public API ของหนว่ ยงานซึ่ง Public API นี้ควรเปดิ ใหน้ ักพฒั นา โปรแกรมโดยทั่วไปสามารถเรียกใช้งานได้ โดยอาจจะมีข้ันตอนการขอ สิทธใิ นการใชง้ าน B. หน่วยงานควรพิจารณา Public API เพื่อให้นักพัฒนาท่ัวไปสามารถ น�ำข้อมูลสาธารณะท่ีถูกต้องเช่ือถือได้จากหน่วยงานไปใช้งานได้โดยตรง อย่างมปี ระสิทธ์ิภาพ C. Public API ควรเข้าถึงได้โดยง่าย มีรูปแบบการรับส่งข้อมูลท่ีใช้กัน อย่างกวา้ งขวาง (เปน็ De Facto Standard) ในช่วงท่ีพฒั นาขณะนั้น D. Public API ท่เี ขา้ ถงึ ข้อมูลไดท้ ันที ไมค่ วรมีการละเมดิ ความเป็นส่วนตวั ของผใู้ ชง้ านภายในระบบ และไมค่ วรสามารถเขา้ ถงึ ขอ้ มลู อนั เปน็ สว่ นตวั ของผใู้ ชง้ านได้ E. Pubic API ต้องมีเอกสารอ้างอิงส�ำหรับการพัฒนาโปรแกรม (Development Documentation) ท่ีระบุถึงรูปแบบการรับส่งข้อมูล โดยละเอยี ด (API Specification) เพื่อให้นักพฒั นาสามารถน�ำไปใชไ้ ด้ ทนั ที

25 มาตรฐานแอปพลิเคชันภาครัฐส�ำหรบั อปุ กรณเ์ คลือ่ นที่ เวอรช์ ัน 1.0 1.3.3. API เพ่ือเข้าถงึ ขอ้ มลู ท่ีเจาะจงเฉพาะผใู้ ช้งานเฉพาะแอปพลเิ คชันและ/ หรอื เฉพาะผพู้ ฒั นา (Specific Content’s Focused API) A. แอปพลิเคชันที่มีการเข้าถึงข้อมูลเจาะจงเฉพาะผู้ใช้งานเฉพาะ แอปพลเิ คชนั และ/หรอื เฉพาะผพู้ ฒั นา ควรมกี ารออกแบบใหร้ ะบผุ ใู้ ชง้ าน แอปพลิเคชนั ท่ใี ช้และ/หรือผู้พฒั นาได้ B. การเขา้ ถงึ API ดงั กลา่ วควรเปน็ ไปตามมาตรฐานความปลอดภยั ของขอ้ มลู ควรค�ำนึงถึงการเข้ารหัสข้อมูลการควบคุมสิทธ์ิในการเข้าถึงข้อมูลและ ความเป็นส่วนตวั ของผู้ใชง้ านอยา่ งเครง่ ครดั 1.3.4. การเปลี่ยนแปลง API (Changing API) A. API ควรรองรับหลายเวอรช์ ัน (API Versioning) การเปลีย่ นแปลง API ควรค�ำนึงถึงแอปพลิเคชันท่ีใช้งาน API อยู่แล้วจะยังคงต้องใช้งานได้ ต่อไปโดยไม่สง่ ผลกระทบ B. API ควรมชี อ่ งทางใหน้ กั พฒั นาลงทะเบยี นรบั ขา่ วสารของการเปลยี่ นแปลง API ตา่ ง ๆ ได้

26Government Mobile Application Standard Version 1.0 1.3.5. การกำ� หนดขอ้ ตกลงในการใช้งาน API (API Agreement) A. ในกรณีท่มี ีการเปดิ Public API ควรมีเวบ็ ไซตท์ ี่แสดงขอ้ ตกลง และสทิ ธิ์ ในการใชง้ าน API อยา่ งชดั เจน B. ข้อตกลงควรครอบคลุมสิทธิ์การใช้งาน หรือรูปแบบของแอปพลิเคชัน ทหี่ า้ มพฒั นา หรอื สามารถพฒั นาได้ รวมถงึ เรอ่ื งการเปน็ เจา้ ของขอ้ ความ ปฏิเสธ (Disclaimer) และเงอื่ นไขต่าง ๆ ทน่ี กั พฒั นาต้องปฏบิ ัตติ าม เช่น การให้เครดิตการอ้างอิงแหล่งท่มี าหรือรปู แบบของการน�ำขอ้ มูลไปใช้ต่อ เป็นตน้

27 มาตรฐานแอปพลเิ คชนั ภาครัฐส�ำหรบั อปุ กรณเ์ คลอ่ื นที่ เวอร์ชนั 1.0 1.4. การทดสอบคุณสมบตั ขิ องแอปพลิเคชัน (Functional Testing) 1.4.1. ท่ัวไป (General) A. แอปพลิเคชันต้องได้รับการทดสอบอย่างละเอียดถี่ถ้วนโดยการทดสอบ ต้องครอบคลมุ ถึงสถานการณต์ ่าง ๆ ที่เกดิ ข้นึ ได้ในการใชง้ านจรงิ B. แอปพลเิ คชนั ตอ้ งไดร้ บั การทดสอบวา่ ไมป่ ดิ ตวั เอง (Crash) ในสถานการณ์ การใชง้ านปกติ C. แอปพลเิ คชนั ควรไดร้ บั การทดสอบบนอปุ กรณจ์ รงิ ทมี่ รี ายละเอยี ดคณุ สมบตั ิ ของอุปกรณ์ ครอบคลมุ กลุ่มเป้าหมายผ้ใู ช้งาน D. แอปพลิเคชันควรได้รับการทดสอบบนทุกระบบปฏิบัติการ ท่ีเป็น กลมุ่ เป้าหมายของการนำ� ไปใชง้ านจริง E. แอปพลิเคชันควรทดสอบกับข้อมูลจริงหรือข้อมูลท่ีจ�ำลองเสมือนใน ปริมาณข้อมูลที่เหมาะสมกับการน�ำไปใช้งานจริงเพ่ือให้เห็นสภาพของ การใช้งานจริง F. แอปพลิเคชันควรได้รับการทดสอบสถานการณ์จ�ำลองข้อผิดพลาดใน การใชง้ านทอ่ี าจเกิดขนึ้ ไดท้ ้งั หมด 1.4.2. การทดสอบสว่ นตดิ ต่อกบั ผใู้ ชง้ าน (User Interface Testing) A. แอปพลิเคชันต้องได้รับการทดสอบในส่วนของ “ลักษณะทั่วไปของ แอปพลเิ คชนั สว่ นตดิ ตอ่ ผใู้ ชง้ านและการใชง้ านแอปพลเิ คชนั ” ทกุ รายการ ที่เก่ียวข้อง B. แบบฟอร์มส�ำหรับกรอกข้อมูล ทุกจุดต้องได้รับการทดสอบ ความถูกต้องของข้อมูลท่ีสามารถ ใส่ได้ท้ังประเภทข้อมูลรูปแบบ ข้อมูลความถูกต้องของข้อมูล และการน�ำข้อมูลไปใช้งานต่ออย่าง ถกู ตอ้ ง

28Government Mobile Application Standard Version 1.0 C. แอปพลิเคชันควรแสดงผลอย่างถูกต้องในกรณีท่ีระบบปฏิบัติการแสดง สถานะการท�ำงานบางอย่างแทรกเข้ามาในบางส่วนของหน้าจอ เช่น Internet Sharing/Tethering ของระบบปฏิบตั ิการ iOS เป็นตน้ D. แอปพลิเคชนั ควรไดร้ บั การทดสอบการรองรับการสมั ผสั ส่วนต่าง ๆ ของ หน้าจออย่างรวดเรว็ หรอื Input Flooding ในแตล่ ะหน้าจอ 1.4.3. การทดสอบการท�ำงานรว่ มกบั ระบบแจ้งเตือน (Notification System) A. แอปพลเิ คชนั ทม่ี กี ารทำ� งานรว่ มกบั ระบบแจง้ เตอื นตอ้ งไดร้ บั การทดสอบ ในกรณีมีข้อความเตือน ผู้ใช้งานสามารถเรียกอ่านข้อความผ่าน การแจ้งเตือนได้ เมื่อผู้ใช้งานกดข้อความแจ้งเตือนจะสามารถเข้าไปใช้ งานแอปพลิเคชันได้และมีการแสดงหน้าจอที่เหมาะสมสอดคล้องกับ ขอ้ ความแจง้ เตือนที่ไดร้ ับ B. แอปพลเิ คชนั ควรไดร้ บั การทดสอบสถานะของแอปพลเิ คชนั ทงั้ ในสถานะ ท�ำงานอยู่ (Active) ปดิ อย่แู ตอ่ ยใู่ นฉากหลงั (Inactive, Background) หรอื ปดิ อย่อู ยา่ งสมบูรณ์ (Inactive, Closed) เปน็ อยา่ งน้อย

29 มาตรฐานแอปพลเิ คชนั ภาครฐั สำ� หรับอปุ กรณเ์ คลื่อนท่ี เวอร์ชนั 1.0 1.4.4. การทดสอบการทำ� งานกับระบบเครอื ขา่ ย (Network delay and loss of connection) A. แอปพลิเคชันต้องถูกทดสอบว่าสามารถใช้งานได้ปกติในขณะท่ีระบบ เครอื ข่ายมีปญั หาโดยแสดงขอ้ ความแจ้งผ้ใู ช้งานอย่างเหมาะสม B. แอปพลิเคชันที่มีการใช้งานเครือข่ายควรมีการทดสอบการท�ำงานกับ เครอื ข่ายท่มี คี วามเร็วแตกต่างกนั 1.4.5. การทดสอบการทำ� งานกบั API และ/หรอื ระบบแมข่ า่ ยขอ้ มลู (API Testing) A. แอปพลิเคชันต้องได้รบั การทดสอบการทำ� งานรว่ มกับ API ที่จำ� เปน็ B. แอปพลเิ คชันต้องไดร้ ับการทดสอบว่าสามารถทำ� งานได้โดยไมป่ ิดตัวเอง ในกรณีที่ API ท�ำงานผิดพลาด มีการเปลี่ยนแปลงเวอร์ชันหรือ สาเหตุอื่น ๆ ส่งผลให้แอปพลิเคชันไม่สามารถให้บริการได้โดยต้องมี ขอ้ ความแจง้ เตือนแกผ่ ู้ใช้งาน 1.5. สิทธิและข้อตกลงในการใชเ้ คร่อื งมือและองค์ประกอบตา่ ง ๆ จากภายนอก (3rd Party) 1.5.1. ทั่วไป (General) A. ผู้พัฒนาท่ีมีการใช้เคร่ืองมือต่าง ๆ เช่น โปรแกรมจากภายนอก (3rd. Party Application Program) สว่ นตดิ ตอ่ เพอ่ื พฒั นาจากภายนอก (3rd. Party Application Programming Interface; API) ชุดพฒั นา ซอฟตแ์ วรจ์ ากภายนอก (3rd. Party Software Development Kit; SDK) ต้องได้รับอนุญาตให้ใช้เครื่องมือเหล่านั้นในการพัฒนา แอปพลเิ คชนั และสามารถแสดงสทิ ธใ์ิ นการใชง้ านเครอื่ งมอื ดงั กลา่ วได้ B. แอปพลิเคชัน สามารถมีองค์ประกอบต่าง ๆ จากภายนอก เช่น เพลง ภาพถ่ายภาพกราฟิก ฟอนต์ ต้องได้รับอนุญาตให้ใช้องค์ประกอบ เหล่าน้ันในการพัฒนาแอปพลิเคชันและสามารถแสดงสิทธ์ิในการใช้งาน ดังกลา่ วได้

30Government Mobile Application Standard Version 1.0 1.5.2. การใช้งานโปรแกรมตา่ ง ๆ (Developer’s Right and Permission) A. ผู้พัฒนาแอปพลิเคชันจะต้องมีสิทธิ์การใช้งานโปรแกรมทุกตัวท่ีน�ำมา ใช้งาน และมีจ�ำนวนสิทธิ์ที่เพียงพอส�ำหรับจ�ำนวนคนในทีมพัฒนา แอปพลิเคชัน B. สทิ ธใิ์ นการใชง้ านตอ้ งครอบคลมุ ถงึ การนำ� ผลงานจากโปรแกรมไปใชง้ าน จรงิ รวมถงึ การใชท้ ำ� การคา้ ไมใ่ ชเ่ ปน็ สทิ ธทิ์ ดลองใชส้ ทิ ธเิ์ พอื่ การศกึ ษาหรอื สทิ ธ์ิอ่นื ๆ ที่มักไม่อนุญาตใหน้ �ำผลงานไปใชใ้ นวัตถปุ ระสงคด์ ังกลา่ ว 1.5.3. การใช้งานถ่ายภาพกราฟกิ เพลงและส่ือตา่ ง ๆ (Media’s Right) A. ภาพและส่ือทุกอย่างท่ีน�ำมาใช้ต้องได้รับอนุญาตจากเจ้าของภาพ หรือผู้ถือลิขสิทธิ์เป็นลายลักษณ์อักษรหรือใช้ภาพและสื่อท่ีมีข้อตกลง ในการใชง้ านทอ่ี นญุ าตให้นำ� ไปใชใ้ นการพฒั นาแอปพลิเคชนั ได้ B. ห้ามน�ำภาพและส่ือต่าง ๆ มาใช้โดยไม่ได้รับสิทธ์ิไม่ได้รับอนุญาต โดยเดด็ ขาดแม้จะใหเ้ ครดิตชัดเจนภายในแอปพลเิ คชันก็ตาม

31 มาตรฐานแอปพลเิ คชนั ภาครัฐส�ำหรบั อุปกรณเ์ คลอื่ นที่ เวอรช์ ัน 1.0 C. ในกรณีที่เป็นภาพหรือสื่อที่ทางผู้พัฒนาได้สิทธ์ิมาก่อนในการพัฒนา แอปพลิเคชันหรือสร้างสรรค์ผลงานอ่ืน ต้องตรวจสอบให้แน่ใจว่า สามารถใช้กบั การพัฒนาแอปพลเิ คชนั ใหม่ได้ 1.5.4. การใชฟ้ อนต์ (Font) A. ฟอนต์ที่น�ำมาใช้ต้องได้รับอนุญาตในการใช้งานในแอปพลิเคชัน จากเจ้าของฟอนต์หรือผู้ถือลิขสิทธ์ิเป็นลายลักษณ์อักษรหรือ ใช้ฟอนต์ที่มีข้อตกลงในการใช้งานท่ีอนุญาตให้น�ำไปใช้ในการพัฒนา แอปพลเิ คชันได้ B. ฟอนต์ที่ผู้พัฒนาได้สิทธ์ิในการใช้งานส�ำหรับงานสร้างสรรค์อื่น ๆ เช่น สอื่ สงิ่ พมิ พจ์ ะตอ้ งตรวจสอบใหแ้ นใ่ จวา่ สามารถนำ� มาใชง้ านในการพฒั นา แอปพลเิ คชนั ได้

32Government Mobile Application Standard Version 1.0 1.5.5. การใช้งาน API และ SDK จากภายนอก (External API/SDK) A. แอปพลิเคชันที่มีการพัฒนาโดยการน�ำส่วนติดต่อเพื่อพัฒนาโปรแกรม (API) หรือชุดพฒั นาซอฟต์แวร์ (Software Development Kit; SDK) จากภายนอกเขา้ มาใชง้ านจะตอ้ งพจิ ารณาขอ้ ตกลงในการใชง้ าน API และ SDK ตา่ ง ๆ โดยละเอยี ด B. ข้อตกลงการใช้งาน API และ SDK ท่ีน�ำมาใช้งาน ต้องไม่ละเมิด หรอื ขดั ตอ่ ความเปน็ เจา้ ของลขิ สทิ ธส์ิ ทิ ธกิ์ ารใชง้ านการเปดิ รหสั ซอฟตแ์ วร์ หรือส่วนของซอฟต์แวร์ตามท่ีระบุไว้ในสัญญาการพัฒนาแอปพลิเคชัน ของหนว่ ยงาน C. ข้อตกลงการใช้งาน API และ SDK ที่น�ำมาใช้งานทั้งหมดต้องมี ความสอดคล้องกนั ไมข่ ดั แยง้ กัน D. ผู้พัฒนาต้องแสดงรายการของ API และ SDK ที่นำ� มาใชง้ านทง้ั หมด และ แสดงข้อตกลงในการใช้งานเสมอ E. ผู้พัฒนาต้องท�ำตามข้อตกลงการใช้งาน API และ SDK ท่ีน�ำมาใช้งาน อยา่ งเคร่งครัด

33 มาตรฐานแอปพลิเคชันภาครัฐสำ� หรับอุปกรณเ์ คลอื่ นที่ เวอรช์ ัน 1.0 2 คณุ สมบัตดิ า้ นความมัน่ คงปลอดภัย (Security Functional Requirement) ความมัน่ คงปลอดภัย 2.1. (Security) 2.1.1. การจดั การข้อมลู ท่มี คี วามส�ำคัญ (Sensitive Information) A. ข้อมูลท่ีเป็น Sensitive Information ต้องมีการเข้ารหัสเสมอแม้ว่า จะเปน็ การเกบ็ ไวช้ ว่ั คราวในเครอื่ งของผใู้ ชง้ านในระบบแมข่ า่ ยขอ้ มลู และ การส่งข้อมูลผ่านระบบเครือข่ายทั้งหมดเช่นข้อมูลส่วนตัวของผู้ใช้งาน ขอ้ มูลบตั รเครดิตข้อมลู บญั ชธี นาคาร เปน็ ตน้ B. เมื่อมีการปิดแอปพลิเคชันต้องพิจารณาไม่ให้เข้าถึงข้อมูลส�ำคัญ (Sensitive Information) โดยไม่ใส่รหัสผ่านเพ่ือยืนยันตัวตนอีกครั้ง แมผ้ ู้ใช้งานจะยงั คงเขา้ ระบบค้างอยูก่ ็ตาม C. การแสดงผลต้องมีการแทนขอ้ มลู จริงดว้ ยเคร่ืองหมาย * เสมอโดยแทน ทั้งข้อความหรือในกรณีที่เป็นข้อมูลท่ีต้องการให้ผู้ใช้งานเห็นบางส่วน กจ็ ะตอ้ งแทนด้วย * อย่างนอ้ ย 25% ของขอ้ มูลทงั้ หมด

34Government Mobile Application Standard Version 1.0 2.1.2. มาตรการรองรบั ส�ำหรบั ความปลอดภยั เม่ืออปุ กรณ์สูญหาย (Security on loss devices) A. ในกรณีท่ีระบบรองรับการให้ผู้ใช้งาน 1 คนเข้าสู่ระบบเพ่ือใช้งาน พร้อมกันได้มากกว่า 1 อุปกรณ์ต้องรองรับการสั่งให้ออกจากระบบ พร้อมกันหมดทุกอุปกรณ์ รวมถึงการลบข้อมูลความเป็นส่วนตัวและ ขอ้ มลู ชวั่ คราวทง้ั หมดของผใู้ ช้งานออกจากเครอ่ื ง 2.1.3. การติดตอ่ กบั ระบบแมข่ า่ ยข้อมูล (Networking) A. การส่งข้อมูลที่เป็นข้อมูลส่วนตัวของผู้ใช้งานข้อมูลส�ำคัญ (Sensitive Information) ระหว่างแอปพลิเคชัน และระบบแม่ข่ายข้อมูล ต้องมีการเข้ารหัสข้อมูลเสมอไม่สามารถส่งเป็นข้อความธรรมดา (Plain Text) ได้ B. การส่งข้อมูลส่วนตัวของผู้ใช้งานต้องท�ำผ่าน Secure Channel (SSL/TLS) C. ในการเขา้ ถงึ ขอ้ มลู ทเี่ ปน็ สว่ นตวั ของผใู้ ชง้ านทเี่ กบ็ ไวท้ ร่ี ะบบแมข่ า่ ยขอ้ มลู ตอ้ งรบั รองว่าเปน็ ผไู้ ดร้ ับอนุญาตในการเข้าถงึ เท่าน้ัน

35 มาตรฐานแอปพลิเคชนั ภาครัฐสำ� หรบั อปุ กรณเ์ คล่ือนท่ี เวอร์ชัน 1.0 D. ต้องพิจารณาข้อมูลสาธารณะ (Public Data) หรือการตอบสนองจาก Public API ท่ีสามารถเข้าถึงได้จากภายในแอปพลิเคชันโดยไม่มีข้อมูล ความเป็นส่วนตัวของผู้ใช้งานและเข้าถึงได้โดยไม่ต้องท�ำการเข้าระบบ จึงจะสามารถส่งเป็น Plain Text ทไี่ มต่ ้องเขา้ รหัสได้ 2.1.4. การระบุตัวตนผู้ใช้งาน (Authentication) A. แอปพลิเคชันควรรองรับการระบุตัวตนผู้ใช้งานด้วยเทคโนโลยีระบุ ตัวตนแบบใหม่ เช่น OAuth 2.0 แทนการส่งขอ้ มูลการเขา้ ใช้งานระบบ (ชื่อบญั ชีผูใ้ ชง้ านและรหสั ผา่ น) B. หากจ�ำเป็นต้องส่งชื่อบัญชีผู้ใช้งานและรหัสผ่านให้จัดการตามวิธีการ จดั การขอ้ มลู ทเ่ี ปน็ Sensitive Information C. ควรพิจารณาการระบุตัวตนโดยใช้องค์ประกอบหรือปัจจัยอย่างน้อย 2 อย่าง (2 Factors Authentication) หรอื มากกว่าน้นั เช่น การทำ� งาน ร่วมกับระบบ One-Time Password (OTP) ไปยังหมายเลขโทรศัพทท์ ี่ ได้ระบุไวเ้ ป็นตน้



37 มาตรฐานแอปพลเิ คชันภาครฐั ส�ำหรบั อปุ กรณ์เคล่ือนที่ เวอรช์ ัน 1.0 > การอ้างองิ ลำ� ดบั แหลง่ ข้อมลู ประเทศกลุ่ม 1. Mobile Government สหรัฐอาหรับเอมเิ รตส์ แหลง่ ท่ีมา : http://www.government.ae/docu- ments/10138/98433/Guidelines_En_ mGov_final.pdf 2. Enterprise Mobile Application Lifecycle กลุ่มผพู้ ัฒนาระดบั สากล Developing a Process for End to End Mobile Application Development. แหล่งทม่ี า : http://www.enterprisemanagement360. com/wp-content/files_ mf/1341922927entlifecycle.pdf 3. Modeling the Mobile Application กลมุ่ ผู้พัฒนาระดับสากล Development Lifecycle แหล่งทม่ี า : http://www.iaeng.org/publication/ IMECS2014/IMECS2014_pp596-600.pdf 4. Smartphone Secure Development สหภาพยุโรป Guidelines for App Developers แหล่งทมี่ า : www.enisa.europa.eu

38Government Mobile Application Standard Version 1.0 ล�ำดบั แหลง่ ขอ้ มูล ประเทศกล่มุ 5. Technical Considerations for 5 Vetting สหรัฐอเมรกิ า 3rd Party Mobile 6 Applications (Draft) แหลง่ ทมี่ า : http://csrc.nist.gov/publications/ drafts/800-163/sp800_163_draft.pdf 6. Information technology -- Security องคก์ รอิสระ techniques -- Evaluation criteria for IT security -- Part 3: Security assurance components, ISO/IEC 15408-3:2008 แหลง่ ทีม่ า : http://www.iso.org/iso/home/store/ catalogue_tc/catalogue_detail. htm?csnumber=46413 7. Delivering enterprise information สหรัฐอเมริกา securely on Android, Apple iOS and Microsoft Windows tablets and smart- phones, แหลง่ ทมี่ า : http://www.citrix.com/content/dam/ citrix/en_us/documents/oth/delivering- enterprise-informati on-securely.pdf 8. The Digital by Default Service Standard สหราชอาณาจักร แหลง่ ทม่ี า : https://www.gov.uk/service-manual/ digital-by-default

39 มาตรฐานแอปพลิเคชนั ภาครัฐส�ำหรบั อุปกรณเ์ คลือ่ นท่ี เวอรช์ ัน 1.0 ล�ำดับ แหล่งข้อมูล ประเทศกล่มุ 9. http://en.wikipedia.org/wiki/Iterative_ สหรัฐอเมริกา and_incremental_development 10. http://www.scrumguides.org/docs/ สหรฐั อเมริกา scrumguide/v1/scrum-guide-us.pdf 11. http://docs.telerik.com/platform/ สหรัฐอเมริกา appbuilder/code-signing-your-app/ กลุ่มผพู้ ฒั นาระดบั สากล configuring-code-signing กล่มุ ผพู้ ัฒนาระดบั สากล -for-ios-apps/register-app-id 12. App Quality Alliance (AQuA) Best Practice Guidelines แหลง่ ทมี่ า : http://www.appqualityalliance.org 13. Best Practices for Mobile Application Developers. แหล่งท่มี า : https://www.cdt.org/files/pdfs/Best- Practices-Mobile-App-Developers.pdf