ข้ามไปที่เนื้อหา

S6 — ปรับปรุงระบบ OCIPA (ช่วยเหลือเยียวยาผู้เสียหายและจำเลยในคดีอาญา)

⚠️ HIGH RISK

ตารางภาพรวมระบบ

คุณลักษณะ ค่า
ส่วนใน TOR 7.16
หน่วยงาน สชง. (สำนักชดเชยค่าสินไหม)
ประเภท ปรับปรุง
ระดับความพยายาม 🔴 HIGH RISK
Stack เทคโนโลยี C# .NET, IIS, MSSQL
ควบคุมเวอร์ชัน FILES ONLY — ไม่มี Git version control
สถานะการคอมไพล์ ซอร์สโค้ดบางส่วนไม่สามารถคอมไพล์ได้
ความซับซ้อนของเวิร์กโฟลว์ 6 เวิร์กโฟลว์หลัก พร้อม 4-29 ขั้นตอนต่อเวิร์กโฟลว์

เอกสาร SRS อ้างอิง

รายการ ข้อมูล
ชื่อเอกสาร Software Requirement Specification (SRS) v3.0.0
วันที่ออกฉบับ กันยายน 2565 (2022)
ผู้รับเหมา Megazzy (www.megazzy.co.th)
BA นุศรา แก้วคำ
System Analyst คุณโทนวิทย์ ปะดินัง
Project Manager คุณสกณธ์ รัตนมาลัย
Template ISSA RAH_T_SRS_V.2.0.0
จำนวนหน้า 169 หน้า
Server Production ocipav1.rlpd.go.th (IP 10.136.27.44, port 80/443/9081)
Server UAT ocipauat.rlpd.go.th (IP 10.136.27.144, port 80/443/9081)
Admin User madev.t

วัตถุประสงค์โครงการ (จาก SRS Section 1)

ระบบ OCIPA ถูกพัฒนาเพื่อบรรลุวัตถุประสงค์หลักดังต่อไปนี้:

  1. ปรับปรุงระบบสารสนเทศการช่วยเหลือเยียวยา — ทบทวนกระบวนการใหม่และติดตามสถานการณ์ที่เปลี่ยนแปลง เพื่อให้เกิดความเสมอภาคและประสิทธิภาพในการให้บริการ

  2. ลดขั้นตอนการยื่นขอเงินเยียวยา — แทนที่การส่งเอกสารทางไปรษณีย์ (สชง. 15/16) ด้วยระบบออนไลน์ที่เข้าถึงได้ง่าย เพิ่มความสะดวกให้กับผู้เสียหายและจำเลย

  3. ติดตามและประมวลผลจัดอันดับจังหวัด — ระบบติดตามสีสัญญาณ (สีเขียว/เหลือง/แดง) เปรียบเทียบกับสถิติตำรวจ เพื่อการวิเคราะห์และปรับปรุงอย่างต่อเนื่อง

  4. รองรับการรับคำขอออนไลน์ — เปิดช่องทางดิจิทัลสำหรับการยื่นเรื่องใหม่ เพิ่มการเข้าถึงบริการสำหรับกลุ่มต่างๆ

  5. พัฒนาระบบช่วยเหลือเยียวยาครบวงจร 4 ด้าน:

  6. ยุติธรรม (Justice) — ด้านกฎหมายและสิทธิ
  7. ชดเชยผู้กระทำผิด (Offender Compensation) — จำเลยในคดีอาญา
  8. ชดเชยโดยรัฐ (State Compensation) — เงินสนับสนุนจากงบประมาณของรัฐ

  9. ช่วยเหลือเรื่องอื่น (Other Assistance) — สนับสนุนด้านสังคม สุขภาพ เป็นต้น

  10. ช่วยเหลือเยียวยาผู้ต้องทำในชั้นสอบสวน — เพิ่มจุดติดต่อช่วยเหลือในระยะเริ่มต้นของกระบวนการยุติธรรม

  11. ยืนยันข้อมูลส่วนบุคคลผ่าน OTP — ใช้เทคโนโลยี One-Time Password เพื่อความปลอดภัยข้อมูลและการยืนยันตัวตน

