HASIL DAN ANALISIS Fakhruddin R. Batubara, ST, MTI

BAB 4 HASIL DAN ANALISIS

Setelah dilakukan observasi, sistem pencarian kerja dan tenaga kerja pada sektor informal dengan memanfaatkan teknologi jaringan ponsel dapat dibangun dengan memperhatikan beberapa hal. Prototip sistem ini dirancang, untuk membuktikan sistem ini dapat berjalan dengan baik hanya dengan memanfaatkan teknologi jaringan ponsel dan algoritma pemrograman yang baik tanpa memerlukan dukungan teknologi pendukung seperti server terpusat. Sistem ini memiliki kelebihan dan juga kekurangan jika dibandingkan dengan sistem yang menggunakan server terpusat. 4.1. Hasil observasi pemilihan spesifikasi sistem Observasi pemilihan spesifikasi sistem bertujuan untuk menghasilkan spesifikasi sistem yang sesuai dengan situasi dan kondisi di lapangan. Observasi meliputi observasi terhadap pengguna sistem, cara aksesibilitas sistem, teknologi pendukung sistem dan ketergantungan sistem.

4.1.1. Hasil observasi pengguna sistem

Setelah dilakukan observasi untuk mengetahui latar belakang para buruh bangunan maka didapatkan umumnya upah perhari mandor adalah Rp. 80.000, upah Universitas Sumatera Utara tukang Rp. 60.000, dan kenek Rp. 40.000. Waktu yang diperlukan untuk mendapatkan suatu proyek pekerjaan berkisar antara 1 sampai 2 minggu. Kriteria yang mempengaruhi pencarian kerja meliputi upah kerja, wilayah kerja dan jenis keahlian tukang. Hasil observasi juga menunjukkan pengaruh ponsel yang besar dalam mendukung pencarian kerja. Setiap buruh bangunan umumnya memiliki ponsel pribadi untuk menunjang pekerjaan mereka. Untuk jenis ponsel yang digunakan oleh para buruh bangunan merupakan ponsel biasa dengan harga berkisar rata-data Rp. 500.000 dan bukan merupakan ponsel smartphone. Jenis layanan yang sering digunakan oleh para buruh bangunan adalah SMS dan juga layanan voice.

4.1.2. Hasil observasi cara aksesibilitas sistem

Aksesibilitas ponsel biasa lebih terbatas dibandingkan dengan ponsel smartphone. Umumnya konektivitas ponsel biasa hanya meliputi SMS, GPRS dan Voice. Pada penelitian ini cara aksesibilitas yang dipilih adalah SMS karena SMS didukung oleh semua jenis ponsel dan operator yang ada di Indonesia. Tidak membutuhkan setting khusus seperti GPRS dan tidak semahal voice.

4.1.3. Hasil observasi teknologi pendukung sistem

Penelitian ini menggunakan konsep database terdistribusi. Namun ponsel biasa memiliki keterbatasan sumber daya sehingga tidak memungkinkan penggunaan Distributed Database Management System DDBMS yang kompleks dan besar. Universitas Sumatera Utara Salah satu solusinya adalah dengan memanfaatkan ruang memori lokal yang terdapat

4.1.4. Hasil observasi ketergantungan sistem

Sistem di bangun dengan teknologi Java ME. Java ME dipilih karena umumnya ponsel yang beredar di Indonesia mendukung teknologi Java. Konfigurasi yang dipilih merupakan konfigurasi untuk ponsel dengan keterbatasan sumber daya yaitu CLDC Connected Limited Device Configuration atau bukan konfigurasi untuk ponsel dengan kemampuan tinggi. Untuk mendukung agar sistem dapat berjalan secara otomatis tanpa terlalu membutuhkan campurtangan pengguna sistem, maka ponsel yang digunakan harus mendukung push registry. Push registry hanya dapat dijalankan oleh ponsel dengan profil MIDP 2.0 keatas. MIDP merupakan singkatan dari Mobile Information Device Profile. 4.2. Hasil Perancangan Sistem Terdistribusi Observasi perancangan sistem terdistribusi bertujuan untuk menghasilkan pilihan kebijakan yang sesuai. Dimana kebijakan ini dapat mempengaruhi efisiensi sistem dalam mendistribusikan maupun untuk mengumpulkan kembali data global dari setiap ponsel. Terdapat empat kategori observasi yaitu cara alokasi data, cara transmisi data dan pemrosesan query, manajemen direktori, dan konfigurasi jaringan.

4.2.1. Hasil observasi cara alokasi data dan manajemen direktori

