Kamis, 05 Desember 2013
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):
bagan kerja Metode Waterfall
Pada bagan
diatas, ada 5 tahap proses pengerjaan, yaitu:
- Communication merupakan tahap pencarian informasi kebutuhan dari keseluruhan sistem yang diaplikasikan ke dalam software
- Planning pada tahap ini, diestimasikan perencanaan pembuatan software, seperti biaya, peralatan, perlengkapan dan jumlah pekerja serta penjadwalan kerja
- Modelling menerjemahkan informasi yang sudah diperoleh ke dalam sebuah representasi, biasanya dalam bentuk blueprint
- Construction Terbagi dalam 2 tahap, yaitu proses Coding dan Testing.
- Coding merupakan proses pembuatan software dengan menggunakan bahasa pemrograman tertentu.
- Testing merupakan tahap ujicoba terhadap software yang dikerjakan.
- Deployment tahap terakhir dimana software diberikan kepada user, kemudian user akan memberikan feedback. Pada tahap ini juga dilakukan proses maintenance.
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.
Keunggulan Metode Waterfall
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.
Rabu, 04 Desember 2013
Contoh Kasus Database Kepegawaian
Contoh Kasus
1 :
Gambar 1
:menunjukkan relasi kepala departemen antara entiti Pegawai dengan Departemen adalah
1 : 1 yang berarti satu orang pegawai hanya dapat mengepalai satu departemen
dan satu departemen hanya boleh dikepalai oleh satu orang pegawai. Dilihat dari
kenyataan yang terjadi, relasi tersebut adalah benar karena tidak mungkin pada
satu waktu, ada lebih dari satu pegawai yang mengepalai suatu departemen dan
begitu pula sebaliknya.
Gambar 1.
Relasi entiti Pegawai dan entitiDepartemen
Namun
ternyata ketika terjadi pergantian kepala departemen, data kepala departemen
yang lama sudah tidak dapat lagi diketahui. Dengan kata lain, database tidak
menyediakan penyimpanan data masa lampau. Oleh karena itu, desain gambar 1
ditambahkan suatu entiti yang mencatat tanggal seorang pegawai menjabat suatu
departemen, sehingga dapat ditelusuri siapa saja yang pernah menjabat menjadi
kepala departemen suatu departemen (gambar 2).
Gambar 2.
Penambahan entiti History Kepala Departemen
Apabila
ruang lingkup ditambah dengan pencatatan setiap jabatan yang dipegang selama
seorang pegawai, maka gambar 2 harus diubah lagi dengan memasukkan informasi
pilihan jabatan yang mungkin dijabat seorang pegawai selain kepala departemen.
Sebagai seorang pegawai pasti mempunyai sebuah jabatan, sehingga dari entiti
history jabatan dapat diketahui departemen yang saat itu menaunginya. Oleh
karena itu, relasi antara entiti Pegawai dengan entiti Departemen dapat
dihilangkan.
Gambar 3.
Perubahan entiti History Jabatan
Moss poin
(d) dan Elmasri poin (a) menyatakan bahwa pembuatan model harus disesuaikan
dengan fakta. Contoh kasus 1 memperlihatkan bahwa dalam melakukan desain perlu
memastikan data apa saja yang dibutuhkan baik sekarang maupun yang akan datang
dapat tersedia. Pada gambar 1 terdapat permasalahan yaitu tidak menyediakan
penyimpanan data masa lampau. Kemudian yang kedua adalah apakah database dapat
memenuhi kebutuhan sesuai dengan pertumbuhan user sebagaimana yang
digambarkan pada gambar 3 yaitu bahwa jenis jabatan dapat semakin beragam, oleh
karena itu dibuat sebuah entiti tersendiri.
Contoh kasus
2 :
Pada suatu database
yang diakses oleh banyak user, perlu diperhatikan data mana saja
yang boleh diakses seorang pegawai, data mana yang tidak boleh diakses oleh seorang
pegawai. Seperti yang dilihat pada gambar 4, setiap pegawai berhak melihat
history jabatannya masing-masing maupun milik pegawai lain, namun setiap
pegawai (kecuali bagian penggajian) hanya boleh melihat data gaji miliknya
sendiri.
Gambar 4.
Pengaksesan history jabatan
Untuk
memastikan data agar dapat diakses oleh banyak user pada banyak aplikasi
maka perlu diperhatikan pemilihan database yang digunakan. Apabila
ternyata database yang digunakan tidak mendukung management user,
maka perlu disediakan entiti Hak Akses dan entiti Menu (gambar 5).
Gambar 5.
Penambahan hak akses menu
Contoh kasus
2 memperlihatkan bahwa pemilihan database juga mempengaruhi desain database,
antara lain adalah management user atau pemilihan tipe data, dimana tiap
database menyediakan tipe data yang berbeda.
Contoh kasus
3 :
Seorang
pegawai berprestasi akan dikaitkan dengan jabatan apa yang dimiliki pada saat
itu, sehingga pada gambar 6 digambarkan bahwa entity Prestasi direlasikan
dengan entiti History Jabatan.
Gambar 6. Entiti
Prestasi berleasi dengan entity Jabatan
Ternyata
prestasi tidak sepenuhnya melekat pada prestasi, namun sebenarnya lebih tepat
apabila entiti Prestasi direlasikan dengan entiti Pegawai. Untuk mengetahui
prestasi seorang pegawai didapat pada saat pegawai tersebut menjabat menjadi
apa, dapat dilakukan proses query. Contoh kasus 3 memperlihatkan bahwa
ketika mengadopsi aturan bisnis dengan obyek pada dunia nyata harus dilakukan
dengan cermat, sehingga relasi yang dibuat menjadi tepat (Moss poin (d) dan
Elmasri poin (a) dan memastikan bahwa tiap definisi/semantik menempel pada data
yang sesuai (Moss (a) dan Elmasri (d)).
Gambar 7.
Entiti Prestasi berelasi dengan entity Pegawai
Langganan:
Postingan (Atom)