Yazılım Mühendisliği

Yazılım Süreç Modelleri

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

Giriş

Classroom

  • Sınıf Kodu: xog7rwhi
  • classroom.google.com → Sınıfa katıl → kodu girin (kurumsal hesapla).

Öğrenme Kazanımları

Bu dersin sonunda:

  • Yazılım süreci ile süreç modeli kavramlarını ve bir sürecin bileşenlerini (ürün, rol, ön/son koşul) açıklayabilecek,
  • Dört temel süreç aktivitesini (spesifikasyon, geliştirme, doğrulama ve geçerleme, evrim) tanımlayabilecek,
  • Şelale, V-Modeli, artımlı geliştirme, yeniden kullanım, sarmal model ve RUP’ı güçlü ve zayıf yönleriyle karşılaştırabilecek,
  • Doğrulama (verification) ile geçerleme (validation) arasındaki farkı örneklerle ayırt edebilecek,
  • Bir projenin gereksinim kararlılığı, risk düzeyi ve teslimat hızı gibi özelliklerine bakarak uygun süreç modelini seçip gerekçelendirebilecek.

Yazılım Süreç Modelleri

Yazılım Süreci Nedir?

Bir yazılım sistemini geliştirmek, işletmek ve bakımını yapmak için gerekli olan yapılandırılmış faaliyetler bütünüdür.

  • Neyi içerir? Teknik, işbirlikçi ve yönetimsel aktiviteler.
  • Amacı nedir? Yüksek kaliteli yazılımı öngörülebilir bir şekilde, bütçe ve zaman kısıtları dahilinde üretmek.
  • Her süreç, belirli bir yazılım süreç modeli tarafından soyut bir şekilde temsil edilir.

Yazılım Süreç Modeli Nedir?

  • Soyut Bir Temsil: Bir yazılım süreci modeli, bir sürecin basitleştirilmiş, soyut bir temsilidir. Gerçek dünyadaki karmaşık sürecin anlaşılmasını kolaylaştırır.
  • Belirli Bir Bakış Açısı: Süreci, belirli bir perspektiften (örneğin, aktivitelerin sıralı akışı, risk yönetimi döngüsü vb.) açıklar.
  • Faaliyetler ve Sıralama: Modelleri tartışırken genellikle süreç içindeki ana faaliyetlerden (örneğin, bir kullanıcı arayüzü tasarlama) ve bu faaliyetlerin nasıl sıralandığından bahsederiz.

Süreç Açıklamasının Bileşenleri

Ancak, bir süreci resmi olarak tanımlamak için sadece faaliyet akışından daha fazlası gerekir. Kapsamlı bir süreç açıklaması şunları da içerebilir:

  • Ürünler (Products / Artifacts):
    • Bir faaliyetin sonucunda ortaya çıkan çıktılar.
    • Örn: Gereksinim dokümanı, UML diyagramı, test raporu, çalıştırılabilir kod.
  • Roller (Roles):
    • Sürece dahil olan kişilerin ve ekiplerin sorumlulukları.
    • Örn: Proje Yöneticisi, Analist, Geliştirici, Test Uzmanı.

Süreç Açıklamasının Bileşenleri (devam)

  • Ön ve Son Koşullar (Pre- and Post-conditions):
    • Bir faaliyetin başlayabilmesi için doğru olması gereken koşullar (ön koşul) ve faaliyet bittiğinde doğru olması gereken durum (son koşul).
    • Örn: “Test” faaliyetinin ön koşulu “kodun derlenmiş olmasıdır”.

Temel Süreç Aktiviteleri

Hemen hemen tüm yazılım süreç modelleri, farklı şekillerde de olsa şu dört temel aktiviteyi içerir:

  • Spesifikasyon (Ne yapılacak?)
  • Geliştirme (Nasıl yapılacak?)
  • Doğrulama (Doğru yapıldı mı?)
  • Evrim / Bakım (Değişen gereksinimlere uyum)

Bu aktivitelerin sırası ve etkileşimi, seçilen sürece göre değişir.

1. Yazılım Spesifikasyonu

Bu aktivitenin amacı, sistemin sunacağı hizmetleri ve çalışacağı ortamın kısıtlarını anlamak ve tanımlamaktır. Bu süreç, Gereksinim Mühendisliği olarak da bilinir ve yazılımın başarısı için en kritik aşamadır.

Temel Çıktısı: Sistemin ne yapması gerektiğini detaylandıran bir Gereksinim Dokümanıdır.

Gereksinim Mühendisliği Süreci

