Sistem Informasi Lalu-lintas

Sistem Informasi Lalu-lintas

Sabtu, 01 September 2012

system berikut sebenarnya merupakan sebuah sub-system dari main-system yang sudah ada, system ini dibangun dengan tujuan untuk membantu para petugas dalam pengelolaan surat pengantar mutasi SIM (surat ijin mengemudi). contoh: dari jakarta ke daerah.. 

knapa dipilih title demikian, karena untuk membantu perbendaharaan entitas dalam pembangunan sistem ini. lagipula, jika title yang dipilih adalah: sistem informasi surat pengantar mutasi SIM, sudah tentu terlalu panjang bukan? =D 

daftar aktor

gambar: aktor yang dibutuhkan dalam scenario ini..

sbenarnya dalam scenario ini kebutuhan bukan untuk scope besar, hanya operator yang berperan sebagai end-user saja yang menjalankan program. dalam UML (unified modeling language) aktor yang non-human suatu saat akan dibutuhkan, contoh ketika sistem dapat beradaptasi dengan sistem dari luar (dengan device misalnya).

scenario yang dibutuhkan

gambar: kebutuhan masih sangat sederhana..

just info:

kadang sesuatu jika tidak dimulai dari yang sederhana akan lama tumbuh, untuk itu belum terlambat jika dimulai dari sekarang. sbenarnya main system dari lalu-lintas ini sudah berjalan cukup lama di Indonesia, konon sudah dimulai sejak jaman presiden soeharto dulu. sistem diAdaptasi dari luar negri..

jadi sistem yang nantinya akan dibangun ini hanya merupakan sub-system dari main yang sudah ada.

pengelolaan surat pengantar

gambar: pengelolaan surat pengantar dan spesialisasinya..

seperti biasa, DML (data manipulation language) yang ada di SQL diImplementasikan: proses seleksi data, pengubahan dan penghapusan untuk data yang mungkin sudah tidak dipakai. bagi para pemrogram web biasanya menyebutnya: CRUD (create, update, delete).

memang aga susah untuk membuat behavior CRUD ini, terutama untuk table transaksi. mungkin sebagian sudah ada yang berhasil membuatnya..

proses seleksi data pada pelaporan sbenarnya menggunakan perintah yang sama, untuk itu scenario ini hanyalah pengembangan dari yang sudah ada. perintah pada SQL-nya adalah: SELECT.

pengelolaan kontak

gambar: tidak ada pelaporan untuk data master kontak..

karena bukan transaksi, dirasa tidak perlu untuk memuat scenario pelaporan mengenai kontak. yang penting pemakai dapat melakukan pencarian dengan kriteria tertentu. sama halnya dengan pattern sebelumnya, proses pencetakan data merupakan ekstensi dari pencarian. 

contoh implementasi dari ekstensi yang dimaksud adalah:  
misalnya DML yang digunakan adalah SELECT, ekstensi dari proses seleksi data ini adalah dengan ditambahkannya clausa WHERE. pada saat pengKodean nanti, cukup tambahkan parameter apakah user memerlukan filtering tertentu atau hanya memerlukan seleksi data sederhana.

pengelolaan sistem

gambar: proses pencarian tidak diEkstensikan pada scenario ini..

untuk proses pengelolaan sistem juga masih sederhana yang dibutuhkan, hanya pengelolaan pemakai akhir dari sistem dan kebutuhan pencetakan data. mungkin pada sistem yang lebih kompleks pengaturan ini akan menjelma menjadi gurita raksasa.. (ini masih bayi gurita!) =D

untuk sistem informasi dalam skala besar biasanya user benar-benar dapat mengCustomize system, bahkan sampai ke theme, color, maupun fitur lainnya.

informasi

gambar: generalisasi pada informasi mengenai suatu sistem tertentu..

walaupun bukan merupakan kbutuhan primary, tapi informasi mengenai suatu sistem tertentu dapat sangat berguna: contoh kebijakan privasi tertentu jika perusahaan memiliki legal dan sebaginya..

overview penggunaan sistem

gambar: harus log terlebih dahulu untuk mulai menggunakan sistem..

proses log ke sistem sama seperti log pada umumnya, namun yang berbeda adalah pada pengelolaan privileges yang digunakan adalah layer database. untuk keperluan pengelolaan dalam lingkup yang lebih luas banyak pengguna yang diKelompokkan ke dalam suatu grup pengguna. 

