ประกวดราคาจ้างเหมาเพิ่มประสิทธิภาพแพลตฟอร์ม Sphere เพื่อบริหารจัดการตรวจสอบการเข้าถึงและการให้บริการ

• เพื่อเพิ่มประสิทธิภาพและความเสถียรของแพลตฟอร์ม Sphere และระบบ GISTDA API Gateway
• ให้สามารถบริหารจัดการการเข้าถึงและการให้บริการได้อย่างปลอดภัย โปร่งใส ตรวจสอบได้
• ให้ระบบรองรับการขยายตัวของผู้ใช้งานในอนาคต
• พัฒนากลไกการควบคุมสิทธิ์ การตรวจสอบและเฝ้าระวังการใช้งาน
• บำรุงรักษาระบบให้พร้อมใช้งานอย่างต่อเนื่อง

• บริหารจัดการโครงการร่วมกับ สทอภ.: จัดประชุม Kick-off, ประชุมเก็บความต้องการ, จัดทำแผนดำเนินงาน (Project Plan), จัดประชุมรายงานความก้าวหน้าอย่างน้อยเดือนละครั้ง
• วิเคราะห์การทำงานระบบ GISTDA API Gateway ที่มีอยู่เดิม: วิเคราะห์ระบบและกระบวนการที่เกี่ยวข้อง จัดทำข้อเสนอแนะและแนวทางการพัฒนาต่อยอด จัดทำเอกสารสรุปผลการวิเคราะห์
• ออกแบบส่วนบริหารจัดการสิทธิ์ของผู้ใช้และแพ็กเกจของเซอร์วิสร่วมกับ สทอภ.: ออกแบบ Authentication (เช่น Email, Social Login), ออกแบบระดับผู้ใช้ (Root, Admin, Officer, User), ออกแบบส่วนติดต่อผู้ใช้ (Management Console สำหรับ Admin/ Officer และส่วนสำหรับ User), ออกแบบแพ็กเกจบริการ จัดทำเอกสารการออกแบบในรูปแบบเมทริกซ์หรือแผนภูมิ
• ปรับปรุงและพัฒนาต่อยอดระบบ GISTDA API Gateway:
  • ปรับปรุง User Interface ให้ทันสมัยและรองรับ Responsive Web Design
  • พัฒนาระบบตามผลการวิเคราะห์และออกแบบ
  • พัฒนาเมนูและฟังก์ชันการทำงานสำหรับผู้ใช้ทั่วไป (Dashboard, API Keys, Services, Profile, Credit wallet, API Documentation)
  • พัฒนาเมนูและฟังก์ชันการทำงานสำหรับผู้ดูแลระบบ (Dashboard, API Keys, Services, Users and Permissions, Packages, Usage/Statistics, Profile)
  • พัฒนาระบบลงทะเบียนผู้ใช้ (ด้วยอีเมลและ Thai ID)
  • พัฒนาระบบบริหารจัดการ Services (แสดงรายการ, ค้นหา, ลงทะเบียนบริการจากภายนอกเช่น ArcGIS Service, จัดการ Endpoint)
  • พัฒนาระบบบริหารจัดการผู้ใช้และสิทธิ์ (แสดงรายการ, ระงับการใช้งาน, จัดการสิทธิ์ระดับ User/Group, จัดการโควต้าเครดิต)
  • พัฒนาระบบบริหารจัดการแพ็กเกจ (Packages)
  • พัฒนาระบบแสดงผลและสรุปผลการใช้บริการ (Usage Dashboard)
  • พัฒนาระบบแจ้งเตือนและการตัดบริการอัตโนมัติตามเครดิต
  • จัดเก็บประวัติการใช้งาน
  • ย้ายบริการข้อมูล (Migrate Services) โดยไม่กระทบระบบเดิม
  • ใช้ GitLab ของ สทอภ. สำหรับ Version Control
  • ทดสอบระบบบน Development Zone ก่อน deploy ไปยัง Production
• จัดฝึกอบรมเชิงปฏิบัติการ พร้อมจัดทำคู่มือ: ฝึกอบรมการจัดการผู้ใช้/สิทธิ์/คำนวณค่าใช้จ่าย และการปรับปรุง Services ให้เจ้าหน้าที่ สทอภ. อย่างละไม่น้อยกว่า 1 วัน (รูปแบบ on-site)
• จัดทำแผนการบำรุงรักษา (Maintenance): จัดทำแผนการดำเนินงานและค่าใช้จ่ายแบบรายปีเป็นระยะเวลา 1 ปี (เพื่อให้ สทอภ. พิจารณาต่อไป)

• สรุปรายงานการประชุมเริ่มโครงการ (Kick-Off)
• เอกสารสรุปการประชุมเก็บความต้องการและให้ข้อเสนอแนะ
• เอกสารแผนการดำเนินงานปรับปรุงและพัฒนาระบบ (Project Plan)
• เอกสารสรุปผลการวิเคราะห์ระบบ GISTDA API Gateway ที่มีอยู่เดิม พร้อมข้อเสนอแนะ
• เอกสารการออกแบบส่วนบริหารจัดการสิทธิ์ของผู้ใช้และแพ็กเกจของเซอร์วิส (รูปแบบตารางเมทริกซ์หรือแผนภูมิ)
• ระบบ GISTDA API Gateway ที่ปรับปรุงและพัฒนาต่อยอดแล้ว พร้อมฟังก์ชันครบถ้วนตามข้อกำหนด
• รายงานการฝึกอบรม (แผนการฝึกอบรม, ภาพบรรยากาศ, ใบเซ็นชื่อผู้เข้าอบรม)
• Source code ทั้งหมดของโครงการ (ผ่าน GitLab ของ สทอภ.)
• เอกสารการทดสอบการใช้งานระบบ (UAT)
• เอกสารแผนการบำรุงรักษา (Maintenance) แบบรายปี 1 ปี
• เอกสารรายงานฉบับสมบูรณ์ (Hard copy และ Digital file)

ระยะเวลาดำเนินงานทั้งหมด 240 วัน นับถัดจากวันลงนามในสัญญา โดยมีกำหนดส่งมอบงานเป็นงวดดังนี้:

• งวดที่ 1 (ภายใน 60 วัน): ส่งมอบเอกสารสรุปการประชุม Kick-off, เอกสารเก็บความต้องการ, แผนดำเนินงาน และสรุปผลการวิเคราะห์ระบบเดิม
• งวดที่ 2 (ภายใน 180 วัน): ส่งมอบเอกสารการออกแบบ และระบบ GISTDA API Gateway ที่พัฒนาต่อยอดแล้ว
• งวดที่ 3 (ภายใน 240 วัน): ส่งมอบงานฝึกอบรม, source code, เอกสาร UAT, และแผนการบำรุงรักษา

• Eligibility Requirements: ต้องผ่านการคัดเลือกผู้ที่มีคุณสมบัติเบื้องต้นในการจัดจ้างของ สทอภ.
• Standards Compliance: -
• Experience: ผู้ยื่นข้อเสนอต้องมีผลงานประเภทเดียวกันกับการจ้างในการพัฒนาระบบ API Gateway ร่วมกับระบบภูมิสารสนเทศ ตามภาคผนวก ก. ในวงเงินไม่น้อยกว่า 2,000,000 บาท (สองล้านบาท) ในสัญญาเดียว ภายในเวลาไม่เกิน 5 ปี นับถัดจากวันที่งานแล้วเสร็จ จนถึงวันยื่นข้อเสนอ อย่างน้อย 1 ผลงาน และเป็นผลงานที่เป็นคู่สัญญาโดยตรงกับส่วนราชการ/หน่วยงานของรัฐ/หน่วยงานเอกชนที่ สทอภ. เชื่อถือ
• Previous Project Cost: ต้องมีผลงานที่มีมูลค่าสัญญาไม่น้อยกว่า 2,000,000 บาท
• Technical Capabilities: ต้องมีความสามารถในการพัฒนาระบบตามแนวคิด Microservices และรองรับการทำงานแบบ Containerized บน Kubernetes หรือสถาปัตยกรรมที่ดีกว่า ต้องสามารถใช้เครื่องมือ GitLab ของ สทอภ. ในการควบคุมเวอร์ชันได้
• Personnel: ต้องมีผู้จัดการโครงการจำนวน 1 คน ซึ่งมีประสบการณ์บริหารโครงการที่เกี่ยวข้องกับงานด้านการพัฒนาระบบภูมิสารสนเทศ (ต้องยื่น CV ประกอบ)

การพิจารณาใช้หลักเกณฑ์การประเมินค่าประสิทธิภาพต่อราคา (70:30) โดยแบ่งคะแนนดังนี้:

• เกณฑ์คุณภาพ (70 คะแนน):
  1. แนวทางในการพัฒนาระบบ (15 คะแนน): แผนการดำเนินงาน (5 คะแนน), แผนภาพแบบจำลองความคิด (5 คะแนน), แผนผัง Data flow diagram (DFD) (5 คะแนน)
  2. เทคโนโลยีที่จะนำมาใช้ในโครงการ (35 คะแนน): การใช้ซอฟต์แวร์รหัสเปิด (Open Source) (10 คะแนน), การใช้มาตรฐานแบบเปิด (OGC API และ/หรือ ArcGIS Service) (สูงสุด 20 คะแนน), สถาปัตยกรรม Microservices และ Containerized (5 คะแนน)
  3. ตัวอย่าง Mock up (10 คะแนน): มีตัวอย่างหน้าจอ Mock up/ต้นแบบตามส่วนการออกแบบและพัฒนาระบบ
  4. ข้อเสนอพิเศษนอกเหนือจาก TOR (10 คะแนน): เสนอเครื่องมือหรือฟังก์ชันเพิ่มเติมที่เกี่ยวข้องกับการบริหารจัดการ API (เช่น การรวม Multiple Services เป็น Single Endpoint)
• เกณฑ์ราคา (30 คะแนน): พิจารณาจากราคาที่เสนอ
  เงื่อนไขสำคัญ: หากคะแนนในเกณฑ์คุณภาพ (ข้อ 1-4) รวมกันไม่ถึง 50 คะแนนจาก 70 คะแนน จะไม่พิจารณาข้อเสนอด้านราคา และผู้ยื่นข้อเสนอต้องมานำเสนอและชี้แจงผลงานต่อคณะกรรมการในรูปแบบ onsite ที่สำนักงาน สทอภ. ภายใน 3 วันทำการนับถัดจากวันเสนอราคา

