BAB III METODOLOGI. Penelitian ini dimulai dengan studi literatur dari teori-teori yang

Transkripsi

1 BAB III METODOLOGI 3.1 Kerangka Penelitian Penelitian ini dimulai dengan studi literatur dari teori-teori yang berhubungan dengan CNS/ATM khususnya bagian ADS-B Flight Monitoring. Observasi dan wawancara dilakukan untuk mengetahui kondisi sistem yang sedang berjalan dan permasalahannya serta mengetahui kebutuhan pemakai (user requirement). Setelah dilakukan observasi dan wawancara, kemudian dilanjutkan dengan mempelajari dokumentasi pada sistem yang sudah dikembangkan. Dengan menggunakan gap analisis akan didapatkan gambaran perbedaan antara sistem yang sedang berjalan dengan sistem yang diinginkan sehingga diperoleh permasalahan yang akan diselesaikan. Dari masalah tersebut akan dibuat hipotesa (solusi sementara atas masalah tersebut). Hipotesa ini akan menjadi pegangan dalam merancang sistem yang akan dilakukan pada tahap perancangan. Pada tahap perancangan untuk dapat mengetahui sistem yang dibangun layak atau tidak, maka digunakan Pilot Study. Pada Pilot Study ini dibuat sistem dengan skala kecil atau modul-modul kecil, dimana modul ini akan diperiksa kelayakannya. Jika pilot study sudah dinyatakan layak maka tahap selanjutnya adalah implementasi, pada tahap ini sistem yang dibuat akan dibuat/diuji pada kondisi sebenarnya dilapangan. Setelah itu dilakukan pengujian antara sistem yang dijadikan sebagai referensi dengan sistem yang dikembangkan menggunakan dengan menggunakan beberapa variabel sebagai acuannya, sehingga diperoleh suatu kesimpulan. 50

2 51 Gambar 3.1 Kerangka Penelitian 3.2 Metode Pengumpulan Data Di dalam pengumpulan data penulis menggunakan dua cara diantaranya sumber yang berupa data primer dan sumber yang berupa data sekunder.

3 Sumber Data Primer Untuk memperoleh data dan informasi yang akurat dalam penelitian ini, penulis menggunakan teknik pengumpulan data melalui wawancara, observasi. Wawancara dilakukan secara langsung dengan Kepala Program, chief Engineer, Group Leader, Leader dan para Engineering Staff. Dengan observasi memungkinkan penulis melihat dan mencoba secara langsung hardware dan software yang digunakan dan mencatat perilaku sistem yang sedang berjalan Sumber Data Sekunder Data sekunder merupakan cara pengumpulan data dengan cara mempelajari data yang telah tersedia atau dikumpulkan terlebih dahulu oleh pihak lain seperti buku-buku. Cara yang digunakan untuk mengumpulkan data sekunder adalah metode Dokumentasi, yaitu dengan mengumpulkan data dan informasi yang diperlukan dari sumber-sumber yang kebanyakan dari materi sejenis dokumen yang berhubungan dengan masalah yang diteliti. Metode ini digunakan untuk pengumpulan data yang berhubungan dengan penelitian. Adapun dokumen yang diperoleh dari perusahaan antara lain dokumentasi pengujian perangkat lunak sebelumnya, dokumentasi pengembangan perangkat lunak sebelumnya yang berupa Technical Note (TN), Technical Report (TR) dan Technical Document (TD).

4 Metode Analisis Pada metode Analisis ini akan dilakukan sbb : Analisis terhadap sistem yang sedang berjalan untuk mengetahui cara kerja sistem, masalah yang timbul dan sumber masalahnya. Identifikasi terdapat kebutuhan pengguna (user requirement) tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Identifikasi terhadap kebutuhan sistem (system requirement) tentang layanan/kemampuan sistem dan batasan-batasannya. Analisis terdapat kinerja pemrograman multi thread, pada prosesor multi core. Tujuan dari analisis ini adalah untuk merancang algoritma agar penggunaan kemampuan komputer menjadi lebih optimal Melakukan Gap Analisis, yaitu analisis yang dilakukan untuk melihat kesenjangan antara sistem yang sedang berjalan dengan sistem yang diinginkan (user requirement). Analisis merupakan bagian penting dari proses rekayasa perangkat lunak, karena semua proses selanjutan akan sangat bergantung pada baik tidaknya hasil analisis ini.

5 54 Gambar 3.2 Tahapan dalam analisis 3.4 Usulan Pemecahan Masalah Dari hasil Analisis pada bab 3.3 diatas, akan diperoleh kesenjangan antara sistem yang sedang berjalan dengan sistem yang diinginkan (user requirement). Usulan pemecahan masalah adalah solusi untuk menghilangkan kesenjangan tersebut. 3.5 Perancangan Sistem Disain perangkat lunak adalah tahapan atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis komputer. Disain perangkat lunak sering juga disebut sebagai physical design. Tahapan analisis sistem menekankan pada masalah proses, maka pada disain perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak.

