สรุป TOR Phase 2¶
การพัฒนาและปรับปรุงระบบสารสนเทศ RLPD — Phase 2¶
ข้อมูลโครงการ¶
ชื่อโครงการ (ไทย): พัฒนาและปรับปรุงระบบสารสนเทศกรมคุ้มครองสิทธิและเสรีภาพ ระยะที่ 2
ชื่อโครงการ (อังกฤษ): Development and Enhancement of RLPD Information System — Phase 2
ลูกค้า: กรมคุ้มครองสิทธิและเสรีภาพ (RLPD) Bureau of Civil Rights and Liberties Protection, Thailand
ระยะเวลาสัญญา: 270 วันปฏิทินนับจากการเริ่มโครงการ
งบประมาณ: ตามสัญญาลงนาม
วันเริ่มโครงการ: [เพื่อยืนยัน]
เป้าหมาย Go-Live: ก่อนวันที่ 30 กันยายน 2026 (ขั้นต่ำ 5 ระบบ ในอุดมคติ 7 จาก 9)
สถาปัตยกรรมระบบและข้อกำหนดทางเทคนิค¶
สถาปัตยกรรมโดยรวม (TOR 6.4 & 7.1)¶
- Pattern สถาปัตยกรรม: Microservices + API-based
- ฐานข้อมูล: Single consolidated MSSQL database
- เหตุผล: Unified Data Model ความง่ายในการบูรณาการ ความปลอดภัยแบบรวมศูนย์
ข้อกำหนด UI/UX (TOR 7.3)¶
- วิธีการออกแบบ: Responsive, Modern, User-friendly Interfaces
- การปฏิบัติตามมาตรฐาน: การสนับสนุน Mobile และ Desktop
- ประสบการณ์ผู้ใช้: การนำทางโดยสัญชาตญาณ การออกแบบจากความเข้าถึงก่อน
มาตรฐานการเข้าถึง (TOR 7.18.2)¶
- ระดับการปฏิบัติตาม: WCAG 2.2 Level AA
- ขอบเขต: ระบบทั้ง 9 และ Web Portal
- การทดสอบ: ต้องมีการตรวจสอบด้านการเข้าถึงแบบ Automated และ Manual ก่อน Go-live
ข้อกำหนดความปลอดภัย¶
- การตรวจสอบสิทธิ์: SSL Encryption สำหรับข้อมูลทั้งหมดขณะส่งอย่างสม่ำเสมอ
- Single Sign-On (SSO):
- บูรณาการ ThaiD (Thai National Digital ID)
- ระบบตรวจสอบสิทธิ์ Digital ID
- Role-based Access Control (RBAC)
- การจัดการเซสชัน:
- ข้อจำกัดจำนวนครั้งที่ลองเข้าสู่ระบบ (ป้องกัน Brute Force)
- ข้อจำกัดเซสชันพร้อมกันตามบทบาท
- นโยบายรหัสผ่าน:
- ข้อกำหนดความซับซ้อนขั้นต่ำ
- วันหมดอายุรหัสผ่าน: 60 วัน
- Lockout บัญชีที่ไม่ใช้งาน: 45 วัน
- การปลดล็อคบัญชีต้องมีการแทรกแซงของผู้ดูแลระบบหรือ Time-based Reset
ขอบเขตระบบ (TOR 7.11–7.19)¶
โครงการครอบคลุมระบบที่แตกต่างกัน 9 ระบบ:
| # | ชื่อระบบ (ไทย) | ชื่อระบบ (อังกฤษ) | เจ้าของ | ส่วน TOR |
|---|---|---|---|---|
| S1 | ระบบการให้ความปรึกษาทางกฎหมาย | Legal Consultation System (กพส.) | [ภายนอก] | TOR 7.11 |
| S2 | ระบบจัดการข้อเสนอของเจ้าหน้าที่ | PJOS (Personnel Job Offer System) | [ภายนอก] | TOR 7.12 |
| S3 | ระบบรายงานกิจกรรม | Activity Report System (กสส.) | [ภายนอก] | TOR 7.13 |
| S4 | ระบบการเบี่ยงเบนข้อพิพาท | Mediation System (กสร.) | [ภายนอก] | TOR 7.14 |
| S5 | ระบบทดแทนค่าสินไหม 134/1 | 134/1 Compensation System (กพส.) | [ภายนอก] | TOR 7.15 |
| S6 | ระบบ OCIPA | OCIPA System (สชง.) | [ภายนอก] | TOR 7.16 |
| S7 | ระบบคุ้มครองพยาน | Witness Protection System (สคพ.) | [ภายนอก] | TOR 7.17 |
| S8 | เว็บไซต์หน้าหลัก | Website (Main Portal) (IT) | สำนัก IT | TOR 7.18 |
| S9 | ระบบพอร์ทัล | Web Portal System | [ภายนอก] | TOR 7.19 |
หมายเหตุการบูรณาการที่สำคัญ¶
- S1 Embed ใน S9: ระบบให้ความปรึกษาทางกฎหมายถูก Embed ภายใน Web Portal
- S1 พึ่งพา S6: ข้อมูล Sync จากระบบย่อย OCIPA
- S1 Sync ไป S5: ข้อมูลการกำหนดทนายความไหลไป Compensation System
- S3 บูรณาการ AD: ต้องใช้การตรวจสอบสิทธิ์ Active Directory
- S6 เป็น Data Source: OCIPA เป็น Hub ข้อมูลวิกฤติสำหรับระบบหลายระบบ
API Integration & Interoperability (TOR 7.20)¶
ข้อกำหนด API¶
- ระบบ 9 ระบบทั้งหมดต้องเปิดเผย API Endpoints มาตรฐาน
- เอกสาร API: ต้องมีการส่งมอบเป็นส่วนหนึ่งของผลงาน
- API Pattern: REST หรือ SOAP ตามที่ระบุใน TOR
- รูปแบบข้อมูล: JSON/XML ที่มี Versioning ที่เหมาะสม
- ความเข้ากันได้แบบ Backward: API Versioning สำหรับขั้นการปรับปรุงในอนาคต
ระบบการบูรณาการระหว่างระบบ¶
- จุดการบูรณาการที่กำหนด:
- S6 → S1 (OCIPA Data Source)
- S1 → S5 (Lawyer Assignment Sync)
- S1 ↔ S9 (Embedding + Portal Integration)
- ความถี่ Sync: ตามข้อกำหนดทางธุรกิจ (จะระบุรายละเอียดใน SA/SD)
- การจัดการข้อผิดพลาด: Retry Logic, Fallback Mechanisms, Audit Logging
ความปลอดภัยและการปฏิบัติตาม (TOR 7.23–7.24)¶
การประเมินความเสี่ยง (VA Scan)¶
- ข้อกำหนด: ระบบทั้งหมดต้องผ่าน VA Scan ก่อน Go-live
- หน่วยงานที่รับผิดชอบ: สกมช (องค์กรความปลอดภัยของไทย)
- กำหนดเวลา: ประมาณ 1 เดือนนับจากการแจ้งเตือน
- กระบวนการ: ต้องแจ้งเตือน สกมช ของความตั้งใจเร็วๆ นี้ (ตามที่ระบุใน TOR 7.23)
- ทางเลือก: ผู้ให้บริการ VA Vendor บุคคลที่สามอาจติดต่ออันหากกำหนดเวลาวิกฤติ
- ขอบเขต: ระบบ 9 + Infrastructure + ฐานข้อมูล
การทดสอบความปลอดภัย¶
- Penetration Testing: ขอแนะนำแต่อาจไม่พอดี 270 วัน Timeline
- Code Review: ตามที่ปฏิบัติตามมาตรฐานความปลอดภัย
- Dependency Scanning: สำหรับไลบรารีบุคคลที่สาม และ Frameworks ทั้งหมด
การรับรองความเข้ากันได้¶
- มาตรฐานที่ตรงตาม:
- SSL/TLS Encryption
- WCAG 2.2 Level AA
- ข้อบังคับการคุ้มครองข้อมูลของไทย (ถ้าปฏิบัติได้)
ผลงานและเหมือน Payment Milestones¶
โครงสร้าง 4-Milestone¶
Milestone 1 (วันที่ 45)¶
ผลงาน: - System Architecture Document (SA) - System Design Document (SD) - Database Schema Design (สำหรับ Single MSSQL Database) - API Specification - เอกสารตั้งค่า Infrastructure - แผนการจัดการโครงการ
การชำระเงิน: Tranche ที่ 1 (25% หรือตามสัญญา)
Milestone 2 (วันที่ 90)¶
ผลงาน: - สภาพแวดล้อมการพัฒนาเปิดใช้งานเต็มที่ - การพัฒนาหลัก 75% สำหรับระบบ 9 ระบบเสร็จสิ้น - Integration Testing Framework ติดตั้ง - การใช้งาน API สมบูรณ์ - การ Migration ฐานข้อมูลที่วางแผน - ตรวจสอบความปลอดภัยเบื้องต้นสมบูรณ์
การชำระเงิน: Tranche ที่ 2 (25% หรือตามสัญญา)
Milestone 3 (วันที่ 240)¶
ผลงาน: - การพัฒนา 100% สมบูรณ์สำหรับระบบ 9 ระบบ - Unit Testing สมบูรณ์และเอกสาร - User Acceptance Testing (UAT) สภาพแวดล้อม Deployed - Go-live Readiness Checklist 90% สมบูรณ์ - เอกสารฝึกอบรมเตรียม - Go-live เกิดขึ้นสำหรับระบบขั้นต่ำ 5 ระบบ (เป้าหมาย: 7)
การชำระเงิน: Tranche ที่ 3 (25% หรือตามสัญญา)
Milestone 4 (วันที่ 270 — สุดท้าย)¶
ผลงาน: - ระบบ 9 ทั้งหมดใน Production (หรือแผนหลังจาก Go-live ที่เอกสาร) - VA Scan สมบูรณ์และผ่าน (ตามที่ระบุใน TOR 7.23) - รายงานการประเมินความปลอดภัยขั้นสุดท้าย - เอกสาร Performance Baseline - ระยะเวลาการสนับสนุนหลัง Go-live เริ่มต้น - รายงานปิดโครงการ
การชำระเงิน: Tranche ที่ 4 (25% หรือตามสัญญา)
ข้อจำกัดสำคัญและข้อพิจารณาสถาปัตยกรรม¶
ความกดดันของกำหนดเวลา¶
- 270 วันทั้งหมด สำหรับระบบ 9 ระบบเป็นเรื่องด่วน
- ข้อกำหนด Go-live: ระบบขั้นต่ำ 5 ระบบภายในวันที่ 30 กันยายน 2026
- นัยยะ: ต้องมีการพัฒนา Parallel ของระบบ ความพึ่งพาลำดับแบบต่อเนื่องน้อยที่สุด
- ความเสี่ยง: การรวบรวมข้อกำหนดคาดว่าจะเป็นเฟสที่ยาวที่สุด; ความล่าช้ากระทบคตาหลาย
ความตึงเครียดด้านสถาปัตยกรรม: Single DB เทียบกับ Microservices¶
- TOR 6.4: Single MSSQL Database บังคับใช้
- TOR 7.1: สถาปัตยกรรม Microservices + API บังคับใช้
- ความตึงเครียด: Microservices โดยดั้งเดิมใช้ Polyglot Persistence (Multiple DBs)
- ความขัดแย้งแก้ไข:
- Microservices แบ่งปัน Single DB อย่างไรโดยไม่ Tight Coupling?
- กลยุทธ์ Schema Isolation?
- ขอบเขตธุรกรรมข้ามบริการ?
- ต้องจัดการใน System Architecture Document (Milestone 1)
ความแตกต่างของความซับซ้อนของระบบ¶
- ความซับซ้อนสูง: S4 (Mediation) — สองเวอร์ชัน ความสับสนของผู้ใช้ ความซับซ้อนการรวม
- ความเสี่ยงสูง: S6 (OCIPA) — โค้ดไม่คอมไพล์ ไม่ใช่ Git, ปัญหาประสิทธิภาพ
- มาตรฐาน: S2, S7 (ใหม่/เรียบง่าย)
- นัยยะ: การจัดสรรทรัพยากรต้องถ่วงน้ำหนักต่อ S4 และ S6
ความพึ่งพาภายนอก¶
- การประสานงาน Firewall: สป. (ทีม Network) สำหรับการอนุมัติรายการอนุญาต
- การประเมินความปลอดภัย: สกมช สำหรับ VA Scan (ขั้นต่ำ 1 เดือน)
- Active Directory: S3 ต้องการการบูรณาการ Infrastructure RLPD AD
- บูรณาการ ThaiD: SSO Implementation พึ่งพา ThaiD API Availability
- Artifact ของผู้รับเหมาก่อนหน้า: S3 มีระบบรายงาน Legacy; S4/S6 อาจมี Existing Code
ปัจจัยความสำเร็จที่สำคัญ¶
- Finalization ข้อกำหนดเร็วๆ นี้: ลงทุนอย่างหนักใน Phase 1 Output เพื่อหลีกเลี่ยงการทำซ้ำ
- การประเมิน S4 & S6: ศึกษาความเป็นไปได้/การตรวจสอบ ภายใน 2 สัปดาห์แรก
- ความพร้อมของ Infrastructure: VPN, Database, Git, Firewall Whitelist ต้องพร้อมก่อนสัปดาห์ที่ 2
- การจัดตำแหน่งผู้มีส่วนได้ส่วนเสีย: Sync ปกติกับเจ้าของระบบ (หลาย ภายนอกสำนัก IT)
- การวางแผนความปลอดภัย: แจ้งเตือน สกมช เร็วๆ นี้; งบประมาณ 1 เดือนสำหรับ VA Scan ก่อนส่งมอบขั้นสุดท้าย
- Parallel Workstreams: ทีมระบบ Run ใน Parallel; ลดความพึ่งพาลำดับให้เหลือน้อยที่สุด
- ความชัดเจนของสถาปัตยกรรม: หาข้อตกลง Single-DB เทียบกับ Microservices ใน SA Document
Cross-References ของเอกสาร¶
| หัวข้อ | ส่วน TOR | เอกสาร Phase 2 |
|---|---|---|
| สถาปัตยกรรม | TOR 6.4, 7.1 | System Architecture Document (Milestone 1) |
| UI/UX | TOR 7.3 | System Design Document (Milestone 1) |
| ความสามารถในการเข้าถึง | TOR 7.18.2 | WCAG Compliance Plan |
| ระบบ 1–9 | TOR 7.11–7.19 | เอกสารข้อกำหนดแต่ละระบบ |
| API Integration | TOR 7.20 | API Specification (Milestone 1) |
| VA Scan | TOR 7.23 | Security Assessment Plan |
| Payment Terms | TOR [Contract Section] | สัญญา |
สมมติฐาน และหมายเหตุ¶
- กำหนดเวลาทั้งหมดสมมติว่าไม่มีความล่าช้าที่สำคัญในการรวบรวมข้อกำหนด
- ลำดับความสำคัญ Go-live (ขั้นต่ำ 5 เป้าหมาย 7) สมมติว่ามีทีมการพัฒนา Parallel
- Timeline VA Scan 1 เดือนสมมติว่าแจ้งเตือนเร็วๆ นี้ สกมช
- งบประมาณคงที่ต่อสัญญา; การเปลี่ยนแปลงขอบเขตต้องมีการจัดการการเปลี่ยนแปลงอย่างเป็นทางการ
- ขอบเขตระยะเวลาการสนับสนุนหลัง Go-live (ผลงาน M4) เพื่อกำหนดใน Kick-off Meeting
เวอร์ชันเอกสาร: 1.0 วันที่เตรียม: 24 มีนาคม 2026 อิงจาก: TOR อย่างเป็นทางการ Phase 2 Contract บันทึก Pre-Kickoff Meeting ตรวจสอบครั้งต่อไป: หลัง Milestone 1 (อนุมัติ System Architecture Document)