Rancang Bangun Sistem Informasi Fasilitas dan Penunjang Operasional Berbasis Android (Studi Kasus: Bandar Udara Internasional Sam Ratulangi Manado)
Vol. 2, No. 11, November 2018, hlm. 5462-5469 http://j-ptiik.ub.ac.id
Rancang Bangun Sistem Informasi Fasilitas dan Penunjang Operasional
Berbasis Android (Studi Kasus: Bandar Udara Internasional Sam
Ratulangi Manado)
1
2
3 Nanda Adhi Winata , Aryo Pinandito , Satrio Agung Wicaksono
Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya 1 2 3 Email: nandhi.winata@gmail.com, aryo@ub.ac.id, satrio@ub.ac.id
Abstrak
Untuk menjaga kesiapan fasilitas dan penunjang operasional pada Bandar Udara Internasional Sam Ratulangi Manado maka dilakukan pengelolaan oleh divisi kelistrikan. Divisi kelisktrikan perlu mendapatkan kesesuaian informasi kesiapan fasilitas dan penunjang operasional pada tiap shift. Teknisi terkadang memerlukan riwayat kerusakan untuk mengidentifikasi kerusakan perangkat. Penelitian ini berusaha menyelesaikan masalah dengan sistem yang mampu melakukan distribusi data secara cepat.
Platform yang dipilih adalah Android karena hampir semua teknisi memiliki Android. Aplikasi Android bisa berjalan di background dan melakukan sinkronisasi data. Digunakan Firebase karena mampu mengirim notifikasi serta memiliki pemicu pembaruan data yang real time. Penelitian menggunakan pendekatan incremental untuk menampung keinginan pengguna terhadap sistem. Penelitian diawali dengan analisis permasalahan yang menghasilkan kebutuhan fungsional dan non fungsional sistem. Penelitian dilanjutkan dengan perancangan, implementasi, pengujian sistem, dan evaluasi sistem oleh pemangku kepentingan secara berulang. Perancangan menghasilkan rancangan perilaku sistem dan struktur data yang dibutuhkan. Implementasi dan pengujian menghasilkan hasil nyata sistem. Evaluasi sistem oleh pemangku kepentingan menghasilkan masukan untuk pengembangan berikutnya. Tahap terakhir adalah pengujian dan analisis pengujian untuk mengetahui apakah sistem mampu menyelesaikan masalah dengan membandingkan waktu yang dibutuhkan. Dari hasil pengujian didapatkan bahwa proses bisnis sesudah implementasi lebih cepat dibanding sebelum implementasi sehingga dianggap menyelesaikan masalah yang ada.
Kata kunci: Teknisi, Sistem Informasi Fasilitas dan Penunjang Operasional, Android, Firebase,
distribusi data
Abstract
In an effort to maintain facilities and operational support at Sam Ratulangi International Airport
Manado managed by electricity division. In daily tasks, electricity division require conformity about the
readiness of device on each shift. Technicians sometimes requires a previous history of damage to help
identify damage to the device. This research provide a system capable of distributing data quickly.
Almost all technicians have Android devices. Android applications can run in the background and
provides data synchronization. Firebase has a feature to trigger updates in real time data and able to
send notifications. This research uses an incremental approach to accommodate the user's desire about
the system. Begins by analyzing problems that result in functional and non functional requirements.
Research continues with the design, system implementation and testing, and system evaluation by
stakeholders repeatedly. The design produce system behavior and required data structure.
Implementation and testing produce tangible results from system implementation. Stakeholder
evaluation generates feedback in subsequent development. The last stage is testing to see if the system
capable to solve the problem by comparing the time required. The test results obtained that the business
process after implementation faster than before implementation so it is considered to solve existing
problems.
Keywords: Technician, Facility and Operational Support Information System, Android, Firebase, data
distribution Fakultas Ilmu Komputer Universitas Brawijaya
5462
2. LANDASAN TEORI 1. PENDAHULUAN
Dalam menjaga kesiapan fasilitas dan
2.1. Firebase
penunjang operasional pada Bandar Udara Firebase menyediakan real time database
Internasional Sam Ratulangi Manado dilakukan dapat disinkronisasikan kepada pengguna. FCM pengelolaan fasilitas oleh divisi kelistrikan. dapat mengirim notifikasi untuk mendorong
Dalam kegiatan operasional, jam kerja dibagi interaksi dengan pengguna (Firebase, 2017). menjadi dua , sehingga diperlukan
shift
Kedua fitur tersebut bisa mengurangi waktu kesesuaian informasi kondisi perangkat. penyampaian informasi. Untuk menjalankan
Dari hasil wawancara dengan Erwin, teknisi kedua fitur tersebut dibutuhkan pemicu yang kelistrikan, pada tanggal 3 Februari 2018, dijalankan seperti memasukkan data baru. terdapat beberapa masalah. Informasi terkini keadaan perangkat hanya dikelola teknisi yang sedang memeriksa, setelah memeriksa teknisi harus memberi tahu pengawas dan teknisi lain kondisi perangkat tersebut. Keadaan tersebut menimbulkan keterlambatan informasi sehingga menyebabkan keterlambatan teknisi lain untuk membantu perbaikan perangkat jika perangkat mengalami kerusakan. Pada saat pemeriksaan, teknisi terkadang membutuhkan riwayat kerusakan sebelumnya untuk mengidentifikasi kerusakan. Namun Laporan Terjadinya Kerusakan (LTK) terdokumentasi setiap terjadi
Gambar 1. Alur kerja FCM
kerusakan, sehingga teknisi membutuhkan waktu karena harus mencari pada setiap
3. METODOLOGI PENELITIAN dokumen LTK perangkat yang dimaksud.
Langkah-langkah pada penelitian ini Saat ini, smartphone dan aplikasinya digambarkan dalam Gambar 2. berperan menyelesaikan pekerjaan manusia sehari-hari (Az-zahra, 2015) Mayoritas teknisi memiliki perangkat Android. Android mampu menerima notifikasi walaupun aplikasi berjalan pada background untuk sinkronisasi data. Selain itu digunakan Firebase karena memiliki pemicu pembaruan data yang real time dan dapat mengirim notifikasi (Firebase, 2017). Dengan penerapan pada perangkat Android teknisi tidak perlu berjalan menuju tempat penyimpanan LTK, serta penggunaan Firebase bisa mengurangi waktu penyampaian informasi.
Penelitian sebelumnya oleh Sholichin (2016) mengembangkan sistem berbasis Android yang memanfaatkan Firebase Cloud Messaging (FCM) yang dapat dijadikan acuan dalam penelitian ini.
Penelitian dijalankan dengan pendekatan
incremental untuk menyesuaikan sistem seperti
yang diinginkan oleh pengguna (Sommerville, 2011). Penelitian ini melakukan pengujian untuk mengetahui apakah sistem mampu menyelesaikan masalah dengan membandingkan waktu yang dibutuhkan pada proses bisnis sebelum dan sesudah implementasi. Penelitian ini diharapkan mampu memperbaiki efisiensi proses bisnis dan waktu. Gambar 2. Metodologi penelitian
3.1. Analisis Kebutuhan
3.1.1. Proses Bisnis As-is
Pemodelan proses bisnis as-is bertujuan untuk mengetahui proses bisnis yang berjalan pada pemeriksaan dan perbaikan perangkat.
3.1.2. Proses Bisnis To-be
Pemodelan proses bisnis to-be bertujuan untuk memberi rekomendasi proses bisnis baru pada pemeriksaan dan perbaikan perangkat.
3.1.3. Kebutuhan Fungsional dan Non Fungsional
Dari hasil analisis, pada tahap awal didapatkan 12 kebutuhan fungsional dan 2 kebutuhan non fungsional.
Tabel 1. Kebutuhan fungsional tahap awal Kode Fungsi Nama Fungsi SKPL-F-01 Log in SKPL-F-02 Log out SKPL-F-03 Melihat daftar perangkat bermasalah SKPL-F-04 Melihat daftar perangkat
Gambar 3. Use case diagram pengembangan versi 1 belum diperiksa SKPL-F-05 Melihat daftar semua
Pada pengembangan versi 2 ditambahkan 5
perangkat SKPL-F-06 Melihat informasi use case untuk dilakukan implementasi dan perangkat digambarkan dalam Gambar 4. SKPL-F-07 Melihat daftar laporan pemeriksaan bermasalah SKPL-F-08 Melihat daftar semua laporan pemeriksaan SKPL-F-09 Melihat laporan pemeriksaan SKPL-F-10 Membuat laporan pemeriksaan SKPL-F-11 Melihat laporan perbaikan SKPL-F-12 Membuat laporan perbaikan
Tabel 2. Kebutuhan non fungsional Kode Fungsi Nama Fungsi SKPL-NF-01 Availability SKPL-NF-02 Real time
3.2. Perancangan
3.2.1. Use Case Diagram
Dari kebutuhan fungsional maka diubah menjadi use case (Bittner & Spence, 2003). Use
case diagram pengembangan versi 1 terdapat 10 use case sesuai dengan jumlah implementasi
kebutuhan fungsional. Use case pengembangan versi 1 digambarkan dalam Gambar 3.
Gambar 4. Use case diagram pengembangan versi 2
3.2.2. Activity Diagram Activity diagram menggambarkan aliran
Pada pengembangan versi 1 terdapat 6 class yaitu checklist, perangkat, terakhir_diperiksa, pemeriksaan, checklist pemeriksaan dan teknisi. Pada pengembangan versi 2 terdapat penambahan 3 class yaitu gambar pemeriksaan, perbaikan dan gambar pemeriksaan.
Halaman buat pemeriksaan menampilkan pemeriksaan yang telah dilakukan. Kotak pertama berisi nama perangkat, kategori fasilitas, lokasi perangkat, teknisi yang melakukan pemeriksaan, kondisi perangkat, dan waktu pemeriksaan dilakukan. Dibawahnya terdapat checklist pemeriksaan yang telah dijalankan teknisi pada pemeriksaan tersebut. Gambar 6 merupakan gambar dari pemodelan antarmuka halaman buat pemeriksaan.
Perancangan antarmuka bertujuan untuk membantu dalam fase implementasi antarmuka. Pemodelan antarmuka memodelkan isi dari suatu halaman serta tata letak tiap elemen yang dibutuhkan.
3.2.7. Perancangan Antarmuka
dibuat ditransformasikan untuk disesuikan dengan penggunaan pada Firebase untuk memudahkan saat melakukan query data.
Domain model class diagram yang telah
3.2.6. Pemetaan Domain Model Class Diagram ke Database
rangkuman dari sequence diagram yang telah dibuat (Satzinger, Jackson & Burd, 2012). Pada pengembangan versi 1 pada package screen terdapat 12 class. Pada pengembangan versi 2 terdapat penambahan 3 class pada package screen.
3.2.5. Design Class Diagram Design class diagram merupakan
diagram dibuat berdasarkan kebutuhan data pada setiap objek.
aktivitas pengguna secara berurutan (Satzinger, Jackson & Burd, 2012). Dari tiap use case diambil spesifikasi use case sebagai ilustrasi terhadap alur utama maupun alternatif dengan menggunakan activity diagram.
menggambarkan struktur sistem dari segi pendefinisian data yang diperlukan (Satzinger, Jackson & Burd, 2012). Domain model class
3.2.4. Domain Model Class Diagram Domain model class diagram bertujuan
(Sommerville, 2011). Sequence diagram dimodelkan berdasarkan activity diagram.
diagram dimodelkan interaksi antarobjek
Dari tiap spesifikasi use case dan activity
3.2.3. Sequence Diagram
Aktivitas melihat laporan pemeriksaan pada Gambar 5 dimulai dengan teknisi memilih salah satu laporan pemeriksaan. Sistem menampilkan halaman pemeriksaan. Apabila data berhasil diambil maka sistem menampilkan detail laporan pemeriksaan tersebut. Jika laporan yang dimaksud tidak ada maka sistem menampilkan pesan “Data pemeriksaan tidak ditemukan”. Jika data gagal diambil maka sistem menampilkan pesan eror.
Gambar 5. Activity diagram melihat laporan pemeriksaan
Gambar 6. Perancangan antarmuka melihat laporan pemeriksaan
Jalur independen yang didapat adalah sebagai berikut: 1)
3.5. Evaluasi Sistem oleh Pemangku Kepentingan
3.4.2. Pengujian Integrasi dengan Pendekatan Thread-based
1-2-4,5-6-9 Berdasarkan 3 jalur yang didapatkan kasus uji dan dilakukan pengujian pada kasus uji tersebut semuanya bernilai valid.
1-2-3-6-9 3)
1-7,8-9 2)
3.3. Implementasi
V(G) = E - N + 2 = 8 - 7 + 2 = 3 atau V(G) = R + 1 = 2 + 1 = 3
Gambar 8. Flow graph pengambilan laporan pemeriksaan
dengan baik (Mall, 2014). Kasus uji didasarkan pada main flow dan alternative flow dari sebuah spesifikasi use case. Dari hasil pengujian semua kasus uji yang diuji bernilai berhasil.
Evaluasi sistem menggunakan acceptance
class yang membangun sebuah use case bekerja
test untuk menyetujui atau menolak kriteria yang
3.4. Pengujian Sistem
Halaman buat pemeriksaan pada Gambar 7 menampilkan pemeriksaan yang telah dilakukan. Kotak pertama berisi nama perangkat, kategori fasilitas, lokasi perangkat, teknisi yang melakukan pemeriksaan, kondisi perangkat, dan waktu pemeriksaan dilakukan. Dibawahnya terdapat checklist pemeriksaan yang telah dilakukan teknisi pada pemeriksaan tersebut.
Gambar 7. Hasil implementasi sistem
Programming Interface (API).
Pemicu real time digunakan untuk menjalankan pengambilan data melalui Application
database . Firebase digunakan untuk menerima notifikasi dan menjalankan real time database.
Implementasi merupakan aktivitas merubah perancangan menjadi hasil nyata berupa sistem dengan penulisan kode dan implementasi pada
Pengujian integrasi memastikan kolaborasi
3.4.1. Pengujian Unit Menggunakan Basis
diberi nomor untuk menandai jalur yang dilewati. Node (N) merupakan perintah sedangkan Edge (E) merupakan jalur yang dilalui. Region (R) menandakan wilayah yang dibatasi Node dan Edge.
Flow graph dibuat berdasarkan pseudocode . Setiap perintah pada pseudocode
Pengujian unit memastikan komponen terkecil sistem yaitu method bekerja dengan benar (Mall, 2014). Dari pseudocode diilustrasikan flow graph dan dicari jalur independent yang dilalui (Mitchell & Black, 2015).
Path Testing
ditetapkan pada Software Requirements
Specification (Perry, 2006). Kasus uji didasarkan
pada main flow dan alternative flow dari sebuah spesifikasi use case. Dari hasil pengujian semua kasus uji yang diuji bernilai berhasil. Terdapat masukan pada pengembangan versi 1 yaitu:
- Menambahkan gambar pada pemeriksaan bermasalah.
- Menambahkan gambar pada perbaikan.
- Menghapus pemeriksaan. Masukan diubah menjadi kebutuhan fungsional final karena tidak ada lagi masukan pada pengembangan versi 2. Tabel 3 merupakan kebutuhan fungsional final.
Pengujian dilakukan dengan mencatat waktu tiap aktivitas dalam proses bisnis as-is dan
Teknisi memperbaiki kerusakan perangkat
1. Teknisi mengidentifikasi kerusakan perangkat
Teknisi mengidentifikasi kerusakan perangkat
05.00 05.00 00.00
2. Teknisi mencari kerusakan sebelumnya Teknisi mencari kerusakan sebelumnya
09.30 00.08 09.22
3. Teknisi memperbaiki kerusakan perangkat
05.00 05.00 00.00
to-be pemeriksaan perangkat. Pengujian
4. Teknisi membuat laporan kerusakan
Teknisi membuat laporan kerusakan
07.50 04.00 03.50
5. Teknisi melaporkan ke pengawas Sistem mengirim notifikasi
09.10 00.06 09.04
6. Pengawas menerima laporan Pengawas menerima laporan
00.01 00.01 00.00
Tabel 5. Rata-rata waktu yang dibutuhkan pada perbaikan penunjang dan operasional Sebelum Sesudah Rata-rata waktu yang dibutuhkan (menit) Sebelum Sesudah Selisih
Pengujian dilakukan dengan mencatat waktu yang dibutuhkan pada tiap aktivitas dalam proses bisnis as-is dan proses bisnis to-be perbaikan fasilitas dan penunjang operasional. Pengujian dilakukan kepada 3 teknisi dan tiap teknisi melakukan 2 percobaan.
3.6.2. Pengujian Pada Proses Bisnis Perbaikan Perangkat Fasilitas dan Penunjang Operasional
= 18.17 − 05.22 18.17 × 100% = 70,6%
Tabel 4 merupakan rata-rata dari tiap aktivitas proses bisnis. Dihitung penurunan waktu dengan menghitung rata-rata selisih waktu dibagi waktu sebelum implementasi dan dikali 100%. Sehingga didapatkan penurunan waktu setelah implementasi sebesar 70,6%.
00.01 00.01 00.00
Pengawas menerima checklist pemeriksaan
4. Pengawas menerima checklist pemeriksaan
Tabel 4. (lanjutan) Sebelum Sesudah Rata-rata waktu yang dibutuhkan (menit) Sebelum Sesudah Selisih
3.6. Pengujian Waktu
3.6.1. Pengujian Pada Proses Bisnis Pemeriksaan Perangkat Fasilitas dan Penunjang Operasional
3. Teknisi menyerahkan checklist pemeriksaan
Teknisi mengisi checklist pemeriksaan Tabel 5 merupakan rata-rata dari tiap aktivitas proses bisnis. Dihitung penurunan waktu dengan menghitung rata-rata selisih waktu dibagi waktu sebelum implementasi dan dikali 100%. Sehingga didapatkan penurunan waktu setelah implementasi sebesar 61%.
2. Teknisi mengisi checklist pemeriksaan
05.00 05.00 00.00
Teknisi memeriksa kondisi perangkat
1. Teknisi memeriksa kondisi perangkat
Tabel 4. Rata-rata waktu yang dibutuhkan pada pemeriksaan penunjang dan operasional Sebelum Sesudah Rata-rata waktu yang dibutuhkan (menit) Sebelum Sesudah Selisih
dilakukan pada 3 teknisi dan tiap teknisi melakukan 2 kali percobaan.
Sistem mengirim notifikasi 12.40 00.07 12.33
00.36 00.15 00.21
= 36.31 − 14.15 36.31 × 100% = 61%
3.6.3. Pengujian Waktu Distribusi Informasi
Dari Gambar 10 dapat disimpulkan bahwa aktivitas teknisi mencari kerusakan sebelumnya memiliki pengurangan waktu paling besar. Hal tersebut disebabkan teknisi harus berjalan ke tempat penyimpanan laporan dan mencari laporan secara manual. Sedangkan pada aktivitas tersebut setelah implementasi, teknisi tidak perlu berjalan menuju tempat penyimpanan laporan dan laporan kerusakan sebelumnya ada pada daftar pertama pada aplikasi.
Dari hasil pengujian waktu proses bisnis didapatkan hasil bahwa sesudah implementasi tiap proses bisnis memiliki waktu yang lebih cepat dibandingkan dengan proses bisnis sebelum implementasi. Dari hasil pengujian pada proses bisnis pemeriksaan perangkat terdapat penurunan waktu dengan persentase 00.00 02.53 05.46 08.38 11.31 14.24 Aktivitas 1 Aktivitas 2 Aktivitas 3 Aktivitas 4 Sebelum Sesudah Selisih 00.00 02.53 05.46 08.38 11.31 Sebelum Sesudah Selisih
5. KESIMPULAN
Secara umum distribusi informasi yang dimaksud adalah menyampaikan hasil aktivitas kepada teknisi lain. Pada distribusi informasi sebelum implementasi teknisi menyampaikan informasi pada teknisi lain dengan bertatap muka sehingga membutuhkan waktu untuk berjalan untuk menghampiri teknisi lain. Sedangkan ketika sesudah implementasi ketika sistem menyimpan hasil pemeriksaan atau perbaikan secara otomatis mengirim notifikasi ke semua teknisi sehingga teknisi tidak perlu berjalan.
4.3. Analisis Hasil Pengujian Waktu Distribusi Informasi
Gambar 10. Perbandingan waktu proses bisnis perbaikan perangkat
Setelah mendapat hasil pengujian sebelum dan sesudah hasil implementasi maka dihitung rata-rata tiap tugas yang dikerjakan. Dari hasil perhitungan rata-rata dicari selisihnya dan dicari persentase perubahan waktu.
Dari hasil pengujian pada Tabel 5 didapatkan rata-rata waktu yang dibutuhkan pada tiap aktivitas yang diilustrasikan dalam Gambar 10.
4.2. Analisis Hasil Pengujian Pada Proses Bisnis Perbaikan Perangkat Fasilitas dan Penunjang Operasional
Dari Gambar 9 dapat disimpulkan bahwa aktivitas teknisi menyerahkan checklist pemeriksaan yang diubah menjadi sistem mengirim notifikasi memiliki pengurangan waktu paling besar. Hal tersebut dikarenakan teknisi harus berjalan dari tempat pemeriksaan perangkat menuju tempat pengawas untuk memeriksa pemeriksaan yang telah dibuat. Sedangkan setelah implementasi, teknisi tidak perlu berjalan menuju tempat pengawas.
Gambar 9. Perbandingan waktu proses bisnis pemeriksaan perangkat
Dari hasil pengujian pada Tabel 4 didapatkan rata-rata waktu yang dibutuhkan pada tiap aktivitas yang diilustrasikan dalam Gambar 9.
= 12.50 − 00.02 12.50 × 100% = 99,7%
4. ANALISIS HASIL PENGUJIAN WAKTU
4.1. Analisis Hasil Pengujian Pada Proses Bisnis Pemeriksaan Perangkat Fasilitas dan Penunjang Operasional
70,6%. Sedangkan pada proses bisnis perbaikan perangkat yang tidak memerlukan informasi perbaikan sebelumnya terdapat penurunan waktu dengan persentase 53,4% dan pada proses bisnis perbaikan perangkat yang memerlukan informasi perbaikan sebelumnya terdapat penurunan waktu dengan persentase 61%. Pada umumnya penurunan waktu disebabkan karena teknisi tidak perlu berjalan menuju tempat yang dituju dan digantikan dengan bantuan dari sistem. Dari hasil pengujian waktu distribusi didapatkan hasil bahwa sesudah implementasi terdapat penurunan waktu dengan persentase 99,7%. Pada umumnya penurunan waktu disebabkan karena teknisi tidak perlu berjalan untuk menemui teknisi lain dan digantikan dengan sistem mengirim notifikasi pada teknisi lain.
16 Agustus 2017] Sommerville, I. 2011. Software engineering. 9th ed . Pearson Education, Boston.
6. DAFTAR PUSTAKA Az-zahra, H.M., Pinandito, A., & Tolle, H. 2015.
(FCM) . Tersedia di:
<https://firebase.google.com/docs/clou d-messaging/?hl=id> [Diakses
16 Agustus 2017] Mall, R. 2014. Fundamentals of Software
Engineering, 4th ed . PHI Learning Private Limited, Delhi.
Mitchell, J. L. & Black, R. 2015. Advanced
Software Testing . Rocky Nook, Santa Barbara.
Usability Evaluation of Mobile Application in Culinary Recommendation System dalam IEEE
Software Testing . Wiley Publishing, Indiana.
Satzinger, J. W., Jackson, R. B., & Burd, S. D.
2012. Systems Analysis and Design in a
Changing World, Sixth Edition . Course Technology, Boston.
Sholichin, F. 2016. Pengembangan Aplikasi
Mobile Direktori Tempat Praktik Kerja Industri Pada Platform Android di SMK Negeri 3 Kasihan Bantul . S1.
Universitas Negeri Yogyakata. Tersedia di: <http://eprints.uny.ac.id/48652/1/13520 241037_fauzi_sholichin.pdf> [Diakses
Asia Pacific Conference on Wireless and Mobile. Bittner, K. & Spence, I. 2003. Use Case Modeling . Pearson Education, Boston. Firebase. 2017. Firebase Cloud Messaging
Perry, W. E. 2006. Effective Methods for