Çarşamba, Mart 22, 2006

Soyutlamalar ve Ogrenme Tembelligi

Programlama yaparken -hatta tüm mühendislik problemlerini çözerken- en önemli becerilerden biri zannediyorum soyutlama becerisi. Yani bir işin detaylarını soyutlayarak, daha üst seviyeden o işi yapabilmeyi sağlamak. Java gibi dillerden, Struts, JSF gibi kütüphanelere veya design patternlardan aspect oriented programminge kadar yöntemler hep daha ileri seviyede soyutlama yapmayı sağlıyor. Hatta kimin söylediğini hatırlayamıyorum, meşhur bir yazılım mühendisi akademisyen -belki Donald Knuth olabilir- şöyle diyordu: "Programlamadaki her problem bir indirection (dolaylandırma) yoluyla çözülebilir."

Soyutlama sadece programlamayı da aşan genel bir mühendislik çözüm yöntemi. Matematikteki faydalı tüm teoremler bir soyutlama ile altta yatan şeylerin detaylarından kullanıcısını kurtarır. Diğer mühendisliklerde de soyutlama ilerlemenin temel aracı. Mesela motor kavramı, altta yatan silindir gibi mekanizmalardan tasarımcısını soyutlar.

Ancak soyutlamanın bu kadar faydalı bir araç olması, ciddi bir soruna da sebep oluyor: Ezbercilik veya düşünce tembelliği. Nasıl bir matematik teoreminin mantığını anlamadan, formülü ezberlemek bazı problemleri çözmekte yeterli olabiliyorsa, programlamadaki soyutlamaları da anlamadan iyi programlar yazmak mümkün, ama bir yere kadar.

Soyutlamaların mantığını anlamamanın, iyi programcılıkla, çok iyi programcılığı ayıran bir şey olduğunu düşünüyorum. Matematikte de böyleydi. Kimisi formülleri ezberler ve sınavı geçer. Ama yepyeni bir problem geldiğinde veya çok sayıda konu içeren bir sınavla karşılaştığında veya hiç bilmediği bir alanda kimse ona yol göstermeden problemlerle karşılaştığında formülleri ezberlemiş olmak bir fayda sağlamaz.

Yazının Devamı...

Salı, Mart 21, 2006

Yenilik Uretme Yaklasimi Nasil Olmali?

Bir yerde şunu okumuştum: Sahip olduğunuz beceriler/teknolojilerden çıkarak yeni ürün fikri üretmemelisiniz. Bunun yerine ihtiyaçtan yola çıkarak yeni fikirler üretmelisiniz.

Evet, bu ikisi büsbütün farklı yaklaşımlar. Ancak tek başına ihtiyaçtan yola çıkmak da yeterli değil. Çünkü elimizdeki potansiyel kaynaklarla neler yapabileceğimizi, hangi ihtiyacı karşılayabileceğimizi bilmediğimiz sürece yenilik üretemeyiz.

Ancak yine de öneri doğru. Çünkü doğrudan ihtiyaçlardan değil de beceri/teknolojilerden yeni ürün fikirleri geliştirilirse, o zaman pazarın ihtiyaç duymadığı şeyleri yapma ihtimalimiz çok yüksek olur.

Öyleyse, yeni ürün fikirleri ihtiyaçtan yola çıkmalı, ancak geniş bir teknoloji/beceri bilgisine sahip olmak ön koşul olmalı.

Yazının Devamı...

Pazartesi, Mart 20, 2006

Program Yazma Keyfi

Programcılık neden bilmiyorum bana çok büyük bir keyif veriyor. Bir problemi ele almak. Onu anlamaya çalışmak. Çözümler tasarlamak. Buna yönelik bir ilerleme planı oluşturmak. İlk adımı tasarlamak ve bunu uygulamak. Biraz ilerlemek. Sonra plana geri dönüp kaldığım yerden devam etmek... Bunlar bana büyük keyif veriyor. Gerçi her zaman böyle olmuyor. Belki çoğu zaman problemlerde tıkanıyorum. Ama sonra sabırla uğraşmaya devam etmek ve bir şekilde tıkanıklıkları aşmanın verdiği sevinç bir başka oluyor.

Bazen bir arkadaşıma bildiğim şeyleri anlatmaktan da çok keyif alıyorum. Ona anlatırken kafamda problemler ve çözümler daha güzel oturuyor. Sonra bana karşılaştığı problemler için danışmaya geliyor. Genelde o aşamalardan daha önce geçtiğim için, çoğunu bir şekilde yanıtlayamıyorum. Ama her zaman da böyle olmuyor.

Üniversitede endüstri mühendisliği okudum. Onu da seviyorum, ama programlama yapmak bana daha çok keyif veriyor. Çünkü üniversitede gördüğümüz derslerde bu kadar çok mühendislik problemiyle karşılaşmıyorduk. Daha büyük çaplı ancak daha az sayıda problem oluyordu. Fazla formül ağırlıklı çalışıyorduk ve mantığını bilmesek de formülleri uygulamakla problemleri çözebiliyorduk. O zaman da problemlerle uğraşmanın keyifini yaşayamıyorduk. Gerçi her zaman da böyle değildi. Bazı zamanlar çok keyif veren problemlerle de uğraşıyorduk... Son sene aldığım vaka çalışması (case study) içeren dersler böyleydi. Bir de tabi favori dersim: Sistem Dinamikleri dersi vardı.

Şimdi endüstri mühendisliğini tekrar okusaydım, öğrendiğim tüm modellerin mantığını daha iyi anlamak için özel gayret sarf ederdim. Neden bunu okurken yapmadım, acaba? Galiba insan okurken, derslere düşman olmaya kendi kendini programlıyor. Bir şey ancak ders dışı olursa, onu severek yapma isteği oluşuyor :)

Yazının Devamı...

Cuma, Mart 17, 2006

Dubai Resimleri

Marinadan bir resim. Burası dünyanın en büyük insan yapımı marinasıymış. Resimde marinanın sadece çok küçük bir kısmı görünüyor. Posted by Picasa

Yazının Devamı...

Salı, Mart 14, 2006

Yazilim Bakim Maliyeti

java.net sitesinde güzel bir yazı çıktı: "The economics of quality" Yazıda, bir yazılımın bakım sürecindeki hataların maliyetlerinin nasıl tahmin edileceği ve maliyet iyileştirmesi için nereye odaklanılması gerektiği gösteriliyor. Buna göre bakım sürecindeki hataların maliyetleri dört faktöre bağlı: Kalite, yazılımın büyüklüğü, hata başına maliyet, müşterinin bulduğu hataların oranı.

Bu dört faktörden, son ikisi kontrol edilmesi ve hatta tam olarak ölçülmesi oldukça güç. İlk iki faktör ise, yazılım geliştirmecilerin kontrolü altında.

Burada kaliteden kasıt, satır başına hata sayısı. KLOC (bin satır kod) başına kaç hata bulunuyorsa, o değer alınıyor. Yani 1000 satırdaki hata sayısı, 50 ise, Q (kalite) 0.05 ediyor.

En önemli maliyet faktörünü de kalite faktörü oluşturuyor. Malcolm Davis, yazının yazarının gözlemlerine göre kurumsal IT departmanlarında Q ortalama 0.1 civarında. Bu oranı sadece 0.05'e düşürmek bile, maliyetlerde yarı yarıya tasarruf anlamına geliyor. Benzer şekilde kurumsal IT yazılımlarında, kopyala/yapıştır türü alışkanlıkların yaygın olmasından dolayı, yazılımlar gereğinden fazla büyük. Bu tip kod fazlalıklarını temizlemekle de ciddi bir maliyet tasarrufu yapılabiliyor.

Bu yazının bana önemli gelen tarafı şu oldu: Genellikle kalitenin veya sadeliğin (kısalığın) iyi bir şey olduğunu biliriz. Ancak bunun sayısal etkisinin ne olduğunu göstermesi açısından bu yazı son derece yararlı. Malcolm Davis yazısında kullandığı rakamları 10 yılı aşan çok sayıda projede yaptığı ölçümlerle destekliyor. Ve bu yolla hesapladığı maliyet tahminleri, firmalarda çalışan bakım yazılımcılarının yıllık masraflarına yaklaşık eşit çıkıyor.

Yazının Devamı...

Pazartesi, Mart 06, 2006

Dubai

Geçen hafta Pazar günü Dubai'ye geldim. Oytek'teki işimden Cuma günü ayrıldım. Hemen iki gün içinde, hazırlanıp, Dubai'de yeni bir işe başladım. Aslında ilk günden itibaren bloglamayı düşünüyordum, ancak fırsat bulamadım.

Uçak yolculuğundan başlayayım şimdi :) Açıkçası uçağa daha önce de binmiştim, ama bu sefer nedense daha heyecanlı oldu yolculuk. Uçak kalkarken, çok tuhaf hissettim, bu kadar büyük bir şeyin uçabilmesinden dolayı. Sonra gökyüzüne biraz çıktıkça, aslında bu uçağın hiç de büyük olmadığını düşündüm. Sonra dünyayı düşündüm. Dünya da bir uçak gibi, koca evrende çok daha süratli bir şekilde uçuyor.

Dubai'ye oldukça geç bir saatte geldim. Hava limanı, gerçekten çok büyük. Burada o kadar çok görkemli yapı var ki, bir süre sonra küçük binaların ne demek olduğunu insan unutuyor. Yaklaşık herhalde 15 dakika yürüdük ve belli bir yolu da terminal içinde elektrikli bir arabayla geçerek bagajları alacağımız yere vardık.

Otele gidişim, yaklaşık 20 dakika kadar sürdü. Çok geniş ve temiz yolları var. Herhangi bir çukura rastlanmıyor, bu bizim için alışılmadık bir şey. Bütün yol kenarları, çiçeklerle ve palmiye ağaçlarıyla süslenmiş. Şeyh Zaid adlı bir yoldan otele geldik. Bu yol, İstanbul'un E-5'i gibi en popüler yol. Yalnızca otoyol gibi kullanılmıyor. Sanki aynı zamanda bir cadde. Pek çok işyeri ve önemli siteler, bu yolun etrafına dizilmiş. Aslında bu kadar gürültülü bir yolun yanında oturmak çok sağlıklı olmaz, ama ekonomik açıdan herhalde prim yaptığından insanlar buralara yatırım yapıyor.

Kaldığım otel, buradaki diğer pek çok otel ve işyeri gibi bir gökdelen. 42 katlı. Burada çok yüksek bir gökdelen talebi var gördüğüm kadarıyla. Benim kaldığım semt Marina. Dünyanın en büyük insan yapımı marinasıymış. Burada dünya rekoru inşaat rekorları kırmaya yönelik arzu çok fazla. En yüksek bina, en büyük yapay ada vs.

Bana bütün bunlar çok anlamsız ve uzun vadede ekonomik açıdan zararlı görünüyor. Ama bu işten, insanlar büyük paralar kazanıyor. Dubai'yi cazibe merkezi haline getirmek için bu tip projeler teşvik ediliyor. Zaten projelerin pek çoğunu devlet veya Şeyh Muhammed kendisi yapıyor. Sanırım burada devlet ve şeyh aynı anlama geliyor. Aynı zamanda burada şeyhlik, dini bir anlama sahip değil. Gördüğüm kadarıyla prens anlamında kullanılıyor.

