Blueprint Pengembangan mx-core-metric – KPI Planning, Recording & Forecasting Platform

Blueprint Pengembangan mx-core-metric – KPI Planning, Recording & Forecasting Platform

• 1. BRS - Business Requirement Specification
• 📘 2. SRS – Software Requirement Specification
  • 📌 1. Tujuan Dokumen
  • 📦 2. Ruang Lingkup Sistem
  • 📚 3. Definisi dan Akronim
  • 📈 4. Deskripsi Umum Sistem
  • ⚙️ 5. Fungsi Sistem (Functional Requirements Overview)
  • 🔐 6. Non-Functional Requirements (NFR)
  • ⛔ 7. Batasan Sistem
  • 📌 1. Use-Case List
  • 📑 2. Use-Case Detail (Narratif)
  • 📌 Traceability Matrix
  • ✅ 🔼 Prioritas Pengembangan (MoSCoW)
• 🎯 3. System Design
  • 🔷 3.1. High-Level Design (HLD) → kita bahas sekarang
• 🎯 4. Implementation (Coding)
  • 1️⃣ Setup Repositori (Git)
  • 2️⃣ Coding by Module/Sprint
  • ✅ 3️⃣ Kode Mengacu pada LLD
  • 🗂️ 6. Modularisasi File Sesuai Struktur HLD & LLD
  • ✅ 4️⃣ Versioning dan Dokumentasi
  • ✅ 5️⃣ Code Review & Integration Checklist
  • ✅ 6️⃣ Output: Source Code Versi Alpha
  • 🧠 Keterkaitan dengan SRS, HLD, dan LLD
• 📘 **5 Testing **
  • ✅ 1. Unit Test
  • ✅ 2. Integration Test
  • ✅ 3. System Test
  • ✅ 4. User Acceptance Test (UAT)
  • 🧠 Korelasi dengan SRS & UC
  • 📝 5️⃣ Test Plan
  • ✅ 6️⃣ Test Case
  • 🐞 7️⃣ Bug Log & Traceability Matrix
  • 🧩 8️⃣ Release Candidate (RC) Definition
  • 📤 Output Tahap Testing
  • 🧠 Keterkaitan dengan Tahap Sebelumnya
• 📘 6 Deployment – mx-core-metric
  • ✅ 1. Build & CI/CD Pipeline
  • ✅ 2. Environment Setup
    • Variabel Lingkungan (.env)
  • ✅ 3. Backup & Rollback Plan
  • ✅ 4. Dokumen Release Notes
  • ✅ 5. Deployment Log
• 📘 7 Maintenance & Support – mx-core-metric
  • ✅ 1. Monitoring Performance
  • ✅ 2. Patch & Bug Fix
  • ✅ 3. User Feedback Loop
  • ✅ 4. Model Retraining (Jika Menggunakan AI)
  • ✅ 5. Feature Improvement Roadmap
  • ✅ Output: SLA & KPI Pemeliharaan

1. BRS - Business Requirement Specification

• 📌 Latar Belakang Masalah

Dalam operasional industri berskala besar, pemantauan performa lintas departemen secara real-time menjadi tantangan besar. Selama ini:

• Perencanaan KPI dilakukan secara manual dan tersebar di berbagai format (Excel, form offline).
• Tidak ada sistem terpadu yang mengaitkan target KPI dengan aktual capaian serta dampak gangguan operasional.
• Sulit melakukan monitoring berkala (mingguan/bulanan), apalagi memprediksi capaian akhir tahun.
• Forecasting dilakukan secara manual atau tidak akurat, mengandalkan penilaian subjektif.
• Belum ada integrasi dengan data sensor/IoT untuk otomatisasi pencatatan aktual.

• 🎯 Visi dan Tujuan Bisnis

Visi: Membangun sistem KPI terpadu yang mampu mencatat, mengelola, dan memprediksi performa operasional lintas departemen secara otomatis, fleksibel, dan dapat diintegrasikan dengan sistem sensor/IoT.

Tujuan:

• Menyediakan platform digital untuk perencanaan dan pemantauan KPI numerik/non-numerik secara multi-level (tahunan → harian).
• Menghubungkan aktual capaian dengan gangguan operasional yang terjadi.
• Menyediakan fitur prediksi capaian akhir tahun menggunakan metode manual dan otomatis.
• Menyajikan dashboard interaktif yang membantu manajemen mengambil keputusan berbasis data real-time.
• Mempersiapkan sistem untuk integrasi IoT & otomatisasi data (sensor → MQTT → API).

