V-modeli: her tasarım aşamasının bir test karşılığı olduğu yaşam döngüsü
V-modelinin neden V şeklinde çizildiğini, hangi geliştirme aşamasının hangi test seviyesiyle eşleştiğini ve doğrulama ile geçerleme kavramlarının burada nasıl ayrıldığını öğrenirsiniz.
Bir bakışta
- V-modeli, şelale akışının test odaklı bir uzantısı olarak anlatılır. Kodlamadan sonra adımlar yukarı doğru kıvrılır ve V şeklini oluşturur.
- Sol kol belirtim ve tasarım, sağ kol birleştirme ve sınamadır. Sol koldaki her aşamanın sağ kolda karşılık gelen bir test seviyesi vardır.
- Test planı tasarımla birlikte yazılır, sonuna bırakılmaz. Kabul, sistem, entegrasyon ve birim testleri ilgili tasarım aşamasında planlanır.
- Zaman soldan sağa akar, geri dönüşler zordur. Bu yüzden model, gereksinimleri baştan oturan işlere uygun, değişken işlere ise zayıf kalır.
V-modeli nedir?
V-modeli, bir sistemin ya da yazılımın geliştirme yaşam döngüsünü V harfi biçiminde gösteren modeldir. Yazılım geliştirme bağlamında, şelale modelinin bir uzantısı olarak da anlatılır: adımlar kodlama aşamasına kadar aşağı iner, sonra yukarı doğru kıvrılarak V'yi oluşturur.
Modelin ana fikri, geliştirme aşamaları ile test aşamaları arasında bire bir ilişki kurmasıdır. Test, en sonda ayrı bir iş olarak değil, her tasarım düzeyinin karşılığı olarak baştan düşünülür. Model sistem mühendisliğinde de kullanılır; yazılım uyarlaması ise bunun yazılım bağlamındaki yorumudur.
Sol kol ve sağ kol
V'nin sol kolu gereksinimlerin parçalanmasını ve belirtimlerin oluşturulmasını temsil eder. Ana fikir yukarıdan aşağıya iner: önce kullanıcı ihtiyacı, sonra sistem tasarımı, mimari tasarım ve modül tasarımı. En altta kodlama yer alır.
Sağ kol ise parçaların birleştirilmesini ve sınanmasını temsil eder. Aşağıdan yukarıya çıkarken önce küçük birimler sınanır, sonra birleştirilen modüller, ardından tüm sistem ve en sonunda kullanıcı ihtiyacına karşı kabul sınanır. Zaman soldan sağa akar; yineleme gerekirse V'nin dikey hattı boyunca bir üst ya da alt düzeye gidilir.
Her tasarım düzeyinin sağ kolda bir test karşılığı vardır
Yaygın anlatımdaki eşleşme
| Sol kol: tasarım | Sağ kol: test | |
|---|---|---|
| En üst düzey | Gereksinim analizi | Kabul testi |
| Sistem düzeyi | Sistem tasarımı | Sistem testi |
| Mimari düzey | Mimari tasarım | Entegrasyon testi |
| Modül düzeyi | Modül tasarımı | Birim testi |
Test planı tasarımla birlikte yazılır
V-modelini şelaleden ayıran en somut özellik budur. Yaygın anlatıma göre kullanıcı kabul testleri gereksinim aşamasında, sistem testi belgeleri sistem tasarımında, entegrasyon testi tasarımı mimari tasarımda, birim test planları ise modül tasarımında hazırlanır.
Bu düzen iki işe yarar. Birincisi, gereksinim yazılırken nasıl sınanacağı da düşünüldüğü için belirsiz ya da sınanamayan gereksinimler erken fark edilir. İkincisi, test ekibi kod bitene kadar beklemeden hazırlık yapabilir.
Doğrulama ve geçerleme
V-modelinde iki sorunun ayrı ayrı sorulduğu söylenir. Doğrulama, ürünün belirtimi karşılayıp karşılamadığına bakar ve çoğu zaman kısaca ürünü doğru mu yapıyoruz sorusu olarak özetlenir. Geçerleme ise ürünün gerçek kullanıcı ihtiyacını karşılayıp karşılamadığına bakar ve doğru şeyi mi yapıyoruz sorusuna denk düşer.
Bu ayrım önemlidir, çünkü bir ürün belirtime kusursuz uyabilir ve yine de kullanıcının ihtiyacını karşılamayabilir. Gereksinimlerin kendisi de üst düzey ihtiyaca karşı geçerlenmelidir; yani geçerleme yalnızca V'nin sağ ucunda yapılan bir iş değildir. Terimlerin tam tanımı sektöre ve standarda göre biraz farklılaşır.
Güçlü yanlar ve sınırlar
Modelin güçlü yanı izlenebilirliktir: her gereksinimin en az bir tasarım öğesine ve bir kabul testine bağlanması beklenir. Sorumluluk ve çıktılar açık olduğu için planlama sapmaları ve riskler erken görülebilir. Güvenlik ya da düzenleme gerektiren işlerde bu izlenebilirlik değer taşır.
Sınırı ise esneklikte ortaya çıkar. Zaman soldan sağa akar ve gerçekten geri dönmek zordur; gereksinimler sık değişiyorsa tüm V'nin yeniden dolaşılması gerekebilir. Ayrıca model bir proje içindeki yazılım geliştirmeyi anlatır, tüm kurumu ya da işletim ve bakım dönemini ayrıntılı kapsamaz. Hızlı geri bildirim isteyen işlerde çevik yaklaşımlar ya da hibrit yapılar tercih edilir.
Proje yönetimi programlarında yeri
V-modeli, yazılım yaşam döngüsü modelleri içinde sıkça karşılaşılan bir kalıptır. Mindset'in IT Proje Yönetimi Sertifika Programı, yazılım geliştirmeye yönelik özel proje yönetim ilkelerini ve IT projelerinde kalite güvencesi ile test yönetimini işler; hangi modelin hangi projeye uyduğunu tartışmak için bu çerçeve yararlıdır.
İlgili Mindset programı
IT Proje Yönetimi Sertifika Programı
Sık sorulan sorular
V-modeli şelale modelinden nasıl farklıdır?
İkisi de sıralı ilerler. Şelalede test çoğu zaman sonda bir aşama olarak anılırken V-modelinde her geliştirme aşamasının karşılık gelen bir test seviyesi baştan tanımlanır. Bu yüzden V-modeli şelalenin test odaklı bir uzantısı gibi anlatılır.
V-modelinde test hangi aşamada başlar?
Test planlaması geliştirme aşamalarıyla birlikte başlar: kabul testleri gereksinimle, sistem testi sistem tasarımıyla, entegrasyon testi mimariyle, birim testi modül tasarımıyla ilişkilendirilir. Testin yürütülmesi ise sağ kolda, kodlama bittikten sonra gerçekleşir.
V-modeli çevik projelerde kullanılır mı?
Saf haliyle genellikle hayır, çünkü sıralı akış ve baştan oturan gereksinimler varsayar. Ancak seviyeli test düşüncesi, yani birim, entegrasyon, sistem ve kabul ayrımı, çevik ekiplerde de kullanılır. Model bütünüyle alınmasa da fikir taşınır.
Doğrulama ile geçerleme neden ayrı sayılır?
Doğrulama ürünün belirtime uyup uymadığını, geçerleme ise gerçek ihtiyaca uyup uymadığını sınar. Belirtim yanlışsa ürün belirtime uygun olduğu halde işe yaramaz. İki sorunun ayrı sorulması bu riski görünür kılar.
V-modelinin tek bir resmî tanımı var mı?
Hayır. Sistem mühendisliğinde, Almanya'da kamu projelerinde kullanılan yönteminde ve yazılım test topluluğunda biraz farklı biçimlerde anlatılır. Aşama adları ve eşleşmeler kaynağa göre değişebilir; bu nedenle kullanmadan önce hangi sürümün kastedildiği netleştirilmelidir.