beberapa pattern pengelolaan sistem di atas dapat juga digunakan pada sistem informasi yang lain.

kita break sejenak, see ya then.. =)

Minggu, 02 September 2012

kita lanjut lagi, kali ini melangkah ke class diagram. sbenarnya tahapan dalam analisa bagi tiap orang mungkin berbeda, namun sekali lagi: setiap orang memiliki style masing-masing, jadi kembali pada preferensi yang dianggap paling sederhana untuk dikerjakan.

untuk saya: biasanya setelah melakukan analisa dengan use-case diagram melangkah ke class-diagram. 

Kebutuhan Entitas Global

requirement gathering:
sebuah proses penggalian informasi dari client yang biasanya didapat pada saat wawancara, hasil dari wawancara ini dapat berbentuk: entitas, enumerasi, peran, atau hanya sekedar relasional antar entitas. caranya cukup mudah: tangkap semua objek dari hasil wawancara, tampung semua, kemudian baru dipilah dan dikelompokkan sesuai dengan porsinya.

gambar: kebutuhan entitas global

hasil dari wawancara kemarin dengan client, ada beberapa hal yang cukup unik; contoh: entitas yang saya beri stereotype LookUp. tabel yang nantinya memuat daftar yang cukup dipilih pada saat entry data, jadi user tidak perlu mengetik full data tersebut. 

agregasi entitas pada system

gambar: agregasi entitas system

hanya ada dua komposisi pada system ini, kontak dan surat pengantar. ini merupakan entitas yang berelasi langsung dengan entitas lembaga, dan 1 (satu) komposisi pada surat pengantar, yaitu: rincian dari surat pengantar itu sendiri. 

relasi entitas pada kontak

gambar: relasi entitas pada kontak

relasi pada entitas kontak cukup banyak, karena kontak memuat hampir seluruh entitas yang ada. walaupun kontak merupakan data master, tapi sesuai dengan standarisasi dari uml bahwa: objek harus dapat berdiri sendiri dan tidak memuat informasi dari entitas lain kecuali jika entitas tersebut berelasi dengan yang lainnya.

relasi entitas pada surat pengantar

gambar: relasi entitas pada surat pengantar

pada proses surat pengantar ada juga hal unik yang ditemukan: peran pada entitas kontak, dalam scenario ini kontak dapat berperan sebagai petugas entry data, pejabat yang mengesahkan surat tersebut dan pemohon yang mengajukan surat. hal ini merupakan implementasi dari generalisasi kontak, berbentuk flag unik yang lahir sebagai enumerasi yang membedakan kontak dalam memainkan perannya.

nah.. selesai deh analisa tahap ke-dua: analisis model. nanti kalo ada temuan terbaru, artikel akan terus diUpdate. =)

Senin, 03 September 2012

selamat pagi.. 

ada beberapa revisi sedikit pada capture sebelumnya, yaitu: entitas jenis SIM (surat ijin mengemudi). entitas ini memberikan flag unik pada entitas SuratIjinMengemudi..

hari ini sebagai hasil dari tahap analisa entitas wujudnya adalah diagram ERD (entity relationShip diagram) berikut:

gambar: entity relationShip diagram..

demikian, terima kasih.

Masih di Hari Senin 03 September 2012 Jam 6 Pagi lewat 23 menit.. lanjut sebentar ya? =)

Perancangan AntarMuka Pengguna

berikut adalah hasil dari analisa sebelumnya, kita sekarang ada di tahap perancangan. perancangan yang diMaksud adalah perancangan formulir antarMuka untuk pengguna akhir mengAkses atau meManipulasi data.

Lembaga

gambar: Formulir Lembaga..

antarMuka pertama sudah tentu identitas mengenai lembaga, instansi (atau perusahaan) di mana tempat sistem diImplementaskan. biasanya formulir identitas ini juga dapat dimanfaatkan oleh sebagian pengembang untuk meRegister lisensi pengguna, jadi setelah pengguna melengkapi identitas yang ada untuk pertama kali, mereka tidak perlu melakukan registrasi untuk selanjutnya.

Kontak

gambar: Formulir Kontak..

formulir data master disajikan dalam pattern yang sama: dapat melakukan seleksi data, penambahan data, pengubahan maupun penghapusan. seperti yang telah dijelaskan sebelumnya bahwa pattern biasa disebut dengan CRUD (create, update dan delete) oleh para pengembang pemrograman berbasis web.

Kontak - Editing

