SDLC - Hızlı Kılavuz

Yazılım Geliştirme Yaşam Döngüsü (SDLC), yazılım endüstrisinin yüksek kaliteli yazılımları tasarlamak, geliştirmek ve test etmek için kullandığı bir süreçtir. SDLC, müşteri beklentilerini karşılayan veya aşan, zaman ve maliyet tahminleri içinde tamamlanmaya ulaşan yüksek kaliteli bir yazılım üretmeyi amaçlamaktadır.

SDLC, Yazılım Geliştirme Yaşam Döngüsünün kısaltmasıdır.
Yazılım Geliştirme Süreci olarak da adlandırılır.
SDLC, yazılım geliştirme sürecinin her adımında gerçekleştirilen görevleri tanımlayan bir çerçevedir.
ISO / IEC 12207, yazılım yaşam döngüsü süreçleri için uluslararası bir standarttır. Yazılım geliştirmek ve sürdürmek için gerekli tüm görevleri tanımlayan standart olmayı hedefler.

SDLC nedir?

SDLC, bir yazılım organizasyonu içerisinde bir yazılım projesi için izlenen bir süreçtir. Belirli bir yazılımın nasıl geliştirileceğini, korunacağını, değiştirileceğini ve değiştirileceğini veya iyileştirileceğini açıklayan ayrıntılı bir plandan oluşur. Yaşam döngüsü, yazılım kalitesini ve genel geliştirme sürecini iyileştirmek için bir metodoloji tanımlar.

Aşağıdaki şekil, tipik bir SDLC'nin çeşitli aşamalarının grafiksel bir temsilidir.

Tipik bir Yazılım Geliştirme Yaşam Döngüsü aşağıdaki aşamalardan oluşur -

Aşama 1: Planlama ve İhtiyaç Analizi

Gereksinim analizi, SDLC'deki en önemli ve temel aşamadır. Müşteriden, satış departmanından, pazar araştırmalarından ve sektördeki alan uzmanlarından gelen girdilerle ekibin üst düzey üyeleri tarafından gerçekleştirilir. Bu bilgiler daha sonra temel proje yaklaşımını planlamak ve ekonomik, operasyonel ve teknik alanlarda ürün fizibilite çalışması yapmak için kullanılır.

Kalite güvence gereksinimleri için planlama ve proje ile ilgili risklerin belirlenmesi de planlama aşamasında yapılır. Teknik fizibilite çalışmasının sonucu, projeyi minimum riskle başarılı bir şekilde uygulamak için izlenebilecek çeşitli teknik yaklaşımları tanımlamaktır.

Aşama 2: Gereksinimlerin Tanımlanması

İhtiyaç analizi yapıldıktan sonraki adım, ürün gereksinimlerini açıkça tanımlamak ve belgelendirmek ve bunları müşteriden veya pazar analistlerinden onaylatmaktır. Bu, bir aracılığıyla yapılırSRS (Software Requirement Specification) Proje yaşam döngüsü boyunca tasarlanacak ve geliştirilecek tüm ürün gereksinimlerini içeren belge.

Aşama 3: Ürün Mimarisini Tasarlama

SRS, geliştirilecek ürün için en iyi mimari ile ortaya çıkan ürün mimarları için referanstır. SRS'de belirtilen gereksinimlere dayalı olarak, genellikle ürün mimarisi için birden fazla tasarım yaklaşımı önerilir ve bir DDS - Tasarım Dokümanı Spesifikasyonunda belgelenir.

Bu DDS, tüm önemli paydaşlar tarafından gözden geçirilir ve risk değerlendirmesi, ürün sağlamlığı, tasarım modülerliği, bütçe ve zaman kısıtlamaları gibi çeşitli parametrelere dayalı olarak ürün için en iyi tasarım yaklaşımı seçilir.

Bir tasarım yaklaşımı, ürünün tüm mimari modüllerini, dış ve üçüncü parti modüllerle (varsa) iletişim ve veri akışı temsiliyle birlikte açıkça tanımlar. Önerilen mimarinin tüm modüllerinin iç tasarımı, DDS'deki en küçük ayrıntılarla açıkça tanımlanmalıdır.

4. Aşama: Ürünü Oluşturma veya Geliştirme

SDLC'nin bu aşamasında asıl geliştirme başlar ve ürün inşa edilir. Bu aşamada programlama kodu DDS'ye göre üretilir. Tasarım ayrıntılı ve organize bir şekilde gerçekleştirilirse, kod üretimi çok fazla güçlük çekmeden gerçekleştirilebilir.

Geliştiriciler, kuruluşları tarafından tanımlanan kodlama yönergelerine uymalıdır ve kodu oluşturmak için derleyiciler, yorumlayıcılar, hata ayıklayıcılar vb. Gibi programlama araçları kullanılır. Kodlama için C, C ++, Pascal, Java ve PHP gibi farklı üst düzey programlama dilleri kullanılmaktadır. Programlama dili, geliştirilmekte olan yazılımın türüne göre seçilir.

Aşama 5: Ürünü Test Etme

Bu aşama, modern SDLC modellerinde olduğu gibi genellikle tüm aşamaların bir alt kümesidir, test faaliyetleri çoğunlukla SDLC'nin tüm aşamalarında yer alır. Ancak bu aşama, ürün SRS'de tanımlanan kalite standartlarına ulaşıncaya kadar ürün hatalarının rapor edildiği, takip edildiği, düzeltildiği ve yeniden test edildiği ürünün yalnızca test aşamasını ifade eder.

Aşama 6: Pazarda Dağıtım ve Sürdürme

Ürün test edildikten ve kullanıma hazır hale getirildikten sonra uygun pazarda resmi olarak piyasaya sürülür. Bazen ürün dağıtımı, o kuruluşun iş stratejisine göre aşamalar halinde gerçekleşir. Ürün ilk olarak sınırlı bir segmentte piyasaya sürülebilir ve gerçek iş ortamında test edilebilir (UAT - Kullanıcı kabul testi).

Daha sonra, geri bildirimlere göre ürün olduğu gibi veya hedefleme pazarı segmentinde önerilen geliştirmelerle piyasaya sürülebilir. Ürün piyasaya sürüldükten sonra mevcut müşteri kitlesi için bakımı yapılır.

SDLC Modelleri

