SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA) STUDI KASUS PT. SASARAN EHSAN MEKARSARI IMAM ABU DAUD

SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT

BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA)

STUDI KASUS PT. SASARAN EHSAN MEKARSARI

IMAM ABU DAUD

SEKOLAH PASCASARJANA

INSTITUT PERTANIAN BOGOR

BOGOR

2013

! iii

PERNYATAAN MENGENAI TESIS DAN SUMBER

INFORMASI

Dengan ini saya menyatakan bahwa tesis Sistem Informasi Pembibitan Kelapa Sawit Berbasis Resource-Oriented Architecture (ROA) Studi Kasus PT. Sasaran Ehsan Mekarsari adalah karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi manapun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhit tesis ini.

Bogor, Februari 2013

Imam Abu Daud NIM G651100121

! v

ABSTRACT

IMAM ABU DAUD. Oil Palm Nursery Information System based on Resource-oriented Architecture (ROA) case study PT. Sasaran Ehsan Mekarsari. Supervised by SRI NURDIATI and YANDRA ARKEMAN.

This research present an application of Resource Oriented Architecture with RESTful web service style at oil palm research station, PT. Sasaran Ehsan Mekarsari. The system consist of two major systems: Nursery Information System (IS) and Geographics Information System (GIS), with each part of the system built with two foundations: back-end and front-end. The experiment resulted that these RESTful design can be applied both at IS and GIS. The web service made Nursery Information System (IS) could cooperate easily with Geographics Information System (GIS) and vice versa to accommodate company needs. Standardized data format made the communication among each system run easier and open the scalability of the system at the future.

Keywords: Web service, Resource Oriented Architecture, RESTful, Geographics Information System

! vii

RINGKASAN

IMAM ABU DAUD. Sistem Informasi Pembibitan Kelapa Sawit Berbasis Resource-Oriented Architecture (Roa) Studi Kasus Pt. Sasaran Ehsan Mekarsari. Dibimbing oleh SRI NURDIATI dan YANDRA ARKEMAN.

PT. Sasaran Ehsan Mekarsari adalah perusahaan yang bergerak di bidang riset dan pembibitan kelapa sawit. Proses bisnis yang terjadi dimulai dari bibit mulai ditanam, dirawat, hingga dipersiapkan untuk diteliti lagi atau dijual ke konsumen. Luasnya areal kebun penelitian menyebabkan kebutuhan akan monitoring terhadap kegiatan yang terjadi di perusahaan harus dilakukan secara remote. Pengembangan sistem harus dilakukan sehingga monitoring secara real-time dan dari manapun dapat dilakukan. Visualisasi terhadap keadaan lapang pun harus dapat dilakukan untuk membantu proses pengambilan keputusan. Visualisasi diwujudkan dalam bentuk Sistem Informasi Geografis (SIG).

Upaya pengembangan aplikasi sistem informasi seringkali dilakukan tanpa perencanaan yang baik dan benar, sehingga aplikasi dikembangkan berdasarkan hasil analisis dan disain dari fungsi organisasi secara lokal. Akhirnya banyak terdapat pulau-pulau sistem informasi (SI) dalam organisasi. Keterpisahan ini menyebabkan setiap aplikasi sulit berkomunikasi dengan lainnya sehingga berdampak tidak terintegrasinya data dan informasi yang ada, yang pada akhirnya berakibat pada rendahnya tingkat kertersediaan, konsistensi, dan efektifitas data dan informasi yang ada.

Sistem informasi yang beragam memerlukan arsitektur yang mengatur bagaimana aplikasi yang satu dengan yang lainnya dapat saling berkomunikasi dan bertukar data. Representational State Transfer (REST) merupakan salah satu cara untuk mengimplementasikan Resource Oriented Architecture (ROA) sehingga komunikasi antar sistem dapat dilakukan lebih mudah. ROA merupakan bentuk kongkrit dari RESTful web service sebagai salah satu cara untuk memecahkan permasalahan menjadi solusi: komposisi dari URI, HTTP, dan XML yang saling bekerja sama. RESTful web service menerjemahkan operasi Create Read Update Delete (CRUD) terhadap basis data ke dalam interface HTTP berupa POST, GET, PUT, dan DELETE. Setiap entitas pada domain permasalahan dipetakan oleh REST ke dalam bentuk resource yang dalam penelitian ini akan direpresentasikan dalam bentuk XML.

PT SEM memiliki divisi perusahaan yaitu: kebun (garden), gudang (warehouse), pabrik (factory), administrasi dan pemasaran (marketing) dan kepegawaian (human resource). Setiap divisi tersebut memiliki fungsi dan proses yang saling terkait.

Entitas pada setiap domain tersebut dianalisis sehingga menghasilkan sebanyak 56 entitas. Selanjutnya pemetaan seluruh entitas terhadap Uniform Resource Identifier (URI) resource dilakukan menggunakan template URI {domain}/{resource}/{subresource}/{parameter} sehingga diperoleh sebanyak 75 URI yang menjadi URI resource tersebut. Selanjutnya dirancang interface untuk setiap URI tersebut beserta representasi resource menggunakan XML. Asosiasi antara resource yang satu dan lainnya dirancang menggunakan hypermedia. Sistem yang menggunakan resource ini menjadi back-end SI.

Front-end SI akan menjadi titik masuk data ke sistem. Sistem front-end berfungsi menerjemahkan data yang dikirim oleh pengguna ke bentuk representasi yang didukung oleh back-end sistem informasi. Sistem ini juga berfungsi sebaliknya, menerjemahkan representasi dalam bentuk XML ke bentuk yang dapat dimengerti secara langsung oleh pengguna. Sistem dikembangkan menggunakan bahasa pemrograman PHP dengan framework CodeIgniter. Sistem diimplementasikan menggunakan konsep Model View Controller (MVC). Model yang dihasilkan tidak berkomunikasi dengan sistem basis data melainkan dengan REST Application Programming Interface (API) dari back-end sistem informasi.

Back-end SIG dikembangkan menggunakan Geoserver dan PostgreSQL. Sistem dapat menampilkan tema-tema: tanaman siap panen, siap polinasi, dan tanaman induk terpilih. Tema tersebut merupakan hasil pengolahan data di back-end SI yang dikombinasikan dengan data spasial pada back-back-end 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. Front-end SIG 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 back-end SIG menjadi sesuai dengan kondisi lapangan (real-time).

Pengujian sistem dilakukan empat tahap: pengujian back-end SI, front-end SI, back-end SIG, dan front-end SIG. Pengujian pada tahap pertama dilakukan menggunakan peramban Google Chrome dengan addon Postman. Pengujian dilakukan untuk menyimulasikan proses komunikasi client-server menggunakan format data XML. Pengujian tahap kedua dilakukan untuk menguji seluruh operasi pembacaan, penyimpanan, dan penghapusan data yang ada pada seluruh domain perusahaan serta keluaran dari peta yang dihasilkan. Pengujian tahap ketiga dilakukan dengan melihat tema peta dengan cara melakukan modifikasi terhadap data lalu melihat hasil yang ditampilkan oleh peta melalui Geoserver. Pengujian terakhir dilakukan dengan membuka peta melalui peramban.

Berdasarkan hasil penelitian yang dilakukan, berhasil dibuat sistem informasi yang heterogen yang berkomunikasi satu sama lain. Sistem informasi yang dikembangkan menggunakan REST web service terbukti mempermudah pengembangan dan integrasi komponen sistem yang berjumlah cukup banyak. Sistem informasi geografis yang ada dengan mudah dapat berkomunikasi dengan mengolah data yang ada pada sistem informasi lainnya menggunakan web service tersebut. Penambahan atau pengurangan komponen sistem informasi geografis dapat dilakukan lebih mudah karena keterikatan antara komponen yang rendah. Keterikatan yang rendah tersebut menyebabkan efek yang ditimbulkan menjadi minimal.

