Pengembangan Sistem Berbasis Komponen Posted on : 7/12/2007 04:37:00 PM

Salah satu hal yang menjadi tanggung jawab seorang software-arsitek adalah ketika merencanakan arsitektur software yang akan dikonstruksi. Dalam perencanaan pengembangan sistem (ini beda dengan perencanaan arsitektur) dan analisis requirements, SA udah banyak mengakuisisi banyak fakta yang bisa dijadikan bahan utk merancang arsitektur. Selayaknya arsitek bangunan yang survey lahan, lokasi, tanah, dan permintaan - seorang software arsitek juga mempelajari semua kondisi riil di lapangan, keperluan-keperluan nya, de-el-el - lalu mulailah dia merencanakan arsitektur software.

Nah, tantangan yang pertama SA hadapi dalam perencanaan arsitekturnya umumnya gini : gimana memilah-milah mana requirements yang merupakan KEBUTUHAN user dan mana yang *sebenarnya* hanya KEINGINAN user... - kadang klo kita nanya2 ke (calon) user tentang aplikasi *yang akan* dikembangkan ini kebutuhan dasarnya apa, yang dijawab sama dia justru *keinginan-keinginannya*. Dan kadang, pas sesi interview, saking semangatnya si (calon) user tersebut ceritain *imajinasinya*, ngga 100% kebutuhan dia akan sistem tersampaikan dari dia...

Kebutuhan dan keinginan itulah yang nantinya akan mempengaruhi kerangka perencanaan arsitektur sistem. Jika semua keinginan user *akhirnya* di-implementasikan semua, ada kemungkinan fungsionalitas sistem tidak akan optimal, walo bukan berarti tidak mungkin optimal. Bisa saja sih optimal...

Tapi, sebaiknya kita memperhatikan konsepsi-konsepsi dasar orientasi pengembangan aplikasi perangkat lunak (software), yaitu aplikasi sistem yang akan dibuat sebaiknya FOKUS ke fungsi utamanya. Sekarang coba liat gini : kenapa aplikasi MS Word ngga bisa nyetel musik? Tanya kenapa? Karena fungsi MS Word emang difokuskan untuk text editor...

Sama saja dengan aplikasi yang akan dikembangkan... Misal, pengembangan sistem informasi perpustakaan (...contoh...), ada fasilitas pendaftaran anggota plus cetak kartu. Aplikasi menyediakan kemampuan utk menyimpan foto anggota perpus... Trus pas implementasi, salah satu petugas perpus (end-user nih) request gini : "Mas, ngga bisa kah dibuat supaya habis njepret muka anggota baru lewat camdig, tu foto langsung masuk ke form pendaftaran jd ngga perlu lagi nge-browse-nge-browse gambar, etc-etc..."

Kadang mereka (end-user) suka mendramatisir arti kata otomatisasi. Mungkin (bisa jadi) ini dikarenakan staf marketing kita pas presentasi dan penawaran (pra-produksi) yang mengobral kata-kata otomatisasi itu. "Oh pak, ntar laporannya secara otomatis akan dibuatkan oleh aplikasi." ato "O nanti bapak ngga perlu lagi nyatet2 judul buku yg dipinjem etc-etc, itu secara OTOMATIS udah dicarikan sama program aplikasi pak..." ato "penghitungan denda juga ngga perlu repot2 lagi pak, udah otomatis ditangani ama aplikasi"... - dan akhirnya, tertanamlah di benak user bahwa *sakti* banget aplikasi yang mo dibeli kantor ku nieh... apa-apa os-tos-mas-tis brooo....

Nah, ketika imple, yang kena batunya kita selaku developer aplikasi. Pas bayangan tentang otomatisasi itu *dipertanyakan* sama user, koq step-by-step nya banyak yaa, musti buka ACDSee utk acquire dari camdig, trus di cropping biar pas ukurannya pake ACDSee Photo Editor, trus di save as, baru dari aplikasi di browse foto yang udah dicropping itu n baru bisa masuk deh ke database... - ngga salah user mempertanyakan *dimana letak* otomatisasinya itu...

Oke, cukup sampe di sini kita ngerasanin petugas perpus itu... dia ngga dosa apa2 ^_^ Sekarang kita kembali ke perspektif Software-Arsitek.