Spesifikasyon süreci kendi içinde alt adımlara ayrılır:

  • Fizibilite Çalışması: Projenin teknik, ekonomik ve operasyonel olarak yapılabilir olup olmadığının değerlendirilmesi.
  • Gereksinimleri Ortaya Çıkarma ve Analiz: Paydaşlarla (müşteri, kullanıcılar vb.) görüşerek sistemden beklentilerini anlama.
  • Gereksinimleri Belirtme: Anlaşılan gereksinimleri net, tutarlı ve anlaşılır bir şekilde dokümante etme.
  • Gereksinimleri Doğrulama: Belirtilen gereksinimlerin gerçekten paydaşların istediği şeyler olup olmadığını kontrol etme.

2. Yazılım Tasarımı ve Entegrasyon

Bu aktivitenin amacı, gereksinim spesifikasyonunu çalıştırılabilir bir sisteme dönüştürmektir. Bu, iki ana faaliyetten oluşur:

  • Yazılım Tasarımı: Gereksinimleri karşılayacak yazılımın yapısını, mimarisini, bileşenlerini, arayüzlerini ve veritabanını tasarlama.

  • Gerçekleştirim (Implementation): Tasarımın, seçilen programlama dilinde koda dökülmesi.

  • Bu iki faaliyet genellikle birbiriyle iç içe ve tekrarlı olarak yürütülür.

Tasarım Faaliyetleri

Tasarım süreci, farklı soyutlama seviyelerinde gerçekleşen birkaç ana aktiviteyi içerir:

  • Mimari Tasarım: Sistemin genel yapısını, ana bileşenlerini (alt sistemler veya modüller) ve aralarındaki ilişkileri belirleme.
  • Arayüz Tasarımı: Sistem bileşenleri arasındaki ve sistem ile dış dünya (kullanıcılar, diğer sistemler) arasındaki arayüzleri tanımlama.
  • Bileşen Tasarımı: Her bir bileşenin iç yapısını ve nasıl çalışacağını tasarlama.
  • Veritabanı Tasarımı: Sistemin kullanacağı veri yapılarının ve bu yapıların veritabanında nasıl temsil edileceğinin tasarlanması.

3. Yazılım Doğrulama (Verification & Validation)

Bu aktivitenin amacı, yazılımın spesifikasyonlara uygun olduğunu ve müşterinin beklentilerini karşıladığını göstermektir. İki temel kavramı içerir:

  • Doğrulama (Verification): “Ürünü doğru mu inşa ediyoruz?”
    • Yazılımın, spesifikasyonlara (gereksinim ve tasarım dokümanlarına) uygun olup olmadığını kontrol etme.
  • Geçerleme (Validation): “Doğru ürünü mü inşa ediyoruz?”
    • Yazılımın, müşterinin gerçek ihtiyaçlarını ve beklentilerini karşılayıp karşılamadığını kontrol etme.

Bu süreçteki en yaygın aktivite test etmektir.

Test Aşamaları

Test etme genellikle üç ana aşamada gerçekleştirilir:

  • Bileşen (Birim) Testi: Her bir bileşen (bir fonksiyon, class veya modül) diğerlerinden bağımsız olarak tek başına test edilir. Geliştirici tarafından yapılır.
  • Sistem Testi: Tüm bileşenler bir araya getirildikten sonra sistemin bir bütün olarak test edilmesi. Sistemin fonksiyonel ve fonksiyonel olmayan gereksinimleri karşılayıp karşılamadığı kontrol edilir.
  • Kabul Testi: Sistemin müşterinin ihtiyaçlarını karşılayıp karşılamadığını görmek için, genellikle müşteri verileriyle yapılan son testtir. Müşteri, sistemi “kabul edip etmediğine” bu aşamada karar verir.

4. Yazılım Evrimi (Değişim)

Yazılım sistemleri statik değildir; değişen iş ve pazar koşullarına uyum sağlamak için sürekli olarak değişmek zorundadırlar.

  • Değişimin Nedenleri:
    • Yeni iş gereksinimlerinin ortaya çıkması.
    • Mevcut gereksinimlerin değişmesi.
    • Hataların düzeltilmesi (bakım).
    • Yeni teknolojilere veya platformlara uyum sağlama zorunluluğu.

Bu nedenle, geliştirme ve bakım (evrim) arasındaki çizgi, özellikle uzun ömürlü sistemler için giderek belirsizleşmektedir.

Süreç Modellerinin Sınıflandırılması

Yazılım süreçleri genel olarak iki ana felsefeye ayrılır:

  • Plan Odaklı Süreçler (Plan-Driven)
  • Çevik Süreçler (Agile)

Not

Bu derste daha çok geleneksel ve plan odaklı modellere odaklanacağız. Çevik (Agile) metodolojiler ayrı bir dersin konusudur.