gambar: Formulir Kontak Edit..

untuk keperluan manipulasi di atas, dibuatkan formulir editing yang fungsinya diGeneralisasikan menjadi 1 (satu) form saja. cukup berikan parameter untuk ia mengetahui apakah pengguna sedang melakukan penambahan data atau sedang melakukan pengubahan data.

berhubung keterbatasan waktu, perancangan antarMuka grafis ini akan dilanjutkan next.. fiuh.. sayang ya? padahal lagi seru-serunya nih! =D

Selasa, 04 September 2012

Revisi pada Kontak

ada beberapa revisi pada master data kontak, di antaranya adalah:

jumlah kolom pada grid disederhanakan, dirasakan terlalu banyak jumlah kolom yang ditampilkan; toh para pengguna juga tidak akan menggunakan semua kolom yang tersedia, jika mereka ingin menampilkan informasi yang lebih rinci maka dapat diakses dengan form editing.

pada form editing jumlah field disederhanakan dan dikelompokkan pada pageFrame, tujuan dari revisi ini adalah agar para pengguna juga tidak diberikan informasi yang terlalu banyak dan agar informasi yang disampaikan juga lebih tepat.

gambar: master data kontak yang diRevisi..

jika jumlah kolom yang ditampilkan seperti di atas, diharapkan pengguna tidak dibuat bingung dengan jumlah informasi yang berlebihan. pilih salah satu record yang diinginkan kemudian tekan tombol ubah untuk melihat informasi lebih rinci mengenai kontak tertentu.

gambar: form editing kontak yang dikelompokkan pada pageFrame..

pada form editing juga dikelompokkan menjadi:

• biodata
• domisili
• pekerjaan dan
• lain-lain

untuk lebih lanjut dapat diperhatikan pada ilustrasi berikut untuk tiap page-nya:

gambar: informasi pada page domisili

untuk sistem yang lebih kompleks, mungkin informasi yang ditampilkan di page domisili ini akan lebih banyak. dalam program ini karena request dari client demikian, tentu kita tidak akan memberikan informasi yang kadang-kadang tidak mereka butuhkan bukan?

gambar: informasi pada page pekerjaan

hanya ada satu kolom pada page ini, yaitu: pekerjaan. hanya memuat informasi mengenai pekerjaan dari kontak yang bersangkutan. silahkan mengembangkan jika memang dibutuhkan..

gambar: informasi pada page lain-lain

biasanya pada page ini dapat ditambahkan photo terbaru atau informasi tambahan apa pun di luar informasi utama dari kontak.

demikian revisi sampai dengan saat ini.

Jumat, 07 September 2012

hm.. seharusnya dari kmaren dah mo diUpload pnambahan ini, cuma karena blom sempet. ya udah, hari ini aja kita upload. pnambahannya ada di form editing master data kontak, di mana sesuai dengan scenario yang ada bahwa kontak memiliki relasi dengan SIM (surat ijin mengemudi). 

gambar: dalam scenario disebutkan bahwa seorang kontak memiliki SIM (surat ijin mengemudi)

dalam relasi ini seorang kontak tampil dengan memiliki 1 (satu) SIM, katakan SIM C. namun, bisa jadi seseorang memiliki lebih dari 1 (satu) SIM. karena untuk sementara yang diperoleh dari request client adalah demikian, maka dirancang seperti ini terlebih dahulu. jika ditemukan kebutuhan lebih dari 1 (satu) akan diRevisi kemudian.

Entitas dengan StereoType LookUp

banyak LookUp yang dapat diperoleh dalam sistem ini, tujuannya untuk mempermudah pada saat operator melakukan entry data. mereka hanya tinggal pickUp data dari TextBox seperti LiveSearch pada google. beberapa LookUp yang didapat di antaranya:

• pekerjaan
• kelurahan
• kecamatan
• kabupaten
• polRes

Pekerjaan

gambar: formulir utama pada master data pekerjaan

pattern dari master data hanya memiliki 2 (dua) formulir, yaitu: formulir utama dan editing-nya. pattern ini akan berlaku untuk semua master data, kecuali jika dibutuhkan lebih dari ini. maka akan ditambahkan sesuai dengan kebutuhan.

gambar: formulir editing dari master data pekerjaan

karena hanya untuk mengkoleksi kumpulan data yang akan digunakan untuk LookUp nantinya, rasanya tidak perlu untuk membuat fasilitas yang terlalu berlebihan. cukup kolom dari LookUp tersebut dan tambahkan keterangan agar dapat diperoleh informasi tambahan mengenai suatu LookUp.