• 👥 Stakeholders dan Peran

• 🧭 Kebutuhan Bisnis Tingkat Tinggi

1. Sistem mampu mengelola target KPI tahunan dan breakdown periodik (bulanan/mingguan/harian).
2. Sistem mendukung input aktual capaian KPI dan gangguan (disturbance) secara manual maupun otomatis.
3. Sistem menyediakan fitur prediksi (forecast) capaian akhir tahun berdasarkan data historis.
4. Sistem menyediakan dashboard untuk memantau KPI, deviasi, dan dampak gangguan.
5. Sistem memungkinkan integrasi dengan sensor eksternal (via MQTT) untuk pencatatan otomatis.

• 🏁 Kriteria Keberhasilan Proyek

• 🧱 Batasan dan Asumsi

• 📚 Referensi Pendukung

• Dokumen ERD & Struktur Data mx-core-metric

• Studi kasus penggunaan KPI di Maintenance, Produksi, dan K3

• Rencana strategis korporat terkait digitalisasi performa dan dashboardisasi

• Standar ISO 22400 (Key Performance Indicators for Manufacturing Operations)

📘 2. SRS – Software Requirement Specification

📌 1. Tujuan Dokumen

Dokumen ini menjabarkan kebutuhan teknis sistem mx-core-metric yang akan dikembangkan. Dokumen ini menjadi rujukan utama bagi tim teknis (developer, QA, devops) dalam proses desain, implementasi, dan pengujian.

📦 2. Ruang Lingkup Sistem

mx-core-metric adalah plugin dalam monorepo mx-core yang berfungsi sebagai platform pengelolaan Key Performance Indicator (KPI) lintas departemen dan unit operasional. Fitur utama sistem ini mencakup:

• Perencanaan KPI tahunan dan breakdown ke target periodik
• Input dan pencatatan capaian aktual KPI
• Pencatatan gangguan operasional (disturbance)
• Forecasting capaian KPI akhir tahun
• Dashboard performa & insight gangguan
• Dukungan integrasi sensor melalui MQTT

📚 3. Definisi dan Akronim

📈 4. Deskripsi Umum Sistem

• 🧭 Alur Sistem:

1. Perencanaan KPI: Ditentukan setahun sekali, terdiri dari target tahunan per departemen/unit.
2. Breakdown Target: Target tahunan dipecah ke periode lebih kecil (bulan, minggu, hari).
3. Input Capaian Aktual: User atau sistem mencatat capaian aktual pada periode berjalan.
4. Gangguan Operasional: Dicatat sebagai disturbance, bisa dihubungkan ke KPI tertentu.
5. Forecast Otomatis: Sistem menghitung estimasi capaian akhir tahun secara otomatis.
6. Dashboard Monitoring: Menyediakan visualisasi KPI, forecast, deviasi, dan insight gangguan.

⚙️ 5. Fungsi Sistem (Functional Requirements Overview)

Berikut daftar kebutuhan fungsional sistem mx-core-metric:

🔐 6. Non-Functional Requirements (NFR)

⛔ 7. Batasan Sistem

• ✅ Ringkasan Output Tahap Ini

• Tujuan dan ruang lingkup sistem terdefinisi
• Kebutuhan fungsional (FR-01 s.d FR-12) terdokumentasi
• Kebutuhan non-fungsional (availability, security, performance, dll)
• Batasan sistem dijelaskan agar ekspektasi terukur

📌 1. Use-Case List

📑 2. Use-Case Detail (Narratif)

Berikut beberapa use-case utama yang mewakili seluruh FR dan NFR:

• 🟦 UC-001 — Manajemen Master KPI

• 🟨 UC-003 — Breakdown Target Periodik

• 🟩 UC-004 — Input Capaian Aktual KPI (Manual & Sensor)

• 🟥 UC-007 — Forecast Capaian Otomatis

• 🟪 UC-008 — Visualisasi Dashboard KPI & Gangguan

• 🟨 UC-009 — Manajemen Role & Hak Akses

• 🟩 UC-010 — Terima Data Sensor via MQTT

• 🟥 UC-011 — Audit Trail Perubahan Data

• 🟦 UC-012 — Ekspor Data & Laporan

📌 Traceability Matrix

✅ 🔼 Prioritas Pengembangan (MoSCoW)

