Yazılım Geliştirme Yaşam Döngüsünün (SDLC) 7 Aşaması/Aşaması

SDLC, yazılım geliştirmek için kullanılan bir süreçtir. Yaşam döngüsü, planlama aşamalarından işletme ve bakıma kadar yazılımın gelişimini takip eder.

Yazılım geliştirme yaşam döngüsü (SDLC), yazılımın tasarlanması, oluşturulması ve teslim edilmesi için tamamlanması gereken görevleri tanımlar. Bu görevler, geliştiricilerin içinde çalışması için bir yapı oluşturur.

SDLC'de tümü kendi benzersiz etkinlikleri ve görev tamamlama listesi olan 7 aşama veya aşama vardır. Bu 7 aşama, yazılımın tamamlanıp teslim edilmesi için yapılması gerekenlere dair bir yol haritası sunmaktadır.

Bugün SDLC'nin 7 aşaması hakkında bilgi edinmek için okumaya devam edin!

1. Planlama

Bu, SDLC'nin ilk aşamasıdır. Bu aşama, iş operasyonlarını iyileştirmek için yeni bir sisteme ihtiyaç olup olmadığının belirlenmesidir. İhtiyaç belirlendikten (veya problem tanımlandıktan sonra), çözümlerin bulunması gerekir.

Bilgi ve kaynaklar, yeni bir sisteme veya halihazırda var olan bir sistemin iyileştirilmesine olan ihtiyacı desteklemek için bu aşamada toplanır. İhtiyacı destekleyen bilgilerden yola çıkılarak çözümler tasarlanır ve onaya sunulur.

Bu aşamada, ihtiyacı karşılayacak en güncel bilgi ve kaynaklara sahip olmak için mevcut web geliştirme endüstrisi trendlerini tazelemek iyi bir fikirdir.

 Sizin için önerilir: Yapay Zeka Modern Web Uygulamalarının Gelişimini Nasıl Etkiler?

2. Sistem Analizi ve Gereksinimleri

Bu, önerilen çözümlerin, şirketin genel stratejisine ve hedeflerine en uygun çözüm bulununcaya kadar incelendiği yerdir. Bu aşamada, planlama hala yapılır, ancak çok daha derin bir analitik düzeyde.

Proje veya çözüm için fonksiyonel gereksinimleri belirlemek için problem ve ilgili sistemler analiz edilir. Bunlar, sorunu çözmek ve kurumsal stratejiyle uyum sağlamak için yeni sistemin karşılaması gereken gereksinimler olacaktır.

Burası bir zaman çizelgesinin seçildiği, bireysel bölümlerden kimin sorumlu olduğu ve işin ihtiyaçlarının nasıl karşılanacağının belirlendiği yerdir.

3. Sistem Tasarımı

Kulağa geldiği gibi, yeni sistem veya yazılımın tasarlanacağı yer burasıdır. Parametreler, kullanılacak teknolojiler, proje kısıtlamaları, zaman ve bütçe ile birlikte paydaşlarla tartışılacaktır. İncelemeden sonra ikinci aşamada belirlenen gereksinimleri karşılayacak en iyi tasarım yaklaşımı seçilir.

Seçilen tasarım yaklaşımının, geliştirilmesi gereken tüm bileşenlerin, kullanıcı akışlarının ve veritabanı iletişimlerinin ve üçüncü taraf hizmetlerle iletişimin bir tanımını sağlaması gerekecektir.

4. Geliştirme

Geliştirme aşaması, yeni sistem veya yazılım üzerinde gerçek gerçek çalışmanın başladığı yerdir. Tipik olarak, kaynak kodu yazmaya başlamak için bir programcı, ağ mühendisi veya veritabanı geliştiricisi veya herhangi bir kombinasyon getirilecektir.

Bu aşamada bir akış şemasının oluşturulması önemlidir. Bu akış şeması, sistem süreçlerinin uygun şekilde organize edilmesini sağlamak için kullanılır.

Bu aşama genellikle kullanılacak asıl yazılımın geliştirilmesiyle ilgiliyken, prototip modelinde bu, prototipin geliştirildiği aşamadır. Prototip daha sonra müşterinin ihtiyaçlarını karşılayana ve müşteri tatmin olana kadar sürekli olarak geliştirilir ve test edilir. Bundan sonra, prototip bu aşamaya son bir kez geri döner.

