SDLC Aşamaları [Açıklandı]: 2021'de Harika Yazılım Nasıl Hazırlanır

Yazılım geliştirme endüstrisi patlama yaşıyor. Her yıl büyük miktarlarda kod üretmeye devam ediyoruz.

Endüstrinin özünde yazılım geliştirme yaşam döngüsü (SDLC) vardır - yazılım ekiplerine işlerini nasıl yapılandıracakları ve planlayacaklarına rehberlik eden süreç.

Öyleyse, yazılım geliştirmenin tehlikeli arazisinde bir yolculuğa çıkalım.

SDLC'nin gerçekte ne olduğuna bakacağız ve evrimini izleyeceğiz. Sektörün kullandığı ana modellerin hangileri olduğunu göreceğiz.

Bir yazılım parçasının gün ışığına çıkmadan önce geçtiği SDLC aşamalarını ve her birinin kilit oyuncularını keşfedeceğiz.

Son olarak, size tüm sürecin kuşbakışı görünümünü sunacağız.

SDLC Sürecini Anlamak

Yazılım oluşturmak bir süreçtir. Bu nedenle, iyi tanımlanmış bir hedefe, bunu başarmak için araçlara ve sonuçları ölçmenin, sürdürmenin ve iyileştirmenin yollarına ihtiyacı vardır. Yazılım geliştirmeye yönelik farklı yaklaşımlar tüm bunları sağlar. Yine de hepsi aynı kumaştan kesilmiyor. Koşullarınıza bağlı olarak, çılgınca farklı yaklaşımları tercih etmeniz gerekebilir.

Bu, aşağıdakiler gibi birçok değişkene bağlıdır:

• sanayi
• organizasyonun büyüklüğü
• ekip ve proje
• tahmini zaman çerçevesi
• ve ayrılan bütçe.

Ortak olan, her bir yazılım parçasının belirli bir SDLC süreç akışını takip etmesidir .

Bu çerçeve, tamamlanması gereken aşamaları, gerekli kaynakları ve yol boyunca gerçekleştirilecek görevleri ortaya koymaktadır.

SDLC Süreci sonuçta başarılı olmak için gerekenleri iyi yapılandırılmış bir program olduğunu. Tahmini süre ve maliyet sınırlamaları içerisinde en iyi yazılım geliştirme yaklaşımına karar verir.

SDLC, genellikle bilgi sistemleri geliştirmek için en eski çerçeve olan daha geniş “sistem geliştirme yaşam döngüsü” teriminin bir alt kümesi olarak kabul edilir.

1960'ların başında, büyük miktarda veriyi işleyebilen iş sistemlerine duyulan ihtiyaca bir yanıt olarak ortaya çıktı. İlk iyi belgelenmiş SDLC çerçevesi , 1969'dan itibaren yapılandırılmış programlama paradigmasıdır.

1990'larda çeşitli yazılım geliştirme metodolojileri ortaya çıkmıştır. Bunlardan bazıları Nesne yönelimli programlama, Scrum ve Rational Unified Process'tir. Çevik Birleşik Süreç 2005 yılında ortaya çıktı.

Yazılım Geliştirme Sürecinin Yapısı

Bir yazılım ürününün geliştirilmesi, iyi koordine edilmiş bir dizi aşamadır. Seçilen geliştirme yaklaşımına bağlı olarak SDLC adımlarının sayısı değişebilir.

SDLC'nin 5 aşamalı ve 7 aşamalı lezzetlerini inceleyeceğiz.

5 Aşamalı Versiyon

Yazılım geliştirme sürecinin 5 aşamalı versiyonu şu şekildedir:

Gereksinimler ve Analiz

Bu, müşteri ve paydaşlarla etkileşimin gerekli olduğu çok önemli bir aşamadır. Beklenen sonucu, yani yazılım ürününün amacını belirlemeleri gerekir. Müşteri gereksinimlerinin yanı sıra, dikkate alınması gereken her türlü başka faktör vardır. Bunlar şunları içerir:

• Mimari
• fonksiyonel
• İşlevsiz
• Verim
• Ve tasarımla ilgili olanlar

Bu aşamayı başarıyla tamamlamak için “yazılım gereksinimi belirtimi” adlı bir belge geliştirilmiştir. Bu andan itibaren gerçekleşecek her şeyin temelidir.

