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)
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:
4.1.1 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.
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.
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.
4.1.2 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 :
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.
4.1.3 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.
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.
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.
4.1.4 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.
• 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.
4.1.5 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.
Gambar 8 Use case kebutuhan SI pembibitan kelapa sawit 4.2.1 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.
• 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. 4.2.2 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. 4.2.3 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,
• 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. 4.2.4 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.
4.2.5 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.
4.2.6 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
4.3.1 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
• 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
4.3.2 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
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
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 !
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
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 4.3.3 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
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).
4.3.4 Desain representasi yang dikirim ke server
Rancangan representasi yang dikirim kepada server terdiri atas entitas-entitas 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>
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
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 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.
4.3.5 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.
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.
4.3.6 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.
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. 4.3.7 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
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
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.
4.5 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,
PostgreSQL. Tabel tersebut selanjutnya akan diproses oleh Geoserver untuk ditampilkan dalam bentuk peta pada peramban seperti pada Gambar 19.
4.6 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
end SIG. Tabel yang terbaru menyebabkan peta yang dihasilkan oleh back-end SIG menjadi sesuai dengan kondisi lapangan (real-time). Proses pembaruan
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.
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 4.1.22 dengan sistem operasi Ubuntu 10.4 LTS (front-end SI,
back-end SI, dan front-back-end SIG) dan Ubuntu 12.04 LTS (back-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 (http://web.sem): PHP 5.4 dengan framework CodeIgniter 2.0
2. Back-end SI (http://api.sem): PHP 5.4 dengan framework Restler 2, MySQL
3. Front-end SIG (http://gis.sem): PHP 5.3 dengan framework CodeIgniter 2.0,
Openlayers
4. Back-end SIG (http://geoserver.sem): Geoserver 2.2, PostgreSQL 9.1
dengan ekstensi Postgis 2
4.8 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.
4.8.1 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,
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 http://api.sem/v1/garden/bunch/1
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.
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 http://api.sem/v1/garden/bunch/ Interface POST Body <item> <number>0001</number> <label> g10101d -0001-2012</label> <link> <rel>tree</rel> <href>http://api.sem/v1/garden/tree/g10101d </href> </link> </item>
Headers 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.
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 http://api.sem/v1/garden/bunch/ Interface PUT Body <item> <number>0002</number> </item>
Headers 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
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 http://api.sem/v1/garden/bunch/1
Interface DELETE Body
Headers Authorization: Basic c2VtOmxldG1laW4=
4.8.2 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 Status
200 Membaca resource yang ada. Server memberikan kode “200” beserta representasi XML dari resource yang bersangkutan
Berhasil
204 Resource di basis data dikosongkan, kemudian dilakukan
pembacaan terhadap resource tersebut. Server memberikan kode “204” tanpa ada tambahan representasi resource.
Berhasil
401 Pembacaan dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404 Pembacaan resource yang tidak ada atau membaca resource dengan id tertentu yang tidak ada pada basis data
Berhasil
406 Pembacaan dengan header tambahan berupa permintaan format representasi lain seperti CSV, XLS, dll yang tidak didukung oleh server (server hanya mendukung XML)
Berhasil
500 Server dikondisikan error sehingga tidak dapat melayani
segala macam operasi
Berhasil
Kode Deskripsi Status 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
Berhasil
401 Operasi dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404 Penyuntingan suatu resource dengan id yang tidak
terdaftar di sistem Berhasil
409 Penyuntingan dilakukan dengan mengubah id dengan id yang telah terdaftar sehingga server mendeteksi potensi duplikasi
Berhasil
415 Body representasi data yang dikirim dalam bentuk selain
XML, misalnya JSON dan CSV
Berhasil
500 Server dikondisikan error sehingga tidak dapat melayani
segala macam operasi
Berhasil
Tabel 22 Skenario umum pengujian kode respon pada interface POST
Kode Deskripsi Status
201 Pembuatan suatu resource yang berhasil seharusnya memberikan kode “201”
Berhasil
400 Body yang dikirim saat pembuatan resource dirancang
memiliki atribut yang tidak lengkap sehingga server mengirimkan kode “400”
Berhasil
401 Operasi dilakukan tanpa menyertakan header untuk
otorisasi Berhasil
404 Pembuatan resource dengan URL ditujukan pada resource yang tidak terdaftar di sistem, misalnya
/garden/weeding
Berhasil
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”
Berhasil
415 Pengiriman representasi data dalam format yang tidak
didukung oleh server, misalnya CSV Berhasil 500 Server dikondisikan error sehingga tidak dapat melayani
segala macam operasi
Tabel 23 Skenario umum pengujian kode respon pada interface DELETE
Kode Deskripsi Status
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
Berhasil
401 Operasi dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404 Pengujian dengan mencoba menghapus suatu resource
dengan id yang tidak terdaftar pada sistem Berhasil 500 Server dikondisikan error sehingga tidak dapat melayani
segala macam operasi
Berhasil
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.
4.8.3 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).
(a)
(b)
Gambar 24 Tampilan peta, (a) peta tanaman terpilih dari basis data asli, (b) salah satu baris telah ditambahkan
4.8.4 Pengujian operasi pada front-end SIG
Pengujian dilakukan dengan menjalankan aplikasi front-end SI lalu memilih bagian peta dan memeriksa peta yang ditampilkan oleh peramban. Pengujian dianggap berhasil ketika peta yang ditampilkan merefleksikan keadaan pada basis data.
4.8.5 Pengujian operasi pada front-end SI
Pengujian tahap selanjutnya adalah pengujian sistem utuh yang merupakan hasil dari kerjasama antara keempat sistem yang ada: back-end SI, back-end SIG, dan front-end SIG. Pengujian dilakukan untuk menguji seluruh operasi
pembacaan, penyimpanan, dan penghapusan data yang ada pada seluruh domain perusahaan.
Skenario yang digunakan untuk pengujian front-end SI adalah dengan melakukan operasi pembacaan, pembuatan, penyuntingan, dan penghapusan terhadap setiap resource yang ada melalui sistem yang ada. Secara garis besar pengguna adalah sebagai berikut:
a. Skenario membuka sistem pada peramban
Skenario : Pengguna membuka peramban lalu memasukkan URL http://api.sem/v1/
Kondisi berhasil : Sistem ditampilkan pada peramban tersebut
Kondisi gagal : Peramban tidak menampilkan sistem pada peramban Hasil : Berhasil
b. Skenario menampilkan data kosong
Skenario : Pengguna membuka salah satu modul pada domain tertentu dengan kondisi basis data yang kosong/belum terisi
Kondisi berhasil : Sistem ditampilkan tanpa data apapun Kondisi gagal : Sistem ditampilkan dengan data Hasil : Berhasil
c. Skenario menambah data baru
Skenario : Pengguna menekan tombol “tambah data” pada sistem, kemudian mengisi form yang ada.
Kondisi berhasil : Sistem menampilkan notifikasi bahwa data berhasil ditambahkan, kemudian data tersebut ditampilkan pada tabel yang sebelumnya kosong
Kondisi gagal : Sistem tidak memberikan respon apapun Hasil : Berhasil
d. Skenario menyunting data pada tabel
Skenario : Pengguna memilih salah satu baris pada tabel kemudian memilih tombol “Ubah data”, kemudian mengisi form yang ada.
Kondisi berhasil : Sistem menampilkan notifikasi bahwa data berhasil disunting, kemudian data tersebut ditampilkan pada tabel sesuai dengan penyuntingan sebelumnya
Kondisi gagal : Sistem tidak memberikan respon apapun Hasil : Berhasil
e. Skenario menghapus data baru
Skenario : Pengguna memilih salah satu baris pada tabel kemudian memilih tombol “Hapus data”
Kondisi berhasil : Sistem menampilkan notifikasi bahwa data berhasil dihapus, kemudian data tersebut hilang dari tabel Kondisi gagal : Sistem tidak memberikan respon apapun
Hasil : Berhasil !
4.8.6 Pengujian integrasi sistem
Seluruh sistem yang ada dinyalakan menggunakan VirtualBox, lalu pada sistem operasi host dilakukan operasi pembacaan, penulisan, penyuntingan dan penghapusan data melalui front-end SI untuk melihat konsistensi data yang ada. Sistem dianggap berhasil ketika perubahan yang dilakukan melalui front-end SI dapat dilayani oleh front-end SI dan memiliki hasil yang sama dengan basis data.
Pada beberapa modul dengan ketergantungan tinggi sistem harus dapat menampilkan/tidak menampilkan data sesuai dengan state dari data tersebut. Segala penambahan/pengurangan data pada suatu modul harus dapat diolah dengan benar pada modul lain yang tergantung pada modul tersebut. Sebagai contoh modul panen, sistem harus dapat menampilkan tanaman yang buahnya telah dimasukkan dalam modul polinasi. Saat buah tersebut telah masuk ke basis data panen, maka sistem harus tidak menampilkan buah tersebut dari pilihan buah yang siap dipanen. Pengujian pada tahap ini telah berhasil karena modul sistem dapat menunjukkan hasil pengolahan data dari sistem informasi lainnya.
Pengujian terhadap SIG dilakukan dengan menambah/menghapus identitas tanaman yang ditampilkan pada peta untuk melihat perubahan yang terjadi secara langsung pada peta yang ada. Hasil pengujian menunjukkan peta yang diakses melalui front-end SI menampilkan kondisi sesuai dengan basis data (yang sedang diuji).
4.9 Dokumentasi
Dokumentasi yang ada terdiri atas dua buah: dokumentasi teknis dan dokumentasi perancangan. Dokumentasi perancangan dapat dilihat pada Lampiran diagram domain (Lampiran 2) dan Lampiran perancangan URI (Lampiran 3), sedangkan dokumentasi teknis diletakkan langsung pada sistem operasi dari sistem yang bersangkutan. Dokumentasi teknis berisi konfigurasi sistem beserta konfigurasi jaringan supaya sistem dapat berjalan dan berkomunikasi dengan sistem lainnya seperti konfigurasi akun basis data, format data, dan konfigurasi spesifik basis data (Postgre SQL).