Berikut adalah versi terbaru dan lengkap:

🎯 3. System Design

Tahap System Design bertujuan untuk menerjemahkan semua kebutuhan sistem (FR, NFR, UC, BL) menjadi bentuk arsitektur teknis yang siap diimplementasikan. System Design memastikan bahwa:

• Semua kebutuhan telah dipetakan ke komponen dan modul sistem
• Arsitektur sistem dibuat agar modular, scalable, maintainable
• Desain teknis disusun hingga ke level implementasi database, API, dan logika bisnis

• 🔧 Substruktur System Design

System Design dibagi menjadi dua level utama:

• 🗂️ Konten High-Level Design (HLD)

• 📂 Konten Low-Level Design (LLD)

• 🧠 Validasi System Design terhadap SRS

System Design (baik HLD maupun LLD nanti) harus memenuhi semua elemen berikut:

🔷 3.1. High-Level Design (HLD) → kita bahas sekarang

Tujuan dari High-Level Design (HLD) adalah memberikan gambaran arsitektur sistem secara modular, hubungan antar komponen, serta alur komunikasi dan integrasi — berdasarkan kebutuhan yang telah ditentukan di SRS (FR, NFR, BL, UC).

• 🔷 1. Tujuan High-Level Design

• Mendeskripsikan arsitektur sistem mx-core-metric secara modular
• Menjelaskan komponen utama, relasi, dan alur data
• Mendasari pengambilan keputusan desain teknis di LLD nanti

• 🧩 2. Komponen Utama Sistem

Sistem mx-core-metric memiliki beberapa sub-komponen modul yang saling terhubung, dengan tanggung jawab sebagai berikut:

• 🏗️ 3. Diagram Arsitektur Modular

                                +-----------------------------+
                                |         User Interface      |
                                |     (Web Dashboard UI)      |
                                +-------------+---------------+
                                              |
              +-------------------------------+-----------------------------+
              |                                                             |
+---------------------------+                           +------------------+------------------+
|       REST API Gateway    |                           |        MQTT Broker (IoT)            |
|   (Next.js API Routes)    |                           |   [mosquitto / cloud-based MQTT]    |
+-------------+-------------+                           +----------+---------------------------+
              |                                                    |
   +----------+----------+                               +---------v----------+
   |     Application     |                               |    MQTT Ingestor   |
   |       Layer         |                               |  (Data Parser +    |
   |  (Nest.js service*) |                               |   Validator)       |
   +---+--------+--------+                               +---------+----------+
       |        |                                                  |
       |        |                                +-----------------+-----------------+
       |        |                                |                                   |
+------v+    +--v------+             +------------v------------+      +---------------v---------------+
|  KPI  |    | Target  |             |   KPI Recorder          |      |   Disturbance Manager        |
| Mgmt  |    | Planner |             | (Manual + Sensor Input) |      | (Logs, Source, Link to KPI)  |
+-------+    +---------+             +------------+------------+      +---------------+---------------+
                                                  |                                       |
                                                  |                                       |
                                     +------------v------------+             +------------v------------+
                                     |     Forecast Engine     |             |      Audit Logger        |
                                     | (Linear, Manual, Future |             | (Perubahan data penting) |
                                     |  ML-ready)              |             +---------------------------+
                                     +------------+------------+
                                                  |
                                      +-----------v-----------+
                                      |   Dashboard & Report  |
                                      +-----------------------+

Catatan:

• Backend dapat menggunakan monolith Next.js API routes atau dipisah microservice (Nest.js)
• MQTT listener bisa dijalankan sebagai service terpisah dengan worker/job scheduler

• 🔗 4. Alur Komunikasi Sistem

• 🔒 5. Security & Auth Flow

• 🌐 6. External Interface

• 🧠 7. Pemetaan ke SRS

Semua bagian HLD ini sudah terpenuhi dan sesuai dengan SRS (FR/NFR/UC/BL):

• ✅ Ringkasan HLD

• ✅ Arsitektur sistem modular sudah ditentukan
• ✅ Komunikasi antar modul dan protokol eksternal jelas
• ✅ Desain terbuka untuk integrasi dan bersifat scalable
• ✅ Selaras dengan semua kebutuhan di SRS

• 🎯 3.2 Low-Level Design (LLD)

Low-Level Design bertujuan untuk:

