BAB IV HASIL DAN PEMBAHASAN

Transkripsi

1 BAB IV HASIL DAN PEMBAHASAN Wawancara dilakukan terhadap setiap penanggung jawab divisi perusahaan yang terdiri atas kebun, gudang, pabrik, administrasi/pemasaran, dan kepegawaian. Pada wawancara tersebut dihasilkan gambaran proses bisnis yang terjadi di perusahaan. Hal-hal lain seperti rencana di lima tahun ke depan seperti implementasi smartphone pun menjadi harapan dari implementasi sistem yang sedang diteliti. Wawancara dilakukan mulai dari awal tahun 2012 hingga bulan Agustus 2012 dan menghasilkan daftar kebutuhan dari sistem beserta detail lainnya. Setelah dilakukan wawancara dan pengumpulan informasi kebutuhan sistem dari sistem yang sedang berjalan, diperoleh beberapa informasi yang akan digunakan sebagai dasar perancangan dan pengembangan sistem yang akan dibangun. Wawancara lanjutan dilakukan kepada setiap penanggung jawab bagian di setiap divisi perusahaan untuk memverifikasi gambaran proses bisnis hasil wawancara sebelumnya dengan hasil analisis terhadap sistem yang sedang berjalan. Pada bagian ini juga diidentifikasi permasalahan-permasalahan yang ada yang menjadi kendala dalam implementasi pada sistem yang berjalan. Secara garis besar, hasil wawancara dan analisa terhadap sistem yang sedang berjalan dijelaskan pada bagian selanjutnya. 4.1 Domain permasalahan PT. Sasaran Ehsan Mekarsari (PT. SEM) merupakan perusahaan yang bergerak di bidang pembibitan dan penelitian kelapa sawit. Secara garis besar, perusahaan ini melakukan penelitian kelapa sawit yang dimulai dari bibit hingga tanaman dewasa. PT. SEM memiliki beberapa divisi perusahaan di dalamnya yaitu: 1. Kebun (garden) 2. Gudang (warehouse) 3. Pabrik (seed garden factory SGF) 4. Administrasi dan pemasaran (marketing) 5. Kepegawaian (human resources) 27

2 28 Setiap divisi dari perusahaan saling berhubungan satu sama lain sebagai sebuah kesatuan sehingga segala proses yang terjadi di perusahaan dapat berjalan lancar. Setiap bagian tersebut memiliki fungsi dan tugas masing-masing seperti uraian berikut ini: Kebun (garden) Bagian kebun merupakan bagian utama dari PT. SEM, karena pada bagian inilah kegiatan pembibitan dan penelitian berlangsung. Aktivitas yang dilakukan di kebun sesuai hasil wawancara terdiri atas beberapa bagian, mulai dari pembibitan hingga pemanenan. Pengelompokkan menjadi satu domain didasarkan pada hasil wawancara sebagai berikut: Kebun dimulai dengan penerimaan kecambah dari pabrik, lalu ditanam di pembibitan prenursery, dan seterusnya hingga dipanen beberapa tahun kemudian. Walau prosesnya cukup panjang, namun pengelolaannya masih dilakukan di bawah mandor kebun. Tahapan yang terjadi pada kebun adalah: a) Pembibitan prenursery Aktivitas ini berfokus pada proses pembibitan awal yang dimulai dari bibit belum tumbuh hingga menjadi kecambah berusia 3 bulan. Setelah kecambah tersebut sudah berusia 3 bulan maka proses berlanjut pada bagian pembibitan mainnursery (repotting). Aktivitas yang terjadi pada pembibitan prenursery yaitu: Penyiapan kantong plastik (polibeg), kegiatan pengisian kantong plastik dengan tanah sebagai persediaan media tanam bibit. Penanaman bibit, kegiatan penanaman bibit ke dalam kantong polibeg kecil. Repotting, proses pemindahan bibit dari kantong polibeg kecil ke kantong polibeg besar pada pembibitan mainnursery. Penyeleksian bibit rusak/mati, proses pemilihan bibit yang rusak/mati dan menyingkirkannya dari lahan pembibitan. Penjualan bibit, pemindahan bibit dari lahan pembibitan untuk dijual ke konsumen. Sensus pokok, perhitungan jumlah tanaman berdasarkan usia dan varietasnya.

3 29 b) Pembibitan mainnursery Aktivitas lanjutan dari prenursery yang berfokus untuk memelihara dan membesarkan tanaman hingga siap tanam di medan sesungguhnya. Kegiatan pembibitan mainnursery akan berlangsung selama 9 bulan sehingga tanaman yang keluar dari tahap ini dapat ditanam atau dijual ke konsumen. Aktivitas yang terjadi pada tahap ini yaitu: Penanaman bibit, kegiatan penanaman bibit ke dalam kantong polibeg kecil. Transplanting, proses pemindahan bibit dari kantong polibeg kecil ke kantong polibeg besar pada pembibitan mainnursery. Penyeleksian bibit rusak/mati, proses pemilihan bibit yang rusak/mati dan menyingkirkannya dari lahan pembibitan. Penjualan bibit, pemindahan bibit dari lahan pembibitan untuk dijual ke konsumen. Sensus pokok, perhitungan jumlah tanaman berdasarkan usia dan varietasnya c) Perawatan Kegiatan perawatan dilakukan per tanaman yang ada di kebun. Perawatan terdiri dari beberapa jenis dan dilakukan secara periodik maupun insidental (perawatan khusus). d) Penanaman tanaman Kegiatan penanaman dilakukan di kebun pada titik tanam yang kosong atau belum ditempati. Tanaman yang ditanam bisa berasal dari mainnursery maupun tanaman dewasa dari luar perusahaan. e) Penanaman tanaman pengganti/sulam/replanting Kegiatan replanting dilakukan karena tanaman tertentu di kebun telah tidak produktif lagi ataupun sudah mati sehingga perlu diganti dengan tanaman baru. Penanaman ini dilakukan pada titik tanam yang telah ditempati namun tanaman yang menempati tersebut tidak produktif lagi. f) Pembungkusan (bagging) Kegiatan pembungkusan dilakukan pada tandan/janjang (buah sawit betina) yang bertujuan sterilisasi tandan dari polen/serangga. Kegiatan ini dilakukan per tandan pada tandan yang sudah siap dikawin.