Yazılım geliştirme sürecinde izlenen, tanımlanan ve tasarlanan çeşitli yazılım geliştirme yaşam döngüsü modelleri vardır. Bu modeller aynı zamanda Yazılım Geliştirme Süreç Modelleri olarak da adlandırılır. Her süreç modeli, yazılım geliştirme sürecinde başarıyı garantilemek için kendi türüne özgü bir dizi adım izler.

Aşağıda sektörde izlenen en önemli ve popüler SDLC modelleri yer almaktadır -

Şelale Modeli
Yinelemeli Model
Spiral Modeli
V-Model
Büyük Patlama Modeli

Diğer ilgili metodolojiler Çevik Model, RAD Modeli, Hızlı Uygulama Geliştirme ve Prototipleme Modelleridir.

Şelale Modeli, tanıtılan ilk Süreç Modeli oldu. Aynı zamanda birlinear-sequential life cycle model. Anlaması ve kullanması çok basit. Bir şelale modelinde, bir sonraki aşama başlamadan önce her aşama tamamlanmalıdır ve aşamalarda örtüşme yoktur.

Waterfall modeli, yazılım geliştirme için kullanılan en eski SDLC yaklaşımıdır.

Şelale Modeli, yazılım geliştirme sürecini doğrusal bir sıralı akışta gösterir. Bu, geliştirme sürecindeki herhangi bir aşamanın yalnızca önceki aşama tamamlandığında başlayacağı anlamına gelir. Bu şelale modelinde aşamalar çakışmaz.

Şelale Modeli - Tasarım

Waterfall yaklaşımı, projenin başarısını sağlamak için Yazılım Mühendisliğinde yaygın olarak kullanılan ilk SDLC Modeliydi. "Şelale" yaklaşımında, tüm yazılım geliştirme süreci ayrı aşamalara ayrılmıştır. Bu Şelale modelinde, tipik olarak, bir aşamanın sonucu, sırayla bir sonraki aşama için girdi görevi görür.

Aşağıdaki çizim Şelale Modelinin farklı aşamalarının bir temsilidir.

Waterfall modelindeki ardışık aşamalar şunlardır:

Requirement Gathering and analysis - Geliştirilecek sistemin tüm olası gereksinimleri bu aşamada ele alınır ve bir gereksinim şartname belgesinde belgelenir.
System Design- Bu aşamada ilk aşamadaki ihtiyaç özellikleri incelenir ve sistem tasarımı hazırlanır. Bu sistem tasarımı, donanım ve sistem gereksinimlerinin belirlenmesine ve genel sistem mimarisinin tanımlanmasına yardımcı olur.
Implementation- Sistem tasarımından gelen girdilerle, sistem ilk olarak bir sonraki aşamada entegre edilen birimler adı verilen küçük programlarda geliştirilir. Her birim, Birim Testi olarak anılan işlevselliği için geliştirilmiş ve test edilmiştir.
Integration and Testing- Uygulama aşamasında geliştirilen tüm birimler, her birimin test edilmesinden sonra bir sisteme entegre edilir. Entegrasyon sonrası tüm sistem herhangi bir hata ve arızaya karşı test edilir.
Deployment of system- Fonksiyonel ve fonksiyonel olmayan testler yapıldıktan sonra; ürün müşteri ortamında devreye alınır veya piyasaya sürülür.
Maintenance- İstemci ortamında ortaya çıkan bazı sorunlar var. Bu sorunları gidermek için yamalar yayınlandı. Ayrıca ürünü geliştirmek için bazı daha iyi sürümler yayınlanmıştır. Müşteri ortamında bu değişiklikleri sağlamak için bakım yapılır.

Tüm bu aşamalar, ilerlemenin aşamalar boyunca (bir şelale gibi) sürekli aşağıya doğru aktığı görüldüğü şekilde birbirine kademelidir. Bir sonraki aşama, yalnızca önceki aşama için tanımlanan hedefler kümesine ulaşıldıktan ve imzalandıktan sonra başlatılır, yani "Şelale Modeli" adı verilir. Bu modelde, aşamalar çakışmaz.

Şelale Modeli - Uygulama

Geliştirilen her yazılım farklıdır ve iç ve dış faktörlere bağlı olarak izlenecek uygun bir SDLC yaklaşımı gerektirir. Waterfall modelinin kullanımının en uygun olduğu bazı durumlar şunlardır:

Gereksinimler çok iyi belgelenmiştir, açık ve sabittir.
Ürün tanımı sabittir.
Teknoloji anlaşılır ve dinamik değildir.
Belirsiz gereklilikler yoktur.
Ürünü desteklemek için gerekli uzmanlığa sahip geniş kaynaklar mevcuttur.
Proje kısa.

Şelale Modeli - Avantajlar

Şelale geliştirmenin avantajları, bölümlere ayırma ve kontrole izin vermesidir. Her geliştirme aşaması için son tarihler içeren bir program belirlenebilir ve bir ürün, geliştirme süreci modeli aşamalarından birer birer ilerleyebilir.

Geliştirme, konseptten tasarım, uygulama, test, kurulum, sorun giderme aşamalarına doğru ilerler ve işletme ve bakımda sona erer. Gelişimin her aşaması kesin bir sırayla ilerler.

Şelale Modelinin önemli avantajlarından bazıları aşağıdaki gibidir -

Basit ve anlaşılması ve kullanılması kolay
Modelin sertliğinden dolayı yönetimi kolaydır. Her aşamanın belirli çıktıları ve bir inceleme süreci vardır.
Aşamalar birer birer işlenir ve tamamlanır.
Gereksinimlerin çok iyi anlaşıldığı küçük projeler için iyi sonuç verir.
Açıkça tanımlanmış aşamalar.
İyi anlaşılmış kilometre taşları.
Görevleri düzenlemek kolaydır.
Süreç ve sonuçlar iyi bir şekilde belgelenmiştir.

Şelale Modeli - Dezavantajları

Şelale gelişiminin dezavantajı, çok fazla yansıma veya revizyona izin vermemesidir. Bir uygulama test aşamasındayken, geri dönüp, kavram aşamasında iyi belgelenmemiş veya üzerinde düşünülmemiş bir şeyi değiştirmek çok zordur.

Şelale Modelinin başlıca dezavantajları aşağıdaki gibidir -

