Hi guys,
Beberapa waktu yang lalu saya dapat proyek baru. To make a story short, setelah proses pengumpulan informasi, tawar-tawaran, deal, pembuatan program, dan lain-lain, akhirnya program itu pun jadi. Pada waktu final delivery, si owner meminta saya untuk menginstall program itu di komputer dia (komputer lama, PII-350). Waktu saya periksa komputernya, ternyata di dalam sistem komputernya ada TIGA program untuk business dia:
- Yang satu aplikasi web based yang dibuat dengan PHP dengan database MySQL (belum selesai - masih banyak yang script error)
- lalu juga ada aplikasi yang dibuat dengan VFP7 (!!! - karena penasaran saya decompile, dan dari base classes-nya saya mendapati bahwa programnya menggunakan base forms dari aplikasi sample tastrade. Program yang ini sudah hampir selesai, tapi sayang, kelihatannya si programmer bingung dengan kompleksitas frameworknya, dan business process bener-bener di integrasikan sampai ke level user interface. Akibatnya dengan hanya sedikit perubahan pada business si owner (dalam kasus ini adalah nama jasa yang dijual atau penambahan jasa baru), program ini sudah tidak terpakai dan harus di bongkar mulai dari struktur database, sampai user interface (form design) ).
- Program ketiga dibuat dengan Microsoft Access. Ini adalah program yang paling lumayan di antara ketiga program yang ada. Tapi kelihatannya si pembuat mendapat masalah yang sama dengan kasus VFP7. Business process-nya di masukin semua di form. Ini masih ditambah dengan masalah database yang banyak redundancy. Akibatnya report yang dihasilkan jadi nggak konsisten.
Anyway, waktu saya tanya owner apakah semua program lama ini mau dihapus, dia dengan tegas menjawab 'ya' dan 'sedikit' bercerita mengenai sejarah program-program itu. Saya tidak akan menceritakan mengenai bagaimana ceritanya, tapi setelah mendengar cerita dia dan melihat ketiga aplikasi itu, saya jadi ingin sedikit berbagi untuk foxer-foxer indonesia --- terutama untuk independent software developer (saya lebih seneng pakai istilah itu daripada istilah 'programmer freelance' - yang terakhir kesannya kok cheap banget
).
Saya sama sekali tidak bermaksud mengajari, juga tidak bermaksud sombong dan mengatakan bahwa saya sudah berhasil. Bukan begitu. Saya hanya ingin berbagi. Tujuan saya supaya profesi kita ini lebih dihargai. Kalau profesi kita ini lebih dihargai, saya yakin, kita semua bisa memetik buahnya.
Nah, yang akan saya berikan sekarang adalah tips-tips ringan mengenai membuat aplikasi. Point-point-nya mungkin tidak tersusun rapi (karena saya tidak akan ada waktu untuk mengedit ulang post ini), tapi inilah point-point itu:
1. Pastikan Anda telah mengumpulkan informasi yang cukup sebelum Anda mulai membuat program.
Informasi apa saja yang perlu Anda kumpulkan? Yang pasti pertama kali Anda harus tau business process-nya. Bagaimana alur datanya. Apa saja entitas yang terlibat. Dan jangan lupa, bagaimana report yang sekarang sudah berjalan dan bagaimana report yang diharapkan oleh user (yang dengan sistem yang ada sekarang masih merupakan angan-angan). Cara mendapatkan informasi adalah dengan komunikasi. Cobalah untuk ngobrol dengan owner, dan dengan semua orang yang akan terlibat dengan sistem. Setiap orang akan punya pengharapan-pengharapan dan keperluan tertentu. Tampunglah semua requirement itu. Semakin besar sebuah sistem, semakin banyak requirement yang harus dikumpulkan. Ada banyak metode untuk menampung dan mendokumentasikan informasi ini. Yang paling sering saya gunakan adalah metode CRC (Class-Responsibiliy-Collaborator). Untuk menggunakan metode ini, buatlah kartu ukuran 1/4 kertas A4 seperti ini:
+-----------------------------------+
| CLASS |
+----------------+------------------+
| Responsibility | Collaborator |
+----------------+------------------+
| | |
| | |
| | |
| | |
| | |
| | |
+----------------+------------------+
Contoh kartu CRC:
+----------------------------------------------------------+
| Head PPIC |
+-----------------------------+----------------------------+
| Responsibility | Collaborator |
+-----------------------------+----------------------------+
| Membuat planning produksi | Owner (preference) |
| | Marketing (sales data) |
| | Kondisi buffer stock (gdg) |
+-----------------------------+----------------------------+
CRC Card akan sangat membantu dalam mengorganisir pengumpulan data pada level lapangan.
2. Kalau Anda adalah desiner sistem, setelah informasi terkumpul, jangan langsung buru-buru menjalankan VFP dan membuat form. Gunakan buku. Sekali lagi: gunakan buku - bukan kertas lembaran. Kalau Anda senang menggunakan kertas, pastikan Anda menggunakan kertas yang mudah dibinder (seperti kertas loose leaf seperti jaman kulihan dulu). Setelah digunakan, kertas itu harus langsung di-binder. Kalau tidak kertas itu akan jadi lost leaf. Pokoknya gini deh, kalau Anda punya banyak kertas-kertas penting tapi menurut orang rumah itu adalah 'susuh tikus' berarti Anda perlu buku!
3. Next point: apa yang harus Anda isi di buku itu? Well. Semua pikiran Anda. Usul saya, mulailah dengan membuat DFD level 0 (a.k.a context diagram). DFD level 0 hanya berisi satu proses (yaitu proses dengan nama Sistem Informasi Bikinan Anda) dan entitas-entitas yang terlibat. Membuat DFD level 0 ini mudah sekali. Harusnya Anda hanya butuh paling lama 5 menit untuk membuatnya. Biarpun ini mudah dan sederhana, tapi DFD Level-0 harus dibuat. Karena dengan membuat DFD level 0, secara psikologis akan membentuk benteng-benteng batasan di pikiran kita. Jadi kita tidak berpikir di luar masalah yang ada.
Setelah itu buat juga DFD level 1-nya. Cara membuat DFD level-1: kumpulkan CRC card yang sudah diisi, lalu susun di atas meja yang cukup luas. Nah, dari sana, anda akan dengan mudah membuat DFD level-1. Kalau prosesnya masih kompleks, bisa juga dibuat level 2. Tapi saya rasa sampai level 2 cukup. Saya pribadi jarang sampai ke level-3.
Setelah draft DFD, bisa diteruskan dengan database design. Saat database design ada satu tips untuk para pemula: JANGAN TAKUT DENGAN TABEL YANG BANYAK. Tiga aplikasi yang saya ceritakan di awal post ini, hanya menggunakan tabel yang sangat sedikit. Yang aplikasi VFP7, malah hanya menggunakan tiga tabel dan 5 view. Banyak pemula yang mendesain database dengan tabel yang sedikit. Yah, nggak bisa disalahkan. Kalau kita lihat bahan kuliahan sistem database (basis data), biasanya pada contoh kasus atau (bahkan) ujian paling mentok 4 tabel. Lima aja jarang. Nah, apa minusnya tabel sedikit? Kalau tabel-nya sedikit, hampir pasti design database tidak memenuhi kaidah normalisasi database. Misalnya aplikasi VFP yang saya ceritakan barusan; ada satu tabel yang mempunyai 50 field dan 40 field-nya bernama seperti ini: absenKB1, absenKB2, absenKB3, absenKB4, absenKB5, absenDRP1, absenDRP2, absenDRP3, absenGOR1, dst. Nah, Anda bisa bayangkan bagaimana strukturnya?
Jumlah tabel yang banyak adalah hal yang umum di aplikasi-aplikasi bisnis. Angka 80 tabel atau 120 tabel bukan hal yang aneh. Kalau business rule dan authentication di aplikasikan ke database juga (misalnya untuk db SQL Server), maka view yang digunakan bisa dua kali lipat jumlah tabel. Itu juga jumlah yang umum. Jadi sekali lagi: jangan takut melakukan desain dengan jumlah tabel yang banyak - tentu saja kalau memang diperlukan.
Selanjutnya mengenai normalisasi: Saya punya aturan untuk menormalisasi tabel sampai N3. Apabila tabel itu: a) hanya akan berupa lookup tabel, b) relasi hanya dengan satu tabel lain - tidak lebih; dan c) relatif tidak ada insertion selama operasional harian aplikasi; maka saya akan men-denormalisasi ke N2. Tapi bukan berhenti di N2. Normalisasi semua tabel sampai N3, lalu untuk beberapa tabel yang memenuhi tiga aturan di atas, denormalisasi-kan ke N2. Kalau misalnya Anda bertanya; 'apa perlunya normalisasi database?' - berarti Anda perlu membaca lebih banyak mengenai normalisasi. Silahkan search google. Dari sana banyak sekali link artikel mengenai normalisasi.
Sedikit tambahan mengenai primary key; sebaiknya setiap tabel mempunyai surrogate primary key. Artinya primary key yang tidak dapat dilihat oleh user dan tidak mempunyai arti oleh user. Jadi, jangan gunakan nomor order atau kode customer, atau no transaksi, atau sejenisnya sebagai primary key. Gunakan satu kolom (field) khusus misalnya nama tabel adalah sales; maka nama primary key-nya sales_PK. Bisa digunakan tipe integer atau Long Integer (atau boleh juga menggunakan GUID kalau database Anda terdistribusi). Mungkin Anda berargumen; "Tapi kode customer yang saya gunakan pasti unik. Tidak mungkin tidak unik", atau mungkin: "Tapi nomor order saya di generate otomatis dengan lookup table - jadi nggak mungkin ada yang double - berarti bisa dipakai PK!". OK. Whatever argument anda, jawaban saya: "OK. Tetap gunakan surrogate primary key". Anda bisa punya banyak candidate key di tabel Anda. Tapi hanya gunakan satu kolom (field) untuk primary key.
Fiuh. Artikel ini jadi panjang. Repot juga ya? Gini deh, artikel ini masih akan bersambung. Tapi sambungannya lain kali ya...
Kalau ada yang mau ditanyakan, silahkan.
Disclaimer:
Artikel ini adalah berdasarkan pengalaman saya dan bersumber dari pilihan/preference saya berdasarkan buku, artikel, dan post-post dari komunitas foxpro yang saya baca. Saya percaya bahwa setiap profesional mempunyai preference dan pemikiran tersendiri. Jadi artikel ini bukan aturan baku.
hth,
Foxy
