Kullanım şekilleri (durumları) üzerine IBM araçları (Use Case)

Rational Unified Process (RUP)

Yazılım geliştirme süreci özellikle son on yılda çok önemli gelişmeler gösterdi. Tabiki bu gelişme ve değişimde, gelişen teknolojinin, yaşamın her alanına giren yazılımların ve hızlanan dünyanın katkıları yadsınamaz. Özellikle endüstride Nesne Yönelimli Yaklaşım ve Java/J2EE ‘nin başarılı kullanımı ve yaygın kabul görmesi paralelinde metodolojiler, modelleme dil ve kullanılan yazılım geliştirme araçlarında önemli gelişmeler meydana geldi.

Tutarlı ve ortak tek bir nesne yönelimli metodolojiye ve görsel modelleme diline olan ihtiyaç 1990 lardan itibaren kendini göstermeye başlamıştır. O dönemde varolan temel üç nesne yönelimli metodoloji

1. Booch metodolojisi (Grady Booch)
2. OMT - Object Modeling Technique (James Rumbaugh)
3. OOSE - Object Oriented Software Engineering (Ivar Jacobson)

çoğu noktalarda benzeşmesine rağmen gerek kullanılan görsel notasyon gerekse metodolojiler farklılıklar göstermekteydi. James Rumbaugh ve Ivar Jacobson‘ın da Rational ‘a katılması sonrası Rational, görsel modelleme dillerini birleştirerek Unified Modeling Language (UML) 0.8 i Ekim 1995 de geliştirdi. Aralarında IBM’inde bulunduğu büyük BT şirketlerinin de desteği ile UML standartlaşma sürecinden de geçerek Kasım 1997 de UML 1.1 sürümü ile yazılım endüstrisinde bir standart haline geldi. (UML dilinin bakımı günümüzde bir standartlar kuruluşu olan Object Management Group “OMG” tarafından yapılmaktadır. Son sürümü UML 2.0 dır).

Yine Rational Software tarafından bu üç ayrı metodolojide diğer firma ve grupların da katkıları ile birleştirilerek, yazılım geliştirme hayat döngüsü içerisinde yer alan tüm süreç, eleman (artifact), sorumluluk ve rollerinde tanımlandığı bileşik yazılım geliştirme süreç yönetimi Rational Unified Process 5.0 (RUP) Haziran 1998’de geliştirildi. (bkz Şekil 1)

Şekil-1 RUP'un gelişimi

Günümüzde, ihtiyacımız olan yazılımlar daha büyük, daha hızlı ve daha karmaşık yazılımlardır. Bu ihtiyaçlara bir de yazılımda aradığımız nitelikler eklendiğinde (ölçeklenebilir, güvenli, sağlam, çok katmanlı, bağımsız (loose coupling), açık, taşınabilir, bütünleşebilir, yeniden kullanılabilir ....) karmaşıklık daha da artmakta, diğer tarafdan “yazılım pazara çıkış zamanı” beklentisi kısalmaktadır. Bu şartlar altında 30 yıllık metodlar kullanarak geliştirilen yazılımların ihtiyaca cevap vermediği dünyada deneyimlerle görülmüştür.
Günümüz ihtiyaçlarına cevap verebilecek yazılım geliştirme metodu olan RUP ‘in üç temel özelliği

1. Kullanıma göre kurgulanmış, “use-case driven”
2. Mimari odaklı, “architecture centric”
3. Yinelenen artımlı ”iterative and incremental” olmasıdır..

Kullanım durumu “use-case”; geliştirilen yazılım ile bir sistemin veya kullanıcının belirli bir fonksiyonel gereksinim dahilinde etkileşimidir. Tüm kullanım şekilleri biraraya geldiğinde kullanım durum modeli “use-case model” meydana getirir ve bu model her yineleme içerisinde analiz, tasarım, gerçekleştirim ve test aşamalarına temel teşkil eder. Yazılım geliştirme süreclerinin kullanım durum modelindeki bir seri akışı takip ederek gerçekleştirilmesi, kullanıma göre kurgulanmış olması anlamına gelir.