• สถาปัตยกรรมระบบ: ต้องออกแบบตามหลักแนวคิด Microservices และรองรับการทำงานแบบ Containerized บน Kubernetes หรือสถาปัตยกรรมที่ดีกว่า
• มาตรฐานที่ต้องรองรับ: ระบบที่พัฒนาต้องรองรับ APIs for the Web ตามมาตรฐาน OGC API และ/หรือ ArcGIS Service (Map service, Feature service, Image service)
• การพิสูจน์ตัวตนและให้สิทธิ์ (Authentication & Authorization): ต้องลดความซ้ำซ้อน โดยรองรับการเข้าสู่ระบบด้วยช่องทางต่างๆ เช่น Email, Social Login, OpenID และต้องมีการออกแบบระดับผู้ใช้ 4 ระดับ (Root, Admin, Officer, User) พร้อมระบบจัดการสิทธิ์ที่ชัดเจนและยืดหยุ่น
• ส่วนติดต่อผู้ใช้ (UI/UX): ต้องพัฒนาตามหลัก Responsive Web Design และแยกส่วนติดต่อเป็น 2 ส่วนหลัก ได้แก่ Management Console สำหรับผู้ดูแลระบบ และส่วนสำหรับผู้ใช้ทั่วไป
• ฟังก์ชันหลักสำหรับผู้ใช้ทั่วไป: ต้องมี Dashboard แสดงสถิติการใช้เครดิตและบริการ, การจัดการ API Keys (พร้อม Domain/IP Whitelisting), ดูรายการ Services, จัดการ Profile, ตรวจสอบ Credit wallet, และเข้าถึง API Documentation
• ฟังก์ชันหลักสำหรับผู้ดูแลระบบ: ต้องมี Dashboard แสดงสถิติภาพรวมระบบ, การจัดการ API Keys, การบริหารจัดการ Services (รวมถึงการลงทะเบียนบริการจากภายนอกเช่น ArcGIS Service และ Tiles), การบริหารจัดการผู้ใช้และสิทธิ์ (Users and Permissions), การจัดการแพ็กเกจ (Packages), การแสดงผลสถิติการใช้งาน (Usage/Statistics)
• ระบบจัดการเครดิต (Credit Management): ต้องมีระบบแจ้งเตือนเมื่อเครดิตใกล้หมด และตัดบริการอัตโนมัติเมื่อใช้เกินโควต้าหรือวงเงิน
• การลงทะเบียนบริการจากภายนอก: ต้องรองรับการลงทะเบียนบริการข้อมูลประเภท ArcGIS Service (Map service, Feature service, Image service) และ Tiles ในรูปแบบ PNG/WEBP
• การทดสอบและ Deployment: ต้องทดสอบระบบบน Development Zone ของ สทอภ. ทุกครั้งก่อนนำขึ้น Production
• Version Control: ต้องใช้ GitLab ของ สทอภ. ในการควบคุมเวอร์ชันซอร์สโค้ดตลอดโครงการ

• วงเงินจัดจ้าง: 4,400,000 บาท (รวม VAT)
• การชำระเงิน: แบ่งเป็น 3 งวด
  • งวดที่ 1 (10%): หลังส่งมอบงานงวดแรกครบถ้วนและตรวจรับแล้ว (ภายใน 60 วัน)
  • งวดที่ 2 (50%): หลังส่งมอบงานงวดที่สองครบถ้วนและตรวจรับแล้ว (ภายใน 180 วัน)
  • งวดที่ 3 (40%): หลังส่งมอบงานงวดสุดท้ายครบถ้วนและตรวจรับแล้ว (ภายใน 240 วัน)
• ค่าปรับ: หากส่งมอบงานล่าช้า ชำระค่าปรับร้อยละ 0.10 ของราคาสัญญาต่อวัน (ไม่ต่ำกว่าวันละ 100 บาท)
• ระยะเวลารับประกัน: 1 ปี นับจากวันที่ส่งมอบงานงวดสุดท้ายและตรวจรับเรียบร้อยแล้ว
• หลักประกันสัญญา: ผู้รับจ้างต้องมอบหลักประกันสัญญาร้อยละ 5 ของราคาค่าจ้าง
• สิทธิ์ในทรัพย์สินทางปัญญา: ผู้ว่าจ้าง (สทอภ.) เป็นเจ้าของลิขสิทธิ์หรือทรัพย์สินทางปัญญาในผลงานที่พัฒนาขึ้นใหม่ตามสัญญาทั้งหมดแต่เพียงผู้เดียว

• Q: ระบบที่พัฒนาต้องรองรับการลงทะเบียนบริการข้อมูลจากแหล่งภายนอกประเภทใดบ้าง?
  A: ระบบต้องรองรับการลงทะเบียนบริการข้อมูลประเภท ArcGIS Service ได้อย่างน้อย 3 ประเภท ได้แก่ Map service, Feature service และ Image service รวมถึงรองรับบริการข้อมูลแบบ Tiles ในรูปแบบไฟล์ PNG และ WEBP

• Q: การออกแบบ Authentication ของระบบต้องเป็นไปตามข้อกำหนดใด?
  A: ต้องลดความซ้ำซ้อนในการเข้าสู่ระบบ โดยให้ผู้ใช้งานสามารถเลือกเชื่อมโยงช่องทางเข้าสู่ระบบหลายช่องทางเข้าด้วยกันได้ด้วยตนเอง เช่น Email, Social Login (เช่น Google) หรือ OpenID ของหน่วยงาน

• Q: ระบบต้องมีการจัดการสิทธิ์ผู้ใช้ในระดับใดบ้าง?
  A: ระบบต้องออกแบบระดับผู้ใช้ 4 ระดับ ได้แก่ Root (สิทธิ์สูงสุด), Admin (ผู้ดูแลระบบ), Officer (ผู้จัดการบริการ), และ User (ผู้ใช้งานทั่วไป) และต้องสามารถจัดการสิทธิ์ได้ในระดับผู้ใช้ (user), ระดับกลุ่ม (group) และกลุ่มย่อย (subgroup) อย่างน้อยหนึ่งลำดับ

• Q: ระบบ Credit wallet มีฟังก์ชันการทำงานอะไรบ้างที่สำคัญ?
  A: นอกจากการแสดงเครดิตคงเหลือและประวัติใช้จ่ายแล้ว ระบบต้องสามารถแจ้งเตือนผู้ใช้เมื่อเครดิตใกล้หมดผ่านอีเมล และต้องสามารถตัดบริการต่างๆ ได้โดยอัตโนมัติเมื่อผู้ใช้มีการใช้งานเกินโควต้าเครดิตหรือวงเงินที่จ่าย

• Q: ผู้รับจ้างต้องดำเนินการทดสอบระบบอย่างไรก่อนนำขึ้นใช้งานจริง?
  A: ผู้รับจ้างต้องดำเนินการทดสอบระบบบน Development Zone ของ สทอภ. ทุกครั้ง เพื่อทดสอบความถูกต้อง ความพร้อมใช้งาน ประสิทธิภาพ และความเสถียรของระบบ ก่อนจะดำเนินการให้บริการระบบบน Production Zone

• Q: มีข้อกำหนดเกี่ยวกับเครื่องมือในการพัฒนาหรือควบคุมซอร์สโค้ดหรือไม่?
  A: ใช่ ผู้รับจ้างต้องใช้เครื่องมือ GitLab ของ สทอภ. เป็นระบบควบคุมเวอร์ชัน (Version Control System) ในการพัฒนา ปรับปรุง และบริหารจัดการซอร์สโค้ดของระบบตลอดระยะเวลาดำเนินโครงการ

• Q: ระบบสำหรับผู้ใช้ทั่วไปและผู้ดูแลระบบมีเมนูหรือฟังก์ชันที่แตกต่างกันอย่างไร?
  A: ผู้ใช้ทั่วไปจะเข้าถึงเมนูเช่น Dashboard ส่วนตัว, API Keys, Services ตามสิทธิ์, Profile, Credit wallet และ API Documentation ส่วนผู้ดูแลระบบจะเข้าถึงเมนูสำหรับจัดการระบบ เช่น Dashboard ภาพรวม, จัดการ Services, จัดการผู้ใช้และสิทธิ์ (Users and Permissions), จัดการแพ็กเกจ (Packages) และดูสถิติการใช้งาน (Usage/Statistics)

• Q: ข้อเสนอพิเศษที่นอกเหนือจาก TOR สามารถเสนออะไรได้บ้าง และมีเงื่อนไขอย่างไร?
  A: สามารถเสนอเครื่องมือหรือฟังก์ชันที่เกี่ยวข้องกับการบริหารจัดการ API ที่เป็นประโยชน์ต่อโครงการ เช่น ฟังก์ชันการรวมหลายบริการข้อมูล (Multiple Services) จากแหล่งที่ต่างกันให้เป็นจุดให้บริการเดียว (Single Endpoint) ข้อเสนอพิเศษดังกล่าวต้องไม่ซ้ำกับฟังก์ชันที่มีอยู่เดิมและต้องเป็นลิขสิทธิ์ของ สทอภ. ทั้งหมด

• Q: การฝึกอบรมที่ต้องจัดให้กับเจ้าหน้าที่ สทอภ. มีรายละเอียดอย่างไร?
  A: ต้องจัดฝึกอบรม 2 หัวข้อ ได้แก่ 1) การจัดการผู้ใช้งานและสิทธิ์การใช้งาน รวมถึงคำนวณค่าใช้จ่ายการใช้บริการ และ 2) การปรับปรุงอัปเดตข้อมูลส่วนให้บริการข้อมูล (Service) แต่ละหัวข้อต้องมีผู้เข้าอบรมตั้งแต่ 5 คนขึ้นไป และใช้เวลาไม่น้อยกว่า 1 วันต่อหัวข้อ โดยจัดในรูปแบบ on-site ณ สำนักงาน สทอภ.

• Q: หลังโครงการสิ้นสุด ผู้รับจ้างต้องส่งมอบอะไรเพิ่มเติมเกี่ยวกับการบำรุงรักษา?
  A: ผู้รับจ้างต้องจัดทำแผนการบำรุงรักษา (Maintenance) หลังจากสิ้นสุดระยะเวลารับประกัน โดยเสนอแผนการดำเนินงานและค่าใช้จ่ายแบบรายปี เป็นระยะเวลา 1 ปี ให้ สทอภ. พิจารณา (เพื่อใช้เป็นแนวทางในการตัดสินใจต่อไป)

หน้า 1/19
ขอบเขตของงาน (Term of Reference: TOR)
จ้างเหมาเพิ่มประสิทธิภาพแพลตฟอร์ม Sphere เพื่อบริหารจัดการตรวจสอบการเข้าถึงและการให้บริการ ภายใต้แผนงานการบํารุงรักษาระบบโครงสร้างพื้นฐานการบริการภูมิสารสนเทศแบบออนไลน์

