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)