PEMBANGUNAN SISTEM INFORMASI MANAJEMEN BARANG
MENGGUNAKAN METODE EOQ (ECONOMIC ORDER QUANTITY)
DENGAN BAHASA PEMROGRAMAN JAVA
(STUDI KASUS TOKO SEHAT SUBUR, PETANAHAN KEBUMEN)
SKRIPSI
Disusun sebagai Salah Satu Syarat
untuk Memperoleh Gelar Sarjana Komputer
pada Jurusan Ilmu Komputer / Informatika
Disusun Oleh:
Fauzan Aziz
J2F 008 101
JURUSAN ILMU KOMPUTER / INFORMATIKA
FAKULTAS SAINS DAN MATEMATIKA
HALAMAN PENGESAHAN
Judul : Pembangunan Sistem Informasi Manajemen Barang Menggunakan Metode EOQ (Economic Order Quantity) Dengan Bahasa Pemrograman Java (Studi Kasus Toko Sehat Subur Petanahan, Kebumen)
Nama : Fauzan Aziz Nim : J2F008101
Telah diujikan pada sidang Tugas Akhir tanggal ____________
Semarang, Desember 2013
Pembimbing Utama,
Nurdin Bahtiar, S.Si, MT NIP. 19790720 200312 1 002
Pembimbing Anggota,
HALAMAN PENGESAHAN
Judul : Pembangunan Sistem Informasi Manajemen Barang Menggunakan Metode EOQ (Economic Order Quantity) Dengan Bahasa Pemrograman Java (Studi Kasus Toko Sehat Subur Petanahan, Kebumen)
Nama : Fauzan Aziz Nim : J2F008101
ABSTRAK
Permasalahan yang sering dihadapi penjual ketika memasarkan produk adalah masalah persediaan produk itu sendiri. Upaya untuk mengoptimalkan ketersediaan produk salah satunya adalah dengan cara menggunakan metode EOQ (Economic Order Quantity). Metode EOQ merupakan cara untuk mengetahui berapa jumlah yang paling ekonomis untuk melakukan pemesanan dalam sekali periode. Dalam Tugas Akhir ini permasalahan yang diangkat adalah bagaimana perhitungan dengan menggunakan metode EOQ? Kapan pemesanan ulang barang (Reorder Point) dilakukan. Berapa besar biaya penyimpanan barang (Total Carrying Cost), biaya pemesanan (Total Ordering Cost), biaya stok aman barang (Ordering Safety Stock), total biaya persediaan (Total Inventory Cost) yang harus dikeluarkan?. Dalam kaitannya dengan kemajuan iptek, metode EOQ dapat diimplementasikan ke dalam sistem komputerisasi berbasis desktop dengan menggunakan bahasa pemrograman Java. Pengaplikasian berbasis desktop ini diharapkan dapat membantu permasalahan yang dialami penjual khususnya adalah Toko Sehat Subur sebagai pihak pengguna.
ABSTRACT
Problems are often encountered when marketing products seller is itself the product inventory problem . Efforts to optimize the availability of products one of which is by using the EOQ (Economic Order Quantity). EOQ method is a way to know how many of the most economical to place an order in one period . In this final issue raised is how the calculation by using the EOQ. When to reorder goods (Reorder Point) do. How much does the storage of goods(Total Carrying Cost), booking fee (Total Ordering Cost), safety stock cost of goods (Ordering Safety Stock), the total cost of inventory (Total Inventory Cost) that must be removed? . In relation to the progress of science and technology, EOQ method can be implemented into a desktop based computerized system using the Java programming language. Desktop based application is expected to help the problems experienced by the seller in particular is Toko Sehat Subur as the case study authors.
KATA PENGANTAR
Puji syukur penulis panjatkan kehadirat Allah SWT yang telah melimpahkan rahmat dan hidayah-Nya sehingga penulis dapat menyusun tugas akhir yang berjudul “Pembangunan Sistem Informasi Manajemen Barang Menggunakan Metode EOQ (Economic Order Quantity) Dengan Bahasa Pemrograman Java (Studi Kasus Toko Sehat Subur Petanahan, Kebumen)” untuk mendapatkan gelar sarjana strata satu Jurusan Ilmu Komputer / Informatika pada Fakultas Sains dan Matematika Universitas Diponegoro (FSM UNDIP).
Dalam penyusunan tugas akhir ini, penulis mendapat bantuan dan dukungan dari banyak pihak. Atas peran sertanya dalam membantu dalam penyelesaian tugas akhir ini, penulis ingin mengucapkan terima kasih kepada :
1) Dr. Muhamad Nur, DEA selaku Dekan FSM UNDIP.
2) Nurdin Bahtiar, S.Si., MT selaku Ketua Jurusan Ilmu Komputer / Informatika FSM UNDIP.
3) Nurdin Bahtiar, S.Si., MT selaku pembimbing I dan Panji Wisnu Wirawan, ST, MT selaku pembimbing II yang telah meluangkan waktu untuk membimbing dan mengarahkan Penulis dalam menyelesaikan tugas akhir ini.
4) Toko Sehat Subur yang telah memberikan ijin kepada penulis untuk melakukan observasi dan membantu memberikan informasi pada tugas akhir ini.
5) Semua pihak yang telah membantu hingga selesainya tugas akhir ini, yang tidak dapat penulis sebutkan satu persatu.
Penulis menyadari bahwa masih banyak kekurangan dalam penyusunan laporan tugas akhir ini, untuk itu penulis mohon maaf dan mengharapkan saran serta kritik yang membangun dari pembaca. Semoga laporan tugas akhir ini dapat bermanfaat bagi pengembangan ilmu dan pengetahuan, khususnya pada bidang Teknik Informatika.
Semarang, Desember 2013
DAFTAR ISI
2.3. Metode EOQ (Economic Order Quantity) 13 2. 2. 1. EOQ (Economic Order Quantity) 13 2. 2. 2. Pemesanan Ulang (ReOrder Point) 13
2. 2. 3. Biaya Penyimpanan (Total Carrying Cost) 14 2. 2. 4. Biaya Pemesanan (Total Ordering Cost) 14 2. 2. 5. Biaya Safety Stock (OSS) 15
2. 2. 6. Jumlah Total Biaya Persediaan (TIC) 15 2.4. Konsep Object Oriented 15
2.5. Bahasa Pemrograman Java 17
2.6. Database Management SystemMySQL18 2.7. Unified Modelling Language (UML) 18
2. 7. 2. Diagram 19 2. 7. 3. Relationship 24 2.8. Unified Process 25
BAB III 29
3.1. Definisi Kebutuhan Perangkat Lunak 29 3.2. Deskripsi Umum Perangkat Lunak 29 3.3. Model Use Case 32
3. 3. 1. Definisi Aktor 32
3. 3. 2. Definisi Use Case 32 3. 3. 3. Use Case Diagram 34 3. 3. 4. Use Case Detail 34
3.4. Kebutuhan Non-fungtional Perangkat Lunak 54 3.5. Analisis 54
3. 5. 1. Realisasi Use Case Tahap Analisis 54 3. 5. 2. Class Analysis 61
3.6. Perancangan 63
3. 6. 1. Class Diagram Tahap Perancangan 63 3. 6. 2. Perancangan Basis Data 64
3. 6. 3. Analisis dan Perancangan Metode EOQ (Economic Order Quantity) 66
BAB IV 70
4.1. Implementasi 70
4. 1. 1. Spesifikasi perangkat pada pengembangan sistem informasi 70 4. 1. 2. Implementasi Kelas 71
4. 1. 3. Implementasi Database 72
4. 1. 4. Implementasi Antarmuka 73 4.2. Pengujian 90
4. 2. 1. Lingkungan Pengujian 91 4. 2. 2. Rencana Pengujian 91 4. 2. 3. Pelaksanaan Pengujian 92 4. 2. 4. Evaluasi Pengujian 92
BAB V 93
DAFTAR GAMBAR
Gambar 2.1 Interaksi Komponen Sistem Informasi...7
Gambar 2.2 Faktor-faktor yang mempengaruhi persediaan bahan...12
Gambar 2.3 Inheritance, Class B, C, dan D Mewarisi Class A...16
Gambar 2.4 Contoh Activity Diagram...20
Gambar 2.5 Use Case Kegiatan Pasien...21
Gambar 2.6 Contoh Communication Diagram...22
Gambar 2.7 Contoh Class Diagram...23
Gambar 2.8 Contoh Communication Diagram...24
Gambar 2. 9 Software Development Process...25
Gambar 2.10 Unified Prociss...26
Gambar 3.1. Arsitektur Sistem...30
Gambar 3.2. Activity Diagram Sistem Manajemen Barang Toko Sehat Subur...30
Gambar 3. 3 Use Case Sistem Informasi Manajemen Barang Toko Sehat Subur...34
Gambar 3.4 Form utama admin master...36
Gambar 3.5 Form Tambah Admin Master...36
Gambar 3.6 Form Edit Pencarian admin...37
Gambar 3.7 Form Hapus Admin...37
Gambar 3.8 Pesan Konfirmasi Hapus Admin...38
Gambar 3.9 Form Utama Monitoring Data...39
Gambar 3.10 Form Monitoring Data Tabel Barang...39
Gambar 3.11 Form Monitoring Data Penjualan...40
Gambar 3.12 Form Monitoring Data Supplier...40
Gambar 3.13 Form Admin Barang...41
Gambar 3.14 Form Pencarian Barang...42
Gambar 3.15 Form Manajemen Barang...42
Gambar 3.16 Form Utama Admin Penjualan...44
Gambar 3.17 Form Admin Penjualan...44
Gambar 3.18 Form Transaksi dan Biaya...46
Gambar 3.19 Inputan Form Transaksi dan Biaya...46
Gambar 3.20 Kotak Peringatan Inputan Form Transaksi dan Biaya...47
Gambar 3.22 Form Pencarian Barang...48
Gambar 3.23 Form Konversi Harga...49
Gambar 3.24 Form Mengelola Supplier...51
Gambar 3.25 Form Tambah Supplier...51
Gambar 3.26 Form Pencarian supplier...52
Gambar 3.27 Sketsa Form Hapus Suplier...52
Gambar 3.28 Sketsa Monitoring Status Barang...53
Gambar 3.29 Diagram Analisis Class Mengelola Admin...54
Gambar 3.30 Communication Diagram Mengelola Admin...55
Gambar 3.31 Diagram Analisis Class Memonitoring Data Sistem...55
Gambar 3.32 Communication Diagram Memonitoring Data Sistem...56
Gambar 3.33 Diagram Analisis Class Mengklasifikasi Barang...56
Gambar 3.34 Communication Diagram Mengklasifikasi Barang...57
Gambar 3.35 Diagram Analisis Class Menghitung Transaksi Penjualan Barang...57
Gambar 3.36 Communication Diagram Menghitung Transaksi Penjualan Barang...57
Gambar 3.37 Diagram Analisis Class Memasukkan Data Transaksi dan Biaya Barang...58
Gambar 3.38 Communication Diagram Memasukkan Data Transaksi dan Biaya Barang..58
Gambar 3.39 Diagram Analisis Class Mengkonversi Harga Barang...59
Gambar 3.40 Communication Diagram Mengkonversi Harga Barang...59
Gambar 3.41 Diagram Analisis Class Mengelola Suplier...60
Gambar 3.42 Communication Diagram Mengelola Suplier...60
Gambar 3.43 Diagram Analisis Class Monitoring Stock Barang...60
Gambar 3.44 Communication Diagram Monitoring Stock Barang...61
Gambar 3.45 Class Diagram Sistem Informasi Manajemen Barang Toko Sehat Subur... 64
Gambar 4.1 Antarmuka Form Login Admin...74
Gambar 4.2 Antarmuka Form Admin Master...75
Gambar 4.3 Antarmuka Form Admin Barang...75
Gambar 4.4 Antarmuka Form Admin Penjualan...76
Gambar 4.5 Antarmuka Form Admin Pembelian...77
Gambar 4.6 Antarmuka Form Tambah Admin...77
Gambar 4.7 Antarmuka Form Pencarian Admin...78
Gambar 4.9 Form Cari Hapus Admin...79
Gambar 4.10 Antarmuka Form Konfirmasi Hapus Admin...79
Gambar 4.11 Antarmuka Monitoring Data Barang...80
Gambar 4.12 Antarmuka Monitoring Data Penjualan...80
Gambar 4.13 Antarmuka Monitoring Data Suplier...81
Gambar 4. 14 Antarmuka Form Manajemen Barang...81
Gambar 4.15 Antarmuka Pencarian Barang...82
Gambar 4.16 Antarmuka Edit Barang...82
Gambar 4.17 Antarmuka Form Transaksi Penjualan Barang...83
Gambar 4.18 Antarmuka Input Transaksi Penjualan Barang...84
Gambar 4.19 Antarmuka Form Transaksi Dan Biaya Barang...85
Gambar 4.20 Antarmuka Form Inputan Form Transaksi Dan Biaya Barang...85
Gambar 4.21 Antarmuka Form Konversi Harga Barang...86
Gambar 4.22 Antarmuka Pencarian Konversi Harga Barang...87
Gambar 4.23 Antarmuka Inputan Konversi Harga Barang...87
Gambar 4.24 Antarmuka Form Supplier...88
Gambar 4.25 Antarmuka Tambah Form Supplier...88
Gambar 4.26 Antarmuka Form Pencarian Supplier...89
Gambar 4.27 Antarmuka Hapus Suplier...89
Gambar 4.28 Antarmuka FormMonitoring Status Barang...90
Tabel 2.1 Jenis-jenis Relationship pada Use Case Diagram...21
Tabel 2.2 Komponen Pembentuk Communication Diagram...22
Tabel 2.3 Komponen Communication Diagram...23
Tabel 2.4 Jenis-jenis relationship...24
Tabel 2.5 Stiriotypi Analysis Class...28
Tabel 3.1 Daftar Aktor pada Sistem Informasi Manajemen Barang...32
Tabel 3.2 Daftar Use Case pada Sistem Informasi Manajemen Barang...33
Tabel 3.3 Use case detail Mengelola Admin...34
Tabel 3.4 Use Case Memonitoring Data Sistem...38
Tabel 3. 5 Use Case Mengklasifikasi Barang...41
Tabel 3.6 Use Case Menghitung Transaksi Penjualan...43
Tabel 3.7 Use Case Memasukkan Data Transaksi dan Biaya Barang...45
Tabel 3.8 Use Case Mengkonversi Harga Barang...47
Tabel 3.9 Use Case Mengelola Supplier...49
Tabel 3.10 Use Case Memonitoring Stock Barang...53
Tabel 3.11 Identifikasi Class Analysis...61
Tabel 3.12 Tanggung Jawab Class...62
Tabel 3.13 Tabel Admin...65
Tabel 3.14 Tabel Barang...65
Tabel 3.15 Tabel Suplier...66
Tabel 3. 16 Tabel Penjualan...66
Tabel 4.1 Tabel Implementasi Kelas...71
DAFTAR KODE
Kode 2.1 Sourci coedi java...17
Kode 4.1 Implementasi Basis Data Tabel Admin...72
Kode 4.2 Implementasi Basis Data Tabel Barang...72
Kode 4.3 Implementasi basis data tabel penjualan...73
DAFTAR LAMPIRAN
Tabel Lampiran 1.1 Deskripsi Hasil Uji Use Case Mengelola Admin...96
Tabel Lampiran 1.2 Deskripsi Hasil Uji Use Case Memonitoring Data Sistem...96
Tabel Lampiran 1.3 Deskripsi Hasil Uji Use Case Mengkasifikasi barang...96
Tabel Lampiran 1.4 Deskripsi Hasil Uji Coba Use Case Menghitung Transaksi Penjualan Barang...97
Tabel Lampiran 1.5 Deskripsi Hasil Uji Use Case Memasukkan Data Transaksi dan Biaya Barang...97
Tabel Lampiran 1.6 Deskripsi Hasil Uji Use Case Mengkonversi Harga Barang...97
Tabel Lampiran 1.7 Deskripsi Hasil Uji Use Case Mengelola Suplier...98
BAB I
PENDAHULUAN
Bab ini membahas latar belakang, rumusan masalah, tujuan dan manfaat, dan ruang lingkup, dan sistematika penulisan tugas akhir dengan judul “Pembangunan Sistem Informasi Manajemen Barang Dengan Menggunakan Metode EOQ (Economic Order Quantity) Dengan Bahasa Pemrograman Java (Studi Kasus Toko Sehat Subur Petanahan, Kebumen)”
1.1. Latar Belakang
Toko Sehat Subur merupakan minimarket yang menyediaakan aneka barang kebutuhan pertanian seperti pupuk organik, pupuk anorganik dan obat hama. Berada di kota kebumen desa petanahan, toko dengan luas 150m2 telah berdiri semenjak 3
tahun silam. Bermula dari menjual beberapa barang pertanian, perlahan tapi pasti toko mulai semakin berkembang. Bapak Habib dibantu istrinya selaku pemilik toko, secara bersama-sama berkeinginan untuk membesarkan Toko Sehat Subur, sehingga dapat memberikan memberikan pelayanan yang maksimal kepada pelanggan lama atau pelanggan baru.
Dalam pencapaian target tersebut, bapak Habib tentunya mempunyai tujuan yang sama pada umumnya dalam dunia perdagangan yaitu memperoleh laba atau keuntungan yang maksimal dan resiko kerugian yang seminimal mungkin. Tetapi untuk mencapai tujuan tersebut tidaklah mudah, karena hal itu dipengaruhi oleh beberapa faktor. Salah satu faktor yang mempengaruhinya dalam dunia perdagangan adalah mengenai masalah ketersediaan barang atau disebut inventory. Masalah ketersediaan atau inventory barang merupakan masalah yang sangat penting dalam kaitanya hal ini, karena dapat berpengaruh pada laba hasil penjualan barang. Apabila dalam ketersediaan bahan berjalan lancar, maka tujuan dari toko untuk menjual dan memperoleh laba akan tercapai [2].
keuntungan atau laba yang seharusnya didapatkan. Oleh karena itu, tersedianya persediaan barang merupakan suatu hal yang mutlak diperlukan [2].
Ketika melakukan pemesanan barang harus terlebih dahulu direncanakan berapa jumlah barang yang akan dibeli. Untuk memenuhi kebutuhan dalam jangka panjang pemilik toko harus membeli bahan kepada supplier dalam jumlah yang besar dan menyimpannya di gudang. Pembelian barang dalam jumlah yang sangat besar dapat menguntungkan toko karena selain akan mendapatkan potongan harga, juga akan mengatasi masalah kehabisan barang. Akan tetapi, apabila jumlah persediaan barang yang terlalu besar akan berakibat pada membengkaknya biaya penyimpanan yang harus dikeluarkan oleh pemilik toko. Semakin besar barang yang ada di gudang, maka semakin besar pula biaya yang harus dikeluarkan untuk penyimpanannya. Persediaan yang optimal ini memerlukan perencanan berapa besar barang yang harus dibeli, kapan barang dibeli agar proses tidak terganggu karena kekurangan barang [2].
Dengan adanya permasalahan ketersediaan barang seperti itu, maka biaya tersebut dapat di tekan sekecil mungkin. Untuk meminimumkan biaya persediaan tersebut dapat digunakan dengan metode analisis “Economic Order Quantity” (EOQ). EOQ adalah volume atau jumlah pembelian yang paling ekonomis untuk dilakukan pada setiap kali pembelian [7]. Metode EOQ ini berusaha mencapai tingkat persediaan yang seminimum mungkin, biaya rendah dan mutu yang lebih baik. Perencanaan metode EOQ dalam suatu penjualan akan mampu meminimalisasi terjadinya out of stock atau kehabisan barang, sehingga tidak mengganggu proses dalam penjualan dan mampu menghemat biaya persediaan yang dikeluarkan oleh toko karena adanya efisisensi persediaan barang. Selain itu dengan adanya penerapan metode EOQ, toko diharapkan mampu mengurangi biaya penyimpanan, penghematan ruang, baik untuk ruangan gudang dan ruangan kerja, menyelesaikan masalah-masalah yang timbul dari banyaknya persediaan yang menumpuk.
Melihat pada perkembangan teknologi informasi saat ini, bapak Habib sebagai pemilik toko bermaksud untuk memulai membangun sistem informasi yang dapat memenuhi kebutuhan dalam menjamin ketersediaan barang. Berdasarkan hasil diskusi dengan pemilik toko, sistem informasi yang dibangun diharapkan dapat memenuhi dua kebutuhan pokok dari toko yaitu: sistem dapat melakukan transaksi penjualan, dan manajemen ketersediaan barang.
Berdasarkan pada dua fungsi utama yang diharapkan ada pada sistem informasi maka penulis bermaksud untuk merancang dan membangun sebuah sistem informasi manajemen barang berbasis dekstop yang dapat digunakan untuk melakukan manajemen barang, transaksi penjualan, sehingga mempermudah pemilik toko dalam mengelola toko tersebut.
Metode pengembangan perangkat lunak yang tengah berkembangan saat ini adalah metodologi dengan konsep dasar object oriented. Perangkat lunak berorientasi objek menekankan konsep reusable sehingga proses pengembangan perangkat lunak dapat dilakukan lebih cepat dan berkualitas tinggi [11] .
Unified Process merupakan salah satu software development process yang menerapkan konsep berorientasi objek yang dikembangkan oleh Ivar Jacobson, Grady Booch, dan James Rumbaugh. Unified Process merupakan generic process framework yang dapat dispesialisasi untuk area aplikasi, tipe organisasi, tingkat kompetensi, dan ukuran projek yang berbeda . Unified Process bersifat open, free, dan tidak terikat dengan vendor tertentu . Oleh karena itu, proses pengembanga sistem informasi ini menggunakan Unified Process sehingga diharapkan dihasilkan perangkat lunak yang berkualitas tinggi, reusable, dan mudah untuk dipelihara [6].
1.2. Rumusan Masalah
Berdasarkan pada uraian latar belakang, maka rumusan masalah yang diangkat dalam tugas akhir ini adalah bagaimana membangun sebuah sistem informasi manajemen barang Toko Sehat Subur. Proses pengembangan sistem informasi menggunakan metode pengembangan Unified Process dan metode mengelola ketersediaan barang dalam gudang dengan menggunakan metode EOQ (Economic Order Quantity).
1.3. Tujuan dan Manfaat
Penyusunan tugas akhir ini memiliki tujuan untuk menghasilkan Sistem Informasi manajemen barang di toko sehat subur dengan menggunakan metode pengembangan perangkat lunak unified process dan menerapkan EOQ (metode Economic Order Quantity) menghasilkan efisisensi persediaan barang .
Penyusunan dan pembuatan tugas akhir ini diharapkan dapat memberikan manfaat tidak hanya untuk penulis, akan tetapi juga untuk pihak toko. Adapun manfaat yang diharapkan tercapai dari tugas akhir ini adalah sebagai berikut:
1) Bagi Penulis
1.4. Ruang Lingkup
Dalam penyusunan tugas akhir ini, diberikan ruang lingkup yang jelas agar pembahasan lebih terarah dan tidak menyimpang dari tujuan penulisan. Ruang Lingkup pada Tugas Akhir ini adalah sebagai berikut :
a. Sistem mampu melakukan manajemen admin, manajemen barang, transaksi penjualan, manajemen suplier, dan monitoring data sistem.
b. Barang yang dihitung merupakan bahan jadi.
c. Terdapat empat hak akses admin, yaitu admin master, admin barang, admin penjualan, dan admin pembelian.
d. Menggunakan metode Economic Order Quantity (EOQ) dalam membuat sistem. e. Program aplikasi inventory ini nantinya akan di implementasikan pada Toko Sehat
Subur di Petanahan, Kebumen.
1.5. Sistematika Penulisan
Sistematika penulisan yang digunakan dalam tugas akhir ini terbagi menjadi beberapa pokok bahasan, yaitu:
BAB I PENDAHULUAN
Bab I menguraikan tentang latar belakang masalah, perumusan masalah, tujuan dan manfaat penulisan tugas akhir, ruang lingkup, dan sistematika penulisan tugas akhir “Pembangunan Sistem Informasi Inventory Management Barang di Toko Sehat Subur Menggunakan Bahasa Pemrograman Java ”.
BAB II LANDASAN TEORI
Bab II berisi penjelasan mengenai konsep-konsep yang mendukung pembuatan Sistem seperti: sistem informasi, persediaan, metode eoq, konsep object oriented, bahasa pemrograman java, mysql. BAB III ANALISIS DAN PERANCANGAN
Bab III berisi pembahas tentang proses pengembangan perangkat lumak dan hasil yang didapatkan pada tahap definisi kebutuhan, analisis, dan perancangan.
Bab IV berisi pembahasan proses pengembangan perangkat lunak dan hasil yang didapatkan pada tahap implementasi dan pengujian.
BAB V PENUTUP
Bab ini berisi kesimpulan yang diambil berkaitan dengan sistem informasi yang dibuat dan saran untuk pengembangan lebih lanjut.
Bab ini dipaparkan mengenai teori yang digunakan dalam penyusunan tugas akhir. Dasar teori yang digunakan pada penyusunan tugas akhir ini meliputi sistem informasi, persediaan, metode EOQ, konsep object oriented, bahasa pemrograman java, basis data MySQL,Unified Modeling Language, UnifiedProcess.
2.1. Sistem Informasi
Sistem adalah kumpulan dari komponen yang saling berhubungan satu dengan yang lainnya membentuk satu kesatuan untuk mencapai tujuan tertentu. Informasi adalah data yang diolah menjadi bentuk yang berguna bagi para pemakainya. Suatu informasi dapat berguna jika memenuhi tiga pilar yaitu tepat kepada orangnya atau relevan, tepat waktu, dan tepat nilai atau akurat [7].
Sistem informasi merupakan sekumpulan elemen yang terintegrasi yang digunakan untuk mengubah data menjadi informasi. Sistem informasi terbentuk dari beberapa komponen yang saling berhubungan. Komponen-komponen tersebut meliputi input, model, basis data, output, teknologi, dan kontrol [7]. Kinerja komponen-komponen sistem informasi yang tergabung dalam siklus informasi dapat dilihat pada gambar 2.1.
Gambar 2.1 Interaksi Komponen Sistem Informasi 2.2. Persediaan
hanya dalam jumlah dan keadaan yang berbeda-beda. Untuk industri perdagangan besar ataupun industri perdagangan menengah persediaan barang ini dipersiapkan dengan baik, akan tetapi untuk industri perdagangan kecil persediaan barang kadang-kadang tidak dipersiapkan sama sekali [3]. Walaupun demikian, pada prinsipnya semua akan mengadakan persediaan barang. Keadaan semacam ini antara lain disebabkan oleh hal-hal sebagai berikut :
1) Barang yang dipergunakan untuk proses produksi dalam perusahaan, tidak dapat didatangkan secara satu persatu sebesar jumlah yang diperlukan serta pada saat bahan tersebut akan dipergunakan. Bahan ini akan didatangkan/dibeli sekaligus untuk keperluan proses produksi selama beberapa waktu (seminggu, sebulan, dan sebagainya). Dengan demikian bahan yang sudah dibeli tersebut tetap belum masuk kedalam proses produksi akan masuk sebagai persediaan barang. Dalam hal ini perusahaan akan mempunyai persediaan bahan dan menanggung resiko serta konsekuensi adanya persediaan barang tersebut [3].
2) Apabila terjadi ketiadaan barang, sedangkan barang yang dipesan belum datang, maka kegiatan proses produksi akan berhenti karena tidak ada bahan baku untuk kegiatan proses produksi tersebut. Proses produksi akan berjalan kembali apabila pesanan dari bahan baku tersebut sudah datang, atau membeli secara mendadak untuk keperluan proses produksi pada saat tersebut dengan harga yang lebih mahal. Hal semacam ini akan merugikan perusahaan [3].
3) Persediaan bahan yang terlalu besar tidak akan menguntungkan perusahaan [3]. Persediaan bahan yang terlalu besar ini akan menyerap dana perusahaan yang cukup besar pula, biaya-biaya persediaan yang besar serta semakin tingginya resiko kerusakan bahan, resiko kecurian dan lain sebagainya dalam penyimpanan.
Beroperasi tanpa menyelenggarakan persediaan bahan baku tidaklah mungkin. Akan tetapi persediaan bahan yang terlalu besar akan merugikan perusahaan. Sebaliknya persediaan bahan baku yang terlalu kecil juga tidak menguntungkan. Adapun beberapa kerugian ataupun kelemahan persediaan bahan yang terlalu besar antara lain adalah sebagai berikut [3] :
2) Tingginya biaya penyimpanan serta investasi dalam persediaan bahan baku, akan mengakibatkan berkurangnya dana untuk investasi dalam bidang yang lain, Seperti misalnya perluasan produksi, peningkatan programpemasaran dan lain sebagainya. Dengan kata lain dapat dinyatakan bahwa persediaan bahan baku yang terlalu tinggi justru menghalangi kemajuan itu sendiri.
3) Apabila persediaan bahan tersebut mengalami kerusakan, atau mempunyai perusahaan-perusahaan kimiawi sehingga tidak dapat dipergunakan, maka kerugian perusahaan akan menjadi semakin besar dengan semakin tingginya tingkat persediaanperusahaan.
4) Apabila perusahaan menyelenggarakan persediaan bahan baku yang sangat besar, maka penurunan harga pasar akan merupakan kerugian yang tidak kecil artinya bagi perusahaan. Walaupun dalam hal ini apabila terjadi kenaikan harga pasar perusahaan akan mendapat keuntungan. Oleh karena itu sangat penting artinya bagi perusahaan untuk dapat memperkirakan perubahan-perubahan harga pasar akan terjadi untuk penentuan besar kecilnya persediaan perusahaan.
Adapun kelemahan atau kerugian apabila perusahaan menyelenggarakan persediaan yang terlalu kecil antara lain adalah sebagai berikut [3] :
1) Persediaan yang terlalu kecil sangat sering tidak dapat mencukupi kebutuhan untuk proses produksi. Untuk menjaga kelangsungan proses produksi, perusahaan akan melakukan pembelian mendadak dengan harga yang lebih tinggi. Hal ini didalam jangka panjang akan sangat merugikan perusahaan.
2) Dengan sering terjadinya kehabisan atau kekurangan persediaan bahan baku, maka proses produksi tidak dapat berjalan dengan lacar. Dengan demikian kwlaitas dan kwantitas produk akhir perusahaan akan menjadi berubah-ubah pula.
Dengan beberapa hal diatas, maka jelaslah bahwa didalam perumusan kebijaksanaan persediaan bahan baku ini, akan mencakup beberapa masalah yaitu : 1) Berapa besar persediaan bahan baku perusahaan.
2) Kapan dan berapa bahan baku tersebut dibeli. 3) Kapan akan mengadakan pembelian kembali.
Didalam hal ini perumusan kebijaksanaan tentang persediaan bahan baku ini, maka sudah selayaknya apabila faktor-faktor yang mempengaruhi persediaan itu sendiri diperhitungkan terlebih dahulu. Tanpa memperhatikan faktor-faktor tersebut maka kebijaksanaan perusahaan rentang persediaan bahan baku ini akan mengalami kepincangan dan tidak mendapatkan hasil yang memuaskan.
Faktor-faktor yang mempengaruhi persediaan bahan baku ini ada beberapa macam. Dalam hal ini factor-faktor tersebut akan saling berkaitan, sehingga secara bersama-sama akan mempengaruhi persediaan bahan baku. Adapun factor –faktor yang dimaksud adalah sebagai berikut [3] :
1) Perkiraan pemakaian
Sebelum kegiatan pembelian bahan baku dilaksanakan, maka management harus dapat membuat perkiraan bahan baku yang akan dipergunakan didalam proses produksi suatu periode. Perkiraan kebutuhan bahan baku ini merupakan perkiraan tentang berapa besar jumlah bahan baku yang akan dipergunakan oleh perusahaan untuk keperluan proses produksi pada periode yang akan datang. Perkiraan kebutuhan bahan baku terebut dapat diketahui dari perencanaan produksi pada periode yang bersamaan.
2) Harga daripada bahan
Harga dari pada bahan baku yang akan dibeli menjadi salah satu factor penentu pula dalam kebijakansanaan persediaan bahan. Harga bahan baku ini merupakan dasar penyusunan perhitungan berapa besar dana perusahaan yang harus disediakan untuk investasi dalam persediaan bahan baku ini. Sehubungan dengan permasalahan ini, maka biaya modal (cost of capital) yang dipergunakan dalam persediaan bahan baku tersebut harus pula diperhitungkan.
3) Biaya-biaya persediaan
yaitu biaya-biaya yang semakin besar dengan semakin besarnya rata-rata persediaan, serta biaya yang justru semakin kecil dengan seamakin besarnya rata-rata persediaan.
4) Kebijaksanaan pembelanjaan
Seberapa besar persediaan bahan baku akan mendapatkan dana dari perusahaan akan tergantung kepada kebijaksanaan pembelanjaan dari dalam perusahaan tersebut. Apakah perusahaan akan memberikan fasilitas yang pertama, kedua atau justru yang terakhir untuk dana bagi persediaan bahan baku ini. Disamping itu juga dilihat apakah dana yang disediakan tersebut cukup untuk pembayaran semua bahan yang diperlukan perusahaan, ataukah hanya sebagian saja.
5) Pemakaian senyatanya
Pemakaian bahan baku senyatanya dari periode-periode yang lalu (actual demand) merupakan salah satu factor yang perlu diperhatikan. Seberapa besar penyerapan bahan baku oleh proses produksi perusahaan serta bagaimana hubungannya dengan perkiraan pemakaian yang sudah disusun harus senantiasa dianalisa. Dengan demikian maka akan dapat disusun perkiraan kebutuhan bahan baku mendekati kepada kenyataan.
6) Waktu tunggu (lead time) adalah masa tenggang waktu yang diperlukan ( yang terjadi) antara pemesanan dan bahan baku dengan datangnya bahan baku itu sendiri. Waktu tunggu ini sangat perlu diperhatikan oleh karena hal ini sangat erat hubungannya dengan penentuan saat pemasran kemabali (reorder). Dengan diketahuinya waktu tunggu yang tepat maka perusahaan akan dapat membeli pada saat yang tepat pula, sehingga resiko penumpukan persediaan atau kekurangan persediaan dapat ditekan seminimal mungkin.
Gambar 2.2 Faktor-faktor yang mempengaruhi persediaan bahan
Kebijaksanaan persediaan bahan baku yang tepat akan mendasarkan diri kepada faktor-faktor tersebut. Dengan diketahuinya kebijaksanaan pembelanjaan (financial policy), biaya-biaya persediaan, harga dari pada bahan serta perkiraan pemakaian bahan baku (forecast demand) akan dapat ditentukan jumlah/ kwalitas bahan yang dipesan secara ekonomis (mempunyai biaya minimal). Demikian pula dengan diketahuinya perkiraan pemakaian bahan dan pemakaian sesungguhnya (pada waktu-waktu yang lalu) akan dapat dianalisa jumlah persediaan (safety stock) yang paling tepat. Waktu tunggu (lead time) diperlukan untuk menentukan waktu pemesanan kembali (reorder). EOQ , safety stock dan order ini akan membentuk pola persediaan bahan baku dari perusahaan yang bersangkutan [3].
2.3. Metode EOQ (Economic Order Quantity)
persentase tertentu dari nilai persediaan rata-rata, jumlah bahan baku yang dibutuhkan dalam satu periode misalnya dalam satu tahun, dan biaya pesanan. Teknik perhitungan ini biasa disebut dengan EOQ (Economic Order Quantity).
2. 2. 1. EOQ (Economic Order Quantity)
EOQ merupakan jumlah pembelian yang paling ekonomis untuk dilakukan pada setiap kali pembelian [4]. Model EOQ bertujuan untuk mengetahui jumlah barang yang dipesan agar diperoleh total cost yang minimum. Rumus jumlah barang yang dipesan agar diperoleh total cost yang minimum pada model ini adalah :
EOQ = ...(2.1)
Keterangan :
EOQ = Economic Order Quantity (jumlah barang yang dipesan yang paling ekonomis) (unit)
F = Biaya pemesanan (Rp) S = Kebutuhan pertahun (unit) C = Biaya penyimpanan (Rp)
P = Harga beli per unit (%)
2. 2. 2. Pemesanan Ulang (ReOrder Point)
Reorder point adalah saat atau waktu tertentu perusahaan harus mengadakan pemesanan bahan baku kembali, sehingga datangnya pemesanan tersebut tepat dengan habisnya bahan baku yantg dibeli, khususnya dengan metode EOQ. Ketepatan waktu tersebut harus diperhitungkan kembali, bila agak mundur dari waktu tersebut akan menambah biaya pembelian bahan baku atau stock out cost [9].
Berikut ini cara penghitung untuk mendapatkan nilai reorder point :
ROP = ...(2.2)
ROP = Pemesanan kembali (unit) S = Kebutuhan pertahun (unit) Lt = Lead time (hari/minggu/bulan)
2. 2. 3. Biaya Penyimpanan (Total Carrying Cost)
Biaya penyimpanan merupakan biaya yang digunakan untuk menyimpan barang agar terhindar dari stock out (kehabisan barang). Biaya penyimpanan per periode akan semakin besar bila jumlah atau kuantitas bahan yang disimpan semakin tinggi. Misal: Biaya pemeliharaan bahan, biaya asuransi, dll.
………(2.3)
Dimana diketahui :
TCC = Biaya Penyimpanan (total carrying cost) (Rp) C = Biaya penyimpanan (Rp)
P = Harga beli perunit (unit) Q = Kebutuhan EOQ (unit)
2. 2. 4. Biaya Pemesanan (Total Ordering Cost)
Biaya pemesanan merupakan biaya yang dilakukan untuk melakukan pemesanan. Biaya persediaan akan semakin besar bila frekuensi pemesanan bahan baku semakin besar. Contoh biaya pemesanan adalah biaya bongkar bahan, biaya administrasi dll.
………...(2.4)
Dimana diketahui :
2. 2. 5. Biaya Safety Stock (OSS)
Biaya safety stock merupakan biaya yang dikeluarkan untuk pemeliharaan atau perawatan persediaan aman barang.
………(2.5)
OSS = Ordering Safety Stock (Rp) C = Biaya penyimpanan (Rp) P = Harga beli perunit (unit)
2. 2. 6. Jumlah Total Biaya Persediaan (TIC)
Jumlah total biaya persediaan (TIC) adalah jumlah dari biaya pemesanan, biaya penyimpanan dan biaya safety stock.
………..……….(2.6)
Paradigma Object Oriented (OO) didasarkan pada pembangunan sistem dari item yang disebut objek. Sebuah objek adalah konstruktor perangkat lunak yang mencerminkan sebuah konsep di dunia nyata, misal orang, tempat, benda, peristiwa, laporan, dan lain-lain. Objek memiliki baik data maupun fungsionalitas. Attribute akan mendefinisikan data, sedangkan method akan mendifinisikan fungsionalitas [1].
Beberapa istilah yang sering digunakan dalam konsep object oriented adalah sebagai berikut:
1) Encapsulation
penyembunyian informasi sehingga tidak dapat diakses secara langsung oleh pihak di luar objek.
2) Inheritance
Inheritance atau pewarisan adalah karakteristik dalam object oriented yang memungkinkan sifat-sifat sebuah kelas, baik attribute maupun method, dari suatu superclass diturunkan ke class lain yang disebut subclass [11].
Gambar 2.3 Inheritance, Class B, C, dan D Mewarisi Class A struktur dan behavior yang umum [1], dapat dikatakan bahwa class merupakan prototype yang mendefinisikan atribut dan method (service, prosedur, fungsi secara umum . Object dapat berupa object fisik seperti meja atau pelanggan maupun object konseptual seperti text input area atau file.
5) Atribute dan Method
Atribute adalah sesuatu yang melekat pada object yang mendeskripsikan sifat class atau object , sedangkan method adalah algoritma yang memproses nilai dari atribut tersebut [11].
6) Message
akan menstimulasi sejumlah behavior agar terjadi pada object yang menerima message tersebut.
2.5. Bahasa Pemrograman Java
Java adalah bahasa pemrograman yang dapat dijalankan di berbagai komputer termasuk telepon genggam. Bahasa ini awalnya dibuat oleh James Gosling saat masih bergabung di Sun Microsystems saat ini merupakan bagian dari Oracle dan dirilis tahun 1995. Bahasa ini banyak mengadopsi sintaksis yang terdapat pada C dan C++ namun dengan sintaksis model objek yang lebih sederhana serta dukungan rutin-rutin aras bawah yang minimal. Aplikasi-aplikasi berbasis java umumnya dikompilasi ke dalam p-code (bytecode) dan dapat dijalankan pada berbagai Mesin Virtual Java (JVM). Java merupakan bahasa pemrograman yang bersifat umum/non-spesifik (general purpose), dan secara khusus didisain untuk memanfaatkan dependensi implementasi seminimal mungkin. Karena fungsionalitasnya yang memungkinkan aplikasi java mampu berjalan di beberapa platform sistem operasi yang berbeda, java dikenal pula dengan slogannya, “Tulis sekali, jalankan di mana pun”.
Sejarah awal mula terbentuknya java, java dipelopori oleh James Gosling, Patrick Naughton, Chris Warth, Ed Frank, dan Mike Sheridan dari Sun Microsystems, Inc pada tahun 1991. Mereka membutuhkan kurang lebih 18 bulan untuk membuat versi pertamanya. Bahasa ini pada awalnya disebut “Oak” tapi kemudian diubah menjadi “Java” pada tahun 1995 karena nama “Oak” telah dijadikan hak cipta dan digunakan sebagai bahasa pemrograman lainnya. Antara pembuatan “Oak” pada musim gugur 1992 hingga diumumkan ke publik pada musim semi 1995, banyak orang yang terlibat dalam desain dan evolusi bahasa ini. Bill Joy, Arthur van Hoff, Jonathan Payne, Frank Yellin, dan Tim Lindholm merupakan kontributor kunci yang mematangkan prototipe aslinya [14].
Berikut ini kode 2.4 merupakan contoh sederhana dari sebuah program Java : public class HelloWorlds
{
public static void main (String [] args){ System.out.printlm(“Hello World”); }
Kode 2.1 Source code java
Pada source code gambar 2.4 merupakan syntak untuk membuat sebuah program sederhana yang menampilkan tulisan “Hello World” pada console.
Terdapat beberapa aturan dalam membuat program dalam Java yaitu :
a) Nama file harus sama dengan nama kelas program. Misal pada source code Gambar 2.1. maka nama kelasnya adalah “HelloWorld”, jadi nama file harus
HelloWorld.java.
b) Hanya boleh terdapat satu kelas public pada sebuah file.
c) Kelas yang menjadi program harus memiliki metode “public static void main(String [ ] args)”.
d) Terminal pada Java menggunakan tanda ;(titik koma).
2.6. Database Management SystemMySQL
Sebuah database management system (DBMS) adalah kumpulan program yang memungkinkan pengguna untuk membuat dan memelihara database [5]. MySQL merupakan salah satu DBMS Sructured Query Language (SQL) bersifat open source paling populer yang dikembangkan, didistribusikan, dan didukung oleh Sun Microsystem [5]. Keandalan MySQL dalam mengolah database ditunjang dengan kecepatannya dalam mengakses perintah query serta banyaknya fitur-fitur yang dimilikinya. Dengan menggunakan konsep client-server, kelebihan dari MySQL adalah cepat, kuat, serta mudah digunakan, sehingga dapat dengan mudah menyimpan, mengubah, dan mengakses data. Segala informasi mengenai MySQL software dapat diakses di MySQL website (http://www.mysql.com/).
2.7. Unified Modelling Language (UML)
Unified Modelling Language memiliki tiga elemen utama (building blocks) yaitu things, relationship, dan diagram [12].
2. 7. 1. Things
Things merupakan building blocks yang berfungsi sebagai abstraksi paling utama dalam UML. Terdapat 4 jenis things dalam UML, yaitu : Structural things, Behavioral things, Grouping things, Annotational things [12].
1) Structural things
Structural things merupakan bagian statis dari model UML yang merepresentasikan elemen konseptual maupun elemen fisik [12]. Jenis-jenis structural things meliputi class, interface, collaboration, use case, active class, component, artifact, dan node.
2) Behavorial things
Behavioral things merupakan bagian dinamis dari model UML yang merepresentasikan behavior [12]. Jenis-jenis behavorial things meliputi interaction, state machine, dan activity .
3) Grouping things
Grouping things merupakan bagian organisasional dari model UML [1]. Yang termasuk jenis grouping things adalah package. Package merupaka mekanisme untu k mengorganisasikan design itu sendiri. Structural things, behavorial things,dan bahkan grouping things yang lain dapat ditempatkan dalam sebuah package.
4) Annotational things
Annotational things merupakan bagian yang menjelaskan model UML. Yang termasuk ke dalam annotational things yaitu note. Note berfungsi untuk memberikan constrain atau komentar yang melekat pada suatu elemen tertentu.
2. 7. 2. Diagram
Diagram merupakan visualisasi grafis yang terdiri atas things dan relationship. Diagram berfungsi untuk memproyeksikan suatu sistem yang akan dibangun dari sejumla perspektif yang berbeda [12].
1) Activty diagram
Activity diagram merupakan suatu diagram yang menggambarkan berbagai aliran aktivitas yang terjadi di dalam sistem [1]. Activity diagram dilengkapi dengan-alur percabangan, kondisional, dan sinkronisasi (untuk aktifitas yang dilakukan secara konkuren) yang berfungsi untuk menjelaskan aliran aktivitas di dalam sistem. Activity diagram dapat digunakan untuk memodelkan workflow proses bisnis. Untuk membagi aktivitas bisnis ke dalam kelompok-kelompok tertentu sesuai dengan tanggung jawabnya dalam organisasi dapat digunakan notasi swimlane . Swimlane dapat merepresentasikan entitas di dunia nyata seperti unit organisasional dalam sebuah perusahaan. Dalam sebuah activity diagram yang dipartisi ke dalam beberapa swimlane, setiap aktivitas hanya dapat berada pada satu swimlane, tetapi transaksi dapat terjadi antar lane. Contoh Activity diagram pengambilan uang dari ATM pada gambar 2.5.
Gambar 2.4 Contoh Activity Diagram
2) Use case diagram
yang dapat berupa orang (user) atau benda seperti dumb terminal, sensor atau sistem komputer lainnya yang berinteraksi secara langsung dengan sistem. Contoh pembuatan use case diagram pada gambar 2.5 “Pasien menghubungi klinik untuk membuat janji (appointment) dalam pemeriksaan tahunan. Receptionis mendapatkan waktu yang luang pada buku jadwal dan memasukkan janji tersebut ke dalam waktu luang itu”.
Gambar 2.5 Use Case Kegiatan Pasien
Jenis-jenis relationship pada use case diagram dapat dilihat pada tabel 2.2
Tabel 2.1 Jenis-jenis Relationship pada Use Case Diagram
Jenis Deskripsi Gambar
Association Association merupakan komunikasi antara aktor dan use case yang terlibat.
generalization Generalization merupakan hubungan generalisasi/spesialisasi. Generalization dapat terjadi antar use case atau aktor. extend relasi antar use case yang memungkinkan
suatu use case secara opsional menggunakan fungsionalitas yang disediakan use case lainnya.
<<extend>>
include relasi antar use case yang mana suatu use case menggunakan fungsionalitas yang disediakan use case lainnya.
<<include>>
3) Communication diagram
Tabel 2.2 Komponen Pembentuk Communication Diagram
Jenis Deskripsi
Aktor Seseorang atau apa saja yang berhubungan langsung dengan sistem yang sedang dibangun.
Objek Semua class yang berpartisipasi dalam interaksi yang dimodelkan. Dapat berupa boundary, control dan entity. Link Pnghubung antar-object yang menggambarkan komunikasi. Sequence number Angka di depan message yang menunjukan urutan dari
interaksi.
Call message Invokasi dari sebuah operasi pada objek.
Return message Pengembalian sebuah nilai kepada objek pemanggil.
Gambar 2.6 Contoh Communication Diagram
4) Calss Diagram
5) Communication Diagram
Communication diagram adalah diagram UML yang memberi tekanan pada hubungan-hubungan antarpartisipan yang berbeda dalam sebuah interaksi yang terjadi di dalam sistem. Penjelasan komponen dari use case diagram dapat dilihat pada Tabel 2.3. Contoh communication diagram dapat dilihat pada Gambar 2.9.
Tabel 2.3 Komponen Communication Diagram
No. Jenis Deskripsi
1. Aktor Aktor adalah seseorang atau apa saja yang berhubungan langsung dengan sistem yang sedang dibangun.
2. Object Object adalah semua class yang berpartisipasi dalam interaksi yang dimodelkan. Dapat berupa boundary, control dan entity.
3. Link Link adalah penghubung antar object yang menggambarkan komunikasi.
4. Sequence number Sequence number adalah angka di depan message yang menunjukan urutan dari interaksi.
5. Call Message Call Message adalah invokasi dari sebuah operasi pada objek.
6. Return Message Return Message adalah pengembalian sebuah nilai kepada objek pemanggil.
Pada dasarnya communication diagram dan sequence diagram memiliki tujuan yang sama yaitu menggambarkan interaksi yang terjadi antar-objek di dalam sistem. Perbedaan antara kedua diagram tersebut adalah sequence diagram
menekankan pada skenario yang terjadi pada sebuah interaksi sesuai dengan urutan waktu, sedangkan communication diagram menekankan pada hubungan-hubungan yang terjadi dalam sebuah interaksi.
Gambar 2.8 Contoh Communication Diagram 2. 7. 3. Relationship
Relationship merupakan building blocks yang berfungsi sebagai penghubung antar things [12]. Jenis-jenis relationship meliputi dependency, association, generalization, dan realization [12].
Tabel 2.4 Jenis-jenis relationship
2 association Relasi struktural antar-class yang mendeskripsikan sekumpulan link 3 generalization Hubungan di mana unsur khusus
(child) dibangun berdasarkan spesifikasi dari elemen umum (parent) 4 realization Semantic relationship diantara dua
classifier 2.8. Unified Process
-yang diperlukan untuk menerjemahkan kebutuhan pengguna menjadi sebuah sistem perangkat lunak seperti dijelaskan gambar 2.9
Gambar 2. 9 Software Development Process
Ciri khusus pengembangan perangkat lunak menggunakan Unified Process sebagai berikut:
1) Use Case Driven
Pada proses pembangunan perangkat lunak, use case digunakan sebagai artifak utama untuk mendiskripsikan perilaku sistem baru, menverifikasi dan menvalidasi arsitektur sistem, menguji, dan untuk mengkomunikasikan antara stakeholders dari proyek [6].
2) Architecture Centric
Pada proses pembangunan perangkat lunak arsitektur sistem digunakan sebagai artifak primer dalam conceptualizing, membangun, pengelolaan, dan meningkatkan sistem dalam pembangunannya [6].
3) Iteration & Incremental
Iteration berarti bahwa proses perancangan perangkat lunak dilakukan secara berulang ulang. Sedangkan incremental berarti bahwa kode ditulis dan diuji dalam suatu bagian-bagian kecil kemudian dikombinasikan ke dalam satu pekerjaan [6].
Unified Process memiliki dua dimensi yaitu dimensi horizontal dan dimensi vertical. Dimensi horizontal 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. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition. Dimensi vertikal mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Dimensi horizontal dan vertical dapat dilihat pada gambar 2.10 arsitektur unifiedprocess.
1) Inception
Inception mendefinisikan jangkauan proyek dan mengembangkan business case, serta menentukan kemungkinan-kemungkinan yang akan terjadi atau akan dikerjakan [6]. Pada fase ini dilakukan beberapa hal diantaranya menentukan ruang lingkup proyek, membuat business case, dan menjawab pertanyaan tentang kelayakan kerja yang dilakukan.
2) Elaboration
Elaboration menangkap functional requirements, menentukan non-functional requirements, dan membuat basis arsitektur. Pada fase ini requirements ditinjau kembali dan dimungkinkan ada perubahan atau pergantian [6]. Pada fase ini dilakukan beberapa hal diantaranya menganalisis berbagai persaratan dan resiko, menetapkan base line, merencanakan fase construction.
3) Construction
Construction mewujudkan requirements dalam bentuk coding dan pengujian. Fase ini menghasilkan perangkat lunak [6]. Pada fase ini dilakukan beberapa hal diantaranya melakukan beberapa iterasi, pada setiap iterasi akan melibatkan proses analisis desain, implementasi, dan testing.
4) Transition
Transition merupakan peralihan produk dari pengembang ke user. Fase ini menghasilkan perangkat lunak yang sudah diuji [6]. Pada fase ini dilakukan beberapa hal diantaranya melakukan pengujian beta dan performace testing, membuat dokumentasi tambahan seperti, training, user guides, dan sales kit, membuat rencana peluncuran produk ke komunitas pengguna.
Tiap fase unified process dilakukan proses-proses workflow yang meliputi requirement , analysis , design , implementation , dan test.
1) Requirement
Requirements atau definisi kebutuhan sistem memiliki tujuan untuk mengarahkan pembangunan ke arah sistem yang benar, sesuai kebutuhan pengguna sistem [6]. Pada proses ini kebutuhan-kebutuhan pengguna dikumpulkan, kemudian ditransformasikan ke dalam sebuah deskripsi sistem. Pada tahap selanjutnya deskripsi sistem digunakan sebagai dasar pembuatan use case. Pada tahap ini dihasilkan use case model, prototipe antarmuka dan kebutuhan nonfungsional sistem [5]. Diagram UML yang digunakan untuk menggambarkan use case model adalah use case diagram.
2) Analysis
Analysis berfungsi untuk melakukan restrukturisasi hasil pada proses requirement ke dalam bahasa developper. Pada tahap ini akan menghasilkan model analisis berupa use case realization dan analysis class. Use case realization pada tahap analisis berfungsi untuk menggambarkan hubungan antara use case dengan analysis class melalui partisipasi class dalam implementasi use case dan interaksi yang terjadi antar class. Analysis class berfungsi untuk menggambarkan satu atau beberapa class dan atau subsistem dalam lingkungan design sistem. Analysis-class digambarkan dengan menggunakan tiga stereotype dasar yang meliputi entity, boundary, dan control.
Tabel 2.5 Stereotype Analysis Class
Jenis Deskripsi Notasi
Boundar y
Boundary class digunakan memodelkan interaksi sistem actor.
Control Control class digunakan untuk mengkoordinasikan interaksi antara actordengan data di entity class.
3) Design
Proses ini akan menghasilkan rancangan rinci dari sistem yang akan diimplementasikan pada proses berikutnya [6]. Produk utama yang dihasilkan pada proses design adalah design model yang meliputi design class dan use case realization tahap design. Selain itu juga dihasilkan sequence diagram untuk mendeskripsikan perilaku dinamis dari class. Pada proses design juga dibuat database design yang akan digunakan sebagai tempat penyimpanan data. Database yang digunakan dalam pengembangan sistem ini adalah relational database. Relational database design merupakan pemetaan ke dalam relationaltable untuk setiap class dalam class diagram yang bersifat entity.
4) Implementation
Proses implementasi dilakukan penerapan hasil pada proses design [6]. Implementasi adalah tahap yang mengkonversi sistem yang telah dirancang ke dalam sebuah bahasa yang dimengerti komputer. Kemudian komputer akan menjalankan fungsi-fungsi yang telah didefinisikan sehingga mampu memberikan layanan-layanan kepada penggunanya.
5) Test
Test merupakan penggambaran kegiatan yang dilakukan untuk menguji perangkat lunak dalam rangka memastikan bahwa perangkat lunak yang dikembangkan telah memenuhi persyaratan kebutuhan pengguna [6].
BAB III
ANALISIS DAN PERANCANGAN
3.1. Definisi Kebutuhan Perangkat Lunak
Model use case digunakan untuk mendeskripsikan fungsi sebuah sistem yang terdiri dari definisi Aktor (actor) dan definisi use case yang digambarkan ke dalam suatu bentuk use case diagram. Fungsi dari use case diagram digunakan untuk menunjukkan hubungan antara Aktordan use case.
3.2. Deskripsi Umum Perangkat Lunak
Sistem informasi manajemen gudang di Toko Sehat Subur merupakan suatu bentuk sistem informasi berbasis dekstop untuk mengatur atau memanajemen persediaan barang dengan menggunakan fitur metode EOQ (Economic Order Quantity). Sistem ini dibuat untuk mempermudah dalam manajemen barang bagi pemilik toko.
Sistem informasi memiliki empat jenis administrator dengan hak akses yang berbeda-beda sesuai dengan perannya masing-masing, diantaranya:
1) Admin Master
Admin master merupakan admin yang bertugas untuk memanajemen hak akses ke semua admin dan monitoring data pada sistem. Disini admin master berwenang menambah, merubah, menghapus admin dan melihat data pada sistem. 2) Admin Barang
Admin barang merupakan admin yang bertugas untuk memanajemen barang. Disini admin barang memiliki hak akses untuk mensortir kategori barang dan memberikan status penilaian pada barang.
3) Admin Penjualan
Admin penjualan merupakan admin yang bertugas untuk manajemen penjualan ke pembeli. Disini admin penjualan memiliki hak akses untuk melakukan transaksi penjualan ke pembeli.
4) Admin Pembelian
Admin pembelian merupakan admin yang memiliki hak akses untuk menghitung kapan reorder barang dilakukan dengan metode EOQ, konversi harga dan manajemen supplier barang.
java dapat dilihat pada gambar 3.1. Diagram aktifitas yang memberikan penjelasan mengenai aktifitas utama yang terjadi antar user dapat dilihat pada gambar 3.2.
Gambar 3.1. Arsitektur Sistem
Gambar 3.2. Activity Diagram Sistem Manajemen Barang Toko Sehat Subur
Detail penjelasan activity diagram yang menggambarkan kerja dari perangkat lunak secara umum dapat ditunjukkan pada gambar 3.2 dan dideskripsikan sebagai berikut : 1) Admin Master
melakukan monitoring data tabel, terdapat beberapa tabel yaitu data yang berisi data tabel barang, tabel penjualan dan tabel supplier.
2) Admin Pembelian
Admin pembelian melakukan verifikasi admin penjualan. Admin pembelian memiliki empat fungsi utama yaitu transaksi dan biaya pada barang, manajemen supplier, konversi harga dan monitoring status barang. Dalam fungsi transaksi dan biaya barang admin pembelian memasukkan data-data pada form kemudian diproses untuk mendapatkan hasil dari metode EOQ (Economic Order Quantity). Kemudian fungsi manajemen supplier memiliki beberapa tiga fungsi yaitu tambah supplier, ubah supplier dan melihat supplier. Pada fungsi konversi harga admin penjualan melakukan perubahan harga dari harga beli menjadi harga jual dengan dengan dikalikan 20%. Kemudian untuk monitoring stok barang mempunyai fungsi menampilkan status barang dalam tabel.
3) Admin Penjualan
Admingudang melakukan proses verifikasi admin barang. Dalam alur proses ini admin barang melakukan proses manajemen barang. Admin dapat merubah kategori barang dan status barang dalam form admin barang.
3.3. Model Use Case
Fase inception metode pengembangan perangkat lunak unified process menghasikan ruang lingkup pengembangan perangkat lunak yang meliputi activity diagram, penentuan aktor, penentuan use case, dan use case diagram.
3. 3. 1. Definisi Aktor
Tabel 3.1 Daftar Aktor pada Sistem Informasi Manajemen Barang
No Aktor Deskripsi
1. Admin Master Seseorang yang diberi hak akses penuh untuk manajemen pengelolaan admin pada sistem informasi manajemen barang.
2. Admin Barang Seseorang yang diberi hak akses penuh untuk pengelolaan barang pada sistem informasi manajemen barang.
3. Admin Penjualan
Seseorang yang diberi hak akses penuh untuk melakukan transaksi penjualan kepada konsumen toko pada sistem informasi manajemen barang.
4. Admin Pembelian
Seseorang yang diberi hak akses penuh untuk melakukan manajemen EOQ, konversi harga, manajemen suplier pada sistem informasi manajemen barang.
3. 3. 2. Definisi Use Case
Sebuah use case pada proses pengembangan piranti perangkat lunak menggambarkan sebuah fungsi atau pekerjaan tertentu untuk menghasilkan sesuatu. Daftar use case pada sistem informasi manajemen barang dapat dilihat pada tabel 3.2
Tabel 3.2 Daftar Use Case pada Sistem Informasi Manajemen Barang
No Use Case Deskripsi
1. Mengelola admin Aktor melakukan pengelolaan menejemen ke semua admin dari admin master, admin barang, admin penjualan dan admin pembelian pada sistem informasi manajemen barang. Pengelolaan yang dilakukan adalah tambah, edit dan hapus admin.
2 Memonitoring data sistem
3 Mengklasifikasi barang
Aktor melakukan penyortiran barang seperti kategori barang dan status barang.
4 Menghitung transaksi penjualan
Aktor melakukan proses transaksi jual barang ke konsumen.
5 Menghitung data transaksi dan biaya barang
Aktor melakuan proses perhitungan metode EOQ (Economic Order Quantity) dengan memasukkan bebarapa inputan yang tersedia di form transaksi dan biaya.
6. Mengkonversi harga barang
Aktor melakukan proses konversi harga dari harga beli supplier ke harga jual toko dengan mengambil laba 20% dari harga beli supplier pada setiap barang.
7. Mengelola supplier Aktor melakukan pengelolaan pelanggan atau supplier dengan cara menambah, mencari dan menghapus pelanggan. 8. Monitoring stock
barang
Aktor melakukan prose monitoring data barang disajikan dalam bentuk tabel.
3. 3. 3. Use Case Diagram
3. 3. 4. Use Case Detail
Penjelasan mendalam tentang interaksi antar aktor dengan sistem, skenario utama, skenario abnormal dari use case diagram pada gambar 3.3 dapat dilihat pada tabel 3.3 sampai tabel 3.10
Tabel 3.3 Use case detail Mengelola Admin No Use case 1
Nama Use case Mengelola admin
Aktor Adminr Master
Kondisi awal Sistem menampilkan form manajemen administrator yang terdiri dari menu yaitu tombol tambah, edit, hapus.
Lanjutan Tabel 3.3 Use Case detail Mengelola Admin
Skenario utama 1. Admin Master menambahkan data admin baru 2. Tekan tombol tambah tambah untuk menambah
admin baru
3. Admin mengisi form tambah admin baru 4. Tekan tombol simpan untuk menyimpan data
5. Tekan tombol batal untuk batal dan kembali ke form utama
6. Sistem menyimpan data admin baru dalam basis data 7. Admin Master mengubah admin
8. Tekan tombol edit untuk merubah admin
9. Muncul form pencarian admin yang akan diubah (edit) 10. Admin merubah pada form edit admin
11. Tekan tombol simpan untuk menyimpan data
12. Tekan tombol batal untuk batal dan kembali ke form utama
13. Sistem menyimpan perubahan data admin pada basis data
15. Muncul form pencarian hapus admin
16. Tekan tombol Ok untuk menghapus data admin
17. Tekan tombol batal untuk batal dan kembali ke form utama
18. Sistem menghapus data admin dalam basis data
Skenario abnormal Terdapat peringatan kesalahan apabila salah memasukkan data
Kondisi akhir Data periode tersimpan dalam basis data Sketsa antarmuka Gambar 3.4 – 3.8
Berdasarkan skenario yang ditunjukan oleh tabel 3.3, skenario untuk mengelola admin memiliki tiga sketsa antarmuka, yaitu pertama sketsa tambah admin yang dapat ditunjukkan pada gambar 3.5. Kedua sketsa edit admin yang dapat ditunjukkan pada gambar 3.6. Ketiga sketsa hapus admin yang dapat ditunjukkan pada gambar 3.7. Sketsa menu utama pada admin master ditunjukan pada gambar 3.4
Gambar 3.4 Form utama admin master
Gambar 3.5 Form Tambah Admin Master
Pada skenario yang ditunjukkan tabel 3.3 ketika pengguna menekan tombol edit. Selanjutnya, sistem akan menampilkan antarmuka yang ditunjukan oleh gambar 3.6 untuk melakukan proses pencarian admin. Selanjutnya data yang telah dipilih oleh admin, akan di bawa ke form utama seperti pada gambar 3.5
Gambar 3.6 Form Edit Pencarian admin
Gambar 3.7 Form Hapus Admin
Berdasarkan gambar 3.7, sistem menampilkan form hapus admin. Pengguna mencari data admin yang tampil pada tabel form hapus admin. Selanjutnya sistem akan melakukan konfirmasi persetujuan untuk menghapus data admin seperti pada gambar 3.8.
Gambar 3.8 Pesan Konfirmasi Hapus Admin Tabel 3.4 Use Case Memonitoring Data Sistem
No Use case 2
Nama Use case Memonitoring data sistem
Aktor Administrator Master
Kondisi awal Sistem menampilkan tombol monitoring barang, monitoring penjualan dan monitoring supplier.
Skenario abnormal
-Kondisi akhir Sistem kembali form utama Sketsa antarmuka Gambar 3.9 – 3.12
Berdasarkan skenario yang ditunjukan oleh tabel 3.4, skenario untuk monitoring data tabel pada sistem manajemen barang terdapat tiga tombol yang memiliki fungsi berbeda-beda. Masing-masing tombol memiliki output berbeda-beda. Sketsa menu utama dapat ditunjukan oleh gambar 3.9
Gambar 3.9 Form Utama Monitoring Data
Gambar 3.10 Form Monitoring Data Tabel Barang
Berdasarkan gambar 3.10, sistem hanya menampilkan data tabel barang. Tombol kembali berfungsi untuk kembali ke form utama admin master yang dapat ditunjukkan pada gambar 3.9. Selanjutnya pengguna ketika menekan tombol penjualan maka akan muncul sketsa antarmuka yang ditunjukkan pada gambar 3.11.
Gambar 3.11 Form Monitoring Data Penjualan
Gambar 3.12 Form Monitoring Data Supplier
Berdasarkan gambar 3.12, sistem hanya menampilkan data tabel supplier. Tombol kembali berfungsi untuk kembali ke form utama admin master yang dapat ditunjukkan pada gambar 3.9.
Tabel 3. 5 Use Case Mengklasifikasi Barang
No Use case 3
Nama Use case Mengklasifikasi barang
Aktor AdminBarang
Kondisi awal Sistem menampilkan form utama manajemen barang
Skenario utama 1. Admin Barang melakukan manajemen barang dengan menekan tombol edit pada form utama admin barang 2. Sistem menampilkan data-data barang pada form
pencarian barang
3. AdminBarang memilih data barang
4. AdminBarang memilih kategori dan status barang 5. Sistem menyimpan data manajemen barang
Skenario abnormal
-Kondisi akhir Sistem kembali form utama admin barang Sketsa antarmuka Gambar 3.13 – 3.15
Gambar 3.13 Form Admin Barang
Berdasarkan pada gambar 3.13 sistem menampilkan form admin barang, dalam form admin barang semua inputan deprogram disable kecuali tombol edit. Tombol edit berfungsi merubah barang pada database, dan ketika tombol edit di pilih maka akan kelua form pencarian barang seperti pada gambar 3.14.
Gambar 3.14 Form Pencarian Barang
Gambar 3.15 Form Manajemen Barang
Tabel 3.6 Use Case Menghitung Transaksi Penjualan
No Use case 4
Nama Use case Menghitung Transaksi Penjualan
Aktor Admin Penjualan
Kondisi awal Sistem menampilkan form utama transaksi penjualan
Skenario utama 1. Admin Penjualan melakukan transaksi penjualan dengan memasukkan inputan pada form terlebih dahulu 2. Sistem menampilkan hasil inputan admin kedalam
tabel
3. Admin Penjualan menekan tombol total melakukan perhitungan jumlah biaya yang harus dibayarkan
4. Admin Penjualan menekan tombol simpan untuk menyimpan hasil dari transaksi
5. Sistem menyimpan data transaksi penjualan Skenario abnormal
-Kondisi akhir Sistem kembali form utama admin penjualan Sketsa antarmuka Gambar 3.16 – 3.17
barang-barang guna mempercepat proses jalannya transaksi penjualan. Sketsa menu utama dari admin penjualan dapat ditunjukan oleh gambar 3.16.
Gambar 3.16 Form Utama Admin Penjualan
Gambar 3.17 Form Admin Penjualan
Tabel 3.7 Use Case Memasukkan Data Transaksi dan Biaya Barang
No Use case 5
Nama Use case Memasukkan Data Transaksi dan Biaya Barang
Aktor Admin Penjualan
Kondisi awal Sistem menampilkan form utama transaksi penjualan
Skenario utama 1. Admin Penjualan masuk pada form transaksi dan penjualan barang
2. Admin Penjualan mengisi inputan sesuai yang telah disediakan untuk memperoleh hasil dari perhitungan dengan menggunakan metode EOQ (Economic Order Quantity)
3. Admin Penjualan menekan tombol konversi untuk melihat hasil dari perhitungan dengan metode EOQ (Economic Order Quantity)
4. Admin Penjualan menekan tombol simpan untuk menyimpan hasil dari perhitungan ke dalam sistem. 5. Sistem menyimpan pada database
akan menampilkan kotak peringatan. Kondisi akhir Sistem kembali form transaksi dan biaya Sketsa antarmuka Gambar 3.18 – 3.20
Berdasarkan skenario yang ditunjukan oleh tabel 3.8, sketsa untuk form memasukkan data transaksi dan biaya barang dapat ditunjukkan pada gambar 3.18
Gambar 3.18 Form Transaksi dan Biaya