Plan Odaklı Süreçler (Plan-Driven)

  • Tüm süreç aktiviteleri önceden detaylı olarak planlanır.
  • İlerleme, bu plana göre ölçülür.
  • Gereksinimlerin en başta net ve sabit olduğu varsayılır.
  • Örnek: Şelale

Çevik Süreçler (Agile)

  • Planlama artımlıdır ve değişime açıktır.
  • Süreci, değişen müşteri gereksinimlerine göre adapte etmek kolaydır.
  • Hızlı ve esnek teslimat ön plandadır.

Pratikte Süreçler

  • Hem plan odaklı hem çevik unsurlar barındırır
  • Doğru/Yanlış süreçleri yoktur. Proje yapısına uygun süreçler vardır.

Şelale (Waterfall) Modeli

  • En eski ve en bilinen süreç modelidir.
  • Plan odaklıdır ve aktiviteler arasında sıralı bir akış vardır.
  • Bir sonraki aşamaya geçmeden önce mevcut aşamanın tamamen bitirilmesi gerekir.

Şelale Modeli Aşamaları

  1. Gereksinim Analizi ve Tanımı: Sistemin hizmetleri, kısıtları ve hedefleri belirlenir.
  2. Sistem ve Yazılım Tasarımı: Sistem mimarisi ve temel yazılım bileşenleri tasarlanır.
  3. Uygulama ve Birim Testi: Yazılım, modüller halinde geliştirilir ve her birim ayrı ayrı test edilir.
  4. Entegrasyon ve Sistem Testi: Birimler birleştirilir ve sistem bir bütün olarak test edilir.
  5. Yayınlama: Sistem müşteriye teslim edilir.
  6. Bakım: Hatalar düzeltilir ve yeni ihtiyaçlar eklenir.

Şelale Modeli: Avantajları

  • Anlaşılması ve yönetilmesi basittir.
  • Her aşamanın sonunda belirli çıktılar (dokümanlar) olduğu için disiplinli bir yapı sunar.
  • Gereksinimlerin çok iyi anlaşıldığı ve sabit olduğu projeler için uygundur.

Şelale Modeli: Dezavantajları

  • Esnek Değildir: Değişen müşteri gereksinimlerine uyum sağlamak çok zor ve maliyetlidir.
  • Geç Geri Bildirim: Müşteri, çalışan bir sistemi ancak projenin sonlarına doğru görür.
  • Riskli: Başta anlaşılamayan bir gereksinim, projenin sonunda büyük bir probleme dönüşebilir.

Şelale Modeli: Uygulama Senaryosu

Senaryo: Bir devlet kurumu için, yasal mevzuatlarla tüm kuralları ve hesaplama yöntemleri net olarak belirlenmiş bir vergi beyanname sisteminin geliştirilmesi.

Neden Şelale Modeli Uygun?

  • Sabit Gereksinimler: Yasal mevzuat, gereksinimlerin proje boyunca değişmeyeceğini garanti eder.
  • Öngörülebilirlik: Kamu projelerinde bütçe ve zaman çizelgesine sıkı sıkıya uymak kritiktir. Şelale modelinin planlı yapısı bunu destekler.
  • Dokümantasyon: Her aşamada üretilen detaylı dokümanlar, projenin denetlenebilirliği ve ilerideki bakım süreçleri için zorunludur.

V-Modeli (Doğrulama ve Geçerleme Modeli)

  • Şelale modelinin, test süreçlerini daha belirgin hale getiren bir uzantısıdır.
  • Temel felsefesi, her geliştirme aşamasına karşılık paralel bir test aşamasının planlanmasıdır.
  • Modelin ‘V’ şekli, geliştirme aktivitelerinden (sol taraf) test aktivitelerine (sağ taraf) geçişi simgeler. Kodlama, V’nin en alt noktasını oluşturur.

V-Modeli: Geliştirme ve Test İlişkisi

V-Modeli, geliştirme ve test fazları arasında net bir ilişki kurar:

  • Gereksinim Analizi - Kabul Testleri (Müşteri ihtiyaçları karşılanıyor mu?)
  • Sistem Tasarımı - Sistem Testleri (Tüm sistem bir bütün olarak doğru çalışıyor mu?)
  • Mimari Tasarım - Entegrasyon Testleri (Modüller bir araya geldiğinde doğru çalışıyor mu?)
  • Modül Tasarımı - Birim Testleri (En küçük kod parçası doğru çalışıyor mu?)

Bu yapı, “testi en başından düşünme” prensibini zorunlu kılar.

V-Modeli: Uygulama Senaryosu

Senaryo: Bir otomobil için geliştirilen Motor Kontrol Ünitesi (ECU) yazılımı. Bu yazılım, yakıt enjeksiyonunu, ateşlemeyi ve emisyonları kontrol eder.

