BAB 3 ANALISIS SISTEM

(1)

BAB 3

ANALISIS SISTEM

3.1 Gambaran Umum Perusahaan 3.1.1 Sejarah Singkat Perusahaan

BINUS School Serpong yang beralamatkan pada Jl. Lengkong Karya – Jelupang No. 58 berdiri pada pertengahan tahun 2007. Dibangun di atas tanah seluas 4 hektar, BINUS School Serpong adalah tambahan terbaru pada saat ini ke dalam keluarga besar organisasi Bina Nusantara. Melihat keberhasilan dari BINUS School Simprug, BINUS School Serpong menggabungkan teknologi informasi dan kekuatan sumber daya dari organisasi Bina Nusantara dengan filosofi dan strategi pendidikan terbaik yang didapatkan selama 25 tahun pengalaman di bidang edukasi.

BINUS School Serpong menawarkan sebuah sekolah national-plus yang terbaik dengan tingkat edukasi dari pre-school hingga high-school yang menyediakan berbagai macam multiple-intelligences learning style, dengan fokus pada dua bahasa, dan bahkan tiga bahasa, pendidikan karakter melalui service-learning, dan sebuah budaya yang inovatif. Setiap anggota didorong untuk berpikir keluar dari kotak untuk membuat suatu peningkatan terhadap berbagai aspek dari kehidupan kampus.

3.1.2 Visi dan Misi Perusahaan

Visi BINUS School Serpong adalah untuk menghasilkan individu yang mempunyai karakter bermoral, keunggulan akademis dan kepemimpinan inovatif yang dapat menginspirasikan dan memberi kontribusi pada komunitas lokal dan global.

(2)

Misi BINUS School Serpong adalah untuk memberikan kecerdasan dan nilai pendidikan terbaik dari Taman kanak–kanak sampai Sekolah Menengah Atas kepada murid – murid di Indonesia, Dimana performa akademis dan pencapaian extrakulikuler, dapat dibandingkan dengan standar terbaik di wilayah setempat. Yang didukung oleh dengan komitmen BINUS School Serpong untuk melayani komunitas dengan nilai karakter yang kuat dan kebudayaan yang cakap dan inovatif.

3.1.3 Struktur Organisasi Perusahaan

Gambar 3.1 Struktur organisasi BINUS School Serpong

3.1.4 Tugas dan Wewenang Masing-Masing Divisi

Berikut merupakan penjelasan tentang tugas dan wewenang masing – masing divisi yang ada dalam BINUS School Serpong :

1. Board of Management:

Board of Management bertugas untuk menentukan kebijakan BINUS School Serpong dan menentukan perencanaan strategis.

2. Principal:

Principal bertanggung jawab atas keseluruhan kegiatan yang dilakukan dalam BINUS School Serpong.

(3)

3. Marketing Directorate

Divisi ini bertanggung jawab untuk menentukan strategi pemasaran yang akan dijalankan oleh BINUS School Serpong.

4. Finance Directorate

Divisi ini bertanggung jawab untuk mengatur semua masalah dan strategi keuangan yang akan dijalankan oleh BINUS School Serpong.

5. General Affair and Legal Directorate

Divisi ini bertugas untuk mengatur seluruh operasional organisasi dan menyelesaikan permasalah umum yang terjadi di BINUS School Serpong.

6. Talent Management Directorate

Divisi ini bertanggung jawab untuk mengurusi urusan Human Resource, seperti penambahan karyawan baru, pemberhentian karyawan, menentukan besar gaji dan job description karyawan BINUS School Serpong.

7. Secretary

Secretary merupakan jembatan atau penghubung antara Principal dengan divisi dibawahnya, yaitu: ECY-EL Coordinator, National Curricullum Coordinator, MS-HS Coordinator, Head of Guidance and Counseling, Information Technology Manager, General Operation Manager dan Quality Assurance Senior Officer.

8. ECY-EL Coordinator

Divisi ini mengkoordinasikan semua kegiatan yang akan dilakukan oleh staff pengajar tingkat early childhood year hingga elementary school.

9. National Curricullum Coordinator

Divisi ini berhubungan dengan pemerintah untuk mengkoordinasikan semua kurikulum yang akan diajarkan pada siswa di BINUS School Serpong dan mengurus

(4)

tentang sertifikasi serta legalitas. Divisi ini berhubungan secara langsung dengan ECY-EL Coordinator dan MS-HS Coordinator

10. MS-HS Coordinator

Divisi ini mengkoordinasikan semua kegiatan yang akan dilakukan oleh staff pengajar tingkat middle School hingga high school.

11. Head of Guidance and Counseling

Divisi ini bertugas untuk membimbing dan berkonsulatasi dengan siswa BINUS School Serpong dan mengatasi siswa yang bermasalah.

12. Information Technology Manager

Divisi ini bertanggung jawab untuk membangun sistem informasi yang akan diterapkan di BINUS School Serpong dan memelihara sistem informasi tersebut. 13. General Operations Manager

Divisi ini bertugas untuk memastikan seluruh operasi yang ada di BINUS School Serpong berjalan dengan baik.

14. Quality Assurance Senior Officer

Divisi ini bertanggung jawab dalam permasalahan menyangkut ISO dan menjaga serta meningkatkan kualitas yang dimiliki BINUS School Serpong.

(5)

3.2 Analisis Sistem Parkir yang Berjalan

Analisis Sistem Parkir BINUS School Serpong yang berjalan dibagi menjadi 4 prosedur, yaitu, proses masuk parkir dengan mobil, keluar parkir dengan mobil, masuk parkir dengan motor, dan keluar parkir dengan motor. Berikut ini analisis dari setiap prosedur pada sistem parkir BINUS School Serpong:

3.2.1 Proses Masuk Parkir Serpong dengan Menggunakan Mobil

Proses bisnis masuk parkir dengan menggunakan mobil dimulai ketika terdapat penggguna yang menggunakan mobil akan menggunakan lahan parkir BINUS di dalam area parkir Pos 2. Berikut ini adalah beberapa tahap proses yang terjadi :

1. Pengguna datang ke BINUS School Serpong

2. Jika pengguna tidak memiliki kartu pass, maka hanya dapat parkir di area pos 1 3. Jika pengguna hendak memakai fasilitas di area parkir pos 2, pengguna harus

memiliki kartu pass yang akan di verifikasikan oleh protekom pada saat pengguna masuk.

(6)

Berikut adalah Diagram Aliran Dokumen (DAD) untuk proses masuk parkir serpong menggunakan mobil

(7)

3.2.2 Proses Keluar Parkir Serpong dengan Menggunakan Mobil

Proses bisnis dimulai ketika pengguna hendak keluar dari area parkir serpong. Tahap proses yang terjadi pada proses ini hanya keluarnya pengguna yang memakai mobil dari area parkir serpong.

DAD dari proses keluar parkir serpong dengan menggunakan mobil :

Gambar 3.3 DAD Prosedur keluar parkir menggunakan mobil

3.2.3 Proses Masuk Parkir Serpong dengan Menggunakan Motor

Proses parkir dengan motor dimulai ketika terdapat pengguna yang menggunakan motor datang ke area parkir BINUS School Serpong, beberapa tahap proses yang terjadi :

1. Pengguna yang memakai motor datang ke area parkir BINUS School Serpong

2. Pengguna ditanya apakah memiliki kartu pass / staff, jika pengguna memiliki kartu pass / staff maka akan diberikan kartu tanda terima dan parkir di pos 1. Jika pengguna tidak memiliki kartu pass / staff maka akan ditanya keperluannya

(8)

3. Jika pengguna tidak memiliki keperluan maka akan diminta keluar dari area parkir, jika mempunyai keperluan maka data dan keperluan pengguna dicatat dan diberikan kartu tanda parkir.

Berikut merupakan DAD masuk parkir dengan menggunakan motor :

(9)

3.2.4 Proses Keluar Parkir Serpong dengan Menggunakan Motor

Proses keluar parkir dimulai ketika terdapat pengguna yang telah memarkirkan motornya hendak keluar dari area parkir BINUS School Serpong. Beberapa Tahap yang terjadi dalam proses ini adalah :

1. Pengguna datang mengambil motor dan mengembalikan tanda parkir dan keluar dari BINUS School Serpong

2. Jika tanda parkir hilang maka STNK akan diminta untuk di cek , jika pengguna dapat menunjukkan STNK dan STNK pengguna valid, maka pengguna dapat keluar dari area BINUS School Serpong