• Menjabarkan detail teknis tiap modul berdasarkan HLD
• Menyediakan spesifikasi implementasi untuk database, API, algoritma, dan integrasi
• Memastikan semua kebutuhan fungsional (FR), non-fungsional (NFR), dan batasan (BL) dari SRS dapat diimplementasikan secara terukur dan konsisten

• 🧱 1. Entity Relationship Diagram (ERD)

LLD ini mengacu penuh pada ERD yang telah Anda lampirkan sebelumnya (format dbdiagram.io). Berikut adalah ringkasannya dalam bentuk modul:

📂 Tabel Utama: KPI & Target

📂 Tabel Gangguan

📂 Tabel Organisasi & User

• 📖 2. Data Dictionary (Contoh)

Berikut cuplikan struktur field-level yang relevan untuk pengembangan:

🔹 Tabel kpi_record

• 🌐 3. Skema API (REST API)

Sesuai dengan arsitektur HLD (Next.js API / Nest.js), berikut contoh endpoint utama:

🔹 POST /api/kpi-record

{
  "kpi_id": "kpi-001",
  "unit_id": "unit-a",
  "department_id": "dept-prod",
  "periode": "2025-12-01",
  "value": 9500,
  "source": "manual",
  "note": "Capaian minggu ke-1",
  "created_by": "user-001"
}

| Response |

{
  "status": "success",
  "data": {
    "id": "record-12345"
  }
}

🔹 POST /api/mqtt-ingest

| Deskripsi | Endpoint untuk menerima payload dari MQTT listener (internal call) | | Payload |

{
  "topic": "kpi/update/unit-a",
  "payload": {
    "kpi_id": "kpi-001",
    "value": 480,
    "periode": "2025-12-02",
    "source": "sensor"
  }
}

🔹 GET /api/dashboard/summary

| Fungsi | Mendapatkan ringkasan KPI vs target untuk dashboard | | Query Params | periode, unit_id, department_id | | Response Example |

{
  "target": 10000,
  "actual": 9500,
  "achievement_percent": 95,
  "status": "warning"
}

• 🧠 4. Algoritma Forecasting

Modul Forecast Engine akan menjalankan perhitungan otomatis dengan metode:

📌 Default Method: Linear Projection

/**
 * Linear Forecast
 * @param actuals Array of past values with known time delta (weekly/monthly)
 * @param currentIndex Index of current period (e.g. month 8 of 12)
 */
function forecastLinear(actuals: number[], currentIndex: number): number {
  const sum = actuals.reduce((a, b) => a + b, 0);
  const avg = sum / currentIndex;
  const projectedTotal = avg * 12;
  return projectedTotal;
}

Catatan:

• Untuk NFR forecast cepat, algoritma ini sangat ringan
• Di masa depan bisa diganti dengan regression, LSTM, dsb (sesuai roadmap)

• 🧪 5. Validasi Payload Sensor (MQTT Format)

| Format MQTT Payload (JSON) | Topik: kpi/update/{unit} |

{
  "kpi_id": "kpi-001",
  "value": 123.45,
  "periode": "2025-12-10"
}

Jika tidak valid → reject & log error

• ⚙️ 6. MQTT Listener Design

• Broker: Bisa pakai Mosquitto atau MQTT Cloud (e.g. HiveMQ, EMQX)
• Topik Standar: Format: kpi/update/{unit_id} Payload: JSON (sesuai skema di atas)
• Processor: Listener subscribe ke topik, validasi, lalu simpan ke DB

• 🔐 7. Konfigurasi Role & Logging

| Logging | Entitas yang dilog: kpi_record, target, forecast, disturbance |

• ✅ Sinkronisasi LLD dengan HLD & SRS

• 📦 Ringkasan Output LLD

✅ Struktur tabel dan field lengkap (ERD & data dictionary) ✅ API endpoint & payload lengkap untuk tiap fungsi utama ✅ Algoritma forecast sudah ditentukan ✅ Format dan arsitektur integrasi sensor via MQTT ✅ Role access dan audit trail siap diimplementasikan

🎯 4. Implementation (Coding)

Tahap ini menerjemahkan semua desain dari HLD dan LLD menjadi kode sumber nyata, melalui struktur kerja yang terorganisasi dan dapat ditinjau. Tahap ini juga menjadi dasar untuk penentuan milestone sprint, pengelolaan repositori, dan distribusi tugas tim dev.

1️⃣ Setup Repositori (Git)

• 📁 Struktur Direktori (Monorepo – Plugin mx-core-metric)

