YAZILIM MÜHENDİSLİĞİ - 2

YAZILIM MÜHENDİSLİĞİ - 2

BÖLÜM 10: G

Bölüm Kapsamında İncelencek Konular:

• Müşteri ihtiyaçlarının neler olduğunu belirleme

• Gereksinimler iş akışına genel bakış

• Uygulama sahasını (domain) anlama

• İş modeli

• Başlangıç gereksinimleri

• İlk uygulama sahasını kavrama: The MSG Foundation örnek çalışması

• İlk iş modeli: The MSG Foundation örnek çalışması

• Başlangıç gereksinimleri: The MSG Foundation örnek çalışması

• Gereksinimler iş akışına devam: The MSG Foundation örnek çalışması

• Gereksinimleri gözden geçirme: The MSG Foundation örnek çalışması

• Test iş akışı: The MSG Foundation örnek çalışması

• Klasik gereksinimler safhası

• Hızlı prototipleme

• İnsan faktörleri

• Hızlı prototiplemenin yeniden kullanımı

• Gereksinimler iş akışı için CASE araçları

• Gereksinimler iş akışı için ölçütler

• Gereksinimler iş akışının değişimleri

G

İ

A

H

• Gereksinimler iş akışının hedefi, yazılım ürünü neyi yapabilmeli sorusuna yanıt vermektir.

M

Burada bir kavram hatası vardır. Müşterinin ne istediğini değil, neye ihtiyacı olduğunu tespit etmeliyiz.

• Bir sistem analistinin, bir yazılım ürününü ve bu yazılım ürününün fonksiyonlarını gözünde canlandırması zordur. Bu problem müşteri için çok daha kötüdür.

• Tecrübeli bir sistem analistinin, müşterinin ihtiyaçlarını belirleyebilmesi için müşteriden gerekli bilgileri edinmesi gerekmektedir. Bu bilgilerinde tek kaynağı müşteridir. Çünkü çalışma ortamını ve neye ihtiyacı olduğunu en iyi bilen müşteridir.

• Çözüm:

Müşteriden başlangıç bilgileri elde edilir.

Bu başlangıç bilgileri, Birleştirilmiş Sürece (Unified Process) giriş olarak kullanılır.

Yakın bir zamana kadar, Booch, Jacobson ve Rumbaugh’ın object-oriented metodolojileri oldukça başarılıydı. Bu üç object-oriented metodoloji, birbirinden bağımsız olarak çalışmaktaydı. 1999’da, Booch, Jacobson ve Rumbaugh’ın metodolojileri birleştirilerek, eksiksiz bir object-oriented analysis and design metodolojisi yayınlandılar. Orjinal adı: Rational Unified Process (RUP), Sonraki adı: Unified Software Development Process (USDP), Bugün kullanılan adı:

Unified Process (UP)

Müşterinin gerçek ihtiyaçlarını belirlemek için Birleştirilmiş Sürecin (Unified Process) adımları takip edilir.

Neydi bu adımlar?

Inception phase (başlangıç safhası),

Elaboration phase (detaylandırma safhası), Constraction phase (yapım safhası), Transition phase (geçiş safhası).

G

İ

A

G

G

• İlk olarak, uygulama sahasını yani application domain’i anlamalıyız. Yazılım ürününün kullanılacağı, işletileceği ortamı anlamamız gerekiyor.

• İkinci olarak, bir iş modeli (business model) oluşturmalıyız. Burada UML diyagramları kullanarak müşterinin iş süreçlerinin bir modelini oluşturuyoruz.

• Üçüncü olarak, bu iş modelini müşterinin ihtiyaçlarını belirlemek için kullanıyoruz.

• Bu adımları gerektiğinde tekrarlıyoruz.

T

• Müşterinin ihtiyaçlarını keşfetme

Gereksinimleri elde etme (requirements elicitation)

Görüşme (interviews) ve anket (surveys) metotlarını kullanma

• Başlangıç gereksinimlerinin genişletilmesi ve iyileştirilmesi

Gereksinimlerin analiz edilmesi

U

S

A

• Geliştirme takımının (development team) bütün üyeleri uygulama sahasına tam olarak aşina olmalıdır.

Bunun için doğru terminoloji gereklidir.

• Doğru terminolojiyi elde etmek içinde bir sözlük (glossary) oluşturulması gereklidir. Bu sözlükte;

Uygulama sahası içinde kullanılan teknik sözcüklerin bir listesi ve bunların anlamları yer alır.

İ

M

(B

M

)

• İş modeli, bir organizasyonun iş süreçlerinin tanımıdır.

Örneğin; bir bankada gerçekleştirilen işlemleri düşünürsek;

müşterilere kredi verilmesi, müşterinin bankaya para yatırması, müşterilerin birikimlerine yönelik yatırımların yapılması gibi bir bankanın iş süreçlerini tanımlayarak, bu banka için bir iş modeli oluşturabiliriz.

• İş modeli, müşterinin yapmış olduğu işin bir bütün olarak anlaşılmasını sağlar.

Bu bilgi müşterinin otomasyon sistemi hakkında geliştiricilerin (developers) bilgilendirilmesi için gereklidir.

• Sistem analisti, çeşitli iş süreçlerini anlayarak ayrıntılarını elde etmeye gereksinim duyar.

Bu ayrıntıları elde etmek için farklı teknikler kullanır. Bu teknikler içinde, öncelikle görüşmeyi (interviewing) kullanır.

G

(I

)

• Gereksinimleri belirleyen takım, konuyla ilgili bütün bilgileri çıkarmak için, müşteri ve kullanıcılarla görüşme yapmalıdır.

• Genelde görüşmelerde iki tip soru vardır;

Close-ended soruların cevabı kesindir. Örneğin; müşteriye, şirket çalışanlarının kaçı satış personeli diye sorulabilir? – veya – geliştirilecek sistemde yanıt süresinin (response time) hızlı olması gerekiyor mu?

Open-ended sorularda ise, görüşülen kişinin yazılım ürünü hakkında açıkça ne düşündüğünü öğrenmeye yönelik sorulan sorulardır.

Örneğin; müşteriye, şuan kullandığı, yazılım ürününün niçin onu tatmin etmediği veya niçin yetersiz gördüğü gibi sorular sorulabilir.

Müşteri bu soruyu, iş yaklaşımını birçok yönden ele alarak açıklayabilir.

• Görüşmelerin (interviews) iki tipi vardır;

Yapısal görüşme (structured interview); sorulacak olan sorular önceden planlanmış, hazırlanmıştır. Genellikle bunlar close-ended sorular oluyor.

Yapısal olmayan görüşme (unstructured interview); sorular önceden hazırlanıyor. Görüşme soru/cevap şeklinde geçiyor. Verilen cevaba göre başka soru soruluyor. Genellikle bu tür görüşmelerde sorular open-ended oluyor.