3. Jika pengguna tidak dapat menunjukkan STNK atau dapat menunjukkan STNK tetapi tidak valid, maka motor pengguna akan ditahan dan pengguna keluar dari area parkir tanpa kendaraannya.

(10)

Berikut adalah DAD untuk proses keluar parkir dengan menggunakan motor :

(11)

Tabel 3.1 Permasalahan pada proses bisnis sistem parkir yang berjalan

No. Nama Proses Masalah

Sulitnya untuk memverifikasikan kartu pass karena di letakkan di tempat yang berbeda – beda di setiap mobil pengguna

1. Proses mobil masuk parkir BINUS School Serpong

Kartu pass dapat dipalsukan ketika pengguna telah mengetahui desain kartu pass

Kemungkinan terjadinya pencurian mobil karena pada proses keluar tidak divalidasi

2. Proses mobil keluar parkir BINUS School Serpong

Tidak ada datanya yang dicatat pada saat mobil keluar sehingga menyulitkan maintenance dan evaluasi sistem parkir

3 Proses motor masuk parkir BINUS School Serpong

-

4 Proses motor keluar parkir BINUS School Serpong

-

3.2.5 Analisis Wawancara dengan BINUS School Serpong

Dengan ditemukannya permasalahan pada studi kasus, maka untuk membuktikan masalah – masalah yang di identifikasi tersebut dilakukan wawancara dan observasi. Observasi dan wawancara dilakukan pada hari Jumat, tanggal 16 November 2007, dari pukul 11.00 sampai pukul 13.00, pada area BINUS School Serpong, yang beralamat di Jalan Lengkong Karya – Jelupang No. 58m Lengkong Karya, Serpong, Tangerang. Observasi dan wawancara dilakukan untuk mengetahui masalah – masalah yang terdapat pada sistem parkir berjalan pada saat ini. Berikut adalah wawancara yang dilakukan :

(12)

Tabel 3.2 Draft Wawancara 1

Nama : Andriansyah

Jabatan : Protekom Pos 1 Tanggal Wawancara : 16 November 2007 Jam Wawancara : 11.00

Tempat : BINUS School Serpong Daftar Pertanyaan :

1. Bagaimana jika kartu tanda parkir hilang?

2. Apakah anda merasakan kesulitan pada Sistem parkir yang sekarang berjalan? Tabel 3.3 Draft Wawancara 2

Nama : Ade Ramadana

Jabatan : Protekom Pos2 Tanggal Wawancara : 16 November 2007 Jam Wawancara : 12.50

Tempat : BINUS School Serpong Pertanyaan :

1. Apakah anda kesulitan dalam memverifikasi kartu pass?

2. Apakah terdapat kesulitan lain pada Sistem parkir yang sekarang berjalan?

Tabel 3.4 Draft Wawancara 3

Nama : Aries Purnama

Jabatan : Guru sosial SMP dan SMA BINUS School Serpong Tanggal Wawancara : 16 November 2007

Jam Wawancara : 12.00

Tempat : BINUS School Serpong Daftar Pertanyaan :

1. Apakah anda merasa repot dengan tanda parkir dan penggunaan kartu pass yang digunakan sekarang?

2. Apakah jika menggunakan kartu staff anda sebagai tanda parkir anda akan merasa lebih nyaman dan efektif ?

(13)

Berikut merupakan evaluasi hasil wawancara yang dilakukan pada sistem BINUS School Serpong :

Tabel 3.5 Tabel Evaluasi Wawancara No. Permasalahan

Yang Muncul

Target Pengguna Evaluasi Dari :

1. Sulitnya untuk memverifikasi

kartu pass

Protekom Draft wawancara 2 : pertanyaan nomor 1.

Apakah anda kesulitan dalam memverifikasi kartu pass?

2. Kartu pass dapat dipalsukan ketika pengguna telah mengetahui

desain kartu pass

Protekom Draft wawancara 2 : pertanyaan nomor 1 dan 2.

Apakah anda kesulitan dalam memverifikasi kartu pass?

Apakah terdapat kesulitan lain pada Sistem parkir yang sekarang berjalan?

Dari wawancara yang dilakukan pada tanggal 16 November 2007 di BINUS School Serpong dihasilkan beberapa kesimpulan :

1. Sulitnya untuk memverifikasi kartu pass

Kartu pass dapat diletakkan pada bagian mana saja dalam mobil, sehingga terjadinya kesulitan pada protekom pada saat memeriksa kartu pass yang ada. 2. Kartu pass kemungkinan dipalsukan

Kartu pass pada saat di verifikasi hanya dilihat dari luar mobil oleh protekom dan tidak diperiksa secara detail, kemudian karena sederhananya desain kartu pass menyebabkan pengguna dapat memalsukan kartu pass dengan mencetak sendiri kartu pass untuk masuk ke area parkir BINUS School Serpong.

(14)

3.2.6 Identifikasi Masalah

Dari hasil wawancara dan observasi yang dilakukan pada sistem parkir BINUS School Serpong yang sedang berjalan dapat di identifikasikan beberapa permasalahan pada sistem yang berjalan:

1. Kesulitan dalam identifikasi kartu pass

Dari hasil wawancara dan observasi, kartu pass dapat diletakkan oleh pengguna di bagian mana saja dalam mobil, sehingga protekom tidak dapat langsung memverifikasi kartu pass.

2. Kemungkinan dipalsukannya kartu pass

Desain kartu pass yang sederhana dan kesulitan protekom dalam memverifikasi kartu pass menyebabkan kemungkinannya dibuat kartu pass palsu yang dapat digunakan untuk masuk ke area parkir BINUS school serpong.

3. Tidak ada data yang dicatat untuk proses masuk dan keluar mobil

Tidak adanya data yang tercatat pada saat proses mobil masuk dan keluar menyebabkan kurangnya keamanan dan kurangnya data yang diperlukan dalam evaluasi dan pemeliharaan sistem parkir. Dalam segi keamanan harus dicatat siapa yang membawa keluar kendaraan sehingga jika terjadi masalah dapat lebih mudah untuk pelacakan. Untuk evaluasi dan pemeliharaan tidak adanya data pada saat keluar menyebabkan kurangnya data dalam pengambilan keputusan perbaikan sistem parkir yang telah ada karena pengambilan keputusan yang efektif tidak dapat dilihat hanya dari sisi proses masuk parkir saja.

(15)

4. Kemungkinan pencurian mobil

Tidak adanya pengecekan apakah pengguna berhak membawa mobil yang sedang di kendarainya pada saat proses pengguna keluar dari area BINUS School Serpong menyebabkan kemungkinan terjadinya pencurian.

3.3 Analisis Pemecahan Masalah 3.3.1 Solusi yang di identifikasi

Dengan adanya masalah–masalah yang di-identifikasikan pada sistem parkir yang sedang berjalan maka diajukan sistem parkir yang diusulkan untuk memberi solusi pada masalah– masalah yang ada pada sistem parkir berjalan. Antara lain :

1. Pembuatan sistem aplikasi sistem parkir yang terkomputerisasi

Dengan dibuatnya sistem parkir berbasis komputer, memungkinkan pemakaian database sebagai penyimpan data serta penggunaan aplikasi untuk melakukan proses-proses yang ada pada saat masuk dan keluar area parkir BINUS School Serpong dengan lebih efektif.

2. Penggantian kartu pass dan tanda parkir dengan kartu RFID dan tiket

Kartu RFID dapat menyimpan data dan mempunyai kata kunci untuk dapat digunakan yang telah ditentukan oleh developer. Sehingga bagi pengguna internal BINUS School Serpong, kartu RFID dapat digunakan sebagai pengganti kartu pass dan tanda parkir yang diperlukan dalam sistem aplikasi terkomputerisasi. Sedangkan untuk pengguna umum menggunakan media tiket sebagai tanda parkir untuk masuk dan keluar area BINUS School Serpong.

(16)

3.3.2 Model Konseptual

Pada saat ini BINUS School Serpong sudah melakukan implementasi kartu RFID, tetapi baru diimplementasikan pada 3 bagian yaitu: bagian registrasi kartu, bagian peminjaman buku di perpustakaan dan bagian absensi. Dimana kegunaan kartu RFID ini berperan sebagai kartu identitas. Kartu RFID yang digunakan adalah kartu RFID pasif dengan ISO 14443. Dimana kartu RFID yang digunakan bisa dibaca dan di write data ke dalam kartu RFID tersebut. Dengan kartu RFID ini maka dapat dibangun satu sistem pengidentifikasian lagi untuk sistem parkir. Sedangkan tiket merupakan media cetak dari bahan kertas yang dicetak barcode tipe linear kode 39 untuk menyimpan nilai yang dibutuhkan dalam proses parkir.

