Alur Kerja Pembuatan Aplikasi

 Alur kerja pembuatan aplikasi (not ideal but must to know)
1. BRD (bisnis requirement Diagram)
- aplikasi apa
- fiture apa => timeline breakdown
- MVP (minimal viable product)
- Alur (flow bisnis)
- Riset tim produk, bisnis, dan tim operasional. Minta dokumen BRD (dibuat pake confluent)
- Alur tidak jelas (misal tiket dibatalkan)
- Semua harus tertulis di BRD supaya benar atau salah bisa dari cek BRD nya.
- Diskusi

2. UI/UX
- Hasil dari tim UI/UX (tim produk), berupa gambaran tiap flow BRD.
- Bentuk form, button, component dan alur harus jadi dulu
- Memakai aplikasi adobe xd utk tau dan interaksi jelas.
- Sebagai acuan tim teknologi utk gambaran

3. Technical Design
- Technical implementation dalam btk dokumen, dalam confluent page
- Deployement diagram :
misal fitur A butuh aplikasi B, pakai database apa, pakai API, atau pakai setup message broker, mengaggregasi service, mengirim data2 lain ke third party. Semua dibuat dalam diagram.
- ERD : structure table dan relation tiap2 table.
- Selama techincal design maka kebutuhan dari service2 lain bisa di evaluasi.
- Gambaran besar cara membuat aplikasinya.
- Best practice table , third party, dll.

4. Architecture Review
- Penggabugan dari semua senior arsitek. (infra arc, security arc, development arc, frontend arc)
- Techinal design utk direview dan dipastikan jika dibuat sudah baik, jika ada concern maka concern akan review
ERD harus selalu normal,
jika grow tinggi maka table yg terlalu bnyak join akan dibuat flat,
infra akan membuat perkiraan CPU, memory server dari traffic,
dari security
dari FE , performace dan API calling response time
feedback akan diperbaiki technical design.
Jika terlalu slow bisa di buat message broker

jadi memastikan yg dibuat itu baik dan tidak ada kecolongan bnyak masalah waktu di production.

5. API Specification
- Perdebatan antar QA, FE dan BE bisa diskusi di tahap ini
- API Spec mengacu pada data yg di butuhkan dan ditampilkan dari UI,
- Supaya bisa berjalan secara paralel dan tidak saling menunggu seperti method waterfall.
- Jadi kesepakatan (request dan response) based on UI/UX
- Kebutuhan endpoint tiap screen,  
- Tim backend biasanya buat api dari tabel yg dibuat, secara screen blm tentu, 1 table 1 screen tpi gabungan dari beberapa table.
- Format json harus ditentukan dan disepakati masing2 contohnya https://github.com/ProgrammerZamanNow/kotlin-restful-api
- Seletah di ketok palu maka tidak ada yg boleh berubah.

6. Development (BE,FE,QA)
QA => mmembuat automation based on API Spec
- Jalan termin 1 dalam 1 bulan (4 minggu), semua jalan secara paralel.
- Sesuai kesepakatan yg dibuat dari API Spec.
- Tidak seperti waterfall yang meunggu2, sehingga bisa dikejar 3 minggu dan bisa spare 1 minggu.

7. Non Prod Deployment
- Deploy product tiap2 environment : dev env, QA env, Staging env, Sandbox
- BE/FE dibuat CI/CD
- Release versi dan baca sesuai repo dan dibuat tag baru sehingga dapat CI/CD nya.
- QA bisa dibuat 2 env nya supaya tidak bentrok di dlm project lain.

8. Testing (Performance, QA, Security)
- End to End test (yg sudah dibuat oleh tim QA)
- Performance test (misal API response harus < 2 seconds)
- Security Test apakah ada xss, security hall.
- Tergantung KPI dari perusahaan atau company
- happy flow, ketika belanja sampai dapat barang.

9. Prod Deployment
- A/B Testing, blue deployment
- jika ada feature baru maka harus dijalankan QA otomation.
- Mencoba proses belanja.
Maintenance => ketika aplikasi tiba2 mati, atau rusak.
Improvement (balik lagi ke awal yaitu buat BRD dan sampai testing )

Maintenance bisa dibuat Monitoring aktivity,
total traffic, respons time, optimize algoritma cara kerja API.