Evaluasi: Tahap 3 · Medium

Sebuah klinik ingin memberikan program obat gratis bagi pasien kelompok usia rentan, yaitu lansia (usia 60 tahun ke atas) ATAU anak balita (usia 5 tahun ke bawah).

Algoritma yang ditulis oleh staf perawat:

1. Baca usia pasien.

2. Jika (usia >= 60 DAN usia <= 5):

Status = "Obat Gratis"

3. Jika tidak:

Status = "Obat Berbayar"

4. Tampilkan Status.

Masalah: Saat sistem digunakan, tidak pernah ada satu pun pasien yang mendapatkan status obat gratis, baik kakek usia 70 tahun maupun bayi usia 2 tahun.

Tuliskan di kertas: (1) letak kesalahan logika dan penyebabnya, (2) perbaikan kondisi yang tepat, (3) hasil pengujian untuk usia 70, 2, dan 25 tahun.

Letak kesalahan: Kondisi (usia >= 60 DAN usia <= 5) menggunakan operator DAN.

Penyebab kegagalan: Tidak ada satu pun angka usia yang bisa bernilai lebih besar atau sama dengan 60 sekaligus lebih kecil atau sama dengan 5 pada saat bersamaan. Kondisi ini secara matematis selalu SALAH (kontradiksi mutlak).

Perbaikan algoritma: Ganti operator "DAN" dengan operator "ATAU":

Jika (usia >= 60 ATAU usia <= 5): Status = "Obat Gratis"

Pengujian kondisi setelah perbaikan:

- Usia 70: 70 >= 60 bernilai BENAR -> Obat Gratis.

- Usia 2: 2 <= 5 bernilai BENAR -> Obat Gratis.

- Usia 25: 25 >= 60 SALAH dan 25 <= 5 SALAH -> Obat Berbayar.

Diberikan rancangan algoritma pengiriman saldo dompet digital dari Akun A (pengirim) ke Akun B (penerima):

1. Baca nominal transfer.

2. Tambahkan saldo Akun B sebesar nominal transfer.

3. Kurangi saldo Akun A sebesar nominal transfer.

4. Jika saldo Akun A < 0:

Tampilkan pesan "Saldo Anda tidak cukup, transaksi gagal."

Batalkan transaksi.

5. Selesai.

Tuliskan di kertas: (1) mengapa urutan langkah di atas berbahaya dan salah secara logika transaksi, (2) potensi skenario kegagalan data jika sistem mati di tengah proses, (3) susunan algoritma perbaikan yang aman.

Kelemahan logika & risiko:

- Validasi dilakukan setelah mutasi data: Saldo penerima sudah terlanjur ditambah dan saldo pengirim sudah terlanjur dikurangi sebelum memastikan apakah pengirim memiliki saldo yang mencukupi.

- Jika koneksi putus atau sistem mati di antara langkah 2 dan 4, penerima sudah menerima uang sementara pembatalan belum sempat dieksekusi, menyebabkan ketidakkonsistenan saldo (saldo tercipta dari ketiadaan).

Urutan algoritma yang benar (Defensive & Atomic):

1. Baca nominal transfer.

2. Validasi input: pastikan nominal > 0.

3. Periksa kecukupan saldo: Jika saldo Akun A < nominal:

Tampilkan "Saldo tidak mencukupi, transaksi dibatalkan."

Berhenti (Selesai).

4. Jika saldo mencukupi:

Kurangi saldo Akun A sebesar nominal.

Tambahkan saldo Akun B sebesar nominal.

Tampilkan "Transfer berhasil."

5. Selesai.

Diberikan algoritma penghitung rata-rata nilai kuis kelas:

1. Inisialisasi total = 0.

2. Hitung jumlah_siswa = banyak_data(daftar_nilai).

3. Untuk setiap nilai dalam daftar_nilai: total = total + nilai.

4. rata_rata = total / jumlah_siswa.

5. Tampilkan rata_rata.

Masalah: Pada saat kelas baru dibuka dan belum ada satu pun siswa yang mengumpulkan kuis (daftar_nilai kosong), program mengalami crash fatal (error sistem).

Tuliskan di kertas: (1) penyebab persis terjadinya error crash, (2) pada baris nomor berapa kesalahan terjadi, (3) rancangan perbaikan algoritma agar menangani data kosong secara anggun (graceful).

Penyebab error crash:

- Ketika daftar_nilai kosong, banyak_data(daftar_nilai) menghasilkan jumlah_siswa = 0.

- Pada langkah 4, dilakukan operasi `total / jumlah_siswa` yang sama dengan `0 / 0`. Pembagian dengan angka nol (Division by Zero) adalah operasi aritmetika tidak terdefinisi yang memicu crash/eksepsi fatal di hampir seluruh bahasa pemrograman.