Yaşam döngüsünün sonlarına kadar hiçbir çalışan yazılım üretilmez.
Yüksek miktarda 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. Dolayısıyla bu süreç modeli ile risk ve belirsizlik yüksektir.
Aşamalar içindeki ilerlemeyi ölçmek zordur.
Değişen gereksinimleri karşılayamaz.
Yaşam döngüsü sırasında kapsamın ayarlanması bir projeyi sona erdirebilir.
Entegrasyon, en sonunda bir "büyük patlama" olarak yapılır ve herhangi bir teknolojik veya iş darboğazını veya zorluğu erken tespit etmeye izin vermez.

Yinelemeli modelde yinelemeli süreç, küçük bir yazılım gereksinimleri kümesinin basit bir uygulamasıyla başlar ve tüm sistem uygulanana ve dağıtılmaya hazır olana kadar gelişen sürümleri yinelemeli olarak geliştirir.

Yinelemeli bir yaşam döngüsü modeli, gereksinimlerin tam bir belirtimi ile başlamaya çalışmaz. Bunun yerine, geliştirme, yazılımın yalnızca bir bölümünü belirleyip uygulayarak başlar ve daha sonra başka gereksinimleri belirlemek için gözden geçirilir. Bu işlem daha sonra tekrarlanır ve modelin her yinelemesinin sonunda yazılımın yeni bir sürümünü üretir.

Yinelemeli Model - Tasarım

Yinelemeli süreç, yazılım gereksinimlerinin bir alt kümesinin basit bir uygulamasıyla başlar ve tam sistem uygulanana kadar gelişen sürümleri yinelemeli olarak geliştirir. Her yinelemede tasarım değişiklikleri yapılır ve yeni işlevsel yetenekler eklenir. Bu yöntemin arkasındaki temel fikir, tekrarlanan döngülerle (yinelemeli) ve bir seferde daha küçük bölümlerde (artımlı) bir sistem geliştirmektir.

Aşağıdaki çizim, Yinelemeli ve Artımlı modelin bir temsilidir -

Yinelemeli ve Artımlı geliştirme, hem yinelemeli tasarımın hem de yinelemeli yöntemin ve geliştirme için artımlı derleme modelinin bir kombinasyonudur. "Yazılım geliştirme sırasında, aynı anda yazılım geliştirme döngüsünün birden fazla yinelemesi devam ediyor olabilir." Bu süreç, "evrimsel kazanım" veya "aşamalı inşa" yaklaşımı olarak tanımlanabilir.

Bu artımlı modelde, tüm gereksinim çeşitli yapılara bölünmüştür. Her yineleme sırasında, geliştirme modülü gereksinimler, tasarım, uygulama ve test aşamalarından geçer. Modülün sonraki her sürümü, önceki sürüme işlev ekler. İşlem, ihtiyaca göre komple sistem hazır olana kadar devam eder.

Yinelemeli bir yazılım geliştirme yaşam döngüsünün başarılı bir şekilde kullanılmasının anahtarı, gereksinimlerin titiz bir şekilde doğrulanması ve yazılımın her sürümünün modelin her döngüsü içinde bu gereksinimlere göre doğrulanması ve test edilmesidir. Yazılım birbirini takip eden döngülerle geliştikçe, yazılımın her sürümünü doğrulamak için testler tekrarlanmalı ve genişletilmelidir.

Yinelemeli Model - Uygulama

Diğer SDLC modelleri gibi, yinelemeli ve artımlı geliştirme, yazılım endüstrisinde bazı özel uygulamalara sahiptir. Bu model genellikle aşağıdaki senaryolarda kullanılır -

Tüm sistemin gereksinimleri açıkça tanımlanmış ve anlaşılmıştır.
Ana gereksinimler tanımlanmalıdır; ancak bazı işlevler veya istenen geliştirmeler zamanla gelişebilir.
Piyasa kısıtlamasına bir zaman var.
Proje üzerinde çalışırken geliştirme ekibi tarafından yeni bir teknoloji kullanılıyor ve öğreniliyor.
Gerekli beceri setlerine sahip kaynaklar mevcut değildir ve belirli yinelemeler için sözleşme temelinde kullanılması planlanmaktadır.
Gelecekte değişebilecek bazı yüksek riskli özellikler ve hedefler vardır.

Yinelemeli Model - Artıları ve Eksileri

Bu modelin avantajı, geliştirmenin çok erken bir aşamasında sistemin çalışan bir modelinin mevcut olmasıdır, bu da işlevsel veya tasarım kusurlarını bulmayı kolaylaştırır. Sorunları geliştirmenin erken bir aşamasında bulmak, sınırlı bir bütçeyle düzeltici önlemlerin alınmasını sağlar.

Bu SDLC modelinin dezavantajı, yalnızca büyük ve hantal yazılım geliştirme projelerine uygulanabilmesidir. Bunun nedeni, küçük bir yazılım sistemini daha küçük hizmet verilebilir artımlara / modüllere ayırmanın zor olmasıdır.

Yinelemeli ve Artımlı SDLC Modelinin avantajları aşağıdaki gibidir -

Bazı çalışma işlevleri, yaşam döngüsünün erken ve hızlı bir şekilde geliştirilebilir.
Sonuçlar erken ve periyodik olarak alınır.
Paralel geliştirme planlanabilir.
İlerleme ölçülebilir.
Kapsamı / gereksinimleri değiştirmek için daha az maliyetli.
Daha küçük yineleme sırasında test etmek ve hata ayıklamak kolaydır.
Yineleme sırasında riskler belirlenir ve çözülür; ve her bir yineleme, kolayca yönetilen bir kilometre taşıdır.
Riski yönetmek daha kolay - Önce yüksek riskli kısım yapılır.
Her artışta operasyonel ürün teslim edilir.
Her bir artıştan belirlenen sorunlar, zorluklar ve riskler kullanılabilir / bir sonraki aşamaya uygulanabilir.
Risk analizi daha iyidir.
Değişen gereksinimleri destekler.
İlk Çalışma süresi daha azdır.
Büyük ve görev açısından kritik projeler için daha uygun.
Yaşam döngüsü boyunca, müşteri değerlendirmesini ve geri bildirimini kolaylaştıran yazılım erken üretilir.

Yinelemeli ve Artımlı SDLC Modelinin dezavantajları aşağıdaki gibidir -