Dubai'yle ilgili garip bir nokta şu, bu zenginlik petrolden kaynaklanmıyor. Dubai'nin yıllık GSMH'sinin sadece %6'sı petrole dayanıyor. Bazıları petrolün bittiğini söylüyor, bazıları gelecek için sakladıklarını söylüyor.

Dubai'deki en büyük gelir kaynağı ticaret. Dünyanın en büyük limanına sahiplermiş: Cebel Ali (Jebel Ali) limanı. Henüz gidemedim, benim kaldığım yere yaklaşık 15 km mesafede.

Burada yönümü ilkin şaşırdım. Basra Körfezi kıyısında olmasından dolayı, denizin doğu yönünde kaldığını düşünüyordum. Halbuki, Dubai'den denize bakınca, Batıya dönmüş oluyorsunuz. Çünkü burası Arabistan yarımadasının Kuzeye doğru kıvrıldığı yerde.

Dubai çok modern ve gelişmiş bir yer. Çok sayıda yabancı var. Öyle ki, İngilizceyi her yerde konuşabiliyorsunuz. Arapçadan daha yaygın. Bütün tabelalarda mutlaka İngilizce kısmı bulunuyor. İnsanların çoğunluğu Hint, Paki. Araplar yaklaşık %15 civarındaymış. Ancak çok sayıda Lübnan, Suriye gibi ülkelerden gelen Arap da yaşıyor. Nüfus az. Dubai 1.5 milyon kadarmış. Ancak nüfus artışı çok yüksek. Büyük oranda göçlerden kaynaklanıyor, artış. Ancak henüz yabancılara vatandaşlık vermediklerinden, gelenler 3-5 sene içinde ülkelerine geri dönüyor.

Ülke tam anlamıyla küreselleşme ekonomisine dayanıyor. İş gücü büyük oranda Hindistan ve Pakistan'dan tedarik ediliyor. Uzmanlık ve yöneticilik işlerinde, Avrupalılar çok yaygın. Genellikle çok uluslu firmaların, Orta Doğu ve Afrika merkezleri Dubai'de. Ayrıca reexport amaçlı çok şirket de var. Şimdi giderek, servis ve turizme dayalı bir ekonomi haline gelmeye çalışıyor.

Araplar, son derece cana yakın ve iyi insanlar. İlişki kurmak ve sohbet etmek çok kolay. Ancak şu ana değin, yerli Araplardan ziyade Suriye, Lübnan tarafından Araplarla tanışabildim. Yerli Araplar, biraz daha uzak. Genelde çok zenginler. Üst yönetici veya yatırımcı konumlarında olduklarından, çok fazla bağlantı kuramadım henüz.

Şehrin altyapısı her yerde çok iyi. Tertemiz ve bakımlı bir şehir. Ancak şehrin arka sokaklarında, oldukça zor şartlarda yaşadıklarını tahmin ettiğim Hintliler de var. Evlerin eşiklerinden görünen kısımları pek iyi sayılmaz, ama belki içerileri iyidir. Duyduğum kadarıyla, bazı yabancıları çok düşük fiyatlarla çalıştırıyorlarmış. Zaten pahalı da bir şehir olduğundan, bir arkadaşımın şirketinde çalışan Hintliler 30 kişi bir evde kalıyormuş.

Çok fazla alışveriş merkezi ve lüks mağaza var. Bunlar da genellikle son birkaç yıl içinde inşa edilmiş. Ancak hala daha pek çoğu da inşa halinde. Tuhaf ve henüz anlayamadığım bir ekonomi var burada. Yerli iş gücünün bu kadar kıt olduğu halde, petrole de dayanmadan bu kadar gelişmiş ve iş yapan bir ekonomi olması çok ilginç. Kafamda, bu sistemin ne kadar sürdürülebilir olduğu sorusu sürekli duruyor. Hindistan ve Pakistan gibi çok yüksek nüfusa sahip ve iyi eğitimli çok büyük bir iş gücü arzı olmasa herhalde bu ekonomi oluşamazdı.

11 Eylül'den sonra Arapların Amerika ve İngiltere'deki sermayelerini çekmesinden dolayı, son birkaç yılda aşırı miktarda yatırım yapılmış Dubai'ye. Gayrimenkul fiyatları fırlamış. Taksi ücretleri 4 misline çıkmış. Bu kadar yeni gökdelen ve alışveriş merkezleri yapıldığı halde, hala şehrin bazı semtlerinde inşaat vinçlerinden geçilmiyor.

Dün yanlışlıkla ve mecbur kaldığımdan bir Hint lokantasına gittim ilk defa. Kimseye tavsiye etmem. Çok garip baharatlar kullanıyorlar yemeklerde. Mesela tavuk yerken, ağzınıza hiç anlamadığınız ve bir şeye benzetemediğiniz çok keskin bir baharat tadı gelebiliyor.

Çok geç saatlere kadar (akşam 9) burada çalışıyoruz. Bu yüzden, çok fazla vaktim olmuyor. Buranın alışkanlığı değil. Ancak benim çalıştığım firma danışmanlık firması olduğu için, onlardan kaynaklanan bir kültür.

Buranın sevdiğim bir yanı kendimi Peygamber Efendimizin (ASM) memlekindeymişim gibi hissettirmesi. Bazen sıkılınca, bunu düşünüyorum. Her ne kadar bayağı bir mesafe de olsa Medine'ye, yine de bu güzel bir duygu.

Tekrar görüşmek üzere. Gelecek yazım için buraya ait bazı resimler çekmeye çalışacağım...

Yazının Devamı...

Pazar, Şubat 12, 2006

copy-log

copy-log is a weblog about ajax applications. It reviews regularly new ajax sites. It has nice content.

Yazının Devamı...

Bedava Dosya Gonderme ve Saklama

Çok büyük dosyaları emaille arkadaşlarınıza göndermekte güçlük yaşıyorsanız, yousendit.com gibi bir web sitesini kullanabilirsiniz. Bu site, büyük dosyaları yüklemenize ve istediğiniz zaman (7 gün içinde) indirmenize izin veriyor. Dosyayı yükledikten sonra, size dosyayı indirmek için kullanacağınız linki sunuyor. Bu link başka hiçbir yerde yayınlanmadığından, sizin haber verdiklerinizin dışında kimse bu linkten ve dolayısıyla dosyadan haberdar olamıyor.

Ayrıca bir blog yazarıysanız, resim, flash gibi büyük dosyaları image hosting sitelerine yükleyebilirsiniz. Böylece blog sağlayıcınızın sağladığı disk ve bant kapasitesini tüketmeden, dosyalarınızı ziyaretçilerinize sunabilirsiniz.

http://www.ghacks.net/2005/12/09/free-file-host-list-december-2005/ sayfasında, resim ve dosya yüklemek için kullanılabilecek sitelerin özelliklerini gösteren geniş bir liste var.

Yazının Devamı...

Cuma, Şubat 10, 2006

Hafta Sonu Izni

Az önce çok anlamsız bir şey duydum. Devlet memurları, hafta sonları dahil olmak üzere tatil zamanlarında şehir dışına çıkarken, müdürlerinden izin almaları gerekiyormuş. Bu doğru mu, bilen var mı?

Yazının Devamı...

En Iyi Yazilim Firmalari

En beğendiğim yazılım firmaları şunlar:

  1. Google - Herkesin favorisi. Arama motorlarında yaptığı devrimi diğer alanlarda da (gmail, google maps vs.) devam ettirdi.
  2. JetBrains - Küçük bir Çek firması olmasına rağmen, IBM, Sun, Oracle, Borland gibi büyük firmaların top koşturduğu Java IDE pazarında ciddi bir pazar payı elde etti. NetBeans ve Eclipse gibi bedava IDE'lerle rekabet ediyor ve tüm Java IDE'lerine teknoloji konusunda öncülük ediyor. Refactoring desteğini ilk defa geniş ölçüde sağlayan IDE.
  3. Opera - Küçücük (4 MB) bir yazılımda, çok sayıda özelliği sığdırdı. En çok özelliğe sahip browser olmasına rağmen, çok kullanışlı ve basit bir uygulama.
  4. Thoughtworks - Çok sayıda popüler open-source kütüphaneyi geliştiren yazılımcıların bulunduğu firma. Martin Fowler gibi yazılım mühendisliğinin pek çok duayeni bu firmada.

Yazının Devamı...

Çarşamba, Şubat 08, 2006

Çin Resimleri

Çin'den tabiat, su, pirinç tarlaları ve gökyüzü resimleri. Çok güzeller :)

http://www.impactlab.com/modules.php?name=News&file=article&sid=7301

Yazının Devamı...

Cumartesi, Ocak 28, 2006

Zorbalikla (Bullying) Ilgili Tim Fieldin Sozleri

Bu yazıda, Tim Field'ın zorbalıkla (bullying) ilgili sözlerinden bir kısmını çevireceğim. (Not: Daha önceki yazılarımda yaptığım gibi, burada da zorbalığı, psikolojik şiddet, yıldırma anlamında kullanıyorum. Bunlar İngilizcedeki bullying veya mobbing terimlerinin karşılığıdır.)


"Bütün organizasyonlarda seri bir zorba vardır. Bir kişinin bölücü ve yararsız davranışının bütün organizasyona bir kanser gibi yayılması beni her zaman şaşırtmıştır."

Tim Field, seri zorba tabirini, zorbalığı bir alışkanlık haline getiren insanlar için kullanıyor. Zorbalık da sigara, alkol ve diğer zararlı maddeler gibi bağımlılık yapan bir şey. Bir kere, bir kişi kendi yetersizliklerini zorbalık yaparak gizlemeye başladı mı, bu o kişide zaman içinde bir bağımlılık haline geliyor.

Niçin böyle oluyor acaba? Niçin psikolojik şiddet bir bağımlılık oluşturuyor? Biraz daha genelleştirerek düşünelim, niçin herhangi bir şey bağımlılığa sebep oluyor? O kadar çok şey bağımlılık haline gelebiliyor ki... Yalnızca, alkol, sigara veya uyuşturucu değil bağımlılık yaratan malzemeler.

Belki kolay yoldan insanların sıkıntılarını hafifletmesi, onlara zevk vermesi, onların kendilerini daha değerli hissetmelerini sağlaması gibi menfaatler sunması bağımlılık yapan şeylerin ortak özelliğidir. Seri zorbalar, zorbalığın bağımlısı olmuştur. Psikolojide bu tip davranışlara, kompulzif obsesif (compulsive obsessive) davranış deniyor. Türkçeye düzgün çevirememiş olabilirim, anlamı, zorunlu saplantı davranışları gibi ifade edilebilir.

Tim Field'ın zorbalıkla ilgili sözlerine devam ediyorum:

"Bir tecavüz mağdurunun, tek başına suçluyu teşhis etmesi, izini bulması, takip etmesi, bulması, yakalaması, dava açması, mahkum etmesi ve cezalandırması beklenemez. Zorbalığın hedefleri bütün bunları kendi başlarına yaparlarken, otoriteyi temsil eden kişiler sürekli olarak sorumluluktan kaçınırlar."

