SDLC - V-Modeli
V-modeli, işlemlerin V şeklinde sıralı bir şekilde yürütüldüğü bir SDLC modelidir. Olarak da bilinirVerification and Validation model.
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ı olduğu anlamına gelir. Bu oldukça disiplinli bir modeldir ve sonraki aşama ancak önceki aşama tamamlandıktan sonra başlar.
V-Model - Tasarım
V-Modeli kapsamında, geliştirme aşamasının ilgili test aşaması paralel olarak planlanmaktadır. Dolayısıyla, "V" nin bir tarafında Doğrulama aşamaları, diğer tarafında Doğrulama aşamaları vardır. Kodlama Aşaması, V-Modelinin iki tarafını birleştirir.
Aşağıdaki çizim, SDLC'nin V-Modelindeki farklı aşamaları tasvir etmektedir.
V-Model - Doğrulama Aşamaları
V-Modelinde birkaç Doğrulama aşaması vardır, bunların her biri aşağıda ayrıntılı olarak açıklanmıştır.
İş İhtiyaç Analizi
Bu, ürün gereksinimlerinin müşterinin bakış açısından anlaşıldığı geliştirme döngüsünün ilk aşamasıdır. Bu aşama, beklentilerini ve tam gereksinimini anlamak için müşteri ile ayrıntılı iletişimi içerir. Müşterilerin çoğu tam olarak neye ihtiyaç duyduklarından emin olmadığı için bu çok önemli bir faaliyet ve iyi yönetilmesi gerekiyor. acceptance test design planning iş gereksinimleri kabul testi için bir girdi olarak kullanılabileceğinden, bu aşamada yapılır.
Sistem tasarımı
Net 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 için tüm donanım ve iletişim kurulumunun anlaşılmasına ve detaylandırılmasına sahip olacaktır. Sistem test planı, sistem tasarımına göre 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
Mimari şartnameler bu aşamada anlaşılır ve tasarlanır. Genellikle birden fazla teknik yaklaşım önerilmekte ve teknik ve mali fizibiliteye dayalı olarak nihai karar alınmaktadır. Sistem tasarımı, farklı işlevleri kapsayan modüllere ayrılmıştır. Bu aynı zamandaHigh Level Design (HLD).
İç modüller arasında 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, tüm sistem modülleri için ayrıntılı iç tasarım belirtilir, Low Level Design (LLD). Tasarımın sistem mimarisindeki diğer modüllerle ve diğer harici sistemlerle uyumlu olması önemlidir. Birim testleri, herhangi bir geliştirme sürecinin önemli bir parçasıdır ve maksimum hata ve hataları çok erken bir aşamada ortadan kaldırmaya yardımcı olur. Bu birim testleri bu aşamada iç 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 dili, sistem ve mimari gereksinimlere göre belirlenir.
Kodlama, kodlama yönergelerine ve standartlarına göre gerçekleştirilir. Kod çok sayıda kod incelemesinden geçer ve son derleme 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çıklanmıştır.
Birim Testi
Modül tasarım aşamasında tasarlanan birim testleri, bu doğrulama aşamasında kod üzerinden gerçekleştirilir. Birim testi, kod düzeyinde yapılan testtir ve hataları erken bir aşamada gidermeye yardımcı olur, ancak tüm kusurlar birim testiyle ortaya çıkarılamaz.
Entegrasyon Testi
Entegrasyon testi mimari tasarım aşamasıyla ilişkilidir. Sistem içindeki dahili modüllerin bir arada varlığını ve iletişimini test etmek için entegrasyon testleri 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 uyumluluğu sorunlarının çoğu, bu sistem testi yürütmesi sırasında ortaya çıkarılabilir.
Kabul testleri
Kabul testi, iş gereksinim analizi aşaması ile 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ı, her iki model de sıralı tipte olduğundan şelale modeli ile hemen hemen aynıdır. Proje başlamadan önce gereksinimlerin çok net olması gerekir, çünkü genellikle geri dönüp değişiklik yapmak pahalıdır. Bu model, kesinlikle disiplinli bir alan olduğu için 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ıştır, açıkça belgelenmiştir ve sabitlenmiştir.
Ürün tanımı sabittir.
Teknoloji dinamik değildir ve proje ekibi tarafından iyi anlaşılmıştır.
Belirsiz veya tanımlanmamış gereksinimler yoktur.
Proje kısa.
V-Model - Artıları ve Eksileri
V-Model yönteminin avantajı, anlaşılması ve uygulanmasının çok kolay olmasıdır. Bu modelin sadeliği, yönetmeyi de kolaylaştırır. Dezavantajı ise modelin değişikliklere esnek olmaması ve tam da günümüz dinamik dünyasında çok yaygın olan bir ihtiyaç değişikliği olması durumunda değişikliği yapmak çok pahalı hale geliyor.
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 sonuç verir.
Basit ve anlaşılması ve kullanılması kolaydır.
Modelin sertliğinden dolayı 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 nesneye yönelik projeler için iyi bir model değil.
Uzun ve devam eden projeler için zayıf model.
İhtiyaçların orta ila yüksek değişim riskinde olduğu projeler için uygun değildir.
Bir uygulama test aşamasındayken, geri dönüp bir işlevi değiştirmek zordur.
Yaşam döngüsünün sonlarına kadar hiçbir çalışan yazılım üretilmez.