Bir geliştirme projesinin başarısı, büyük ölçüde gereksinim analizine bağlıdır. Bu aşamadaki kilit oyuncu İş Analistidir (BA). İş gereksinimlerini toplamak, kapsamlı bir analiz yapmak ve en önemlisi - bu bilgileri paydaşlar ve geliştiriciler arasında çevirmek için tüm iletişimi yönetir.

Tasarım

Yazılımın tasarımı, belirlenmiş gereksinimlere dayanmaktadır. Burası geliştirme ortamını, programlama dillerini, mimari çerçeveyi, donanımı vb. belirlediğimiz yerdir. Ayrıca, kullanılacak test stratejisini belirleme zamanıdır. Burada sistem mimarının rolü çok önemlidir. "Gereksinimler belirtimi" belgesindeki tüm ön koşulları dikkate almaları ve bir sonraki adımda kullanılacak bir tasarım kağıdı sağlamaları gerekir.

Kodlama aşaması

Şimdiye kadar, geliştiriciler tasarım özelliklerinin zaten farkındalar. İş modüllere ayrılır ve kodlama başlar. Müşteri de bu aşamada yer almalıdır. Ürünün beklentilerini karşılaması için tüm önlemlerin alınmasını sağlarlar. Çalışan bir yazılım üretmek bu aşamada nihai sonuçtur.

Test yapmak

Artık uygulanabilir bir ürünümüz olduğuna göre, test aşaması başlayabilir. Tasarım spesifikasyon belgesinde özetlenen test stratejisine bağlı olarak bu, çeşitli şekillerde olabilir.

Ancak hedefler aynı kalır. İlk olarak, tüm ilk gereksinimlerin karşılandığını doğrulayın ve ikinci olarak, kodda herhangi bir hata olup olmadığını belirleyin. Testçiler burada kilit oyunculardır. Çabalarının sonucu, kullanıma hazır, tamamen işlevsel bir yazılımdır.

Bakım onarım

Mükemmel bir yazılım ürünü diye bir şey yoktur. Bu nedenle müşteri hizmetleri geliştirme sürecinde büyük bir rol oynamaktadır. Son müşteriye teslim edildikten sonra gerçek zamanlı sorunlar ortaya çıkar ve bunların düzeltilmesi gerekir. Memnun müşterilere sahip olmak istiyorsanız sürekli bakım şarttır.

7 Aşamalı Versiyon

Şimdi bu sürecin 7 aşamalı tadı biraz daha farklı. Diğerlerinin doğasını da kaçınılmaz olarak değiştiren birkaç ekstra aşaması var. Hadi bir bakalım:

Planlama

SDLC Sürecini başlatmanın başka bir yolu da planlama aşamasıdır. Gereksinimlerin toplanmasından önce gelir ve çoğunlukla geri bildirim ister. Paydaşlardan, iş ortaklarından, mühendislerden ve son müşterilerden gelen girdiler projenin kapsamını şekillendirir. Bu aşama aşağıdaki gibi soruları yanıtlar:

• Ne yapılması gerekiyor?
• Hangi kaynaklara ihtiyaç var?
• Ne kadar zaman alacaktı?
• Kaça mal olacak?

Gereksinimler ve Analiz

Burada iş analistleri, müşteriden gelen geri bildirimlere dayalı olarak bir gereksinimler listesi derler. Daha sonra bunları yazılım mühendislerine iletirler. İletişim esastır.

Bu aşama, tüm gereksinimleri özetleyen ve bir sonraki aşama için bir temel görevi gören bir belge üretmelidir.

Sistem Tasarımı

Yazılım gereksinimleri artık sistem mimarisine giriyor. Bu noktada projeyi teslim etmek için ihtiyaç duyduğumuz işlevsel araçları ve işlemleri belirleyebiliriz. Tasarım planı hazırlandıktan sonra işletmeye sunulur. Gerçek programlama başlamadan önce tüm geri bildirimleri dahil ediyoruz.

Yazılım geliştirme

Gereksinimler netleştikten sonra yazılım mühendisleri çalışmaya başlayabilir. Bu aşamada hedef, teste hazır, çalışan bir programdır. Bu aynı zamanda SDLC Sürecinde üretimin başlangıcıdır .

Test yapmak

Kalite güvence ekibinin rolü, ilk iş gereksinimlerinin karşılanıp karşılanmadığını bulmaktır. Yazılım kodunun kalitesini denetlerler. Hatalar giderilir. Geçilmesi gereken bir dizi yazılım test yöntemi vardır: işlevsel, entegrasyon, performans testi vb.