• Görüşme (interviewing) kolay değildir.

Gereğinden çok yapısal olmayan bir görüşme yapmak, konuyla ilgili çok fazla bilgi sağlamayacaktır.

Görüşmeci, uygulama sahasına tam olarak aşina olmalıdır.

Görüşmeci, her zaman açık fikirli olmalıdır.

• Görüşme sonrasında, görüşmeci yazılı bir rapor hazırlamalıdır. Hazırlamış olduğu raporun bir kopyasını da görüşme yaptığı kişiye vermelidir.

D

T

• Görüşme ilk tekniktir.

• Gereksinimleri belirlerken görüşü alınacak kişi sayısı fazla ise, anketlerde (questionnare) kullanılabilir. Sorular önceden hazırlanır ve close-ended olur.

• İş formlarını inceleme, güncel olarak müşterinin işi nasıl yaptığını gösterir.

• Bazen çalışanları iş yaparken direkt olarak gözlemlemek de işe yarayabilir.

Videotape kameralar, bu tekniğin modern bir versiyonu olur.

Fakat tape’leri analiz etmek uzun zaman alabilir

Çalışanlar, özel yaşam haklarına bir saldırı olarak bu durumdan rahatsız olabilirler.

U

C

• Use case, yazılım ürünü (product) ile yazılım ürününün kullanıcısı (aktör) arasındaki etkileşimi modeller.

• Örneğin = bir banka sistemi; süreç için iki aktör var. Müşteri (customer) ve veznedar (teller)

• Aktör, yazılım ürünü dışındaki dünyanın bir üyesidir.

• Genellikle bir aktörü belirlemek kolaydır.

Bir aktör çoğunlukla yazılım ürününün kullanıcısıdır.

• Genelde, aktör yazılım ürününde rol alır. Bu roller;

Kullanıcı (user),

Başlatıcı (initiator), ön ayak olan kimse,

Use case’in kritik bir kısmında rol oynayan kimse.

• Bir sistemin kullanıcısı, birden fazla rol oynayabilir.

• Örneğin = Bir bankanın müşterisi;

Borç Alan (Borrower) , Borç Veren (Lender).

• Bunun tersine, bir aktör birden fazla use-case içinde katılımcı olabilir.

• Örneğin = Borç Alan Kişi (Borrower)

Borç Para Alma (Borrow Money) use case’i

Kredi Faizi Ödeme (Pay Interest on Loan) use case’i

Anaparayı Geri Ödeme (Repay Loan Principal) use case’i içinde bir aktör olabilir.

• Ayrıca Borç Alan kişiyi oynayan aktör binlerce bank müşterisini temsil etmektedir.

• Bir aktör insan olmak zorunda değildir, bir yazılım ürünü de aktör olabilir.

Örneğin; bir e-ticaret bilgi sistemi, bir kredi kartı bilgi sistemi ile etkileşim halindedir.

Kredi kartı bilgi sistemi, e-ticaret bilgi sisteminin bakış açısından bir aktördür.

E-ticaret bilgi sistemi de, bir kredi kartı bilgi sisteminin bakış açısından bir aktördür.

• Aktörleri tanımlarken potansiyel problem, ortak yönleri olan (görevleri kesişen) aktörleri belirlemektir.

• Örneğin = Bir Hastane Yazılım Ürünü düşünürsek;

Bir use case’in aktörü Hemşire (Nurse),

Diğer bir use case’in aktörü Sağlık Elemanı (Medical Staff) olabilir.

En iyisi;

Aktörler: Doktor (Physician) ve Hemşire (Nurse) olmalıdır.

• Ya da alternatif olarak;

Sağlık Elemanı’nın (Medical Staff), iki özel durumu olsun;

Doktor (Physician) ve Hemşire (Nurse)

B

G

• Müşterinin gereksinimlerini tespit etmek için, başlangıç gereksinimleri ilk iş modeli temel alınarak düzenlenmektedir.

• Daha sonra uygulama sahası ve iş modelini anlayarak ve müşteri ile görüşerek, başlangıç gereksinimleri iyileştirmektir.

• Gereksinimler dinamiktir ve sıklıkla değişir. Bu değişimleri sık sık ele almak için en iyi yol, müşteri tarafından onaylanan gereksinimlerin use case’leri ile birlikte olması muhtemel gereksinimlerin bir listesini oluşturmaktır.

• Müşteriden elde edilen gereksinimler; işlevsel (functional) ve işlevsel olmayan (nonfunctional) gereksinimler olmak üzere iki kategoriye ayrılır.

• İşlevsel (functional) gereksinimler, yazılım ürününün yapacağı işi belirliyor.

Bir giriş verildiğinde nasıl bir çıkış ortaya çıkar. Yazılım ürününün fonksiyonlarını ortaya çıkarmaya çalışıyoruz.

• İşlevsel olmayan (nonfunctional) gereksinimler ise, yazılım ürününün özelliklerini belirler. Ne gibi özellikler olabilir;

Altyapı (platform) kısıtları, Yanıt süreleri (response times), Güvenilirlik (reliability).

• İşlevsel (functional) gereksinimler, gereksinimler (requirements) ve analiz (analysis) iş akışlarının icrası sırasında ele alınırken, işlevsel olmayan (nonfunctional) gereksinimler tasarım iş akışına kadar bekleyebilir. Bazı işlevsel olamayan gereksinimler için ayrıntılı bilgiler, gereksinimler ve analiz iş akışları tamamlanana kadar mevcut olmaz.

M

S

G

F

C

S

Martha Stockton Greengage 87 yaşında öldüğünde, 2.3 milyar dolarlık servetinin tamamını yardım derneğine bıraktı. Onun adına kurulmuş olan Martha Stockton Greengage Vakfı, düşük fiyatlı krediler vasıtasıyla genç çiftlerin ev satın almalarına yardım etmektedir.

İşlem masraflarını azaltmak için, MSG Vakfı’nın yöneticileri bilgisayarlı otomasyon sistemlerini incelemişlerdir. Vakıf yöneticilerinin hiçbiri bilgisayarlar ile ilgili olarak herhangi bir tecrübeye sahip olmadığından, ev satın almak için her hafta ne kadar paranın gerekli olduğuna karar vermek üzere gerekli hesaplamaları yerine getirecek bir yazılım ürününü yani pilot projeyi gerçekleştirmek için küçük bir yazılım geliştirme organizasyonu görevlendirmeye karar vermişler.