4 30 g) Polinasi Kegiatan polinasi tandan yang telah dibungkus/bagging dilakukan sekitar 12 hari setelah tandan dibungkus. Kegiatan polinasi dilakukan menggunakan serbuk sari/polen dari tanaman sawit pejantan (Pisifera). Tandan yang telah dikawinkan selanjutnya dibungkus lagi supaya terhidar dari serangan hama. h) Pemanenan Setelah sekitar 5 bulan tandan dipolinasi, tandan yang siap dipanen dipotong dan diambil yang selanjutnya akan diproses lebih lanjut. Selain tandan betina, tandan jantan yang berasal dari pohon sawit pejantan (Pisifera) dipanen juga sesuai dengan jadwal yang ada. i) Sensus Bunga Kegiatan sensus dilakukan setiap minggu terhadap seluruh tanaman yang ada di kebun. Kegiatan ini bertujuan mencatat jumlah tandan yang ada beserta keadaannya pada setiap pohon. j) Seleksi Pohon Induk Pohon induk sawit adalah pohon sawit yang memenuhi kriteria tertentu yang menunjukkan tanaman tersebut memiliki kualifikasi untuk dijadikan sumber bibit. Tidak semua tanaman yang menghasilkan bibit sawit dijadikan sebagai sumber bibit. Pohon yang telah menjadi pohon induk akan diberikan perhatian lebih dibandingkan lainnya. Setiap aktivitas yang terjadi di kebun merupakan rangkaian dari perjalanan hidup bibit sawit tersebut, yang dimulai dari pembibitan prenursery hingga bibit tersebut tertanam sebagai pohon induk dan menghasilkan bibit lainnya yang siap ditanam atau dijual ke konsumen Gudang (warehouse) Gudang adalah tempat yang difungsikan untuk menyimpan barang sementara sebelum barang digunakan. Barang yang disimpan di gudang adalah semua jenis barang mulai dari bahan kimia, spare part, pupuk, dan sebagainya. Pada gudang terjadi beberapa aktivitas berikut :

5 31 a) Pembelian barang Pembelian barang baru atau barang lama yang sudah aus dilakukan dalam dua tahap: permohonan pembelian yang selanjutnya jika disetujui akan diproses pembelian dan barang yang datang akan dicatat. b) Pengeluaran barang Barang yang ada pada gudang akan keluar melalui dua tahap: bon permintaan barang yang selanjutnya jika disetujui maka barang akan dikeluarkan dan dicatat. c) Stock Opname Perhitungan stok atau jumlah yang ada pada setiap barang di gudang dilakukan setiap bulan yang selanjutnya akan dilaporkan kepada bagian Adminsitrasi Pabrik (factory) Buah sawit/tandan yang telah dipanen selanjutnya akan diproses di pabrik. Berbeda dengan pengolahan pada kebun produksi, output dari pabrik pengolahan ini bukanlah minyak sawit, tapi outputnya adalah biji yang siap tanam. Secara garis besar, tahap yang dilalui oleh setiap biji yang ada dimulai dari seleksi awal hingga seleksi akhir seperti pada Gambar 7. Gambar 7 Proses perkecambahan bibit kelapa sawit

6 32 Pabrik pengolahan terdiri atas beberapa proses: a) Serah terima tandan Proses pengolahan diawali dengan penyerahan tandan hasil panen (tandan betina) dari bagian kebun ke bagian pabrik. Pada tahap ini, biji tandan sudah terlepas dari batang tandan, namun masih dalam keadaan yang kotor sehingga perlu dibersihkan dan diseleksi pada tahap selanjutnya. b) Seleksi biji Biji sawit yang sudah terlepas dari tandannya akan dibersihkan dan diberi fungsida untuk mencegah jamur. Seleksi dilakukan terhadap biji yang afkir atau kosong sehingga biji yang akan diproses selanjutnya merupakan bibit yang baik. Pada tahap ini dilakukan pembungkusan biji sawit dan pelabelan bungkus tersebut berdasarkan sumber tandannya. Label ini selanjutnya akan menjadi identitas dari kantong tersebut pada beberapa tahap selanjutnya. Setiap tandan bisa saja terdiri atas dua atau lebih kantong dengan identitas yang sama, hal tersebut didasarkan pada dasarnya sumber mereka sama sehingga walaupun berada pada kantong yang berbeda namun sumber tandannya adalah sama. c) Ruang dingin Kantong biji sawit selanjutnya dapat masuk ke ruang dingin untuk disimpan sementara atau lebih lama jika pesanan terhadap biji sawit belum adasehingga proses perkecambahan perlu diperlambat. Pencatatan dilakukan dua kali, yaitu pada saat masuk dan keluar dari ruang ini, serta pemeriksaan terhadap biji yang mati atau berjamur harus dilakukan saat bibit keluar dari ruang dingin. Biji yang ada pada ruangan ini dapat bertahan hingga mencapai 2 tahun. d) Ruang panas Kantong biji sawit dapat masuk ke ruang panas jika bijinya hendak dikecambahkan untuk dijual atau ditanam. Pencatatan dilakukan terhadap kantong yang masuk maupun keluar dari ruangan ini serta pemeriksaan dilakukan saat bibit keluar dari ruang panas untuk menyingkirkan bibit yang kosong atau berjamur. Biji sawit berada pada ruangan ini selama kurang lebih 35 hari.

7 33 e) Perkecambahan Biji sawit yang siap berkecambah kemudian akan dimasukkan dalam ruang germinasi atau perkecambahan selama kurang lebih 30 hari hingga biji sudah berkecambah. Selanjutnya biji yang sudah berkecambah akan dipisahkan dari kantongnya dan disimpan di ruang dingin hingga kuota biji yang telah berkecambah mencukupi. Pencatatan dilakukan secara periodik untuk melihat perkembangan kecambah supaya tidak terlalu tinggi sehingga dapat langsung dipindahkan ke ruang dingin atau diproses ke tahap selanjutnya. Pemeriksaan terhadap biji yang kosong dan berjamur dilakukan untuk menghindari penyebaran jamurnya. Tidak semua biji yang dikecambahkan dapat tumbuh pada satu tahap, kadang beberapa biji harus dimasukkan ulang ke ruang panas lalu masuk lagi ke ruang germinasi pada putaran berikutnya supaya dapat tumbuh, proses ini disebut recycle. f) Seleksi akhir Kecambah yang siap ditanam selanjutnya diseleksi ulang dan disiapkan untuk penanaman di lahan sendiri (pembibitan prenursery) atau dipersiapkan untuk pengiriman ke lokasi pelanggan Pemasaran dan Administrasi (marketing) Divisi pemasaran dan administrasi pada PT. SEM berada pada bagian yang sama. Pada bagian ini berlangsung kegiatan sebagai berikut: a) Penjualan kecambah Proses penjualan kecambah sawit dilakukan secara bertahap mulai dari datangnya pesanan dari pelanggan (sales order), yang selanjutnya dilanjutkan dengan pembuatan kontrak kerjasama (contract) antara kedua belah pihak dan pengiriman tagihan (invoice) kepada pelanggan tersebut. Dilanjutkan dengan pembayaran down payment sesuai kontrak (payment) hingga pengiriman kecambah ke lokasi pelanggan. Pemesanan, pada tahap ini pihak adminstrasi akan memastikan jumlah persediaan kecambah yang siap dijual. Proses pemesanan hingga realisasi pengiriman membutuhkan waktu yang paling cepat sekitar 3 bulan jika ada persediaan di ruang penyimpanan (ruang dingin). Proses dilanjutkan bila jumlah yang diinginkan mencukupi.