Otomasyon testi, Bamboo ve Jenkins gibi harici yazılımların kullanımı yoluyla tekrarlayan testler çalıştırma sürecini otomatikleştirmenin bir yoludur.

uygulama

Kod test aşamasını geçtikten sonra üretim ortamına dağıtılmaya hazırdır. Şirket politikasına bağlı olarak bu süreç onay gerektirebilir; ancak çoğu durumda yazılım geliştirme yaşam döngüsünde otomatik bir adımdır .

Bakım ve Operasyonlar

Yazılım üretime geçtiğinde, her türlü sorun ortaya çıkabilir. İzleme yoluyla, tespit edilebilir ve çözülebilirler. Yeni özellikler de ürüne girmenin yolunu bulabilir. Bu, performansın ölçülebildiği ve geliştirilebildiği aşamadır.

SDLC modelleri

Bir yazılım parçası geliştirme süreci büyük ölçüde evrenseldir. Daha fazla aşama eklemek veya mevcut aşamaları basitleştirmek için yer var - ama çoğunlukla aynı şey.

Geliştirme yöntemlerine baktığımızda bu doğru değildir . Hepsi süreci gözlemleseler de, bunu çok farklı şekillerde yapıyorlar.

En uygun olanı seçmek için dikkate alınması gereken birkaç önemli faktör vardır. Her zaman müşterinin ihtiyaçları ile yazılım geliştirmenin pratik detayları arasında bir denge vardır. Gibi faktörler vardır:

• projenin karmaşıklığı
• seçilen teknoloji
• ve takım büyüklüğü.

Bütün bunlar, hangi yaklaşımın en iyi şekilde çalışabileceğini belirler. En yaygın olarak bilinen ve kullanılan SDLC metodolojilerinden bazılarına genel bir bakış yapacağız .

Şelale

Şelale modeli doğrusal bir sıralı tasarım sürecidir. Yazılım mühendisliğinde kullanılan bilinen en eski metodolojidir. 1970'lerde imalat ve inşaat sektörlerinden kaynaklanır.

Şelale modelini izleyen bir geliştirme projesinin ilerlemesi, kesinlikle SDLC hattından aşağı iner. Bir ilerleme, yalnızca SDLC'nin önceki aşaması başarıyla tamamlandığında mümkündür. Geriye gitmek için tanımlanmış bir süreç yoktur.

SDLC şelale çok yapılandırılmış bir yaklaşımdır. Şu durumlarda iyi çalışır:

• gereksinimler ve faaliyetler iyi tanımlanmış ve anlaşılmıştır
• teknoloji güvenilir
• destek ekibi mevcut ve kısa vadeli bir proje tahmin ediyorsunuz

Yöntemin dezavantajı, esneklik eksikliği ile ilgilidir. Yol boyunca yeni ortaya çıkan gereksinimleri uygulayamazsınız. Geliştirme sürecinde geç saatlere kadar somut bir ürün üretilmediğinden risk ve belirsizlik yüksektir. Projenin gereksinimlerini veya kapsamını anında değiştirmeye karar verirseniz, bu çok pahalı bir yaklaşım olabilir.

yinelemeli

Bu yöntem, yazılımın bir dizi tekrarlayan döngü yoluyla oluşturulabileceği fikrine dayanmaktadır. Basit bir dizi gereksinimle başlar. Her turda, mühendisler yazılımın önceki sürümlerinin davranışından öğrenirler ve işlevselliğini geliştirebilirler.

Bu yaklaşımın en büyük avantajı, her döngü tamamlandıktan sonra yazılımın çalışan bir prototipinin üretilmesidir. Bu, değişiklikleri uygulamayı, riskleri tanımlamayı kolaylaştırır. Her tekrarda yapıldığında SDLC test nispeten daha kolaydır.

Yinelemeli yazılım geliştirme modelinin dezavantajları, kaynaklara ve maliyete iner. Yineleme sayısını artırmak daha fazla kaynak tüketir. Proje bitiş tarihi belirsizdir ve risk de öyle. Bu nedenle, bu yöntemin çalışması için risk analizi yapan çok yetenekli uzmanlara ihtiyaç vardır.

Metodoloji daha küçük projeler için uygun değildir.

Atik

