Pendekatan Dalam Membangun Sebuah Sistem

Photo by Christina Morillo from Pexels

Bagaimana sih melakukan pendekatan dalam membangun sebuah sistem yang paling mudah? Nyatanya sampai hari ini banyak yang menanyakan hal tersebut. Mengapa? Karena ketika kita membangun sebuah sistem hal ini seperti menggabungkan 2 dunia, yakni dunia teknik atau algortima komputer dengan pola pikir bisnis.

Untuk pendekatan yang terbaik, bisa dilihat dari kondisi. Saya sampai hari ini melihat banyak yang masih mencintai metode pembangun waterfall, meskipun dalam kenyataannya mereka malah sangat jauh sekali dari waterfall. Kita lihat sedikit apa itu metode pembangunan waterfall.

Metode Pembangan Waterfall, untuk Sistem yang Mirip.

Kapan metode waterfall dipakai? Metode waterfall digunakan pada saat kamu membangun sebuah sistem yang kamu sudah sangat familier. Dalam kata lain, kamu sudah sering membangun sistem ini pada beberapa perusahaan dan kamu sudah sangat paham seluk beluk didalamnya. Misalkan kamu sudah membangun sistem untuk POS restaurant berkali-kali dan client baru kamu juga meminta dibangunkan sebuah POS untuk restaurant juga. Karna sudah beberapa kali membangun POS restauran maka kamu paham akan kebutuhan dan desain yang akan dibangun. Hanya saja analisa dan pencarian kebutuhan di awal akan digunakan untuk menyesuaikan POS yang dibangun sesuai dengan kebutuhan atau permintaan perusahaan. Sehingga urutan pembangunan akan seperti gambar berikut.

Pembangunan sistem yang dilakukan berjalan 1 arah dan hanya sekali saja. Hal ini sudah dengan alasan yang jelas, karena kamu sudah memiliki pengalaman dan dokumentasi kode untuk sistem POS yang ada, sehingga kamu mungkin akan banyak copy paste dari kode proyek lama mu dan kemudian melakukan penyesuaian terhadap kode mu dalam proyek yang baru. Sehingga waktu pengerjaan bisa kamu hemat dengan sangat luar biasa. Namun, saat kamu belum memiliki pengalaman, tidak disarankan menggunakan metode waterfall karena akan membuat banyak masalah dan menemukan banyak masalah. Nantinya akan menghasilkan low quality product dan proyek yang terus terlambat karena perbaikan-perbaikan yang ada.

Sebuah Sistem yang Perlu Evaluasi dan Penyesuaian, Metode Iterative

Metode berikutnya adalah metode iterative, metode ini banyak digunakan oleh perusahaan atau sebuah bisnis yang memerlukan tenaga ahli sistem informasi secara berkala untuk membuat, kemudian menyesuaikan dengan kondisi lapangan bahkan dengan perubahan-perubahan atas permintaan customer. 

Kenapa metode iterative ini dibutuhkan, karena perusahaan(bisnis) juga belum mengerti keinginan atau kebutuhan dari user dan yang bisa mereka lakukan hanya melakukan dugaan. Perlu diketahui saat saya menyebut dugaan, maksudnya adalah dugaan teredukatif. Artinya dugaan tidak dilakukan bedasarkan perasaan saja namun bedasarkan hasil fact finding.

Metode ini dimulai dari perencanaan awal di mana mungkin akan diberitahukan rencana dan pembangunan sistemnya secara menyeluruh. Kemudian akan memasuki tahap perencanaan secara lebih detil setelah itu kita akan melakukan langkah-langkah yang mirip dalam metode waterfall namun ada pembeda dalam metode iterative seperti yang ada pada gambar berikut.

 

Perbedaannya adalah setelah ada testing maka akan ada 2 panah, yang satu kembali melanjutkan iterasi yang dilakukan dan yang satunya melakukan peluncuran. Peluncuran ini apa? Peluncuran adalah saat software yang kita bangun dipublikasikan sehingga bisa digunakan oleh user. Mengapa ini menjadi hal penting? Tentu saja penting, tanpa adanya peluncuran maka yang kita bangun tidak diketahui dan digunakan oleh user, bila tidak dipakai maka kita tidak akan dapat melakukan yang namanya evaluasi. Apabila hanya sampai pada testing saja maka yang dilakukan bukan metodek iterative namun metode waterfall.

