Yazılım Mühendisliği

Burada yazacaklarım okuduğum "Yazılım Mühendisliği" kitabından ve internetten faydalandığım sunum dosyalarından küçük alıntılardır.Esasen kendime not etmekten öte bir gayem olmayıp doğru bilginin yayılmasında bir parça katkıda bulunmak içindir.

Konuyu daha derinlemesine öğrenmek için kitabı satın almanızı ve interneti kurcalamanızı tavsiye ederim.

Ekonomi	Tamlık	Yeniden Kullanılabilirlik	Etkinlik	Bütünlük
Güvenirlik	Modülerlik	Belgeleme	Kullanılabilirlik	Temizlik
Değiştirilebilirlik	Geçerlilik	Esneklik	Genellik	Sınanabilirlik
Taşınabilirlik	Bakılabilirlilik	Anlaşılabilirlik	Birlikte Çalışabilirlik

Yazılım Yaşam Döngüsü Temel Adımları:

1. Planlama
2. Çözümleme
3. Tasarım
4. Gerçekleştirim
5. Bakım

Yazılım Üretim Yaşam Döngüsü Kronolojik Olarak 5 Sınıfta İncelenir:

1. Gelişigüzel Model (60'lı yıllarda tek kişilik üretim ortamlarında kullanılan yöntemdir)
   
2. Barok Modeli
3. Çağlayan Modeli
4. V Modeli
5. Helezonik Model ve Uyarımları

Barok Modeli

1. İnceleme
2. Analiz
3. Tasarım
4. Kodlama
5. Modül Testleri
6. Altsistem Testleri
7. Sistem Testi
8. Belgeleme
9. Kurulum

Yaşam döngüsü temel adımlarının doğrusal bir şekilde geliştirildiği model.
70’li yıllar.
Belgelemeyi ayrı bir süreç olarak ele alır, ve yazılımın geliştirilmesi ve testinden hemen sonra yapılmasının öngörür.
Halbuki, günümüzde belgeleme yapılan işin doğal bir ürünü olarak görülmektedir.
Aşamalar arası geri dönüşlerin nasıl yapılacağı tanımlı değil.
Gerçekleştirim aşamasına daha fazla ağırlık veren bir model olup, günümüzde kullanımı önerilmemektedir.

ŞELALE MODELİ (http://en.wikipedia.org/wiki/Waterfall_model)

• Yaşam döngüsü temel adımları baştan sona en az bir kez izleyerek gerçekleştirilir.
• İyi tanımlı projeler ve üretimi az zaman gerektiren yazılım projeleri için uygun bir modeldir.
• Geleneksel model olarak da bilinen bu modelin kullanımı günümüzde giderek azalmaktadır.
• Barok modelin aksine belgeleme işlevini ayrı bir aşama olarak ele almaz ve üretimin doğal bir parçası olarak görür.
• Barok modele göre geri dönüşler iyi tanımlanmıştır.
• Yazılım tanımlamada belirsizlik yok (ya da az) ise ve yazılım üretimi çok zaman almayacak ise uygun bir süreç modelidir.
  

Sorunları:

• Gerçek yaşamdaki projeler genelde yineleme gerektirir.
• Genelde yazılımın kullanıcıya ulaşma zamanı uzundur.
• Gereksinim tanımlamaları çoğu kez net bir şekilde yapılamadığından dolayı, yanlışların düzeltilme ve eksiklerin giderilme maliyetleri yüksektir.
• Yazılım üretim ekipleri bir an önce program yazma, çalıştırma ve sonucu görme eğiliminde olduklarından, bu model ile yapılan üretimlerde ekip mutsuzlaşmakta ve kod yazma dışında kalan (ve iş yükünün %80’ini içeren) kesime önem vermemektedirler.
• Üst düzey yönetimlerin ürünü görme süresinin uzun oluşu, projenin bitmeyeceği ve sürekli gider merkezi haline geldiği düşüncesini yaygınlaştırmaktadır.

V MODELİ

V süreç modelinin temel çıktıları;

• Kullanıcı Modeli
• Geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır.
• Mimari Model
• Sistem tasarımı ve oluşacak altsistem ile tüm sistemin sınama işlemlerine ilişkin işlevler.
• Gerçekleştirim Modeli
• Yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonlar.
• Belirsizliklerin az, iş tanımlarının belirgin olduğu BT projeleri için uygun bir modeldir.
• Model, kullanıcının projeye katkısını arttırmaktadır.
• BT projesinin iki aşamalı olarak ihale edilmesi için oldukça uygundur:
• İlk ihalede kullanıcı modeli hedeflenerek, iş analizi ve kabul sınamalarının tanımları yapılmakta,
• İkinci ihalede ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp, gerçeklenmektedir.

HELEZONİK MODEL

• Planlama
• Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirme
• Risk Analizi
• Risk seçeneklerinin araştırılması ve risklerin belirlenmesi
• Üretim
• Ara ürünün üretilmesi
• Kullanıcı Değerlendirmesi
• Ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmeler

Avantajları:

1. Kullanıcı Katkısı
• Üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından sınanması temeline dayanır.
• Yazılımı kullanacak personelin sürece erken katılması ileride oluşabilecek istenmeyen durumları engeller.
2. Yönetici Bakışı
• Gerek proje sahibi, gerekse yüklenici tarafındaki yöneticiler, çalışan yazılımlarla proje boyunca karşılaştıkları için daha kolay izleme ve hak ediş planlaması yapılır.
3. Yazılım Geliştirici (Mühendis) Bakışı
• Yazılımın kodlanması ve sınanması daha erken başlar.
• Risk Analizi Olgusu ön plana çıkmıştır.
• Her döngü bir fazı ifade eder.
• Doğrudan tanımlama, tasarım,... vs gibi bir faz yoktur.
• Yinelemeli artımsal bir yaklaşım vardır.
• Prototip yaklaşımı vardır.
  

Evrimsel Geliştirme Süreç Modeli

• İlk tam ölçekli modeldir.
• Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları).
• Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler.
• Pilot uygulama kullan, test et, güncelle diğer birimlere taşı.
• Modelin başarısı ilk evrimin başarısına bağımlıdır.

Örnek:

• Çok birimli banka uygulamaları.
• Önce sistem geliştirilir ve Şube-1’e yüklenir.
• Daha sonra aksaklıklar giderilerek geliştirilen sistem Şube-2’ye yüklenir.
• Daha sonra geliştirilen sistem Şube-3’e,…. yüklenir.
• Belirli aralıklarla eski şubelerdeki güncellemeler yapılır.

Aksaklığı:

• Değişiklik denetimi
• Konfigürasyon Yönetimidir
• Sürüm Yönetimi
• Değişiklik Yönetimi
• Kalite Yönetimi

Artırımsal Geliştirme Süreç Modeli

• Üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir.
• Öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi (bitirme tezleri).Her geliştirme süreci ile "henüz yazılmadı" içerikli özellikler sisteme eklenmiş olur.
  
• Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir.
• Bir taraftan kullanım, diğer taraftan üretim yapılır.
• Her artımdan sonra çekirdek sürekli olarak gözden geçirilmekte ve bir sonraki artım bir öncekini içerecek tarzda üretim yapılmaktadır.Bu nedenlerle değişiklik yönetimi oldukça önem kazanmaktadır (Revizyon kontrol sistemlerinin kullanımı ve kod dokümantasyonu burada yüksek öneme sahiptir).
  

• Yap-at prototipi olarak ta bilinir.
• Araştırma ortamları bütünüyle belirsizlik üzerine çalışan ortamlardır.
• Yapılan işlerden edinilecek sonuçlar belirgin değildir.
• Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır.
• Model-zaman-fiyat kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir.

Örnek:

• En Hızlı Çalışan asal sayı test programı!
• En Büyük asal sayıyı bulma programı!
• Satranç programı!

METODOLOJİLER

1. Metodoloji: Bir BT projesi ya da yazılım yaşam döngüsü aşamaları boyunca kullanılacak ve birbirleriyle uyumlu yöntemler bütünü.
2. Bir metodoloji,
1. bir süreç modelini ve
1. belirli sayıda belirtim yöntemini içerir
3. Günümüzdeki metodolojiler genelde Çağlayan ya da Helezonik modeli temel almaktadır

Bir Metodolojide Bulunması Gereken Temel Bileşenler (Özellikler)
Ayrıntılandırılmış bir süreç modeli	Konfigürasyon yönetim modeli
Ayrıntılı süreç tanımları	Maliyet yönetim modeli
İyi tanımlı üretim yöntemleri	Kalite yönetim modeli
Süreçlerarası arayüz tanımları	Risk yönetim modeli
Ayrıntılı girdi tanımları	Değişiklik yönetim modeli
Ayrıntılı çıktı tanımları	Kullanıcı arayüz ve ilişki modeli
Proje yönetim modeli	Standartlar

Bir Metodolojide Bulunması Gereken Temel Bileşenler

Metodoloji bileşenleri ile ilgili olarak bağımsız kuruluş (IEEE, ISO, vs.) ve kişiler tarafından geliştirilmiş çeşitli standartlar ve rehberler mevcuttur. Kullanılan süreç modelleri ve belirtim yöntemleri zaman içinde değiştiği için standart ve rehberler de sürekli güncellenmektedir. Bir kuruluşun kendi metodolojisini geliştirmesi oldukça kapsamlı, zaman alıcı ve uzmanlık gerektiren bir faaliyet olup, istatistikler yaklaşık 50 kişi/ay’lık bir iş gücü gerektirdiğini göstermektedir.

Bir Metodoloji Örneği
Yourdan Yapısal Sistem Tasarımı Metodolojisi.
Kolay uygulanabilir bir model olup, günümüzde oldukça yaygın olarak kullanılmaktadır.
Çağlayan modelini temel almaktadır.
Bir çok CASE aracı tarafından doğrudan desteklenmektedir.

Yourdon Yapısal Sistem Tasarım Metodolojisi