Application Lifecycle Management konusundaki yazılarımıza Yazılım Metodolojileri - II ile devam ediyoruz. Daha önce Application Lifecycle Management nedir? ve Yazılım Metodolojileri - I yazılarını yayınlamıştım. Şayet bu yazıları okumadıysanız öncelikle onları okumanızı tavsiye ederim.

Bu konudaki ilk yazımızda Waterfall ve Spiral modeli masaya yatırmıştık; ikinci yazımızda ise Rational Unified Process (RUP) metodolojisini inceleyeceğiz.

Rational Unified Process (RUP)

1980 yılında Rational Software çalışanları yeni bir yazılım metodolojisi arayışlarına girdi ve ilk olarak Spiral modeli kendilerine temel aldılar. Ancak tam olarak kafalarındaki sorulara cevap bulabilmiş değillerdi, "Neden yazılım projeleri başarısız oluyor?". Bu sorunun cevabını ararken altta yatan sebep olarak aşağıdaki semptomları belirlediler.

• Özel gereksinim yönetimi
• Komplekslik
• İletişim sorunları
• Gereksinimdeki, uyarlamadı ve tasarımdaki öngörülmemiş sorunlar
• Yetersiz test
• Proje durumuna objektif yaklaşım
• Kontrolsüz değişiklik yönetimi
• Yetersiz otomasyon

Yalnız Rational Software takımına göre sorun belirli bir semptomun varlığından değil, birden fazla semptomun bir arada bulunmasından kaynaklanıyordu. Buna sebep olarakta, her projenin kendine has bir yapısı olduğu ve standart bir metodolojinin uygulanması bazen projenin karakteristiklerine uymadığı için başarsızlıkla sonuçlanıyordu. Dolayısı ile Rational Software takımı Rational Unified Process (aka RUP) adını verdikleri bazı prensipler (best practices) belirlediler.

RUP'un Waterfall ve Spiral'e göre farkı, RUP size baştan sona ne yapacağınızı dayatmaz. Siz RUP'un prensiplerini istediklerinizi kendi projenize uygulayarak yazılım sürecinizi yönetirsiniz.

RUP'un Prensipleri

1. Süreci uyarlayın (Adapt the process): RUP ruhu gereği firma projenin karakteristiklerine göre (Yönetim, proje büyüklüğü, önemi, vs) RUP'un gereksinimlerini seçer ve uygularlar. RUP'un küçük, orta boy ve büyük projeler için hazır şemaları bulunmaktadır.
2. Paydaşların önceliklerini göz önünde bulundurun (Balance stakeholder priorities): Bir projeye başlamanın temel sebebi olan paydaşların istekleri ile iş hedefleri çoğu zaman çakışabilir. Bunlar arasındaki dengenin iyi planlanması gerekiyor.
3. Takımlar arası ilişkileri düzenleyin (Collaborate across teams): Takdir edersiniz ki çoğu zaman yazılım işi bir takım çalışması ile yapılıyor; ancak burada takımdan kasıt sadece kod yazan yazılımcılar değildir. Test ekibi, analiz ekibi, müşteri gibi bu projenin dokunduğu herkes bu takımın bir üyesi sayılır. Dolayısı ile örneğin genel kanının aksine müşteriniz ile sadece gereksinim analizi aşamasında iletişim kurup sonrasında iletişimi koparmak doğru değildir. Ne yazık ki bizde müşteri ile iş bitene kadar mümkün olduğunca az iletişim kurmak fikri hakimdir; oysaki müşteri ile test sonuçları, proje durumu veya mimarisel bilgilerde paylaşılmalı ki erken geri bildirimler ile ileride sorun oluşturabilecek durumların önüne geçilebilsin.
4. İteratif çalışmanın değerini gösterin (Demonstrate value iteratively): Waterfall modelinin yapısı gereği süreçler arasında geriye doğru hareket edilemiyor; bu da müşteri geri bildirimi veya değişiklik isteklerinin herşey bittikten sonra alınması anlamına geliyor. Oysaki Spiral gibi iteratif modelerde her iterasyonun sonunda müşteri de dahil olmak üzere tüm paydaşlardan alınan geri bildirimler bir sonraki iterasyonun girdisi oluyor. Bu da amaçlanan sonuca daha kesin şekilde ulaşmayı sağlıyor.
5. Soyutlama seviyesini yükseltin (Elevate the level of abstraction): RUP yazılım ekiplerini soyutlama seviyesinin yükseltimesi için destekler. Bunun anlamı yazılım desenleri, tekrar kullanılabilir bileşenler ve frameworkler kullanılması anlamına gelir. Bu ise yazılımcının bir ihtiyacı karşılamak için herşeyi baştan yapmasını engelleyerek bir nevi Amerika'nın tekrar keşfedilmesini engeller.
6. Devamlı kaliteye odaklanın (Focus continuously on quality): Ne yazık ki kalite yazılım projelerinde ciddi bir sorundur. Bir çok yönetici için kalite uygulamaları sadece zaman kaybıdır. Önemli olan işin yapılması ve paranın alınmasıdır. Oysa ki kaliteye odaklanmak, süreçlerin doğru yürütülmesini, testlerin üzerine düşülmesini sağlayacaktır. Ayrıca kaliteli bir uygulama geliştirmenin neresi kötü olabilir ki?