Bir yazılımdaki kullanım şekillerinin sadece %10‘u o sistemin mimari olarak adlandırdığımız en önemli ve temel fonksiyonları için yeterlidir. Kullanım şekilleri izole bir biçimde değil, sistem mimarisine uygun olarak seçilir ve her yineleme (“iteration”) ile hem mimari model hem kullanım durum modeli birlikte olgunlaştırılır. Mimari geliştikçe yeni kullanım durumları, kullanım durumları geliştikçe mimari olgunlaşır, mimari yapının tam olarak oturmasına kadar devam eden bu süreç mimari odaklıdır.

RUP, bir yazılım projesini daha küçük birçok yazılım projelerinden oluşan bir bütün ve her bir küçük yazılım projesini bir artım ”increment” ile biten bir yineleme olarak tanımlar. Her yineleme kontrollü, planlı olmalı ve bellirlenmiş önemli riskleri çözümleyecek bir gurup seçilmiş kullanım durumunu içermelidir. Başarılı bir yineleme içerdiği küçük projeyi bir önceki yinelemenin kaldığı noktadan planlanan riskleri çözümleyerek bir sonraki yinelemenin gereksinimlerine uygun hale getiren yinelemedir. Her iterasyonda yazılım geliştiriciler ilgili kullanım durumlarını seçerek ve yaratarak (bazıları henüz oluşmamış olabilir) belirlenen mimari rehberliğinde yazılım elemanlarını tasarlar ve kullanım durumlarını gerçeklediğinden emin olurlar. Eğer bir yineleme amaçlarını karşılıyorsa (genellikle karşılar) bir sonraki yinelemeye geçilir, amaçları karşılamıyorsa daha önce verilen kararlar gözden geçirilmeli, düzeltme ve gerek duyulan yeni kararlar tasarımda yerini almalıdır. Tabii ki öngörülmeyen ihtiyaçlar ve sorunlar geliştirme esnasında oluşacaktır, bu durumda yeni yinelemeler eklenmesi veya planlanan yineleme akışının değiştirilmesi gerekir. Sürecin yinelenen artımlı olmasının asıl amacı bu tür durumlarda kaybı minimize etmektir, sadece ilgili iterasyonun kaybı veya uzaması tüm bir ürünü kurtaracaktır (Bkz Şekil 2) . Daha önceki yazılım geliştirme süreçlerinde bu tür durumların bu yöntemle çözülmemesi, tüm projenin başarısızlıkla sonuçlanmasına veya yazılım geliştirme maliyetinin iki – üç katına çıkmasına neden olmuştur.

RUP, yazılım geliştirme sürecini verimli, etkin, açık, kısa ve kontrollü yinelemeler bütünü olarak yönetmektedir. Bu sayede sonu gelmeyen proje aşamaları ortadan kalkmakta, geliştirme ekibi de daha tempolu, daha paralel ve daha esnek çalışabilmektedirler. Kullanılan görsel modellemenin (UML) geliştirme ekibine sağladığı hızlı ve kalıcı iletişim, yüksek soyutlama düzeyi altyapısı ve modelin kod üretiminde de kullanılabilmesi diğer çok önemli avantajlardır. Bir sistemde sınıfların %70 i ortaya çıkarılması kolay sınıflardır, %25 i tasarım ve gerçekleştirim yinelemelerinde keşfedilir, kalan %5 ise bakım yinelemelerine kadar ortaya tam olarak çıkmazlar. Bu istatistik RUP ve özetle açıkladığım üç temel özelliğin ne kadar vazgeçilmez ve eş önemde özellikler olduğunu anlamamıza yardımcı olacaktır.

Şekil 2 : RUP ‘in Dokuz temel süreç iş akışı ve dört temel faz

Yazılım yaşam döngüsü çevrimlere bölünmüştür ve her bir çevrim ürünün yeni bir nesli üzerinde çalışır.Rational Unified Process, bir gelişim çevrimini birbirini izleyen dört evreye ayırır (Bkz Şekil 2)

• Algılama (“inception”) evresi
• Somutlaştırma / Detaylandırma (“elaboration”) evresi
• Yapım (“construction”) evresi
• Geçiş (“transition”) evresi

