Bu
yazımda sizlere; son dönemlerin popüler yazılım geliştirme süreçlerinden olan
"Rational Birleştirilmiş Süreç" (Rational Unified Process)
ve "Uç Programlama" (Extreme Programming)
konularını açıklayarak projeniz için uygun olan süreci belirlemede yol göstermeye
çalışacağım. Bu kapsamda; iki sürecin benzerliklerini, farklılıklarını ele
alarak uç programlamanın avantajlı yöntemlerini RUP içinde nasıl kullanabileceğimizi
açıklayacağım. İki sürecin birlikte kullanıldığı "Uç
RUP" (Extreme RUP) süreci de yazının ilerleyen bölümlerinde incelenecektir.
Süreçlerin
tam olarak tanımlı olmadığı durumda, yazılım geliştiren ekip üyelerinin birbirleri
arasında farklı şekilde konuşmaya başlayacağı açık bir gerçektir. Organizasyonlar,
sahip oldukları kaynaklara bağlı olarak hedefleri ve deneyimlerini göz önünde
bulundurarak projelerinde kullanacakları süreçleri belirlemelidirler.
Rational
Birleştirilmiş Süreç (RUP)
Rational
firması tarafından geliştirilen RUP, organizasyon
içindeki sorumlulukları detaylı olarak belirleyerek disiplinli bir yazılım
geliştirme süreci sunar. Yazılım geliştirme sürecinin her aşamasında kullanılabilecek
tümleşik araçları, hazır belge şablonları sayesinde proje ekibinin üretkenliğini
arttırmaktadır. RUP içinde aktivite gruplarına disiplin
adı verilmektedir. Gereksinimler, analiz, tasarım, gerçekleme,
test temel disiplinlere örnek olarak verilebilir. RUP
içinde yazılım yaşam çevrimi 4 aşamadan oluşmaktadır.
Başlangıç
(Inception),
Düzenleme (Elaboration),
Oluşturma (construction) ve Geçiş
(transition). Her aşama bir durak noktası ile sonlanmakta ve her aşama sonunda
bir değerlendirme yapılarak amaçlara ne oranda ulaşıldığı incelenmektedir.
Orta ölçekli bir proje için; proje takviminin %10’unun
Başlangıç
aşamasında, %30’unun
Düzenleme, %50’sinin
Oluşturma
ve geri kalan %10’unun
Geçiş aşamasında kullanıldığı söylenebilir.
Bu aşamaları iki durak noktası arasındaki yazılım geliştirme etkinlikleri
olarak ifade etmek de mümkündür. Bu durak noktalarını sırası ile; amaç, mimari,
operasyonel yetenek ve ürün teslimi olarak sıralayabiliriz.
Başlangıç aşamasında; yaklaşık tahminler yapılarak temel gereksinimler ortaya
konulmaya çalışılır. 2.aşamada daha gerçekçi tahminler yapılarak mimari belirlenir
ve yüksek riskler için çözümler sunulur. 3. aşamada, ürün hazır hale getirilerek
hatalar belirlenir. 4.aşama ise müşteriye ürünün teslim edildiği ve müşteriden
gelen geri beslemeye göre iyileştirmelerin yapıldığı aşamadır.
Dikkat
edilmesi gereken önemli bir nokta; RUP içindeki
her aşamada yazılım mühendisliğinin tüm aktivitelerinin farklı oranlarda uygulanıyor
olmasıdır. Klasik yazılım geliştirme süreci olan çağlayan
(waterfall) modelinde ise bildiğiniz gibi, her aktivite bir önceki aktivitenin
bitmesinin ardından gerçekleştirilmektedir. Çağlayan modelinde kodlama aktivitesi,
tasarımın ardından gerçekleştirilirken; RUP içinde her aşamada kodlama yapılabilmektedir.
RUP sürecindeki aşamaların amaçlarını öğrendiğimiz için her aşama sonunda
oluşturmamız gereken çıktıları sıralayabiliriz.
Başlangıç
aşaması sonunda; vizyon belgesi, kullanım senaryoları
(use case, %10-%20 oranında), proje sözlüğü, prototipler, risk yönetimi ve
tahmini, maliyet fayda analizi, özyineleme planı, finansal tahmin ve başarı
kriteri, aşama ve özyinelemeleri gösteren proje planı oluşturulmuş olmalıdır.
Düzenleme aşamasının bitişi ile birlikte; kullanım
senaryolarının ve aktörlerin yer aldığı model (%80 oranında), tasarım modeli,
yazılım mimari tanımı, veri-gerçekleme-test modelleri, yeniden düzenlenmiş
risk listesi, kullanıcı arayüz prototipleri ve yazılım geliştirme planının
hazırlanmış olması gerekmektedir.Oluşturma aşaması
sonunda; kaynak kod, birim testleri, test senaryoları, test kodları, son kullanıcıya
verilecek ürün, kullanıcı belgeleri oluşturulması beklenmektedir. Son aşama
olan Geçiş aşamasının bitiminde; müşteri memnuniyeti
saptanmalı ve gereksinimlerinin ne ölçüde karşılandığı, planlamaların başarılı
olup olmadığı analiz edilmelidir.
Her
aşama sonunda hazırlanması gereken belgeleri ve süreçler içerisindeki geliştiricilerin
rollerindeki fazlalığı düşündüğünüz zaman RUP’un sadece çok büyük ölçekli
firmalara özgü olduğu sonucuna varabilirsiniz. Ancak; gözden kaçırılmaması
gereken önemli bir nokta da RUP’un değişikliğe izin veren bir mimarisinin
olmasıdır. Organizasyonunuz için gerekli rolleri, aşamaları tanımlayarak kendi
birleştirilmiş sürecinizi oluşturmanız mümkündür. Nitekim; 31.Mart.2004 tarihinde
Yıldız Teknik Üniversitesi Oditoryumunda düzenlenen
"Bilişimde Proje Yönetim Paneli" ’nde
Turkcell firması yetkilileri RUP’u kendilerine özgü olarak düzenlediklerini
ve bu süreci TUP (Turkcell Unified Process) olarak adlandırdıklarını ifade
etmiştirler.
Uç
Programlama (Extreme Programming-XP)
Yapılan
çalışmalarda, yazılım projelerinin %70 oranında başarısızlıkla sonuçladığı
bilinmektedir. Başarısızlığın temel nedenleri; gereksinim analizinin doğru
yapılmaması, değişim yönetimindeki hatalar, iletişimin etkin olarak gerçekleştirilmemesi
olarak sıralanabilir. Bu eksikliği düşünerek; gereksinimlerin sürekli olarak
değişebilmesine olanak veren, çalışanlar arasında iletişimi arttıran Uç
Programlama (XP) yöntemi ortaya konulmuştur.
Uç programlamada; basitlik, cesaret, geri besleme, iletişim en önemli değerlerdendir.
Planlama, kodlama, tasarım, test aşamaları da XP içinde de yer almaktadır.
Son
yıllarda oldukça popüler olan XP konusunda maalesef yanlış bilgiler mevcuttur.
Tasarım içermediği, deneyimli olmayanlar için uygun olduğu, "ikili
programlamanın"(pair programming) verimsiz
olduğu, uygulanan testlerin hataları tespit edemediği bilgileri tamamen yanlış
varsayımlardır. Organizasyonunuz içindeki mevcut sürecinizden memnunsanız,
süreç iyileştirmeye ihtiyaç duymuyorsanız, projeleriniz statik gereksinimler
içeriyorsa, çalışma ortamınız ikili programlamaya uygun değilse uç programlamaya
da ihtiyaç duymuyorsunuz demektir. Aksi durumda; XP süreci içindeki avantajlı
yöntemleri denemenizde fayda vardır.
Uç
programlama kullanmanın farklı nedenleri olabilmektedir. Doğru olan, projenin
başında uç programlamayı benimsemektir. Projenin başında klasik yazılım geliştirme
süreci ile başlayıp, proje takviminin kısalması sonucu uç programlamaya geçmeye
çalışanların başarılı olması mümkün değildir. Önemli olan uç programlamayı
disiplin olarak benimsemek ve tüm yazılım yaşam döngüsü boyunca kullanmaktır.
Yoksa geciken projelerinize, sihirbaz etkisi yapması mümkün değildir.
Karşılaştırma
İki
sürecin öncelikle benzerlikleri açıklanacak ardından farklılıkları ortaya
konulacaktır.
Bu
süreçlerin ortaya çıkmasındaki temel nedenlerin farklı olmasına rağmen bazı
benzerlikler mevcuttur ve aşağıda sıralanmaktadır:
1-)
Özyineleme kullanımı: İki süreçte de özyineleme mevcut olup süreleri
farklıdır.
2-)
Nesne teknolojisi: İkisi de temel olarak nesne teknolojisi üzerine
kurulmuştur ancak kullanılan teknolojiye tam bağımlı değillerdir.
3-)
Değişim: Devam eden değişim, sürecin bir parçası olarak düşünülür.
4-)
Kullanım senaryoları: XP içindeki kullanım öyküleri, RUP içindeki
kullanım senaryolarına benzemektedir.
5-)
Risk önceliklendirme: Kritik riskler belirlenerek çözümler ortaya
konulur.
6-)Gereksinim
önceliklendirme: Gereksinimlerden hangisinin önce gerçeklenmesi gerektiğine
karar verilir.
7-)
Otomatik testler: Hazır araçlarla otomatik testler yapılmasına izin
verirler.
8-)
RUP’un başlangıç fazı, XP’deki kullanıcı öykülerinin oluşturulması aşamasına
benzemektedir.
9-)
RUP’un düzenleme fazı, XP’deki “Oyunu Planlama”
fazına benzemektedir.
10-)
Basitlik: Planlama konusunda ilk aşamada detaya inmezler.
İki
sürecin farklılıkları aşağıda sıralanmaktadır. Bu farklılıkları belirleyerek,
iki süreç üzerinde derinlemesine bilgi sahibi olmamız mümkündür. Ayrıca; iki
yöntemden birini tercih edeceğimiz durumlarda bu farklılıklar yol gösterici
olacaktır.
1-)
RUP, daha çok büyük ölçekli projelerde tercih edilmektedir.
2-)
RUP, değişiklik maliyetinin üstel olarak arttığını varsaymaktadır. Bu nedenle
risk azaltma konusu ile çok fazla ilgilenmektedir. Uç programlama ise, geliştirme
aşamasında değişiklik maliyetinin düşük olduğunu varsayar. Bu nedenle mimarinin
zamanla olgunlaşmasına izin verir.
3-)
İkili programlama kavramı RUP içinde yer almaz.
4-)
RUP’un uygulandığı projelerde, ekipler daha fazla eleman içerir.
5-)
XP’de daha fazla özyineleme vardır ve özyineleme süreleri daha kısadır.
6-)
XP, RUP içindeki tüm disiplinleri içermez.
7-)
RUP çok seçimli bir süreç sunarken XP’de seçenekler mevcut değildir.
8-)
XP’de çalışanların sorumlulukları daha fazladır.
9-)
XP’deki roller; Programcı, Müşteri, Koç ve Yöneticidir. Programcı ve müşteriler
RUP içinde de bulunur. Koç kavramına en yakın rol tasarımcı, yönetici kavramına
en yakın rol ise Proje Lideri’dir. RUP içinde bu rollerin dışında birçok rol
tanımlıdır.
10-)
XP’de geliştirilen kod üzerinde ortaklaşa sahiplik söz konusudur. Herhangi
bir anda ihtiyaç duyan, kodun bir parçasını değiştirebilir. RUP’da ise herkes
rolünün gereğini yapması gerekir.
11-)
RUP, uç programlamaya göre mimariye daha fazla önem verir.
12-)
XP, bir doküman kullanılmıyorsa defalarca güncellenmesini istemez. Ayrıca,
çok fazla sayıda belge oluşturmanın faydasına inanmaz. RUP ise tasarımın sürekli
güncel olmasını ister. XP’de yazılan belge yerine kodun etkin olarak çalışmasını
arzular.
13-)
RUP’daki bazı sorumluluklar XP içinde bulunmayabilir çünkü ilgili aktivite
XP içinde yer almıyor olabilir.
Uç
programlama ile RUP birlikte kullanılabilir mi?
RUP
genel olarak büyük projelerde kullanılırken, uç programlama daha küçük projelerde
kullanılmaktadır. Ancak; uç programlamanın birçok aktivitesi oldukça faydalı
yazılım mühendisliği uygulamaları içermektedir. Bu nedenle, XP’yi bir RUP
projesi içinde daha küçük çalışma gruplarınca uygulayabiliriz. Hibrid yaklaşım
olarak tanımlanabilecek olan bu sürece, "Uç RUP"
(Extreme RUP) adı verilmektedir.
Gereksinim
aşamasında, SIStems kavramı kullanılmaktadır. SIStems, birbirine bağlı sistemlerden
oluşan bir sistem olarak düşünülür. Büyük sistemler modellenirken, özellikle
dağıtık sistemler, SIStems kavramı çok yararlıdır. SIStems’e farklı detay
seviyelerinde bakılabilir. Birincil seviyede, sistem bütün olarak düşünülürken
ikincil seviyede alt sistemlerin etkileşimi düşünülür. Gereksinim analizinde,
müşteri ile çalışarak birincil kullanım senaryoları belirlenir. İkincil seviyede,
gereksinimleri hazırlayan proje elemanları müşteri gibi çalışır ve kullanım
öyküleri oluşturur. Birincil kullanım senaryoları RUP’un başlangıç aşamasında
tanımlanabilir.
Tasarım aşamasında, sistem seviyesinde bir mimari ve tasarımı oluşturulabilir.
Detaylı tasarım XP ile yapılabilir. Sistem mimarisi temel olarak, “Düzenleme”
fazında belirlenebilir. Test aşamasında, birim testleri XP ile yapılabilir.
RUP’un önerdiği şekilde test takımı kurulabilir. Fonksiyonel ve fonksiyonel
olmayan testler alt sistem ve sistem seviyesinde yapılabilir. Geliştirme
aşamasında; ikili programlama, ortaklaşa sahiplik, sürekli tümleştirme her
alt grup tarafından kullanılabilir. Bu şekilde, XP ve RUP’un birlikte kullanımı
dağıtık sistemler gibi karmaşık sistemleri geliştirirken uygulanabilir.
Sonuç
Bu
yazıda, RUP ve uç programlama süreçleri incelenerek aralarındaki benzerlikler,
farklılıklar ortaya konulmuştur. İki sürecin birlikte kullanılması durumunda,
ortaya çıkan model açıklanmıştır.
Yazılım geliştirme grubunun büyük olduğu, uzun soluklu projelerde RUP’un,
daha küçük projelerde ise uç programlamanın tercih edilmesi gerektiği söylenebilir.
RUP’un çalıştığınız organizasyon için çok detaylı olduğunu düşünüyorsanız
kendi organizasyonunuza uygun bir süreci RUP’u kullanarak oluşturmanız mümkündür.
Bir
sonraki yazıda görüşmek üzere.
Çağatay
ÇATAL
[email protected]
Referanslar:
1. Kruchten, P.: The Rational Unified Process – An Introduction. Addison Wesley
Longmann (2000)
2. Probasco, L.: The Ten Essentials of RUP. The Rational Edge (2000)
3. Beck, K.: Extreme Programming Explained. Addison Wesley (2000)
4. Smith, J.: A Comparison of RUP and XP. Rational Unified White Paper (2001)
5. Beck, K., Fowler, M..: Planning Extreme Programming. Addison Wesley (2001)
6. Fowler, M.: Refactoring. Addison Wesley (1999)
7. Martin, R.: RUP/XP Guidelines. Rational Unified White Paper (2000)
8. Kuntzmann, A., Kruchten, P.: The Rational Unified Process. Rational Unified
White Paper (2001)