Penelitian lanjutan dapat dilakukan dengan menambahkan fitur pencarian berdasarkan atribut dari resource dan memanfaatkan model yang telah ada kemudian diimplementasikan penambahan modul baru menggunakan perangkat keras lain seperti smartphone, tablet, dan lain-lain.

! ix

© Hak Cipta milik IPB, tahun 2013 Hak Cipta dilindungi Undang-Undang

Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan atau menyebutkan sumbernya. Pengutipan hanya untuk kepentingan pendidikan, penelitian, penulisan karya ilmiah, penyusunan laporan, penulisan kritik, atau tinjauan suatu masalah; dan pengutipan tersebut tidak merugikan kepentingan yang wajar IPB.

Dilarang mengumumkan dan memperbanyak sebagian atau seluruh Karya tulis dalam bentuk apapun tanpa izin IPB.

! xi

SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT

BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA)

STUDI KASUS PT. SASARAN EHSAN MEKARSARI

IMAM ABU DAUD G 651100121

Tesis

Sebagai Salah Satu Syarat untuk Melakukan Penelitian dan Penulisan Tesis Guna Memperoleh Gelar Magister Komputer

pada Progam Studi Ilmu Komputer

SEKOLAH PASCASARJANA

INSTITUT PERTANIAN BOGOR

BOGOR

2013

! ! ! ! ! ! ! ! ! !

! xv

RIWAYAT

Penulis dilahirkan di Bogor pada tanggal 27 Oktober 1985, dari pasangan Bapak Djuanda dan Ibu Sriwati. Penulis merupakan putra kelima dari enam bersaudara.

Pada tahun 1998, penulis lulus dari SD Negeri Babakan 3 Bogor, lalu pada tahun yang sama melanjutkan pendidikan di SMP NEGERI 3 Bogor. Pada tahun 2001, penulis lulus dari SLTP dan melanjutkan sekolah di SMU Negeri 1 Bogor hingga tahun 2004. Pada tahun yang sama penulis berkesempatan untuk melanjutkan studinya di Institut Pertanian Bogor (IPB) melalui jalur Undangan Seleksi Masuk IPB (USMI) sebagai mahasiswa S1 Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam. Pada tahun 2008 Penulis lulus dari S1 Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam. Pada tahun 2008 – 2012 penulis bekerja sebagai staf Teknologi Informasi di PT. Sasaran Ehsan Mekarsari. Pada tahun 2013 hingga saat tulisan ini dibuat, penulis bekerja sebagai konsultan perangkat lunak di PT. Xsis Mitra Utama.

! xvii

PRAKATA

Alhamdulillahi Rabbil ‘alamin, puji dan syukur penulis panjatkan kepada Allah SWT atas segala curahan rahmat dan karunia-Nya sehingga tugas akhir ini dapat diselesaikan.

Dalam menyelesaikan tugas akhir ini penulis mendapatkan banyak sekali bantuan, bimbingan dan dorongan dari berbagai pihak. Oleh karena itu, penulis ingin mengucapkan terima kasih kepada semua pihak yang telah membantu dalam penyelesaian tugas akhir ini, antara lain:

1 Kedua orangtua tercinta, bapak Djuanda dan mamah Sri atas segala do’a, kasih sayang, dan dukungannya,

2 Ibu Sri Nurdiati, selaku pembimbing pertama atas bimbingan dan arahannya selama pengerjaan tugas akhir ini,

3 Bapak Yandra Arkeman, selaku pembimbing kedua atas bimbingan dan arahannya selama pengerjaan tugas akhir ini,

4 Bapak Sony Hartono Wijaya, Bapak Wisnu Ananta Kusuma selaku penguji dan pemberi masukan terhadap laporan tugas akhir ini,

5 Bapak Toto Haryanto dan seluruh staff Ilmu Komputer IPB atas bantuan dan motivasinya dalam penyelesaian administrasi,

6 Gibtha Fitri Laxmi atas bantuan, perhatian, dan motivasinya selama pengerjaan tugas akhir ini,

7 Pak Welli, Bu Ira, Mas Lungguh, Pak Totok, Pak Gito, dan seluruh pegawai perusahaan atas kerjasama dan dukungannya,

8 Semua teman seperjuangan Pascasarjana Ilkom 12,

Penulis juga mengucapkan terima kasih kepada semua pihak yang telah membantu selama pengerjaan penyelesaian tugas akhir ini yang tidak dapat disebutkan satu-persatu. Semoga penelitian ini dapat memberi manfaat.

Bogor, Februari 2013

! xix

DAFTAR ISI

Halaman

DAFTAR GAMBAR ... xxi

DAFTAR TABEL ... xxiii

DAFTAR LAMPIRAN ... xxv BAB I PENDAHULUAN ... 1 1.1 Latar Belakang ... 1 1.2 Rumusan Permasalahan ... 2 1.3 Tujuan Penelitian ... 3 1.4 Manfaat Penelitian ... 3

1.5 Ruang Lingkup Penelitian ... 4

BAB II TINJAUAN PUSTAKA ... 5

2.1 Resource-oriented Architecture (ROA) ... 5

2.2 Representational State Transfer (REST) ... 6

2.3 Application state dan Resource State ... 9

2.4 Hypermedia As The Engine Of Application State (HATEOAS) ... 9

2.5 Template URI ... 10

2.6 Kode respon HTTP ... 11

2.7 HTTP header ... 12

2.8 Uniform Resource Identifier (URI) ... 14

2.9 Web Service ... 15

2.10 Kelapa sawit (Elaeis) ... 15

2.11 Metode Waterfall ... 16

BAB III METODE PENELITIAN ... 19

3.1 Lokasi Penelitian ... 19

3.2 Langkah Penelitian ... 19

3.2.1 Studi kebutuhan ... 20

3.2.2 Identifikasi masalah ... 20

3.2.3 Analisis Kebutuhan Sistem ... 20

3.2.4 Desain sistem ... 20

3.2.7 Dokumentasi ... 25

BAB IV HASIL DAN PEMBAHASAN ... 27

4.1 Domain permasalahan ... 27

4.1.1 Kebun (garden) ... 28

4.1.2 Gudang (warehouse) ... 30

4.1.3 Pabrik (factory) ... 31

4.1.4 Pemasaran dan Administrasi (marketing) ... 33

4.1.5 Kepegawaian (human resources) ... 34

4.2 Analisis kebutuhan ... 34

4.2.1 Kebun (garden) ... 35

4.2.2 Gudang (warehouse) ... 36

4.2.3 Pabrik (factory) ... 36

4.2.4 Pemasaran dan Administrasi (marketing) ... 37

4.2.5 Kepegawaian (human resources) ... 37

4.2.6 Direktur ... 38

4.3 Perancangan ... 38

4.3.1 Identifikasi Resource ... 38

4.3.2 Pemetaan Resource ... 40

4.3.3 Penentuan Uniform Interface ... 44

4.3.4 Desain representasi yang dikirim ke server ... 45

4.3.5 Format representasi yang dikembalikan dari server ... 48

4.3.6 Integrasi resource menggunakan hypermedia ... 49

4.3.7 Kode respon dari server ... 50

4.4 Implementasi front-end Sistem Informasi (SI) ... 52

4.5 Implementasi back-end Sistem Informasi Geografis (SIG) ... 53

4.6 Implementasi front-end Sistem Informasi Geografis (SIG) ... 54

4.7 Implementasi integrasi sistem ... 55

4.8 Pengujian Sistem ... 56

BAB V SIMPULAN DAN SARAN ... 67

5.1 Simpulan ... 67

5.2 Saran ... 67

DAFTAR GAMBAR

Halaman

1 Representasi photo yang berisi hypermedia jenis link (Allamaraju 2010) ... 10

2 Catatan respon dari pembacaan resource (Richardson & Ruby 2007) ... 14

3 Varietas kelapa sawit (Pahan 2010) ... 16