Her zaman ki gibi ilk adım, uygulama sahasını anlamaktır, bu örnekte ipotekli konut finansman kredisi (mortgage) verilmiş. Birçok insanın, bir ev satın alabilmek için peşin ödemeye gücü yetmemektedir. Bunun yerine, insanlar kendi birikimlerinden evi satın alma ücretinin küçük bir yüzdesini öderler ve geri kalan parayı ödünç alırlar. Bu bir kredi tipidir, kredi için teminat olarak aynı mülk ipotek edilmektedir, bu ipotekli konut finansman kredisi (mortgage) olarak adlandırılır.

Örneğin, birisinin $100.000’lık bir ev satın almak istediğini varsayalım. Evi satın almak isteyen kişi yüzde 10 veya $10.000 peşinat (deposit) öder ve geri kalan

$90.000’lık miktarı da ipotekli konut finansman kredisi kapsamında bir banka veya kredi tasarruf firması gibi mali bir kurumdan ödünç alır. Sonuç olarak $90.000 anapara (principal or capital) ödünç alınmıştır.

İpotekli konut finansman kredisinin (mortgate) koşulları olarak, her yıl yüzde 7.5 (her ay yüzde 0.625) faiz oranında 30 yıl üzerinden aylık taksitlerle borcun geri ödeneceğini varsayalım.

• Borçlu her ay finans şirketine $629.30 öder. Bu miktarın bir kısmı ödenmemiş bakiyenin faizi; geri kalan kısmı ise anaparayı azaltmak için kullanılır.

• Bu aylık ödeme dolayısıyla çoğu zaman P & I (Principal – Anapara &

Interest - Faiz) olarak bilinmektedir.

• Örneğin, ilk ayda ödenmemiş bakiye $90.000’dır. $90.000 üzerinden yüzde 0.625 aylık faizi, $562.50'dır. $629.30’lık P & I (aylık ödeme) ödemesinin geri kalan kısmı, yani $66.80 ise anaparayı azaltmak için kullanılmaktadır.

Sonuç olarak, ilk ayın sonunda, ilk ödeme sonrası finans şirketi $89,933.20 alacaklıdır.

• İkinci ay için faiz $89,933.20’nin yüzde 0.625’i, yani $562.08’dır.

• $629.30’lık P & I ödemesinin geri kalan kısmı, yani $67.22 ise anaparayı azaltmak için kullanılmaktadır.

• İkinci ayın sonunda, ikinci ödeme sonrası finans şirketi $89,865.98 alacaklıdır.

• 15 yıl sonra (180 ay), P & I ödemesi hala $629.30’dır, ama şu anda anapara

$67,881.61’a azalmıştır.

$67,881.61 üzerinden aylık faiz $424.26’dır, bundan dolayı P & I ödemesinin $205.04’lık geri kalan kısmı anaparayı azaltmak için kullanılmaktadır.

• 30 yıl sonra (360 ay) borcun tamamı geri ödenmiş olacaktır.

•

• Birincisi, borçlu beyan edilen bir yasal dokümanı (ipotekli konut finansman kredi sözleşmesi) imzalar. Eğer borçlu aylık ödemeleri yapamazsa, finans şirketi evi satabilir ve borcun ödenmemiş bakiyesini ödemek için satıştan elde edilen geliri kullanabilir.

• İkincisi, finans şirketi borçludan evi sigorta altına almasını ister. Böylece ev yanıp kül olsa bile, sigorta şirketi zararı karşılayacak ve sigorta şirketinden gelen sigorta poliçesi daha sonra borcu geri ödemek için kullanılacaktır.

• Sigorta primleri, finans şirketi tarafından genellikle yılda bir defa ödenmektedir.

Finans şirketi borçludan aylık sigorta prim taksitlerini ödemesini ister.

Prim taksitleri banka tarafından borçluya açılan bir bloke hesaba (escrow account) yatırılır. Bu bloke hesap finans şirketi tarafından yönetilen bir tasarruf hesabı (savings account) dır.

• Yıllık sigorta priminin vadesi geldiğinde, para bloke hesaptan alınmaktadır.

• Evin emlak vergisi (real-estate tax) ödemesi de aynı yoldan işlem görmektedir, yani aylık taksitler bankaya bloke hesap içinde yatırılmaktadır ve yıllık emlak vergisi ödemesi de bu hesaptan yapılmaktadır.

• Üçüncüsü, finans şirketi ipotekli konut finansman kredisi için borçlunun ödeme gücünün olup olmadığından emin olmak ister. Genellikle, toplam aylık ödeme (P & I + sigorta + emlak vergisi) borçlunun toplam gelirinin yüzde 28’ini aşıyorsa ipotekli konut finansman kredisi kabul edilmemektedir.

• Aylık ödemelere ek olarak, finans şirketi neredeyse her zaman, borçluya parayı ödünç vermeye karşılık olarak yapılan bütün toplam masrafların ödenmesini ister. Genellikle, finans şirketi anaparanın yüzde 2’sini (2 points–borçlanılan paranın maliyeti) isteyecektir. Kredinin $90.000 olması durumunda, bu miktar $1800’dır.

• Son olarak, bir ev satın alırken yasal giderler ve çeşitli vergiler gibi diğer giderler vardır. Bu nedenle, $100.000’lık bir evi satın almak için anlaşma imzalarken, gayrimenkul mülkiyeti devrinde alıcı ve satıcıların giderleri (closing costs – yasal giderler, vergiler ve diğer…), artı borçlanılan paranın maliyeti muhtemelen $7000’ı bulabilir.

• Bakiye (Balance): Ödenmemiş kredinin miktarı.

• Anapara (Capital): Borç alınan toplam peşin para. Principal’ın eşanlamlısı.

• Closing Costs: bir evi satın almak için anlaşma imzalarken, gayrimenkul mülkiyeti devrinde alıcı ve satıcıların giderleri (yasal giderler, vergiler ve diğer…)

• Peşinat (Deposit): evin toplam maliyetine karşı başlangıç taksiti.

• Bloke hesap (escrow account): Prim taksitleri banka tarafından borçluya açılan bir bloke hesaba (escrow account) yatırılır. Bu bloke hesap finans şirketi tarafından yönetilen bir tasarruf hesabı (savings account) dır. Evin emlak vergisi (real-estate tax) ödemesi de aynı yoldan işlem görmektedir,

yani aylık taksitler bankaya bloke hesap içinde yatırılmaktadır ve yıllık emlak vergisi ödemesi de bu hesaptan yapılmaktadır.

• Faiz (Interest): Ödenmemiş miktarın bir kısmı olarak hesaplanan, borç alınan paranın maliyeti.

• İpotekli Konut Finansman Kredisi (Mortgage): Kredinin teminatı olarak aynı mülkü ipotek eden bir kredi tipidir.

• P & I: Principal – Anapara & Interest – Faiz için kısaltmadır.

• Borçlanılan Paranın Maliyeti

