UML/UP ile Yazılım Geliştirme

Bölüm 5/7

İçerik

• UML’in Sizin için Anlamı• UML Şemaları, Semboller ve Semantik İlişkileri• Şema ve Model Bazlı UML Çalışmaları

Arasındaki Farklar• Alternatif Yazılım Geliştirme Süreçlerinde

UML'in Yeri• UML ile Gereksinim Yönetimi• UML ile Nesne Yönelimli Tasarım

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

Değişen

gereksinimler

Yeni

sistem

Süreç

Süreç Nedir?

• Kimin Neyi Ne Zaman Nasıl yapacağını tanımlamaktır.

1. Gereksinim Yönetimi (Ne?)

Ürünün yerine getirmesi gerekenler

2. Analiz (Nasıl?)

Sistemin parçalarının ve birbirleriyle alakalarının kavramsal seviyede belirlenmesi

3. Tasarım (Nasıl?)

Sistemin parçalarının ve birbirleriyle alakalarının bir teknolojiye has olarak (J2EE, C++) belirlenmesi

4. İmplementasyon (Kodlamak)

Sistemin kaynak kodunun geliştirilmesi

5. Test (Verifikasyon: Fonksiyonel Test)

Test verileriyle uygulamayı çalıştırmak

6. Bakım (Hata Düzeltme ve Geliştirme)

Ürünün hatalarını giderme ve yeni özellikler ekleme

Yazılım Süreci Aşamaları

1. Gereksinim Yönetimi: Uygulama kullanıcının bakiyesini göstermelidir.

2. Analiz ve Tasarım: Tasarım VadesizHesap ve VadeliHesap class’larına sahip olmalıdır.

3. İmplementasyon: class VadesizHesap{ double bakiye; getBakiye{}; setBakiye{}} …

4. Test: yatırılan $44.92 / yatırılan $32.00 / çekilen $101.45 / … bakiye $2938.22, testi geçti.

5. Bakım: Hata düzeltme: Bakiye sıfır olunca ve para çekme işlemi yapılmak istenince sistem

göçüyor.Ek Özellik Geliştirme: Euro para birimini destekleme.

Süreç Örneği: Bireysel Finans

Waterfall Yazılım Süreci

zaman

GereksinimAnalizi

Tasarım

Milestone(s)

Fazlar

İmplementasyon

Test

Bakım

Ürünün sürümleri

Bu fazlar kısa bir süre için örtüşebilir

Waterfall Neden Pratik Değildir?

1. Sahip olunması istenen bilgilerin hepsi hazır değildirBütün detayları işin başında görmek zordur

2. Gereksinimlerin implementasyon maliyetlerini sadece tahmin edebiliriz Tahminin isabetliliğini anlamak için en riskli olanlarının tasarlanıp,

implemente edilmeleri gerekirBuradan alınan sonuçlara göre gereksinimler değişebilir

3. Sık sık ara sürümler çıkarmak zorunda kalırızPaydaşların (müşteriler, yöneticiler) projeye güvenlerini tazelemek gerekirTasarımcılar ve programcılar geliştirdikleri sistemin istenen sistem

olduğunun konfirmasyonunu beklerler (Bunun yegane yolu: kademe kademe parçaları birleştirerek (iterative ve incremental) yazılım geliştirme ve testtir)

4. Tipik olarak yazılım ekibinin elemanları farklı fazlarda da görev alırlar

Spiral Süreç

Spiral Süreç

zaman

1 Gereksinim

Tasarım

Kodlama

Test

1İterasyon #

1

1

2

2

2

3

3

3

X sürüm 1.0

M I L E S T O N E S

2 3

2 3 1

α(prototype) X

β

Örtüşen Süreç Aşamaları: UP

RUP’un Gelişimi

İşlevsellik TestiPerformans TestiGereksinim Denet.Değişiklik Denet.İş AkışıVeri TabanıUI

Rational Unified Process 5.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

Ericsson Yaklaşımı

Rational Yaklaşımı UML

Süreç Seçim Yaklaşımı Olarak MPP

• Method over Tool:“Herhangi bir yazılım mühendisliği ürününden ziyade