สถานะปัจจุบัน

  • ระบบใช้งานได้: OCIPA ทำงานในสภาพแวดล้อมการใช้งานจริงและให้บริการช่วยเหลือเยียวยาผู้เสียหายและจำเลย

  • หนี้ทางเทคนิค: มีการสะสมอย่างมีนัยสำคัญ:

  • ซอร์สโค้ดเก็บรักษาเป็นไฟล์เท่านั้น — ไม่มี Git หรือ version control
  • โมดูลซอร์สโค้ดบางส่วนไม่สามารถคอมไพล์ได้
  • ไม่มีเอกสารข้อผิดพลาดในการคอมไพล์

  • การ deploy อัตโนมัติจำกัด

  • ช่องว่างการควบคุมเวอร์ชัน: ปัญหาวิกฤตสำหรับการบำรุงรักษาและความร่วมมือของทีม

  • ไม่มีประวัติ commit หรือติดตามการเปลี่ยนแปลง
  • ความเสี่ยงจากการสูญเสียโค้ดหรือการเขียนทับโดยไม่ตั้งใจ

  • ไม่มีกลยุทธ์การแยกสาขาสำหรับการเปลี่ยนแปลงใน Phase 2

  • การจัดการสถานะของกระบวนการ: เวิร์กโฟลว์ขึ้นอยู่กับช่องสถานะ ที่มีข้อจำกัดที่ยากในการปฏิบัติ

  • เวิร์กโฟลว์ 6 ชนิดตามสถานการณ์ การยื่นขอเสียหาย อุทธรณ์ จำเลย เป็นต้น
  • การอัปเดตสถานะเชื่อมโยงโดยตรงกับการเปลี่ยนแปลงสถานะ UI
  • จำเป็นต้องแทรกแซงฐานข้อมูลด้วยตนเองเพื่อแก้ไขข้อผิดพลาด

Business Processes จาก SRS (Section 2.2)

ระบบ OCIPA สนับสนุน 6 เวิร์กโฟลว์ธุรกิจหลัก ซึ่งมีความซับซ้อนและทำงานร่วมกัน:

1. ศูนย์รับเรื่อง กคส. (Case Reception Center) — 6 ขั้นตอน

ขั้นตอน: 1. รับเรื่องจากช่องทางต่างๆ 2. เสียบบัตรประชาชนและสแกนข้อมูล 3. คัดลอกข้อมูลจากระบบ MSC (Master System via Web Service) 4. ให้คำปรึกษาเบื้องต้น 5. บันทึกการให้คำปรึกษา 6. ส่งต่อหน่วยงานกพส. (กองบัญชาการประสานงาน) เพื่อการให้คำปรึกษากฎหมายเชิงลึก

ช่องทาง Source: - MSC Web Service - Call Center (โทรศัพท์) - ประชาชนยื่นเอง (ศูนย์บริการ)

Output: คำส่งต่องานให้กพส. เพื่อการประกอบการ

2. รับเรื่องร้องทุกข์ (Complaint Reception Workflow)

เวิร์กโฟลว์หลายขั้นตอนสำหรับการบันทึก การจัดประเภท และการส่งต่อร้องทุกข์ของประชาชน

3. ช่วยเหลือเยียวยาผู้เสียหายในคดีอาญา (Victim Compensation) — 29 ขั้นตอน

ลักษณะ: เวิร์กโฟลว์แบบมัลติแชนเนล (8 swim lanes)

ผู้เกี่ยวข้อง (Swim Lanes): 1. ผู้ยื่นอุทธรณ์ (Appellant/Victim) 2. เจ้าหน้าที่ สชง. (OCIPA Officer) — การบันทึก การตรวจสอบ 3. นิติกร (Legal Officer) — การทบทวนกฎหมาย การแสวงหาข้อเท็จจริง 4. เลขาฯคณะอนุกรรมการย่อย (Sub-committee Secretary) — การเตรียมการประชุม 5. คณะอนุกรรมการย่อย (Sub-committee) — การพิจารณาเบื้องต้น 6. เลขาฯคณะกรรมการ (Committee Secretary) — การเตรียมประชุมชั้นสูง 7. คณะกรรมการ (Full Committee) — การพิจารณาขั้นสุดท้าย 8. การเงิน (Finance) — การจัดการการชำระเงิน

