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
- ^ Clarus Concept of Operations. 5 Temmuz 2009 tarihinde Wayback Machine sitesinde arşivlendi. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
Dış bağlantılar
https://eprints.dkit.ie/144/ 6 Mart 2021 tarihinde Wayback Machine sitesinde arşivlendi.
https://link.springer.com/chapter/10.1007/978-3-642-30439-2_13?LI=true 15 Ağustos 2020 tarihinde Wayback Machine sitesinde arşivlendi.
https://harmonicss.co.uk/project/the-death-of-the-v-model/ 21 Ocak 2022 tarihinde Wayback Machine sitesinde arşivlendi.
https://tryqa.com/what-is-v-model-advantages-disadvantages-and-when-to-use-it/ 6 Nisan 2022 tarihinde Wayback Machine sitesinde arşivlendi.