8 34 Pembuatan kontrak perlu dilakukan antara perusahaan dengan pelanggan yang berisi jadwal pengiriman dan aturan pembayaran tagihan supaya pengiriman dan pembayaran dapat dilakukan sesuai dengan rencana. Tagihan akan dikirimkan yang berisi sejumlah uang yang harus dibayarkan pada awal kerjasama (down payment) yang selanjutnya dilakukan pencatatan pembayaran setelah pelanggan melunasi tagihan tersebut. Proses perkecambahan dilakukan dan proses pengiriman dilakukan dengan membuat berita acara pengiriman dan berita acara penerimaan yang nanti diisi pelanggan saat kiriman telah sampai. b) Pembelian barang Sebagai sebuah perusahaan, pembelian barang kebutuhan operasional maupun non operasional dilakukan untuk berbagai keperluan. Pembelian dapat saja dilakukan atas dasar permohonan pembelian dari divisi gudang maupun pembelian kebutuhan non operasional seperti workshop, sponsorship, aset non gudang, dll. Pembayaran akan dilakukan terhadap tagihan yang datang kepada perusahaan supaya pengiriman barang dapat dilakukan Kepegawaian (human resources) Administrasi kepegawaian yang dilakukan tidak seluruhnya oleh PT. SEM. Sebagai bagian dari PT. Mekar Unggul Sari, maka transaksi keuangan yang dilakukan berkenaan dengan kepegawaian masih dilakukan terpusat. Kegiatan yang dilakukan terbatas pada aktivitas absensi kepegawaian dan perjalanan dinas. 4.2 Analisis kebutuhan Berdasarkan domain permasalahan tersebut dan spesifikasi sistem sebelumnya, diperoleh beberapa poin hasil dari analisis kebutuhan sistem. Secara umum, kebutuhan sistem ditunjukkan pada Gambar 8.

9 35 Gambar 8 Use case kebutuhan SI pembibitan kelapa sawit Kebun (garden) Kebutuhan fungsional sistem untuk bagian kebun yang terdiri atas pembibitan prenursery, pembibitan mainnursery hingga kebun induk, terdiri atas penyimpanan dan manajemen data dari: penyiapan polibeg kosong. penggunaan polibeg. pembibitan prenursery dan mainnursery yang terdiri atas aktivitas penanaman bibit, repotting, transplanting, seleksi bibit rusak/mati, penjualan bibit, dan hasil sensus bibit. perawatan tanaman di kebun penelitian, baik perawatan periodik maupun insidental. penanaman pohon baru atau penggantian pohon yang rusak (replanting). pembungkusan, penyerbukan, dan panen tanaman betina (Dura). pemanenan polen dari pohon jantan (Pisifera). sensus bunga pohon yang dilakukan setiap minggu.

10 36 registrasi pohon-pohon yang terseleksi sebagai pohon induk. stok bibit sesuai usia pada pembibitan prenursery dan mainnursery. Selain itu pada bagian ini dibutuhkan sistem informasi geografis yang ditujukan untuk memperlihatkan/visualisasi aktivitas maupun keadaan kebun. Sistem SIG tersebut harus dapat memperlihatkan beberapa hal berikut: Menampilkan peta aktivitas pembungkusan tandan. Menampilkan peta aktivitas penyerbukan tandan. Menampilkan peta aktivitas pemanenan tandan. Menampilkan informasi pada pohon terpilih secara interaktif Gudang (warehouse) Pada bagian gudang, sistem harus dapat menyimpan dan mengatur data dari aktivitas yang terjadi ada gudang sebagai berikut: Slip Permintaan Barang (SPB) yang dikeluarkan oleh pihak gudang kepada pihak perusahaan dalam rangka pembelian barang baru. Tanda Terima Gudang (TTG) yang diperoleh dari pemasok/pengirim barang yang dibeli. Bon Permintaan Barang (BPB) yang dikeluarkan oleh pihak perusahaan untuk konsumsi barang di gudang Slip Keluar Barang (SKB) yang dikeluarkan oleh pihak gudang untuk mencatat barang keluar. Hasil pemeriksaan stok barang di gudang Pabrik (factory) Kebutuhan akan pencatatan data pada bagian pabrik terutama diperuntukkan sebagai data historis bibit/kecambah yang diproses pada lokasi tersebut. Pencatatan ditujukan salah satunya supaya informasi produktivitas tanaman penghasil kecambah tersebut dapat diketahui persentase keberhasilan bibitnya dikecambahkan dan persentase kegagalan perkecambahannya, oleh sebab itu pada pabrik pengolahan dibutuhkan sistem yang dapat menyimpan dan mengatur data dari aktivitas berikut: penyerahan tandan dari pihak kebun, hasil seleksi awal dan pembungkusan ke dalam kantong biji,

11 37 kantong biji yang masuk atau keluar dari ruang dingin, kantong biji yang masuk atau keluar dari ruang panas, hasil pemeriksaan perkecambahan pada ruang germinasi, hasil seleksi akhir biji untuk dijual atau ditanam kembali di pembibitan Pemasaran dan Administrasi (marketing) Divisi administrasi dan pemasaran berada pada domain proses yang sama. Pada perusahaan ini beberapa proses bisnis masih dilakukan secara terpusat pada perusahaan induk sehingga kebutuhan yang diperlukan pada sistem menjadi lebih sederhana dan terbatas. Divisi pemasaran membutuhkan sistem yang dapat menyimpan dan mengatur data/aktivitas berikut: daftar pelanggan aktif maupun calon pelanggan, daftar pemasok barang, surat kontrak pembelian bibit/kecambah, surat permintaan pembelian (purchase order), pesanan bibit/kecambah, pengiriman bibit/kecambah, laporan penerimaan pengiriman bibit/kecambah (Berita Acara Penerimaan), tagihan dari pemasok atau ke pelanggan Kepegawaian (human resources) Divisi kepegawaian tidak melakukan seluruh proses kepegawaian karena masih dikelola oleh perusahaan induk seperti penggajian, pengangkatan, kontrak kerja, dll. Adapun yang dilakukan oleh PT. SEM terbatas pada beberapa hal berikut: Menyimpan data karyawan di perusahaan. Menyimpan data perjalanan dinas karyawan. Menyimpan data kehadiran karyawan beserta lemburnya. Secara lebih teknis, kebutuhan fungsional lainnya yang diperlukan yaitu sistem dikembangkan berbasis web sehingga dapat diakses melalui peramban.

12 Direktur Sebagai posisi tertinggi, pihak direktur membutuhkan sistem yang dapat menampilkan peta hasil data insidental (perawatan spesifik) dan periodik. Peta akan diakses dari peramban supaya dapat diakses dimanapun dan kapanpun. 4.3 Perancangan Identifikasi Resource Berdasarkan proses bisnis yang ada di PT. SEM, maka dapat dirangkumkan entitas dan aktivitas yang terlibat di dalamnya menggunakan diagram domain (Lampiran 1). Pada tahap ini entitas dari diagram domain dijadikan dasar dalam identifikasi resource. Berikut ini hasil identifikasi entitas yang akan menjadi resource: a) Pembibitan prenursery Polibeg Bibit Stok Bibit Penanaman Bibit Repotting Bibit Seleksi Bibit Penjualan Bibit Sensus Bibit b) Pembibitan mainnursery Bibit Stok Bibit Penanaman Bibit Transplanting Bibit Seleksi Bibit Penjualan Bibit Sensus Bibit c) Kebun Pohon Tandan Polen Perawatan Penanaman Replanting