1. หลักการและเหตุผล
   ในยุคที่การให้บริการข้อมูลภูมิสารสนเทศและบริการดิจิทัลกลายเป็นพื้นฐานสําคัญของการบริหารจัดการ ทั้งภาครัฐและภาคเอกชน ภารกิจด้านภูมิสารสนเทศ สทอภ. (GI) มีหน้าที่ในการจัดทําและบริหารคลังข้อมูล รวมทั้งจัดการการให้บริการข้อมูลภูมิสารสนเทศผ่านแพลตฟอร์ม Sphere เพื่อเผยแพร่ข้อมูลสู่สาธารณะที่สามารถ นําไปวิเคราะห์ต่อยอดเพื่อสนับสนุนการตัดสินใจรวมถึงให้บริการต่อประชาชน โดยมี GISTDA API Gateway ทํา หน้าที่เป็นช่องทางหลักในการจัดการการเผยแพร่และควบคุมการเข้าถึงบริการข้อมูลภูมิสารสนเทศ (Services) ของ สทอภ. ด้วยการเติบโตของจํานวนผู้ใช้ ประเภทของผู้ใช้ และรูปแบบการใช้งานที่หลากหลาย ส่งผลให้เกิด ความซับซ้อนด้านการกํากับสิทธิ์ การพิสูจน์ตัวตน และการบริหารอัตราการใช้งาน
   ปัจจุบันกลไกการตรวจสอบการเข้าถึงและการให้บริการ ยังพบประเด็นความสามารถในการตรวจสอบ ย้อนหลัง (audit) และการกํากับนโยบายการเข้าถึงที่ยังไม่ครบถ้วน ซึ่งหากมิได้รับการปรับปรุงอาจจะเพิ่มความ เสี่ยงต่อการให้บริการขัดข้อง หรือคุณภาพการให้บริการที่ไม่เป็นไปตามมาตรฐาน ทําให้เกิดผลกระทบต่อความ เชื่อมั่นของผู้ใช้และการดําเนินงานของหน่วยงาน
   ดังนั้น การจ้างเหมาเพื่อเพิ่มประสิทธิภาพแพลตฟอร์ม Sphere พัฒนาและปรับปรุงส่วนบริหารจัดการ ตรวจสอบการเข้าถึงและการให้บริการข้อมูล (GISTDA API Gateway) จึงมีความจําเป็นเชิงยุทธศาสตร์ เพื่อให้ แพลตฟอร์มสามารถรองรับรูปแบบการให้บริการข้อมูลที่หลากหลาย จัดการปริมาณการใช้งานที่เพิ่มขึ้น มีความ ปลอดภัยและความโปร่งใสในการควบคุมการเข้าถึง การดําเนินงานดังกล่าวจะช่วยยกระดับแพลตฟอร์ม Sphere รองรับการให้บริการข้อมูลที่หลากหลายรูปแบบ ซึ่งเป็นรากฐานสําคัญในการพัฒนาระบบบริการภูมิสารสนเทศ
   ของ สทอภ. ให้สอดคล้องกับมาตรฐานสากลและความต้องการของผู้ใช้ในระยะยาว
2. วัตถุประสงค์
   เพื่อเพิ่มประสิทธิภาพและความเสถียรของแพลตฟอร์ม Sphere และระบบ GISTDA API Gateway ให้ สามารถบริหารจัดการการเข้าถึงและการให้บริการได้อย่างปลอดภัย โปร่งใส ตรวจสอบได้ และรองรับการขยายตัว ของผู้ใช้งาน พร้อมทั้งพัฒนากลไกการควบคุมสิทธิ์ การตรวจสอบและเฝ้าระวังการใช้งาน ตลอดจนบํารุงรักษา
   ระบบให้พร้อมใช้งานอย่างต่อเนื่อง
   012715
   หน้า 2/19
3. คุณสมบัติของผู้ยื่นข้อเสนอ
   3.1 มีความสามารถตามกฎหมาย
   3.2 ไม่เป็นนิติบุคคลล้มละลาย
   3.3 ไม่อยู่ระหว่างเลิกกิจการ
   3.4 ไม่เป็นนิติบุคคลซึ่งอยู่ระหว่างถูกระงับการยื่นข้อเสนอหรือทําสัญญากับหน่วยงานของรัฐไว้ชั่วคราว เนื่องจากเป็นผู้ที่ไม่ผ่านเกณฑ์การประเมินผลการปฏิบัติงานของผู้ประกอบการตามระเบียบที่ รัฐมนตรีว่าการกระทรวงการคลังกําหนดตามที่ประกาศเผยแพร่ในระบบเครือข่ายสารสนเทศของ
   กรมบัญชีกลาง
   3.5 ไม่เป็นนิติบุคคลซึ่งถูกระบุชื่อไว้ในบัญชีรายชื่อผู้ทิ้งงานและได้แจ้งเวียนชื่อให้เป็นผู้ทิ้งงานของ หน่วยงานของรัฐในระบบเครือข่ายสารสนเทศของกรมบัญชีกลางซึ่งรวมถึงนิติบุคคลที่ผู้ทิ้งงานเป็น หุ้นส่วนผู้จัดการ กรรมการผู้จัดการ ผู้บริหาร ผู้มีอํานาจในการดําเนินงานในกิจการของนิติบุคคลนั้น 3.6 มีคุณสมบัติและไม่มีลักษณะต้องห้ามตามที่คณะกรรมการนโยบายการจัดซื้อจัดจ้างและการบริหาร
   พัสดุภาครัฐกําหนดในราชกิจจานุเบกษา
   3.7 นิติบุคคลที่มีอาชีพรับจ้างที่ประกวดราคาอิเล็กทรอนิกส์ ดังกล่าว
   3.8 ไม่เป็นผู้มีผลประโยชน์ร่วมกันกับ ผู้ยื่นข้อเสนอ รายอื่นที่เข้ายื่นข้อเสนอ ให้แก่ สทอภ. ณ วันประกาศ ประกวดราคาอิเล็กทรอนิกส์ หรือไม่เป็นผู้กระทําการอื่นเป็นการอันเป็นขัดขวางการแข่งขันราคาอย่าง เป็นธรรมในการ ประกวดราคาอิเล็กทรอนิกส์ ครั้งนี้
   3.9 ไม่เป็นผู้ได้รับเอกสิทธิ์หรือความคุ้มกัน ซึ่งอาจปฏิเสธไม่ยอมขึ้นศาลไทย เว้นแต่รัฐบาลของผู้ยื่น
   ข้อเสนอได้มีคําสั่งให้สละเอกสิทธิ์และความคุ้มกันเช่นว่านั้น
   3.10 ผู้ยื่นข้อเสนอ ที่ยื่นข้อเสนอในรูปแบบของ “กิจการร่วมค้า” ต้องมีคุณสมบัติดังนี้
   3.10.1 กรณีที่ข้อตกลงระหว่างผู้เข้าร่วมค้า กําหนดให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้เข้าร่วมค้าหลัก
   ข้อตกลงระหว่างผู้เข้าร่วมค้าจะต้องมีการกําหนดสัดส่วนหน้าที่ และความรับผิดชอบในปริมาณ
   งาน สิ่งของ หรือมูลค่าตามสัญญาของผู้เข้าร่วมค้าหลักมากกว่าผู้เข้าร่วมค่ารายอื่นทุกราย 3.10.2 กรณีที่ข้อตกลงระหว่างผู้เข้าร่วมค้า กําหนดให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้เข้าร่วมค้าหลัก
   กิจการร่วมค้านั้นต้องใช้ผลงานของผู้เข้าร่วมค้าหลักรายเดียว เป็นผลงานของกิจการร่วมค้าที่ ยื่นข้อเสนอสําหรับข้อตกลงระหว่างผู้เข้าร่วมค้า ที่ไม่ได้กําหนดให้ผู้เข้าร่วมค้ารายใดเป็น
   ผู้เข้าร่วมค้าหลัก ผู้เข้าร่วมค้าทุกรายจะต้องมีคุณสมบัติครบถ้วนตามเงื่อนไขที่กําหนดไว้ใน เอกสารเชิญชวน
   3.10.3 กรณีที่ข้อตกลงระหว่างผู้เข้าร่วมค้า กําหนดให้มีการมอบหมายผู้เข้าร่วมค้ารายใดรายหนึ่งเป็น ผู้ยื่นข้อเสนอในนามกิจการร่วมค้า การยื่นข้อเสนอดังกล่าวไม่ต้องมีหนังสือมอบอํานาจสําหรับ
   0026
   ชุม
   ช
   หน้า 3/19
   ข้อตกลงระหว่างผู้เข้าร่วมค้า ที่ไม่ได้กําหนดให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้ยื่นข้อเสนอ
   ผู้เข้าร่วมค้าทุกรายจะต้องลงลายชื่อในหนังสือมอบอํานาจ ให้ผู้เข้าร่วมค้ารายใดรายหนึ่งเป็นผู้
   ยื่นข้อเสนอในนามกิจการร่วมค้า
   3.11 ผู้ยื่นข้อเสนอต้องลงทะเบียนที่มีข้อมูลถูกต้องครบถ้วนในระบบจัดซื้อจัดจ้างภาครัฐด้วยอิเล็กทรอนิกส์
   (Electronic Government Procurement: e-GP) ของกรมบัญชีกลาง
   3.12 กรณีผู้ยื่นข้อเสนอเป็นผู้ประกอบการที่ได้ขึ้นทะเบียนเป็นผู้ประกอบการวิสาหกิจขนาดกลางและขนาด
   ย่อม (SMEs) จะต้องยื่นสําเนาใบทะเบียนผู้ประกอบการวิสาหกิจขนากลางและขนาดย่อม (SMEs) 3.13 ต้องผ่านการคัดเลือกผู้ที่มีคุณสมบัติเบื้องต้นในการจัดจ้างของสํานักงานพัฒนาเทคโนโลยีอวกาศและ
   ภูมิสารสนเทศ (องค์การมหาชน)
   3.14 ผู้ยื่นข้อเสนอจะต้องเสนอโครงการที่เป็นผลงานประจักษ์และมีผู้จัดการโครงการที่มีประสบการณ์สูง
   พร้อมแสดงประวัติการทํางาน หรือ หลักฐานอื่นๆ ที่พิสูจน์ได้ อย่างน้อย ดังนี้
   3.14.1 ผู้ยื่นข้อเสนอราคาต้องมีผลงานประเภทเดียวกันกับการจ้างในการพัฒนาระบบ API Gateway ร่วมกับระบบภูมิสารสนเทศตาม ภาคผนวก ก. ในวงเงินไม่น้อยกว่า 2,000,000 บาท (สอง ล้านบาทถ้วน) ในสัญญาเดียว ภายในเวลาไม่เกิน 5 ปี นับถัดจากวันที่งานแล้วเสร็จ จนถึงวัน ยื่นข้อเสนอ อย่างน้อย 1 ผลงาน และเป็นผลงานที่เป็นคู่สัญญาโดยตรงกับส่วนราชการ หน่วยงานตามกฎหมายว่าด้วยระเบียบบริหารราชการส่วนท้องถิ่น รัฐวิสาหกิจ หน่วยงานอื่น ของรัฐ หรือหน่วยงานเอกชนที่สํานักงานเชื่อถือ ทั้งนี้ต้องแนบสําเนาหนังสือรับรองผลงาน และขอบเขตงานจ้างนั้น ๆ พร้อมลงนามรับรองสําเนาถูกต้อง เสนอพร้อมการยื่นข้อเสนอ 3.14.2 ผู้จัดการโครงการจํานวน 1 คน และมีประสบการณ์บริหารโครงการที่เกี่ยวข้องกับงานด้าน
   การพัฒนาระบบภูมิสารสนเทศ โดยต้องยื่น CV (Curriculum Vitae) ประกอบ