Neden V-Modeli Uygundur?

  • Güvenlik Kritikliği: Yazılımdaki bir hata, motorun arızalanmasına veya yüksek emisyon değerlerine yol açabilir. Bu nedenle her seviyede katı test zorunludur.
  • İzlenebilirlik (Traceability): Her gereksinimin (örneğin, “Yakıt enjeksiyonu X milisaniyede gerçekleşmelidir”) hangi tasarım kararına, hangi kod parçasına ve hangi teste karşılık geldiği net bir şekilde belgelenmelidir. V-Modeli bu izlenebilirliği destekler.
  • Değişmeyen Gereksinimler: Bir aracın motor kontrol gereksinimleri, üretim öncesinde büyük ölçüde sabitlenir ve proje sırasında değişmesi beklenmez. Bu da modelin katı yapısına uygundur.

Değişimle Başa Çıkmak: Temel Zorluk

Teoride plan odaklı modeller harika görünse de, pratikteki en büyük zorluk değişimdir. Tüm büyük yazılım projelerinde değişim kaçınılmazdır.

  • Değişimin Kaynakları:
    • İş Değişiklikleri: Pazar koşulları, rakip hamleleri veya şirket stratejileri, yeni sistem gereksinimlerine yol açar.
    • Yeni Teknolojiler: Yeni teknolojiler, mevcut uygulamaları iyileştirmek veya yeni özellikler eklemek için fırsatlar sunar.
    • Değişen Platformlar: İşletim sistemleri, veritabanları veya donanımlardaki değişiklikler, yazılımda da değişiklik gerektirir.

Değişiklik, yeniden çalışma (rework) demektir ve bu da projelere maliyet olarak yansır.

Yeniden İşleme Maliyetlerini Düşürmek: İki Strateji

Değişimin kaçınılmaz maliyetini yönetmek için iki temel strateji vardır:

  1. Değişimden Kaçınma (Change Avoidance):
    • Süreç içinde, gelecekte ortaya çıkabilecek olası değişiklikleri öngörmeye ve önlemeye yönelik etkinlikler içerir.
    • En güçlü tekniği prototiplemedir. Müşteriye sistemin erken bir versiyonunu göstererek, gereksinimleri en başta netleştirmek ve “yanlış anladık” kaynaklı büyük değişikliklerden kaçınmak hedeflenir.
  2. Değişim Toleransı (Change Tolerance):
    • Süreci ve mimariyi, değişikliklerin düşük maliyetle ve kolayca uygulanabileceği şekilde tasarlamaktır.
    • En güçlü tekniği artımlı teslimattır. Bir değişiklik talebi, mevcut işi bozmadan, henüz geliştirilmemiş bir sonraki artıma eklenebilir.

Artımlı (Incremental) Geliştirme

  • Plan odaklı ve çevik yaklaşımların bir karışımıdır.
  • Sistem, “artım” (increment) adı verilen parçalar halinde geliştirilir ve teslim edilir.
  • Her artım, sistemin bir alt kümesini veya yeni bir işlevselliği içerir.

Artımlı Geliştirme ve Artımlı Teslimat

Bu iki kavramı ayırt etmek önemlidir:

  • Artımlı Geliştirme (Incremental Development):
    • Sistemi aşamalar halinde geliştirmek ve bir sonraki artıma geçmeden önce her bir artışı (genellikle ekip içinde veya müşteri vekili ile) değerlendirmektir.
    • Çevik yöntemlerde kullanılan standart yaklaşımdır. Tüm sistem bitene kadar son kullanıcıya bir teslimat yapılmayabilir.
  • Artımlı Teslimat (Incremental Delivery):
    • Geliştirilen her bir artımı son kullanıcıların kullanımına sunmaktır.
    • Bu sayede yazılımın pratik kullanımı hakkında çok daha gerçekçi ve erken geri bildirim alınır.

Özetle: Artımlı teslimat, artımlı geliştirmeyi zorunlu kılar, ancak bir ekip artımlı geliştirme yapıp tek bir büyük teslimat yapmayı da seçebilir.

Artımlı Geliştirme: Avantajlar

Avantajları:

  • Değişim Maliyeti Düşüktür: Değişiklikler bir sonraki artımda ele alınabilir.
  • Erken Geri Bildirim: Müşteriler, sistemin ilk versiyonlarını erken aşamada görerek değerli geri bildirimler sağlar.
  • Hızlı Değer Teslimi: Sistemin en önemli ve öncelikli fonksiyonları daha erken kullanıma sunulur.
  • Daha Düşük Risk: Tüm projeyi tek seferde yapma riski yerine, risk küçük parçalara bölünür.