Pada sistem ini cara alokasi data dilakukan dengan menggabungkan metode Universitas Sumatera Utara fragmentasi dan replikasi. Ada beberapa tabel yang direplikasi secara utuh tapi ada juga tabel yang difragmentasi kemudian di replikasi. Gambar 4.1 menampilkan ilustrasi tabel-tabel yang terdapat pada masing-masing pengguna sistem. Dengan penjelasan sebagai berikut, garis merah menunjukkan hubungan relasi antar tabel, garis biru tabel yang difragmentasi sedangkan garis hijau adalah tabel yang direplikasi secara utuh. Metode penggabungan dilakukan untuk meningkatkan efisiensi penyimpanan dan sinkronisasai data. Tabel 3.2 direplikasi secara utuh ke semua ponsel anggota karena tabel ini merupakan sentral dari alamat pengiriman token. Setiap ponsel bertugas untuk mengedarkan token dimana nomor ponsel penerima token berdasarkan urutan NoId dari Tabel 3.2 ini. Dengan adanya Tabel 3.2 di semua ponsel menyebabkan pengambilan isi tabel berlangsung secara lokal sehingga lebih efisien daripada harus mengambil data dari ponsel yang berbeda. Tabel 3.3 difragmentasi berdasarkan kebutuhan sistem. Koordinator dan mandor memiliki Tabel 3.3 secara utuh. Namun ponsel tukang hanya menyimpan fragmentasi dari tabel ini yaitu yang berisi data tukang lainnya dengan spesifikasi pekerjaan yang sama. Hal ini berkaitan dengan Tabel 3.6 yang dimiliki ponsel tukang. Setiap mendapatkan proyek pekerjaan, ponsel tukang hanya perlu mensinkronisasikan ke Tabel 3.6 tukang lainnya yang memiliki spesifikasi pekerjaan yang sama. Dengan hanya menyimpan fragmentasi data yang dibutuhkan akan meningkatkan efisien dalam hal penyimpanan ruang memori ponsel. Sedangkan koordinator dan mandor memiliki replikasi tabel yang utuh untuk keperluan ketersediaan data jika ada ponsel Universitas Sumatera Utara tukang yang membutuhkan informasi tentang tukang dengan spesifikasi keahlian yang berbeda.

4.2.2. Hasil observasi konfigurasi jaringan, transmisi data dan pemrosesn query