Karena mx-core-metric adalah submodul dari monorepo mx-core, maka struktur awalnya mengikuti standar plugin:

mx-core/
│
├── apps/
│   ├── dashboard/         ← Aplikasi utama (Next.js Web UI)
│   └── api/               ← Next.js API routes (jika monolith)
│
├── packages/
│   ├── mx-core-metric/    ← Plugin KPI & metric (kode kita)
│   └── mx-core-auth/      ← Plugin lain (misal: auth, user)
│
├── libs/                  ← Library bersama (utils, UI kit, dsb)
│
└── .github/               ← CI/CD, workflows

• 🔧 Naming Repositori Internal

• Package Name: @mx-core/metric
• Folder Path: packages/mx-core-metric
• Namespace: metric, dengan ekspor modular (e.g. metric.api, metric.forecast, metric.utils)

• 🛠️ Inisialisasi Repositori

• Git branch default: main

• Branch protection: ✔ PR required, ✔ review 1x

• Template commit: Conventional Commits

  • feat(metric): add forecast calculation
  • fix(metric): validate MQTT payload before insert

• Setup tool: turbo (untuk monorepo builder)

2️⃣ Coding by Module/Sprint

• 📆 Sprint Breakdown (Rekomendasi: 2 minggu/sprint)

• 📦 Struktur Modular Package (Coding Level)

Dalam packages/mx-core-metric:

mx-core-metric/
│
├── src/
│   ├── api/                     ← API handler per endpoint
│   ├── services/                ← Logic per modul (forecast, record, etc)
│   ├── models/                  ← Tipe data (TypeScript) dan skema DB
│   ├── utils/                   ← Helper functions
│   └── config/                  ← Config MQTT, forecast, dsb
│
├── tests/                      ← Unit & integration tests
├── README.md
├── tsconfig.json
└── package.json

• 📌 Contoh Modul Sprint: Forecast Engine

• Lokasi: src/services/forecast/linear.ts
• Tipe: manual, linear, dan disiapkan untuk ml_model
• Dipanggil dari: src/api/forecast.ts

export function forecastLinear(
  actuals: number[],
  currentIndex: number
): number {
  const sum = actuals.reduce((a, b) => a + b, 0);
  const avg = sum / currentIndex;
  return avg * 12;
}

✅ 3️⃣ Kode Mengacu pada LLD

• 🧩 1. Acuan Data Model & Tipe Data

✅ Kode sumber menggunakan model TypeScript yang merepresentasikan entitas dari ERD:

// src/models/KpiRecord.ts
export interface KpiRecord {
  id: string;
  kpi_id: string;
  unit_id: string;
  department_id: string;
  periode: string; // ISO 8601
  value: number;
  source: 'manual' | 'sensor' | 'imported';
  note?: string;
  created_by: string;
  created_at: string;
}

🟢 Sesuai dengan LLD → Data Dictionary → Table kpi_record

• 🔧 2. Validasi Input Sesuai Spesifikasi LLD

Setiap endpoint (manual maupun MQTT) wajib validasi schema sebelum insert/update.

✅ Contoh: Validasi payload POST /api/kpi-record:

import { z } from 'zod';

const kpiRecordSchema = z.object({
  kpi_id: z.string().min(1),
  unit_id: z.string().min(1),
  department_id: z.string().min(1),
  periode: z.string().refine((val) => !isNaN(Date.parse(val)), {
    message: 'Invalid date format',
  }),
  value: z.number(),
  source: z.enum(['manual', 'sensor', 'imported']),
  note: z.string().optional(),
  created_by: z.string().min(1),
});

export type KpiRecordInput = z.infer<typeof kpiRecordSchema>;

🟢 Ini sesuai dengan LLD → API Schema & Validasi Payload MQTT

• 📊 3. Penerapan Algoritma Forecast Sesuai LLD

✅ Implementasi kalkulasi linear projection:

// src/services/forecast/linear.ts
export function forecastLinear(values: number[], currentIndex: number): number {
  const sum = values.reduce((a, b) => a + b, 0);
  const avg = sum / currentIndex;
  return avg * 12;
}

• Sudah sesuai dengan algoritma yang didefinisikan di LLD
• Forecast siap dipanggil via scheduler atau cron

• 🌐 4. Endpoint Sesuai Spesifikasi API LLD

Semua endpoint memanfaatkan input schema, response handler, dan ORM layer yang mengacu ke model LLD