Şayet dikkat edecek olursanız, prensiplerin orjinal isimlerinin ilk harfleri RUP'un ABC'sini oluşturuyor.

• Adapt the process
• Balance stakeholder priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

RUP Yaşam Döngüsü

RUP'un yaşam döngüsü, 4 aşamadan oluşur; bunlar aşağıdaki gibidir.

1. Başlangıç
2. Detaylandırma
3. İnşa
4. Geçiş

Yukarıdaki şekilde RUP'un yaşam döngüsü görülüyor. Kolonlar yukarıdaki aşamaları ifade ederken, satırlarda bulunanlar ise görevlerdir. Grafikteki şekiller ise hangi görevin hangi aşamada ağırlık kazandığı ve yürütüldüğünü ifade etmektedir.

Başlangıç Aşaması

Başlangıç aşaması, standart yazılım sürecindeki İhtiyacın Belirlenmesi,, Gereksinim analizi aşamalarına denk gelmektedir. Bu aşamanın Waterfall'da ki aşamalardan farkı, aşama bittiği zaman bir daha geri dönmemek üzere konuyu kapatmıyoruz. Bu aşama tüm proje boyunca bize temel oluşturan bir yol sunacak olan verilerin hazırlanmasını sağlıyor. Bu aşamanın geçilmesi için aşağıdaki kriterlerin sağlanması gerekmektedir.

• Müşteri ile kapsam ve maliyet/zaman hesaplamalarında hem fikir olmak/li>
• Takım gerekli ihtiyaçların alındığı konusunda hem fikir ve gereksinimlerden herkes aynı şeyi anlıyor
• Takım, maliyet/zaman hesapları, öncelikler, riskler ve geliştirme sürecinin uygunluğu konularında hem fikir
• Tüm riskler tanımlanmış ve her biri için çözüm stratejisi mevcut.

ŞŞayet bu kriterler sağlanmıyorsa ya proje iptal edilir ya da süreç tekrarlanır.

Detaylandırma Aşaması

Bu aşamada projenin neye benzeyeceği ortaya çıkar. Bu aşamada tasarım ve analiz (Teknik Çözüm) büyük bir efor tutmaktadır; ancak sonraki aşamalara devam etmek için bu efora katlanılması gerekmektedir. Ayrıca bu aşamada uyarlama safhası, kodun nasıl yazılacağı da belirlenir. Use-case diyagramları da bu aşama da hazırlanır. Bu aşamayı geçebilmek için aşağıdaki kriterleri sağlamak gerekmektedir.

• Projenin vizyonu kararlı mı?
• Mimari tasarım kararlı mı?
• Ciddi riskler belirlenmiş mi ve çözülmüş mü?
• İnşa aşaması için plan yeterince detaylandırılmış mı?
• Paydaşlar, mevcut vizyonun uygulanabilir olduğu konusunda hem fikir mi?
• Mevcut kaynak harcamaları ve planlanan kaynak harcamaları kabul edilebilir mi?

Şayet bu kriterlerde sağlanmazsa Başlangıç Aşamasında olduğu gibi proje iptal edilebilir veya süreç tekrarlanabilir. Unutulmaması gereken bu aşama, inşa aşaması öncesindeki son aşamadır. Şayet bu aşama düzgün bir şekilde yürütülmezse sonraki aşamalarda ortaya çıkacak sorunları çözmek daha maliyetli olacaktır.

İnşa Aşaması

Başlangıç aşaması ve detaylandırma aşamasından sonra inşa aşamasına geçilir. Bu aşama artık oluşturulan mimari çözümün hayata geçirildiği yani kodlamanın yapıldığı aşamadır. Bu aşama Spiral modelde olduğu gibi iteratif bir yapıda yürütülür. Böylece her iterasyon sonunda müşteriden alınacak olan geri bildirimler ile bir sonraki iterasyonda daha kaliteli bir prototipin ortaya çıkması sağlanır. Bu aşamada use-case diyagramları önceliklendirilir ve iterasyonlara paylaştırılır. Yüksek risk ve önceliğe sahip iterasyonların öncelikle ele alınması daha iyi olacaktır.

Bu aşamanın geçilmesi için aşağıdaki kriterlerin sağlanması gerekmektedir.

• Ürün nihai sürümü yayınlamak için yeterince kararlı ve olgun mu?
• Müşteri kullanıcılarını bu sisteme geçirmek için hazır mı?
• Mevcut kaynak harcamaları ve planlanan kaynak harcamaları hala kabul edilebilir mi?

Geçiş Aşaması