4. ขอบเขตการดําเนินงาน
   4.1
   บริหารจัดการโครงการร่วมกับ สทอภ.
   4.2 วิเคราะห์การทํางานระบบ GISTDA API Gateway ที่มีอยู่เดิม
   4.3 ปรับปรุงส่วนบริหารจัดการสิทธิ์ของผู้ใช้และแพ็กเกจของเซอร์วิส รวมถึงออกแบบร่วมกับ สทอภ.
   4.4 ปรับปรุงและพัฒนาต่อยอดระบบ GISTDA API Gateway
   4.5 จัดฝึกอบรมเชิงปฏิบัติการ พร้อมจัดทําคู่มือ
   4.6 จัดทําแผนการบํารุงรักษา (Maintenance)
   Onds
   ल
   Ди
   หน้า 4/19
5. ข้อกําหนดทางเทคนิค
   5.1 บริหารจัดการโครงการร่วมกับ สทอภ. ดังนี้
   5.1.1 ผู้รับจ้างต้องจัดประชุมเริ่มโครงการ (Kick-Off) ภายใน 30 วัน นับถัดจากวันลงนามในสัญญา
   พร้อมสรุปรายงานการประชุม
   5.1.2 ผู้รับจ้างต้องจัดให้มีการประชุมเพื่อเก็บความต้องการและให้ข้อเสนอแนะ สําหรับการออกแบบ
   ระบบร่วมกับ สทอภ. พร้อมสรุปรายงานการประชุม
   5.1.3 ผู้รับจ้างต้องจัดทําแผนการดําเนินงานปรับปรุงและพัฒนาระบบ โดยมีรายละเอียดกิจกรรมใน แต่ละขั้นตอนและระยะเวลาดําเนินการในแต่ละกิจกรรม และนําเสนอต่อคณะกรรมการตรวจ
   รับพัสดุ เพื่อพิจารณา
   5.1.4 ผู้รับจ้างต้องจัดให้มีการประชุมอัปเดตรายงานความก้าวหน้าการดําเนินงานตามแผนงาน อย่าง น้อยเดือนละ 1 ครั้ง หรือตามความเหมาะสมของเนื้องาน และสรุปรายงานการประชุม
   5.2 วิเคราะห์การทํางานระบบ GISTDA API Gateway ที่มีอยู่เดิม รวมถึงกระบวนการอื่นๆ ที่เกี่ยวข้อง
   ตลอดทั้งโครงการ ดังนี้
   5.2.1 ผู้รับจ้างต้องวิเคราะห์ระบบ GISTDA API Gateway ที่มีอยู่เดิม โดยให้ข้อเสนอแนะและจัดทํา
   แนวทางในการพัฒนาต่อยอด ดังนี้
   5.2.1.1 การวิเคราะห์ ออกแบบ และพัฒนาระบบ ต้องสอดคล้องกับสถาปัตยกรรมของ
   โครงสร้างพื้นฐานด้านไอทีและสภาพแวดล้อมการทํางาน ของ สทอภ.
   5.2.1.2 สถาปัตยกรรมภาพรวมของระบบ ต้องออกแบบตามหลักแนวคิด Microservices และ รองรับการทํางานแบบ Containerized บน Kubernetes หรือสถาปัตยกรรมอื่นๆ ที่
   ดีกว่า
   5.2.1.3 Interaction Overview Diagrams ต้องครอบคลุมทุกส่วนของระบบ เช่น ส่วนบริหาร จัดการผู้ใช้และสิทธิ์, ส่วนบริหารจัดการแพ็กเกจของเซอร์วิส และส่วนการใช้งานของ ผู้ใช้ทั่วไป
   5.2.1.4 ระดับและรายละเอียดการพิสูจน์ตัวตน (Authentication) และ การให้สิทธิ์ (Authorization) ที่ต้องลดความซ้ําซ้อน เช่น เข้าสู่ระบบด้วย google และเข้าสู่ด้วย
   อีเมล
   5.2.1.5 User Flow Diagrams แสดงการใช้งานของผู้ใช้ในแต่ละระดับสิทธิ์
   5.2.1.6 รายละเอียดกลุ่มสิทธิ์ พร้อมคําอธิบาย
   5.2.1.7 รายละเอียดแพ็กเกจของเซอร์วิส พร้อมคําอธิบาย
   5.2.1.8 รายละเอียดประเภทเซอร์วิส พร้อมคําอธิบาย
   0318
   দি
   หน้า 5/19
   5.2.1.9 รายการเซอร์วิสทั้งหมดบนระบบ โดยแบ่งเป็นเซอร์วิสสําหรับใช้งานระหว่างแอปพลิเค
   ชันกับแอปพลิเคชัน และเซอร์วิสที่ให้บริการภายนอก
   5.2.1.10 ออกแบบ Screen Designs โดยใช้ Figma
   5.2.2 ผู้รับจ้างต้องนําผลที่วิเคราะห์ได้มาใช้เป็นแนวทางในการพัฒนาและปรับปรุงตามขอบเขตงาน
   ในโครงการจ้างครั้งนี้
   5.2.3 จัดทําเอกสารสรุปผลการวิเคราะห์การทํางานระบบ GISTDA API Gateway ที่มีอยู่เดิม พร้อม
   ข้อเสนอแนะในการพัฒนาปรับปรุงระบบ
   5.3 ออกแบบส่วนบริหารจัดการสิทธิ์ของผู้ใช้และแพ็กเกจของเซอร์วิส ร่วมกับ สทอภ.
   5.3.1 ออกแบบการพิสูจน์ตัวตน (Authentication) สําหรับเข้าใช้งานระบบ เพื่อลดความซ้ําซ้อนใน การใช้งาน (Login) โดยผู้ใช้งานสามารถเลือกเชื่อมโยงช่องทางเข้าสู่ระบบ เช่น Email, Social Login หรือ OpenID ของหน่วยงาน เข้าด้วยกัน ได้ด้วยตนเอง
   5.3.2 ออกแบบระดับผู้ใช้งานและกลุ่มสิทธิ์ พร้อมจัดทําคําอธิบายกํากับ โดยครบคลุมการทํางาน
   ดังนี้
   5.3.2.1 “Root” คือ ผู้ใช้งานระดับสูงสุดที่ มีสิทธิ์ขาดในการบริหารจัดการทุกส่วนของระบบ 5.3.2.2 “Admin” คือ ผู้ดูแลระบบ ที่มีสิทธิ์ในการบริหารจัดการงานทุกอย่างแทนเทียบเท่า
   “Root”
   5.3.2.3 “Officer” คือ ผู้ดูแลและจัดการการให้บริการข้อมูล สามารถมอบหมายสิทธิ์การ ทํางานเพิ่มเติมรายบุคคลให้ทํางานบางอย่างที่ Admin ทําได้ กล่าวคือ ไม่ต้องการให้ ทําตามสิทธิ์ Admin ได้ทั้งหมด
   5.3.2.4 “User” คือ ผู้ใช้งานทั่วไป หรือ ผู้ที่เข้ามาใช้บริการข้อมูล
   5.3.3 ออกแบบส่วนติดต่อผู้ใช้งาน ออกเป็น 2 ส่วน เพื่อให้การบริหารจัดการและการเรียกใช้บริการ
   ข้อมูลมีความชัดเจนและปลอดภัยสูงสุด
   5.3.3.1 สําหรับเจ้าหน้าที่และผู้ดูแลระบบ (Management Console) เป็นผู้ใช้งานที่มีสิทธิ์
   เป็น Root, Admin, Officer
   5.3.3.2 สําหรับผู้ใช้งานทั่วไป อํานวยความสะดวกในการเรียกใช้บริการข้อมูล เป็นผู้ใช้งานที่มี
   สิทธิ์เป็น User
   5.3.4 ออกแบบแพ็กเกจของเซอร์วิส พร้อมจัดทําคําอธิบายกํากับ
   5.3.5 การออกแบบระดับผู้ใช้งานและกลุ่มสิทธิ์ โดยระบบสามารถกําหนดสิทธิ์ให้แอปพลิเคชันเข้าถึง บริการข้อมูลได้โดยตรง โดยไม่ต้องผ่านกระบวนการยืนยันตัวตนผู้ใช้งาน ทั้งนี้ผู้รับจ้างสามารถ เสนอแบบอื่น ๆ ที่เหมาะสมกว่าได้ และต้องนําเสนอและได้รับความเห็นชอบจาก สทอภ.
   OVAT
   On
   หน้า 6/19
   5.3.6 การออกแบบการจัดการสิทธิ์ ตามแนวทางข้อ 5.3.2 ต้องมีการกําหนดสิทธิ์ที่ชัดเจนตามหน้าที่
   และอนุญาตให้มอบหมายสิทธิ์พิเศษสําหรับบางสิทธิ์ เพื่อความยืนหยุ่นในการบริหารจัดการ 5.3.7 ออกแบบรูปแบบการตั้งชื่อบริการข้อมูล (Service) เพื่อความเป็นระเบียบเรียบร้อย 5.3.8 จัดทําเอกสารการออกแบบส่วนบริหารจัดการสิทธิ์ของผู้ใช้และแพ็กเกจของเซอร์วิส ในรูปแบบ ของตารางเมทริกซ์ (Matrix Table) หรือแผนภูมิลําดับชั้น (Hierarchy) หรือรูปแบบอื่นๆ ที่ เหมาะสม ที่สามารถอ่านแล้วเข้าใจได้ง่าย
   5.4 ปรับปรุงและพัฒนาต่อยอดระบบ GISTDA API Gateway
   5.4.1 ปรับปรุงส่วนการแสดงผลระบบ (User Interface) ให้ดูมีความทันสมัย และสามารถใช้งานได้
   ตามหลัก Responsive Web Design
   5.4.2 นําผลการวิเคราะห์และออกแบบตามข้อ 5.2 และ 5.3 มาใช้ในการปรับปรุงระบบ 5.4.3 มีเมนูสําหรับเข้าถึงการใช้งานอื่นๆ บนระบบ และย้อนกลับได้ สําหรับผู้ใช้งานทั่วไป ดังนี้
   5.4.3.1 แดชบอร์ด (Dashboard)
   5.4.3.2 API Keys
   5.4.3.3 เซอร์วิส (Services)
   5.4.3.4 บัญชีผู้ใช้ (Profile)
   5.4.3.5 Credit wallet
   5.4.3.6 API Documentation
   5.4.4 มีเมนูสําหรับเข้าถึงการใช้งานอื่นๆ บนระบบ และย้อนกลับได้ สําหรับผู้ดูแลระบบ ดังนี้
   5.4.4.1 แดชบอร์ด (Dashboard)
   5.4.4.2 API Keys
   5.4.4.3 เซอร์วิส (Services)
   5.4.4.4 ผู้ใช้และสิทธิ์ (Users and Permissions)
   5.4.4.5 แพ็กเกจ (Packages)
   5.4.4.6 การใช้งานและสถิติ (Usage / Statistics)
   5.4.4.7 บัญชีผู้ใช้ (Profile)
   5.4.5 เมนูการใช้งานระบบในข้อ 5.4.3 และข้อ 5.4.4 สามารถปรับเปลี่ยนให้สอดคล้องกับผลการ วิเคราะห์ในข้อ 5.2 และการออกแบบในข้อ 5.3 ได้ กรณีที่ได้รับความเห็นชอบจาก สทอภ.แล้ว 5.4.6 ระบบสามารถเปิดให้ผู้ใช้งานทั่วไป ลงทะเบียน ได้ ดังนี้ อีเมล และ Thai ID เป็นอย่างน้อย 5.4.7 ผู้ใช้งานทั่วไป ที่ลงทะเบียนในระบบแล้ว สามารถใช้งานต่อไปนี้ได้เป็นอย่างน้อย
   5.4.7.1 สามารถดูสรุปผลการใช้งานภาพรวมของผู้ใช้นั้นๆ ได้ (Dashboard) ประกอบด้วย
   OAA S
   W
   2
   หน้า 7/19
   5.4.7.1.1 สรุปจํานวนเครดิต (Credits) ที่ใช้ไปทั้งหมด
   5.4.7.1.2
   เครดิต (Credits) ที่เหลือทั้งหมดที่สามารถใช้งานได้
   5.4.7.1.3 ปริมาณการใช้เครดิต รายวันและรายเดือน เป็นอย่างน้อย และสามารถ
   เลือกช่วงเวลาการแสดงผลได้
   5.4.7.1.4 ปริมาณการเรียกใช้งาน Service โดยแบ่งเป็นราย Endpoint 5.4.7.1.5 ปริมาณการใช้เครดิตของ Service โดยแบ่งเป็นราย Endpoint 5.4.7.1.6 คาดการณ์ปริมาณการใช้งานล่วงหน้า 1 เดือน
   5.4.7.1.7 การแสดงผลต้องอยู่ในรูปแบบกราฟที่อ่านเข้าใจได้ง่าย และสามารถ
   เลือกช่วง วัน/เดือน/ปี ในการแสดงผลได้
   5.4.7.2 สร้าง API Key สําหรับใช้งาน Service ที่ให้บริการผ่านระบบได้ (API Keys) โดยยังคง
   ต้องมีความสามารถเหมือนระบบเดิมและใช้งานได้โดยสมบูรณ์
   5.4.7.2.1 ชื่อ
   5.4.7.2.2 วันหมดอายุ
   ประกอบด้วย
   5.4.7.2.3 การกําหนดข้อจํากัดการใช้งานด้วยชื่อโดเมนและหมายเลขไอพี
   (Domain and IP Whitelisting)
   5.4.7.2.4 หากมีการปรับปรุงเพิ่มเติมต้องเสนอให้ สทอภ. พิจารณาและเห็นชอบ
   ก่อนดําเนินการ
   5.4.7.3 สามารถดูรายการ Service ตามสิทธิ์หรือแพ็กเกจได้ (Services)
   5.4.7.4 สามารถแก้ไขรายละเอียดส่วนตัวได้ (Profile)
   5.4.7.5 สามารถตรวจสอบปริมาณการใช้เครดิตและเครดิตคงเหลือได้ (Credit wallet)
   5.4.7.6 สามารถเข้าถึง API Documentation ได้
   5.4.8 ผู้ดูแลระบบ ที่ลงทะเบียนในระบบแล้ว สามารถใช้งานต่อไปนี้ได้เป็นอย่างน้อย
   5.4.8.1 พัฒนาและปรับปรุงส่วนสรุปผลการใช้งานภาพรวมของระบบ (Dashboard)
   5.4.8.1.1 ปริมาณการใช้ Service ทั้งหมดของระบบ และสรุปเป็นรายวันใน
   รูปแบบกราฟที่อ่านเข้าใจได้ง่าย
   5.4.8.1.2 แสดงรายรับที่ได้จากการเติมเครดิต (Credit) ทั้งหมดของระบบหน่วย
   เป็นบาทไทย และสรุปเป็นรายวันในรูปแบบกราฟที่อ่านเข้าใจได้ง่าย 5.4.8.1.3 ปริมาณการเรียกใช้งาน Service โดยแบ่งเป็นราย Endpoint ทั้งห
   ทั้งหมด
   ของระบบ
   Ота
   o
   หน้า 8/19
   ทั้งหมด
   5.4.8.1.4 ปริมาณการใช้เครดิตของ Service โดยแบ่งเป็นราย Endpoint
   ของระบบ
   5.4.8.1.5 แสดงจํานวน API Key ทั้งหมดของระบบ
   5.4.8.1.6
   คาดการณ์ปริมาณการใช้ Service ล่วงหน้า 1 เดือนเป็นอย่างน้อย
   5.4.8.1.7 การแสดงผลต้องอยู่ในรูปแบบกราฟที่อ่านเข้าใจได้ง่าย และสามารถ
   5.4.8.1.8
   เลือกช่วงวันเดือนปีในการแสดงผลได้
   สามารถ export รายงานปริมาณการใช้งาน ตามช่วงวันเดือนปีที่กําหนด ในรูปแบบ CSV หรือ png หรือรูปแบบอื่นๆ ที่เหมาะสม
   5.4.8.2 สร้าง API Key สําหรับใช้งาน Service ที่ให้บริการผ่านระบบได้ (API Keys) โดยยังคง
   ต้องมีความสามารถเหมือนระบบเดิมและใช้งานได้โดยสมบูรณ์
   5.4.8.2.1 ชื่อ
   5.4.8.2.2 วันหมดอายุ
   5.4.8.2.3
   ประกอบด้วย
   กําหนดข้อจํากัดการใช้งานด้วยชื่อโดเมนและหมายเลขไอพี (Domain
   and IP Whitelisting)
   5.4.8.2.4 หากมีการปรับปรุงเพิ่มเติมต้องเสนอให้ สทอภ. พิจารณาและเห็นชอบ
   ก่อนดําเนินการ
   5.4.8.3 พัฒนาและปรับปรุงส่วนบริหารจัดการการให้บริการข้อมูล (Services)
   5.4.8.3.1 ปรับปรุงหน้าแสดงรายการบริการข้อมูล (Services) มีรายละเอียดดังนี้
   5.4.8.3.1.1 แสดงชื่อบริการข้อมูล (Service) เป็นภาษาไทยหรือ
   ภาษาอังกฤษ ที่อ่านออกได้สมบูรณ์
   5.4.8.3.1.2 แสดง Path URL ของบริการข้อมูล นั้นๆ
   5.4.8.3.1.3 แสดงประเภทบริการข้อมูล (Service) 5.4.8.3.1.4 แสดงแท็ก (Tag) ของบริการข้อมูล นั้นๆ 5.4.8.3.1.5 แสดงวันที่อัปเดตการให้บริการข้อมูลล่าสุด 5.4.8.3.1.6 แสดงวันที่สร้างการให้บริการข้อมูล
   5.4.8.3.1.7
   มีหน้าแสดงตัวอย่างผลลัพธ์ (sandbox) การเรียกใช้งาน
   บริการข้อมูลนั้นๆ ที่สามารถทดลองกําหนด
   ค่าพารามิเตอร์ ได้
   }
   หน้า 9/19
   5.4.8.3.1.8
   มีส่วนแสดงผล URL Service รูปแบบเต็ม กล่าวคือ URL Service ต่อด้วย Parameter (หากมี) และมีปุ่มสําหรับ คัดลอก (Copy) URL Service ได้
   5.4.8.3.1.9 มีหน้าแสดงตัวอย่างการนําไปใช้ประโยชน์หรือตัวอย่าง
   การซ้อนทับบนแผนที่ออนไลน์
   5.4.8.3.2 สามารถค้นหาข้อมูลตามคําค้นหรือแท็กที่ต้องการได้
   5.4.8.3.3 เพิ่มความสามารถการลงทะเบียนบริการข้อมูล (Services) จากแหล่ง
   บริการข้อมูลภายนอก ดังนี้
   5.4.8.3.3.1 ต้องรองรับประเภทบริการข้อมูล (Service) ของ ArcGIS Service อย่างน้อยดังนี้ Map service,
   Feature service และ Image service อ้างอิงตาม
   https://developers.arcgis.com/rest
   5.4.8.3.3.2 รองรับประเภทบริการข้อมูลแบบ Tiles ในรูปแบบไฟล์
   5.4.8.3.3.3
   PNG และ WEBP เป็นอย่างน้อย
   จัดทําคําอธิบายและ URL Service ตัวอย่างของประเภท
   บริการข้อมูล
   5.4.8.3.3.4 จัดทําสัญลักษณ์ที่บ่งบอกถึงความจําเป็นต้องกรอก เช่น
   เครื่องเหมายดอกจันทร์ (*) ในช่องกรอกนั้นๆ
   5.4.8.3.3.5 ต้องสามารถใส่คําอธิบายของพารามิเตอร์ (param) ได้
   5.4.8.3.3.6
   ความสามารถการลงทะเบียนบริการข้อมูล (Services) ของเดิมบนระบบต้องไม่ได้รับผลกระทบและใช้งานได้
   อย่างสมบูรณ์
   5.4.8.3.4 สามารถจัดการบริการข้อมูล (Services) ราย Endpoint ได้ดังนี้
   5.4.8.3.4.1 สามารถระงับปิดการใช้งานได้ (Disable)
   5.4.8.3.4.2 สามารถตั้งค่าการมองเห็น (Visibility) บริการข้อมูล โดย การซ่อนไม่ให้แสดงในรายการบริการข้อมูล ทั้งนี้บริการ
   ข้อมูลยังคงต้องสามารถเรียกใช้งานได้ตามปกติ
   5.4.8.3.4.3 สามารถแก้ไขรายละเอียดบริการข้อมูลที่ลงทะเบียนได้
   (Edit) เช่น เพิ่มแท็ก (Tag), แก้ไข URL Service, แก้ไข พารามิเตอร์ เป็นต้น
   ants

