V-Model (Yazılım geliştirme)

v-model (yazılım geliştirme) şelale (waterfall) modelinin gelişmiş hali olarak düşünülebilecek bir yazılım geliştirme süreci sunar. doğrusal bir yönde ilerlemek yerine, süreç adımları kodlama evresinden sonra yukarıya doğru eğim alır ve tipik v şeklini oluşturur. v-model geliştirme yaşam çevriminin her bir evresi arasındaki ilişkileri gösterir. yatay ve dikey açılar zaman veya projenin tamamlanabilirliğini ve soyut seviyeyi gösterir.

doğrulama evreleri

gereksinim analizleri 
gereksinim analizi evresinde, ilk evre doğrulama sürecidir, sistemin gereksinimleri kullanıcının ihtiyaçları analiz edilerek toplanır. bu evre ideal sistemin işlemek zorunda olduğu şeyleri kurgulamayla ilgilenir. ancak yazılımın nasıl tasarlanacağını ve inşa edileceğini belirlemez. genellikle kullanıcılar görüşülür ve üretilen kullanıcı gereksinimleri dokümanı oluşturulur.

kullanıcı gereksinimleri dokümanı sistemin fonksiyonelliği, arayüzü, performansı, verisi, güvenliği gibi kullanıcı tarafından beklenen gereksinimleri tanımlar. kullanıcıya sistemin anlamını iletmek için iş analisti tarafından kullanılır. kullanıcılar dikkatli bir şekilde sistem tasarım evrelerinde  sistem tasarımcıları için bir kılavuz gibi hizmet etmesi için bu dokümanları incelerler. kullanıcı kabul testleri bu evrede tasarlanır. fonksiyonel gereksinimleri de inceleyebilirsiniz.

hem yazılımsal hem de donanımsal metodolojileri içeren gereksinimleri toplamak için farklı metotlar vardır, bunlar görüşmeler, anketler, doküman analizleri, incelemeler, tek kullanımlık prototipler, kullanıcı senaryoları, statik ve dinamik incelemeler.

sistem tasarımı 
sistem tasarımı sistem mühendislerinin analiz ettiği ve kullanıcı gereksinim dokümanlarını çalışarak sundukları sistemin işleyişini anladıkları evredir. onlar mümkün durumları ve teknikleri kullanıcı gereksinimlerini gerçekleştirerek anlamaya çalışırlar. eğer herhangi bir gereksinim uyuşmazlığı varsa, kullanıcı bununla ilgili olarak bilgilendirilir. çözüm bulunur ve kullanıcı gereksinim dokümanı düzenlenir.
yazılım talimatname dokümanı geliştirim evresinin üretilmesi için bir tasarı gibi hizmet eder. bu doküman genel sistem organizasyonunun, menü yapılarını, veri yapılarını içerir.

aynı zamanda iş senaryolarını, örnek pencereleri, daha iyi anlamak için raporları da tutabilir. diğer teknik dokümantasyon varlık diyagramları, veri sözlüğü gibi bu evrede üretilir. sistem testi için dokümanlar hazılanır.

mimari tasarım 

bilgisayar mimarisinin ve yazılım mimarisinin tasarım evresi yüksek seviye tasarım olarak refere edilebilir. seçilen mimaride temel tipik olarak içereceği modüllerin listesi, her bir modülün özet fonksiyonelliğini, arayüz ilişkisini, bağımlılıklarını, veritbaanı tablolarını, mimari diyagramlarını, teknoloji detaylarını  sunmalıdır. entegrasyon test etme tasarımı özel bir evre içinde gerçekleştirilir.

modül tasarımı 

modül tasarımı düşük seviyeli tasarım olarak refere edilebilir. tasarım sistemi daha küçük birimlere veya modüllere ayrılır ve her biri programcıya doğrudan kodlamaya başlayacak şekilde açıklanır. düşük seviye tasarım dokümanı veya program talimatnameleri sahte kod içindeki modülün ayrıntılı bir fonksiyonel mantığını taşıyacaktır.

 veritabanı tabloları, tüm elemanları ile birlikte, tiplerini ve boyutlarını içerir.
 tüm arayüz ayrıntıları karmaşık api referanslarıyle bilrikte
 tüm bağımlılık konuları
 hata mesaj listesi
 eksiksiz girdi ve çıktılar	
birim test tasarımı bu evrede geliştirilir.

geçerli kılma evreleri 
v-modeli içerisinde doğrulama evresinin her bir seviyesi geçerleme evresindeki her bir seviye ye karşılık gelmektedir.  v-model deki tipik geçerleme evreleri aşağıdaki gibidir, bazıları diğer isimleriyle de bilinir.

birim test etme 

v-model içinde, birim test planları(utps) modül tasarım evresi boyunca geliştirilir. bu utp’ler birim seviyesindeki veya kod seviyesindeki hataları ortadan kaldırmak için yürütülür. bir birim bağımsız olarak var olabilen mesala program modülü en küçük varlıktır. birim testi kodun/birimin geri kalanından izole edildiğinde düzgünce işleyebilen en küçük varlığı doğrular.

entegrasyon test etme 

entegrasyon test planları mimari tasarım evresi boyunca geliştirilir. bu testler birimler arasında haberleşebilen ve aynı zamanda birbirinden bağımsız şekilde test edilen ve oluşturulan birimleri doğrular. test sonuçları müşteri takımlarıyla paylaşılır.

sistem test etme 

sistem tes planları sistem tasarım evresi boyunca geliştirilir. birim ve entegrasyon test planlarına benzemez, sistem test planları müşterinin iş takımı tarafından birleştirilir. sistem testi uygulama geliştirimi beklentilerinin karşılandığından emin olur. tüm uygualma işlevselliği, merkezi bağımsızlığı ve iletişimi için test edilir. sistem testi fonksiyonel ve fonksiyonel olmayan gereksinimlerin karşılandığını doğrular.
yükleme ve performans test etme, stres test etme, regresyon test etme gibi alt kümeler sistem testi içindir.

kullanıcı kabul test etme 

kullanıcı kabul testi(uat:user acceptance test) planları gereksinim analiz evresi boyunca geliştirilir.  test planları iş kullanıcıları tarafından birleştirilir. uat gerçekçi veriyi kullanarak üretim ortamını benzeterek bir kullanıcı ortamında çalışır. uat kullanıcının gereksiniminin karşılandığını  ve  gerçek zamanda kullanım için sistemin hazır olduğunu ve sistemin dağıtıma uygun olduğunu doğrular.

kaynakça

dış bağlantılar 
https://eprints.dkit.ie/144/ 

https://link.springer.com/chapter/10.1007/978-3-642-30439-2_13?li=true 

https://harmonicss.co.uk/project/the-death-of-the-v-model/ 

https://web.archive.org/web/20120508022817/http://www.pharmpro.com/articles/2008/03/gamp-standards-for-validation-of-automated-systems/

https://tryqa.com/what-is-v-model-advantages-disadvantages-and-when-to-use-it/ 

yazılım geliştirme yöntembilimi