Metode Waterfall (RPL Lanjutan)

Metode Waterfall

Metode-metode pada RPL yaitu meliputi :

1.Waterfall.

2.Incremental.

3.RAD.

Masing –masing memiliki penjelasan yang berbeda-beda,berikut adalah penjelasan dari setipa metode-metode tersebut.

A.      Waterfall

Apa itu waterfall ? , waterfall : mengambil kegiatan dasar seperti spesifikasi , pengembangan validasi, evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak , implementasi , pengujian dan seterusnya.

Kelebihan dari metode waterfall adalah sebagai berikut:

1.       Setiap tahap dikerjakan dengan lengkap dan jelas.

2.       Dokumentasi sangat baik.

3.       Model proses waterfall menngusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dan dimodelkan setelah siklus rekayasa konvensiaonal, dimana model sekuensial linier ataupun waterfall proses melingkupi aktivitas-aktivitas sebagai berikut:

a.       Rekayasa dan pemodelan sistem/informasi.

b.      Analisis kebutuhan perangkat lunak.

c.       Desain

d.      Generasi kode

e.      Pengujian

f.        Pemeliharaan

4.       Ketika semua kebutuhan sistem dapat didefinisikan secara utuh , eksplisit, dan benar di awal project, maka software engineering dapat berjalan dengan baik dan tanpa masalah.Meskipun seering klai kebutuhan system tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problen pada kebutuhan systemdiawal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

5.       Efisiensi waktu dan teknis kerja.

B.      Apa kelemahan waterfall?

Kelemahan dari pada metode/model adalah perlu adanya informasi yang lengkap pada setiap tahapnya, dan bukan sesuatu hal yang mudah untuk mendapatkan informasi tersebut. Pada prakteknya, sering tidak mungkin untuk menulis dokumentasi kebutuhan yang lengkap sebelum dibangun prototipe. Sehingga yang terjadi adalah “kerja dua kali”, membuat prototipe, kemudian dari prototipe diperoleh informasi kebutuhan dan barulah dibangun sistem final
.