Upload
pipin-ibnu-faqih
View
430
Download
10
Embed Size (px)
Citation preview
APLIKASI PENGOLAHAN SISTEM BENGKEL
RAMAYANA BERBASIS JAVA DESKTOP
PENULIS
PIPIN IBNU FAQIH | 6701140215
PROGRAM STUDI MENEJEMEN INFORMATIKA
FAKULTAS ILMU TERAPAN
TELKOM UNIVERSITY
BANDUNG
2014
BAB1
LATAR BELAKANG
Informasi pada saat ini berkembang ke arah efektifitas dan efisiensi yang tujuannya untuk
memberikan kemudahan bagi segala aspek baik pendidikan, hiburan maupun bisnis. Era saat
ini sangat memerlukan informasi yang akurat, cepat dan tepat.
Salah satunya usaha bisnis yang bergerak di bidang otomotif (bengkel). Kebutuhan akan
informasi yang baik sangat dibutuhkan, seperti informasi mengenai persediaan suku cadang,
transaksi yang terjadi hingga pembuatan laporan. Hal tersebut dapat menjadi kendala dalam
pengembangan usaha apabila informasi tersebut tidak tertata dengan baik. Seperti yang
dialami oleh bengkel motor Honda, dimana pengolahan informasi masih dilakukan secara
manual baik dalam pendataan suku cadang, transaksi ataupun dalam pembuatan laporan.
Kesulitan dalam pendataan persediaan suku cadang serta dalam pembuatan laporan yang
kurang akurat menjadi permasalahan utama dibuatnya aplikasi ini. Oleh karena itu setelah
dibuatnya aplikasi ini semoga dapat menjadi solusi bagi permasalahan bengkel motor Honda.
Batasan Masalah
Batasan masalah dimaksudkan untuk membatasi ruang lingkup pembahasan agar
system yang dirancang lebih terarah. Batasan masalah dari perancangan sistem ini dibatasi
pada hal-hal sebagai berikut :
1. Penjualan suku cadang dan service meliputi registrasi pelanggan
2. Pembayaran
3. Pembuatan laporan
BAB 2
ANALISIS
Analisis kebutuhan fungsionalitas Tahap 1 : Tentukan Aktor
1. Petugas Front office adalah actor utama yang berinteraksi dengan system, dikarenakan
menerima orderan servis dan barang dari pelanggan. Petugas juga menerima pembayaran dan mencatat pembayaran.
2. Manajer adalah actor yang berinteraksi dengan system, dikarenakan harus dapat menerima laporan perhari.
3. Pelanggan bukanlah actor karena tidak berinteraksi langsung dengan system. 4. Mekanik bukanlah actor karena tidak berinteraksi langsung dengan system.
Tahap 2 : Tentukan Fungsionalitas Input data servis dan penjualan
Mentotalkan biaya servis
Melihat stock barang
Mencetak laporan
Melihat data pegawai berserta menghitung gaji pegawai
Identifikasi Permasalahan
1. Pembuatan laporan penjualan perhari masih manual dengan mengumpulkan struk
pembelian.
2. Pengecekan stock barang masih dilakukan secara manual.
3. Data pelanggan belum tersimpan
4. Tidak ada suatu aplikasi yang terintegrasi antar bagian yaitu kantor cabang pusat dan
suplier sehingga untuk mendistribusian barang agak rumit dan masih banyak manual itu
membuat agak terlalu lama pendistribusiannya.
KEBUTUHAN FUNGSIONAL DAN NON FUNGSIONAL
Kebutuhan Fungsional
1. Perhitungan pembelian
2. Pembayaran pembelian
3. Membuat rekapan pembelian
4. Penegecekan stok barang
5. Pengecekan data pelanggan
6. Pendataan gaji pegawai
7. Pendataan barang ada tau tidak ada (ada)
8. Pendataan barang ada tau tidak ada (tidak ada)
1. Input : Data barang yg dijual
Proses : Proses perhitungan pembelian
Output : Struk pembelian
2. Input : Jumlah pembelian
Proses : Pembayaran
Output : Struk pembelian
3. Input : Struk-struk pembelian
Proses : Merekap hasil penjualan
Output : Laporan penjualan
4. Input : Data stok barang
Proses : Pengecekan ketersediaan stok barang
Output : Data stok barang yang telah habis
5. Input : Data pelanggan
Proses : Pengecekan data pelanggan dan kendaraan
Output : Data daftar pelanggan dan kendaraan
6. Input : Data pegawai
Proses : Pengecekan data pegawai
Output : Data daftar gaji pegawai
7. Input : Data pemesanan barang
Proses : Pendataan barang ada atau tidak ada (ada)
Output : Laporan biaya produksi dan distribusi
8. Input : Data pemesanan barang
Proses : Pendataan barang ada atau tidak ada (tidak ada)
Output : Laporan produksi barang
Kebutuhan Non-Fungsional
Keamanan:
Servis yang sudah dilakukan akan mendapatkan garansi 2x24jam jika lebih dari itu garansi
akan habis.
Teklnologi:
Kantor pusat mencatat permintaan barang dengan mencocokan permintaan barang
sebelumnya menggunakan aplikasi sistem pengolahan ini.
BAB 3
USULAN SISTEM PEMESANAN BARANG
Rincian ide atau Desain
1. Servis dan pembelian sparepart menjadi lebih cepat sehingga mempercepat kinerja front
office.
2. Meminimalisir agar tidak terjadi kehilangan data.
3. Membantu menyelesaikan permasalahan yang ada di PT. Ramayana motor dalam
proses servis dan penjualan sparepart.
Diagram atau Gagasan
Scenario Usecase
SKENARIO USECASE LOGIN
Use Case : Login.
Aktor : Front Office(FO),manager.
Deskripsi : FO dan manager akan menginputkan data diri sebagai awal proses, yang
nantinya akan dicek oleh sistem validasi dari username dan password.
Pra Kondisi : Front Office dan manager sudah mempunyai username dan password.
Pos Kondisi : Sistem memberikan hak akses terhadap masing-masing user untuk memilih
menu aplikasi pada dekstop.
Skenario :
Aksi Aktor Reaksi Sistem
1. FO dan manager masukkan Username
dan Password pada form login.
2. FO dan manager menekan tombol
“Login”.
3. Memverifikasi valid tidaknya username dan
password pada database.
4. Masuk ke aplikasi.
SKENARIO ALTERNATIF NO.3
a. Masukkan username dan password pada
form login.
b. Mengecek valid/tidaknya data masukan.
c. Menampilkan pesan login tidak valid.
d. Masukkan Id password yang valid.
e. Mengecek valid/tidaknya data masukan.
f. Jika data valid maka secara otomatis akan
masuk ke tampilan awal aplikasi.
SKENARIO USE CASE MEMASUKKAN DATA PELANGGAN
Use Case : Memasukkan Data pelanggan.
Aktor : FO.
Deskripsi : Proses ini adalah sebuah proses dimana FO Memasukkan data pelanggan
yang yang akan melakukan service di bengkel motor honda.
Pra Kondisi : FO sudah berada pada menu pelanggan.
Pos Kondisi : Data pelanggan telah tersimpan.
Skenario :
Aksi Aktor Reaksi Sistem
1. FO memasukkan data pribadi
pelanggan dan kebutuhan service.
2. Menekan tombol “Simpan”.
3. Meng-update Data Pelanggan
4. Sistem akan menampilkan
notifikasi “Data telah berhasil
disimpan”.
5. FO menekan tombol “Selesai” .
SKENARIO USE CASE CETAK BUKTI TRANSAKSI
Use Case : cetak bukti transaksi.
Aktor : FO.
Deskripsi : Ini merupakan proses pencetakan struk/bukti transaksi.
Pra Kondisi : FO berada pada menu view data pelanggan, kemudian FO akan
mencetak bukti transaksi.
Pos Kondisi : Bukti transaki dicetak.
Skenario :
Aksi Aktor Reaksi Sistem
1. FO berada pada menu view data
pelanggan.
2. FO menekan tombol “Print”.
3. Menampilkan menu view data
pelanggan, dan mencetak bukti
transaksi.
4. FO menekan tombol “Selesai”.
SKENARIO USE CASE MENGUBAH DATA PELANGGAN
Use Case : Memasukkan data pelanggan yang baru.
Aktor : Manager.
Deskripsi : Ini merupakan proses pengubahan data pelanggan/kebutuhan pelanggan.
Pra Kondisi : Manager telah berada di menu Ubah Data Pelanggan.
Pos Kondisi : Update data pelanggan selesai.
Skenario :
Aksi Aktor Reaksi Sistem
1. Manager sudah berada di menu
ubah data pelanggan, kemudian
menginputkan data pelanggan yang
baru.
2. Menekan Tombol “Tambah”.
3. Menampilkan form data
pelanggan.
4. FO memasukkan kembali data
pelanggan yang baru, kemudian
menekan tombol “Simpan”.
5. Sistem akan menyimpan data
pelanggan yang baru.
6. Muncul notifikasi “Data
pelanggan telah di-update”.
SKENARIO USE CASE MEMASUKKAN KEBUTUHAN BENGKEL
Use Case : Mengecek status suku cadang yang tersedia
Aktor : Manager
Deskripsi : Ini merupakan proses input data suku cadang.
Pra Kondisi : Manager telah berada di menu input kebutuhan bengkel.
Pos Kondisi : sistem akan menampilkan menu data suku cadang yang masih tersedia
maupun yang sold out.
Skenario :
Aksi Aktor Reaksi Sistem
1. Manager berada di menu input
kebutuhan bengkel, kemudian
meng-input data suku cadang yang
baru.
2. Menekan Tombol “Ok”.
3. Sistem akan menampilkan data
suku cadang yang baru dan akan
menampilkan status tersedia
ataupun sold out.
SKENARIO USE CASE MENGECEK TRANSAKSI PELANGGAN
Use Case : Mengecek transaksi pelanggan.
Aktor : Manager.
Deskripsi : Ini merupakan proses pengecekan data transaksi pelanggan
yang melakukan service motor.
Pra Kondisi : Manager sudah berada pada menu view data transaksi pelanggan.
Pos Kondisi : Sistem akan menampilkan “Data Tansaksi pelanggan”.
Skenario :
Aksi Aktor Reaksi Sistem
1. Manager berada di menu view data
transaksi pelanggan.
2. klik icon “Cari”.
3. Sistem akan menampilkan
data transaksi pelanggan.
SKENARIO USE CASE MENGINPUT DATA PEGAWAI
Use Case : Meng-input Data Pegawai
Aktor : Manager
Deskripsi : Ini merupakan proses input data pegawai baru.
Pra Kondisi : Petugas sudah berada pada menu input data pegawai.
Pos Kondisi : Sistem akan menampilkan “form Data Pegawai”
Skenario :
Aksi Aktor Reaksi Sistem
1. Manager sudah berada di menu
input data pegawai, kemudian
memasukkan data pegawai baru.
2. Menekan tombol “OK”
3. Sistem akan menampilkan data pegawai baru.
4. Petugas menekan tombol “Selesai”
5. Muncul notifikasi “Data Pegawai telah tersimpan”
Activity Diagram
3.4. Activity Diagram
Activity diagram merupakan representasi grafis dari seluruh tahapan alur kerja. Berikut
perancangan activity diagram pengelolaan bengkel motor honda:
Class Diagram
Class Diagram digunakan untuk menampilkan kelas-kelas dan paket-paket di dalam
sistem. Berikut perancangan class diagram pengelolaan bengkel motor honda:
Dalam form ini terdapat username, password, login sebagai, tombol login, tombol forgot
password. Di form login ini berfungsi sebagai tempat login manager dan front office.
Gambar 1. Form Login
Tampilan Menu Masuk
Dalam tampilan ini terdapat menu-menu yang dapat dipilih seperti menu profil, data
pelanggan, data pegawai, stok barang, dan gaji pegawai.
Gambar 2. Tampilan Menu Setelah Login
Tampilan Menu Form Pelanggan
Tampilan ini berisi form yang digunakan front office untuk meng-input data pelanggan
dan melihat review data pelanggan.
Gambar 3. Form Front Office
Tampilan View Data Pelanggan
Disini menampilkan beberapa review data pelanggan yang telah di-input oleh front
office.
Gambar 4.View Data Pelanggan
Tampilan Input Data Pegawai
Menu ini digunakan untuk meng-input data pegawai yang bekerja di bengekel motor
honda.
Gambar 5. Input Data Pegawai