(

• Anapara (Principal): Borç alınan toplam peşin para.

• Anapara & Faiz (Principal & Interest): Ödenmemiş bakiyenin faizi, artı anaparanın bir kısmını içeren aylık ödeme.

B

İ

M

: MSG C

S

• Yazılım geliştirme ekibinin üyeleri, MSG Vakfı’nın farklı yöneticileri ve çalışan elemanları ile görüşmeler (interviews) yaptılar ve Vakıf’ın faaliyet gösterdiği iş alanını anlamaya çalıştılar.

• Her hafta başında, MSG Vakfı ipotekli konut finansman kredileri için (mortgates) haftalık ne kadar para finanse edeceğini yani ne kadar para kaynağı ayıracağını tahmin etmek ister.

• Standart bir ipotekli konut finansman kredisini karşılama da oldukça düşük gelire sahip olan çifte, MSG Vakfı bir ev satın almak için dilediği zaman ipotekli konut finansman kredisini (mortgage) uygulayabilmelidir.

• MSG Vakfı çalışanı ilk olarak, MSG ipotekli konut finansman kredisi (mortgage) için çiftin nitelikli olup olmadığına karar verir. Aynı zamanda MSG Vakfı çalışanı, MSG Vakfı’nın o hafta evi satın alabilmek için mevcut birikiminin yeterli olup olmadığına karar verir.

• Eğer ipotekli konut finansman kredisi (mortgage) onaylanırsa; haftalık ipotekli konut finansman kredisi (mortgage) geri ödemesi, MSG Vakfı'nın kurallarına göre hesaplanır.

• Bu geri ödeme miktarı, çiftin güncel gelirine bağlı olarak haftadan haftaya değişebilir.

• İlk iş modelinin bir kısmı ile ilgili olarak, üç use case var;

Haftalık kullanılabilir birikimleri tahmin etme

MSG ipotekli konut finansman kredisine (mortgage) başvurma Haftalık geri ödeme miktarlarını hesaplama

HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE’İ

Bu use case MSG Vakfı çalışanına, MSG Vakfı’nın ipotekli konut finansman kredilerini (mortgates) haftalık ne kadar para finanse edeceğini yani ne kadar para kaynağı ayıracağını tahmin etmesinde yardımcı olur.

MSGİPOTEKLİ KONUT FİNANSMAN KREDİSİNE BAŞVURMA USE CASE’İ

Bir çift ipotekli konut finansman kredisine (mortgage) başvurduğunda, bu use case;

MSG Vakfı çalışanının, MSG ipotekli konut finansman kredisi (mortgage) için çiftin nitelikli olup olmadığına ve aynı zamanda MSG Vakfı’nın o hafta evi satın alabilmek için mevcut birikiminin yeterli olup olmadığına karar vermesinde yardımcı olur.

HAFTALIK GERİ ÖDEME MİKTARLARINI HESAPLAMA USE CASE’İ

Bu use case; MSG Vakfı çalışanına, borçlunun her hafta ne kadar geri ödemesi gerektiğini hesaplamada yardımcı olmaktadır.

Aktör Kimdir?

• MSG ipotekli konut finansman kredisine başvurma use case’i içinde Başvuran Kişiler (Applicants) niye bir aktördür?

• Yazılım ürününün kullanıcısı aynı zamanda bir aktördür. Ancak Başvuran Kişiler (Applicants) yazılım ürününü kullanmamaktadırlar. Bu kişiler sadece başvuru formunu doldurmaktadırlar. Başvuru yapan kişilerin başvuru formunda vermiş olduğu cevaplar, MSG Vakfı çalışanı tarafından yazılım ürününe girilmektedir. Bu nedenle Başvuran Kişiler (Applicants), yazılım ürünü ile etkileşim halinde değildirler.

• Bununla beraber,

Başvuran Kişiler (Applicants), use case’i başlatır. Eğer çiftler ipotekli konut finansman kredisine başvurmazlarsa, bu use case asla meydana gelmez.

MSG Vakfı çalışanı tarafından yazılım ürününe girilen bilgiler, Başvuran Kişiler (Applicants) tarafından sağlanır.

Bir anlamda, gerçek aktör Başvuran Kişiler (Applicants) dir, MSG Vakfı çalışanı, başvuran kişiler için sadece bir aracıdır.

• Bu yüzden Başvuran Kişiler (Applicants), gerçekte bir aktördür.

• Benzer olarak Borç Alan Kişiler (Borrowers) de, haftalık geri ödeme miktarlarını hesaplama use case içinde bir aktördür.

Bu use case de, Borç Alan Kişiler (Borrowers) aktörü tarafından başlatılmaktadır.

Aynı biçimde Borç Alan Kişiler (Borrowers) tarafından sağlanan bilgiler, MSG Vakfı çalışanı tarafından yazılım ürününe girilmektedir.

• Bu nedenle, Borç Alan Kişiler (Borrowers), use case içinde gerçekte bir aktördür.

BİR YATIRIMI YÖNETME USE CASE’İ

• MSG Vakfı iş modelinin diğer bir yaklaşımı, MSG Vakfı’nın yatırımları ile ilgilidir. Yatırımların alımı ve satımı veya ipotekli konut finansman kredisi için geçerli yatırım gelirinin ne olduğu ile ilgili detaylar bu adımda henüz bilinmemektedir.

• Hâlbuki bu use case, ilk iş modelinin gerekli bir parçasıdır.

BİR YATIRIMI YÖNETME USE CASE’İ

Bu use case; MSG Vakfı çalışanının, yatırım alım-satımı ve yatırım portföyünü yönetmesini sağlar.

B

G

: MSG C

S

• Bir önceki slâytta gördüğümüz dört use case, MSG Vakfı’nın iş modelini kapsamaktadır. Ancak bu dört use case, geliştirilecek yazılım ürününün bütün gereksinimlerini karşılayıp karşılamadığı konusunda açık değildir.

Müşterinin ne istediğini hatırlarsak; “ev satın almak için her hafta ne kadar paranın uygun olduğuna karar vermek için gerekli hesaplamaları yerine getirecek bir yazılım ürününü yani pilot projeyi gerçekleştirmekti.”

Her zaman ki gibi, geliştiricilerin görevi, müşterinin yardımı ile müşterinin neye ihtiyacı olduğunu tespit etmektir. Bu ilk aşamada, analistlerin nezdinde neye ihtiyaç duyulup duyulmadığını belirlemede sadece bu pilot projeyle karar verebilmesi için yeterince bilgi yoktur.

• Böyle bir durumda ilerlemek için en iyi yol, müşterinin ne istediğine dayanarak başlangıç gereksinimlerini düzenlemektir ve sonra tekrar etmektir.

• Sırasıyla her bir use case’i düşünelim:

Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’i açıkçası başlangıç gereksinimlerinin bir kısmıdır.

MSG İpotekli Konut Finansman Kredisine (mortgage) Başvurma (Apply for an MSG Mortgage) use case’inin, pilot projeyle aralarında herhangi bir alışveriş olmadığı görülmektedir, bundan dolayı bu use case başlangıç gereksinimlerinden ayrı tutulur.

Haftalık Geri Ödeme Miktarlarını Hesaplama (Compute Weekly Repayment Amount) ve Bir Yatırımı Yönetme (Manage an Investment) use case’lerinin her ikisininde pilot proje ile ilgili olduğu görülmektedir.

• Bununla birlikte, pilot proje "ev satın almak için her hafta ne kadar paranın uygun olduğu" ile de uğraşmaktadır.

Bu paranın bir kısmı mevcut ipotekli konut finansman kredilerinin haftalık geri ödemelerinden, diğer bir kısmı da yatırımlardan elde edilen gelirlerden gelmektedir.

• Sonuçta oluşan use case diyagramı bir sonraki slâytta görülmektedir.

• Bir sonraki adım: gereksinimler iş akışını tekrarlamaktır.

Uygulama sahası hakkında bilgi sahibi olan geliştirme takımının üyeleri MSG Vakfı yöneticileri ve çalışanlarıyla görüşerek, büyük ölçüde ilk iş modeline aşina olmaktadırlar. Geliştirme takımı üyeleri, aşağıda verilen bilgilerin farkına varmıştır.

• MSG Vakfı, aşağıdaki koşulların altında bir ev satın almak için yüzde yüz ipotekli konut finansman kredisini destekler:

Çift yasal olarak en az 1 yıllık evli olmalıdır, ama 10 yıldan daha çok evli olmamalıdırlar.

Karı koca, her ikisi de maaş karşılığı çalışan olmalıdırlar.

Evin bedeli, geçmiş 12 ay boyunca evin bulunduğu çevredeki evler için açıklanan ortalama bedelin altında olmalıdır.

Çiftlerin geliri ve/veya tasarrufu, 90% ipotekli konut finansman kredisini (mortgage) 30 yıl standart bir sabit-oranda karşılamak için yetersiz olmalıdır.

Vakıf evi satın almak için, yeterli birikimlere sahip olmalıdır.

• Eğer başvuru onaylanırsa, çift sonraki 30 yıl boyunca her hafta MSG Vakfı’na;

Anapara ve faiz ödemesinin toplamını – ipotekli konut finansman kredisinin süresi boyunca asla değişmez; artı

Bloke masrafı, yıllık emlak vergisi ve evin yıllık sigorta primi toplamının 1/52’sini öder.

• Eğer bu toplam, çiftin haftalık brüt gelirinin %28’inden daha fazlaysa, MSG Vakfı bir bağış biçiminde bu farkı ödeyecektir. Sonuç olarak ipotekli konut finansman kredisi (mortgage), her hafta tam olarak ödenecektir, ama çift asla ortak brüt gelirinin 28%’in den daha fazla ödemek zorunda olmayacaktır.

MSG Vakfı, bir ipotekli konut finansman kredisi (mortgage) uygulamasını onaylarken birikimlerin yeterli olup olmadığı belirlemek için aşağıdaki algoritmayı kullanır.

1) Hafta başında, MSG yatırımlarından tahmini yıllık gelir hesaplanır ve 52'ye bölünür.