Beberapa faktor yang mempengaruhi pilihan konfigurasi adalah kompleksitas dan efisiensi biaya. Pada penelitian ini konfigurasi jaringan yang dipilih adalah konfigurasi ring network karena lebih sederhana dan murah. Instruksi dikirim secara hop by hop sehingga biaya pengiriman tidak ditanggung oleh hanya 1 pihak saja. Pilihan transmisi data untuk ponsel CLDC tidaklah sebanyak cara transmisi data untuk ponsel kategori smartphone. Pada penelitian ini, cara transmisi data yang dipilih adalah SMS dengan pertimbangan SMS merupakan layanan yang dapat dijalankan oleh setiap jenis ponsel dan semua operator selular yang ada di Indonesia. Pada sistem ini, SMS merupakan media untuk menjalankan MIDlet secara otomatis. Untuk membedakan dengan layanan SMS biasa, SMS pada sistem ini dilakukan dengan cara mengakses port tertentu. Port yang dipilih haruslah port yang tidak digunakan oleh sistem standar ponsel. Pada penelitian ini port yang dipilih yaitu port 8888. Pada penelitian ini, transaksi dikirim ke dan diolah di lokasi data. Hal ini disebabkan karena cara ini lebih efisien dibandingkan jika data yang dikirim terutama untuk data dengan kapasitas besar. Untuk itu dibuatlah suatu aturan transaksi dengan algoritma yang sesuai agar sistem dapat berjalan dengan baik, akurat dan efisien. Universitas Sumatera Utara Setiap SMS terdiri dari header pesan, informasi pengirim dan data. Header pesan terdiri dari 4 bit data biner yang merupakan kode instruksi yang harus dijalankan oleh sistem. Informasi pengirim berisi 4 bit data biner yang merupakan kode pengirim apakah mandor, koordinator atupun tukang dengan keahlian tertentu. Sedangkan data berisi data yang akan dieksekusi. Panjang pesan binari yang dapat dikirimkan dan diterima oleh suatu ponsel bervariasi. Namun secara umum suatu ponsel hanya mampu menerima atau mengirim 133 byte data per sekali SMS. Untuk itu pada sistem ini panjang data pesan maksimal 132 byte karena 1 byte digunakan untuk header + informasi pengirim. Jika panjang data melebihi 132 byte maka pesan akan dikirimkan dalam beberapa sesi dengan kode header tersendiri. Untuk lebih jelasnya, penjelasan header dan kode pengirim dapat dilihat pada Tabel 4.1 dan Tabel 4.2. Universitas Sumatera Utara Tabel 4. 1 Daftar instruksi header pesan Header Pesan Instruksi 0000 Pendaftaran konfirmasi pendaftaran anggota komunitas baru 0001 Konfirmasi penambahan anggota baru kepada anggota komunitas lainnya 0010 Update konfirmasi update data anggota komunitas 0011 Konfirmasi update data anggota komunitas kepada anggota komunitas lainnya 0100 Pesan sambungan jika pesan yang dikirimkan lebih dari kapasitas 1 kali SMS 0101 Cek apakah dapat mengirim token 0110 Konfirmasi token dapat dikirim 0111 Pengiriman token 1000 Trigger untuk membangkitkan token Universitas Sumatera Utara Tabel 4. 2 Informasi kode pengirim Kode Pengirim Penjelasan 0000 Koordinator 0001 Tukang rangka baja 0010 Tukang kayu 0011 Tukang listrik instrumen 0100 Tukang besi 0101 Tukang keramik 0110 Tukang batu 0111 Tukang pipa 1000 Lain-lain 1001 Mandor Setiap header akan membawa data pesan yang berbeda karena setiap header memiliki skenario yang berbeda pula. Penjelasan lebih lanjut tentang data pesan ini Universitas Sumatera Utara akan dibahas pada algoritma aturan transaksi. 4.3. Algoritma Aturan Transaksi Aturan transaksi dibuat agar sistem dapat menjalankan instruksi dengan tepat. Berikut ini akan dibahas tentang algoritma aturan transaksi pada penelitian ini. a. Algoritma pendaftaran anggota komunitas baru Pendaftaran anggota komunitas baru dilakukan oleh tukangmandor yang ingin bergabung dengan komunitas ini dengan cara mengisi formulir pendaftaran yang terdapat pada ponsel mereka yang terdiri dari kolom NoKTP, Nama, Alamat dan Kode Keahlian. Selanjutnya algoritma pendaftaran anggota komunitas baru dapat dilihat di bawah ini. 1. Pertama sistem di ponsel tukangmandor membuat Tabel 3.1. 2. Lalu sistem di ponsel tukangmandor menginput data pribadi tukangmandor ke dalam Tabel 3.1, dimana untuk NoId anggota masih kosong 0 karena menunggu balasan dari ponsel koordinator. 3. Sistem juga membuat sebuah Tabel 3.3, pada baris pertama diisi dengan kode keahlian tukangmandor yang bersangkutan. 4. Kemudian sistem mengirimkan instruksi kepada ponsel mandor yang terdiri dari 4 bit header pendaftaran 0000, 4 bit kode keahlian tukang, dan maksimal 74 byte data pribadi tukang. Universitas Sumatera Utara 5. Menanti konfirmasi dari ponsel koordinator 6. Jika pesan konfirmasi dari ponsel koordinator masuk, sistem akan mengecek pesan yang terdiri dari 4 bit header pesan 0000 + 4 bit kode pengirim koordinator 0000 + Data yang terdiri dari 2 byte NoId tukang, 12 byte dikalikan jumlah anggota yaitu data seluruh data no ponsel tukang yang telah bergabung, 2 byte untuk data jumlah anggota yang memiliki keahlian yang sama dengan tukang, 2 byte dikalikan jumlah anggota dengan keahlian sama yaitu daftar NoId anggota lainnya yang memiliki keahlian yang sama, 1 byte data boolean yaitu konfirmasi apakah pesan bersambung atau tidak, pesan bersambung jika data yang dikirim melebihi 133 byte. 7. Insert NoId ke dalam baris pertama Tabel 3.1. 8. Membuat Tabel 3.2 dan mengisi dengan NoId dan No ponsel seluruh anggota komunitas yang didapat dari ponsel koordinator. 9. Mengisi baris kedua Tabel 3.2 dengan daftar NoId anggota komunitas lainnya yang memiliki kode keahlian tukang yang bersangkutan. 10. Menampilkan pesan konfirmasi kepada user bahwa telah terdaftar sebagai anggota komunitas. b. Algoritma konfirmasi pendaftaran anggota komunitas baru Konfirmasi penerimaan anggota baru dilakukan oleh Universitas Sumatera Utara koordinator setelah mendapatkan pesan dengan header 0000 yang dikirimkan oleh para tukangmandor. Setiap ada anggota komunitas yang bergabung, selain mengkonfirmasi kepada tukangmandor yang mendaftar, koordinator juga harus mengkonfirmasi kepada seluruh anggota komunitas lainnya. Adapun algoritma konfirmasi pendaftaran anggota komunitas baru dapat dilihat pada langkah-langkah berikut ini. 1. Sistem menerima pesan masuk dengan header 0000, sistem lalu memecah pesan yang terdiri dari 4 bit header 0000, 4 bit kode keahlian tukang yang mendaftar dan maksimal 74 byte data pribadi tukangmandor yang mendaftar. Sistem lalu memanggil function anggota daftar;. 2. Sistem menambah record baru pada Tabel 3.2 yang menampung data pribadi anggota yang mendaftar. Nomor record baru inilah yang menjadi NoId bagi tukangmandor yang baru mendaftar tesebut. 3. Sistem mengecek kode keahlian tukang dan membuka Tabel 3.3 pada baris yang sesuai dengan keahlian tukang tersebut. Sistem kemudian memecah isi baris berdasarkan byte array-nya, byte array yang pertama berisi jumlah anggota pada keahlian ini dan yang byte array kedua berisi daftar NoId tukang yang terdapat pada keahlian ini. Isi byte array jumlah anggota di tambah 1 dan isi byte array kedua ditambahkan dengan NoId tukang yang baru terdaftar tersebut. 4. Sistem meng-update Tabel 3.3. Universitas Sumatera Utara 5. Sistem kemudian mengambil seluruh data NoId dan NoPonsel anggota yang ada dalam Tabel 3.2, di tuangkan dalam suatu variabel bertipe string, setiap data ponsel dipisahkan dengan tanda semi colon ;. 6. Sistem juga membuka Tabel 3.3 dan mengambil isi baris yang sesuai dengan kode keahlian tukang. 7. Sistem mengirimkan konfirmasi kepada tukangmandor yang baru mendaftar dengan komposisi pesan : pesan yang terdiri dari 4 bit header pesan 0000 + 4 bit kode pengirim koordinator 0000 + Data yang terdiri dari 2 byte NoId tukang, 12 byte dikalikan jumlah anggota yaitu data seluruh data no ponsel tukang yang telah bergabung, 2 byte untuk data jumlah anggota yang memiliki keahlian yang sama dengan tukang, 2 byte dikalikan jumlah anggota dengan keahlian sama yaitu daftar NoId anggota lainnya yang memiliki keahlian yang sama, 1 byte data boolean yaitu konfirmasi apakah pesan bersambung atau tidak, pesan bersambung jika data yang dikirim melebihi 133 byte. c. Algoritma konfirmasi penambahan anggota baru kepada anggota komunitas lainnya. Setiap ada anggota komunitas yang baru bergabung, koordinator harus mengkonfirmasikannya kepada seluruh anggota komunitas lainnya. Adapun algoritmanya dapat diihat pada penjelasan berikut ini. 1. Sistem di ponsel koordinator membuat suatu paket data yang terdiri dari komposisi pesan yaitu 4 bit header pesan 0001, 4 bit informasi kode pengirim yaitu koordinator 0000, 12 byte yang berisi nomor telepon anggota Universitas Sumatera Utara yang baru bergabung, 2 byte berisi NoId anggota baru tersebut, 2 byte berisi kode keahlian tukang baru, 2 byte berisi jumlah anggota komunitas terbaru untuk kriteria yang sama dengan kode keahlian tukang baru, 2 byte dikalikan jumlah berisi daftar NoId anggota yang memiliki kode keahlian yang sama dengan anggota baru tersebut. 2. Paket data dikirimkan ke seluruh anggota komunitas d. Konfirmasi update data anggota komunitas kepada anggota komunitas lainnya. Setiap menerima paket data dengan header 0001 sistem di ponsel tukangmandor akan melakukan beberapa langkah berikut ini. 1. Membuka paket data. 2. Membuka Tabel 3.2. 3. Menambahkan no ponsel anggota baru kedalam Tabel 3.2. 4. Membuka Tabel 3.3. 5. Membandingkan kode keahlian tukang pemilik ponsel dengan kode keahlian yang dikirim oleh koordinator. Jika kode keahlian sama maka akan dilakukan peng-update-an Tabel 3.3. 6. Jika kode keahlian tidak sama, maka Tabel 3.3 di ponsel tukang tersebut tidak di update. e. Algoritma mengecek apakah dapat mengirim token Peredaran token dimulai dari ponsel koordinator kepada NoId pertama dari Tabel 3.2. Selanjutnya token akan diedarkan oleh NoId pertama Universitas Sumatera Utara ke NoId kedua begitu seterusnya. Sebelum token diedarkan, dilakukan suatu pengecekan untuk memastikan ponsel penerima token dalam keadaan aktif. Algoritmanya dapat dilihat pada penjabaran berikut ini. 1. Buka Tabel 3.2, ambil NoId anggota penerima token. 2. Membuat paket data yang terdiri dari 4 bit header 0101 dan 8 byte data berisi informasi waktu pengiriman token. 3. Menyimpan waktu pengiriman token ke dalam suatu tabel sementara. Menunggu pesan konfirmasi selama 5 menit dengan header 0110. 4. Jika pesan konfirmasi masuk, token dapat dikirim 5. Jika pesan konfirmasi tidak masuk maka diasumsikan ponsel tujuan tidak dapat menerima token dan ponsel akan mengambil NoId selanjutnya dari Tabel 3.2. f. Algoritma konfirmasi token dapat dikirim Ponsel tukangmandor yang menerima paket data dengan header 0101 akan melakukan algoritma sebagai berikut. 1. Membandingkan waktu pengiriman pesan dengan waktu sekarang. 2. Jika selisih waktu pengiriman lebih kecil dari 5 menit, maka ponsel tukangmandor mengirimkan konfirmasi token dapat dikirimkan dengan komposisi pesan 4 bit header 0110. 3. Jika selisih waktu lebih besar dari 5 menit, diasumsikan pesan telah kadaluarsa dan ponsel tukangmandor yang menerima paket ini tidak akan mengirimkan konfirmasi token dapat dikirimkan. Universitas Sumatera Utara g. Algoritma mandor penerima token Ada perbedaaan antara algoritma penerima token untuk mandor dan tukang. Jika mandor menerima token maka mandor akan mengirimkan daftar cari pekerja kepada para tukang yang memiliki kriteria yang sama dengan pekerja yang dicari oleh mandor tersebut. Algoritma mandor penerima token dapat dilihat sebagai berikut. 1. Ponsel mandor menerima pesan dengan header 0111 2. Membuka Tabel 3.5, ambil salah satu record dan melihat kriteria pekerja yang dibutuhkan. 3. Sistem di ponsel mandor kemudian membuka Tabel 3.2. 4. Mengirim salah satu record dari Tabel 3.5 ke semua anggota komunitas yang memiliki kriteria yang sama dengan yang dicari oleh mandor. 5. Sistem kemudian mengirimkan token ke NoId anggota berikutnya. h. Algoritma tukang penerima token Sedangkan jika token diterima oleh tukang maka ponsel tukang akan membandingkan Tabel 3.5 yang dikirimkan oleh mandor dengan Tabel 3.4 yang ada diponselnya. Untuk lebih jelasnya algoritma penerimaan token dapat dilihat sebagai berikut. 1. Ponsel tukang menerima pesan dengan header 0111 2. Sistem di ponsel tukang membuka Tabel 3.4. Universitas Sumatera Utara 3. Sistem membuka Tabel 3.5. 4. Sistem kemudian membandingkan kedua tabel 5. Jika sama, sistem lalu menghapus data pekerjaan di Tabel 3.5 dan menyimpannya ke dalam Tabel 3.6. 6. Sinkronisasikan Tabel 3.6 kepada mandor yang memberikan kerja 7. Sinkronisasikan Tabel 3.5 yang baru kepada semua tukang yang memiliki kriteria yang sama 8. Sistem mengirimkan token ke NoId anggota berikutnya. 4.4. Skenario Sistem Pada sistem ini terdapat beberapa skenario sistem yaitu skenario pendaftaran anggota baru dan skenario pencarian kerjapekerja.