"Seri zorbalar, benim tahminime göre toplumun 1/30'unu oluştururlar ve toplumun refahı, organizasyonların etkililiği, işletmelerin karlılığına yönelik en önemli tehdit

Yazının Devamı...

Cuma, Ocak 27, 2006

Psikolojik Yıldırmanin Sağlığa Etkileri

Bullyonline sitesinden yaptığım özet çevirilere devam edeceğim. Psikolojik yıldırmanın sağlığa etkileriyle ilgili oldukça detaylı ve kapsamlı bir makale bullyonline sitesinde yayınlanmış.

Tim Field, bullyonline sitesinin kurucusu (maalesef birkaç hafta önce kanserden vefat etti), zorbalığı (bullying veya mobbing) iş yerindeki stresin en önemli, ancak en az tanınan sebebi olarak görüyor. Stres, genellikle çalışanların fazla iş yükünün altından kalkamamasından değil, yetersiz ve zorbalık uygulayan yöneticilerin anlamsız taleplerinden kyanaklanıyor.

Stres iki tipe ayrılır: pozitif ve negatif. Pozitif stres, yeterli ve olgun bir liderliğin sonucunda, herkesin birbirine değer verdiği ve desteklediği bir ortamda oluşur. İnsanlar birbirleriyle tatlı bir rekabet içindedir ve birbirlerini örnek alarak, daha yüksek bir performans gösterirler. Negatif stres, zorbalık ikliminin bir sonucudur. Bu ortamda, tehdit, zor kullanma ve korku, var olmayan yönetim becerilerinin yerini alır. Çalışanlar, yetersiz yönetimi telafi edebilmek için iki misli daha çok çalışmanın karşılığında, normalin yarısı oranda çıktı üretebilirler. Negatif stres, kişinin hayat kalitesini düşürür ve sağlığına zarar verir.

Stres, vücudun bağışıklık (immune) sistemini zayıflatır.

Semptomlar

  • Ana semptomlar: stres, korku, uykusuzluk, bitkinlik, travma
  • Fiziksel semptomlar: hastalıklara karşı düşük bağışıklığın sonucunda sık yaşanan soğuk algınlıkları, nezle, ateş vs. (özellikle tatil günlerinde), ağrılar ve acılar (açık bir sebebi olmayan), sırt ağrısı, göğüs ağrıları, yüksek kan basıncı, baş ağrısı ve migren, terleme, titreme, hormonal problemler, fiziksel hissizlik (özellikle parmaklar ve dudaklarda), duygusal hissizlik (zevk ve sevgi hislerinin kaybolması), IBS, paruresis, iştah kaybı, yataktan daha yorgun uyanmak vs.
  • Psikolojik semptomlar: panik atak, reaktif depresyon (uyum bozukluğu), intihar düşüncesi, stres boşalması, unutkanlık, hafızanın etkisizleşmesi, düşük konsantrasyon, flashback (geçmişteki olayları yeniden hissetme), aşırı suç, kuşku, karışıklık ve kaybolma duyguları, çok yüksek seviyede korku, izolasyon hissi, güvensizlik, umutsuzluk vb; zorbanın bulunduğu ortamı ziyaret etmenin verdiği endişe, zorbayla yüzleşmekten rahatsız olma ve gerginleşme
  • Davranışsal semptomlar: gözyaşlarının dolması, alınganlık, öfke patlamaları, saplantı (tecrübe giderek hayatınızı ele geçirir), aşırı kuşku, aşırı duyarlılık, somurtkanlık (ruhsal zarar görmenin bir işareti), ruhsal durumun gidip gelmesi, vazgeçme, kararsızlık, mizah yoksunluğu, aşırı dikkat (zaman, yer ile ilgili), tikler, uyuşturucu malzemelerin artan kullanımı (sigara, kahve, alkol, uyku ilacı, antidepresanlar gibi), zevk için harcamalar, fobiler vs.
  • Kişilik üzerindeki etkileri: özgüvenin sarsılması, zayıf benlik algısı, kişinin kendine verdiği değerin ve duyduğu sevginin kaybolması
Bunların dışında, araştırmalara göre, stres, diyabet, astım, alerji, kronik fatigue sendromu ve bazı kanser formlarına da sebep oluyor. Biologist dergisindeki bir makaleye (T cells divide and rule in Gulf War syndrome (and asthma, TB, cancer, ME), Jenny Bryan, Immunology section in The Biologist, (1997) 44 (5)) göre bağışıklık sistemindeki zayıflama pek çok bozuklukla ilişkilidir.

Zorbalığın sonucunda hedef kişinin yaşadığı travmatik etki, pek çok zaman hedef kişilerin niçin kendilerine yapılanları ve kimin sorumlu olduğunu açıkça ifade edemediklerini de açıklar. Hedef kişi yüksek travmanın etkisiyle, olaydan sonra bir yıldan uzun süre yaşadıklarını ifade edemeyebilir.

Önemli bir sorun da, pek çok sağlık personelinin bu tür psikiyatrik zararları teşhis edememesinden kaynaklanır. Yanlış teşhisin sonucunda, hedef kişiyle ilgili şizofreni, paranoya, iş korkusu, okul korkusu, kişilik bozukluğu tanısı konulabilir.

Zorbalığın sonucunda hedef kişide, güçlü korku, utanma, şaşkınlık ve suç duyguları oluşabilir. Bu hisler, zorbalar tarafından, hedef kişinin sessiz tutulması için kullanılır. Bütün tacizciler (çocuk tacizcileri dahil) hedeflerini bu şekilde sustururlar. Bullyonline sitesinde taciz hedeflerinin niçin tacizi bildiremediklerini açıklayan bir makale daha bulunuyor.

İş arkadaşları, pek çok zaman, hedef kişiye olan desteklerini bırakır ve zorbalığa katılır. Bu psikiyatrik zararın seviyesini ve stresi artırır.

Yazının Devamı...

Çarşamba, Ocak 25, 2006

Mobbinge Karşı Savunma

Mobbinge karşı savunma yapmaya yönelik sözleri bullyonline sitesinden özetleyerek yazmaya çalışacağım.

Zorbaya (bully veya mobbing yapan kişi) karşı en etkili sözlerden biri, taciz edici davranıştan sonra, sert bir şekilde "Orada durun. Çizgiyi geçtiniz ve benimle ne siz ne de bir başkası bu şekilde konuşabilir." demektir.

Zorbalar aşırı kincidirler ve hasetlerini yıllarca sürdürebilirler. Bunlara yönelik Amerika veya Kuzey Avrupa ülkeleri gibi gelişmiş ülkelerde, hukuki yollardan hak aramak mümkün olurdu. Bu durumda, kendilerini hukuki mücadeleyle tehdit etmek, muhtemelen zarar verici davranışlarını engellemek için yararlı olurdu. Ama ne yazık ki, bizim hukuk sistemimizin bu seviyeye ulaşması için, bir süre daha beklememiz gerekiyor.

Sitedeki en önemli tavsiyelerden biri, zorbaya karşı mücadele ederken, gündelik hayatınızda sürdürdüğünüzden farklı bir nezaket (etiquette) izlemek gerektiği. Haklılığınızı savunmak için uygulayacağınız nezaket kuralları, sosyal hayatınızda uyguladığınız nezaket olmamalı. Bunun yerine hukuki bir nezaket (legal etiquette) izlemelisiniz. Yani duygularınıza girmeden, karşı tarafa empati duymadan savunma yapmalısınız.

Zorba kişiyi davranışlarından dolayı sorumlu tuttuğunuzda, size karşı bir dizi karşı iddiada bulunacaktır. Bu durumda şu tipte sözler söylemek faydalı:

"Bu dayanaksız suçlamaların anlamsız doğası, davranışlarından sorumlu tutulduktan sonra sorumluluktan kaçınmak için misillemede bulunan zorbaların tipik bir özelliğidir."

"Bu zorbaların, sorumluluktan kaçınmak için uyguladıkları bir dezenformasyon tipidir."

"Bu dayanaksız suçlama yanlış ve dolayısıyla kötü niyetli ve kincidir. Yanlış ve kötü niyetli dayanaksız suçlamalarda bulunmak ciddi bir disiplin kusurudur."

Bilimsel olarak, kişilik bozukluğuna veya psikopat kişiliğe sahip kişilerin belirleyici özelliği, davranışlarından sorumlu tutulduklarında, kendilerini açığa çıkaran kişiyi, kendi sahip oldukları kişilik bozukluğuyla suçlamaktır. Dolayısıyla böyle bir durumla karşılaşıldığında, bu gerçeği ifade etmeli ve eklemeli: "Kendi kişilik bozukluğunuzu benim üzerime yansıtmayınız. Bu zorbalar tarafından kullanılan bir taktiktir. Dolayısıyla bunu yapmakla, aslında kendi kişilik bozukluğunuzu itiraf etmiş oluyorsunuz."

Sözlerinizde "kurban" dili kullanmayınız. "Hastalık" yerine "sağlık problemi", "İşimi yapamadım" yerine "taciz eden kişi görevlerimi tamamlamama engel oldu", "öfke" yerine "heyecan", "kurban" yerine "hedef" gibi kelimeler kullanmalısınız. "Kurban" kelimesi zorbaların ve destekçilerin, savunucuların ve inkarcıların, başka insanların "kurban olmak"la ilgili önyargılarını ve algılarını uyandırmalarına sebep olacaktır.

Zorba size bağırdığında, özellikle başkalarının yanında, kendinizi savunmak için, sakince "Görüşlerinizi bizimle paylaştığınız için teşekkür ederiz." deyiniz ve nazikçe ekleyin: "Lütfen bunu tekrarlayabilir misiniz?"

Yalnız bu şekilde bir söz düellosuna girmek, hazır cevap insanlar için sanırım daha uygun. Benim gibi pek çok kişi, sözlü çatışmalarda, böyle zamanlarda hızlı cevaplar veremez. Bu durumda, risk almamakta fayda var. Yoksa, kendinizi yeni bir duygusal saldırıya maruz bırakabilirsiniz.

Mobbingle mücadele ederken, özellikle yönetimle görüşürken, detaylara girmekten kaçınınız. Detaylara girmek, insanların size karşı dönmelerine sebep olur. Yasal, finansal ve anlaşmaya dayalı noktalara odaklanın. Yazı yazarken, duygu, şok, korku, intikam, kızgınlık, sansasyonellik, rica, yalvarma, keskinlik, sızlanma, ağlama, kendini hor görme, özür gibi şeylerden kaçınınız. Ayrıca ünlem, soru işareti, gereksiz büyük harfler ve vurgulamalar, renkli yazılar gibi okuyucuyu rahatsız eden formatlamalardan kaçınınız. Bu gibi davranışlar, okuyucu üzerinde ters etki oluşturacaktır. Kuşku uyandıracak ve söylediklerinizin doğruluğuna güvenmemelerine sebep olacaktır.

Abartılı, boş, literatüre atıf yapan, herkesin bildiği sözlerle dolu veya telaşa verici bir dil kullanmayın. %100 yerinde olmayan hiçbir şeyi yazmayın. Daha az kelimeyle anlatabilmek varken, daha çoğunu kullanmayın ve totolojiye (kendini tekrarlama) girmeyin. İtiraf türündeki sözleri silin. Kendinizi küçültmeyin. Mümkün olduğunca kısa, öz ve profesyonel kalın.

