Apa Masalah Model Waterfall di Software Development

Model yang baik dahulu kala belum tentu cocok hari ini. Kemampuan tersulit transformasi digital adalah beradaptasi dengan culture, proses, dan cara baru. Model waterfall adalah pendekatan desain sekuensial yang relatif linier untuk bidang desain teknik, software engineering , atau pengembangan perangkat lunak (software development) .

Dalam pengembangan perangkat lunak (aplikasi) , metode ini cenderung menjadi kurang relevan di era transformasi digital menimbang kebutuhan akan kecepatan baik time to market aplikasi maupun kecepatan perubahan (CR) .Menjadi kurang relevan karena pendekatan waterfall yang kurang fleksibel, karena progress pengembangan mengalir sebagian besar satu arah ke bawah, seperti air terjun, melalui fase konsepsi, inisiasi, analisis, desain, konstruksi, pengujian, penyebaran dan pemeliharaan. Digunakan dalam proyek pengembangan perangkat lunak, fase biasanya terlihat seperti ini:

1. Requirement

Jika Anda tertarik dengan pengembangan perangkat lunak atau jenis apa pun dari tim pembuat proyek, Anda ingin mengetahui konteks bisnis dari apa yang Anda coba buat - Anda ingin menentukan jenis masalah apa, siapa stakeholder yang terlibat, bagaimana user,role, permission dibuat dan sebagainya. Setelah Anda menentukan semua "persyaratan" ini, Anda memiliki input yang harus Anda lanjutkan ke langkah berikutnya. Output pada tahap ini adalah user story dari bisnis analyst atau technical writer.

2. Design

Langkah ini terdiri dari semua langkah yang Anda butuhkan untuk memenuhi semua persyaratan yang telah Anda tentukan sebelumnya. Dalam pengembangan perangkat lunak, ini adalah bagian di mana Anda mendefinisikan semua perangkat lunak dan arsitektur perangkat keras, bahasa pemrograman, penyimpanan data, dll. Ini juga merupakan bagian di mana Anda menentukan bagaimana proyek akan berguna bagi pengguna akhir.

3. Implementation

Pada langkah ini, Anda mulai membangun apa yang telah Anda rancang dalam rencana Anda. Bagian dari metode Waterfall ini didedikasikan untuk memenuhi standar yang telah Anda buat pada langkah sebelumnya. Ini adalah bagian di mana tim developer atau tim pengembangan masuk dan membuat semua hal yang dibahas dalam langkah sebelumnya terjadi berdasarkan wireframe phase design.

4. Verification

Ini adalah tahap metode di mana tim quality control penjaminan mutu masuk untuk memastikan bahwa tim pengembangan tidak melakukan kesalahan. Ini juga kemungkinan besar adalah bagian di mana orang menyadari apa yang berfungsi atau tidak bekerja dalam rencana mereka.

Catatan penting dalam waterfall konsep adalah ketika semua hal dipenuhi oleh pengembang proyek (Developer) , klien atau pengguna akhir masuk dan membuat persetujuan terakhir jika proyek siap untuk diluncurkan atau diuji.

Metode Waterfall menyatakan bahwa ketika ada sesuatu yang salah pada tahap tertentu, orang dapat kembali ke tahap sebelumnya untuk melihat apa yang salah dan segera memperbaikinya . Misalnya, jika ada masalah dalam Implementasi plan dan design, dan orang-orang tahu bahwa mereka hanya mengikuti blue print yang telah diserahkan kepada mereka, maka manajer proyek melihat rencana mereka dan membuat revisi dari sana. Sounds perfect, right? Perfect dalam kondisi tidak banyak perubahan, berjalan di jalan smooth bebas hambatan. But it is too good to be true! New requirement, new updated design, stakeholders input in the middle of proyek dan lainnya. Ini kondisi real yang ada dalam pengembangan aplikasi sekarang. Then, the waterfall looks like this:

Klien mungkin tidak tahu apa yang mereka butuhkan sebelum mereka melihat fungsi real dari perangkat lunak yang mereka inginkan. Pada waterfall klien tidak melihat any screen hingga project hampir selesai. Setelah melihat screen dan UI datanglah perubahan persyaratan , yang mengarah ke pendesainan ulang, pembangunan kembali, dan pengujian ulang, dan tentunya meningkatkan biaya dan waktu . Metode waterfall menjadi kurang relevan karena :

