Sistem mühendisliğinin V-Modeli.
**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
--------

1. ↑  *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
---------------

 6 Mart 2021 tarihinde Wayback Machine sitesinde arşivlendi.

 15 Ağustos 2020 tarihinde Wayback Machine sitesinde arşivlendi.

 21 Ocak 2022 tarihinde Wayback Machine sitesinde arşivlendi.

 6 Nisan 2022 tarihinde Wayback Machine sitesinde arşivlendi.

| * g
* t
* d
Yazılım mühendisliği |
| --- |
| Alanlar | Gereksinim çözümlemesi • Yazılım tasarımı • Programlama • Biçimsel yöntemler • Yazılım testi • Yazılım sistemleri • Yazılım dağıtımı • Yazılım bakımı  |
| Kavramlar | Veri modelleme • Kurumsal mimari • Functional specification • Modelleme dili • Programlama paradigması • Yazılım • Yazılım mimarisi • Yazılım geliştirme yöntembilimi • Yazılım geliştirme süreci • Yazılımın niteliği • Yazılım kalite güvencesi • Yapısal analiz  |
| Yönelimler | Atik • Aspect-oriented • Nesne yönelimli • Ontoloji • Servis odaklı • SDLC |
| Modeller | *Geliştirme modelleri*: Atik • Yinelemeli model • RUP • Scrum • Spiral model • Waterfall model • XP • V-Model
*Diğer modeller*: CMMI • Veri modeli • İşlev modeli • IDEF • Bilgi modeli • Metamodeling • Nesne modeli • Görünüm modeli • UML  |
| Yazılımmühendisleri | Victor Basili • Dennis Ritchie • Kent Beck • Peter Chen • Grady Booch • Fred Brooks • Barry Boehm • Bjarne Stroustrup • Ward Cunningham • Ole-Johan Dahl • Tom DeMarco • Edsger Dijkstra • Martin Fowler • C. A. R. Hoare • Watts Humphrey • Michael A. Jackson • Ivar Jacobson • Craig Larman • James Martin • Bertrand Meyer • David Parnas • Winston W. Royce • James Rumbaugh • Danese Cooper • Niklaus Wirth • Edward Yourdon |
| İlgili alanlar | Bilgisayar bilimi • Bilgisayar mühendisliği • İşletme mühendisliği • Geçmiş • Matematik • Proje yönetimi • Risk yönetimi • Sistem mühendisliği |