4.4.1. Skenario pendaftaran anggota baru dan update data pribadi

Untuk mendaftar sebagai anggota komunitas maupun untuk meng-update data pribadi, seorang mandortukang dapat menjalakan menu daftarupdate yang terdapat pada ponsel mereka masing-masing. Pengguna sistem akan mendapatkan konfirmasi jika mereka berhasil daftarupdate . Universitas Sumatera Utara Gambar 4.1 Tampilan program pendaftaran anggota Universitas Sumatera Utara Sistem menampilkan transparansi kepada pengguna dengan menyembunyikan kerumitan sistem. Dimana proses yang terjadi sebenarnya adalah SMS untuk daftarupdate dari pengguna akan masuk di port 8888 pada ponsel koordinator, aplikasi akan mengecek 4 bit pertama dari pesan yang merupakan header pesan. Dimana header pesan 0000 merupakan pendaftaran anggota baru dan 0010 untuk meng-update data. Urutan pendaftaran anggota baru diawali dengan tukangmandor mengisi form pendaftaran yang terdapat di ponselnya meliputi nomor KTP, nama, alamat, nomor telepon dan spesifikasi keahliannya. Aplikasi di ponsel tukangmandor akan menyimpan nomor KTP, nama, alamat, nomor telepon di dalam Tabel 3.1 dan mengirim header 0000 + 4 bit kode spesifikasi keahlian tukang ke ponsel koordinator. Setelah mendapatkan pesan ini, ponsel koordinator akan menambahkan data tukangmandor tersebut ke dalam Tabel 3.2 dan membangkitkan sebuah NoId untuk tukangmandor baru tersebut. Aplikasi di ponsel koordinator kemudian akan meng-update Tabel 3.3 dengan cara menambahkan NoId anggota baru tersebut ke dalam baris Tabel 3.3 yang memiliki kode spesifikasi tukang yang sama. Setelah itu aplikasi di ponsel koordinator akan membuat paket pesan yang terdiri dari 4 bit header 0000 + 2 byte NoId tukangmandor yang baru dibangkitkan + isi Tabel 3.2 + fragmentasi Tabel 3.3 yaitu baris tabel yang berisi tentang kode spesifikasi tukang tersebut. Paket data kemudian dikirimkan ke ponsel tukangmandor yang baru Universitas Sumatera Utara mendaftar tersebut. Aplikasi di ponsel tukangmandor akan menyimpan NoId ke dalam Tabel 3.1 dan meng-update Tabel 3.2 serta Tabel 3.3 sesuai dengan pesan yang didapat dari ponsel koordinator. Jika panjang pesan yang dikirimkan lebih dari 133 byte maka pesan akan dikirim dalam beberapa sesi dengan header 0100. Selanjutnya aplikasi di ponsel koordinator juga akan mensinkronisasi perubahan Tabel 3.2 dan Tabel 3.3 kepada seluruh anggota komunitas dengan mengirim pesan yang terdiri dari header 0010 + 3 byte NoId Anggota baru + 4 bit kode keahlian spesifikasi tukang baru tersebut. Anggota komunitas juga dapat mengubah data yang terdapat pada Tabel 3.1 dengan cara memilih update data pada form update yang terdapat di ponsel mereka. Jika data yang diubah adalah nomor KTP, nama dan alamat maka perubahan hanya bersifat lokal yaitu hanya pada Tabel 3.1 di ponsel anggota tersebut. Namun jika yang diubah adalah spesifikasi keahlian maka perubahan harus di sinkronisasikan kepada seluruh anggota komunitas. Untuk proses sinkronisasi, pertama sekali aplikasi di ponsel tukang akan mengirim pesan yang terdiri dari header 0010 + NoId anggota + kode spesifikasi keahlian lama + kode spesifikasi keahlian baru. Selanjutnya ponsel tukangmandor dapat mensinkronisasi Tabel 3.3 berdasarkan pesan ini. Diagram aktivitas dari proses ini dapat dilihat pada Gambar 4.3. Universitas Sumatera Utara Gambar 4.2 Diagram aktivitas penerimaan anggota baru Tukang Mandor Koordinator Menunggu Pesan di port 8888 Cek Header pesan 4 bit pertama Add NoHp pengirim ke Tabel 3.2, NoHp mendapatkan sebuah NoId Mengirim header 0000 + NoId + Tabel 3.2 + fragmentasi Tabel 3.3 Update Tabel 3.3 Baca kode keahlian pengirim 4 bit berikut setelah header Kirim sinkronisasi kepada seluruh anggota lainnya : Header 0011 + NoId + Kode Keahlian lama + kode keahlian baru Update Tabel 3.2 dan Tabel 3.3 Menerima pesan dengan header 0000 [pesan masuk] [pesan tdk masuk] [0010] [0000] Baca NoId pengirim 3 byte berikut, kode keahlian lama 4 bit berikutnya dan kode keahlian baru 4 bit terakhir Update Tabel 3.3 Kirim sinkronisasi kepada seluruh anggota lainnya : Header 0001 + NoId + Kode Keahlian Universitas Sumatera Utara

