juga dikenal sebagai model verifikasi dan validasi, model v
adalah perpanjangan model air terjun dan didasarkan pada asosiasi tahap
pengujian untuk setiap tahap pengembangan yang sesuai. ini berarti bahwa model
v menunjukkan hubungan antara setiap fase siklus hidup pengembangan dan fase
pengujian yang terkait. ada tahap anverifikasi di satu sisi fase 'v' dan
validasi di lain sisi. tahap pengkodean menggabungkan kedua sisi model v. sumbu
horisontal dan vertikal mewakili kelengkapan waktu atau proyek (kiri ke kanan)
dan tingkat abstraksi. ini adalah model yang sangat disiplin dan fase
berikutnya dimulai hanya setelah selesainya fase sebelumnya.
model v aplikasi hampir sama dengan model waterfall, karena
kedua model tersebut bersifat berurutan. persyaratan harus sangat jelas sebelum
proyek dimulai, karena biasanya mahal untuk kembali dan melakukan perubahan.
sebaiknya digunakan untuk proyek berukuran kecil sampai
menengah dimana persyaratannya didefinisikan dengan jelas dan tetap.
kepercayaan pelanggan yang tinggi dibutuhkan. karena, tidak
ada prototipe yang dihasilkan, ada risiko yang sangat tinggi yang terlibat
dalam memenuhi harapan pelanggan.
asal usul model v
salah satu hambatan utama model air terjun(water fall)
adalah bahwa,sebelumnya telah di temukan kecacatan pada proses pembangunan yang
kemudian menjadi lambat, karena pengujian dilakukan pada akhir siklus
pengembangan. ini menjadi sangat menantang dan mahal untuk memperbaiki cacat
sejak ditemukan pada tahap selanjutnya. untuk mengatasi masalah ini, model
pengembangan baru diperkenalkan dengan nama "model v". model v
mendapat namanya dari kenyataan bahwa prosesnya sering dipetakan sebagai flowchart
yang mengambil bentuk huruf v. pengenalan model v benar-benar membuktikan
implementasi pengujian langsung dari fase kebutuhan.
verification phases | validation phases
ada beberapa tahap verifikasi & validasi dalam model v,
masing-masing dijelaskan secara rinci di bawah ini,
verifikasi: analisis kebutuhan bisnis >> spesifikasi
fungsional >> desain tingkat tinggi >> desain rinci
validasi: tes penerimaan >> pengujian sistem >>
pengujian integrasi >> pengujian unit
business requirements analysis | acceptance tests
pada tahap analisis kebutuhan, langkah pertama dalam proses
verifikasi, persyaratan sistem dikumpulkan dengan menganalisis kebutuhan
pengguna. persyaratan dikumpulkan, dianalisis dan dipelajari. bagaimana sistem
diimplementasikan tidak penting di sini, tapi sistem apa yang seharusnya
dilakukan, itu penting. ini melibatkan komunikasi terperinci dengan pelanggan
untuk memahami dan mendokumentasikan ekspektasinya dan persyaratan yang tepat
dalam dokumen spesifikasi persyaratan perangkat lunak. dokumen ini akan menjadi
panduan bagi perancang sistem dalam tahap perancangan sistem. ini adalah
kegiatan yang sangat penting dan perlu dikelola dengan baik, karena sebagian
besar pelanggan tidak yakin dengan apa sebenarnya yang mereka butuhkan. namun
hal itu tidak menentukan bagaimana perangkat lunak akan dirancang atau
dibangun.
uji penerimaan pengguna (uat) rencana dikembangkan pada
tahap ini karena persyaratan bisnis dapat digunakan sebagai masukan. ini
melibatkan pengujian produk di lingkungan pengguna. uat dilakukan di lingkungan
pengguna yang menyerupai lingkungan produksi, menggunakan data yang realistis.
uat memverifikasi bahwa sistem yang dikirimkan memenuhi persyaratan dan sistem
pengguna siap digunakan secara real time.
functional specifications | system testing
begitu anda memiliki persyaratan produk yang jelas dan
rinci, sekarang saatnya merancang sistem yang lengkap. perancangan sistem
adalah fase dimana para insinyur sistem menganalisis dan memahami kebutuhan
bisnis dan mengetahui kemungkinan dan teknik yang dengannya persyaratan
pengguna dapat diterapkan. dokumen spesifikasi perangkat lunak yang berfungsi
sebagai cetak biru untuk tahap pengembangan dihasilkan.
rencana uji sistem dikembangkan berdasarkan spesifikasi
fungsional. uji sistem memastikan bahwa harapan dari aplikasi yang dikembangkan
terpenuhi. seluruh aplikasi diuji karena fungsinya, saling ketergantungan dan
komunikasi. pengujian sistem memverifikasi bahwa persyaratan fungsional dan
non-fungsional telah terpenuhi. pengujian beban dan kinerja, pengujian stres,
pengujian regresi, dan lain-lain, merupakan subkumpulan pengujian sistem.
high-level design | integration testing
spesifikasi arsitektur dipahami dan dirancang pada tahap
ini. dasar dalam memilih arsitektur adalah bahwa ia harus menyadari semua yang
biasanya terdiri dari daftar modul, fungsi singkat setiap modul, hubungan antar
muka, dependensi, tabel database, diagram arsitektur, rincian teknologi dll.
biasanya lebih dari satu pendekatan teknis adalah diusulkan dan berdasarkan
kelayakan teknis dan finansial keputusan akhir diambil. perancangan sistem
dipecah menjadi modul yang mengambil fungsionalitas yang berbeda. hal ini juga
disebut sebagai high level design (hld). ini memberikan gambaran tentang
solusi, platform, sistem, produk dan layanan / proses. transfer data dan
komunikasi antara modul internal dan dengan dunia luar (sistem lain) dipahami
dan didefinisikan secara jelas pada tahap ini.
dengan informasi ini, rencana uji integrasi dapat dirancang
dan didokumentasikan selama tahap ini. uji integrasi dilakukan untuk menguji
koeksistensi dan komunikasi modul internal dalam sistem. tes ini memverifikasi
bahwa unit yang dibuat dan diuji secara mandiri dapat hidup berdampingan dan
berkomunikasi di antara mereka sendiri.
detailed design | unit testing
pada tahap desain tingkat rendah (lld), desain internal yang
rinci untuk semua modul sistem ditentukan. sistem yang dirancang dipecah
menjadi unit atau modul yang lebih kecil dan masing-masing dijelaskan sehingga
pemrogram bisa mulai coding secara langsung. dokumen desain tingkat rendah atau
spesifikasi program akan berisi logika fungsional rinci modul, dalam kode semu.
adalah penting bahwa desainnya kompatibel dengan modul lain dalam arsitektur
sistem dan sistem eksternal lainnya.
unit test plans (utps) dapat dirancang pada tahap ini
berdasarkan desain modul internal. unit adalah entitas terkecil yang dapat
berdiri sendiri, mis. sebuah modul program pengujian unit memverifikasi bahwa
entitas terkecil dapat berfungsi dengan benar saat diisolasi dari kode / unit
lainnya. ini membantu menghilangkan bug pada tahap awal, meskipun semua cacat
tidak dapat ditemukan oleh unit testing. pengujian ini pada dasarnya dilakukan
oleh tim pengembang.
the coding phase
pengkodean aktual dari modul sistem diambil dalam fase coding.
bahasa pemrograman yang paling sesuai diputuskan berdasarkan persyaratan sistem
dan arsitektur. pengkodean dilakukan berdasarkan pedoman dan standar
pengkodean. kode berjalan melalui banyak ulasan kode dan dioptimalkan untuk
kinerja terbaik sebelum pembuatan akhir diperiksa ke dalam repositori.
setelah pengkodean selesai, jalan eksekusi berlanjut ke sisi
kanan v dimana rencana uji yang dikembangkan sebelumnya digunakan.
kelebihan model v
keuntungan utama v model adalah sangat mudah dipahami dan
diterapkan. kesederhanaan model ini juga mempermudah pengelolaan.
sederhana dan mudah dimengerti dan digunakan.
model dan fase yang sangat disiplin diselesaikan satu per
satu.
bekerja dengan baik untuk proyek yang lebih kecil dimana
persyaratannya sangat dipahami.
mudah dikelola karena kekakuan model. setiap tahap memiliki
deliverable dan proses review yang spesifik.
menguji aktivitas seperti perencanaan, perancangan uji
terjadi dengan baik sebelum pengkodean sehingga ambiguitas diidentifikasi sejak
awal. ini menghemat banyak waktu. maka peluang sukses yang lebih tinggi
dibanding model waterfall.
mudah diatur karena setiap fase memiliki tujuan dan sasaran
yang jelas.
kelemahan dari model v
kelemahannya adalah modelnya tidak fleksibel terhadap
perubahan dan kalau-kalau ada perubahan persyaratan, yang sangat umum terjadi
di dunia dinamis saat ini, menjadi sangat mahal untuk melakukan perubahan.
resiko tinggi dan ketidakpastian
tidak cocok untuk proyek di mana persyaratan berada pada
risiko sedang hingga tinggi untuk mengalami perubahan.
setelah aplikasi dalam tahap pengujian, sulit untuk kembali
dan mengubah fungsionalitas.
perangkat lunak dikembangkan selama tahap implementasi, jadi
tidak ada prototipe kerja awal dari perangkat lunak yang diproduksi sampai
larut selama siklus hidup.
jika ada perubahan terjadi di tengah jalan, maka dokumen uji
beserta dokumen persyaratan harus diperbaharui.
referensi :
softwaretestingstudio
http://www.softwaretestingstudio.com/v-model-software-development/
softwaretestingstudio
http://www.softwaretestingstudio.com/v-model-software-development/