2) Tahmini yıllık MSG işletme giderleri, 52'ye bölünür.

3) Haftalık ipotekli konut finansman kredisi (mortgage) ödemelerinin tahmini toplamı hesaplanır.

4) Hafta boyunca tahmin edilen bağışların toplamı hesaplanır.

5) Hafta başında eldeki mevcut miktar: (1) - (2) + (3) - (4) tür.

6) Eğer evin fiyatı (5.) adımda elde edilen miktardan daha fazla değilse, evi satın almak için birikimler tedarik edilir.

7) Her haftanın sonunda, harcanmamış herhangi bir birikim yatırım yapılır.

Pilot Proje’nin Gereksinimleri

• Pilot projenin maliyetini mümkün olduğunca düşük tutmak için, geliştiricilere haftalık birikimlerin hesabı için gerekli olan veri öğelerinin yazılım ürünü içinde birleştirilmesi gerektiği söylenir.

• Burada sadece 3 tip veriye gereksinim vardır:

Yatırım verisi (investment data),

İşletme giderleri verisi (operating expenses data),

İpotekli konut finansman kredisi verisi (mortgage data).

Y

V

((I

D

)

• Öğe numarası,

• Öğe adı,

• Tahmini yıllık getiri,

• Tahmini yıllık getirinin en son güncellenmiş olduğu tarih

İ

G

V

(O

E

D

)

• Tahmini yıllık işletme giderleri,

• Tahmini yıllık işletme giderlerinin en son güncellenmiş olduğu tarih.

İ

K

F

K

V

(

)

• Hesap numarası,

• İpotekli konut finansman kredisine (mortgage data) başvuranın soy ismi,

• Evin gerçek satın alma fiyatı,

• İpotekli konut finansman kredisinin düzenlenmiş olduğu tarih,

• Haftalık anapara ve faiz ödemesi,

• Şu anki müşterek haftalık brüt gelir,

• Şu anki müşterek haftalık brüt gelirin en son güncellenmiş olduğu tarih,

• Yıllık emlak vergisi,

• Yıllık emlak vergisinin en son güncellenmiş olduğu tarih,

• Evin yıllık sigorta primi,

• Evin yıllık sigorta priminin en son güncellenmiş olduğu tarih.

P

P

G

R

• Üç tip rapora gereksinim vardır:

Haftalık hesaplanan birikimlerin sonuçları,

Bütün yatırımların listesi (istenildiği zaman basılmalı)

Bütün ipotekli konut finansman kredilerinin listesi (istenildiği zaman basılmalı)

GEREKSİNİMLERİ TEKRAR GÖZDEN GEÇİRİP DÜZELTME:MSGCASE STUDY

• Başlangıç gereksinimleri aşağıdaki üç use case içeriyordu:

Haftalık kullanılabilir birikimleri tahmin etme, Haftalık geri ödeme miktarlarını hesaplama, Bir yatırımı yönetme.

• Şimdi alınan bu ekstra bilgilerin ışığında, başlangıç gereksinimleri yeniden gözden geçirilebilir.

• MSG Vakfı’nın ipotekli konut finansman kredileri için (mortgates) haftalık ne kadar para finanse edeceğini yani ne kadar para kaynağı ayıracağını hafta başında belirlemek için daha önce verilen algoritmanın adımlarını göz önüne alalım. Bu adımlar aşağıdaki gibiydi:

1) Hafta başında, MSG yatırımlarından tahmini yıllık gelir hesaplanır ve 52'ye bölünür.