Evaluasi digunakan untuk menerima masukan dan membuat software yang dibangun menjadi lebih baik. Sehingga kita benar-benar bisa meningkatkan kualitas dari produk/software tersebut. Setelah evaluasi, akan kembali ke perencanaan. Kenapa perlu direncanakan lagi? Karena produk/software telah diluncurkan dan untuk memperbaiki produk/software yang diluncurkan perlu kehati-hatian ekstra. Hal ini bukan tanpa alasan, tetapi karena user telah menggunakan produk/software dan kita harus mengusahakan agar tidak menganggu user yang sedang menggunakan produk/software. Metode iterative akan melakukan iterasi terus menerus hingga produk dinyatakan telah sempurna, tetapi kata sempurna mungkin akan sulit didapat mengingat bahwa jaman dan teknologi kita terus berubah, inilah sebabnya perlu bekerja sama dengan tenaga sistem informasi terus menerus agar produk/software tidak berhenti berkembang begitu saja.

Ketika Sama-sama "Buta" Gunakan  Prototyping

Metode prototyping adalah metode favorit yang sering saya pakai. Tentu saja metode prototyping ini juga memiliki kelemahan, yakni merepotkan. Namun metode ini favorit saya karena keuntungan yang jauh lebih banyak dibanding kelemahan. Keuntungan utama adalah produk akhir yang berkualitas meskipun user/client tidak memiliki atau belum memiliki gambaran akhir dari sistem yang akan dibangun. Mungkin ini adalah hal yang sulit dicerna, namun pada kenyataannya hal ini sering terjadi. Pada awal artikel sudah saya katakan bahwa kita menggabungkan 2 dunia. Seringkali client hanya berdiri pada 1 dunia saja, yakni bisnis. Sehingga saat ditanya mengenai gambaran akan software, maka mereka juga tidak tahu tepatnya.

Prototyping melakukan pembangunan software sesuai dengan permintaan user, dimulai dengan gambaran secara besar terlebih dahulu. Setelah dia mendapat gambaran besar maka dia baru akan menyesuaikan sistem sesuai dengan kebutuhannya secara spesifik. Mungkin gambar berikut dapat memberikan gambaran secara umum mengenai metode prototyping.

Prototype pertama

Prototype pertama diberikan bedasarkan pengetahuan analisa dasar dari keperluan user secara garis besar, lalu saat user mencoba menggunakan maka user akan mengatakan bahwa ada hal yang harus disesuaikan dengan keperluan mereka dan produk yang diberikan perlu diperbaiki. Kita kemudian akan menampung semua permintaan dan perbaikan dari user kemudian kita akan membangun prototype berikutnya.

Prototype Kedua

Di sini user mungkin akan meminta bahwa ada keperluan seperti penyimpanan konversi unit di mana saat user menerima barang maka barang langsung dikonversi dan di simpan dalam satuan terkecil, pencatatan stok minimum agar ada pengingat untuk melakukan stok ulang barang dan tambah barcode dikarenakan pada lapangan ada beda barcode pada barang satuan terkecil dan satuan besar. Maka setelah semua diperbaiki dan diserahkan ke user, mereka akan mencoba dan kita akan membangun kembali prototype berikutnya yang sesuai dengan kebutuhan user. Sampai kapan hal ini dilakukan, sampai user merasa semua kebutuhannya dipenuhi.

Prototype akhir

Saat sudah menjadi prototype akhir maka hasilnya akan disimpan dan siap diluncurkan. Perlu diketahui bahwa dalam membangun prortype harus dijaga agar benar-benar sesuai dengan tujuan utama dan awal dari prototype tersebut. Apabila kamu seorang pembangun software bedasarkan kontrak dan bukan karyawan dari perusahaan tersebut, pastikan saja yang kamu bangun sesuai dengan kontrak dan perjanjian awal dan bila sudah melenceng terlalu jauh, maka kamu bisa arahkan kembali. Ingat hal ini terjadi karena user juga tidak memiliki gambaran akhir dari perangkat lunak, disinilah butuh keahlian kamu sebagai konsultan Sistem Informasi.