13 39 Pembungkusan Tandan Betina Polinasi Panen Tandan Betina Panen Polen Sensus Bunga Seleksi Pohon d) Gudang Surat Permintaan Barang (SPB) Tanda Terima Gudang (TTG) Bon Permintaan Barang (BPB) Slip Keluar Barang (SKB) Material/Peralatan Stok Material/Peralatan e) Pabrik Serah Terima Tandan Tandan Kantong Tandan Seleksi Awal Pendinginan (Ruang Dingin) Pemanasan (Ruang Panas) Pengecambahan (Ruang Germinasi) Seleksi Penjualan f) Pemasaran dan Administrasi Pelanggan Pemasok Pesanan Kontrak Pembelian Barang Tagihan ke Pelanggan Tagihan dari Pemasok Pembayaran dari Pelanggan Pembayaran ke Pemasok Surat Jalan Pengiriman Berita Acara Penerimaan g) Kepegawaian Pegawai Perjalanan Dinas Divisi Perusahaan Presensi

14 Pemetaan Resource Berdasarkan resource dari setiap domain tersebut, maka pemetaan terhadap seluruh entitas kepada URI resource perlu dilakukan. Pemetaan dilakukan menggunakan template URI pada Gambar 9 (Gregorio et al. 2012): {domain}/{resource}/{subresource}/{parameter} Domain : Domain dari perusahaan Resource : Nama resource Sub Resource : Nama sub-resource (jika ada) Parameter : Parameter URI (jika ada) Gambar 9 Template pemetaan URI terhadap resource yang ada Template tersebut terdiri atas beberapa bagian sebagai berikut: Domain, merupakan nama dari bagian bisnis di perusahaan seperti /garden (kebun), /warehouse (gudang), /marketing (pemasaran), /hr (kepegawaian), dll. Domain diperlukan sebagai cara pengelompokkan resource berdasarkan aktivitas yang dilakukan pada bagian tersebut. Hal tersebut bertujuan agar URI yang dihasilkan akan lebih mudah dipahami. Resource, merupakan nama dari resource itu sendiri, misalkan /customer yang merupakan hasil pemetaan dari entitas pelanggan (customer). Sub-resource, beberapa entitas terdiri atas beberapa hirarki sehingga diperlukan pengelompokan berdasarkan hirarkinya. Sebagai contoh resource/bunch (tandan) memiliki subresource /ready_harvest (tandan siap panen), yang berarti resource sistem akan memberikan list tandan yang siap dipanen. Parameter, merupakan bagian yang terdapat pada URI yang menunjukkan komponen spesifik dari resource yang ada, misalnya id pada pembacaan suatu resource. Parameter sangat bergantung pada interface yang diberikan. Pada beberapa interface seperti GET dan POST, parameter dapat dikosongkan untuk menunjukkan list dari seluruh resource yang ada pada URI yang diberikan, namun dapat juga diberikan untuk menunjukkan

