2. İç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
4. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
5. Proje Başarısızlığı Nedenleri
• En yaygın nedenler:
– Kullanıcı fikirlerinin alınmaması (% 13)
– Eksik gereksinimler (% 12)
– Değişen gereksinimler (% 12)
• Dolayısıyla projelerin üçte biri gereksinimlerle
ilgili nedenlerden başarısız oluyor
6. Proje Başarısı Nedenleri
• En yaygın nedenler :
– Kullanıcı fikirlerinin alınması (% 16)
– Üst yönetim desteği (% 14)
– Gereksinimlerin açık olması (% 12)
7. Gereksinim Hataları
• Müşteriye taşınan hataların yaklaşık olarak
üçte biri gereksinim hatalarıdır
• Gereksinim hataları bulundukları anda
giderilmezlerse ilerideki düzeltilme maliyetleri
10 ila 100 katına çıkabilir
• İyi proje takımları hataları tespit edildikleri
anda tahlil ederler
8. Gereksinim Yönetimi
• Öyleyse gereksinimleri denetlemeye
ihtiyacımız var:
– Gereksinimleri bulmak, organize etmek ve
dokümante etmek için bir sistem gerekli
– Gereksinim değişikliklerini yöneterek müşteri ve
proje ekibinin anlaşmalarını sağlayabilmek için bir
süreç gerekli
• Bu kavramlara Gereksinim Yönetimi diyoruz
9. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
10. Gereksinim Nedir?
• Gereksinimleri tanımlayabilmek için onları
gereksinim gibi algılanabilecek diğer bilgi
türlerin ayrıştırabilmemiz gerekir
• Bir ihtiyaç (need) bir sistemi kullanan
müşterinin işini yapabilmesi için gereken,
sistemin sahip olmak zorunda olduğu bir
özelliktir
11. Gereksinim Nedir?
• İşlev (feature) sistemin yerine getirmeyi taahhüt
ettiği bir hizmettir
• Gereksinim (requirement) sistemin karakteristik bir
özelliğidir
• Gerçekleştirme (realization) gereksinimlerin
uygulanma şeklidir
Bir işlevden bir veya daha fazla gereksinim türetilebilir
13. Gereksinim Nedir?
• Fırsat (opportunity) yeni bir işlev, yeni bir
müşteri tipi veya ürüne eklenen yeni bir özellik
olabilir
• Problem müşterinin işini yaparken karşılaştığı
bir zorluktur
• Kısıtlama (constraint) oluşturulacak sistemin
uymak zorunda olduğu bazı sınırlardır
14. Acaba Bu Bir Gereksinim Mi?
• Yoksa eksik bilgiyle tasarımıma mı başladık?
• Gerçekte ihtiyaç duyulmayan gereksinimlere
ve aslında mevcut olmayan kısıtlara dikkat
ediniz
• Yoksa birisi problemden ziyade çözümü mü
tanımlamaya başladı?
• Bir gereksinim olmak için çok mu genel?
15. Öncelik
• Gereksinimin önceliği veya aciliyeti nedir?
– Yüksek, Orta, Düşük
– Zaruri, İstenen, Seçeneğe Tabii
– Mutlaka olmalı, Olması arzulanan, Olsa iyi olacak olan
– Gündelik terminolojide ‘olacak’, ‘olsa iyi olur’, ‘olmayabilir’
• Gereksinimlerin önem nedenleri nedir?
– Sistem Mimarisine etki,
– Teknolojik yenilik nedeniyle bir risk,
– Zorluk nedeniyle bir risk,
– Vs. vs.
16. Paydaş (Stakeholder)
• Müşteriden fikri değerli yegane grupmuş gibi
bahsedebiliyoruz ama projeye yönelik çelişen
düşüncelere sahip pek çok grup insan olabilir
(paydaş)
17. Paydaş Türü Örnekleri
• Sponsor
• İş Analisti, Sistem analisti, Tasarımcı, Programcı,
Veritabanı Analisti, vs.
• Konu Uzmanları
• Kullanıcı
• Yöneticiler
• Admin.’ler
• Süreç Uzmanları, Kalite Sorumluları, vs.
• 3rd Party
18. Paydaşların Çelişen İstekleri
• Bu paydaşların hepsinin farklı ve birbirleriyle
çelişen istekleri olabilir
• Başarılı bir projenin sağlaması gereken en
önemli şeylerden biri bu isteklerin sahipleri
arasında bir mutabakat sağlamaktır
• Mutabakat farklı çıkarlara sahip rollerin
çıkarlarını olabildiğince korumalarıyla
mümkündür
19. Yazılım Ekibi
• Yazılım geliştirme sürecine iştirak eden herkes
gereksinim yönetimi çalışmalarından farklı
şekillerde etkilenirler
• Problem çoğu yazılımcının teknik odaklarından
dolayı insan ilişkilerinde çok başarılı
olmayışlarıdır
• Öte yandan modern sistemlerin karmaşıklıkları
insan ilişkisini zaruri kılmaktadır
20. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
21. Altı Ekip Yeteneği
1. Problem analizi
2. Müşteri ihtiyaçlarını anlama
3. Sistemi tanımlama
4. Sistem kapsamını yönetme
5. Sistem tanımının revize edilmesi
6. Doğru sistemin geliştirilmesi
23. 2. Müşteri ihtiyaçlarını anlama
• En üst seviyedeki gereksinimler olası çözümün
tanımlanmasından çıkar
• Müşteriden bu gereksinimleri alabilmek için
hangi teknikleri kullanacağımıza nasıl karar
vereceğiz?
• Tıpkı bir marangoz gibi iş için gereken alet
edavatı kolayca tespit edebilmek
24. 3. Sistemi tanımlama
• Bir dizi gereksinimi nasıl organize edecek ve
oluşturulacak sistemin açık bir resmini
görebileceğiz?
• Alakalı ürünler arasındaki ortak gereksinimler
nasıl ilişkilendirilecekler?
• Ürünün vizyonunun dejenere olmaması için
onu detay gereksinimlerden nasıl
ayrıştıracağız?
25. 4. Sistem kapsamını yönetme
• Gereksinimler nadiren statiktir. Üç yaşındaki
çocukların ilgi alanı gibi her an değişirler
• Ürünün kapsamının kontrolden çıkmasını nasıl
sağlayacağız?
• Yapılması gerekenleri geciktirirsek kapsamı
nasıl kontrol edebiliriz?
26. 5. Sistemin tanımının revizyonu
• Yazılım ekibinin işini yapmaya kalkışmadan
onlar için gerekli detay seviyesindeki
gereksinimleri nasıl oluşturabiliriz?
• Detaylı gereksinimler vizyondan kopmamalı ve
sadece her küçük problem parçasının
çözülebilir olmasını sağlamalı
27. 6. Doğru sistemin geliştirilmesi
• Tasarımın gereksinimleri yerine getirdiğini
nasıl anlayacağız?
• Tasarımın müşteri isteklerine uygunluğundan
nasıl emin olacağız?
• Gereksinim değişikliklerini nasıl kontrol altına
alacağız?
28. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
29. Problemler ve Fırsatlar
• Sistemlerin en önemli iki nedeni:
– Problem çözmek; mevcut sistem müşteri
ihtiyaçlarını karşılamıyor demek
– Fırsatları değerlendirmek; yeni ürün düşünceleri,
yeni işlevler, yeni pazarlar vs.
• Biz problem çözmeye odaklanacağız
30. Problem Analizi Aşamaları
• Problem beş aşamada tahlil edilebilir:
– Problem tanımı üzerinde anlaşmak
– Problemin temel nedenlerini anlamak
– Paydaş ve kullanıcıları tespit etmek
– Sistemin sınırlarını tespit etmek
– Çözümü sınırlandıracak olan kısıtları bulmak
31. 1
Problem tanımı üzerinde anlaşmak
• Problem tanımı içeriği:
– Problemi tarif ediniz
– Etkilenen paydaşları belirtiniz
– Problemin paydaşlar ve yaptıkları işler üzerindeki
etkilerini belirtiniz
– Önerilen çözümü ve sağlayacağı faydaları ifade
ediniz
• Kısaca, neden bu problemi çözmek için
vaktimizi harcamalıyız?
32. 2
Problemin nedenlerini anlamak
• Problemin mevcudiyetinden emin olunca bir çözüm
oluşturmamız gerekiyor:
• Bir yol “temel neden” veya “nedensellik analizi”dir. Böylece
problemin mevcudiyet nedenini anlayabiliriz
• Bunun için ‘kılçık şeması’ (fishbone) çizebiliriz
– Düz bir çizgi çekerek problemi yazınız
– Sonra problem nedenlerini yazınız
– Daha sonra problem nedenlerinin nedenlerini yazınız
– Tekrar ediniz
33. 2
Problemin nedenlerini anlamak
12 m.
• ‘Akıl haritası’ (mindmap) çizebiliriz Boeing Uçak A.H.
34. 3
Paydaşları ve kullanıcıları tespit
• Sistemi kullanacak ve mevcudiyetinden
etkilenecek kişileri tespit edin
• Çoğu paydaş kullanıcıdır ama diğerleri
değillerdir
35. 4-5
Sistemin sınırlarını tespit
• En basit tanımıyla her sistem bazı girdiler alır
ve bazı çıktılar üretir
System
Inputs Outputs
• Püf noktası bu girdi ve çıktıları kimin veya
neyin üretip tükettiğidir
36. 4-5
Sistemin sınırlarını tespit
• Neler sistemin kapsamındadır?
– Paydaşların yerine kendimizi koyarsak,
– Kullanıcıların yerine kendimizi koyarsak,
– Yazılım ekibinin yerine kendimizi koyarsak,
• Dış sistemler hangileridir?
– Bağımlı olduklarımız,
– Bizim sistemimize bağımlı olanlar
37. 4-5
Sistemin sınırlarını tespit
• Sistem üzerine adı yazılı bir kutu ile gösterilir
• Aktörler çöpten adamlardır
• Dış sistemler ya adı üzerine yazılı bir kutu ya da daha yaygın olarak birer
aktör olarak gösterilirler
• İlişki çizgilerinin yönü veri akış yönünü gösterir
Stock Stock
Tracking Exchanges
End User
System
38. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
39. Paydaş ve Kullanıcı İhtiyaçları
“Stakeholder Requests”
• Gereksinimlerin bulunabilmeleri için yazılım
ekibi dikkatli olmalıdır
– Gereksinimleri açığa çıkarabilecek kavramları
değerlendiriniz
– “Bunu bir gereksinim olarak eklemek ister misiniz”
diye sorunuz ve bahsedilen düşüncenin önemini
saptayınız
• Çalışmalarınıza müşteri ihtiyaçlarını tespit
ederek başlayınız
40. Paydaş ve Kullanıcı İhtiyaçları
“Stakeholder Requests”
• En üst seviyedeki bilgi türümüz olan
ihtiyaçlarla problem tahliline başlayabiliriz
• Genellikle ihtiyaçlar sistemin çözmesi
beklenen temel bir problemle ifade edilirler
(bu problemi nelerin ortadan kaldıracağıyla)
• Bazı kullanıcılar işlevlere değinebilirler –
ihtiyaçların nasıl yerine getirilebilecekleri
41. İşlevler
“Features”
• İşlevler müşteri ihtiyaçlarının hangi ürün kabiliyetlerine
karşılık geleceğini ifade ederler
– İşlev sistemin bir ihtiyacı gidermek için sunduğu bir
hizmettir
• İşlevin faydası onun altında yatan ihtiyaçlara bakıldığında
kendisini gösterir
• Bir ihtiyaç sisteme değinmez; bunu bir işlev yapar
Örneğin,
Evden okula kayıt olabilmek istiyorum (ihtiyaç) -> Sistemin
internet erişimi olmalıdır (işlev)
42. Hangisi Hangisi?
• Kullanıcı görüşmesinde ihtiyaç ve işlev
ayrımını hemen yapmak gerekmez
• Daha sonra edinilen bilgilerin
düzenlenmesinde yardımcı olur
(brainstorming)
• İşlev örneği arıyorsanız, yazılım ürünü
reklamlarına bakınız!
43. İhtiyaç ve İşlev Sayıları
• İhtiyaçlar genellikle azdır – 10 veya daha az
• İşlevler sistemin büyüklüğüne göre genellikle
25-100 arasında değişirler
• Sistem kapsamı toplantıları için işlevler
kullanılırlar
44. İşlevler ve Gereksinimler
• İşlevlerin (feature) detayları ortaya dökülmeye
başlandığında gereksinimler (requirement)
ortaya çıkmaya başlarlar
• İşlev aşamasında geçici öncelikler verilebilir
• İşlevleri ileride kolayca yönetebilmek için
açıklamalarını yazınız
46. İşlev/Gereksinim Değişkenleri (Attribute)
– Değişebilirlik (Stability), işlevin ve ileride
implementasyonunun değişme olasılığı / derecesi
– Hedeflenen sürüm, Bu işlev hangi sürümde hazır
olacak?
– Görevli, Bu işlevle ilgili atama kime yapıldı?
Aşamasına göre farklı kişiler olabilir (gereksinim,
analiz vs.)
– Neden veya Kaynak – Bu işlevin kaynağı nedir?
47. İşlevler ve Gereksinimler
Üst seviye gereksinimler: İşlevler
“features”
Fonksiyonel gereksinimler Fonksiyonel olmayan gereksinimler
“functional requirements” “supplementary requirements”
49. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
50. Senaryo Odaklı Gereksinim Yönetimi
İhtiyaçlar
İşlevler
S e n a r y o O d a k lı Yo l G e le n e k s e l Yo l
Gereksinimler
+ =
Use-Case Modeli
Geleneksel Software Requirements Specification (SRS) dokümanı Use Case
Modeli ve Ek Gereksinimler Dokümanına (Supplementary Requirements) karşılık
gelmektedir.
51. Gereksinim Ürünleri (Artifact)
Use Case Modeli
Proje Sözlüğü
Aktörler (Glossary)
Use Case’ler
...
Ek Gereksinimler
Use-Case Dokümanları (Supplementary
Specification)
52. İlgili Roller
• Hazırlayan: İş Analisti, Sistem Analisti
• Faydalanan: Tasarımcı, Kullanıcı Arayüzü
Tasarımcısı, Ürün Kullanım Kılavuzu Yazarı,
Veritabanı Tasarımcısı
• Yardımcı: Müşteri, Müşteri Temsilcisi, Konu
Uzmanı
55. [1]
Vizyon
• Ürününüzün ilgili olduğu işi aklayan ve gerekli
kabiliyetlerini ortaya koyan genel bir
dokümandır
• Ne yapmak istiyorsunuz ve o iş neden
yapılmaya değer?
• Vizyon dokümanı içeriği:
– Giriş:
ürününüzün karşılık olduğu temel ihtiyaçlara
değininiz
56. Vizyon
– Konumlandırma (Positioning):
hitap ettiğiniz pazarın sizin açınızdan problemli yanlarını,
hedef kitlenizi ve rakiplerinizin ürünlerinin kabiliyetlerini
(ne yapıp ne yapamadıkları) yazınız.
– Paydaş Tanımları:
paydaşların demografik yapısını, ürününüzü kullanmak için
gereken kabiliyet seviyesini, paydaşlarınızın hedefleri ve
yaşadıkları sorunları belirtiniz. Her paydaş türüne bir
temsilci atayarak irtibat bilgilerini sağlayınız.
57. Vizyon
– Ürün işlevleri listesi:
ürünün sağlaması gereken temel işlevleri ve
bunların paydaşlara ne fayda sağlayacağını birer
ikişer cümle ile yazınız
66. [2]
Use Case Dokümantasyonu
• Monolog değil Dialog olmalı.
• Aktörleri ile Use Case arasındaki etkileşimleri
içermeli.
• Müşteri ile Tasarımcılar, Veritabanı
Tasarımcıları ve Arayüz Tasarımcıları
arasındaki köprü olmalı.
67. Use Case: Olayların Akışı
• Bir tane olağan, en tipik akış: Temel Akış (“Happy
Path”)
“Happy Path”
• Birden fazla Alternatif Akış:
– Başarılı alternatif akışlar
– Başarısız Akışlar hata durumlarını tolere etmeye
yarar
68. Senaryo Nedir?
Bir senaryo use case’in içerdiği akışların bir kombinasyonunun başlayıp
bitişidir: Use Case Instance.
69. Senaryolar
• Use Case akışlarının bir kombinasyonudur (use
case instance)
• Bir senaryonun beklenen (başarılı) bir neticesi
olabilir
– Müşteri kitaplarını satın aldı
• Veya başarısız bir neticesi olabilir
– Müşterinin kredi kartı kabul edilmedi
70. Senaryolar
• Her use case’in odağı başarılı Temel Akışı’dır
• Ancak pek çok başarılı ve başarısız Alternatif
Akış olabilir
– Alternatif senaryolar akış esnasında neler
olabileceğini tespit yollarıdır. Örneğin, farklı
şekillerde ödeme, bir transaction’ın bitirilememesi
gibi
71. Use Case Dokümanı Formatı
• Tek-sütun formatında her paragraf aktör veya
sistemin bir faaliyetini anlatır. Daha yaygın bir
kullanımdır.
• İki-sütun formatında sol sütun aktöre sağ
sütun sisteme aittir ve faaliyetleri ona göre yer
alırlar. Faydası dialoğun zigzag yapısını daha iyi
göstermesidir.
72. Use Case Dokümanı
Gelişim Süreci
Bulunma Tanımlanma
Konu Başlıkları + Kısa Tanımlar
Temel Akış Detaylanır Tüm Akışlar Detaylanır
73. Use Case Dokümanı İçeriği
• Dokümanın mutlaka içermesi gerekenler ‘*’
işaretlenmiştir.
– Temel Aktör*
– Paydaşlar ve UC’le ilgileri
– Precondition*
– Postcondition*
– Temel Akış*
– Alternatif Akışlar*
74. 1. Use Case Tanımı
– İlişkili Use Case’ler
– Ek Gereksinimler
– İş Kuralları
– Kullanım Yoğunluğu
– Açık Konular
75. 2. Temel Aktör
• Bir use case için temel aktör o UC’i kendine bir
fayda sağlamak için çalıştıran aktördür.
• Dolayısıyla bu aktör UC’i için bir tetik
mekanizmasıdır.
• Temel Aktör genellikle insandır. Ancak bazen
sistemler otomatik olarak dış sistemlere
erişirler.
76. 3. Paydaşlar ve UC ile İlgileri
• Bu bölümde use case’in akışında bir parçası
olan tüm aktörler ve kendilerine sağladıkları
faydalar belirtilmelidir
• Genellikle aktör başına bir iki cümle kafidir
77. 4. Temel Akış
• Herşeyin yolunda gittiği varsayılarak use case akışının adım
adım ve aktörle sistem arasındaki dialoğu işaret edecek
şekilde yazılmasıdır.
• Bu akış iş kurallarını, üretilecek ve tüketilecek veri yapılarını
ve yapılacak kontrolleri içerir.
• Bu akış use case’in beklenen kullanım şeklini ifade eder.
• Bütün adımlar aktör’ün perspektifiyle yazılır. Yalnızca onun
gördükleri ve yaptıkları ile sistemin bu davranışlara
reaksiyonlarını içerir.
78. 5. Alternatif Akışlar
• Temel akışın izlediği yolu değiştirebilecek
koşulları ve bu durumlarda kullanılacak yeni
akışları ifade eder
• Bu başarısızlık durumlarını içerdiği gibi (kredi
kartının reddedilmesi), farklı seçeneklerin
izlediği yolları da içerir (çekle, kredi kartıyla
veya paypal’le ödeme)
79. 5. Alternatif Akışlar
• Alternatif akışlar geçerli oldukları temel akış
adımında yanlarına harf konarak işaretlenirler
• Temel Akış
3. Kasiyer ürün numarasını girer
• Alternatif Akış
3a. Geçersiz numara
• Daha sonra da alternatif akış adımları yazılır
80. 5. Alternatif Akışlar
• Dolayısıyla alternatif akışların iki parçası olur:
• Nedeni: Başlığı
• Akışı: Kendine özel akışı
• Nedeni: 3a. Geçersiz ürün numarası
Akışı:
1. Sistem bir hata mesajı vererek ürünün
girilmesini engeller.
81. 6. Precondition
• Use Case’in çalışabilmesi için sistemin sahip
olması gereken durumu ifade ederler
• Bu liste temel aktörün o ana kadar yaptıklarını
ve yapmadıklarını, şu andaki use case’e
yönelmesine yol açan eylemleri içerebilir
82. 7. Postcondition
• Use case’in akışının tamamlanmasının
sonucunda sahip olunması gereken durumları
ifade eder
• Bu da precondition gibi temel akış referanslı
bir listedir. Herşey yolunda giderse use case
akışı sonunda elimize ne geçecek?
83. 8. Ek Gereksinimler
• Fonksiyonel olmayan gereksinimler veya use
case’e özel kısıtlamalar olabilir
– Performans, Güvenilirlik, Kullanılabilirlik ve
Tasarım Kısıtlamaları bu bölümde belirtilebilir
• Use Case’e özel olmayan bu tür gereksinimler
Ek Gereksinimler (Supplementary
Specification) dokümanında yer alır
84. 9. İş Kuralları
• Use Case akışı esnasında uyulması gereken işe
özel kuralları ve yapılması gereken kontrolleri
gösterir.
• Genellikle use case’e özel değil, proje
genelinde bir doküman olarak oluşturulur.
85. 10. Kullanım Yoğunluğu
• Use Case’in kullanım yoğunluğunun belirtildiği
bölümdür:
– Günde 1000 defa mı?
– Ayda 1 defa mı?
• Use Case öncelikleri hakkında fikir verdiğinden
tasarıma yardımcı olur
86. 11. Açık Konular
• Bu kısımda emin olmadığımız varsayımları,
muhtemel teknoloji değişikliklerini ve bunlar
gibi kesinleşmemiş konuların
unutulmamalarını sağlayabiliriz.
• Kesinleşmemiş hukuki, iş akışı ve interface
konularını da burada belirtebiliriz.
87. Bid on Item - Use Case Dokümanı
İnternette Açık Artırma
92. [3]
Ek Gereksinimler: FURPS+ Modeli
• Ek Gereksinimlerin kapsamı:
• Fonksiyonel (Functional)
• Kullanılabilirlik (Usability)
• Güvenilirlik (Reliability)
• Performans
• Bakım (Supportability)
• + = geriye kalan herşey
93. Fonksiyonel
• Tüm sisteme yönelik fonksiyonel
gereksinimler.
• UC odaklı olmayan yazılım geliştirme
yöntemlerini kullananlar için.
• Fonksiyonel gereksinimlerin tamamı aslında
UML yaklaşımında UC Modeliyle kapsanıyor.
94. Kullanılabilirlik (Usability)
• Kullanılabilirlik:
– İnsan faktörü; sisteminizi kullanmak nasıl
hoşnutluk verici olabilir?
– Help; Kullanıcıya hangi help imkanı sağlanacaktır?
F1? Context sensitive? Online kullanım kılavuzu?
– Dokümantasyon; Kullanıcıları eğitmek için ne tür
dokümantasyon üretilecektir?
95. Güvenilirlik (Reliability)
• Güvenilirlik ölçüm şekilleri:
– Mean Time Between Failures (MTBF); İki sistem
göçmesi arasında geçen zaman
– Mean Time To Repair (MTTR); Sistem göçtüğünde
çalışır hale getirilmesi için gereken zaman (Bu
‘bakım’ başlığı altında da olabilir)
– Sistemin kullanılabilir durumunu koruması
(Availability) ‘performans’ başlığı altında yer alır
96. Performans
• Çoğu performans kriteri gereksinime dönüşür
– Sorgu cevaplama süresi (ortalama, maksimum)
– Throughput (Saat veya gün başına işlenen kayıt
sayısı, transactions per second (TPS))
– Accuracy (scan veya veri giriş doğrululuğu)
– Kaynak kullanımı (CPU, HDD kullanımı, network
trafiği)
97. Bakım (Supportability)
• İçeriği:
– Bakım prosedürünü içerir. Sorunlar için kılavuz mu
sunacaksınız?
– Sistemin bakımını yapmak ne kadar kolay? Yazılımı
ve Donanımı birlikte düşününüz.
– Internationalization; sisteminiz farklı dillerde
kullanılabilecek mi?
– Sisteminizin konfigürasyonu kolayca değiştirilebilir
mi?
98. “+”
• İçeriği:
– İmplementasyon
– Interface
– Operasyonel
– Paketleme
– Kanuni konular
– Ve aklınıza ne gelirse!
99. “+” - İmplementasyon
• İmplementasyon üzerindeki sınırlamaları ifade
eder:
– Kaynak sınırlamaları (maliyet, zamanlama,
eleman)
– Dil ve ürünler (kullanılacak programlama ortamı)
– Donanım (Dell)
– Yazılım (MySQL)
– Kullanıcı PC özellikleri (PIII 1000 MHz, 128 MB
RAM, Windows ME)
100. “+” - Interface
• Interface gereksinimleri dış sistemlerle
haberleşme amaçlıdır:
– Kurumuzdaki eski sistemler
– Bileşenlerini satan şirketler
– Başka proje ekipleri
– Dış kurumlar (İMKB vs.)
101. “+” - Operasyonel
• Sisteminiz kullanım halindeyken
yönetilebilmelidir
• Yöneticilere gereken kabiliyetler?
– Kullanıcı ekleme
– Kullanıcı erişim haklarını değiştirme
– Kaynak kullanımını izleme (CPU, disk, network)
– Fiziki ortamı izleme (ısı, nemlilik)
102. “+” - Paketleme
• Ürününüz nasıl paketlenecek?
– Medya? CD-ROM? DVD?
– Hangi dokümanlar basılacak? Hangileri elektronik
ortamdan sağlanacak?
– Kullanıcılar için help desk kimlerden oluşacak?
– Farklı ülkelere özel çalışmalar yapılacak mı?
103. “+” - Kanuni
• Ürününüz nasıl lisanslanacak?
– Kullanıcı başına? Şirket başına?
– PC başına?
– CPU başına?
• Ürününüzün farklı versiyonları var mı?
(akademik, profesyonel)
• Ürününüzün satılamayacağı yerler var mı?
(ihracat kısıtlamaları)
106. [4]
Sözlük (Glossary)
• Proje terimlerini içerir:
– Terim 1, Terim 2, … Terim N
• Kısaltmaları ve use case dokümanlarında ifade
edilseler çok yer kaplayarak okunmayı zorlaştıracak
veri yapısı tanımlarını içerir
• Tanımlar dokümanda olabilir veya başka bir
dokümanı refere edebilir
• Sözlük hyperlink’ler içerebilir
107. İçerik
• Proje Başarısızlığı Nedenleri
• Gereksinim Yönetimi Kavramları
• Gereksinim Yönetimi Teknikleri
• Problem Analizi Teknikleri
• Gereksinim Türleri
• Gereksinim Dokümanları
• Önceliklendirme ve Takip Edilebilirlik
108. Gereksinimleri Önceliklendirme
• Tüm gereksinimler (özellikle use case modelindeki
fonksiyonel gereksinimler) için öncelikler belirlemeli
ve ona göre zaman planı yapmalıyız.
• Önceliklendirme gereksinim değişkenleri kullanılarak
yapılmalıdır:
– {Tür: Zaruri, İstenen, Seçeneğe Tabii}
– {Sistem Mimarisine Etki: Var, Yok}
– {Emek: Zor, Orta, Kolay}
– Vs. vs.
120. İlham Kaynakları
James Bielak
Alistair Cockburn
Ellen Gottesdiener
Notas do Editor
Yazılım projeleri üzerine araştırma yapan kuruluşların çalışmaları arasında büyük paralellikler görüyoruz. Bu çalışmaların en önemli bulgusu ise yazılım projelerinin en az teknolojik ve teknolojiyi kullanma nedenleri kadar proje gereksinimleriyle ilgili konulardan da başarısızlığa uğradıkları. Gereksinimlerle ilgili başarısızlık konularına değinmeden, bir başarılı proje tanımı yapacak olursak, “ Başarılı bir yazılım şirketi taahhüt ettiği kaliteli yazılımı zamanında ve bütçesini aşmadan sağlar.” Murray Cantor, Software Leadership Bu hedefi gereksinimler nedeniyle gerçekleştirememe nedenleri arasında en önemli bulunanları: Yokluk: Kullanıcı fikirlerinin gerektiği kadar alınmaması ve alınan bilgilerin yoruma açık bir şekilde saklanmaları. Bilgilere tekrar başvurulduğunda yazılım ekibi elemanlarınca farklı (kişiye özel) bir şekilde anlaşılarak, farklı çözümlere neden olunması. Eksiklik: Derlenen gereksinimlerin eksikliklere sahip olması. Farklı bilgi türlerinin ve farklı yazılım disiplinlerine (Gereksinim, Analiz, vs.) ait çalışmaların karışık bir şekilde hazırlanmaları ve sunulmaları sonucunda eksikliklerin kendilerini gizlemesi. Eskilik: Gereksinimlerdeki değişiklikleri takip edilememeleri. Değişen gereksinimlerin sistem geneline ve tasarıma etkisinin tespit edilememesi.
Murray Cantor’ın başarılı yazılım şirketi tanımını hatırlarsak, “ Başarılı bir yazılım şirketi taahhüt ettiği kaliteli yazılımı zamanında ve bütçesini aşmadan sağlar.” Peki, Kaliteli Yazılım nedir? Gereksinimlere bağlı çalışır Eksiksiz ve güncellenmesi kolay dokümantasyona ve iş ile sistem tarafını bir araya getiren ortak bir dille yazılan modellere sahip olmalıdır. Etkili proje ve risk yönetimi ile metriklerle denetlenerek oluşturulur. Esnek ve ölçeklenebilir bileşen bazlı bir sistem mimarisine sahiptir . Mevcut çalışmalarımızdan olabildiğince yararlanarak oluşturulur . Üstteki kaliteli yazılım hedeflerini sağlamak için, Duyarlılık: Kullanıcı fikirlerine özel bir önem verilir. Bu fikirlerin değerlendirilmesi, onaylanması ve değişikliklerinin takibi için tanımlı yöntemler geliştirilir ve kullanılır. Destek: Yönetimin kaliteye yönelik tam desteği alınır ve böylece gerekli kaynak ihtiyaçları karşılanır. Yönetim desteğini almayan yazılım kalitesi çalışmaları büyük ölçüde başarısızlığa uğramaktadırlar. Açıklık: Gereksinimlerin ifadeleri için yoruma açık olmayan ve tüm muhataplarının kolayca anlayabileceği bir dil ve detaylandırma şekli kullanılır.
Gereksinim hatalarını yazılım sürecinin ilerleyen aşamalarında bulmak tasarım, kodlama, test, test prosedür ve kodlarını yazma ve dokümantasyon güncelleme gibi faaliyetlerin tekrarlanmalarına yol açar. Maliyeti bu derecede yükselten bu tür tekrarlardır. Etkili proje takımlarının hataları tespit eder etmez onlara müdahale edebilecekleri istenir. Ancak hataları zamanında tespit ve müdahale için yöntemlere sahip olmamız gerekir.
Gereksinim Yönetimi (Requirements Management): Gereksinimleri bulmak, Gereksinim türlerine ayrıştırmak ve aralarındaki takip ilişkilerini tanımlamak, Dokümantasyon şablonlarını belirlemek, Çalışma tür ve bunları gerçekleştirecek rolleri belirlemek, Değişikliği yönetebilmek ve Analiz ve Tasarım çalışmalarını buna göre yönlendirebilmek için gereken disipline denir.
Gereksinim Yönetimi Kavramları İhtiyaç (Need): Müşterilerin geliştirilecek veya mevcut sisteme yönelik olarak talep ettikleri ve işlerini yapabilmek (veya daha kolay ya da daha kaliteli bir biçimde yapabilmek) için gereksinim duydukları ihtiyaçlarıdır. Bu durumu ifade etmek için sık kullanılan diğer bir terim, Müşteri İstekleridir ( Stakeholder Request ). Sistem zaten mevcutsa, ihtiyaçlar hata düzeltme ( bug fix ) veya özellik ekleme ( enhancement request ) talebi olabilirler.
Gereksinim Yönetimi Kavramları İşlev (Feature): Müşteri isteklerinin derlenip değerlendirmeleri sonucunda belirlenen ve sistemin yerine getireceği taahhüt edilen (genellikle bir tür kontrat özelliğine sahip bir dokümanda yer alan) en üst seviyede tanımlanan gereksinimlerdir. Gereksinim (Requirement): İşlevlerden daha detay bilgi veren ve sistemin özelliklerini yazılım ekibinin anlamasını sağlayan gereksinimlerdir. Kendi içinde iki gruba ayrılır: ‘Fonksiyonel’ ve ‘Fonksiyonel Olmayan.’ Bazen ‘İster’ veya ‘Sistem İsterleri’ olarak adlandırılırlar. Gerçekleştirme (Realization): Gereksinimlerin ilgili alana (Analiz, Tasarım, Kullanıcı Etkileşimi, Veritabanı, vs.) nasıl uygulanacağının gösterilmesidir. Gerçekleştirme İlişkisi: Gereksinimleri Analiz ve Tasarım çalışmalarına bağlamak için kullanılan ve takip edilebilirliği sağlayan ilişkilendirme yöntemidir. İşlevler ve Gereksinimler arasında birebir bir sayı ilişkisi yoktur. Bir işlevden bir veya pek çok gereksinim ortaya çıkabilir. Bunun tersi de mümkündür. Bununla birlikte bizler senaryo odaklı bir gereksinim yönetimi (use case) kullanacağımızdan, şunu söyleyebiliriz: Ortalama olarak işlev sayısı 25-50 arasındadır. Nadiren 100’e yaklaşır. Aynı şekilde 20’li – 30’lu rakamlar use case’ler için yüksek sayılardır. Ancak Use Case’lerin dokümanlarında gereksinim sayısı yüksek olabilir. Ayrıca gereksinimler içeren diğer dokümanlar da mevcuttur. Örneğin ek gereksinimler (supplementary requirements) dokümanı gibi. Dolayısıyla, işlevlerin sayısı use case’lerden çok fazla olabilir. Aynı şekilde, kullanılan işaretleme yöntemine göre de use case dokümanlarındaki gereksinimlerin sayısı işlevlerin sayısını aşabilir.
Sistemin özelliklerini beyan eden farklı detay seviyelerindeki bilgi türlerinin proje süreci içerisinde ortaya çıkış sırası aşağıdaki gibidir: | 1 | Müşterinin Probleminin Tanımı [i] Müşteri İstekleri (Stakeholder Requests): İsteklerin ilgili oldukları konu ve yöneltilen sistemin geliştirilecek veya mevcut olmasına bağlı olarak farklı terimlerle ifade edilebilen, daha onaylanmamış ve sistemin sahip olması taahhüt edilen kabiliyetleri arasında sıralanmamış isteklerdir. İhtiyaç (Need) Hata Düzeltilmesi (Bug Fix) Ek Özellik Talebi (Enhancement Request) | 2 | Çözümün Tanımı [i] Sistem İşlevleri (Features): Sistemi geliştirecek ekiplerle birlikte müşterin bir taahhüt ilişkisi kurmalarını sağlayan Vizyon dokümanının içinde ifade edilen sistemin sahip olmasına karar verilen kabiliyet listesidir. En üst seviye gereksinimler olarak da ifade edilirler. [ii] Gereksinimler (Requirements): Yapısal özelliklerine göre farklı isimler alabilir ve sistemin sahip olmasına karar verilmiş özelliklerinin detaylarını ifade ederler. Fonksiyonel Gereksinimler (Use Case Requirements) Fonksiyonel Olmayan Gereksinimler (Supplementary Requirements) | 3 | Çözümün Gerçekleştirilmesi Gereksinimlere dayanılarak Analiz, Tasarım, İmplementasyon vs. çalışmalarının yapılmasıdır.
Gereksinimler pek çok farklı kaynaktan doğabilirler. Yazılımın yönelik olduğu iş türüyle ilgili yeni bir fırsatın ortaya çıkması beraberinde yeni iş akışlarını, dolayısıyla, yeni yazılım gereksinimlerini getirecektir. Diğer bir sık rastlanan kaynak, müşterilerin karşılaştıkları zorluklardır. Bu zorluklar mevcut sistemin yeni geliştirilecek bir sistemler yer değiştirmesi sırasında dile getirilebilir. Eğer yeni bir sistem geliştirmek ziyade mevcut sistemin bakımı söz konusu ise bu zorluklar daha çok hata giderme ve ek özellik geliştirme şeklinde ifade edileceklerdir. Yukarıda değindiğimiz iki türden farklı olarak müşteri memnuniyetini kötü olarak etkilese dahi uymak zorunda olduğumuz tasarım kısıtlamaları olabilir. Bu kısıtlamalar tasarımı direkt olarak yönlendiren gereksinimler ortaya çıkarabilir.
Yazılım projelerinde en sık yaşanan sıkıntı gereksinimlerle tasarımı birbirine karıştırmaktır. Bu problemin ortadan kaldırılması için en etkili yol çıkarları birbirleriyle çelişen müşteri istekleri temsilcisi (Sistem Analisti) ile geliştirilecek yazılım tasarımını yapacak kişileri (Tasarımcı) birbirlerinden net bir biçimde ayırmaktır. Bu iki rolün faklı kişilerce canlandırılması çok önemli bir proje başarısı nedenidir. UML süreci bu karışıklığı kolayca bertaraf edebilmek için geleneksel çalışma şeklinde analiz olarak adlandırılan akış, veri yapısı ve iş mantığı bilgisi toplama çalışmalarını ‘Gereksinim Yönetimi’ disiplini içine kaydırmış ve tüm Analiz ve Tasarım çalışmalarını bu bilgilerle beslenen yeni çalışma türleri olarak ifade etmiştir. Yine aynı mantıkla, İş Modeli ve İş Süreçlerine yönelik çalışmalarını (Business Modeling) da gereksinim yönetimi çalışmalarından ayrı ve onlardan önce gelen çalışmalar olarak tanımlayarak bu karışıklıklara son vermiştir.
Gereksinimler toplanmaya başladıktan sonra göreceli önceliklerinin saptanması gerekir. UML süreci içerisinde bu öncelikler kullanılarak kademelendirme ve yazılımın parça parça geliştirilmesi mümkün olmaktadır. Öncelikleri ifade etmek için farklı terimler ve farklı sayısı öncelik kademeleri belirlemek mümkündür. Bunları ihtiyaçlarınıza göre tanımlayabilirsiniz. Bununla birlikte, bu kademelendirme içinde mutlaka “ Sistemin Görevini Yerine Getirebilmesi için Sahip Olması Zaruri”, “Sistemin Sahip OlmasıArzulanan” ve “ Olmaması Eksiklik Hissi Uyandırmayan” kabiliyetlerini birbirlerinden ayırt edebilmeniz gerekir. Bu ayrımları yaparken sizlere yol gösterecek farklılıklar, Gereksinimlerin sistem mimarisini etkileyip etkilememeleri, Gereksinimlerin sistem mimarisine etkilerinin oranları, Teknolojik yenilik nedeniyle ortaya çıkan bir gerçekleştirme riski, Gerçekleştirilecek sistem kabiliyetinin herhangi bir nedenden (mevzuat karmaşıklığı, algoritmik karmaşıklık, vs.) ötürü sahip olduğu zorluk olabilir.
UML Süreci içerisindeki en önemli kavramlardan bir tanesi paydaştır. Süreç yapısı projenin sorumluluğunu paylaşan herkesin fikirlerini ifade edebilmelerine ve yoruma açık olmayan bir şekilde haberleşebilmelerine imkan vermektedir.
Paydaş türlerine örnekler verecek olursak, ‘ Sponsor’ ürünün maliyetini üstlenen ve gereksinim sohbetlerine noktayı koyacak kişidir, ‘ Tasarımcı’ ve ‘Programcı’ ürünü tasarlayan ve oluşturan kişilerdir, ‘ Konu Uzmanları’ gereksinimlerin konularıyla ilgili kısımlarında destek verirler, ‘ Kullanıcı’ geliştirilen sistemi gündelik işini görürken kullanacak kişidir, Sponsorlar ile Kullanıcılar arasında ürünü arada sırada kullanan ‘Yönetici’ ler olabilir, Sistemin bakımını yapanlar, ‘Administrator’ , olabilir, Bunlar sadece backup alan kişiler bile olabilir, Sisteme dış kaynaklardan alınan bileşenleri temsil edenler olabilir, ‘ Süreç Uzmanları’ ve ’Kalite Sorumluları’ olabilir. Örnek olarak bir Hava Trafik Kontrol Sistemini alırsak, Sponsor (İşin mali boyutunu üstlenen) : T.C. Hükümeti, Yazılım Ekibi (Sistem Analisti, Tasarımcı, Programcı, Veritabanı Analisti, Kullanıcı Arayüzü Tasarımcısı, vs.) : TAV ve THY Uzmanları, Konu Uzmanı (Domain Expert) : THY Uzmanları Yöneticiler: THY ve TAV Kullanıcı: Kule Elemanları Administrator: Kule Bakım Ekibi Ürün Temsilcileri: IBM, Sparx Systems Süreç Danışmanı: Anyspec BT Danışmanlık
Farklı çıkarlara sahip ve farklı dilleri konuşan gruplar arasındaki anlaşmazlıklar kaçınılmazdır. UML süreci bu farklı grupları yazılım rolleri olarak tanımlayarak, aralarındaki iş bölümü, sorumluluklar ve yetki alanlarının kesin bir biçimde belirlenmesiyle, uyumlu bir ekibe dönüştürmeyi hedeflemektedir. Proje başarısı (projenin taahhüt ettiklerini yerine getirerek müşterisini memnun etmesi) için paydaşların çelişen çıkarlarının birer sağlama mekanizması olarak olabildiğince korunması ve bu çıkarlar arasında bir mutabakat sağlanması gerekir. Bu mutabakat ihtimalinin varsayımı paydaşların birbirlerini net bir şekilde anladıklarıdır ki UML’in de en önemli faydalarından bir tanesi budur.
Yazılım Ekipleri yüzlerce kişiden oluşmakta ve bu kişiler gereksinim değişikliklerinden farklı şekillerde etkilenebilmekteler. Gereksinim Değişikliklerine uyum sağlayabilmek işin bir tarafı, daha önemli sorun ise gereksinimleri yoruma açık olmayan bir şekilde anlamak ve gruplar arasında taahhütler oluşturabilmek. Bu taahhütler sayesinde proje sürecinin kontrol altına alınabilmesi ve değişikliklerin yönetilebilmesi mümkün olacaktır. Problemlerin çoğunlukla nedeni yazılımcıların görevleri gereği, geliştirilecek sistemin detayları içinde kaybolmaları ve müşteriye olan duyarlılıklarını kaybetmeleridir. Bu gibi durumlarda etki gücü fazla olan grup, Bazen müşteri temsilcisi bazense yazılım ekibindeki rollerden biri, diğer çalışmaları kötü olarak etkileyebilmekte; geliştirilecek yazılımın tasarımını tek başına yönlendirebilmektedir. Bazı ileri vakalarda gruplar arasındaki Sürtüşmeler olağan kabul edilerek şirket içerisinde farklı ‘kavim’lerin ortaya çıkmalarına neden olabilmektedir. Dolayısıyla, pek çok kez gerçekte ekibin verimliliğini sağlamak kişisel verimliliği artırma yöntemlerinden ötesine muhtaç.
Gereksinim Yönetimi çalışmalarımızı altı yeteneğimize odaklanarak geliştireceğiz: [2] Müşteri İhtiyaçlarını Anlama En üst seviyedeki gereksinimler (Temel İşlevler, Sistem İşlevleri, Features) çözümü tanımlamaya çalıştığımızda ortaya çıkarlar. Bu durumda karşımıza çıkan temel soru bu gereksinimleri tespit yollarının neler olduğudur. UML sayesinde tıpkı bir marangozcunun hangi işle uğraşırsa uğraşsın bir alet kutusuna sahip olmasını yazılım ekiplerine de sağlamak mümkün olmuştur. Üst seviye gereksinimleri ortaya çıkarmak (Stakeholder Requests) ve bulgularımızı sergilemek (Vision) için tanımlı dokümanlar mevcuttur.
[3] Geliştirilecek Çözümün (Sistemin) Tanımlanması Bu aşamada karşımıza çıkan sorulara verebileceğimiz cevaplar, Gereksinimleri aynı hedefe yönelik senaryo grupları haline getireceğimiz (use case’ler), Bu kullanım senaryolarının farklı sistemler (farklı ürünler) olarak birbirlerini tamamlayabilecekleri ve Ürün vizyonunun Kullanım Senaryoları Şemaları ve Dokümanları aracılığıyla detaylandırılacağıdır. Ayrıca, fonksiyonel olmayan gereksinimleri de Ek Gereksinimler doküman şablonunu kullanarak detaylandıracağımız.
[4] Sistem Kapsamını Yönetme Kapsamın sınırını çizmeyi elimize çok detaylı gereksinimler geçene kadar bekletirsek ürün kapsamı kontrolümüzden çıkacaktır. O zaman detayları daha sonra ortaya çıkarabileceğimiz bir sistem sınırları belirleme yöntemi kullanmalıyız: Kullanım Senaryoları (Use Case’ler)
[5] Sistem Tanımının Revizyonu Yazılım ekibinin işini yapmamızın engellenmesi UML süreci içerisinde şöyle sağlanmaktadır: Akış, veri yapısı ve iş kuralları bilgilerini (Use Case Modeli) Sistem Analisti derlenmektedir. Tüm analiz ve tasarım çalışmaları (Analiz ve Tasarım Modelleri) nesne teknolojilerine, programlama diline ve proje konusuna hakim bir Tasarımcı tarafından yapılmaktadır. Böylece ‘Ne’ ile ‘Nasıl’ arasına net bir sınır çizilmektedir.
[6] Doğru Sistemin Geliştirilmesi Değişiklik Yönetimi ve geliştirilen sistem içerisindeki Takip Edilebilirliği UML sürecinde şöyle sağlayacağız: Kullanım Senaryoları proje gelişimi süresince çalışmalarımızı alakalandırmak ve müşteri isteklerine bağlamak için kullanılacaklar. Böylece hem müşteri memnuniyetini hem de değişikliklerin etkilerini tolere edebilmeyi sağlayacağız.
[1] Problem Analizi Kullanacağımız problem analizi tekniğinin sahip olduğu beş aşama ileride detaylarını inceleyeceğimiz üst seviye gereksinimleri sıraladığımız (feature) bir doküman olan Vizyon’un bölümleri ile Use Case Modelinin ilk çalışması olan sistem genelini resmettiğimiz ‘ Sisteme Genel Bakış’ use case şemasına karşılık gelmektedir. Bu çalışmalar bittiğinde, Problemin mahiyeti; nedeni ve olası çözüm, Çözüm ola ra k geliştirilecek sistemin etkilediği paydaşlar ve sistemin kullanıcıları, Sistemin sahip olması gereken kabiliyetler ve vereceği hizmetlerin sınırları ile Geliştireceğimiz çözümün kapsamını etkileyecek kısıtlamalr hakkında bilgi sahibi olacağız. Bu bilgilerin ötesindeki detaylar daha sonra sistemin parçaları arasında öncelikler belirlendiğinde oluşturulacaktır. Bütün bu bahsettiğimiz çalışmaları ‘Gereksinim Modeli’ olarak da adlandırabiliriz. Bu durumda kasdedilen, çeşitli dokümanlar (Müşteri İstekleri, Vizyon, Use Case Dokümanı, Ek Gereksinimler Dokümanı) ve Use Case Modeli’dir.
[1] Problem Analizi i. Problem Tanımı Üzerinde Anlaşmak Yaygın olarak başvurulan problem tanımı formüllerinden bir tanesi, “ The problem of {problem description} affects {the stakeholders affected by the problem } the impact of which is {what is the impact of the problem?} a successful solution would be {list some key benefits of a successful solution }”
[1] Problem Analizi ii. Problemin Nedenlerini Anlamak Kılçık Şemasını (Fishbone Diagram) bir kalite kontrol istatistikçisi olan Dr. Kaoru Ishikawa geliştirmiştir. Kılçık Şeması problemin etkilerine ve bu etkileri ortaya çıkaran (veya katkıda bulunan) nedenlere sistematik bir bakış imkanı sağlayan bir ‘Nedensellik Analizi Tekniği’dir. Bu özelliğinden dolayı şemanın diğer bir adı da ‘Neden-Sonuç Şeması’dır. Eğer, Bir sorunun temel nedenini bulmaya çalışıyorsanız, Bir sürecin neden sorunlar yaşamaya başladığını tüm nedenlerini ortaya koyarak anlamak istiyorsanız, Bir konuyla ilgili veri toplamanız gereken alanlarını saptamak istiyorsanız veya Bir sürecin neden arzulanan sonuçları sağlamadığını anlamak istiyorsanız kullanılabilen bir tekniktir. Tekniğin Uygulanma Aşamaları a) Düz bir çizgi çizerek (Balığın başı) incelemek istediğiniz sorunu yanına yazınız. b) Bu çizgiye neden kategorilerini ekleyiniz: 4 M ( Methods, Machines, Materials, Manpower ), 4 P ( Place, Procedure, People, Policies ), 4 S ( Surroundings, Suppliers, Systems, Skills ) Bu kategorilere kendinizinkileri de ekleyebilirsiniz. c) Her kategoriye ait sorun nedeni olan faktörleri bulmaya çalışınız. Bunu yaparken fikir ortaya çıkaran başka teknikleri (brainstorming gibi) kullanınız. Birbirinize sorunuz: “ {Problem adı} problemine neden olan veya katkıda bulunan {kategori adı} faktörleri nelerdir? ” d) Bulduğunuz faktörleri alt-faktörlere indirgeyene dek ‘Neden’ sorusunu sormaya devam ediniz. e) ‘Neden’ sorusuna mantıklı cevaplar alamamaya başlayıncaya kadar çalışmayı sürdürünüz. f) Birden fazla kategoride kendini gösteren (gerçek neden olma ihtimali yüksek) faktörleri saptayınız. g) Bulunan gerçek neden adaylarını aralarında bir önem sırasına sokunuz. İlkini birincil neden olarak kabul ediniz.
[1] Problem Analizi iii. Paydaşları ve Kullanıcıları Tespit Sistemi paydaşlarından bağımsız olarak ele almak bizi onun kullanılacağı gerçek dünyadan uzaklaştırır. Bunun gibi durumlarda yazılım ekibi tasarımın kontrolünü müşteri memnuniyetini kötü olarak etkilediğini farketmeden tek başına yönlendirir. Sistemle dolaylı veya direkt olarak bir ilişkisi olan her grubu, kullanıcılar (end-user) ve yazılım ekibini de içine alacak şekilde tanımlayınız. Fayda ve Senaryo Bazlı olarak yürüteceğimiz çalışmaların başarısı bu paydaşların eksiksiz bir biçimde bulunmuş olmalarına bağlıdır. Muhatabının varlığından bihabersek, sistemin ona sağlaması gereken faydayı da bulamayız.
[1] Problem Analizi iv. - v. Sistemin Sınırlarını Tespit Sistemin sınırlarını belirlerken kullanabileceğimiz bir araç sistemle etkileşen birimlerin kimler veya neler olduğunu belirlemektir. Bu ihtiyaç UML süreci içerisinde, Use Case Modeli oluşturulurken, Aktörlerin Tanımlanmalarıyla sağlanmaktadır.
[1] Problem Analizi iv. - v. Sistemin Sınırlarını Tespit Sistemin sınırlarını belirlerken kullanabileceğimiz en önemli araçlardan olan Aktörlerin Tanımlanma çalışmalarını detaylandırısak, Girdi ve çıktıların çoğu ya bir aktör (kullanıcı veya paydaş) ya da dış bir sistem tarafından tetiklenirler. Tespit etmemiz gereken nelerin bizim sistemimiz kapsamında olduğu ve nelerin olmadığıdır. Dikkatimizi sistemimizle direkt olarak etkileşecek nesnelere yöneltmeliyiz: Süpermarkette kasayı biz kullanıyor musunuz? Dış sistemler şunlar olabilir: Kurumunuzdaki eski sistemler (insan kaynakları veri tabanı, muhasebe modülü vs.), Dış firmaların sistemleri (eğer sisteminiz onlarla, örneğin, kredi kartı tahsilatı için direkt olarak etkileşiyorsa), Sistemin içinde bulunduğu ortamdaki sensörler (ısı, nem, güç kaynağı vs.). İnternetten otomatik olarak alınan bilgiler (hisse senedi değerleri vs.) Sistemin farklı yerlerdeki kullanıcılarını unutmayın (ev, şube vs.). Sistem sınırları içinde kalanlar sizin direkt kontrolünüz altındaki alanlardır: Neticede tasarımını yapıp, kodunu yazmayacaksanız o kısımlar sisteminizin dışındadır.
10 Aşamalı Müşteri İstekleri Analizi [1-4] Kim için ne üretiyorsunuz? Başarınız ne ile ölçülüyor? Başarınızı engelleyenler nedir? İşinizi daha kolay yapmanızı neler sağlar? 2) Hangi konularla ilgili iyi çözümlere sahip değilsiniz? ‘Eklemek istedikleriniz var mı?’ a) Problem neden mevcut? Nasıl çözüyorsunuz? Nasıl çözülmesini istersiniz? 3) Kullanıcılar kimler? Eğitim ve Deneyimleri neler? Hangi platform kullanılıyor? Uygulama diğer hangi uygulamalarla ilişkili? Kullanım Kolaylığı beklentileriniz nelerdir? Ürün Eğitimi sizce ne kadar sürmeli? Ne tür help ve kullanım kılavuzlarına ihtiyacınız var? 4) Bana söylediğiniz problemler şunlar: 1, 2, 3, vs. Mevcut çözümle ilgili sorunlarınızı bu liste özetliyor mu? ‘Eklemek istedikleriniz var mı?’
10 Aşamalı Müşteri İstekleri Analizi [5-10] 5) [Önce paydaşın aklına gelmeyen problemleri sıralayınız ve daha sonra her biri için] Bu gerçekten bir problem midir? Problem neden mevcut? Nasıl çözüyorsunuz? Nasıl çözülmesini istersiniz? Bu problemi sizin değindiklerinizle karşılaştırarak önemini söyleyiniz. 6) Eğer şunu yapabilseydiniz [önerdiğiniz çözümün temel kabiliyetlerini sıralayınız]? Bu kabiliyetleri karşılaştırarak önemlerini söyleyiniz. 7) Bu uygulamaya kimlerin ihtiyacı var? Toplam kullanıcı türü sayısı nedir? Başarılı bir çözümün sizce önemi nedir? 8) Sistem güvenilirlik ve performans beklentileriniz nedir? Sistemin bakımını kim yapacak? Özel bakım ihtiyaçlarınız var mı? Güvenlik gereksinimleriniz nedir? Yükleme ve Uyarlama gereksinimleriniz nedir? Lisanslama gereksinimleriniz nedir? Yazılımın dağıtım, paketleme ve etiketlendirme gereksinimleri nelerdir? Hangi yasal yükümlülükleriniz ve uymakla zorunlu olduğunuz standartlar var? Bunların dışında ‘eklemek istedikleriniz var mı?’ 9) Sormam gereken başka bir şey kaldı mı? Eğer başka sorular aklıma gelirse sizi arayabilir miyim? Gereksinimlerin onaylanması aşamasında yer almak ister misiniz? 10) [Görüşmenin bir özetini oluşturunuz] Paydaşın en önemli 3-4 problemini aşağıda bulabilirsiniz: i. ii. iii. iv.
Müşteri isteklerini derledikten sonra yapılması gereken bu ihtiyaçları sistem kabiliyetleri kapsamında (işlevler) gruplamaktır. Bu gruplamanın sonuçları Vizyon dokümanının ‘Sistem İşlevleri’ (Features) bölümünde listelenecektir. İhtiyaç giderilmesi arzulanan ve belli bir önceliğe sahip olan bir sıkıntıdır. İhtiyaç ifade edilirken bunun sistem tarafından nasıl destekleneceğini belirtilmez. Bunlar ihtiyaçlar gruplanarak işlevlere dönüştürülürken ortaya çıkacaktır.
Kullanıcı görüşmelerinde, ‘Müşteri İstekleri’ (Stakeholder Requests) dokümanının içeriğini hatırlarsanız, derlenen istekler bu isteklerin bir listesinin oluşturulduğu aşamada sistem işlevlerine dönüştürülmeye veya bahsi geçen konunun aslında bir işlev olup olmadığına bakılmaz. UML süreci içindeki en önemli konulardan birisi çalışma türleri, aranılan veya üretilen bilti türleri ve detay seviyeleri, bu çalışmaların ne zaman bitmiş kabul edilebilecekleri, bu bilgilerin kim tarafından ve kimler için üretileceklerinin açık ve kesin bir şekilde belli oluşudur. Dolayısıyla, müşteri istekleri derleyen Sistem Analisti rolü bir işini yaparken oluşturduğu doküman ve model öğelerini adım adım ürettiğinden anlık ihtiyaçlara / görevlere odaklanacaktır.
Gereksinim Yönetimi çalışmalarında derlenen bilgilerin yazılım ekibini korkutabilen özelliklerinden bir tanesi sayılardır. Sayıların büyüklüğü ve küçüklüğü çoğu kez zorlukla (dolayısıyla taahhütlerinin yerine getirilip getirilemeyeceğiyle) alakalandırılması bunun en önemli nedenidir. Oysa ihtiyaç, işlev ve daha ileride ortaya çıkacak gereksinim sayıları sadece aynı hedefe yöneliklik kapsamında gruplanırlarsa geçerli ve anlamlıdır. Genellikle ihtiyaç sayıları çok fazla olmaz, çünkü son derece geneldirler. Sadece bir sıkıntıya -onun hiç bir detayı hakkında bilgi vermeksizin- işaret ederler. Tipik sayılar 10’lu rakamlardır. İşlevler ise bu sıkıntıyı bertaraf etmenin yolunu ifade ettiklerinden daha yüksek bir sayıda olurlar. Genellikle sayıları 25 ila 100 arasında değişir. Bulunan işlevler müşteriyle yazılım ekibi arasında bir kontrat ilişkisi sağladıklarından sistem kapsamını belirlemek amacıyla pek çok toplantının ana konuları olurlar.
Gereksinim Yönetimi çalışmalarının ilerleyen aşamalarında (Use Case Şeması çizilirken, Use Case’lerin dokümantasyonu hazırlanırken, vs.) işlevlerden gereksinimler türetilmeye başlanır. İşlevler ile Gereksinimler arasında birebir bir ilişki yoktur. işlevler farklı detay seviyelerinde olabildiklerinden bazen bir kaç use case’e, bazen bir use case’e bazen ise bir use case dokümanı içindeki bir kaç satıra karşılık gelebilirler.
Proje gelişimi süresince gereksinimleri ve değişikliği yönetebilmek için gereksinimlere çeşitli değişkenler atanabilir. Bu değişkenler proje yapınıza göre bir miktar değişebilmekle birlikte pek çok kez aşağıda belirtilen değişkenlerden ibaretlerdir: 1) Statü: Gereksinimin sistemin kapsamına kabul edilme seviyesini belirtir. 2) Öncelik: İteratif yazılım geliştirme için bir zaruriyet olan önceliklendirme gereksinimlerin zorluklarına, sistem mimarisine etkilerine ve karmaşıklıklarına odaklanır. 3) Emek: Yazılım ekibince gereksinimle ifade edilen kabiliyetin gerçekleştirilmesi için harcanacak emeği (adam/gün) ifade eder. 4) Risk: Söz konusu gereksinimin yerine getirilememe riskini ifade eder.
5) Değişebilirlik: Gereksinimle ilgili müşteri kararsızlığı gibi faktörlere dayalı olarak gereksinimin değişme veya geçerliliğini yitirme oranını ifade eder. Bazen kullanılan ‘Hata ve İstek Takip’ ürünleri gereksinim değişikliklerinin tarihçesini tuttuğundan, bu şekilde tespit edilir ve müşteriyle durumun nasıl bertaraf edilebileceği tartışılır. 6) Hedeflenen Sürüm (veya iterasyon): Söz konusu gereksinimin öncelik sırasının ne olduğunu ifade eder. 7) Görevli: Söz konusu gereksinimle ilgili yazılım mühendisliği çalışmalarını kimler yapacak ve şu anda kim görevli? 8) Neden: Yine gereksinim önceliği hakkında bilgi veren, gereksinimin ortaya çıkma nedeni (hata düzetleme, ek özellik, vs.).
Gereksinimler arasında ‘genelden detaya’ doğru bir sıralama yapmak istersek, En üstte sistem işlevlerini (üst seviye gereksinimler, features) buluruz. Bu işlevler ‘vizyon dokümanı’ içinde yer alan sistemin yerine getirmeyi taahhüt ettiği kabiliyetlerdir. Bu işlevlerden esinlenilerek use case modeli (aktörler, kullanım senaryoları, kullanım senaryosu dokümanları) ve ek gereksinimler (fonksiyonel olmayan gereksinimler) dokümanı hazırlanır. Bu çalışmalar ilgili oldukları işlevlere <<dependency>> ilişkisi kullanılarak bağlanırlar. Burada sağlanmak istenen amaç herhangi bir işlev değişikliği veya yeni işlev doğması halinde bunun sistemin hangi bölümüyle ilgili olduğunu kesin ve kolay bir şekilde bulmaktır. İsteklerinin maliyet ve emek boyutu hakkında müşterileri eğitmek ve değişikliklerin etkisine bağlı olarak tasarım kararları almak diğer ‘takip edilebilirlik’ faydalarındandır. Bunların dışında eğer kurumunuzun hedeflediği CMMI gibi kalite standartları varsa bu tür ‘takip edilebilirlik’ bir zaruriyet olarak ortaya çıkmaktadır.
Gereksinimler genellikle bir doküman çerçevesinde gruplanırlar. Bu tür bir doküman tanımlanırken Doküman kullanıcılarının tanımlı olmasına, Dokümanı hazırlayan rolün tanımlılığına, Doküman çalışmasının hangi süreç aşamasında ve hangi disiplin yetki alanında yapılacağına ve Bunlara bağlı olarak dokümanda hangi başlıkların (bilgi türlerinin) olmasının gerektiğine dikkat edilmelidir. Kullanılan UML ürününe bağlı olarak bu çalışmalar görsel bir ortamda yapılabilir. Geleneksel çalışma ortamıysa genellikle MS Word formatında hazırlanan yazılardır.
Geleneksel yaklaşımda hazırlanan Yazılım Gereksinimleri Dokümanı (SRS) bizim kullanacağımız senaryo odaklı yaklaşımda parçalanmaktadır. SRS kapsamındaki tüm fonksiyonel gereksinimler use case modeliyle karşılanacaktır. Fonksiyonel olmayan gereksinimler ise ek gereksimler dokümanıyla karşılanacaktır. Burada dikkat edilmesi gereken senaryo odaklı yazılım geliştirmede çalışma odağının doğal olarak senaryolar (use case’ler) olmalarıdır. Diğer bir deyişle fonksiyonel olmayan gereksinimlerin gözden kaçmamasına özel bir önem verilmelidir. Çünkü böyle yapılmazsa elde edeceğimiz bilgiler SRS kapsamının sadece bir kısmına karşılık gelecektir. Yine dikkat edilmesi gereken diğer bir konu fonksiyonel gereksinimlerin tasarımı ciddi miktarda ve direkt olarak etkileyebildikleridir.
Gereksinim çalışmaları sırasında Use Case Modeli sistemin davranışını ifade etmek amacıyla oluşturulur. Use Case Modeli müşteri, kullanıcılar ve yazılım ekibi arasındaki bir kontrattır. Bu model kullanılarak müşteri ve kullanıcıların sistemin istedikleri çözümü sunup sunmadığını sınamaları ve yazılım ekibinin istenen çözümü oluşturabilmesi sağlanmaktadır. Use Case Modeli Aktörler ve Kullanım Senaryolarından (Use Case) oluşur. Her use case aktör ve sistemin adım adım etkileşimlerini içerek şekilde detaylandırılır. Use Case’ler ve onların ‘uzantıları’ (Use Case Realization yapısı) UML modelinin bütünlüğünü korumak için önemlidirler. Analiz, Tasarım, İmplementasyon ve Test çalışmaları esnasında kullanılırlar. Her use case detaylı akış, veri yapısı, iş kuralları ve alternatif akış bilgilerini içeren bir dokümantasyona sahiptir. Gereksinim çalışmalarını eksiksiz hale getirmek için use case ile birlikte aşağıdaki dokümanların da hazırlanmaları gerekir: Ek Gereksinimler (Supplementary Requirements): Fonksiyonel olmayan gereksinimleri içerir. Sözlük (Glossary): Projeye yönelik terim ve kısaltmaların açıklamalarını içerir.
Gereksinim Yönetimi Esnasında Aktif Roller Hazırlayanlar: İş Analisti (Business Use Case Model, Business Vision, Business Process Model, vs.), Sistem Analisti (Use Case Model, Vision, Supplementary Requirements, vs.). Faydalananlar: {Paralel Olarak} Tasarımcı (Analysis Model, Design Model), Kullanıcı Arayüzü Tasarımcısı (Human Interaction –User Experience- Model), Veritabanı Tasarımcısı (Data Model), Ürün Kullanım Kılavuzu Yazarı (Ürün Kullanım Kılavuzu ve Help İçeriği). Yardımcı Olanlar: Müşteri (Sistem Analistine bilgi sağlar), Müşteri Temsilcisi (“), Konu Uzmanı (“).
Gereksinim Ürünlerini sıralayacak olursak, ilk olarak aklımıza gelecek olan Use Case Şemalarıdır. Bu şemalar sistem genelini, sistem mimarisini etkileyen kabiliyetleri veya iterasyon kapsamlarını göstermek için kullanılabilir. Sistem genelini göstermek amacıyla en az bir tane hazırlanmalıdır. Genellikle şu şekilde isimlendirilir: “ Overview of Actors and Use Cases” veya “Overview of {Project Name}” “ Aktör ve Kullanım Senaryolarına Genel Bakış” veya “{Proje Adı} Projesine Genel Bakış”
Şemaların ötesinde gereksinim yönetimi çalışmaları büyük oranda (Ortalama 20/80) doküman yazma çalışmalarıdır. Eğer kendimize minimum bir doküman topluluğu oluşturmak istersek, İlk önce ‘Vizyon’ dokümanını hazırlamalı, daha sonra buradaki bilgilerden yararlanarak Use Case Modelini çizmeliyiz. Bunu takiben Ek Gereksinimler dokümanını doldurmalıyız. Bu doküman sistem genelinde hazırlanmalıdır. En sonunda use case’lerin dokümanlarını sadece birer ‘outline’ seviyesinde hazırlamalıyız: Bu tür doküman sadece use case tanımı, temel ve alternatif akış adları ile precondition/postcondition ilişkileri hakkında bilgi verse kafidir. Use case’leri bu kaba dokümanlara ve değişkenlerine göre önceliklendirdikten sonra ilk iterasyon kapsamında olanların detaylı dokümanlarını hazırlamaya başlamalıyız. Sözlük dokümanı bu çalışmaların her aşamasında kademe kademe doldurulabilinir.
Sırasıyla bu dokümanların içeriklerini, Vizyon’dan başlayarak, inceleyelim: Proje geneli hakkında bilgi verdiğini iddia ederken daha çok zaman ve para hesaplarına dalan dokümanların aksine, Projenin aklanmasını sağlayan ve proje sorumluluğunu taşıyan herkesin tanımlandığı bir dokümandır. Doküman içerisindeki alt başlıklar: [1] Giriş: Dokümanın içeriği hakkında kısaca bilgi veriniz, ürünün giderdiği en önemli sorunları birincil kullanıcılarına değinerek belirtiniz. Bu bilgileri verirken bir paragraftan daha uzun olmamasına dikkat ediniz.
[2] Ürünün Konumlandırılması Geliştirilecek yazılımın hitap ettiği piyasada / ortamda hangi boşluğu giderdiğini muhtemel rakip /alternatif çözümlerle karşılaştırarak belirtiniz. [3] Paydaş ve Kullanıcı Tanımları Paydaşları kullanıcı olanları belirterek açıklayınız. Geliştireceğiniz yazılımın tasarımını etkileyebilecek paydaş özelliklerini (fiziksel, demografik, bilişime yakınlık vs.) belirterek açıklayınız. Her paydaş ve kullanıcı grubu için ismi ve erişim bilgileri belli birisinin tanımlandığından emin olunuz.
[4] Ürün İşlevleri Listesi (Features) Dokümanın en önemli kısmı belki de bu listedir. Teker teker (birden fazla sistem kabiliyetini aynı cümlede ifade etmeye çalışarak anlaşılmasını güçleştirmeden) sistemin sahip olması gereken bütün kabiliyetleri listeleyiniz. Bu kabiliyetleri isterseniz ilgili oldukları konular kapsamında gruplayabilirsiniz. Örneğin, kullanım kolaylığı veya konu adı (muhasebe) gibi. Her değindiğiniz sistem kabiliyetini gözden birşey kaçmaması için bir kaç cümleyle açıklayınız. Bu açıklamalarda sağlanan faydanın ne olduğunu ve ilgili paydaşı belirtebilirsiniz. İşlevlerin toplam sayısı 20’li rakamlardan 100’e kadar varabilir. Bunda sizi endişelendirmemelidir. Bütün bu işlevler çok daha az sayıda kullanım senaryosu ve ek gereksinimler alt başlıkları altına yerleşeceklerdir.
Burada Rational şirketinin Vizyon Dokümanı tanımı bulunmaktadır. Buradaki tanıma göre bu tür dokümanlarda bulunması gereken bölümler: Giriş Hedef: Dokümanla yapılmak istenen iş Tanımlar ve Kısaltmalar: Açıklamaları Referanslar Ürünün Konumlandırılması İş Fırsatı: Geliştirilen yazılımla değerlendirilen iş fırsatı Problem Tanımı: Geliştirilen yazılımın çare olduğu problem açıklaması Paydaşlar ve Kullanıcıların Tanımları Paydaşlar: Yazılımdan dolaylı etkilenenler hakkında bilgiler Kullanıcılar: Yazılımı birebir kullanacak gruplar hakkında bilgiler En önemli paydaş / kullanıcı ihtiyaçları Ürünün Temel İşlevleri: burada sırasıyla listelenir. Genellikle 25-100 maddeden oluşur Öncelik: Temel işlevlerin birbirlerine göre öncelikleri belirtilir Diğer Ürün Gereksinimleri: Ek Gereksinimler Dokümanında detaylandırılacak fonksiyonel olmayan gereksinimler
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Vizyon Dokümanı : Giriş “ Bu dokümanın amacı J2EE altyapısı kullanılarak gerçekleştirilecek PearlCircle İnternetten Açık Artırma (PCOA) sisteminin üst seviye gereksinimlerini [işlevlerini] belirtmektir. PCOA tedarikçilerinin (satıcıların) internet vasıtasıyla diledikleri ürünleri çok sayıda potansiyel alıcının arzına sunmayı sağlayan bir açık artırma sistemidir. Bu dokümanın geriye kalanı PCOA sisteminin karşılık geldiği sorunları, Sistemin paydaşları ve onların en önemli ihitiyaçları, Sistemin sahip olmayı taahhüt ettiği kabiliyetleri ve Sistemin uymak zorunda olduğu kısıtlamaları açıklayacaktır.”
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Vizyon Dokümanı : İş Fırsatı “ İnternette Açık Artırma tedarikçilerin potansiyel alıcılarla karşı karşıya geldikleri yaygın bir yaklaşım haline gelmiştir. Satıcılar için çok büyük sayılarda alıcılara hitap edebilme imkanı ortaya çıkmıştır. Alıcılar içinse içinden dilediklerince seçim yapabilecekleri çok geniş ürün sayısına sahip kataloklara ulaşabilmek mümkündür. Her iki grup için de işlemlerini bitirme aşaması haricinde kimliklerini gizlemek mümkün olacaktır. O anda dahi kimlikleri sistem haricinde bir gruba açılmamaktadır. Açık artırma iş modeli basit iş mantığı yüzünden popülerlik kazanmaktadır. Açık artırma site sorumlusu satıcıları bitmiş her satış işlemi için ücretlendirmektedir. Bu ücret ya sabit bir ücrettir ya da satış meblağının belli bir yüzdesine karşılık gelmektedir. Bir açık artırma sitesinin karlılığı (1) yapılan işlem miktarına ve (2) sistemin maliyetine bağlıdır. Her iki faktör de iyi tasarlanmış ve uygulamaya alınmış bir sisteme çok bağlıdır. Eğer sisteme erişim ve sistemin kullanımı kolay, güvenilir ve performanslı ise daha çok sayıda satıcı ve alıcı bu siteye rağbet gösterecektir. Diğer taraftan, eğer sistemin kurulumu, yönetim ve bakımı kolaysa operasyonel maliyetler azalacaktır. Dolayısıyla temel sistem mimarisini ve önemli tasarım kararlarını resmeden bir referans uygulama geliştirilmesi önemli bir iş fırsatı olarak değerlendirilmektedir.”
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Vizyon Dokümanı : Problem Tanımı “ PCOA aşağıdaki paydaş ve kullanıcı ihtiyaçlarına istinaden geliştirilecektir: Satıcılar mümkün olan en yüksek sayıda potansiyel alıcıya erişmek ihtiyacı duymaktalar, Alıcılar mümkün olan yüksek çeşite sahip ürün kataloklarına erişmek ve harcayacakları tutarı denetimleri altına almak ihtiyacı içindeler, Hem alıcılar hem de satıcılar satın işlemlerini gerçekleştirdikleri ana dek kimliklerini gizli tutmak istemekler, Açık artırma sitesi sorumlusu alıcı ve satıcıların sık sık, kimliklerini deşifre etmeden bir araya geldikleri ve satın almaların yapıldığı bir yapıya sahip olmak sitemektedir. Site sorumlusu satın alma bazında bir ücret talep ederek kar etmek istemektedir. PCOA satıcıların ürünlerini tanıtabilecekleri, alıcıların ürünlere teklifler yapabileceği ve sistem sorumlusunun bu sanal pazarı yöneterek kar elde edebileceği bir yapıda olmalıdır.”
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Vizyon Dokümanı : Paydaşlar “ Paydaş Bilgileri Özeti: Paydaş sözcüğüyle anlatılmak istenen PCOA sisteminin kabiliyet ve özellikleri hakkındaki önemli kararları veren Veya bu kararları etkileyen tüm kişi ve kurumlardır. Bu önemli paydaşlar, Açık Artırma Site Sorumlusu (Sahibi) ve Açık Artırma Sistem Geliştiricisi’dir. Her ikisi hakkında da açıklamaları aşağıda bulabilirsiniz. Açık Artırma Site Sorumlusu (Sahibi) Tanım: Açık Artırma Sitesi sahibi olan kişi veya kurum. Kaygılar ve Sorumluluklar: Açık artırma sistemine yönelik gereksinimlerin tanımlanması, değerlendirilmesi ve onaylanmaları. Site kullanımı kurallarının (ücretler, kullanma hakkı, satılabilen ürünler ve hizmetler, vs.) belirlenmesi. Site kullanımı ve performansı gibi konularda istatistiki bilgiler edinmek. Site yönetimi ve geliştirilmesi için finansman sağlamak. Açık Artırma Sistem Geliştiricisi Tanım: Açık Artırma Sistemini geliştiren ve bakımını yapan kişi veya kurum. Kaygılar ve Sorumluluklar: Gereksinimleri anlamak ve paydaş ihtiyaçlarını karşılamak. Bakımı ve geliştirilmesi kolay, esnek bir sistem mimarisine sahip bir sistem geliştirmek. Mevcut problem çözümlerini sisteme entegre etmek. Geliştirilen sistemin benzer sistemler geliştiriken tekrar kullanılabilmesini sağlamak.“
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Vizyon Dokümanı : Paydaş Detayları Her paydaşın, kullanıcılar da dahil olmak üzere detaylarının verildiği bir bölümdür. Yukarıdaki örnekte sadece kullanıcılara değiniyoruz. Ayrıca yine bu örnekte önemli bir eksiklik var: Bu detay bilgilerinde mutlaka her grup için erişilebilecek bir temsilci belirlenmelidir (Adı, Telefonu, E-Mail Adresi, vs.). “ Satıcı Tanım: Açık artırma sisteminde satılık bir ürün veya hizmet tanımlayan kişi veya kurumdur. Kaygı ve Sorumluluklar: Açık Artırma Sorumlusu gözetiminde kayıt olmak ve kredi durumu onayı almak. Satılacak nesneyi tanımlamak. Başlangıç fiyatını ve teklif artış oranını belirlemek. Teklifleri izlemek ve reddetmek. Bir teklifi kabul etmek. Onaylanan alıcıya satılan ürünü iletmek. Açık Artırma Sitesi Sorumlusuna harç ödemek. Alıcı Tanım: Satılan bir ürüne veya hizmete yönelik teklif veren kişi veya kurumdur. Kaygı ve Sorumluluklar: Açık Artırma Sistesi Sorumlusu gözetiminde kayıt olmak. Katalok içeriğine bakabilmek. Bir ürün veya hizmete yönelik teklif verebilmek. Onaylanmadan teklifini geri çekebilmek (iptal edebilmek). Eğer teklifi onaylanırsa ödeme yapmak. Ziyaretçi Tanım: Sadece ürün kataloğuna bakmak için siteyi ziyaret eden ve ileride satıcı veya alıcıya dönüşme ihtimali olan kişidir. Kaygı ve Sorumluluklar: Bir teklif verme zaruriyeti olmaksızın tüm katalok içeriğine bakabilmek (“Sadece bakıyorum tavrı”). Açık Artırma Sistem Yöneticisi Tanım: Açık artırma sitesinin kullanılabilirliğini korumak için site yönetimini gerçekleştiren kişidir. Kaygı ve Sorumluluklar: Satılığa çıkarılmış ürünlerin gruplarının yönetimi. Satıcı ve Alıcıların kayıt altına alınmaları. Site faaliyetlerinin izlenmesi ve raporlanması. Açık Artırma kapatma işlemlerinin yönetimi. Servis ücretlerinin tahsil edilmesi. Kullanıcı düşünce ve şikayetlerinin toplanması, usulsüz kullanım durumları ve ilgili grupların yasaklanmaları.”
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Vizyon Dokümanı : Sistem İşlevleri Konuya göre de gruplanabilecek bu işlevlerin hepsinin altına kısa açıklamalar yazılmış olmasına dikkat ediniz. Bu açıklamalarda hangi kullanıcıların söz konusu işlevle ilgili olarak yapabileceklerini (hangi faydaları sağlayabileceklerini) belirtmelisiniz. Kullanıcı hesap yönetimi, Açık artırmaya ürün eklemek, Satılığa çıkarılmış ürünlerin kataloğuna bakabilmek, Açık artırma yönetimi, Sistem güvenliğinin sağlanması, vs. vs.
Use Case Dokümanı Yapısı Hakkında İçeriği neyle ilgili olursa olsun, use case dokümanının eksiksizliği her zaman aynı şekilde ve aşağıdaki sırayla kontrol edilir: 1) Format Kontrolleri Metin Yapısı: Dokümanın bulundurması gereken asgari alt başlıklar ve içerikleri mevcut mudur? (Tanım, Temel Akış, Alternatif Akışlar, Precondition, Postcondition) Diyalog Yapısı: Metnin akış bilgisi veren bölümleri monologdan ziyade dialog yapısında yazılmış mıdır? Alternatif akışlar (sonuçlanmaları bir kaç satırı geçen alternatif durumlar) ayrı bir bölümde gruplandırılmış mıdır? Akışlar arasındaki geçişler etiketlenmiş ve gerektiğinde refere edilmiş midir? 2) İçerik Kontrolleri Olağandışı durumların nasıl tolere edileceğini gösteren ‘Başarısız Alternatif Akışlar’ tanımlanmış mıdır? Akış bilgilerinde ‘ne’ gözardı edilerek ‘nasıl’a mı cevap verilmiştir (Tasarıma mı kayılmıştır) Akış bilgileri okunduğunda use case’in adıyla ifade edilen faydaya ulaşılması için gereken veri yapısı, akış adımları ve iş mantığı açık bir şekilde ortaya dökülmüş müdür? 3) Doküman Onayının Verilmesi Geçerli Roller Sistem Analisti: Müşterinin memnun kaldığı kullanım sağlanmış ve arzulanan hedeflere varılmış mıdır? > Değilse tekrar müşteriye başvurunuz. Bir başka Tasarımcı: Bu açıklamalarla Analiz Modeli çalışmalarını tamamlamak mümkün müdür? > Değilse Sistem Analistinden daha detaylı bilgi talep ediniz.
Temel Akış use case çalıştırıldığı zaman gerçekleşen tipik akışı ifade eder. Genellikle temel akış “Mutlu Senaryo” olarak adlandırılır. Bu Use Case’in olağan koşullar altında izlemesi gereken akıştır. Bir Use Case’in akışı çeşitli parçalara bölünebilir. Bir akışı parçalara bölmek ve bu parçaların detaylarına kendilerine ayrılmış bölümlerde girmek metnin okunurluğunu artıracaktır. Aynı zamanda bir use case’in tipik akışı da bu yaklaşım altında daha net bir şekilde ortaya çıkacaktır. Eğer temel akışın bir parçası çok kapsamsız ve kısaysa veya kendi başına bir önem ifade etmiyorsa o akışın temel akışın içinde kalması daha yararlı olacaktır. Aksi halde metnin okunurluğunu artırmak yerine azaltacaktır. Use Case Dokümanı use case’in sahip olduğu tüm akışları (temel, alternatif, olağandışı) içermelidir. Metni yazarken bütün alternatiflerin hangi koşullarda ortaya çıktıklarını, daha sonra ana akışa geriye dönülüp dönülmediğini ve bu tür alternatiflerin temel akıştaki başlangıç yerlerini net bir şekilde, gerekirse açıklayıcı referanslar kullanarak anlatınız. Alternatif Akış nedenlerine örnekler verecek olursak, Uzun ve kapsamlı bir akış parçasının detayını gizlemek, Alternatif akış adımlarını gruplandırmak, Olağandışı durumları saptamak ve bu durumların nasıl tolere edileceklerini belirlemek, Temel akış içerisinde tekrarlanan parçaları tekrar tekrar yazmaktan kurtulmaktan bahsedebiliriz.
Bir senaryo olası bir use case kullanım/çalıştırılma şeklidir. Diğer bir deyişle use case olası pek çok temel akış, alternatif akış ve olağandışı akış kombinasyonlarından birisidir. Yukarıdaki örnekte bazı kombinasyon örneklerini görüyorsunuz. Soru: Kaç senaryo gereklidir? Cevap: Geliştirilen sistemi anlamaya yetecek kadar. İlgi çekici ve riskli use case’leri daha detaylı incelemelisiniz. Senaryolar tahlil amacıyla kullanıldıkları kadar olay akışlarının onaylanmaları için de kullanılabilirler. Bazıları önce senaryoları bulup bunları use case’lerle gruplandırırlar. Diğerleriyse önce use case’leri bulup, daha sonra onlara senaryoları eklerler.
Use Dokümanlarının en önemli bölümü akış bilgilerinin verildiği bölümlerdir. Zaten dokümanın tamamına yakın bir kısmını da bu bölümler oluştururlar. Akış bölümlerinin kendileri ise use case’in adıyla ifade edilen faydaya ulaşmaya çalışan senaryolardan oluşur. Senaryolar Başarılı ve Başarısız olarak ikiye ayrılırlar. Başarılı senaryolar beklenen bir biçimde gelişerek kullanıcıya use case’in sağlamayı taahhüt ettiği faydayı farklı güzergahlar izleyerek sağlarlar. Başarısızlık durumunda ise bir alternatif kullanım senaryosu (Başarısız Akış / Olağandışı Akış / Exceptional Flow) bu başarısızlık durumunun sistem tarafından nasıl tolere edileceğiniz anlatır. Aksi halde başarısızlık durumlarında müşteri kendi başına bırakılır ki bu müşteri memnuniyetini negatif olarak etkileyecek bir durumdur.
Kullanım Senaryolarının odağı, yani akış bilgilerinin düzenlenmesi sırasında bizi yönlendiren nihai hedefi, use case’in adıyla ifade edilen faydaya başarılı ve tipik bir şekilde nasıl ulaşıldığını gösteren Temel Akışı’dır. Aşağıdaki soruya cevap olarak tanımlanır: 1) Temel Akış: {Kullanım senaryosu adı} için en tipik ve başarıyla (Kullanıcının faydaya ulaşmasıyla) biten yol nedir? Ancak bir kullanım senaryosunun tüm olası güzergahları incelenirken bir senaryo kafi değildir. Bunu tamamlamak için aşağıdaki sorulardan yararlanabiliriz: 2) Başarılı Alternatif Akışlar: {Kullanım senaryosu adı} için (başarıyla biten) diğer yollar nedir? Kaç tane bulursanız o kadar iyidir. Senaryo sayılarının artışı işinizi güçleştirmekten çok kolaylaştıracak ve ileride ideal bir nesne modeli tanımlayabilmenizi sağlayacaktır. 3) Başarısız Alternatif Akışlar: {Kullanım senaryosu adı} ile ifade edilen faydaya ulaşamama durumları nelerdir ve bunlar nasıl tolere edilecektir? Bu akışları bulmanız müşteri memnuniyetini büyük ölçüde etkileyecektir. Çünkü herhangi bir problem durumunda kullanıcı yalnız başına bırakılmayarak yardımcı olunacaktır.
Kullanım Senaryosu Dokümanının akış bilgisi içeren bölümleri bir dialog halinde sistemle aktör etkileşimini göstereceğinden bunun kolay okunabilmesi için kullanılan iyi yaygın yöntem vardır: 1) Tek Sütun (Daha yaygındır): Bir satır (veya paragraf) aktörün ne yaptığını, diğer satır (veya paragraf) sistemin buna istinaden neler yaptığını anlatır. Bu satırlar (veya paragraflar) ayrı ayrı etiketlenirler. Genellikle bunun için numaralar kullanılır: 1, 2, 3, vs. 2) İki Sütun: Zig zag yapısını daha iyi gösteren bu yöntemde birinci sütun aktöre, ikinci sütun sisteme verilerek yine yukarıdaki gibi önce aktörün ne yaptığı ve sonra sistemin buna istinaden neler yaptığı yazılır. Bu yöntemin popüler olmayışı bu şekilde bir çalışmanın Activity Şeması ve (amacı dışında bir şekilde kullanıldığında) Sequence Şeması ile daha kolay bir şekilde yapılabilmesidir.
Kullanım Senaryosu Dokümanı Gelişim Süreci: Her önemli kullanım senaryosu için sırasıyla, 1) Kullanım Senaryosunun Bulunur 2) Kullanım Senaryosu – Tanım bölümü doldurulur 3) Kullanım Senaryosu – İçerik bölümü doldurulur (Akışların isimleri vs.) 4) Kullanım Senaryosu – İçeriği başlıkları eksiksizleşir ve kısa tanımlar ortaya çıkar 5) Kullanım Senaryosu – Akışların detayları girilmeye başlar. Temel Akış eksiksizleşir. 6) Kullanım Senaryosu – Tüm alternatif akışlar eksiksizleşir. Dokümanın geriye kalanı doldurulur.
Pek çok Kullanım Senaryosu Şablonu mevcuttur. Bazı vurgulayabileceğimiz ekoller, en önemlisi Rational şirketi olmakla birlikte, şunlardır: Alistair Cockburn ve Paul R. Reed’dir. Öte yandan, hangi şablonu seçerseniz seçin, her kullanım senaryosu dokumanı mutlaka tüm alternatif akışlar, kullanım senaryosu çalışmadan önce ve sonrasında sistemin durumu ve kullanıcıları hakkında bilgi vermelidir.
Kullanım Senaryosu Dokümanı İçeriği: Tanım Use Case tanımında ilişkili olduğu (<<extend>> ve <<include>>) diğer use case’lerin adlarına, fonksiyonel olmayan gereksinimlerine, önemli iş kurallarına, use case’in kullanım yoğunluğuna değinebilirsiniz. Bu detaylara sahip bir paragraf, ilk ortaya çıktığında sadece akış başlıklarına sahip olan use case dokümanına dayanarak use case’leri önceliklendirebilmenizi kolaylaştıracaktır. Öte yandan genellikle bu kadar detaylı bilgi içermeyen tanım bölümünde, en azından use case’in hangi aktöre hangi faydaları sağladığını ve bunun sistem içindeki önemini belirtebilirsiniz.
Kullanım Senaryosu Dokümanı İçeriği: Use Case Aktörleri Genellikle ayrı bir bölümde belirtilmeyen aktörlere daha fazla dikkat çekmek isterseniz, birincil aktörü diğerlerinden ayırarak kullanım senaryosunun kullanıcılarını ve bağımlı olduğu sistemleri belirtiniz.
Kullanım Senaryosu Dokümanı İçeriği: Use Case Paydaşları Yine genellikle ayrı bir bölümde belirtilmeyen use case paydaşları (tanım içerisine kaydırılan bilgiler) hakkında bilgiler verilmesi use case akış bilgileri ve kapsamı hakkında sorunlar çıktığında başvurulacak grupların tanımlı olması açısından faydalıdır.
Kullanım Senaryosu Dokümanı İçeriği: Temel Akış Use Case Dokümanının en önemli kısmıdır.
Kullanım Senaryosu Dokümanı İçeriği: Alternatif Akışlar Başarılı Akış Örnekleri (ATM’den Para Çekme Use Case’i için): Müşteri bakiyesine bakıp sistemden çıkar. Başarısız Akış Örnekleri (ATM’den Para Çekme Use Case’i için): Müşteri hesabını seçer, bakiyesini görür, çekim işlemini onaylar AMA banka merkezine ulaşılamaz: Olmaması Gereken: i) Müşterinin anlamayacağı bir programcı hata kodu görür. Olması Gereken: ii) Müşteriye durum açıklanır ve varsa alternatif bir yol önerilir. Başarısız Alternatif Akışların tanımlanılmasının istenme nedeni yukarıdaki (ii) gibi beklenmeyen hataların tolere edilebilmesini sağlamaktır.
Kullanım Senaryosu Dokümanı İçeriği: Alternatif Akışlar Alternatif Akışların ilişkilendirilme yollarına bir örnek verirsek, Temel Akış : Satır ‘n’ … filanca işlem yapılır … {Başarılı Alternatif durumu varsa ilgili akış kodu: An gibi} {Başarısız Alternatif durumu varsa ilgili akış kodu: En gibi} Alternatif Akışlar Başarılı Alternatif Akışlar: A1 : … A2 : … Başarısız Alternatif Akışlar: E1 : … E2 : …
Kullanım Senaryosu Dokümanı İçeriği: Alternatif Akışlar Alternatif Akışların detaylandırılma yollarına bir örnek verirsek, {Başarılı / Başarısız} Alternatif Akışlar: Akış Kodu Kod formatı size bağlı olmakla birlikte genellikle ya sayı olmaktadır ya da akış türünün bir kısaltması. Örneğin, Başarılı Akışların başladığı satırın sayısı 2 ise, alternatif akışların kodları 2.1, 2.2, 2.3 gibi olabilir. Akış türünün bir kısaltmasını kullanmak isterseniz, Başarılı Alternatifler için Alternate Flow (A1, A2, A3, …), Başarısız Alternatifler için Exceptional Flow (E1, E2, E3, …) kullanılabilinir. Akış Adı Akışı temel akıştan ayıran özelliğini vurgulayacak bir ad veriniz. Örneğin, bir e-ticaret sitesinden satın alma use case’i için, başarısız bir örnek: Kredi Kartı Reddi, başarılı bir örnek: Özel İndirimli bir Kartın Kullanımı (Axess) olabilir. Akış Detayları Temel Akışta olduğu gibi bir dialog yapısı kullanarak tüm akış adımlarını, iş kurallarını ve kullanılan veri yapısını belirtiniz. Alternatif akışın bitişini ve Temel Akış’a nasıl dönüleceğini belitiniz. Çok karmaşık akışların söz konusu olduğu durumlarda alternatif akışlar altında da alternatif akışlar bulunabilir. Bu durumda yine yukarıdaki yapıyı koruyarak, gerekli bilgileri sağlayınız.
Kullanım Senaryosu Dokümanı İçeriği: Precondition (Ön Koşullar) Eğer örnekler verecek olursak, bir “Satın Al”ma yapabilmek için, Sistemde tanımlı olmak ve Sisteme bağlanmış olmak gerekmektedir.
Kullanım Senaryosu Dokümanı İçeriği: Postcondition (Ardıl Koşullar) Eğer örnekler verecek olursak, bir “Satın Al”ma yaptıktan sonra, Müşterinin sipariş verdiği ürünler depodan çekilir veya temin edilmek üzere tedarikçilere sipariş geçilir. Müşteri’den tutar tahsil edilmiş olmalıdır. Müşteriye gönderilmek üzere fatura düzenlenmiş olmalıdır. Müşteriye satın alma bilgileri e-mail aracılığıyla gönderilmiş olmalıdır. Müşteriye gönderilen e-mail içeriğinde ilgili ürünlerin tanıtımı yer almış olmalıdır. Müşterinin alışveriş tutarına göre hediye puanı hesabına işlenmiş olmalıdır.
Kullanım Senaryosu Dokümanı İçeriği: Ek Gereksinimler (Special Requirements) Fonksiyonel olmayan gereksinimler sisteme genel olduklarından aslında tek bir dokümanda (Ek Gereksinimler: Supplementary Requirements) toplanırlar. Bununla birlikte use case dokümanı incelenirken hemen dikkati çekmek istediğiniz fonksiyonel olmayan bir gereksinim varsa veya Ek Gereksinimler Dokümanını hazırlamayacaksınız bu bölümün geçerliliği ortaya çıkmaktadır.
Kullanım Senaryosu Dokümanı İçeriği: İş Kuralları (Business Rules) Özel Gereksinimlerle aynı mantıkta iş kuralları da sisteme genel bir dokümanda (Business Rules) toplanırlar. Bununla birlikte bu dokümanı hazırlamak istemiyorsanız ve use case dokümanları kullanırken akışların anlaşılmasını kolaylaştırdığını düşünüyorsanız, bu bölümün geçerliliği ortaya çıkacaktır.
Kullanım Senaryosu Dokümanı İçeriği: Kullanım Yoğunluğu (Frequency) Dokümana eklenen bir satırla, kullanım senaryosunun göreceli kullanım sıklığının belirtilmesidir. İleride bu bilgi use case’ler önceliklendirilirken çok işe yarayacaktır. Çok kesin ve rakamsal bilgiler verilmesi –mümkün değilse- gerekmez. Kullanıcıların aşağı yukarı kesin fikirleri zaten mevcuttur. Bundan yararlanılır.
Kullanım Senaryosu Dokümanı İçeriği: Açık Konular Dokümana sizin altbaşlık veya paragraflar kapsamında eklebileceğiniz standart dışı bilgi türleridir.
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Use Case Dokümanı “ Bid on Item” : Teklif Ver Doküman ilk kez ortaya çıktığında burada içerik sayfasında gözüktüğünden fazla bilgi içermez. Tek fazla bilgi tanım bölümünde olur. Açık Artırma Sisteminde satılan bir ürün veya hizmete yönelik bir teklif verilmesinin, bir tipik yolu (basic flow), üç alternatif yolu vardır: “Açık Artırma Sona Ermiştir”, “Alıcının Açık Artırma Sitesi Sorumlusuna Borçları Mevcuttur”, “ Verilen Teklif Geçersizdir” Bir teklif verilebilmesi için önce ‘Satıcının sisteme bağlanmış olması’ ve ‘Satıcının sattığı ürünü tanımlamış olması’ gerekmektedir. Bir teklif verildikten sonra ise “Açık Artıma Seansına Yönelik bir Teklifin İşleme Konmuş Olması” gerekmektedir. ‘ Extension Points’ (Genişleme Noktası) bölümünün boş olması bu use case ile <<include>> ve <<extend>> ilişkisine sahip use case’lerin olmadığını gösterir.
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Use Case Dokümanı : Tanım “ Bid on Item” : Teklif Ver “ Kısa Tanım: Açık artırma seanslarındaki ürünlere göz atarken (‘Kataloğa Bak’ use case’ine bakınız) bir Alıcı, bu ürünlere yönelik bir teklif vermek isteyebilir. Verilen teklif Satıcının tanımladığı artırım oranlarında bir önce verilmiş tekliften büyük olmalıdır. Bu kriteri geçen teklif mevcut teklif tutarı olarak kaydedilir. Kullanıcının bir teklif verebilmesi için sisteme bağlanmış olması gerekmektedir. Detaylar için ‘Sisteme Bağlan’ use case’ine bakınız. Eğer açık artırma seansı sona ermişse, teklif kabul edilmez. Detaylar için ‘Açık Artırmayı Kapat’ use case’ine bakınız. Eğer Alıcının zamanında yapmadığı ödemeleri varsa, Alıcıya bir ikaz gösterilerek, herhangi bir Açık Artırma Seansına katılabilmesi için önce bu ödemeleri yapması gerektiği hatırlatılır. Gerekiyorsa, kredi kartı bilgilerini güncelleyebilmesi için ‘ Hesap Yönet’ use case’i kullanılabilir.“ NOT: İtalikle yazılmış bilgilerin detaylarını Sözlük Dokümanında bulabilirsiniz.
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Use Case Dokümanı : Temel Akış “ Bid on Item” : Teklif Ver “ 2.1) Temel Akış: 1) Bu use case ‘Kataloğa Bak’ use case’ini genişletmektedir (<<extend>>). Use Case’in başlangıç adımı Alıcının açık artırma sitesinin kataloğunda bir ürünü seçmesi ve teklif verme işlemini başlatmasıdır. 2) Sistem verilecek teklifin girilmesi için bir form gösterir. 3) Alıcı teklif miktarını girer. Sistem girilen değerin geçerliliğini kontrol eder. Girilen teklif tutarı bir öncekinden tanımlı artırma oranında daha büyük olmalıdır. 4) Sistem Açık Artırma teklifini geçerli hale getirir. Teklif güncel teklif haline gelir. 5) Alıcıya verdiği teklif tutarını belirten bir mesaj gönderilir. Mesajda ayrıca açık artırmanın muhtemel sona eriş zamanı/meblağı belirtilir. 6) Alıcıya verdiği teklifin aktif olduğunu belirten bir mesaj gösterilir. Mesaj içeriğinde, Alıcı adı ve soyadı, Alıcı e-mail adresi, Ürün veya hizmet adı ile Teklif tutarı yer almalıdır. 2.2) Alternatif Akışlar: 2.2.1) Açık Artırma Sona Erdi Use Case akışının başlangıcında eğer açık artırma sona ermişse, Alıcı bir mesaj gösterilerek durumdan haberdar edilir ve teklif reddedilir. Use Case sona erer. 2.2.2) Alıcının Yapması Gereken Ödemeleri Var Use Case akışının başlangıcında, eğer Alıcı Açık Artırma Sorumlusuna (Sahibine), [ödemesi gereken harçlardan dolayı] yapması gereken ödemelerini yapmamışsa, herhangi bir açık artırma seansına Alıcı veya Satıcı olarak katılabilmesi için önce bu ödemeleri yapması gerektiği bir mesaj gösterilerek hatırlatılır. Bu ödemeleri yapması için Alıcının kredi kartı bilgilerini güncellemesi gerekmektedir. Bu bilgileri ‘Hesap Yönet’ use case’i kapsamında yapabilir. Use Case sona erer. NOT: Eğer veri yapıları çok uzunsa ve metnin okunmasını zorlaştırıyorsa, bunlar sözlüğe taşınarak çeşitli use case dokümanlarında Yalnızca refere edilerek kullanılabilirler. Bu durumu göstermek için kullanılan yaygın bir yöntem, bu tür bilgileri italik kullanarak yazmaktır.”
Rational Referans Uygulaması – “İnternetten Açık Artırma” – Use Case Dokümanı : Geriye Kalan Bölümler “ Bid on Item” : Teklif Ver “ Özel Gereksinimler: Kullanıcı Kataloğu Gezerken en fazla üç mouse tıklamasıyla bir teklif verebilmiş olmalıdır. Kullanıcı açık artırmada olan ürünleri tek bir klavye tuşunu kullanarak sırayla, gezebilmelidir. Ön Koşullar: Satıcı sisteme bağlanmış olmalıdır: Satıcının Alıcıdan önce sisteme bağlanmış ve açık artırma seansını başlatmış olması olması gerekmektedir. Satıcının sattığı ürün listeye eklenmiş olmalıdır: Alıcı teklif vermek istediği ürünün sayfasına bakıyor olmalıdır. Detaylar için ‘Kataloğa Bak’ use case’ine bakınız. Ardıl Koşullar: Girilen teklif tutarı açık artırma için güncel başlangıç teklifi haline gelir ve Satıcı ikaz edilir. Genişleme Noktaları: Yoktur.“
Ek Gereksinimler Dokümanının içeriğini sırasıyla inceleyecek olursak, her bir konu bir alt başlık olmak üzere, [1] Fonksiyonel Gereksinimler Bir use case kapsamına indirgenemeyen ve sistem geneliyle ilgili olan fonksiyonel gereksinimler. Bizler use case odaklı bir yazılım geliştirme süreci kullandığımızdan bu bölüme tek tük gereksinimler yazılır. Genellikle boş kalır. Bir örnek verecek olursak, “ Kullanıcı Sistemi Gezerken en fazla üç mouse tıklamasıyla kullanım kapsamını değiştirip işlemlerine başlamış olmalıdır.”
[2] Kullanılabilirlik Gereksinimleri Kullanım kolaylığını nasıl sağlayacaksınız? Kullanıcılarınız sistemi kullanırken işlerini görmenin ötesinde nasıl bir şekilde hoş kullanım izlenimi edinecekler (ve başka potansiyel kullanıcılara sizleri tavsiye edecekler)? Kullanım güçlükleri nasıl bertaraf edilecek? Örneğin, help sistemi nasıl çalışacak, yapılan işlemin kapsamı ne kadar kolay bir şekilde değiştirilecek ve hatalar nasıl tolere edilecek? Sistem hedeflediği kullanıcı grubunun özel ihtiyaçları karşılamak dışında, sisteme daha yabancı potansiyel kullanıcılarında da aynı memnuniyeti sağlayabilecek mi?
[3] Güvenilirlik Sistemin taahhüt ettiği işi yerine getireceğine olan güvenimiz ne ölçüdedir? Bu görevi aksatma durumları ve oranları nedir? Görev yerine getirememe zamanlarına toleransımız ne kadardır? Bir hastanın bitkisel hayatta olduğunu ve bağlı olduğu cihazdaki yazılımın göçmesi durumunda hayatı kaybedebileceğini düşününüz. Diğer uçtan bir örnek verecek olursak, film izlediğimiz bir yazılımın kitlenmesini verebilriz. Filmin en heyecanlı kısmında gerçekleşirse sinirlenebiliriz ama bu dünyanın sonu demek de değildir.
[4] Performans Bir örnek verecek olursak, Sistemin kullanıma hazır durumunu koruması: Availability (%) Down Time (Senelik) 99.0 3.66 gün 99.9 8.76 saat 99.99 52.6 dakika 99.999 5.26 dakika 99.9999 31.5 saniye
[5] Bakım Yazılımın güncellenmesini, hatalarının giderilmesini ve kullanıcısına uyarlanmasını kolaylaştırmak için uymamız gereken gereksinimler nelerdir?
[6] +: İmplementasyon Geliştireceğiniz yazılımın gerçekleştirilme ve uygulanma açısından ihtiyaç duydukları, kullanacakları ve sınırlamalarını ifade eder.
[6] +: Interface Geliştireceğiniz sistemin bağımlı olduğu dış sistemler, size bağımlı olacak dış sistemler, kullanacağınız altyapılar ve sizi altyapı olarak kullanabilecek sistemler hakkında bilgi verir.
[6] +: Operasyonel (Sistem İşletim ve Yönetimi) Geliştireceğiniz sistemin yöneticileri (System Administrator) için gereken sistem kabiliyetleri nelerdir? Sistemin sahip olması gereken özel yönetim imkanları (Örneğin, run-time esnasında) gerekiyor mu?
[6] +: Paketleme Eğer yazılımınız raflarda satılacaksa, nasıl bir paketleme kullanılarak arza sunulacaktır? Raflardan satılmayacaksa nasıl bir indirme politikası (download) yürütülecektir? Paket ve/veya içerikleri neler olacaktır? Bu pazardan pazara değişecek midir?
[6] +: Kanuni Konular (Yükümlülükler) Ürününüz için kullanacağız lisanslama çeşitleri ve yöntemleri nelerdir? İndirim politikanız nasıl işleyecektir? Satış politikanız nedir?
FURPS + Fonksiyonel Olmayan Gereksinim ifade modelini UML ile ilişkilendirdiğimizde, bu gereksinimlerin geleneksel SRS (Software Requirement Specification) dokümanının Use Case Modeli ile birlikte bir muadili olduğunu görürüz. Kullanılan UML ürününe bağlı olmakla birlikte, bu gereksinimler ya modele ilişkilerindirilen (hyperlink) dokümanlar ya da UML standardının yukarıdaki gibi genişletilmesiyle (“UML is extensible”) şema içeriklerine eklenebilmektedir. Verdiğimiz örnekte, her türlü dokümanın paketler kullanılarak içeriklerinin görsel bir ortamda ifade edilmesinin mümkün olduğunu görüyorsunuz.
Sözlük Dokümanının yapısı bazı diğer dokümanlarla (Business Rules, Risk List) aynıdır: i) Terim n: Önce gelen harfle başlayan bir terim: Açıklamaları … ii) Terim n + x: Sonra gelen harfle başlayan bir terim: Açıklamaları … iii) Kaynakça: Refere edilen dokümanların bir listesi ve erişim bilgileri. Örneğin, … [S] Terim n: Snigglefratz Açılımı: Tanımı: İnterface’i lokal network’e bağlayan nesne Kaynakça: Projeye özel terim … [U] Terim n + x: UPC Açılımı: Universal Product Code Tanımı: Ürüne has 12 basamaklı sayı Kaynakça: http://www.uc-council.org
Senaryo Odaklı Yazılım Geliştirme Yönteminde önceliklendirme en kritik konulardan bir tanesidir. Gereksinimler kendilerine atanan değişkenlere göre kolayca gruplara ayrılabilirler. Değişkenleri zaten proje ekibi bu tür yönetsel ihtiyaçlarını gidermek için tanımlamakta ve birbirleriyle ilişkilendirmektedir. Özel önem verilmesi gereken bir konu use case’lerin önceliklendirilmesidir. Kademeli ve Birbirinin Üzerine İnşaa Edilebilen bir çalışma (Iterative ve Incremental) bu mekanizma sayesinde mümkündür. Yine iteratif yazılım geliştirmenin sağladığı manevra kabiliyeti bu tür bir çalışma sonucunda mümkün olmaktadır.
UML süreci içerisinde takip edilebilirlik şu şekilde sağlanabilmektedir (Aşağıdaki Yukarıdakini Takip Edecek Şekilde): Müşteri İstekleri Vizyon (Sistem İşlevleri) Use Case Modeli (Kullanım Senaryolarının Tanımlanması) Kullanım Senaryosu Dokümanları (Fonksiyonel Gereksinimler) Ek Gereksinim Dokümanı (Fonksiyonel Olmayan Gereksinimler) Analiz Modeli Tasarım Modeli Deployment Modeli İmplementasyon Modeli Bu yapının içine ihtiyaç duyduğunuz diğer dokümanları ekleyebilirsiniz. Örneğin bir ‘Kanuni Yükümlülükler’ Dokümanı Vizyon’u etkileyerek yeni ürün sürümlerinin nedeni olabilir. Ürüne bağlı olmakla birlikte, tüm dokümanları (EA’da olduğu gibi) modele çekerek ‘kağıtsız ofis’e geçebilirsiniz.
Önceliklendirme ve Takip Edilebilirlik Kriterlerinin belirlendiği en önemli doküman Gereksinim Yönetimi Planı’dır. İçeriğini ileride göreceğimiz doküman hazırlanmadığı zamanlarda nispeten özet halinde Vizyon Dokümanının sonuna eklenir. UP’de ‘Vizyon’ ve ‘Gereksinim Yönetim Planı’ Sistem Analisti rolünün oluşturması gereken dokümanlardır.
UP’de ‘Vizyon’ ve ‘Gereksinim Yönetim Planı’ aslında Sistem Analisti rolünün oluşturması gereken dokümanlar olsalar da aşağıdaki görev dağılımını sık sık görmekteyiz: . Proje Yöneticisi: Vizyon, Gereksinim Yönetimi Planı veya . Sistem Analisti: Vizyon (Proje Yöneticisi ile birlikte) Bu görev dağılımı Sistem Analisti rolünün net olarak tanımlanmadığı şirketlerde görülmektedir. Unutmamak gerekir ki bu aslında bir uyarıdır. Çünkü Sistem Analisti ve Tasarımcı ayrımları UP’in en önemli rol tanımlarıdır.
[1] Gereksinim Yönetimi Planı: İşlev [Diğer gereksinimler için de yapılmalıdır] Değişkenleri İşlevler geliştirdiğiniz yazılım ürünlerinin değerlendirilmesini, izlenebilmesini, önceliklendirilerek yönetilebilmesini sağlar. Tüm gereksinim türleri ve değişkenlerini Gereksinim Yönetimi Planında açıklamalısınız. Aşağıda vizyon dokümanı kapsamındaki işlev değişkenlerinin açıklamalarını bulabilirsiniz [Hatırlarsanız Vizyon Dokümanı gereksinim türü İşlev (Feature) idi. Çoğu zaman doküman başına bir gereksinim türü tanımlanır]. Statü Önerildi: Resmi olarak kabul edilmemiş ve haklarındaki görüşmelerin devam ettiği işlevlerdir. Onaylandı: İstenen sistem özellikleri faydalı ve yapılabilir görüldü. Kapsama eklendi. Uygulandı: İstenen sistem özellikleri belli bir sürüm ve tarihte gerçekleştirildi.
[2] Gereksinim Yönetimi Planı: Fayda Zaruri: Eksiklikleri müşteri memnuniyetini ve proje başarısını kötü olarak etkileyen işlevlerdir. Önemli: Varlıkları müşteri memnuniyetini ve proje başarısını artıran işlevlerdir. Vazgeçilebilir: Yokluklarında aranmayan fakat varlıklarında müşteri memnuniyetini ve proje başarısını az oranda olsa da artıran işlevlerdir.
[3] Gereksinim Yönetimi Planı: Emek Daha fazla zaman ve kaynak ihtiyacı olan işlevleri diğerlerinden ayırarak, adam-hafta, satır-kod gibi hesaplamaları yapabilmek için kullanılır. Proje kapsamı ve önceliklerini yönetebilmek için etkili bir araçtır. Risk Proje sürecinde yaşanabilecek istenmeyen olayları öngörebilmek için kullanılır. Yaygın olarak kullanılan değerleri: Yüksek, Orta ve Düşük’tür. Güvenilirlik (Değişebilirlik) Sistemin tanımlanmış işlevlerinin değişebilirliklerini tanımlayarak, proje odağını belirlemek ve gerektiğinde kullanılacak ‘değişikliği tolere etme’ yöntemini geliştirmek için zaman kazanmak için kullanılır. Sürüm Sistem işlevlerinin gerçekleştirileceği sürümlerdir. Statü değişkeniyle birlikte kullanıldığında pek çok proje yönetimi karmaşıklığına ışık tutabilmenizi sağlar. Proje kapsam yönetimi için kullanılır.
[4] Gereksinim Yönetimi Planı: Görevli İşlevle ilgili çalışmalar (Gereksinim, Analiz ve Tasarım, Kodlama vs.) kimler tarafından gerçekleştirilecek belirlemeye yarar. Neden İşlevin varlığının nedeni açıklar.
UP süreç tanımı içinde Değişikliğin Yönetilmesi en önemli kavramlardan bir tanesidir. Değişikliğin yönetilebilmesi ise üç temel referansa sahiptir: Müşteri İsteklerinin ve Hataların Yönetilmesi Gereksinimlerin Yönetilmesi Ürün Konfigürasyonunun Yönetilmesi Bu çalışmaların yapılması kullanılan ürünlere bağlı olarak değişmekle birlikte, değişmeyen birlikte değerlendirilmeleri gerektiği ve bu üç konunun hepsine dayanan bir çözümün kullanılması gerektiğidir. Eğitimimizin konusu olan UML ise bu üç öğeyi birbirine bağlayan omurgadır. Dolayısıyla, yazılım süreçlerinizi iyileştirmeniz için ilk olarak yapabileceğiniz ve diğer çalışmalarınız size hep yol gösterecek bir konudur. Ürün uygulamalarına örnek verecek olursak, Sparx Systems: EA ve bir Versiyonlama Ürünü IBM: Rational RequisitePro, ClearQuest, ClearCase ve bir Rational UML ürünü Borland: StarTeam, CaliberRM ve bir Together versiyonu, vs. vs.
[1] İterasyonların Belirlenmesi İşlediğimiz konular dahilinde örneğimizi parçalara ayırmaya çalışacağız. Burada gereksinimler ve değişkenlerine tekrar değinmeyeceğiz. İncelediğimiz sistem: Kullanıcı’ların sisteme bağlanarak hesap açtıklarında Alıcı ve Satıcı olabildikleri bir internet’te açık artırma sistemidir. Olayların akışı özetle, Satıcıların sisteme bağlanarak bir Müzayede tanımlamaları ve bir seans açmalarıyla başlar. Daha sonra Alıcılar katalokta bu ürünü gördüklerinde ona yönelik tekliflerde bulunurlar. Belli zaman sonra müzayede otomatik olarak (daha önce Satıcı bitirmemişse) bitirilir. Bunun sonucunda hem Alıcı hem de Satıcı birer ikaz mesajı alırlar. Ödemeler dış bir sistem tarafından tahsil edilir.
[2] İterasyonların Belirlenmesi Tüm sistem kapsamında (bütün use case’ler için) birer kaba doküman (outline) hazırlanır. Bu dokümanlarda sadece use case tanımı, temel ve alternatif akışların isimleri ile ilgili oldukları diğer use case’lerin isimleri yer almalıdır. Bu bilgiler ışında ve use case değişkenlerinin değerlerine bakılarak, bir önceliklendirme yapılmaya başlanır.
[3] İterasyonların Belirlenmesi Önceliklendirme sonucunda iterasyon kapsamında use case’ler gruplara bölünür. İlk iterasyon kapsamları daha riskli, daha zor ve altyapıyla daha ilgi olmak üzere, her eklenen iterasyonda bu kapsam kolaylaştırılır. Elde edilen kilometre taşlarına göre iterasyonlar UP Fazları (Inception, Eleboration, Construction, Transition) altına yerleştirilir. İterasyon kapsamındaki her use case’in aynı zorlukta olması gerekmez. Her iterasyon kapsamında bir ‘hikaye bütünlüğü’ sağlayabilmek için eşdeğer zorluktaki ‘esas’ iterasyon kapsamına daha az zorlukta olan diğer use case’ler eklenebilir.
İlham Kaynakları Alistair Cockburn (Co-burn diye okunur): http://alistair.cockburn.us/ James Bielak: http://www.greenstoneconsulting.com/solutions/index.shtml Ellen Gottesdiener: http://www.ebgconsulting.com/