Fakultas Ilmu Komputer
5462
Rancang Bangun Sistem Informasi Fasilitas dan Penunjang Operasional
Berbasis Android (Studi Kasus: Bandar Udara Internasional Sam
Ratulangi Manado)
Nanda Adhi Winata1
, Aryo Pinandito
2, Satrio Agung Wicaksono
3Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1[email protected], 2[email protected], 3[email protected]
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.
1. PENDAHULUAN
Dalam menjaga kesiapan fasilitas dan penunjang operasional pada Bandar Udara Internasional Sam Ratulangi Manado dilakukan pengelolaan fasilitas oleh divisi kelistrikan. Dalam kegiatan operasional, jam kerja dibagi menjadi dua shift, sehingga diperlukan kesesuaian informasi kondisi perangkat.
Dari hasil wawancara dengan Erwin, teknisi kelistrikan, pada tanggal 3 Februari 2018, 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 kerusakan, sehingga teknisi membutuhkan waktu karena harus mencari pada setiap dokumen LTK perangkat yang dimaksud.
Saat ini, smartphone dan aplikasinya 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.
2. LANDASAN TEORI
2.1. Firebase
Firebase menyediakan real time database
dapat disinkronisasikan kepada pengguna. FCM dapat mengirim notifikasi untuk mendorong interaksi dengan pengguna (Firebase, 2017). Kedua fitur tersebut bisa mengurangi waktu penyampaian informasi. Untuk menjalankan kedua fitur tersebut dibutuhkan pemicu yang dijalankan seperti memasukkan data baru.
Gambar 1. Alur kerja FCM
3. METODOLOGI PENELITIAN
Langkah-langkah pada penelitian ini digambarkan dalam Gambar 2.
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 belum diperiksa
SKPL-F-05 Melihat daftar semua perangkat
SKPL-F-06 Melihat informasi perangkat
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 3. Use case diagram pengembangan versi 1
Pada pengembangan versi 2 ditambahkan 5
use case untuk dilakukan implementasi dan digambarkan dalam Gambar 4.
3.2.2. Activity Diagram
Activity diagram menggambarkan aliran 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.
Gambar 5. Activity diagram melihat laporan pemeriksaan
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.
3.2.3. Sequence Diagram
Dari tiap spesifikasi use case dan activity diagram dimodelkan interaksi antarobjek (Sommerville, 2011). Sequence diagram
dimodelkan berdasarkan activity diagram.
3.2.4. Domain Model Class Diagram
Domain model class diagram bertujuan menggambarkan struktur sistem dari segi pendefinisian data yang diperlukan (Satzinger, Jackson & Burd, 2012). Domain model class diagram dibuat berdasarkan kebutuhan data pada setiap objek.
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.
3.2.5. Design Class Diagram
Design class diagram merupakan 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.6. Pemetaan Domain Model Class Diagram ke Database
Domain model class diagram yang telah dibuat ditransformasikan untuk disesuikan dengan penggunaan pada Firebase untuk memudahkan saat melakukan query data.
3.2.7. Perancangan Antarmuka
Perancangan antarmuka bertujuan untuk membantu dalam fase implementasi antarmuka. Pemodelan antarmuka memodelkan isi dari suatu halaman serta tata letak tiap elemen yang dibutuhkan.
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.
3.3. Implementasi
Implementasi merupakan aktivitas merubah perancangan menjadi hasil nyata berupa sistem dengan penulisan kode dan implementasi pada
database. Firebase digunakan untuk menerima notifikasi dan menjalankan real time database. Pemicu real time digunakan untuk menjalankan pengambilan data melalui Application Programming Interface (API).
Gambar 7. Hasil implementasi 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.
3.4. Pengujian Sistem
3.4.1. Pengujian Unit Menggunakan Basis Path Testing
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).
Flow graph dibuat berdasarkan
pseudocode. Setiap perintah pada pseudocode
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.
Gambar 8. Flow graph pengambilan laporan pemeriksaan
V(G) = E - N + 2 = 8 - 7 + 2 = 3 atau
V(G) = R + 1 = 2 + 1 = 3
Jalur independen yang didapat adalah sebagai berikut:
1) 1-7,8-9 2) 1-2-3-6-9 3) 1-2-4,5-6-9
Berdasarkan 3 jalur yang didapatkan kasus ujidan dilakukan pengujian pada kasus uji tersebut semuanya bernilai valid.
3.4.2. Pengujian Integrasi dengan Pendekatan Thread-based
Pengujian integrasi memastikan kolaborasi
class yang membangun sebuah use case bekerja 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.
3.5. Evaluasi Sistem oleh Pemangku Kepentingan
Evaluasi sistem menggunakan acceptance test untuk menyetujui atau menolak kriteria yang 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.
Tabel 3. Kebutuhan fungsional final
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 belum diperiksa
SKPL-F-05 Melihat daftar semua perangkat
SKPL-F-06 Melihat informasi perangkat
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 Menambah gambar
pemeriksaan bermasalah SKPL-F-12 Menghapus laporan
pemeriksaan
SKPL-F-13 Melihat laporan perbaikan
SKPL-F-14 Membuat laporan
perbaikan
SKPL-F-15 Menambah gambar
perbaikan
3.6. Pengujian Waktu
3.6.1. Pengujian Pada Proses Bisnis Pemeriksaan Perangkat Fasilitas dan Penunjang Operasional
Pengujian dilakukan dengan mencatat waktu tiap aktivitas dalam proses bisnis as-is dan
to-be pemeriksaan perangkat. Pengujian dilakukan pada 3 teknisi dan tiap teknisi melakukan 2 kali percobaan.
Tabel 4. Rata-rata waktu yang dibutuhkan pada pemeriksaan penunjang dan operasional
Sebelum Sesudah
Rata-rata waktu yang dibutuhkan (menit)
Sebelum Sesudah Selisih
1. Teknisi
Tabel 4. (lanjutan)
Sebelum Sesudah
Rata-rata waktu yang dibutuhkan (menit)
Sebelum Sesudah Selisih
4. Pengawas 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%.
𝑃𝑒𝑟𝑠𝑒𝑛𝑡𝑎𝑠𝑒 = 18.17 − 05.2218.17 × 100% = 70,6%
3.6.2. Pengujian Pada Proses Bisnis Perbaikan Perangkat Fasilitas dan Penunjang Operasional
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.
Tabel 5. Rata-rata waktu yang dibutuhkan pada perbaikan penunjang dan operasional
Sebelum Sesudah
Rata-rata waktu yang dibutuhkan
(menit)
Sebelum Sesudah Selisih 1. Teknisi
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%.
𝑃𝑒𝑟𝑠𝑒𝑛𝑡𝑎𝑠𝑒 = 36.31 − 14.1536.31 × 100% = 61%
3.6.3. Pengujian Waktu Distribusi Informasi
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.
𝑃𝑒𝑟𝑠𝑒𝑛𝑡𝑎𝑠𝑒 = 12.50 − 00.0212.50 × 100% = 99,7%
4. ANALISIS HASIL PENGUJIAN WAKTU
4.1. Analisis Hasil Pengujian Pada Proses BisnisPemeriksaan Perangkat Fasilitas dan Penunjang Operasional
Dari hasil pengujian pada Tabel 4 didapatkan rata-rata waktu yang dibutuhkan pada tiap aktivitas yang diilustrasikan dalam Gambar 9.
Gambar 9. Perbandingan waktu proses bisnis pemeriksaan perangkat
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.
4.2. Analisis Hasil Pengujian Pada Proses BisnisPerbaikan Perangkat Fasilitas dan Penunjang Operasional
Dari hasil pengujian pada Tabel 5 didapatkan rata-rata waktu yang dibutuhkan pada tiap aktivitas yang diilustrasikan dalam Gambar 10.
Gambar 10. Perbandingan waktu proses bisnis perbaikan perangkat
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.
4.3. Analisis Hasil Pengujian Waktu Distribusi Informasi
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.
5. KESIMPULAN
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
Aktivitas 1 Aktivitas 2 Aktivitas 3 Aktivitas 4
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.
6. DAFTAR PUSTAKA
Az-zahra, H.M., Pinandito, A., & Tolle, H. 2015.
Usability Evaluation of Mobile Application in Culinary Recommendation System dalam IEEE Asia Pacific Conference on Wireless and Mobile.
Bittner, K. & Spence, I. 2003. Use Case Modeling. Pearson Education, Boston. Firebase. 2017. Firebase Cloud Messaging
(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.
Perry, W. E. 2006. Effective Methods for 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 16 Agustus 2017]