Tercihen bir sayfayı, azami iki sayfayı geçmeyin. Yazdıklarınızın sesli ve kamuya açık bir yerde okunması durumunda, nasıl algılanacağını düşünün. İki sayfadan uzun mektuplar okunmayacaklardır. Eğer dahil etmeniz gereken rapor, tablo gibi detaylar varsa, bunları ekler kısmına koyun, böylece okunması ertelenebilsin. Yazılı iletişimi, mümkün olduğunca kısa tutun.

Mobbingin hedefi, kendi iddialarını destekleyecek çok sayıda bilgiye sahiptir. Ancak dinleyen kişilerin, bunların tümünü değerlendirmeye vakti yoktur. Kuşkuyla karşılaşan hedef daha fazla detaylara girerek, kanıt sunma eğilimindedir. Ancak dinleyen kişi, bu tip bir kişisel bilgi bombardımanıyla karşılaştığında bariyer koymak ister. Ne kadar çok detay olursa, o kadar çok kuşku ve inkar olur. Ne kadar çok kuşku olursa, hedef o kadar çok detay sunmak ister. Bu bir kısır döngüdür. Bu yüzden iletişimi mümkün olduğunca kısa ve öz tutun. Aksi taktirde güvenilirliğinizi yitirirsiniz.

Zorba kasıtlı olarak, diğer kişilerin hedefle çatışma içine girmesi için uğraşır. Böylece dikkatlerin kendi üzerinden dağılmasını ve kendisiyle ilgili olumsuz bilgilerin birikmesini önlemeyi amaçlar.

Önemli sorunlardan biri, zorbayla ilgili daha fazla bilgi toplamaktır. Zorbanın geçmişinde de benzer sorunlar ortaya çıkmıştır. Fakat bunları siz bilmiyorsunuzdur. Bir iki yıllık bir çerçevede, her şey sadece sizinle ilgiliymiş gibi görünür. Ama 10 yıllık bir çerçevede olayları görebilseydiniz, odak noktasında siz değil, zorba kişi görünürdü. Sizin yaşadığınız tacizler, buz dağının sadece görünür kısmıdır. Çoğu durumda, suyun altında zorbanın davranışlarını açıklayan çok sayıda bilmediğiniz sorun vardır. Siz sadece zorbanın giderek artan paranoyasının saklandığı kavanozu açan kişisinizdir.

Mümkün olduğunca derinleri deşmeye ve zorbayla ilgili bilgi bulmaya çalışın. Sosyal nezaket açısından bu iyi bir davranış değildir. Ama burada hukuki nezaket geçerlidir. Zorbanın geçmişinde çok sayıda suç veya ahlak dışı davranış bulunur.

Ancak burada da bir problem var. Zorba kendisiyle ilgili bilgi sızdırmamaya özel dikkat gösteriyordur. Geçmişinde pek çok karanlık nokta olduğundan ve zorbalık konusunda tecrübeli olduğundan dolayı, bilgi saklamayı iyi biliyordur.

Bütün bu yöntemler bir yana, bence dua etmek ve Allah'a güvenmek her şeyden daha önemli. Çünkü bu yöntemler kişiye, kendisini savunması için araçlar sunmakla birlikte, zorbalığa uğrayan kişinin en önemli sıkıntılarından biri ruhsal olarak kendisini rahatlatabilmesidir. Aksi durumda kendisini savunması bile oldukça güç olacaktır.

Yazının Devamı...

Salı, Ocak 24, 2006

Mobbing - Duygusal Yıldırma

Dün akşam internette araştırma yaparken yeni bir kavramla karşılaştım: mobbing. Türkçeye belki duygusal yıldırma veya taciz diye çevrilebilir. Anlamı, iş ortamında sahip olduğu güce dayanan bir kişinin, başka bir kişiyi çeşitli duygusal manipülasyon yöntemleriyle yıldırması anlamına geliyor. Çok önemli bir kavram. Bu olay, hepimizin orta okuldan beri bildiği bir şey olmakla birlikte, buna bir isim verilmesini ve bu konunun detaylı olarak incelenmesini çok faydalı buluyorum.

Çünkü yıldırmaya maruz kalan kişinin, kendi haklılığını ikna etmesi son derece güç. Ancak çeşitli manipülasyon teknikleri kullanan kişinin davranışlarını iyice anlamakla, mağdur kişi, kendi haklılığını ispatlayabilir.

Bu konuda birkaç tane siteyi dolaştım: Wikipedia'daki mobbing makalesi, mobbingin anlamını tanımlıyor. Leymann adlı bir bilim adamının sitesi var: http://www.leymann.se/ Leymann kendisi, 1990'lı yıllarda mobbing terimini ilk ortaya atan ve bu konuda detaylı araştırmalar yapan bir kişi. Büyük bir ahlaki ve bilimsel sorumluluğa sahip olduğundan daha 1996 yılında web sitesinde yaptığı araştırmaların önemli bir kısmını webde herkesin erişimine açmış. http://www.bullyonline.org/ sitesi de çok detaylı bilgiler sunuyor. Şu sorulara yanıtlar veriyor:

  • Niçin duygusal tacize maruz kaldığınızda insanların çoğu yardım etmez?
  • Niçin "zorba" (bully) kişi sizi seçmiştir?
  • Neden zorbalık yaparlar?
Bullying kelimesini zorbalık olarak, bully kelimesini de zorba olarak çevirdim. Biraz Türkçede unuttuğumuz bir kelime. Zorbalığın sanki sadece geçmiş zamanda veya sadece mafya gibi yasadışı ortamlarda olduğunu düşünüyoruz. Halbuki gerçekte zorbalık gündelik hayatta kendi aramızda çok sık gerçekleşebiliyor. Manipülasyon teknikleri uygulamak, uzun süreye yayılmış düşük gerilimli çatışmalar yürütmek, arkadan konuşmak, küçük düşürmelek, hedef kişinin yaptığı işe yönelik haksız suçlamalarda bulunmak, hedef kişiyi otoriteye isyan etmekle veya uyumsuzlukla suçlamak, hedef kişinin itibarını zedelemek, üçüncü kişilerden bilgi saklamak ve insanlara yanlış bilgi vermek gibi çok sayıda davranışla, "zorbalık" yapılıyor.

Önemli noktalardan biri de şu: Mobbing, uzun süreye yayılan, yıldırma taktiğidir. Uzun süreye yayıldığı için, insanlar açık bir şekilde büyük bir haksızlık yapıldığını göremiyorlar. Ayrıca mağdur kişi, gerilim ve stres içinde uzun süre kaldığı için, zaman içinde duygusal dengesini kısmen yitiriyor. Bazı durumlarda, mobbingin sonucunda, mağdur zihinsel rahatsızlık geçirebiliyormuş. Dolayısıyla, henüz bu safhaya gelmediyseniz bile, size yapılan haksızlığın aslında adli suçlar kadar tehlikeli ve zararlı bir suç olduğunun farkında olmalı ve önlem almakta acele etmelisiniz.

İnsanlar, iş ortamındaki meslektaşlarınız niçin size yardım etmiyor? Bu soruya bullyonline sitesinde çok sayıda cevap verilmiş. Ben burada bunlardan birkaçını Türkçeye çevirerek derliyorum.

  • Az sayıda insan, zorbalığa, haksızlığa, ahlaki kirliliğe karşı koyacak dürüstlük ve cesarettedir. Mobbingin hedefi olan kişi, çoğu zaman bu ahlaki özelliklere sahip olduğundan zorbalığa maruz kalır.
  • Çoğu kişi, yapılan haksızlıkları ve tacizleri anlayamaz. Çünkü saldırganlıktan farklı olarak, yıldırıcı tacizler dolaylı ve gizlidir. Çok sayıda belki yüzlerce küçük küçük olaylardan oluşabilir. Bunların her biri tek başına basit ve bağlamından soyutlanmıştır. Bu yüzden, izleyenler bütün resmi göremez.
  • Zorba hedefinin itibarını küçük düşürmeye yönelik uzun süreli bir uygulama içindedir. Hedefin, kötü iş yapan biri olduğunu insanlara gösterir. Sürekli çamur atılan kişi, meslektaşlarının gözünde, organizasyon için bir tehdit olarak algılanır.
  • Zorba, hedefle ilgili pek çok bilgiyi saklar ve insanlara yanlış bilgi verir.
  • Yukarıdakilere ek olarak, benim gördüğüm kadarıyla zorbaların bir taktiği de, mağdur kişiyle ilgili kimsenin itiraz edemeyeceği bir haklı eleştiride bulunmaları. Diğer insanlara özellikle, hedef kişiyle ilgili bu haklı eleştiriyi gösterirler. Bu da diğer insanların, mağduru savunmalarını güçleştirir.
Yine bullyonline sitesinde, zorba kişilerin niçin özellikle hedef kişiyi seçtiklerine yönelik çeşitli cevaplar var:

  • Tamamen yanlış zamanda yanlış yerde bulunmaktan kaynaklanabilir. Hedef kişi, o sırada orada kim olsa o olacaktır.
  • İşinde iyi ve uzman olan kişiler mobbing hedefi seçilir.
  • Zorbalar genellikle korkaktır. Kendi yetersizliklerini ortaya çıkarabilecek ahlaki özelliklere ve profesyonel yeteneklere sahip kişilere kin beslerler.
  • Özgür ve önyargılardan uzak, ahlaki ve mesleki kurallara uymaya gayret eden kişiler hedef seçilir.
Özellikle kişisel ilişkiler ve yeteneklere yönelik kıskançlık mobbingin önemli sebeplerinden biridir.

Uçak kazalarıyla ilgili yapılan araştırmalar, pek çok uçak kazasının otoriter özellikteki kaptanların çevrelerinde kendilerine itiraz etmeyen bir sürü oluşturmasından kaynaklandığını gösteriyor. Kaptanın yardımcıları, kaptanın kurallara uymayan davranışlarına karşı çıkamadıklarından, büyük kazaların olduğu gözlemlenmiş. Bu kazaların sonucunda, havacılık sektöründe, kaptanlara verilen yetkiler azaltılmış ve pilot eğitimleri daha fazla takım çalışmasına yatkın bir hale getirilmiş.

Statükoyu farkında olmaksızın tehdit eden olaylar, zorba kişileri tetikleyen sebeplerden biridir. Dikkat çekmek, bir emire -bu emirin kuralları ihlal etmesinden dolayı- itaat etmemek, zorbalığa maruz kalan bir iş arkadaşını savunmak gibi davranışlar, zorbanın sizi hedef olarak seçmesine sebep olur.

Mobbingle ilgili yapılan araştırmalar, mağdurların, genellikle zeki, yenilikçi, azimli, dürüst, hoşgörülü, iyimser, idealist kişiler olduğunu gösteriyor. Bu özelliklerdeki insanlar, iş yerindeki zorbanın konumu için tehdit edici olmasından dolayı, hedef oluyorlar.

Bullyonline sitesinde, zorbaların bir hedefi tamamıyla yıldırıp yendikten sonra yeni bir hedef bulduklarını yazıyor. Bunun saplantıya dayalı bir davranış (obsessive compulsive behaviour) olduğunu, eğer kendilerine yeni bir hedef bulmazlarsa, kendi yetersizliklerini yansıtabilecekleri biri olmayacağından yaşayamayacaklarını yazıyor.

