Artikel ini dulu saya tulis sebagai guideline dalam persiapan soal di TOKI. Tetapi saya rasa artikel ini juga akan berguna bagi rekan-rekan yang ingin mempersiapkan kompetisi-kompetisi pemrograman. Semoga bisa sedikit banyak membantu meningkatkan kualitas kompetisi pemrograman di Indonesia.
Tahap-tahap pemrosesan sebuah soal yang sudah cukup ideal menurut saya dan biasa saya terapkan, saya jelaskan sebagai berikut.
2.1 Verifikasi ide penyelesaian
Tidak ada gunanya memproses soal apabila idenya belum tentu benar. Kesalahan yang ditemukan di saat-saat berikutnya akan sangat membuang waktu. Oleh karena itu, biasakan mem-verifikasi algoritma penyelesaian baik deng an pembuktian matematis, apabila tidak terlalu obvious. Apabila author kurang yakin, ia perlu untuk mendiskusikan idenya dengan orang lain yang dianggap mampu melakukan verifikasi. Poin ini akan meningkatkan efisiensi karena meminimialisir waktu terbuang, akan tetapi lebih bersifat opsional karena tidak mempengaruhi kualitas soal (apabila ternyata ada error, pada akhirnya akan ditemukan pada fase testing. Tetapi tentu waktu sudah banyak terbuang).
2.2 Pembentukan Deskripsi dan Testcase Generation
Kedua poin ini saya satukan karena biasanya dilakukan secara hampir bersamaan. Yang mana dilakukan lebih dahulu tidak terlalu penting apabila pembuat testcase adalah juga merupakan pembuat soal. Akan tetapi, Pembentukan Deskripsi perlu dilakukan lebih dahulu apabila testcase dibuat oleh orang lain.
2.3 Deployment Soal pada Server
Soal hasil 2.1 dan 2.2 beserta test data dan checker (apabila diperlukan) harus dipasang dulu pada server yang akan digunakan di kontes sebelum lanjut ke tahap 2.4.
2.4 Testing
Melewatkan fase ini adalah kesalahan yang paling sering saya lihat pada penyelenggara sebuah kontes. Fase ini terdiri dari empat subtahap, yang saya tulis secara berurutan:
2.4.1 Testing Deskripsi 1
Deskripsi harus di-proofread oleh pihak ketiga yang sama sekali tidak ikut dalam tahapan 2.1 dan 2.2 karena para pelaku tahap 2.1 dan 2.2 bisa saja memiliki asumsi yang secara tidak disadari berbeda dari soal. Fase ini sangat penting karena berbagai ketidakjelasan di soal dapat teratasi.
Deskripsi harus sangat jelas dan tidak boleh ambigu. Ini adalah hal yang sangat sulit, bahkan bagi orang-orang yang sudah berpengalaman. Proofreader harus adalah orang yang terbiasa dengan penulisan deskripsi yang baik pada soal pemrograman dan sangat teliti serta sensitif pada berbagai kesalahan, termasuk kesalahan pengetikan, penggunaan bahasa yang tidak baik, dan sebagainya.
Biasanya, kami memiliki beberapa orang yang saya rasa sangat layak untuk menjadi proofreader. Tetapi tidak semua orang yang memiliki performansi baik pada kompetisi pemrograman adalah proofreader yang baik.
2.4.2 Testing Test Data dan Checker
Testing subtahap ini terdiri dari dua sub sub tahap:
2.4.2.1 Testing dengan Solusi Benar
Tester ini boleh saja merupakan proofreader pada poin 2.3.1, tetapi tidak boleh merupakan seseorang yang terlibat dalam tahap 2.1 dan 2.2. Tester harus melakukan testing tanpa mengetahui solusi (maupun spoiler solusi) dari pembuat soal. Ia harus menemukan sendiri solusi soal tersebut dari awal tanpa pengaruh dan bantuan pihak yang terlibat pada 2.1 maupun 2.2, meskipun boleh dibantu orang lain.
2.4.2.1 Testing dengan Solusi-solusi Salah
Tester yang satu ini boleh siapapun, termasuk pihak yang terlibat dalam tahap 2.1 dan 2.2. Tester mengimplementasikan solusi-solusi salah untuk menguji ketangguhan test data.
2.4.3 Testing Deskripsi 2
Pada 2.3.2, bisa saja Tester menemukan lagi kesalahan pada deskripsi sehingga deskripsi dimodifikasi lebih lanjut. Hasil modifikasi tersebut harus di-proofread sekali lagi agar tidak terjadi kesalahan karena modifikasi. Ini bisa oleh siapa saja termasuk pihak yang terlibat pada tahapan 2.1 dan 2.2.
2.4.4 Validasi Input
Tahap ini sangat penting karena kesalahan apapun pada berkas masukan sangat fatal. Untungnya, testing ini sangat mudah boleh dilakukan siapapun. Testing dilakukan dengan cara memodifikasi program solusi juri dengan menambahkan assertions yang akan memberikan runtime error apabila format masukan tidak benar maupun ada masukan yang tidak sesuai dengan batasan maupun kriteria yang diberikan pada deskripsi. Program hasil modifikasi ini harus dibuat se-strict mungkin agar bisa menangkap kesalahan format sekecil mungkin.
Apabila hasil testing menemukan kesalahan maupun kelemahan pada test data, kesalahan dan kelemahan itu harus segera diperbaiki, dan semua solusi tester harus di-regrade untuk memastikan hasil modifikasi sesuai yang diharapkan.
2.5 Selesai
Soal sudah siap digunakan.
Dengan prosedur tersebut, sebagian besar kesalahan dapat ditemukan dengan mudah. Meskipun ada desakan waktu, seluruh tahap, subtahap, dan subsubtahap tetap harus dikerjakan.
Banyak pihak minimum untuk mempersiapkan soal adalah 3: penulis soal mengerjakan 2.1, 2.2, dan 2.3, kemudian dua orang tester untuk melakukan 2.4.