Perbaikan algoritma:

1. Inisialisasi total = 0.

2. Hitung jumlah_siswa = banyak_data(daftar_nilai).

3. Jika jumlah_siswa == 0:

Tampilkan "Belum ada data nilai siswa."

Selesai.

4. Untuk setiap nilai dalam daftar_nilai: total = total + nilai.

5. rata_rata = total / jumlah_siswa.

6. Tampilkan rata_rata.

7. Selesai.

Sebuah restoran memberlakukan ketentuan pembayaran:

- Pajak Restoran: 10% dari total harga makanan/minuman.

- Biaya Layanan (Service Charge): 5% dari total harga makanan/minuman.

Staf kasir membuat algoritma penghitungan nota sebagai berikut:

1. Baca subtotal_makanan.

2. total = subtotal_makanan + (subtotal_makanan * 10 / 100).

3. total = total + (total * 5 / 100).

4. Tampilkan total.

Keluhan: Pelanggan memprotes bahwa biaya layanan yang ditagihkan lebih besar dari 5% harga makanan, dan pemilik restoran dituduh memungut pajak ganda.

Tuliskan di kertas: (1) bukti matematis letak kesalahan perhitungan di atas, (2) penjelasan mengapa langkah tersebut merugikan pelanggan, (3) algoritma perbaikan yang menghitung pajak dan layanan masing-masing dari subtotal makanan asli.

Bukti matematis kesalahan:

- Misal subtotal_makanan = Rp100.000.

- Langkah 2: total = 100.000 + 10.000 = Rp110.000 (sudah memuat pajak).

- Langkah 3: layanan dihitung dari total baru: 110.000 * 5% = Rp5.500, total akhir = Rp115.500.

- Seharusnya biaya layanan 5% dari Rp100.000 adalah Rp5.000, total akhir Rp115.000. Selisih Rp500 adalah biaya layanan yang dikenakan di atas pajak (pajak dikenai biaya layanan).

Perbaikan algoritma yang adil dan transparan:

1. Baca subtotal_makanan.

2. pajak = subtotal_makanan * 0.10

3. biaya_layanan = subtotal_makanan * 0.05

4. total_akhir = subtotal_makanan + pajak + biaya_layanan

5. Tampilkan rincian: subtotal, pajak, biaya layanan, dan total akhir.

6. Selesai.

Sebuah lift gedung kantor memiliki batas kapasitas beban maksimal 500 kg.

Algoritma kontrol pintu dan alarm lift saat ini:

1. Baca total_beban dari sensor lantai lift.

2. Jika total_beban > 500:

Bunyikan alarm dan biarkan pintu terbuka.

3. Jika tidak:

Tutup pintu dan jalankan lift.

Masalah kasus batas (Boundary Edge Cases):

- Saat sekelompok orang masuk dengan beban tepat 500.0 kg, lift tetap berjalan. Namun teknisi menemukan bahwa sensor memiliki margin fluktuasi +-1.5 kg.

- Saat beban 500.2 kg, pintu tetap menutup karena sensor membaca pembulatan ke bawah jika tidak ditentukan presisinya.

Tuliskan di kertas: (1) evaluasi kondisi batas saat beban tepat 500 kg dan sedikit di atasnya, (2) risiko keamanan jika toleransi sensor diabaikan, (3) perbaikan algoritma dengan aturan batas aman (safety threshold) yang jelas.

Evaluasi kasus batas:

- Kondisi `> 500` berarti beban tepat 500.00 kg dianggap lolos. Namun jika ada penumpang bergerak sedikit saja, beban dinamis sesaat bisa melonjak melewati batas aman.

- Jika pembacaan sensor memiliki ketidakpastian +-1.5 kg, beban riil 501 kg mungkin terukur 499.5 kg sehingga lift tetap berjalan dengan beban berlebih berbahaya.

Rancangan perbaikan batas aman:

1. Tentukan batas aman operasional dengan margin keamanan (misal batas cut-off alarm = 500 kg, dengan toleransi pencegahan).

2. Baca beban sensor dengan presisi floating-point.

3. Jika total_beban >= 500.0:

Bunyikan alarm kelebihan beban.

Tampilkan pesan "Kelebihan beban, mohon kurangi penumpang."

Kunci pintu dalam kondisi terbuka penuh sampai beban turun di bawah 480 kg (histeresis agar tidak buka-tutup berulang).

4. Jika total_beban < 500.0:

Matikan alarm, tutup pintu, dan lanjutkan perjalanan.