Bila Persetujuan Semua Pihak Diperlukan, Maka Gunakan Metode Join Application Design

Permintaan dari client kadang sangat butuh perhatian dari banyak divisi sehingga kita tidak bisa melakukan pendekatan dari salah satu divisi dahulu. Tujuannya adalah agar integrasi sistem dapat berjalan dengan baik dan lancar. Saya secara pribadi tidak akan menggunakan metode ini kecuali terpaksa. Tapi client biasanya lebih membutuhkan, karena client yang butuh biasanya berasal dari Top Management, di mana dia ingin membangun sistem lebih baik dan teritegrasi namun dia tidak mengerti kondisi lapangan secara mendetil sehingga dia membutuhkan bantuan dari seluruh divisi yang ada. Yang lebih aneh lagi meski tidak disukai masih dipakai, perlu diperhatikan bahwa biasanya proyek ini besar dan memerlukan kerjasama banyak divisi, dan tentu saja bayarannya tidak sedikit. 

Photo by Christina Morillo from Pexels

Temukan semua yang berkepentingan dalam 1 ruangan, dan diskusikan mengenai kebutuhan sistem. Kebutuhan dan hal-hal yang perlu di integrasikan akan lebih cepat ditemukan dalam metode Joint Application Design, sehingga bila dilakukan dengan tepat maka hal ini dapat menghemat waktu dengan sangat banyak. 

Beberapa hal yang perlu disiapkan adalah komitmen dalam mengikuti rapat, tidak ada telpon mendadak dan konsentrasi penuh selama rapat. Kedua, pastikan ada notulen rapat yang akan membantu kamu mencatat permintaan client sementara kamu memimpin rapat.  Namun di sisi lain kita juga sudah memiliki sound recorder yang cukup baik, sehingga notulen dapat dilengkapi dengan lebih detil lagi.

Orang-orang penting yang harus hadir adalah executive director/manager, kepala/pimpinan dari setiap divisi serta client atau pemilik dana. Setelah rapat ini selesai maka sisa dari metode ini sama seperti metode waterfall. Kalau boleh disimpulkan, mungkin hasil akhirnya seperti gambar ini

Sehingga lebih hemat 1 langkah, dan memang terbukti pada banyak kasus setelah rapat selesai, waktu yang diperlukan dalam menjalankan metode joint application design lebih singkat daripada menggunakan metode waterfall.

Rational Unified Process, Metode Membangun Sistem yang Lebih Rasional dan Realistis. 

Rational Unified Process adalah metode pembangunan sistem dengan pendekatan objek oriented yang artinya dia melakukan pendekatan per objek bukan sistem secara keseluruhan secara bersama-sama. Rational Unified Process adalah metode pembangunan yang saya sering gunakan dalam kenyataan dan terasa paling realistis. 

Pendekatan Rational Unified Process memiliki 4 tahapan besar dalam membangun

• Inception
• Elaboration
• Construction
• Transistion

Inception adalah sebuah bentuk perencanaan awal, seperti yang ada pada metode pembangunan software lainnya, dalah tahap ini kasus bisnis atau permasalahan yang ada diperkenalkan dan kamu menganalisa mengenai kelayakan proyek ini. 

Elaboration adalah bagian di mana kita melakukan analisa lebih detil dan mendesain sistem baru yang akan diimplementasikan. Termasuk finalisasi keperluan dan rencana proyek. 

Construction, fokus utama tahap ini adalah dalam programming untuk menjalankan alur sistem informasi perusahaan, tetapi di tahap ini tidak kaku terhadap perubahan. Maksudnya apa? Maksudnya saat user menemukan kebutuhan baru maka pembangun software akan melakukan analisa terhadap kebutuhan tersebut dan bila disetujui oleh atasan mereka akan mendesain kembali untuk memperbaiki sistemnya. Hasil akhir dari tahap ini adalah sebuah software yang siap di uji coba dan diimplementasikan.