ขั้นตอนหลัก: ยื่นคำขอ → ประกอบการ → ตรวจสอบเอกสาร → ประเมินความคุ้มค่า → ส่งคณะอนุกรรมการ → พิจารณา → อนุมัติ → ชำระเงิน → ปิดกรณี

4. ช่วยเหลือเยียวยาผู้เสียหายในคดีอาญา (กรณีอุทธรณ์) (Appeal Case) — 29 ขั้นตอน

เวิร์กโฟลว์เดียวกับข้างต้น แต่เน้นการอุทธรณ์สำหรับการตัดสินใจที่ปฏิเสธก่อนหน้านี้

ผู้เกี่ยวข้อง: swim lanes เดียวกัน 8 แห่ง

5. ช่วยเหลือเยียวยาจำเลยในคดีอาญา (Defendant Compensation) — 26 ขั้นตอน

เวิร์กโฟลว์สำหรับการขอเงินชดเชยจากจำเลยที่ไม่ได้ร้องขอตัวเอง แต่โดยตัวแทน

ผู้เกี่ยวข้อง: swim lanes เดียวกัน 8 แห่ง (อาจมีบทบาทเพิ่มเติมจากประชาชนทั่วไป)

6. ช่วยเหลือเยียวยาผู้ต้องหา (Suspect Compensation)

เวิร์กโฟลว์สำหรับผู้ต้องสงสัย (ยังไม่ได้กล่าวหา) ที่เสียหายและต้องการความช่วยเหลือ

หมายเหตุ: ทั้ง 6 เวิร์กโฟลว์ใช้ข้อมูลเดียวกันแต่มีกฎการประมวลผลแตกต่างกัน ผู้ใช้ระบบต้องจำแนกประเภทกรณีได้ถูกต้องตั้งแต่ยื่นเรื่องครั้งแรก

ข้อกำหนดตาม TOR

  • ปรับปรุงระบบ OCIPA (ส่วน 7.16)
  • รักษาบริการช่วยเหลือเยียวยาผู้เสียหายและจำเลย
  • สนับสนุนเวิร์กโฟลว์การยื่นขอเงินค่าชดเชย
  • รองรับการติดตามอินฟลูเอนซ์ (tracking by color-coded status)
  • บูรณาการระบบ OTP สำหรับยืนยันตัวตน
  • บูรณาการกับ GFMIS สำหรับการชำระเงิน

ปัญหาที่พบ