Sistem parkir yang akan dibangun akan dibagi menjadi 2 bagian, yaitu front-end dan back end. Bagian front-end akan mengatur semua proses yang dibutuhkan dalam proses masuk dan keluar parkir di BINUS School Serpong oleh pengguna dan operator, sementara bagian back-end akan mengatur hak akses aplikasi, pembuatan laporan dan proses-proses yang akan dilakukan oleh administrator dan operator sistem parkir. Dengan penggunaan sistem ini, beberapa masalah dalam sistem parkir yang sedang berjalan dapat teratasi.

Aplikasi sistem parkir pada bagian front-end berfungsi atau digunakan pada saat semua sistem berjalan sesuai dengan yang diharapkan.Yang dimaksud dengan sistem berjalan sesuai dengan yang diharapkan adalah proses masuk dan keluar parkir berjalan tanpa ada nya kesalahan, baik yang dilakukan oleh pengguna (kehilangan atau rusaknya tiket atau kartu RFID) ataupun operator (kesalahan input data) . Dengan digantinya tanda parkir motor dan kartu pass dengan kartu RFID dan tiket yang memiliki nilai barcode, pengidentifikasian akan dilakukan oleh sistem. Untuk penggunaan dengan

(17)

kartu RFID, sistem akan memverifikasi kartu RFID sah atau tidak melalui kata kunci yang telah ditentukan oleh pihak developer dan data identitas pengguna yang tersimpan pada kartu RFID tersebut, hal ini menyebabkan kemungkinan pemalsuan kartu RFID akan menjadi sangat kecil.

Setelah sistem memverifikasi kartu RFID atau tiket yang digunakan oleh pengguna, sistem akan melakukan proses pengambilan gambar kendaraan dan memasukkan data – data seperti tanggal, jam, identitas pengguna, foto tampak depan kendaraan, nomor parkir ke dalam database. Data – data tersebut akan digunakan sebagai pembanding pada saat pengguna melakukan proses keluar parkir, sehingga dapat menentukan apakah pengguna tersebut berhak atau tidak berhak keluar dari area BINUS School Serpong dengan kendaraan tersebut. Setelah di tentukan pengguna berhak keluar dan kendaraan pengguna keluar dari area parkir BINUS School Serpong, maka proses dari bagian front-end selesai.

Aplikasi sistem parkir bagian back-end berfungsi untuk mengatur hak akses operator, pembuatan laporan, menentukan aturan dan menangani kasus parkir jika terjadi sistem tidak berjalan tidak sesuai yang diharapkan. Yang dimaksud dengan sistem yang tidak berjalan tidak sesuai harapan adalah jika terjadi kesalahan oleh pengguna atapun operator. Contoh dari kesalahan operator adalah kesalahan pada saat input data pengguna, dan contoh dari kesalahan pengguna adalah hilangnya tiket atau kartu RFID.

(18)

(19)

Tabel 3.6 Rangkuman Solusi Untuk permasalahan Studi Kasus

No. Permasalahan Yang

Diidentifikasi

Solusi Untuk Permasalahan Verifikasi Dengan Landasan Teori

1 Sulitnya untuk memverifikasi kartu pass

Penggantian kartu pass dan tanda parkir dengan kartu RFID dan tiket

Penggantian tanda pass dengan kartu RFID dan tiket akan memudahkan proses verifikasi kartu pass yang dilakukan oleh aplikasi.

2 Kartu pass dapat

dipalsukan ketika pengguna telah mengetahui desain kartu pass

Penggantian kartu pass dan tanda parkir dengan kartu RFID dan tiket

Kartu RFID dapat menyim-pan identitas pengguna dan kata kunci yang membatasi pemakaiannya dalam ruang lingkup tertentu sehingga tidak mudah dipalsukan. Sedangkan tiket yang terdapat

PassiveRFIDtags dapat memiliki non-volatile EEPROM didalamnya yang berfungsi untuk menyimpan data, sehingga respon yang dipancarkan oleh

passive RFIDtag bisa tidak hanya berupa angka identifikasi

Tiket berbahan kertas dan berwarna putih merupakan media cetak dan dapat

dicetak barcode. Barcode memiliki kemampuan menyembunyikan informasi

(20)

No. Permasalahan Yang Diidentifikasi

Solusi Untuk Permasalahan Verifikasi Dengan Landasan Teori

barcode dapat menyimpan nilai tersendiri juga

3 Mungkinnya

pencurian mobil karena tidak adanya pengecekan pada saat mobil keluar

Pembuatan sistem aplikasi sistem parkir yang

terkomputerisasi

Dengan sistem aplikasi yang terkomputerisasi yang diusulkan akan dilakukan verifikasi pada saat kendaraan masuk atau keluar dari area parkir

4 Tidak adanya data

mengenai mobil yang masuk dan keluar

Pembuatan sistem aplikasi sistem parkir yang

terkomputerisasi

Pada saat kartu RFID atau tiket divalidasi, secara otomatis komputer akan mendapatkan data yang dibutuhkan oleh administrator

Sistem informasi menurut O’Brien (2003, p7) merupakan kombinasi dari

manusia, hardware, software, jaringan komunikasi dan sumber daya data yang

terorganisir yang mengumpulkan, mengubah dan menyebarkan informasi dalam sebuah organisasi

(21)

3.3.3 Analisis Tujuan dari Solusi yang Akan Dibangun

Tujuan dari solusi – solusi yang akan dibangun antara lain : 1. Meningkatkan Keamanan fasilitas parkir

Faktor keamanan merupakan bagian terpenting dari sebuah sistem perpakiran. Dengan dibuatnya pos parkir pada proses masuk dan proses keluar dan adanya kartu RFID dan tiket sebagai pengganti kartu pass dan tanda parkir hal tersebut dapat dicapai. Pos parkir berguna sebagai tempat dimana pengguna akan di verifikasi haknya untuk menggunakan lahan parkir dan kartu RFID dan tiket sebagai media transaksi sistem parkir.

2. Mendapatkan data dan membuat laporan dari proses parkir

Dengan membuat sistem berbasis komputer maka data yang di dapat dari proses parkir baik proses parkir masuk atau keluar dapat tercatat dengan mudah dan telah terstruktur dalam database. Data dalam database tersebut akan digunakan dalam pembuatan laporan yang dapat digunakan untuk evaluasi sistem perpakiran dan membantu dalam perkembangan sistem parkir selanjutnya.

3.4 Perancangan Solusi

(22)

Tabel 3.7 Proses Bisnis Untuk Mewujudkan Tujuan dari Solusi

No. Tujuan Solusi Proses-Proses Bisnis Yang

Akan Digunakan Untuk Mewujudkan Tujuan

Fungsi/Menu dan Informasi Yang Akan Terdapat Dalam Proses Bisnis Tersebut

Mengganti tanda parkir yang sedang dipakai dengan kartu identitas (kartu binusian/staff) yang dilengkapi RFID

Menu tidak berada pada ruang lingkup skripsi kami, menu atau fungsi yang diperlukan terdapat pada aplikasi card management

1 Membuat tanda

parkir yang lebih efisien dan praktis

Mengganti tanda parkir yang sedang dipakai dengan Tiket untuk pengguna umum (yang tidak memiliki kartu RFID)

Fungsi mencetak barcode

Pada saat pengguna yang tidak memiliki kartu RFID datang ke area BiNus, ia akan menekan tombol sebagai pemicu memerintahkan aplikasi untuk mengenerate kode random dan di ubah menjadi barcode lalu dicetak.

Proses Masuk Parkir dengan Kartu RFID

Menu Check In

1.Fungsi Verifikasi validitas kartu RFID 2.Fungsi Mengcapture foto kendaraan Proses Keluar Parkir

dengan kartu RFID

Menu Check Out

1.Verifikasi Id kartu RFID 2.Verifikasi foto kendaraan Proses Masuk Parkir

dengan Tiket

Menu Check In

Pengguna menekan tombol untuk mencetak barcode Webcam menangkap foto kendaraan pengguna 2 Memudahkan

petugas parkir melakukan

verifikasi tanda parkir

Proses Keluar Parkir dengan Tiket

Menu Check Out

Verifikasi barcode

(23)