yönteme odaklanmak”• Project over Method:“Herhangi bir yazılım sürecinden ziyade projeye/ürüne

odaklanmak”• People over All:“Herşeyden çok ürünün kullanıcıları ve onu geliştirenler

dahil olmak üzere paydaşlara odaklanmak”

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

Proje Gelişim Süreci

zaman

Inception Elaboration Construction Transition

•Inception: Projenin sınırlarının belirlenmesi, Verilecek hizmetin berraklaştırılması

•Elaboration: Proje planının oluşturulması, ürün özelliklerinin saptanması, Baseline

•Construction: Ürünün oluşturulması•Transition: Kullanıma sunulma

saptama tasarlama oluşturma sunma

GereksinimKontrolü

SistemMimarisi

Kullanılabilirlik ResmiSürüm

Aşamalar ve İterasyonlar

Bir iterasyon planlı olarak gerçekleştirilmiş faaliyetler bütünüdür. Sonucunda başarısı ölçülebilen çalıştırılabilir bir bilgisayar programı oluşur.

ArchIteration

... Dev Iteration

Dev Iteration

... TransIteration

...

Release Release Release Release Release Release Release Release

PrelimIteration

...

Inception Elaboration Construction Transition

İterasyonlar ve İşler

P re lim in a ry

Ite ra tio n (s )ite r.

# 1

ite r.

# 2

ite r.

# n

ite r.

#n + 1

ite r.

# n +2

ite r.

# m

ite r.

#m +1

Inception Elaboration Construction Transition

Gereksinim

Tasarım

Uygulanma

Test

Analiz

Aşamalar

İşler

İterasyon

İterasyonlar ve Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Proje risklerinin ortaya konması

•Mimarinin revizyonu

•Risk-bazlı iterasyonlar

•Entegrasyon

•Kullanıma sunma

•Müşteri memnuniyetini ölçme

•Senaryolarla sistemin yapısının ve davranışının oluşturulması

•Sistem Mimarisinin oluşması

•Temel mekanizmaların tasarlanması

Risk Azaltma Odaklı İterasyonlar

İlk Proje Riskleriİlk Proje Odağı

Yenilenen Proje Planı• Maliyet• Zamanlama• Odak/İçerik

İterasyon N’in Planı• Maliyet• Zamanlama

Iteration N’in değerlendirilmesi

Giderilen RisklerDiğer Riskler• Yeni öncelikler

Iteration N’in oluşması• Maliyet ve Kalite ölçümleri

En önemli risklere yönelik senaryoların oluşturulması

Iterasyon N

Use Case Odaklı İterasyonlar

Inception Elaboration Construction Transition

İterasyon1İterasyon2 İterasyon3

İterasyon PlanıGereksinimler

Analiz + TasarımUygulama

Test Release

“Mini-Waterfall” Süreci

İterasyon Süreci

• Önceki iterasyonların sonuçları• Güncel Risk Raporu• Model, kod ve test kayıtları

Release raporuYeni Risk RaporuKonfigürasyon Denet.

İterasyon Planı

Gereksinimlerin Sapt.

Analiz + Tasarım

Uygulama

Test

Release

Adapte Olabilen bir Süreç: UP

Murray CantorMurray CantorMurray CantorMurray Cantor

Rational Stratejik Hizmetler Biriminde baş Rational Stratejik Hizmetler Biriminde baş danışman. danışman.

Uzmanlık alanları:Uzmanlık alanları:

• Yazılım Mühendisliği SüreçleriYazılım Mühendisliği Süreçleri

• Sistem Mühendisliği SüreçleriSistem Mühendisliği Süreçleri

• Yazılım Proje YönetimiYazılım Proje Yönetimi

• LiderlikLiderlik

Software Leadership: A Guide to Successful Software Development

Rational Stratejik Hizmetler Biriminde baş Rational Stratejik Hizmetler Biriminde baş danışman. danışman.

Uzmanlık alanları:Uzmanlık alanları:

• Yazılım Mühendisliği SüreçleriYazılım Mühendisliği Süreçleri

• Sistem Mühendisliği SüreçleriSistem Mühendisliği Süreçleri

• Yazılım Proje YönetimiYazılım Proje Yönetimi

