1.
Pengertian
V Model
Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian. Bisa dikatakan model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang.
Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian. Bisa dikatakan model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang.
Tahapan dalam V Model
Tahapan pada V Model dibagi menjadi 2 garis besar yaitu tahap Verifikasi dan Validasi atau testing.
Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen, tahapan ini meliputi serangkaian kegiatan sebagai berikut:
1.
Business Case: Merupakan tahapan
awal yang menggambarkan kebutuhan/harapan konsumen terhadap sistem yang akan
dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya
yang harus disediakan.
2.
Requirement: pada fase ini klien
mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan
dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
3.
Analisis Informasi: Setelah
diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas
difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut,
termasuk metode, hardware dan software apa saja yang diperlukan untuk mencapai
kebutuhan yang sudah didefinisikan.
4.
Perancangan Sistem: pada tahapan ini
akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang
sudah disepakati.
5.
Unit Design: merancang setiap
elemen/unit software termasuk rancangan modul/program, antarmuka, database dan
lain-lain.
6.
Development: merealisasikan hasil
rancangan menjadi satu aplikasi/program tertentu.
Tahapan
Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software
dengan spesifikasi yang sudah ditetapkan. Tahapan ini dicapai melalui
serangkaian pengujian/testing sebagai berikut:
o
Unit test: menguji setiap
komponen/unit program apakah sesuai dengan rancangan unit yang sudah
ditetapkan. Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu
yang bertugas sebagai software tester, tetapi dalam kenyataannya seringkali
unit testing dilakukan oleh programmer sendiri.
o
Interface test: setelah semua
komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test
untuk melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain
sesuai dengan fungsi yang diharapkan.
o
System test: setelah semua interface
berjalan dengan baik, selanutnya dilakukan system test untuk melihat sejauh
mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System
testing bersifat menyeluruh dan tidak dapat dilakukan berdasarkan
fungsionalitas sistem yang diuji secara terpisah. Aktivitas pada system testing
termasuk melakukan pengujian hal-hal berikut:
1.
Performance – apakah kinerja sistem
sesuai dengan target yang sudah didefinisikan sebelumnya.
2.
Volume – apakah software/sistem
dapat menampung volume informasi yang cukup besar.
3.
Stress – apakah software/sistem
dapat menampung sejumlah informasi pada waktu-waktu tertentu.
4.
Documentation – apakah semua
dokumentasi penting sudah disiapkan.
5.
Robustness – apakah software/sistem
cenderung stabil pada berbagai kondisi diluar dugaan/ekstrim.
o
Acceptance test merupakan aktivitas
untuk menguji sejauh mana sistem/software dapat membantu memecahkan business
case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan
konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini
sering kali disebut sebagai User Acceptance Test (UAT).
o
Release testing: test ini dilakukan
untuk menguji sejauh mana sistem/software dapat mendukung aktivitas organisasi dan
berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa
pertanyaan coba dijawab pada fase ini misalnya apakah software tersebut
mempengaruhi sistem lain? Apakah software tersebut kompatibel dengan sistem
lain? Bagaimana kinerja sistem sebenarnya di dalam organisasi?
Kelebihan
V model:
o
V model sangat fleksibel. V
model ini bisa digunakan untuk project tailoring serta penambahan pengurangan
method dan tool secara dinamik.
o
V model dikembangkan dan di
maintain oleh publik. User dari V model berpartisipasi dalam change board yang
memproses semua change request terhadap V model.
Kekuranagn
V model
o
V model hanya bisa digunakan
sekali dalam suatu proyek hal tersebut disebabkan kerena V model merupakan
model yang project oriented.
o
V model bersifat terlalu fleksibel
sehingga mengakibatkan beberapa aktivitas-aktivitas yang digambarkan dalam V
model menjadi terlalu abstrak. Hal tersebut mengakibatkan tidak bisa diketahui
dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.
Dimana
saja V Model Diterapkan?
16. Dalam proyek teknologi informasi di Jerman
17. V Model dibandingkan dengan CMM
18. V Model didesain untuk mengembangkan sistem yang didalamnya
terdapat dua komponen
19. Pengembangan V Model dalam bidang industri dapat dilakukan
dengan mudah
Sejarah
Model Waterfall
Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .
Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Berikut gambar model waterfall.
Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .
Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Berikut gambar model waterfall.
Pengertian
Waterfall
Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.
Langkah-langkah yang harus dilakukan pada metodologi Waterfall
1. Requirement Analysis
Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.
2. System Design
Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.
3. Implementation
Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
4. Integration & Testing
Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.
5. Operation & Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.
Keuntungan Waterfall
Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.
Langkah-langkah yang harus dilakukan pada metodologi Waterfall
1. Requirement Analysis
Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.
2. System Design
Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.
3. Implementation
Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
4. Integration & Testing
Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.
5. Operation & Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.
Keuntungan Waterfall
o
Kualitas dari sistem yang dihasilkan
akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak
terfokus pada tahapan tertentu.
o
Document pengembangan system sangat
terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum
melangkah ke fase berikutnya. Jadi setiap fase atau tahapan akan
mempunyai dokumen tertentu.
o
Metode ini masih lebih baik digunakan
walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan.
Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui
dengan baik.
Kelemahan
Waterfall
o
Diperlukan majemen yang baik, karena
proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya
suatu produk.
o
Kesalahan kecil akan menjadi masalah
besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan
selanjutnya.
o
Pelanggan sulit menyatakan kebutuhan
secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat
awal pengembangan.
o
Pelanggan harus sabar, karena
pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai.
Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.
o
Pada kenyataannya, jarang mengikuti
urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan
masalah baru.
Kapan
Model Waterfall digunakan?
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
28. Ketika semua persyaratan sudah dipahami dengan baik di awal
pengembangan.
29. Definisi produk stabil dan tidak ada perubahan saat
pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan,
perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang
digunakan pun harus sudah dipahami dengan baik.
30. Menghasilkan produk baru, atau versi baru dari produk yang
sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk
incremental development, yang setiap tahapnya sama dengan Waterfall kemudian
diulang-ulang.
31. Porting produk yang sudah ada ke
dalam platform baru.
Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.
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 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, 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. Berikut gambar modelnya.
32. 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.
33. 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.
34. Rancangan 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.
35. 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.
36. 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.

0 komentar:
Posting Komentar