Daha fazla kaynak gerekli olabilir.
Değişim maliyeti daha düşük olmasına rağmen, değişen ihtiyaçlar için çok uygun değildir.
Daha fazla yönetim dikkati gereklidir.
Tüm gereksinimlerin tüm yaşam döngüsünün başlangıcında toplanmaması nedeniyle sistem mimarisi veya tasarım sorunları ortaya çıkabilir.
Artımların tanımlanması, tüm sistemin tanımlanmasını gerektirebilir.
Küçük projeler için uygun değil.
Yönetim karmaşıklığı daha fazladır.
Bir risk olan projenin sonu bilinmeyebilir.
Risk analizi için yüksek vasıflı kaynaklar gereklidir.
Projelerin ilerlemesi büyük ölçüde risk analizi aşamasına bağlıdır.

Sarmal model, yinelemeli geliştirme fikrini şelale modelinin sistematik, kontrollü yönleriyle birleştirir. Bu Spiral model, yinelemeli geliştirme süreci modeli ile sıralı doğrusal geliştirme modelinin, yani risk analizine çok yüksek vurgu yapan şelale modelinin bir kombinasyonudur. Spiralin etrafındaki her yinelemede ürünün artımlı sürümlerine veya artımlı iyileştirmeye izin verir.

Spiral Model - Tasarım

Spiral modelin dört aşaması vardır. Bir yazılım projesi, Spiral adı verilen yinelemelerle bu aşamalardan tekrar tekrar geçer.

Kimlik

Bu aşama, iş gereksinimlerinin temel sarmalda toplanmasıyla başlar. Sonraki spirallerde ürün olgunlaştıkça, sistem gereksinimlerinin, alt sistem gereksinimlerinin ve birim gereksinimlerinin belirlenmesi bu aşamada yapılır.

Bu aşama aynı zamanda müşteri ve sistem analisti arasındaki sürekli iletişim yoluyla sistem gereksinimlerinin anlaşılmasını da içerir. Spiralin sonunda, ürün belirlenen pazarda konuşlandırılır.

Tasarım

Tasarım aşaması, temel spiraldeki kavramsal tasarımla başlar ve sonraki spirallerde mimari tasarım, modüllerin mantıksal tasarımı, fiziksel ürün tasarımı ve son tasarımı içerir.

İnşa Et veya İnşa Et

Oluşturma aşaması, gerçek yazılım ürününün her spiralde üretilmesini ifade eder. Temel spiralde, ürün henüz düşünüldüğünde ve tasarım geliştirilirken, müşteri geri bildirimini almak için bu aşamada bir POC (Proof of Concept) geliştirilir.

Daha sonra, gereksinimler ve tasarım ayrıntıları konusunda daha net olan sonraki spirallerde, sürüm numarasıyla build adı verilen bir yazılımın çalışma modeli üretilir. Bu yapılar, geri bildirim için müşteriye gönderilir.

Değerlendirme ve Risk Analizi

Risk Analizi, teknik fizibilite ve program kayması ve maliyet aşımı gibi yönetim risklerinin tanımlanmasını, tahmin edilmesini ve izlenmesini içerir. Derlemeyi test ettikten sonra, ilk yinelemenin sonunda müşteri yazılımı değerlendirir ve geri bildirim sağlar.

Aşağıdaki çizim, her aşamadaki faaliyetleri listeleyen Spiral Modelin bir temsilidir.

Müşteri değerlendirmesine bağlı olarak, yazılım geliştirme süreci bir sonraki yinelemeye girer ve ardından müşteri tarafından önerilen geri bildirimi uygulamak için doğrusal yaklaşımı izler. Spiral boyunca yineleme süreci, yazılımın ömrü boyunca devam eder.

Spiral Model Uygulaması

Spiral Model, herhangi bir ürünün doğal gelişim süreciyle, yani müşteri ve geliştirme firmaları için minimum risk içeren olgunlukta öğrenme ile senkronize olduğu için yazılım endüstrisinde yaygın olarak kullanılmaktadır.

Aşağıdaki işaretçiler, bir Spiral Modelin tipik kullanımlarını açıklamaktadır -

Bütçe kısıtı olduğunda risk değerlendirmesi önemlidir.
Orta ila yüksek riskli projeler için.
Gereksinimler zamanla değiştikçe ekonomik önceliklerdeki potansiyel değişiklikler nedeniyle uzun vadeli proje taahhüdü.
Müşteri gereksinimlerinden emin değildir, bu genellikle böyledir.
Gereksinimler karmaşıktır ve netlik elde etmek için değerlendirmeye ihtiyaç duyar.
Yeterli müşteri geri bildirimi almak için aşamalı olarak piyasaya sürülmesi gereken yeni ürün grubu.
Geliştirme döngüsü sırasında üründe önemli değişiklikler beklenmektedir.

Spiral Model - Artıları ve Eksileri

Spiral yaşam döngüsü modelinin avantajı, ürün elemanlarının mevcut olduğunda veya bilindiğinde eklenmesine izin vermesidir. Bu, önceki gereksinimler ve tasarımla hiçbir çelişki olmamasını sağlar.

Bu yöntem, bir bakım faaliyetine düzenli bir geçiş yapılmasına olanak tanıyan birden çok yazılım yapısına ve sürümüne sahip yaklaşımlarla tutarlıdır. Bu yöntemin bir başka olumlu yönü, spiral modelin sistem geliştirme çabasına erken bir kullanıcı katılımını zorlamasıdır.

Öte yandan, bu tür ürünleri tamamlamak çok sıkı bir yönetim gerektirir ve spirali belirsiz bir döngüde çalıştırma riski vardır. Bu nedenle, ürünün başarılı bir şekilde geliştirilmesi ve devreye alınması için değişim disiplini ve değişiklik taleplerinin alınma kapsamı çok önemlidir.

Spiral SDLC Modelinin avantajları aşağıdaki gibidir -

Değişen gereksinimler karşılanabilir.
Prototiplerin kapsamlı kullanımına izin verir.
Gereksinimler daha doğru bir şekilde yakalanabilir.
Kullanıcılar sistemi erken görür.
Geliştirme daha küçük parçalara bölünebilir ve riskli bölümler daha erken geliştirilebilir, bu da daha iyi risk yönetimine yardımcı olur.

Spiral SDLC Modelinin dezavantajları aşağıdaki gibidir -

Yönetim daha karmaşıktır.
Projenin sonu erken bilinmeyebilir.
Küçük veya düşük riskli projeler için uygun değildir ve küçük projeler için pahalı olabilir.
Süreç karmaşıktır
Spiral sonsuza kadar devam edebilir.
Çok sayıda ara aşama, aşırı dokümantasyon gerektirir.

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, sistem tasarım aşamasıyla doğrudan 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ı kolay.
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.