Geliştirme aşamasına yaptığı son yolculukta, geliştirilecek ve kullanılacak gerçek yazılım veya sisteme dönüştürülecektir.

5. Entegrasyon ve Test

Bu aşamada, deneyimli test uzmanları, yazılımı veya sistemi gereksinimlere göre test etmeye başlayacaktır. Amaç, sistemdeki herhangi bir kusuru ve ikinci aşamadan itibaren belgelenen gereksinimlere uygun davranıp davranmadığını belirlemektir.

Bu aşama, yazılımın teslim edilmesi için çok önemlidir. Test aşamasından geliştirme aşamasına geçiş yapmak yaygındır. Bunun nedeni, yazılım veya sistem içinde kusurlar veya sorunlar bulunduğunda, not edilmesi ve bir çözüm için geliştirme aşamasına geri gönderilmesidir.

Test uzmanlarının sistemleri ve yazılımı test etmesinin birkaç farklı yolu vardır. Bir test komut dosyası kullanabilir veya keşif testi kullanabilirler.

Bir test komut dosyası kullanmak, sistemin gereksinimlerle uyumlu olduğundan emin olmak için bir dizi önceden belirlenmiş testi otomatik olarak çalıştıracaktır. Keşif testini kullanmak daha çok deneyime dayalıdır. Test eden kişi, yeni sistemi veya yazılımı çalıştırarak kullanımlarını, özelliklerini ve yeteneklerini keşfederek yeni sistemi test edecektir. Test eden kişi, yalnızca deneyime dayalı olarak sistemde gezinecek ve gereksinimleri karşılayıp karşılamadığını değerlendirecektir.

Tüm gereksinimler sistem tarafından karşılandığında, test cihazı sistemi veya yazılımı bir sonraki aşamaya geçirecektir. Sistemdeki sorunların kapsamına ve boyutuna bağlı olarak, bunun gerçekleşmesi birkaç günden birkaç aya kadar sürebilir.

 İlginizi çekebilir: 2019'da Odaklanacak En İyi 7 Web Geliştirme Trendi.

6. Uygulama

Yine, kulağa geldiği gibi, bu yeni sistemin normal iş operasyonlarına uygulandığı aşamadır. Yeni yazılım veya sistem yüklenir ve daha fazla kod yazılmasının yanı sıra herhangi bir dosya veya verinin yeni sisteme taşınması gerekir.

Kurulum sırasında iş operasyonlarını kesintiye uğratma riski nedeniyle, bu aşama genellikle yoğun olmayan saatlerde gerçekleşir. Bunun nedeni, entegrasyon veya aktarımla ilgili herhangi bir hata olasılığıdır. Amaç bu hataları en aza indirmek iken, bunlar meydana gelebilir ve yoğun saatlerde meydana geldiklerinde şirket üretkenlik ve gelir kaybına uğrayabilir.

Son kullanıcılar ve analistler, bitmiş sistemin ilk bakışlarını ve şirkete getireceği değişiklikleri görmelidir.

7. İşletme ve Bakım

SDLC'nin son aşaması, düzenli bakım ve zorunlu güncellemeleri zorlamayı içerir. Burada son kullanıcılar, sistemi gelecekteki ihtiyaçlara daha iyi uyacak şekilde ince ayar yapma yeteneğine sahiptir.

BT, yeni güncellemeleri uzaktan yükleyebilecek ve aynı zamanda şirketin ihtiyaçlarını sürekli olarak karşılayacak şekilde sistemin özelleştirilmesine yardımcı olacak. BT ayrıca ortaya çıkabilecek herhangi bir hatayı veya sorunu düzeltmekten de sorumludur. Hiçbir sistem mükemmel değildir ve sürekli bakım, herhangi bir yeni sistem veya yazılım projesinin gerekli bir parçasıdır.

SDLC Modelleri

SDLC, model adı verilen çeşitli şekillerde kullanılabilir. Bu modeller birbirinden farklı ve kendi avantaj ve dezavantajlarına sahip olsa da, hepsi aynı adımları aynı sırayla kullanır. İşte SDLC'yi takip ederken kullanılacak en popüler modellerden ikisi.

Çevik Model

