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ı:
- Planlama
- Çözümleme
- Tasarım
- Gerçekleştirim
- Bakım
- Gelişigüzel Model (60'lı yıllarda tek kişilik üretim ortamlarında kullanılan yöntemdir)
- Barok Modeli
- Çağlayan Modeli
- V Modeli
- Helezonik Model ve Uyarımları
- İnceleme
- Analiz
- Tasarım
- Kodlama
- Modül Testleri
- Altsistem Testleri
- Sistem Testi
- Belgeleme
- Kurulum
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.
- 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 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.
- 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ı:
- 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.
- 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.
- 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.
- Ç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ı!
- 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ü.
- Bir metodoloji,
- bir süreç modelini ve
- belirli sayıda belirtim yöntemini içerir
- 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 |
---|
|
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
Hiç yorum yok:
Yorum Gönder