Artikel Wartefall

 WATERFAL

Sejarah Model Waterfall

Penggunaan metode waterfall pertama kali diperkenalkan oleh Herbert D. Benington di Symposium on Advanced Programming Method for Digital Computers pada tanggal 29 Juni 1956. Presentasi tersebut menjelaskan tentang pengembangan perangkat lunak untuk SAGE (Semi Automatic Ground Environment).

Pada tahun 1983, dipresentasikan kembali oleh Benington dan menjelaskan tentang fase – fase dalam proses pengembangannya. Dan pada tahun 1985, Departemen Pertahanan Amerika Serikat juga menggunakan metode ini dengan beberapa tahapan yang digunakan, terdiri dari 6 fase, yaitu: Preliminary design, Detailed design, Coding and unit testing, Integration, dan Testing.

Kelebihan Metode Waterfall

1. Rangkaian Kerja Jelas

Dengan metode waterfall tahapan pengembangan sistem menjadi jelas. Masing-masing anggota yang terdiri dari Analis, desainer, programmer, tester atau juga pemasaran memiliki tugas yang terdefinisi dengan baik.

Setiap tim akan bekerja sesuai alur atau tahapan dalam metode ini, sehingga kesalahan-kesalahan bersifat teknis dapat ditekan seminimal mungkin.

2. Berkomitmen Pada Tujuan Akhir

Pada tahap awal klien dan tim analis bertemu untuk mendefinisikan detail kebutuhan dari software yang akan dibuat. Jika tahapan ini selesai, maka klien dan seluruh tim yang terlibat akan mengetahui gambaran atau tujuan akhir dari sistem yang dibuat.

Semua akan berkomitmen pada hasil akhir software. Tidak boleh ada perubahan ditengah proses baik itu oleh pihak developer ataupun klien. Semuanya harus sejalan dengan tujuan yang telah disepakati diawal.

3. Dokumentasi yang Baik

Waterfall adalah pendekatan yang sangat metodis, setiap informasi akan tercatat, terdistribusikan dan dapat diakses dengan cepat oleh setiap anggota tim.

Dokumentasi ini juga berguna ketika misal ada 1 atau beberapa anggota tim mundur dari proyek. Dengan dokumentasi yang baik maka anggota tim baru nantinya dapat lebih mudah beradaptasi dengan sistem dan prosedur yang ada.

Selain itu, setiap divisi tim juga akan lebih mudah menyelesaikan pekerjaan. Misalnya programmer yang bisa bekerja dengan arahan dokumen yang telah dibuat tim analis dan desain.

4. Hemat Waktu dan Biaya

Hal yang biasanya menjadi penyebab molornya waktu penyerahan software adalah kebutuhan klien yang berubah-ubah dan banyaknya campur tangan klien ketika proses pengerjaan.

Dalam metode waterfall, klien tidak bisa leluasa mencampuri proses pembuatan software, terlebih ketika sudah memasuki tahap programming.

Klien harus mendefinisikan secara jelas kebutuhan diawal dan harus berkomitmen dengan hal tersebut. Dengan seperti itu pihak developer dapat membuat estimasi waktu dan juga biaya pengerjaan.

5. Cocok untuk Pembuatan Software Berskala Besar

Metode Waterfall dinilai cocok untuk pengerjaan software yang melibatkan banyak sumber daya manusia dan memiliki prosedur yang kompleks.

Tapi ada juga ahli yang berpendapat bahwa metodologi waterfall lebih baik digunakan pada proyek skala kecil dengan pengerjaan waktu yang singkat.

Kekurangan Metode Waterfall

1. Membutuhkan Tim dan Manajemen yang Solid

Masing-masing divisi tim bertanggung jawab untuk melakukan setiap tugasnya dengan baik. Jika satu tim gagal mengerjakan pekerjaan, maka itu akan berdampak pada keseluruhan projek.

Misalnya ketika tim analis kurang detail dalam mendeskripsikan produk, maka itu menjadi malapetaka untuk para desainer dan programmer.