• Bir görünüm belgesi: temel projenin gereksinimlerinin, ana özelliklerinin ve önemli kısıtlamalarının genel bir görünümüdür.
• Başlangıç kullanım durum modelleri (%10 -%20) oranında tamamlanmış).
• Başlangıç proje sözlüğü (kısmi olarak bir etki alanı modeli biçiminde de ifade edilebilir).
• İş bağlamını, başarı ölçütlerini (öngörülen gelir, pazarda tanınma vb.) içeren başlangıç iş örneği ve mali tahmin.
• Başlangıç risk değerlendirmesi.
• Evreleri ve yinelemeleri gösteren bir proje planı.
• Gerekiyorsa, bir iş modeli.
• Bir ya da birkaç prototip.

Somutlaştırma evresinin amacı, sorunun etki alanının çözümlenmesi, sağlam bir mimari temelin kurulması, proje planının geliştirilmesi ve projedeki yüksek risk öğelerinin ortadan kaldırılmasıdır. Bu hedeflere ulaşmak için, sistem hakkında “enine boyuna” bir görüşe sahip olmanız gerekir. Mimari kararlar, sistemin bütününü, yani kapsamını, ana işlevselliğini ve başarım gereksinimleri gibi işlevselliğe ilişkin olmayan gereksinimlerini anlayarak verilmelidir. Bu evrenin sonunda, zor olan “mühendislik” aşaması tamamlanmış sayılır. Yapım ve geçiş evrelerine geçme ya da geçmeme kararı projede en önemli karar olacaktır. Projelerin birçoğu için bu, hareketli, hafif ve çevik, düşük riskli bir işlemden önemli ölçüde atıl, yüksek maliyetli ve yüksek riskli bir işleme geçiş anlamına da gelir. Bir yandan sürecin değişikliklere sürekli uyum sağlaması gerekirken, geliştirme evresindeki etkinlikler de geliştirmenin tamamlanması için maliyeti ve zaman çizelgesini tahmini olarak belirlememize yardımcı olabilmek amacıyla, mimarinin, gereksinimlerin ve planların yeterince sabit olmasını ve risklerin hafifletilmesini sağlar. Kavramsal olarak bu doğruluk düzeyi, bir kuruluşun sabit fiyatlı yapım evresine geçmesi için gereken düzeye karşılık gelir.

Somutlaştırma evresinde, projenin kapsamına ve riskine bağlı olarak bir ya da birkaç yinelemede gerçekleştirilebilir. Projedeki belli başlı teknik riskleri işaret eden önemli kullanım durumları doğrultusunda bir mimari prototip oluşturulur.

Somutlaştırma evresinin sonuçları:

• Bir kullanım durumu modeli (en az %80 oranında tamamlanmış olarak) — tüm kullanım durumları ve oyuncular belirlenmiş ve kullanım durumlarından birçoğu geliştirilmiş olur.
• İşlevsel olmayan gereksinimleri ve belirli bir kullanım durumuyla ilişkili olmayan tüm gereksinimleri yakalayan tamamlayıcı gereksinimler saptanmıştır.
• Bir Yazılım Mimarisi Tanımı yapılmıştır.
• Yürütülebilir bir mimari prototip geliştirilmiştir.
• Gözden geçirilmiş bir risk listesi ve iş örneğ hazırlanmıştır.
• Yinelemeleri ve her yineleme için değerlendirme ölçütlerini gösteren, kaba taslak bir proje planını da içerecek şekilde, projenin tamamı için bir geliştirme planı yapılmıştır.
• Kullanılacak süreci belirten güncellenmiş bir geliştirme örneği çıkarılmıştır.
• Bir ön kullanıcı kılavuzu (isteğe bağlı olarak) hazırlanmıştır.