4 Metodologi pengembangan perangkat lunak waterfall (Sommerville 2010) .... 16

5 Kerangka penelitian ... 19

6 Tahap perancangan back-end sistem informasi (Richardson & Ruby 2007) ... 21

7 Proses perkecambahan bibit kelapa sawit ... 31

8 Use case kebutuhan SI pembibitan kelapa sawit ... 35

9 Template pemetaan URI terhadap resource yang ada ... 40

10 Rancangan representasi XML untuk dikirim ke server ... 45

11 Representasi XML pada resource panen tandan ... 46

12 Ilustrasi request menggunakan POST (pembuatan resource baru) ... 47

13 Ilustrasi request menggunakan GET (pembacaan) ... 47

14 Ilustrasi request menggunakan PUT (pengubahan) ... 47

15 Ilustrasi request menggunakan DELETE (penghapusan) ... 48

16 Ilustrasi format representasi hasil pembacaan resource ... 49

17 Implementasi hypermedia pada representasi resource ... 50

18 Front-end sistem informasi sebagai penengah komunikasi ... 52

19 Rancangan tampilan back-end sistem informasi ... 53

20 Rancangan tampilan front-end sistem informasi ... 54

21 Proses pembaruan informasi tema peta x ... 55

22 Arsitektur sistem ... 55

23 Hasil pengujian resource /garden/bunch/1 ... 57

24 Tampilan peta, (a) peta tanaman terpilih dari basis data asli, (b) salah satu baris telah ditambahkan ... 63

! xxiii

DAFTAR TABEL

