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

Transkripsi

1 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 i

2 ii ii

3 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 G iii

4 iv iv

5 v ABSTRACT IMAM ABU DAUD. Oil Palm Nursery Information System based on Resourceoriented 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 v

6 vi vi

7 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 realtime 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. vii

8 viii 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 backend SI yang dikombinasikan dengan data spasial pada 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 (realtime). 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. viii

9 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. ix

10 x x

11 xi SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA) STUDI KASUS PT. SASARAN EHSAN MEKARSARI IMAM ABU DAUD G 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 xi

12 xii Penguji pada Ujian Tesis : Sony H. Wijaya, S.Kom., M.Kom. xii

13 xiii xiii

14 xiv xiv

15 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 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 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. xv

16 xvi xvi

17 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 Imam Abu Daud xvii

18 xviii xviii

19 xix DAFTAR ISI Halaman DAFTAR GAMBAR... xxi DAFTAR TABEL... xxiii DAFTAR LAMPIRAN... xxv BAB I PENDAHULUAN Latar Belakang Rumusan Permasalahan Tujuan Penelitian Manfaat Penelitian Ruang Lingkup Penelitian... 4 BAB II TINJAUAN PUSTAKA Resource-oriented Architecture (ROA) Representational State Transfer (REST) Application state dan Resource State Hypermedia As The Engine Of Application State (HATEOAS) Template URI Kode respon HTTP HTTP header Uniform Resource Identifier (URI) Web Service Kelapa sawit (Elaeis) Metode Waterfall BAB III METODE PENELITIAN Lokasi Penelitian Langkah Penelitian Studi kebutuhan Identifikasi masalah Analisis Kebutuhan Sistem Desain sistem Implementasi sistem Pengujian sistem xix

20 xx Dokumentasi BAB IV HASIL DAN PEMBAHASAN Domain permasalahan Kebun (garden) Gudang (warehouse) Pabrik (factory) Pemasaran dan Administrasi (marketing) Kepegawaian (human resources) Analisis kebutuhan Kebun (garden) Gudang (warehouse) Pabrik (factory) Pemasaran dan Administrasi (marketing) Kepegawaian (human resources) Direktur Perancangan Identifikasi Resource Pemetaan Resource Penentuan Uniform Interface Desain representasi yang dikirim ke server Format representasi yang dikembalikan dari server Integrasi resource menggunakan hypermedia Kode respon dari server Implementasi front-end Sistem Informasi (SI) Implementasi back-end Sistem Informasi Geografis (SIG) Implementasi front-end Sistem Informasi Geografis (SIG) Implementasi integrasi sistem Pengujian Sistem BAB V SIMPULAN DAN SARAN Simpulan Saran DAFTAR PUSTAKA xx

21 DAFTAR GAMBAR Halaman 1 Representasi photo yang berisi hypermedia jenis link (Allamaraju 2010) Catatan respon dari pembacaan resource (Richardson & Ruby 2007) Varietas kelapa sawit (Pahan 2010) Metodologi pengembangan perangkat lunak waterfall (Sommerville 2010) Kerangka penelitian Tahap perancangan back-end sistem informasi (Richardson & Ruby 2007) Proses perkecambahan bibit kelapa sawit Use case kebutuhan SI pembibitan kelapa sawit Template pemetaan URI terhadap resource yang ada Rancangan representasi XML untuk dikirim ke server Representasi XML pada resource panen tandan Ilustrasi request menggunakan POST (pembuatan resource baru) Ilustrasi request menggunakan GET (pembacaan) Ilustrasi request menggunakan PUT (pengubahan) Ilustrasi request menggunakan DELETE (penghapusan) Ilustrasi format representasi hasil pembacaan resource Implementasi hypermedia pada representasi resource Front-end sistem informasi sebagai penengah komunikasi Rancangan tampilan back-end sistem informasi Rancangan tampilan front-end sistem informasi Proses pembaruan informasi tema peta x Arsitektur sistem Hasil pengujian resource /garden/bunch/ Tampilan peta, (a) peta tanaman terpilih dari basis data asli, (b) salah satu baris telah ditambahkan xxi

22 xxii xxii

23 xxiii DAFTAR TABEL Halaman 1 Uniform Resource Interface yang digunakan pada RESTful HTTP (Roth 2012) 7 2 Pemetaan URI di pembibitan (domain: /nursery/*) Pemetaan URI di pembibitan prenursery (domain: /prenursery/*) Pemetaan URI di pembibitan mainnursery (domain: /mainnursery/*) Pemetaan URI di kebun (domain: /garden/*) Pemetaan URI di gudang (domain: /warehouse/*) Pemetaan URI di pabrik (domain: /factory/*) Pemetaan URI di pemasaran (domain: /marketing/*) Pemetaan URI di kepegawaian (domain: /hr/*) Rancangan interface pada komunikasi antara client dan server Struktur tabel panen tandan (tree_harvesting) Kode respon dari server untuk operasi menggunakan interface GET Kode respon dari server untuk operasi menggunakan interface PUT Kode respon dari server untuk operasi menggunakan interface POST kode respon dari server untuk operasi menggunakan interface DELETE Parameter pengujian resource dari garden/bunch/ Parameter pengujian pembuatan resource baru dari garden/bunch/ Parameter pengujian penyuntingan resource dari garden/bunch/ Parameter pengujian penghapusan resource dari garden/bunch/ Skenario umum pengujian kode respon pada interface GET Skenario umum pengujian kode respon pada interface PUT Skenario umum pengujian kode respon pada interface POST Skenario umum pengujian kode respon pada interface DELETE xxiii

24 xxiv xxiv

25 xxv DAFTAR LAMPIRAN Halaman 1 Kegiatan pembibitan di perusahaan Diagram domain bisnis di perusahaan Rancangan template URI Back-end SI menggunakan Google Chrome (addon Postman) Front-end SI Back-end SIG menggunakan Geoserver Front-end SIG menampilkan tema peta pohon terpilih xxv

26 xxvi xxvi

27 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. 1

28 2 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.

29 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 frontend 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.

30 4 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 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.

31 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: 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 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. 5

32 6 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

33 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 Idempotent lama POST Membuat resource baru atau sub-resource baru dengan id dikelola oleh server

34 8 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

35 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

36 10 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 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.

37 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: (Ok). Kode ini mengindikasikan server sukses melakukan operasi yang diminta oleh client (Created). Server mengirimkan kode ini jika resource telah tersimpan/tercipta sesuai dengan request yang dikirim oleh client (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: (Bad Request). Merupakan kode generik dari kesalahan yang disebabkan oleh client (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 (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.

38 (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 (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 (Not Acceptable). Kode ini diberikan saat server tidak dapat memenuhi permintaan format representasi yang diminta oleh client (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 (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 (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: (Internal Server Error). Kode ini merupakan kode generik dari respon kesalahan yang terjadi oleh server (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

39 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 maka header ini akan berisi 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.

40 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: Peramban dapat memanipulasi resource dengan menghubungi server lokasi tempat resource tersebut berada ( 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: 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 bukanlah resource yang berbeda.

41 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) 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).

42 16 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 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 Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan

43 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.

44

45 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. Gambar 5 Kerangka penelitian 19

46 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 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 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 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.