4.4.2. Skenario sistem pencarian kerja pekerja

Skenario sistem pencarian pekerja dilakukan oleh mandor dengan mengisi suatu form di ponsel mandor. Form tersebut meliputi spesifikasi keahlian pekerja yang dibutuhkan, upah, wilayah kerja, waktu kerja dan jumlah pekerja yang dibutuhkan dimana data ini di simpan dalam Tabel 3.5 pada ponsel mandor. Ketika ponsel mandor mendapatkan giliran token, maka aplikasi di ponsel mandor akan mengirimkan data pada Tabel 3.5 ini ke ponsel para tukang yang memiliki kode spesifikasi keahlian yang sama. Pesan yang dikirim dari aplikasi mandor terdiri dari 4 bit header yaitu pengiriman token 0111 + 4 bit kode mandor yaitu 1001 + 1 byte id_proyek yang terdiri dari NoId mandor digabung dengan autonumber kode proyek + 4 bit kode keahlian yang dicari + 2 bit kode wilayah + 2 bit kode upah + 3 byte tanggal mulai proyek + 3 byte tanggal akhir proyek + 1 byte jumlah yang dibutuhkan. Sehingga total panjang pesan adalah 10 byte. Aplikasi tukang yang menerima akan menyimpannya dalam Tabel 3.6. Seorang tukang dapat menginput kriteria kerja yang dibutuhkannya dengan mengisi sebuah form pencarian kerja yang terdapat pada ponsel tukang Gambar 4.4. Aplikasi di ponsel tukang kemudian akan menyimpan kriteria kerja di dalam tabel 3.4. Ketika ponsel tukang mendapatkan token, maka aplikasi di ponsel tukang akan membandingkan Tabel 3.4 dengan Tabel 3.6 yang ada di ponselnya. Jika sesuai maka ponsel tukang akan melakukan proses sinkronisasi Tabel 3.6 di ponsel mandor yang bersangkutan dan juga kepada ponsel tukang yang memiliki kriteria pekerjaan yang Universitas Sumatera Utara sama. Pesan sinkronisasi yang dikirim meliputi 4 bit header pengiriman token 0111 + 4 kode spesifikasi keahlian + 1 byte Id_proyek + 3 byte NoId pengirim. Diagram aktivitas skenario pencarian kerjapekerja dapat dilihat pada Gambar 4.5. Gambar 4 3 Tampilan program pencarian kerjapekerja Universitas Sumatera Utara Gambar 4.4 Diagram aktivitas pencarian KerjaPekerja Token = salah Mandor Tukang Membandingkan Tabel 3.4 dan Tabel 3.6 Menerima Paket Data Sinkronisasi ke mandor yang memberikan pekerjaan Menyimpan kriteria pekerja dalam Tabel 3.6 Sinkronisasi ke semua tukang yang memiliki kriteria keahlian yang sama Menginput kriteria kerja yang dicari Menyimpan kriteria kerja yang dicari dalam Tabel 3.4 [sama] [berbeda] Token = benar Menginput kriteria pekerja yang dibutuhkan Mengirim kriteria pekerja yang dicari ke semua tukang yg memiliki spesifikasi keahlian yang sama Menyimpan kriteria pekerja dalam Tabel 3.7 Sinkronisasi Tabel 3.7 [Token = benar] [Token = salah] Kirim token ke NoId berikutnya Header 0111 + NoId pengirim Universitas Sumatera Utara