🔴 ปัญหาวิกฤต

  1. ข้อจำกัดการย้อนกลับสถานะ
  2. ช่องสถานะไม่สามารถย้อนกลับได้เมื่ออัปเดตผ่านเวิร์กโฟลว์ UI ปกติ
  3. หากผู้ใช้ไปยังขั้นตอนต่อไปโดยไม่ตั้งใจ จะต้องแก้ไขฐานข้อมูลโดยตรง
  4. ต้องมีการแทรกแซงจากผู้ดูแลระบบฐานข้อมูล IT

  5. สร้างคอขวดและข้อกังวลเกี่ยวกับการตรวจสอบความปลอดภัย

  6. ข้อผิดพลาดการรอสูงสุดของการค้นหา

  7. การค้นหาชุดข้อมูลขนาดใหญ่หมดเวลาโดยไม่มีการตอบรับข้อผิดพลาด
  8. ไม่มีการจัดการข้อผิดพลาดอย่างสง่างาม หรือข้อความเตือนผู้ใช้
  9. ผู้ใช้ไม่ทราบว่าการค้นหาล้มเหลวจนกว่าหน้าจอจะค้าง

  10. อาจขาดการกำหนดค่าสูงสุดเวลา หรือ connection pooling

  11. ข้อล้มเหลวในการส่งออกรายงาน

  12. รายงานล้มเหลวเมื่อส่งออกชุดข้อมูลขนาดใหญ่
  13. อาจไม่มีการแบ่งหน้าในตรรมชาติลอจิก
  14. ผู้ใช้ได้รับรายงานว่างเปล่าหรือข้อผิดพลาดของระบบแทนผลลัพธ์แบ่งหน้า

  15. ส่งผลกระทบต่อการรายงานการปฏิบัติตามข้อบัญญัติและการรายงานทางการเงิน

  16. ข้อจำกัดในการแนบเอกสาร

  17. ไม่สามารถเพิ่มเอกสารแนบที่ขาดหายไปได้ย้อนหลัง
  18. หากผู้ใช้ลืมแนบเอกสารที่จำเป็น จะไม่มีเส้นทางการกู้คืน
  19. เวิร์กโฟลว์หยุดชะงักหรือต้องปฏิเสธกรณีและเริ่มต้นใหม่

  20. ไม่มีการจัดเวอร์ชันเอกสารหรือความสามารถในการแทนที่

  21. หนี้ทางการจัดองค์กร

  22. ระบบย่อยบางระบบ "จอด" ใน OCIPA ที่ไม่เกี่ยวข้องกับขอบเขตการชดเชย
  23. สร้างภาระการบำรุงรักษา
  24. ทำให้ขอบเขตการทดสอบและการปรับใช้ไม่ชัดเจน

🟡 ปัญหาคุณภาพโค้ด

  1. ข้อล้มเหลวในการคอมไพล์ซอร์สโค้ด
  2. ต้องการการตรวจสอบฐานรหัสอย่างเต็มรูปแบบ
  3. ไลบรารีที่ขาดหายหรือการอ้างอิงที่ล้าสมัย
  4. การเปลี่ยนแปลงที่ทำให้เสียหายในเวอร์ชัน .NET framework
  5. ความไม่ตรงกันของเวอร์ชันแพ็คเกจ NuGet

เวิร์กโฟลว์และขั้นตอน

ขั้นตอนหลักของการยื่นเรื่องและการประมวลผลชดเชย

เวิร์กโฟลว์แบบลำดับเหล่านี้แสดงถึงวงจรชีวิตของกรณีจากการยื่นขอจนถึงการชำระเงิน:

  1. การยื่นขอค่าชดเชย — ผู้เสียหายหรือจำเลย ยื่นคำขอผ่านหน้าต่างกคส. หรือออนไลน์
  2. การตรวจสอบเบื้องต้น — เจ้าหน้าที่ สชง. ตรวจสอบความสมบูรณ์ของเอกสาร
  3. การตรวจสอบเอกสารและประกอบการ — นิติกรแสวงหาข้อเท็จจริงและตรวจทานเอกสาร
  4. การส่งคณะอนุกรรมการ — เลขาฯคณะอนุกรรมการย่อยจัดการประชุมพิจารณา
  5. การพิจารณาคณะอนุกรรมการย่อย — คณะอนุกรรมการให้ความเห็น
  6. การส่งคณะกรรมการชั้นสูง — เลขาฯคณะกรรมการเตรียมประชุมสรุป
  7. การพิจารณาคณะกรรมการ — คณะกรรมการให้ความเห็นขั้นสุดท้าย (Decision)
  8. การกำหนดจำนวนเงินชดเชย — การเงินคำนวณจำนวนเงิน
  9. การชำระเงิน — ประมวลผลผ่าน GFMIS ยืนยันการโอนเงิน (KTB, BBL, Cheque)
  10. การปิดกรณี — บันทึกการปิดและจัดเก็บเอกสาร

ข้อจำกัดปัจจุบัน: การเปลี่ยนสถานะแต่ละครั้งเป็นทางเดียวโดยไม่มีตัวเลือกนำทางย้อนกลับ