1. Team developer akan secara "kacamata kuda" mengikuti rencana.

Meskipun perencanaan itu penting, penting juga bahwa pengembang dan pemeriksa kualitas memahami bagaimana segala sesuatu harus terjadi, terutama dengan klien atau pengguna akhir. Penting juga bahwa semua orang yang terlibat dalam proyek dapat segera mengatakan bagaimana langkah tertentu dalam pemenuhan proyek dapat berantakan tanpa harus menunggu tahap pengujian. Mengikuti peta perjalanan tanpa mempertimbangkan risk di setiap persimpangan jalan adalah seperti mengikuti "peta buta" Namun inilah waterfall konsep, toh air terjun tidak pernah berpikir untuk turun berbelok sedikit aga tidak merusak pohon misalnya.

2. Proses dan perubahan berurutan menjadi mahal

Pendekatan ini tidak memungkinkan perubahan requirement yang ditentukan saat proyek berlangsung. Jadi ada potensi besar bahwa perangkat lunak tidak akan sepenuhnya memenuhi kebutuhan pengguna, itu akan tidak efisien dan memiliki fungsi yang buruk dari sisi pengguna, karena perubahan adalah makanan sehari hari di pengembangan aplikasi.

Ini tidak memadai karena pengembang tidak bisa hanya kembali dan mengubah sesuatu pada fase sebelumnya karena kebutuhan pelanggan berubah tetapi pengembang harus kembali ke tempat kebutuhan harus berubah dan memulai seluruh fase itu.

3. Pengguna akhir tidak tahu apa yang mereka inginkan.

Sering kali pikiran pengguna akhir terus berubah dan sebagian besar orang memiliki gagasan ambigu tentang requirement perangkat lunak mereka dan seiring perkembangan perangkat lunak saat itu pulalah mereka tentukan requirement baru  mereka.

Ketika tiba saatnya untuk menyerahkan produk jadi kepada klien, ada kemungkinan bahwa mereka tidak akan menyukai bagaimana hasilnya, dan meminta perubahan, mudah bagi klien dan pengguna akhir untuk mengubah apa yang mereka inginkan dari waktu ke waktu. Sistem Waterfall belum memiliki cara untuk menyelesaikannya, tanpa harus merevisi rencana dan mengulangi seluruh proyek sekaligus.

4. Tahap Pengujian (Q&A) untuk kualitas akan panjang dan menderita.

Tidak mungkin untuk secara akurat memprediksi hasil dari suatu proyek yang tidak ada snapshot pada titik tertentu dan hanya mengenal proses mulai dan akhir. Ketika seluruh tim terdesak waktu, yang paling mungkin untuk memotong tahap pengujian pendek untuk memenuhi tenggat waktu. This is where the problem start!

5. Anda tidak akan pernah tahu pada tahap apa Anda sebenarnya berada.

Karena produk yang Anda coba buat tidak akan diproduksi sampai akhir, Anda tidak benar-benar yakin apakah Anda masih dalam perencanaan atau sudah dalam tahap pengembangan. Itu berarti Anda juga mungkin menghabiskan lebih banyak waktu di atas harapan dan kecemasan bahwa pengembang anda  mampu membuat seperti yang anda harapkan karena visibilitas yang buruk di waterfall ini.

Secara ringkas, metode Waterfall terlalu berisiko dan kaku untuk memenuhi misi digital transformation. Anda membutuhkan aplikasi yang cepat, banyak, dan yang terpenting, membuat Anda menghasilkan produk yang berfungsi dan akan cukup fleksibel untuk membantu Anda mengetahui apa yang berhasil atau tidak dan merubah nya pada tahap tertentu.

Metode agile scrum project management datang dengan harapan baru untuk mengatasi masalah ini. Deltadata Mandiri membantu enabling digital transformation FAST dengan menerapkan agile scrum di setiap proses pengembangan aplikasi.

Find out more :

https://www.deltadatamandiri.com/rapid-application-development