Bu sayfada, zorbalara karşı kullanılabilecek sözlerden çeşitli örnekler verilmiş. Yalnız pek çok kişi, stres anında, böyle sözler etmeyi başaramaz. Ben kendi adıma, stres altındayken, hemen hemen hiç konuşamam. Genellikle sessiz kalırım ve haklılığımın, zaman içinde ortaya çıkacağını kendi kendime telkin ederim..

Sitedeki şu cümle çok dikkatimi çekti:
"When responding to specious (plausibly deceptive) criticisms and allegations, under no circumstances be deceived into explaining, justifying, elaborating or apologising - each of these responses accords the criticism or allegation a validity which it does not have. Always put the onus on the bully to provide substantive and quantifiable evidence to justify his or her accusation."

Türkçesi:
"Yanıltıcı (muhtemelen aldatıcı) eleştirilere ve dayanaksız suçlamalara cevap verirken, hiçbir zaman açıklama yapma, davranışınızı meşrulaştırma, özür dileme, iddiaları ele alma gibi bir davranış yapmaya aldanmayın. Bütün bu yanıtlar, dayanaksız suçlamalar bir geçerlilik verecektir ki aslında bunların hiçbir geçerliliği yoktur. Somut, ölçülebilir kanıtlarla iddialarını ispatlama işini, her zaman zorbalık yapan kişinin üzerine yükleyin."

Çok doğru bir öneri. Mobbing yapan kişi, dayanaksız iddialarda bulunduğundan, bu kişiler için yeni suçlamalarda bulunmak oldukça kolaydır. Çünkü suçlamalarının dayanağı olması gerekmez. Halbuki hedef kişinin her bir iddianın yanlışlığını az bir zamanda, stres altında ve yanıltıcı bir çerçeve içine sokulmuş bir tartışmada son derece güçtür. Dolayısıyla, bu şartlar altında, hedef kişinin zorbanın iddialarına cevap yetiştirmeye teşebbüs etmemesi gerekir. Bunun yerine odak noktasını zorbanın kendi iddialarını ispatlamasına getirmeli.

Mobbing yapan kişilerle ilgili benim bir gözlemim de şu şekilde: Mobbing yapan kişi kendisi eksik veya yetersiz insandır. Uzun süreden beri mobbing yaparak yaşamaya alıştığından, öğrenme kabiliyetini uzun süre önce kaybetmiş, bu yüzden mesleki ve sosyal becerileri son derece sınırlıdır. Dolayısıyla, hedef kişi için son derece saçma ve basit görünebilecek iddialar, bu kişinin algı dünyasında, makul görünebilir. Hedef kişiyle, zorba arasında duygusal ve bilişsel zeka açısından ciddi bir fark bulunur. Zorba, hedef kişiye kıskançlık ve kin duygularıyla yaklaşır. Hedef kişi ise, zorbayı kendisi gibi normal zihinsel yeteneklere sahip bir insan olarak algılar. Halbuki, zorba kişi normalin çok altında düşünme ve öğrenme yeteneğine sahip bir insandır.

Yazının Devamı...

Perşembe, Ocak 19, 2006

Toplantilarin Calisanlar Uzerindeki Etkileri

Guardian Research sitesinde çıkan bir yazıda iş yerinde yapılan toplantı sayılarının giderek uzadığı, ancak bunun çalışanların motivasyonu üzerinde ters etkisi olduğuna yönelik çeşitli araştırma sonuçları anlatılıyor.

İlginç buldum...

Yazının Devamı...

Bedava Iconlar

http://www.famfamfam.com/lab/icons/ sitesinde açık lisanslı bedava simgeler (icon) var. Güzel yapmışlar.

Yazının Devamı...

Salı, Ocak 17, 2006

Operanın Arama Kutusunu Özelleştirmek

Yeni arama motorları eklemek için,

C:\Documents and Settings\...\Application Data\Opera\Opera\profile\search.ini dosyasını açın.

Mesela aşağıdaki gibi bir entry ekleyin:

[Search Engine 4]
Name=&Wikipedia
URL=http://www.wikipedia.org/search-redirect.php?search=%s&language=en&go=++%3E++&go=Go
Query=
Key=wiki
Is post=0
Has endseparator=0
Encoding=utf-8
Search Type=0
Verbtext=17063
Position=4
Nameid=0

Ancak search engine başlıkları arasında boşluk olmamalı ve numaralar küçükten büyüğe göre sıralanmalı.

Kaynak olarak: http://www.schrode.net/opera/search/search_ini.html sayfasından yararlanabilirsiniz.

Yazının Devamı...

Pazartesi, Ocak 16, 2006

Metodoloji Arayışı - In Search Of Methodology

Cockburn'den yaptığım özetlere çok beğendiğim bir makalesiyle devam edeceğim: In Search of Methodology:

IBM´in metodoloji danışmanlığı grubu OO metodolojileri araştırdı.

Çok sayıdaki OO metodolojisinden hangisini kullanmalıyız, sorusu yerine, bir OO metodolojisinin hangi unsurunu kullanmalıyız? Kabullenmeyi etkileyen şey nedir? Çeşitli yöntemlerin güzel özelliklerini nasıl entegre edebiliriz?

OO çok popülerleşti. Ancak uygulayıcıların çoğunun acemi oluşundan dolayı, yeterli bir olgunluk oluşmadı.

Bir metodolojinin kullanılabilir olması şu özelliklere bağlı:

Basit, etkili ve düşük iş yükü oluşturması. Kabullenme ve kullanışlılık, grubun iş alışkanlıklarını değiştirme yeteneğine bağlı. Ayrıca bürokratik işlere olan toleransına bağlı. Her ikisi de düşüktür. Mühendislik kökenli gruplarda daha yüksek.

Dizayn tekniklerinin faydalı olması için karmaşık olması gerekmiyor. En çok kullanılan ve fayda sağlayan iki teknik: Use caseler ve sorumluluklar. Bunlar aşamalı geliştirme (incremental development) ile de uyumlu. Ayrıca dizayn kalıpları gibi yeni fikirler için alan bırakıyorlar.

Araştırma bulguları:

- Geliştiriciler, doğrudan son ürüne yönelmemiş dizayn etkinliklerine zaman harcamak istemiyorlar.

- Elle (manuel) dizayn dokümanlarının güncellenmesi işinden hoşlanmıyor. Bunu yapmıyorlar.

- Yeni iş alışkanlıklarını öğrenmek için sınırlı zaman veriliyor.

- Geliştiriciler metodolojinin sevmedikleri yönlerini genellikle uygulamıyorlar.

Bürokratik işlerden kaçınılıyor. Bunun sebebi geliştiricilerin bu konuda yetkiye sahip olmaları. Veya değilse bile organizasyonun metodolojinin bu yönlerinin uygulanıp uygulanmadığını takip edememeleri. Proje yöneticisi de çoğu zaman metodolojinin yıkıldığının farkında değil.

Basit yöntemler:

Yukarıdaki sorunlar olmakla birlikte, iyi geliştirciler iyi sistemler tasarlamaya devam ediyor. Bunlarla yapılan görüşmeler, bunların basit, etkili ve verimli teknikleri tutarlı olarak yürüttüklerini gösteriyor.

Sorumluluk:

Sorumluluk temelli tasarımın en çok kullanılan ve etkili bir dizayn tekniği olduğu ortaya çıktı.

Sorumluluk sistem tasarımının gerekçesini oluşturur. Ancak yapısal tasarımda da sorumluluk kavramı vardı. Fark ne?

Nesne tasarımında sorumluluklar aynı zamanda hem tanımlanır hem de dağıtılır. Yapısal analizde tanımlanır ancak dağıtılmaz.

Ancak herkes sorumlulukların bulunup dağıtılması işini aynı kalitede yapmaz.

Yeni gelenler bile hemen bu işten dolayı ya bir rahatlık ya da bir rahatsızlık hissi alıyor.

Use case:

Sorumluluklar bir nesnenin veya alt sistemin bir fonksiyonu nasıl gerçekleştirdiğini gösterir. Ama niçini göstermez. Bunu senaryolar ve use caseler sağlar.

Use Case nedir?

Sistemle aktör arasındaki bir işlem diyaloğu...

Bu tanımda maksat eksik. Niçin?

Jacobson yeni yazılarında, daha kaba işlem ve senaryo seçiminin daha inceltilmiş seçimlerden daha faydalı olduğunu söylüyor.

Bir teyp cihazını düşünelim. Her bir İleri Sar, Play, Geri Sar düğmesi bir use case olabilir. Veya...

"Bu düğmelere niye basıyoruz?"

"Kasette belirli bir yeri bulmak için."

Öyleyse tek tek düğmeler değil, düğmelerin belirli bir kombinasyonu aslında bir use case. Veya şöyle diyelim: "Kasette belirli bir yeri bulmak için basıyoruz."

Use case, bir "kullanım zarfıdır". Zarfın kapağında, maksadı yazar. İçindeyse, bu maksadın nasıl gerçekleştiği, bu da başka use caseler, senaryolar ve kullanım zarflarıyla olur.

Use caselerin maksatlarının toplamı, bir sistemin ihtiyaçlarının en kısa ve okunabilir tarifidir.

Devirli geliştirme (iterative development):

Yapılan görüşmeler şunu gösterdi. Devirli geliştirme, projenin başarılı olup olmayacağının çok iyi bir ayırt edicisidir. Çok az yönetici bunun mantığını ve mekaniğini anlamış.

Niçin böyle?

Birinci sebep, aşamalı geliştirme, proje yöneticilerinin çalışma alışkanlıklarını etkiliyor. Halbuki bu insanların, değişme becerileri geliştiricilerden daha yüksek değil.

İkinci sebep, aşamalı geliştirme için karmaşık ve muğlak tanımlar kullanılmış. Spiral, küp, "gestalt round trip"... Bunların yerine daha basit tarifler gerekiyor.

Yazının Devamı...

Etkili Use Case Yazımı - Tavsiyeler

Cockburn'ün kitabından yaptığım özete devam ediyorum:

1. Her use case bir düz yazıdır (makale, prose)

İyi bir makale yazmak için geçerli olan bütün kurallar, use case yazımında da geçerlidir.

2. Kolay okunabilir yaz:

Use casei kimin için yazarız?

İnsanlar için. İnsanların kolay anlaması use caselerin kalite kriteridir. Use caseler kaliteli olmalıdır ki, nihai yazılım kaliteli olsun.

- Doğrudan amaca yönelik ve kısa olsun.
- İsim verirken, aktif fiillerle kullanıcı hedefini belirt.
- Aktif fiiller kullan

3. Tek cümle formu:

- Geniş zaman kullan
- Bir amacı gerçekleştiren bir aktörün dilinden yaz:

"Customer enters card and PIN."
"System validates that customer is authorized and has sufficient funds."
"PAF intercepts responses from the web site, and updates the user's portfolio."
"Clerk finds a loss using search details for "loss"."

Extensionların koşul kısmında farklı bir gramer biçimi kullan. Büyük oranda geçmiş ve : ile ayrılmış olsun.

"Time-out waiting for PIN entry:"
"Bad password:"
"File not found:"
"User exited in the middle:"
"Data submitted is not complete:"