ลำดับเวลาทั่วไป

  • การยื่นเรื่องจนถึงอนุมัติ: 30-60 วัน (ขึ้นอยู่กับความเรียบง่ายของกรณี)
  • การอุทธรณ์: อีก 30-45 วัน เพิ่มเติม
  • การชำระเงิน: 5-10 วันทำการหลังจากอนุมัติ

Data Model (สรุปจาก Data Dictionary) — 150+ ตาราง

กลุ่มตาราง: Registration & Case Management

  • CaseRegistration — การลงทะเบียนกรณี ประมาณวันที่และผู้ยื่น
  • CaseTransaction — บันทึกการลงรายการ (เหตุการณ์) ของกรณี
  • CaseRunning — สถานะปัจจุบันและขั้นตอนของกรณี
  • CaseType — ประเภทกรณี (เสียหาย จำเลย ผู้ต้องหา)

กลุ่มตาราง: OCIPA Workflow & Job Management

  • OCIPAJob — งาน (Task) ที่เจ้าหน้าที่ต้องทำ
  • OCIPAWorkStep — ขั้นตอนการทำงาน (การตรวจสอบ การให้ความเห็น เป็นต้น)
  • OCIPAWorkStepPath — เส้นทางการไหลของขั้นตอน (การเปลี่ยนสถานะ)
  • OCIPAWorkStepProcess — กฎการประมวลผลสำหรับแต่ละขั้นตอน
  • OCIPAJobStatusHistory — ประวัติการเปลี่ยนแปลงสถานะของงาน

กลุ่มตาราง: Criminal Case Integration

  • CriminalCaseRegistration — ลิงค์กับเคสอาญาจากระบบตำรวจ
  • Compensation — จำนวนเงินชดเชยที่อนุมัติ
  • CompensationMapComplainant — แมปเชื่อมโยงระหว่างการชดเชยและผู้ยื่น

กลุ่มตาราง: Finance & Payment Processing

  • FinanceStatus — สถานะการเงิน (เตรียม อนุมัติ ส่งจ่าย ปิด)
  • FinanceTransactionApproveUpload — อัปโหลดสำหรับการอนุมัติการจ่ายเงิน GFMIS
  • PaymentInformation — รายละเอียดบัญชีธนาคารสำหรับการชำระเงิน (KTB, BBL)
  • PaymentStatus — สถานะการชำระเงิน (ส่งออกแล้ว ยืนยันแล้ว)

กลุ่มตาราง: Document & Attachment Management

  • DocumentAttachment — เอกสารแนบในกรณี
  • DocumentVersion — เวอร์ชันของเอกสารแต่ละฉบับ
  • DocumentRequirement — ข้อกำหนดเอกสารโดยประเภทกรณี

กลุ่มตาราง: User & Access Control

  • UserRole — บทบาทผู้ใช้ (Officer, Legal, Committee, Finance)
  • UserPermission — สิทธิในการเข้าถึง

กลุ่มตาราง: Audit & Logging

  • AuditLog — บันทึกการตรวจสอบทั้งหมดการเปลี่ยนแปลง
  • ApplicationLog — บันทึกข้อผิดพลาด และกิจกรรมของระบบ

หมายเหตุ: โปรแกรม Data Dictionary ใน SRS มีรายละเอียดคอลัมน์ ประเภทข้อมูล ข้อจำกัด และความเสมอภาคสำหรับตารางทั้งหมด 150+ ตาราง