hm.. akan kita lanjutkan lagi nanti.

gambar: formulir master data kelurahan, memiliki konsep yang sama seperti master data lainnya.

kita lanjutkan lagi ya? =)

sama seperti master data sebelumnya, pada master data kelurahan ini terdapat juga formulir editing-nya. sebagian perancang yang lain kadang menempatkan master data untuk keperluan LookUp sebagai table native yang disimpan di local storage, tujuannya agar pada saat diQuery proses jadi lebih cepat.

gambar: master data kecamatan

gambar: master data kabupaten.

gambar: master data polRes.

tampaknya tidak ada yang perlu dibahas lebih rinci mengenai beberapa master data di atas, sebab konsep formulir utama dan editing hampir sama dengan sebelumnya.

demikian perancangan master data, yang dibutuhkan sudah cukup. selanjutnya kita akan melangkah ke transaksi. transaksi yang dimaksud adalah: pengelolaan surat pengantar. surat pengantar ini bertujuan untuk para pemohon SIM yang ingin mengajukan mutasi wilayah, contoh: dari jakarta ke daerah misalnya.

Sabtu, 08 September 2012

Perancangan Transaksi

sekarang kita masuk ke perancangan transaksi, transaksi pengelolaan surat pengantar mutasi. apa yang membedakan antara master data dengan transaksi? pada transaksi, relasi terbentuk dari banyak entitas. bukannya master data itu tidak memiliki relasi, pada master data relasi lebih sedikit. transaksi juga memuat informasi mengenai kejadian historis, biasanya terdapat kolom tanggal kapan event itu terjadi. biasanya pada scenario transaksi juga ada aktor yang berperan. mengenai deskripsi yang tepat tentang transaksi itu sendiri mungkin dapat dicari pada referensi yang lebih luas di internet.

gambar: form utama pada transaksi pengelolaan surat pengantar mutasi.

jangan terlalu banyak memuat informasi pada form utama, pengguna akan dirugikan jika kolom yang ditampilkan berlebihan. cukup poin penting, sisanya dapat dilihat lebih rinci nantinya pada formulir editing. pada tampilan utama ini hanya kolom berikut yang ditampilkan:

• tanggal pada saat surat dibuat,
• nomor surat yang dibuat dan,
• siapa pemohon surat tersebut.

nanti dilanjutkan lagi ya?

Rabu, 12 September 2012 Jam 3 Pagi..

kita hampir mendekati penyelesaian pekerjaan, tinggal beberapa langkah lagi yang harus dilalui. mungkin sistem informasi ini dapat mencakup ruang lingkup yang lebih luas nantinya, namun kali ini request dari client adalah cukup pada pengelolaan surat pengantar mutasi SIM. 

gambar: form editing pada transaksi pengelolaan mutasi SIM.

terdapat dua page yang ditampilkan:

• biodata dan
• surat ijin mengemudi

gambar: form editing pada pengelolaan mutasi SIM - page selanjutnya.

demikian, sudah ditampilkan semua perancangan formulir (baik data master maupun transaksi). sesuai dengan analisa yang ada, semua kebutuhan scenario sudah diAkomodir. analisa lebih mendalam akan dilanjutkan nanti jika kebutuhan akan hal itu dirasakan. dari 2 tahap analisa yang ada: use-case dan class diagram sudah dapat membentuk perancangan ini.

Revisi pada Kontak

ada revisi pada data master kontak, sesuai dengan analisa yang ada bahwa: pada saat SIM dibuat, tanggalnya harus ditampilkan. sebab, tanggal itu memuat kapan SIM dikeluarkan. oleh karena itu, pada page SIM di form editing kontak ditambahkan kolom tanggal SIM.

gambar: ditambahkan kolom tanggal SIM dikeluarkan..

pada perancangan output nanti, selain tanggal kadaluarsa diperlukan juga tanggal kapan SIM dibuat.

Perancangan Keluaran

gambar: hasil keluaran sistem.

selesai sudah untuk sesi kali ini: sistem pengelolaan surat pengantar mutasi SIM dengan ditampilkannya hasil keluaran ini. semua perancangan baik itu master data maupun transaksi dirancang berdasarkan hasil akhir ini, walaupun terlihat sederhana: tetapi selalu tidak se-sederhana itu. 

demikian, terima kasih.