4. Alt use caseleri metnin içine dahil et

Extends ve specializes özelliklerini kullanmaktan kaçın. Karışıklığa sebep oluyor. Normalde nasıl yazacak idiysen öyle yaz:

"Clerk finds a loss using search details for "loss"."

Finds a loss, alt bir use casedir.

5. Hedef seviyesini iyi ayarla

Deniz seviyesindeki amaçların özellikleri:

- Tek kişi tarafından tek yerde ve zamanda yapılır (2-20 dakika)
- İş bittiğinde aktör mutlu olarak ayrılabilir.
- Çok sayıda yaparsa, zam isteyebilir.

9´dan fazla adım varsa, adımları azalt.

- Kullanıcı hareketleri
- Benzer işler (veri girişi)
- Niçin bunu yapıyor?
- İki aktör arasında çok sayıda gidip gelme. Bu tarz bir müzakere sürecinin amacı nedir?

6. GUI´yi dışarıda bırak

- Doküman çok uzar.
- Kırılgan ve değişmeye çok müsait hale gelir.
- GUI kararları erkenden alınmış olur.

Kötü örnek:

2. The system displays the Login screen with fields for username and password.
3. The user enters username and password and clicks ’OK’.
4. The system verifies name and password.
5. The system displays the Main screen, containing function choices.
6. The user selects a function and clicks ’OK’.

7. Başarısızlık durumu

Başarısızlık durumu bütün alt use caseler için de ele alınmalı. Eğer alt use case, ana senaryodan çağrıldıysa, başarısızlık alternatif senaryolar kısmında ele alınır. Eğer alternatif akış içinde ele alındıysa, aynı yerde başarısızlık durumu da çözülür.

8. Bütün paydaşların (stakeholders) korunması:

Bir use case sadece ana aktörün (primary actor) amacına hizmet etmez. Bütün paydaşların beklentilerine hizmet etmeli. Eğer öyle olsaydı zaten, o zaman sadece kullanıcı etkileşimi tarif edilirdi.

Kullanıcı use casei sürer, ancak use case bütün paydaşların beklentilerini (garanti) karşılar.

- Ana aktörün amacı, use casein ismidir.

- Şirketin amacı, ödediği şeyin karşılığını almak.

- Düzenleyici kurum: Şirketin yönetmelikleri uyguladığı. Bir tür log tutulması.

- Paydaşlardan biri, hata durumunda kurtarmaya yönelik amacı vardır. Bu yüzden daha çok log ister.

Son koşullar (guarantees) kısmı, bütün paydaşların beklentilerinin nasıl karşılandığını ifade eder.

Son koşulları, ana senaryodan önce yazmakta fayda var. Çünkü bu sayede senaryo sırasında kimlerin hangi beklentilerini karşılamak gerektiği daha kolay ortaya çıkar.

10. Önkoşullar:

En yaygın önkoşullar, kullanıcının login olması ve yetkili olmasıdır.

Başka önemli bir önkoşul da, bir use casein bir başka use casede sağlanan koşula dayanmasıdır. Mesela bir use casede kullanıcı bir ürünü seçer. İkincisinde bu seçilmiş ürünün bilgisi işlenir.

Dolayısıyla ne zaman ki bir önkoşul varsa, daha üst seviye bir use case vardır.

11. Çek listesi:

İyi bir use casein sağlaması gereken özellikler:

- Use case başlığı: Aktif bir fiil cümlesi mi? Ana aktörün amacını mı ifade ediyor? Sistem bu amacı yerine getiriyor mu?

- Kapsam ve sevyie: Kapsam ve seviye alanları dolduruldu mu?

- Kapsam: Eğer use case bir srs dokümanıysa "kara kutu" olmak zorunda.

- Ana aktör: Ana aktörün davranışı var mı?

- Önkoşullar: Use case içinde hiç kontrol edilmiyorlar, değil mi?

- Paydaşlar: Onlardan hiç bahsediliyor mu?

- Sonkoşullar: Bütün paydaşların beklentileri karşılanıyor mu?

- Asgari garanti: Bütün paydaşların menfaatleri korunuyor mu?

- Ana senaryo: Tetikleyiciden mi başlatılıyor? Adım sırası doğru mu? 3-9 adım arası mı?

- Senaryodaki her adım: Bir amaç ifade ediyor mu? Hangi aktör tarafından yapıldığı belirtiliyor mu? Aktörün amacı açık mı? Amaç seviyesi, use casein amaç seviyesinden tam bir seviye mi düşük? Kullanıcı etkileşimini ifade etmiyor değil mi? Hangi bilginin aktarıldığı açık mı? Adım, "onaylama" yapıyor mu, bir koşulun "kontrol edilmesi" yerine?

- Alternatif adım koşulu: Sistem bunu tespit edebiliyor mu? Sistem bunu ele almak zorunda mı?

- Genel içerik: Sponsor ve kullanıcılara: "Bu sizin istediğiniz şey mi?" "Teslimattan sonra, bunu alıp almadığınızı söyleyebilecek misiniz?" Geliştiricilere: "Bunu gerçekleştirebilir misiniz?"

12. Sürekli açılan bir hikaye

Birçok projede en üst seviyede bir use case tanımlanır: "XXX Sistemini kullan". Bu aslında çok sayıdaki use casei toplayan bir içindekiler tablosu gibidir. Bu use caselerin arasındaki ilişkileri gösterebilir.

İnsanlar bir başlangıç noktası olarak böyle en üst seviye bir use case tanımlamayı faydalı buluyor.

Deniz seviyesindeki use caselerden bir alt seviyeye inince, daha derindeki indigo (lacivert) use caselere erişiriz. Bunlar genellikle sofistike bir adımın kendi başına tanımlanması şeklindedir. Müşteri bul, ürün bul gibi use caseler bu tarz alt fonksiyonlar olarak tanımlanabilir.

Ancak her use casein bakım maliyeti vardır. Bu yüzden bunlarda mümkün olduğunca tutumlu olmak lazım.

Prensip olarak alt seviye use caseler istenildiği kadar derinleştirilebilir.

13. İş kapsamı ve sistem kapsamı

Bir sistemin tasarımında sınırları belirlemek çoğu zaman muğlaklık içerir.

Use caseler tanımlanırken, özellikle, iş use caseleriyle (business) sistem use caseleri arasındaki ayrım net olmalı.

İş use casei, iş operasyonlarıyla ilgilidir. Bir iş akış şemasında, bir sürecin baştan sona gösterilmesindeki use caselerdir. Dolayısıyla iş use casei, otomasyon sisteminin içinde değildir. Sadece belirli adımları otomasyona dahildir.

İş use casei, açık kutu formunda ifade edilir. Sistem use casei ise kapalı kutu.

14. Temel değerler ve farklılaştırmalar

Bir konferansta iki makale, bir düzine kadar önemli hatayı özetledi. Bu makalelerde belirtilen temel değerler şunlardı:

- Amaç temellilik. Use caseler, ana aktörün amaçları ve diğer aktörlerin alt amaçları etrafında oluşur.

- Kuş bakışı perspektifi. Use case, sistemı kuş bakışıyla tasvir eder. İçeriden bir bakışla değil.

- Okunabilir. Use casein veya herhangi başka bir spesifikasyonun nihai amacı insanlar tarafından anlaşılmasıdır. Eğer insanlar kolaylıkla dokümanı anlayamazsa, doküman esas amacını gerçekleştiremez. Bu yüzden gerektiğinde hassasiyetten ve belki hatta doğruluktan bile bir miktar fedakarlık edilebilir. Bu açığı, daha fazla iletişim ve diyalogla kapatırsınız. Ancak eğer ki okunabilirlikten fedakarlık yaparsanız, yazılım geliştiricileriniz/müşterileriniz/yöneticileriniz onları okumaz.

- Çok çeşitli amaçlara hizmet eder.

- Kapalı kutu fonksiyonel ihtiyaçlar

- İş sürecinin yeniden tasarımının ihtiyaçları

- Süreç dokümantasyonu

- İhtiyaçların ortaya çıkarılması ve onaylanması için bir araç

- Test vakalarının belirlenmesi

- Sistemin iç yapısının dokümantasyonu

- Bir tasarım çerçevesinin davranışının dokümantasyonu

- Kapalı kutu ihtiyaçlar. Use caselerin açık kutu ihtiyaçların tanımlanmasında kullanılması durumunda, okunabilirlik düşüyor, daha kırılgan oluyor.

- Alternatif yollar, ana senaryodan sonra. Alternatif yolları, ana senaryonun içine yerleştirmek, anlaşılmayı güçleştiriyor. Jacobson´ın orjinal modeli, daha faydalı.

- Az enerji harcamak. Sürekli olarak use caseleri inceltmeye çalışmak, çok değer eklemiyor. İlk taslak, değerin yarısını zaten inşa ediyor. Cümlelerin ifade ediliş şekli gibi detaylarla oynamak, iletişimi kötüleştiriyor bile. Bunun yerine iş kurallarının tanımlanması, kullanıcı arayüzlerinin, harici arabirimlerin kontrolü gibi diğer ihtiyaçlarla ilgilenmek daha faydalı olur. Tabi ki, projenin kritikliği de inceltme noktasında önemli bir karar kriteri.

Değişebilecek noktalar:

- Numaralanmış adımlar veya basit paragraflar. İnsanlar hangisiyle daha rahat çalışıyorsa, o tercih edilmeli.

- Tam doldurulmuş veya serbest yazılmış. Bazı zamanlar fonksiyonel ihtiyaçların eksiksiz bir şekilde detaylandırılması doğrudur, bazen hafif olarak doldurulması yeterlidir. Dolayısıyla use case şablonları da mutlak bir şekilde dikte edilmemeli.

- Ön iş modellemesi, use caselerle veya use caselersiz. İş sürecinin dokümantasyonu, sistemin fonksiyonel ihtiyaçlarının tanımlanmasından önce de olur, sonra da.

Uygunsuz noktalar:

- Ana başarı senaryosunun içinde "eğer" cümlelelri

- Use case metni yerine, sequence şemaları. Sequence şemaları, use case metninin yerine geçemez. Çünkü,

- okunması daha zordur (özel bir notasyon içerir)
- paydaşların beklentilerinin korunup korunmadığını ifade etmez.
- Okların üzerine yeterli metin yerleştirmek imkansızdır
- Metnin bir pop-up diyalog kutusuna yazılmasını gerektirir. Bu da hikayenin takibini zorlaştırır.

- GUI detaylarının fonksiyonel spesifikasyonlarda yer alması. Bunun yanlışlığı konusunda genel bir uzlaşma vardır.

16. Use caseler sadece bir chapterdır.

Başka chapterlar da var, ihtiyaç analizinde ele alınması gereken: Veri tanımları, iş kuralları, kullanıcı arayüzü tasarımı, iş alanının modeli ve sair. Use caseler bunların hepsinin merkezindeki bir çekirdek gibi.

Bu çok önemli bir nokta. Çünkü çok sayıda ekipte, use caseler ihtiyaç analizinin tümünü içeren bir parça olarak ele alınıyor.

17. Önce genişlik.

Genişlik, derinlikten önce gelir. Düşük hassasiyetten, yüksek hassasiyete doğru gidilmeli. Bu enerjinizi daha verimli yönetmenizi sağlayacak. Şu sıra ile çalışın:

1. Baş aktörler. Bütün baş aktörleri tespit edin. Beyin fırtınası...

2. Amaçlar. Bütün baş aktörlerin bütün amaçlarını listelemek, bütün sistemin tek bir seferde görünmesini sağlamak için son şans olacaktır. Bu listenin tam ve doğru olması için yeterli zaman ve enerjiyi harcamanın getirisi çok olacaktır.

3. Ana başarı senaryosu. Ana senaryo genellikle kısa ve çok açıktır. Alternatif akışları ortaya koymadan önce ana senaryo bir ortaya çıkmalı.

4. Hata ve genişletme koşulları. Nasıl ele alınacaklarının tespit edmeden önce, hangi farklılaşma koşulları olabilir, bunları tespit etmek önemli. Bu da yine bir beyin fırtınası etkinliğidir, araştırmadan ziyade.

5. Düzeltme davranışı. Hata koşullarının ne olacağını önce tespit etmeli. Sonra bunların nasıl düzeltileceği belirlenmeli.


18. 12 adımlık reçete:

1. Sistemin sınırlarını bul
2. Baş aktörleri beyin fırtanası ile listele.
3. Baş aktörlerin amaçlarını beyin fırtanası ile listele.
4. En üst seviye özet use caseleri yaz.
5. Stratejik use caseleri değerlendir ve gözden geçir.
6. Malzemeyi daha iyi anlamak için, bir use casei al ve hikayesini yaz.
7. Paydaşları, menfaatlerini (interest), önkoşullarını ve sonkoşullarını yaz.
8. Ana başarı senaryosunu yaz. Menfaatler ve sonkoşullarla kıyasla.
9. Beyin fırtınası ile, bütün hata ve alternatif başarı koşularını listele.
10. Aktörlerin ve sistemin her alternatifte nasıl davranacağını yaz.
11. Alt use caseleri ayır.
12. En üstten başla ve use caseleri yeniden ayarla. Ekle, çıkar, birleştir. Tamlığı, okunabilirliği ve hata koşullarını gözden geçir.

19. Hataların maliyeti.

Her projenin hassasiyet seviyesi, o proje takımındaki iletişim seviyesine ve projenin kritikliğine bağlıdır. Mesela Chrysler Bordrolama programında, kısa use caseler yeterli olmuştu. Çünkü müşteriyle yazılımcıların arasındaki iletişim çok yüksekti.

20. Blue jeanler tercih edilir.

Kulağa tuhaf gelse de, daha az yazmanın zararı daha çok yazmaya göre daha düşüktür. Eğer şüpheye düşüyorsanız, daha az metin yazın. Daha üst seviye amaçları kullanın. Hassasiyeti düşürün. Böylece kısa ve okunabilir bir dokümanınız olur. İnsanlar, okuyunca, sorularını sorar.

Eğer çok uzun yazarsan, insanlar okumaya üşenecektir. Takım içindeki iletişim azalacaktır.

Bu çok sık yaşanan bir sorundur.

21. Hataları ele al.

Use caselerin en büyük değerlerinden biri, alternatif koşulları isimlendirmektir. Hataları tanımlamak ve bunların nasıl ele alınacağını incelemek, çoğu zaman sistemle ilgili bilinmeyen birçok şeyi (aktörleri, amaçlarını, iş kurallarını) ortaya çıkaracaktır.

Hemen hemen her programcı şöyle bir şeyi yaşar:


If (condition)
then
else ..?.


else kısmına gelince durur. "Bu durumda ne yapılacak?" Hemen kendisi bir şey tahmin eder ve onu kodlar.

Halbuki else kısmında yazılması gereken şey, ihtiyaç dokümanında belirtilmiş olmalıydı.

22. İş ünvanları erken ve geç

İş ünvanları projenin başlangıcında da sonunda da önemlidir. Ama ortasında değil.

İş ünvanlarını başta ortaya çıkararak, sistemin gerçekleştirmesi gereken amaçları ortaya çıkarırsın.

Projenin sonunda yine önemli hale gelir. Çünkü izin seviyelerini ayarlamak, eğitim malzemelerini hazırlamak, paketlemek bu aşamada olur.

Yazının Devamı...

Etkili Use Case Yazımı - Use Case Adımları

Alistair Cockburn'ün "Writing Effective Use Cases" adlı kitabı en faydalandığım yazılım mühendisliği kitaplarından biri. Cockburn bu kitabında bir yazılımın davranışsal ihtiyaçlarını (behavioral requirements) keşfetmek ve tanımlamak için kullanılan use case modellerinin nasıl etkili bir şekilde yazılacağını anlatıyor. Kitabın önemli kısımlarını kendim için bundan iki sene kadar önce özetlemiştim. Bloguma bu özetimden bazı kısımları koyacağım. Özetlerin parça parça ve asıl metinin kısaltılmış hali olmasından dolayı, bir telif hakkı ihlaline sebep olmayacağını ümit ediyorum.

Adım cümleleri, her zaman aynı gramer formunda yazılır. Basit tek aktif eylemden oluşan bir cümle:

"User enters name and address."
"At any time, user can request the money back."
"The system verifies that the name and account are current."
"The system updates the customer’s balance to reflect the charge."

1. İlke: Özne - zarf - tümleç - yüklem
2. İlke: Topu kimin attığı çok açıktır.
3. İlke: 3. kişinin gözüyle

İlk başlarda insanlar, sistemin gözünden etkileşimi yazıyor. Halbuki, ne sistem ne de kullanıcı. Üçüncü kişinin gözünden etkileşim tarif edilmeli.

4. İlke: Süreç sürekli olarak ileri doğru ilerler

Her bir adım, ana use casedeki amaçtan bir alt seviye amaca sahiptir.

Before:
1. System asks for name.
2. User enters name.
3. System prompts for address.
4. User enters address.
5. User clicks ’OK’.
6. System presents user’s profile.
After:
1. User enters name and address.
2. System presents user’s profile.

Eğer çok sayıda veri girişi varsa, bunları ayrı ayrı satırlarda madde madde yazabilirsiniz:

Acceptable variant 1:
3. Customer enters name, address, phone number, secret information, emergency contact
phone number.
Acceptable variant 2:
3. Customer enters
- name
- address
- phone number
- secret information
- emergency contact phone number

5. İlke: Bir eylemler kümesidir

Jacobson, bir adımı, alt seviye bir transaction olarak tanımlıyor. Bir transaction çeşitli alt eylemlerden oluşur:

1. Ana aktör bir talepte bulunur ve sisteme veri gönderir.
2. Sistem talebin ve verinin geçerliliğini onaylar
3. Sistem iç durumunu değiştirir
4. Sistem, aktöre sonucu gönderir.

Bütün bu dört eylemi, tek bir adım içinde de anlatmak mümkündür, ayrı ayrı da. Hangi yolun daha iyi olacağı, adımın karmaşıklığına bağlıdır. Aşağıdaki örnekte, aynı adımın farklı şekillerde parçalanması görülüyor:

Version 1.
1. The customer enters the order number. The system detects that it matches the winning number
of the month, registers the user and order number as this month's winner, sends an email to
the sales manager, congratulates the customer and gives them instructions on how to collect
the prize.
Version 2.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month, registers the user and
order number as this month's winner, sends an email to the sales manager, congratulates the
customer and gives them instructions on how to collect the prize.
Version 3.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month.
3. The system registers the user and order number as this month's winner, sends an email to
the sales manager, congratulates the customer and gives them instructions on how to collect
the prize.
Version 4.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month.
3. The system registers the user and order number as this month's winner, and sends an email
to the sales manager.
4. The system congratulates the customer and gives them instructions on how to collect the
prize.
Version 5.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month.
3. The system registers the user and order number as this month's winner.
4. The system sends an email to the sales manager.
5. The system congratulates the customer and gives them instructions on how to collect the
prize.

1. versiyon çok karmaşık. 2. versiyon genellikle basit adımlar için uygun. 3. versiyon bu örneğe iyi oturdu. 4. ve 5. versiyonlar da iyi.

6. İlke: Kontrol etmez, onaylar

Sistem bir iş kuralının geçerli olduğunu onaylar. Birçok zaman bunun yerine, sistem şu koşulu kontrol eder, ifadesi kullanılıyor. Bu ifade, süreci açıkça bir adım iletletmiyor. Kontrolün sonucu belli değil. Bir amaç ifade etmiyor. Bunun ardından, şunu yazmak gerekiyor: "Eğer kontrol geçerse ..." "Eğer kontrol geçmezse ..."

Niçinini sorarsak bu tarz ifadeleri düzeltebiliriz. Sistem niçin koşulu kontrol ediyor? Bir kuralın geçerli olduğunu sabitlemek, onaylamak veya temin etmek için.

Before:
2. The system checks whether the password is correct
3. If it is, the system presents the available actions for the user.
After:
2. The system validate that the password is correct
3. The system presents the available actions for the user.

7. İlke: Zamanlama opsiyoneldir

Çoğu adım birbirini takip eder. Ama gerektiğinde bir adımın ne zaman gerçekleşeceğini belirtebilirsiniz.

3 ve 5. adımların arasında, kullanıcı şunu yapar...

Kullanıcı şunu yaptığında, sistem bunu yapar.

8. İlke: İfade: "Kullanıcı, A sistemine B sisteminde iş yaptırtır."

Birçok zaman tasarladığımız sistemin, başka bir sisteme bir iş yaptırtması gerekir. Bu durumda, şöyle diyemeyiz: "Kullanıcı Verileri Çek düğmesine basar. Sistem verileri, MRP sisteminden talep eder."

Bu kullanıcı arayüzü detaylarını açığa çıkarmak olurdu.

İki adım olarak yazabiliriz:
4. User signals to the system to fetch data from system B.
5. The system fetches the background data from system B."

Doğru olsa da, bu uzundur. Daha kolayı:
4. User has the system fetch the z data from system B.

9. İlke: İfade: "x-y adımlarını ... koşuluna kadar tekrarla"

Düz metinle yazıyor olmamızın bir katkısı, tekrarlanan işlemleri, daha kolay bir şekilde ifade edebiliyor olmamızdır.

Tek adım tekrarlanıyorsa:

"Kullanıcı bir veya daha çok ürün seçer."
"Kullanıcı çeşitli ürün katalogları arasından istediği ürünü buluncaya kadar dolaşır."

Eğer birkaç adım tekrarlanacaksa, tekrarlanan bloğun öncesine veya sonrasına tekrarlama ifadesini yaz. Sonrasına yazmak daha kolay anlaşılır.

1. Customer supplies either account identifier or name and address.
2. System brings up the customer's preference information.
3. User selects a item to buy, marks it for purchase.
4. System adds the item to the customer's "shopping cart".
Customer repeats steps 3-4 until indicating that he/she is done.
5. Customer purchases the items in the shopping cart (see use case xxx).

Tekrarlama ifadesini numaralandırmadık. Böylesi daha okunaklı.

Tekrarlamanın bir türü de, x-y adımlarının herhangi bir sırada meydana geleceğini belirtmektir:

1. Müşteri login olur
2. Sistem mevcut ürünleri ve servisleri sunar.