จุดเชื่อมต่อระบบ

  • การรวมกับ S1 (ระบบคำปรึกษาด้านกฎหมาย)
  • S1 ได้รับข้อมูลจาก "OCIPA ยื่นออนไลน์" (OCIPA online submission)

  • สร้างลิงก์อ้างอิงระหว่างคำปรึกษาด้านกฎหมายและการยื่นขอเงินค่าชดเชย

  • ข้อกำหนดสถาปัตยกรรมที่สำคัญ: S1 ต้องคงความเป็นอิสระจาก S6

  • S1 ไม่ควรถูกบล็อกโดยการหยุดทำงานของ OCIPA
  • การซิงค์ข้อมูลเป็นทางเดียว (S6 → S1)
  • ไม่มีการพึ่งพาแบบวงกลม

  • วัฏจักรการปรับใช้แยกต่างหาก

  • การพึ่งพาระบบที่อาจเป็นไปได้ (จำเป็นต้องตรวจสอบ):

  • ระบบบัญชี/บัญชีทางการเงิน
  • ฐานข้อมูลผู้เสียหายและจำเลย (MSC - Master System)

  • ระบบการจัดการกรณี (Case Management System)

  • การบูรณาการการชำระเงิน:

  • GFMIS integration สำหรับการจัดสรรงบประมาณ การเบิกจ่าย
  • ธนาคาร: KTB (Krung Thai Bank), BBL (Bangkok Bank)
  • วิธีการชำระ: โอนเงิน ธนาคาร เช็ค
  • การยืนยันการชำระเงินจากระบบธนาคาร

คำถามที่ยังไม่ได้คำตอบ

[OPEN] ไฟล์ซอร์สโค้ดใดบ้างที่ไม่สามารถคอมไพล์ได้? จำเป็นต้องมีการตรวจสอบข้อผิดพลาดการคอมไพล์ที่สมบูรณ์

[OPEN] ระบบย่อย "จอด" ใดบ้างที่อยู่ใน OCIPA ปัจจุบัน? ควรลบออกหรือแยกออกเป็นระบบต่างหาก?

[OPEN] สามารถรีแฟกเตอร์ฐานรหัสเพื่อใช้ Git ได้โดยไม่ทำให้การปรับใช้หรือความสมบูรณ์ของข้อมูลเสียหาย?

[OPEN] เวิร์กโฟลว์ 10 ขั้นตอนที่แน่นอนคืออะไร พร้อมแผนภาพการเปลี่ยนสถานะที่สมบูรณ์และกฎการตรวจสอบ?

[OPEN] มีเอกสารโครงสร้างฐานข้อมูลอยู่หรือไม่? จำเป็นต้องตรวจสอบคีย์ต่างประเทศ ข้อจำกัด และทริกเกอร์

[OPEN] เวอร์ชัน .NET Framework ใดและแพ็คเกจ NuGet ใดที่ต้องการการอัปเดตหรือการแทนที่?

[OPEN] ความครอบคลุมการทดสอบปัจจุบันคืออะไร? มีการทดสอบหน่วย/การรวมพื้นฐานหรือจำเป็นต้องเขียน?

[OPEN] ข้อมูลได้รับการสำรองไว้อย่างไร? ขั้นตอนการกู้คืนจากความผิดพลาดคืออะไร?

[OPEN] ใครมีการเข้าถึงฐานข้อมูลในปัจจุบัน? จำเป็นต้องใช้การเข้าถึงสิทธิน้อยที่สุดสำหรับการเปลี่ยนแปลง Phase 2

[OPEN] ตัวเลขอนุมัติของเอกสาร SRS ฉบับนี้ (v3.0.0) คืออะไร? ใครมีประมาณการเชิงนอก?

[OPEN] เวิร์กโฟลว์การอุทธรณ์เพิ่มเติม (29 ขั้นตอน) ต่างจากเวิร์กโฟลว์หลักอย่างไร? มีแผนภาพที่ชัดเจนในเอกสาร SRS หรือไม่?

[OPEN] ตัวชี้วัด KPI ที่คาดหวังสำหรับการปรับปรุง OCIPA คืออะไร? (ระยะเวลาประมวลผล อัตราความสำเร็จ ความพึงพอใจผู้ใช้)

หมายเหตุทางเทคนิค

ลำดับความสำคัญในการปรับปรุง Phase 2

