Hemen hemen tüm mühendislik alanlarında bir işi yapabilmenin yöntemi ve süreci tanımlanmıştır. Ama yazılım mühendisliği alanında henüz böyle standart bir yöntem yada süreç şart koşulmamıştır. Bu sebeple, bu alanda gerçekleşen yazılım ürünleri kişilere en uygun gelen geleneksel yöntem olan, “önce kodla; sonra modelle” süreci kullanılarak gerçekleştirilmiştir.

Bu yöntemin kolay olması avantajının yanında, önceden sorunları görememesi ve oluşan ürünün en sonunda kullanılmaz bir hal alması dezavantajını da beraberinde getirmektedir. Bu da sonuç olarak, başarısızlık, para ve zaman kaybı demektir. 
Yazılımların başarısız olma sebepleri bir çoktur. Bunlardan bazıları:

• İyi tanımlanmamış istekler ve yönetme metodları.
• Muğlak ve etkisiz haberleşme.
• Zayıf ve dayanıksız mimariler.
• Çok karmaşa. (süreç, doküman, istek, teknoloji karmaşıklıkları)
• İstek toplama, tasarım ve gerçekleştirme safhalarında fark edilmemiş tutarsızlıklar.
• Yetersiz test.
• Proje planındaki gerçekçi olmayan varsayımlar.
• Riskleri önceden saptayıp onlar için yeterince erken önlem alamama.
• Yetersiz otomasyon. (elle yapılan işerin uzun zaman alması)
• Çok fazla analiz ve tasarım sonucu yazılımları gerçekleştirebilmek için yeterli zaman kalmayışı.
• Teknolojiyi yeterli derecede bilmemek.
• Müşterinin ne istediğini tam bilmemesi ve projenin arkasında durmaması.
• Plansızlık ve amatör yazılım teknikleri.

Kısacası, yazılımlardaki başarısızlık acele etmek, amatörce davranmak, teknolojiyi bilmemek, işini iyi yapmaya özen göstermemek ya da dozu kaçırarak işi karmaşık hale getirmekten kaynaklanmaktadır. Bunlar gözle görülen sebepler olmakla birlikte bir de gözle görülemeyen sebepler olan yazılımcıların işini sevmemesi, konsantre olamamak, yanlış yönlendirilmek gibi bir takım psikolojik ve yönetimsel sorunlar olabilir. Bu yazımızın amacı bunlarla çözüm aramak değildir...

{mosimage}

Teknoloji ile alakalı olanlar hariç, diğer tüm başarız olma sebepleri bir plan ve program içersinde profesyonelce davranamayarak, yazılım adımlarını ve müşteriyi organize edememeden kaynaklanmaktadır.

Bu noktada planlı ve programlı davranarak, ne yaptığımızı bildiğimizi karşımızdakilere ve kendimize kabul ettirebilmek için mantıklı, basit, standartlaşmış bir sürece ihtiyaç duyulmaktadır. Çünkü yapılan iş karmaşıktır. İş operasyonlarının ve bunla alakalı yazılım çözümlerinin karmaşıklığı arttıkça, bu kuralları ve istekleri toplayacak ve bunları yazılım çözümüne dönüştürecek bir yöntem yada süreçe ihtiyaç vardır. Değişim vazgeçilmez olduğu için bu sürecin esnek olabilmesi gerekir.

Yukarıda değinmeye çalıştığımız sorunları aşmak amacıyla, IBM Rational çalışanları bir çok başarısız yazılımda ki bu özellikleri görüp; başarılı yazılım oluşturmak için gerekli adımları saptayarak Rational Unified Process (RUP) adlı süreci oluşmuştur.

RUP, anlamsal olarak yazılım mühendislik süreci olup şirketlere yazılım geliştirme aşamasında bir yön sağlayan; use-case ve nesne teknolojileri tabanlı; tekrarlanan (iterative) yazılım geliştirme ve iş modelleme yöntemidir. RUP, sabit tanımlı bir süreç değildir. Aksine bu süreçleri bir çatı (framework) olarak sunarak, firmaların bu çatı içerisinden kendi isteklerine uygun bir süreç belirlemesine olanak tanır ve böylece her işletmenin ihtiyacına adapte olabilir.

Böyle bir sürecin bize verecekleri arasında bizi ve müşteriyi organize edebilmesi, standart tanımlı adımları olması, oluşacak yazılımdaki sık değişiklikleri öngörebilmesi, basit olması ve proje yönetim aktivitelerinin çok fazla olmaması gibi özellikler olmalıdır.

RUP Mimarisi

Bu süreç normal bir yazılım ürünü gibi tasarlanmıştır. Temelinde UML ile belirtilen nesne modellemesi ile iki boyuta sahiptir:

Yatay süreç zamanı irdeler. Projenin ilerlemesini zaman açısından değerlendirir.