15 41 resource yang lebih detail. Pada interface PUT dan DELETE, parameter id merupakan keharusan. Gambaran umum rancangan URI hasil pemetaan entitas terhadap resource yang diperlukan dalam sistem informasi tersebut akan terdiri atas beberapa bagian. Bagian pemetaan tersebut terdiri dari pemetaan URI di pembibitan (Tabel 2), pembibitan prenursery (Tabel 3), pembibitan mainnursery (Tabel 4), kebun (Tabel 5), gudang (Tabel 6), pabrik (Tabel 7), pemasaran (Tabel 8) dan kepegawaian (Tabel 9). Tabel 2 Pemetaan URI di pembibitan (domain: /nursery/*) No URI Deskripsi NU.1 /seedling Bibit sawit (tanaman kecil) Tabel 3 Pemetaan URI di pembibitan prenursery (domain: /prenursery/*) No URI Deskripsi PN.1 /polybag_production Pembuatan polibeg PN.2 /polybag_usage Pemakaian polibeg PN.3 /stock Stok bibit PN.4 /cultivation Penanaman kecambah ke pembibitan PN.5 /repotting Repotting bibit ke pembibitan prenursery PN.6 /census Seleksi bibit yang rusak, sakit, atau mati PN.7 /sale Penjualan bibit PN.8 /stock_age Stok bibit sesuai usia (bulan) Tabel 4 Pemetaan URI di pembibitan mainnursery (domain: /mainnursery/*) No URI Deskripsi MN.1 /stock Stok bibit MN.2 /cultivation Penanaman bibit ke kebun MN.3 /transplanting Transplanting bibit ke pembibitan mainnursery MN.4 /census Seleksi bibit yang rusak, sakit, ataupun mati MN.5 /sale Penjualan bibit MN.6 /stock_age Stok bibit sesuai usia (bulan)

16 42 Tabel 5 Pemetaan URI di kebun (domain: /garden/*) No URI Deskripsi GA.1 /upkeep Perawatan pohon GA.2 /item_goods_tree_upkeep Item dari perawatan GA.3 /upkeep_type Tipe perawatan GA.4 /replanting Replanting pohon GA.5 /item_goods_replanting Item dari replanting GA.6 /bagging Pembungkusan tandan betina GA.7 /pollination Penyerbukan tandan GA.8 /harvesting Panen tandan betina GA.9 /pollen_harvesting Panen tandan jantan/pollen GA.10 /selection Seleksi pohon induk pilihan GA.11 /tree Pohon di kebun GA.12 /bunch Tandan jantan dan betina dari pohon GA.13 /pollen Pollen pohon GA.14 /block Blok tanam GA.15 /crossing Asal crossing tanaman GA.16 /parental Parental tanaman GA.17 /variety Jenis tanaman (Dura, Pisifera, dll) Tabel 6 Pemetaan URI di gudang (domain: /warehouse/*) No URI Deskripsi WH.1 /goods Barang berupa material/peralatan di gudang WH.2 /goods_unit Satuan barang WH.3 /spb Surat Permintaan Barang WH.4 /item_spb Item SPB WH.5 /ttg Tanda Terima Gudang WH.6 /item_ttg Item TTG WH.7 /skb Slip Keluar Barang WH.8 /item_skb Item SKB WH.9 /bpb Bon Permintaan Barang WH.10 /item_bpb Item BPB WH.11 /stock Stok barang di gudang

17 43 Tabel 7 Pemetaan URI di pabrik (domain: /factory/*) No URI Deskripsi FA.1 /consignment Serah terima tandan FA.2 /bunch_bag Kantong tandan FA.3 /selection Seleksi awal FA.4 /cooling Pendinginan di Ruang Dingin FA.5 /heating Pemanasan di Ruang Panas FA.6 /germination Pengecambahan FA.7 /saleable Seleksi penjualan Tabel 8 Pemetaan URI di pemasaran (domain: /marketing/*) No URI Deskripsi MA.1 /customer Pelanggan/pembeli perusahaan MA.2 /supplier Pemasok barang/jasa dari luar MA.3 /order Pesanan bibit/kecambah MA.4 /item_order Item pemesanan MA.5 /contract Kontrak antara pelanggan dengan perusahaan MA.6 /invoice_customer Tagihan yang ditujukan ke pelanggan MA.7 /item_invoice_customer Item tagihan pelanggan MA.8 /invoice_supplier Tagihan dari pemasok MA.9 /item_invoice_supplier Item tagihan pemasok MA.10 /payment_customer Pembayaran tagihan oleh pelanggan MA.11 /item_payment_customer Item pembayaran pelanggan MA.12 /payment_supplier Pembayaran tagihan kepada pemasok MA.13 /item_payment_supplier Item pembayaran pelanggan MA.14 /delivery Surat jalan pengiriman (delivery order) MA.15 /item_delivery Item pengiriman MA.16 /bap Berita Acara Penerimaan (BAP) MA.17 /item_bap Item berita acara penerimaan MA.18 /procurement Pembelian barang kepada pemasok MA.19 /item_procurement Item pembelian barang ke pemasok

18 44 No URI Deskripsi MA.20 /file Berkas lampiran kontrak Tabel 9 Pemetaan URI di kepegawaian (domain: /hr/*) No URI Deskripsi HR.1 /employee Pegawai perusahaan HR.2 /travel Perjalanan dinas pegawai HR.3 /presence Presensi pegawai HR.4 /item_presence Item presensi pegawai HR.5 /division Divisi perusahaan Penentuan Uniform Interface Pada tahap ini rancangan interface ditetapkan untuk setiap resource yang tersedia. Interface perlu ditetapkan sebagai panduan dalam melakukan komunikasi antara penyedia resource (server) dan pemakai resource (client). Secara garis besar rancangan yang dihasilkan ada pada Tabel 10 berikut: Tabel 10 Rancangan interface pada komunikasi antara client dan server Interface Parameter Penjelasan GET /{id} Pembacaan resource tertentu sesuai dengan URI dan {id} yang diberikan. Contoh: /marketing/order/123 GET / Pembacaan tanpa parameter dapat dilakukan dan akan mengembalikan seluruh resource yang tersimpan pada server untuk resource tersebut. Contoh: /marketing/order GET /{id}/{attr} Pembacaan atribut {attr} dari resource dengan identitas {id}. Contoh: /marketing/order/123/date POST / Penyimpanan/pembuatan resource yang baru sesuai dengan URL yang diberikan sebagai tujuannya. Client harus menyertakan seluruh informasi yang dibutuhkan oleh server untuk

19 45 Interface Parameter Penjelasan memproses informasi tersebut. Contoh: /marketing/order PUT /{id} Pengubahan resource yang ada dengan id benilai {id}, client harus menyertakan informasi yang diubah. Contoh: /marketing/order/123 DELETE /{id} Penghapusan resource yang ada dengan id bernilai {id}. Contoh: /marketing/order/123 Pemilihan empat interface tersebut didasarkan pada penggunaannya yang cukup mudah dan sering digunakan (Richardson & Ruby 2007) Desain representasi yang dikirim ke server Rancangan representasi yang dikirim kepada server terdiri atas entitasentitas yang diperlukan saat client melakukan request yang berisi pembuatan resource baru dan pengubahan resource yang ada. Rancangan yang terbentuk akan menjadi acuan bagi client dalam melakukan request menggunakan interface POST dan PUT. Pada operasi pembacaan ataupun penghapusan suatu resource tidak membutuhkan penyertaan entitasnya karena semua informasi yang dibutuhkan dalam proses pembacaan atau penghapusan telah ada pada URI yang diberikan. Rancangan representasi XML dari resource yang dikirim ke server dapat dilihat pada Gambar 10. <item> <nama-atribut-1>nilai Atribut 1</nama-atribut-1> <nama-atribut-n>nilai Atribut n</nama-atribut-n> [ <link> <rel>nama Relasi 1</rel> <href>url dari resource 1 yang dimaksud</href> </link> <link> <rel>nama Relasi m</rel> <href>url dari resource m yang dimaksud</href> </link> ] </item> Gambar 10 Rancangan representasi XML untuk dikirim ke server

20 46 Representasi yang disiapkan berisi atribut dari resource yang bersangkutan. Entitas link dapat kosong atau tidak dimasukkan ke dalam representasi XML yang dikirim jika resource tersebut tidak merujuk atau tidak memiliki relasi pada resource lainnya. Saat relasi ada maka relasi tersebut dimasukkan ke dalam entitas link dengan nilai href berisi URL dari resource yang dirujuk. Informasi yang diberikan pada saat pengubahan resource diperbolehkan tidak berisi seluruh atribut yang ada, namun pada operasi pembuatan resource baru harus berisi seluruh atribut dari resource tersebut. Rancangan dapat diturunkan dari desain basis data yang dihasilkan pada tahap analisis sehingga struktur data yang dikirimkan ke server saat melakukan suatu request memilik karakter yang mirip dengan struktur tabelnya namun tidak harus identik. Sebagai contoh pada resource yang merepresentasikan aktivitas panen tandan (tree harvesting) yang terletak pada URL /garden/harvesting memiliki struktur tabel seperti pada Tabel 11. Tabel 11 Struktur tabel panen tandan (tree_harvesting) Kolom Tipe data Keterangan id Integer ID dari data bunch_label Characters(45) Label dari tandan date Date(YYYY-MM-DD) Tanggal aktivitas panen weight Integer Bobot tandan dalam kg Representasi yang dapat dikirimkan kepada server saat melakukan request pembuatan data, menggunakan format XML seperti pada Gambar 11. Gambar 11 Representasi XML pada resource panen tandan Proses yang terjadi saat client melakukan beberapa operasi terhadap resource panen dapat dilihat pada beberapa ilustrasi seperti ilustrasi request

21 47 menggunakan POST (Gambar 12), GET (Gambar 13), PUT (Gambar 14), dan DELETE (Gambar 15). Gambar 12 Ilustrasi request menggunakan POST (pembuatan resource baru) Gambar 13 Ilustrasi request menggunakan GET (pembacaan) Gambar 14 Ilustrasi request menggunakan PUT (pengubahan)

22 48 Gambar 15 Ilustrasi request menggunakan DELETE (penghapusan) Pada ilustrasi tersebut terjadi komunikasi antara client dan server. Pertama, client mengirimkan data panen tandan menggunakan format XML. Informasi dikirim melalui interface POST melalui URI panen tandan pada /garden/harvesting. Setelah sampai di server, informasi tersebut diproses dan disimpan. Informasi dikirim balik kepada client yang berisi URI dari resource baru yang telah tersimpan beserta kode respon hasil dari operasi yang telah dilakukan. Identitias ini selanjutnya dapat digunakan sebagai id dalam melakukan operasi lainnya seperti operasi GET (Gambar 13), PUT (Gambar 14), dan DELETE (Gambar 15). Server juga memberikan kode respon 201 (Resource Created) yang menandakan bahwa resource baru telah tersimpan dengan sukses. Kode lainnya dapat diberikan sesuai dengan hasil proses yang dilakukan oleh server terhadap informasi yang diberikan kepadanya. Sebagai contoh untuk data panen yang sama, namun dikirimkan ke URI yang salah akan akan memberikan kode respon 404( Not Found ) yang berarti resource pada URI yang diberikan tidak ditemukan sehingga proses tidak dapat dilakukan Format representasi yang dikembalikan dari server Format representasi yang dikembalikan oleh server kepada client yang memintanya menggunakan interface GET pada dasarnya sama dengan format representasi yang digunakan untuk membuat resource baru. Beberapa atribut ditambahkan sebagai referensi kepada client tentang representasi yang diterimanya. Atribut yang ditambahkan yaitu: id dan self. Id adalah identitas dari resource tersebut, sedangkan self adalah hypermedia yang merujuk pada URI resource tersebut seperti yang ditunjukkan oleh Gambar 16.

23 49 Gambar 16 Ilustrasi format representasi hasil pembacaan resource Pada interface PUT dan POST, representasi yang dikembalikan adalah URI dari resource yang telah diubah/dibuat. Pada interface DELETE, tidak ada representasi yang dikembalikan oleh server karena resource yang dituju pada dasarnya telah dihapus Integrasi resource menggunakan hypermedia Integrasi resource yang satu dengan lainnya diwujudkan menggunakan konsep HATEOAS. Resource yang memiliki hubungan dengan resource lainnya akan memiliki entitas berupa hypermedia yang berisi URI dari resource rujukannya tersebut. Hubungan antara resource satu dengan lainnya digambarkan pada elemen rel pada hypermedia yang ada. Sebagai contoh pada Gambar 17, representasi yang dikembalikan oleh server mengandung entitas berbentuk URI yang menunjukkan entitas tersebut sebuah hypermedia. Resource bernama /garden/harvesting/ (panen tandan) memiliki hubungan dengan resource /garden/bunch/ (tandan), sedangkan resource /garden/bunch/ (tandan) merujuk lagi kepada resource /garden/tree/ (pohon), dan seterusnya. Informasi tautan antara resource yang satu dengan lainnya dapat diproses lebih lanjut oleh client untuk mengetahui informasi lebih lanjut tentang entitas yang dituju.

24 50 Gambar 17 Implementasi hypermedia pada representasi resource Implementasi hypermedia dilakukan untuk mengurangi kesalahan yang ditimbulkan oleh client terutama pada format URI dari suatu resource yang dikirimkan. Selain itu, manfaat utama yang dapat diperoleh adalah pengubahan yang dilakukan terhadap sistem yang ada dapat dilakukan lebih terisolasi dan terkontrol, karena URI yang berisi rujukan terhadap suatu resource ditangani seluruhnya oleh server. Hal tersebut memungkinkan penambahan atau pengurangan terhadap rujukan/fitur dari suatu resource menjadi lebih mudah Kode respon dari server Perancangan kode respon dilakukan sebagai rujukan dari komunikasi yang terjadi antara client dengan server. Rancangan kode respon yang digunakan pada penelitian ialah operasi GET (Tabel 12), PUT (Tabel 13), POST (Tabel 14) dan DELETE (Tabel 14). Tabel 12 Kode respon dari server untuk operasi menggunakan interface GET Kode Deskripsi 200 Resource yang dituju ada 204 Resource yang dituju ada, tapi tidak memiliki konten (masih kosong) 401 Operasi tidak dapat dilakukan karena client tidak memiliki otoritas 404 Resource yang dituju tidak ada 406 Terjadi bila client meminta representasi dalam format yang tidak

25 51 didukung server 500 Terjadi kesalahan lain yang terjadi di server Tabel 13 Kode respon dari server untuk operasi menggunakan interface PUT Kode Deskripsi 200 Resource berhasil diubah. 401 Operasi tidak dapat dilakukan karena client tidak memiliki otoritas 404 Resource yang dituju tidak ada. 409 Resource tidak dapat diubah karena konflik dengan resource lain. 415 Server tidak mendukung format representasi yang dikirimkan 500 Terjadi kesalahan lain yang terjadi di server Tabel 14 Kode respon dari server untuk operasi menggunakan interface POST Kode Deskripsi 201 Resource baru berhasil dibuat. 400 Representasi yang dikirimkan memiliki format yang salah 401 Operasi tidak dapat dilakukan karena client tidak memiliki otoritas 404 Resource yang dituju tidak ada. 409 Resource yang ingin dibuat mengalami konflik dengan resource lain yang telah ada 415 Server tidak mendukung format representasi yang dikirimkan 500 Terjadi kesalahan lain yang terjadi di server Tabel 15 kode respon dari server untuk operasi menggunakan interface DELETE Kode Deskripsi 200 Resource berhasil dihapus. 401 Operasi tidak dapat dilakukan karena client tidak memiliki otorisasi 404 Resource yang dituju tidak ada. 500 Terjadi kesalahan lain yang terjadi di server Kode respon seperti 401, 404, dan 500 merupakan kode respon yang dapat muncul dari seluruh interface yang ada karena merupakan respon dari proses yang tidak tergantung dari jenis interface yang digunakan. Setelah rancangan tersebut selesai, implementasi akan dilakukan dengan cara menyisipkan kode tersebut pada respon yang dikembalikan oleh server. Pada

26 52 operasi seperti pembacaan, penulisan, dan pembuatan resource baru, server akan merespon dengan representasi resource dalam bentuk XML dan memberikan kode respon pada header sebagai metadatanya. Implementasi dilakukan secara implisit pada kode pemrograman bersamaan dengan saat pengiriman representasi resource tersebut. 4.4 Implementasi front-end Sistem Informasi (SI) Front-end SI akan menjadi titik masuk data ke sistem. Sistem front-end SI menjadi penyambung komunikasi antara pengguna dengan sistem melalui tampilan berbasis web yang dapat dioperasikan secara langsung (Gambar 18). Gambar 18 Front-end sistem informasi sebagai penengah komunikasi Sistem front-end sekaligus berfungsi menerjemahkan data yang dikirim oleh pengguna ke bentuk representasi yang didukung oleh back-end sistem informasi. Sistem ini juga berfungsi sebaliknya, menerjemahkan representasi data dalam bentuk XML ke bentuk yang dapat dimengerti secara langsung oleh pengguna. Sistem ini dikembangkan menggunakan bahasa pemrograman PHP dengan framework Code Igniter. Sistem diimplementasikan menggunakan konsep Model View Controller (MVC). Model yang dihasilkan tidak berkomunikasi dengan sistem basis data melainkan dengan back-end sistem informasi yang berada pada komputer yang bebeda menggunakan protokol HTTP. Data yang terkirim ke sistem front-end ini disimpan pada server lainnya, yaitu server back-end. Sistem menerjemahkan data yang diperoleh dari pengguna ke XML, lalu mengirimkannya kepada back-end sistem informasi yang berada pada komputer yang berbeda. Pembacaan data yang berasal dari sistem back-end dalam bentuk XML pun diterjemahkan ke dalam format data PHP sebelum ditampilkan kepada pengguna.

27 Implementasi back-end Sistem Informasi Geografis (SIG) Sistem dikembangkan menggunakan Geoserver 2.2 dan basis data PostgreSQL 9.1 dengan ekstensi Postgis 2. Geoserver merupakan aplikasi server yang ditulis menggunakan bahasa Java yang ditujukan untuk melakukan manajemen data spasial. Pemilihan basis data PostgreSQL karena sistem harus dapat menampilkan tema kebun tertentu. Tema yang ada harus berdasarkan data yang tersimpan pada back-end sistem informasi. Penggunaan PostgreSQL menjadikan komunikasi antara back-end sistem informasi dengan back-end sistem informasi geografis dapat dilakukan lebih mudah. Perancangan back-end sistem informasi geografis pada penelitian ini dapat dilihat pada Gambar 19. Gambar 19 Rancangan tampilan back-end sistem informasi Tema yang ada merupakan hasil pengolahan data di back-end sistem informasi yang disimpan pada tabel khusus di PostgreSQL. Setiap tema memiliki tabelnya masing-masing sehingga untuk tema Pohon terpilih, pohon siap polinasi, dan pohon siap panen memiliki tabel masing-masing list_individu_terpilih, list_individu_siap_polinasi, dan list_individu_siap_panen di basis data

28 54 PostgreSQL. Tabel tersebut selanjutnya akan diproses oleh Geoserver untuk ditampilkan dalam bentuk peta pada peramban seperti pada Gambar Implementasi front-end Sistem Informasi Geografis (SIG) Peta yang ditampilkan oleh back-end SIG adalah peta statis karena bersumber dari tabel basis data yang terpisah dari back-end sistem informasi. Tampilan peta secara real-time dapat diwujudkan dengan cara melakukan pembaruan terhadap isi dari tabel yang ada di back-end GIS setiap kali peta hendak ditampilkan oleh front-end SIG. Rancangan tampilan front-end sistem informasi memiliki komponen: header, sidebar, body, dan footer sesuai ilustrasi pada Gambar 20. Header berisi informasi dan logo perusahaan. Sidebar berisi navigasi terhadap setiap komponen sistem informasi. Body berisi data tabular dan form pengisian/pengubahan data yang diperlukan. Footer berisi informasi pendukung lainnya. Gambar 20 Rancangan tampilan front-end sistem informasi Sistem ini (front-end SIG) akan melakukan request terhadap back-end SI sesuai tema yang dimaksud, kemudian sistem ini akan memperbarui isi tabel di back-end SIG. Tabel yang terbaru menyebabkan peta yang dihasilkan oleh backend SIG menjadi sesuai dengan kondisi lapangan (real-time). Proses pembaruan dan penampilan peta sesuai dengan Gambar 21.

29 55 Gambar 21 Proses pembaruan informasi tema peta x 4.7 Implementasi integrasi sistem Hasil akhir sistem terdiri atas dua sistem utama: Sistem Informasi (SI) dan Sistem Informasi Geografis (SIG). Masing-masing sistem tersebut terdiri dari dua komponen utama: back-end dan front-end. Masing-masing komponen dari tiap sistem saling berkomunikasi menggunakan web service yang telah dirancang seperti terlihat pada Gambar 22. Gambar 22 Arsitektur sistem

30 56 Sistem diimplementasikan pada komputer dengan spesifikasi sebagai berikut: 1. Processor: Intel Core i5 2500K 2. Memory: 8 GB 3. Hardisk: Corsair Force GT 60 GB Sistem diimplementasikan dalam bentuk mesin virtual menggunakan VirtualBox dengan sistem operasi Ubuntu 10.4 LTS (front-end SI, backend SI, dan front-end SIG) dan Ubuntu LTS (back-end SIG). Penggunaan sistem operasi yang berbeda untuk back-end SIG disebabkan kompabilitas dari basis data yang lebih baik pada versi tersebut. Implementasi secara detail untuk setiap komponen yaitu: 1. Front-end SI ( PHP 5.4 dengan framework CodeIgniter Back-end SI ( PHP 5.4 dengan framework Restler 2, MySQL 3. Front-end SIG ( PHP 5.3 dengan framework CodeIgniter 2.0, Openlayers 4. Back-end SIG ( Geoserver 2.2, PostgreSQL 9.1 dengan ekstensi Postgis Pengujian Sistem Pengujian sistem dilakukan dua tahap: pengujian back-end SI dan pengujian front-end SI. Pengujian pada tahap pertama dilakukan menggunakan peramban Google Chrome dengan add-on Postman. Pengujian dilakukan untuk mensimulasikan proses komunikasi client-server menggunakan format data XML. Seluruh resource yang ada pada back-end SI diuji untuk setiap interface yang tersedia dan tidak tersedia. Pengujian terhadap interface yang tidak tersedia ditujukan untuk melihat kode respon yang diberikan apakah sesuai dengan rancangan atau tidak Pengujian operasi pada back-end SI Skenario pengujian yang dilakukan adalah melakukan operasi baca, tulis, sunting, dan hapus terhadap seluruh resource (URI) yang ada. Seluruh resource tersebut terdiri dari setiap resource dari setiap domain yang ada: garden,

31 57 marketing, factory, warehouse, dan human resources. Sebagai contoh untuk domain garden, diuji pembacaan terhadap resource yang bernama bunch (buah). Pengujian dilakukan dengan membuka peramban Google Chrome dengan addon Postman, lalu mengisi parameter berikut (Tabel 16) sebagai skenario pengujian. Tabel 16 Parameter pengujian resource dari garden/bunch/1 Parameter Nilai URL Interface GET Body Headers Authorization: Basic c2vtomxldg1law4= Hasil yang diperoleh menggunakan parameter tersebut adalah seperti pada Gambar 23. Hasil menunjukkan beberapa hal. Pertama, status yang bernilai 200 yang menunjukkan operasi berhasil dilakukan. Kedua adalah resource yang dikembalikan oleh server yang berisi representasi XML dari resource tersebut. Hasil pengujian pembacaan terhadap seluruh resource adalah berhasil. Gambar 23 Hasil pengujian resource /garden/bunch/1 Pengujian terhadap operasi penulisan dilakukan dalam tiga tahap: 1. Pembacaan terhadap seluruh resource yang ada untuk membuktikan resource yang akan dibuat belum ada di sistem.

32 58 2. Pengiriman data XML ke server menggunakan interface POST dan kode respon yang diterima dari server harus bernilai 201 yang menunjukkan resource tersebut berhasil dibuat. 3. Pembacaan terhadap resource baru tersebut untuk menunjukkan bahwa resource tersebut saat itu telah ada. Parameter yang digunakan pada pengujian penulisan baru dari resource /garden/bunch/ terdapat pada Tabel 17. Pada operasi pembuatan baru, id dari resource yang hendak dibuat tidak dimasukkan pada URL karena id tersebut dibangkitkan secara otomatis oleh server. Hasil pengujian penulisan terhadap seluruh resource adalah berhasil. Tabel 17 Parameter pengujian pembuatan resource baru dari garden/bunch/ Parameter Nilai URL Interface Body Headers POST <item> <number>0001</number> <label> g10101d </label> <link> <rel>tree</rel> <href> </href> </link> </item> Authorization: Basic c2vtomxldg1law4= Pengujian terhadap operasi penyuntingan dilakukan dalam tiga tahap: 1. Pembacaaan terhadap resource tersebut untuk menunjukkan resource yang ingin disunting telah ada sebelumnya. 2. Pengiriman representasi XML terhadap URL resource tersebut yang memiliki isi berbeda dengan isi pada tahap pertama. Kode respon yang diterima harus bernilai 200 yang menunjukkan bahwa resource yang ada telah berhasil disunting.

33 59 3. Pembacaan terhadap resource tersebut untuk menunjukkan bahwa resource tersebut telah berubah sesuai dengan representasi XML yang dikirim pada tahap kedua. Parameter yang digunakan pada operasi penyuntingan ditunjukkan pada Tabel 18. Pada dasarnya parameternya mirip dengan operasi pembuatan baru, bedanya terletak pada URL yang dituju telah memuat id dari resource yang bersangkutan. Perbedaan lainnya adalah body dari operasi penyuntingan tidak harus berisi seluruh atribut dari resource tersebut. Atribut yang ingin disunting sajalah yang dimasukkan pada body. Hasil pengujian penulisan terhadap seluruh resource adalah berhasil, baik penyuntingan seluruh atribut resource maupun sebagian dari atribut yang ada. Tabel 18 Parameter pengujian penyuntingan resource dari garden/bunch/1 Parameter Nilai URL Interface Body Headers PUT <item> <number>0002</number> </item> Authorization: Basic c2vtomxldg1law4= Pengujian terhadap operasi penghapusan dilakukan dalam tiga tahap: 1. Pembacaan resource yang ingin dihapus untuk menunjukkan bahwa resource tersebut sebelumnya telah ada, dan hendak dihapus. 2. Pengiriman operasi menggunakan interface DELETE terhadap URL resource tersebut. Kode respon yang diterima dari server harus bernilai 200 yang menunjukkan bahwa proses penghapusan berhasil dilakukan. 3. Pembacaan terhadap resource yang telah dihapus pada tahap kedua. Hasil kode respon yang diterima harus 404 yang berarti resource yang dibaca pada tahap ini tidak ditemukan karena telah terhapus. Parameter yang digunakan pada penghapusan ditunjukkan pada Tabel 19. Pada operasi penghapusan yang berhasil, server tidak mengirim body kepada

34 60 client, yang dikirim hanya kode 200 yang menunjukkan operasi berhasil. Hasil pengujian penghapusan terhadap seluruh resource adalah berhasil. Tabel 19 Parameter pengujian penghapusan resource dari garden/bunch/1 Parameter Nilai URL Interface DELETE Body Headers Authorization: Basic c2vtomxldg1law4= Pengujian kode respon pada back-end SI Setiap kode respon yang telah didefinisikan sebelumnya diuji dengan sekenario yang berbeda-beda sedemikian hingga kode tersebut muncul sesuai dengan yang diharapkan. Pengujian dilakukan terhadap seluruh resource yang ada dan untuk semua interface yang digunakan. Secara garis besar, pengujian setiap interface dilakukan menggunakan kode respon seperti GET (Tabel 20), PUT (Tabel 21), POST (Tabel 22), dan DELETE (Tabel 23). Tabel 20 Skenario umum pengujian kode respon pada interface GET Kode Skenario 200 Membaca resource yang ada. Server memberikan kode 200 beserta representasi XML dari resource yang bersangkutan 204 Resource di basis data dikosongkan, kemudian dilakukan pembacaan terhadap resource tersebut. Server memberikan kode 204 tanpa ada tambahan representasi resource. 401 Pembacaan dilakukan tanpa menyertakan header untuk otorisasi 404 Pembacaan resource yang tidak ada atau membaca resource dengan id tertentu yang tidak ada pada basis data 406 Pembacaan dengan header tambahan berupa permintaan format representasi lain seperti CSV, XLS, dll yang tidak didukung oleh server (server hanya mendukung XML) 500 Server dikondisikan error sehingga tidak dapat melayani segala macam operasi Status Tabel 21 Skenario umum pengujian kode respon pada interface PUT

35 61 Kode Deskripsi 200 Penyuntingan terhadap resource dilakukan, saat server merespon dengan kode 200 kemudia diperiksa di basis data apakah telah berubah sesuai proses suntingan. Saat data di basis data berubah maka kode 200 tersebut adalah benar 401 Operasi dilakukan tanpa menyertakan header untuk otorisasi 404 Penyuntingan suatu resource dengan id yang tidak terdaftar di sistem 409 Penyuntingan dilakukan dengan mengubah id dengan id yang telah terdaftar sehingga server mendeteksi potensi duplikasi 415 Body representasi data yang dikirim dalam bentuk selain XML, misalnya JSON dan CSV 500 Server dikondisikan error sehingga tidak dapat melayani segala macam operasi Status Tabel 22 Skenario umum pengujian kode respon pada interface POST Kode Deskripsi 201 Pembuatan suatu resource yang berhasil seharusnya memberikan kode Body yang dikirim saat pembuatan resource dirancang memiliki atribut yang tidak lengkap sehingga server mengirimkan kode Operasi dilakukan tanpa menyertakan header untuk otorisasi 404 Pembuatan resource dengan URL ditujukan pada resource yang tidak terdaftar di sistem, misalnya /garden/weeding 409 Pembuatan suatu resource dengan nama atau id yang telah terdaftar sebelumnya. Misalnya /garden/bunch/1 memiliki atribut label bernilai abc, sistem diuji dengan mencoba membuat resource di /garden/bunch dengan label berisi abc 415 Pengiriman representasi data dalam format yang tidak didukung oleh server, misalnya CSV 500 Server dikondisikan error sehingga tidak dapat melayani segala macam operasi Status

36 62 Tabel 23 Skenario umum pengujian kode respon pada interface DELETE Kode Deskripsi 200 Penghapusan salah satu resource, kemudian diperiksa di basis data apakah telah berhasil dihapus. Saat data berhasil dihapus dan server memberikan kode 200 maka kode tersebut valid 401 Operasi dilakukan tanpa menyertakan header untuk otorisasi 404 Pengujian dengan mencoba menghapus suatu resource dengan id yang tidak terdaftar pada sistem 500 Server dikondisikan error sehingga tidak dapat melayani segala macam operasi Status Kode respon yang memiliki makna sama adalah kode 401, 404, dan 500 terlepas dari jenis operasi yang dilakukan. Hal tersebut disebabkan karena kode tersebut merupakan respon terhadap kesalahan yang dilakukan/terjadi terlepas dari operasi yang dilakukan. Sebagai contoh kode 500 yang terjadi akibat kesalahan konfigurasi server atau kode pemrograman, akan menyebabkan segala bentuk operasi menjadi gagal dan tidak dapat diolah Pengujian operasi pada back-end SIG Pengujian dilakukan untuk memastikan Geoserver telah terkoneksi dengan basis data PostgreSQL dan menampilkan data spasial yang dimaksud. Pengujian koneksi dilakukan dengan cara sederhana yaitu mematikan basis data lalu mencoba menjalankan Geoserver untuk menampilkan peta yang dimaksud. Geoserver harus tidak dapat menampilkan peta karena koneksi terputus. Pengujian keabsahan tampilan peta dilakukan dengan cara menghapus baris yang ada pada basis data dengan tujuan melihat perubahan yang dimunculkan oleh Geoserver seperti pada Gambar 24. Pada Gambar 24(a) tanaman terpilih ditampilkan pada peta. Titik berwarna abu-abu yang ditunjuk oleh panah merah dalam kondisi sebagai tanaman tidak terpilih. Selanjutnya satu baris ditambahkan pada basis data yang berisi daftar tanaman yang terpilih, kemudian dilakukan pemuatan ulang peta tersebut untuk melihat perubahan yang terjadi pada peta. Pengujian berhasil saat peta yang ditampilkan telah merefleksikan keadaan pada basis data yang ada, yaitu titik berwarna hijau (Gambar 24b).