4.4.3. Skenario untuk peredaran token

Peredaran token pertama sekali dipicu oleh sebuah header 1000 yang dikirim oleh ponsel koordinator. Pada skenario P2P database terdistribusi, sebuah ponsel yang mendapatkan token akan menjalankan request yang diminta oleh sistem. Setelah itu ponsel akan mengirimkan paket data yang berisi token + request ke ponsel lainnya. Sebelum mengirimkan paket data, ponsel pengirim terlebih dahulu akan mengirimkan suatu pesan konfirmasi yang memerlukan balasan dari ponsel penerima. Pesan ini dilengkapi dengan tanggal dan waktu pengiriman pesan. Jika ponsel menerima dalam keadaan aktif, maka ponsel penerima akan segera membalas pesan ini. Ketika ponsel pengirim menerima balasan pesan, ini menandakan ponsel penerima dalam keadaan aktif dan dapat menerima paket data. Jika ponsel penerima dalam keadaan tidak aktif off maka pesan yang dikirim oleh ponsel pengirim tidak akan direspon. Ponsel pengirim akan menunggu sampai satuan waktu tertentu, lalu akan mengirimkan pesan ke nomor telepon NoId tukang berikutnya dari Tabel 3.2. Jika pesan berbalas, maka paket data akan dikirimkan ke NoId tukang ini. Untuk ponsel yang tadinya tidak aktif ketika ponselnya kembali aktif, ponsel akan mencocokkan waktu pesan yang dikirim dengan waktu saat ponsel aktif. Jika waktu telah melebihi suatu satuan waktu yang ditentukan maka ponsel akan mengirimkan request ke koordinator untuk meminta sinkronisasi database terbaru. Diagram aktivitas untuk. Universitas Sumatera Utara Menerima token menjalankan request Membuat paket data baru : token + request baru Kirim paket data Ambil No Telepon penerima token selanjutnya Kirim pesan konfirmasi Kirim pesan konfirmasi ponsel penerima aktif Request ke koordinator utk sinkronisasi database Menunggu balasan pesan konfirmasi Menerima pesan konfirmasi Menerima paket data Cek waktu pengiriman pesan menerima pesan [Waktu sesuai] [Waktu tidak sesuai] [Waktu sesuai] [waktu habis] Ponsel Pengirim token Ponsel Penerima Token Gambar 4.5 Diagram aktivitas peredaran token Universitas Sumatera Utara 4.5. Analisis Hasil Perancangan Sistem Analisis hasil perancangan sistem dilakukan untuk melihat apakah sistem dapat berjalan dengan baik atau tidak untuk suatu kondisi tertentu. Beberapa skenario pengujian dilakukan untuk mendapatkan hasil analisis.

4.5.1. Analisis skenario pengujian sistem

