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