Artımlı Geliştirme: Dezavantajlar

  • Süreç Görünmezliği: Düzenli dokümantasyon üretilmezse, yöneticiler için süreci takip etmek zor olabilir.
  • Sistem Yapısının Bozulması: Sürekli eklemelerle, iyi bir yeniden düzenleme (refactoring) yapılmazsa sistemin mimari yapısı zamanla bozulabilir.

Artımlı Geliştirme: Uygulama Senaryosu

Senaryo: Yeni bir e-ticaret platformu geliştiren bir startup. İlk hedef, kullanıcıların ürünleri listeleyip satın alabildiği temel bir sürümü 3 ay içinde yayına almaktır.

Neden Artımlı Model Uygundur?

  • Hızlı Pazara Çıkış (Time-to-Market): İlk artım (temel alım-satım), şirketin en kısa sürede pazara girip gelir elde etmeye başlamasını sağlar. Bu, startup’lar için hayati önemdedir.
  • Kullanıcı Geri Bildirimi: İlk sürümden sonra, kullanıcıların en çok istediği özellikler (örneğin, ürün yorumları, favorilere ekleme, indirim kuponları) önceliklendirilerek sonraki artımlarda geliştirilir.
  • Risk Yönetimi: Milyonlarca liralık tam özellikli bir platformu tek seferde geliştirme riskine girmek yerine, proje küçük, yönetilebilir ve değer üreten parçalara bölünür.

Yeniden Kullanım Odaklı Yazılım Mühendisliği

  • Sistem, tamamen sıfırdan yazmak yerine, mevcut bileşenlerin veya servislerin birleştirilmesiyle oluşturulur.
  • Süreç Aşamaları:
    1. Bileşen Analizi: İhtiyaçları karşılayacak mevcut bileşenleri araştırma.
    2. Gereksinim Uyarlaması: Gereksinimleri, bulunan bileşenlere göre revize etme.
    3. Yeniden Kullanım Tabanlı Tasarım: Sistemi bu bileşenler etrafında tasarlama.
    4. Geliştirme ve Entegrasyon.

Yazılım Bileşeni Türleri

Yeniden kullanım odaklı mühendislikte bahsettiğimiz ‘bileşenler’ farklı şekillerde karşımıza çıkabilir. En yaygın türleri şunlardır:

  • Hizmet Olarak Sunulan Bileşenler (Services):
    • Standart arayüzler (genellikle REST API) üzerinden uzaktan çağrılarak kullanılan, bağımsız, çalışır durumdaki hizmetlerdir.
    • Örnek: Google Maps API, online ödeme servisleri (Stripe, Iyzico).

Yazılım Bileşeni Türleri (Devam)

  • Koleksiyonlar ve Çerçeveler (Frameworks):
    • Kendi kodunuza entegre ettiğiniz, belirli bir işlevselliği sağlayan nesne koleksiyonları veya kütüphanelerdir. Standalone çalışmazlar.
    • Örnek: .NET Framework, Jakarta EE (Java EE), Spring Framework.
  • Ticari Satışa Hazır Yazılımlar (COTS):
    • Belirli bir amaca yönelik geliştirilmiş, satın alınıp yapılandırılarak kullanılan, genellikle kendi başına çalışan komple sistemlerdir.
    • Örnek: Oracle Database, SAP ERP, WordPress (CMS), Salesforce (CRM).

Yeniden Kullanım: Avantajları

  • Hız ve Verimlilik: Kanıtlanmış bileşenleri kullanmak, geliştirme süresini önemli ölçüde azaltır.
  • Düşük Maliyet ve Risk: Sıfırdan geliştirme maliyetinden tasarruf edilir ve test edilmiş bileşenler daha güvenilirdir.

Yeniden Kullanım: Dezavantajları

  • Gereksinimlerden Ödün Verme: Sistem, tam olarak istenen gereksinimler yerine mevcut bileşenlerin yetenekleriyle sınırlı kalabilir.
  • Kontrol Kaybı: Kullanılan bileşenlerin (özellikle COTS) gelecekteki güncellemeleri, lisanslama koşulları ve bakımı sizin kontrolünüzde değildir.
  • Entegrasyon Zorlukları: Farklı kaynaklardan gelen bileşenleri bir araya getirmek beklenenden karmaşık olabilir.

Yeniden Kullanım: Uygulama Senaryosu

Senaryo: Bir üniversitenin, personel duyuruları, yemekhane menüsü, akademik takvim ve haberler gibi bilgileri gösterecek bir kurumsal intranet portalı oluşturması.