Sistem telah diujicobakan dengan menggunakan emulator tipe defaultPhoneColor, dengan spesifikasi MIDP 2.0, CLDC 1.0. Beberapa skenario pengujian untuk berbagai keadaan dilakukan untuk melihat kehandalan sistem. a. Ujicoba sistem dengan kondisi seluruh ponsel anggota komunitas dalam keadaan aktif. Hasil ujicoba menunjukkan sistem berjalan dengan baik dan sesuai dengan yang diharapkan. Namun ada persyaratan yang harus dipenuhi yaitu semua ponsel harus memiliki pewaktuan yang sama. Peredaran token dilakukandengan membandingkan waktu keadatangan token dan waktu penerimaan token, jika selisih waktu kedatangan dan penerimaan token tidak melebihi 5 menit maka token dapat diakses. Oleh sebab itu jika pewaktuan antara satu ponsel dengan ponsel lainnya tidak seragam maka sistem tidak berjalan sebagaimana mestinya. Universitas Sumatera Utara b. Ujicoba sistem dengan kondisi ada ponsel anggota komunitas yang tidak aktif. Jika ada satu atau beberapa ponsel anggota komunitas tidak aktif, maka sistem tetap dapat berjalan. Namun peredaran token berjalan lebih lambat jika dibandingkan peredaran token ketika semua ponsel anggota komunitas dalam keadaan aktif. Hal ini disebabkan karena sistem akan menunggu respon konfirmasi selama 5 menit. Waktu keterlambatan peredaran token adalah 5 menit dikalikan dengan jumlah ponsel yang tidak aktif. Berdasarkan hasil analisis skenario pengujian sistem maka dapat disimpulkan sistem berjalan dengan baik dan sesuai dengan yang diharapkan sehingga jika sistem berbasis ponsel ini diterapkan dapat meningkatkan kesempatan kerja bagi pekerja informal pada area pekerjaan lebih luas, lebih cepat, dan lebih sesuai dengan keahlian dibandingkan dengan sistem pencarian kerja tradisional sistem dari mulut ke mulut.

4.5.2. Analisis MIDlet tidak dapat berjalan bersamaan dengan fungsi umum ponsel

Untuk menjalankan sistem MIDlet atau aplikasi sistem pencarian kerja ini harus dalam keadaan aktif running. Karena sistem ponsel CLDC masih bersifat single tasking maka jika MIDlet sistem ini diaktifkan akan mengakibatkan fungsi ponsel lain seperti voice, bermain games dan lain sebagainya tidak dapat dilakukan lagi. Universitas Sumatera Utara

4.5.3. Analisis beban jumlah ponsel

Semakin banyak ponsel tukangmandor yang bergabung dalam sistem ini akan memperbesar kesempatan tukangmandor memperoleh pekerjaanpekerja yang sesuai kriteria pencarian. Namun dengan semakin banyaknya anggota komunitas juga berdampak dengan semakin lama waktu yang dibutuhkan untuk 1 kali putaran token. Jika waktu yang dibutuhkan untuk 1 kali SMS sebesar x menit maka untuk 100 anggota komunitas akan membutuhkan 100 dikalikan x menit untuk 1 kali putaran token. Lamanya waktu putaran token tidak berpengaruh terhadap kesempatan seorang tukangmandor mendapatkan pekerjaan. Seorang anggota komunitas pada posisi ke 1 menerima token akan mendapatkan kesempatan yang sama dengan anggota komunitas pada posisi ke X. Hal ini disebabkan mandor dan tukang menempati posisi NoId yang tidak beraturan. Seorang mandor jika mendapatkan giliran token akan mengirimkan kriteria pekerja yang dibutuhkan ke para tukang. Tukang berkesempatan membandingkan kriteria yang dikirimkan mandor tersebut dengan kriteria dirinya jika hanya mendapatkan giliran token. Sehingga tukang pertama yang dapat membandingkan kriteria tersebut adalah tukang yang posisi NoId nya berada setelah NoId Mandor tersebut.

4.5.4. Analisis kapasitas ruang persisten kosong yang harus disediakan Ponsel