• LiderlikLiderlik

Software Leadership: A Guide to Successful Software Development

Slaytlar 20 - 28

Eski Müşteri/Yazılım Ekibi İlişkisi

• Gereksinimleri ‘bitir’ kaynak değerlendirmesi yap proje planı yaz taahhüt ver planı uygula proje başarısızlığını gör suçluyu ara sonunda kabul edilebilecek bir çözüm sun (belki)

• Varsayımlar – Gereksinimlerin, proje içeriğinin, kullanılacak teknolojinin

eksiksiz ve gereken detay seviyesinde anlaşıldığını ... – Çok isabetli tahminlerde bulunmanın mümkün olduğunu ...– Detaylı bir planın yapılabileceği ve uygulanabileceği ...

‘Waterfall’ Yaklaşımının SonuçlarıDetaylı toplantılar yapılıyor /Toplantı

notları yazılıyor

Tasarım uygun gözüküyor.

Detaylı bir spesifikasyon hazırlanıyor.

Gereksinim kapsama yüzdesi (% 100) yüksek.

• Tasarım “suçu ispatlanana kadar

masum.”

Toplantılar ve dokümanlar karmaşık bir yazılım sisteminin gerçek risklerinin çok azına değiniyor.

Elle tutulur bir delil yok.

Yanıltıcı bir güvenlik hissi var.

Pek azı n*(% 10) tasarımı yönlendiriyor.

Gereksinimlerin hepsine nüfuz etme çabası kritik noktaları gözden kaçırıyor.

Her zaman suçlu. Tasarım hatası ileride istemediğimiz bir zamanda ortaya çıkacak.

Sözde Sonuçlar Gerçek Sonuçlar

Pareto KanunuFa

yd

aFa

yd

a

EmekEmek20%20%

80%80%

%%2020’lik ’lik eemekmek faydanınfaydanın %%8080’ini sağlar’ini sağlar..%%2020’lik ’lik eemekmek faydanınfaydanın %%8080’ini sağlar’ini sağlar..

Hata Payını En Aza İndirmek Çok Emek İster

• Gereksinimler karmaşıktır– Fonksiyon/Davranış– Sistem tarafı ayrıca karmaşıktır.

• Tam anlamıyla anlamak analiz, deneyler ve neticelerin değerlendirilmesiyle mümkündür.

• Gereksinimlerle Sistem Mimarisinin ilişkilerinin belirlenmesi gerekir.

• Tüm bu emek bahsettiğimiz 80/20 kuralına tabiidir. – Eksiksiz bir bilgiye erişim en iyimser yaklaşımla ekonomik

değildir. Gerçekçi olursak mümkün değildir. – Bilgi proje süresince eksiksizleşir.

ParadoksYapılacak işi yönetebilmek içim yazılım taahhütlerinin olması gerekli

Taahhütlerin çok detaylı bir şekilde tarif edilmeleri mümkün değil

Çözüm:– Açık bir şekilde ortaklaşa çalışma, müşteriye sonuç göstererek

yönetim ve programcı arasında ahenk oluşturarak çalışmak– İteratif yazılım geliştirme– Elde edilen bilgilerin kademeli olarak zaman içerisinde

eksiksizleşmesi ve detay seviyelerinin artması.

Yazılım Problemi: İki nokta arasındaki en kısa yol

Buradan Buraya

Nasıl gideceğiz?

Buradan Buraya

Nasıl gideceğiz?

Düşündüğümüz GüzergahDüşündüğümüz Güzergah

Projenin ilk Durumu

Mevcut ‘malzemeler’, teknolojiler

Elemanlar, kabiliyetleri, bilgileri

Kaynak eksiklikleri

Belirsizlikler

Projenin ilk Durumu

Mevcut ‘malzemeler’, teknolojiler

Elemanlar, kabiliyetleri, bilgileri

Kaynak eksiklikleri

Belirsizlikler

Müşteriyi Tatmin Edebilecek Alan

Katmadeğer: Kullanıcıya (kullanılabilirlik, performans, kalite)

Maliyet (zaman ve para)

Katmadeğer: Yazılım Geliştirici (kar, deneyim, satış, Pazar payı vs.)

