BAB V IMPLEMENTASI
6.1. Tahapan Pengujian Model
6.1.3 Tahapan Perhitungan Estimasi Harga
Setelah 7 tahapan awal dilakukan, selanjutnya adalah tahapan dalam memperhitungkan estimasi harga pada setiap aplikasi.
Pada bagian ini akan mencakup tahapan mulai dari tahap 8 sampai dengan tahap 13.
Tahap 8 : Menghitung distribusi usaha
Langkah pertama dalam melakukan perhitungan estimasi harga adalah perlunya menentukan distribusi usaha untuk semua aplikasi terlebih dahulu. Distribusi usaha yang akan digunakan pada penelitian ini didasari oleh penelitian Primandari dan Sholiq karena kemiripan jumlah UCP[6].
Daftar distribusi usaha dan fase-fasenya dapat dilihat pada tabel 16.
Tahap 9 : Menghitung Payrate perusahaan
Selanjutnya, pada tahapan ini akan ditentukan payrate dari perusahaan. Payrate didapat dengan menggunakan rumus yang telah ditetapkan oleh INKINDO[19]. Berikut adalah cara mencari payrate menggunakan data gaji pegawai CV Owline Group: Month Rate (gaji per bulan). Dengan persamaan diatas, maka akan didapatkan sebagai berikut:
Tabel 33. Payrate setiap Posisi (dalam IDR)
Posisi
mmer 3,000,000 731,707.317
1 150,000 24,375
Design
er 3,000,000 731,707.317
1 150,000 24,375
Berdasarkan tabel diatas, maka dapat ditentukan bahwa payrate untuk CV Owline Group adalah nilai rata rata gaji per jam dari semua posisi yaitu 29791,67. Karena perusahaan CV Owline Group berada di kota Surabaya, maka sesuai dengan peraturan INKINDO 2018 maka rata-rata gaji per jam (payrate) akan dikalikan dengan indeks Jawa Timur yaitu sebesar 0,926 dalam perhitungan tahap selanjutnya.
85
Tahap 10 : Menghitung Cost by Activities
Setelah didapatkan distribusi usaha dan payrate pada CV Owline Group, selanjutnya akan dicari biaya yang dikeluarkan perusahaan untuk setiap aktivitas pengembangan perangkat lunak. Caranya adalah dengan mengalikan nilai estimasi usaha dengan persen distribusi usaha, lalu dikalikan dengan payrate. Berikut adalah hasil perhitungan Cost by Activities:
Tabel 34. Cost by Activites Software Phase
Aplikasi Pay Rate Index
Biaya Per Aktivitas (dalam IDR) Software Phase
Requirement Specification Design Implementation Acceptance &
Deployment Kasir
Pintar
29791.666
67 0.926 241,589.8365 1,132,452.359 905,961.887 7,851,669.686 830,465.0629 Studyliciou
s
29791.666
67 0.926 124,313.2168 582,718.2039 466,174.563 4,040,179.547 427,326.6829 Sily 29791.666
67 0.926 201,715.7858 945,542.7459 756,434.197 6,555,763.038 693,398.0137 Trans ITS 29791.666
67 0.926 77,402.56897 362,824.542 290,259.634 2,515,583.492 266,071.3308 Simonag 29791.666
67 0.926 154,805.1379 725,649.0841 580,519.267 5,031,166.983 532,142.6617
Tabel 35. Cost by Activites On-going Life Cycle Phase
Aplikasi Pay
Rate Index
Biaya Per Aktivitas (dalam IDR) On going life cycle phase Project
Management
Configuration Management
Documenta
tion Training Quality Assurance &
Testing Kasir
Pintar
29791.6
6667 0.926 573,775.8616 649,272.6855 1,268,346.6 42
6667 0.926 295,243.89 334,091.7702 652,644.38 84
77,695.7605
2 769,188.0291
Sily 29791.6
6667 0.926 479,074.9913 542,111.1743 1,059,007.8 75
6667 0.926 183,831.1013 208,019.4041 406,363.48 71
48,376.6056
1 478,928.3955
Simonag 29791.6
6667 0.926 367,662.2026 416,038.8082 812,726.97 42
96,753.2112
1 957,856.791
87
Tahap 11 : Menghitung Personel Direct Cost
Pada tahap ini, setelah ditemukan cost by Activities untuk setiap aplikasi maka seluruh biaya per aktivitas tersebut akan dijumlahkan sehingga menghasilkan Personel Direct Cost (sebelum ditambah profit). Mengacu pada formula (8) dan formula (9), dengan profit yang diambil untuk semua aplikasi adalah 10% sehingga nilai Personel Direct Cost untuk setiap aplikasi adalah sebagai berikut:
Tabel 36. Personel Direct Cost setiap Aplikasi
Aplikasi Personel Direct Cost
awal Profit Personel Direct Cost
Kasir Pintar 15,099,364.78 0.1 16609301.26 Studylicious 7,769,576.052 0.1 8546533.657 Sily 12,607,236.61 0.1 13867960.27 Trans ITS 4,837,660.561 0.1 5321426.617 Simonag 9,675,321.121 0.1 10642853.23
Tahap 12 : Menambahkan Non Personel Direct Cost Jumlah nilai Non Personel Direct Cost akan dihitung berdasarkan lama waktu pengerjaan untuk setiap aplikasi. Cara perhitungannya adalah total biaya operasional (sebesar Rp 5.500.000,00) ditambah dengan biaya sewa gedung perbulan (Rp 1.600.000,00), lalu dikalikan dengan persentase pengerjaan aplikasi. Nilai penuh 100% menandakan pengerjaan selesai dalam waktu 1 bulan. Nilai ini akan ditambahkan dengan nilai Personel Direct Cost untuk menentukan Harga Perkiraan Sendiri (sebelum diberi pajak).
Berikut adalah total estimasi harga dengan model Harga Perkiraan Sendiri (HPS):
Tabel 37. Harga Perkiraan Sendiri sebelum Pajak Estimate Cost sebelum
7,100,000 23,709,301.26 Studylicio Trans ITS 5,321,426.6
17
Setelah didapat nilai total HPS, maka tahap berikutnya adalah menambahkan persen pajak pada nilai HPS sesuai dengan ketentuan negara yang sedang berlaku. Pajak yang dikenakan berupa Pajak Pertambahan Harga (PPh) sebesar 10%, sehingga nilai akhir HPS ditambahkan sebesar 10%.
Tabel 38. HPS ditambah dengan Pajak
Aplikasi Owner Estimate Cost
sebelum Pajak Pajak Owner Estimate Cost
Kasir Pintar 23,709,301.26 0.1 26,080,231.38 Studylicious 13,871,533.66 0.1 15,258,687.02
Sily 22,742,960.27 0.1 25,017,256.3
Trans ITS 8,871,426.617 0.1 9,758,569.278 Simonag 21,292,853.23 0.1 23,422,138.56 6.1.4 Pengujian Model
Pada tahap ini, akurasi model perlu ditentukan untuk melihat apakah estimasi pada penelitian ini sudah cukup akurat atau
89 belum. Hal ini dilakukan dengan menghitung deviasi Magnitude of Relative Error (MRE) untuk masing-masing Harga Perkiraan Sendiri pada setiap perangkat lunak. Rumus untuk menentukannya adalah:
...(10) Dengan membandingkan harga estimasi dengan harga aktual yang disediakan dari CV Owline Group, dapat diketahui apakah estimasi dalam penelitian ini mendekati prediksi dengan margin yang besar atau tidak. Untuk mengevaluasi akurasi, digunakan rumus ini:
Pred (0,25) = k / N ...(11) Dari persamaan itu, pembilang k adalah jumlah pengamatan yang MRE-nya kurang dari atau sama dengan 0,25 yang berarti deviasi prediksi harus di bawah 26%, dan penyebut N adalah total jumlah pengamatan. Hal ini menandakan bahwa evaluasi didasarkan pada persentase pengamatan yang memiliki deviasi estimasi harga kurang dari 26%. Menurut Conte et al. prediksi yang baik (Pred) harus memiliki MMRE (Mean of MRE) kurang dari 26%, dan juga harus memiliki Pred (0,25) lebih dari 75%. Ini berarti bahwa deviasi prediksi penelitian harus di bawah 26%, dan prediksi itu harus berjumlah lebih dari 75% dari 100% total pengamatan proyek pengembangan perangkat lunak[20]. Berikut adalah hasil perbandingan harga estimasi dengan harga aktual pada setiap aplikasi:
Tabel 39. Tabel Pengujian Akurasi Model HPS
Aplikasi Harga Estimasi
Harga Aktual
Magnitude of Relative Error (MRE)
Kasir Pintar 26,080,231.38 23,700,000 0.100431704 Studylicious 15,258,687.02 17,775,000 0.141564724 Sily 25,017,256.3 29,625,000 0.155535652
TransITS 9,758,569.278 11,850,000 0.176492044 SIMONAG 23,422,138.56 47,250,000 0.341149408 Mean of MRE 0.183034706 Dimana :
Pred(0.25)=4/5 Pred(0.25)=80%
91
6.2. Pembahasan Hasil Pengujian Model Harga Perkiraan Sendiri
Berdasarkan hasil pengujian model Harga Perkiraan Sendiri yang dicetuskan oleh Sholiq et. al, peneliti berhasil menemukan harga estimasi untuk setiap aplikasi yang disediakan oleh CV Owline Group[7]. Penelitian oleh Sholiq dilakukan pada aplikasi pemerintah secara general, sedangkan pada penelitian ini, model diujikan dengan aplikasi berbasis android. Untuk melihat validasi atas keakuratan perkiraan model, perlu dilihat terlebih dahulu bahwa deviasi/MRE untuk setiap aplikasi memiliki variasi yang tidak berdekatan satu sama lain. Berdasarkan anjuran Conte[20], prediksi yang dapat diterima dari pengujian 5 aplikasi ada pada 4 aplikasi, yaitu Kasir Pintar, Studylicious, Sily, dan TransITS. Empat aplikasi ini memiliki nilai deviasi dibawah 26% dengan masing masing memiliki deviasi 10%, 14%, 15%, dan 17%. Sedangkan 1 aplikasi lainnya memiliki nilai deviasi yang cukup tinggi, yaitu berada pada 34%. Dari keseluruhan pengamatan, keakuratan prediksi (MMRE) dapat dilihat dari nilai Pred(0.25), yaitu sebesar 80%. Melihat hasil ini, didapatlah temuan mengapa empat aplikasi memiliki deviasi yang cukup rendah, sedangkan satu aplikasi sisanya memiliki deviasi yang tinggi sekali. Salah satu faktor yang perlu diperhatikan untuk mencari sebab terjadinya deviasi yang besar pada aplikasi tersebut, adalah diketahui pula bahwa aplikasi SIMONAG merupakan aplikasi dengan harga tertinggi dari seluruh harga aplikasi yang diamati. Dari temuan diatas, dapat disimpulkan bahwa harga aplikasi tersebut adalah overpriced, yaitu harganya besar tetapi tidak sebanding dengan fungsional aplikasi yang ditawarkan. Kemungkinan kedua akan penyebab dari besarnya deviasi perhitungan harga aplikasi SIMONAG adalah sulitnya penelitian yang dilakukan dalam menentukan level detailnya sebuah transaksi pada setiap use case membuat peneliti tidak sesuai dalam mengidentifikasi jumlah transaksi, sehingga berakibat besar bagi perhitungan UCP. Hal ini dikemukakan oleh Bente Anda pada penelitiannya dalam
estimasi usaha pengembangan perangkat lunak dari kacamata dunia industri[21].
Selanjutnya, persentase distribusi usaha yang digunakan pada penelitian ini didasarkan dari penelitian Primandari dan Sholiq[6]. Pada penelitian tersebut, aplikasi yang diujikan adalah aplikasi secara umum yang berskala kecil-medium.
Sesuai dari hasil wawancara, aktivitas aktivitas yang dilakukan oleh CV Owline Group memiliki kesamaan dengan aktivitas aktivitas yang dilakukan oleh developer aplikasi yang diteliti oleh Primandari dan Sholiq. Kesamaan aktivitas ini diuji dan dibuktikan dengan penggunaan distribusi usaha pada penelitian sebelumnya, lalu diadaptasi pada penelitian ini.
Hasil yang didapatkan dari penelitian ini pula menunjukkan bahwa keakuratan model secara keseluruhan cukup rendah, yaitu 18%. Hal ini menunjukkan bahwa distribusi usaha yang dikemukakan oleh Primandari dan Sholiq dapat digunakan sebagai estimasi distribusi usaha untuk menguji aplikasi yang berbasis android. Penelitian selanjutnya diharapkan dapat digunakan distribusi usaha pada perusahaan pengembang aplikasi android yang lebih mendetail sehingga cost by activities yang didapat menjadi lebih akurat.
Pembahasan lain mengenai ditemukannya deviasi error pada estimasi harga dan usaha adalah pendefinisian jumlah transaksi pada sebuah use case. Menurut Ochodek[17], penentuan jumlah transaksi dalam sebuah use case adalah hal yang krusial sehingga ia meneliti berbagai macam cara untuk mendefinisikan apa yang dimaksud dengan satu transaksi.
Pada penelitian ini, digunakan definisi perhitungan satu transaksi sebagaimana yang dijelaskan oleh Jacobson[22].
Menurut Jacobson, sebuah transaksi dihitung sebagai satu transaksi jika terdapat yang disebut dengan round-trip.
Dimulai dari stimulus yang dilakukan oleh aktor, dilanjutkan oleh perubahan kondisi dari sistem, lalu diakhiri dengan respon dari sistem itu sendiri. Hasil pengaplikasian definisi satu transaksi ini telah dilakukan dan dengan melihat hasil estimasi metode HPS, telah terlihat bahwa definisi oleh
Jacobson dapat digunakan sebagai acuan peneliti yang ingin melakukan estimasi usaha dan harga dari aplikasi yang berbasis android.
(Halaman ini sengaja dikosongkan)
95 BAB VII
KESIMPULAN DAN SARAN
Bab ini berisi kesimpulan dari keseluruhan permasalahan penelitian tugas akhir dan saran perbaikan yang dapat dikembanglam di masa mendatang.
7.1. Kesimpulan
Pada penelitian ini, dapat disimpulkan bahwa menggunakan metode Harga Perkiraan Sendiri untuk memperkirakan harga dan usaha suatu aplikasi adalah metode yang cukup akurat jika melihat deviasi error yang cukup rendah. Metode ini juga merupakan metode yang sebelumnya hanya diujikan pada aplikasi secara umum. Hasil penelitian menunjukkan bahwa metode ini dapat diaplikasikan dengan baik pada objek penelitian aplikasi berbasis android.
Kesimpulan yang didapat berikutnya adalah bagaimana keakuratan model Owner Estimate Cost pada usaha dalam pengembangan perangkat lunak berbasis android. Deviasi error yang didapatkan memang terbilang rendah. Pada penelitian ini telah ditemukan nilai MMRE sebesar 18%. Nilai ini sudah memenuhi kriteria akan keakuratan dari Conte sebesar kurang dari 25% sehingga dapat disimpulkan bahwa model telah akurat dalam melakukan estimasi. Tetapi dari keseluruhan observasi, terdapat 1 aplikasi yang memiliki nilai MRE diatas 25% yaitu aplikasi SIMONAG. Penyebab dari deviasi yang besarnya diatas ambang batas (25%) ini adalah:
1. Harga aplikasi merupakan harga yang tertinggi, tetapi memiliki jumlah UCP dan Effort yang kecil, sehingga bisa disimpulkan bahwa harga aplikasi overpriced.
2. Kesulitan peneliti untuk dengan secara akurat mengidentifikasi level detailnya sebuah transaksi pada setiap use case pada aplikasi SIMONAG, sehingga membuat hasil penelitian tidak sesuai dalam mengidentifikasi jumlah transaksi, sehingga berakibat besar bagi perhitungan UCP.
7.2 Saran
Beberapa hal yang diharapkan dapat dikembangkan untuk penelitian selanjutnya yaitu:
1. Perlu ditambahkannya jumlah observasi/studi kasus yang ada untuk meyakinkan pengguna model ini bahwa model Harga Perkiraan Sendiri yang dikemukakan Sholiq et. al. ini dapat secara akurat memperkirakan harga sebuah aplikasi, termasuk aplikasi berbasis Android.
2. Penelitian lebih lanjut akan penentuan dari standar level use case yang diidentifikasi agar perhitungan UCP semakin akurat dan semakin menambah akurasi dari perkiraan harga.
(Halaman ini sengaja dikosongkan)
98
(Halaman ini sengaja dikosongkan)
99
DAFTAR PUSTAKA
[1] C. Leong, B. Tan, X. Xiao, F. T. C. Tan, and Y. Sun,
―Nurturing a FinTech ecosystem: The case of a youth microloan startup in China,‖ Int. J. Inf. Manag., vol. 37, no. 2, pp. 92–97, Apr. 2017.
[2] Citi Group, ―Digital disruption, How FinTech is Forcing Banking to a Tipping Point.,‖ 2016.
[3] ContractIQ, ―What’s happening in the mobile development economy? Outsourced app development trends, pricing, and outlook 2015.,‖ 2015.
[4] S. Yuntoto, ―Pengembangan Aplikasi Android sebagai Media Pembelajaran Kompetensi Pengoperasian Sistem Pengendali Elektronik pada Siswa Kelas XI SMKN 2 Pengasih,‖ 2015.
[5] M. Jiménez Romero and D. A. Aparicio Álvarez, ―The Standish Group Report,‖ B.S. thesis, Universidad EAFIT, 2014.
[6] P. L. Primandari A and Sholiq, ―Effort Distribution to Estimate Cost in Small to Medium Software Development Project with Use Case Points,‖ Procedia Comput. Sci., vol. 72, pp. 78–85, 2015.
[7] Sholiq, A. Pribadi Subriadi, F. Artwodini M, and R. Sari Dewi, ―A Model of Owner Estimate Cost for Software Development Project in Indonesia.‖
[8] G. F. Prassida, A. H. N. Ali, and Sholiq, ―Estimasi Biaya Pembuatan Modul Enterprise Resource Planning (ERP) Untuk Unit Bisnis Pabrik Gula Di PT. Perkebunan XYZ Dengan Metode Use Case Point,‖ J. Tek. POMITS, vol.
1, 2012.
[9] M. Hayat, ―The Effect of the National Program of Society Empowerment (PNPM) on Women Existence between Public Space and Domestic Space,‖ J. Peremp.
Dan Anak, vol. 1, no. 1, p. 1, 2015.
[10] ―Harga Perkiraan Sendiri (HPS), antara Mark-Up dan Pelelangan Gagal - Badan Pendidikan dan Pelatihan
Keuangan.‖ [Online]. Available:
http://www.bppk.kemenkeu.go.id/publikasi/artikel/147- artikel-anggaran-dan-perbendaharaan/20287-harga- perkiraan-sendiri-hps-,-antara-mark-up-dan-pelelangan-gagal. [Accessed: 03-Mar-2018].
[11] A. B. Nassif, L. F. Capretz, and D. Ho, ―Enhancing use case points estimation method using soft computing techniques,‖ ArXiv Prepr. ArXiv161201078, 2016.
[12] G. Sparks, ―The Use Case Model,‖ Sparx Syst., 2000.
[13] M. Jørgensen, ―What We Do and Don’t Know about Software Development Effort Estimation,‖ IEEE Softw., vol. 31, no. 2, pp. 37–40, Mar. 2014.
[14] M. Cohn, ―Estimating with use case points,‖ Methods Tools, vol. 13, no. 3, pp. 3–13, 2005.
[15] G. Karner, ―Resource estimation for objectory projects,‖
Object. Syst. SF AB, vol. 17, 1993.
[16] M. Patton, Qualitative Research & Evaluation Methods, 4th ed. 2005.
[17] M. Ochodek, B. Alchimowicz, J. Jurkiewicz, and J.
Nawrocki, ―Improving the reliability of transaction identification in use cases,‖ Inf. Softw. Technol., vol. 53, no. 8, pp. 885–897, Aug. 2011.
[18] A. P. Subriadi and P. A. Ningrum, ―Critical Review of the Effort Rate Value in Use Case Point Method for Estimating Software Development Effort,‖ . Vol., vol.
59, p. 10, 2005.
[19] ―Billing Rate INKINDO (2011) Untuk Penyusunan Jasa Konsultasi.‖ Ikatan Nasional Konsultan Indonesia, 2012.
[20] S. D. Conte, H. E. Dunsmore, and Y. E. Shen, Software Engineering Metrics and Models. Redwood City, CA, USA: Benjamin-Cummings Publishing Co., Inc., 1986.
[21] B. Anda, H. Dreiem, D. I. K. Sjøberg, and M. Jørgensen,
―Estimating Software Development Effort Based on Use Cases — Experiences from Industry,‖ in ≪UML≫ 2001
— The Unified Modeling Language. Modeling Languages, Concepts, and Tools, vol. 2185, M. Gogolla
and C. Kobryn, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2001, pp. 487–502.
[22] I. Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Longman, Inc, 1992.
(Halaman ini sengaja dikosongkan)
103
BIODATA PENULIS
Penulis bernama lengkap Pandu Satrio Hutomo, dilahirkan di kota Solo, 27 Juli 1995, merupakan anak pertama dari dua bersaudara. Penulis telah menempuh pendidikan formal di SD Sompok Semarang, SMPN 13 Surabaya, dan SMAN 5 Surabaya. Penulis meneruskan pendidikan tinggi negeri di Departemen Sistem Informasi Institut Teknologi Sepuluh Nopember, Surabaya dan terdaftar dengan NRP 05211340000150. Pengalaman selama menjadi mahasiswa di ITS, penulis aktif berorganisasi di UKM ITS Foreign Language Society sebagai Ketua Divisi Bahasa Jepang pada tahun 2014 dan sebagai Ketua Umum UKM pada tahun 2015.
Penulis juga pernah melaksanakan kerja praktik selama dua bulan pada tahun 2017 di PT Bank Rakyat Indonesia (BRI).
Penulis mengambil bidang minat Manajemen Sistem Informasi (MSI) pada penyelesaian Penelitian Tugas Akhir dengan topik Pengujian Model Harga Perkiraan Sendiri (Owner Estimate Cost) Proyek Pengembangan Perangkat Lunak pada Aplikasi Berbasis Android. Untuk menghubungi penulis, dapat melalui e-mail : pandu.satrio27@gmail.com.
(Halaman ini sengaja dikosongkan)
LAMPIRAN A Lampiran A-1
Berikut adalah lampiran mengenai detail use case tiap aplikasi.
Tabel 40. Use Case Trans ITS Nama
Aplikasi
Nomor Use Case
Nama Use Case
Nomor
Transaksi Tipe Flow Aktivitas
Trans ITS 1 Sign Up 1 Main 1. User memasukkan data diri untuk
mendaftar
2. Sistem memvalidasi data yang di input 3. Verifikasi email
4. Pendaftaran berhasil, sistem menampilkan halaman utama 2 Alternate A 1. Data yang diinputkan tidak sesuai
2. Sistem menampilkan pesan error
2 Login 1 Main 1. User memasukkan data diri untuk
mendaftar
2. Sistem memvalidasi data yang di input 3. Login berhasil, sistem menampilkan
halaman utama
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor
Transaksi Tipe Flow Aktivitas
2 Alternate A 1. User salah menginputkan data login 2. Sistem menampilkan pesan error 3
Melakukan Pencarian Halte
1 Main 1. User menggunakan text box untuk mencari halte
2. User menginputkan beberapa kata 3. Sistem melakukan prediksi pada
pencarian user
4. User mengklik query pencarian
5. Sistem menampilkan hasil sesuai dengan pencarian
2 Main 1. User mentap hasil pencarian
2. Sistem menampilkan lokasi halte pada map
3. User mentap halte pada map 4. Sistem menampilkan informasi yang
terkait pada halte tersebut
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor
Transaksi Tipe Flow Aktivitas
3 Main 1. User mentap tombol Get Alert pada tampilan informasi halte
2. Sistem akan mengingatkan user setiap ada bus yang berhenti di halte tersebut
4 Get Bus Info 1 Main 1. User mengklik tombol Bus Info
2. Sistem akan mencari info terkait pada bus yang terpilih
3. Sistem akan menampilkan informasi akan jadwal bus dan data pengenal sopir bus tersebut
5
Pinpoint Lokasi Sekarang
1 Main 1. User mengklik tombon Pinpoint 2. Sistem akan mencari lokasi user berada
melalui GPS
3. Sistem akan menampilkan layar maps tempat user berada dan bus berada
6 Manage User 1 Main 1. User mengklik icon profil user
Nama
Transaksi Tipe Flow Aktivitas Profile
2. Sistem menampilkan data diri user 3. User dapat mengubah data diri 4. Sistem memvalidasi input 5. User profile terupdate 2 Main 1. User mengklik tombol logout
Tabel 41. Use Case Studylicious
Nama
Flow Aktivitas
Studylicious 1 Login 1 Main 1. User memasukkan email dan
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
2 Alternate
A 1. User klik lupa password
2. User masuk ke browser
3. Sistem mengirim link reset
password ke email
4. Verifikasi link di email
5. Mengganti password lama ke
baru
6. Kembali ke aplikasi
7. Login, dan masuk ke homepage
3 Alternate
B
1. User login langsung menggunakan akun gmail
2. User klik tombol gmail
3. User memilih akun gmail yang
akan dipakai
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
4. Sistem memverifikasi akun
gmail
5. Berhasil login, sistem
menampilkan homepage
4 Alternate
C 1. User belum memiliki akun
2. Klik tombol Registrasi sekarang
3. User mengisi data diri dan
mengupload foto
4. User memverifikasi akun
melalui email
5. Setelah semua proses selesai, user akan dikembalikan ke halaman login
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
5 Alternate
D
1. Data yang dimasukkan ke kolom login salah/tidak valid (ex : karena sudah terdaftar)
2. Sistem menampilkan pesan error
ke user
2 Melakukan
Challenge 1 Main 1. User klik tombol piala
2. User memilih mata pelajaran
3. Sistem memberi respon dengan pilihan mulai atau batal tantangan
4. User memulai mengerjakan soal
5. Sistem menyimpan histori
pengerjaan
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
6. User naik level sejumlah
tantangan yang dikerjakan
2 Alternate
A
1. User ingin memfilter kategori tantangan
2. User scroll down pilihan
kategori
3. Sistem menyaring tantangan
sesuai kategori input user
4. Sistem menampilkan tantangan
yang sesuai filter
3 Alternate
B
1. User ingin membagikan hasil tantangan tapi tidak bisa karena sedang dalam development
2. Sistem menampilkan pesan error
ke user
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
4 Alternate
C
1. User tidak bisa melakukan tantangan karena level tidak cukup
2. Sistem menampilkan pesan error
ke user
3 Setting Akun 1 Main 1. User ingin redeem coin
2. Memilih tipe pembayaran
dengan google play
3. Sistem memvalidasi pembayaran
4. Coin diterima
5. Muncul histori pembayaran
2 Alternate
A
1. User ingin membeli coin dengan metode transfer ATM
2. Transfer uang ke rekenening
yang dituju
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
3. Konfirmasi melalui WA
4. Masukkan token ke aplikasi dari
WA
5. Pembayaran berhasil
3 Alternate
B
1. User tidak memasukkan kode token yang benar
2. Sistem menampilkan pesan error
ke user
4 Main 1. User ingin chat dengan user lain
2. User klik tombol Chat
3. User bisa memulai chatting
dengan user lain
5 Alternate
B
1. User belum berteman dengan user lain (mutual follow)
Nama
Flow Aktivitas
2. Sistem akan menampilkan pesan bahwa user harus saling berteman terlebih dahulu
6 Main 1. User ingin memberikan feedback
akan aplikasi
2. User mengklik tombol WA
kontak yang tersedia
3. User akan diarahkan ke WA untuk chat dengan costumer service
7 Alternate
A
1. User ingin memberikan feedback tidak melalui WA
2. User klik tombol media sosial
lain yang akan digunakan
3. Sistem akan mengarahkan user
ke media sosial tersebut
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
8 Alternate
B
1. User belum pernah memberikan feedback sama sekali terhadap aplikasi
2. Sistem akan mendeteksi rating
dari user, jika belum maka:
3. Sistem akan menampilkan dialog box agar user memberi rating melalui Google Play
4. Sistem akan mengarahkan user
ke Google Play
5. User memberi rating
9 Main 1. User memasukkan pertanyaan ke
kolom yang disediakan
2. Memilih kategori dan jenjang
pertanyaan
3. User mengupload foto tambahan
Nama Aplikasi
Nomor Use Case
Nama Use Case
Nomor Transaksi
Tipe
Flow Aktivitas
4. Sistem menerima data
5. Sistem menampilkan status di
newsfeed
10 Main 1. User memasukkan data diri dan
mengupload foto
2. User memilih jenjang
pendidikan
3. Sistem menyimpan data diri user
4. User klik tombol Simpan
5. Sistem memberikan pesan data
sudah tersimpan
6. Kembali ke homepage
4 Melakukan
Kontes 1 Main 1. User klik Kontes Saya
Nama
Flow Aktivitas
2. Sistem akan mengarahkan user
untuk mengerjakan soal
3. Sistem akan menilai hasil dari
1. User tidak dapat mengerjakan Kontes
2. Sistem akan menampilkan pesan
bahwa level user belum cukup
3 Alternate
B
1. User tidak dapat melihat kontes yang terbaru
2. User swipe layar keatas untuk
merefresh
Nama Aplikasi
Nomor Use Case
Nama Use
Nama Use