Yazılım Geliştirme Yaşam Döngüsü ve Test

Konu Anlatımı

Yazılım Geliştirme Yaşam Döngüsü ve Test

Yazılım geliştirme yaşam döngüsü, bir yazılımın fikirden kullanıma ve bakıma kadar geçtiği aşamaların tümüdür. Bu aşamaların sırası, projenin büyüklüğüne ve kullanılan yönteme göre değişebilir; ancak analiz, tasarım, kodlama, test, yayın ve bakım başlıkları her yöntemde bulunur. Yazılımın kalitesi, bu aşamalardan hangisinin atlandığıyla doğrudan ilişkilidir.

Analiz ve Tasarım

Analiz aşamasında kullanıcının ne istediği anlaşılır ve gereksinimler yazılı hâle getirilir. Gereksinimler; işlevsel olmayan isteklerle birlikte kullanım senaryosu, veri sözlüğü ve akış şemaları gibi belgelerle desteklenir. Tasarım aşamasında bu gereksinimler; veri tabanı şemasına, arayüz tasarımına ve modül yapısına dönüştürülür. İyi bir tasarım, sonradan değişikliği en az maliyetle yapmayı sağlar.

Kodlama ve Kod İnceleme

Kodlama aşamasında tasarım dile dönüştürülür. Yazılan kod; okunabilir, anlaşılır ve gereksiz karmaşıklıktan arındırılmış olmalıdır. Kod inceleme yöntemi, kodun ayrı bir kişi tarafından okunarak hataların yazılı aşamadan yakalanmasını sağlar. Küçük ekiplerde bile eşleşmeli inceleme yararlıdır; çünkü inceleyen kişi farklı bir bakış açısıyla hatayı görür.

Çevik ve Geleneksel Yöntem

Geleneksel şel model, tüm gereksinimlerin baştan tanımlandığı ve aşamaların sırayla yürütüldüğü yöntemdir; büyük ve değişmeyen gereksinimlere uygundur. Çevik yöntem ise kısa döngülerle çalışır, müşteri geri bildirimini sık alır ve değişikliğe esnek davranır. İki yöntem arasındaki fark, projenin belirsizlik düzeyi ve geri bildirim sıklığıyla ilgilidir.

Test Türleri

Birim testinde geliştirici tek bir modülü kendi yazdığı kodla dener. Entegrasyon testinde modüllerin birbirine veri aktarımı sınanır. Sistem testinde tüm uygulama gereksinimlere karşı sınanır. Kabul testinde kullanıcı, sistemi gerçek senaryolarla kullanarak uygunluğa karar verir. Performans testi yanıt süresini ve yükü, güvenlik testi ise yetkisiz erişim senaryolarını ölçer.

Hata Takibi ve Metrikler

Her hata için kusur kaydı açılır; kayıtta hatanın yeniden üretilme adımları, beklenen sonuç ile gerçekleşen sonuç ve etkisi bulunur. Kusur kalan oranı = açık kusur / (kapalı kusur + açık kusur) × 100 bağıntısıyla izlenir. Bu oran projenin olgunluğunu gösterir; kabul aşamasına girmeden düşürülmesi gerekir.

Yayın ve Bakım

Yayın aşamasında sürüm numarası verilir ve değişiklik kayıtları yazılır. Bakım aşamasında ortaya çıkan hatalar giderilir, kullanıcı talepleri değerlendirilir ve performans ölçümleri yapılır. Bakım maliyeti, geliştirme maliyetinin önemli bir bölümünü oluşturduğu için yazılımın baştan ölçeklenebilir ve belgelenmiş tasarlanması gerekir.

• Test kapsamı = test edilen modül sayısı / toplam modül sayısı
• Kusur yoğunluğu = bulunan kusur / kod satırı
• Kusur kalan oranı = açık kusur / toplam kusur

Sürüm ve Yapılandırma

Sürüm numaralarında değişiklik derecesine göre artış yapılır ve her sürüm için geri dönüş noktası oluşturulur. Yapılandırma ayarları koddan ayrı tutulur; böylece aynı yazılım farklı kurumlarda farklı değerlerle çalıştırılabilir. Bu ayrım, hem test hem de bakım süreçlerini hızlandırır.

Ne Öğreneceğiz

Analiz, tasarım, kodlama, test, yayın ve bakım aşamalarından oluşan yazılım geliştirme sürecini, çevik ve geleneksel yöntem farklarını, test türleri ile hata takibini kapsar. Bu konuda ögrenme çıktıları:

• Yazılım geliştirme yaşam döngüsü aşamalarını sıralar ve her aşamanın çıktısını belirler.
• Çevik yöntem ile geleneksel yöntemin farklarını karşılaştırır ve uygun yöntemi seçer.
• Test kapsamı, hata yoğunluğu ve kusur kalan oranı gibi ölçütleri hesaplar.
• Birim, entegrasyon, sistem ve kabul testlerini ayırt eder.
• Hata kaydını aynı biçimde açar, önceliklendirir ve kapatma sürecini izler.