Big Bang modeli, belirli bir süreci takip etmediğimiz bir SDLC modelidir. Geliştirme, girdi olarak gerekli para ve çabayla başlar ve çıktı, müşteri ihtiyacına göre olan veya olmayan geliştirilen yazılımdır. Bu Büyük Patlama Modeli bir süreci / prosedürü izlemez ve çok az planlama gerekir. Müşteri bile tam olarak ne istediğinden emin değildir ve gereksinimler çok fazla analiz yapılmadan anında yerine getirilir.

Genellikle bu model, geliştirme ekiplerinin çok küçük olduğu küçük projeler için takip edilir.

Big Bang Modeli ─ Tasarım ve Uygulama

Big Bang Modeli, çok az planlama ile veya hiç planlama olmadan yazılım geliştirme ve kodlamadaki olası tüm kaynaklara odaklanmayı içerir. Gereksinimler geldikçe anlaşılır ve uygulanır. Gerekli herhangi bir değişiklik, tüm yazılımı yenilemeye ihtiyaç duyabilir veya gerekmeyebilir.

Bu model, bir veya iki geliştiricinin birlikte çalıştığı küçük projeler için idealdir ve akademik veya uygulama projeleri için de kullanışlıdır. Gereksinimlerin iyi anlaşılmadığı ve son çıkış tarihinin verilmediği ürünler için ideal bir modeldir.

Big Bang Modeli - Artıları ve Eksileri

Bu Big Bang Modelinin avantajı, çok basit olması ve çok az planlama gerektirmesi veya hiç planlama gerektirmemesidir. Yönetimi kolaydır ve resmi bir prosedür gerekmez.

Bununla birlikte, Big Bang Modeli çok yüksek riskli bir modeldir ve gereksinimlerdeki değişiklikler veya yanlış anlaşılan gereksinimler, projenin tamamen tersine çevrilmesine veya silinmesine neden olabilir. Minimum riskle tekrarlayan veya küçük projeler için idealdir.

Big Bang Modelinin avantajları aşağıdaki gibidir -

Bu çok basit bir model
Çok az veya hiç planlama gerektirmez
Yönetimi kolay
Çok az kaynak gerekli
Geliştiricilere esneklik sağlar
Yeni gelenler veya öğrenciler için iyi bir öğrenme yardımcısıdır.

Big Bang Modelinin dezavantajları aşağıdaki gibidir -

Çok 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.
Gereksinimler yanlış anlaşılırsa çok pahalı olabilir.

Çevik SDLC modeli, çalışan yazılım ürününün hızlı teslimi ile süreç uyarlanabilirliği ve müşteri memnuniyetine odaklanan yinelemeli ve artımlı süreç modellerinin bir kombinasyonudur. Çevik Yöntemler, ürünü küçük artımlı yapılara böler. Bu yapılar yinelemeler halinde sağlanır. Her yineleme tipik olarak yaklaşık bir ila üç hafta sürer. Her yineleme, aşağıdakiler gibi çeşitli alanlarda eşzamanlı olarak çalışan çapraz işlevsel ekipleri içerir:

Planning
Gereksinimlerin analizi
Design
Coding
Birim Testi ve
Kabul testleri.

Yinelemenin sonunda müşteriye ve önemli paydaşlara çalışan bir ürün gösterilir.

Çevik nedir?

Çevik model, her projenin farklı şekilde ele alınması gerektiğine ve mevcut yöntemlerin proje gereksinimlerine en uygun şekilde uyarlanması gerektiğine inanır. Agile'da görevler, bir sürüm için belirli özellikler sunmak üzere zaman kutularına (küçük zaman dilimleri) bölünmüştür.

Yinelemeli yaklaşım alınır ve her yinelemeden sonra çalışan yazılım derlemesi teslim edilir. Her yapı, özellikler açısından artımlıdır; son yapı müşterinin ihtiyaç duyduğu tüm özellikleri barındırır.

Çevik Modelin grafik bir gösterimi:

Çevik düşünce süreci, yazılım geliştirmenin erken safhalarında başlamış ve esnekliği ve uyarlanabilirliği sayesinde zamanla popüler olmaya başlamıştır.

En popüler Çevik yöntemler arasında Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development ve Dynamic Systems Development Method (DSDM) (1995) bulunur. Bunlar artık toplu olarak şu şekilde anılmaktadır:Agile MethodologiesÇevik Manifesto 2001'de yayınlandıktan sonra.

Çevik Manifesto ilkeleri aşağıdadır -

Individuals and interactions - Çevik geliştirmede, ortak konum ve eşli programlama gibi etkileşimler kadar kendi kendine organizasyon ve motivasyon da önemlidir.
Working software - Demo çalışan yazılım, yalnızca belgelere bağlı olmak yerine, müşterilerle gereksinimlerini anlamak için en iyi iletişim aracı olarak kabul edilir.
Customer collaboration - Çeşitli faktörlerden dolayı proje başlangıcında ihtiyaçlar tam olarak toplanamadığından, uygun ürün gereksinimlerini elde etmek için sürekli müşteri etkileşimi çok önemlidir.
Responding to change - Çevik Geliştirme, değişime ve sürekli gelişime hızlı yanıt vermeye odaklanır.

Çevik Vs Geleneksel SDLC Modelleri

Çevik, adaptive software development methodsşelale modeli gibi geleneksel SDLC modelleri ise tahmine dayalı bir yaklaşıma dayanmaktadır. Geleneksel SDLC modellerindeki tahmine dayalı ekipler genellikle ayrıntılı planlama ile çalışır ve önümüzdeki birkaç ay içinde veya ürün yaşam döngüsü sırasında teslim edilecek tam görevler ve özellikler hakkında tam bir tahmine sahiptir.

Tahmine dayalı yöntemler tamamen requirement analysis and planningdöngünün başında yapılır. Dahil edilecek herhangi bir değişiklik, katı bir değişiklik kontrol yönetimi ve önceliklendirmeden geçer.

Çevik, bir adaptive approachayrıntılı bir planlamanın olmadığı ve gelecekteki görevlerde yalnızca hangi özelliklerin geliştirilmesi gerektiğine ilişkin netlik olduğu durumlarda. Özellik odaklı bir geliştirme vardır ve ekip, değişen ürün gereksinimlerine dinamik olarak uyum sağlar. Ürün, sürüm yinelemeleri aracılığıyla çok sık test edilir ve gelecekte herhangi bir büyük arıza riskini en aza indirir.