No. Tujuan Solusi Proses-Proses Bisnis Yang Akan Digunakan Untuk

Mewujudkan Tujuan

Fungsi/Menu dan Informasi Yang Akan Terdapat Dalam Proses Bisnis Tersebut

Proses Masuk Parkir dengan Kartu RFID

Menu Check In

Entry data pengguna kartu RFID pada saat masuk meliputi tanggal, jam, cardId, TransactionId, Foto kendaraan pengguna.

Proses Keluar Parkir dengan kartu RFID

Menu Check Out

Entry data pengguna kartu RFID pada saat keluar meliputi tanggal keluar, jam keluar , Foto kendaraan pengguna berdasarkan Transaction Id dan CardId.

Proses Masuk Parkir dengan Tiket

Menu Check In

Entry data pengguna umum pada saat masuk dengan menekan tombol tiket meliputi tanggal, jam, TransactionId, Foto kendaraan pengguna.

3 Memudahkan pengumpulan dan penyimpanan data pengguna sistem parkir

Proses Keluar Parkir dengan Tiket

Menu Check Out

Entry data pengguna umum pada saat masuk dengan menekan tombol barcode meliputi tanggal keluar, jam keluar, Foto kendaraan pengguna berdasarkan Transaction Id .

(24)

3.4.2 Desain Front End

Gambar 3.7 Use Case diagram proses parkir Front-end

Proses bisnis yang di ajukan pada sistem parkir pada bagian front-end yang dibangun ditunjukkan melalui gambar Use Case Diagram di atas, yang memperlihatkan. Masing – masing proses bisnis memiliki aktor dan flow of event masing – masing. Berikut ini merupakan penjelasan dari proses bisnis yang terdapat pada sistem parkir bagian front- end.

(25)

3.4.2.1Pengguna Masuk dengan Kartu RFID

(26)

Gambar 3.9 Activity Diagram untuk use case Pengguna Masuk Dengan Kartu RFID

(27)

Flow Of Event Proses Masuk dengan Kartu RFID Actor : Pengguna yang memiliki RFID ( pengguna internal ), webcam

Precondition : Pengguna yang memiliki kartu RFID ingin masuk ke area parkir BINUS School

Flow Of Events Basic Path :

1. Use Case mulai ketika pengguna datang untuk mengunakan jasa layanan parkir 2. Pengguna meng-scan kartu RFID

3. Nomor kartu RFID akan divalidasikan oleh system 4. Webcam mengambil foto mobil pengguna

5. Portal parkir akan terbuka

6. Pengguna masuk ke pelataran parkir 7. Portal parkir tertutup, use case berakhir Alternative Path :

Alternative 1 : Kartu RFID tidak valid

1. Pada langkah ke 3, jika validasi nomor kartu salah. 2. Portal akan tetap tertutup

3. Sistem akan memberitahu petugas keamanan untuk datang ke tempat kejadian , use case berakhir

(28)

3.4.2.2Pengguna Keluar dengan Kartu RFID

(29)

Gambar 3.11 Activity Diagram untuk use case Pengguna Keluar Dengan Kartu RFID

(30)

Flow Of Event Proses Keluar dengan Kartu RFID

Actor : Pengguna yang memiliki kartu RFID , Operator / admin, webcam, protekom Preconditions: Pengguna yang memiliki kartu RFID akan keluar dari area parkir BINUS School

1. Use Case mulai ketika pengguna akan keluar dari area parkir BINUS School 2. Pengguna meng-scan kartu RFID

3. Sistem akan memvalidasikan kartu RFID

4. Foto mobil akan muncul dalam layar komputer operator 5. Foto mobil akan dicocokkan oleh operator

6. Foto mobil pengguna akan di capture kembali untuk kepentingan dokumentasi 7. Operator akan membuka portal parkir

8. Pengguna keluar dari area parkir

9. Portal parkir tertutup, Use case berakhir

Alternative Path :

Alternative 1 : Validasi kartu RFID tidak valid

1. Pada langkah ke 3, jika validasi nomor kartu salah. 2. Portal akan tetap tertutup

3. Sistem akan memberitahu petugas keamanan untuk datang ke tempat kejadian 4. Pengguna ditangani oleh petugas keamanan, use case berakhir

Alternative 2 : Foto mobil tidak cocok

1. Pada langkah ke 5, jika salah satu foto mobil atau foto pengguna tidak cocok 2. Portal parkir akan tetap tertutup

3. Sistem akan memberitahu petugas keamanan untuk datang ke tempat kejadian 4. Pengguna ditangani oleh petugas keamanan, use case berakhir

(31)

1. Alternative ini mulai dari langkah nomor 2 ketika pengguna tidak dapat menunjukan kartunya

2. Pengguna melapor kepada operator bahwa kartu RFID hilang

3. Operator akan memberitahu petugas keamanan untuk datang ke tempat kejadian 4. Pengguna akan diminta kembali ke area parkir lalu mengurus kehilangan

kartunya ke management card

5. Pengguna akan mendapat kartu baru, kembali ke langkah 2 dalam basic path Alternative 4 : Jika pengguna menolak untuk mengurus kehilangan kartunya

1. Alternative 4 mulai dari langkah 4 pada alternative 3, jika pengguna menolak mengurus pembuatan kartu RFID pada saat itu

2. Pengguna diminta menunjukkan dokumen yang dibutuhkan oleh petugas 3. Dokumen pengguna dicek oleh petugas

4. Petugas memberitahu operator tentang data dari dokumen 5. Foto mobil ditangkap lagi oleh webcam

6. Operator menjalankan aplikasi back-end

7. Operator memasukkan data pada aplikasi back-end dan membuka portal parkir 8. Portal parkir terbuka

9. Pengguna keluar

10.Portal tertutup, use case berakhir

Alternative 5 : Pengguna tidak dapat menunjukkan dokumen yang diperlukan

1. Alternative 5 mulai pada langkah ke 2 dari alternative 4, jika pengguna tidak dapat menunjukkan dokumen yang diperlukan.

2. Pengguna diminta kembali ke area parkir

3. Pengguna ditangani oleh petugas, Use case berakhir Alternative 6 : Dokumen pengguna salah

1. Alternative 6 mulai pada langkah 3 dari alternative 4, jika dokumen milik pengguna salah

3. Pengguna ditangani oleh petugas, Use case berakhir Post Condition : Pengguna keluar dari area perpakiran

(32)

3.4.2.3Pengguna Masuk Tanpa Kartu (Masuk dengan Tiket)

(33)

Gambar 3.13 Activity Diagram untuk use case Pengguna Masuk Dengan Tiket

(34)

Flow Of Event Proses Masuk dengan Tiket Actor : Pengguna tanpa kartu RFID (Tamu) , webcam

Preconditions : Pengguna yang tidak memiliki kartu RFID ingin masuk ke pelataran parkir BINUS School

Flow of Events Basic Path :

1. Use Case Mulai ketika pengguna datang untuk mengunakan jasa layanan parkir 2. Pengguna menekan tombol di mesin pencetak tiket

3. Sistem memberitahukan agar tidak mencetak tiket lagi sampai proses masuk parkir selesai

4. Tiket keluar dari mesin

5. Webcam mengambil foto mobil pengguna 6. Pengguna mengambil tiket.

7. Portal parkir terbuka

8. Pengguna masuk ke pelataran parkir 9. Portal Parkir tertutup, use case berakhir Alternative path :

Alternative 1 : Tiket habis

1. Alternative ini mulai dalam langkah ke 4 ketika tiket habis 2. Pengguna memanggil operator

3. Operator mengisi kembali kertas pada mesin printer

4. Tiket sudah dapat keluar, kembali ke langkah 6 dalam basic path Alternative 2 : Tiket tidak keluar tidak dapat keluar

1. Alternative ini muncul pada langkah ke 4 jika tiket masih ada tetapi tidak dapat keluar ( terjadi kerusakan pada mesin )

2. Pengguna memanggil operator

3. Operator memanggil pihak maintenance 4. Pihak maintenance membetulkan mesin

5. Tiket sudah dapat keluar, kembali ke langkah 6 dalam basic path

(35)

3.4.2.4Pengguna Keluar Tanpa Kartu (Keluar dengan Tiket )

(36)

Gambar 3.15 Activity Diagram untuk use case Pengguna Keluar Dengan Tiket

(37)

Flow Of Event Proses Keluar dengan Tiket Actor : Operator / Admin, pengguna dengan tiket, webcam, Protekom