ये
หน้า 10/19
5.4.8.3.4.4
สามารถแสดงรายการแพ็กเกจ (Packages) ได้
5.4.8.3.4.5 สามารถลบ (Delete) บริการข้อมูลได้
5.4.8.4 พัฒนาและปรับปรุงส่วนบริหารจัดการผู้ใช้งานและสิทธิ์การใช้งาน (Users and
Permissions)
5.4.8.4.1 แสดงรายการผู้ใช้งานระบบทั้งหมด และสามารถดูรายละเอียดได้อย่าง
น้อยดังนี้
5.4.8.4.1.1 ชื่อผู้ใช้งานระบบ (username)
5.4.8.4.1.2 อีเมลที่สมัครใช้งาน (email)
5.4.8.4.1.3 ระดับสิทธิ์การใช้งาน (Role)
5.4.8.4.1.4 วันที่สมัครใช้งาน (Created date)
5.4.8.4.1.5 วันที่เข้าใช้งานล่าสุด (Last Login)
5.4.8.4.1.6 สถานะการใช้งาน (Status)
5.4.8.4.2 ระงับการใช้งานเป็นราย username ได้ แบบปุ่มคลิกระงับการใช้งาน และแบบตั้งวันที่และเวลาระงับการใช้งาน รวมถึงสามารถระบุสาเหตุการ
ระงับการใช้บริการได้
5.4.8.4.3 สามารถจัดการสิทธิ์ได้ในระดับผู้ใช้งาน (user) ระดับกลุ่ม (group) และ
กลุ่มย่อย (subgroup) อย่างน้อยหนึ่งลําดับ
5.4.8.4.4 ผู้ใช้งานทั่วไป ที่ลงทะเบียนเข้าใช้งานใหม่ ต้องถูกกําหนดให้อยู่กลุ่ม ผู้ใช้งาน (Group) เริ่มต้นอัตโนมัติ พร้อมทั้ง สามารถเลือกแผนการเข้าใช้ บริการข้อมูล หรือ แพ็กเกจ ที่ต้องการได้
5.4.8.4.5 สามารถทําสําเนา (duplicate) สิทธิ์การใช้งานแพ็กเกจ (package) ได้ 5.4.8.4.6 สามารถบริหารจัดการผู้ใช้งานทั่วไปได้ เช่น เพิ่ม ลบ แก้ไข กําหนดสิทธิ์
การใช้งาน เป็นอย่างน้อย
5.4.8.4.7 สามารถกําหนดโควต้าเครดิต (Credits) การใช้งานแต่ละส่วนของระบบ เป็นรายผู้ใช้งาน ซึ่งเจ้าหน้าที่ต้องสามารถใส่เหตุผลในการเพิ่ม/ลดโควต้า ในแต่ละครั้งได้
5.4.8.4.8
สามารถกําหนดการใช้งานแบบเครดิตไม่จํากัด (Credits Unlimit) เป็น ช่วงเวลาได้ เช่น ลูกค้าซื้อการใช้งาน Service เป็นรายปีแบบเหมาจ่าย 5.4.8.5 พัฒนาและปรับปรุงส่วนบริหารจัดการแพ็กเกจการให้บริการข้อมูล (Packages)
หน้าแสดงรายการแพ็กเกจ (Packages) มีรายละเอียดประกอบด้วยดังนี้
5.4.8.5.1
00716
หน้า 11/19
5.4.8.5.1.1 ชื่อแพ็กเกจ
5.4.8.5.1.2 คําอธิบายแพ็กเกจ
5.4.8.5.1.3 วันที่สร้างแพ็กเกจ
5.4.8.5.2 สามารถเรียกดูรายการบริการข้อมูลที่ลงทะเบียนในแต่ละแพ็กเกจได้ 5.4.8.5.3 สามารถกําหนดราคาของผลิตภัณฑ์ 2 รูปแบบ ได้เป็นอย่างน้อย
5.4.8.5.3.1 แบบ per request
5.4.8.5.3.2 แบบ per size
5.4.8.5.3.3 หรือแบบอื่นๆ ตามที่ออกแบบในข้อ 5.3
5.4.8.6 พัฒนาส่วนแสดงผลและสรุปผลการใช้บริการ (Usage) ในรูปแบบแดชบอร์ด
5.4.8.6.1 หน้ารายงานสรุปผลรายได้ที่ได้จากการให้บริการที่เกิดขึ้นจากธุรกรรม
ช่องทางออนไลน์
5.4.8.6.2 สามารถสรุปรายได้ที่ได้จากการให้บริการที่เกิดขึ้นจากธุรกรรมช่องทาง ออนไลน์ในแต่ละเดือนได้ หรือสามารถเลือกสรุปรายวัน รายเดือน และ
รายปี ได้
5.4.8.7 สามารถแก้ไขรายละเอียดส่วนตัวได้ (Profile)
5.4.8.8 สามารถบริการจัดการ API Document ได้ เพื่อให้บริการแก่ผู้ใช้งานทั่วไป 5.4.9 ระบบต้องสามารถตั้งค่าการเรียกใช้บริการข้อมูล โดยไม่ต้องยืนยันตัวตนได้
5.4.10 ระบบต้องสามารถแจ้งเตือนผู้ใช้งาน กรณีที่ผู้ใช้งานมีการใช้งานโควต้าเครดิต (Credits) ใกล้
หมด (เงื่อนไขตามที่ สทอภ. กําหนด) ผ่านทางอีเมล
5.4.11 ระบบต้องสามารถตัดบริการต่างๆ ได้โดยอัตโนมัติ ในกรณีที่ผู้ใช้งานมีการใช้งานเกินโควต้า
เครดิต (Credits) หรือเกินวงเงินที่จ่าย
5.4.12 มีระบบจัดเก็บประวัติการใช้งานระบบ เช่น ประวัติการดาวน์โหลด ประวัติปริมาณการใช้งาน
service
5.4.13 ผู้รับจ้างต้องทําการย้ายบริการข้อมูล (Migrate Services) ตามที่ได้ออกแบบและปรับปรุง ระบบ GISTDA API Gateway โดยต้องไม่กระทบกับการใช้งานและบริการของแอปพลิเคชันที่ มีอยู่เดิม
5.4.14 การปรับปรุงและพัฒนาระบบเพิ่มเติมสามารถปรับเปลี่ยน ให้สอดคล้องกับผลการวิเคราะห์ใน ข้อ 5.2 และการออกแบบในข้อ 5.3 ได้ ทั้งนี้ต้องได้รับความเห็นชอบจาก สทอภ. ก่อน
ดําเนินการ
ल
หน้า 12/19
5.4.15ระบบที่ปรับปรุงและพัฒนาขึ้นใหม่ภายใต้โครงการนี้ รวมถึงระบบเดิมที่นํามาต่อยอด ต้อง
ให้บริการและใช้งานได้อย่างสมบูรณ์ ตามทุกข้อกําหนดขอบเขตงาน
5.4.16 ผู้รับจ้างต้องใช้เครื่องมือ GitLab ของ สทอภ. ควบคุมเวอร์ชัน (Version Control System) ในการพัฒนา ปรับปรุง และบริหารจัดการซอร์สโค้ดของระบบตลอดระยะเวลาการดําเนิน โครงการ
5.4.17 ผู้รับจ้างต้องดําเนินการทดสอบระบบบน Development Zone ทุกครั้ง ก่อนดําเนินการ ให้บริการระบบบน Production Zone ของ สทอภ. เพื่อทดสอบความถูกต้องและความพร้อม ใช้งานของฟังก์ชัน รวมถึงประสิทธิภาพและความเสถียรของระบบ
5.4.18 ผู้รับจ้างต้องพัฒนาและปรับปรุงระบบ โดยไม่กระทบกับการใช้งานระบบเดิม หากจําเป็นต้อง
ปรับปรุงและมีผลกระทบต้องรีบแจ้งให้ สทอภ. ทราบล่วงหน้า 5 วันทําการ 5.4.19 ผู้รับจ้างต้องดูแลบํารุงรักษาความปลอดภัย (Security) ของระบบทั้งหมดโดยให้ความร่วมมือ ในการจัดทําแผนและแนวทางการปฏิบัติเพื่อรองรับสถานการณ์แก้ไขภัยพิบัติ รวมทั้ง ประสานงาน ตรวจสอบข้อมูล และระบบงานร่วมกับทีมงานที่ สทอภ.กําหนด 5.5 จัดฝึกอบรมเชิงปฏิบัติการเพื่อพัฒนาศักยภาพบุคลากรของ สทอภ. พร้อมจัดทําคู่มือ
5.5.1 ผู้รับจ้างต้องจัดทําเอกสารคู่มือสําหรับฝึกอบรม (เท่าจํานวนผู้เข้าอบรมในแต่ละหัวข้อ) 5.5.2 จัดฝึกอบรมโดยมีรายละเอียด ดังต่อไปนี้
5.5.2.1 ฝึกอบรมการจัดการผู้ใช้งานและสิทธิ์การใช้งาน รวมถึงคํานวนค่าใช้จ่ายการใช้บริการ (GISTDA API Gateway) สําหรับผู้ดูแลระบบ ให้แก่เจ้าหน้าที่ สทอภ. ตั้งแต่ 5 คนขึ้น
ไป ไม่น้อยกว่า 1 วัน
5.5.2.2 ฝึกอบรมการปรับปรุงอัปเดตข้อมูลส่วนให้บริการข้อมูล (Service) สําหรับผู้ดูแลระบบ
ให้แก่เจ้าหน้าที่ สทอภ. ตั้งแต่ 5 คนขึ้นไป ไม่น้อยกว่า 1 วัน
5.5.3 รูปแบบการฝึกอบรมเป็นแบบออนไซต์ (on-site) ทั้งนี้สถานที่ในการฝึกอบรมแบบออนไซต์ใช้
พื้นที่ของ สทอภ. ศูนย์ราชการแจ้งวัฒนะฯ หรือ สทอภ. บางเขน ตามความเหมาะสม 5.5.4 ค่าอาหารเบรคเช้า-บ่าย ค่าอาหารกลางวัน ในทุกๆ วันที่มีการฝึกอบรม ผู้รับจ้างต้องเป็น
ผู้รับผิดชอบค่าใช้จ่ายทั้ง
ยางหมด
5.6 ผู้รับจ้างต้องจัดทําแผนการบํารุงรักษา (Maintenance) หลังจากสิ้นสุดระยะเวลารับประกันตาม ขอบเขตงานนี้ โดยเสนอแผนการดําเนินงานและค่าใช้จ่ายแบบรายปี เป็นระยะเวลา 1 ปี ให้ สทอภ. พิจารณา (เพื่อใช้เป็นแนวทางสําหรับ สทอภ. พิจารณาต่อไป)
{
o
หน้า 13/19
6. ระยะเวลาการดําเนินงาน
ผู้รับจ้างจะต้องดําเนินการภายในระยะเวลา 240 วัน นับถัดจากวันลงนามในสัญญา
7. เงื่อนไขการชําระเงินและการส่งมอบงาน
ผู้รับจ้างจะต้องส่งมอบงานภายใน 240 วัน นับถัดจากวันลงนามในสัญญา และ สทอภ. จะชําระเงินค่าจ้าง เป็นรายงวด จํานวน 3 งวด ดังนี้
งวดที่ 1 ชําระเงินเป็นจํานวนร้อยละ 10 ของมูลค่าตามสัญญาฯ เมื่อผู้รับจ้างส่งมอบงานแล้วเสร็จสมบูรณ์ ภายใน 60 วันนับถัดจากวันลงนามในสัญญาฯ และคณะกรรมการตรวจรับพัสดุได้ตรวจรับงานเรียบร้อย ดังนี้
ส่งมอบสรุปรายงานการประชุมเริ่มโครงการ (Kick-Off) ตามข้อ 5.1.1 ส่งมอบเอกสารสรุปการประชุมเก็บความต้องการและให้ข้อเสนอแนะ ตามข้อ 5.1.2 ส่งมอบเอกสารแผนการดําเนินงานปรับปรุงและพัฒนาระบบ (Project Plan) ตามข้อ 5.1.3 ส่งสรุปรายงานการวิเคราะห์ระบบ GISTDA API Gateway ที่มีอยู่เดิม ตามข้อ 5.2 ผู้รับจ้างต้องจัดส่งเอกสารแบบ Hard copy จํานวน 2 ชุด และ Digital file รูปแบบ Acrobat (.pdf) และ MS Word บันทึกลง USB Flash Drive จํานวน 2 ชุด
งวดที่ 2 ชําระเงินเป็นจํานวนร้อยละ 50 ของมูลค่าตามสัญญาฯ เมื่อผู้รับจ้างส่งมอบงานแล้วเสร็จสมบูรณ์ ภายใน 180 วันนับถัดจากวันลงนามในสัญญาฯ และคณะกรรมการตรวจรับพัสดุได้ตรวจรับงานเรียบร้อย ดังนี้ ส่งมอบเอกสารการออกแบบส่วนบริหารจัดการสิทธิ์ของผู้ใช้และแพ็กเกจของเซอร์วิส ตามข้อ
5.3
พัฒนาและปรับปรุงต่อยอดระบบ GISTDA API Gateway ตามข้อ 5.4
ผู้รับจ้างต้องจัดส่งเอกสารแบบ Hard copy จํานวน 2 ชุด และ Digital file รูปแบบ Acrobat (.pdf) และ MS Word บันทึกลง USB Flash Drive จํานวน 2 ชุด
งวดที่ 3 ชําระเงินเป็นจํานวนร้อยละ 40 ของมูลค่าตามสัญญาฯ เมื่อผู้รับจ้างส่งมอบงานแล้วเสร็จสมบูรณ์ ภายใน 240 วัน นับถัดจากวันลงนามในสัญญาฯ และคณะกรรมการตรวจรับพัสดุได้ตรวจรับงานเรียบร้อย ดังนี้

จัดฝึกอบรมตามข้อ 5.5 พร้อมส่งมอบรายงานการฝึกอบรม ประกอบด้วย แผนการฝึกอบรม ภาพบรรยากาศการฝึกอบรมในหัวข้อต่างๆ และเอกสารใบเซ็นชื่อเข้าฝึกอบรมของผู้อบรม ส่ง source code โดยต้องไม่มีการเข้ารหัสทั้งหมดของโครงการ ผ่าน GitLab ของ สทอภ. ตาม
ข้อ 5.4.16
ส่งมอบเอกสารการทดสอบการใช้งานระบบที่พัฒนา (UAT) ตามข้อ 5.4.17 ส่งมอบเอกสารแผนการบํารุงรักษา (Maintenance) ตามข้อ 5.6
02265
ท
8. อัตราค่าปรับ
หน้า 14/19
ผู้รับจ้างต้องจัดส่งเอกสารรายงานฉบับสมบูรณ์ แบบ Hard copy จํานวน 2 ชุด และ Digital file รูปแบบ Acrobat (*.pdf) และ MS Word บันทึกลง USB Flash Drive จํานวน 2 ชุด
หากผู้รับจ้างไม่สามารถส่งมอบงานได้ตามกําหนดระยะเวลาในสัญญา ผู้รับจ้างจะต้องชําระค่าปรับให้แก่ ผู้ว่าจ้าง เป็นรายวันในอัตราร้อยละ 0.10 (ศูนย์จุดหนึ่งศูนย์) ของราคางานจ้างตามสัญญาต่อวัน แต่ต้องไม่ต่ํากว่า วันละ 100 บาท (หนึ่งร้อยบาทถ้วน)
9. กําหนดยืนราคา
ผู้ยื่นข้อเสนอจะต้องยืนราคาที่เสนอไม่น้อยกว่า 30 วัน นับตั้งแต่วันเสนอราคา
10. วงเงินในการจัดจ้าง
งบประมาณในการจัดจ้าง จํานวนเงิน 4,400,000 บาท (สี่ล้านสี่แสนบาทถ้วน) รวมภาษีมูลค่าเพิ่ม
11. สงวนสิทธิ์
สิทธิในทรัพย์สินทางปัญญา หรือสิทธิอื่นใด (ไม่จํากัดอยู่แค่ ลิขสิทธิ์ สิทธิบัตร เครื่องหมายการค้า ความลับทางการค้า เทคโนโลยี วิธีการเทคนิค วิทยาการความรู้ (Know-How) ที่เป็นของผู้รับจ้างหรือของผู้ว่าจ้าง แล้วแต่กรณี และได้นํามาใช้หรือนํามาพัฒนาต่อยอดในการดําเนินการตามสัญญานี้ย่อมเป็นของฝ่ายนั้น
ผู้ว่าจ้างเป็นเจ้าของลิขสิทธิ์ หรือทรัพย์สินทางปัญญา ในผลงานที่ผู้รับจ้างได้ดําเนินการขึ้นใหม่ตามสัญญา ทั้งหมดแต่เพียงฝ่ายเดียว โดยผู้ว่าจ้างสามารถที่จะทําการปรับปรุง ดัดแปลง หรือแก้ไขเพิ่มเติมในตัวผลงานได้ ทั้งนี้รวมถึงการแจกจ่าย หรือจําหน่ายผลงานดังกล่าวได้ด้วย และให้บรรดาข้อมูล เนื้อหา และนวัตกรรมที่ได้จาก การดําเนินงานตามสัญญาทั้งหมด ถือเป็นลิขสิทธิ์ของผู้ว่าจ้างแต่เพียงผู้เดียว ห้ามมิให้ผู้รับจ้างทําการสําเนา หรือ ให้ผู้อื่นนําไปใช้เพื่อการอื่นใด เว้นแต่จะได้รับอนุญาตจากผู้ว่าจ้างเป็นลายลักษณ์อักษร
12. เงื่อนไขการดําเนินการ
12.1 ผู้รับจ้างต้องดําเนินการประสานงานและติดตั้งระบบฯ ในโครงการ บนเครื่องแม่ข่ายคอมพิวเตอร์ของผู้
ให้บริการที่ สทอภ. เป็นผู้กําหนด
12.2 ผู้รับจ้างต้องดําเนินการรักษาความปลอดภัยให้กับเครื่องเว็บเซิร์ฟเวอร์
12.3 ระบบและซอฟต์แวร์ที่ส่งมอบในโครงการต้องเป็นสิทธิ์การใช้งานตลอดชีพของ สทอภ. 12.4 ต้องสามารถเพิ่มจํานวนผู้ใช้งานในระบบได้ไม่จํากัด
%
หน้า 15/19
12.5 ต้องสามารถขยายระบบได้โดยไม่ติดเงื่อนไขด้านลิขสิทธิ์ใด ๆ
12.6 สทอภ. สามารถใช้ระบบฯ ในการให้บริการและเชื่อมโยงข้อมูลภูมิสารสนเทศร่วมกับหน่วยงานต่างๆ
ทั้งภายในและภายนอกองค์กร เพื่อรองรับการดําเนินการระดับประเทศในอนาคต
13. เกณฑ์การพิจารณาคะแนน
พิจารณาการยื่นข้อเสนอครั้งนี้ สทอภ. จะใช้หลักเกณฑ์การประเมินค่าประสิทธิภาพต่อราคา โดยพิจารณา ให้คะแนนเกณฑ์คุณภาพน้ําหนักร้อยละ 70 และเกณฑ์ราคาน้ําหนักร้อยละ 30 รวม 100 ดังนี้
ลําดับ หัวข้อในการพิจารณา
1
แนวทางในการพัฒนาระบบ
1.1
แผนการดําเนินงาน
หลักเกณฑ์ในการให้คะแนน
1.2
แผนภาพแบบจําลอง
แผนการดําเนินงานมีขั้นตอนการดําเนินงานที่เหมาะสมและ
สอดคล้องกับเนื้องาน และระยะเวลาการดําเนินงานตาม
ระยะเวลาโครงการ

• ส่งแผนการดําเนินงานตามระยะเวลาที่กําหนด มีเนื้อหา
  ละเอียดครบถ้วน สอดคล้องกับงวดงาน (5 คะแนน) - ไม่มีแผนการดําเนินงาน หรือมีเนื้อหาละเอียดไม่ครบถ้วน
  ไม่สอดคล้องกับงวดงาน หรือมีระยะเวลาดําเนินการมากกว่า ที่กําหนด (0 คะแนน)
• มีแผนภาพแบบจําลองความคิด (Conceptual model)
  ความคิด (Conceptual | พร้อมคําอธิบายที่ชัดเจน (5 คะแนน)
  model)
  1.3
  มีแผนผัง Data flow
  diagram (DFD)
  2
  2.1
• ไม่มีแผนภาพแบบจําลองความคิด (Conceptual model)
  (0 คะแนน)
• มี Data flow diagram (DFD) Level 2 (2.5 คะแนน) มี Data flow diagram (DFD) Level 1 (1.5 คะแนน) - มี Data flow diagram (DFD) Level 0 (1 คะแนน) - ไม่มี Data flow diagram (DFD) (0 คะแนน) หมายเหตุ คะแนนสูงสุดไม่เกิน 5 คะแนน
  เทคโนโลยีที่จะนํามาใช้ในโครงการ
  มีการใช้ซอฟต์แวร์รหัส | - ใช้ซอฟต์แวร์รหัสเปิดทุกรายการ (10 คะแนน)
  เปิด (Open Source) - ใช้ซอฟต์แวร์รหัสเปิดไม่ครบทุกรายการ (0 คะแนน)
  WAS
  นําหนัก
  คะแนนเต็ม
  15
  นก
  5
  5
  5
  35
  10
  ল
  Оне
  ลําดับ หัวข้อในการพิจารณา
  ในการพัฒนาระบบฯ
  หน้า 16/19
  หลักเกณฑ์ในการให้คะแนน
  นําหนัก
  คะแนนเต็ม
  2.2 ใช้มาตรฐานแบบเปิดใน - ซอฟต์แวร์ที่พัฒนารองรับ APIs for the Web ตาม
  การจัดทําโครงการ
  2.3
  สถาปัตยกรรมในการ
  พัฒนาระบบฯ
  3
  ตัวอย่าง Mock up
  3.1
  จัดทําหน้าจอ Mock up บนเว็บแอพพลิเคชั่น
  4
  ข้อเสนอพิเศษ
  นอกเหนือจากที่ TOR
  กําหนด
  มาตรฐาน OGC API (10 คะแนน)
• ซอฟต์แวร์ที่พัฒนารองรับ APIs for the Web ตาม
  มาตรฐาน ArcGIS Service (10 คะแนน)
  หมายเหตุ ข้อละ 10 คะแนน คะแนนสูงสุดไม่เกิน 20
  คะแนน
  พัฒนาระบบตามหลักแนวคิด Microservices และรองรับ
  การทํางานแบบ Containerized (5 คะแนน)
• พัฒนาระบบไม่เป็นตามหลักแนวคิด Microservices และไม่
  รองรับการทํางานแบบ Containerized (0 คะแนน)
  มีตัวอย่างหน้าจอ Mock up หรือต้นแบบ (Prototype) บน เว็บแอพพลิเคชั่นเพื่อแสดงให้เห็นว่าผู้รับจ้างสามารถ
  ดําเนินงานได้จริงตามข้อเสนอ
• เสนอตามส่วนข้อกําหนด 5.3 (ต้นแบบละ 5 คะแนน)
  เสนอตามส่วนข้อกําหนด 5.4 (ต้นแบบละ 5 คะแนน) หมายเหตุ คะแนนสูงสุดไม่เกิน 10 คะแนน ข้อเสนอใด ๆ จะเป็นประโยชน์และสอดคล้องกับ วัตถุประสงค์โครงการ สามารถเสนอเครื่องมือหรือฟังก์ชันที่ เกี่ยวข้องกับการบริหารจัดการ API ทั้งนี้คะแนนรวมสูงสุดไม่ เกิน 10 คะแนน ซึ่งมีระดับการให้คะแนนดังต่อไปนี้
• เสนอเครื่องมือหรือฟังก์ชันส่วนการลงทะเบียนบริการข้อมูล (Services) ที่สามารถรวมหลายบริการข้อมูล (Multiple Services) จากแหล่งที่มาที่ต่างกัน เข้าด้วยกันเป็นจุด ให้บริการเดียว (Single Endpoint) พร้อมทั้งอธิบาย รายละเอียดโดยสังเขป (10 คะแนน)
  ra
  ले
  20
  เก
  5
  10
  10
  10
  ลําดับ หัวข้อในการพิจารณา
  หน้า 17/19
  หลักเกณฑ์ในการให้คะแนน
  นําหนัก
  คะแนนเต็ม
• เสนอเครื่องมือหรือฟังก์ชันที่เกี่ยวข้องกับการบริหารจัดการ API พร้อมทั้งอธิบายรายละเอียดการนําไปใช้โดยสังเขป
  (เครื่องมือหรือฟังก์ชันละ 5 คะแนน)
  เงื่อนไข ต้องไม่ซ้ํากับเครื่องมือหรือฟังก์ชันที่มีอยู่เดิม
  **ทั้งนี้ข้อเสนอพิเศษต้องเป็นลิขสิทธิ์ของ สทอภ. ทั้งหมด
  หมายเหตุ คะแนนสูงสุดไม่เกิน 10 คะแนน
  พิจารณาข้อเสนอด้าน
  เก
  5
  ราคา
  รวม
  30 คะแนน
  100 คะแนน
  เงื่อนไขการพิจารณา

1. ให้แสดงเอกสารหลักฐานที่ชัดแจ้ง เพื่อนํามาใช้ในการพิจารณาให้คะแนนในแต่ละหัวข้อ
2. หากผู้ยื่นข้อเสนอมีคะแนนรวมข้อเสนอแนวทางในการพัฒนาระบบในข้อ 1 เทคโนโลยีที่จะนํามาใช้ใน โครงการในข้อ 2 ตัวอย่าง Mock up ในข้อ 3 และข้อเสนอพิเศษนอกเหนือจากที่ TOR กําหนดในข้อ 4 ไม่ถึง 50 คะแนน จาก 70 คะแนน สทอภ. ขอสงวนสิทธิ์ที่จะไม่พิจารณาข้อเสนอด้านราคา 3) การคัดลอกข้อกําหนดมาวางโดยไม่อธิบายชี้แจงเพิ่มเติม ผู้ยื่นข้อเสนอจะไม่ได้รับคะแนนในการ
   พิจารณาหัวข้อนั้น ๆ
3. หากผู้ยื่นข้อเสนอรายใดไม่ส่งเอกสารตามหัวข้อการพิจารณา จะไม่ได้รับการพิจารณาให้คะแนนตาม
   หัวข้อนั้น
   ๆ
4. สัญญาหรือผลงานที่ยังไม่สิ้นสุดโครงการ ไม่สามารถนํามาพิจารณาคะแนนได้
5. ผู้ยื่นข้อเสนอ จะต้องมานําเสนอและชี้แจง แนวคิด ความคิดสร้างสรรค์ การออกแบบ รวมทั้ง องค์ประกอบอื่นๆ ตามหัวข้อในเกณฑ์การพิจารณาคะแนนข้อ 13 และผลงานที่ยื่นข้อเสนอ ข้อ 3.14.1 ต่อคณะกรรมการ เป็นเวลา 30 นาที โดยผู้ยื่นข้อเสนอจะต้องลงทะเบียน online เวลา 09:00 น. และเริ่มนําเสนอและชี้แจงฯ ตั้งแต่เวลา 09:30 น. เป็นต้นไป สทอภ. ขอกําหนดวันนําเสนอ ภายใน 3 วันทําการนับถัดจากวันเสนอราคา โดยผู้ยื่นข้อเสนอจะต้องมานําเสนอในรูปแบบ onsite ณ สํานักงานพัฒนาเทคโนโลยีอวกาศและภูมิสารสนเทศ (องค์การมหาชน) เลขที่ 120 ศูนย์ราชการ
   ले
   หน้า 18/19
   เฉลิมพระเกียรติ 80 พรรษา 5 ธันวาคม 2550 อาคารรัฐประศาสนภักดีชั้น 6-7 ถนน แจ้งวัฒนะ แขวง ทุ่งสองห้อง เขตหลักสี่ กรุงเทพมหานคร

14. การรับประกันความชํารุดบกพร่องของงาน
    ผู้รับจ้างต้องรับประกันความชํารุดบกพร่องหรือขัดข้องของสิ่งของเป็นเวลา 1 ปี นับถัดจากวันที่ได้ส่งมอบ งานงวดสุดท้ายและคณะกรรมการตรวจรับพัสดุได้ตรวจรับเรียบร้อยแล้ว โดยภายในกําหนดเวลาดังกล่าว หาก สิ่งของเกิดชํารุดบกพร่อง หรือขัดข้องอันเนื่องมาจาก การใช้งานตามปกติ ผู้รับจ้างจะต้องจัดการซ่อมแซม หรือ แก้ไขให้อยู่ในสภาพ ที่ใช้การได้ดีดังเดิม ภายใน 30 วัน นับแต่วันที่ได้รับแจ้งจาก สทอภ. โดยไม่คิดค่าใช้จ่ายใดๆ ทั้งสิ้น ทั้งสิ้น หากผู้รับจ้างบิดพลิ้ว ไม่กระทําการดังกล่าวให้แล้วเสร็จภายในเวลาที่กําหนดนับแต่วันที่ได้แจ้งจากส ทอภ. สทอภ. มีสิทธิที่จะทําการนั้นเอง หรือจ้างผู้อื่นให้ทํางานนั้น โดยผู้รับจ้างต้องเป็นผู้ออกค่าใช้จ่าย
15. หลักประกันสัญญา
    ผู้รับจ้างจะต้องนําหลักประกันอัตราร้อยละ 5 ของราคาค่าจ้าง มามอบไว้แก่ สทอภ. เพื่อเป็นหลักประกัน การปฏิบัติตามสัญญา และหลักประกันจะต้องมีอายุครอบคลุมความรับผิดทั้งปวงของผู้รับจ้างตลอดอายุสัญญา สทอภ. จะคืนหลักประกันสัญญาให้แก่ผู้รับจ้าง เมื่อผู้รับจ้างพ้นจากข้อผูกพันและความรับผิดทั้งปวงตามสัญญา
    แล้ว
16. สถานที่ส่งมอบงาน
    ณ สํานักงานพัฒนาเทคโนโลยีอวกาศและภูมิสารสนเทศ (องค์การมหาชน) ศูนย์ราชการเฉลิมพระเกียรติ 80 พรรษา 5 ธันวาคม 2550 เลขที่ 120 อาคารประศาสนภักดี ชั้น 6-7 ถนนแจ้งวัฒนะ แขวงทุ่งสองห้อง เขตหลัก สี่ กรุงเทพฯ 10210
17. เงื่อนไขอื่น ๆ
    ผู้รับจ้างต้องปฏิบัติตาม ประกาศ สํานักงานพัฒนาเทคโนโลยีอวกาศและภูมิสารสนเทศ (องค์การมหาชน) ลงวันที่ 24 พฤษภาคม พ.ศ. 2565 เรื่อง นโยบายคุ้มครองข้อมูลส่วนบุคคล (Privacy Policy) ตามพระราชบัญญัติ คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562
18. หน่วยงานที่รับผิดชอบ
    สํานักนวัตกรรมเทคโนโลยีภูมิสารสนเทศ สํานักงานพัฒนาเทคโนโลยีอวกาศและภูมิสารสนเทศ (องค์การ
    มหาชน) ชื่อ นางสาวดลพร พิมพิชัย โทรศัพท์ 082-4744998
    anis
    N
    ल
    ภาคผนวก ก.
    แนวคิด ระบบ API Gateway ร่วมกับระบบภูมิสารสนเทศ
    APIs & Services
    (source 1)
    register
    APIs & Services
    (source 2)
    APIs & Services
    (source 3)
    ตัวอย่าง
    http://xxxx.xx.xxxxxxx{port}/api/gi-service/
    ${VERSION}/${CLASS}/${ENDPOINT}
    GISTDA API Gateway
    (OGC API std. & ArcGIS Service)
    Public
    ‘New URL’
    APIs & Services
    หน้า 19/19
    {gateway URL/gi-service/${VERSION}/${CLASS}/${ENDPOINT}
    ले