Neden Yeniden Kullanım Modeli Uygundur?

  • COTS Kullanımı: Sıfırdan bir portal yazmak yerine, WordPress gibi hazır bir İçerik Yönetim Sistemi (CMS) temel olarak kullanılabilir. Bu, COTS yaklaşımıdır.
  • Hizmet Entegrasyonu: Akademik takvim için mevcut Google Calendar API’si entegre edilebilir. Bu, hizmet odaklı bir bileşen kullanımıdır.
  • Standart İhtiyaçlar: İstenen fonksiyonların çoğu (haber yönetimi, kullanıcı rolleri vb.) piyasada hazır eklentiler veya bileşenler olarak mevcuttur.

Evrimsel Modeller: Prototipleme

  • Bir prototip, bir sistemin fikirleri göstermek ve tasarım seçeneklerini denemek için kullanılan erken bir versiyonudur.

  • Tek başına bir model olmaktan çok, diğer süreçlerin içinde kullanılan bir tekniktir.

  • Kullanım Amaçları:

    • Gereksinim mühendisliği sürecinde, gereksinimleri netleştirmek ve doğrulamak.
    • Tasarım sürecinde, kullanıcı arayüzü gibi seçenekleri keşfetmek.
    • Kullanıcılardan erken geri bildirim almak.

Not

Prototipler genellikle “atılmak” üzere geliştirilir. Üretim sisteminin temeli olarak kullanılmamalıdır çünkü kalite standartlarını karşılamazlar.

Evrimsel Modeller: Sarmal (Spiral) Model

  • Barry Boehm tarafından geliştirilmiştir.
  • Süreci, risk odaklı bir yaklaşımla yinelenen bir sarmal olarak temsil eder.
  • Şelale modelinin sıralı yapısıyla prototiplemenin esnekliğini birleştirir.
  • Özellikle büyük, karmaşık ve yüksek riskli projeler için uygundur.

Sarmal Modelin Döngüleri

Sarmalın her bir döngüsü dört ana aktiviteyi temsil eder:

  1. Hedef Belirleme: Döngü için özel hedefler belirlenir.
  2. Risk Değerlendirmesi ve Azaltma: Proje için potansiyel riskler analiz edilir ve bunları çözmek için adımlar atılır (örneğin prototip oluşturma).
  3. Geliştirme ve Doğrulama: Riskler çözüldükten sonra, uygun bir geliştirme modeli (örneğin Şelale) seçilerek o aşama geliştirilir.
  4. Planlama: Proje gözden geçirilir ve sarmalın bir sonraki döngüsü planlanır.

Sarmal Model: Avantajları

  • Güçlü Risk Yönetimi: Riskleri projenin erken aşamalarında fark edip yönetme olanağı sunar. Bu, en temel gücüdür.
  • Esneklik: Proje ilerledikçe gereksinimler netleşebilir ve değişikliklere uyum sağlanabilir.
  • Müşteri Katılımı: Her döngünün sonunda yapılan değerlendirmeler, müşterinin sürece sürekli dahil olmasını sağlar.
  • Büyük Projelere Uygunluk: Karmaşık ve büyük sistemlerin geliştirilmesini yönetilebilir parçalara böler.

Sarmal Model: Dezavantajları

  • Karmaşıklık: Yönetimi diğer modellere göre daha zordur ve risk analizi konusunda uzmanlık gerektirir.
  • Maliyetli: Sürekli planlama, risk analizi ve prototipleme süreçleri maliyeti artırabilir.
  • Küçük Projeler İçin Uygun Değil: Düşük riskli veya küçük ölçekli projeler için getirdiği yönetimsel yük fazladır.

Sarmal Model: Uygulama Senaryosu

Senaryo: NASA’nın, daha önce denenmemiş yeni sensörler ve yapay zeka tabanlı otonom sürüş algoritmaları kullanacak yeni bir Mars keşif aracının (rover) kontrol yazılımını geliştirmesi.

Neden Sarmal Model Uygundur?

  • Yüksek Teknik Risk: Projenin en büyük belirsizliği şudur: “Geliştireceğimiz yapay zeka algoritması, Mars’ın bilinmeyen yüzey koşullarında aracı güvenli bir şekilde sürebilecek mi?” Bu, projenin en başında ele alınması gereken devasa bir risktir.
  • Risk Odaklı İlerleme: Sarmal modelin ilk döngüsü tamamen bu riski azaltmaya odaklanabilir. Örneğin, ilk döngünün “Geliştirme” adımında Mars yüzeyini taklit eden bir simülasyon (prototip) ortamı yaratılıp algoritmanın performansı test edilebilir.
  • Hataya Tahammülün Olmaması: Projenin başarısızlık maliyeti (milyarlarca dolar ve yılların emeği) aşırı yüksek olduğundan, risk odaklı ve her adımı dikkatle planlanan bir süreç zorunludur.

Modern Bir Çerçeve: Rational Unified Process (RUP)

  • UML (Unified Modeling Language) ile birlikte geliştirilmiş, modern ve kapsamlı bir süreç çerçevesidir.
  • Tek bir model değil, uyarlanabilir bir “framework”tür.
  • Daha önce tartışılan modellerin (artımlı, şelale vb.) birçok yönünü bir araya getirir.

