{"id":22,"date":"2014-01-25T23:17:01","date_gmt":"2014-01-25T23:17:01","guid":{"rendered":"http:\/\/www.risanp.com\/articles\/?p=22"},"modified":"2016-04-22T04:58:57","modified_gmt":"2016-04-22T04:58:57","slug":"problem-development-process","status":"publish","type":"post","link":"https:\/\/www.risanp.com\/notes\/?p=22","title":{"rendered":"Problem Development Process"},"content":{"rendered":"

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.<\/strong><\/em><\/p>\n

Tahap-tahap pemrosesan sebuah soal yang sudah cukup ideal menurut saya dan biasa saya terapkan, saya jelaskan sebagai berikut.
\n<\/p>\n

2.1 Verifikasi ide penyelesaian<\/strong><\/p>\n

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\u00a0<\/em>an pembuktian matematis, apabila tidak terlalu\u00a0obvious<\/em>. Apabila\u00a0author<\/em>\u00a0kurang 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).<\/p>\n

2.2 Pembentukan Deskripsi dan\u00a0Testcase Generation<\/em><\/strong><\/p>\n

Kedua poin ini saya satukan karena biasanya dilakukan secara hampir bersamaan. Yang mana dilakukan lebih dahulu tidak terlalu penting apabila pembuat\u00a0testcase<\/em>\u00a0adalah juga merupakan pembuat soal. Akan tetapi, Pembentukan Deskripsi perlu dilakukan lebih dahulu apabila\u00a0testcase<\/em>\u00a0dibuat oleh orang lain.<\/p>\n

2.3 Deployment Soal pada Server<\/strong><\/p>\n

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.<\/p>\n

2.4 Testing<\/strong><\/p>\n

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:<\/p>\n

2.4.1 Testing Deskripsi 1<\/strong><\/p>\n

Deskripsi harus di-proofread<\/em>\u00a0oleh 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.<\/p>\n

Deskripsi harus sangat jelas dan tidak boleh ambigu. Ini adalah hal yang sangat sulit, bahkan bagi orang-orang yang sudah berpengalaman.\u00a0Proofreader<\/em>\u00a0harus 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.<\/p>\n

Biasanya, kami memiliki beberapa orang yang saya rasa sangat layak untuk menjadi\u00a0proofreader<\/em>. Tetapi tidak semua orang yang memiliki performansi baik pada kompetisi pemrograman adalah\u00a0proofreader<\/em>\u00a0yang baik.<\/p>\n

2.4.2 Testing\u00a0Test Data<\/em>\u00a0dan\u00a0Checker<\/em><\/strong><\/p>\n

\u00a0<\/em>Testing subtahap ini terdiri dari dua sub sub tahap:<\/p>\n

2.4.2.1 Testing dengan Solusi Benar<\/strong><\/p>\n

Tester<\/em>\u00a0ini boleh saja merupakan\u00a0proofreader<\/em>\u00a0pada poin 2.3.1, tetapi tidak boleh merupakan seseorang yang terlibat dalam tahap 2.1 dan 2.2.\u00a0Tester<\/em>\u00a0harus melakukan\u00a0testing<\/em>\u00a0tanpa mengetahui solusi (maupun\u00a0spoiler<\/em>\u00a0solusi) 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.<\/p>\n

2.4.2.1 Testing dengan Solusi-solusi Salah<\/strong><\/p>\n

Tester<\/em>\u00a0yang satu ini boleh siapapun, termasuk pihak yang terlibat dalam tahap 2.1 dan 2.2.\u00a0Tester\u00a0<\/em>mengimplementasikan solusi-solusi salah untuk menguji ketangguhan test data.<\/p>\n

2.4.3 Testing Deskripsi 2<\/strong><\/p>\n

Pada 2.3.2, bisa saja\u00a0Tester<\/em>\u00a0menemukan lagi kesalahan pada deskripsi sehingga deskripsi dimodifikasi lebih lanjut. Hasil modifikasi tersebut harus di-proofread<\/em>\u00a0sekali lagi agar tidak terjadi kesalahan karena modifikasi. Ini bisa oleh siapa saja termasuk pihak yang terlibat pada tahapan 2.1 dan 2.2.<\/p>\n

2.4.4 Validasi\u00a0Input<\/em><\/strong><\/p>\n

Tahap ini sangat penting karena kesalahan apapun pada berkas masukan sangat fatal. Untungnya, testing<\/em>\u00a0ini sangat mudah boleh dilakukan siapapun.\u00a0Testing\u00a0<\/em>dilakukan dengan cara memodifikasi program solusi juri dengan menambahkan\u00a0assertions<\/em>\u00a0yang 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<\/em>\u00a0mungkin agar bisa menangkap kesalahan format sekecil mungkin.<\/p>\n

Apabila hasil testing menemukan kesalahan maupun kelemahan pada test data, kesalahan dan kelemahan itu harus segera diperbaiki, dan semua solusi\u00a0tester\u00a0<\/em>harus di-regrade<\/em>\u00a0untuk memastikan hasil modifikasi sesuai yang diharapkan.<\/p>\n

2.5 Selesai<\/strong><\/p>\n

Soal sudah siap digunakan.<\/p>\n

Dengan prosedur tersebut, sebagian besar kesalahan dapat ditemukan dengan mudah. Meskipun ada desakan waktu, seluruh tahap, subtahap, dan subsubtahap tetap harus dikerjakan.<\/p>\n

Banyak pihak minimum untuk mempersiapkan soal adalah 3: penulis soal mengerjakan 2.1, 2.2, dan 2.3, kemudian dua orang\u00a0tester\u00a0<\/em>untuk melakukan 2.4.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-22","post","type-post","status-publish","format-standard","hentry","category-programming-competition"],"_links":{"self":[{"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=\/wp\/v2\/posts\/22"}],"collection":[{"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=22"}],"version-history":[{"count":4,"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=\/wp\/v2\/posts\/22\/revisions"}],"predecessor-version":[{"id":26,"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=\/wp\/v2\/posts\/22\/revisions\/26"}],"wp:attachment":[{"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=22"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=22"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.risanp.com\/notes\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=22"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}