II-21 BAB II
LANDASAN TEORI 2.1 Produksi Pangan
Menurut Undang-Undang Nomor 18 Tahun 2012 Pasal 1 Ayat 6. “Produksi Pangan adalah kegiatan atau proses menghasilkan, menyiapkan, mengolah, membuat, mengawetkan, mengemas, mengemas kembali, dan/atau mengubah bentuk Pangan”.
Menurut Djuni, dkk (2012) berikut merupakan strategi untuk pengembangan produksi dan ketersediaan bahan pangan dapat dilakukan dengan beberapa cara yaitu:
1. Peningkatan dan pemeliharaan kapasitas produksi nasional 2. Peningkatan produksi bahan pangan dalam negeri
3. Percepatan peningkatan produksi bahan pangan nonkonvensional
4. Pengembangan teknologi untuk peningkatan produktivitas usaha masyarakat.
Djuni, dkk (2012) juga menjelaskan, untuk menjamin kecukupan bahan pangan strategi pengembangan teknologi hendaknya mampu.
1. Meningkatkan dan memelihara kapasitas produksi nasional.
2. Meningkatkan produksi pangan domestic.
3. Meningkatkan produktivitas (dan pendapatan) usaha masyarakat.
4. Memperkecil kehilangan.
5. Meningkatkan nilai tambah.
6. Meningkatkan efisiensi usaha.
Menurut Dickiaulia (2020:9) dalam produksi pangan terdapat dua jenis faktor yaitu simultan atau bersama-sama dan parsial atau sendiri-sendiri. Berikut merupakan faktor- faktor tersebut:
1. Secara bersama-sama (simultan) terdiri atas: luas lahan garapan, jumlah tenaga kerja efektif, jumlah pupuk, jumlah pestisida, pengalaman petani dalam berusaha tani, jarak rumah dengan lahan garapan, dan sistem irigasi.
2. Secara sendiri-sendiri (parsial) terdiri atas: luas lahan garapan, jumlah tenaga kerja efektif, jumlah pupuk, jumlah pestisida (obat-obatan), dan jarak lahan garapan dengan rumah petani.
Menurut Dickiaulia (2020:9) pembagian dalam kedua faktor tersebut dibagi menjadi berikut:
1. Faktor produksi yang terdiri dari luas lahan, jumlah benih, jumlah pupuk, jumlah pestisida dan tenaga kerja.
2. Faktor parsial yaitu parsial luas lahan, jumlah pupuk dan jumlah pestisida.
2.2 Surplus Defisit Pangan
Surplus defisit pangan dihitung dari selisih antara jumlah produksi dalam satuan waktu (minggu/bulan/tahun) dengan jumlah kebutuhan seluruh penduduk (dalam ton).
(Rejekiningrum, 2013:66)
Selama ini pemerintah dalam menghitung kelebihan hasil panen, atau surplus, sering kali dinyatakan dalam ukuran atau satuan “ton”. Penggunaan satuan berat ini digunakan sebagai satuan atau ukuran yang merepresentasikan jumlah kelebihan panen di suatu daerah dalam skala nasional. Namun akan terjadi perbedaan hasil jika satuan berat tersebut digunakan sebagai ukuran surplus dari dua negara yang sangat berbeda jumlah penduduknya. Sebagai contoh sebuah negara yang berpenduduk 20 juta orang (negara “A”) yang berhasil panen dengan surplus 500.000 ton. Jika diasumsikan konsumsi beras per orang adalah 0,5 kg/hari, maka konsumsi penduduk negara “A” adalah 10.000 ton/hari. Ini berarti bahwa surplus beras sebesar 500.000 ton akan dapat memenuhi kebutuhan beras seluruh penduduk selama 50 hari, di saat terjadi kegagalan panen total di masa tanam pertama tahun berikutnya. Bandingkan jika terjadi surplus 500.000 ton di negara “B” yang berpenduduk 240 juta, dengan cara yang sama, akan didapati bahwa konsumsi beras dari seluruh penduduk negara “B” adalah 120.000 ton/hari. Ini berarti bahwa surplus beras negara “B” hanya dapat memenuhi kebutuhan beras seluruh penduduk selama 4 hari, untuk masa tanam yang sama. Perhitungan tersebut didasarkan pada asumsi bahwa tidak ada beras import di pasar, sehingga menunjukkan tingkat
ketahanan pangan yang sesungguhnya (tanpa intervensi beras import). Terlihat bahwa terjadi perbedaan nilai manfaat dari surplus beras sebesar 500.000 ton yang dihasilkan oleh kedua negara yang berbeda ketika harus menghadapi kegagalan panen total di masa tanam pada tahun berikutnya. Oleh karena itu, ukuran surplus juga harus dapat menjadi indikator langsung dari tingkat ketahanan pangan negara yang mengalami surplus tersebut. (Rejekiningrum, 2013:64)
Rumus menghitung surplus defisit pangan, yaitu :
SDP = PP – (P X K)
SDP = Surplus Defisit Pangan PP = Produksi Pangan P = Penduduk K = Konsumsi
Kriteria surplus dikategorikan kedalam beberapa hal, yaitu :
1. Mencapai target surplus jika nilai surplus sama dengan nilai yang ditetapkan 2. Melebihi target surplus, jika surplus lebih dari nilai yang ditetapkan
3. Kurang dari target surplus, jikan surplus kurang dari nilai yang ditetapkan
Prasada dan Tia (2018,212), menjelaskan dalam menghitung konsumsi pangan.
Konsumsi pangan penduduk dapat tercermin dari data pengeluaran per kapita penduduk per bulan untuk setiap komoditas. Data tersebut kemudian dibagi dengan harga yang berlaku pada tahun bersangkutan untuk mendapatkan data konsumsi pendudk perkapita per bulan.
2.3 Rational Unified Process (RUP)
Menurut Suryana (2007), Rational Unified Process (RUP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak. RUP menggunakan konsep object oriented, dengan
aktifitas yang berfokus pada pengembangan model menggunakan Unified Model Language (UML).
Gambar 2. 1 Arsitekture Rational Unified Process (RUP) 1. Dimensi pertama digambarkan secara horizontal.
Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari fase selanjutnya. Setiap fase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition.
2. Dimensi kedua digambarkan secara vertikal.
Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, how dan when. Dimensi ini terdiri atas Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment.
Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (object orinted) memiliki manfaat yakni :
1. Improve productivity
Standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia atau dibuat sehingga dapat meningkatkan produktifitas
2. Deliver high quality system
Kualitas sistem informasi dapat ditingkatkan sebagai sistem yang dibuat pada komponen-komponen yang telah teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery sistem informasi yang dibuat dengan kualitas yang tinggi.
3. Lower maintenance cost
Standard ini dapat membantu untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard yang jelas.
4. Facilitate reuse
Standard ini memiliki kemampuan yang mengembangkan komponen- komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.
5. Manage complexity
Standard ini mudah untuk mengatur dan memonitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua manajer proyek yakni deliver good quality software within cost and schedule time and the users accepted.
2.3.1 Fase RUP
Menurut Suryana (2007), dijelaskan juga fase-fase yang digunakan dalam metode RUP.
1. Inception
a. Menentukan ruang lingkup proyek b. Membuat ‘Business Case’
c. Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan
2. Elaboration
a. Menganalisa berbagai persyaratan dan resiko b. Menetapkan ‘base line’
c. Merencanakan fase berikutnya yaitu construction 3. Construction
a. Melakukan sederetan iterasi
b. Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing
4. Transition
a. Membuat apa yang sudah dimodelkan menjadi suatu produk jadi b. Dalam fase ini dilakukan:
a) Beta dan performance testing
b) Membuat dokumentasi tambahan seperti: training, user guides dan sales kit
c) Membuat rencana peluncuran produk ke komunitas pengguna
2.3.2 Penerapan Tahapan Metodologi Perangkat Lunak Menggunakan RUP Menurut Suryana (2007), dalam penerapan tahapan metodologi Rational Unified Process (RUP). Metode RUP merupakan metode pengembangan kegiatan yang berorientasi pada proses. Dalam metode ini, terdapat empat tahap pengembangan perangkat lunak yaitu:
1. Inception
Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user, dan melakukan perancangan awal perangkat lunak (perancangan arsitektural dan use case). Pada akhir fase ini, prototipe perangkat lunak versi Alpha harus sudah dirilis
2. Elaboration
Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikasikan fitur perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak.
3. Construction
Pengimplementasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi perangkat lunak.
4. Transition
Instalasi, deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.
2.3.3 Workflow dan Metodologi RUP
Dalam setiap tahapan pengerjaan dilakukan beberapa jenis kegiatan yang umumnya berjalan bersamaan. Pada lima bagian kegiatan yang dipakai dalam pembangunan sistem ini adalah Business Modeling, Requirement, Analysis and Design, Implementation, dan Test.
(Hidayat dan Sofwandi, 2018:5) menjelaskan:
1. Business Modeling
Dalam Business Modeling dilakukan beberapa aktifitas seperti Assess Business Status, Identify Business Process, sampai dengan Refine Roles and Responsibilities. Aktifitas ini dilakukan untuk memahami bisnis proses yang diperlukan untuk pembangunan sistem informasi produksi pangan.
2. Requirement
Wawancara dengan pihak Instansi Pemerintah sangat diperlukan untuk memberikan gambaran yang lebih detail tentang bisnis proses yang berjalan dalam menentukan kebutuhan sistem yang akan dibangun.
3. Analysis
Aktifitas Analisis kebutuhan mendeskripsikan secara detil kebutuhan dari aplikasi yang dikembangkan dengan penyusunan dokumen use-case dan business rules. Analisis kebutuhan meliputi:
a. Analisis terhadap kondisi sistem yang telah ada. Dilakukan analisis mengenai siapa saja pihak-pihak yang akan terlibat di dalam Sistem (organisasi atau aplikasi lain) dan bagaimana bentuk komunikasi informasi yang terjadi antar pihak-pihak tersebut.
b. Analisis terhadap kebutuhan sistem informasi. Berkaitan dengan analisis terhadap kondisi sistem yang telah ada di atas, maka pada tahap ini dilakukan analisis mengenai proses-proses mana saja yang membutuhkan penanganan melalui Sistem Informasi.
c. Mengidentifikasi keluaran sistem informasi. Sebagai kelanjutan dari aktifitas di atas, pada tahap ini dilakukan pengidentifikasian ruang lingkup bentuk keluaran (output) dari sistem informasi yang dihasilkan.
d. Pendokumentasian hasil analisis. Hasil akhir analisis kebutuhan adalah dokumen-dokumen berikut:
a) Dokumen Use Case yang berisi pendetilan skenario penggunaan aplikasi mengikuti format yang telah ditetapkan.
b) Non Functional Requirements yaitu berisi pembatasan-pembatasan teknis mengenai perangkat lunak yang harus dibangun.
c) Business Rules yaitu aturan-aturan yang harus diikuti oleh aplikasi.
Business Rules diperoleh langsung dari peraturan kerja organisasi dan dari hasil survei.
4. Design
Aktifitas Desain mendeskripsikan solusi teknis yang akan digunakan untuk mencapai perilaku yang sudah ditetapkan dalam kegiatan requirement.
Desain di sini meliputi desain alur, desain interaksi, desain visual, dan desain teknis. Kegiatan ini dilakukan oleh Analis dan Desainer Sistem, Desainer Visual. Desain yang digunakan di dalam pengerjaan Sistem Informasi ini adalah desain berorientasi objek dengan menggunakan UML (Unified Modeling Language).
5. Implementation
Implementasi yaitu merealisasikan desain ke dalam kode komputer yang dapat dieksekusi oleh komputer. Ini dilakukan dengan melakukan pemrograman. Pemrograman dilakukan dengan menggunakan satu atau lebih bahasa pemrograman dengan bantuan perangkat kerjanya.
6. Test
Aktifitas Uji Coba dilakukan dengan tujuan untuk menghilangkan kesalahan-kesalahan yang mungkin timbul. Uji coba dilakukan oleh seorang Tester atau programmer tergantung jenis pengujiannya. Uji coba terdiri dari beberapa yaitu:
a. Uji coba proses yang dilakukan secara otomatis oleh software. Agar hal ini dapat dilakukan maka untuk setiap fungsi atau proses di dalam aplikasi perlu disiapkan data uji dan prosesnya dimasukkan ke dalam sebuah perangkat yang disebut UnitTest. UnitTest kemudian dapat terus-menerus dijalankan secara otomatis untuk memastikan bahwa proses telah dilakukan oleh sistem dengan benar dan tetap benar setelah dilakukan berbagai modifikasi atau penambahan fitur.
b. Uji coba antar muka yang dilakukan oleh tester (penguji coba). Penguji coba selain mencatat kesalahan yang mungkin timbul juga bertanggung jawab untuk memberi masukan-masukan mengenai kemudahan penggunaan sistem.
c. Analisis kinerja atas sistem yang dibangun yang disesuaikan dengan dokumen analisis kebutuhan yang dibuat pada kegiatan analisis kebutuhan.
Hasil akhir kegiatan uji coba adalah laporan bug (kesalahan program) beserta dengan laporan perbaikan kesalahan program yang telah dilakukan.
2.3.4 Pemodelan UML
Menurut Badriyah (2007) Unified Modeling Language (UML) adalah Bahasa standart untuk melakukan spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen- komponen perangkat lunak, dan digunakan untuk pemodelan bisnis. Pemodelan dengan
UML berarti menggambarkan yang ada dalam dunia nyata ke dalam bentuk yang dapat dipahami dengan menggunakan notasi standar UML.
“Unified Modelling Language (UML) adalah suatu alat untuk memvisualisasikan dan mendokumentasikan hasil analisa dan desain yang berisi sintak dalam memodelkan sistem secara visual” (Haviluddin, 2001:1). UML Juga merupakan satu kumpulan konvensi pemodelan yang digunakan dalam menentukan atau menggambarkan sebuah sistem software yang terkait dengan objek. (Haviluddin, 2001:1)
2.3.5 Diagram UML
Macam-macam diagram UML adalah sebagai berikut menurut Syarif dan Wahyu (2020:65).
a. Use Case Diagram
Use case atau diagram use case merupakan pemodelan untuk kelakuan (behavior) sistem informasi yang akan dibuat.
b. Class Diagram
Diagram kelas atau class diagram menggambarkan struktur sistem dari segini pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem.
c. Activity Diagram
Diagram aktivitas atau activity diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis atau menu yang ada pada perangkat lunak.
d. Sequence Diagram
Sequence diagram merupakan UML yang menggambarkan interaksi antar objek di dalam dan disekitar sistem, termasuk pengguna, display, dan sebagainya berupa message yang digambarkan terhadap waktu.