2) Tahmini yıllık MSG Vakfı işletme giderleri, 52'ye bölünür.

3) Haftalık tahmini ipotekli konut finansman kredisi (mortgage) ödemelerinin toplamı hesaplanır.

4) Haftalık tahmini bağışların toplamı hesaplanır.

5) Hafta başında eldeki mevcut miktar: (1) - (2) + (3) - (4) tür.

• Bu adımları her birini sırasıyla göz önüne alalım.

1) Yatırımlardan yıllık geliri tahmin etme: Bütün yatırımları al, yıllık tahmini her bir yatırım getirisini topla ve sonucu 52'ye böl.

İlaveten, Haftalık Yatırım Gelirlerini Tahmin Etme use case’ine ihtiyaç duyulmaktadır. (Buna rağmen yatırımları eklemek, silmek ve değiştirmek için Bir Yatırımı Yönetme use case’ine gereksinim duyarız.)

Haftalık Yatırım Gelirlerini Tahmin Etme use case’i, burada görüldüğü gibi resmedilmiştir ve bir sonraki slâytta da ayrıntılı olarak bu use case tanımlanmaktadır. Burada <<include>> (içerme) olarak etiketlenmiş bir ucu açık ok ile Haftalık Yatırım Gelirlerini Tahmin Etme use case’inin, Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’inin bir parçası olduğu gösterilmektedir.

Haftalık Yatırım Gelirlerini Tahmin Etme use case’inin açıklaması:

Kısa Açıklama

Haftalık Yatırım Gelirlerini Tahmin Etme use case’i, Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’inin haftalık kullanılabilir ne kadarlık bir yatırım geliri olduğunu tahmin etmesinde yardımcı olur.

Adım Adım Açıklama

1. Her bir yatırım için, yıllık tahmini yatırım getirisini çıkar.

2. Birinci adımda çıkartılmış değerleri topla ve sonucu 52'ye böl.

Use-Case Diyagramın Yeniden Gözden Geçirilmesinin İlk İterasyonu sonucunda, yeni use case farklı renkte gölgelendirilmiştir.

2) Tahmini yıllık işletme giderleri (estimated annual operating expenses):

Şimdiye kadar, tahmini yıllık işletme giderlerini düşünmemiştik. Bu giderleri birleştirmek için, ek olarak iki use case’e daha ihtiyaç duyulmaktadır.

Tahmini Yıllık İşletme Giderlerini Güncelleme (Update Estimated Annual Operating Expenses) use case’i, tahmini yıllık işletme giderleri değerlerinin düzenlenmesini modeller.

Haftalık İşletme Giderlerini Tahmin Etme (Estimate Operating Expenses for Week) use case’i de, gerekli olan işletme giderlerinin tahmin edilmesini sağlar.

Tahmini Yıllık İşletme Giderlerini Güncelleme (Update Estimated Annual Operating Expenses) Use Case’i

Kısa Açıklama

Tahmini Yıllık İşletme Giderlerini Güncelleme (Update Estimated Annual Operating Expenses) use case’i, MSG Vakfı çalışanına tahmini yıllık işletme giderlerini güncellemede yardımcı olur.

Adım Adım Açıklama

1. Tahmini yıllık işletme giderlerini güncelle.

Haftalık İşletme Giderlerini Tahmin Etme (Estimate Operating Expenses for Week) Use Case’i

Haftalık İşletme Giderlerini Tahmin Etme (Estimate Operating Expenses for Week) use case’i, Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’inin bir parçası olduğu için kesikli ok üzerinde <<include>> (içerme) ile gösterilmektedir.

Kısa Açıklama

Tahmini Yıllık İşletme Giderlerini Güncelleme (Update Estimated Annual Operating Expenses) use case’i, Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’inin haftalık işletme giderlerini tahmin etmesinde yardımcı olur.

Adım Adım Açıklama

1. Tahmini yıllık işletme giderlerini 52’ ye böl.

Use-Case Diyagramının yeniden düzenlenmesiyle ikinci iterasyon şekil 10.21’de görüldüğü gibi oluşmaktadır. Burada iki yeni use case farklı renkte gölgelendirilmiştir.

3) Haftalık tahmini mortgage ödemelerinin toplamı ve

4) Haftalık tahmini bağış ödemelerinin toplamı:

Haftalık Geri Ödeme Miktarlarını Hesapla (Compute Weekly Repayment Amount) use case’i her bir mortgage için ayrı olarak tahmini mortgage ödemesi ve tahmini bağış ödemesinin hesaplanmasını modeller.

Bu ayrı miktarların toplamı, haftalık tahmini mortgage ödemelerinin toplamını ve haftalık tahmini bağış ödemelerinin toplamını verir.

• Bununla beraber Haftalık Geri Ödeme Miktarlarını Hesapla (Compute Weekly Repayment Amount) use case’i, aynı zamanda borç alan kişilerin (borrowers) haftalık gelir miktarındaki değişimleri de modeller.

• Dolayısıyla, Haftalık Geri Ödeme Miktarlarını Hesapla (Compute Weekly Repayment Amount) use case’ini, Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) ve Borç Alan Kişinin Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) use case’i olmak üzere iki use case’e bölebiliriz.

Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) Use Case’i

Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’i, Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’inin bir parçası olduğu için kesikli ok üzerinde <<include>> (içerme) ile gösterilmektedir.

Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) Use Case’i

Kısa Açıklama

Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’i, Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’inin içinde bulunulan haftada MSG Vakfı tarafından ödenen toplam bağış miktarlarını ve MSG Vakfına borçlu tarafından ödenen tahmini toplam mortgage ödemelerini tahmin etmesinde yardımcı olur.

Adım Adım Açıklama 1. Her bir mortgage için;

1.1. İçinde bulunulan hafta ödenecek miktar, evin yıllık sigorta primi, yıllık emlak vergisi, anapara ve faiz ödemesinin toplamıdır.

1.2. Çiftin güncel haftalık brüt gelirinin yüzde 28’i hesaplanır.

1.3. Eğer adım 1.1.’in sonucu adım 1.2.’nin sonucundan büyükse, içinde bulunulan hafta için mortgage ödemesi adım 1.2’de elde edilen sonuçtur. Ayrıca içinde bulunulan hafta için yapılacak olan bağışın miktarı, adım 1.1.’in sonucu ile adım 1.2.’nin sonucu arasındaki farktır.

1.4. Aksi durumda, içinde bulunulan hafta için mortgage ödemesi adım 1.1’de elde edilen sonuçtur ve o hafta için bağış yapılmaz.

2. Adım 1.3 ve 1.4’deki mortgage ödemelerinin toplamı, haftalık tahmini mortgage ödemelerini verir.