Yazılım geliştirmeye Çevik yaklaşım nispeten yenidir. Yine de, dünya çapında hızla popülerlik kazandı.

Çevik SGYD yazılımını çalışma ve müşteriden anında geri bildirim arayan küçük porsiyonlarda teslim dayanmaktadır. Bu yaklaşımın temelinde ekipler arasındaki güçlü işbirliği ve sürekli iletişim yatmaktadır. Her döngü yaklaşık bir ila üç hafta sürer ve bu noktada çalışan modül/özellik müşteriye teslim edilir. İşlem daha sonra tekrarlanır.

Test, her yinelemede gerçekleştirilir, bu da sorunların erken çözülmesine olanak tanır. Yazılım işlevselliğinin gösterilmesini ve geri bildirim alınmasını teşvik eder. Model, sonuçların net bir şekilde görülebilmesini sağlar. Takım çalışmasını savunur ve yazılım mühendislerine esneklik sağlar.

Ağır belgeler için gereklilik olmadığından, belirli kişilere bağımlılık riski vardır. Bu, ekibin yeni üyelerine bilgi aktarımı söz konusu olduğunda da zor olabilir.

Eğilmek

Yalın yazılım geliştirme metodolojisi, Çevik yazılım geliştirme yönteminin bir parçası olarak kabul edilir. Yalın metodoloji aşağıdaki SDLC Süreci yedi prensibe dayanmaktadır:

• Atıkları ortadan kaldırın
• Öğrenmeyi güçlendirin
• Mümkün olduğunca geç karar verin
• Mümkün olduğunca hızlı teslim edin
• Ekibi güçlendirin
• Bütünlük oluşturun
• Büyük resmi gör

Bu modeli anlamanın anahtarı bu ilkelerden geçer. Bu, bunların işlevsel çevik uygulamalara dönüştürülmesine ve bunların uygulanmasının çalışma sürecine dönüştürülmesine yol açacaktır.

Yalın ilkeler, kalite, hız, maliyet ve iş beklentilerini optimize ederken son kullanıcılar için mümkün olduğunca fazla katma değer üretme fikri etrafında düzenlenmiştir. Bu amaçla, bazı görevler elenir (ağır belgeler) ve diğerleri optimize edilir (toplantı sıklığı).

DevOps

DevOps modeli kısmen hem Çevik hem de Yalın'a dayanmaktadır . Tüm geliştirme yaşam döngüsü boyunca yazılım geliştirme ve operasyon ekipleri arasındaki yakın işbirliğini birbirine bağlayan yeni ortaya çıkan bir yaklaşımdır.

Bu metodolojinin kilit yönü, geliştirme sürecinin otomasyonuna yapılan vurgudur. Nihai hedef, SDLC'yi kısaltmak ve aynı zamanda iş gereksinimleriyle uyumlu yüksek kaliteli, yenilikçi sonuçlar sunmaktır.

Bu yaklaşımla geliştiriciler, operasyon ekipleri ve kalite güvencesi üyelerinin hepsi aynı sayfada. Aynı araçları kullanırlar ve aynı süreçleri takip ederler. Bu, iletişimi geliştirir ve daha iyi ve daha zamanında sonuçlara yol açar.

Sarmal

Bu, yinelemeli geliştirme ve şelale modelinin bazı kavramlarının bir birleşimidir. Her yinelemeli döngüde yazılımın kısmi sürümlerine izin verir.

Dört aşama ve tekrarlara “spiral” denir. SDLC Aşamaları şunlardır: planlama ve gereksinimleri toplama; tasarım; geliştirme ve test etme.

Risk analizi kilit bir role sahiptir. Her sarmalda, olası risklerin belirlenip önlenebilmesi veya üstesinden gelinebilmesi için bir risk analizi yapılır. Yönetim ve sürecin kendisi karmaşık olsa da, büyük projeler için uygundur.

Sarmak

Yazılım geliştirmeye doğru yaklaşımı seçmek, önemli araştırma gerektirir. Projenizin kapsamını, gereksinimlerini ve hedefini tanımlayarak, ürününüzün geçmesi gereken SDLC Aşamalarını belirleyebilirsiniz .

Seçtiğiniz metodoloji, yalnızca işlevsel bir ürün geliştirme süreci değildir. Uyumlu bir çalışma ortamı yaratmak için kuruluşunuzun ve ekiplerinizin değerlerini hizalamanın bir yoludur.