OPT CDP migration PoC. Q&A về cơ chế đo hiệu quả AI: đo theo công đoạn, guard chống ảo số, 6 chuẩn legacy↔new, provenance, 18 metric Phase-2.
💡 KPI ID (gạch nét đứt, màu xanh) = rê chuột xem tóm tắt, click mở trang chi tiết (định nghĩa · cách đo · ví dụ). Keyword gạch-chân-chấm = hover xem định nghĩa. Trạng thái: ✅ đã đo · ⏳ chưa đo (KHÔNG phải đang chạy) · ⛔ blocked thiếu dữ liệu.
Người soạn: facon (điều phối SDLC + AI adoption) - Người nhận: Thiên (POC Leader OPT) - Ngày: 2026-06-24 Mục đích: tổng hợp dạng Q&A để Thiên trình khách OPT về cơ chế đo hiệu quả AI trong dự án migration VB.NET to Java/Spring+JSP. Nguyên tắc nền: mọi con số truy được nguồn [SoT: ...]; số chưa đo ghi rõ "chưa đo" kèm lý do; suy luận gắn [Estimation]/[CONFIRM]; không bịa số. Trạng thái engine tại thời điểm soạn: kpi_snapshot.py --validate cho 4 metric đã đo / 13 pending trên 17 metric, headline AI-FPA = N.A (guard A3 chưa thoả). [SoT: Code] .claude/skills/nexa-audit-target/scripts/kpi_snapshot.py --validate
Trạng thái đo tại 2026-06-24. Nguồn: kpi_snapshot.py --validate => 4 đo / 13 pending của 17 metric, headline AI-FPA = N.A. [SoT: Code]
Ký hiệu: ✅ đã đo (evidence) · ⏳ chưa đo (cơ chế sẵn) · ⛔ blocked (thiếu input).
| ID | Metric | Target | Hiện tại | Trạng thái |
|---|---|---|---|---|
| A1 | KB extraction accuracy | 80/90 | - | ⏳ |
| A2 | Docs gen FPA (BD/DD) | 60/70 | - | ⏳ |
| A3 | Code gen FPA ⭐ | 50/60 | - | ⏳ chưa bật git-tag (0 cặp) |
| A4 | Test-case gen FPA | 60/70 | - | ⏳ |
| B1 | Effort reduction | ≥40% | - | ⛔ effort-log 0 dòng |
| B2 | Review time/doc | 16h→4h | - | ⏳ |
| B3 | Throughput | report-only | - | ⏳ |
| C1 | Quality-gate pass | 100% | - | ⏳ vận hành |
| C2 | UI fidelity vs prototype | ≥95% | 100% (json) | ✅ caveat live |
| C3 | Legacy mapping (tracing) | 100% | 100% | ✅ |
| C4 | Screen audit-breadth | ≥90% | 90.6% | ✅ |
| C5 | Code structure DDD | 0 P1 | 0 gateable P1 | ✅ |
| C6 | 新旧比較 UT (parity) | ≥95% | 5/5 (scope hẹp) | ⏳ engine pending |
| D1 | Issue register | 100% | - | ⏳ |
| D2 | First-time approval | 40%→70% | - | ⏳ |
| D3 | Tuning iterations | ≤3 | - | ⏳ |
| D4 | Improvement plan | 100% | - | ⏳ |
Headline AI-FPA = N.A · guard A3≥50% = N.A · weights provisional. [SoT: Code] --validate.
| # | Tiêu chí | Hiện tại | Mục tiêu | Đạt? |
|---|---|---|---|---|
| Q1 | Mapping logic cũ→mới | proxy 85-94%, số thật chưa đo | ≥70% | 🟡 |
| Q2 | Độ chính xác logic code | parity 5/5, scope hẹp | ≥80% | 🟡 |
| Q3 | Giảm công sức/thời gian | 0 dòng effort-log | ≥40% | ⏳ |
| Q4 | Kiểm tĩnh (Sonar) | proxy 4/4 PASS, chờ server | Pass | 🟡 |
| Q5 | Coverage unit-test logic | 87.7% | ≥80% | ✅ |
| Q6 | Tỷ lệ Pass test-case | 100% (246/246) | 100% | ✅ |
spList_/FIXME phải fix| Nhóm | Metric thiếu | Khi đo |
|---|---|---|
| ROI/tài chính | M1 ROI%, M2 TCO, M3 Adoption | khi có B1+B4 |
| Chất lượng giao hàng | M4 Defect-escape, M5 Density, M6 DRE, M7 CFR, M8 Coverage% | M3/M4 code |
| Tốc độ | M9 Lead-time, M10 Cycle-time, M11 Deploy-freq | Phase-2 CI/CD |
| Con người | M12 Dev-satisfaction, M13 Trust, M14 Knowledge-transfer | định kỳ |
| Kỹ thuật | M15 SAST, M16 Tech-debt, M17 Traceability%, M18 Stat-rigor | Phase-2 |
Shortlist 6 nếu review SI: M1+M2 · M4 · M3 · M8 · M12 · roadmap DORA. [SoT: Vault] researcher.md §4.
Khách OPT hỏi đúng hai câu (qua báo cáo họp của Thiên): (1) AI tham gia công đoạn nào, giảm bao nhiêu phần trăm công sức; (2) dùng AI vấp vấn đề gì, kế hoạch cải thiện ra sao. Niềm tin hiện tại của khách: tin AI sinh đúng khoảng 40%, không tin đạt 70%, nếu chứng minh được trên 60% có bằng chứng thì hài lòng cao. [SoT: Vault] kpi-targets.json context.customer_belief_pct=40, prove_threshold_pct=60.
Quan điểm chốt mà tài liệu này bảo vệ:
Q1. Tại sao không báo khách một con số duy nhất "AI chính xác X%" cho gọn?
A. Vì độ chính xác AI khác nhau hẳn theo công đoạn. AI tham gia bốn nhóm công đoạn: đọc và tóm tắt source cũ (SCAN), sinh tài liệu thiết kế (BD/DD), sinh code, sinh test. Trích xuất tri thức từ source cũ gần như tất định nên chính xác cao; sinh code UI hiện còn yếu theo quan sát của Thiên. [SoT: Vault] kpi-targets.json A3.note "UI gen currently low per Thien". Gộp tất cả vào một số vừa không công bằng (công đoạn mạnh kéo công đoạn yếu lên) vừa không hành động được (không biết phải cải thiện chỗ nào). Do đó đo từng công đoạn trước (nhóm A), rồi mới gộp có trọng số thành headline AI-FPA. [SoT: Vault] nexa-metrics-explained.md §1.1.
Q2. Headline AI-FPA là gì, và cơ chế nào chống "làm đẹp" con số tổng hợp?
A. AI-FPA = trung bình có trọng số của ba tỷ lệ First-Pass Acceptance trên ba công đoạn sản xuất chính: tài liệu (A2), code (A3), test (A4). Công thức AI-FPA = Σ(FPAᵢ × Wᵢ), trọng số đề xuất {A2: 0.3, A3: 0.5, A4: 0.2}, trạng thái provisional. [SoT: Vault] kpi-targets.json headline.weights. Cơ chế chống ảo số là một guard bắt buộc: headline chỉ được công bố khi A3 (Code FPA) đạt mức tối thiểu 50%. Lý do: con số tổng hợp có thể vượt 60% nhờ phần tài liệu hoặc test kéo lên trong khi phần sinh code, đúng chỗ khách nghi ngờ nhất, vẫn dưới chuẩn. [SoT: Vault] kpi-targets.json headline.guard.
Hiện trạng thật: headline = N.A. Hai lý do, không chỉ thiếu dữ liệu: (a) A2/A3/A4 đều chưa có số; (b) trọng số Wᵢ chưa được CTO chốt cơ sở (tính theo "số artifact" và theo "effort-share" cho hai kết quả khác nhau). [SoT: Vault] nexa-metrics-explained.md Phần 2. Guard hiện = N.A vì A3 chưa có số. [SoT: Code] --validate => headline AI_FPA: None guard=N.A.
Sáu tiêu chí 品質基準 do Fabbi đề xuất theo yêu cầu khách (Thiên đã trình). Cột "Mục tiêu" = ngưỡng Fabbi đề xuất, chưa phải ngưỡng khách áp đặt, cần khách duyệt thành ngưỡng nghiệm thu. [SoT: Vault] nexa-metrics-explained.md §⭐⭐.
| # | Tiêu chí | Công thức / cách đo | Hiện trạng thật | Mục tiêu | Đạt? |
|---|---|---|---|---|---|
| Q1 | Tỷ lệ ánh xạ logic cũ to mới | Mẫu số ĐÚNG = tổng logic legacy (FARE detect); @LegacyOrigin chỉ là tracing-helper | Proxy claim-matcher 85-94% (mẫu số = claim UI-presence); số Q1 thật chưa đo (FARE full extraction chưa chạy) | ≥ 70% | 🟡 proxy đạt, số thật chưa đo đúng cách |
| Q2 | Độ chính xác logic code mới | parity test (output Java == VB) + A3 code-FPA | parity 5/5 PASS nhưng chỉ trên 3 logic tất định; A3 toàn diện chưa đo | ≥ 80% | 🟡 tín hiệu tốt scope hẹp, chưa kết luận |
| Q3 | Tỷ lệ giảm công sức/thời gian | effort-log (giờ AI+người ÷ giờ thủ công baseline) | cơ chế đã lập, 0 dòng dữ liệu | ≥ 40% | ⏳ chưa có dữ liệu |
| Q4 | Kiểm tĩnh (Sonar) | SonarQube quality-gate | proxy 4/4 PASS (Spotless, Checkstyle, DDD-audit, SpotBugs 0 bug); Sonar wired chờ server | Pass | 🟡 proxy xanh, chờ server |
| Q5 | Coverage unit-test logic | JaCoCo line coverage | logic = 87.7% (domain 88.9% / app 87.1%); tổng-app 59.9% | ≥ 80% | ✅ ĐẠT trên tầng logic |
| Q6 | Tỷ lệ Pass test case | mvn test PASS/total | 100% (246/246) | 100% | ✅ ĐẠT |
[SoT: Vault] nexa-metrics-explained.md bảng ⭐⭐ + Phần 3.
Q3. Q1 (mapping率) đã đạt 100% chưa? Tôi thấy báo 100% legacy-mapping.
A. Cần phân biệt hai con số tên gần giống. "100% legacy-mapping" (C3) là tracing: mỗi class nghiệp vụ mới truy được về gốc VB legacy qua annotation @LegacyOrigin, đo bằng ArchUnit. Mẫu số là code mới, không phải logic legacy. [SoT: Vault] nexa-metrics-explained.md §Chi tiết Q1.A-B. Hai phản ví dụ phơi bày lỗi nếu lẫn lộn: legacy 100 logic, new chỉ làm 20 logic và cả 20 đều có annotation => annotation báo 100% (ảo), coverage thật chỉ 20%. Do đó Q1 thật phải lấy tổng logic legacy (FARE detect độc lập) làm mẫu số, hiện chưa chạy nên Q1 thật chưa đo được; 85-94% chỉ là proxy claim-matcher. [SoT: Vault] nexa-metrics-explained.md §Chi tiết Q1.C-D.
Bốn nhóm là khung đo nội bộ đầy đủ; sáu tiêu chí khách là tập con. Map: Q1↔C3+C4, Q2↔C6+A3, Q3↔B1, Q4↔C5+SpotBugs, Q5↔C7, Q6↔C8. [SoT: Vault] nexa-metrics-explained.md §1.3.
Q4. Nhóm A đo gì, hiện có số chưa?
A. Bốn metric FPA theo công đoạn, tất cả pending. [SoT: Code] --validate A1-A4 = pending.
| ID | Tên | Công thức | Min/Target | Nguồn chuẩn | Hiện trạng |
|---|---|---|---|---|---|
| A1 | KB extraction accuracy (SCAN) | đúng/sample (n≥50, HITL) | 80/90 | FARE KB sample audit | ⏳ chưa có gather |
| A2 | Docs gen FPA (BD/DD) | min(Completeness%, Accuracy%) v0(AI) vs GT(final), min-rule bảo thủ | 60/70 | MSR-002 tiers | ⏳ chưa lưu bản v0 |
| A3 | Code gen FPA ⭐ | 1 − (LoC người đổi semantic / LoC AI sinh) | 50/60 | git diff ai-gen..tuned | ⏳ chưa bật git-tag (0 cặp tag) |
| A4 | Test-case gen FPA | case dùng được không sửa / tổng; ISTQB mix là cờ PASS/FAIL riêng | 60/70 | MSR-002 ISTQB | ⏳ skill sẵn, chưa chạy |
[SoT: Vault] kpi-targets.json group A. [SoT: Code] --validate => "A3 ai-gen/tuned tag pairs: 0 (none)".
A3 là metric quan trọng nhất vì đúng chỗ khách nghi 40%. Điều kiện đo: từ nay tag commit ai-gen/<CM> (ngay sau AI sinh, trước khi người sửa) và tuned/<CM> (sau review). Màn làm trước khi có tag không truy hồi ngược được, ghi pending, không ước lượng ngược. [SoT: Code] provenance-protocol.md Cơ chế 1.
Q5. Vì sao chưa trả lời được "tiết kiệm bao nhiêu phần trăm"?
A. B1 (effort reduction) = 1 − Σ(giờ AI + giờ người) / Σ(giờ baseline thủ công) per phase, target ≥40% overall và ≥50% BD/DD. Hiện blocked vì effort-log có 0 dòng nên không có mẫu số. [SoT: Code] --validate => "B1 effort-log rows: 0 ... start forward logging (no retro per protocol)". Đây là việc số 1 phải làm ngay: phát template log cho team. Không có mẫu số thì cuối PoC chỉ nói cảm tính, đúng cái khách không muốn nghe. [SoT: Vault] nexa-metrics-explained.md Nhóm B cảnh báo. B4 (quy tiền ¥) phụ thuộc B1 cộng đơn giá giờ công, cả hai chưa có nên chưa ra con số ¥. Đưa con số ¥ trước hai đầu vào này = bịa.
Q6. Nhóm C đã có bằng chứng cứng gì?
A. Đây là nhóm có số thật. Đo trên 04-coding HEAD e1f3654.
| ID | Tên | Hiện trạng | Trạng thái |
|---|---|---|---|
| C2 | UI fidelity vs prototype | 100.0% (json); live re-run lộ chênh lệch, xem caveat | MEASURED (engine) |
| C3 | Legacy mapping integrity (tracing) | 100% (4/4 màn, 154-155 @LegacyOrigin) | MEASURED |
| C4 | Screen audit-breadth | CM06010 96.6 / CM71060 93.5 / CM05110 95.8 / CM30020 90.6 | MEASURED |
| C5 | Code structure DDD | 0 gateable P1, 4/4 gate PASS (2 P1 CM71060 là false-positive engine, đã sửa) | đo lại |
| C6 | 新旧比較 UT (parity cũ/mới) | 5/5 PASS trên enum/mapping tất định, 3 màn; chưa phủ SQL/proc | scope hẹp |
| C7 | Unit-test coverage logic | 87.7% logic-ring | MEASURED (=Q5) |
| C8 | Test-case Pass rate | 100% (246/246) | MEASURED (=Q6) |
| C9 | SpotBugs static-bug | 0 bug | MEASURED |
[SoT: Vault] nexa-metrics-explained.md Nhóm C. [SoT: Code] --validate C2/C3/C4 MEASURED, C5 current=2count.
Cờ tự khai C2 (trung thực): số "100% (4/4 PASS)" lấy từ json đã commit là số engine. Khi khởi động app thật rồi chạy prototype-ui-audit.py live, một số màn lộ chênh lệch: phần lớn "thiếu" là mock-data của prototype không có trong DB live rỗng (data-diff, không phải lỗi UI), nhưng có leak thật (token máy spList_, placeholder FIXME) phải fix. Kết luận: không dùng "C2 = 100%" trần. [SoT: Vault] nexa-metrics-explained.md §C2 caveat.
Q7. Goal 2 trả lời thế nào khi nhóm D còn pending?
A. Nhóm D (D1-D4: issue register, first-time approval, tuning iterations, improvement plan) hiện toàn bộ là leading indicator, đổ đầy theo mốc M1-M4. [SoT: Code] --validate D1-D4 pending. Đừng trả lời Goal 2 bằng bảng D "chưa đo", mà kể năm vấn đề thực đã gặp cộng cách xử lý: (1) sinh code UI còn yếu => tuning prompt/context + mở rộng golden sample; (2) công cụ đo logic đếm sót (báo 57.1% fidelity sai vì chỉ đọc BD) => fix matcher đọc cả DD; (3) CM71060 báo 2 P1 hoá ra false-positive engine => sửa engine + neg-test, code không đổi; (4) chưa có effort-log => phát template ngay; (5) FarPoint Grid không có bản Java 1:1 => thay HTML table, quyết license Phase 2. [SoT: Vault] nexa-metrics-explained.md §Goal 2. Thông điệp: AI không hoàn hảo, ghi lại sòng phẳng chỗ vấp để dự án thật biết trước rủi ro.
Q8. Các ngưỡng 60/70/80/90 lấy từ đâu? Có phải chuẩn ngành không?
A. Thang gốc là benchmark nội bộ MSR-002: Min ≥60% / Target ≥70% / Good ≥80% / Excellent ≥90%, cộng KPI AIDP review-time 2 ngày to 4 giờ và first-approval 40% to 85%. [SoT: Vault] nexa-metrics-explained.md §1.4. Cần nói thẳng: tài liệu gốc QUALITY_MANAGEMENT_GUIDE / AIDP_Enhanced_Review_Process không nằm trong repo PoC này, là tham chiếu second-hand, không phải chuẩn ngành công khai. Đây là lý do các target nhóm A bám quanh 60-70%.
Q9. Bộ chỉ số này so với DORA / SPACE thì sao? SI lớn (NTT/Accenture) review có lọt không?
A. NEXA set ánh xạ mạnh với MSR-002 (thang gốc), một phần với SPACE (phủ tốt Performance + Efficiency qua nhóm C và B), gần như không với DORA. [SoT: Vault] researcher.md §0, §2. DORA đo *hiệu năng giao hàng* (deploy nhanh/ổn), SPACE đo *năng suất kỹ sư*; cả hai không có khái niệm "output cũ == output mới". [SoT: Research] Forsgren et al. 2021; [SoT: Official] dora.dev. Nói rõ điều này tránh hiểu lầm "bộ chỉ số sai": NEXA set thiên về AI-accuracy đúng mục tiêu khách, DORA/SPACE là phần bổ sung Phase 2 cần roadmap. ISTQB xuất hiện ở A4 dưới dạng cờ phân bố test (EP 60-70 / BVA 10-15 / EG 10-20 / DT 5-10), là constraint PASS/FAIL riêng, không cộng vào scalar FPA. [SoT: Vault] kpi-targets.json A4.formula.
Q10. Đo "bản mới làm đúng như bản cũ" dựa trên chuẩn khoa học nào? Dùng cái nào cho OPT?
A. Migration-correctness là một họ chuẩn riêng (gốc từ kiểm thử + refactoring legacy), không phải DORA/SPACE. Khái niệm lõi: migration đúng khi với mọi input hợp lệ x, OLD(x) ≡ NEW(x), trong đó ≡ phải định nghĩa tường minh và thoả reflexive/symmetric/transitive. [SoT: Vault] legacy-new-standards.md §0. Sáu chuẩn, mỗi cái countable:
| # | Chuẩn | Nguồn | ≡ định nghĩa qua | Vai trò cho OPT |
|---|---|---|---|---|
| 1 | Characterization Test | Feathers 2004 | giá trị OLD đã chụp (golden) | lưới an toàn per-màn khi spec cũ mất |
| 2 | Differential Testing | McKeeman 1998 | comparator (OLD==NEW, không cần đúng tuyệt đối) | mạnh nhất cho migration (fuzz/traffic, divergence to 0) |
| 3 | Golden Master / Approval | Falco | normalizer + comparator | output lớn (màn/report cũ to mới) |
| 4 | Parallel Run + Reconciliation | Fowler / Thoughtworks | comparator nghiệp vụ, traffic thật | bằng chứng mạnh nhất, roadmap Phase 2 |
| 5 | ISO/IEC 25010 Functional Suitability | ISO | khớp trong dung sai ε | khung số hiệu quốc tế: Completeness% + Correctness% |
| 6 | Bidirectional Traceability | CMMI REQM SP1.4 | tồn tại ánh xạ 2 chiều | C3 đã có forward; thêm backward bắt code thừa |
[SoT: Vault] legacy-new-standards.md §7 bảng tổng hợp.
Bộ tối thiểu đề xuất cho OPT [Estimation]: (a) lõi định lượng = #2 Differential + #1/#3 Characterization/Golden-master, đây chính là cái C6 新旧比較UT đang gọi tên; (b) khung báo cáo khách = #5 ISO 25010 (Completeness% + Correctness%) cho số hiệu chuẩn quốc tế; (c) chống bỏ-sót/thừa = #6 CMMI bidirectional (đã có nền @LegacyOrigin, thêm backward); (d) roadmap Phase 2 = #4 Parallel Run khi app chạy thật. [SoT: Vault] legacy-new-standards.md §7.
Điểm phải nói thẳng với khách: với UI migration (VB WinForms to Java web khác render), không có "giống hệt từng byte/pixel". Mọi chuẩn nghiêm túc định nghĩa ≡ qua normalizer/dung-sai = "tương đương hành vi nghiệp vụ", không phải equality thô. [SoT: Vault] legacy-new-standards.md §8.
Q11. Làm sao biết phần nào AI sinh, phần nào người gõ tay? Đo A3 (Code-FPA) ra sao?
A. Provenance chia ba lớp: L1 gen-mass (NEXA sinh khung hàng loạt), L2 skill gen+fix (chạy NEXA-skill graft/restructure), L3 manual (dev sửa business logic). Ba lớp chồng lên nhau trên cùng file, chia theo *giai đoạn lịch sử của file*. [SoT: Code] provenance-protocol.md §3 lớp. Cơ chế đếm countable: tag git ba mốc per màn ai-gen/<CM> to skill-gen/<CM> to tuned/<CM>; lớp = git diff --numstat giữa các tag; A3 Code-FPA = 1 − semantic-LoC(ai-gen..tuned)/LoC(ai-gen). [SoT: Code] provenance-protocol.md Cơ chế 1. Baseline tag provenance-baseline tại HEAD e1f3654.
Q12. Vì sao forward-only, không hồi tố? Khách có thể nghi "giấu số cũ".
A. Ngược lại, forward-only chính là để bảo vệ uy tín, không bịa số khách nghi nhất. Provenance không được ghi lúc commit (0 git tag, 0 header @generated); tác giả commit chỉ là proxy yếu (dev có thể chạy AI rồi commit dưới tên mình). [SoT: Code] provenance-protocol.md đầu file; [SoT: Vault] nexa-metrics-explained.md §7c "Giới hạn gốc". Do đó tỷ lệ phần trăm từng lớp không đo hồi tố được, chỉ ước lượng forensic gắn [Estimation]. Câu defensible duy nhất trước CTO: "Khung 4 màn do NEXA sinh hàng loạt một lần (bằng chứng commit 9e08a17: 74 file / 5153 dòng), traceability NEXA phủ 100% file (155 @LegacyOrigin), phần tinh chỉnh logic do dev người làm tiếp. Tỷ lệ phần trăm từng lớp không đo hồi tố được vì provenance chưa ghi lúc commit; bật cơ chế đếm từ màn kế tiếp." [SoT: Vault] nexa-metrics-explained.md §7c. Nếu hồi tố bằng cách đoán số rồi báo "X% do AI sinh", đó đúng là loại con số đẹp không bảo vệ được mà khách sẽ vặn ngay. Forward-only = thà chậm mà chắc.
Q13. Cơ chế nào đảm bảo các con số không bị thổi phồng?
A. Bốn lớp kỷ luật: (1) Guard headline A3 ≥ 50% mới được công bố composite (chống docs-volume thổi headline). [SoT: Vault] kpi-targets.json headline.guard. (2) Một file số liệu duy nhất .nexa/kb/scope-tracker/kpi-targets.json, engine kpi_snapshot.py ghi current+state, người viết không sửa tay số. (3) Lịch sử bất biến kpi-history.jsonl append-only có timestamp. (4) Evidence file đính kèm mỗi số nhóm C trỏ tới file output gốc. [SoT: Vault] nexa-metrics-explained.md Phần 6.
Q14. Có con số nào từng sai, đã tự khai chưa?
A. Có, ba cờ tự khai bắt buộc: (a) 57.1% CM30020 fidelity từng là LỖI matcher (chỉ đọc BD trong khi nội dung thật ở DD), không phải chất lượng code; (b) C4 90.6% vs raw 42.5% chênh nhau do denominator (audit-breadth vs presence thô) chưa minh bạch hoàn toàn, với màn CM30020 chưa trích số logic nào làm chất lượng cuối tới khi matcher fix xong; (c) trọng số Wᵢ chưa CTO-freeze. [SoT: Vault] nexa-metrics-explained.md §C5, §CM30020 block; [SoT: Vault] memory cm30020-split-screen-audit-artifact. Đối sách gỡ nghi ngờ: mời khách hoặc bên thứ ba tự chạy lại một lệnh nhóm C trên một màn và đối chiếu tay; khớp thì tin cả bộ engine. [SoT: Vault] nexa-metrics-explained.md Phần 6 §kiểm định độc lập.
Q15. Review cấp NTT Data / Accenture sẽ đòi thêm chỉ số gì mà hiện chưa có?
A. 18 metric (M1-M18) chia năm nhóm, sắp theo độ-chắc-bị-hỏi. [SoT: Vault] researcher.md §3.
| Nhóm | Metric thiếu | Khung nguồn | Khi đo |
|---|---|---|---|
| Kinh doanh / ROI | M1 ROI%, M2 TCO chi phí AI, M3 Adoption/Utilization rate | business-case SI, SPACE-Activity | khi có B1+B4 |
| Chất lượng giao hàng | M4 Defect Escape Rate, M5 Defect Density, M6 DRE, M7 Change Failure Rate, M8 Test Coverage% | QA ngành + DORA + ISO | M3/M4 (code) |
| Tốc độ giao hàng | M9 Lead Time, M10 Cycle Time, M11 Deployment Frequency | DORA / SPACE | Phase 2 (CI/CD) |
| Con người / áp dụng | M12 Developer Satisfaction, M13 Trust qualitative, M14 Knowledge-transfer | SPACE-Satisfaction/Communication | định kỳ |
| Kỹ thuật bổ trợ | M15 Security/SAST density, M16 Maintainability/tech-debt, M17 Traceability%, M18 Statistical rigor | OWASP/ISO/CMMI | Phase 2 |
[SoT: Vault] researcher.md §3.1-3.5.
Điểm phải phân biệt cho khách migration: M4 Defect Escape Rate ≠ C6 parity. C6 đo "output cùng-input có khớp không"; M4 đo "lỗi lọt qua gate ra giai đoạn sau". SI sẽ tách bạch hai cái. [SoT: Vault] researcher.md §3.2. Shortlist sáu metric nếu chỉ thêm được sáu cho buổi review SI: M1+M2 (ROI/TCO), M4 (defect-escape), M3 (adoption), M8 (test coverage), M12 (dev satisfaction), cộng roadmap DORA (M7/M9/M11) dạng cam kết đo Phase 2. [SoT: Vault] researcher.md §4. Lưu ý trung thực: M1/M2/M3/M5/M6/M8/M10/M14-M18 gắn [SoT: Inference] (suy từ thực hành chuẩn SI, không có văn bản nội bộ NTT/Accenture trong tay); M4/M7/M9/M11 (DORA) và M12/M14 (SPACE) có nguồn khung công khai chắc chắn. [SoT: Vault] researcher.md §6.
| # | Mục cần chốt | Trạng thái hiện tại | Ai chốt |
|---|---|---|---|
| 1 | Trọng số headline Wᵢ (A2/A3/A4) | {0.3, 0.5, 0.2} provisional [Estimation]; engine dùng equal-weights tới khi freeze | CTO (Dzũng) |
| 2 | Baseline source B1 (thủ công) | KMD estimate vs chuẩn JP-SI, chưa chốt nguồn [Estimation] | CTO + khách |
| 3 | Đơn giá giờ công + baseline per-screen (B4) | chưa có => chưa ra con số ¥ | CTO |
| 4 | Ngưỡng B1 target | ≥40% overall, ≥50% BD/DD [Estimation] | CTO |
| 5 | Định nghĩa "người sửa semantic" (A3) | semantic-only đề xuất, chưa cơ giới hoá | CTO |
| 6 | Tần suất snapshot KPI | đề xuất mỗi milestone M1-M4 | CTO |
| 7 | Ngưỡng nghiệm thu chính thức Q1-Q6 | Fabbi đề xuất, chờ khách duyệt | khách OPT |
[SoT: Vault] kpi-targets.json freeze_with_cto; nexa-metrics-explained.md §7.2.
Lưu ý trước buổi trình khách: các số gắn [Estimation] (trọng số headline, baseline B1, day_rate B4, target B1) chưa qua CTO. Cần buổi freeze với CTO trước, nếu không là đang trình số chưa được duyệt. [SoT: Vault] nexa-metrics-explained.md Phần 5 lưu ý.
*Bản machine-readable: .nexa/kb/scope-tracker/kpi-targets.json. Engine đo: .claude/skills/nexa-audit-target/scripts/kpi_snapshot.py (--snapshot/--a3/--final/--validate) + trend_report.py. Trạng thái khi soạn: 4 measured / 13 pending của 17 metric, headline N.A.*
A - Độ chính xác AI
Hiện trạng: ⏳ CHƯA ĐO (mục tiêu: đạt 80%, tốt 90%)
Khi AI (công cụ FARE) đọc code VB cũ rồi bóc ra 'tri thức', nó bóc ĐÚNG được bao nhiêu phần. Cao = AI đọc-hiểu hệ cũ chuẩn, ít phải dò tay.
FARE bóc cụ thể 5 loại từ source VB cũ: (1) danh sách entity - mỗi class/Sub/Function; (2) cạnh gọi nhau - ai gọi ai (call graph); (3) bảng DB được đụng; (4) stored-proc được gọi; (5) ánh xạ màn → module. A1 đo độ đúng của 5 loại mẩu này.
Lấy ngẫu nhiên ít nhất 50 mẩu trong số trên, một người ngồi đối chiếu tay với code cũ. Đúng 1 điểm, sai 0, mơ hồ 0.5. Kết quả = tổng điểm / số mẩu.
CHƯA ĐO. FARE đã bóc graph cho 4 màn nhưng chưa lấy mẫu ≥50 để chấm đúng/sai. Chưa có con số nào.
Minh hoạ CÁCH TÍNH (KHÔNG phải số đo thật): nếu lấy 50 mẩu mà 45 đúng, 4 sai, 1 mơ hồ => (45+0.5)/50 = 91%.
Là đầu vào của Q1: muốn biết 'logic cũ đã làm lại đủ chưa' phải có FARE bóc ĐỦ tổng logic cũ trước. A1 thấp = mẫu số Q1 không đáng tin.
Đối chiếu tay mẫu tri thức FARE bóc ra. [Estimation].
A - Độ chính xác AI
Hiện trạng: ⏳ CHƯA ĐO (chưa lưu bản nháp để so; mục tiêu 60%, tốt 70%)
AI viết bản nháp tài liệu thiết kế (BD/DD), người sửa thành bản cuối. Đo phần nháp 'sống sót', tức không bị sửa.
Đếm theo từng MỤC trong tài liệu: mỗi luồng xử lý, mỗi bảng, mỗi quy tắc validate, mỗi thông báo là 1 mục. So từng mục bản nháp AI với bản cuối.
Chấm 2 thứ rồi lấy số NHỎ HƠN cho an toàn: 'đủ ý' (có thiếu mục nào không) và 'đúng' (mục viết ra có chính xác không).
CHƯA ĐO - chưa lưu bản nháp v0 của AI để so với bản cuối. Chưa có con số.
Minh hoạ CÁCH TÍNH (chưa phải số thật): tài liệu 80 mục, bản cuối giữ 70 mục đúng (đúng 87.5%), đủ 76/80 mục (đủ ý 95%) => lấy số nhỏ = 87.5%.
Trọng số 0.3 (30%) trong con số tổng AI-FPA.
Cách so MSR-002 (chuẩn nội bộ), mốc 60/70/80/90.
A - Độ chính xác AI
Hiện trạng: ⏳ CHƯA ĐO (0 cặp mốc git; mục tiêu 50%, tốt 60%)
Code AI sinh ra giữ lại được bao nhiêu sau khi dev sửa. Đây là con số khách nghi nhất (họ tin AI chỉ làm đúng ~40% code). 70% = dev chỉ phải sửa 30% số dòng.
Đếm số dòng code (LoC) ở 2 mốc git cho từng màn: lúc AI vừa sinh ('ai-gen') và sau khi dev sửa xong ('tuned'). Chỉ tính dòng sửa vì logic sai, bỏ dòng sửa cho đẹp (đổi tên biến, căn lề).
git diff 2 mốc => 1 − (số dòng sửa logic / số dòng AI sinh).
CHƯA ĐO - hiện 0 cặp mốc ai-gen/tuned (xác nhận cả trên remote). Code 4 màn làm TRƯỚC khi đặt mốc nên KHÔNG truy hồi ngược được => không bịa số. Phải bật mốc từ màn kế tiếp.
Minh hoạ CÁCH TÍNH (chưa phải số thật): AI sinh 100 dòng, dev sửa 30 dòng logic => 1 − 30/100 = 70%.
Trọng số 0.5 (50%) - CAO NHẤT trong AI-FPA, và là chốt chặn: con số tổng chỉ được công bố khi A3 ≥ 50%. Đúng chỗ khách nghi nhất.
provenance-protocol: đánh mốc git ai-gen / skill-gen / tuned.
↔ Là cốt lõi của tiêu chí khách Q2
A - Độ chính xác AI
Hiện trạng: ⏳ CHƯA ĐO (skill sẵn, chưa chạy; mục tiêu 60%, tốt 70%)
AI sinh test-case xong, bao nhiêu cái dùng được luôn mà không phải sửa.
Đếm từng test-case AI sinh: dùng được ngay hay phải sửa. Tách riêng việc test có đủ các kiểu theo chuẩn ISTQB (giá trị biên, phân vùng, đoán lỗi, bảng quyết định).
Số case dùng được không sửa / tổng case. (Phân bố ISTQB là điều kiện đạt/không riêng, không cộng vào con số này.)
CHƯA ĐO - skill sinh test chưa chạy đo. Chưa có con số.
Minh hoạ CÁCH TÍNH (chưa phải số thật): AI sinh 40 case, 28 dùng được không sửa => 70%.
Trọng số 0.2 (20%) trong AI-FPA.
Mốc ISTQB của chuẩn MSR-002.
B - Giảm công sức
Hiện trạng: ⛔ BLOCKED (effort-log 0 dòng; mục tiêu ≥40%, riêng BD/DD ≥50%)
Dùng AI thì tốn ít công hơn làm tay bao nhiêu phần, tính riêng theo từng giai đoạn (thiết kế, code, test).
Ghi giờ theo từng task vào file effort-log.csv: phase / artifact / giờ AI chạy / giờ người sửa / số vòng review.
1 − (giờ làm có AI / giờ làm tay thuần). 'Giờ có AI' = giờ AI + giờ người sửa. Số 'giờ làm tay' (mốc so) phải chốt với sếp kỹ thuật.
BLOCKED - effort-log.csv hiện 0 dòng, không có mẫu số 'giờ làm tay' => chưa tính được gì. Đây là việc số 1 phải bật ngay.
Minh hoạ CÁCH TÍNH (chưa phải số thật): BD làm tay 80h, có AI 36h (AI 6h + người 30h) => 1 − 36/80 = 55%.
Là tiêu chí khách Q3 (giảm công sức) + đầu vào quy ra tiền B4. Không log ngay = cuối PoC không trả lời được câu khách hỏi.
effort-log.csv + mốc tay chốt với CTO.
↔ Là tiêu chí khách Q3
B - Giảm công sức
Hiện trạng: ⏳ CHƯA ĐO (mốc cũ 16h, mục tiêu còn 4h)
Review xong 1 tài liệu mất bao nhiêu giờ, khi đã có AI soi lỗi trước 2 lượt.
Bấm giờ mở/đóng review trên ticket Backlog, ghi cho từng tài liệu.
Giờ đóng − giờ mở. Mốc gốc 16h = 2 ngày công (8h/ngày).
CHƯA ĐO - chưa ghi timestamp review.
Minh hoạ (chưa phải số thật): trước 16h, có AI còn 3.5h => qua mốc 4h.
Bổ trợ B1 (đo thời gian trôi, không phải công sức).
Chuẩn MSR-002 AIDP: kéo từ 2 ngày xuống 4 giờ.
B - Giảm công sức
Hiện trạng: ⏳ chỉ để báo cáo (PoC 4 màn quá ít để chốt mục tiêu)
Năng suất: cứ 1 tuần công của 1 người thì xong được mấy màn.
Số màn hoàn tất + số tuần-người bỏ ra, lấy từ sổ tiến độ + effort-log.
Số màn xong / số tuần-người.
CHƯA ĐO - phụ thuộc effort-log (đang trống). PoC 4 màn quá nhỏ để đặt mục tiêu cứng.
Minh hoạ (chưa phải số thật): 4 màn / 2 tuần-người = 2 màn/tuần-người.
Chỉ để báo cáo xu hướng, không phải con số nghiệm thu.
Sổ scope-tracker + effort-log.
B - Giảm công sức
Hiện trạng: ⛔ BLOCKED (thiếu B1 + đơn giá giờ)
Đổi số giờ tiết kiệm (từ B1) ra TIỀN, rồi ước cho cả dự án thật 256 màn. Câu sếp tài chính hỏi đầu tiên.
Cần 3 đầu vào: B1% (chưa có), giờ-gốc-mỗi-màn (chưa chốt), đơn giá theo giờ (chưa chốt).
giờ tiết kiệm = B1% × giờ-gốc-mỗi-màn; tiền = giờ tiết kiệm × đơn giá giờ; nhân 256 màn.
BLOCKED - thiếu cả B1 lẫn đơn giá giờ. Đưa con số tiền nào lúc này cũng là bịa.
Chưa có ví dụ số được vì thiếu đầu vào.
Câu hỏi của sếp tài chính. Có B1 + đơn giá là ra ngay con số ¥ per-màn và ngoại suy 256 màn.
[Estimation] - chốt đơn giá giờ + giờ-gốc-mỗi-màn với CTO.
C - Chất lượng đầu ra
Hiện trạng: ⏳ vận hành; RT4 đo thật lộ 95.1% dead nav (P1 hệ thống)
Trước khi cho 1 giai đoạn đi tiếp, có loạt 'cổng kiểm chất lượng' G1-G11 phải qua hết. Đo % cổng đã qua.
11 cổng G1-G11, mỗi lần chuyển phase phải qua các cổng tương ứng.
Số cổng qua / tổng cổng, đọc từ log lệnh nexa gate run.
Đang vận hành theo từng phase, chưa chốt số tổng hợp cuối. ĐO THẬT 260624: cổng RT4 lộ 1 P1 HỆ THỐNG - 78/82 màn có route RỖNG = 95.1% link điều hướng chết (dead nav link). Đây là lỗi systemic phải fix, không giấu. Evidence: plans/260624-1838-kpi-measure-surfaces/result-C1.json.
Giai đoạn BD có 4 cổng, qua cả 4 mới được sang DD => 100%.
Cơ chế chặn: không cho qua phase khi cổng còn đỏ (vd C5 còn P1 thì gate FAIL). RT4 95.1% dead nav = cổng đang BÁO ĐỎ đúng chức năng, phải sửa route trước nghiệm thu.
Log nexa gate run.
C - Chất lượng đầu ra
Hiện trạng: ✅ 100% (file); chạy app thật 2/4 đạt, có chữ rác (mục tiêu ≥95%)
Màn mới có giống bản thiết kế mẫu (prototype) không: đủ nút, đủ ô nhập, không thiếu không thừa.
4 màn: CM06010, CM05110, CM71060, CM30020. Mỗi màn kiểm từng thành phần UI (nút / ô / bảng) so với prototype.
Số thành phần khớp / số thành phần kiểm, chạy trên app THẬT (cổng :8080) bằng prototype-ui-audit.py.
Theo file json: 100%. Chạy LẠI trên app thật (e1f3654): CM71060 100%, CM05110 100%, CM06010 81%, CM30020 83.3% => 2/4 đạt. Phần thiếu phần lớn do data mẫu prototype không có trong DB rỗng; NHƯNG có leak THẬT: chữ máy 'spList_' (CM06010), 'FIXME' (CM30020) lọt ra UI - phải xoá. Evidence: 04-coding/report/prototype-ui-audit.json.
Màn CM71060: kiểm 71 thành phần, khớp cả 71 => 100% (số thật).
Tiêu chí chất lượng UI. Số json 100% là STALE (cũ) - đừng dùng trần, phải nói rõ live 2/4 + leak.
prototype-ui-audit.py.
C - Chất lượng đầu ra
Hiện trạng: ✅ 100% (4/4 màn, 154 nhãn)
Mỗi đoạn code mới có dán 'nhãn' chỉ về dòng VB cũ mà nó thay không. Đây là TRUY NGUỒN, KHÔNG phải 'đã làm đủ logic cũ chưa' - đừng nhầm.
4 màn, tổng 154 nhãn @LegacyOrigin. Mỗi class nghiệp vụ 1 nhãn ghi file + dòng VB gốc (+ stored-proc nếu có).
Test tự động ArchUnit bắt mọi class nghiệp vụ phải có nhãn. Số màn qua test / tổng màn.
100% (4/4 màn qua test). Nhãn thật: Cm06010UnlockResult → FrmCM06010.vb:L62; Cm71060ProcedureGateway → FrmCM71060.vb:L936 + 3 stored-proc (CM71060_INS1/INS2/UPD). Evidence: surefire LegacyOriginMappingTest.
@LegacyOrigin(source="FrmCM06010.vb:L62") = 'tôi thay cho dòng 62 file VB cũ'.
Là điều kiện CẦN (truy nguồn được), KHÔNG phải đủ. 100% nhãn KHÔNG bằng 'phủ 100% logic cũ' - mẫu số là code mới, không phải logic cũ.
Test ArchUnit + script legacy-map-check.py.
↔ Là một nửa của tiêu chí khách Q1
C - Chất lượng đầu ra
Hiện trạng: ✅ 90.6-96.6% (SCOPED; CM30020 raw ~41.5%); presence không phải fidelity
Công cụ tự động soi được bao nhiêu LOẠI thông tin trong màn cũ (nút, bảng, thông báo, quy tắc). Đo độ RỘNG audit, KHÔNG phải 'tài liệu mới có đủ chưa'.
4 màn, số mẩu trích được / số khớp: CM06010 29/28, CM05110 71/68, CM71060 93/87, CM30020 183 mẩu.
Chỉ số coverage_pct của screen-audit-check.py. Mẫu số = số loại thông tin máy trích ra được.
CM06010 96.6%, CM05110 95.8%, CM71060 93.5%, CM30020 90.6%. LƯU Ý 90.6% là số SCOPED = khớp 76 / trong-scope 85 (scope = main + Netflix). Tính trên TOÀN BỘ surface legacy thì RAW = 76/183 ≈ 41.5%. Phải ghi CẢ HAI số, đừng để 90.6% trông như full coverage. Evidence: plans/260624-1838-kpi-measure-surfaces/result-*.json.
CM06010: 29 mẩu trích, 28 khớp => 96.6% (số thật).
Đo độ rộng audit (là một nửa của Q1). 2 caveat phải nói: (1) coverage = % LOẠI claim CÓ MẶT (presence), KHÔNG phải độ đúng hành vi (behaviour fidelity); (2) 90.6% là scoped (76/85), không phải full surface (76/183 ≈ 41.5%). Máy bóc mẩu theo cái HIỆN trên màn, chưa bằng toàn bộ logic ngầm.
screen-audit-check.py.
↔ Là một nửa của tiêu chí khách Q1
C - Chất lượng đầu ra
Hiện trạng: ✅ 0 lỗi nặng còn mở (4/4 màn qua cổng)
Code có đặt đúng chỗ chưa: logic nghiệp vụ phải ở tầng 'domain', không nhét vào controller hay tầng truy DB (nguyên tắc DDD). Đếm lỗi nặng (P1) còn mở.
4 màn, đếm finding P1 (logic đặt sai tầng) từ công cụ audit.
code-audit-check.py đếm lỗi P1. P1 = phải sửa trước bàn giao (chưa tới mức sập hệ thống).
0 lỗi gateable trên 4 màn. CM05110: 2 P1 cũ (S12/S15 rò rỉ kiểu persistence) ĐÃ FIX về 0. CM71060: 2 P1 (S13/S14) điều tra ra là CÔNG CỤ báo nhầm (adapter để ở thư mục riêng máy không thấy) => sửa công cụ + test chứng minh vẫn bắt lỗi thật, code app KHÔNG đổi. Evidence: code-audit-check.py.
CM71060 S13: công cụ chỉ quét thư mục infrastructure/persistence nên không thấy adapter đặt ở excel/, file/, procedure/ => báo nhầm 'thiếu impl'.
Cổng G yêu cầu 0 P1 mới qua. Cùng loại với sự cố 57.1% CM30020: lỗi ĐO, không phải lỗi code.
code-audit-check.py + test ArchUnit.
↔ Là một phần tiêu chí khách Q4
C - Chất lượng đầu ra
Hiện trạng: ⏳ 5/5 mức VO/field; screen-parity 0/0 (mục tiêu ≥95%)
Cho cùng input chạy qua màn cũ và màn mới, kết quả có GIỐNG nhau không. Vì cả dự án là 'bê màn cũ sang công nghệ mới giữ nguyên cách chạy', đây là bằng chứng nghiệm thu quan trọng nhất.
3 test so cũ-mới, golden lấy verbatim từ source VB: RegionComparisonTest (CM71060, golden FrmCM71060.vb:L821); ReceptionStatusComparisonTest (CM06010, golden basCM06_Common.vb:L60-66); ContactStatusComparisonTest (CM05110, golden FrmCM05110.vb:L583).
Chụp kết quả bản cũ làm 'đáp án mẫu' (golden-master), test bắt bản mới ra đúng. ./mvnw test -Dtest=*ComparisonTest.
5/5 PASS nhưng 100% này CHỈ ở mức VO/field (3 VO, 3 màn CM05110/CM06010/CM71060, mức field/enum). Parity mức MÀN (screen-level render) = 0/0 - CHƯA tồn tại golden fixture cho màn nào. CHƯA phủ SQL / stored-proc / validation. Evidence: plans/260624-1838-kpi-measure-surfaces/result-C6.json.
RegionComparisonTest: đáp án mẫu lấy từ FrmCM71060.vb:L821; bản mới ra đúng => PASS (số thật, mức field).
Bằng chứng nghiệm thu SỐ 1 của migration (mới==cũ). Caveat phải nói thẳng với khách: khách đòi parity ≥3 MÀN; hiện mới đạt mức FIELD trên 3 màn, KHÔNG phải full-screen render => KHÔNG được trình 100% như screen-parity. Việc còn lại = dựng golden fixture mức màn + phủ SQL/proc.
Bộ test *ComparisonTest (golden-master).
↔ Là cốt lõi của tiêu chí khách Q2
C - Chất lượng đầu ra
Hiện trạng: ✅ logic 87.7% (mục tiêu ≥80%)
Khi chạy test, code được test 'chạm tới' bao nhiêu % số dòng (coverage). Ở đây tính trên tầng logic (domain + application).
117 class, đo coverage 2 tầng logic: domain + application (không tính hạ tầng/IO).
JaCoCo đếm: dòng được chạm / (dòng chạm + dòng bỏ sót).
domain 88.9%, application 87.1% => tầng logic 87.7% (đạt ≥80). Tính cả app chỉ 59.9% vì hạ tầng/IO ít unit-test - bình thường. Evidence: target/site/jacoco/jacoco.csv.
(88.9 + 87.1) gộp theo số dòng => logic-ring 87.7% (số thật).
= tiêu chí khách Q5. Đã qua ngưỡng ≥80 trên tầng logic (đúng cái khách yêu cầu 'coverage LOGIC').
Công cụ JaCoCo.
↔ Là tiêu chí khách Q5
C - Chất lượng đầu ra
Hiện trạng: ✅ 100% (246/246)
Chạy hết bộ test thì bao nhiêu % PASS (không fail, không lỗi).
Toàn bộ test-suite hiện có: 246 case.
(số chạy − fail − lỗi) / số chạy, bằng ./mvnw test.
246 chạy, 0 fail, 0 lỗi => 100%. Trước đó 5 test config đỏ; sau khi khôi phục file config 380 khoá (từ legacy Commufa.config) thì xanh hết. Evidence: surefire reports.
246/246 PASS = 100% (số thật).
= tiêu chí khách Q6. Đã đạt 100%.
Báo cáo surefire của mvn test.
↔ Là tiêu chí khách Q6
C - Chất lượng đầu ra
Hiện trạng: ✅ 0 bug (đang thay tạm cho Sonar)
Công cụ SpotBugs quét code (không chạy app) tìm bug kiểu null, rò rỉ dữ liệu, đếm bug còn lại. Thay tạm phần bắt-bug của Sonar khi chưa có server.
Quét toàn repo, đếm bug từ mức Low trở lên.
./mvnw spotbugs:check.
0 bug. CM71060 ban đầu 16 bug => fix THẬT phần rò rỉ dữ liệu bằng List.copyOf + 1 null-check; phần báo nhầm (Spring tự quản đối tượng + cleanup-rethrow) thì tắt CÓ ghi chú lý do trong file loại trừ - không nới bừa. Evidence: spotbugs:check BUILD SUCCESS.
16 bug → 0: vd EI_EXPOSE (trả thẳng list nội bộ) sửa bằng List.copyOf (copy phòng thủ).
Thay tạm phần bug-detection của Sonar (tiêu chí Q4) tới khi có server Sonar.
Công cụ SpotBugs.
↔ Là một phần tiêu chí khách Q4
D - Vấn đề & cải thiện
Hiện trạng: ⏳ vận hành theo Backlog (mục tiêu 100%)
Mỗi lỗi/issue do AI gây ra có ghi đủ NGUYÊN NHÂN và CÁCH SỬA không, để sau dùng AI tốt hơn.
Mỗi ticket Backlog bắt buộc điền 2 field: root-cause + solution.
Số issue ghi đủ / tổng issue.
CHƯA tổng hợp số - đang vận hành theo Backlog rules. (Riêng cổng RT4 đo thật 260624 đã lộ 1 P1 hệ thống, xem chi tiết ở C1.)
5 issue AI gặp, cả 5 ghi đủ => 100% (minh hoạ).
Trả lời câu khách Goal-2 (dùng AI vấp gì + xử lý sao). 8 vấn đề thực đã ghi trong Q&A phần B.
Ticket Backlog.
D - Vấn đề & cải thiện
Hiện trạng: ⏳ CHƯA ĐO (mốc cũ 40%, mục tiêu 70%)
Tài liệu/đoạn việc được DUYỆT NGAY ở vòng review đầu (không phải làm lại) chiếm bao nhiêu phần.
Đếm từ log review: số việc duyệt vòng đầu / tổng việc.
Số duyệt vòng đầu / tổng.
CHƯA ĐO - chỉ số dẫn hướng, đổ đầy theo mốc M1-M4.
Minh hoạ (chưa phải số thật): 10 tài liệu, 7 duyệt ngay => 70% (mục tiêu kéo 40% lên 85%).
Đo mức 'AI làm tốt dần' theo thời gian.
Chuẩn MSR-002 AIDP.
D - Vấn đề & cải thiện
Hiện trạng: ⏳ CHƯA ĐO (mục tiêu ≤3 vòng)
Trung bình phải review đi review lại mấy vòng thì 1 việc mới được duyệt. Càng ít càng tốt.
Đếm số vòng review từng artifact tới khi duyệt, lấy trung bình.
Trung bình số vòng review tới khi duyệt.
CHƯA ĐO.
Minh hoạ (chưa phải số thật): duyệt sau 2 vòng => đạt mốc ≤3.
Bổ trợ D2.
[Estimation] - quy ước nội bộ (tối đa 3 vòng).
D - Vấn đề & cải thiện
Hiện trạng: ⏳ chưa tới kỳ (làm cuối PoC, mục tiêu 100%)
Các vấn đề gặp khi làm PoC có được gom thành BÀI HỌC + KẾ HOẠCH PHÒNG cho dự án thật không.
Số vấn đề được viết thành bài học + kế hoạch / tổng vấn đề, trong báo cáo cuối PoC.
Tỉ lệ trên.
CHƯA tới kỳ (làm ở báo cáo cuối PoC). Hiện đã có 8 vấn đề thực ghi nhận trong Q&A phần B.
8 vấn đề PoC => cả 8 viết thành bài học + cách phòng = 100% (mục tiêu).
Đây là giá trị PoC khách muốn nhất (biết trước rủi ro AI cho dự án thật).
Báo cáo cuối PoC.
Tiêu chí khách
Hiện trạng: 🟡 số tạm 85-94%, số THẬT chưa đo (mục tiêu ≥70%)
Logic hệ cũ đã được làm lại ở hệ mới bao nhiêu phần. Mẫu số ĐÚNG = 'tổng logic hệ cũ', KHÔNG phải đếm nhãn trên code mới (đếm nhãn ra số ảo).
Tử số = logic cũ đã làm lại; mẫu số = tổng logic cũ (cần FARE bóc đủ trước). Hiện chỉ có proxy từ C4 (85-94%) với mẫu số CHƯA đủ.
Logic cũ đã làm / tổng logic cũ. Cần FARE bóc đủ tổng logic cũ - chưa chạy.
Số THẬT CHƯA ĐO (FARE chưa bóc đủ). Số tạm 85-94% là proxy claim-matcher (C4), mẫu số chưa = 100% logic cũ nên CHƯA được báo là Q1 thật.
Cẩn thận số ảo: cũ 100 logic, mới làm 20 và cả 20 đều có nhãn => khoe '100%' nhưng thật chỉ 20/100 = 20%.
Tiêu chí khách quan trọng. ĐỪNG dùng tracing C3 100% thay cho Q1 - hai cái khác nhau.
Cần chạy FARE bóc đủ logic cũ (chưa làm).
↔ Đo bằng: C3 (truy nguồn) + C4 (độ rộng)
Tiêu chí khách
Hiện trạng: 🟡 5/5 đúng nhưng hẹp, A3 chưa đo (mục tiêu ≥80%)
Logic code mới sinh có chạy ra kết quả ĐÚNG NHƯ hệ cũ không.
Đo bằng C6 (test so cũ-mới, 5/5 trên 3 màn enum/mapping) + A3 (tỉ lệ code AI giữ lại, chưa đo).
Kết hợp C6 + A3.
C6 5/5 PASS nhưng phạm vi hẹp (giá trị cố định); A3 toàn diện chưa đo => CHƯA kết luận chắc.
5/5 comparison-test PASS (số thật, nhưng hẹp).
Tiêu chí nghiệm thu cốt lõi của migration.
C6 + A3.
↔ Đo bằng: C6 + A3
Tiêu chí khách
Hiện trạng: ⏳ CHƯA ĐO (effort-log trống; mục tiêu ≥40%)
Dùng AI giảm được bao nhiêu phần công sức và thời gian.
Đo qua B1 (bảng ghi giờ). Cơ chế sẵn, dữ liệu trống.
Xem B1.
CHƯA ĐO - effort-log 0 dòng. Không log ngay = cuối PoC không trả lời được.
Minh hoạ (chưa phải số thật): BD 80h tay => 36h có AI = 55%.
Một trong 2 câu chính khách hỏi (Goal-1).
B1 effort-log.
↔ Đo bằng: B1
Tiêu chí khách
Hiện trạng: 🟡 4 công cụ tạm xanh, chờ server Sonar
Code qua kiểm tĩnh (Sonar quét lỗi không cần chạy app) có sạch không.
Tạm thời thay Sonar bằng 4 công cụ: Spotless + Checkstyle + kiểm kiến trúc DDD (C5) + SpotBugs (C9).
Chạy SonarQube (cần server + token); hiện dùng 4 proxy.
4/4 proxy xanh, 0 bug (SpotBugs). Sonar tổng hợp chờ được cấp server + token.
Spotless ✅ Checkstyle ✅ DDD ✅ SpotBugs 0 bug ✅ (số thật).
Một trong 6 tiêu chí khách. Đạt proxy nhưng chưa chạy Sonar đầy đủ.
SonarQube + 4 proxy (C5/C9).
↔ Đo bằng: C5 + C9
Tiêu chí khách
Hiện trạng: ✅ 87.7% (mục tiêu ≥80%)
Test chạm tới bao nhiêu % code ở tầng logic.
Đo bằng C7 (JaCoCo) trên tầng domain + application.
Xem C7.
logic 87.7% (domain 88.9% / app 87.1%) - đã qua mốc ≥80. Evidence: jacoco.csv.
87.7% (số thật).
Tiêu chí khách đã ĐẠT.
C7 JaCoCo.
↔ Đo bằng: C7
Tiêu chí khách
Hiện trạng: ✅ 100% (246/246)
Chạy bộ test thì bao nhiêu % PASS.
Đo bằng C8 (mvn test) trên 246 case.
Xem C8.
246/246 = 100% (số thật). Evidence: surefire.
246/246 => 100%.
Tiêu chí khách đã ĐẠT.
C8.
↔ Đo bằng: C8