6 55 Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada pengguna sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi disain umum hanya berisi gambaran umum agar pengguna sistem mengerti akan seperti apa perangkat lunak yang akan dibangun. Alat bantu yang digunakan untuk mendisain sistem adalah Use Case diagarm. Use Case diagram merupakan point penting dibagian perancangan untuk berkomunikasi dengan pengguna. Spesifikasi disain rinci kadang-kadang juga disebut dengan disain arsitektur rinci perangkat lunak, dan desain ini diperlukan untuk merancang sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly dan memiliki dasar-dasar untuk pengembangan selanjutnya. Desain arsitektur ini terdiri dari desain proses, desain user interface yang mencakup desain input, output form dan report. Alat bantu (tool) yang digunakan pada perancangan sistem ini adalah UML (Unified Modeling Languange). 3.6 Testing Pada tahap implementasi peneliti menggunakan model waterfall yang sudah dimodifikasi, dimana setiap object atau modul program langsung di test sampai benar seperti gambar 3.3 dibawah.

7 56 Gambar 3.3 Siklus Testing per Modul program 3.7 Integrasi Pada tahapan ini modul modul yang sudah dibuat dan sudah di test kebenarannya kemudian di gabungkan menjadi sebuah aplikasi program yang disebut dengan ADS-B Flight Tracking yang sudah memiliki spesifikasi / fitur sesuai dengan user requirement. 3.8 Metode Pengujian Sistem Metode pengujian digunakan metode Black-Box yang berfokus pada persyaratan fungsional perangkat lunak. Dengan memberikan serangkaian data input maka yang diamati hasil data outputnya. Pengujian dilakukan dengan cara membandingkan perangkat lunak yang dibuat (ADS-B Flight Tracking) dengan perangkat lunak yang dibeli dari perusahaan Kinetic Avionics dari Inggris yang

8 57 diberi nama Obelix SBS-2. Konfigursi sistem pengujian seperti terlihat pada gambar 3.4 dibawah. Dengan memberikan serangkaian data input yang sama kepada kedua program ini, kemudian data outputnya dari kedua program dibandingkan. Data output yang akan dibandingkan adalah : Jumlah pesawat yang muncul pada layar monitor Lokasi (koordinat latitude dan longitude) dari pesawat yang muncul di layar monitor Informasi pesawat lainnya seperti kode pesawat (call sign), arah pesawat (track angle), kecepatan pesawat (ground speed) dan ketinggian (flight level). Pengujian akan dilakukan pada kondisi yang berbeda beda yaitu pada waktu jam sibuk dimana jumlah pesawat yang ditangkap oleh ADS-B receiver cukup banyak biasanya pada pagi hari atau sore hari, dan pada jam yang agak sepi dimana jumlah pesawat tidak terlalu banyak biasanya di siang hari atau malam hari. Pengujian dilakukan dengan dua cara yaitu pertama dengan pengamatan langsung kepada kedua program dengan menaruh kedua layar monitor saling berdekatan, dan kedua dengan cara merekam data di masing-masing program kemudian hasilnya dibandingkan. Cara yang kedua ini dilakukan dengan mengambil beberapa sample data saja.

9 58 Gambar 3.4 Konfigurasi Pengujian 3.9 Pengukuran Keberhasilan Sebagai ukuran keberhasilan dari perancangan sistem perangkat lunak ADS- B Flight tracking adalah berdasarkan pada hasil pengujian yang dilakukan pada bab 3.6 diatas. Keberhasilan dari sistem ini bisa dilihat dari 3 (tiga) sisi yaitu : 1. Kelengkapan fitur fitur yang dimiliki oleh software ADS-B Flight Tracking sekurang kurang nya 80% dari Perangkat Lunak Obelix SBS Kebenaran hasil output dalam pemrosesan data yang diterima dari Server ADS-B Receiver dengan format Asterix-21 sampai ditampilkan di layar Monitor secara real time. 3. CPU Utilization, yaitu berapa besar (%) utilisasi CPU yang terpakai dengan rancangan algoritma yang baru. Untuk kelengkapan fitur dapat diukur/dibandingkan dari User Requirement, sedangkan dari sudut kebenaran hasil pemrosesan data dapat dilihat dari hasil pengujian dengan metode pengujian seperti pada bab 3.6 diatas. Sedangkan CPU

10 59 utilisasi bisa dilihat dari performance yang ditunjukkan oleh program Windows Task Manager. Pada penelitian ini penulis lebih menekankan keberhasilan perancangan software ini dari kebenaran pemrosesan data dengan CPU Utilization yang optimal. Parameter output yang dijadikan ukuran keberhasilan adalah sbb: Jumlah pesawat yang ditampilkan di layar monitor harus sama dengan yang ditampilkan oleh program Obelix Lokasi setiap pesawat (longitude dan latitude) harus sama dengan yang ditampilkan oleh program Obelix Ketinggian setiap pesawat (Flight level) harus sama dengan yang ditampilkan oleh program Obelix ICAO Address, Call Sign dari setiap pesawat harus sama dengan yang ditampilkan oleh program Obelix Track Angle dan waktu dari setiap pesawat harus sama dengan yang ditampilkan oleh program Obelix Lintasan dari setiap pesawat yang ditampilkan di layar monitor harus sama dengan lintasan pesawat yang ditampilkan oleh program Obelix Pada saat program dijalankan CPU Utilization yang optimal.