Temel Prensipleri:

  • Yinelemeli ve Artımlı (Iterative and Incremental)
  • Mimari Merkezli (Architecture-centric)
  • Kullanım Senaryosu Güdümlü (Use-case driven)

RUP’ın Boyutları

RUP, süreci iki farklı açıdan tanımlar:

  • Dinamik Perspektif (Zaman): Sürecin yaşam döngüsünü gösteren aşamalar.
    • Başlangıç (Inception): Projenin kapsamı ve iş senaryosu oluşturulur.
    • Detaylandırma (Elaboration): Alan anlaşılır, mimari temel oluşturulur ve riskler ele alınır.
    • İnşa (Construction): Sistemin geri kalanı geliştirilir ve entegre edilir.
    • Geçiş (Transition): Sistem, kullanıcılara dağıtılır ve canlı ortama geçirilir.

RUP’ın Boyutları (devam)

  • Statik Perspektif (Aktiviteler): Geliştirme boyunca yapılan iş akışları (workflows).
    • İş Modelleme, Gereksinimler, Analiz ve Tasarım, Uygulama, Test, Dağıtım vb.
  • Bu iş akışları her fazda farklı yoğunlukta yürütülür; örneğin Başlangıç fazında gereksinimler ağır basarken İnşa fazında uygulama ve test öne çıkar.

RUP’ın 6 Temel İyi Uygulaması (1/2)

RUP’ın başarısı, sadece fazları takip etmekle değil, aynı zamanda aşağıdaki altı temel prensibi uygulamakla mümkündür:

  1. Yazılımı Yinelemeli Olarak Geliştirin:
    • Müşteri önceliklerine göre artımları planlayın ve en yüksek değerli özellikleri ilk olarak teslim edin.
  2. Gereksinimleri Yönetin:
    • Müşteri gereksinimlerini net bir şekilde belgeleyin ve bu gereksinimlerdeki değişiklikleri izlemek için resmi bir süreç kullanın.
  3. Bileşen Tabanlı Mimariler Kullanın:
    • Sistemi, yeniden kullanılabilir ve modüler bileşenlerden oluşan sağlam bir mimari üzerine inşa edin. Bu, esnekliği ve bakımı kolaylaştırır.

RUP’ın 6 Temel İyi Uygulaması (2/2)

  1. Yazılımı Görsel Olarak Modelleyin (UML):
    • Yazılımın statik yapısını ve dinamik davranışını herkesin anlayabileceği ortak bir dil olan UML diyagramları ile modelleyin. Bu, RUP’ın temel taşlarından biridir.
  2. Yazılım Kalitesini Sürekli Doğrulayın:
    • Kalite kontrolünü sadece en sona bırakmayın. Test ve kalite güvence aktivitelerini projenin tüm yaşam döngüsüne yayın.
  3. Değişiklikleri Kontrol Altında Tutun:
    • Yapılan tüm değişiklikleri (kod, doküman, model vb.) bir konfigürasyon ve değişiklik yönetimi sistemi kullanarak izleyin ve yönetin.

Süreç İyileştirme

  • Yazılım geliştirme süreçlerinin kalitesini, verimliliğini ve öngörülebilirliğini artırmak için yapılan sistematik bir yaklaşımdır.
  • Amaç daha iyi yazılım üretmek, maliyeti düşürmek ve teslimat sürelerini kısaltmaktır.

Süreç İyileştirme Döngüsü:

  1. Ölçme (Measure): Mevcut süreci ve zayıf yönlerini anla.
  2. Analiz (Analyze): İyileştirme alanlarını ve potansiyel çözümleri belirle.
  3. Değişim (Change): Süreç değişikliğini uygula ve etkisini ölç.

Süreç Olgunluğu: CMMI

  • Capability Maturity Model Integration (CMMI), bir organizasyonun süreçlerinin ne kadar olgun ve yetkin olduğunu değerlendirmek için bir çerçevedir.
  • Süreç iyileştirme için bir yol haritası sunar.

5 Olgunluk Seviyesi:

  1. Başlangıç (Initial): Süreçler kaotik ve reaktiftir. Başarı bireysel çabaya bağlıdır.
  2. Yönetilen (Managed): Temel proje yönetimi teknikleri uygulanır. Projeler planlanır ve izlenir.
  3. Tanımlı (Defined): Organizasyon genelinde standartlaştırılmış ve dokümante edilmiş bir süreç vardır.
  4. Nicel Yönetilen (Quantitatively Managed): Süreç ve ürün kalitesi hakkında metrikler toplanır ve süreç nicel olarak kontrol edilir.
  5. İyileşen (Optimizing): Sürekli süreç iyileştirme kültürü vardır ve süreç proaktif olarak iyileştirilir.