Agar sistem dapat berjalan dengan baik, ponsel harus menyediakan ruang Universitas Sumatera Utara persisten atau ruang memori lokal pada ponsel untuk penyimpanan data. Ada sedikit perbedaan antara ponsel mandor, tukang dan koordinator. Berikut ini dijabarkan perhitungan batas minimum penyediaan ruang persisten di ponsel jika diasumsikan jumlah anggota komunitas sebanyak 100 orang. a. Ponsel Koordinator Ponsel koordinator menyimpan 3 tabel yaitu Tabel 3.1, Tabel 3.2 dan Tabel 3.3. Tabel 3.1 terdiri dari 5 field yaitu NoId 2 byte, NoKTP 12 byte, Nama 20 byte, Alamat 30 byte sehingga untuk record 1 orang anggota dibutuhkan kapasitas penyimpanan sekitar 64 byte dan untuk 100 orang dibutuhkan 64 byte dikalikan 100 yaitu 640 byte . Tabel 3.3 terdiri dari 2 field yaitu Kode Keahlian 4 bit dan Daftar NoId 2 byte dikalikan jumlah anggota, ponsel koordinator menyimpan semua spesifikasi tukang 11 spesifikasi sehingga dibutuhkan ruang persisten kosong untuk field Kode Keahlian 11 dikalikan 4 bit = 5.5 byte. Sedangkan untuk field Daftar NoId dibutuhkan kapasistas 2 byte dikalikan 100 = 200 byte. Selanjutnya untuk Tabel 3.2 terdiri dari 2 field yaitu NoId 2 byte dan field NoPonsel 12 byte sehingga untuk 1 record anggota dibutuhkan 14 byte dan untuk 100 record anggota dibutuhkan 140 byte. Berdasarkan perhitungan di atas untuk ponsel koordinator dengan jumlah anggota komunitas sebanyak 100 orang dibutuhkan minimum space kosong sebesar 640 byte + 205.5 byte + 140 byte = 985.5 byte atau setara dengan 0.96 Kilobyte ≈ 1 Kilobyte. Universitas Sumatera Utara b. Ponsel Mandor Ponsel Mandor terdiri dari 5 tabel yaitu Tabel 3.1, Tabel 3.2, Tabel 3.3, Tabel 3.5 dan Tabel 3.7. Tabel 3.1 terdiri dari 5 field yaitu NoId 2 byte, NoKTP 12 byte, Nama 20 byte, Alamat 30 byte, mandor hanya menyimpan record pribadi dirinya saja sehingga untuk tabel ini dibutuhkan kapasitas penyimpanan sekitar 64 byte. Tabel 3.7 terdiri dari 6 field yaitu Id Proyek 1 byte, NoId 2 byte, wilayah 2 bit, upah 2 bit, Tgl Mulai 3 byte dan Tgl Akhir 3 byte sehingga untuk 1 record Daftar Pekerja dibutuhkan kapasitas memori sebesar 9.5 byte. Diasumsikan dalam satu putaran token mandor dapat memperoleh 20 orang pekerja sehingga dibutuhkan kapasitas memori sebesar 9.5 byte dikalikan 20 = 190 byte. Tabel Cari Pekerja terdiri dari 7 field yaitu id proyek 1 byte, Kode Keahlian 4 bit, Wilayah 2 bit, Upah 2 bit, Tgl Mulai 3 byte, Tgl Akhir 3 byte dan Jumlah 1 byte untuk 1 record tabel ini membutuhkan kapasitas penyimpanan sebesar 9 byte. Jika diasumsikan seorang mandor hanya dapat mencari pekerja sebanyak 20 kriteria maka jumlah kapasita penyimpanan yang dibutuhkan sebesar 9 dikalikan 20 = 180 byte. Untuk Tabel 3.3, sama seperti ponsel koordinator, seorang mandor harus menyimpan semua data spesifikasi tukang sehingga untuk tabel ini dibutuhkan 205.5 byte. Untuk Tabel Anggota terdiri dari 2 field yaitu NoId 2 byte dan No Ponsel 12 byte sehingga untuk 1 record dibutuhkan kapasitas penyimpanan sebesar 14 byte dan untuk 100 record anggota dibutuhkan 140 byte. Berdasarkan perhitungan di atas untuk ponsel mandor dengan jumlah Universitas Sumatera Utara anggota komunitas sebanyak 100 orang dibutuhkan minimum space persisten kosong sebesar 64 byte + 190 byte + 180 byte + 205.5 byte + 140 byte = 779.5 byte atau setara dengan 0.76 Kilobyte . c. Ponsel Tukang Ponsel tukang terdiri dari 5 buah tabel yaitu Tabel 3.1, Tabel 3.2, Tabel 3.3, Tabel 3.5 dan Tabel 3.6. Serupa dengan ponsel mandor untuk Tabel 3.1 seorang tukang hanya menyimpan data pribadi miliknya saja sehingga dibutuhkan kapasitas penyimpanan sebesar 64 byte. Tabel 3.6 pada ponsel tukang memiliki field yang sama seperti pada ponsel mandor, jika diasumsikan jumlah record untuk tabel ini adalah 20 record maka besarnya kapasitas yang dibutuhkan untuk tabel ini sebesar 180 byte. Tabel 3.5 terdiri dari 4 fields yaitu wilayah 4 bit, upah 2 bit, Tgl Mulai 3 byte dan Tgl Akhir 3 byte jika diasumsikan pada satu putaran pencarian kerja, seorang tukang hanya diizinkan mencari pekerjaan sebanyak 20 buah kriteria pekerjaan maka kapasitas ruang penyimpanan untuk tabel ini sebesar 6.75 byte dikalikan 20 = 135 byte. Tabel 3.3 terdiri dari 2 fields yaitu Kode Keahlian 4 bit dan Daftar NoId 2 byte, sehingga besarnya kapasitas memori yang dibutuhkan untuk tabel ini adalah 4 bit + 2 byte dikalikan 100 = 200.05 byte. Untuk perhitungan Tabel Anggota sama seperti perhitungan kapasitas pada Tabel 3.2 untuk ponsel Mandor yaitu 140 byte. Berdasarkan perhitungan di atas untuk ponsel tukang dengan jumlah anggota komunitas sebanyak 100 orang dibutuhkan minimum space persisten kosong sebesar 64 Universitas Sumatera Utara byte + 180 byte + 135 + 200.05 byte + 140 byte = 719.05 byte atau setara dengan 0.70 Kilobyte.

4.5.5. Analisis kelebihan dan kelemahan sistem

Sistem ini memiliki beberapa kelebihan dibandingkan dengan sistem yang menggunakan server terpusat. Diantaranya sistem tidak membutuhkan biaya pengadaan dan perawatan server, sistem tetap dapat berjalan walaupun ada ponsel yang tidak aktif, ketersediaan data lebih terjamin dengan adanya proses fragmentasi dan juga replikasi. Selain itu sistem ini menjamin setiap ponsel memiliki kesempatan yang sama untuk mengakses sistem dan tidak akan terjadi bottleneck. Sistem ini juga memiliki beberapa kekurangan jika dibandingkan dengan sistem yang menggunakan server terpusat. Diantaranya pemrograman yang lebih sukar, instalasi program yang lebih sukar, membutuhkan biaya SMS untuk menjalankan sistem dan keamanan data yang lebih rentan. Universitas Sumatera Utara

BAB 5 KESIMPULAN DAN SARAN