UNIFIED SÜRECİne Giriş

UNIFIED SÜRECİ’ne Giriş

Bir yazılımı geliştirmek, sunmak ve mümkün olduğu derecede bakımını yapmak aşamalarında uygulanan yaklaşıma yazılım geliştirme süreci denir. Unified Süreci ise nesne tabanlı (Object Oriented) sistemler geliştirmek için ortaya çıkmış bir yazılım geliştirme sürecidir. Bu süreç tekrarlamalar sonucunda gereksinimlerdeki değişimleri idare edebilen, riskleri yönetebilen ve gerçekten uygulandığı takdirde projeyi başarıya taşıyabilen bir süreçtir.

            Unified Süreci’nin temel iki noktası tekrarlamalı olarak geliştirmesi ve değişimi kabul edebilmesidir.

1. Tekrarlamalı Geliştirme (Iterative Development)

Unified Süreci"nin temel yapı taşı tekrarlamalı geliştirmedir (iterative development). Yazılım geliştirme kısa ve kendi içinde sabit zamanlı mini projeler halinde organize edilir. Her mini proje sonunda çalışan, test edilmiş küçük bir sistem ortaya çıkar. Fakat bu mini sistemler, genel sistemin tamamlanmamış küçük parçalarıdır.Her tekrarlama kendi içinde gereksinimlerin bulunması, analiz, tasarım ve kodlama aşamalarını içerir. Bu tekrarlamaların her birine iterasyon adı verilir.

Unified Süreci’nde sistem parça parça geliştirildiği için, sonradan doğabilecek gereksinimleri de karşılamak kolay olur. Sistem iterasyonlar sonucu kendini tekrar tekrar tanımlar ve sonuçta karşı tarafın gereksinmelerine en uygun sistem ortaya çıkmış olur. Sistemin her iterasyondan sonra testi yapıldığı için hataları bulmak ve düzeltmek hem daha kolaydır hem de daha az risk taşır.

Genel olarak Unified Sürecini bir şekille açıklamak istersek :

Şekil 1.1 Unified Süreci’nde İterasyonlar

Şekil 1.1’de her iterasyon sonucu oluşan mini sistemi prototipleme sonucu oluşan sistemler ile karıştırmamak gerekir, çünkü her mini sistem çalışan, tamamlanmış, test edilmiş bir sistemdir.

Her iterasyonun sonucunda sisteme yeni alt sistemler ve parçalar eklenecek diye kesin bir kural tanımlanmamıştır. Mesela bazı iterasyonlarda yeni parçalar eklemek yerine sadece performansı arttırmak istenebilir.

2. Değişimi Kabul Etmek

Eski yazilim geliştirme metodolojilerinde (örn. Waterfall) tüm gereksinimler ilk başta toplanır, bu gereksinimlerin analizi yapılır, tasarım ,kodlama, test ve sunum aşamaları ile devam edilirdi. Yani sonradan çıkacak gereksinimler bir bakıma kabul edilemezdi. Çünkü tüm sistem tek seferde geliştirmeye başlanmıştı.

Eski metodolojilerde yazılım geliştirme süresince geribildirim alınamazdı. Tüm sistem bittikten sonra kullanıcının görüşleri öğrenilebilirdi. Son sistemi gören kullanıcı kendi açısından bazı şeylerin eksik olduğunu, bazı şeylerin olması gerektiği gibi olmadığını düşünürse, yazılım geliştiricilerin sistemin çok büyük bölümünü baştan geliştirmesi gerekebilirdi.

Unified Süreci’nde her iterasyonda sadece gereksinimlerin bir bölümü üzerinde çalışılır ve bu gereksinimlerden bir mini sistem meydana getirilir. Yani henüz üzerinde durmadığınız gereksinimlerdeki değişiklik sizin için büyük ihtimalle sorun yaratmaz. Eğer bitmiş olan bir mini sistemde değişiklik isteniyor ise sadece küçük bir sistem içinde değişiklik yaparak bu işin üstesinden gelebiliriz. Böylece yazılımda köklü değişiklik yapma riskini alt seviyelere çekmiş olursunuz.

Şekil 1.2 Gereksinimler ile Iterasyonların İlişkisi