Phase 1: การปรับเสถียรภาพและการตรวจสอบ (สัปดาห์ 1-2)

  1. การตรวจสอบซอร์สโค้ด
  2. พยายามคอมไพล์ในสภาพแวดล้อมที่ควบคุม
  3. เอกสารข้อผิดพลาดการคอมไพล์ทั้งหมดพร้อมหมายเลขบรรทัด
  4. ระบุการอ้างอิงที่ขาดหายและข้อขัดแย้งเวอร์ชัน

  5. สร้างรายงานข้อผิดพลาดการคอมไพล์

  6. การย้ายไป Git

  7. สร้างที่เก็บ Git
  8. นำเข้าฐานรหัสปัจจุบันเป็น commit เริ่มต้น
  9. ตั้งค่ากลยุทธ์การแยกสาขา (main, develop, feature/)

  10. กำหนดค่า deployment pipeline สำหรับการสร้างที่ควบคุมเวอร์ชัน

  11. เอกสารโครงสร้างฐานข้อมูล

  12. ส่งออกแผนภาพโครงสร้าง
  13. เอกสารตารางทั้งหมด คอลัมน์ ข้อจำกัด
  14. ระบุความสัมพันธ์ของคีย์ต่างประเทศ
  15. แมปไปยังการเปลี่ยนแปลงสถานะเวิร์กโฟลว์

Phase 2: แก้ไขปัญหาวิกฤต (สัปดาห์ 3-6)

  1. ระบบอัตโนมัติการปรับสมดุลสถานะ
  2. เพิ่มความสามารถในการย้อนกลับสถานะผ่าน UI (ต้องได้รับการอนุมัติจากผู้ดูแล)
  3. ใช้บันทึกการตรวจสอบสำหรับการเปลี่ยนแปลงสถานะทั้งหมด
  4. สร้างกฎการตรวจสอบสถานะและข้อจำกัด

  5. การปรับเปลี่ยนขั้นตอนที่ใช้ UI (ลบการแก้ไข DB เท่านั้น)

  6. ประสิทธิภาพการค้นหาและการจัดการข้อผิดพลาด

  7. เพิ่มการแบ่งหน้าให้กับการค้นหาชุดข้อมูลขนาดใหญ่
  8. ใช้การกำหนดค่าสูงสุดเวลากับข้อความข้อผิดพลาดที่เป็นมิตรต่อผู้ใช้
  9. เพิ่มข้อจำกัดขนาดผลลัพธ์การค้นหา
  10. การลดลงอย่างสง่างาม: คืนผลลัพธ์บางส่วนแทนข้อผิดพลาดสูงสุดเวลา

  11. บันทึกโดยละเอียดเพื่อการแก้ไขจุดบกพร่อง

  12. การปรับปรุงการส่งออกรายงาน

  13. ใช้การแบ่งหน้าสำหรับฟังก์ชันการส่งออก
  14. รองรับการส่งออกแบบสตรีมสำหรับชุดข้อมูลขนาดใหญ่
  15. เพิ่มตัวบ่งชี้ความก้าวหน้าสำหรับการส่งออกที่ใช้เวลานาน

  16. ใช้ขีดจำกัดขนาดการส่งออกกับการส่งข้อความที่ชัดเจน

  17. การจัดการการแนบเอกสาร

  18. เพิ่มความสามารถในการแทนที่เอกสารหลังจากการส่ง
  19. ใช้เวอร์ชันเอกสาร (ติดตามประวัติการแนบ)
  20. สร้างเวิร์กโฟลว์การอัปโหลดเอกสารย้อนหลัง
  21. เพิ่มการตรวจสอบว่าเอกสารที่จำเป็นมีอยู่ก่อนการเปลี่ยนขั้นตอน

