Pengertian Metode Waterfall
Pengembangan Software Metode Waterfall
Model pengembangan software yang
diperkenalkan oleh Winston Royce pada tahun 70-an ini merupakan model klasik
yang sederhana dengan aliran sistem yang linier — keluaran dari tahap
sebelumnya merupakan masukan untuk tahap berikutnya. Pengembangan dengan model
ini adalah hasil adaptasi dari pengembangan perangkat keras, karena pada waktu
itu belum terdapat metodologi pengembangan perangkat lunak yang lain. Proses
pengembangan yang sangat terstruktur ini membuat potensi kerugian akibat
kesalahan pada proses sebelumnya sangat besar dan acap kali mahal karena
membengkaknya biaya pengembangan ulang.
Metode
Waterfall adalah suatu proses pengembangan perangkat lunak berurutan, di mana
kemajuan dipandang sebagai terus mengalir ke bawah (seperti air terjun)
melewati fase-fase perencanaan, pemodelan, implementasi (konstruksi), dan
pengujian. Berikut adalah gambar pengembangan perangkat lunak berurutan/ linear
(Pressman, Roger S. 2001):
Tahapan Metode Waterfall
Dalam pengembangannya metode waterfall memiliki beberapa
tahapan yang runtut: requirement, design, implementation, verification dan
maintenance. Tahap requirement atau spesifikasi kebutuhan sistem adalah analisa
kebutuhan sistem yang dibuat dalam bentuk yang dapat dimengerti oleh klien dan
staf pengembang. Dalam tahap ini klien atau pengguna menjelaskan segala kendala
dan tujuan serta mendefinisikan apa yang diinginkan dari sistem. Setelah
dokumen spesifikasi disetujui maka dokumen tersebut menjadi kontrak kerja
antara klien dan pihak pengembang.
Tahap selanjutnya adalah desain,
dalam tahap ini pengembang akan menghasilkan sebuah arsitektur sistem secara
keseluruhan, dalam tahap ini menentukan alur perangkat lunak hingga pada tahap
algoritma yang detil. Selanjutnya tahap implementasi, yaitu tahapan dimana
keseluruhan desain diubah menjadi kode-kode program. kode program yang
dihasilkan masih berupa modul-modul yang selanjutnya akan di integrasikan
menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak
telah dipenuhi. Tahap selanjutnya adalah verifikasi oleh klien, klien menguji
apakah sistem tersebut telah sesuai dengan kontrak yang telah disetujui. Tahap
akhir adalah pemeliharaan yang termasuk diantaranya instalasi dan proses
perbaikan sistem sesuai kontrak.
Manfaat
Metode Waterfall
Keunggulan model pendekatan pengembangan
software dengan metode waterfall
adalah pencerminan kepraktisan rekayasa, yang membuat kualitas software tetap
terjaga karena pengembangannya yang terstruktur dan terawasi. Disisi lain model
ini merupakan jenis model yang bersifat dokumen lengkap, sehingga proses
pemeliharaan dapat dilakukan dengan mudah. Akan tetapi dikarenakan dokumentasi
yang lengkap dan sangat teknis, membuat pihak klien sulit membaca dokumen yang
berujung pada sulitnya komunikasi antar pengembang dan klien. Dokumentasi kode
program yang lengkap juga secara tak langsung menghapus ketergantungan
pengembang terhadap pemrogram yang keluar dari tim pengembang. Hal ini sangat
menguntungkan bagi pihak pengembang dikarenakan proses pengembangan perangkat
lunak tetap dapat dilanjutkan tanpa bergantung pada pemrogram tertentu.
Kelemahan Metode Waterfall
Kelemahan pengembangan software
dengan metode waterfall
yang utama adalah lambatnya proses pengembangan perangkat lunak. Dikarenakan
prosesnya yang satu persatu dan tidak bisa diloncat-loncat menjadikan model
klasik ini sangat memakan waktu dalam pengembangannya. Disisi lain, pihak klien
tidak dapat mencoba sistem sebelum sistem benar-benar selesai pembuatannya.
Kelemahan yang lain adalah kinerja personil yang tidak optimal dan efisien karena
terdapat proses menunggu suatu tahapan selesai terlebih dahulu.
Secara keseluruhan model pendekatan pengembangan
software dengan metode waterfall
cocok untuk pengembangan software / perangkat lunak dengan tingkat resiko yang
kecil, dan memiliki ukuran yang kecil serta waktu pengembangan yang cukup
panjang. Model ini tidak disarankan untuk ukuran perangkat lunak yang besar dan
tingkat resiko yang besar.
2. V-Model
Dalam proses model Waterfall dasar
melihat beberapa kelemahan atau keterbatasan dalam model yang mulai model SDLC
baru. Seperti yang kita lihat dalam model Waterfall isu-isu yang ditemukan di
akhir SDLC, hal ini disebabkan pengujian yang terjadi pada tahap akhir dari
SDLC Anda. Untuk mengatasi masalah ini V-Model yang datang ke dalam gambar. Itu
selalu lebih baik untuk memperkenalkan pengujian dalam tahap awal SDLC, seperti
dalam model ini kegiatan pengujian akan dimulai dari tahap awal SDLC.
Sebelum memulai pengujian yang
sebenarnya, tim pengujian harus bekerja pada berbagai kegiatan seperti
penyusunan Strategi Uji, Uji Perencanaan, Penciptaan kasus Uji & Test
Scripts yang bekerja paralel dengan kegiatan pembangunan yang membantu untuk
mendapatkan tes diserahkan tepat waktu.
Dalam Model Pengembangan Perangkat
Lunak Siklus Hidup V, berdasarkan informasi yang sama (persyaratan spesifikasi
dokumen) kegiatan pembangunan & pengujian dimulai. Berdasarkan dokumen
persyaratan tim pengembang mulai bekerja pada desain & setelah selesai pada
desain mulai implementasi aktual dan tim pengujian mulai bekerja pada
perencanaan pengujian, menulis uji kasus, script pengujian. Kedua kegiatan bekerja
sejajar satu sama lain. Dalam model Waterfall & V-model mereka cukup mirip
satu sama lain. Karena itu adalah Uji Perangkat Lunak paling populer Hidup
Model Siklus sehingga sebagian besar organisasi mengikuti model ini.
V-model juga disebut sebagai
Verifikasi dan model Validasi. Kegiatan pengujian tampil dalam setiap fase dari
fase Siklus Hidup Uji Perangkat Lunak. Di paruh pertama model kegiatan validasi
pengujian terintegrasi dalam setiap fase seperti kebutuhan pengguna review,
dokumen Sistem Desain & di babak berikutnya kegiatan pengujian Verifikasi
datang dalam gambar.
Khas V-Model menunjukkan kegiatan Pengembangan
Perangkat Lunak di sisi kiri dari model dan sisi kanan dari Fase Pengujian
model yang sebenarnya dapat dilakukan.
Dalam proses
ini “Do-Prosedur” akan diikuti oleh tim pengembang dan “Check-Prosedur” akan
diikuti oleh tim pengujian untuk memenuhi persyaratan yang disebutkan.
Dalam siklus V-Model hidup
pengembangan perangkat lunak langkah yang berbeda yang diikuti Namun di sini
kita akan mengambil jenis yang paling umum dari V-model contoh. V-model
biasanya terdiri dari beberapa tahap sebagai berikut:
1. Unit
Pengujian: Persiapan Kasus Uji Satuan
2. Integrasi Pengujian: Persiapan Uji Kasus Integrasi
3. Sistem Pengujian: Persiapan kasus uji Sistem
4. Penerimaan Pengujian: Persiapan Uji Kasus Penerimaan
2. Integrasi Pengujian: Persiapan Uji Kasus Integrasi
3. Sistem Pengujian: Persiapan kasus uji Sistem
4. Penerimaan Pengujian: Persiapan Uji Kasus Penerimaan
V-model dikembangkan di Jerman untuk aplikasi
pertahanan. Didalam V-model terdapat 3 kompomen kerja yang pokok yakni
Project Definition yakni mendefenisian project apa yang akan dibuat, Time yakni
waktu yang dibutuhkan dalam pengimplementasiannya dan Project Test And
Integration atau pengujian dan integrasi project tersebut.
Model ini berpusat pada user. Dimana pengulangan
selalu dibutuhkan jika kebutuhan untuk user belum terpenuhi “ketidaktahuannya”
tanpa harus memberikan software dengan lingkungan yang baru. Resiko pada setiap
tahap dalam pengembangan dapat dikurangi dengan memahami kebutuhan user.
Didalam pendefenisian project terdapat aktivitas
Concept Operation (konsepsi project) yakni menentukan tujuan yang akan di
capai dalam pembuatan project tersebut. Requirement and Architecture
(persyaratan dan arsitektur) yakni harus dapat menjelaskan apa saja yang
diinginkan dan diperlukan oleh user. Untuk itu diperlukan adanya psroses
klarifikasi, perbaikan, penentuan kelengkapan, dan ruang lingkup. Sebagai
masukannya dapat berupa dokumen persyaratan dan keluarannya adalah ketetapan
persyaratan. Terdapat bermacam-macam persyaratan yang dapat dihasilkan :
·
Fungsional : menjelaskan tentang apa saja yang dapat dilakukan oleh system
·
Non fungsional : dapat berupa ukuran memori, jangka waktu respon.
·
Data : data apa saja yang perlu disimpan dan bagaimana penyimpanannya.
Detailed
Design yakni memperincikan desain sebuah aplikasi yang akan dibuat.
Selanjutnya
setelah Project tersebut telah ditetapkan maka Diimplementasikan lah atau di
jalankan. Selanjutnya dalam tahap Project Test and Integration
aplikasi/software yang telah dilakukan Integration test and Verification yang
mana dalam tahap ini aplikasi yang telah diimplementasikan di lakukan
verifikasi atau ditinjuau kegunaan nya apakah sesaui dengan kebutuhan user.
Selanjutnya Operation and Maintenance yakni melakukan
perbaikan atas apa yg telah di verifikasi dan di sesuaikan dengan kebutuhan
user. Dan pada akhirnya dalam model ini akan dilakukan proses Verivikasi
dan Validitas kepada user apakah sudah bekerja sesuai dengan yang diharapkan
dan apakah rancangan sesuai dengan apa nyang diinginkan.
3. Simple Interaction Design Model (Model Rancangan Interaksi Sederhana)
gambar simple interaction design model
Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki
satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai engan
kebutuhan, lalu didesain sesuia dengan persyaratan yang telah ditetap kan.
Setelah di Desain rancangan tersebut dibangun dan harus interaktif. Setelah itu
barulah racangan tersebut dievaluasi.
Evaluasi dapat
dilaukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain
ulang atau apakah rancanagn tersebut tidak sesuai dengan kebutuhan user, maka
alur tersebut akan terus berbupar hingga pada tahap evaluasi tidak lagi terjadi
kesalahan, baik dalam penetapan kebutuhan user maupun pendesainannya, sehingga
pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.
Star Life Cycle
Pada tahun 1989, Star siklus hidup model
yangdiusulkan oleh Hartson dan Hix seperti yang ditunjukkan pada gambar:
Misalnya Dalam siklus permodelan ini,
pengujian dilakukan terus menerus, tidak harus diakhir. dimulai dari menentukan
kosep desain (conceptual design). Dalam proses ini akan langsung terjadi
evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user,
bila belum maka akan terus berulang di evaluasi hingga benar-benar pas.
Setelah itu, apabila sudah pas, maka dari tahap evaluasi yang pertama akan
lanjut ke proses yg selanjutnya, yakni requirements/specification yakni
memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga
langsung terjadi pengevaluasian seperti tahap pertama.
Selanjutnya akan tetap sama, terjadi
pada tahap-tahap selanjutnya yakni task analysis/fungsion analysis,
pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah
aplikasi yang sesuai dengan kebutuhan user.
4. Star Lifecycle Model (Hartson & Hix, 1989)
- Analisa
Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan yang diinginkan baik dalam ketrampilan maupun peralatan.
Metode : tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.
Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan yang diinginkan baik dalam ketrampilan maupun peralatan.
Metode : tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.
- Evaluasi kompetisi
Tentukan kekuatan dan kelemahan rancangan
Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.
Tentukan kekuatan dan kelemahan rancangan
Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.
-Rancang sambil jalan
Gunakan hasil analisa untuk membuat alternatif solusi, minta masukan sampai dengan penentuan pilihan yang terbaik.
Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.
Gunakan hasil analisa untuk membuat alternatif solusi, minta masukan sampai dengan penentuan pilihan yang terbaik.
Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.
- Evaluasi dan validasi
Secara periodik user memberikan masukan selama pengembangan dan perancangan akan diulang berdasarkan masukan tadi.
Metode : amati kebutuhan pokok user dalam menggunakan sistem.
Secara periodik user memberikan masukan selama pengembangan dan perancangan akan diulang berdasarkan masukan tadi.
Metode : amati kebutuhan pokok user dalam menggunakan sistem.
- Benchmark
Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang sebaiknya ada dibandingkan dengan kompetitor, contoh : situs IBM.
Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang sebaiknya ada dibandingkan dengan kompetitor, contoh : situs IBM.
Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus
dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design )
dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah
sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di
evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap
evaluasi yang pertama aka lanjut ke proses yg selanjutnya yakni
requirements/specification yakni memverifikasikan persyaratan rancangan
tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap
pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan
selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping
hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan
user. Intinya pada rancangan model ini pengevaluasian dilakukan disetiap
tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang
lainnya.
Sumber
http://tommysetiawan1994.wordpress.com/2013/01/22/star-life-cylce-model-hartson-hlx1989/
Sumber
http://www.etunas.com/web/pengembangan-software-dengan-metode-waterfall.htm
http://arismigisetiawan.blogspot.com/
http://tommysetiawan1994.wordpress.com/2013/01/22/star-life-cylce-model-hartson-hlx1989/
http://riosilvianto92.blogspot.com/2014/06/simple-interaction-design-model.html
http://erniwijayanti07.blogspot.com/2013/07/star-lifecycle-model-hartson-hix-1989.html