Preconditions : Pengguna parkir yang memiliki tiket ingin keluar dari area parkir BINUS School

Flow Of Events Basic Path :

1. Use Case mulai ketika pengguna parkir akan keluar dari area perpakiran BINUS School

2. Pengguna parkir akan mengembalikan tiket yang ia terima pada saat masuk ke pelataran parkir ke operator parkir

3. Operator parkir akan men-scan tiket tersebut 4. Sistem akan memvalidasikan tiket.

5. Foto mobil pengguna akan muncul dalam layar komputer operator 6. Foto divalidasikan oleh operator

7. Foto kendaraan pengguna akan ditangkap kembali oleh webcam untuk kepentingan dokumentasi

8. Operator akan membuka portal parkir 9. Pengguna keluar dari area parkir

10.Portal parkir tertutup, Use case berakhir

Alternative path :

Alternative 1 : Validasi tiket salah

1. Alternative ini mulai dari pada langkah ke 3 basic path, jika validasi nomor tiket salah.

2. Portal akan tetap tertutup

3. Sistem akan memberitahu petugas keamanan untuk datang ke pos parkir keluar 4. Pengguna ditangani oleh petugas keamanan, use case berakhir

Alternative 2 : Salah satu dari foto pengguna atau foto mobil tidak cocok

1. Alternative ini mulai dari langkah nomor 6 ketika pencocokan foto tidak benar 2. Portal parkir akan tetap tertutup

(38)

3. Sistem akan memberitahu satuan keamanan untuk datang ke tempat kejadian 4. Pengguna ditangani oleh petugas, Use case berakhir

Alternative 3 : Tiket hilang atau rusak

1. Alternative 3 mulai dari langkah nomor 2 dalam basic path ketika pengguna tidak dapat menunjukan tiketnya atau tiket rusak ( tidak dapat discan oleh alat) 2. Pengguna diminta menunjukkan dokumen yang dibutuhkan oleh petugas 3. Dokumen pengguna dicek oleh petugas

4. Petugas memberitahu operator tentang data dari dokumen 5. Foto mobil ditangkap lagi oleh webcam

6. Operator menjalankan aplikasi back end

7. Operator memasukkan data pada aplikasi back-end dan membuka portal parkir 8. Portal parkir terbuka

9. Pengguna keluar

10.Portal tertutup, use case berakhir

Alternative 4 : Pengguna tidak dapat menunjukkan Dokumen yang diperlukan

1. alternative 4 mulai pada langkah ke 3 dari alternative 3, jika pengguna tidak dapat menunjukkan Dokumen yang diperlukan

3. Pengguna ditangani oleh petugas, Use case berakhir Alternative 5: Dokumen tidak sah

1. Alternative 5 mulai pada langkah 4 dari alternative 3, jika Dokumen milik pengguna tidak sah

3. Pengguna ditangani oleh petugas,Use case berakhir

(39)

3.4.3 Desain Back End

Gambar 3.16 Use Case diagram proses parkir back end

Proses bisnis yang di ajukan pada sistem parkir pada bagian back-end yang dibangun ditunjukkan melalui gambar Use Case Diagram di atas, yang memperlihatkan. Masing – masing proses bisnis memiliki aktor dan flow of event masing – masing. Berikut ini merupakan penjelasan dari proses bisnis yang terdapat pada sistem parkir bagian back-end.

(40)

3.4.3.1Proses Parkir Melihat dan Merubah Data Parkir Operator / Admin Finish Start Operator mencari data yang dibutuhkan Operator memilih kriteria pencarian Data Parkir Operator merubah data parkir

(41)

Gambar 3.18 Activity Diagram untuk

(42)

Flow Of Event Proses melihat dan merubah data parkir Actor : Operator / Admin

Preconditions : Ketika operator ingin melihat data parkir dan mengubah data parkir. Flows Of Events :

Basic Path :

1. Use Case mulai ketika operator ingin melihat data parkir atau mengubah data parkir.

2. Operator Login ke sistem Parkir Back-End.

3. Operator kemudian akan memilih kriteria pencarian.

4. Operator memasukkan nilai sesuai dengan kriteria pencarian yang dipilih. 5. Operator mencari data parkir yang diinginkan.

6. Bila data yang diinginkan sudah ditemukan, operator dapat menekan tombol detail

7. Tombol detail akan memicu agar aplikasi menampilkan detail dari data yang dipilih

8. Bila operator ingin mengubah data, maka operator dapat menekan tombol Edit 9. Tombol Edit akan memicu agar aplikasi menampilkan detail data yang dipilih

dengan kontrol yang dapat diubah nilainya.

10.Operator akan menekan tombol Save untuk melakukan transaksi penyimpanan data ke database.

(43)

Alternative 1: Operator kembali ke halaman pemilihan kriteria list data parkir

1. Pada langkah ke 4 basic path, jika operator salah memilih kriteria atau hendak memilih kriteria lain

2. Operator kembali ke langkah ke 3 basic path, Halaman pemilihan kriteria.Use Case berakhir.

Alternative 2 : Operator kembali ke halaman pemilihan kriteria dari halaman detail data parkir

1. Pada langkah 7 basic path, jika operator hendak kembali memilih kriteria

2. Operator kembali ke langkah ke 3 basic path, Halaman pemilihan kriteria.Use Case Berakhir.

Alternative 3 : Operator membatalkan edit data

1. Pada Langkah 9 basic path, jika pengguna membatalkan proses edit pada saat penggantian nilai pada form.

2. Operator kembali ke langkah 7 pada basic path, Halaman detail data parkir. Use Case berakhir.

(44)

3.4.3.2Proses Konfigurasi Aturan Proses Parkir Keluar Tanpa Kartu RFID dan Tiket

Gambar 3.19 DAD untuk proses

(45)

Menentukan tipe parkir

Menentukan Bukti Parkir

Menentukan bukti parkir yang dibutuhkan pada tipe parkir tertentu

Gambar 3.20 Activity Diagram untuk use case Proses Konfigurasi Aturan Parkir

Flow Of Event Proses Konfigurasi Aturan Parkir Actor : operator / admin

Precondition : Operator hendak menentukan tipe parkir. Flow Of Events

Basic Path :

1. Use Case dimulai ketika operator hendak melakukan proses manajemen proses aturan parkir

2. Operator menentukan tipe parkir 3. Operator menentukan bukti

4. Operator menentukan bukti bukti yang dibutuhkan sesuai tipe parkir, Use Case Berakhir.

(46)

Operator memilih Menu Add/Edit/Delete Type Park

Menampilkan daftar tipe parkir

Rubah

mengubah tipe parkir

Simpan

Tambah

menambah tipe parkir

Simpan

Verifikasi Data Kembali

Hapus

mengurangi tipe parkir

Verifikasi Data

Manipulasi Database permanen Manipulasi Database sementara

Membatalkan semua manipulasi database

(47)

Flow Of Event Proses menentukan tipe parkir Actor : operator / admin

Precondition : Operator hendak melakukan manajemen pada tipe parkir. Flow Of Events

Basic Path :

1. Use Case dimulai ketika operator hendak melakukan proses manajemen pada tipe parkir

2. Operator memilih menu manajemen tipe parkir pada aplikasi 3. Operator melihat daftar tipe parkir yang telah ada

4. Operator melakukan manajamenen tipe parkir

5. Operator melakukan commit pada transaksi dan membuat perubahan yang dilakukan menjadi permanen dalam database, Use Case Berakhir.

Alternative 1: Manajemen tipe parkir : Add (penambahan)

1. Pada langkah 4, manajemen tipe parkir yang dilakukan manajemen merupakan penambahan tipe parkir.

2. Operator masuk ke dalam halaman form pengisian data tipe parkir dan mengisinya.

3. Operator menekan tombol save untuk menyimpan tipe data baru 4. Tipe data baru akan diverifikasi

5. Data sesuai dengan persyaratan verifikasi, manipulasi pada database dilakukan. 6. Operator melakukan commit pada transaksi dan melakukan manipulasi database

(48)

Alternative 2 : Operator membatalkan proses Add

1. Pada alternative 1 langkah 2, operator membatalkan pengisian form dan menekan tombol back

2. Operator kembali ke halaman daftar tipe parkir (basic path, langkah 3),, Use Case berakhir.

Alternative 3: verifikasi proses data add gagal

1. Pada alternative 1 langkah 5, jika data tipe parkir baru tidak memenuhi syarat verifikasi