3. Adım 1.3’teki bağış ödemelerinin toplamı, haftalık tahmini bağış ödemelerini verir.

Borç Alan Kişinin Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) Use Case’i

Kısa Açıklama

Borç Alan Kişinin Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) use case’i, Vakıf’tan borç para alan bir çiftin haftalık gelirini güncellemede MSG Vakfı çalışanına yardımcı olur.

Adım Adım Açıklama

1. Borç alan kişinin haftalık gelirini güncelle.

Use-Case Diyagramının yeniden düzenlenmesiyle üçüncü iterasyon şekil 10.26’de görüldüğü gibi oluşmaktadır. Burada iki yeni use case farklı renkte gölgelendirilmiştir.

Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’i

• Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’i, diğer üç use case’den elde edilen veriyi kullanarak hesaplamayı modeller. Bu üç use case;

Haftalık Yatırım Gelirlerini Tahmin Etme (Estimate Investment Income for Week),

Haftalık İşletme Giderlerini Tahmin Etme (Estimate Operating Expenses For Week),

Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week).

Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’inin ikinci iterasyonu yukarıdaki şekilde görüldüğü gibidir. Bu şekil bir önceki yani Şekil 10.26’daki use case diyagramından çıkartılmıştır.

Bir sonraki slâytta Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’inin açıklaması yer almaktadır.

Kısa Açıklama

Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’i, MSG Vakfı çalışanına, MSG Vakfı’nın ipotekli konut finansman kredilerini (mortgates) haftalık ne kadar para finanse edeceğini yani ne kadar para kaynağı ayıracağını tahmin etmesinde yardımcı olur.

Adım Adım Açıklama

1. Haftalık Yatırım Gelirlerini Tahmin Etme (Estimate Investment Income for Week) use case’ini kullanarak yatırımlardan haftalık tahmini geliri belirle.

2. Haftalık İşletme Giderlerini Tahmin Etme (Estimate Operating Expenses for Week) use case’ini kullanarak haftalık işletme giderlerini belirle.

3. Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’ini kullanarak haftalık tahmini toplam mortgage ödemelerini belirle.

4. Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’ini kullanarak haftalık tahmini toplam bağışları belirle.

5. Adım 1 ve 3’ün sonuçlarını topla ve Adım 2 ve 4’ün sonucundan çıkar. Çıkan sonuç, içinde bulunulan haftada mortgage için kullanılabilir toplam miktardır.

• Üstteki gösterim doğrudur. Alttaki gösterim yanlıştır.

• Alttaki diyagram, Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) ve Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’lerini iki ayrı use case olarak modelliyor.

• Hâlbuki bir use case, bir yazılım ürünü (product) ile bu yazılım ürününün kullanıcısı arasındaki etkileşimi modeller.

• Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’i, bir aktör ile etkileşim halinde değildir ve bu yüzden tek başına bir use case olamaz.

Bunun yerine üstteki diyagramda da gösterildiği gibi Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’i Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’inin bir parçasıdır.

• Iterative and incremental life-cycle modelin bilinen bir yan etkisi vardır.

Ertelenen detaylar unutulur. Bu yüzden devamlı test yapmak önemlidir.

Bir sonraki slâytta test iş akışı ile ilgili olarak iki örnek verilmiştir.

• Yatırım Yönetme (Manage an Investment) use case’inin detayları gözden kaçırılmıştır.

• Mortgage Yönetme (Manage an Mortgage) use case’inin;

Yeni bir mortgage’ın eklenmesi,

Var olan bir mortgage’ın düzenlenmesi, Var olan bir mortgage’ın silinmesi

gibi üç işlemin modellenmesi tamamen unutulmuştur.

Yatırım Yönetme (Manage an Investment) Use Case’i

• Burada use case üzerinde düzeltme yapıyoruz.

Kısa Açıklama

Yatırım Yönetme (Manage an Investment) use case’i, MSG Vakfı çalışanının yatırım ekleme – silme işlemlerini gerçekleştirmesini ve yatırım portföyünü yönetmesini sağlar.

Adım Adım Açıklama

1. Bir yatırımı ekleme, düzenleme veya silme.

Mortgage Yönetme (Manage an Mortgage) Use Case’i

• Burada use case üzerinde düzeltme yapıyoruz.

Kısa Açıklama

Mortgage Yönetme (Manage an Mortgage) use case’i, MSG Vakfı çalışanının mortgage ekleme – silme işlemlerini gerçekleştirmesini ve mortgage portföyünü yönetmesini sağlar.

Adım Adım Açıklama

1. Bir mortgage ekleme, düzenleme veya silme.

Use-Case Diyagramının yeniden düzenlenmesiyle dördüncü iterasyon şekil 10.34’de görüldüğü gibi oluşmaktadır. Burada yeni use case farklı renkte gölgelendirilmiştir.

• Burada başka bir eksiklik daha var. Bu eksiklikte Rapor Üretme (Produce a Report) use case’i.

Yatırımların raporu, Mortgage’ların raporu,

Haftalık hesaplamaların sonuçları, olmak üzere üç rapor eksiktir.

Rapor Üretme (Produce a Report) use case’i

Rapor Üretme (Produce a Report) Use Case’i

Kısa Açıklama

Rapor Üretme (Produce a Report) use case’i, MSG Vakfı çalışanına bütün yatırımların veya mortgage kredilerinin listesini yazdırmasında veya yeni bir mortgage kredisi için haftalık hesaplanan kullanılabilir birikimlerin sonuçlarının yazdırmasında yardımcı olur.

Adım Adım Açıklama

1. Aşağıdaki raporlar üretilebilmelidir:

1.1. Yatırım raporları – isteğe bağlı basılır:

Bilgi sistemi, bütün yatırımların bir listesini yazdırır. Her bir yatırım için aşağıdaki nitelikleri yazdırır:

- Yatırım numarası - Yatırım adı

- Tahmini yıllık getiri

- Tahmini yıllık getirinin en son güncellenmiş olduğu tarih

1.2. Mortgage raporları – isteğe bağlı basılır:

Bilgi sistemi, bütün mortgage’ların bir listesini yazdırır. Her bir mortgage için aşağıdaki nitelikleri yazdırır:

- Hesap numarası

- Mortgage kredisine başvuran kişinin soyadı - Evin gerçek fiyatı

- Mortgage’ın düzenlenmiş olduğu tarih - Anapara ve faiz ödemeleri

- İçinde bulunulan hafta için haftalık brüt gelir

- İçinde bulunulan hafta için haftalık brüt gelirin en son güncellendiği tarih

- Yıllık emlak vergisi

- Yıllık emlak vergisinin en son güncellendiği tarih - Evin yıllık sigorta primi

- Evin yıllık sigorta primi en son güncellendiği tarih 1.3. Haftalık hesaplamaların sonuçları – her hafta basılır:

Bilgi sistemi, içinde bulunulan hafta esnasında yeni bir mortgage için kullanılabilir toplam miktarı yazdırır.

Use-Case Diyagramının yeniden düzenlenmesiyle beşinci iterasyon şekil 10.37’de görüldüğü gibi oluşmaktadır. Burada yeni use case farklı renkte gölgelendirilmiştir.

• Bu yaptığımız iyileştirmeleri tekrar gözden geçirince iki problemin daha olduğu ortaya çıkıyor.

Bir use case kısmen iki kez kullanılmış, İki use case’de yeniden düzenlenmelidir.

Birinci problem neydi? Bir use case kısmen iki kez kullanılmıştı. Mortgage Yönetme (Manage a Mortgage) use case’i MSG Vakfı çalışanının mortgage ekleme – silme işlemlerini gerçekleştirmesini ve mortgage portföyünü yönetmesini sağlar.

Bu use case’in eylemlerinden biri mortgage üzerinde değişiklik yapmaktı.

Borçlunun Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) use case’in amacı da borçlunun haftalık gelirini güncellemekti. Borçlunun haftalık gelirini güncelleme, mortgage’ın bir niteliği (attribute) dir. Yani, Borçlunun Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) use case’i, Mortgage Yönetme (Manage a Mortgage) use case’inin bir alt use case’dir.

Mortgage Yönetme (Manage a Mortgage) use case’i zaten Borçlunun Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) use case’ini içerdiği için Borçlunun Haftalık Gelirini Güncelleme (Update Borrowers’ Weekly Income) use case’inin silinmesi gerekir.

Use-Case Diyagramının yeniden düzenlenmesiyle altıncı iterasyon şekil 10.38’de görüldüğü gibi oluşmaktadır. Burada yeni use case farklı renkte gölgelendirilmiştir.

Borrowers’ı Mortgage Yönet (Manage a Mortgage) use case’ine bağladık.

• Bu iterasyon ilerleme ile değil gerileme ile sonuçlandı.

• Silme işlemi bir hata yaptığımız zaman olur.

• Bazı zamanlarda yanlış bileşenleri (artifact) düzeltebiliriz, çoğunlukla silmek zorundayız.

• Buna rağmen, bir hata bulduğumuz zaman sıfırdan başlamak zorunda değiliz.

• İlk önce o anki iterasyonu düzeltmeliyi deneriz.

• Eğer bu hata çok ciddi bir hata ise, öteki iterasyona geri döneriz ve ilerlemek için daha iyi bir yol bulmayı deneriz.

İkinci problem neydi? İki use case’inde yeniden düzenlenmesi gerekiyordu.

• İçinde bulunulan hafta için kullanılabilir birikimler belirleniyordu. Bunun içinde Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’i kullanılıyordu.

Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’i hesaplamaların gerçekleştirilmesini modeller.

Rapor Üretme (Produce a Rapor) use case’inin 1.3.’cü adımı hesaplamaların sonucunun yazdırılmasını modeller.

• Eğer sonuçlar yazdırılmayacaksa kullanılabilir birikimlerin tahmin edilmesinin bir mantığı yoktur.

• Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) ve Rapor Üretme (Produce a Rapor) use case’lerinin tanımları düzenlenmiştir.

Rapor Üretme (Produce a Report) Use Case’i

Kısa Açıklama

Rapor Üretme (Produce a Report) use case’i, MSG Vakfı çalışanına bütün yatırımların veya mortgage kredilerinin listesini yazdırmasında yardımcı olur.

Adım Adım Açıklama

1. Aşağıdaki raporlar üretilebilmelidir:

1.1. Yatırım raporları – isteğe bağlı basılır:

Bilgi sistemi, bütün yatırımların bir listesini yazdırır. Her bir yatırım için aşağıdaki nitelikleri yazdırır:

- Yatırım numarası - Yatırım adı

- Tahmini yıllık getiri

- Tahmini yıllık getirinin en son güncellenmiş olduğu tarih 1.2. Mortgage raporları – isteğe bağlı basılır:

Bilgi sistemi, bütün mortgage’ların bir listesini yazdırır. Her bir mortgage için aşağıdaki nitelikleri yazdırır:

- Hesap numarası

- Mortgage kredisine başvuran kişinin soyadı - Evin gerçek fiyatı

- Mortgage’ın düzenlenmiş olduğu tarih - Anapara ve faiz ödemeleri

- İçinde bulunulan hafta için haftalık brüt gelir

- İçinde bulunulan hafta için haftalık brüt gelirin en son güncellendiği tarih

- Yıllık emlak vergisi

- Yıllık emlak vergisinin en son güncellendiği tarih - Evin yıllık sigorta primi

- Evin yıllık sigorta primi en son güncellendiği tarih

Kısa Açıklama

Haftalık Kullanılabilir Birikimleri Tahmin Etme use case’i, MSG Vakfı çalışanına, MSG Vakfı’nın ipotekli konut finansman kredilerini (mortgates) haftalık ne kadar para finanse edeceğini yani ne kadar para kaynağı ayıracağını tahmin etmesinde yardımcı olur.

Adım Adım Açıklama

1. Haftalık Yatırım Gelirlerini Tahmin Etme (Estimate Investment Income for Week) use case’ini kullanarak yatırımlardan haftalık tahmini geliri belirle.

2. Haftalık İşletme Giderlerini Tahmin Etme (Estimate Operating Expenses for Week) use case’ini kullanarak haftalık işletme giderlerini belirle.

3. Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’ini kullanarak haftalık tahmini toplam mortgage ödemelerini belirle.

4. Haftalık Ödemeleri ve Bağışları Tahmin Etme (Estimate Payments and Grants for Week) use case’ini kullanarak haftalık tahmini toplam bağışları belirle.

5. Adım 1 ve 3’ün sonuçlarını topla ve Adım 2 ve 4’ün sonucundan çıkar. Çıkan sonuç, içinde bulunulan haftada mortgage için kullanılabilir toplam miktardır.

6. İçinde bulunulan hafta esnasında yeni bir mortgage için kullanılabilir toplam birikimi yazdır.

• Bir <<include>> ilişkisinin kullanılmasının genel nedeni bir use case’in iki veya daha fazla use case’in parçası olması durumudur.

• Case Study’de kullanılan bütün use case’ler sadece Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’inin bir parçasıdır.

• Bu üç <<include>> use case’ini Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case’i altında birleştirilmektedir.

• Şuan gereksinimlerin doğru olduğu görülmektedir.

Gereksinimler müşterinin ne istemiş olduğuna göredir.

Gereksinimlerin müşterinin ihtiyaçlarını tatmin ettiği görülmektedir.

Burada başka hatalar görülmemektedir.

• Şimdilik, her şeyin iyi olduğu gözükmektedir.