Çevik model ( wiki ), gereksinimlerden ziyade geliştirme sırasında esnekliğe odaklanır. Çevik modeli kullanmak, projeyi daha küçük artımlı bölümlere ayırmayı gerektirir. Her segment, bir sonraki segment üzerinde çalışmaya başlamadan önce son kullanıcı veya müşteri tarafından geliştirilir, test edilir ve değerlendirilir.

Etkili bir şekilde her segment, her adımda müşteri girdisi ve geri bildirimi ile bir önceki segmentin işlevselliğini ve özelliklerini geliştirir. Üzerinde çalışılacak her segment için zaman çerçevesi, sprint olarak bilinir.

Sprintler yaklaşık 2 ila 4 hafta sürebilir. Sprintin süresi ne olursa olsun, sprint sonunda mal sahibi ürünü doğrular ve müşterilere teslim edip etmediğini onaylar.

Müşteriler aynı şekilde şirketin geliştirme ekibine geri iletmesi için yorum ve eleştiri bırakacak. Müşteri geri bildirimleri ve önerileri, yolun her adımında toplanır. Ancak, bir müşteri sistemin ne yapmasını istediğinden emin değilse, model ve sistem başarısız olabilir.

Prototip Modeli

Bu model, gerçek yazılım veya sistemden önce birden fazla değilse de en az bir prototip geliştirmeyi içerir. Bu prototipler, tam yazılım veya hizmetin sunduğu hizmetlerin tam kullanılabilirliğini sunmaz. Ancak, müşterilerin ihtiyaçlarını belirlemede faydalı olabilirler.

Test aşamasında müşterilere geri bildirim için gönderilen gerçek yazılım yerine prototip modeli ( wiki ) ile prototip gözden geçirilir. Müşteri hala geri bildirimde bulunur ve prototip, değişiklikleri yapmak için geliştirmeye geri gönderilir. Bu değişiklikler yapıldıktan sonra, inceleme için müşteriye geri gönderilir.

Bu, müşteri tatmin olana ve ihtiyaçları karşılanana kadar devam eder. Müşteri tatmin olduğunda prototip oluşturulur ve SDLC'nin sonraki aşamalarına gönderilir.

Bu modelin en büyük avantajlarından biri maliyet tasarrufudur. Testler gerçek yazılım yerine prototipler üzerinde yapıldığından, kusurlar çok daha erken bulunur. Bu, son teslim tarihlerini ve lansman tarihlerini karşılama konusunda paradan ve zamandan tasarruf sağlayabilir. Diğer bir avantaj, müşterilerinizin geri bildirimleri aracılığıyla mevcut web geliştirme endüstrisi trendlerinden haberdar olma yeteneğidir.

Ancak, bu modelin bir dezavantajı da avantajlarından biridir. Müşteriler, geri bildirim sağlayarak ve kullanacakları ve ihtiyaçlarını karşılayan bir yazılım oluşturmaya yardımcı olarak sürece erken dahil olurlar. Ancak bu nedenle müşteri, son ürünün gereksinimlerini değiştirerek başlatma ve dağıtımda gecikmelere neden olabilir.

 Şunlar da hoşunuza gidebilir: Laravel, İş Web Uygulaması Geliştirme için Mükemmel Bir Çerçeve mi?

Çözüm

SDLC'ye uygunluk ve bağlılık, bir sorunu çözmek veya bir ihtiyacı karşılamak için ihtiyaç duyulan herhangi bir proje veya yazılımın başarısını sağlamak için kritik öneme sahiptir. SDLC, yazılım geliştirmenin yaşam döngüsünü tanımlayan ve açıklayan 7 aşamadan oluşan bir seridir.

SDLC, en dikkat çekenleri çevik ve prototip model olan birkaç modelle uygulanabilir. Her iki model de, döngünün başlarında müşteri geri bildirimlerine büyük ölçüde güveniyor. Bu, şirketin müşterinin ihtiyaçlarını etkin ve zamanında karşılamasını sağlar.

SDLC'yi ve bir dağıtım modelini benimsemek, şirketinizin problemini çözmesine, şirketin ve müşterilerin ihtiyaçlarını belirlemesine ve bu ihtiyaçları karşılamak için yeni sistemleri ve yazılımları devreye almasına yardımcı olmak için uzun bir yol kat edecektir.