2. Operator kembali ke form pengisian tipe data baru dan diberi tahu bagian yang tidak memenuhi syarat verifikasi (alternative 1, langkah 2), Use Case berakhir. Alternative 4: Manajemen tipe parkir : Delete (pengurangan)

1. Pada basic path langkah 4, manajemen yang dilakukan operator merupakan pengurangan tipe parkir

2. Operator memilih tipe parkir yang akan dihapus 3. Operator menghapus tipe parkir dari database

4. Operator melakukan commit pada transaksi dan memastikan semua perubahan pada database dalam transaksi tersebut permanen, Use Case berakhir

Alternative 5: Operator membatalkan proses delete

1. Pada alternative 4 langkah 2, operator membatalkan proses delete.

2. Operator kembali ke halaman daftar tipe parkir (basic path, langkah 3), Use Case berakhir.

(49)

Alternative 6: Manajemen tipe parkir : Edit (perubaha)

1. Pada basic path langkah 4, manajemen yang dilakukan operator merupakan perubahan tipe parkir

2. Operator memilih tipe parkir yang akan di ubah 3. Operator merubah nama tipe parkir

4. Operator menekan tombol save, untuk menyimpan data pada database

5. Data yang akan dirubah sesuai dengan verifikasi, manipulasi pada database dilakukan.

6. Operator melakukan commit pada transaksi dan memastikan semua perubahan pada database dalam transaksi tersebut permanen, use case berakhir

Alternative 7: Operator membatalkan proses edit

1. Pada alternative 6 langkah 2, operator membatalkan proses edit

Alternative 8: Verifikasi data pada proses edit tidak sesuai dengan syarat

1. Pada basic path langkah 4, alternative 6 langkah 5, data yang di input pada perubahan tipe nama parkir tidak sesuai dengan syarat verifikasi

2. Operator kembali ke halaman input nama parkir (Alternative 6 ,langkah 3), Use Case berakhir.

(50)

Alternative 9: Operator melakukan kegiatan manajemen kembali setelah selesai melakukan suatu aktivitas manajemen

1. Pada basic path langkah 4, alternative 1 langkah 6, alternative 4 langkah 4, alternative 6 langkah 6, Operator melakukan kegiatan manajemen kembali. 2. Operator kembali ke halaman daftar tipe parkir (basic path,langkah 3), Use Case

berakhir.

Alternative 10 : Operator membatalkan transaksi perubahan

1. Pada alternative 1 langkah 6, alternative 4 langkah 4, alternative 6 langkah 6, Operator membatalkan transaksi perubahan

2. Perubahan data pada database di batalkan dan keadaan database dikembalikan pada keadaan sebelum dirubah.

(51)

Operator Memilih Menu Add/Edit Type Proof

Menampilkan daftar bukti

Rubah

Merubah tipe bukti

Simpan

Tambah

Mengisi form bukti parkir baru

Simpan

Verifikasi Data Back

Manipulasi database sementara

Manipulasi Database permanen

Membatalkan semua manipulasi database

(52)

Flow Of Event Proses menentukan bukti parkir Actor : operator / admin

Precondition : Operator hendak menentukan bukti parkir. Flow Of Events

Basic Path :

1. Use Case dimulai ketika operator hendak melakukan proses manajemen bukti parkir

2. Operator memilih menu untuk manajemen bukti parkir 3. Operator melihat daftar bukti parkir yang telah terdaftar 4. Operator melakukan manajemen bukti parkir

Alternative Path:

Alternative 1: Manajemen bukti parkir : Edit (perubahan)

1. Pada langkah 4 Basic path, manajemen bukti parkir yang dilakukan oleh operator adalah proses perubahan bukti parkir

2. Operator merubah tipe bukti

3. Operator menekan tombol save untuk menyimpan data pada database

4. Operator melakukan commit pada transaksi dan membuat perubahan yang dilakukan menjadi permanen dalam database, Use Case Berakhir

(53)

1. Pada alternative 1 langkah 2, operator membatalkan proses edit dan menekan tombol back

2. Operator kembali ke halaman daftar bukti parkir yang telah terdaftar (basic path, langkah 3), Use Case berakhir.

Alternative 3: Manajemen bukti parkir : Add (penambahan)

1. Pada langkah 4 Basic path, manajemen bukti parkir yang dilakukan oleh operator adalah penambahan bukti parkir

2. Operator masuk ke halaman form pengisian bukti baru, dan mengisinya 3. Operator menekan tombol save untuk menyimpan data pada database 4. Data bukti baru sesuai dengan syarat verifikasi

5. Memanipulasi database

Alternative 4 : Operator membatalkan proses Add

1. Pada alternative 3 langkah 2, Operator membatalkan proses penambahan bukti baru

2. Operator kembali ke halaman daftar bukti (basic path langkah 3), Use Case berakhir

Alternative 5: Data bukti baru tidak sesuai syarat verifikasi

1. Pada alternative 3 langkah 4, data bukti baru tidak sesuai dengan syarat verifikasi

2. Operator kembali ke halaman form input bukti baru dan terdapat keterangan syarat yang tidak terpenuh (alternative 2 langkah 2), Use Case berakhir

(54)

Alternative 6 : Operator melakukan kegiatan manajemen kembali setelah selesai melakukan suatu aktivitas manajemen

1. Pada basic path langkah 5, alternative 1 langkah 4 atau alternative 3 langkah 6, Operator hendak melakukan aktivitas manajemen kembali setelah selesai melakukan suatu aktifitas manajemen

2. Operator kembali ke halaman daftar bukti (basic path langkah 3), Use Case berakhir

Alternative 7 : Operator membatalkan transaksi

1. Pada basic path langkah 5, alternative 1 langkah 4 atau alternative 3 langkah 6, Operator membatalkan transaksi yang telah dilakukan

3. Operator kembali ke halaman daftar bukti (basic path langkah 3), Use Case berakhir

(55)

Operator Memilih Menu Setting Proof Needed When Out

Menunjukkan konfigurasi bukti yang dibutuhkan pada saat keluar parkir

Edit

Merubah bukti yang dibutuhkan untuk setiap tipe parkir

Edit Add

Back Memilih bukti yang akan diubah Memilih bukti yang akan ditambah

Manipulasi database sementara

Mengembalikan keadaan database seperti semula

Simpan

Manipulasi database permanen Delete

Memilih bukti yang akan di hapus

Gambar 3.23 Activity Diagram untuk

(56)

Flow Of Event Proses menentukan bukti parkir yang dipakai pada tipe parkir tertentu

Actor : operator / admin

Precondition : Operator hendak menentukan bukti parkir yang dipakai pada tipe parkir tertentu

1. Use Case dimulai ketika operator hendak melakukan proses manajemen proses aturan parkir

2. Operator memilih menu untuk memanejemen pemakaian bukti parkir pada tipe parkir tertentu

3. Operator melihat daftar bukti parkir yang diperlukan sesuai tipe parkir 4. Operator merubah bukti yang dibutuhkan pada suatu tipe parkir.

5. Operator melakukan commit pada transaksi dan membuat perubahan yang dilakukan menjadi permanen dalam database, Use Case berakhir.

Alternative 1: Merubah bukti yang dibutuhkan pada proses parkir : Add

1. Pada basic path langkah 4, manajemen bukti yang dipakai pada tipe parkir tertentu merupakan penambahan bukti

2. Operator memilih bukti yang akan ditambahkan

3. Operator menekan tombol save untuk memanipulasi database

(57)

Alternative 2: Proses penambahan bukti yang dipakai pada tipe parkir tertentu dibatalkan 1. Pada alternative 1 langkah 2, operator membatalkan proses penambahan bukti

yang diperlukan pada tipe parkir tertentu

2. Operator kembali ke halaman daftar bukti parkir yang diperlukan sesuai tipe parkir (basic path langkah 2), Use Case berakhir.

Alternative 3: Merubah bukti yang dibutuhkan pada proses parkir : Delete

1. Pada basic path langkah 4, manajemen bukti yang dipakai pada tipe parkir tertentu merupakan pengurangan bukti

2. Operator memilih bukti yang akan dikurangi

3. Operator menekan tombol save untuk memanipulasi database

Alternative 4: Proses pengurangan bukti yang dipakai pada tipe parkir tertentu dibatalkan

1. Pada alternative 3 langkah 2, operator membatalkan proses pengurangan bukti yang diperlukan pada tipe parkir tertentu

Alternative 5: Merubah bukti yang dibutuhkan pada proses parkir : Edit