Phase 3: การบำรุงรักษาและการทำความสะอาด (สัปดาห์ 7+)

  1. ระบุและแยกระบบ "จอด"
  2. ตรวจสอบชุดคุณลักษณะเพื่อระบุฟังก์ชันที่ไม่ใช่การชดเชย
  3. พิจารณาว่าพวกเขาเป็นของระบบอื่นหรือไม่
  4. วางแผนการดึงออก/ย้ายถ้าเหมาะสม

  5. เอกสารกระบวนการการส่งมอบ

  6. กลยุทธ์การทดสอบ

  7. การทดสอบหน่วยสำหรับตรรมชาติการเปลี่ยนสถานะ
  8. การทดสอบการรวมสำหรับเวิร์กโฟลว์เอกสาร
  9. การทดสอบการโหลดสำหรับการส่งออกรายงาน
  10. UAT กับเจ้าหน้าที่การชดเชย

  11. การทดสอบการถอยหลังในทั้ง 10 ขั้นตอนเวิร์กโฟลว์

  12. ระบบอัตโนมัติการปรับใช้

  13. การสร้างอัตโนมัติจาก Git (CI/CD pipeline)
  14. การทดสอบอัตโนมัติก่อนการปรับใช้การใช้งานจริง
  15. ขั้นตอนการตัดสินใจสำหรับการปรับใช้ที่ล้มเหลว
  16. กลยุทธ์การปรับใช้โดยไม่มีเวลาหยุด

การตัดสินใจสถาปัตยกรรม: ความเป็นอิสระของ S1

วิกฤต: การเปลี่ยนแปลง S6 ต้องไม่ส่งผลกระทบต่อความพร้อมหรือความสมบูรณ์ของข้อมูล S1

  • ใช้การเชื่อมต่อฐานข้อมูลแยกต่างหาก
  • ใช้คิวข้อความ (หากจำเป็น) สำหรับการซิงค์ข้อมูลแบบอะซิงโครนัส
  • S1 ควรมีสำเนาแคช S6 ข้อมูล (สำหรับการอ้างอิงเท่านั้น)
  • การหยุดทำงาน S6 ไม่ควรบล็อกการดำเนินการ S1
  • ตรวจสอบจุดรวมเพื่อความสอดคล้องของข้อมูล

พื้นฐานคุณภาพโค้ด

หลังจากการปรับเสถียรภาพ ให้สร้างมาตรฐานคุณภาพขั้นต่ำ: - โค้ดทั้งหมดคอมไพล์ได้โดยไม่มีคำเตือน - การทดสอบอัตโนมัติสำหรับเส้นทางวิกฤตทั้งหมด - ข้อกำหนดการตรวจสอบโค้ดสำหรับคำขอดึง - เครื่องมือวิเคราะห์แบบคงที่ที่เปิดใช้ (SonarQube หรือเทียบเท่า) - การสแกนความปลอดภัยสำหรับช่องโหว่การพึ่งพา

ข้อมูลเพิ่มเติมจาก SRS

Scope — Web Application (Section 3.1)

คุณลักษณะทั่วไป (General Characteristics): - รองรับบรรดา 6 เวิร์กโฟลว์หลัก - ส่วนติดต่อ UI สำหรับเจ้าหน้าที่ สชง. ที่ทำงานภายในศูนย์รับเรื่อง - ส่วนติดต่อ UI สำหรับนิติกร ลงรับเรื่องและประกอบการ - ส่วนติดต่อ UI สำหรับประธาน/เลขาฯคณะอนุกรรมการ - ส่วนติดต่อ UI สำหรับการเงิน ในการจัดการการชำระเงิน

คุณลักษณะเฉพาะ (Specific Characteristics): - ระบบทดสอบให้ผ่าน OTP การยืนยันตัวตน - ระบบติดตามสถานะแบบสีสัญญาณ (Green/Yellow/Red) - ความสามารถในการปรับประมาณการเงินก่อนการชำระ - สนับสนุนการส่งออกรายงานตามจังหวัด - การบูรณาการ MSC Web Service สำหรับข้อมูลผู้ยื่น

ไม่อยู่ในขอบเขต (Out of Scope): - การพิมพ์หนังสือราชการโดยตรง (จัดการแยกต่างหาก) - การส่งอีเมลโดยอัตโนมัติ (ขึ้นอยู่กับระบบ Email Service อื่น) - การจัดการสิ่งพิมพ์ (Document Management)

ปรับปรุงครั้งสุดท้าย: 2026-03-29 แหล่งข้อมูลหลัก: OCIPA SRS v3.0.0 (Sept 2022, Megazzy, ISSA RAH_T_SRS_V.2.0.0)