Implementasi Metode Scrum dalam Pembuatan Modul Pemesanan Kurban Berbasis ASP.NET dan Analisis Kinerja Endpoint API

Abstract

Peningkatan skala pelaksanaan kurban kolektif membuat pengelolaan administrasi secara manual tidak lagi memadai untuk menangani pemesanan dalam jumlah besar, sehingga digitalisasi melalui modul pemesanan kurban menjadi solusi yang relevan. Namun, pola akses musiman menjelang Hari Raya Idul Adha berpotensi memicu lonjakan beban yang belum teruji pada sistem kurban terdahulu yang umumnya berhenti pada pengujian fungsional. Penelitian ini bertujuan membuat modul pemesanan kurban dengan mengimplementasikan metode Scrum berbasis ASP.NET, sekaligus menganalisis kinerja endpoint API pada kondisi beban puncak melalui metode load testing. Modul diselesaikan dalam lima Sprint yang mencakup 32 item Product Backlog, dan kinerjanya diuji menggunakan Apache JMeter terhadap enam endpoint alur utama pada beban 100 virtual user. Seluruh Increment memenuhi Definition of Done dan seluruh endpoint memenuhi threshold, dengan average response time 98–455 ms, P95 161–980 ms, throughput 29–41 request/detik, dan error rate 0–0,42%. Endpoint POST pesanan menjadi endpoint kritis, tetapi modul tetap dinyatakan layak dioperasikan pada estimasi beban puncak.

The growing scale of collective qurban makes manual administration inadequate for handling orders at large volume, so digitalisation through a qurban ordering module becomes a relevant solution. However, the seasonal access pattern ahead of Eid al-Adha may trigger load surges that previous qurban systems, which generally stop at functional testing, have not tested. This research aims to develop an ASP.NET-based qurban ordering module by implementing the Scrum method, while also analysing API endpoint performance under peak load through load testing. The module was completed across five Sprints covering 32 Product Backlog items, and its performance was tested using Apache JMeter on six main-flow endpoints at a load of 100 virtual users. Every Increment met the Definition of Done and all endpoints satisfied the thresholds, with an average response time of 98–455 ms, a P95 of 161–980 ms, throughput of 29–41 requests per second, and an error rate of 0–0,42%. The POST order endpoint became the critical endpoint, but the module remains feasible to operate at the estimated peak load.