2-4. adımlar herhangi bir sırayla gerçekleşebilir
2. Kullanıcı satın alacağı ürünleri seçer.
3. Kullanıcı ödeme biçimini belirtir.
4. Kullanıcı nakliye adresini verir.

5. Kullanıcı alışverişin bittiğini işaretler
6. Sistem siparişi başlatır. Seçili ürünleri, tercih edilen ödeme biçimine borçlandırır ve nakliye adresine yollar.

Yazının Devamı...

Pazar, Ocak 15, 2006

Yeni Groovy

Yazılım dünyasının en güzel özelliklerinden biri, birkaç ay kendisinden uzak kaldığınızda, size pek çok yeni ürünler göstermesi... Bir süredir gerek işte uğraştığımız projelerden, gerek de akşamleyin farklı alanlarla ilgileniyor olmamdan dolayı, java dünyasındaki yenilikleri takip edemiyordum. Bugün biraz internette dolaştım, java.net, clientjava.com ve diğer popüler sitelerdeki geçmiş blogları takip ettim. Özellikle groovy ve netbeans beni çok etkiledi. Kendim yazılım geliştirirken, IntelliJ'i kullanıyorum. IntelliJ pek çok açıdan bütün diğer IDE'lerden daha fazla verimlilik kazandıran özelliğe sahip. Ama yine de Netbeans'in özellikle Matisse adlı GUI tasarımı için kullanılan modülü harika. IntelliJ'de veya şu ana gördüğüm diğer GUI tasarım araçlarından çok daha kullanışlı ve özellikli.

Bu arada, java.net'te birinin yazısını okuyordum. Microsoft'un pazarlama yöneticilerinden biri yeni VS'deki Rename ve IntelliSense özelliklerinin çok büyük yenilikler olduğunu söylüyormuş. Halbuki bunlar Eclipse, IntelliJ gibi java IDE'lerinin artık yıllar önce geride bıraktıkları standart özellikler. MS dünyasını doğrudan gözlemleyemiyorum. Çalıştığım yerde herkes java üzerinde çalışıyor. Evde de MS'in ürünlerini yüklemedim. Ancak dolaylı yollardan öğrendiklerim kadarıyla Java platformu, MS'den hem görsel tasarımda, hem de yenilikçi IDE özelliklerinde birkaç sene daha önde.

İki sene önce Petran/MedArt firmasında çalışırken yöneticilerimizden biri -Ömer Oruç- çok güzel bir söz söylemişti. Tam olarak dediklerini hatırlayamıyorum, ama yaklaşık şu anlama geliyordu: Uzun vadede, açık platformlar, kapalı platformlara göre üstünlük sağlar. Çünkü açık platformlar, çok daha fazla insanın katkısıyla gelişir.

Java dünyasındaki çok sayıdaki yenilikten biri de Groovy. Daha önce Ruby on Rails ile ilgili izlenimlerimi birkaç defa yazmıştım. Groovy, Ruby'nin güzel yönlerini java ortamında yapmaya izin veren bir ortam. Ortam diyorum, çünkü içinde yeni bir programlama dili, bir MVC web framework, debug etmeyi kolaylaştıran bir konsol, COM objelerini scriptle programlamayı sağlayan bir kütüphane gibi çok sayıda teknolojiyi barındırıyor. Umarım yeterince yazılım geliştirici tarafından Groovy kullanılır ki, zaman içinde daha da fazla gelişebilsin.

Yazının Devamı...

Pazar, Ocak 08, 2006

Yenilikçilik Sanatı Kitabı

Tom Kelley'in Yenilikçilik Sanatı adlı kitabını sanırım bundan üç sene kadar önce okumuştum. Kitap Ezcazıbaşı Holding tarafından basılmış. Ezcacıbaşı'nı böyle güzel bir kitabı Türkçeye çevirdiği ve bastığı için kutluyorum. Ancak böyle kaliteli kitapların, yayıncı olmayan şirketler tarafından bastırılıp dağıtılmasını doğru bulmuyorum. Ezcacıbaşı, kendisi yayıncılık işinde olmadığından kitabı az sayıdaki şirket personeline ve tanıdıklara dağıtmakla yetiniyor. Halbuki bu gibi kitapların daha fazla insana erişebilmesi gerekir. Bunun için de kitabın kitapçılara dağıtılması lazım. Ancak yayıncılık işinde olmayan Ezcacıbaşı gibi şirketler, kitabın dağıtımını iyi yapamıyorlar. Öyle olunca da geniş kitleler böyle güzel kitaplardan faydalanamıyor...

Kitabın amazondaki linki için burayı tıklayın. Türkiye'deki kitapyurdu.com gibi sitelerden link veremiyorum, çünkü kitabın Türkçesi Türkiye'deki kitapevleri tarafından satılmıyor.

Yazının Devamı...

Salı, Ocak 03, 2006

Kapsamli Bir Analiz Yontemi: Volere

Hafta sonu ODTÜ'nün kütüphanesinden Suzanne ve James Robertson'ın "Mastering The Requirements Process" adlı kitabını almıştım. Çok güzel bir kitap. Özellikle yazılım sektöründen çıkılarak yazılmış olmakla birlikte, yeni bir sistem veya ürün geliştirme işiyle uğraşan herkese öneririm.

Yöntem anlatan kitapların ne yazık ki az bir kısmı faydalı bir bilgi veriyor. Pek çok kitap ya çok detaya gömülmüş, ya da işe yarar bilgiler içermeyen çok genel ve muğlak bir anlatıma sahip. Robertson'ların kitabı bu yönlerden çok iyi. Hem kapsayıcı bir teoriyle, analiz işinin bütününün resmini gösteriyor. Hem de çok fazla örneklerle anlatımı zenginleştirerek, ne demek istendiğini çok net bir şekilde somutlaştıyor.

Kitap Volere adını verdikleri bir analiz yöntemini anlatıyor. Bu yöntem, bir sistemin gereksinim analizini yaparken, hem izlemeniz gereken süreci adım adım anlatıyor, hem de nihai olarak üretilecek gereksinim spesifikasyon (requirements specification) dokümanının içeriğine yönelik bir şablon sunuyor. Anlatılan süreç, bu dokümanın içeriğine ait bilgilerin hangi aşamalarda nasıl toplanacağını gösteriyor.

Buraya önerdikleri gereksinim spesifikasyon dokümanının şablonunu Türkçe olarak aktarıyorum. (Umarım yazarlar bundan dolayı şikayetçi olmazlar :))

Sistem Kısıtlamaları - tüm sistemi belirleyen kısıtlamalar
1 Sistemin amacı - sistemi geliştirme amacı ve sağlayacağı iş faydası
2 Müşteri ve diğer paydaşlar - sistemle ilgisi olan kişiler
3 Sistemin kullanıcıları - son kullanıcılar
4 Gereksinim kısıtlamaları - çözüme ait kısıtlamalar
5 İsimlendirme uzlaşıları ve tanımlar - terimlerin net anlamları
6 İlgili veriler - sistem üzerinde etkisi olan, dış dünyaya ait veriler
7 Varsayımlar - proje ekibinin yaptığı varsayımlar
Fonksiyonel Gereksinimler - sistemin davranışına ait gereksinimler
8 Sistemin kapsamı - sistemin ele aldığı iş olaylarının sınırı ve yan sistemler/aktörler
9 Fonksiyonel ve veri gereksinimleri - sistemin yapması gereken işlevler ve tutması gereken kayıtlar
Fonksiyonel Olmayan Gereksinimler - sistemin davranış dışı özellikleri
10 Görünüm gereksinimleri - amaçlanan görünüm
11 Kullanışlılık gereksinimleri - son kullanıcıların sistemi kullanabilmesi için gereken özellikler
12 Performans gereksinimleri - ne kadar hızlı ve ne kapasitede
13 Operasyonel gereksinimler - sistemin kullanılacağı fiziksel ortamın gerektirdiği özellikler
14 Bakım ve taşınabilirlik gereksinimleri - sistemin ne kadar değişime uygun olduğu
15 Güvenlik gereksinimleri - sistemin güvenliği, gizliliği ve ürettiği verilerin doğruluğu
16 Kültürel ve politik gereksinimler
17 Yasal gereksinimler - kanunlara uygunluk
Diğer Proje Konuları
18 Açık noktalar
19 3. parti çözümler
20 Yeni sorunlar - sistemin işler hale gelmesiyle ortaya çıkacak sorunlar
21 Productiona geçiş için gerekli işler
22 Geçiş süreci - mevcut sistemden geçiş için yapılması gereken işler
23 Riskler - projenin karşılaşması muhtemel riskler
24 Maliyetler - projeyi geliştirme maliyetine dair ilk tahminler
25 Kullanıcı dokümantasyon planı - kullanıcılara yönelik kılavuzları geliştirme planı
26 Bekleyen gereksinimler - gelecek sürümlere eklenebilecek gereksinimler

Yazarlar, bu gereksinimlerin nasıl toplanacağına yönelik çok detaylı bir süreç tarif ediyorlar. Her bir gereksinimin toplanmasında dikkat edilecek noktalara ve yardımcı olacak araçlara değiniyorlar.

Kitapta bahsedilen gereksinim toplamada kullanılan araçlardan biri, yazarların Requirement Shell olarak adlandırdıkları, benim Gereksinim Kartı diye çevirdiğim bir araç. Her gereksinim, ilk akla geldiğinde bu karta yazılıyor. Kartta şu alanlar bulunuyor:

Gereksinim Kartı
Başlık:
Gereksinim No:
Gereksinim Tipi:
Olay/Use Case No:
Açıklama:
Gerekçe:
İlk Bildiren:
Kabul Kriteri:
Müşteri Memnuniyeti:
Müşteri Memnuniyetsizliği:
Bağımlılıklar:
Çatışmalar:
Kaynaklar:
Tarihçe:

Bütün bu alanların gereksinimin ilk kaydedildiği anda doldurulması gerekmiyor. Sadece gereksinimi unutmamak önemli olan. Gereksinimin bağlı olduğu olay ve use case numaralarıyla ilişkileri burada kaydedilerek, bütün gereksinim analizi, iş olaylarının ve use caselerinin etrafında yapılandırılıyor.

Kullanılacak analiz sürecini yazarlar çok kapsamlı olarak tarif ediyorlar. Ben biraz bunu oldukça basitleştirerek kendime göre bir süreç çıkardım. O da şu şekilde:

Analiz Süreci

  • Proje Tanımlama
  • Bilgi Toplama (Her bir use case için tekrarla)
    • Use case yazımı
      • Normal akış
      • Extension points
      • Alternatiflerin yürütülmesi
    • Fonksiyonel olmayan gereksinimler
    • Kabul kriterleri
    • Prototip
    • Gereksinimlerin yazılması
  • Kalite denetimi

Sanırım burada yazdığım başlıklar belki ilk bakışta pek anlamlı görünmeyecektir. Ancak resmin bütününü tek bir blog yazısında göstermek istediğimden detaylara giremiyorum. Umarım ilerideki yazılarımda fırsat buldukça bunların detaylarına girebilirim. Ancak bu arada siz eğer bulabiliyorsanız kitabı okuyabilir veya http://www.volere.co.uk/ adresinden daha detaylı bilgi alabilirsiniz.

Yazının Devamı...