Ön Bilgi

Bu konuya başlamadan önce temel kavram ve ön koşulları kavramanız yardımcı olacaktır. Konunun çerçevesinde şu kavramlar dikkat ister:

• Gereksinimler yazılı hâle gelmeden kodlama aşamasına geçilmemelidir.
• Kod inceleme, hataları yazılı aşamadan yakalamanın en etkili yollarından biridir.
• Birim, entegrasyon, sistem ve kabul testleri farklı amaçlara hizmet eder.
• Her hata kaydında yeniden üretme adımları bulunmalıdır; aksi hâlde hata düzeltilemez.
• Sürüm numarası ve değişiklik kaydı olmadan bakım yapılamaz.

Basit Örnek ve Günlük Yaşam

Günlük yaşamda ve mesleki bağlamda bir uygulama:

Soru: Bir uygulamada 40 modülden 34'üne test senaryosu yazıldı.

1. Test edilen modül sayısı belirlenir.
2. Toplam modül sayısıyla karşılaştırılır.
3. Oran hesaplanıp eksik modüller listelenir.

Sonuç/cevap: Test kapsamı 34 / 40 = %85 olarak bulunur; kalan 6 modül için senaryo yazılmalıdır.

İleri Örnek

Daha ileri bir uygulama:

Soru: Kullanıcı, rapor ekranında filtre uygulandığında liste boş göründüğünü bildirmiştir.

1. Hatanın yeniden üretilme adımları kayda yazılır.
2. Beklenen sonuç ile gerçekleşen sonuç karşılaştırılır.
3. Öncelik ve etki bilgisi belirtilerek kusur kaydı açılır.

Sonuç/cevap: Yeniden üretilebilir, beklenen ve gerçek sonucu içeren kayıt, hatanın düzeltilmesi için gereklidir.

Adım Adım Çözülmüş Örnek

Test Kapsamının Hesaplanması konusunun adımları:

1. Test edilen modül sayısı belirlenir.
2. Toplam modül sayısıyla karşılaştırılır.
3. Oran hesaplanıp eksik modüller listelenir.

Karşılaştırma Tablosu

Sık Yapılan Hatalar

Testi en sonda tek seferde yapmak: Test geciktirildiğinde hata maliyeti hızla artar; testin her sürümde tekrarlanması gerekir.

Hata kaydına yalnızca başlık yazmak: Yeniden üretim adımları olmayan bir kayıt düzeltilemez ve geliştiriciye boşa zaman kaybettirir.

Kusur kalan oranını tek başına kalite ölçütü saymak: Oran tek başına yeterli değildir; hangi modüllere dağıldığı da incelenmelidir.

Sürüm numarasını değiştirmemek: Sürüm bilgisi olmayan bir yayın, hangi düzeltmenin yapıldığının izini bırakmaz.

Kabul testini kullanıcıya bırakmadan bitirmek: Kullanıcı beklentisiyle yazılı gereksinim arasındaki fark ancak kabul aşamasında görünür.

Özet

Yazılım geliştirme yaşam döngüsü analiz, tasarım, kodlama, test, yayın ve bakım aşamalarından oluşur. Gereksinimler yazılı hâle getirilmeden kodlamaya geçilmez; kod inceleme hataları erken yakalar. Geleneksel şel model büyük ve sabit gereksinimlere, çevik yöntem ise belirsiz gereksinimlere uygundur. Test kapsamı = test edilen modül / toplam modül × 100 bağıntısıyla ölçülür; 40 modülden 34'ü test edildiyse kapsam = %85 olur. Kusur yoğunluğu bin satır başına düşen kusur sayısıdır. Kusur kalan oranı açık kusurların toplama oranını gösterir; 120 kusurun 18'i açıksa oran = %15 olur. Test verimliliği testte yakalanan kusurun toplama oranıdır; 240 kusurun 180'i testte bulunmuşsa verimlilik = %75 olarak hesaplanır.

Kendini Dene

Soru: Küçük bir kütüphane uygulaması için yazılım geliştirme yaşam döngüsü aşamalarını sıralayın ve her aşamada üretilecek çıktıyı yazınız.

Örnek cevap: Puanlama anahtarı: Altı ana aşamanın doğru sırayla yazılması 4 puan; analiz aşamasında gereksinim belgesi ve kullanım senaryosunun belirtilmesi 3 puan; tasarımda veri şeması ve arayüz tasarımının açıklanması 3 puan; test aşamasında test senaryosu ve kabul ölçütünün yazılması 3 puan; yayın ve bakım aşamalarının çıktılarının belirtilmesi 2 puan. Toplam 15 puan.