Customer Interactionbu Agile metodolojisinin bel kemiğidir ve minimum dokümantasyonla açık iletişim, Agile geliştirme ortamının tipik özellikleridir. Agile ekipleri birbirleriyle yakın işbirliği içinde çalışır ve çoğunlukla aynı coğrafi konumda bulunurlar.

Çevik Model - Artıları ve Eksileri

Çevik yöntemler son zamanlarda yazılım dünyasında yaygın olarak kabul görmektedir. Ancak bu yöntem her zaman tüm ürünler için uygun olmayabilir. Çevik modelin bazı artıları ve eksileri.

Çevik Modelin avantajları aşağıdaki gibidir -

Yazılım geliştirmeye çok gerçekçi bir yaklaşımdır.
Takım çalışmasını ve çapraz eğitimi teşvik eder.
İşlevsellik hızla geliştirilebilir ve gösterilebilir.
Kaynak gereksinimleri minimumdur.
Sabit veya değişen ihtiyaçlara uygun
Erken kısmi çalışma çözümleri sunar.
Sürekli değişen ortamlar için iyi bir model.
Minimal kurallar, dokümantasyon kolayca kullanılır.
Genel olarak planlanmış bir bağlam içinde eşzamanlı geliştirme ve teslimi etkinleştirir.
Çok az veya hiç planlama gerekmez.
Yönetmesi kolay.
Geliştiricilere esneklik sağlar.

Çevik Modelin dezavantajları aşağıdaki gibidir -

Karmaşık bağımlılıkları ele almak için uygun değildir.
Daha fazla sürdürülebilirlik, sürdürülebilirlik ve genişletilebilirlik riski.
Genel bir plan, çevik bir lider ve çevik bir PM uygulaması, onsuz çalışmayacağı bir zorunluluktur.
Sıkı teslimat yönetimi, teslim edilecek kapsamı, işlevselliği ve son teslim tarihlerini karşılamak için ayarlamaları belirler.
Büyük ölçüde müşteri etkileşimine bağlıdır, bu nedenle müşteri net değilse, ekip yanlış yöne yönlendirilebilir.
Üretilen minimum dokümantasyon olduğundan çok yüksek bir bireysel bağımlılık söz konusudur.
Yeni ekip üyelerine teknoloji transferi, dokümantasyon eksikliği nedeniyle oldukça zor olabilir.

RAD (Rapid Application Development)model, belirli bir planlama olmaksızın prototip oluşturmaya ve yinelemeli geliştirmeye dayanır. Yazılımın kendisini yazma süreci, ürünü geliştirmek için gereken planlamayı içerir.

Hızlı Uygulama Geliştirme, atölyeler veya odak grupları aracılığıyla müşteri gereksinimlerini toplamaya, yinelemeli konsept kullanarak müşteri tarafından prototiplerin erken test edilmesine, mevcut prototiplerin (bileşenlerin) yeniden kullanımına, sürekli entegrasyon ve hızlı teslimata odaklanır.

RAD nedir?

Hızlı uygulama geliştirme, hızlı prototipleme lehine minimum planlama kullanan bir yazılım geliştirme metodolojisidir. Bir prototip, işlevsel olarak ürünün bir bileşenine eşdeğer olan çalışan bir modeldir.

RAD modelinde, fonksiyonel modüller prototipler olarak paralel olarak geliştirilir ve daha hızlı ürün teslimi için eksiksiz ürünü yapmak için entegre edilir. Ayrıntılı bir ön planlama olmadığından, değişiklikleri geliştirme sürecine dahil etmeyi kolaylaştırır.

RAD projeleri yinelemeli ve artımlı modeli takip eder ve geliştiricilerden, etki alanı uzmanlarından, müşteri temsilcilerinden ve bileşenleri veya prototipleri üzerinde aşamalı olarak çalışan diğer BT kaynaklarından oluşan küçük ekiplere sahiptir.

Bu modelin başarılı olabilmesi için en önemli husus, geliştirilen prototiplerin tekrar kullanılabilir olduğundan emin olmaktır.

RAD Model Tasarımı

RAD modeli, analiz, tasarım, inşa ve test aşamalarını bir dizi kısa, yinelemeli geliştirme döngüsüne dağıtır.

RAD Modelinin çeşitli aşamaları aşağıdadır -

İş Modellemesi

Geliştirilmekte olan ürün için iş modeli, bilgi akışı ve çeşitli iş kanalları arasında bilgi dağıtımı açısından tasarlanmıştır. İş için hayati bilgileri bulmak, nasıl elde edilebileceğini, bilgilerin nasıl ve ne zaman işlendiğini ve başarılı bilgi akışını sağlayan faktörlerin neler olduğunu bulmak için eksiksiz bir iş analizi yapılır.

Veri Modelleme

İş Modelleme aşamasında toplanan bilgiler gözden geçirilir ve iş için hayati önem taşıyan veri nesneleri kümeleri oluşturmak üzere analiz edilir. Tüm veri setlerinin öznitelikleri tanımlanır ve tanımlanır. Bu veri nesneleri arasındaki ilişki, iş modeline uygun olarak kurulur ve ayrıntılı olarak tanımlanır.

Süreç Modelleme

Veri Modelleme aşamasında tanımlanan veri nesnesi setleri, iş modeline göre belirli iş hedeflerine ulaşmak için gereken iş bilgi akışını kurmak üzere dönüştürülür. Veri nesnesi setlerindeki herhangi bir değişiklik veya iyileştirme için süreç modeli bu aşamada tanımlanır. Bir veri nesnesinin eklenmesi, silinmesi, geri alınması veya değiştirilmesi için işlem açıklamaları verilmiştir.

Uygulama Üretimi

Gerçek sistem oluşturulur ve kodlama, süreç ve veri modellerini gerçek prototiplere dönüştürmek için otomasyon araçları kullanılarak yapılır.

Test ve Ciro

Prototipler her yineleme sırasında bağımsız olarak test edildiğinden, RAD modelinde genel test süresi azaltılır. Ancak, tüm bileşenler arasındaki veri akışı ve arayüzlerin eksiksiz bir test kapsamı ile kapsamlı bir şekilde test edilmesi gerekir. Programlama bileşenlerinin çoğu zaten test edildiğinden, herhangi bir önemli sorun riskini azaltır.