• 🔐 5. Role & Auth Flow Sesuai LLD

• ✅ Role di-inject dari token JWT
• ✅ Role digunakan untuk gate API (e.g. hanya admin bisa input KPI tahunan)

// Middleware (pseudo)
if (user.role !== 'admin') {
  return res.status(403).json({ error: 'Forbidden' });
}

🟢 Sesuai dengan LLD → Role Access dan NFR-03

🗂️ 6. Modularisasi File Sesuai Struktur HLD & LLD

• Modul services/, api/, models/, utils/, dan config/ digunakan sesuai fungsinya
• Struktur kode mengikuti struktur modular HLD
• Memudahkan pengujian dan refactor per modul

• 🔄 7. Traceability dari FR/UC ke Kode

Semua fitur utama terhubung langsung ke SRS dan LLD

✅ 4️⃣ Versioning dan Dokumentasi

• 🧭 Versioning Strategy (Git + Semver)

• 🚀 Semantic Versioning (SemVer)

• 📚 Dokumentasi Kode

✅ Disusun per modul dalam folder docs/ atau dalam file README.md tiap direktori:

📌 Format dokumentasi: Markdown, ditulis ringkas dan fokus pada integrasi + pemakaian

✅ 5️⃣ Code Review & Integration Checklist

• 🧩 Pull Request Workflow

• ✅ Integration Checklist

📌 Checklist ini dijalankan oleh tim dev sebelum lanjut ke testing/UAT

✅ 6️⃣ Output: Source Code Versi Alpha

• 🚧 Kriteria Versi Alpha

📌 Versi Alpha ini bisa diberi tag: v0.1.0-alpha

🧠 Keterkaitan dengan SRS, HLD, dan LLD

📘 **5 Testing **

🎯 Tujuan:

Memastikan sistem mx-core-metric berjalan sesuai SRS dan Use-Case Validasi dilakukan secara bertahap, dari unit terkecil (fungsi) hingga keseluruhan sistem (UAT).

✅ 1. Unit Test

Menguji fungsi/method individual untuk memastikan logika berjalan sesuai ekspektasi.

• Contoh Unit yang Diuji:

• Tools:

• Jest (untuk TypeScript)
• Coverage target: ≥ 80% modul services/ dan utils/

✅ 2. Integration Test

Menguji interaksi antar modul: API ↔ DB, API ↔ Service, MQTT ↔ Handler.

• Contoh Skenario:

• Tools:

• Supertest untuk REST API
• ts-mockito / msw untuk mocking service

✅ 3. System Test

Simulasi alur end-to-end berdasarkan Use-Case

• Contoh Alur UC yang Diuji:

• Coverage:

• Minimal 1 test untuk setiap UC prioritas Must dan Should
• Fokus pada alur utama dan validasi kondisi sukses

✅ 4. User Acceptance Test (UAT)

Validasi oleh end-user bahwa sistem sesuai ekspektasi fungsional.

• Pelaksanaan:

• Peserta: Perwakilan dept. Maintenance, Produksi, K3

• Format: Workshop + form checklist

• Fokus:

  • Kemudahan input & navigasi
  • Visualisasi data KPI, forecast, gangguan
  • Sesuai terminologi dan struktur organisasi user

• Form Checklist UAT:

🧠 Korelasi dengan SRS & UC

📝 5️⃣ Test Plan

Rencana pengujian secara menyeluruh terhadap sistem mx-core-metric.

• 📌 Struktur Test Plan

✅ 6️⃣ Test Case

Daftar skenario pengujian berdasarkan Use-Case & FR

• 📋 Contoh Format Test Case (Tabel)

• 📌 Kriteria:

• Mapped ke UC dan FR

• Harus cover:

  • Positive test
  • Negative test (validasi gagal)
  • Boundary (nilai ekstrem, null, 0, max float)

• Status: ✅ = Lolos, ❌ = Gagal, ⚠ = Butuh review

🐞 7️⃣ Bug Log & Traceability Matrix

• 🐞 Bug Log

• Tool: GitHub Issues / Linear / Notion

• Severity:

  • Blocker: Tidak bisa lanjut proses
  • High: Gangguan fitur utama
  • Medium/Low: Tidak berdampak signifikan

• 🔁 Traceability Matrix (SRS → Test Case)

📌 Semua FR dan UC utama tercover dalam test case

🧩 8️⃣ Release Candidate (RC) Definition