1. Pada basic path langkah 4, manajemen bukti yang dipakai pada tipe parkir tertentu merupakan perubahan bukti

2. Operator memilih bukti yang akan dirubah

(58)

4. Operator melakukan commit pada transaksi dan membuat perubahan yang dilakukan menjadi permanen dalam database, Use Case berakhir.

Alternative 6: Proses perubahan bukti yang dipakai pada tipe parkir tertentu dibatalkan 1. Pada alternative 5 langkah 2, operator membatalkan proses perubahan bukti yang

diperlukan pada tipe parkir tertentu

Alternative 7 : Operator melakukan kegiatan manajemen kembali setelah selesai melakukan suatu aktivitas manajemen

1. Pada basic path langkah 5, alternative 1 langkah 4 atau alternative 3 langkah 4, alternative 5 langkah 4, Operator hendak melakukan aktivitas manajemen kembali setelah selesai melakukan suatu aktifitas manajemen

Alternative 8 : Operator membatalkan transaksi

1. Pada basic path langkah 5, alternative 1 langkah 4 atau alternative 3 langkah 4, alternative 5 langkah 4, Operator membatalkan transaksi yang telah dilakukan

(59)

3.4.3.3Manajemen Operator Operator / Admin Operator menerima permintaan konfigurasi hak akses pengguna aplikasi Operator menambah pengguna Finish Start Operator merubah hak akses pengguna Operator mengurangi pengguna Data Pengguna Operator mendapatkan data pengguna baru Update data pengguna Data pengguna

(60)

Operator Memilih Menu Add/Edit Operator

Menampilkan Daftar operator

Edit

Memilih peran

Simpan

Update Database

Add

Memasukkan data operator baru

Simpan

Memasukkan data ke database Verifikasi database Back

(61)

Flow Of Event Proses manajemen operator Actor : Operator / Admin

Precondition : Pada saat operator melakukan manajemen operator Flow Of Events

Basic Path :

1. Use Case mulai ketika operator hendak melakukan manajemen operator 2. Operator melihat daftar operator yang terdaftar.

3. Operator memilih salah satu operator yang terdaftar. 4. Operator merubah peran operator yang dipilih

5. Operator menekan tombol save untuk menyimpan perubahan yang dilakukan dan menyimpan perubahan tersebut pada database, Use Case berakhir.

Alternative 1 : Operator hendak menambah operator baru

1. Pada langkah ke 2 basic path, jika operator hendak menambah operator baru dengan menekan tombol Add.

2. Operator mengisi form data operator baru

3. Operator melakukan penyimpanan data operator baru dengan menekan tombol save

4. Data yang disimpan oleh operator akan diverifikasi

5. Data yang telah di verifikasi akan tersimpan pada database, Use Case berakhir. Alternative 2 : Operator membatalkan penambahan operator baru

1. Pada alternative 1 langkah 2, operator membatalkan pengisian form dengan menekan tombol back

(62)

2. Operator kembali ke halaman daftar operator (basic path, langkah 2), Use Case berakhir.

Alternative 3 : Data operator baru tidak sesuai dengan persyaratan verifikasi

1. Pada alternative 1 langkah 4, Pada saat data operator baru tidak sesuai dengan persyaratan verifikasi.

2. Operator kembali ke halaman pengisian form operator baru dan terdapat pemberitahuan persyaratan yang tidak dipenuhi oleh operator (Alternative 1, langkah 2), Use Case berakhir.

1. Pada basic path langkah 4, operator membatalkan perubahan peran operator dengan menekan tombol back

2. Operator kembali ke halaman daftar operator (basic path, langkah 2), Use Case berakhir.

(63)

3.4.3.4Pembuatan Laporan

(64)

Memilih kriteria pencarian Operator Memilih Reporting Menu

Operator

Mengisi parameter sesuai kriteria yang dipilih

Search

Menampilkan data yang sesuai dengan kriteria

Mencetak laporan

(65)

Flow Of Event Proses Pembuatan Laporan Actor : operator / admin

Precondition : Operator hendak membuat laporan Flow Of Events

Basic Path :

1. Use Case mulai operator memilih menu pembuatan laporan 2. Operator memilih kriteria pembuatan laporan

3. Operator memasukkan parameter yang dibutuhkan dalam kriteria yang dipilih 4. Operator mendapatkan data yang dicari dalam bentuk laporan.

5. Operator mencetak laporan, Use Case berakhir. Alternative Path :

Alternative 1 : Operator kembali ke halaman kriteria dari halaman input parameter kriteria

1. Pada langkah ke 3, jika operator melakukan kesalahan dalam pemilihan kriteria atau hendak kembali ke halaman pemilihan kriteria pembuatan laporan.

2. Operator kembali ke halaman pemilihan kriteria laporan (basic path, langkah 2), Use Case berakhir.

Alternative 2: Operator kembali ke halaman input parameter kriteria dari halaman laporan

1. Pada langkah 4, Jika Operator membatalkan proses pencetakan laporan, melakukan kesalahan input parameter atau operator tidak mendapat data yang diharapkan dalam laporan.

2. Operator kembali ke halaman input parameter dengan kriteria yang terpilih (basic path, langkah 3), Use Case berakhir.

(66)

3.4.4 Perancangan Struktur Fungsi/Menu

Tabel 3.8 Fungsi/Menu Pengguna No. Fungsi/Menu

Aplikasi

Aktor dan Hak Akses Yang Akan Menggunakan Fungsi/Menu Tersebut

Data Yang Akan Dientri, Proses Yang Akan Dilakukan atau Informasi Yang Akan Dihasilkan oleh Fungsi/Menu

Terhadap Aktor 1. Menu CheckIn

(Tap)

Pengguna

Pengguna menggunakan kartu pengenal yang telah dilengkapi RFID dengan cara mentap/mendekatkan kartu tersebut pada RFID Reader. Atau menekan tombol tombol untuk mencetak tiket jika tidak memiliki kartu RFID.

Membuat data baru Insert data

a.Data yang di-entry : Tanggal

Jam pada saat masuk

Foto kendaraaan pengguna pada saat masuk

TransactionID

CardId / Nilai Barcode

b.Proses yang dilakukan

Pengguna men-tap kartu RFID pada saat masuk atau menekan tombol untuk mendapatkan tiket barcode. Untuk masuk dengan RFID akan dicek dulu validasinya oleh aplikasi apakah kartu RFID yang dipakai oleh pengguna valid atau tidak.

c.Informasi yang dihasilkan

Informasi yang di dapat dari proses ini adalah data pengguna pada saat masuk ke area parkir.

2 Menu CheckOut (Tap)

Pengguna

Pengguna menggunakan kartu RFID atau barcode yang telah di dapat untuk divalidasi sebelum

mening-a.Data yang di-entry : Tanggal Jam pada saat keluar

Foto kendaraan pengguna pada saat keluar

(67)

No. Fungsi/Menu Aplikasi

Terhadap Aktor galkan area parkir

Membuat data baru

Operator

Operator memverifikasi data-data yang ada untuk mengecek apakah kendaraan dengan penggunanya berhak keluar atau tidak.

Membuat data baru Update data

CardId / Nilai Barcode

