\u00c7evik Modelleme Scott W. Ambler tarafından Extreme
\nProgramming değerleri g\u00f6z \u00f6n\u00fcne alınarak geliştirilmiş ve i\u00e7ine al\u00e7akg\u00f6n\u00fcll\u00fcğ\u00fcn
\neklenmesi ile son halini almıştır. Extreme Programming değerleri iletişim,
\nbasitlik, geribildirim ve cesaret değerlerinden oluşur.\u00c7evik Modelleme yazılım
\ngeliştirme a\u00e7ısından uyulması gereken kuralları ortaya koyar ve destekler.<\/p>\n
Şimdi bu değerlere bir g\u00f6z atalım:<\/p>\n
İletişim<\/b><\/p>\n
Projede yer alan herkes arasında \u00e7ok iyi bir iletişim olmalıdır. Başarılı
\nyazılım geliştirme’nin birinci gerekliliği budur. İletişim, s\u00f6zl\u00fckte yazdığı
\nkadarı ile kişiler arası belli işaret, hareket veya sembollerle bilgi alışverişi
\nyapılan genel sistemin adıdır. İletişim iki yollu bir sistemdir. Her iki tarafta
\nbilgi sunar ve kazanır. İletişimde aksamalar ortaya \u00e7ıktığında problemler de
\nortaya \u00e7ıkar. \u00d6rneğin, bir yazılım uzmanı kendi yazdığı b\u00f6l\u00fcm\u00fcn hen\u00fcz tam olarak
\nbitmediğini iş arkadaşlarına s\u00f6ylememesi başka bir yazılım uzmanının bu problemi
\nortaya \u00e7ıkartmak i\u00e7in ekstra zaman harcamasına neden olabilir. Yazılımcılar
\nyazacakları sistemin prototipini m\u00fcşteriye sunarlar ama m\u00fcşteri onun prototip
\nolduğundan haberdar değildir ve ger\u00e7ek sistemin hazır olduğunu zanneder.<\/p>\n
Durup d\u00fcş\u00fcnd\u00fcğ\u00fcn\u00fczde modelleme işleminin aslında iletişimi arttırmak ve
\ngeliştirmek i\u00e7in yaptığımızı g\u00f6r\u00fcr\u00fcz. M\u00fcşteriniz, pek \u00e7ok iş kuralından oluşan
\nkarmaşik bir iş yapısını anlatırken sizin mantığı anlatan bir veri akışı şeması
\n\u00e7izmeniz, işlemi anlamınızı kolaylaştıracaktır. Genellikle, konu hakkında beş
\ndakikada cizeceğiniz bir model, o konu hakkında 5 saat okumaktan veya
\ntartışmaktan cok daha fazla sey \u00f6ğretecektir. Modelleme, kendi fikirlerinizin
\ndaha rahat anlaşılmasına, başka kişilerin fikirlerini daha rahat anlamanıza ve
\nen sonunda genel olarak t\u00fcm iş hakkında genel bir kanı oluşmasına neden olur.<\/p>\n
Basitlik<\/b><\/p>\n
Pek \u00e7ok yazılım kitabı basitlikten s\u00f6z eder fakat i\u00e7erisinde ge\u00e7en konulara ve
\nmetodlara baktığınızda, yazılım geliştirme işini zorlaştırdığını g\u00f6r\u00fcrs\u00fcn\u00fcz.
\nGenellikle yapılan yanlışlar şunlardır.<\/p>\n
Karmaşık yapıları erken uygulamak: İhtiya\u00e7 olmadan modellenen karmaşık yapılar,
\nyazılım uzmanlarının fazla mesai yapmalarına neden olur. Karmaşık yapıların
\nyavaş yavaş sindirilerek ve par\u00e7alara b\u00f6l\u00fcnerek modellenmesi ve en gerekli
\nkısmının ilk olarak yazılması gerekir. M\u00fcşterinize vereceğiniz ilk s\u00fcr\u00fcmde,
\nhayati \u00f6nem taşıyan mod\u00fcllerle ve en az hata ile ortaya \u00e7ıkmalısınız.
\nGereklilikler ortaya \u00e7ıktık\u00e7a, m\u00fcşteri de ne istediğini daha net g\u00f6recek,
\nbelkide karmaşik bir mod\u00fcl\u00fc programlamaktan kurtulacaksınız.<\/p>\n
Gelecekte kullanılacak b\u00f6l\u00fcmler i\u00e7in fazladan modelleme\/kodlama yapmak: Şu anda
\n\u00fczerinde calıştıgınız bankacılık sisteminin, hayat sigortalarını
\ndestekleyebilmesi i\u00e7in belkide sadece bir g\u00fcnl\u00fck bir modelleme gerekiyor, Neden
\nyapmayalimki? Evet, bu sistemi modellemek olduk\u00e7a zevkli olacaktır fakat
\nyazılımınızı bug\u00fcn olduğundan daha karmaşik bir yapıya sokmayacak mı?Yada
\nyazılım uzmanlarınız gelecekte olacak değişikliklere cevap verebilmek veya her
\nisteğe cevap verebilecek en iyi yazılımı yapma egosu ile \u00e7ok fazla modelleme ve
\nkodlama yapma eğiliminde olabilirler. M\u00fcşteri isteklerini anlayarak, olabilecek
\nen basit, en verimli, en ucuz \u00e7\u00f6z\u00fcm\u00fc sunmak hedefimiz olmalıdır. Yarının
\nproblemlerini yarın \u00e7\u00f6zmeliyiz. Eger bug\u00fcnden en basit \u00e7\u00f6z\u00fcm \u00fczerinde
\n\u00e7alışırsak, yarın yeni bir fonksiyon eklemeye kalktığımızda elimizdeki sistem
\n\u00e7ok basit olacaktır.<\/p>\n
Karmaşik altyapılar geliştirmek: Proje ekiplerinin yaptiği genel hata ilk
\nasamada gelecekte kullanmak \u00fczere geliştirdikleri mod\u00fcller, sınıf k\u00fct\u00fcphaneleri
\nve iskelet yapılardır. Ama\u00e7 bu par\u00e7alar lazım olduğunda elimizin altında
\nolmasıdır. Fakat bu amacin ciddi zararları vardır. \u00d6ncelikle m\u00fcşterinizin
\nkaynaklarını, onlara elle tutulur bir ilk s\u00fcr\u00fcm vermeden harcamış oluyorsunuz.
\nM\u00fcşteriniz sizden bazı işlerini kolayca yapabileceği bir sistem istiyor fakat
\nsizin ilk verdiğiniz şey hata-yakalama alt yapısı. Projenizi, hızlı ve
\nkullanilabilir bir fonksiyonellik sunmadığınız i\u00e7in riske atıyorsunuz. Ayrıca
\nhata-yakalama gibi alt-sistemleri projenin gidişati i\u00e7erisinde zamanlada
\ngeliştirebilirsiniz. Sadece ihtiyacınız ger\u00e7ekten ortaya \u00e7ıktığında.<\/p>\n
Geribildirim<\/b><\/p>\n
Yaptığınız işin doğru olup olmadığını anlamanın tek yolu farklı kişilerin
\ngeliştirdiğiniz sistem hakkında test yapmaları ve sonu\u00e7ları paylaşmanizdir
\n(geribildirim). Testi yapan kişilerden sonu\u00e7ları doğru zamanda alıp sebeplerini
\nkısa zamanda bulmak \u00e7ok \u00f6nemlidir. Analizler sonucu ortaya \u00e7ıkan modellerinizin
\ndoğru olup olmadığını nasıl anlayacaksınız.<\/p>\n
Modellemeyi takım halinde yapın. Yazılım geliştirme işi y\u00fczme gibi değildir. Tek
\nbaşına yapmak tehlikelidir. Diğer kişilerle beraber \u00e7alıştığınızda sonu\u00e7lara
\ndaha hızlı ulaşır, sebeplerini bulmak i\u00e7in zaman kaybetmemiş olursunuz.<\/p>\n
Modelinizi doğru kişilerle inceleyin. Modellediğiniz işin, o işten anlayan
\nkişilerle birlikte incelenmesi gerekir. En g\u00fczeli modelleme sırasında bu
\nkişilerin işin i\u00e7inde olmasıdır. Gereklilik modelleri son-kullanıcı ile beraber
\nyapılmalı, detaylı dizayn modelleri ise programlamayı yapacak kişiler ile
\nyapılmalıdır.Resmi toplantılar halinde d\u00fczenlenmesi ve proje başında ayda veya
\nhaftada bir yapılmalıdır. Eğer bu m\u00fcmk\u00fcn değilse (organize etmesi zaman
\nalır)gayri resmi hızlı toplantılar ile yapılacak incelemeler modellerinize \u00e7ok
\nşeyler katabilir.<\/p>\n
Modelin uygulanması. Eğer hi\u00e7 bir şekilde bir toplantı ayarlayamıyorsanız,
\nmodelinizi doğrudan koda d\u00f6ker ve ilk s\u00fcr\u00fcmden sonra gelecek sonu\u00e7ları
\nbeklersiniz. \u00d6nemli olan testlerin zamanında yapılabilmesi ve hataların hızlı
\nolarak sebeplerine ulaşabilmektir.<\/p>\n
Kabul testleri. Esas olarak modellerinizin m\u00fcşteri isteklerini yansıtıyor olması
\ngerekir. M\u00fcşteriniz kabul testleri sırasında bu isteklerini değerlendirir ve
\ngeri d\u00f6nen hatalar ile gene modellerinizi test etmiş olursunuz.<\/p>\n
Geribildirim olayında zaman kavramıda \u00e7ok ilgin\u00e7tir. Bir takım halinde
\n\u00e7alıştığınızda, geribildirim saniyeler yada dakikalar i\u00e7inde olabilmektedir.
\nGayriresmi toplantılarda ise geribildirim dakikalar yada saatler alabilmektedir.
\nResmi toplantı geribildirimleri toplantı sırasında gelsede zaten organize etmesi
\nhaftalar, aylar alabilmektedir. Uygulamayı yapıp ilk s\u00fcr\u00fcm\u00fc verdiğinizde
\ngeribildirim saatler yada g\u00fcnler i\u00e7inde olur. Kabul testlerinden sonra
\ngeribildirim bir ka\u00e7 hafta yada ay i\u00e7erisinde gelir.<\/p>\n
Zaman ne i\u00e7in \u00f6nemlidir? \u00c7\u00fcnk\u00fc kısa zamanda gelen geribildirim, sizin
\nmodellerinizden sapma olasılığınızı d\u00fcş\u00fcr\u00fcr. Takım halinde \u00e7alışmanın en b\u00fcy\u00fck
\nyararı geribildirimlerin hızlı olmasıdır. Yada kağıt \u00fczerinde m\u00fckemmel g\u00f6r\u00fcnen
\nmodelin kodlanması ve ilk s\u00fcr\u00fcmden sonra gelecek geribildirimlerin işlenmesi de
\nmetod olarak d\u00fcş\u00fcn\u00fclebilir.<\/p>\n
Cesaret<\/b><\/p>\n
Arkanıza rahat\u00e7a yaslanıp genel durumu kabul etmek ve bir şeyleri geliştirmeyi,
\nd\u00fczeltmeyi denememek yada birisinin \u00e7ıka gelip hataları d\u00fczeltmesini beklemek
\n\u00e7ok kolay bir işdir. BT end\u00fcstrisinin bug\u00fcnk\u00fc aksayan taraflarında
\ncesaretsizliğin b\u00fcy\u00fck payı vardır. \u00c7evik Metodolojisi size diğer insanlarla
\nberaber \u00e7alışmanızı, onlara g\u00fcvenmenizi ve kendinize g\u00fcvenmenizi \u00f6ğ\u00fctler. Bu
\ncesareti arttırır. XP veya \u00c7evik Modelleme, yapabileceğiniz en basit modeli
\nyapmanızı s\u00f6yler, \u00e7\u00fcnk\u00fc yarının problemlerini yarın \u00e7\u00f6zmek gerekmektedir. \u00c7evik
\nModelleme, ger\u00e7ekten d\u00f6k\u00fcmantasyona ihtiyacınız olduğunda d\u00f6k\u00fcman yaratın der.
\nBeyaz tahta yada not defteri gibi en basit ara\u00e7ları kullanarak modelleme
\nyapmanızı \u00f6ğ\u00fctler. Karmaşık yazılım ara\u00e7larını ancak olabilecek en y\u00fcksek yararı
\nelde edebileceğiniz zaman kullanmanızı \u00f6ğ\u00fctler. Modelerimizin daha iyi
\ng\u00f6r\u00fcnmeleri i\u00e7in zaman harcamamızı \u00f6ğ\u00fctler. Birlikte \u00e7alıştığınız kişilere
\ng\u00fcvenmenizi, yazılım uzmanlarınında dizayn aşamalarında karar verebileceğini
\ns\u00f6yler. T\u00fcm bu s\u00f6ylediklerimizin hepsi cesareti arttırır. Cesaretli ekipler,
\ndenemekten ve yanılmaktan korkmaz. Sonu\u00e7lara daha hızlı ulaşılır ve kat edilen
\nyol daha uzun olur.<\/p>\n
D\u00fcş\u00fcn\u00fcn, firmanızda Modul Tabanlı Analiz ve Geliştirme kurallarını uygulamak
\nistiyorsunuz fakat endişeleriniz var. Se\u00e7im i\u00e7in cesaret gerekir. Her işin her
\nsekt\u00f6r\u00fcn belirli riskleri vardır fakat risklerden ka\u00e7mak olsa olsa daha b\u00fcy\u00fck
\nrisklere yakalanmanıza neden olur (yağmurdan ka\u00e7arken doluya tutulma kuralı).
\nCesaretli olmak sizinde hata yapabileceğinizi anlamanıza yardımcı olur.
\nDenemekten, yanılmaktan ve deneyim kazanmaktan korkmayın.<\/p>\n
Al\u00e7ak G\u00f6n\u00fcll\u00fcl\u00fck<\/b><\/p>\n
En iyi yazılım uzmanı her şeyi bilmediğini kabul edecek kadar al\u00e7ak g\u00f6n\u00fcll\u00fc
\nolandır. Gelmiş ge\u00e7miş en iyi Java yazılımcısı olabilirsiniz fakat her bir Java
\nAPI’sinin detaylarını tek tek bilmiyor olabilirsiniz. \u00c7ok iyi Java bilmeniz, \u00e7ok
\niyi aray\u00fcz tasarımlama yada m\u00fckemmel veritabanı tasarımcısı yada en iyi m\u00fczisyen
\nolduğunuz anlamına gelmez. Sadece \u00e7ok iyi Java bildiğiniz anlamına gelir. \u00c7ok
\niyi Java bilmeniz, yeni başlayan \u00e7ıraklardan hi\u00e7 bir şey \u00f6ğrenemezsiniz anlamına
\nda gelmez.<\/p>\n
\u00c7evik Modelleme ve programlama yapan kişi proje ekibindeki herkesin bir uzmanlık
\nalanı olduğunu bilir ve ancak diğer kişilerin yardımı ile kendi işlerinin
\nbaşarılı bir bi\u00e7imde biteceğini g\u00f6r\u00fcr.Al\u00e7akg\u00f6n\u00fcll\u00fcl\u00fck, diğer kişiler ile
\nbirlikte \u00e7alışmayı imkan dahilinde kılar. \u00c7evik Modelleme yapan kişi diğer proje
\nelemanlarının farklı deneyimlerinin olduğunu, kişisel pek \u00e7ok farklılıklar
\nolduğunu bilir ve saygı ile hareket eder. Patronları "y\u00fcksekte oturan kargalar",
\nson kullanıcıları "aptal kullanıcı", diğer departmanları "kafayı yemiş" olarak
\ndeğerlendirmek iletişim problemlerine yol a\u00e7ar, iletişimsizlik projenizi sekteye
\nuğratabilir. Zaman ve kaynak kaybından başka bir şey olmadığı sizde
\ng\u00f6r\u00fcyorsunuz.<\/p>\n
Bu yazının amacı<\/b><\/p>\n
Burada anlatılan modelleme k\u00fclt\u00fcr\u00fc CBD, UML ve eXtreme Programming ile analiz ve
\nmodelleme yapan projeler tarafından benimsenmeye başlamıştır. \u00c7ok yeni olması
\nnedeni ile tamamen geliştirmeye ve deiştirmeye a\u00e7ık bir konudur.<\/p>\n
Bu yazıyı Scott W. Ambler’in Agile Modelling (ISBN 0-471-20282-7) isimli
\nkitabından, sizin bu konuları duymanızı sağlamak ve hafızalarınızda birer ışık
\nyakmak ama\u00e7lı olarak \u00e7evirdim.<\/p>\n
Bir ka\u00e7 yararlı link:<\/p>\n