จากการอ่าน TOR v1.2 อย่างละเอียด พบ 6 ประเด็นที่ต้องการคำตอบจากลูกค้า — 3 ข้อต้องปิดก่อนลงนาม อีก 3 ข้อ define ใน Design Phase
TOR เขียนว่าผู้รับจ้างต้องรับผิดชอบความถูกต้องของข้อมูลจาก Registrar / TU-NEXT / TUXSA — ซึ่งเราควบคุมไม่ได้เลย ถ้า Registrar ส่งข้อมูลผิดมาแล้วมีปัญหา เราอาจถูกปรับทั้งที่ไม่ใช่ความผิดของเรา
TOR ระบุว่า "สามารถเสนอ" ขยายเวลาได้ถ้าถูก block โดย API ของ TU แต่ไม่มีกระบวนการอนุมัติ ใครตัดสิน? ขยายได้สูงสุดกี่วัน? งวดเงินเลื่อนตามไหม? — ความเสี่ยงสูงเพราะ TU-NEXT ยังไม่มี API พร้อมอยู่แล้ว
TU-NEXT Phase 1 ใช้ File-based Integration (ยังไม่มี API) ข้อมูลหน่วยกิตจะ sync เป็น batch ไม่ใช่ real-time — ต้องตกลงกันว่าส่งกี่วัน/ครั้ง และถ้า TU-NEXT ส่งไฟล์ล่าช้า SLA ของเราจะนับอย่างไร
TOR กำหนดให้มี Match Score แต่ไม่มี formula ปัจจุบัน TU ยังไม่มี criteria ที่ชัดเจน — เป็นดุลยพินิจอาจารย์แต่ละคณะ ถ้าไม่ define ก่อน code จะ implement ผิดและถูกปฏิเสธใน UAT
ตกลงแล้วว่า self-register + รอ in-person verification แต่ยังไม่รู้ว่าแผนกไหนรับผิดชอบ, verify ที่ไหน, ข้อมูล profile เริ่มต้นคืออะไร และระหว่าง pending ทำอะไรได้บ้างใน UX
ตกลงแล้วว่า migrate ข้อมูล 5 ปีก่อน Go-Live จาก Registrar แต่ยังไม่รู้รูปแบบ คุณภาพ และ volume จริงของข้อมูล ถ้าไม่ดู sample ก่อนอาจประเมิน effort ผิดพลาด
ประเด็นต่อไปนี้ได้รับการยืนยันและบันทึกไว้ใน CONTEXT.md แล้ว
มหาวิทยาลัยธรรมศาสตร์พัฒนา TUCBS เป็น Core Digital Infrastructure สำหรับจัดเก็บ สะสม โอนถ่ายหน่วยกิตแบบดิจิทัล รองรับ Lifelong Learning เชื่อมต่อกับระบบภายใน (Registrar, TU-NEXT, TUXSA) และภายนอก ผ่าน API-first + Integration Layer พร้อม AI-Ready Architecture
| 2.1 | พัฒนาระบบคลังหน่วยกิตที่ใช้งานได้จริง |
| 2.2 | รองรับการจัดการและโอนหน่วยกิตแบบดิจิทัล |
| 2.3 | รองรับผู้เรียนหลากหลายกลุ่มและการเรียนรู้ตลอดชีวิต |
| 2.4 | รองรับการเชื่อมต่อกับระบบภายนอก |
| 2.5 | วางโครงสร้างระบบรองรับอนาคต (AI, ระดับชาติ) |
| Module | ชื่อ | หมายเหตุ |
|---|---|---|
| 3.1 | Credit Bank & Learning Accumulation | Credit + Non-Credit Portfolio |
| 3.2 | Learner Profile Management | Unified Profile, RBAC |
| 3.3 | Identity Resolution & MDM | Golden Record, Deduplication |
| 3.4 | Course & Learning Pathway Management | Course Catalog, ลงทะเบียน |
| 3.5 | Credit Transfer & Workflow | Rule-based + Manual Review Phase 1 |
| 3.6 | Co-op & MOU Matching Platform | Rule-based Matching, Employer Portal |
| 3.7 | Integration & API Platform | API Gateway, RESTful |
| 3.8 | Data Architecture & Governance | PDPA, Encryption, AI-ready |
| 3.9 | Reporting & Dashboard | Operational Dashboard Phase 1 |
| 3.10 | AI-Ready Architecture | ML-ready Data Structure |
| AI Production System | Auto Credit Transfer, ML Matching |
| NCBS Integration | รอระบบระดับชาติ |
| Mobile Native App | Phase 1 ใช้ Web Responsive |
| Advanced Analytics | Phase 1 ใช้ Operational Dashboard |
| Data Migration >5 ปี | เฉพาะข้อมูล 5 ปีล่าสุดก่อน Go-Live |
| ประเด็น | ข้อกำหนด |
|---|---|
| Cloud Provider | AWS / Azure / GCP |
| ผู้ใช้งานต่อวัน | ≥ 2,000 คน |
| Concurrent Users | 300–500 คน |
| Uptime SLA | ≥ 99% ต่อเดือน |
| Backup | Full Backup ทุกวัน, Retention ≥ 30 วัน |
| RTO | ≤ 8 ชั่วโมง |
| RPO | ≤ 24 ชั่วโมง |
ระยะเวลา: ไม่เกิน 240 วัน นับจากวันลงนามสัญญา
| งวด | % | Milestone |
|---|---|---|
| งวดที่ 1 | 20% | Design — FSD, Architecture, DB Schema, UX/UI Wireframe |
| งวดที่ 2 | 30% | Development — Source Code, DEV/SIT Environment, SIT ผ่าน |
| งวดที่ 3 | 30% | UAT — ผ่าน UAT, ไม่มี Bug Critical/Major |
| งวดที่ 4 | 20% | Go-Live — Production live, ระบบ stable 7 วัน |
| รายการ | งบประมาณ |
|---|---|
| Development (รวม IP) | 6,485,000 บาท |
| Cloud Infrastructure (8 เดือน Dev + Production ปีที่ 1) | 400,000 บาท |
| บุคลากร On-site (Part-time, 3 ปี) | 720,000 บาท (~20,000/เดือน) |
| รวมทั้งสิ้น | 7,605,000 บาท |
| ระดับ | นิยาม | Response Time |
|---|---|---|
| Critical | ระบบล่ม | ≤ 4 ชั่วโมง |
| Major | Function หลักไม่ทำงาน | ≤ 1 วันทำการ |
| Minor | Function ย่อยผิดปกติ | ≤ 2 วันทำการ |
รับประกัน 3 ปี หลัง Go-Live | Source Code และ IP ทั้งหมดเป็นของ มธ.