Seandainya mau berakit-rakit ke hulu (minus bersenang-senang selalu), membuat SEMUA keinginan user itu bukanlah hal yang tidak mungkin. Bisa koq! Kalopun belum nemu, bisa dicari koq... Mau acquire langsung dr camdig, bisa. Mo langsung cropping setelah acquire, bisa! Tapi, kalo programmer-programmer (baca : tukang bangunannya sang software-arsitek) itu disuruh mbikin fasilitas itu, kapan mengkonstruksi aspek-aspek fungsional dari aplikasinya?

Makanya itu, software arsitek yang baik dan budiman seharusnya :

1. mempunyai/membentuk satu tim sendiri yang khusus bertindak sebagai Riset & Development. kerjaannya, suruh tim itu utk bikin gadget (istilah dari google utk menyebut fasilitas-fasilitas kecil yang bisa di-embedd seketika ke aplikasi). fokusnya bukan ke fungsional,tapi ke arah mendukung operasional.
   
2. berhati-hati dalam mengabulkan permintaan (calon) user dalam perancangan arsitekturnya... kenali kebutuhannya, identifikasi keinginannya. Trus susun prioritas, ngga semua yang kita inginkan harus kita dapatkan, bukan?
3. merencanakan arsitektur aplikasi yang akan didesain dengan perspektif pengembangan berbasis komponen... Maksutnya, pisah-pisahkanlah aspek2 fungsional dari keseluruhan sistem, dan kembangkanlah masing-masing secara independen namun tetap mengacu pada grand-design yang udah direncanakan... hal ini suatu saat akan membantu dalam fase konstruksi. Contohnya gini deh (ngga sreg rasanya klo ngga ngasih contoh) : kita ambil kasus sistem informasi perpustakaan lagi (lagi-lagi perpus...) hehehe... - kalo pengembangan udah dipartisi berbasis komponen, ada yang ndevelop aspek registrasi anggota perpus, ada yang ndevelop aspek manajemen buku, ada yang ndevelop transaksi peminjaman/pengembalian. Anggaplah cuman itu! Trus, kalo udah dipisah-pisahin gitu, misal ada kesalahan (error/bug/ato apa lah istilahnya) di aspek transaksi, yaa perbaikilah transaksi nya doank. Itu fungsi standar dari pengembangan berbasis komponen. Standar banget malahan. Utk mempermudah maintenance. Mempermudah refactoring... Standar. Trus yang lainnya apa? MISAL, suatu saat tim developer kita dihadapkan kasus (proyek) harus mbikin aplikasi klinik (misalnya), kita bisa *comot* kan komponen "registrasi anggota perpus" itu utk di-embedd dalam sistem informasi klinik (hehehe..., skrg udah bukan perpus lagi). tinggal sesuaikan dikit atributnya, yang dari anggota perpus menjadi pasien... konsepnya sama! Bahkan mungkin form nya juga sama! Dan ngga cuman itu aja, komponen2 yang *tadi* udah dirancang secara independen itu terus dipelihara sama kita, di-enhance dikit demi dikit, disempurnain, de-el-el... yang suatu saat komponen itu bener2 sampe ke state *MATANG* dan bisa dijadikan template untuk membangun fungsionalitas aplikasi yang serupa... Template itu bisa dijadikan investasi di hari tua, mungkin 5 tahun ke depan, ketika perusahaan software ini udah kaya template, utk bikin aplikasi2 tertentu tinggal main copy-paste, comot-sana-comot-sini.... BERMANFAAT BANGET, KAN? kalo udah main comot-comot, kita bisa menggeser fokus untuk menjawab aspek-aspek pendukung operasional yang sebelumnya kita anggap itu keinginan user. Hasilnya? kita kerja enak, ringan. User juga puas...
   

Tapi untuk mengimplementasikan itu ngga semudah seperti menuliskannya di blog ini... Kadang software developer juga selalu dikejar2 pemenuhan requirement fungsional, karena harè-gènè mana ada proses bisnis yang simpel... Aspek transaksional makin padat, pihak manajerial juga makin gencar meminta tools yang bisa membantu mereka mengambil keputusan, pihak stakeholder juga makin sering menuntut kebutuhan informasi yang cepet, akurat, dan reliabel. Pengembangan sistem berbasis komponen itu merupakan salah satu trik kita untuk menjawab semua keperluan-keperluan itu... - karena yang nuntut cepet bukan cuman END USER, tapi rentetan kerjaan laen, proyek2 laen, juga menuntut kita selaku software developer harus bisa bekerja CEPAT.

Kenapa ya adegan slow motion cuman ada di tivi?