Aşağıdaki çizim RAD Modelini ayrıntılı olarak açıklamaktadır.

RAD Modeli Vs Geleneksel SDLC

Geleneksel SDLC, kodlama başlamadan önce gereksinim analizi ve toplamaya büyük önem veren katı bir süreç modelini takip eder. Proje başlamadan önce gereksinimleri imzalaması için müşteriye baskı uygular ve uzun süre kullanılabilir bir yapı olmadığı için müşteri ürün hissini almaz.

Müşteri, yazılımı gördükten sonra bazı değişikliklere ihtiyaç duyabilir. Bununla birlikte, değişim süreci oldukça katıdır ve üründeki büyük değişiklikleri geleneksel SDLC'ye dahil etmek mümkün olmayabilir.

RAD modeli, çalışma modellerinin müşteriye yinelemeli ve artımlı teslimine odaklanır. Bu, müşteriye hızlı teslimat ve ürünün tam geliştirme döngüsü sırasında müşterinin katılımıyla sonuçlanır ve gerçek kullanıcı gereksinimlerine uymama riskini azaltır.

RAD Modeli - Uygulama

Net modülerleştirmenin mümkün olduğu projelerde RAD modeli başarıyla uygulanabilmektedir. Proje modüllere ayrılamazsa, RAD başarısız olabilir.

Aşağıdaki işaretçiler, RAD'nin kullanılabileceği tipik senaryoları açıklamaktadır -

RAD, yalnızca bir sistem aşamalı bir şekilde teslim edilmek üzere modüler hale getirilebildiği zaman kullanılmalıdır.
Modelleme için tasarımcıların yüksek kullanılabilirliği varsa kullanılmalıdır.
Yalnızca bütçe otomatik kod oluşturma araçlarının kullanımına izin veriyorsa kullanılmalıdır.
RAD SDLC modeli, yalnızca ilgili iş bilgisine sahip alan uzmanları mevcutsa seçilmelidir.
Proje sırasında ihtiyaçların değiştiği ve çalışma prototiplerinin 2-3 aylık küçük yinelemeler halinde müşteriye sunulacağı durumlarda kullanılmalıdır.

RAD Modeli - Artıları ve Eksileri

RAD modeli, bileşenlerin yeniden kullanılabilirliği ve paralel geliştirme nedeniyle genel geliştirme süresini azalttığı için hızlı teslimat sağlar. RAD, yalnızca yüksek vasıflı mühendisler mevcutsa ve müşteri de belirli bir zaman diliminde hedeflenen prototipi elde etmeye kararlıysa iyi çalışır. Her iki tarafta da eksiklik varsa, model başarısız olabilir.

RAD Modelinin avantajları aşağıdaki gibidir -

Değişen gereksinimler karşılanabilir.
İlerleme ölçülebilir.
Yineleme süresi, güçlü RAD araçlarının kullanılmasıyla kısa olabilir.
Kısa sürede daha az insanla üretkenlik.
Azaltılmış geliştirme süresi.
Bileşenlerin yeniden kullanılabilirliğini artırır.
Hızlı ilk incelemeler gerçekleşir.
Müşteri geri bildirimini teşvik eder.
En başından itibaren entegrasyon, birçok entegrasyon sorununu çözer.

RAD Modelinin dezavantajları aşağıdaki gibidir -

İş gereksinimlerini belirlemek için teknik açıdan güçlü ekip üyelerine bağımlılık.
Yalnızca modülerleştirilebilen sistem RAD kullanılarak oluşturulabilir.
Çok yetenekli geliştiriciler / tasarımcılar gerektirir.
Modelleme becerilerine yüksek bağımlılık.
Modelleme ve otomatik kod oluşturma maliyeti çok yüksek olduğu için daha ucuz projelere uygulanamaz.
Yönetim karmaşıklığı daha fazladır.
Bileşen tabanlı ve ölçeklenebilir sistemler için uygundur.
Yaşam döngüsü boyunca kullanıcının katılımını gerektirir.
Daha kısa geliştirme süreleri gerektiren projeler için uygundur.

Yazılım Prototipleme, geliştirilmekte olan ürünün işlevselliğini gösteren, ancak aslında orijinal yazılımın tam mantığını tutmayabilen yazılım uygulama prototipleri oluşturmayı ifade eder.

Yazılım prototipleme, müşteri gereksinimlerini geliştirmenin erken bir aşamasında anlamayı sağladığı için bir yazılım geliştirme modeli olarak çok popüler hale geliyor. Müşteriden değerli geri bildirimler alınmasına yardımcı olur ve yazılım tasarımcılarının ve geliştiricilerinin, geliştirilmekte olan üründen tam olarak ne beklendiğini anlamalarına yardımcı olur.

Yazılım Prototipleme nedir?

Prototip, bazı sınırlı işlevselliğe sahip çalışan bir yazılım modelidir. Prototip, her zaman gerçek yazılım uygulamasında kullanılan mantığı tam olarak tutmaz ve çaba tahmini altında dikkate alınması gereken ekstra bir çabadır.

Prototipleme, kullanıcıların geliştirici tekliflerini değerlendirmesine ve uygulamadan önce denemesine olanak sağlamak için kullanılır. Ayrıca, kullanıcıya özgü olan ve ürün tasarımı sırasında geliştirici tarafından dikkate alınmamış olabilecek gereksinimleri anlamaya yardımcı olur.

Aşağıda, bir yazılım prototipi tasarlamak için açıklanan aşamalı bir yaklaşım yer almaktadır.

Temel Gereksinim Tanımlaması

Bu adım, özellikle kullanıcı arayüzü açısından en temel ürün gereksinimlerini anlamayı içerir. İç tasarımın daha karmaşık ayrıntıları ve performans ve güvenlik gibi dış unsurlar bu aşamada göz ardı edilebilir.

İlk Prototipin Geliştirilmesi

İlk Prototip, çok temel gereksinimlerin sergilendiği ve kullanıcı arayüzlerinin sağlandığı bu aşamada geliştirilir. Bu özellikler, geliştirilen gerçek yazılımda dahili olarak tam olarak aynı şekilde çalışmayabilir. Geliştirilen prototipte müşteriye aynı görünümü ve hissi vermek için geçici çözümler kullanılır.

