BAB III ANALISA DAN PERANCANGAN 3.1. Tentang Perusahaan dan Struktur Organisasi Perusahaan PT Indodev Niaga Internet (DataOn) adalah suatu perusahaan yang bergerak dibidang Information Technology (IT). Sejak tahun 1999 DataOn memiliki product yang dinamakan SunFish, melalui product inilah DataOn mulai dikenal. Sunfish merupakan aplikasi bisnis yang terintegrasi yang dapat membantu suatu organisasi/perusahaan melakukan kegiatan operasionalnya agar lebih produktif. Perusahaan ini dipimpin oleh seorang direktur yang membawahi 4 department, yaitu purchasing, IT, Marketing and Sales, dan Finance. Organisasi yang ada di DataOn dapat dilihat pada Gambar 3.1. di bawah ini.
Gambar 3.1. Struktur Organisasi 3.2. Analisa Sistem Berjalan 3.2.1.
Prosedur Pemesanan Makanan (Meal Order) di DataOn Berikut ini adalah proses bisnis pemesanan makanan yang berjalan di DataOn:
22
http://digilib.mercubuana.ac.id/
23
1. Admin kantin akan menginputkan menu makanan yang tersedia pada setiap harinya. 2. Karyawan yang akan memesan makanan harus melakukan pemesanan dengan cara menginputkan data pesanan kedalam sistem, yang meliputi: a. Memilih menu (makanan atau minuman) b. Memasukkan berapa banyak makanan yang dipesan c. Memilih pilihan overtime apabila karyawan akan melakukan overtime atau membiarkan pilihannya apabila karyawan memesan makanan biasa. 3. Apabila pesanan telah dikirim / diproses maka pesan kita akan masuk ke dalam sistem dan admin akan mendapatkan pemberitahuan atau notification. 4. Setelah mendapat pemberitahuan tersebut admin akan melakukan perubahan status terhadap pesanan kita menjadi confirmed atau canceled. 5. Karyawan menunggu pengajuannya hingga berstatus ready yang artinya makanan sudah siap diambil, dan pemberitahuannya akan diberikan melalui email. 6. Ketika karyawan telah mengambil makanan, karyawan perlu mengubah statusnya menjadi received. Status ini dipakai sebagai tanda request tersebut telah selesai (closed). 3.2.2.
Hasil Analisa Berikut hasil analisa yang dilakukan pada sistem pemesanan makanan pada
DataOn: Sistem yang sedang berjalan saat ini memang berguna, karena DataOn merupakan perusahaan yang bergerak dalam bidang IT. Selain itu programmer sangat identik dengan lembur. Karyawan akan dapat dengan mudah melakukan pemesanan makanan apabila dalam keadaan membuka laptop atau sedang mengerjakan pekerjaan seperti biasa. Namun bagi kebanyakan karyawan yang memiliki client di luar kantor dan masih ditengah perjalanan akan sulit mengakses laptop. 1. Analisa informasi (information) Informasi dapat diukur dengan akurat, relevan, dan tepat waktu. Informasi merupakan hal yang sangat penting, dalam sistem yang lama informasi. Dengan
http://digilib.mercubuana.ac.id/
24
adanya aplikasi ini user dapat mengetahui status permesanan makanan secara real time dengan menggunakan perangkat mobile berbasis android. 2. Analisa efisiensi (eficiency) Dengan aplikasi yang akan dibuat karyawan akan mendapat manfaat dari segi waktu karena ketika kita menggunakan browser untuk mengakses situs ini akan ada waktu yang terbuang dibandingkan kita langsung mengakses aplikasi mobile yang akan dibuat ini. 3. Analisa pelayanan (service) Service atau layanan berhubungan dengan penyediaan informasi bagi pencari informasi. Pada sistem yang ada, untuk mencari informasi user harus harus membuka laptop atau browser pada HP. Akan lebih baik apabila user dapat mengaksesnya melalui HP dengan tampilan mobile yang telah disesuaikan bukan tampilan browser yang harus kita sesuaikan sendiri. 3.2.3.
Use Case Diagram Sistem Berjalan Adapun use case yang sedang berjalan seperti yang terlihat pada Gambar 3.2. di bawah ini. Use Case Sistem Berjalan Menarik Laporan
Sinkronisasi sistem
LogIn
Finance
Admin Sistem
Memesan makanan Mengelola data menu
Mengubah status pesanan Mengubah status pesanan Karyawan
Melihat sejarah pesanan Admin Kantin
Melihat daftar menu
Menyetujui/menolak pesanan lembur
Gambar 3.2. Use Case Sistem Berjalan
http://digilib.mercubuana.ac.id/
25
Pada dasarnya karyawan telah menggunakan InSys untuk melakukan pemesanan makanan, namun sistem yang ada sekarang belum berjalan secara maksimal apabila diakses melalui smartphone. User harus melakukan penyesuaian terlebih dahulu agar tampilannya sesuai dengan yang diinginkan dan ini sangatlah tidak efektif. Selain itu beberapa fungsi kadang tidak berfungsi ketika kita mengakses sistemnya dari smartphone. Berikut akan dijelaskan skenario Use Case Diagram Sistem Berjalan, diantaranya: Berikut adalah use case description untuk user login pada sistem beralan: Tabel 3.1. Skenario Use Case Login Nama Use Case Actor Deskripsi Pra Kondisi Skenario
Post kondisi
Login Admin Kantin, Karyawan,Admin Sistem Actor yang terlibat harus memasukkan data username dan password agar dapat mengakses sistem. Admin sistem akan membuatkan account berdasarkan no_employee yang telah terdaftar pada sistem HR Admin sistem akan memberikan username dan password kepada karyawan, setelah itu karyawan dapat masuk ke dalam sistem dengan menggunakan password yang telah diberikan, Semua actor terlibat dapat mengakses sistem dan melakukan kegiatan (memesan, membatalkan, melihat history serta mengubah status request yang telah dibuat)
Berikut adalah use case description untuk proses pemesanan pada sistem berjalan: Tabel 3.2. Skenario Use Case Memesan Makanan Nama Use Case Actor Deskripsi Pra Kondisi Skenario
Post kondisi
Memesan makanan Karyawan Untuk melakukan pemesanan karyawan harus mengakses sistem melalui browser (Laptop / PC/HP) Karyawan mengakses sistem melalui Laptop / HP 1. Karyawan mengisi data pesanan 2. Karyawan menerima konfirmasi atas pesanannya secara online Lihat status dari pesanan yang telah dikirimkan
Berikut adalah use case description untuk mengubah status pesanan pada sistem berjalan, bagaimana seseorang melakukan perubahan status untuk request yang telah diajukan.
http://digilib.mercubuana.ac.id/
26
Perubahan status ini dijadikan sebagai informasi baik untuk admin dan untuk karyawan itu sendiri, dan penjelasannya adalah sebagai berikut:
Tabel 3.3. Skenario Use Case Mengubah Status Pesanan Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post Kondisi
Mengubah status pesanan Admin Kantin, Karyawan Perubahan status dimaksudkan untuk memberikan informasi kepada dua belah pihak yang sedang berinteraksi melalui system Admin Kantin akan memberikan status apakah permintaannya diterima, direvisi, atau ditolak 1. Cek permintaan kemudian Admin kantin akan mengubah status. 2. Karyawan melihat status yang telah diubah, apabila isinya statusnya “canceled” request yang telah diajukan ditolak. Apabila statusnya “confirm” maka karyawan harus menunggu sampai statusnya berubah menjadi “ready” dan karyawan dapat mengambil pesanannya. 3. Setelah pesanan diterima karyawan harus mengubah statusnya dari ready ke received Karyawan mengubah status pemesanan ke “received” (Close Request)
Berikut adalah use case description untuk melihat sejarah pemesanan yang dilakukan oleh user pada sistem berjalan: Tabel 3.4. Skenario Use Case Melihat Sejarah Pesanan Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post kondisi
Melihat sejarah pesanan Karyawan, Admin Kantin Selain dari email status pesanan dapat dilihat pada menu history ini. Ketika kita menerima notifikasi berupa email dari sistem kita dapat melihat status permintaan kita pada menu history ini Karyawan mengakses menu history 1. Menerima notifikasi dari email 2. Masuk ke dalam menu history 3. Lihat status Karyawan dapat memantau status dan history dari permintaan – permintaan sebelumnya.
http://digilib.mercubuana.ac.id/
27
Berikut adalah use case description untuk melihat daftar menu pada sistem berjalan: Tabel 3.5. Skenario Use Case Melihat Daftar Menu Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post Kondisi
Melihat daftar menu Karyawan List menu yang ada di kantin baik yang tersedia (dapat dipesan) maupun yang tidak dapat dilihat pada daftar menu yang tersedia User harus mengakses fungsi “Menu List” 1. Lihat list menu yang tersedia 2. Pesan berdasarkan menu yang tersedia 3. Menu yang tersedia berhasil dipesan Pemesanan berhasil dilakukan
Berikut adalah use case description untuk menyetujui/menolak pesanan overtime pada sistem berjalan: Tabel 3.6. Skenario Use Case Menyetujui/Menolak Pesanan Lembur Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post Kondisi
Menyetujui/Menolak Pesanan Overtime Karyawan Setiap karyawan yang ditunjuk sebagai approver akan mendapat notifikasi ketika ada bawahannya yang melakukan meal overtime request. Mereka yang ditunjuk sebagai approver dapat menyetujui atau menolak request yang diajukan oleh bawahannya dengan alasan yang jelas. Karyawan masuk ke dalam sistem kemudian lihat pada menu “Approval” 1. Lihat apakah terdapat request yang masih belum ditanggapi. 2. Lakukan aksi pada request yang diajukan oleh karyawan, approver dapat menyetujui request tersebut atau dapat juga menolaknya dengan alasan yang jelas. Request disetuji / ditolak
Berikut adalah use case description untuk sinkronisasi sistem pada sistem berjalan: Tabel 3.7. Skenario Use Case Sinkronisasi Sistem Nama Use Case Actor Deskripsi
Sinkronisasi system Admin Sistem Terdapat 2 sistem berjalan yang saling terkait, kedua sistem tersebut adalah human resources system (HRIS)
http://digilib.mercubuana.ac.id/
28
dan internal system (InSys). Kedua sistem tersebut harus memiliki data karyawan yang sama, sedangkan penginputan karyawan dilakukan pada HRIS sehingga diperlukan adanya sinkronisasi antara kedua sistem tersebut Admin memasukan data karyawan ke dalam HRIS 1. Masukan data karyawan baru ke HRIS 2. Lakukan sinkronisasi dengan mengakses menu “Auto Sync Staff” 3. Periksa data karyawan Data tersinkronisasi
Pra Kondisi Skenario
Post Kondisi
Berikut adalah use case description untuk mengelola data menu pada sistem berjalan: Tabel 3.8. Skenario Use Case Mengelola Data Menu Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post Kondisi
Mengelola data menu Admin Kantin Admin harus senantiasa mengupdate data menu terbaru. Bukan berart setiaphari harus memasukan menu yang berbeda, tetapi admin harus mengupdate apakah menu yang menu yang terdapat di list menu masih tersedia atau tidak Liahat bahan makanan yang tersedia 2. Masuk ke dalam sistem 3. Update status menu sesuai dengan bahan makanan yang tersedia Data menu terupdate
Berikut adalah use case description untuk pembuatan report pada sistem berjalan: Tabel 3.9. Skenario Use Case Menarik Laporan Nama Use Case Actor Deskripsi
Pra Kondisi Skenario Post Kondisi
Menarik laporan Finance Setiap bulan bagian finance akan menarik laporan transaksi yang dilakukan oleh karyawan setiap bulan, sebagai basis untuk perhitungan gaji. Admin akan melakukan pengecekan terhadap status – status request yang telah masuk 1. Cek status permintaan apakah sudah received semua. 2. Generate report Report diserahkan kepada bagian penggajian
http://digilib.mercubuana.ac.id/
29
3.2.3.
Analisa Kebutuhan Sistem Analisa kebutuhan pengembangan sistem meal order ini meliputi kebutuhan
fungsional dan kebutuhan non fungsional, berikut penjelasannya: 3.2.3.1. Kebutuhan Fungsional Kebutuhan fungsional adalah kebutuhan user terhadap sistem yang akan dikembangkan itu. Kebutuhan fungsional tersebut melputi: 1. User dapat melakukan request atau pemesanan melalui mobile. 2. User dapat memeriksa status pemesanan yang telah dilakukan secara online. 3. User dapat memproses pemesanan lebih cepat. 4. User dapat melakukan aksi (melakukan perubahan status pesanan) dengan lebih mudah dan cepat. 3.2.3.2. Kebutuhan Non Fungsional Selain kebutuhan fungsional, user juga memiliki kebutuhan non fungsional yang harus dipenuhi, diantaranya: 1. Kinerja Sistem dapat diakses dimana saja selama kita memiliki koneksi internet. 2. Keamanan Sistem dan database dilengkapi dengan password untuk login. 3. Informasi Sistem dilengkapi dengan validasi yang cukup agar user terhindar dari kesalahan. 3.3.
Perancangan Sistem
3.3.1.
Use Case Diagram Dalam sistem ini hanya akan melibatkan 1 actor saja, yaitu user. Setiap user yang
telah didaftarkan akan dapat mengakses sistem ini, user dapat melakukan pemesanan atau pembatalan order, selain itu user juga dapat melihat history pemesanan yang telah dilakukan serta melakukan perubahan status apabila ordernya telah diterima. Use Case yang diusulkan untuk pengembangan sistem meal order di DataOn adalah sebagai berikut:
http://digilib.mercubuana.ac.id/
30
3.3.1.1. Use Case Diagram yang Diusulkan untuk Sistem yang Baru Adapun use case diagram yang diusulkan akan ditampilkan pada Gambar 3.3. Pada bagian ini terdapat satu actor yang dihilangkan karena fungsinya tidak relevan apabila dilakukan melalui HP, actor tersebut adalah admin kantin. Admin kantin harus membuka aksesnya ketika mereka siap melayani karyawan. Dari Use case diagram yang diusulkan dapat dilihat tidak banyak perubahan proses yang terjadi, namun tampilan baru yang disajikan akan lebih membatu user dalam melakukan pemesanan makanan di kantin karena selain tampilan yang telah disesuaikan dengan kebutuhan user.
Use Case Sistem yang Diusulkan LogIn
Memesan makanan
Mengubah status pesanan Approver Karyawan Melihat sejarah pesanan
Melihat daftar menu
Menyetujui/menolak pesanan lembur
Gambar 3.3. Use Case Sistem yang Diusulkan 3.3.1.2. Skenario Use Case Diagram yang Diusulkan Dari kekurangan yang telah dipaparkan sebelumnya penulis mencoba memperbaikinya pada use case yang diusulkan ini. Dari sisi kegunaan, sistem yang diusulkan akan lebih dapat membantu karyawan dalam melakukan transaksi meal order apabila dilakukan melalui smartphone, karena sistem ini memang dikembangkan agar dapat lebih compatible pada smartphone. Berikut adalah use case description untuk user login pada aplikasi meal order:
http://digilib.mercubuana.ac.id/
31
Tabel 3.10. Skenario Use Case Login yang Diusulkan Nama Use Case Actor Deskripsi Pra Kondisi Skenario
Post kondisi
Login Admin Kantin, Karyawan,Admin Sistem Actor yang terlibat harus memasukkan data username dan password agar dapat mengakses sistem. Admin sistem akan membuatkan account berdasarkan no_employee yang telah terdaftar pada sistem HR Admin sistem akan memberikan username dan password kepada karyawan, setelah itu karyawan dapat masuk ke dalam sistem dengan menggunakan password yang telah diberikan, Semua actor terlibat dapat mengakses sistem dan melakukan kegiatan (memesan, membatalkan, melihat history serta mengubah status request yang telah dibuat)
Berikut adalah use case description untuk proses pemesanan pada aplikasi meal order: Tabel 3.11. Skenario Use Case Memesan Makanan yang Diusulkan Nama Use Case Actor Deskripsi Pra Kondisi Skenario
Post kondisi
Memesan makanan Karyawan Untuk melakukan pemesanan karyawan harus mengakses sistem melalui browser (Laptop / PC/HP) Karyawan mengakses sistem melalui Laptop / HP 1. Karyawan mengisi data pesanan 2. Karyawan menerima konfirmasi atas pesanannya secara online Lihat status dari pesanan yang telah dikirimkan
Berikut adalah use case description untuk mengubah status pesanan pada aplikasi meal order: Tabel 3.12. Skenario Use Case Mengubah Status Pesanan yang Diusulkan Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Mengubah status pesanan Karyawan Perubahan status dimaksudkan untuk memberikan informasi kepada dua belah pihak yang sedang berinteraksi melalui system Admin Kantin akan memberikan status apakah permintaannya diterima, direvisi, atau ditolak 1. Cek permintaan kemudian Admin kantin akan mengubah status.
http://digilib.mercubuana.ac.id/
32
Post Kondisi
2. Karyawan melihat status yang telah diubah, apabila isinya statusnya “canceled” maka request tersebut ditolak oleh admin kantin. Apabila statusnya “confirmed” maka karyawan harus menunggu sampai statusnya berubah menjadi “ready” dan karyawan dapat mengambil pesanannya. 3. Setelah pesanan diterima karyawan harus mengubah statusnya dari ready ke received Karyawan mengubah status pemesanan ke “received” (Close Request)
Berikut adalah use case description untuk melihat sejarah pemesanan yang dilakukan oleh user pada aplikasi meal order: Tabel 3.13. Skenario Use Case Melihat Sejarah Pesanan yang Diusulkan Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post kondisi
Melihat sejarah pesanan Karyawan Selain dari email status pesanan dapat dilihat pada menu history ini. Ketika kita menerima notifikasi berupa email dari sistem kita dapat melihat status permintaan kita pada menu history ini Karyawan mengakses menu history 1. Menerima notifikasi dari email 2. Masuk ke dalam menu history 3. Lihat status Karyawan dapat memantau status dan history dari permintaan – permintaan sebelumnya.
Berikut adalah use case description untuk melihat daftar menu pada aplikasi meal order: Tabel 3.14. Skenario Use Case Melihat Daftar Menu yang Diusulkan Nama Use Case Actor Deskripsi
Pra Kondisi Skenario
Post Kondisi
Melihat daftar menu Karyawan List menu yang ada di kantin baik yang tersedia (dapat dipesan) maupun yang tidak dapat dilihat pada daftar menu yang tersedia User harus mengakses fungsi “Menu List” 1. Lihat list menu yang tersedia 2. Pesan berdasarkan menu yang tersedia 3. Menu yang tersedia berhasil dipesan Pemesanan berhasil dilakukan
http://digilib.mercubuana.ac.id/
33
Berikut adalah use case description untuk menyetujui/menolak pesanan overtime pada aplikasi meal order: Tabel 3.15. Skenario Use Case Menyetujui/Menolak Pesanan Lembur yang Diusulkan Nama Use Case Actor Deskripsi
Menyetujui/Menolak Pesanan Overtime Karyawan Setiap karyawan yang ditunjuk sebagai approver akan mendapat notifikasi ketika ada bawahannya yang melakukan meal overtime request. Mereka yang ditunjuk sebagai approver dapat menyetujui atau menolak request yang diajukan oleh bawahannya dengan alasan yang jelas. Karyawan masuk ke dalam sistem kemudian lihat pada menu “Approval” 1. Lihat apakah terdapat request yang masih belum ditanggapi. 2. Lakukan aksi pada request yang diajukan oleh karyawan, approver dapat menyetujui request tersebut atau dapat juga menolaknya dengan alasan yang jelas. Request disetuji / ditolak
Pra Kondisi Skenario
Post Kondisi
3.3.2.
Activity Diagram Activity diagram memodelkan alur kerja sebuah proses bisnis. Bagian ini akan
memberi gamaran bagaimana cara sistem yang diusulkan bekerja. Activity diagram dari pengembangan sistem meal order pada DataOn adalah sbb:
http://digilib.mercubuana.ac.id/
34
Karyawan (Requester)
Admin Kantin
Akses aplikasi
[Tidak] Login ke dalam aplikasi
Sesuai? [Ya] [Tidak] Inputkan pesanan Sesuai?
[Ya] Menerima pesanan
Setuju?
[Tidak]
Lihat alasan
Mengubah Status Pesanan
[Ya] [Tidak] Periksa Status Pesanan
Siap? [Ya]
Mengambil Pesanan
Memberikan Pesanan
[Tidak] Ubah Status
Diterima?
[Ya]
Gambar 3.4. Activity Diagram Sistem yang Diusulkan Keterangan: 1. User mengakses aplikasi meal order 2. Menginputkan pesanan kedalam aplikasi meal order dengan cara memilih menu serta menginputkan beberapa informasi yang dibutuhkan pada form aplikasi, setelah itu submit pesanan. 3. Setelah pesanan dilakukan, admin kantin akan menerima pesanan kemudian memberikan aksi terhadap request yang masuk. Action yang dapat diberikan antara lain:
http://digilib.mercubuana.ac.id/
35
a. Confirmed
: artinya request kita diterima dan pihak kantin akan
membuatkan makanan berdasarkan request yang kita lakukan. b. Reject
: artinya request yang kita lakukan ditolak. Ketika status ini
diberikan, admin harus menyertakan alasan mengapa request tersebut ditolak. c. Ready
: artinya request yang telah diterima oleh admin kantin telah siap
dan dapat diambil. 2.
Ketika status ready telah diberikan untuk satu pesanan, dan karyawan telah mendapatkan makanan sesuai dengan request, maka karyawan harus mengubah status pemesanan menjadi received.
3.3.3
Class Diagram Class Diagram memberikan pandangan secara luas dari suatu sistem dengan
menunjukkan kelas – kelasnya dan hubungan mereka. Selama tahap desain, class diagram berperan dalam menangkap struktur dari semua kelas yang membentuk arsitektur yang dibuat.
3.3.3.1 Class Diagram Class diagram dari meal order process pada DataOn dapat dilihat pada Gambar 3.5. di bawah ini:
Pesanan
1..1 Karyawan -UserId -username -password -nama -role +update_data()
1..*
-kodebuku -userid -price -qty -overtime -takehome -subtotal -desc -status -approved -orderid +add() +updatestatus()
1..* Menu 1..*
-kodemenu -namamenu -harga -status +view()
1..1
1..1
1..1
Status1..1 -orderid -status -kdmenu -qty -price -requester -status_ovt -userid +updatestatus()
Gambar 3.5. Class Diagram Sistem yang Diusulkan
http://digilib.mercubuana.ac.id/
36
3.3.4 Sequence Diagram Sequence Diagram menjelaskan interaksi object yang disusun dalam urutan waktu. Sequence Diagram dari meal order process pada DataOn adalah sebagai berikut: 3.3.4.1. Sequence Diagram Login
Tampilan Login
Proses Login
Halaman Utama
User 1. submitData()
2. ValidasiData() 3. KirimData()
3. RetunLogin()
5. TampilanHalamanUtama()
Gambar 3.6. Sequence Diagram Melakukan Login Skenario dari sequence diagram login adalah sebagai berikut : Tabel 3.16. Skenario Sequence Diagram Melakukan Login Nama Sequence
Melakukan Login
Actor
User / Karyawan
Deskripsi
User dapat melakukan login setelah mendapatkan username dan password dari admin. Setelah mendapatkan akses yang dimaksud, user dapat mengikuti langkah – langkah dibawah ini: 1. Memasukkan data login 2. Sistem akan memproses data, dan melakukan pengecekan terhadap data tersebut. Apakah data yang dimasukan valid atau tidak 3. Ketika sistem membaca gagal maka akan tampil error message. Tetapi apabila sistem membaca sukses maka user akan dapat masuk ke dalam sistem.
http://digilib.mercubuana.ac.id/
37
3.3.4.2. Sequence Diagram Melakukan Pemesanan
Tampilan List Menu
Form Pemesanan / Order
Tombol Submit
User
PilihMenu()
2. MemvalidasiData()
3. LengkapiInformasi()
4. MengirimkanData()
2. MemvalidasiData()
4. MenerimaKonfirmasiDataPemesanan()
Gambar 3.7. Sequence Diagram Melakukan Pemesanan Skenario dari sequence diagram di atas adalah sebagai berikut: Tabel 3.17. Tabel Skenario Sequence Diagram Melakukan Pemesanan Nama Sequence Actor Deskripsi
Melakukan Pemesanan Karyawan Ketika user akan melakukan pemesanan makanan / meal order, inilah langkah – langkah yang harus dilakukan oleh user: 1. Masukan data sesuai dengan kebutuhan (pilih makanan dan minuman) 2. Pilih apakah pemesanan yang dilakukan untuk overtime atau bukan 3. Sistem akan melakukan beberapa pengecekan ketika user melakukan pemesanan untuk overtime, diantaranya adalah jumlah pembayarannya tidak melebihi 35000 4. Apabila sistem membaca ada kekeliuan maka akan ada error message yang keluar, apabila sistem membaca data yang dimasukkan valid maka data akan
http://digilib.mercubuana.ac.id/
38
masuk ke dalam sistem.
3.3.4.3. Sequence Diagram Melakukan Perubahan Status
Tampilan Data Pesanan
Tombol Detail
User 1. PilihDataPesanan() 2. CekPemesanan()
3. PesananDitampilkan 4. UbahStatusPemesanan
5. ValidasiStatus
6. MengirimkanData()
7. MenerimaKonfirmasiDataPerubahanStatus()
Gambar 3.8. Sequence Diagram Melakukan Perubahan Status Skenario dari sequence diagram di atas adalah sebagai berikut: Tabel 3.18. Tabel Skenario Sequence Diagram Melakukan Perubahan Status Nama Sequence
Perubahan Status
Actor
Karyawan
Deskripsi
Perubahan status dapat dilakukan oleh user dengan mengikuti langkah – langkah dibawah ini: 1. Setelah mendapatkan notifikasi yang memperlihatkan makanan yang dipesan user sudah siap / “Ready” 2. Klik nomor permintaannya, kemudian ubah statusnya ke “Received”
http://digilib.mercubuana.ac.id/
39
3.3.4.4. Sequence Diagram Melakukan Persetujuan atau Penolakan Pesanan
Tampilan Inbox
TampilanKonfirmasi
User 1. PilihTransaksi() 2. CekPemesanan()
3. PesananDitampilkan 4. AksiMenyetujui()/AksiMenolak()
5. ValidasiData()
6. MengirimkanData() 7. MenerimaKonfirmasi()
Gambar 3.9. Sequence Diagram Persetujuan atau Penolakan Pesanan
Skenario dari sequence diagram di atas adalah sebagai berikut: Tabel 3.19. Tabel Skenario Sequence Diagram Persetujuan atau Penolakan Pesanan Nama Sequence
Persetujuan atau penolakan pesanan
Actor
User / Karyawan
Deskripsi
Aksi persetujuan atau penolakan terhadap pesanan yang telah diajukan hanya dapat dilakukan oleh karyawan yang diberikan akses sebagai approver. Approver tersebut hanya dapat memberikan aksinya ketika request yang diajukan oleh karyawan berstatus received serta time sheet telah
http://digilib.mercubuana.ac.id/
40
diisi. Ketika kedua syarat tersebut terpenuhi, approver dapat mengikuti langkah – langkah dibawah ini: 2. Pilihlah tansaksi yang akan diberikan aksi. 3. Ubahlah status transaksi tersebut dengan cara klik tombol approve untuk menyetujui atau tombol reject untuk menolak. Ketika approver memilih reject, maka dia diharuskan mengisi alasan agar karyawan mengetahui kenapa request yang diajukan tersebut ditolak.
3.4.
Perancangan Basis Data Berikut akan ditampilkan perancangan Basis Data dari Pengembangan Aplikasi
Meal Order di DataOn. 3.4.1.
Spesifikasi Basis Data Berikut akan dijelaskan spesifikasi basis data yang dimulai dari pembuatan Entity
Relationship Diagram (ERD) yang kemudian akan dirubah menjadi Logical Record Stucture (LRS), gambaran dari LRS tersebut akan menghasilkan sebuah tabel relasi basis data. 1. Transformasi ERD ke Bentuk LRS Transformasi diagram ERD ke LRS merupakan suatu kegiatan untuk membentuk data – data dari diagram hubungan entitas ke suatu LRS. ERD diatas akan ditransformasi ke bentuk LRS seperti terlihat pada Gambar 3.10. di bawah ini:
http://digilib.mercubuana.ac.id/
41
-emp_id -first_name -middle_name -last_name -start_date -end_date -user_name -user_password -email_address -emp_status
-emp_id -approved_by
-Id -Name -Unitprice -Type -Inputdate -Flag -Quantity -Source -Sell -emp_id -Id
-emp_id N KApproveAuthority
1
sebagai
TabUser 1
-emp_id -orderno
1
N
pilih
KMenu
1
order miliki
-emp_id -role_id 1 KRole
N KOrderHeader -role_id -role_name
-orderno -ordertime -orderby -orderfor -isocertime -approvestatus -approvedate -approveby -tkhome
Gambar 3.10. Gambar Transformasi E-R ke Bentuk LRS Nama Database : Insys 1. Nama Tabel
: kMenu
Primary Key
:Tabel 3.20. Basis Data List Menu
No Nama Field 1 2 3 4 5 6 7 8 9
Id Name Unitprice Status Type Inputdate Flag Quantity Source
Jenis Char Varchar Money Char Char Datetime Char Int varchar
Panjang 10 50 8 1 1 8 1 4 15
http://digilib.mercubuana.ac.id/
Keterangan
42
No Nama Field
Jenis
10 Sell
Int
2. Nama Tabel
: TabUser
Panjang
Keterangan
4
:-
Primary Key
Tabel 3.21. Basis Data User No Nama Field
Jenis
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Char Varchar Varchar Varchar Datetime Datetime Varchar Binary Varchar Char Char Char Bit Char Char Char
emp_id first_name middle_name last_name start_date end_date user_name user_password email_address emp_status user_role meal_role flag_email emp_id_new InventoryRole dms_role
3. Nama Tabel
Panjang
Keterangan
10 15 15 15 8 8 30 64 30 1 3 2 1 10 3 3
: kOrderHeader : orderno
Primary Key
Tabel 3.22. Basis Data Order Header No Nama Field 1 2 3 4
Orderno Ordertime Orderby Orderfor
Jenis Int Datetime Char Char
Panjang
Keterangan
4 Primary Key 8 10 10
http://digilib.mercubuana.ac.id/
43
No Nama Field 5 6 7 8 9
Jenis
Isovertime Approvestatus Approvedate Approveby tkHome
Bit Char Datetime Varchar Bit
4. Nama Tabel
: kOrderDetail
Primary Key
: orderdetailid
Panjang
Keterangan
1 1 8 10 1
Tabel 3.23. Basis Data Order Detail No Nama Field
Jenis
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Int Int Char Int Varchar Char Int Datetime Varchar Varchar Char Datetime Bit Bit
Orderdetailid Orderno Cdmenu Qty Description Status Price Lastupdate Reason Approvestatus Approveby Approvedate Isovertime tkHome
5. Nama Tabel Primary Key
Panjang
Keterangan
4 Primary Key 4 10 4 225 1 4 8 225 8 10 8 1 1
: Setting :Tabel 3.24. Basis Data Setting
No Nama Field 1 2 3 4 5 6 7 8 9
Rowperpage Maxordertime Maxorderlunch Maxordercancel maxorderRevisi Maxpriceorderovt Pricelunchmenu Maxquotalunch maxquotalunchalt
Jenis Int Datetime Datetime Datetime Datetime Float Float Int Int
Panjang 4 8 8 8 8 8 8 4 4
http://digilib.mercubuana.ac.id/
Keterangan
44
6. Nama Tabel
: kApproveAuthority :-
Primary Key
Tabel 3.25. Basis Data Approve Authority No Nama Field
Jenis
Panjang
1 emp_id 2 approve_by
Char Char
10 10
7. Nama Tabel Primary Key
Keterangan
:TRole :Tabel 3.26. Basis Data Role
No Nama Field 1 role_id 2 role_name
Jenis Char Varchar
Panjang
Keterangan
3 50
3.5. Perancangan Antar Muka 3.5.1.
Login Tampilan ini merupakan tampilan pertama ketika user membuka sistem meal
order. Pada bagian inilah user akan diminta memasukkan username dan password agar dapat masuk ke dalam sistem meal ordernya.
Gambar 3.11. Rancangan User Interface Login 3.5.2.
Halaman Utama Ketika pertama kali login user akan melihat tampilan halaman utama seperti
terlihat pada Gambar 3.12. pada bagian tengahakan tampil request – request yang masih
http://digilib.mercubuana.ac.id/
45
pending atau masih membutuhkan aksi (perubahan status) oleh user. List yang tampil pada menu ini merupakan summary dari request yang diajukan oleh karyawan.
Gambar 3.12. Rancangan User Interface Home Untuk melihat detail dari request yang telah diajukan maka karyawan harus klik tanda “>>” agar kta dapat melihat detailnya secara jelas. Dari detail ini lah karyawan dapat memberikan aksi “Received” ketika makanan yang mereka pesan telah mereka dapatkan. Detail request ini dapat dilihat pada Gambar 3.13. di bawah ini:
Gambar 3.13. Rancangan Request Detail
http://digilib.mercubuana.ac.id/
46
3.5.3.
Order Meal Tampilan di bawah ini merupakan tampilan ketika user akan menambah request
baru dapat dilihat melalui Gambar 3.14. di bawah ini:
Gambar 3.14. Rancangan User Interface Order 1 Karyawan harus memilih menu sesuai dengan yang diinginkan setelah itu klik tombol add kemudian karyawan harus melengkapi beberapa informasi seperti terlihat pada Gambar 3.15. di bawah ini:
Gambar 3.15. Rancangan User Interface Order 2
http://digilib.mercubuana.ac.id/
47
3.5.4.
Inbox Inbox merupakan satu fungsi yang dapat karyawan gunakan untuk memberi
persetujuan atau penolakan terhadap request yang diajukan oleh karyawan. Rancangan menu ini dapat dilihat pada Gambar 3.16. di bawah ini:
Gambar 3.16. Rancangan User Interface Inbox 3.5.5.
History Page ini akan menampilkan request – request kita yang telah kita close (statusnya
“received”)
Gambar 3.17. Rancangan User Interface View History
http://digilib.mercubuana.ac.id/