Alıştırmalar

Senaryo 1

Bir banka, yasal düzenlemelerle tüm detayları net bir şekilde belirlenmiş ve gelecekte değişmesi beklenmeyen bir “Müşteri Dolandırıcılık Tespit Sistemi” geliştirmek istiyor. Tüm gereksinimler en başta dokümante edilebilir durumdadır.

Bu senaryoda hangi yazılım süreç modeli en uygundur?

  1. Artımlı Geliştirme
  2. Şelale Modeli
  3. Sarmal Model

Cevap:

B) Şelale Modeli. Gereksinimler baştan sona net, sabit ve iyi anlaşıldığı için, Şelale modelinin sıralı ve plan odaklı yapısı bu tür bir proje için en düşük riski ve en yüksek öngörülebilirliği sunar.

Senaryo 2

NASA, Mars’a gönderilecek yeni bir keşif aracının uçuş kontrol yazılımını geliştirecek. Proje oldukça karmaşık, bütçesi çok yüksek ve yazılım hatası felaketle sonuçlanabilir. Geliştirme sürecinde birçok teknik belirsizlik ve risk bulunmaktadır.

Bu senaryoda hangi yazılım süreç modeli en uygundur?

  1. Şelale Modeli
  2. Yeniden Kullanım Odaklı Model
  3. Sarmal Model

Cevap ve Açıklama:

C) Sarmal Model. Projenin yüksek riskli, karmaşık ve belirsizliklerle dolu olması, Sarmal modelin temel gücü olan sürekli risk analizi ve azaltma döngülerini en uygun seçenek haline getirir. Her döngüde riskler ele alınarak ilerlenir.

Senaryo 3

Bir startup, daha önce benzeri olmayan yenilikçi bir mobil sosyal ağ uygulaması geliştirmek istiyor. Pazarın ne isteyeceği tam olarak bilinmiyor ve özelliklerin kullanıcı geri bildirimlerine göre hızla şekillenmesi gerekiyor. Sistemin temel bir versiyonunu en kısa sürede piyasaya sürmek kritik öneme sahip.

Bu senaryoda hangi yazılım süreç modeli en uygundur?

  1. Artımlı Geliştirme
  2. Şelale Modeli
  3. Yeniden Kullanım Odaklı Model

Cevap ve Açıklama:

A) Artımlı Geliştirme. Bu model, temel işlevselliğe sahip bir ürünün hızla piyasaya sürülmesine (erken teslimat) ve ardından kullanıcı geri bildirimlerine dayalı olarak yeni özelliklerin artımlar halinde eklenmesine olanak tanır. Değişime ve esnekliğe en uygun yapıdır.

Senaryo 4: Güvenlik Kritik Tıbbi Cihaz

Bir medikal teknoloji firması, diyabet hastaları için kan şekerini ölçüp otomatik olarak insülin enjekte eden bir insülin pompası cihazının yazılımını geliştirecektir. Yazılımdaki en ufak bir hatanın hayati sonuçları olabilir ve tüm gereksinimlerin test edildiği resmi olarak kanıtlanmalıdır.

Bu senaryoda hangi yazılım süreç modeli en uygundur?

  1. V-Modeli
  2. Artımlı Geliştirme
  3. Sarmal Model

Cevap:

A) V-Modeli. Bu proje güvenlik-kritik bir sistemdir. V-Modeli, her geliştirme aşamasına karşılık bir test aşaması tanımlayarak katı bir doğrulama ve geçerleme (V&V) süreci sunar. Gereksinimlerin testlerle birebir eşleştirilmesi (izlenebilirlik), bu tür projeler için zorunludur ve V-Modeli’nin temel gücüdür.

Özet

  • Yazılım süreç modelleri, yazılım geliştirme için bir yol haritası sunar.
  • “Tek bir doğru model yoktur.” Model seçimi projenin türüne, büyüklüğüne, risklerine ve takımın kültürüne bağlıdır.
  • Şelale: Gereksinimler sabit olduğunda kullanılır.
  • Artımlı Geliştirme: Hızlı değer teslimi ve esneklik gerektiğinde idealdir.
  • Yeniden Kullanım: Hız kritik olduğunda ve uygun bileşenler mevcut olduğunda güçlüdür.
  • Sarmal: Büyük ve riskli projeler için risk yönetimi sağlar.
  • RUP: Kapsamlı ve uyarlanabilir bir modern çerçevedir.
  • Süreç iyileştirme (CMMI), organizasyonların daha öngörülebilir ve verimli hale gelmelerine yardımcı olur.