Başlangıç, detaylandırma ve inşa aşamalarını tamamladıktan sonra geçiş aşamasına geçilir. Bu aşama inşa aşamasında olduğu gibi iteratif şekilde yürütülür. Öncelikle kullanıcılara yeni sistem hakkında eğitimler verilir; daha sonra beta testleri yapılır. Beta testlerinde ki amaç, müşteri isteklerini hala karşılayıp karşılamadığını görmektir; çoğu zaman son kullanıcıların karşısına çıkan bir sistem daha önce hiç öngörülmemiş ihtiyaçların ortaya çıkmasına sebep olabilir.

Şayet müşteri ihtiyaçlarını karşılamada sorunlar varsa iterasyonlar tekrarlanır ve değişiklik yönetimi süreci uygulanır.

Bu aşamanın tamamlanması için aşağıdaki kriterlerin sağlanması gerekir.

• Müşteri ihtiyaçları karşılandı mı? / Müşteri tatmin oldu mu?
• Mevcut kaynak harcamaları ve planlanan kaynak harcamaları hala kabul edilebilir mi?

RUP Disiplinleri

RUP ile yazılım geliştirirken görevlerimizi kategorilendirmek için kullanılan dokuz adet disiplin bulunmaktadır. Bunlardan altı tanesi mühendislik disiplinleri, üç tanesi destekleyici disiplinlerdir.

İş Modelleme Disiplini

İlk olarak iş modelleme disiplini gelir. İş modelleme disiplinin amacı iş ve yazılım mühendisliği arasındaki anlayış farklını gidermektir. Böylece uygulama geliştirilirken, işin önemi ve vizyonu takıma daha iyi aktarılır; bu da amacına daha uygun bir ürünün ortaya çıkmasını sağlar.

Gereksinim Disiplini

Bu disiplin sürekli bahsedilen gereksinim analizine karşılık gelmektedir. Amaç, müşteri ve yazılım ekibinin aynı şeyi hedefliyor olmasını sağlamaktır.

Analiz ve Tasarım Disiplini

Bu disiplin teknik çözüm sürecine karşılık gelmektedir.

Uyarlama Disiplini

Bu disiplin hazır bileşenler, dış sistemler veya farklı ekiplerce yazılan yazılım parçalarının bir araya getirilmesi ifade eder. RUP'un, hazır bileşenlerin kullanılmasını desteklediğini daha önce belirtmiştik; hatta hazır bileşenlerin yanında daha önceki projeler için oluşturulan kodlarında bileşen haline getirilip tekrar kullanılmasını da destekler.

Test Disiplini

Test disiplinin temel amacı hataları en erken aşamada bulmak ve düzeltmektir.Test disiplini RUP'a göre tüm yazılım sürecinin bir parçasıdır. Bu disiplinin diğer amaçları da aşağıdaki gibidir,

• Nesneler arasındaki etkileşimin doğrulanması
• Tüm bileşenlerin doğrulanması
• Tüm hataların bulunduğundan, düzeltildiğinden, tekrar test edidiğinden ve kapatıldığından emin olunması
• Sorunların tanımlanması

Canlıya Alma Disiplini

Canlıya alma disiplini, canlıya alma aşamasının daha yazılım sürecinin en başından planlanmasını hedefler. Genelde bu işlem inşa ve geçiş aşamalarında planlanıyor olsa da, en doğrusu teknik çözüm süreci içerisinde tanımlanmasıdır. Çünkü bazen canlıya alma işlemi, teknik çözüme aykırı durumların ortaya çıkmasına sebep olabilir.

Konfigürasyon ve Değişiklik Yönetimi Disiplini

Değişiklik yönetimi, uygulama geliştirmenin önemle ele alınması bir konudur.

Proje Yönetimi Disiplini

Proje yönetimi, aşamaların planması, iteratif aşamalarda kaç iterasyon gerekeceğinin planları ve projenin risklerini yönetir. RUP dışında proje yönetimi genelde insan kaynağı, bütçe ve sözleşme yönetimini de yapar; ancak RUP'ta bu işlemler proje yönetimi disiplinine dahil değildir.

Ortam Disiplini

Ortam disiplininde konu olan yazılım ortamı değil,  projeyi yürütmek için kullanılan araçlar proje ortamıdır.

RUP ile ilgili bu yazıda anlatacaklarımız bu kadar. Son zamanlarda yerini güncel metodolojilere bırakmış olsa da uzun süre birçok firma da kullanıldı. Ancak uyarlamanın bazen zor olması sebebi ile her firmanın uygulayabildiğini söylemek zor.

Daha detaylı bilgi için Wikipedia'nın IBM Relational Unified Process sayfasına bakabilirsiniz.

Bu yazıda da kaynak olarak ağırlıklı olarak Joachim Rossberg'in Pro Visual Studio Team System Application Lifecycle Management kitabından faydalanılmıştır.

Application Lifecycle Management alm, application lifecycle management, rational unified process, rup, yazılım metodolojileri