Örneğin, Şekil 1.2’de görüldüğü gibi, 6. gereksinimde olacak bir değişiklik diğer iterasyonları büyük ölçüde etkilemez. Sistem bitmiş bile olsa her değişim genellikle tek bir iterasyonu bağlar.

Iterasyonlar sonucu oluşan her mini sistem için geribildirim almak çok önemlidir. Bu eski yazılım geliştirme metodolojileri için büyük bir sorundu. Unified süreci sayesinde her mini sistem sonucunda kullanıcılar :

“ Sistemin şu bölümü içime sinmedi, şöyle olması gerekirdi.“

“ Ben böyle bir şey istemiştim ama isteğimi anlamamışsınız. “

“ Sistemde şu özellikler olması gerekirdi ama yok! “

gibi biçimlerde istek ve düşüncelerini dile getirebilirler. Dolayısıyla yazılım geliştiricilerin sorun fazla büyümeden, sorunu giderme ve dokumante etme şansları olur.

İlk başlarda sistem beklenenden uzak bir görüntü çizebilir fakat her iterasyon sonucu düzeltmelerle, son sistem beklentilerin tümünü karşılayan ve sorunsuz bir sistem halini alır.

Unified Süreci’nin Yararları

Yüksek risklerden daha erken kurtulunur. Yüksek riske sahip kısımlar daha erken gerçekleştirilir. İterasyonlar sonucu, çalışan sistemin ilk görüntüleri daha erken ortaya çıkar. Her mini sistem, son sistemin çalışan bir parçasıdır. Erken geribildirimler ve sistemin bu geribildirimler sonucu daha erken değiştirilmesi sonucu son sistem kullanıcı gereksinimlerini, bir çok yazılım geliştirme metodolojisinin olduğundan daha fazla karşılar. Karmaşıklık idare edilebilir. Sistem çok uzun ve karmaşık adımlar yerine daha kısa ve karmaşıklığı daha az adımlarla geliştirilir. Her iterasyondaki gelişim sonucu, metodolojiniz de gelişme gösterir. Iterasyon Uzunluğu ve Zaman Kutulama(Timeboxing)

Unified Süreci, her iterasyon uzunluğunun iki ila altı hafta arasında olmasını tavsiye eder. Kısa zamanlı adımlar, hızlı geribildirim ve adaptasyon Unified Süreci"nin temellerindendir. Uzun adımlar proje üzerindeki motivasyonu azalttığı gibi projenin tamamlanmama riskini de yükseltmiş olur.

   Iterasyonların üzerinde durduğu ana nokta ise zaman kutulama"dır (timeboxing). Yani her iterasyon önceden belirlenen zaman aralığında bitmek zorundadır. Mesela bir sonraki mini sistem üç hafta içinde bitecek diye kararlaştırılmışsa, o parça üç hafta içinde mutlaka bitmelidir. Eğer iterasyonun belirtilen zamanda (deadline) bitmeyeceği durumu ortaya çıkarsa yapılması gereken iş, süreyi uzatmak yerine bu iterasyondaki bazı parçaları bundan sonraki iterasyonlara aktarmaktır. Sonuçta, belirlenen deadline zamanı ne olursa olsun aşılamaz.

Unified Süreci ile Yazılım Geliştirirken Üzerinde Durulması Gereken Noktalar Yüksek riskli ve en önemli parçaları ilk olarak gerçekleştirin. Sistemin gelişimi, geri bildirimler ve gereksinimler konusunda sürekli olarak son kullanıcılarla beraber olun. Birleşik (cohesive) ve merkezdeki yapıları ilk iterasyonlarda gerçekleştirin. Kaliteyi sürekli kontrol edin, testleri anında yapın ve gerçekçi olun. Mutlaka use case"leri kullanın ve bunları uygulayın. Yazılımı sürekli olarak modelleyin (UML). Gereksinimlerin yönetimini çok dikkatli yapın.

Eğer yukarıdaki noktalara dikkat ederseniz geleceğe dönük başarılı bir proje yapmamanız için önemli bir sebep kalmayacaktır. Hangi yazılım sürecini uygularsanız uygulayın en önemli nokta ilgili sürecin kurallarını eksiksiz uygulamaktır. Çünkü yazılım süreçleri defalarca denenmiş başarılı projeler sonucu ortaya çıkmıştır. Sorunsuz günler dileğiyle..

Döküman Arama

Başlık :

Kapat