Transition adalah tahap di mana software masuk dalam penyempurnaan, di mana pembenaran atau programming seharusnya sudah sangat minimal. Tahap ini adalah tahap uji coba atau tepatnya user acceptance test untuk melihat apakah semua sudah sesuai fungsinya dan kegunaannya. Hasil akhir berupa sistem informasi yang telah berjalan dan dokumentasi software termasuk pendukung user seperti user manual.

Yang saya suka dari rational unified process adalah Realistis dalam metode ini. Pertama meski ada 4 tahap, bukan berarti setiap tahap dilakukan dalam sekali jalan. Tahap Elaboration bisa dilakukan 2 kali apabila sistem terbagi menjadi 2 bagian besar. Alahasil kita akan bisa melakukan analisa lebih baik dan detil. Sehingga dapat ditemukan Elaboration 1 dan Elaboration 2 dalam sebuah proyek. Hal yang sama juga terjadi dalam Construction, dan trasition. Bahkan tahap construction bisa sampai 4 kali, yang mana sangat mungkin terjadi bila sistem yang dibangun sangat besar.

Kedua, metode ini juga fleksibel, misal saat masih melakukan analisa maka kita juga dapat membangun software untuk bagian-bagian yang telah selesai di analisa dan di desain. Termasuk memberikan pada user untuk dicoba, meski baru prototype dasar.

Sehingga gambar metode pembangunannya tidak sama dengan gambar metode di atas, melainkan akan saya berikan gambaran mengenai proyek yang berjalan dalam tiap tahap

Fokus inception ada dalam menganalisa kebutuhan dasar dan desain sistem. Sehingga proporsi proyek pada tahap inception akan besar di sana. Coding & implementasi juga mulai dikerjakan, seperti desain tatap muka, standar icon, standar font dan button. Maka dari itu saya mengatakan bahwa metode pembangunan sistem object oriented cukup fleksibel.

Kemudian, tahap berikutnya juga sama, fleksibilitasnya cukup tinggi sehingga apabila sistem yang dianalisa cukup besar maka dapat kita bagi menjadi 2 tahap. Hal ini akan menyebabkan gambar menjadi seperti ini

Dapat dilihat bahwa saat tahap 1 elaboration sudah ada hal yang telah dianalisa dan di desain, sehingga coding dan implementasi bisa dimulai dan tidak perlu menunggu semua hasil analisa dikumpulkan, termasuk peluncuran modul-modul yang sudah selesai pada user. Contohnya modul master untuk memasukan data dalam ke dalam database. Pada tahap kedua maka proses dari proyek akan lebih terlihat bahwa semua bisa dijalankan di saat bersamaan.

Kemudian dapat kita lihat bahwa pada tahap 2 tugas dalam mencari kebutuhan sistem dan membangun business model akan semakin berkurang karena biasanya pada tahap 2 ini seluruh kebutuhan sistem telah ditemukan dan setelah ini selesai akan mulai fokus pada pembangunan software.

Hasil akhir dari keseluruhan pengerjaan rational unified process akan seperti gambar berikut

 

Catatan lain

Metode lain yang bisa digunakan adalah SCRUM, yang menurut saya adalah gabungan dari Rational unified process dan prototyping. Jauh lebih fleksibel dan lebih mudah digunakan. Tetapi saran saja, saat menggunakan metode SCRUM ada baiknya memahami konsep object oriented dengan baik. Kemudian SCRUM termasuk dalam agile methodologies, di mana fokusnya memang pada kecepatan dalam membangun produk/software.

Semua metode ada kelemahan dan kelebihannya masing-masing oleh karena itu dibutuhkan project manager yang berpengalaman untuk memilih pendekatan dalam membangun sistem yang sesuai.

Artikel Lain yang berkaitan : 

1. Apa itu Sistem dan Siklus hidup sistem(SDLC) 

2. Cara mencari dan menemukan kebutuhan sebuah sistem(Fact Finding)

3. Karakteristik yang ada dalam sebuah sistem