Prototipin İncelenmesi

Geliştirilen prototip daha sonra müşteriye ve projedeki diğer önemli paydaşlara sunulur. Geri bildirim, organize bir şekilde toplanır ve geliştirilmekte olan üründe daha fazla iyileştirme için kullanılır.

Prototipi Gözden Geçirin ve Geliştirin

Geri bildirim ve inceleme yorumları bu aşamada tartışılır ve müşteriyle zaman ve bütçe kısıtlamaları ve gerçek uygulamanın teknik fizibilitesi gibi faktörlere dayalı olarak bazı görüşmeler yapılır. Kabul edilen değişiklikler, geliştirilen yeni Prototipe yeniden dahil edilir ve müşteri beklentileri karşılanana kadar döngü tekrarlanır.

Prototiplerin yatay veya dikey boyutları olabilir. Yatay prototip, ürünün kullanıcı arayüzünü görüntüler ve dahili işlevlere odaklanmadan tüm sistemin daha geniş bir görünümünü verir. Diğer taraftaki Dikey prototip, üründeki belirli bir işlevin veya bir alt sistemin ayrıntılı bir detaylandırmasıdır.

Hem yatay hem de dikey prototipin amacı farklıdır. Yatay prototipler, kullanıcı arayüzü seviyesi ve iş gereksinimleri hakkında daha fazla bilgi almak için kullanılır. Piyasada iş yapmak için satış demolarında bile sunulabilir. Dikey prototipler doğası gereği tekniktir ve alt sistemlerin tam olarak işleyişinin ayrıntılarını almak için kullanılır. Örneğin, belirli bir alt sistemde veritabanı gereksinimleri, etkileşim ve veri işleme yükleri.

Yazılım Prototipleme - Türler

Endüstride kullanılan farklı yazılım prototipleri vardır. Yaygın olarak kullanılan başlıca yazılım prototip türleri aşağıdadır -

Atış / Hızlı Prototipleme

Kullanılmayan prototipleme, hızlı veya yakın uçlu prototipleme olarak da adlandırılır. Bu tür bir prototipleme, bir prototip oluşturmak için minimum gereksinim analizi ile çok az çaba harcar. Gerçek gereksinimler anlaşıldığında, prototip atılır ve gerçek sistem, kullanıcı gereksinimlerinin çok net bir şekilde anlaşılmasıyla geliştirilir.

Evrimsel Prototipleme

Aynı zamanda breadboard prototiplemesi olarak da adlandırılan evrimsel prototipleme, başlangıçta minimum işlevsellik ile gerçek işlevsel prototipler oluşturmaya dayanır. Geliştirilen prototip, tüm sistemin üzerine inşa edildiği gelecekteki prototiplerin kalbini oluşturur. Evrimsel prototipleme kullanılarak, iyi anlaşılmış gereksinimler prototipe dahil edilir ve gereksinimler anlaşıldıkça eklenir.

Artımlı Prototipleme

Artımlı prototipleme, çeşitli alt sistemlerin çok sayıda işlevsel prototipini oluşturmayı ve ardından mevcut tüm prototipleri eksiksiz bir sistem oluşturmak için entegre etmeyi ifade eder.

Aşırı Prototipleme

Web geliştirme alanında aşırı prototipleme kullanılır. Üç ardışık aşamadan oluşur. İlk olarak, mevcut tüm sayfalarla birlikte temel bir prototip HTML formatında sunulur. Daha sonra veri işleme, bir prototip hizmetleri katmanı kullanılarak simüle edilir. Son olarak, hizmetler uygulanmakta ve nihai prototipe entegre edilmektedir. Bu sürece Ekstrem Prototipleme adı verilir ve bu işlemin ikinci aşamasına dikkat çekmek için kullanılır, burada gerçek hizmetler çok az dikkate alınarak tamamen işlevsel bir kullanıcı arayüzü geliştirilir.

Yazılım Prototipleme - Uygulama

Yazılım Prototipleme, çevrimiçi sistemler gibi yüksek düzeyde kullanıcı etkileşimlerine sahip sistemlerin geliştirilmesinde en yararlıdır. Kullanıcıların, veriler işlenmeden önce formları doldurmasını veya çeşitli ekranlardan geçmesini gerektiren sistemler, gerçek yazılım geliştirilmeden önce bile tam görünüm ve his vermek için prototiplemeyi çok etkili bir şekilde kullanabilir.

Çok fazla veri işleme içeren ve işlevselliğin çoğu çok az kullanıcı arayüzü ile dahili olan yazılımlar genellikle prototiplemeden fayda sağlamaz. Prototip geliştirme, bu tür projelerde fazladan bir yük olabilir ve çok fazla çaba gerektirebilir.

Yazılım Prototipleme - Artıları ve Eksileri

Tipik durumlarda yazılım prototipleme kullanılır ve kararın çok dikkatli bir şekilde alınması gerekir, böylece prototipi oluşturmak için harcanan çabalar geliştirilen nihai yazılıma önemli bir değer katar. Modelin aşağıda tartışılan kendi artıları ve eksileri vardır.

Prototipleme Modelinin avantajları aşağıdaki gibidir -

Uygulamadan önce bile ürüne artan kullanıcı katılımı.
Sistemin çalışan bir modeli gösterildiğinden, kullanıcılar geliştirilmekte olan sistemi daha iyi anlarlar.
Kusurlar çok daha erken tespit edilebildiği için zamanı ve maliyeti azaltır.
Daha iyi çözümlere yol açan daha hızlı kullanıcı geri bildirimi mevcuttur.
Eksik işlevler kolayca belirlenebilir.
Kafa karıştırıcı veya zor işlevler tanımlanabilir.

Prototipleme Modelinin Dezavantajları aşağıdaki gibidir -

Prototipe çok fazla bağımlılık nedeniyle yetersiz gereksinim analizi riski.
Kullanıcılar prototiplerde ve gerçek sistemlerde kafaları karışabilir.
Pratik olarak, bu metodoloji, sistemin kapsamı orijinal planların ötesine geçebileceği için sistemin karmaşıklığını artırabilir.
Geliştiriciler, teknik olarak uygun olmasa bile gerçek sistemi oluşturmak için mevcut prototipleri yeniden kullanmayı deneyebilirler.
Düzgün bir şekilde izlenmezse, prototip oluşturmaya harcanan çaba çok fazla olabilir.