Dikey boyut ise mantıksal olarak yazılım mühendisliği aktivitelerini gruplayan ana disiplinleri tanımlar.

{mosimage}

RUP’un faz ve  2 boyutlu  katman mimarisi

Yatay boyut dinamik bir bakış açısı ile döngüleri, tekrarlamaları, fazları ve mihenk taşlarını tanımlar. RUP ile yazılım artarak tekrarlanan aktiviteler ile yapılır. Bu nedenle test onaylama, tasarım fikirleri, riskleri yumuşatma daha başlarda ortaya çıkar.

Dikey boyut statik görünüşü oluşturan süreç bileşenlerini temsil eder. Süreç bileşenleri ise aktiviteler (activities), disiplinler, eserler (artifact) ve roller den oluşur.

RUP süreci 4 faz’da tanımlanmıştır.

1. Başlama (Inception) fazı
2. Olgunlaşma (Eleboration) fazı
3. Yapım (Construction) fazı
4. Geçiş (Transistion) fazı

Her faz tanımlanmış ve tekrarlanan işlemler içermektedir (iteration). Tekrarlanan işlemler belirli bir bitirme süresi içerir (deadline). Fazlar ise birer amacı gerçekleştirmeyi içerir(objective).

Başlama Fazı (Inception)

Bu fazda yapılacak iş çözümünün ne olduğu, neyi gerçekleştirmek istediği, beklenen yararlar, gerçekleştirme fiyatı, iş yerinin o andaki durumu ile olmak istediği yer hakkındaki analiz, beklenen riskler, yazılım çözümünden beklenen faydalar ve karlar– ki tüm bunlara “business case” denir – gibi aktiviteler gerçekleşir.

Bu fazda ki tekrarlamalar sonucu üretilebilecek bazı dokümanlar şunlardır:

• Projenin “business-case” olarak tanımlı oluşu.
• Ana use-case lerin tanımlanıp, isteklerin iyi anlaşılması.
• Kabaca yazılım mimarisi.
• Basit bir proje planı.

Faz sonunda aşağıdaki kriterler sağlanmalıdır:

• Yapılacak işin ihtiyaçları nelerdir ve bu ihtiyaçlar nasıl karşılanacak. 
• Tekrarlamaların sayısı ve zamanı. 
• Kabaca bir mimari.

Bu kriterler karşılanmadan sonraki faz olan olgunlaşma fazına geçiş olmaz. Eğer bu kriterler sonucunda yeterli olunmadığına karar verilirse, eksik kısımlar giderilmeli yada tüm bunlar anlamlı bir sonuç verinceye kadar beklenilmelidir.

Olgunlaşma Fazı (Elaboration)

Bu fazda proje oluşmaya, saha analizi ile temel yazılım mimarisi ortaya çıkmaya başlar.

Bu fazda ki tekrarlamalar ile:

• Çözülecek problemin anlaşılması.
• Yazılımın mimarisinin belirlenmesi
• Sonraki tekrarlamalar için detaylı plan.
• Yüksek riskleri ortadan kaldırma.

aktiviteleri gerçekleşmelidir.

Bu faz sırasında işin sahipleri proje planında bir ilerleme göreceklerdir.Faz sırasında tekrarlamalar sonucu üretilebilecek bazı dokümanlar şunlardır:

• Mimarinin prototip olarak çalışır halde bulunduğu yazılım sürümü.
• Birim testler ve test-case’ ler.
• Projenin çoğunluğunu oluşturan use-case ler.
• Sonraki tekrarlamaları belirten detaylı proje planı.

Faz sonunda aşağıdaki kriterler sağlanmalıdır:
Use-case modeli oluşturulmalı ve aktör’ler tanımlanmalıdır. Model %80 oluşturulmalıdır. 
Yazlımı mimarisi oluşturulmalıdır. 
Riskler ve çözüm yollarından bahsedilmelidir. 
Tüm proje için geliştirme planı hazır ve gerçekleştirilebilir olmalıdır.

Bu aşamadan sonra değişiklikler daha ağır ilerleyeceği ve birbirini etkiler olacağı düşünülür ise olgunlaşma fazında yapılacak iş iyice anlaşılmadan, iyi ve anlaşılır bir model ve mimari ortaya çıkmadan, riskler makul ve üstesinden gelinebilir hale gelmeden diğer faza geçilmemelidir.

Yapım fazı (Construction)

Bu fazda, kod geliştirme yapılarak çalışan bir sistem ortaya koyma gayreti içine girilir. Faz sırasında tekrarlamalar sonucu üretilebilecek bazı dokumanlar şunlardır:

• Yazılım
• Testler
• Kullanıcı dokümanı

Faz sonunda aşağıdaki kriterler sağlanmalıdır:

• Ürün kullanılabilir ve yeterli derecede sağlam olmalı.
• Ürün en azından yararlı sonuçlar ortaya koyabilir olmalıdır.

Eğer gerçekleşen proje ve riskler büyük ise bu aşamaya bir an önce gelmek yararlı olacaktır.

Geçiş fazı (Transition)

Bu fazda geliştirilen uygulama kullanıcıya ulaştırılır. Kullanıcı ya sistem hakkında bilgi, eğitim verilir. Sistem test edilmeye başlanılmalıdır. Ürün daha başlangıç fazında belirlenen kalite kriterlerine göre değerlendirmelidir.

Çalışan ürün ile beklenen ürün arasındaki farklılıklar giderilinceye kadar tüm bu fazlar baştan sona kadar tekrarlanır.

Faz sonunda aşağıdaki kriterler sağlanmalıdır:

Başlama fazında belirlenen objektiflerin sağlanmış olması.

Müşterinin memnun olması.

RUP en iyi yazılım geliştirme pratiklerini kapsar

1. Yazılımı tekrarlayarak geliştirme
2. İstekleri yönetme
3. Bileşen tabanlı mimari kullanma
4. Görsel olarak yazılım modelleme
5. Devamlı olarak yazılım kalite kontrolü
6. Yazılım değişimlerini kontrol edebilme

1. Yazılımı tekrarlayarak geliştirme: Bir çok yazılım geliştirme takımı, şelale (waterfall) modelini kullanarak istek analizi, tasarım, gerçekleştirme, test fazlarını birbiri arkasına getirerek tamamlar. Bu model de, bir aşama tam olarak bitmeden diğer aşamaya geçilmez ve bir aşama gerçekleşirken çalışanlar kendilerine sıranın gelmesini beklerler. Test ise en son aşamaya gelene kadar bekler.Bu noktadan sonra bulunan hatalar oldukça maliyetli olur ve tekrardan başa dönüp tamamıyle gerçekleşmiş bir sistemi radikal bir şekilde değiştirmeye yol açabilir. Bu tür olumsuzluklar projenin iptal edilmesine yada uzamasına sebebiyet verir. Örnek vermek gerekirse; diyelimki bilmediğimiz bir iş alanına giriyoruz ve bir çiçekçi dükkanı açıyoruz. Her türlü masraftan kaçınmayıp her çeşit çiçeği dükkanımıza getirip satmayımı deneriz yoksa az sayıda çiçek ile başlayıp müşterinin hangi çiçeklere talebi olduğunu saptadıktan sonra satılan çiçekleri almayımı tercih ederiz.

Ihtiyatlı olarak mı yazılımı gerçekleştirmeli yoksa her şeyi önceden saptayıp düşündüğümüzü ve karşılaşılabilecek riskleri tamamen önceden öngördüğümüzü sanarak mı yazılım gerçekleştirmeliyiz ? Eğer yazılım geliştirdiğimiz alanı bilmiyor isek ihtiyatla yaklaşmak ve yazılım çözümümünü adım adım gerçekleştirmek daha mantıklı olacaktır. Ama her adım gene planlanarak ve üzerinde çalışılarak atılmalıdır.

Tekrarlanabilir model ile sağlanan yararlar:

• İstekler değişir. Bu yazılımda karşılaşacağınız en garanti istekdir. Bunu algılayıp ona göre çözüm sağlamayı bilmek gerekir. Tekrarlanabilir model ile bu öngörülmüş olur. 
• Yazılım bileşenleri teker teker ve yavaş yavaş gerçekleşir. Böylece tüm bileşenlerin tek bir seferde birleşmesi ile sistem entegrasyon problemleri önceden saptanır. 
• Riskler gerçekçi olarak daha önceden saptanır ve önceden önlem almak mümkün olur. 
• Taktiksel değişimleri önceden yapmak daha kolay olur. 
• Yeniden kullanılabilirliği sağlar. Zamanla yazılan kod ile planlama safhasında görülemeyen yeni bileşenler saptanır.Böylece yazılım daha çok bileşenlerden oluşan bir yapıya dönüşür. 
• Yazılım geliştiricileri gözden geçirmeler sırasında karşılaşılan sorunlardan ve hatalardan ders çıkararak daha iyi kod yazmaya sevk edilmiş olurlar.
• Test yapan birimler önceden test etmeye başlayarak ortamlarını önceden, yavaş yavaş oluşturmaya başlarlar ve test planlarını yeni bulgulara göre güncellerler. 
• Her tekrarlama (iteration) dan sonra başarılı olan ve olmayan yöntemler saptanarak bir diğer tekrarlamanın daha iyi nasıl olabileceği saptanır ve hatta süreçler değiştirilir.

2. İstekleri yönetme: İstek yönetimi sistematik bir işlemdir.Değişen istekleri organize etme, iletme, yönetmeyi gerektirir. İstekleri yöneterek bazı yararlar sağlarız:

Projenin daha iyi kontrolü. Proje kapsamını, istekleri daha iyi kavrama ile gereksiz, yersiz istekleri ayıklama.

Gelişmiş yazılım kalitesi ve müşteri memnuniyeti. Bir yazılımın başarısının en önemli göstergesi müşterinin isteklerini karşılayıp karşılamadığıdır. Herkesin ortak noktada birleştiği istekler belirli olduğunda ve anlaşıldığında daha iyi yazılım ortaya çıkar.

Gelişmiş takım haberleşmesi.İyi tanımlanmış istekler ile müşteri, kullanıcılar, yöneticiler, tasarımcılar, yazılım geliştirenler ve test edenler arasında ortak kullanılan bir ortam oluşmuş olur.

RUP use-case tabanlı bir yaklaşım sunar. Bu yaklaşımda tanımlanan use-case ler geliştirme sürecinde bir temel teşkil ederler. Use-case ler iş modellemesinde kritik bir aşamadır.

3. Bileşen tabanlı mimari: Use-case ler tüm sürecin kaynağını oluşturur ama tasarım aktiviteleri mimari üzerine odaklanır. Daha projenin başlarında ilk odak noktası uygulanabilir bir yazılım mimarisi oluşturmaktır. Daha sonra bu mimari gelişerek son halini alır. RUP tasarlama, geliştirme ve onaylama aşamaları için sistematik sağlar.

RUP bileşen tabanlı yazılım geliştirmeyi çeşitli yollarla destekler :
Tekrarlanabilir yaklaşım ile yazılımcılar derece derece bileşenleri belirlerler ve hangilerini yazıp hangilerini hazır kullanabileceklerini bilirler. 
Yazılım tasarımı bileşenleri bulma ve onları birbirine entegre etme aktivitesi haline gelir. 
Bileşenleri organize etmek için paketler, alt sistemler, katmanlar gibi kavramlar oluşur. 
Bileşenler tek tek test edilebilir.

4. Görsel yazılım modelleme: Modelleme gerçeğin basitleştirilmiş halidir. Problemi ve çözümünü anlamaya yardımcı olurlar ve karmaşık, büyük sistemleri bir bütün olarak görüp algılayabilmemizi sağlarlar. RUP’un büyük bölümünde geliştirilecek sistem için modellemeler (Unified Modeling Language) ile yani bir görsel dil ile yapılır.Bu dil standart olduğu için dünya da herkesin anlayabileceği elementlere sahiptir.

5. Kalite kontrol: Kalite yanlızca bir kişinin katkısı ile sağlanan bir etkinlik olmayıp, her takım çalışanının sorumluluğudur. Yazılım geliştirmede kalite iki alanda yoğunlaşır. Ürün kalitesi, süreç kalitesi. 
Ürün kalitesi: Ürünü oluşturan tüm elementlerin kalitesi ile ilgilidir. (bileşenler, alt sistemler, mimari vb…) 
Süreç kalitesi: Üretim sırasında kabul edilmiş bir sürece bağlılık ile ilgilidir. Aynı zamanda süreç zarfında ortaya çıkan tekrarlama planlamaları, test planlamaları, use-case ler, nesne tasarımları gibi…

6. Değişiklikleri kontrol: Her yazılımın değişiklik isteklerini yönetebilecek bir yöntemi olması gerekir. Bu yönetim aynı zamanda hataları, kodları her tekrarlama sonrası elde edilerek çalışan sistem ile ilişkilendirilmesi gerekir.

Son söz
Tipik bir RUP projesi bir çok tekrarlamadan sonra meydana gelir. Bir projeyi tekrarlamalar halinde gerçekleştirmek belirli avantajlar sunar. Riskler yumuşar. Sistem parçalar halinde gerçekleşir. Kullanıcı ortamında çalışan test edilebilir ürün parçası erkenden oluşur ve böylelikle kullanıcı fikirleri erken gelmeye başlar. Her tekrarda öğrenilen dersler bir sonraki tekrarda yerini bulur. Önceden tahmin edilemeyen riskler erkenden kendini göstermeye başlar. Proje planı daha gerçekçi bir hal alır. Değişen yada eklenen istekler bu tekrarlanabilir süreçte gerçekleştirilir. Her değişen ve eklenen istek, baştan aşağıya tüm fazların gerçekleştirilmesini gerektirir.Kısaca RUP use-case sürümlü, UML ve mimari tabanlı, tekrarlanarak ve artarak gelişen, kontrollü bir süreçtir.

Referanslar :

IBM RUP 
http://www-06.ibm.com/software/awdtools/rup/

Rational Unified Process  5.5  Online Referance Kit.

RUP nedir ? http://www.webopedia.com/TERM/R/RUP.html