Yapım evresinde, geri kalan tüm bileşenler ve uygulama özellikleri geliştirilir ve ürünle bütünleştirilir, tüm özellikler bütünüyle test edilir. Yapım evresi, bir anlamda, maliyetleri, zaman çizelgelerini ve kaliteyi en iyi düzeye getirmek için özellikle kaynakların yönetilmesine ve işlemlerin denetlenmesine önem verilen bir üretim sürecidir. Bu anlamda, yönetimin eğilimi, başlangıç ve geliştirme evreleri sırasında fikri mülkiyetin geliştirilmesinden, oluşturma ve geçiş evreleri sırasında kullanılabilir ürünlerin geliştirilmesine doğru bir geçiş yapar. Birçok proje, paralel çalışmaların oluşturulabileceği kadar büyüktür. Bu paralel etkinlikler, uygulanabilecek yayınların kullanılabilirliğini önemli ölçüde hızlandırabilir, ancak kaynak yönetiminin ve iş akışı eşzamanlamasının karmaşıklığını da artırabilir. Sağlam bir mimari ile anlaşılabilir bir plan önemli ölçüde birbirine bağlıdır. Diğer bir deyişle, mimarinin en önemli özelliklerinden biri, yapım kolaylığıdır. Bu nedenle, somutlaştırma evresinde, mimarinin ve planın dengeli bir biçimde geliştirilmesinin ne derece önemli olduğu vurgulanır. Yapım evresinin sonucunda, son kullanıcılara teslim edilmeye hazır, uygun platformlara bütünleştirilmiş, kullanıcı kitapları/yardım dosyaları hazırlanmış bir ürün ortaya çıkar.

Geçiş evresinin birincil hedefleri aşağıdakileri içerir:

• Paydaşların, yayma temellerinin eksiksiz ve vizyonun değerlendirme ölçütleriyle tutarlı olduğu konusunda fikir birliğine varmalarının sağlanması
• IBM Rational Software Architect – Java, J2EE (artık Java EE 5 veya 6), web, portal uygulamaları ve web servisleri için UML 2.0 uyumlu olgun mimariler tasarlanmasını, hızlı geliştirme yapılabilmesini, kolay test, hata ayıklama, devreye alma, “profiling” yapılabilmesini sağlayan, eclipse 3.0 desteği ile birçok yazılım geliştirme aracının bütünleştirildiği yazılım geliştirme platformudur.

IBM Rational Application Developer – Java, J2EE, web, portal uygulamaları ve web servisleri için hızlı tasarım, geliştirme, kolay test, hata ayıklama, devreye alma, “profiling” yapılabilmesini sağlayan, eclipse 3.0 desteği ile birçok yazılım geliştirme aracının bütünleştirildiği yazılım geliştirme platformudur.

IBM Rational Software Modeler – İş süreci modellemesi, gereksinim çözümlemesi ve UML 2.0 uyumlu bileşen mimarisi tasarımı için dünyada lider olan görsel bir modelleme aracıdır.

IBM Rational Requisite®Pro – Gereksinimlerin yazılmasını, iletilmesini ve değiştirilmesini kolaylaştırarak uygulama geliştirme süreci boyunca tüm geliştirme ekibinin güncel bilgilere sahip olmasını sağlar.

IBM Rational ClearCase – Proje paylaşımcılarına her bir yazılım geliştirme projesinin gelişimini izleme gücünü sağlayan, kod ve diğer kaynakların paylaşımını ve saklanmasını güvenli bir biçimde gerçekleştiren, pazarda lider bir yazılım yapılandırma yönetim aracıdır.

IBM Rational ClearQues – Proje ekiplerinin geliştirme yaşam döngüsünde oluşan tüm hata/değişiklik etkinliklerini izlemelerini ve yönetmelerini sağlayan bir hata/değişiklik isteği yönetim ürünüdür.

IBM Rational PurifyPlus –Yazılım geliştiriciler için çalıştırma sırasında hata denetimi yapabilmelerini, bellek hatalarını, olası performans darboğazlarının saptayabilmelerini, geliştiricilerin uygulamalarını bütünüyle, kolay ve verimli bir biçimde test edebilmelerini ve kaynak kodun ne kadarının kapsanabildiğini gösteren gelişmiş bir araçtır.

IBM Rational Functional Tester – Java, .Net ve Web tabanlı uygulamalar için otomatikleştirilmiş işlevsel testleri yaratır, saklar, yürütür ve böylece kodunuzu tam anlamıyla test etmenizi sağlayarak yazılımınızın gereksinimleri karşılayıp karşılamadığını ve beklenen şekilde çalışıp çalışmadığını belirlemenize olanak tanır.

IBM Rational Performance Tester – İstemci/sunucu ve Web sistemlerinin performansını ölçen , gerekli yükü istek profiline uygun olarak simüle eden kullanımı kolay, anlaşılır ve ölçeklenebilir bir araçtır.