Tugas pertama pimpinan proyek adalah membentuk tim yang memiliki skill mumpuni dalam bidangnya masing-masing dan melakukan pengawasan pada setiap tahapan-tahapannya. Dalam metode waterfall kesalahan kecil bisa menjadi masalah besar.

2. Kurang Flexible Bagi Klien

Semua tim harus bekerja sesuai arahan dan tujuan yang ditetapkan diawal. Metode ini tidak mengakomodir perubahan-perubahan spesifikasi yang terjadi ketika proses telah berjalan.

Dalam sebuah proyek terkadang klien ingin ikut mengeluarkan pendapat, merevisi ataupun mengklarifikasi pendapatnya. Dalam metode ini hal itu tidak dapat dilakukan kecuali di tahapan awal perancangan aplikasi.

3. Waktu Pembuatan Software Lebih Lama

Metode waterfall tidak memungkinkan seluruh tim bekerja secara bersamaan. Tim desain tidak bisa bekerja sebelum tim analis selesai melakukan tugasnya. Begitupun para programmer yang harus menunggu tim analis & desain merampungkan tugasnya.

Dengan seperti ini, pekerjaan akan menjadi lambat dan pembuatan software akan memakan waktu lebih lama dibandingkan metodologi pengembangan perangkat lunak lainnya.

4. Tidak Bisa Melihat Gambaran Sistem

Sistem baru akan terlihat ketika seluruh rangkaian telah berjalan. Klien bisa melihat aplikasi dalam bentuk real pada akhir tahapan.

5. Kenaikan Biaya dan Tanggal Rilis

Masalah yang terjadi dalam model waterfall adalah jika dalam tahap pengetesan terdapat konflik atau bug yang rumit. Ini bisa memakan waktu lama dan menyebabkan proyek menjadi molor

Belum lagi jika klien tidak puas dengan hasil kerjaan dan meminta revisi ulang sistem. Maka dari itu sedari awal diperlukan tim yang berkualitas dan berpengalaman serta manajemen tim yang baik agar setiap tugas terawasi dan bisa diprediksi setiap celah kesalahannya.

Contoh kasus proyek perangkat lunak yang menggunakan model tersebut

Model Prototyping pada Rekayasa Perangkat Lunak

Sebuah prototipe adalah bagian dari produk yang mengekspresikan logika maupun fisik antarmuka eksternal yang ditampilkan. Konsumen potensial menggunakan prototipe dan menyediakan masukan untuk tim pengembang sebelum pengembangan skal besar dimulai. Melihat dan mempercayai menjadi hal yang diharapkan untuk dicapai dalam prototipe. Dengan menggunakan pendekatan ini, konsumen dan tim pengembang dapat mengklarifikasi kebutuhan dan interpretasi mereka.

Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat dari pada metode tradisional dan biayanya menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.

Dengan prototype yang terbuka, model sebuah sistem (atau bagiannya) dikembangkan secara cepat dan dipoles dalam diskusi yang berkali-kali dengan klien. Model tersebut menunjukkan kepada klien apa yang akan dilakukan oleh sistem, namun tidak didukung oleh rancangan desain struktur yang mendetil. Pada saat perancang dan klien melakukan percobaan dengan berbagai ide pada suatu model dan setuju dengan desain final, rancangan yang sesungguhnya dibuat tepat seperti model dengan kualitas yang lebih bagus.

Protoyping membantu dalam menemukan kebutuhan di tahap awal pengembangan,terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.

Salah satu hal terpenting mengenai metodologi ini, cepat atau lambat akan disingkirkan dan hanya digunakan untuk tujuan dokumentasi. Kelemahannya adalah metode ini tidak memiliki analisa dan rancangan yang mendalam yang merupakan hal penting bagi sistem yang sudah kokoh, terpercaya dan bisa dikelola. Jika seorang pengembang memutuskan untuk membangun jenis prototipe ini, penting untuk memutuskan kapan dan bagaimana ia akan disingkirkan dan selanjutnya menjamin bahwa hal tersebut telah diselesaikan tepat pada waktunya. 

Dicky Suman Jaya

perkenalkan saya dari mahasiswa teknik komputer dari universitas teknokrat indonesia

Share this post