Studi kasus · Studi kasus

Fokus SL yang didukung. Target penilaian pertama 2027; PDF resmi mengembalikan 403; brief perolehan lama adalah penilaian akhir 2026. Panduan, persyaratan penilaian, dan praktis lainnya tetap mempertahankan catatan yang tercatat.

Prasyarat: baca kuantitas dan satuan yang disebutkan, gunakan aritmatika, dan kondisi model di bawah ini. Setiap pelajaran mengembangkan metodenya sendiri sebelum transfer mandiri.

Ini adalah contoh pengajaran asli atau fiksi eksplisit, bukan pengukuran aktual atau penyelidikan pembelajaran yang selesai dan dinilai.

Apa yang akan menjelaskan observasi ini?

• Sistem pemesanan sekolah yang diusulkan terlihat efisien, namun rekomendasinya bergantung pada pengguna, batasan, dan bukti. Istilah teknis yang masuk akal saja tidak menjadi keputusan yang dibenarkan.
• Mulailah dengan prediksi. Nyatakan besaran atau fitur apa yang akan Anda bandingkan, lalu tentukan bukti apa yang dapat membedakan dua penjelasan.

Bangun modelnya

• Studi kasus menempatkan pilihan komputasi dalam skenario yang dinyatakan. Identifikasi pemangku kepentingan, persyaratan, bukti yang tersedia, dan batasan sebelum merekomendasikan arsitektur atau algoritma. Bedakan fakta skenario dari asumsi dan prediksi. Trade-off dapat melibatkan kinerja, keandalan, aksesibilitas, privasi, pemeliharaan, dan biaya.
• throughput: Pekerjaan selesai per satuan waktu di bawah beban kerja yang dinyatakan; uji penerimaan: Tes apakah persyaratan pengguna yang ditentukan terpenuhi.

Pilih bukti yang dapat mengujinya

• Rekomendasi harus menghubungkan persyaratan dengan mekanisme dan tes yang dapat diamati. Misalnya, masalah konkurensi memerlukan strategi yang mencegah pembaruan yang bertentangan, plus tes yang menunjukkan invarian. Klaim tentang respons lebih cepat memerlukan pengukuran beban kerja yang sebanding daripada hanya label kompleksitas. Evaluasi alternatif di bawah kondisi yang sama yang dinyatakan.
• Gunakan skenario asli yang disetujui sekolah dan data sintetis. Buat matriks klaim, bukti skenario pendukung, penjelasan teknis, keterbatasan, dan uji penerimaan. Tandai fakta yang hilang secara eksplisit dan tunjukkan bagaimana rekomendasi akan berubah jika asumsi gagal. Ini mempersiapkan penalaran berbasis kasus tanpa mereproduksi studi kasus penilaian IB yang tidak tersedia atau membuat rubrik ujian secara sembarangan.

Bekerja dari kuantitas yang diketahui

• Nyatakan nilai yang diketahui dan unitnya. Pilih hubungan kerana asumsinya sesuai dengan kes ini, kemudian susun semula sebelum menggantikan.
• Diketahui: prototipe fiksi memproses 120 permintaan sukses selama pengamatan 30 detik. Throughput adalah 120/30=4 permintaan sukses/detik. Prototipe kedua memproses 150 dalam 30 detik, atau 5/detik. yang kedua memiliki 25% throughput tercatat lebih tinggi, tetapi tidak ada kesimpulan tentang latensi, tingkat kegagalan, atau kinerja di bawah beban kerja yang lebih besar yang dapat ditarik tanpa pengukuran tersebut.

Contoh:

Sistem fiksi berhasil memproses 210 permintaan dalam 30 s. Hitung throughput. Gunakan urutan yang sama: jumlah diketahui → model → relasi → substitusi → unit dan interpretasi.

Periksa kesimpulan dan batasannya

• Throughput bukanlah waktu respons. Rekomendasi kuat menyatakan kondisi di mana hal itu diharapkan berfungsi dan bukti yang dapat membantahnya. Persyaratan studi kasus CS resmi saat ini harus dicek terhadap versi penilaian yang berlaku.
• Kembali ke pengamatan awal. Jelaskan apa hasil tersebut mendukung, kondisi apa yang diasumsikannya, dan satu cara untuk menguji penjelasan saingan.

Peringatan:

Throughput yang lebih tinggi secara otomatis membuktikan waktu respons yang lebih rendah untuk setiap permintaan. Klaim ini salah: Throughput bukanlah waktu respons. Rekomendasi kuat menyatakan kondisi di mana hal itu diharapkan berfungsi dan bukti yang dapat membantahnya. Persyaratan studi kasus CS resmi saat ini harus dicek terhadap versi penilaian yang berlaku.

Kunci:

Analisis kasus komputasi: evaluasi sistem yang diusulkan: sebuah rekomendasi harus menghubungkan kebutuhan dengan mekanisme dan tes yang teramati. Sebagai contoh, masalah konvergensi memerlukan strategi yang mencegah pembaruan yang bertentangan, plus tes yang menunjukkan invarian. Klaim tentang waktu respons yang lebih cepat memerlukan pengukuran beban kerja yang可比 daripada hanya label kompleksitas. Evaluasi alternatif di bawah kondisi yang sama yang ditetapkan.

Jejak dan batas dapat dijalankan

for successful, attempted, seconds in [(240, 300, 30), (270, 300, 30)]:
    if seconds <= 0 or attempted <= 0:
        raise ValueError("Positive exposure required")
    throughput = successful / seconds
    failure_fraction = (attempted - successful) / attempted
    print(throughput, failure_fraction)

Output yang diharapkan:

8.0 0.2
9.0 0.1

Throughput sukses dan fraksi kegagalan menggunakan penyebut berbeda. Waktu nol atau percobaan nol tidak dapat mendukung laju tersebut. Ringkasan fiksi ini tidak menyediakan bukti latensi, biaya, atau beban perwakilan.