Halaman 1 Uniform Resource Interface yang digunakan pada RESTful HTTP (Roth 2012) 7 2 Pemetaan URI di pembibitan (domain: /nursery/*) ... 41 3 Pemetaan URI di pembibitan prenursery (domain: /prenursery/*) ... 41 4 Pemetaan URI di pembibitan mainnursery (domain: /mainnursery/*) ... 41 5 Pemetaan URI di kebun (domain: /garden/*) ... 42 6 Pemetaan URI di gudang (domain: /warehouse/*) ... 42 7 Pemetaan URI di pabrik (domain: /factory/*) ... 43 8 Pemetaan URI di pemasaran (domain: /marketing/*) ... 43 9 Pemetaan URI di kepegawaian (domain: /hr/*) ... 44 10 Rancangan interface pada komunikasi antara client dan server ... 44 11 Struktur tabel panen tandan (tree_harvesting) ... 46 12 Kode respon dari server untuk operasi menggunakan interface GET ... 50 13 Kode respon dari server untuk operasi menggunakan interface PUT ... 51 14 Kode respon dari server untuk operasi menggunakan interface POST ... 51 15 kode respon dari server untuk operasi menggunakan interface DELETE ... 51 16 Parameter pengujian resource dari garden/bunch/1 ... 57 17 Parameter pengujian pembuatan resource baru dari garden/bunch/ ... 58 18 Parameter pengujian penyuntingan resource dari garden/bunch/1 ... 59 19 Parameter pengujian penghapusan resource dari garden/bunch/1 ... 60 20 Skenario umum pengujian kode respon pada interface GET ... 60 21 Skenario umum pengujian kode respon pada interface PUT ... 60 22 Skenario umum pengujian kode respon pada interface POST ... 61 23 Skenario umum pengujian kode respon pada interface DELETE ... 62

! xxv

DAFTAR LAMPIRAN

Halaman 1 Kegiatan pembibitan di perusahaan ... 73 2 Diagram domain bisnis di perusahaan ... 74 3 Rancangan template URI ... 80 4 Back-end SI menggunakan Google Chrome (addon Postman) ... 89 5 Front-end SI ... 90 6 Back-end SIG menggunakan Geoserver ... 91 7 Front-end SIG menampilkan tema peta pohon terpilih ... 92

BAB I PENDAHULUAN

1.1 Latar Belakang

Pemanfaatan teknologi informasi untuk mendukung tercapainya tujuan bisnis organisasi diwujudkan melalui implementasi aplikasi sistem informasi pada berbagai fungsi organisasi. Upaya pengembangan sistem informasi seringkali dilakukan tanpa perencanaan yang baik dan benar, sehingga aplikasi dikembangkan berdasarkan hasil analisis dan desain dari fungsi organisasi secara lokal. Akhirnya banyak terdapat pulau-pulau sistem informasi dalam organisasi. Keterpisahan ini menyebabkan setiap aplikasi sulit berkomunikasi dengan lainnya sehingga berdampak rendahnya tingkat ketersediaan, konsistensi, dan efektivitas data dan informasi yang ada.

Sistem informasi yang beragam memerlukan arsitektur yang mengatur bagaimana aplikasi yang satu dengan yang lainnya dapat saling berkomunikasi dan bertukar data. Resource-oriented Architecture (ROA) merupakan sebuah konsep arsitektur perangkat lunak yang mendefinisikan penggunaan sumberdaya (resources) untuk memenuhi kebutuhan suatu perangkat lunak. Resource ini tidak hanya dapat digunakan oleh sistem yang menaunginya namun dapat digunakan juga oleh sistem lain yang berbeda, sehingga pertukaran informasi atau resource antar sistem relatif lebih mudah diimplementasikan. Representational State Transfer (REST) merupakan salah satu cara untuk mengimplementasikan ROA pada sistem yang beragam supaya lebih mudah beradaptasi dengan perubahan lingkungan yang cepat. Penelitian REST telah dilakukan sebelumnya seperti yang dilakukan oleh Hamad et al. (2010) dan Pautasso et al. (2008).

Industri pembibitan dan penelitian bibit kelapa sawit merupakan salah satu perusahaan berskala besar yang memiliki proses operasional yang kompleks. Proses bisnis tersebut membuat aliran informasi harus terus mengalir dari proses hulu hingga hilir, mulai dari penanaman hingga bibit siap dijual, ditambah lagi dengan proses bisnis pendukung lainnya seperti sumber daya manusia, keuangan, pembukuan dan sebagainya. Setiap bagian fungsional dari perusahaan tidak dapat dipisahkan dari bagian lainnya.

PT. Sasaran Ehsan Mekarsari adalah perusahaan bersama antara Sasaran Ehsan Utama Sdn Bhd (Malaysia) dan PT Mekar Unggul Sari (Indonesia) yang bergerak di bidang riset dan pembibitan kelapa sawit. Proses bisnis yang terjadi dimulai dari bibit mulai ditanam, dirawat, hingga dipersiapkan untuk diteliti lagi atau dijual ke konsumen. Besarnya jumlah tanaman yang dikelola dan aktivitas yang terjadi di perusahaan menyebabkan besarnya jumlah data yang perlu diolah, sehingga menjadikan kebutuhan akan manajemen data yang baik dan berkesinambungan menjadi suatu keharusan.

Luasnya areal kebun penelitian menyebabkan kebutuhan akan monitoring terhadap kegiatan yang terjadi di perusahaan harus dilakukan secara remote. Pengembangan sistem harus dilakukan sehingga monitoring secara real-time dan dari manapun dapat dilakukan. Visualisasi terhadap keadaan lapang pun harus dapat dilakukan untuk membantu proses pengambilan keputusan, visualisasi diwujudkan dalam bentuk Sistem Informasi Geografis (SIG) yang menampilkan hasil pengolahan data dari kegiatan operasional pada Sistem Informasi (SI).

1.2 Rumusan Permasalahan

Sebagai pemain baru dalam penelitian bibit kelapa sawit, PT. Sasaran Ehsan Mekarsari (SEM) telah memiliki sistem informasi yang mengelola data di perusahaan tersebut. Sistem yang ada hanya terbatas pada pengelolaan informasi produksi dan belum menyentuh proses bisnis lainnya, selain itu sistem masih belum berjalan sepenuhnya karena hal-hal berikut ini:

1. Tingginya perubahan fungsional sistem, tercatat sejak tahun 2009 hingga 2011 sistem telah mengalami tiga kali revisi berkenaan dengan parapihan data tanaman yang ada.

2. Kebutuhan analisis data yang ada saat ini masih dalam taraf sederhana, potensi akan kebutuhan analisis yang lebih mendalam sangat besar, dengan sistem yang ada saat ini akan sulit untuk pengembangan lebih lanjut.

3. Jumlah staf pengembang sistem informasi yang terbatas menyebabkan pengembangan sistem dilakukan secara bertahap, begitu pula dengan revisi yang dilakukan terhadap sistem yang sedang berjalan.

! 3

4. Perkembangan teknologi pemrograman dalam beberapa tahun terakhir menyebabkan bahasa permograman yang ada sangat cepat berubah dan tidak sesuai dengan bahasa pemrograman sebelumnya.

1.3 Tujuan Penelitian

Penelitian ini bertujuan merancang arsitektur back-end sistem beserta front-end yang digunakan pada sistem informasi pembibitan kelapa sawit. Arsitektur dirancang berdasarkan konsep Resource-oriented Architecture (ROA) yang diimplementasikan dalam bentuk sistem informasi berbasis Representational State Transfer (REST). Pengembangan sistem informasi dilakukan pula pada front-end sistem yang digunakan untuk menguji fungsionalitas back-end sistem yang ada. Secara lebih detail, tujuan yang hendak dilakukan pada penelitian ini diantaranya:

1. Membangun back-end dan front-end sistem informasi (SI) yang digunakan untuk mengelola data operasional perusahaan.

2. Membangun back-end dan front-end dari sistem informasi geografis (SIG) yang menampilkan beberapa tema peta yang menggambarkan keadaan lapangan.

3. Mengintegrasikan SIG dan SI menggunakan web service. 1.4 Manfaat Penelitian

Sistem informasi yang dihasilkan diharapkan dapat memberikan beberapa manfaat, baik bagi pengembang sistem, pengguna sistem, maupun manajemen. Secara umum, manfaat yang dapat diperoleh diantaranya:

1. Adanya sistem informasi dan sistem informasi geografis untuk mempermudah operasional maupun manajerial perusahaan.

2. Terintegrasinya aplikasi dari beberapa fungsi perusahaan sehingga efektivitas, efisiensi, dan waktu kerja menjadi lebih optimal.

3. Revisi atau penambahan terhadap elemen dari sistem dapat dilakukan dengan penuh pertimbangan dan diharapkan dapat memberikan dampak yang minimal terhadap sistem yang sedang berjalan.

4. Pemeliharaan sistem dapat dilakukan lebih mudah, backup ataupun restore dapat dilakukan dalam kondisi yang terkontrol.

5. Integrasi dengan perangkat lunak dari luar dapat dilakukan lebih mudah karena menggunakan protokol standar.

6. Pengembangan sistem untuk media lain seperti tablet atau smartphone lebih mudah dilakukan karena proses bisnis dan penyimpanan data telah tersedia di server.

1.5 Ruang Lingkup Penelitian

Penelitian dilakukan dengan mengambil studi kasus pada pembibitan dan pabrik pengolahan bibit kelapa sawit di PT. SEM. Kebutuhan fungsional yang dicakup terdiri atas fungsi utama pada perusahaan pada bulan Januari 2012.

Kebutuhan non fungsional seperti security dan user priviledge tidak diimplementasikan pada penelitian ini. Sistem hanya melakukan operasi CRUD: Create (tulis), Read (baca), Update (sunting), dan Delete (hapus) terhadap basis data yang ada.

BAB II TINJAUAN PUSTAKA

2.1 Resource-oriented Architecture (ROA)

Resource adalah segala sesuatu yang dapat disimpan pada komputer dan direpresentasikan dalam bentuk aliran bit: dokumen, record pada basis data, atau hasil akhir dari eksekusi suatu algoritme. Resource akan bermanfaat jika ia memiliki minimal sebuah Uniform Resource Identifier (URI) supaya dapat diakses. ROA merupakan bentuk kongkrit dari RESTful web service sebagai salah satu cara untuk memecahkan permasalahan menjadi solusi: komposisi dari URI, HTTP, dan XML yang saling bekerja sama (Richardson & Ruby 2007).

Resource merupakan abstraksi utama pada REST. Resource dapat statis, yang berarti tidak berubah dari waktu ke waktu, atau dapat pula bersifat dinamis yang terus berubah seiring dengan waktu (Roth 2012).

ROA memiliki dua buah fitur utama, yaitu addressability dan statelessness. Addressabililty berarti bahwa sebuah aplikasi dikatakan addressable jika aplikasi tersebut menampakkan data yang dimilikinya sebagai suatu resource dan memiliki URI sendiri, misalnya sebuah URI tentang resource jelly fish: http://www.google.com/search?q=jellyfish. URI yang addressable memungkinkan pencatatan terhadap URI tersebut sehingga jika akan digunakan lagi, yang perlu dilakukan hanya mengetik URI tersebut pada peramban. Anggap saja website google tidak addressable, maka tidak mungkin menyimpan URI tersebut pada sebuah catatan, sebaliknya harus dilakukan secara manual: membuka peramban, ketik www.google.com di peramban, ketik 'jellyfish' pada kotak pencarian, lalu klik tombol 'Penelusuran Google'.

Fitur kedua yaitu statelessness yang berarti bahwa semua request HTTP yang terjadi harus dilakukan dalam keadaan terisolasi. Saat client melakukan request kepada server, maka request tersebut harus berisi semua informasi yang dibutuhkan oleh server untuk memprosesnya lebih lanjut. Server tidak boleh bergantung pada informasi request sebelumnya yang dilakukan oleh client tersebut. Secara praktik hal ini jika dihubungkan dengan sifat addressability, maka berarti bahwa state dari server dapat dijadikan resource dan memiliki URI tersendiri.

2.2 Representational State Transfer (REST)

Menurut Higashino et al. (2009) web service yang berbasis teknologi SOAP telah menghasilkan aplikasi pada banyak bidang. SOAP didesain untuk transparansi komunikasi dan keterikatan yang rendah antar aplikasi. SOAP tidak lepas dari kelemahan karena dikritik karena kompleksitas dan spesifikasi yang harus dipenuhi terlalu banyak. Selain itu permasalahan teknis yang terlalu terikat pada satu vendor tertentu menjadikan keterikatan rendah yang tidak dapat terwujud (Pautaso, Zimmermann, Leymann 2008).

Representational State Transfer (REST) adalah suatu gaya arsitektur yang bertujuan untuk meminimalkan latensi dan komunikasi jaringan, sementara pada saat yang bersamaan berusaha untuk memaksimalkan independensi dan skalabilitas dari implementasi komponen (Fielding 2000). REST berkembang bersamaan dengan berkembangnya teknologi web, sehingga sering digunakan bersamaan dengan teknologi Hypertext Transfer Protocol (HTTP), oleh alasan inilah implementasi REST menggunakan teknologi HTTP disebut Restfull HTTP.

Sebagai sebuah gaya arsitektur pengembangan sistem, REST memiliki aturan yang menjadi ciri dasarnya (Fielding 2000):

1. Client-server

Terdapat interface seragam antara client dan server. Hal ini berarti client tidak berurusan dengan hal teknis yang menjadi tanggung jawab server, misalnya database, bahasa pemrograman, dll. Hal ini bertujuan untuk portability atau kemudahan migrasi pada client. Pada sisi lain, server tidak berurusan dengan hal teknis pada client, misalnya tampilan sistem atau state dari aplikasi client sehingga pengembangan sistem pada server menjadi lebih sederhana dan lebih mudah dikembangkan (scalable). Server dan client dapat diganti dan dikembangkan secara terpisah selama interface yang digunakan diantara keduanya tidak diubah.

2. Stateless

Komunikasi client-server selanjutnya dibatasi dengan aturan tidak diperbolehkannya state dari suatu client disimpan pada server. Setiap request dari client harus disertai dengan seluruh informasi yang dibutuhkan oleh server untuk memproses request tersebut. Hal ini bertujuan supaya

! 7

server menjadi lebih tidak tergantung pada client sehingga mudah diganti terutama saat terjadi kegagalan jaringan (reliability).

3. Cacheable

Respon yang diberikan kepada client dapat disimpan sementara dalam cache client. Hal ini berakibat bahwa respon yang diberikan oleh server harus menyertakan informasi/metadata tentang kemampuan resource tersebut untuk disimpan sementara atau tidak. Hal ini bertujuan untuk mengurangi jumlah komunikasi yang ada sehingga meningkatkan performa server.

4. Layered System

Client tidak perlu tahu apakah server yang melayani request-nya merupakan server utama ataukah bukan. Hal ini bertujuan untuk meningkatkan skalabilitas server misalnya menambahkan server untuk melakukan load balancing dan cache yang dapat diakses siapapun.

5. Code on Demand

Client server dapat mengkustomisasi fungsionalitas dari client dengan mengirimkan kode yang dapat dieksekusi di client, misalkan javascript. 6. Uniform Interface

Simplifikasi arsitektur sistem yang dikembangkan berdasarkan REST dilakukan salah satunya dengan menggunakan Uniform Resource Interface seperti pada Tabel 1. Interface ini terdiri atas sekumpulan operasi yang telah terdefinisi untuk mengakses dan memanipulasi resource. Interface yang sama dapat digunakan pada resource yang berbeda, dan tidak tergantung pada resource yang digunakan.

Tabel 1 Uniform Resource Interface yang digunakan pada RESTful HTTP (Roth 2012)

Nama Pemanfaatan Sifat

GET Menerima representasi (retrieve) Safe, idempotent

DELETE Menghapus resource Idempotent

PUT Memperbarui resource dengan mengganti yang lama

Idempotent POST Membuat resource baru atau sub-resource baru

Fielding (2000) membagi sifat operasi tersebut menjadi safe dan idempotent. Operasi bersifat safe berarti saat suatu request dilakukan terhadap server, maka state dari resource yang diminta tidak berubah. Operasi GET termasuk safe karena saat suatu request dilakukan terhadap suatu resource, resource tersebut akan tetap sama. Di sisi lain operasi PUT termasuk tidak safe karena saat request dilakukan menggunakan operasi tersebut maka resource tersebut menjadi berubah. Operasi bersifat idempotent berarti hasil dari operasi yang sukses tidak tergantung dari jumlah operasi tersebut dieksekusi, misalkan operasi PUT untuk memperbarui suatu resource dapat dilakukan berulang kali dengan hasil akhir yang sama. Berbeda dengan PUT, operasi POST tidak bersifat idempotent yang berarti jika suatu operasi POST dikirimkan lebih dari sekali, hasil akhirnya bisa saja terdapat duplikasi resource pada server. Hal tersebut disebabkan karena operasi POST digunakan untuk menciptakan resource baru tanpa melihat id spesifik pada client.

Fielding (2000) menjelaskan beberapa batasan yang menjadi ciri khas dari arsitektur REST:

1. Identifikasi dari resource, yang berarti setiap resource yang ada harus memiliki identitas yang standar, misalnya menggunakan URI.

2. Manipulasi resource dilakukan melalui representasi. Resource asli tidak diberikan kepada client melainkan representasinya dalam bentuk XML, JSON, ataupun HTML. Representasi tersebut terdiri atas data dan metadata yang menjelaskan data, misalnya sebuah instansi content-type pada header HTTP merupakan atribut dari metadata.

3. Pesan yang mendefinisikan dirinya sendiri, server akan mengolah request yang dikirim kepadanya melalui metadata yang ada pada request tersebut, misalnya melalui header dari request tersebut.

4. Hypermedia sebagai pengatur transisi dari state. Transisi dari suatu state dilakukan menggunakan hypermedia.

Implementasi REST (RESTful) menjadikan beberapa aplikasi dapat berkomunikasi dan bekerja sama. Melalui web service tersebut, setiap aplikasi pada web memiliki potensi untuk mencapai aplikasi lainnya. Saat aplikasi bertukar informasi melalui standard web service, mereka dapat berkomunikasi secara

! 9

terpisah dan lepas dari sistem informasi, pemograman, processor, dan protokol internal (Breitman et al. 2007).

Menurut Filho & Ferreira (2009), pendekatan REST pada dasarnya terdiri dari lima konsep (resource, representasi, uniform identifier, unified interface, dan lingkup eksekusi), dan tiga prinsip (adressability, statelessness, dan keterhubungan). Hal yang membedakan RESTful dengan web service lainnya adalah linkup dari request dan response harus didefinisikan saat operasi berlangsung.

2.3 Application state dan Resource State

Richardson & Ruby (2007) menjelaskan state berarti suatu keadaan dari suatu informasi yang tersimpan pada suatu sistem di waktu tertentu. Sebagai contoh, jika terdapat suatu resource bernama order, akan terdapat dua keadaan/state dari resource tersebut: order telah terkirim atau order belum terkirim. Suatu resource jarang sekali hanya memiliki satu state dari waktu ke waktu. Perubahan suatu state tersebut disebut state transition dan bagian dari sistem yang mengatur transisi state tersebut disebut sebagai state engine.

State pada REST terdiri atas dua tipe: application state dan resource state. Application state berada pada mesin client, sedangkan resource state berada pada mesin server. Application state dapat digambarkan sebagai suatu kondisi dari aplikasi yang dijalankan di client, pada kasus pencarian menggunakan mesin pencari (search engine), halaman hasil pencarian yang sedang dibuka oleh client dapat dikatakan sebagai application state. Resource state dapat dikatakan sebagai persistence dari resource yang ada dan terletak di server. Application state dari client yang satu dengan yang lain bisa berbeda, sebaliknya resource state dari seluruh client adalah sama.

2.4 Hypermedia As The Engine Of Application State (HATEOAS)

W3C Glosary Dictionary (2003) mendefinisikan hypertext sebagai teks yang mengandung tautan ke teks lainnya. Hypermedia adalah istilah yang digunakan untuk hypertext yang mengacu tidak hanya kepada teks, tapi suara, video, grafik, dan lain-lain.

HATEOAS (Hypermedia As The Engine Of Application State) adalah aturan yang membedakan arsitektur aplikasi berbasis REST dengan aplikasi lain yang

berbasis client-server. Prinsip dasarnya adalah client berinteraksi dengan aplikasi jaringan melalui hypermedia yang diberikan secara dinamis oleh server (Fielding 2000).

Filosofi pemanfaatan hypermedia adalah membuat aplikasi client dapat menelusuri seluruh resource yang ada di server maupun melakukan modifikasi terhadap state dari resource yang ada walaupun tanpa adanya antarmuka sehingga dapat dilakukan oleh aplikasi yang berjalan tanpa manusia. HATEOAS terdiri atas dua jenis: link dan form.

Link adalah atribut dari suatu resource yang berisi suatu hypermedia. Form adalah suatu representasi yang dikirim oleh server dalam bentuk yang deskriptif. Bentuk tersebut berisi semua informasi yang dibutuhkan oleh client untuk melakukan manipulasi terhadap resource state di server.

Komunikasi diawali oleh client dengan cara melakukan suatu request menggunakan URI statis yang sederhana. Interaksi lanjutan dari aksi sebelumnya akan dilakukan berdasarkan representasi resource yang dikembalikan oleh server dan relasi link (hypermedia) yang ada di dalamnya. Perubahan application state yang ada di client dilakukan melalui pemilihan link yang tersedia di dalam representasi yang dikirim oleh server seperti pada Gambar 1 berikut.

Gambar 1 Representasi photo yang berisi hypermedia jenis link (Allamaraju 2010) 2.5 Template URI

Pada RFC 6570 (2012), template URI adalah sekumpulan karakter kompak yang mendeskripsikan jangkauan dari suatu URI melalui ekspansi variabel. Sebagai contoh, URI http://www.example.com/marketing/ customer/{id} adalah URI yang salah, karena mengandung karakter yang tidak diizinkan pada URI, yaitu kurung kurawal {}, namun demikian URI tersebut adalah template URI yang sah. Karakter {id} adalah variabel yang dapat diganti dengan nilai lain yang mendefinisikan id dari customer.

! 11

2.6 Kode respon HTTP

Salah satu fitur utama arsitektur REST adalah pemanfaatan kode respon HTTP (HTTP response code). RFC 2616 (Fielding et al. 1999) membagi kelompok kode menjadi beberapa bagian sesuai dengan informasi yang diberikan: 1xx (meta), 2xx (success), 3xx (redirection), 4xx (client-side error), dan 5xx (server-side error). Kode 1xx merupakan kelompok respon yang digunakan pada negosiasi antara client dengan server.

Kode 2xx mengindikasikan operasi yang dilakukan antara client dengan server berhasil dilakukan. Kelompok ini terdiri atas:

1. 200 (Ok). Kode ini mengindikasikan server sukses melakukan operasi yang diminta oleh client.

2. 201 (Created). Server mengirimkan kode ini jika resource telah tersimpan/tercipta sesuai dengan request yang dikirim oleh client.

3. 204 (No Content). Kode ini biasanya merupakan respon dari operasi PUT, POST, atau DELETE saat server tidak ingin mengembalikan representasi apapun kepada client. Dapat pula digunakan untuk operasi GET terhadap resource yang ada namun memiliki representasi yang kosong.

Kelompok 3xx (Redirection) menginformasikan kepada client bahwa client harus melakukan operasi lainnya hingga request dapat diproses sampai selesai. Kelompok 4xx merupakan kelompok kode yang menandakan terjadi kesalahan yang bersumber pada client. Kelompok ini terdiri atas:

1. 400 (Bad Request). Merupakan kode generik dari kesalahan yang disebabkan oleh client.

2. 401 (Unauthorized). Kode ini mengindikasikan resource yang diminta oleh client merupakan resource yang membutuhkan otoritas tertentu yang tidak disertakan oleh client. Kode ini juga berarti client harus mengulangi request yang dilakukannya dengan menyertakan akun otorisasi yang dibutuhkan. 3. 403 (Forbidden). Kode ini berarti server tidak mengijinkan client untuk

mengakses resource yang dituju. Hal ini dapat berarti karena resource tersebut hanya tersedia pada saat-saat tertentu atau hanya dapat diakses oleh alamat IP tertentu.

4. 404 (Not Found). Kode ini mengindikasikan bahwa URI yang diberikan tidak dapat dipetakan kepada resource yang ada, dengan kata lain resource pada URI yang diberikan tidak ada.

5. 405 (Method Not Allowed). Kode ini mengindikasikan resource yang dituju tidak mendukung operasi menggunakan interface yang diberikan oleh client. Sebagai contoh, resource yang hanya dapat dibaca akan mengembalikan kode 405 (Method Not Allowed) saat client melakukan operasi selain GET.

6. 406 (Not Acceptable). Kode ini diberikan saat server tidak dapat memenuhi permintaan format representasi yang diminta oleh client.

7. 409 (Conflict). Kode ini diberikan saat client melakukan request untuk mengubah state dari resource menjadi tidak konsisten. Sebagai contoh menghapus suatu resource yang memiliki sub-resource yang tidak kosong. 8. 415 (Unsupported Media Type). Server mengirimkan kode ini untuk

memberitahukan client yang mengirimkan representasi data yang tidak dimengerti. Sebagai contoh client mengirimkan representasi dalam format JSON, sedangkan server hanya menerima format XML.

9. 417 (Expectation Failed). Saat client meminta izin server untuk mengirimkan suatu representasi kepada server, namun server tidak mau menerima representasi yang diberikan oleh client, maka server akan mengirimkan kode ini.

Kelompok kode 5xx menandakan terjadi suatu permasalahan yang disebabkan oleh server atau pada proxy yang digunakan. Kelompok ini terdiri atas:

1. 500 (Internal Server Error). Kode ini merupakan kode generik dari respon kesalahan yang terjadi oleh server.

2. 503 (Service Unavailable). Kode ini berarti web service yang dituju oleh client sedang bermasalah. Server berjalan namun karena suatu hal server tidak dapat menangani request dari client.

2.7 HTTP header

HTTP header merupakan komponen dari header suatu pesan yang dikirimkan (request) dan diterima (response) pada protokol HTTP (RFC 2616). Header ini merupakan parameter dari transaksi yang terjadi antara client dengan

! 13

server pada transaksi HTTP. Beberapa header yang umum digunakan diantaranya (Richardson & Ruby 2007):

a. Accept. Client menggunakan ini untuk menginformasikan kepada server format representasi yang diharapkan dikirim oleh server.

b. Authorization. Header ini mengandung informasi otorisasi seperti username dan password yang dikodekan menggunakan skema yang disepakati antara client dan server.

c. Connection. Header ini digunakan oleh proxy yang menghubungkan oleh server dengan client, proxy HTTP selanjutnya akan menghapus header ini saat representasi diteruskan kepada client.

d. Content-Encoding. Header ini menjelaskan pengkodean yang digunakan pada representasi response yang diberikan oleh server.

e. Content-Length. Header ini berisi ukuran dari representasi data yang dikirimkan.

f. Content-Type. Header ini berisi jenis representasi yang ada pada request. g. Date. Pada request yang berasal dari client, header ini berisi waktu request

dikirimkan. Pada response yang diberikan oleh server, header ini berisi waktu response tersebut dikirim oleh server.

h. Expires. Header ini memberi tahu client atau proxy diantara client dan server, bahwa respon yang diberikan oleh server dapat disimpan sementara (cache) hingga periode tertentu.

i. Host. Header ini berisi nama domain dari URI. Saat request dilakukan pada http://www.example.com/page.html, maka header ini akan berisi www.example.com:80.

j. Last-Modified. Header ini berisi waktu terakhir resource tersebut mengalami perubahan.

k. User-Agent. Header ini menginformasikan jenis perangkat lunak yang digunakan saat melakukan request.

l. WWW-Authenticate. Header ini digunakan bersamaan dengan kode respon 401 (“Unauthorized”). Hal ini berarti server mengharapkan client mengulangi request tersebut dengan menyertakan akunnya beserta skema autentikasi yang digunakan.

2.8 Uniform Resource Identifier (URI)

URI atau yang lebih dikenal dengan URL (Uniform Resource Locator) merupakan frase yang terdiri atas sekumpulan karakter yang digunakan untuk mengidentifikasi suatu nama atau sumberdaya (resource). Identifikasi tersebut memungkinkan terjadinya interaksi berdasarkan representasi resource melalui jaringan menggunakan protokol tertentu (Berners et al. 2005). Misalkan seseorang memasukkan URL di peramban: http://www.example.com/hello.txt. Peramban dapat memanipulasi resource dengan menghubungi server lokasi tempat resource tersebut berada (www.example.com) dengan cara mengirimkan sebuah operator "GET" yang menuju ke arah resource /hello.txt pada server tersebut. Selanjutnya server akan memberikan respon sesuai dengan permintaan yang diberikan kepadanya. Catatan respon dari client yang mengakses resource dapat dilihat pada Gambar 2.

Gambar 2 Catatan respon dari pembacaan resource (Richardson & Ruby 2007) URI pada ROA harus didesain sedemikian rupa sehingga URI tersebut memiliki beberapa sifat berikut (Richardson & Ruby 2007):

a. URI harus deskriptif

URI dan resource yang direpresentasikan harus memiliki hubungan secara intuitif. Berikut contoh URI yang baik:

• http://www.example.com/wiki/Jellyfish • http://www.example.com/bugs/by-state/open • http://www.example.com/resource/sales/2004/Q4 • http://www.example.com/resource/sales/Q42004 b. URI harus merepresentasikan paling banyak sebuah resource

URI harus didesain untuk merepresentasikan maksimal sebuah resource, tapi sebuah resource dapat direpresentasikan oleh lebih dari satu URI. Pengaksesan /resource/sales/2004/Q4 mungkin akan memiliki hasil yang sama dengan /resource/sales/Q42004, namun keduanya

! 15

2.9 Web Service

Seperti pendahulunya, seperti Common Request Broker Architecture (CORBA), Remote Method Invocation (RMI) dan Distributed Component Object Model (DCOM), web service adalah sekumpulan standard dan metode pemrograman untuk berbagi data antara aplikasi perangkat lunak yang berbeda.

Web service adalah sistem perangkat lunak yang didesain untuk mendukung interaksi antar mesin melalui jaringan. Web service memiliki interface khusus yang menjelaskan layanan yang ada melalui format yang dapat diproses oleh mesin. Sistem lain dapat berinteraksi dengan web servis melalui prosedur yang ditentukan menggunakan pesan SOAP, XML, ataupun standard web lainnya (W3C 2004).

2.10 Kelapa sawit (Elaeis)

Tanaman kelapa sawit diklasifikasikan sebagai berikut (Pahan 2010): Divisi : Embryophyta Siphonagama

Kelas : Angiospermae Ordo : Monocotyledonae Famili : Arecaceae

Subfamili : Cocoideae Genus : Elaeis

Spesies : E. guineensis Jacq.

E. oleifera (H.B.K) Cortes E. odora

Kelapa sawit yang dibudidayakan terdiri atas dua jenis: E. guineensis dan E. oleifera. Jenis pertama yang terluas dibudidayakan orang secara komersial di Afrika, Amerika Selatan, Asia Tenggara, Pasifik Selatan, serta beberapa daerah lain dengan skala yang lebih kecil. Kedua spesies kelapa sawit ini memiliki keunggulan masing-masing: E. guineensis memiliki produksi yang sangat tinggi dan E. oleifera memiliki tinggi tanaman yang rendah.

Penangkar seringkali melihat tipe kelapa sawit berdasarkan ketebalan cangkang, yang terdiri atas: Dura, Pisifera, dan Tenera (Gambar 3).

Gambar 3 Varietas kelapa sawit (Pahan 2010)

Dura merupakan sawit yang buahnya memiliki cangkang tebal yaitu sekitar 2-8 mm sehingga dianggap memperpendek umur mesin pengolah namun biasanya tandan buahnya besar-besar. Pisifera buahnya tidak memiliki cangkang, sehingga tidak memiliki inti (kernel) yang menghasilkan minyak ekonomis dan bunga betinanya steril sehingga sangat jarang menghasilkan buah. Tenera adalah persilangan antara induk Dura dan jantan Pisifera. Jenis ini dianggap bibit unggul sebab melengkapi kekurangan masing-masing induk dengan sifat cangkang buah tipis sekitar 0,5-4 mm namun bunga betinanya tetap steril.!

2.11 Metode Waterfall

Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Fase waterfall menurut Sommerville (2010) dapat dilihat pada Gambar 4.

Gambar 4 Metodologi pengembangan perangkat lunak waterfall (Sommerville 2010)

a. Requirements analysis and definition

! 17

dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.

b. System and software design

Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap. Desain dilakukan menggunakan UML sebagai pemodelan sistem. c. Implementation and unit testing

Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.

d. Integration and system testing

Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).

e. Operation and maintenance

Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.

Kekurangan utama dari model ini adalah kesulitan dalam mengakomodasi perubahan saat proses telah berjalan. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase selanjutnya. Masalah dengan model waterfall lainnya yaitu:

1. Perubahan sulit dilakukan karena sifatnya yang kaku.

2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.

3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

BAB III METODE PENELITIAN

3.1 Lokasi Penelitian

Penelitian dilakukan di PT. Sasaran Ehsan Mekarsari (PT. SEM) yang beralamat di Jalan Raya Cileungsi, Jonggol Km. 3, Cileungsi Bogor. Penelitian dilakukan pada kantor tersebut karena aktivitas perusahaan seluruhnya dilakukan di sana, seperti lahan pembibitan (Seed Garden), pabrik seleksi (Seed Garden Factory), gudang, dan kantor pusat administrasi (Head Office). Terpusatnya aktivitas mempermudah pengumpulan data yang dibutuhkan pada penelitian ini. 3.2 Langkah Penelitian

Pengembangan perangkat lunak dilakukan menggunakan metode waterfall, dengan proses analisis kebutuhan diperoleh dengan cara menurunkan spesifikasi kebutuhan fungsional/non-fungsional dari sistem yang sedang berjalan ditambah dengan hasil wawancara dengan management PT. SEM. Kerangka penelitian dapat dilihat pada Gambar 5.

3.2.1 Studi kebutuhan

Analisis kebutuhan merupakan suatu tahapan dalam pengembangan perangkat lunak untuk menggali segala bentuk informasi dari awal sampai akhir dengan harapan dapat mengetahui kendala-kendala yang dihadapi. Pada tahapan ini akan digunakan untuk melakukan wawancara mengenai kondisi yang ada sekarang dan masalah yang dihadapi dengan kondisi yang ada beserta harapan untuk memperbaharui kondisi yang ada. Stakeholder yang terkait pada perusahaan akan dilakukan wawancara untuk melakukan verifikasi terhadap kebutuhan sistem yang akan dikembangkan.

3.2.2 Identifikasi masalah

Pada tahapan ini, sudah dapat ditentukan beberapa permasalahan yang ada, baik itu merupakan perbaikan dari sistem yang lama ataupun penambahan suatu proses bisnis yang semakin maju. Pengidentifikasian masalah ini terjadi selama masa wawancara dan penurunan kebutuhan dari sistem yang ada.

3.2.3 Analisis Kebutuhan Sistem

Analisis terhadap kebutuhan sistem dilakukan berdasarkan studi pustaka dan literatur mengenai konsep REST dan ROA yang dibutuhkan selama penelitian. Pada tahap ini proses reverse engineering (penurunan) kebutuhan fungsional dan non-fungsional sistem dianalisis. Hasil analisis akan didokumentasikan dalam tabel kebutuhan sistem.

3.2.4 Desain sistem

Desain sistem secara keseluruhan dilakukan di tahap ini. Arsitektur dikembangkan menggunakan konsep Representational State Transfer (REST). Desain terdiri atas tiga bagian besar sistem: back-end sistem informasi (services provider), back-end sistem informasi geografis (services composer), dan front-end sistem informasi (services consumer). Dokumentasi sistem dilakukan menggunakan Unified Modelling Language (UML) berupa diagram kelas yang menggambarkan keterhubungan antar entitas yang ada pada sistem yang akan dibangun.

Desain sistem terdiri atas tiga tahap: perancangan back-end sistem informasi, back-end GIS, dan front end sistem informasi. Perancangan back-end sistem informasi dilakukan dalam beberapa tahap sesuai dengan Gambar 6.

! 21

Gambar 6 Tahap perancangan back-end sistem informasi (Richardson & Ruby 2007)

! Tahap pertama yaitu perancangan back-end sistem informasi. Tahap ini dilakukan dalam beberapa tahap yaitu:

1. Identifikasi resource melalui entitas yang ada

Pada tahap ini dihasilkan diagram domain (domain diagram) yang menggambarkan entitas yang terlibat pada proses bisnis di perusahaan. Diagram domain ini kemudian digunakan sebagai dasar dalam penentuan kandidat resource yang dibutuhkan pada server.

2. Pemetaan URI untuk setiap resource yang ada

Setiap resource yang ada akan dikelompokkan menurut divisi perusahaan tempat entitas tersebut berada. Selanjutnya penamaan URI untuk setiap resource yang ada dilakukan berdasarkan domain perusahaan tersebut sehingga URI dari setiap resource akan berbentuk hirarki, contoh:

/marketing/customer yang diperuntukkan bagi customer yang

merupakan entitas pada bagian marketing. 3. Penentuan uniform interface yang digunakan

Perancangan uniform interface yang dibutuhkan untuk setiap resource dilakukan pada tahap ini. Secara spesifik, pada tahap ini setiap resource telah memiliki URI-nya masing-masing sehingga rancangan interface yang digunakan secara teknis diberlakukan terhadap URI tersebut.

Interface yang akan digunakan pada penelitian ini terdiri atas GET, POST, PUT, dan DELETE. Operasi yang didefinisikan terhadap setiap interface yaitu:

a) Interface GET melakukan pembacaan terhadap URI yang diberikan kepada server. Pembacaan yang dilakukan dapat ditujukan kepada seluruh resource yang berdasarkan URI tersebut atau terhadap resource tertentu dengan id spesifik. Saat operasi dilakukan terhadap parameter

yang bukan id, maka data yang dikembalikan dari server adalah resource dengan pengelompokkan berdasarkan parameter yang diberikan. Sebagai contoh URI /prenursery/stock/age akan menghasilkan pembacaan resource /stock/ (stok) yang dikelompokkan berdasarkan /age (usia). Selain itu operasi GET dapat pula dilakukan terhadap sub-resource dari suatu resource seperti /marketing/order_item/order/{order} yang berarti operasi dilakukan terhadap /order_item/ yang merupakan sub-resource dari /order/{order}, dengan {order} adalah suatu identifier.

b) Interface POST digunakan untuk melakukan operasi pembuatan resource baru pada URI yang diberikan kepada server. Interface ini dapat pula digunakan untuk menambah item dari suatu resource yang memiliki hubungan dengan resource lainnya. Sebagai contoh resource /marketing/order/ didalamnya mengandung satu atau lebih resource

/order_item/, operasi modifikasi terhadap item dari /order/ dalam

hal ini adalah /order_item/ dapat dilakukan dengan menyertakan identitas {order} yang merujuknya. Operasi menggunakan interface POST pada URI /marketing/order_item/order/123 berarti penambahan item baru terhadap resource /order/ dengan nomor order 123.

c) Interface PUT digunakan untuk melakukan pengubahan terhadap resource tertentu. Operasi dilakukan dengan menyertakan id dari resource yang ingin diubah pada parameter URI yang dikirim kepada server. Sama halnya dengan interface POST, PUT dapat dilakukan terhadap sub-resource dari suatu resource tertentu dengan cara menyertakan id dari resource yang merujuknya.

d) Interface DELETE digunakan untuk melakukan penghapusan terhadap resource tertentu. Operasi dilakukan dengan menyertakan id dari resource yang ingin dihapus pada parameter URI yang dikirim kepada server.

! 23

4. Perancangan format representasi yang dikirim ke server.

Komunikasi antara client dan server dilakukan berdasarkan uniform interface yang telah dirancang pada tahap sebelumnya. Selanjutnya pada tahap ini dilakukan perancangan format representasi yang akan digunakan oleh client dalam mengirimkan data kepada server. Aturan format representasi yang dihasilkan pada tahap ini akan menjadi pedoman bagi client dalam melakukan komunikasi pengubahan (PUT) dan pembuatan baru (POST) untuk resource yang ada terutama dalam hal atribut yang ada untuk setiap resource.

5. Perancangan format representasi yang dikembalikan dari server.

Pada tahap ini dilakukan perancangan format representasi yang dikembalikan oleh server terhadap setiap operasi yang dilakukan untuk setiap resource. Hasil dari tahap ini adalah dokumentasi format representasi yang dapat digunakan oleh client dalam menerima dan membaca resource yang ada.

6. Integrasi antara satu resource dengan resource lainnya menggunakan hypermedia

Perancangan hubungan antara resource yang satu dengan lainnya dilakukan pada tahap ini. Setiap resource yang mengandung resource lainnya akan direpresentasikan menggunakan konsep hypermedia yang pada dasarnya berupa tautan/link ke resource yang dirujuk tersebut. Diagram domain yang dihasilkan sebelumnya digunakan lagi pada tahap ini sebagai rujukan keterhubungan antara resource yang satu dengan lainnya.

7. Perancangan kode respon dari server

Pada tahap ini dirancang kode respon hasil komunikasi antara client dengan server. Perancangan yang akan dilakukan meliputi kode respon yang menunjukkan kesuksesan suatu request maupun kesalahan-kesalahan yang dapat terjadi saat komunikasi berlangsung. Kode respon yang digunakan berdasarkan standard HTTP 1.1 (Fielding et al. 1999).

Tahap kedua adalah perancangan back-end GIS yang akan dilakukan menggunakan framework yang telah ada dalam mengolah data spasial. Selanjutnya perancangan fitur yang disediakan oleh back-end GIS tersebut

ditentukan pada tahap ini yang selanjutnya akan menjadi masukan bagi front-end sistem informasi.

Tahap ketiga adalah perancangan front end sistem informasi. Perancangan akan dilakukan menggunakan framework dengan tujuan merefleksikan fitur yang ada dari kedua back-end yang ada. Front-end akan dikembangkan berbasis web yang menampilkan hasil transaksi data dengan kedua back-end yang ada. Front-end sistem tidak akan melakukan banyak proses bisnis karena berperan sebagai client dari web service sehingga rancangan yang dihasilkan pada tahap ini adalah rancangan antarmuka sistem informasi yang pada akhirnya berhubungan langsung dengan pengguna.

3.2.5 Implementasi sistem

Implementasi akan dikembangkan menggunakan beberapa bahasa pemrograman dan pada platform yang beragam. Services provider yang berfungsi sebagai back-end sistem informasi dikembangkan menggunakan framework Restler (PHP), services composer yang mengolah data GIS diimplementasikan menggunakan framework geoserver (JAVA), dan front-end yang langsung berinteraksi dengan pengguna akan dikembangkan menggunakan framework Code Igniter (PHP). Sistem operasi yang digunakan adalah empat buah Ubuntu yang diletakkan pada virtual machine. Implementasi front-end sistem informasi digunakan sebagai prove of concept (POC) dari arsitektur sistem secara keseluruhan.

3.2.6 Pengujian sistem

Sistem akan diuji menggunakan data contoh (dummy) yang merepresentasikan data aktifitas kegiatan penelitian di perusahaan tersebut. Pengujian akan dilakukan secara sederhana yaitu pengujian black box terhadap seluruh fungsi yang tersedia pada back-end sistem informasi dan back-end-gis. Pengujian sistem dilakukan pada front-end sistem informasi menggunakan peramban Google Chrome dengan addon Postman. Pengujian yang dilakukan terdiri atas:

1. Pengujian terhadap keberhasilan transaksi yang dilakukan antara client dan back-end sistem informasi. Pengujian dilakukan dengan melakukan request

! 25

dan melihat hasil response yang diberikan sesuai dengan skenario yang dibuat.

2. Pengujian terhadap tema peta dengan melakukan request terhadap back-end GIS dan memeriksa hasil yang diberikan.

3. Pengujian terhadap kode respon yang diberikan oleh server terhadap situasi tertentu.

3.2.7 Dokumentasi

Tahap ini merupakan proses pembuatan dokumentasi sistem yang terdiri atas deskripsi arsitektur back-end SI, front-end SI, back-end SIG, dan front-end SIG. Dokumentasi yang dihasilkan akan bermanfaat bagi stakeholder yang memiliki kepentingan terhadap sistem informasi yang ada. Dokumentasi arsitektur akan menjadi panduan bagi pengembang sistem dalam melakukan modifikasi terhadap sistem. Dokumentasi front-end akan menjadi panduan bagi pengguna yang berinteraksi dengan sistem secara langsung.

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)

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.