• 📦 Apa itu Release Candidate?

Versi kode yang dianggap feature-complete dan telah lolos semua pengujian kritikal, siap untuk:

• Di-freeze (tidak ditambah fitur lagi)
• Diuji regresi secara menyeluruh
• Dideploy ke staging atau production (setelah approval)

• ✅ Kriteria RC untuk mx-core-metric

📌 RC Tag: v1.0.0-rc.1

• 🧪 Regresi & Final Check

Dilakukan untuk memastikan fitur-fitur eksisting tidak rusak akibat perubahan/penambahan terbaru.

📤 Output Tahap Testing

🧠 Keterkaitan dengan Tahap Sebelumnya

📘 6 Deployment – mx-core-metric

Menyusun strategi dan checklist implementasi untuk meluncurkan sistem mx-core-metric ke production secara aman, terdokumentasi, dan dapat di-rollback jika diperlukan.

Deployment dilakukan dari hasil release candidate (v1.0.0-rc.1) yang telah lolos semua pengujian sebelumnya.

🔹 Checklist Deployment

✅ 1. Build & CI/CD Pipeline

✅ 2. Environment Setup

Variabel Lingkungan (.env)

✅ 3. Backup & Rollback Plan

✅ 4. Dokumen Release Notes

           - Target tahunan dan periodik
           - Forecast capaian
           - Dashboard
           - Gangguan operasional & linking
           - Export PDF/CSV
           - Role & akses berbasis peran

| Perbaikan | - Validasi input ketat

• Format payload MQTT
• Error handling endpoint | Known Issue | - Belum ada notifikasi otomatis
• Belum support forecasting berbasis ML

📄 File: RELEASE_NOTES_v1.0.0.md

✅ 5. Deployment Log

Disimpan otomatis oleh CI/CD dan/atau dicatat manual oleh DevOps:

📄 File: deployment-log.yaml

• ✅ Output

• 🧠 Keterkaitan dengan SDLC Sebelumnya

📘 7 Maintenance & Support – mx-core-metric

🎯 Tujuan

Menjamin bahwa sistem mx-core-metric:

• Berjalan secara berkelanjutan (sustain)
• Adaptif terhadap kebutuhan pengguna
• Mendapatkan perbaikan cepat jika terjadi kendala
• Dapat ditingkatkan (scalable) tanpa mengganggu sistem yang sudah live

✅ 1. Monitoring Performance

🎯 Tujuan:

• Deteksi dini terhadap penurunan performa sistem
• Pemantauan uptime, latency, error rate

🔧 Tools & Praktik:

✅ 2. Patch & Bug Fix

🛠️ Prosedur:

1. Bug dilaporkan via user / QA
2. Tercatat di Bug Tracker (GitHub Issues / Notion)
3. Diperbaiki dan di-merge ke branch hotfix/
4. Rilis dengan tag vX.Y.Z-patch
5. Update changelog & log deploy

SLA Target:

✅ 3. User Feedback Loop

📥 Sumber Feedback:

• User lapangan (operator, supervisor)
• Admin KPI
• Manajemen (dashboard visibility, export)

🔄 Siklus Feedback:

1. Kumpulkan → melalui form, survey, atau WA group user
2. Triage → Tentukan apakah bug, usulan fitur, atau edukasi
3. Simpan → Dalam backlog Notion atau board Linear
4. Prioritaskan → Gunakan MoSCoW atau RICE score

📌 Contoh Feedback Nyata:

✅ 4. Model Retraining (Jika Menggunakan AI)

Untuk sistem forecast KPI berbasis tren, bisa berkembang ke ML-based forecasting

🧠 Pipeline Sederhana:

1. Ambil data historis dari kpi_record
2. Jalankan training setiap bulan (job cron)
3. Simpan model terbaru
4. Bandingkan hasil forecast ML vs Linear
5. Gunakan yang terbaik

📌 Ini dapat menjadi fitur fase 2 (UC-013 / BL-03)

✅ 5. Feature Improvement Roadmap

Dirancang dari hasil UAT, feedback user, dan evaluasi sistem.

📅 Rencana Peningkatan (Sample Roadmap)

✅ Output: SLA & KPI Pemeliharaan

• 📊 SLA (Service Level Agreement)

• 📈 KPI Maintenance Tim Dev

• 🧠 Integrasi dengan Tahap SDLC Sebelumnya

• ✅ Kesimpulan Tahap Maintenance