Operator memverifikasikan cardid, lalu dari cardid tersebut akan memunculkan data(waktu,jam pada saat masuk, foto kendaraan dan pengguna, transactionId, CardId atau Nilai Barcode. Lalu operator akan mengecek apakah kendaraan yang akan keluar tersebut sama dan pengguna yang mengendarai kendaraan tersebut berhak keluar dengan kendaraan tersebut atau tidak. Setelah di verifikasi data baru yang didapat pada saat proses keluar akan dimasukkan ke dalam database oleh operator melalui aplikasi pada saat transaksi selesai.dan pengguna dapat meningalkan tempat parkir

Informasi yang dihasilkan adalah data pengguna pada saat keluar dari area parkir dan data operator yang melakukan verifikasi data pengguna dalam proses keluar parkir tersebut. 3 Fungsi

Mengcapture foto kendaraan

Webcam(aplikasi)

Mengambil foto kendaraan pengguna

a.Proses yang dilakukan

Webcam mengambil foto kendaraan pengguna pada saat pengguna mentap

(68)

Terhadap Aktor dan pengguna Membuat

Data baru

kartu atau menekan tombol untuk mencetak barcode pada saat masuk parkir BiNus

b.Informasi yang dihasilkan

Informasi yang di dapat dari proses ini adalah foto kendaraan pengguna yang menjelaskan bentuk kendaraan pengguna. 4 Fungsi Verifikasi Validitas Kartu RFID Aplikasi Membaca Informasi

Mengecek apakah kartu RFID yang digunakan merupakan kartu RFID standar yang sesuai digunakan dan mengikuti protokol BiNus

Informasi yang didapat dari proses ini adalah apakah kartu RFID tersebut merupakan kartu RFID yang sah dapat digunakan dalam ruang lingkup BINUS School Serpong.

5 Fungsi

Verifikasi Id Kartu RFID

Operator

Membandingkan Id dari kartu RFID pada saat pengguna masuk dan keluar Membaca Informasi

Proses yang dilakukan

Mengecek apakah kartu RFID yang digunakan pada saat keluar dengan pada saat masuk sama pada kendaraan yang digunakan oleh pengguna pada saat keluar

(69)

Terhadap Aktor dari kartu RFID pengguna. 6 Fungsi

mencetak barcode

Thermal Printer(Aplikasi) Mencetak barcode pada saat Pengguna yang tidak mempunyai RFID

Aplikasi mengenerate kode random dan lalu dibuat menjadi barcode, lalu dicetak pada tiket yang akan diambil oleh pengguna

7 Fungsi Verifikasi Foto

Operator

Membandingkan foto kendaraan pengguna ketika masuk dan ketika keluar

Membaca Informasi

Mengecek apakah foto kendaraan sama pada setiap kendaraan keluar dengan foto yang di ambil pada saat masuk dengan kartu RFID yang sama atau masih dalam satu turunan

Informasi yang di dapatkan adalah apakah kendaraan yang dikendarai pengguna merupakan kendaraan yang berhak untuk di bawa keluar oleh pengguna atau tidak.

8 Fungsi Verifikisi Nomor Kendaraan

Operator

Mengecek nomor kendaraan ketika pengguna akan meninggalkan area parkir BiNus School

Membaca Infromasi Membuat data baru

Mengecek agar Nomor kendaraaan pada saat masuk harus sama dengan nomor kendaraan pada saat keluar dengan kartu RFID yang sama atau masih dalam satu turunan

Informasi yang di dapatkan adalah apakah kendaraan yang dikendarai pengguna merupakan kendaraan yang berhak untuk di bawa keluar oleh

(70)

Terhadap Aktor pengguna atau tidak. 9 Menu Membuat laporan Berdasarkan data yang terkumpul Operator Membuat laporan penggunaan system parkir

untuk evaluasi dan pengembangan parkir

Membaca informasi Membuat data baru

Mengumpulkan data yang terkumpul dan mencetaknya menjadi suatu laporan yang akan dibaca oleh pemilik

Informasi yang di dapat adalah laporan tentang data parkir dan memungkinan untuk menghasilkan hasil data summary yang merupakan perhitungan.

10 Menu lihat data parkir

Operator

Melihat dan mengubah data parkir

Membaca Informasi

Melihat data parkir baik berdasarkan waktu , transactionID atau cardID dan mengubah data parkir

b.Informasi yang dihasilkan Informasi mengenai data parkir yang ditampilkan pada layar aplikasi 11 Menu edit data

parkir

Operator

Merubah data parkir Membaca Informasi Mengupdate data

Melihat data dan merubah data parkir b.Informasi yang dihasilkan Data parkir yang telah diperbarui 12 Menu lihat data

operator

Operator

Melihat data operator yang bertugas mengoperasikan sistem parkir

Membaca Informasi

b.Proses yang dilakukan Melihat data operator

Informasi operator yang bertugas pada sistem parkir di BiNuS School Serpong

(71)

Terhadap Aktor 13 Menu edit data

operator

Operator

Merubah data operator yang bertugas menjalankan sistem parkir

Membaca Informasi Mengupdate data

Melihat dan merubah data operator. Data yang dapat diubah adalah wewenang operator

Informasi operator yang bertugas pada sistem parkir di BiNuS School Serpong 14 Menu Add

Operator

Operator

Menambah operator yang bertugas menjalankan sistem parkir

Membuat data baru

a.Data yang di entry Username operator Wewenang operator Password operator

Memasukkan data operator yang baru.

Informasi operator yang bertugas pada sistem parkir di BiNuS School Serpong 15 Menu view Tipe

parkir

Operator

Melihat tipe parkir yang telah didatakan

Membaca informasi

Melihat tipe-tipe parkir yang dapat terjadi dalam proses masuk atau keluar

b.Informasi yang dihasilkan Informasi mengenai tipe parkir yang mungkin terjadi pada sistem parkir di BiNuS School Serpong

(72)

Terhadap Aktor 16 Menu add, edit,

delete Tipe parkir

Operator

Mengubah, menambah data dan menghapus tipe parkir yang didatakan

Membaca informasi Menambah data baru Menghapus data Mengupdate data

a.Data yang di entry Nama tipe parkir

Menambah, mengubah atau mengubah data baru

c.Informasi yang dihasilkan Informasi mengenai tipe parkir yang mungkin terjadi pada sistem parkir di BiNuS School Serpong

17 Menu view proof Out yang dibutuhkan

Operator

Melihat dokumen-dokumen apa saja yang dibutuhkan dalam proses keluar berdasarkan tipe parkirnya

a.Proses yang dilakukan Melihat dokumen-dokumen yang dibutuhkan dalam proses keluar parkir. b.Informasi yang dihasilkan

Informasi mengenai dokumen-dokumen yang dibutuhkan dalam proses parkir pada BiNuS School Serpong

18 Menu Add,Edit, delete proof Out yang

dibutuhkan

Operator

Mengubah, menambah data dan menghapus tipe parkir yang didatakan

Membaca informasi Menambah data baru Menghapus data Mengupdate data

a.Data yang di entry

Dokumen-dokumen yang dibutuhkan dalam proses keluar atau masuk parkir b.Proses yang dilakukan

Melihat data parkir dan memilih dokumen apa saja yang dibutuhkan berdasarkan tipe parkirnya.

c.Informasi yang dihasilkan Informasi mengenai dokumen-dokumen yang dibutuhkan dalam proses parkir pada BiNuS School Serpong

(73)

3.5 Perancangan Aplikasi

3.5.1 Model Aplikasi Berbasiskan Framework Duwamish

Berikut ini adalah model aplikasi sistem parkir front-end yang berbasiskan pada framework duwamish 7 :

Gambar 3.28 Model Aplikasi Sistem Parkir Front End

Berikut ini adalah model Web aplikasi sistem parkir back-end yang berbasiskan pada framework duwamish 7 :

(74)

Berikut ini adalah model Web Service aplikasi yang berbasiskan pada framework duwamish 7 :

Gambar 3.30 Model Web Service Aplikasi

Berikut ini adalah model Web Service aplikasi yang berbasiskan pada framework duwamish 7 :

(75)

3.5.2 Perancangan Class Diagram

(76)

3.5.3 Perancangan Component Diagram

Berikut ini merupakan Component Diagram sistem parkir yang di usulkan, yang menggambarkan gambaran implementasi yang statis dari sistem parkir dan hubungan aplikasi dengan komponen-komponen yang ada.

Parking Front End

Interop.SoftOrb.dll

Parking Back end RFID Reader

Parking Web Service

Parking.wsdl BusinessFacade.dll BusinessRules.dll DataAccess.dll Common.dll SystemFramework.dll

Parking Back end.exe

BusinessFacade.dll BusinessRules.dll

DataAccess.dll Common.dll

SystemFramework.dll

Application Web Service

ApplicationService.wsdl BusinessFacade.dll BusinessRules.dll DataAccess.dll Common.dll SystemFramework.dll

Data Base Server

BNSchoolSerpongDB ApplicationDB Parking Front end.exe

BusinessFacade.dll BusinessRules.dll DataAccess.dll Common.dll SystemFramework.dll ApplicationService.asmx Parking.asmx ParkingDB

(77)

3.5.4 Perancangan Sequence Diagram

3.5.4.1 Rancangan Sequence Diagram Front End

:TrParking

Display Parking Data Operator Application Parking In bool statusUpdate string ParkingID ScanBarcodeInTicket() ViewTrPark(ParkingID) dataValidate() bool dataValid [dataValid]UpdateTrParking(parkingID,timeIn,typeIDOut, stCarID) Parking Data

(78)

:TrParking

Pengguna

Application Parking In

bool statusInsert string ParkingID Tekan Tombol Tiket

insertDataParking(cardID, parkingID,stCarID,typeIDIn) createParkingID()

(79)