V modeli, süreçlerin yürütülmesinin V şeklinde sıralı bir şekilde gerçekleştiği bir SDLC modelidir. Doğrulama ve Doğrulama modeli olarak da bilinir .
V-Modeli, şelale modelinin bir uzantısıdır ve ilgili her geliştirme aşaması için bir test aşamasının ilişkilendirilmesine dayanır. Bu, geliştirme döngüsündeki her bir aşama için doğrudan ilişkili bir test aşamasının olduğu anlamına gelir. Bu oldukça disiplinli bir modeldir ve bir sonraki aşama ancak önceki aşamanın tamamlanmasından sonra başlar.
V-Modeli – Tasarım
V-Model kapsamında, geliştirme aşamasının ilgili test aşaması paralel olarak planlanmaktadır. Yani ‘V’nin bir tarafında Doğrulama aşamaları, diğer tarafında ise Doğrulama aşamaları var. Kodlama Aşaması V-Modelinin iki tarafını birleştirir.
Aşağıdaki çizimde SDLC’nin V-Modelindeki farklı aşamalar gösterilmektedir.

V-Modeli – Doğrulama Aşamaları
V-Model’de çeşitli Doğrulama aşamaları vardır ve bunların her biri aşağıda ayrıntılı olarak açıklanmaktadır.
İş Gereksinimi Analizi
Bu, ürün gereksinimlerinin müşterinin bakış açısından anlaşıldığı geliştirme döngüsündeki ilk aşamadır. Bu aşama, müşterinin beklentilerini ve tam ihtiyacını anlamak için müşteriyle ayrıntılı iletişimi içerir. Bu çok önemli bir faaliyettir ve iyi yönetilmesi gerekir, çünkü müşterilerin çoğu tam olarak neye ihtiyaç duyduklarından emin değildir. İş gereksinimleri kabul testi için girdi olarak kullanılabileceğinden, kabul testi tasarım planlaması bu aşamada yapılır .
Sistem tasarımı
Açık ve ayrıntılı ürün gereksinimlerine sahip olduğunuzda, tüm sistemi tasarlamanın zamanı gelmiştir. Sistem tasarımı, geliştirilmekte olan ürünün tüm donanım ve iletişim kurulumunu anlayacak ve detaylandıracaktır. Sistem test planı sistem tasarımına dayalı olarak geliştirilir. Bunu daha erken bir aşamada yapmak, daha sonra gerçek test yürütmesi için daha fazla zaman bırakır.
Mimari tasarım
Bu aşamada mimari özellikler anlaşılır ve tasarlanır. Genellikle birden fazla teknik yaklaşım önerilir ve teknik ve mali fizibiliteye dayanarak nihai karar alınır. Sistem tasarımı farklı işlevler üstlenen modüllere bölünmüştür. Bu aynı zamanda Yüksek Düzey Tasarım (HLD) olarak da adlandırılır .
İç modüller arasındaki ve dış dünya (diğer sistemler) ile veri aktarımı ve iletişim bu aşamada açıkça anlaşılır ve tanımlanır. Bu bilgilerle entegrasyon testleri bu aşamada tasarlanabilir ve belgelenebilir.
Modül Tasarımı
Bu aşamada, Düşük Seviyeli Tasarım (LLD) olarak adlandırılan, tüm sistem modülleri için ayrıntılı iç tasarım belirlenir . Tasarımın sistem mimarisindeki diğer modüllerle ve diğer dış sistemlerle uyumlu olması önemlidir. Birim testleri, herhangi bir geliştirme sürecinin önemli bir parçasıdır ve maksimum hata ve hataların çok erken bir aşamada ortadan kaldırılmasına yardımcı olur. Bu birim testleri bu aşamada dahili modül tasarımlarına göre tasarlanabilir.
Kodlama Aşaması
Tasarım aşamasında tasarlanan sistem modüllerinin asıl kodlaması Kodlama aşamasında ele alınır. En uygun programlama diline sistem ve mimari gereksinimlere göre karar verilir.
Kodlama, kodlama yönergelerine ve standartlarına göre gerçekleştirilir. Kod çok sayıda kod incelemesinden geçer ve son yapı depoya eklenmeden önce en iyi performans için optimize edilir.
Doğrulama Aşamaları
Bir V-Modelindeki farklı Doğrulama Aşamaları aşağıda ayrıntılı olarak açıklanmaktadır.
Birim Testi
Modül tasarımı aşamasında tasarlanan birim testleri, bu doğrulama aşamasında kod üzerinde yürütülür. Birim testi, kod düzeyinde yapılan testtir ve hataların erken bir aşamada ortadan kaldırılmasına yardımcı olur, ancak tüm kusurlar birim testiyle ortaya çıkarılamaz.
Entegrasyon Testi
Entegrasyon testi mimari tasarım aşamasıyla ilişkilidir. Entegrasyon testleri, dahili modüllerin sistem içerisinde bir arada bulunmasını ve iletişimini test etmek amacıyla yapılır.
Sistem Testi
Sistem testi doğrudan sistem tasarım aşamasıyla ilişkilidir. Sistem testleri, tüm sistem işlevselliğini ve geliştirilmekte olan sistemin harici sistemlerle iletişimini kontrol eder. Yazılım ve donanım uyumluluk sorunlarının çoğu, bu sistem testinin yürütülmesi sırasında ortaya çıkarılabilir.
Kabul testleri
Kabul testi, iş gereksinimi analizi aşamasıyla ilişkilidir ve ürünün kullanıcı ortamında test edilmesini içerir. Kabul testleri, kullanıcı ortamında bulunan diğer sistemlerle uyumluluk sorunlarını ortaya çıkarır. Ayrıca gerçek kullanıcı ortamındaki yük ve performans kusurları gibi işlevsel olmayan sorunları da keşfeder.
V-Model ─ Uygulama
V-Model uygulaması şelale modeliyle hemen hemen aynı olup her iki model de sıralı tiptedir. Proje başlamadan önce gereksinimlerin çok açık olması gerekir çünkü geri dönüp değişiklik yapmak genellikle pahalıdır. Bu model, kesinlikle disiplinli bir alan olduğundan tıbbi geliştirme alanında kullanılmaktadır.
Aşağıdaki işaretçiler V-Model uygulamasını kullanmak için en uygun senaryolardan bazılarıdır.
- Gereksinimler iyi tanımlanmış, açıkça belgelenmiş ve sabittir.
- Ürün tanımı stabildir.
- Teknoloji dinamik değildir ve proje ekibi tarafından iyi anlaşılmaktadır.
- Belirsiz veya tanımlanmamış gereksinimler yoktur.
- Proje kısa.
V-Model – Artıları ve Eksileri
V-Model yönteminin avantajı anlaşılmasının ve uygulanmasının oldukça kolay olmasıdır. Bu modelin basitliği aynı zamanda yönetimini de kolaylaştırır. Dezavantajı ise modelin değişikliklere karşı esnek olmaması ve günümüzün dinamik dünyasında çok yaygın olan bir gereksinim değişikliği olması durumunda değişikliği yapmanın çok pahalı hale gelmesidir.
V-Model yönteminin avantajları aşağıdaki gibidir –
- Bu oldukça disiplinli bir modeldir ve Aşamalar birer birer tamamlanır.
- Gereksinimlerin çok iyi anlaşıldığı küçük projeler için iyi çalışır.
- Basit ve anlaşılması ve kullanılması kolaydır.
- Modelin sağlamlığı nedeniyle yönetimi kolaydır. Her aşamanın belirli çıktıları ve bir inceleme süreci vardır.
V-Model yönteminin dezavantajları aşağıdaki gibidir –
- Yüksek risk ve belirsizlik.
- Karmaşık ve nesne yönelimli projeler için iyi bir model değil.
- Uzun ve devam eden projeler için zayıf model.
- Gereksinimlerin orta ila yüksek düzeyde değişme riskinin olduğu projeler için uygun değildir.
- Bir uygulama test aşamasına geçtikten sonra geri dönüp bir işlevi değiştirmek zordur.
- Yaşam döngüsünün sonuna kadar hiçbir çalışan yazılım üretilmez.