Müşteriyi Tatmin Edebilecek Alan

Katmadeğer: Kullanıcıya (kullanılabilirlik, performans, kalite)

Maliyet (zaman ve para)

Katmadeğer: Yazılım Geliştirici (kar, deneyim, satış, Pazar payı vs.)

Gerçek Güzergah

İterasyonlar ve Projenin İlerlemesinin Gözlenebilmesi

Müşteriyi Tatmin Edebilecek Alandaki BelirsizlikMüşteriyi Tatmin Edebilecek Alandaki Belirsizlik

Planlanan Planlanan İçerikİçerik

Planlanan Güzergah

Projenin ilk Projenin ilk DurumuDurumu

Planlanan GüzergahPlanlanan Güzergah

Gerçek GüzergahGerçek Güzergah

‘Waterfall’ Yönetimi: “Planla ve Takip Et”

Planlanan Proje Planlanan Proje BitişiBitişiPlanlanan Proje Planlanan Proje BitişiBitişi

Gerçek Proje BitişiGerçek Proje BitişiGerçek Proje BitişiGerçek Proje Bitişi

Müşteriyi Tatmin Edebilecek AlanMüşteriyi Tatmin Edebilecek AlanProjenin ilk DurumuProjenin ilk Durumu

Planla ve Takip Et: Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. Gerçek ve Hayal: Bu durum iki farklı planın takip edilmesini gerektiriyor.

Planla ve Takip Et: Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. Gerçek ve Hayal: Bu durum iki farklı planın takip edilmesini gerektiriyor.

Müşteriyi Tatmin Edebilecek AlanMüşteriyi Tatmin Edebilecek AlanProjenin ilk DurumuProjenin ilk Durumu

Planlanan GüzergahPlanlanan Güzergah

İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol”

Planlanan Proje Planlanan Proje BitişiBitişiPlanlanan Proje Planlanan Proje BitişiBitişi

Gerçek GüzergahGerçek Güzergah

Gerçek Proje BitişiGerçek Proje BitişiGerçek Proje BitişiGerçek Proje Bitişi

Devamlı olarak :Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendirManevra yap ve adapte ol – İterasyonlar bir dizi ufak sonuç sağladığından projenin tüm istekleri yerine getirmesini sağlamak için kullanılabilir: Hangi yönde manevra yapacağız?

Devamlı olarak :Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendirManevra yap ve adapte ol – İterasyonlar bir dizi ufak sonuç sağladığından projenin tüm istekleri yerine getirmesini sağlamak için kullanılabilir: Hangi yönde manevra yapacağız?

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

UP’in 3 Temel Parçası

Use Case’leri tanımla

Use case paketi

Use case

sorumluluğu

Analist

Artifact(Oluşanlar)

Sürecin oluşturduğu, kullandığı veya değiştirdiği bir ürün

Role (Çalışan)

Bir rol Activity (Faaliyet)

Bir iş

Role

• Analistler: İş Analisti, Sistem Analisti, vs.• Yazılım Geliştirenler: Tasarımcı, Programcı,

Kullanıcı Arayüzü Tasarımcısı, vs.• Yöneticiler: Proje Yöneticisi, Süreç Uzmanı, vs.• Diğer: Konu Uzmanları, Denetçiler (Reviewer),

vs.

Activity

Artifact

Unified Process Yapısı

Discipline ve Workflow

Disiplin: Gereksinim Yönetimi

Workflow: Gereksinim Yönetimine ait çalışma şekli detayları

Workflow Details

Daha Fazla Detay “Rol Üzerinden”

Daha Fazla Detay“Yapılacak İş Üzerinden”

Daha Fazla Detay“Üretilenler Üzerinden”

Daha Fazla Detay“Bir Adım Daha İleriye: Şablonlar”

İş Akışları Modelleri Oluşturur

“Ürünler ve Kullanım Teknikleri”

Özetlersek

Sorulamayan Soruyu Bulmak“Sorulamayan soruyu bulmak gerçekle hayali birbirinden ayırmamızı sağlar.”

John M. Berry (A.B.D.’li Filozof)

• UP diğer süreç tanımları gibi ‘geleneksel bir model’ değildir.– Varsayımları (Neden’i) açık ve belli.– Çalışma şekillerinin girdisi, çıktısı, kimlerin ne işine yaradığı ve kimler

tarafından oluşturuldukları belli.• Yapılacakları dikte etmez: Ne’nin yanında Nasıl’da vardır.• Ne’lerin neler olacağına UP’un kullanıcısı karar verebilir.• Ne mevcut değilse onu ekleyebilir: UP plug-in’leri.• Ne’sini, Nasıl’ını ve Neden’ini (en küçük yapı taşına kadar) açıkça ortaya koyan

bir sistem soyut ve anlamsız (süreç için süreç) bir kavrama dönüşmez.• UP’u çok ciddi bir hedef olan CMM-I için de daha çok programcı odaklı

Extreme Programming için de kullanabiliriz.

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

SPEM“Software Process Engineering Metamodel”

• UML gibi OMG tarafından onaylanmaktadır. Açık bir standarttır.

• Bitmiş bir standart değildir. Ufak değişmeler (gelişmeler) söz konusu olacaktır.

• Tamamıyla Unified Process üzerine oturur.• Biz, örneklerimizde, kabaca kullanacağız.

SPEM Gösterimi“Disiplinler”

XXX

SPEM Gösterimi“Roller”

SPEM Gösterimi“Yapılanlar”

SPEM Gösterimi“Üretilenler”

SPEM Gösterimi“Roller, Yapılanlar ve Üretilenler”

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

Süreç Haritası

Süreç Haritası“Çevik Süreç Tanımları”

Süreç Haritası“CMMI”

Süreç Haritası“Unified Process”

UP Uyarlamaları

Gereksinim Yönetimi“Standart UP”

Analiz ve Tasarım “Standart UP”

İmplementasyon “Standart UP”

Bizim UP Sürecine Yaklaşımız

Proje Süresince Roller• Bir kişi birden fazla rolü canlandırabilir.• Aynı kişinin canlandırdığı rollerin çıkarları bir çelişki

oluşturmamalıdır.• Bütçe ve Eleman sayımızı gözeterek ve en verimli

süreç tanımını hedefleyerek,• Aşağıdaki gibi bir kadroyla yola çıkarsak,

– Ahmet Bey: Birincil görevi Sistem Analizi– Leyla Hanım: Birincil görevi Tasarım– Mehmet Bey: Birincil görevi Veritabanı Tasarımı – Hülya Hanım: Birincil görevi Proje Yönetimi

1. Gereksinimler

2. Analiz

ve Tasarım

3. İmplementasyon

4. Test

Proje Yönetimi

Süreç Mühendisliği

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

İdeal Proje Ekibi

BizimProje

Ekibimiz

BizimProje

Ekibimiz

Ahmet = Sistem Analisti

Ahmet = UI Tasarımcısı

Ahmet = Testçi

Leyla = Sistem Mimarı

Leyla = Tasarımcı

Leyla = Programcı

Mehmet = Veritabanı Tasarımcısı

Hülya = Proje Yöneticisi

Hülya = Süreç Uzmanı

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

Proje Hazırlık Çalışmaları“Tanımlamalar”

• Paydaş Türleri• Gereksinim Türleri• Gereksinim Değişkenleri• Kısıtlama Türleri• Risk Türleri• Metrik Türleri• Emek Türleri• Bakım Türleri• Test Türleri• UML Standardına Ekleriniz, vs. vs.

1a. Paydaşlar“Kullanıcılar”

1b. Paydaşlar“Proje Ekibi Adayları”

1c. Paydaşlar“Proje Ekibi”

2a. Gereksinim Türleri

2b. Gereksinim Türleri

2c. Gereksinim DeğişkenleriÖrnek: “Statü”

3. Kısıtlama Türleri

4. Risk Türleri

5. Metrik Türleri

6. Emek Türleri

7. Bakım“Problem Türleri”

8. Test

9. UML Kapsamına Ekler“Size Özel Stereotype”

İlham Kaynakları

James Bach

Watts Humphrey

Philippe Kruchten

Murray Cantor

James Rumbaugh Grady Booch

Terry Quatrani

Ivar Jacobson