Yazilim Uzmanligi Uzerine

Yazılım Uzmanlığı Üzerine
Standartlaşma, Firma Altyapısı, Ekip Oluşturulması, Blogdan Seçmeler ve UML

ile Proje Geliştirilmesi
Gürkan Yeniçeri
i
Sürüm 0.1 beta
Bu kitap Özgür Yazılım mantığı ile yazılmıştır ve her şekilde dağıtılması serbesttir. Lütfen orjinal formatını
koruyunuz. Orjinal formatı korumasanız da arkanızdan gelip niye böyle yaptınız diyecek değiliz. Bu kitabı
kullanıyorsanız, yazara gurkan nokta yeniceri AT gmail nokta com adresinden ulaşarak bildirirseniz
seviniriz. Gördüğünüz hataları veya istekleri de iletirseniz çok daha mutlu oluruz.
Bu kitap zaman içinde değişikliğe uğrayabilir. Son sürümü için www.analystdeveloper.com adresine
bakabilirsiniz. Blog, Forum ve Vezir Wiki sitelerindeki alıntılar ile bir takım eklentiler ve düzeltmeler,
linkler ile zenginleştirilmiş yazılar rahatça okunabilecek bir formatta buraya toplanmıştır.
ii
Önsöz
Bu e-kitap hem bir projenin nasıl yönetilmesi gerektiğini hemde bir proje grubunun nasıl
yapılanması gerektiğini anlatmaktadır. Modül ve Nesne tabanlı analiz ve geliştirme yöntemlerinin nasıl
bir projede uygulanabiliceğini örnekler ile göstermektedir. Bu kitabı yazmaktaki amacım, bilişim
sektörüne gönül vermiş insanların sınırlama olmadan bilgiye ulaşmalarını sağlamak ve havada kalmış bir
takım konuları bir standarda oturtmaktır. Modül ve Nesne tabanlı sistemler yakın zamana kadar
tartışılan ve standarda sokulmaya çalışılan sistemlerdir ve şu anda dünyanın pek çok yerinde genelde
devlet iştirakleri tarafından olmak üzere pek çok yazılım firması tarafından uygulanmaktadır.
Temeli 1980’lere dayanan UML ve 1996 yılında standarda sokulan Modül Tabanlı Yazılım
Geliştirme kuralları ile birlikte Nesne Tabanlı sistemler hayata geçmeye başladı. Böylece yazılım
dünyasında modülleme yolu ile yazılım geliştirmek hem daha az maliyetli hemde yeniden kullanılabilirliği
arttıran bir sistem olarak rağbet görmeye başladı. Bazı firmalar belirli işleri yapan modülleri hazırlayıp
firmaların beğenisine sundular. Bazı firmalarda hem Nesne Tabanlı hemde Modül Tabanlı yazılım
geliştirme araçları ile piyasaya çıktılar. Kitabın ilerleyen sayfalarında bu firmaların araçlarına yer
vereceğiz. Umarım bu kitap bilişim sektörüne gönül vermiş herkes için bir yol gösterici olur ve herkesin
yararlandığı bir kaynak haline gelir.
iii
Kitap Kimin İçin Yazıldı
Kitap yazılım firması sahiplerinden, yazılım uzmanlarına kadar geniş bir kitleye hitap edecek
biçimde hazırlandı. Yazılım firması sahipleri kendi iç organizelerini düzenleyecek bilgiler bulurken, yazılım
uzmanları Modül ve Nesne tabanlı konular hakkında bilgi sahibi olacaklar. Bir sistem yöneticisi yazılım
ortamlarında nelere dikkat etmesi gerektiğini görecek. Bir test uzmanı nasıl test yapılacağı konusunda
metodolojileri öğrenecek. Bir sistem analisti nasıl analiz yapması gerektiğini öğrenecek. Pazarlama
uzmanları nasıl ürünü pazarlamaları gerektiği konusunda yardımcı bilgiler.
Kitabın bu kadar geniş kitleye hitap etmesinin sebebi bir yazılım firması içindeki yapıyı tam olarak
anlatabilmek ve yazılım firması kurmak isteyen genç girişimcilere birazda olsa yol göstermektir. Kitapta
anlatılan metodlar olduğu gibi kullanılabileceği gibi, gerekliliklere göre ekleme yada çıkartma da
yapılabilir.
Kitabın Organizasyonu
Kitap 4 ana bölümden oluşmaktadır. Bunlar:
1- Yönetim ve Yapılanma
Bu bölümde yazılım firması kurmak İşteyen girişimcilerin nelere dikkat etmesi gerektiğini
anlatmaya çalıştım. Altyapı ve firma düzeninin nasıl olacağı konusunda fikirler verdim. Firma yönetimi ile
ilgili yapısal düzenlemelerin nasıl olacağını analtmaya çalıştım.
2- Proje Ekibinin Oluşturulması
Yazılımı üretecek ekibin yapılanması ve aralarındaki haberleşmenin nasıl olacağı konusunda

ayrıntılı bilgileri burada bulabilirsiniz. Yazılım lideri veya yönetim gruplarında bulunan kişiler yapılanma
ile ilgili fikirleri bu kısımda bulabilirler.
3- Blogdan Seçmeler
Bu bölümde blogda yazdığım ve bu kitabın konuları ile örtüşen yazılara yer verdim. Bu yazıların
Türkçe karakter hatalarını temizledim, linkler ile zenginleştirdim, eski olan bazı yazıları teknolojiye göre
güncelledim.
4- UML ve CBD ile Yazılım Geliştirme

iv
UML ve CBD standartlarının tüm proje genelinde nasıl kullanılacağı ve dosyalanacağı konusunda
bilgiyi örnekleri ile beraber bu kısımdan öğrenebilirsiniz. Yazılım geliştiriciler ve sistem analistler için
hazırlanmış bir bölümdür ve teknik ağırlıklıdır.
Her ne kadar farklı bölümlere ayrılmış olsada, her gruptan insanın kitabın tamamını okumasını
tavsiye ederim. Böylece herkes eşit seviyede bilgiye sahip olmuş olacak ve veri akışı daha hızlı olacaktır.
İÇİNDEKİLER
ÖNSÖZ ........................................................................................................................... 2
KİTAP KİMİN İÇİN YAZILDI .............................................................................................. 3
KİTABIN ORGANİZASYONU ............................................................................................ 3
1 YÖNETİM VE YAPILANMA ........................................................................................ 1
1.1 PROJE ALT YAPISININ HAZIRLANMASI ................................................................................................................................... 1
1.2 İŞ ORTAMI VE SAĞLIKLI ÇALIŞMA......................................................................................................................................... 9
1.3 SONUÇLAR .................................................................................................................................................................... 12
2 PROJE EKİBİNİN OLUŞTURULMASI ......................................................................... 13
2.1 SİSTEM SORUMLUSU ....................................................................................................................................................... 14
2.2 PROJE LİDERİ ................................................................................................................................................................. 14
2.3 ANALİZ EKİBİ ................................................................................................................................................................. 16
2.4 TASARIM EKİBİ............................................................................................................................................................... 17
2.5 YAZILIM EKİBİ ................................................................................................................................................................ 18
2.6 MÜŞTERİ TEMSİLCİSİ ....................................................................................................................................................... 19
2.7 TEST EKİBİ .................................................................................................................................................................... 20
2.8 EĞİTİM EKİBİ ................................................................................................................................................................. 22
2.9 PAZARLAMA EKİBİ .......................................................................................................................................................... 23
2.10 KURULUM YÖNETİMİ EKİBİ ............................................................................................................................................... 24
2.11 DEĞİŞİM VE İSTEKLERİN YÖNETİMİ..................................................................................................................................... 25
2.12 PİLOT FİRMA ................................................................................................................................................................. 25
2.13 ŞEFFAF MUHASEBE ......................................................................................................................................................... 26
2.14 YAPILAN YANLIŞLAR ........................................................................................................................................................ 26
3 BLOGDAN SEÇMELER ............................................................................................. 31
3.1 ÜTOPYALARIM, AŞKIM VE BEN .......................................................................................................................................... 31
3.2 AGİLE MODELLEME DEĞERLERİ ......................................................................................................................................... 35
3.3 DÜŞÜNCELERİM ............................................................................................................................................................. 39
3.4 PROGRAMLAMAYA YENİ BAŞLAYACAKLARA.......................................................................................................................... 41
3.5 EXTREME PROGRAMLAMA ............................................................................................................................................... 46
3.6 YAZILIM UZMANI VE SAĞLIK ............................................................................................................................................. 51
3.7 EKİP TOPLANTILARI ......................................................................................................................................................... 52
3.8 ESKİ PROJELER ............................................................................................................................................................... 57
3.9 CMMI, ISO, SPICE, IEEE .............................................................................................................................................. 64
3.10 SOA VE PROJE ANALİZİ ................................................................................................................................................... 68
3.11 ANALİST YAZILIM UZMANI ............................................................................................................................................... 72
3.12 NASIL DAHA İYİ KOD YAZARIZ ........................................................................................................................................... 76
3.13 EĞER TEST EDİLMEMİŞSE ÇALIŞMIYOR DEMEKTİR ................................................................................................................. 82
3.14 GEREKSİNİM YÖNETİMİ VE KALİTE...................................................................................................................................... 84
3.15 DİĞER GEREKSİNİM YÖNETİMİ YAZISI ................................................................................................................................. 87
3.16 SERBEST YAZILIM............................................................................................................................................................ 89
3.17 REUSİNG VE REFACTORİNG ............................................................................................................................................... 91
3.18 KARİYER OLAYI .............................................................................................................................................................. 93
3.19 İSPANYOL TEORİSİ........................................................................................................................................................... 95
3.20 İŞ BAŞVURUSU VE DİKKAT EDİLECEKLER .............................................................................................................................. 97
3.21 YENİ İŞ KURACAKLARA BİR TEST ........................................................................................................................................ 99
3.22 TESTİN CEVAPLARI ........................................................................................................................................................101
3.23 PROGRAMLAMA ÖĞRENCİSİNİN DERDİ .............................................................................................................................103
3.24 BANA RAKİBİNİ SÖYLE ...................................................................................................................................................106
3.25 YAZILIM UZMANLIĞINDAN YÖNETİCİLİĞE...........................................................................................................................107
3.26 ISVLER İÇİN 25 KURAL ..................................................................................................................................................114
3.27 SÜRÜM YÖNETİMİ ........................................................................................................................................................117
3.28 FİRMANIZI KORUMAK ....................................................................................................................................................120
3.29 YAZILIM VE KİŞİLİK ........................................................................................................................................................124
3.30 YAZILIM SÜRECİNDE KALİTE ............................................................................................................................................126
3.31 YAZILIM UZMANI OLAMAYACAĞINIZIN 10 KANITI ...............................................................................................................130
3.32 STRES VE YAZILIM SEKTÖRÜ............................................................................................................................................133
3.33 YURTDIŞINA YAZILIM ÜRETELİM ......................................................................................................................................135
3.34 BİR BAŞKA GÖZLEM ......................................................................................................................................................142
4 UML VE CBD İLE YAZILIM GELİŞTİRME ................................................................. 145
4.1 İŞ GEREKSİNİMLERİNİ MODELLEME AŞAMASI .....................................................................................................................145
4.2 KULLANICI ARAYÜZÜ GEREKSİNİMLERİ VE TASARIMI BELGESİ ................................................................................................148
4.3 SİSTEM MODELLEME AŞAMASI .......................................................................................................................................149
4.4 PROTOTİPLEME AŞAMASI ...............................................................................................................................................153
4.5 ÖRNEK PROJE İLE OO VE UML .......................................................................................................................................153
Yönetim Ve Yapılanma 1
1 Yönetim Ve Yapılanma
Kural koymak çok kolaydır ama gelin görün ki bu kurallara herkesin özveri ile uyduğunu
düşünmek saçma olur. Koyulan kuralların belli yöntemler ile kontrolü ve raporlanması gerekir. Yönetimin
yapması gereken iş sadece kural koymak değil, bu kuralların yerine getirilip getirilmediğini kontrol
edecek mekanizmalarıda işleme sokmaktır. Bu bölümde bir yazılım firmasındaki alt yapıyı inceleyeceğiz.
Firma bölümleri arasındaki veri akışının nasıl verimli hale getirileceğini araştıracağız.
1.1 Proje Alt Yapısının Hazırlanması
Bir firmanın değeri çalışanlarına verdiği değer ile doğru orantılıdır.

Alt yapısına ve çalışanlarına yatırım yapmak yerine zevki için para harcayan
firmalar ise kısa vadeli firmalar olmaktan kurtulamazlar. Günlük çözümler
ile hayatını sürdüren bir firma günün birinde mutlaka batar. İleriyi görerek
yatırım yapanlar ise daha uzun piyasada kalacaklardır. Her firmanın bir
sonu vardır. Fakat unutmayın ki bu sonlardan yeni kaynaklar üretmek ve
yeni yatırım sahaları yaratmak tamamen akıl gücünüze kalmış bir olaydır.
1.1.1 Bilgisayarlar
Bir işe başlarken yapılan yatırım özkaynaklarınızı arttırır. Bu açıdan düşünüldüğünde, alınacak
her bilgisayar, kurulacak her sistem, cekilecek her kablo özkaynaklarınıza dahil olacaktır. Günümüzde
bilgisayar sistemleri çok çabuk güncel-dışı kaldığından bilgisayar alırken dikkat edeceğiniz husus,
güncelleme seçeneklerinin açık olması veya aldığınız firma ile yapacağınız anlaşmada, belirli periyodlarda
sistemlerin yenilenmesi gibi maddelerin olmasına dikkat etmenizdir. Böylece elinizdeki bilgisayar sistemi
zaman içerisinde eskimemiş olacak, verimliliğiniz düşmemiş olacaktır. Bilgisayar aldığınız firmanın köklü
bir firma olmasına dikkat edin. Referanslarını görmek isteyin. Dikkat edeceğimiz hususları maddeler
şeklinde sıralarsak:
 Bilgisayarların tamamı yetkili bir firmadan alınmalıdır.

 Tüm özelliklerin her bilgisayarda aynı olmasına dikkat edilmelidir.
 6 ay veya 1 senelik periyodlarda güncelleme için anlaşılması gerekir.
 Sistemler tamamen değişecek ise eskileri geri alma gibi maddelerde olmalıdır.
 Hasar veya fabrika hataları gibi arızalar sigorta kapsamında olmalıdır ve bilgisayar firması
bu bilgisayarları değiştirmelidir.
 Her kullanıcının kendi bilgisayarı hakkındaki özellikleri bilmesi ve en verimli biçimde

kullanabilmesi için bilgilendirilmelidir.
 Hangi bilgisayarın hangi masada durduğu ve kimin tarafından kullanıldığı kayıt edilmelidir.
 Monitörlerin gözü bozmayacak türden olması gerekir. Yansımayı azaltan ekran filtreleri
kullanarak çalışanların gözlerinin korunması gerekir.
1.1.2 Ağ Yapısı
Firmanız içerisindeki ağ yapısı kurulurken, uzun vadeli bir yatırımmış gibi düşünüp, o sırada
piyasada bulunan en iyi kabloların ve uçların kullanılmasına dikkat edin. Ağ alt yapısı bir daha
değişmeyeceği için, en son sistem ağ yapılarınıda kullanmayı düşünebilirsiniz. Fiber optik, kablosuz yada
100mb CAT5 veya 1Gb CAT6 gibi teknolojileri inceleyip en iyisinin hangisi olacağına karar verebilirsiniz.
Sistemin sağlığı açısından, bilgisayarların yerleştirilme planlarının iyi yapılması gerekir, böylece koblo
uçlarındaki bağlayıcılar zarar görmemiş olacak ve ileride ek bir masraf çıkartmayacaktır. Güvenlik
konularına da dikkat edilmesi gerekir, kabloların bina içinde kontrolü olmayan yerlere gitmesi yada
kablosuz ağ yapınızın 15 yaşında bir bilgisayar kurdu tarafından “hack” edilmesi pek hoş olmasa gerek.
Bu nedenle çekilen her kablonun kağıt üzerinde bir modelinin olmasına özen gösterin. Bu modelleri iyi
saklayıp ileride çıkacak problemleri hızlı bir biçimde çözmek için kullanabilirsiniz. Önceden planlama ile
kaç metre kablo harcanacağını tahmin edebilir ve maliyetlerinizi kontrol altına alabilirsiniz. Bir kaç
madde halinde sıralarsak:
 Önceden plan yapılarak kabloların nerelerden geçeceği tesbit edilir.

 Masaların düzeni ve yerleşim planı ile birleştirilerek ne kadar kablo harcanacağı ortaya
çıkarılır.
 Her kablo etiketlenmeli ve hangi masaya hangi kablo gidiyor kaydı tutulmalıdır.
 Arıza arama ve giderme için kablo test cihazları bulunmalıdır.
 Yedek kablo, uçları ve kablo pensesi her zaman bulundurulmalıdır.
 Yedek “hub” ve benzeri ekipman her zaman bulundurulmalıdır.
 Kablolamayı yapacak firma konusunda uzman olmalıdır.
Kablolama işini Sistem Yöneticilerine yaptırmayın. Eğer bu konuda uzman bir firma
seçecekseniz, alanında iyi olan ve bir kaç referansı olan bir firma seçin. Ağınızda çıkacak herhangi bir
arıza içinde bu firmadan yardım isteyin. Böylece Sistem Yöneticisinin zamanı bu tür işlerle bölünmemiş
olur. Eğer profesyonel düşünce sistemi ile hareket edersek ve profesyonel firmalar ile çalışırsak ileride
doğacak pek çok problemi daha oluşmadan ortadan kaldırmış oluruz. Maliyetleri kısmak için tüm bu
işleri firma içindeki kaynaklar ile çözmeye çalışırsanız ileride doğacak arızalarda çok fazla zaman ve nakit
kaybedebilirsiniz.
Prensip olarak yapılacak her iş için o işle uğraşan profesyonel bir firma seçmenizi tavsiye
ederim. Pek çok yararını göreceksiniz. Öncelikle, belki sizin hiç aklınıza gelmeyecek alternatif çözümler
üretebilirler. Belki de sizin hesapladığınızdan daha az bir harcama ile bu işten kurtulabilirsiniz. Yarın
sorun çıktığında arayacak birileri olacaktır. Ve en önemlisi de güncelleme için başınız ağrımayacaktır.
Tabii tüm bu saydıklarımın imzaladığınız anlaşmada olması gerekmektedir.
1.1.3 İşletim Sistemleri
Yazılım sürecinde kullanılacak işletim sistemlerini ikiye ayırabiliriz. Birincisi ürünü geliştirdiğiniz
ortamlar, diğeri ise ürünü kurup çalıştırdığınız ortamlar yada test ortamları da diyebiliriz. Fiziksel olarak
birbirinden ayrı sistemler olması gerekmektedir. İşletim sistemi için güncelleme ve yeni sürümler, test
ortamında denenebilir. Böylece yazılım ortamı sabit durur. Tüm testler yapıldıktan sonra, “disc image”
programları ile bir kopya oluşturulur ve ürün geliştirme ortamındaki bilgisayarlar güncellenir. “disc
image” programları kullanmaya karar verirseniz, firmanızdaki her bilgisayarın eşit özelliklere sahip olması
gerekir. Ürününüz hangi işletim sistemlerini destekliyorsa o sistemlerin yeni versiyonlarını takip etmek
ve sağlayıcı firma tarafından artık desteklenmeyen sistemleri devre dışı bırakmak gerekir.
Linux gibi açık sistemler kullanıyorsanız, her yeni kernel (Linux çekirdeği) çıktığında veya
desteklediğiniz Linux sürümü yeni sürüme geçtiğinde ürününüzü derleyerek yeni paketler
oluşturmalısınız.
Sanallaştırma ile maliyetleri bir miktar düşürmek te mümkündür. Eğer sanallaştırma

kullanılacaksa gerekli donanımın ihtiyaca göre planlanıp alınması ve gelecekte ihtiyaç olabilecek
yükseltmelerin kolayca uygulanabilmesi gerekir.
Bir de yedekleme stratejilerinin çok iyi uygulanması ve sistemlerin, yazılan kodun,

veritabanlarının ve üretilen her türlü belge ve çıktının yedeklenmesine özen gösterilmesi gerekiyor. Yılda
en az bir kere yedeklerden geriye dönüş tatbikatı yapın. İşlerin yoğun olmadığı bir zamanda yedeği
bulunan tüm sistemleri silin, formatlayın yada kullanılamayacak hale getirin. Aldığınız yedekleri
kullanarak firmayı tekrar ayağa kaldırmaya çalışın. Uygulanması çok zor bir tatbikat gibi görünse de “eğer
başarılı olursanız” bu tatbikatı hiç yapmamış firmalara göre bir üstünlüğünüz olacaktır. Tatbikat sonunda
yedekleme ve bu yedekleri saklama metodlarınızı gözden geçirin ve eğer aksayan yönleri varsa düzeltin.
1.1.4 Yazılım Araçları
İşte hayatınızı, ve firmanızın geleceğini belirleyecek en önemli karara geldik. Seçeceğiniz

programlama dili yada aracı zaman içerisinde kaybolup gitmeyecek ve yeni teknoloji ve teknikleri
uygulayabilir bir dil olmalı. Üzerinde en fazla zaman harcayacağınız, karar verirken en fazla
düşüneceğiniz, en fazla araştırma yapacağınız kısım bu olmalı. Karar verme aşamalarına bir bakalım:
 Ürününüzü birden fazla İşletim sistemini destekleyecek mi?

 Ürününüzü web, istemci/sunucu, tek başına calışabilecek biçimde tasarım edilecek
mi?
 Ürününüz en son yazılım tekniklerini ve teknolojilerini uygulayabilir mi?
 Kullanmayı düşündüğünüz veritabanlarını destekliyor mu?
 Piyasadaki yazılım uzmanları, sizin kullanmayı düşündüğünüz yazılım aracını
biliyorlar mı?
 Yazılım aracı/dili için eğitim verecek kuruluş var mı? Diploma, sertifika veriliyor
mu?
 Dünyada başka kimler kullanıyor? örütbağında arama yaptığınızda kaç tane sonuç
dönüyor?
 İş bulma sitelerinde, sizin düşündügünüz yazılım aracı/dili ile ilgili ne kadar iş ilanı
var.
 Ürününüzü Dünya genelinde satmayı düşünüyor musunuz? Araç/dil bu tasarıma
izin veriyor mu?
 Yazılım aracı/dili üreten firma ile birlikte başka hangi firmalar bu araca/dile destek
veriyor.
 Ne kadar para harcamayı düşünüyorsunuz?
Birden fazla yazılım aracıda düşünebilirsiniz. Veya farklı firmaların ürünlerinden bir sentez de
ortaya çıkabilir. Örneğin, veritabanını Oracle’dan, işletim sistemlerini Microsoft ve Hewlet Packard’dan,
yazılım araçlarının bir kısmını Computer Associates’den, bir kısmını Microsoft’tan, analiz araçlarını
Rational Software’den, Application Server’ları BEA’den, Web sunucuları Microsoft ve Apache’den,
Middleware yazılımlarını IBM’den alabilirsiniz. Kendi alanında lider konumunda bulunan ürünleri
toplamak iyi bir fikir gibi gelebilir. Tek dikkat etmeniz gereken şey satış sonrası desteğin ne kadar iyi
olduğudur. Müşteriniz sancıdan kıvranırken size kolayca ve hızlı çözüm sunabilecekler mi?
Firmanızı kurduktan sonra ilk 2 yıl sizin için bir tampon zaman olacaktır. Bu zaman içerisinde
belirli araçları/dilleri/teknolojileri deneyerek görmeniz, satış sonrası destek olaylarını araştırmanız sizin
için iyi olacaktır. Firma kuruluşu sırasında, dile ve kullanacağınız araçlara karar vermiş bile olsanız, ilk 2
yıl yeni arayışlar içerisinde olmaya bakın. Sizin istediğiniz işleri daha ucuza yapan ceşit ceşit yazılım
geliştirme araçları, veya satış sonrası desteği daha iyi olan başka bir firma bulursanız alt yapınızı
değiştirmekten korkmayın. Unutmayınki burada 10 yıl içinde piyasadan silinecek bir firmadan
bahsetmiyoruz. Kuracağınız firmanın köklü olabilmesi için, ürününüzün ve teknolojinizin de güncel ve
köklü olması gerekir.
Hangi ürünleri seçerseniz seçin başarılı olmak için standartlaştırma ve dosyalama kuralları her
zaman güncel ve uygulanabilir olmalı, her çalışan bu kurallara uyarak yazılım geliştirme yapmalıdır. Belli
kurallara uymadan yapılan işler zaman içerisinde yok olup giderler. Hangi dilde yazılırsa yazılsın bir
program müşterinin isteklerine cevap vermelidir, bence en önemli koşul budur.
1.1.5 Ek Yazılımlar
Ek yazılımlar, firma içerisinde ve yazılım geliştirme sürecinde işleri kolaylaştıracak, kendi

bünyenizde yazılmış yada dışarıdan satın aldığınız ürünler olacaktır. Ceşitli metin editörleri, sıkıştırma
araçları, müzik dinleme programları, sohbet yazılımları ve yazılım geliştirme ile doğrudan bağlantılı
olmayan her türlü program bu kategoriye girer. Dışarıdan alınan ek yazılımların güvenlik açıkları var mı,
kullandığınız sistemler ile uyumlu çalışıyor mu, işinizi yüzde kaç kolaylaştırıyor, güncelleme nasıl yapılıyor
gibi konular takip edilmesi ve yazılması gereken konulardır. Her türlü ek yazılımın firma içinde nasıl
kullanıldığı, hangi bilgisayarlarda yüklü olduğu, kimlerin ne kadar kullandığı gibi bilgilerin güncel bir
biçimde tutulması gerekir.
1.1.6 Dışarıdan Alınmış Modüller
Modül tabanlı geliştirme yapıyorsanız, piyasada hazır bulunan müdülleri kendi ürünlerinize
entegre edebilirsiniz. Bu bağlamda oluşturulmuş, kredi kartı doğrulama, kullanıcı adres bilgileri, güvenlik,
audit (veritabanında hangi kullanıcı ne iş yapmış), veritabanı bağlantıları gibi bir dizi hazır modülü alıp
kullanabilirsiniz. Hem zamandan hem iş gücünden kazanmış olursunuz. Tabii bu modüllerin bakım ve
desteği için belirleyeceğiniz kişilerin yeterli eğitimi almasına dikkat edilmelidir.
1.1.7 Analiz Yazılımları
Projelerinizin analiz aşamasında harcayacağınız zaman daha çok olacağından, bu bölümde

yapılan her işin kayıtlı olması çok büyük önem taşımaktadır. Tutulan kayıtların da belli bir format
içerisinde olması, ve firmanın her bölümünde okunduğunda, rahatça anlaşılabiliyor olması gerekir. Firma
içerisinde bu iş için belli bir kültür oluşturmalı, belge şablonları geliştirmeli, metodolojiler ile ilgili genel
bilgileri herkesin ulaşabileceği bir yerde tutmalı, genel bazı eğitimleri tüm firma çalışanlarının almasını
sağlamanız gerekir. Analiz için belli başlı araçlar, Rational ürünleri veya örütbağ üzerinde bulacağınız bazı
ücretsiz yazılımlarda işinizi görebilir. Önemli olan belli bir standardı oturtmaktır. Analiz bölümünde
standartla ilgili bir kaç şablon bulacaksınız. Herhangi bir ürün almasanız bile veya sadece Microsoft Office
kullansanız bile, tüm bu işin belli bir düzen içinde yapılması gerekir.
UML veya OO analiz metodolojilerini kullanacaksanız kullanacağınız yazılım diline ek olarak, bu

dil ile uyumlu bir UML modelleme aracına bakmanız gerekir. Örneğin IBM Visual Age ile Java dilinde
yazmaya karar verirseniz IBM-Rational’ın Rose aracını UML modellemede kullanabilirsiniz. UML
modellerinin hayat süreci ürün ortaya çıkana kadardır. Modelleri, hayata geçirildikten ve kodlandıktan
sonra tutup tutmamak size kalmıştır. Sınıf şemaları dışındaki diğer tüm UML şemalarını ürün ortaya
çıktıktan sonra ortadan kaldırabilirsiniz. Tamamı ile silmek yerine arşivleyerek saklamak daha iyi olabilir.
Tüm modelleme boyunca rafine edilerek geliştirilen UML modelleri yeni fikirlerin ortaya çıkması ve
risklerin tanımlanabilmesi için geçerlidir. Tüm sorular cevaplanıp sınıf şemaları ve veritabanı tabloları
ortaya çıktıktan sonra artık yazılan kod kendini ifade etmelidir. Ürün ortaya çıktıktan sonra elimizde
sadece Senaryo belgeleri ve kod kalmalıdır. Testler sırasında bu senaryo belgelerine göre tüm modüller
bir arada test edilir.
1.1.8 Hata Denetleme Ve Atama Yazılımları
Proje analizi aşamasında yazılacak modüller az çok ortaya çıkar. Bu işlerin yazılım ekibindeki
kişilere atanması ve sürecin takip edilmesi gerekir. Ayrıca ürün yazılmaya başlandıktan sonra, çıkacak
hataların kayıt edileceği ve gene yazılım ekibine atanması gibi işleri otomatize edecek araçlara ihtiyaç
vardır. Proje gerekliliklerine göre bu araçları kendiniz de yazabilirsiniz. Piyasada bu iş için yazılmış araçlar
da mevcuttur. Dikkat etmeniz gereken kullanacağınız hata denetleme ve atama yazılımının örütbağı
üzerinden erişilebilmesi ve müşterilerinize açık olmasıdır. Kullacağınız aracın yapısına biraz bakalım:
 Farklı projeler yaratıp modülleri belirleyebilmelisiniz.

 Her proje ve modül için sorumlu atayabilmelisiniz.
 Kaydedilen hatalar veya istekler atanan kişiye e-mektup yolu ile
ulaşmalıdır.
 Farklı projeden modülleri bir diğer projede kullanabilmeli ve o modül için

ikinci bir sorumlu atayabilmelisiniz.
 Yapılan işin belgelerine linkler olmalı yada direk program içinde
saklanmalıdır.
 “Her proje ve modül için yüzde kaç ilerleme var” şeklinde raporlar
alabilmelisiniz.
 Bitirme zamanları ve yazılım uzmanlarının üzerindeki işler gibi raporları
alabilmelisiniz.
 Hata veya istekler zorluk derecelerine göre sıralı listelenebilmelidir.
 Her proje elemanının ne kadar iş yaptığı görülebilmelidir.
1.1.9 Dizin Yapısı
Projenin sayısal dosyalaması için dizin yapısı oluşturmak, üretilen her türlü belgeyi burada
muhafaza altında tutmanız ve gerektiğinde yedeklerinin alınması için gereklidir. Her projenin
gereklilikleri farklı olduğu için dizin yapılarıda türlü farklılıklar gösterebilir. Kitap ile gelen tıkızda proje
dizinlerini otomatik olarak yaratan küçük bir programcığa rastlayacaksınız. Bu araç ile proje ismini ve iki
karakterden oluşan kodunu verdiğiniz zaman size temel sayılabilecek bir dizin yapısı oluşturmaktadır.
Ayrıca her proje için geçerli olabilecek bir dizi belgeyide otomatik olarak yaratmaktadır. Bundan sonra
yapacağınız iş adım adım giderek gereklilikleri doldurmaktır.
1.1.10 Programlar Ve Sorumluları
Programları satan firmalardan kontak kişiler, yardım alma biçimleri, yeni versiyonlar ve
yamaların uygulanması. Aldığınız programları firma içerisinde kullananlardan seçilecek kişiler program ile
ilgili her türlü gelişmeyi takip edecek. Fiyat teklifleri, anlaşmalar ve ürünlerin ulaştırılması konularını
organize edeceklerdir. Ürünler firmanıza ulaştıktan sonra, kurulum, test, fiyat, yarar ve zararları
konularında bir belge hazırlayıp, firma yöneticilerine ve ürünü kullanması beklenen kişilere gönderir.
Geriye dönecek yorumlara göre bir toplantı yapılarak sonuçlar tartışılır ve ürünün/yamanın kullanılıp
kullanılmayacağına karar verilir.
1.1.11 Ürünün Dağıtımı
Proje ekibinin ürettiği ürünü piyasaya sürmek için kullanacağınız kurulum geliştirme programları
bir kaç platformu birden desteklemelidir. Tıkız, disket, örütbağ yada iç-örütbağ üzerinden kurulum
yapmaya imkan verecek araçlar kullanmalısınız. Ürününüzü dağıtma mekanizmalarınız ne kadar geniş
olursa hitap edeceğiniz kitle o kadar geniş olur. Ayrıca zaman içerisinde üründe gelişmeler oldukça
ortaya çıkacak yamalarında bir şekilde kullanıcılara ulaştırılması gerekiyor. Bu yamaların uygulama
metodları mümkün olduğu kadar kullanıcıyı yormayacak biçimde olmalıdır.
1.1.12 Merkezi Çalışma Yöntemleri
Proje süreci içinde üretilen her belge ve kod, merkezi sunucularda bulunmalıdır. Paylaşım
programları ile her proje elemanının bu sunucuya erişip koordineli olarak çalışmasını sağlayacak
araçlarıda bünyenizde barındırmanız gerekir. Kullandığınız programlama aracına göre kod sürüm takibi
ve paylaşımlı çalışma araçlarını araştırın. Bu sayede her proje elemanı diğer tüm ekiplerin neler
yaptığından haberdar olur. Bir yazılım firmasında takip edilmesi gereken üç ana unsur:
1. Belge yönetimi ve sürüm takibi
2. Kod yönetimi ve sürüm takibi
3. Ürününüzün yönetimi ve sürüm takibi
Firma içinde analiz aşamalarında üretilecek her belgenin yeri, kim tarafından üretildiği, hangi
versiyonlarda ne gibi değişikliklerin yapıldığını yönetmeniz gerekir. Bunun için çeşitli yazılımlar
geliştirilmiştir. Lotus Domino.Doc gibi yazılımlar veya bir istemci/sunucu şeklinde Miscrosoft’un Share
Point Portal ve Share Point Team Services sunucu sistemlerini kullanabilirsiniz.
Yazılım uzmanları tarafından yazılan kodun merkezi bir sunucuda bulunması ve yazılım
uzmanlarının çalışacakları kısımları belirleyerek sunucudan bu kısımları kendi çalışma ortamlarına
indirmeleri ve işin bitiminde tekrar sunucuyu değişikliklerle güncelleyerek derlemeye hazır hale
getirmelerini organize edecek araçlara da ihtiyaç vardır. Bir kaç örnek vermek gerekirse Microsoft’un
Visual Source Safe, IBM Rational’ın Clear Case, Borland’ın StarTeam gibi yazılımları bu işi yaparlar. Eğer
coğrafik olarak yayılmış bir ekibiniz varsa veya evlerinden çalışan yazılım uzmanları ile çalışıyorsanız,
örütbağı üzerinden de aynı işlemleri gerçekleştirebileceğiniz araçlara yönelmeniz gerekir.
Ürünün derlenmesi ve son haline getirilmesi ile sürüm yönetimi konuları da bu sunucular
üzerinden yapılabilir. Böylece programcılar işlerine devam ederken bir yandan da ürün derlenerek
zaman kazanılmış olur.
1.2 İş Ortamı Ve Sağlıklı Çalışma
1.2.1 Masalar Ve Bilgisayarlar
Masa başında çalışan herkes türlü rahatsızlıklar yaşamaktadır. Fare tutan elin parmaklarında
ağrı ve bilek bölgesinde Tünel Kalpal rahatsızlığı, omuzlarda kasılma, boyun bölgesinde tutulma, sırt
ağrıları, omurgada kayma, göz bozukluğu gibi pek çok rahatsızlık masa başında yanlış oturmak ve belirli
kaidelere uymamaktan dolayı kaynaklanmaktadır.
Ofis için seçilecek masaların yüksekliklerinin ayarlanabilir olması gerekir. Böylece her çalışana
göre masa yüksekliğinin ayarlanması sağlanır.
Kullanılacak koltuk yada sandalyelerin iyi bir sırt desteği olmalı, sandalye yüksekliği, sırt desteği
yüksekliği, yere olan açısı ayarlanabilir olmalıdır.
Kullanılan monitörlerin yüksekliği ve açısı ayarlanabilir kaideler üzerinde durması sağlanmalıdır.

Monitörlerde filtre olması ve bu filtrelerin topraklanması gerekir. Ayrıca monitör başında uzun saatler
geçiren kişiler senede bir kez göz muayenesinden geçirilmeli ve gerekiyorsa dinlendirici gözlükler
kullanılmalıdır.
Masa başı çalışanları için kitap ile birlikte gelen tıkızda masa başında nasıl oturulması gerektiği
anlatılmıştır. Monitörün konumu, klavyenin konumu, gerekli açılar ayrıntılı olarak gösterilmiştir.
Her masaya ait en az 1 adet kilitli çekmece olması gerekir. Böylece mesai bitimi sonunda güvenli
bir yerde saklanması gereken dosyalar muhafaza altına alınmış olur.
Bilgisayarlar 24 saat açık bırakılabilir, sistem oturumunu kapatıp monitörü de kapadıktan sonra
enerji harcaması en aza indirilmiş olur. 24 saat çalışan bilgisayar nem tutmaz ve ömrü daha uzun olur.
Bilgisayar alırken fanlarından çıkan sesin mümkün olduğu kadar az olmasına dikkat etmek gerekir. 30
tane bilgisayarın fan uğultusu oldukça fazla olmaktadır. Yılda bir kez fanların ve kasaların hava üfleyen
elektrik süpürgeleri ile temizlenmesi gerekir.
Pazarlama ekibi ve yazılım ekibi aynı oda içerisinde bulunmamalı, yazılım ekibi için mümkün
olduğu kadar sessiz ve sakin bir ortam yaratılmalıdır. Yazılım ekibinin odasında ses yankılanmalarını
önlemek için duvarlara gözleri dinlendirici resimler asılabilir. Klasik müzik yada dinlendirici tür müzikler
yayınlanabilir. Dahada ileri gidersek duvarlara ses yalıtımı bile düşünülebilir. Bir kayıt stüdyosunda
konuştuğunuz zaman kendi sesiniz hiç bir bozuntuya uğramadan ve yankılanmadan kulağınıza gelir. Bu
tür bir ortamda yazılım yapmak, odaklanmak ve konsantre olmak için idealdir. Hem hafta sonları ekibin
enstrüman çalanları stüdyo olarakta kullanabilir.
1.2.2 Telefonlar
Telefonlar firmanın durumuna göre şehirler arası yada milletler arası kapalı olabilir. En az bir
adet serbest kullanıma açık fax cihazı olmalıdır yada tamamen sayısal bir fax sunucusuda
kullanabilirsiniz. Yapılan telefon görüşmelerini kontrol edip milletler arası yada şehirler arası özel
konuşmaları maaşlardan düşebilirsiniz. Cep telefonları için özel hatlar kurup ucuza aranmalarını
sağlayabilirsiniz. Her masada bir hat olması en idealidir. Dışarıdan arayanlar sekreter hanımın işini
bölmeden istedikleri kişiye ulaşabilirler. Müşteriler yetkili kişilere doğrudan ulaşabilirler. Masalardaki
telefon hatlarına gizli modemler bağlanmış mı arada bir kontrol etmek gerekir. Bazı çalışanlar kendi özel
modemleri ile internete çıkmak isteyebilir. Ayrıca firma bilgisi dışında bağlanmış bu modemler sisteminizi
tehdit edebilir. Dışarıdan gelecek saldırılara karşı açık bir kapı gibi olacaktır. Yazılım uzmanlarının telefon
numaraları müşterilere verilmemelidir.
1.2.3 Işıklandırma
Genelde bilgisayar ve yazılım firmalarında beyaz floresan kullanılır. Fakat bu floresanların

sayılarının her zaman çift olmasına dikkat edilmesi gerekir. Masalarda akrobat masa lambaları
kullanmakta faydalı olabilir. Işıklandırma ekranlardan yansımayacak biçimde yerleştirilmelidir. Ayrıca
pencerelerden gelen ışığın da ekranlara direk gelmemesine dikkat edilmelidir.
1.2.4 Havalandırma
Çalışma ortamı konsantrasyonu bozacak her türlü kokudan arındırılmış olmalıdır. Yakınlardaki
restoranın yemek kokuları, havalandırma cihazlarının kokuları gibi havanın kalitesini bozacak her türlü
koku arındırılmalıdır. Havalandırma cihazlarından çıkan soğuk havanın direk kişiler üzerine gelmemesi
için ayarlamalar yapılır. Havalandırma cihazlarında biyonik filtreler kullanılmalıdır. Nem oranı kontrol
altında tutulmalıdır.
1.2.5 Proje Ortamının Güvenliği
Bilgisayarların tıkız ve disket sürücüleri olmamalı. Sunucular bir odada kilit altında tutulmalı. E-
mektup trafiği denetlenmelidir. Eğer tıkız ve disket sürücüler kullanılacaksa çok iyi bir virüs tarama
programı kurulmalı ve her virüs veritabanı güncellemesi çıktığında güncellenmelidir. E-mektup için kota
uygulaması kullanılabilir.
Yangın söndürme cihazları ve alarmları her hafta bir kez kontrol edilmelidir. Ekiplerden birer kişi
yangın durumları için yetkili atanarak yangın çıkışları ve metodları hakkında bilgilendirilmelidir. Ayda bir
kez yangın tatbikatı yapılarak personelin yangın çıkışlarını nasıl kullanacağı ve hangi kurallara uyması
gerektiği uygulamalı olarak öğretilmelidir. Deprem gibi afetler içinde tatbikat yapılmalı ve binanın
güvenli yerleri, hayat üçgenleri belirlenmeli ve buralara tabelalar asılarak herkesin öğrenmesi
sağlanmalıdır. Yangın tatbikatı için yetkili bir kurumdan yardım almak gerekebilir.
Ofis içinde seçilecek kişiler ilk yardım eğitimi almalı ve bu bilgilerini ihtiyaç halinde
kullanabilmek için hazırlıklı olmalıdırlar.
1.2.6 Diğer
Çalışanların ayrım yapılmadan yılda bir kez, kış aylarına girerken grip aşısı yapılması, hem
firmanız hemde çalışanlarınız için iyi olur. Bir kişiden yayılacak grip virüsü tüm projenizi 1 hafta geriye
atabilir. Bu tür riskleri almak istemiyorsanız grip aşısını göz önünde bulundurmanızı tavsiye ederim. Grip
aşısı isteğe bağlı olmalı, aşı olmak istemeyen personel serbest bırakılmalıdır.
Sigara binanın hiç bir yerinde içilmemelidir. Dinlenme odaları da dahil olmak üzere hiç bir yerde
sigaraya izin verilmemelidir. Sigara içmek isteyenlere nikotin bantları verilebilir. Sigara içenleri işe
almamak bile düşünülebilir.
Mutfak bölümünde buzdolabı, mikro dalga fırın, sıcak su veya çay kahve makineleri ve evden
yemek getirenler için bir masa bulunmalıdır. Mutfağın temizliği, her hafta bir profesyonel temizlik
uzmanına yaptırılmalı ve personelin mutfağı temiz tutması için gerekli önlemlerin alınması gerekir.
Binanın uygun bir odasına koşu bandı, egzersiz bisikleti gibi aletler koyarak çalışanları fiziksel
egzersiz yapmaya teşvik edebilirsiniz. Tabii duş ve değişme odalarını da unutmayın. Bu sayede
motivasyonu arttırmış olursunuz. Sanat ile uğraşan personel için çeşitli çalışma odaları sağlayabilir ve
buralardan çıkacak sanat eserlerinin açık arttırma günleri ile satarak vakıflara yada derneklere yardım
sağlayabilirsiniz. İlk okul, lise veya çevrenizdeki yardıma muhtaç çocuklar veya aileler ile ilgili bu tür
çalışmalar firmanızın ismini medyada duyurmanıza yardımcı olur. Ek olarak ürününüzü üniversitelere
veya liselere ücretsiz vererek gençlerin öğrenmesini sağlayabilirsiniz.
Makinelerden arındırılmış sessiz bir oda yapılacak klasik müzik yayını ile mükemmel bir
dinlenme odasına çevrilebilir. Dinlenme odaları günün problemlerini unutarak, aklı temizlemek ve iş
problemleri ile savaşacak gücü tekrar toplamak için idealdir.
Haftalık çalışma saatinin %20’si araştırma ve geliştirmeye ayrılabilir. Bu sayede çalışanların

motivasyonu artar ve ürün geliştirme bölümünden yeni fikirler elde edilebilir.
1.3 Sonuçlar
Bir firma kurulumu sırasında dikkat edilmesi gerekenleri sıraladık. Burada yapmanız gereken
firmanızın her birimini bir modül olarak ele alıp geliştirmek ve modüller arası ilişkileri çok iyi bir biçimde
tanımlamaktır. Ancak bu şekilde başarılı bir çalışma hayatı çizebilirsiniz. Her modül için bir yönetici
atayın. Bu yönetici kendi modülünün arayüzü olacaktır yani dış dünya ile bağlantı kapısı. Eğer başka bir
modülün yöneticisi diğer bir modüldeki kaynakları (insan gücü, makine, bilgi vb.) kullanmak isterse bu
isteğini o modülün yöneticisine bildirir. Ve böylece arada bir ilişki başlar ve kaynaklar en verimli biçimde
kullanılmak üzere yönlendirilir.
13 Proje Ekibinin Oluşturulması
Bir proje ekibinin birbirini tanıması için en azından 2 ay birlikte geçirmeleri gerekir. Bu 2 ay
zarfında her kes birbirinin psikolojik yapısını, ailesini, yaşam tarzını, değerlerini, önem verdiği şeyleri,
dinlediği müzik türünü, çaldığı enstrümanı, ne kadar bilgisayar bilgisi olduğunu öğrenmelidir. Bu liste
oldukça fazla uzatılabilir. İlk aşamada proje ekibi için iç-örütbağ üzerinde bir web sitesi hazırlayıp, temel
olarak özgeçmiş bilgilerinden başlayıp yayınlamak iyi bir fikir olabilir. Böylece ekip içerisinde kim ne
kadar, ne biliyor, daha önce nerelerde calışmış gibi bilgiler herkese ulaşır. Daha sonra proje ekibinin
görevlerini ve bu görevlerin kimler tarafından üstlenildiğini belirten bilgilerde yer almalıdır. Ekibe verilen
sorumluluklar yerine getirilmeye başlandıkça bu bilgiler güncellenir ve herkesin ne kadar iş yaptığı da
gözler önüne serilir. Sanırım oldukça şeffaf bir yöntem oldu bu ama birbirimizden saklayacak neyimiz
olacak ki. Ekip ilişkilerini geliştirecek bir kaç aktiviteden burada bahsetmek istiyorum.
a. Sabah çayı: Her ekip ayda bir defa içlerinden seçecekleri 3 kişinin hazırlayacağı bir sofra ile 2
saat sürecek bir sabah çayı düzenleyebilir. Yiyecekler için para tüm ekipten toplanır. Bu sofrada genelde
kahvaltı amaçlı yiyecekler bulunur ve sofra akşam iş çıkışına kadar ortada durur. Herkes kendi bardağı ve
çayı ile katılır. Ekip içindeki ilişkileri arttırmak ve iş dışında başka konuları konuşmak için ortam
oluşturmalıdır. Gün sonunda sofrayı kuran kaldırır.
b. Genel sabah çayı: Gene aynı formatta bu sefer firma genelinde düzenlenir. Firmaya yeni
katılan insanlar takdim edilir, yeni başlayan projelerden, başarılan işlerden, başarılması gereken
hedeflerden bahsedilir. Sunumlar hazırlanarak firma genelindeki bilgi paylaşımının en üst seviyeye
çıkarılması sağlanır.
c. Bazı yarışmalar açıp kazananlara ödül verilebilir. Verilen ödüllerin ve yarışmaların gene
yapılan işle alakalı olması gerekir.
d. Son teknolojilerin tartışıldığı bir ortamda hazırlanmalıdır. Bir araştırma geliştirme laboratuarı
bu amaç için uygun olabilir.
e. Bir aktivite kulübü oluşturarak firma içinde düzenlenecek yemek, piknik, mangal partileri gibi
olayları organize etmek te iyi bir fikir olabilir.
f. Piyasa takibi ve haberleri öğrenmek için bilgisayar dergilerine abone olunabilir. Her ay
alınacak dergiler herkesin ulaşabileceği bir yerde durmalıdır. Bir kütüphane oluşturulup çeşitli
yayınlardan ve kitaplardan herkesin yararlanması sağlanmalıdır.
Şimdi bir proje ekibindeki sorumluluklara göz atalım.

Proje Ekibinin Oluşturulması 14
2.1 Sistem Sorumlusu
Sistem sorumlusu firmanın ihtiyacına bağlı olarak kullanılacak tüm yazılım ve donanım’ın
kurulumu ve bakımı konusunda bilgili olmalı yada öğrenmeye ve araştırmaya açık olmalıdır. Genel
elektrik işlerinden anlamalı, lehim yapmak, kablo çekmek gibi işleri bilmelidir. Ayrıca Microsoft Visio gibi
bir programı bilmesi, yerleşim düzeni ve kablolama için gerekli şemaları çizebiliyor olması gerekir.
Eğer sistemde bir değişikliğe gidilecekse ve sistem sorumlusunun yeni sistem hakkındaki bilgisi
az ise, yeterli eğitim verilmeli ve ancak sistem sorumlusu kendini yeterli gördüğü zaman sistem
değiştirme işlemlerine başlanmalıdır.
Sistem sorumlusu e-mektup, örütbağ gibi kullanıcı haklarını firmanın prensiplerine göre
ayarlamalıdır. Sınırlı bir internet bağlantısı ve sıkı virüs tarama programlarıyla denetlenen bir e-mektup
altyapısını kurup yönetebilecek seviyede olmalıdır. Her BT çalışanı ilk 4 yıldan sonra alıştığı, bildiği
yazılımları kurup kullanmak ister. Bu seviyeye gelmiş bir sistem sorumlusu da kullanılacak yazılım ve
donanım hakkında fikir belirtebilmeli ve rahatça çalışabileceği bir ortam yaratılmalıdır. Çalışanların fikrini
almak ve bu bilgileri kullanmak, bir sürü paranızı yutup hiç bir iş yapmayan BT danışmanlarından daha
etkili ve ucuz bir yöntem olacaktır.
Güvenlik ile ilgili konularda piyasa genelinde kullanılan yazılım ve donanımları bilmeside gerekir.
Firewall tabir edilen güvenlik yazılımlarını çok iyi bilmesi gerekir. Yapılan projelerin yedeklenmesi ve
saklanması konularında titiz çalışmalı, sistem göçmeleri halinde en kısa zamanda bir önceki yedeklere
dönecek kadar bilgiye sahip olması gerekir.
Kesintisiz güç kaynakları ve kullanımı hakkında bilgiye sahip olmalı, sağlayıcı firma ile ilişkileri
sağlam tutmalıdır. Servis zamanlarında yada arıza hallerinde sağlayıcı firma tarafından yapılan her işlem
kayıt edilmeli ve arşivlenmelidir. Kesintisiz güç kaynağına ait prizlerin diğer prizlerden farklı olması ve şarj
cihazları veya elektrik süpürgesi gibi kesintisiz güç kaynağına zarar verebilecek cihazların bu prizlerden
kullanılmamasına dikkat etmelidir.
2.2 Proje Lideri
Proje liderinin firma içi tüm operasyonlar ve projesi yapılan iş hakkında geniş bilgiye sahip
olması gerekir. Tercihen iş ile ilgili sektörden gelmiş ve Bilgi Teknolojileri Yönetimi hakkında bilgisi olması
istenir. Eğer böyle birisi bulunamaz ise tüm analiz aşamalarında bulunacak ve işi en ince ayrıntısına kadar
anlayabilecek bir kimse olmalıdır. Proje Lideri ekibi bir arada tutmak ve zaman çizelgelerine uyulması için
gerekli motivasyonu sağlayacak sosyal bir insan olmalıdır. Ayrıca Yönetim Kurulu ile proje arasındaki bilgi
alış-verişini de sağlar. Bütçe konularında düzenlemeler ve maliyet analizlari konusunda yönetim kuruluna
bilgi ve tavsiye verir.
Proje Sözlüğünün oluşturulmasında görev alır ve proje genelinde kullanılan terimlerin herkes
tarafından öğrenilmesine dikkat eder. İyi bir ekip iltişimi için önem verilmesi gereken bir konudur.
Yazılacak modüllerin ve arayüzlerin zorluk derecelerine göre zamanlarını tayin eder ve proje
planı içinde yayınlar. Bu zamanların tayini sırasında proje ekibi ve yazılım uzmanları ile beraber çalışır.
Onların fikirlerini dinler ve tavsiyeleri göz önünde bulundurur.
Proje Lideri yeni gelenlere bilgi akışının sağlanması ve ekip içindeki yerlerini kolayca
bulabilmeleri için de yardımda bulunur. Yeni gelenler için hazırlanacak dosyada, gerekli her şey olmalı,
işe başlarken getirecekleri evraklardan, proje standartlarına ve bina içinde uyulması gereken kurallara
kadar her şey maddeler halinde bulunmalıdır. Firma ahlaki, kuralları, calışma prensipleri, yönetim
şeması, iş tanımı vb. gibi her türlü bilgi düzgün biçimde aktarılmalıdır. Bu tür bilgiler güncellendiğinde
tüm çalışanların bunları öğrenmesi sağlanır.
Yeni yazılım uzmanlarına iş atanırken daha yeni oldukları düşünülerek atanmalı ve öncelikle
ortama uyum sağlamaları ve projesi yapılan işi öğrenmeleri için yeterli zaman tanınmalıdır. Modül
tabanlı geliştirme yapılıyorsa basit modüllerden işler verilerek kişinin işe alışması sağlanır.
Proje Lideri yazılım aracı olarak kullanılan araçları ve dilleri de bilmelidir. Böylece maliyet analizi
ve teslimat günlerini belirlerken gerçekçi tahminlerde bulunabilir. Eğer proje lideri firma içinden yetişmiş
ve yazılım uzmanlığından yükselmiş ise daha da iyi olur. Alt yapıları ve firma ahlakını çok iyi bildiği için,
sadece yönetim ile ilgili bir eğitim alması yeterli olacaktır.
Diğer proje ekipleri ile bilgi alışverişini sağlar ve kontrol altında tutar. Diğer ekiplerin yöneticileri
ile koordineli çalışır. Kendi projesinin teslim zamanı diğer projelerdeki modüllere dayanıyorsa bu
uzantılarıda kontrol eder ve ekibine bildirir.
Projedeki her türlü riski takip eder ve kaynaklarını ona göre tahsis eder. Riskleri belgeleyerek
çözümler için onaya sunar. Onay sonucu çıkan kararları işleyerek sonuçları tekrar yönetim kuruluna
bildirir.
2.2.1 Görev Süreçlerinin Tayin Edilmesi
Atanacak görevlerin alacağı zaman belirlenirken PERT (Project Evaluation Review Technique,
Proje Değerlendirmesi Teftiş Tekniği) ortalamasından yola çıkılabilir. Proje Ekibine görevler atanırken 3
farklı zaman tayini yapılır. Bunlar “En İyi”, “En Kötü” ve “Normal Bitiş” zamanlarıdır. Görev atanan kişinin
deneyimlerinden yararlanılarak tayin edilir. Aşağıdaki formül bu verileri kullanarak görev zamanını
belirlemek amacı ile kullanılır.
GZ = (Eİ + 4NB + EK) / 6
GZ = Görev Zamanı
Eİ = En iyi durumda görevin alacağı zaman
NB = Normal bitiş süresi
EK = En kötü durumda görevin alacağı zaman
Bu formülden elde edilen GZ değeri Microsoft Project™ üzerinde görevlerin süreçlerinin tayin
edilmesi amacı ile kullanılır.
2.3 Analiz Ekibi
Sürekli müşteri ile yüz yüze toplantılar yaparak iş akışının çok iyi bir biçimde aktarılmasından
sorumludur. Yazılım ekibi ile müşteri arasındaki problemlere çözüm bulmak için uğraşır. Analiz
toplantılarında İş Senaryolarını ortaya çıkararak detaylandırılmasında görev alır.
Yazılım ekibinden gelecek her türlü soruyu cevaplamaya çalışır. Yazılım ekibi senaryolar
hakkındaki sorularını merkezi bir dosyada tutar. Haftada bir kere analiz ekibi ile yapılacak toplantı ile bu
sorulara cevap bulmaya yada ortaya çıkan istekler doğrultusunda senaryolarda değişiklik yapma yoluna
gidebilir.
Müşteri isteklerinin tam olarak anlaşılması ve modellenmesi için hazır formlar ve şablonlar
kullanır. Tüm toplantı notları belli düzenler içinde veya tutanak biçiminde tutulur ve saklanır. Kağıt
kullanmayı azaltmayı amaçladığımıza göre 10 parmak yazabilen veya steno bilen bir eleman toplantı
notlarını hızlı ve eksiksiz biçimde tutmalıdır. Daha sonra bunları belgeleyerek proje ekibine ulaştırılmasını
da sağlar.
Yazılım ve tasarım ekibi ile birlikte çalışarak müşteri isteklerinin tam olarak modellenmesine ve
yazılım ekibi tarafından iyice kavranmasına dikkat eder. Ortaya çıkan modellerin doğruluğunu senaryolar
ile onaylar ve yanlış yerlerin değişmesi için öneride bulunur. Bu önerilerin ve değişimlerin yapılıp
yapılmadığını kontrol eder.
Ortaya çıkan ürünün, müşteri öncesi testlerin yapar ve senaryolar yolu ile doğruluğunu ölçer. İş
akışı içinde mantıksal olmayan yerleri ve müşteri isteklerine uymayan kısımları tesbit eder ve değişmesi
için önerilerde bulunur.
Ekran tasarımları ve akışları için de önerilerde bulunabilir. Fakat kullanılan yazılım aracının ve
dilin kapasitesini çok iyi biliyor olması gerekir.
Tüm analiz ekibinin, analiz metodları, UML, OOA gibi konularda bilgi sahibi olması gerekir. UML
ve OOA konularına yeni başlayan firmalarda ise bu konularda eğitim verebilecek seviyede bir elemanın
analiz toplantılarına yön vermesi ve yeni gelenleri eğitmesi gerekir. En iyi eğitimde müşteri ile olan
toplantılarda olur. Yeni gelenler bu toplantılara katılarak hem analizin nasıl yapıldığını hemde UML ve
OOA konularının nasıl uygulandığını görürler.
2.4 Tasarım Ekibi
Tasarım ekibi, analiz ekibinin ürettiği senaryoları UML kullanarak modeller ve analizi yapılan
müşteri gereksinimlerinin elle tutulur bir kopyasını ortaya çıkartır. Ortaya çıkartılan modellerin
bakımından da sorumludur. Tasarım ekibi UML tabanlı bir araç kullanıyorsa, modelleri iç-örütbağı
üzerinde yayınlar ve analiz ekibinin test etmesini sağlar. Eğer bir UML aracı yoksa modeller kağıtlara
çizilerek duvarlara asılır. Bu duvara model duvarı (wonderwall, modeling wall) denir ve herkesin
görebileceği bir duvar seçilir. Model Duvarı ekip içindeki iletişimi arttırmak için çok önemlidir.
Modellerden veri tabanı ve sınıf şemalarını oluşturarak ilk veritabanı modellerini ortaya çıkarır
ve yazılım uzmanları ile analiz ekibinin test etmesini sağlar. Testler sonucu oluşacak değişiklikleri uygular
ve önerileri dikkate alır.
Veritabanı modeli ortaya çıkmaya başladıkça oluşan sahaların ne işe yaradığını gösteren “veri
sözlüğünün” oluşturulmasını sağlar. Bu sözlükte veritabanında bulunan her sahanın açıklaması ve
örnekleri bulunur. Sahalar için bulunan iş kurallarına da referans verilir. Örneğin belli sahalara belli
formatlarda veri girilmesi gerekebilir. Örneğin saha 15 karakterlik bir tekst katarıdır fakat girilen verinin
100-110-111-121 şeklinde olması gerekir. Bu gibi durumlarda ilgili iş kuralı numarası ile belirtilmeli ve bir
“hyperlink” ile bağlanmalıdır.
Modelleme sonucu ortaya çıkan modülleri teste sunar ve gerçekten gerekli olup olmadıklarını
bulmaya çalışır. Analiz ekibi ve yazılım ekibi modül testlerini ortak yapar. Modelleme, süreci boyunca
değişime açık bir konudur ve genelde ilk tesbit edilen modüllerin %60’ı ortadan kalkar. Modül
normalizasyon toplantıları, sistem gereksinimleri ve müşteri istekleri karşılaştırılarak yapılır. Sistem
gereksinimi, ürünün çalışacağı sistem düşünülerek ne kadar cpu, ne kadar hafıza, ne kadar disk alanına
ihtiyacınız olduğudur. Modüllerin gereksiz yere şişmemesi ve çalışmaya başladığında performans
sorunlarına yol açmaması için yapılması gereken bir analizdir.
İş Akışı Senaryo (Sequence) Şemalarının oluşturulmasına öncülük eder ve tüm proje ekibinin bu
genel akışlardan haberdar olmasını sağlar. Projesi yapılan işi tam olarak anlayabilmek ve geliştirmeler
için fikir yürütebilmek amacıyla bu şemaların çok iyi kavranması ve sindirilmesi gerekir. Önce genel iş
akışlarından başlayıp detaylandırarak gitmek mantık olarak olayların anlaşılmasını kolaylaştırır. Mesela
yazılım ekibi detay akışları incelerken, yönetim sadece genel akışları kontrol edebilir. Böylece yönetim
işine yaramayacak pek çok bilgiden kendini soyutlamış olacaktır.
İlk sürümde yer alacak modül ve servislerin belirlenmesi amacı ile tüm modülleri öncelik sırasına
dizer. Projenin minimum kapasite ile çalışacak biçimde ilk sürümünü verebilmesi amacı ile planlama
yapar ve bu modüller üzerine yoğunlaşılmasını sağlar.
Modüllerin sunacağı servislerin belgelendirilmesi için bir şablon belirler ve her servis için
giriş/çıkışların ve servisin yaptığı işin içeriğini ortaya koyar. Daha sonra yazılım ekibi bu belgelerde
anlatılan servisleri hayata geçirecektir. Servis belgelerinda kullanılan dil herkesin anlayabileceği bir
şekilde olmalı ve okuyan yazılım uzmanı bildiği yazılım dili ile uygulayabilmelidir. Servis belgesinin
kullanılan yazılım araçlarından ve dillerinden bağımsız olması gerekir. Yani servisin yaptığı işler yazıya
dökülürken yalın ve düzgün bir Türkçe ile anlatım yapılmalıdır.
Ortaya çıkan servislerin hangi senaryolar ile test edileceğini de maddeler halinde belirtir. Yazılım
uzmanları bu bilgiyi kullanarak Ünite Testi için gerekli veriyi hazırlayacaktır. Veri ile çelişen durumlarda
yada test senaryosunun gerçeklenemeyeği durumlarda, konu iyice tartışılmalı ve veritabanı ile program
tasarımları gözden geçirilmelidir. Zira bu tür bir çelişme tasarımlarda bir değişikliğe yol açabilir.
2.5 Yazılım Ekibi
Firmanızın kalbi, modelleri hayata geçirerek gerçekleyen ve elle tutulur (göreceli, ancak tıkıza
yazarsak olabilir), gözle görülür yazılımlara dönüştüren ekibiniz. Yazılım ekibinin görevlerine bir bakalım.
Yazılım uzmanları tasarım ekibinin oluşturduğu her türlü ürünü okuyarak öğrenmeli ve aklına
takılan soruları rahatça tasarım ekibine yöneltebilmelidir. Analiz aşamalarında bulunmalı ve projesi
yapılan işi en derin yönleriyle öğrenmelidir. Gerektiğinde müşteri tarafında işi öğrenmek için çalışması
sağlanmalıdır yada eğitim günleri ile tüm işi öğrenmesi sağlanır.
Ortaya çıkan modüllerin servislerini yazarak işe başlar. Gerektiğinde değişiklikler için fikir sunar.
Küçük modüllere ayrılmış bir projede her yazılım uzmanı bir modülün sorumluluğunu alabilir. Modüller
arası bağlantıları gerçekleştirir. Servislerin tek tek testini yapar. Test için gerekli veriyi hazırlar ve
veritabanına yükler. Tasarım ekibinin belirlediği test senaryolarının ayrıntılarını yazar ve uygular.
Servisleri kodlamaya başlamadan evvel test verileri ve yöntemi hazır olmalıdır. Kod içinde kullandığı
yorum satırları ile kodun kendini anlatabilmesini sağlar. Karmaşık fonksiyonları yada tekrar eden
işlemleri bölerek ufak parçalar halinde yazmalıdır. Tüm bölünen bu parçaların nasıl çalıştığını
belgelendirerek diğer kişilerin anlamasını kolaylaştırır. Belgelendirme işi uzun süreceğinden kod içine
yazılacak yorum satırları da yeterli olabilir. Zaten ana servis ayrıntıları ile yazıya dökülmüştür. Kodlama
aşamasında ortaya çıkan ufak fonksiyonlar yorum satırları ile anlaşılacak biçimde detaylandırılır. Her
yazılan servisin ve onun kullandığı alt fonksiyonların girdi ve çıktıları, bunların biçimleri, diğer hangi
servisler tarafından çağırıldığı, hata durumlarında yarattığı hata mesajları ve kodları ayrıntılı biçimde
yazılmalıdır. Modül tabanlı geliştirme konusunda bunların örneklerini göreceksiniz.
Yazılım uzmanı kullandığı cihazlara karşı sorumluluk sahibi olmalıdır. Firma kaynaklarını kötü
amaçlarla kullanmamalı, piyasada firmanın yada kendisinin ismini kötü olarak duyuracak davranışlardan
kaçınmalıdır. Masasının ve kullandığı cihazların temizliğinden sorumludur. Arıza hallerinde hemen sistem
sorumlusunu konudan haberdar eder. Günlük tutarak yaptığı işleri yazar veya yapamadığı işlerin
nedenlerini sıralar. Performans değerlendirme zamanlarında bu günlükten yararlanılır. Firmanın
kurallarına göre kendini yeni sahalarda geliştirmelidir. İşini zamanında bitirebilmek için planlamaya vakit
ayırması gerekir. Proje genel planından ve tüm servislerin teslim zamanlarından haberdar olmalıdır.
Yaptığı planları yöneticisi ile paylaşmalı ve fikir almalıdır. Gerekiyorsa planlarını buna göre
değiştirmelidir.
Yazılım uzmanı üretilen her türlü kodun ve belgenin firma dışına çıkmaması için bilinç sahibi
olması gerekir. Yıllar boyunca emek verdiğiniz yazılımınızın 4 milyona yerlerde satıldığını görmek pek iyi
olmasa gerek. Bu konuda pek çok önlem alabilirsiniz fakat en önemlisi ekibin bilinçlendirilmesi ve eğer
ihtiyaç varsa, bindikleri dalı kesmemeleri için eğitilmeleri gerekir.
2.6 Müşteri Temsilcisi
Ürününüzü pazarlayacağınız sektörden yada firmadan atanacak 2 kişi sürekli yazılım geliştirme
süreçlerinde bulunacak ve aşamalara yön vererek kaydedecektir. Müşteri ile yapılan analiz
toplantılarında köprü görevi üstlenecek ve yanlış anlamaları ortadan kaldıracaktır. Müşterinin ne
istedigini tam olarak, tasarım ve yazılım ekibine aktarılmasında kilit rol oynayacaktır. Her toplantıdan
sonra, tartışılan gündemi ve analizleri belgelendirecektir. Bu belgelerin Tüm proje ekibine ayrım
yapmadan dağıtılmasından da sorumludur.
Müşteri temsilcileri yaptıkları işi çok iyi bildikleri için kendi işleri ve hizmet sundukları sektörler
arasındaki akışı en iyi onlar anlatabilir. Analitik düşünce yapısına sahip olmalı ve problem çözme
becerileri bulunmalıdır. Bilgisayar nedir, yazılım nedir ve bu yazılımdan neler bekliyorlar gibi konularda
bilgi sahibi olmaları gerekir. Mühendis yada yazılımcı olmalarına gerek yoktur. Eğer ilk defa bu tür bir
işde çalışacaklarsa, ilişkili veri tabanı mantığı, kullanılacak işletim sistemlerinin genel yapıları, kullanılan
yazılım araçlarının işlevselliği, firma içi standartlar ve kurallar hakkında bilgilendirilmelidirler. Firmadaki
teknik alt yapı ve haberleşme metodları hakkında da bilgi verilmelidir. Giriş seviyesi UML modelleme
konuları öğretilmeli ve analizlerde kullanmaları sağlanmalıdır.
Ürün ortaya çıktıktan sonra iş akışı testlerini yapar ve hesaplamaların doğruluğunu kontrol eder.
Ekranların kullanılırlığını ve akışları konusunda genel testler yapar. Test ekibine doğrudan yardımcı olur.
Proje başında tasarım ve analiz ekibine, ortasında yazılım ekibine ve sonunda da test ekibine yardımcı
olur.
2.7 Test Ekibi
Test ekibine geçmeden önce bu ekibin kullanacağı alt yapıdan biraz bahsedelim. Test ekibi
testlere başladıktan sonra ortaya çıkacak hataları bir yerlere kaydetmelidir. Modül bazında kayıt edilmesi
ve hatanın tam bir açıklaması ile ekran resimlerinin iliştirilmesi gerekir. Hatanın yazılım uzmanı
tarafından tekrar edilebilmesi amacı ile kullanılan veride belirtilmelidir. Tüm bu verilerin kayıt edileceği
bir ortam önceden hazırlanmalı yada satın alınmalıdır. Bu ortam ileride müşteri sorunlarına çözüm
ararken de kullanılacağı için güvenilir, yüksek kapasitede çalışabilecek ve örütbağı izerinden
ulaşılabilecek bir ürün olması gerekir.
Test ekibinin yapacağı testleri bir kaç sınıfa ayırabiliriz. Bunlar:
 Servis testleri
Modül içinde barınan servislerin tek tek test edilmesi ve bu servislerin giriş ve çıkışları servis
belgelerinden kontrol edilerek test edilir. Tüm sonuçlar, servis belgesindeki tahmin edilen sonuçlar ile
karşılaştırılır ve uymayan durumlar tekrar gözden geçirilir. Verinin bütünlüğü genel amaçtır ve
hesaplamalar ile veritabanı operasyonlarının gerçekleşip gerçekleşmediği tesbit edilmeye çalışılır.
 Modül testleri
Modüller arası ilişkiler gözden geçirilerek beraber çalışması umulan modüller birlikte test edilir.
Bir modülün çıktıları başka bir modülün bir servisini tetikliyor olabilir. Bu tür tetiklemelerin oluşup
oluşmadığı test edilir. Bu aşamada veri pek önemli değildir. Dikkat edilmesi gereken konu modüllerin
birbirleri ile nasıl çalıştığı ve bir modülün çıktılarının bir diğer modül tarafından nasıl kullanıldığı ve doğru
olarak veri akışının gerçekleşip gerçekleşmediği test edilir.
 İş akışı testleri
En uzun süren test budur. Servis ve Modül testlerinden başarı ile çıkmış modüllerin tüm sistem
içinde nasıl davrandıkları ve ilk gerçek hayat testleri bu aşamada yapılır. İşin gerektirdiği biçimde ve
Müşteri Temsilcisi tarafından yapılmalıdır. İş akışlarını çok iyi bilen Müşteri Temsilcileri tüm yazılımı bir
bütün olarak ele alıp incelerler.
Örneğin bir hisse senedi alma işine bakalım. Müşteri aracı firmayı arayarak hesap bilgilerini ve
şifresini doğruladıktan sonra almak istediği hisse senedini belirtir. Bu arada hattın diğer ucundaki
personel, müşterinin bilgilerine ulaşmış ve alım için gerekli ekranlara girmiştir. Müşteri satın almak
istediği hisse senedini ve miktarını belirtir ve alım için gerekli talimatı verir. Personelimiz bu bilgileri de
alarak programa girer ve alım için son bir onaydan sonra alım tuşuna basar. Bundan sonra programımız
alımı yapar, müşterinin banka hesabından ücreti düşer, ve hesapları günceller. Son durumu ekranda
gösterir ve personelimiz de bu son durumu telefondaki müşteriye söyler. Buraya kadar geçen tüm
olaylarda programın nasıl kullanıldığını hayal edin. Tüm ekranları gözünüzde canlandırın. Kullanılacak
modülleri bir sayalım, öncelikle müşteri modülü ile müşteri bilgilerine ulaştık, daha sonra alım/satım
modülünden istenen hisse senedine ulaştık. Bu arada başka bir modül hisse senetlerinin fiyatlarını
güncelledi. Müşterinin bankası ile bağlantı kuracak fon transferi modülü de para aktarımını
gerçekleştirdi. Son olarak ta müşteri hesabını görüntüleyen Muhasebe modülü devreye girdi.
Bu tür iş akışları önceden Tasarım ekibi tarafından hazırlanmalıdır ve Servis Testleri sırasında
belli parçaları yazılım uzmanları tarafından kullanılmalıdır. Analizler sırasında ortaya çıkan senaryo
modelleride test amaçlı kullanılabilir. Test için gerekli verinin senaryolar halinde hazırlanması ve
veritabanı uzmanları tarafından yüklenmesi gerekir.
Müsteriden iki kişinin teste yön vermesi de gerekebilir. Yarım gün calışacak iki görevli testlere
farklı bir göz ile bakmayı sağlayacaktır. Müşterinin atayacağı iki kişi hem iş akışlarını hemde ne
istediklerini bilecekler, ayrıca bu kişiler bizim test ekibini de eğiteceklerdir. Senaryoların genişlemesine
yardımcı olacaklardır. Bu kişilerin zaman içerisinde belli bir döngüye girip test senaryolarına dar bir görüş
açısı ile saplanmamaları için belli zamanlarda farklı kişiler ile değiştirilmeleri gerekir.
2.8 Eğitim Ekibi
Eğitim ekibi firma içinde gerekecek her türlü eğitim gereksinimini karşılayacak biçimde
olmalıdır. Firma içi eğitimler kadar dışarıdan da eğitim almak için gerekli organizasyonu yapar. Bu ekibin
yapacağı işi bir kaç alt başlık altında incelersek:
a- Yazılım ekibinin egitilmesi
Yazılım ekibi için gerekecek eğitimleri belirleyecek ve alt yapısını hazırlayacaktır. Firma içi
eğitimler dışında eğer gerekirse uzman eğitim firmalarından destek alması gerekebilir. Yazılım ekibinin
çeşitli konularda sertifikalandırılması ve bu eğitimlerin güncel işlerde kullanılabilecek olmasına dikkat
eder. Eğitim ekibi firma içinde kullanılan ürünlerden, yazılım araçlarından haberdar olmalı ve gerekli
eğitimleri tasarım edebilmelidir. Eğitim için kullanılacak bilgisayarları ve eğitim belgelerini hazırlamalıdır.
b- Pazarlama ekibinin egitilmesi
Pazarlama ekibini satışı yapılacak ürün konusunda bilgilendirmeli, rakipleri araştırarak zayıf
yönlerini belirlemeli ve ürünün özelliklerini tamamı ile pazarlama ekibine öğretmelidir.
c- Belgelerin hazırlanması
Eğitimler için gerekecek her türlü belge ve program önceden hazırlanmalıdır. Standart haline
gelmiş eğitimler ile yeni firmaya katılanlara verilecek eğitimler kitapçıklar halinde hazır olmalıdır. Firma
ahlakını ve çalışma prensiplerini anlatan eğitimler çok önemlidir.
Mezuniyetten sonra hayata atılan iş arkadaşlarıma planlı programlı ve prensipleri olan bir
firmada çalışmalarını tavsiye ederim. Eğer işe girdiğinizin ikinci günü sizden bir şeyler üretmeniz
isteniyorsa anlayın ki firma düzeni pek oturmamıştır ve sizden yapmanız istenen işler de yarın şekil
değiştirecektir. Belirsizlikler içinde sürklenmektense bir an önce başka bir firma bulup geçiş yapmanız
geleceğiniz için iyi olacaktır.
d- Eğitim odalarının hazırlanması
Eğitim odalarının düzeni ve kullanılacak bilgisayar ve beyaz tahtaların bakımı konularından

sorumludurlar. Tüm ekipman kayıt altında tutulmalı ve her eğitimden sonra kontrol edilmelidir. Kayıplar
yada yeni istekler yönetim kuruluna bildirilmelidir.
e- Ürün eğitimlerinin hazırlanması
Üretilen ürünün eğitim kitaplarını hazırlar, yeni güncellemeleri ve ekran değişikliklerini eğitim
belgelerine yansıtır. Ürünün her majör sürümü ile birlikte eğitim kitaplarıda yenilenmelidir.
2.9 Pazarlama Ekibi
Pazarlama ekibi en az yazılım ekibi kadar önemlidir. Hangisinin daha çok gerekli olduğuna değil
birbirleri arasındaki haberleşmenin -firmanın geleceği için- nasıl olması gerektiğine odaklanmak gerekir.
Çalıştığım firmalarda zaman zaman bu konuda tartışmalara tanık oldum. Fakat bilinmesi gerekir ki bu tür
tartışmalar sadece firmanın kaynaklarını boşa kullanmaktır.
Pazarlama ekibi müşteri pazarının belirlenmesi için çalışmalar yapar. Potansiyel müşterileri
belirleyerek ziyaretlerde bulunur. Fuar veya sergi gibi etkinliklerde hem rakipler üzerine araştırma yapar
hemde yeni müşteriler bulabilmek için çalışır. Sektör ile ilgili medyayı takip eder ve gerekli haberleri
arşivleyerek firma içinde dağıtır. Rakiplerin neler yaptıklarını, ürünlerinde ne gibi özellikler olduğunu,
hangi müşterilere satış yaptıklarını öğrenmeye çalışır. Rakiplerin satış fiyatları hakkında bilgi toplar ve
tüm bilgiyi karşılaştırmalı tablolar halinde firma içinde yayınlar.
Reklamların hazırlanması için çalışır. Reklamların hangi dergilerde veya televizyonda hangi
saatlerde çıkacağını belirler. Sektörü yakından takip etmek için medya takip ajansları ile çalışabilir. Satış
stratejileri belirlemek için rakiplerin yeni sürümlerinin ne zaman çıkacağı takip edilmelidir. Reklam
tasarımları için bünyesinde bir grafik tasarımcısı bulundurabilir. Bu sayede grafik tasarımcısı ürünü nasıl
tanıtacağını daha iyi anlar.
Medya ile ilişkileri güncel tutmak için bir kaç köşe yazarı ile bağlantısı olması gerekir. Yeni bir
sürüm çıktığında köşe yazarları ile bağlantı kurup ürünün reklamının yapılması sağlanır.
Müşteri analizleri yaparak veritabanı oluşturma ve müşteri isteklerini kaydederek tasarım veya
yazılım ekibine bildirmesi gerekir. Müşteriyi isteği konusunda bilgilendirerek konu ile ilgilenildiğini
göstermelidir. Bu istekler tasarım ve yazılım ekibi tarafından tartışılarak genel sürümlerde
uygulanabilirliği ortaya çıkartılmalıdır. Bir alt proje gibi ele alınıp harcanan kaynak ve zaman
planlanmalıdır.
Lisans takibi için çalışmalar yaparak hangi müşterinin ne tür lisanslara sahip olduğunu tutar ve
yeni lisansların sağlanması için müşteri ile kontak kurar. Öğrenci lisansı, 30 günlük deneme sürümleri ve
akademik lisansların sağlanması ve ürünün mümkün olan en fazla kişi tarafından kullanılmasını sağlamak
için çalışır. Fuarlarda deneme sürümlerinin dağıtılması ve yeterli eğitim belgesi ile birlikte sunulması için
gerekli organizasyonu da yapar. Firmanın örütbağ sitesi üzerinden gerekli reklamın yapılması ve yeterli
belgenin yayınlanması için çalışmayı da yapar.
BSA ile olan ilişkileri düzenler ve ürünün lisansız kullanılmaması için gerekli tedbirleri alır.
Ürünün elektronik ve yasal olarak korunması için düzenlemeleri yapar. Anlaşma metinlerini düzenler ve
hem ürün içinde hem de örütbağ sitesinde yayınlanmasını sağlar. Değişiklik gerektiren durumlarda tüm
bu ortamlar güncellenir ve müşteriler bu değişiklikten haberdar edilir.
Satış sonrası müşteri memnuniyeti testleri ve ziyaretleri ile sürekli müşteri ile bağlantıda olur ve
böylece müşteri kendini yanlız hissetmez. Müşteriler için etkinlikler organize eder ve müşterilerinde
kendi aralarında bağlar yaratır. Böylece müşteriler birbirlerinin bilgilerinden yararlanabilirler. Bu tür
ilişkilerin artması aile gibi bir yapının müşteriler ve firmanız arasında doğmasına yol açar. Gittikçe
ilerleyen ve gelişen bu yapı ileride meyvelerini toplayacağınız bir ağacın fidesi olabilir.
2.10 Kurulum Yönetimi Ekibi
Kurumsal çözümler sunan bir firma yapısına sahip iseniz yada ürünlerinizi sizin kendi
sunucularınız üzerinden kullandırıyorsanız, tüm kurulum işlemlerinin ve yeni sürümlerin kontrol altında
olması gerekir. Yapılacak iş projelerin bitim tarihleri ile koordineli olarak tüm mevzuatın düzene
sokularak maddeler halinde yazılmasıdır. Özellikle 3-katmanlı yada n-katmanlı sistemlerde
güncellenmesi gereken programlar bir kaç sisteme dağılmış olabilir hatta coğrafik olarak birbirlerinden
uzakta bile olabilirler. Yapılacak işler sırası ile:
 Güncelleme için planlama yapmak.
 Güncellenecek programların kurulumlarını hazırlamak ve bu kurulumların nerelerde

çalıştırılacağını belirlemek. Kurulum işlemlerinin en ince ayrıntısına kadar belgelendirilmesi gerekiyor.
 Güncelleme için gerekli, yazılım dışı, ürün kurmak gerekiyor mu araştırmak.
 Müşterileri uyararak, güncelleme yapılacağı gün programların çalışmayacağını belirtmek.
 Güncellenecek sistemin yedeğini almak.
 Güncellemeyi yapmak
 Tekrar yedek almak
 Yazılım Doğrulama Testi yaparak güncellemenin doğru çalıştığından emin olmak

 (EK) Eğer YDT sonuçları güncellemenin çalışmadığını gösteriyorsa, yedekleri geri

yükleyerek sistemi bir önceki konumuna getirmek.
Bu ana maddeler ışığında tüm adımların en ince ayrıntısına kadar detaylandırılması ve bağlantı
kurulacak kişilerin telefon numaraları bir belge halinde projede görev alan herkese ulaştırılmalıdır.
Yazılım ekibinden bir kişi olası bir sorun durumunda bağlantı kurulması amacı ile destek hizmeti verir.
Oluşturulacak belge bir akış şeması, bir Excel belgesi yada bir MS Project belges olabilir. Önemli olan tüm
tarih ve saatlerin en ince ayrıntısına kadar yazılmasıdır.
2.11 Değişim Ve İsteklerin Yönetimi
Projenin her safhasında değişim ve isteklerin yönetilmesi zorunluluğu vardır. Bu iş için bir kişi
ayrılması şarttır. Değişim ve istekleri yönetecek kişi üretilen her türlü belge ve yazılım parçasından
sorumludur. Üretilen belge yada kod ilk majör sürüm numarasını aldığında o parça artık Değişim ve
İstekler Yönetimi altındadır. Majör numaradan kastımız 1.0’dır. Noktanın sol tarafı 1 olduğu zaman artık
ilk sürüm verilmiş demektir. İstenen her türlü değişiklik ve istek bir toplantı yapılarak karara bağlanır.
Değişimden etkilenen her proje parçası ortaya çıkartılarak maliyet araştırılır. Eğer çok fazla maliyetli bir
değişim ise bir sonraki sürüme bırakılabilir. Fakat bu işleri yöneten kişinin bunların takibini yapması
zorunludur.
2.12 Pilot Firma
Ürününüz belli bir seviyeye geldikten sonra bir pilot firma seçip yazılımı buraya kurmak ve iş
akışı içindeki davranışlarını görmek yapılacak en iyi testlerden biridir. Ortaya çıkan ve testleri bitmiş
modüllerin bu şekilde test edilmesi size ve ürününüze çok yararlı olur. Bu iş için atanacak kişiler ve
kurulacak sistem önceden belirlenmeli ve pilot firmanın iş akışını aksatmayacak biçimde derlenmelidir.
Kurulacak bilgisayarlar ve yazılımlar, var olan sistem üzerine değil, yedek bir sistem üzerine kurulmalıdır.
Belki her masada iki kişi ve iki bilgisayar (biri sizin diğeri pilot firmanın) olacaktır ama ilk aşama için bu
gereklidir. Yazılımınız olgunlaşmaya başladıkça pilot sistem var olan sistemin yerini almaya başlar. Tüm
operasyonlara cevap verecek düzeye geldiğinde ise artık tamamı ile sizin yazılımınız işi ele almış
olacaktır.
Bu iş için ayrılacak elemanlar özel olarak seçilmeli, stres ve baskı altında rahatça ve soğukkanlı
kalabilmeli, problem anlarında kontak kuracakları kişileri bilmeli, tüm alt yapı ve yazılım ile yapılan işi
bilmelidir. Her çıkacak hata veya değişiklik istemi iyi bir hata takip programı ile firmaya aktarılmalı ve
çözümler hızlı ve ayrıntılı biçimde bulunmalıdır.
2.13 Şeffaf Muhasebe
Firma içinde yapılan tüm harcamaların ve gelirlerin şeffaf bir biçimde çalışanların görmesini
sağlayarak belli bir oranda bilinç oluşturabilirsiniz. Kullandıkları makinelere ne kadar harcandığını bilen
bilinçli kullanıcılar, onları korumak için daha fazla çaba gösterecektir. Mutfak ve tuvaletler için yapılan
harcamalar da dahil olmak üzere her harcama herkesin rahatlıkla ulaşabileceği bir yerde olmalıdır. Firma
çalışanlarından gelecek tavsiyeler ile harcamalarda daha hesaplı davranılabilir. Maliyet bilinci ile çalışan
kişi daha dikkatli bir biçimde çalışır. Ayrıca bu harcama bilgisinin firma dışına çıkmaması için gerekli
eğitiminde çalışanlara verilmesi gerekir. Şeffaf muhasebenin miktarını size bırakıyorum. Eğer saklamayı
arzu ettiğiniz harcamalar varsa bunları neden sakladığınızı bir kez daha düşünüp harcamayı o şekilde
yapın.
Firma çalışanlarının firmaya maddi zarar verecek davranışlardan da kaçınması gerekir. Şeffaf
muhasebe ile belirli bir bilinç seviyesine gelen çalışanlar, çalıştıkları firmanın daha uzun ömürlü olması
için ellerinden geleni yapmalıdırlar.
2.14 Yapılan Yanlışlar
2.14.1 Lisanssız Yazılım Kullanımı
Firmanızı kurdunuz, üründe hemen hemen hazır, müşteriler sırada bekliyor fakat ne
kullandığınız yazılım araçları nede işletim sistemleri lisanslı değil. Bu gibi durumlarda yazdığınız ürünü
satmanız mümkün değil. Bir an önce lisanslama yoluna gitmeniz gerekir. Ülkemizde bu konu hakkında
çalışma yapan BSA (Business Software Alliance) lisanssız kullanım için oldukça ağır cezaların
uygulanmasına öncülük etmektedir. Ayrıca yazdığınız ürünün başkaları tarafından lisanssız kulanılmasını
önlemek amaçlı olarak ispiyoncuların size rahatça ulaşabilmesi için bir ortam hazırlamanız ve
avukatlarınızın bu konularda deneyimli olması gerekir. Öte yanda ne yaparsanız yapın bir yerlerde birileri
sizin el emeği göz nuru programınızı lisanssız olarak kullanacaktır. Bu tür bir kuruluş keşfettiğinizde bir
maliyet analizi yapıp karşı dava açarsanız zararınızın ne olacağını ve ne elde edeceğinizi iyi tartmanız
gerek. Astarı yüzünden daha pahallıya gelmesin yani. Birde maliyeti çok gibi görünse de bu tür kaçak
yazılım kullanan bir kuruluşu reklam ve caydırma aracı olarak kullanabilirsiniz.
2.14.2 Yeterli Yardım Ve Desteği Alamama
Kullandığınız yazılım araçlarının üreticisi ile olan ilişkileriniz çok sıkı ve akışkan olmalı. Bir
yardıma ihtiyacınız olduğunda acil aranması gereken telefon numaraları, yardım siteleri, sadece kayıtlı
müşterilerin girdiği forum siteleri gibi tüm yardım araçlarını çok iyi kullanabilmelisiniz. Firma içinden
atanacak bir kişi tüm bu bağlantıları sağlayacak ve bilginin akışkan olarak firmanıza akmasına yardımcı
olacaktır. Ayrıca eğer kontaklar yurt dışında ise, yabancı dili iyi olan bir kişi bu işleri yürütmelidir.
Yeterli desteği alamıyor iseniz kendi içinizde bu problemleri çözmeniz gerekir. Bu yapıyı da
oluşturmak seneler alabilir. Birde bu işlere bakan kişinin 6 ay sonra işden çıktığını düşünün. Yeni gelen
kişinin olayı anlaması ve destek konularını ayağa kaldırması gene bir 6 ay alacaktır. Eğer kendi içinizde
halletmeye karar verirseniz, tüm işlemlerin çok net bir biçimde belgelendirilmesine özen gösterilmelidir
ve tekrar eden işlerin kısa programcıklar ile otomatize edilmesi bazı işleri kolaylaştıracaktır.
Üretici firmalar dışında özel e-mektup listeleri de yardım almak için yararlı olabilir. Bazen üretici
firmadan da daha iyi olabiliyor bu listeler. Kullanıcıların bulduğu çözümler daha gerçek hayata yakın ve
uygulaması kolaydır. Fakat üretici firmanın desteklemediği bir çözüm olabilir, buna dikkat etmek lazım.
Yardım alınacak tüm yollar ve yöntemleri yazılmalı ve genel bir hata veritabanı oluşturulmalıdır.
Bu sayede tekrar eden hatalar zaman kaybetmeden çözüme kavuşturulabilir.
2.14.3 Eğitimsiz Yazılım Uzmanları
Nasıl bilgisayar sisteminizi ve programlarınızı güncelliyorsanız, yazılım uzmanlarınızın da

güncellenmesi gerekir.Yeni bir aracın veya dilin firmanız içinde uygulanmaya başlanmasından evvel,
yazılım ekibine yeterli eğitim verilmeli ve bilgi seviyelerinin aynı olması sağlanmalıdır. Oluşturulacak
güncel bir kütüphane ile her zaman güncel bilgiye ulaşmaları sağlanmalı, sanal belgeler ile de sürekli
desteklenmelidir. En fazla para harcayacağınız yer uzmanlarınız olduğuna göre bu konularda ciddi
çalışma yapılması gerekir. Eğitimsiz bir Yazılım Uzmanı firmanıza çok büyük zararlar verebilir. Projeleriniz
zamanında yetişmez, yazılan programların yeterli belgeleri bulunmaz, kayıt dışı pek çok rutin program
veya iki kere yazılmış pek çok fonksiyon ile ürününüz şişebilir. Sonuçta ortaya çıkan ürün de müşterinin
isteği ile ilgisi olmayan bir ürüne dönüşür. Mükemmel çalışıyordur belki ama müşterinin isteğini yerine
getirmiyorsa ne işe yarar ki.
2.14.4 Firma İçi Ahlakın Öğrenilememesi
Firma içi giyim kuşam, hareket ve davranışların belli bir düzene sokulması amacı ile ceşitli
standartlara gidilebilir. Müşteri ile yüz yüze olmayan yazılım uzmanlarının takım elbise giymesi gerekmez
ama müşteri toplantılarında veya analiz toplantılarında takım elbise şart koşulabilir. Tuvaletlerin
temizliği, mutfağın ve banyonun kullanımı belli standartlar ve hijyenik kurallar içerisinde olması gerekir.
Bu tür kuralları öğrenemeyen firma çalışanı sorun yaratmaya başlar. Sorunlar kısa zamanda giderilmezse
diğer çalışanlar rahatsız olur ve işten ayrılmalara kadar gidebilir. İyi elemanlarınızı sebepsiz yere
kaybetmeye başlarsınız ve proje için pek iyi olmaz. Sorun çıkaran kişi proje lideri de olabilir. Bu gibi
durumlarda proje liderine başka işler verip projeyi yürütmesi için başka bir lider arayışına girmeniz
gerekir.
2.14.5 Lidersizlik
Proje liderine çok fazla iş verilmesi yada başka bir projeye atanması sonucu, ekibin başıboş
kalması ve kontrol edici mekanizmanın iyi çalışmaması nedeni ile projenin aksamasına neden olur. Bu
gibi durumlarda liderin yerine geçici olarak geçecek, proje içinden bir kişi belirlenir ve işlerin normal
yürümesi temin edilir. Performans kriterleri ve varılması gereken hedefler çok açık ve net bir biçimde
herkesin görebileceği gibi yayınlanmalıdır. Aksi takdirde hedefsizlikten doğacak çok büyük gecikmelere
maruz kalabiliriz. Yanlış belirlenmiş hedeflerde problem yaratabilir. Ekipten gelecek yorumlar dikkate
alınıp hedef zamanlarının tekrardan belirlenmesi gerekebilir.
2.14.6 Bütün İşin Herkes Tarafından Bilinmemesi
Bir projeye başlandığında, proje ile ilgili her türlü bilgi en ufak birimlere kadar aktarılmalıdır.
Ekibin bilgisi aynı seviyede tutulmalı ve yazılan programların aslında ne gibi işlere yaradığını gerçek
hayatta görülmesi ve kavranması gerekir. Ayrıca proje planının herkesin görebileceği bir duvara asılarak
yayınlanması gerekir. Böylece ne kadar yol alındığı her kes tarafından görülür. Tüm plan ve bilgi eşit
biçimde paylaşılmalıdır. Her yazılım uzmanı, işin iyi kavranabilmesi için sektörde en az 1 hafta çalışmalı
ve işi kaynağında öğrenmelidir. İş kurallarını ve temel işleyişleri en hızlı bu biçimde öğrenir. Örneğin
ayakkabı tabanı üreten bir firmaya proje yapıyorsunuz. Analiz ve yazılım ekiplerinin dönüşümlü olarak bu
firmada çalışması ve işleyişi tam olarak kavramaları, iş kurallarını öğrenmeleri, iş içinde geçen terimleri
ve müşterinin psikolojisini iyice kavramaları gerekir. Böylece yazılım üretilirken ortaya çıkan parçaların
işin hangi aşamasında kullanılacağı daha rahat hayal edilir.
2.14.7 Yetersiz Haberleşme Ve Bilgi Akışı
Firmanızda, yukarda anlattıgım bölümler arasında haberleşme ve bilgi alış verişi cok iyi
olmalıdır. Yazılım ekibi kendi işini, pazarlama ekibi kendi işini, yonetim kendi işini yaparken, ortaya çıkan
sonuçların her kes tarafından paylaşılması gerekir. Ancak bu şekilde herkesin firmaya olan güveni
sağlamlaştırılır ve ortak çıkarlar için birlikte çalışılır. Bir kaç örnek verelim:
Yazılım ekibi günler geceler boyu ürünün bir modülünü ortaya çıkarır ve testlerine başlanır.
Fakat pazarlama ekibinin bu gidişattan haberi yoktur ve modül hakkında pazarlama için gerekli stratejik
bilgiyi zamanında öğrenemez. İkinci modülde ortaya çıkar ve testleri başlar ama pazarlama ekibinin daha
birinci modülden yeni haberi olmuştur ve ögrenilecek şeylerin sayısı artmıştır. Planlarda gecikme olur ve
zaman daraldığı için Pazarlama ekibinin modüller hakkındaki bilgi kalitesi düşer.
Yönetim yeni bir programlama aracı için karar verir ve kimseye söylemeden aracı alır. Araç
yazılım ekibine verilerek bu ürün ile bir şeyler ortaya çıkarması istenir. Hakkında yeterli araştırma
yapılmadığı ve yazılım ekibine danışılmadığı için ürünün kapasitesi tam olarak kullanılamaz ve
anlaşılamaz.
Yazılım ve tasarım ekibi birbirinden kopuktur ve programlama süreci başladıktan sonra

müşteriden gelen istekler doğru biçimde yazılım ekibine aktarılamaz. Sonuçta ortaya çıkan ürün
müşterinin isteğine uymayan bir ürün olacaktır.
Firma bölümleri aynı dili konuşuyor olmalıdır. Bunun içinde herkesin UML mantığını kavraması
ve kullanması gerekmektedir.
2.14.8 Yetersiz Alt Yapı
Bir projeye başlarken, yada bir yazılım firması kurmaya karar verdiğinizde aldığınız risk
seçeceğiniz ucuz ve yavaş bilgisayar sistemleri, kalitesiz kablolama, ikinci el monitörler gibi kalitesi düşük
cihazlara yapacağınız harcamalar ile 3 yada 5 kat artmaktadır. Yetersiz bilgiye sahip yazılım
uzmanlarınıda bu kategoriye sokabiliriz. Temeliniz ne kadar sağlam olursa üstüne çıkacağınız bina o
kadar sağlam ve çok katlı olur. Eğer alt yapıya gereken önemi verirsek, üstüne yapacağımız projeler
zamanında ve tam olarak teslim edilir. Altyapı konusunda dikkat etmemiz gereken hususlar:
 Teknik altyapı
Bilgisayar sistemleri, donanım, ağ, örütbağ, iç-örütbağ gibi firmanın bel kemiğini ve haberleşme
araçlarını içeren sistemlerdir.
 Bilgi altyapısı
Firmanın tüm bilgi alma kaynaklarıdır. Fiziksel bir kütüphane, iç-örütbağındaki sayısal kütüphane
gibi kolay ulaşılabilecek bir yapısı olmalıdır. Sayısal olanlar için yeterli arama mekanizmaları geliştirilmiş
olmalıdır. Her türlü eğitim belgeside bu sistem içerisinde olmalıdır.
 Yazılım altyapısı
Ürününüzü geliştirmek için kullandığınız tüm ürünler ile yazılım süreci ile doğrudan bağlantısı
olmayan tüm yazılımların bulunduğu yazılım kütüphanesidir.
Tüm bu altyapıların yeri geldikçe güncellenmesi ve yedeklenmesi gerekir. Yanlış kısımların

değiştirilmesi ve zamanı dolan ve artık kullanılmayan bilgi kaynaklarının ise sistemlerden kaldırılması
gerekir.
2.14.9 Yetersiz Belgeleme
Yazılım uzmanları olarak belge yazmayı sevmesekte bu işin yapılması gerekmektedir. Yazılan
kodların, yapılan analizlerin, senaryoların, veritabanı modeli gibi proje içerisinde üretilen her parçanın bir
belgesi olmalıdır. Gruba yeni katılacak kişiler ancak bu belgeler sayesinde her şeyi öğrenebilir. Eğer
yetersiz belge gibi bir sorununuz varsa, acilen bir ekip toparlayıp belgeleri tamamlamaya bakmanız
gerek. Eğer yazılım uzmanlarının zamanı yoksa, günde 1 saat ayırarak belgelendirme ile ilgili bilgiyi bu
ekibe geçirmeleri gerekir.
2.14.10 Yazılım Ekibinden Kopmalar
Yönetimde yapılan yanlışlıklar nedeni ile yada tamamen kişisel sorunlardan dolayı, yazılım
ekibinden ayrılmalar olduğunda projenizden bir bilgi birikimi ayrılmış olur. Bu bilgi birikimini yerine
koymak ise zaman zaman oldukça zor olmaktadır. Yeterli belgeleme yapılmış bir firmada çok fazla
sıkıntıya girmeden, kısa zamanda bu bilgi başka bir çalışana aktarılabilir ve proje normal olarak devam
edebilir. Ayrılan kişininde bir süre daha devam edip bilgisini başka birisine aktarabilir. Eğer standart
belgeleme iyi bir seviyede uygulanırsa, ekipten kopmalar bir sorun olmaktan çıkabilir.
31 Blogdan Seçmeler
3 Blogdan Seçmeler
Aşağıdaki bölümde www.analystdeveloper.com adresindeki Türkçe blogumda yayınladığım ve

bu kitaba uygun konulardaki yazılarımı kopyaladım. Umarım işinize yarar.
3.1 Ütopyalarım, Aşkım ve Ben
Ülkemizde tonlarca Muhasebe ve Personel Yönetim programı yazan firma var. Bu firmalar
yazdıkları programlarda bir firmanın ihtiyacını karşılayacak muhasebe işlemleri ile hiç bir yerde doğru
dürüst uygulanmayan personel yönetimi konularında yazılım çözümleri sunuyorlar. Peki soruyorum bir
maliye denetçisi/müfettişi bu programların hepsini en ince ayrıntısına kadar biliyor ve denetliyor mu?
Yada bir firma denetlenmeye alındığında kullandıkları veritabanları ve programları en kıyıda köşede
kalmış inceliklerine kadar denetleniyor mu? Bu programlar maliye tarafından onaylanmış, lisans verilmiş
programlar mıdır? Yada böyle bir uygulama var mıdır?
Başka bir konuda müşterilerin program satın aldıkları bilgisayar firmalarından istekleri. -Şimdi
herkes olur mu öyle şey diyecek ama- bu müşteriler ne kadar gayri resmi yol varsa aldıkları paket
programlarda bunları uygulamak ve kayıtlarını tutmak, bu yüzsüzlük yetmezmiş gibi bir de bunların gizli
şifreler ile korunmasını ve maliye müfettişleri geldiğinde o bölümlerin görünmemesini istiyorlar. Zaten şu
anda piyasadaki tüm muhasebe programları veya özel sektör için yazılmış pek çok paket programda
alavere dalaverenin binbir türlüsü, bir malı 3, 5 kere satmalar, muhasebe hesaplarının resmi-gayri resmi
olarak ikiye ayrılması, faturasız çalışmalar, SSK ödemelerinin en düşük ücretlerden görünmesini
sağlamak, SSK’lı çalışanları ayda sadece 15 iş günü çalışıyor göstermek gibi daha akla gelebilecek binbir
türlü şeytana pabucunu ters giydirme oyunu. Bütün bu gayri resmi işlemlerin sonucunda devletin
kaybettiği vergi, SSK’ya tam olarak ödenmeyen primler sonucu emekli olduğunuzda alacağınız maaşın
azlığı, firmanın kaçırdığı faturası bile olmayan kazançlar, haksız elde edilmiş pek çok gelir, acaba
bizlerden yani birey olarak her vatandaştan bir şeyler koparıp götürmüyor mu? Üstüne üstlük maliye
müfettişleri tarafından tesadüfen! ortaya çıkartılan bu işlemler sonucu firmanın zarar görmesi ve
sicilinde kara bir lekenin bulunması da cabası.
3.1.1 Çözüm Çokmu Zor?
Belki düşüneceksiniz - halledilmesi gereken bir sürü başka konu varken, önce bu konudan mı
başlanır- yada -adam sende, tonla yazılım firması yazmış muhasebe paketi şimdi onların ekmeğine taş mı
koyacağız- diye. Gerekirse koyacağız! Müşterinin yüzsüzleşmesini ve tavizler verilmesini önlememiz
lazım.
Blogdan Seçmeler 32
-Yok kardeşim bizim paketimizde gayri resmi satışlarını tutacak bir yapı yok yapmayı da
düşünmüyoruz.
-Ama olur mu X firmasının muhasebe paketinde var bu olay. Misler gibi kaçırıyoruz vergiyi.
-Yıkıl, gözüm görmesin.
Tarzında Erdener Abi muhabbetleri çekeceğiz belki ama, eğer tüm firmalar belli kurallara uyarsa
eminim bir kaç sene içinde taviz alamadığını gören müşteri bu üç kağıtlardan vaz geçecek ve doğru
neymiş vicdanının sesiyle karar verdiğinde hem kendisi hemde vergi gelirlerini sosyal hizmetler için
kullanan devlet, refah seviyesini arttırmış olacaktır.
3.1.2 Nedir Benim Önerim?
Bu yazımdan sonra gelecek yorumları merakla bekliyorum. Bilirsiniz, padişahlardan biri

vezirlerine savaşa gidelim mi gitmeyelim mi, karar veremez tarzda bir soru sorar, vezirlerden bazıları
hemen sazan gibi atlayıp gitmeyelim yüce devletlüüüüm derler kimileri de gidelim tabi ne olacak der.
Gitmeyelim diyenlerin boynu vurulur ve savaşa gidilir.
Şimdi gelelim çözüm önerisine. Bu işin T.C. Maliye Bakanlığı eli ile yapılması gerekir. Maliye
Bakanlığı:
 30 kişilik usta mali müşavir/muhasebeci/müfettiş/personel bordro işlerinden anlayan bir

analiz ekibi,
 100 kişilik daha önce muhasebe ve personel yönetim paketi yazmış, yazılım firmalarında
çalışmış, muhasebe ve personel yönetiminden anlayan programcı,
 10 kişilik yüksek matematik bilgisine sahip uzman,
 100 kişilikte gene muhasebe ve personel bordro modüllerini kullanmış, piyasadaki
programlarda tecrübeli, test ekibi oluşturacak.
Bu 30 kişilik uzman takım bir muhasebe/personel bordro programı nasıl olmalı, tüm ayrıntıları
ile oturup bir analiz yapacaklar, Analizler tamamen ayrıntılı Modül Tabanlı Geliştirme (MTG/CBD
Component Based Development) CBD Head Quarter kurallarına göre yapılacak. Hiç bir gayri resmi işleme
izin verilmeyecek. Tabii ben sadece Muhasebe ve Personel Bordro üzerinde durdum ama bu modüller
çoğatılabilir.
Ekip, kendi içinde bölümlere ayrılarak yazılacak modülleri belirleyecek Örneğin muhasebe için
olacak ufak modüller: Hesap planı, Hareketler, Defter Basımı vs gibi modüller...10 kişilik matematik ekibi
programların ürettiği sonuçları matematiksel olarak ele alıp doğru sonuçların ortaya çıkıp çıkmadığını
kontrol edecek. Programı kullanacak firmanın, önünü görebilmesi için gerekli analiz raporlarını
hazırlayacak.100 kişilik test ekibi MTG kurallarına göre test yapacaklar ve programların doğruluğunu
ortaya koyacaklar. 30 kişilik uzman takım ve 10 kişilik matematik takımı ile koordineli çalışacaklar.
100 kişilik programcı ekibi de oturup bu programı geliştirecekler. Bu kişilerin özellikleri neler
olacak? Bu projeye seçilen kişiler özel güvenlik taramalarından sonra seçilecek. Güvenilirliği nasıl
kanıtlanacak? Öncelikle gelen başvurular değerlendirilerek içlerinden yukarıdaki şartlara uygun olanlar
seçilecek. Daha sonra bu kişiler yakın takibe alınacak. Bu iş için MİT’ten yardım alınabilir. 3 yada 4 ay
boyunca hem kişinin geçmiş sicil kayıtları hemde yaşam tarzından tutunda, arkadaşları ile ilişkilerine
varıncaya kadar irdelenmesi gerekiyor. Her aday için atanacak bir MİT görevlisi, adayın yakın
çevresindeki herkes ile görüşmeler yapacak, çeşitli anket formları doldurtulacak ve mümkün olan en
fazla bilginin elde edilmesi sağlanacak. Tüm bu işlemlerin sonucunda MİT bünyesindeki psikologlar ve
İnsan Uzmanları ile (eminim vardır) toplanan bilgiler tartışılacak ve kişiye bir rapor verilecek. Bu rapor
kişinin yüksek derecede sır tutabileceğini, güvenilir olduğunu, yüksek güvenlik gerektiren işlerde
çalışabileceğini onaylayan bir rapor olacak. (kahkahaları duyar gibiyim, gülmeyin bu işler yabancı
ülkelerde böyle dönüyor. Bkz. Security Clearance).
MTG yapısında programlanan bu programlar belli arayüzleri sayesinde herhangi bir ticari paket
programa tak-çalıştır yöntemi ile entegre olabilecek. Devlet tarafından yazılacak bu modüller tamamı ile
ücretsiz verilecek ve her yazılım firmasının bu modülleri kullanması teşvik edilecek veya zorlanacak.
(Tamam biraz sert oldu ama çıkar çevrelerinin cepleri boşalmaya başladığında ne kadar çatlak ses varsa
su üstüne çıkacağından emin olun.) Programın kaynak kodu sadece 100 kişilik uzman programcı takım
içerisinde olacak ve hiç bir şekilde firmalara verilmeyecek. Sadece yazılan modüller, arayüzleri açıklayıcı
bir döküman ile birlikte verilecek.
Bankalar ve SSK/Bağkur veritabanları ile ilişkili programlar olacak. SSK/Bağkur prim ödemeleri
direk banka hesabından SSK yada Bağkur’a yapılabilecek. Firmaların SSK ödediği çalışanları hiç bir şekilde
kredi kartı sahibi olamayacak onun yerine hesabındaki parayı özgürce harcayabileceği bir kartı olacak
(Debit Visa).
Maaş ödemeleri otomatik olabilecek, çalışanların banka hesaplarına otomatik ödenecek ve

şirket muhasebe kayıtlarında otomatik olarak muhasebeleştirilecek. Çalışan hesabına yatan maaşını
internetten zaten kontrol edebiliyor. Personel Bordro modüllerinde tüm bilgiler SSK veritabanında
tutulacak ama Muhasebe tarafı firma içinde bulunabilir. Tek bir muhasebe paketi olduğundan maliye
müfettişlerinin işi oldukça kolaylaşacak. Kontrol mekanizmaları için kurulacak maliye müfettişleri takımı
bu modülleri en ince ayrıntısına kadar bilecek ve bir firma göz altına alındığında gerekli raporlar çok hızlı
bir biçimde ortaya çıkacak. Yada her firma on-line olarak denetlenebilecek. Çeşitli alt ve üst limitleri aşan
firmalar anında olaya müdahale ile ortaya çıkabilecek, nedenleri araştırılıp, çözümler sunulabilecek. 10
kişilik matematik ekibi burada da devreye giriyor.
İşe giriş çıkış gibi işlemler on-line olacağından ve SSK ödemeleri tam olarak yapılacağından hem
devlet hemde sosyal güvenlik açısından bize yarar sağlayacaktır. İşe girişlerde evrak yetersizliğinden
dolayı SSK’ya geç kayıt olma ortadan kalkacak, daha sağlıklı ve düzgün bir işleyiş ortamı sunulacak.
İşe giriş çıkışlarda sadece yanınızda taşıdığınız bar-kodlu, çipli veya manyetik kodlu SSK kartınızı
Muhasebe bölümüne vermeniz yetecek. Geriye kalan tüm evrakların hepsi on-line olarak (ya şu on-line
kelimesine türkçe bir karşılık bulmak gerek) bulunacak ve tekrar adliye, sağlık ocağı, muhtarlık, gibi
makamlar boş yere meşgul edilmeyecek. Zaten Mernis Projesi ile başlayan vatandaşlık numarası gibi
olaylar bu tür alt yapılara hazırdır. Sağlık ocağı konusu ise şöyle halledilebilir. Sağlık ocağından alınan
belgenin süresi altı aydır ve her altı ayda bir sağlık ocağına gidilip kontrolden geçmek gerekiyor. Böylece
Sağlık ocağı veritabanlarında her zaman güncel bir sağlık raporunuz olacak. Aslında bu Sağlık Ocağı ayrı
bir proje olarak ele alınması gerekir fakat SSK tarafında yapılacak ufak değişikliklerle bu kayıtlar SSK’da
tutulabilir.
Yazılım firmaları muhasebe ve personel bordro paketleri ile uğraşmayacağı için başka konularda
kendilerini daha çok geliştirebilir, bu iki pakete harcanan kaynak ve zaman ile daha başka işlerde çok
daha başarılı olunabilir.
Tabii bu arada geliştirme yapılacak ortamın tasarlanması, MTG alt yapısına uygun araçların
seçilmesi, bilgisayar alt yapısının sağlıklı ve yeterli olması gerekiyor.Yazılan programlar ücretsiz
verileceğinden gelir yokmuş gibi görünüyor fakat modüllerin ortaya çıkması ve kullanılmaya başlanması
ile ülkenin kazanacağı geliri bir düşünün. Vergi kaçırma ortadan kalkmış, gayri resmi tüm işlemler yok
edilmiş, SSK ödemeleri tam olarak yapılıyor. Bence sırf İstanbul’da kullanılsa ve %50 civarında bir kaçak
önlense, yazılan programların tüm maliyetleri 2 sene içinde amorti edilir. Ondan sonrada devletin
kaçakları önlemedeki bu başarısı kâr yapmaya başlar.
İleriye dönük ve uzun vadede kâr yapacak bir proje fakat bir yerlerden başlamak lazım. Günlük
politikalarla ve yönetimlerle bu işlerin olmadığı aşikâr.
Personel Bordro modülünde devlet tarafından yapılan yasa değişiklikleri sonucu değişen kurallar
hemen uygulanabilecektir. Örneğin Nema uygulaması kalktığında, yasanın çıktığı gün herkesin bu yasayı
uygulaması sağlanabilir.
Daha bunun gibi pek çok yasa çıkarıldığı gün uygulamaya konulabilir.
Fena uçtum değil mi? Aslında hiç de değil. Siz buna uçmak diyorsanız bide benim öteki
projelerimi dinleyin.
3.2 Agile Modelleme Değerleri
Çevik Modelleme Scott W. Ambler tarafından Extreme Programming değerleri göz önüne
alınarak geliştirilmiş ve içine “alçakgönüllüğün” eklenmesi ile son halini almıştır. Extreme Programming
değerleri iletişim, basitlik, geribildirim ve cesaret değerlerinden oluşur. Çevik Modelleme yazılım
geliştirme açısından uyulması gereken kuralları ortaya koyar ve destekler.
Şimdi bu değerlere bir göz atalım:
3.2.1 İletişim
Projede yer alan herkes arasında çok iyi bir iletişim olmalıdır. Başarılı yazılım geliştirme'nin
birinci gerekliliği budur. İletişim, sözlükte yazdığı kadarı ile kişiler arası belli işaret, hareket veya
sembollerle bilgi alışverişi yapılan genel sistemin adıdır. İletişim iki yollu bir sistemdir. Her iki tarafta bilgi
sunar ve kazanır. İletişimde aksamalar ortaya çıktığında problemler de ortaya çıkar. Örneğin, bir yazılım
uzmanı kendi yazdığı bölümün henüz tam olarak bitmediğini iş arkadaşlarına söylememesi başka bir
yazılım uzmanının bu problemi ortaya çıkartmak için ekstra zaman harcamasına neden olabilir.
Yazılımcılar yazacakları sistemin prototipini müşteriye sunarlar ama müşteri onun prototip olduğundan
haberdar değildir ve gerçek sistemin hazır olduğunu zanneder.
Durup düşündüğünüzde modelleme işleminin aslında iletişimi arttırmak ve geliştirmek için

yaptığımızı görürüz. Müşteriniz, pek çok iş kuralından oluşan karmaşik bir iş yapısını anlatırken sizin
mantığı anlatan bir veri akışı şeması çizmeniz, işlemi anlamınızı kolaylaştıracaktır. Genellikle, konu
hakkında beş dakikada cizeceğiniz bir model, o konu hakkında 5 saat okumaktan veya tartışmaktan cok
daha fazla sey öğretecektir. Modelleme, kendi fikirlerinizin daha rahat anlaşılmasına, başka kişilerin
fikirlerini daha rahat anlamanıza ve en sonunda genel olarak tüm iş hakkında genel bir kanı oluşmasına
neden olur.
3.2.2 Basitlik
Pek çok yazılım kitabı basitlikten söz eder fakat içerisinde geçen konulara ve metodlara
baktığınızda, yazılım geliştirme işini zorlaştırdığını görürsünüz. Genellikle yapılan yanlışlar şunlardır.
Karmaşık yapıları erken uygulamak: İhtiyaç olmadan modellenen karmaşık yapılar, yazılım
uzmanlarının fazla mesai yapmalarına neden olur. Karmaşık yapıların yavaş yavaş sindirilerek ve
parçalara bölünerek modellenmesi ve en gerekli kısmının ilk olarak yazılması gerekir. Müşterinize
vereceğiniz ilk sürümde, hayati önem taşıyan modüllerle ve en az hata ile ortaya çıkmalısınız.
Gereklilikler ortaya çıktıkça, müşteri de ne istediğini daha net görecek, belkide karmaşik bir modülü
programlamaktan kurtulacaksınız.
Gelecekte kullanılacak bölümler için fazladan modelleme/kodlama yapmak: Şu anda üzerinde

calıştıgınız bankacılık sisteminin, hayat sigortalarını destekleyebilmesi için belkide sadece bir günlük bir
modelleme gerekiyor, Neden yapmayalimki? Evet, bu sistemi modellemek oldukça zevkli olacaktır fakat
yazılımınızı bugün olduğundan daha karmaşik bir yapıya sokmayacak mı?Yada yazılım uzmanlarınız
gelecekte olacak değişikliklere cevap verebilmek veya her isteğe cevap verebilecek en iyi yazılımı yapma
egosu ile çok fazla modelleme ve kodlama yapma eğiliminde olabilirler. Müşteri isteklerini anlayarak,
olabilecek en basit, en verimli, en ucuz çözümü sunmak hedefimiz olmalıdır. Yarının problemlerini yarın
çözmeliyiz. Eger bugünden en basit çözüm üzerinde çalışırsak, yarın yeni bir fonksiyon eklemeye
kalktığımızda elimizdeki sistem çok basit olacaktır.
Karmaşık altyapılar geliştirmek: Proje ekiplerinin yaptığı genel hata ilk aşamada gelecekte
kullanmak üzere geliştirdikleri modüller, sınıf kütüphaneleri ve iskelet yapılardır. Amaç bu parçalar lazım
olduğunda elimizin altında olmasıdır. Fakat bu amacın ciddi zararları vardır. Öncelikle müşterinizin
kaynaklarını, onlara elle tutulur bir ilk sürüm vermeden harcamış oluyorsunuz. Müşteriniz sizden bazı
işlerini kolayca yapabileceği bir sistem istiyor fakat sizin ilk verdiğiniz şey hata-yakalama alt yapısı.
Projenizi, hızlı ve kullanılabilir bir fonksiyonellik sunmadığınız için riske atıyorsunuz. Ayrıca hata-
yakalama gibi alt-sistemleri projenin gidişatı içerisinde zamanla da geliştirebilirsiniz. Sadece ihtiyacınız
gerçekten ortaya çıktığında.
3.2.3 Geribildirim
Yaptığınız işin doğru olup olmadığını anlamanın tek yolu farklı kişilerin geliştirdiğiniz sistem
üstünde test yapmaları ve sonuçları paylaşmanızdır (geribildirim). Testi yapan kişilerden sonuçları doğru
zamanda alıp sebeplerini kısa zamanda bulmak çok önemlidir. Analizler sonucu ortaya çıkan
modellerinizin doğru olup olmadığını ancak bu şekilde anlayabilirsiniz.
Modellemeyi takım halinde yapın. Yazılım geliştirme işi yüzme gibi değildir. Tek başına yapmak
tehlikelidir. Diğer kişilerle beraber çalıştığınızda sonuçlara daha hızlı ulaşır, problemlerin sebeplerini
bulmak için zaman kaybetmemiş olursunuz.
Modelinizi doğru kişilerle inceleyin. Modellediğiniz işin, o işten anlayan kişilerle birlikte
incelenmesi gerekir. En güzeli modelleme sırasında bu kişilerin işin içinde olmasıdır. Gereksinim
modelleri son-kullanıcı ile beraber yapılmalı, detaylı tasarım modelleri ise programlamayı yapacak kişiler
ile yapılmalıdır. Resmi toplantılar halinde düzenlenmesi ve proje başında ayda veya haftada bir
yapılmalıdır. Eğer bu mümkün değilse (organize etmesi zaman alır)gayri resmi hızlı toplantılar ile
yapılacak incelemeler modellerinize çok şeyler katabilir.
Modelin uygulanması. Eğer hiç bir şekilde bir toplantı ayarlayamıyorsanız, modelinizi doğrudan
koda döker ve ilk sürümden sonra gelecek sonuçları beklersiniz. Önemli olan testlerin zamanında
yapılabilmesi ve hataların hızlı olarak sebeplerine ulaşabilmektir.
Kabul testleri. Esas olarak modellerinizin müşteri isteklerini yansıtıyor olması gerekir. Müşteriniz
kabul testleri sırasında bu isteklerini değerlendirir ve geri dönen hatalar ile gene modellerinizi test etmiş
olursunuz.
Geribildirim olayında zaman kavramıda çok ilginçtir. Bir takım halinde çalıştığınızda, geribildirim
saniyeler yada dakikalar içinde olabilmektedir. Gayriresmi toplantılarda ise geribildirim dakikalar yada
saatler alabilmektedir. Resmi toplantı geribildirimleri toplantı sırasında gelsede zaten organize etmesi
haftalar, aylar alabilmektedir. Uygulamayı yapıp ilk sürümü verdiğinizde geribildirim saatler yada günler
içinde olur. Kabul testlerinden sonra geribildirim bir kaç hafta yada ay içerisinde gelir.
Zaman ne için önemlidir? Çünkü kısa zamanda gelen geribildirim, sizin modellerinizden sapma
olasılığınızı düşürür. Takım halinde çalışmanın en büyük yararı geribildirimlerin hızlı olmasıdır. Yada kağıt
üzerinde mükemmel görünen modelin kodlanması ve ilk sürümden sonra gelecek geribildirimlerin
işlenmesi de metod olarak düşünülebilir.
3.2.4 Cesaret
Arkanıza rahatça yaslanıp genel durumu kabul etmek ve bir şeyleri geliştirmeyi, düzeltmeyi
denememek yada birisinin çıka gelip hataları düzeltmesini beklemek çok kolay bir iştir. BT endüstrisinin
bugünkü aksayan taraflarında cesaretsizliğin büyük payı vardır. Çevik Metodolojisi size diğer insanlarla
beraber çalışmanızı, onlara güvenmenizi ve kendinize güvenmenizi öğütler. Bu cesareti arttırır. XP veya
Çevik Modelleme, yapabileceğiniz en basit modeli yapmanızı söyler, çünkü yarının problemlerini yarın
çözmek gerekmektedir. Çevik Modelleme, gerçekten dökümantasyona ihtiyacınız olduğunda döküman
yaratın der. Beyaz tahta yada not defteri gibi en basit araçları kullanarak modelleme yapmanızı öğütler.
Karmaşık yazılım araçlarını ancak olabilecek en yüksek yararı elde edebileceğiniz zaman kullanmanızı
öğütler. Modelerimizin daha iyi görünmeleri için zaman harcamamızı öğütler. Birlikte çalıştığınız kişilere
güvenmenizi, yazılım uzmanlarınında tasarım aşamalarında karar verebileceğini söyler. Tüm bu
söylediklerimizin hepsi cesareti arttırır. Cesaretli ekipler, denemekten ve yanılmaktan korkmaz.
Sonuçlara daha hızlı ulaşılır ve kat edilen yol daha uzun olur.
Düşünün, firmanızda Modul Tabanlı Analiz ve Geliştirme kurallarını uygulamak istiyorsunuz

fakat endişeleriniz var. Seçim için cesaret gerekir. Her işin her sektörün belirli riskleri vardır fakat
risklerden kaçmak olsa olsa daha büyük risklere yakalanmanıza neden olur (yağmurdan kaçarken doluya
tutulma kuralı). Cesaretli olmak sizinde hata yapabileceğinizi anlamanıza yardımcı olur. Denemekten,
yanılmaktan ve deneyim kazanmaktan korkmayın.
3.2.5 Alçak Gönüllülük
En iyi yazılım uzmanı her şeyi bilmediğini kabul edecek kadar alçak gönüllü olandır. Gelmiş
geçmiş en iyi Java yazılımcısı olabilirsiniz fakat her bir Java API'sinin detaylarını tek tek bilmiyor
olabilirsiniz. Çok iyi Java bilmeniz, çok iyi arayüz tasarımlama yada mükemmel veritabanı tasarımcısı
yada en iyi müzisyen olduğunuz anlamına gelmez. Sadece çok iyi Java bildiğiniz anlamına gelir. Çok iyi
Java bilmeniz, yeni başlayan çıraklardan hiç bir şey öğrenemezsiniz anlamına da gelmez.
Çevik Modelleme ve programlama yapan kişi proje ekibindeki herkesin bir uzmanlık alanı
olduğunu bilir ve ancak diğer kişilerin yardımı ile kendi işlerinin başarılı bir biçimde biteceğini
görür.Alçakgönüllülük, diğer kişiler ile birlikte çalışmayı imkan dahilinde kılar. Çevik Modelleme yapan
kişi diğer proje elemanlarının farklı deneyimlerinin olduğunu, kişisel pek çok farklılıklar olduğunu bilir ve
saygı ile hareket eder. Patronları "yüksekte oturan kargalar", son kullanıcıları "aptal kullanıcı", diğer
departmanları "kafayı yemiş" olarak değerlendirmek iletişim problemlerine yol açar, iletişimsizlik
projenizi sekteye uğratabilir. Zaman ve kaynak kaybından başka bir şey olmadığı sizde görüyorsunuz.
3.2.6 Bu Yazının Amacı
Burada anlatılan modelleme kültürü CBD, UML ve eXtreme Programming ile analiz ve
modelleme yapan projeler tarafından benimsenmeye başlamıştır. Çok yeni olması nedeni ile tamamen
geliştirmeye ve deiştirmeye açık bir konudur.
Bu yazıyı Scott W. Ambler'in Agile Modelling (ISBN 0-471-20282-7) isimli kitabından, sizin bu
konuları duymanızı sağlamak ve hafızalarınızda birer ışık yakmak amaçlı olarak çevirdim.
Bir kaç yararlı link:
http://www.xprogramming.com/
http://www.extremeprogramming.org/
http://www.ambysoft.com/ Scott Ambler'in web sitesi
3.3 Düşüncelerim
Otobüsle işe giderken hep fantastik düşüncelere dalarım. Program yazmanın geleceğini, bugün
emekleme aşamasında olan teknolojilerin ileride nasıl olacağını tahmin etmeye çalışırım. Yeni çıkan
Microsoft’un ağ hizmetleri veya Sun Microsystems’in Java teknolojileri gibi sistemler yazdığımız
programların farklı platformlar üzerinde çalışabilmelerini sağlıyor. Ayrıca farklı teknolojiden sistemlerin
ortak dillerle konuştuğunu ve veri alışverişi yaptığınada tanık oluyoruz. Yazdığınız programlardaki
fonksiyonlar zaten başkaları tarafından biryerlerde yazılmış ve sizin kullanmanızı bekliyor. Bir gün
gelecek ve program yazmak artık şema çizer gibi mevcut ağ hizmetlerini yada java bean programlarını
birbirlerine bağlamaktan ibaret olacak. Kullandığınız yazılım aracı örütbağ üzerinde mevcut her web-
service’in veya java-bean’in yerini ve nasıl kullanılacağını gösterecek ve ayrıca bu iki sistemi birbirine
bağlamak için gerekli kodu da araç kendi üretecek. Siz sadece şematik olarak modülleri birbirine
bağlayacak ve ortaya sadece bir kaç fonksiyon çağıran ve geri dönen hata mesajlarını derleyen bir
program çıkacak.
Örneğin özel bir firma için hayat sigortası modülü yazıyorsunuz. Hizmetlerini kullanacağınız
birimler SSK, Nüfus müdürlüğü, diğer sigorta firmaları, bankalar ve yabancı ülkelerin sosyal güvenlik
birimleri. Kullandığınız yazılım aracı tüm bu birimlerdeki kullanılabilir modülleri gösteriyor. Hayat
sigortası için gerekli müşteri bilgilerini SSK’nın sunduğu ağ-hizmetinden alıp kendi veritabanınıza kayıt
edeceksiniz ve kişinin ödediği tüm SSK primlerinide SSK fonlarından alıp özel şirketin fonlarına
aktaracaksınız, bu arada da kişinin diğer bir özel sigorta firmasındaki tüm sigorta bilgilerini kendi
tarafınıza alacaksınız tabii ödediği primleri de. Nüfus müdürlüğünün hizmetlerini kullanarak kişinin
ailesinde bir hastalık varmı araştıracak ve ödenecek primleri ona göre otomatik ayarlayacaksınız.
Çalıştığınız bankanın servislerini kullanarak para transferleri gerçekleştireceksiniz. Modüllerini
kullandığınız birimler sundukları hizmetin ücretini otomatik olarak firmanın hesabından trasfer
edecekler. Yabancı ülkelerin sosyal güvenlik modüllerinden kişinin yurt dışında çalışma günlerini ve
ödediği primleri görüp kendi primlerinizde parametre olarak kullanacaksınız. Tüm bu sistemi yazmak
(modelleme + yazılım) 1 gününüzü alacak. Kağıt, mürekkep, iş gücü kaybı, gibi masraflar ortadan
kalkacak ve çevre korunmuş olacak. Bu bir avantaj ama her türlü bilginin sanallaştırılması ve tüm
sistemin bilgisayar ortamına sokulması da bir dezavantaj. Bir firmayı yada ülkeyi ortadan kaldırmak
istediğinizde sunucularını uçurmanız yeter.
Tüm bilgi sanallaştığında orjinalliğide bozulabilir. Örneğin tüm tarihi bilgiyi sanal ortama
kaydettiğimizi düşünelim. Çoklu ortam -ses ve görüntü ile- öğrenilebilme kapasitesi oldukça artar fakat
değiştirilebilmesi çok kolay olacağından, bilginin orjinalliğini koruması çok zor hatta imkansızdır. Ancak
tek bir yolla bilgi bozulmayabilir. İyi bir bilgi koruma algoritması ile. Kuran-ı Kerim’in şifrelendiği 19
sayısını duymuşsunuzdur. 200’e yakın farklı yolla yapılan hesaplamaların sonuçları hep 19’un katları
olmaktadır. Böylece içerik üzerinde oynama yapıldığında kolayca anlaşılmaktadır. Buradan yola çıkarak
bilginin hem herkes tarafından kolayca ulaşılabilmesini hemde değişmeden hayat sürecine devam
edebilmesini sağlayacak şifreleri geliştirebiliriz. PGP gibi programlar ile bilginin içeriğini şifrelemiyoruz
sadece bilgi içine yerleştirdiğimiz bazı kelimeleri veya harfleri sayarak elde edeceğimiz sonuçların
doğruluğunu karşılaştırıyoruz. Var mı böyle bir program yazacak bir arkadaş. İşte size çok güzel bir proje.
İnsan ilişkilerinin diğer ülkelere göre daha yakın ve samimi olduğu ülkemizde bu tür bir
sanallaşma pek mümkün gözükmüyor. Gözükmesin de. Ben örütbağından alış veriş yapmayı hiç sevmem.
Zaten yapamamda çünkü kredi kartı kullanmaya karşıyım. Örneğin bir gitar alacaksam, gitar satan
dükkanları bir gezmek ve beğendiklerimi çalmak isterim. Dükkan sahibi ile oturup bir çay içmek ve gitar
hakkındaki görüşlerini almak isterim. Bir kaç tane reklama kanıpta kafamda belirli bir marka yada model
ile yola çıkmam yani. Bu kadar sosyalleşmeyi monitör karşısında yaşayamayacağım için sanal alışverişi
tercih etmem. Bence firmalar sanal alışveriş sitelerine harcadıkları yatırımı elemanlarına ve dükkanlarını
geliştirmeye harcasalar daha fazla kazanırlar.
“Bu kadar konuşuyorsun da sende bu mesleğin içindesin” dediğinizi duyar gibiyim. Bu düzen
içerisinde yaşıyoruz ve düzenin gereklerine göre hareket etmezsek elde edeceğimiz deneyim azalır.
Tapınaklara kapanıp dünya malından elini eteğini çekip ruhunu Allah’a erdirebilirsin ama önemli olan bu
savaşı şehir hayatı içinde otobüsle işe giderken vermek.
Durak geldi ben iniyorum.
3.4 Programlamaya Yeni Başlayacaklara
Merhaba, bu yazımda sizlere temel konulardan bahsetmek ve programlamaya yeni adım atacak
arkadaşlar için yol gösterici olacak bir kaç fikirden söz etmek istiyorum. Amacım yeni başlayan pek çok
kişinin sorduğu sorulara cevap vermek ve cesaretlendirerek yollarına devam etmelerini sağlamaktır.
3.4.1 Programlama Dili Seçimi
Nasıl tek bir dil bilmek yetmiyorda insanlar İngilizce, Almanca ögreniyorsa bilgisayar dünyasında
da tek bir dil bilmek yetmiyor. Günümüz programlama ortamlarında farklı dillerle yazılmış parçaları
beraber çalıstırabilmek mümkün olduğu için, en az iki programlama dili bilmeniz iyi olur. Dilinizi seçerken
soracağınız sorular:
1. Ürününüz birden fazla işletim sistemini destekleyecek mi?

2. Ürününüz web, istemci/sunucu, tek başına calışabilecek biçimde tasarım edilecek mi?
3. Ürününüz en son yazılım tekniklerini ve teknolojilerini uygulayabilir mi?
4. Kullanmayı düsündüğünüz veritabanlarını destekliyor mu?
5. Yazılım aracı/dili için eğitim verecek kuruluş var mı?
6. Diploma, sertifika veriliyor mu?
7. Dünyada başka kimler kullanıyor?
8. Örütbağında arama yaptığınızda kaç tane sonuç dönüyor?
9. İş bulma sitelerinde, sizin düşündüğünüz yazılım aracı/dili ile ilgili ne kadar iş ilanı var.
10. Ürününüzü dünya genelinde satmayı düşünüyor musunuz?
11. Araç/dil bu tasarıma izin veriyor mu?
12. Yazılım aracı/dili üreten firma ile birlikte başka hangi firmalar bu araca/dile destek
veriyor.
13. Ne kadar para harcamayı düşünüyorsunuz?
Buradaki araştırmaların hepsini Türkiye çapında değil dünya çapında yapın. En son sürümleri ve
teknolojileri satın almaya bakın.
İkinci dil ile ilgili olarak tamamen karşıt bir firma/teknoloji seçin. Mesela VB ve Delphi, Java ve
C++, C# ve Perl, PHP ve XML vs. İşletim sistemini de değiştirebilirsiniz. Mesela Linux/Kylix ve
Windows/C++, Unix/Python ve Windows/XML, Linux/PHP ve Windows/HTML vs. Listeleri uzatmak

mümkün.
3.4.2 Nasıl Başlanır
Dilinizi seçtikten sonra ilk yapacağınız iş, ortama olan göz alışkanlığınızı kazanmak için
menülerde ve ekranlarda gezinmeniz olacaktır. Burada ortam dedigimiz programlama yaptığınız dilin
arayüzü olan IDE (Integrated Development Environment, Tümleşik Geliştirme Ortamı) hakkında bilgi
sahibi olmak ve menülerde ne nerede bilgisini oluşturmaya çalışıyoruz. Eğer İngilizce biliyorsanız
menüler üzerindeyken F1 tuşu ile yardım alabilir ve ne işe yaradığını öğrenebilirsiniz. Bundan sonra
baslangıç seviyesi kitapları ile yola çıkarak adım adım dili öğrenmeye başlarsınız. Kitap dişinda deneme-
yanılma yolu ile küçük projeler yapıp, dilinizin nelere imkan verdiğini ögrenebilirsiniz. İlk başlarda cok
fazla zaman harcayarak mümkün olan her şeyi deneyin. Belli bir seviyeye geldikten sonra, belli konuları
daha derin öğrenmeye başlarsınız. Dili biraz ögrendikten sonra bıranşlaşma için, veritabanı, donanım,
sistem, ticari programlama gibi konulara eğilebilirsiniz.
3.4.3 Kitaplar
Her yeni başlayana tavsiye ettigim yazarlar, İhsan Karagülle, Memik Yanık, Zeydin Pala dışında
kullandığınız dilin üreticisinin kitapları yada 3. parti firmaların kitapları çok yararlı olabilir. İlgilendiğiniz
konularda referans kitaplarınızın bulunması ve ihtiyacınız olduğunda konu başlıklarını kullanarak yardım
almanız çok iyi olur. Eger merkezlere uzak yerlerde oturuyorsanız örütbağ üzerinde sipariş
verebileceğiniz yerler oldukça fazla. Aldığınızın kitapların yayinevlerinin sitelerinden kitapla ilgili
düzeltmeler var mı kontrol edin. Kitapların pek çoğuna pdf formatında da erişebilirsiniz. Benim tercih
ettiğim bir yöntem çünkü yerden tasarruf sağlıyor.
3.4.4 Örütbağ Üzerinde
E-posta listeleri çok yararlıdır ve teknolojileri günlük takip etmenizi sağlar. Özellikle Microsoft,
Rational, IBM, CA, Inprise gibi büyük firmaların gazete e-postalarına üye olmanızı tavsiye ederim. Bu
sayede yeni ürünler çıktığında veya seminerler olduğunda hemen haberiniz olur, ayrıca gidip bu
firmaların sitelerinde debelenmekten kurtulursunuz. Haber sunucuları, programlamaya özel siteler'de
işinizi görür. Önemli olan bir şekilde teknolojileri takip etmek ve güncel konulardan haberdar olmak.
Yahoo, Google gibi sitelerin gruplarına da bakabilirsiniz. Hangisinde daha fazla üye ve mesaj varsa ona
üye olun.
3.4.5 Teknolojiler
Seçtiginiz programlama dili ile son teknolojileri uygulamak mümkün mü? Fazla kod değişikliği
yapmadan hem internet ortamnı hem istemci/sunucu yapılarını destekleyebiliyor musunuz? Yada daha
da önemlisi seçtiginiz dil ile, bitmek tükenmek bilmeyen müşteri isteklerine cevap verebilecek misiniz.
Platformlar arası veri alışverişi konularına destek veriyor mu? Hangi veritabanlarını destekliyor? Yada
sizin istediğiniz veya kullanmayı düşündüğünüz veritabanını tam olarak destekliyor mu? Teknoloji
demekle neyi kastediyoruz. ActiveX, SOAP, COM, DCOM, COM+, .NET, Web Services, RMI, IIOP, TCP/IP
vs. gibi pek çok metod bahsettigimiz teknoloji alanına girer. Seçtiginiz dil ile bu teknolojilerden bazılarını
desteklemek istiyor musunuz?
3.4.6 Analiz
Program yazarken kullanacağınız analiz metodolojileri en az kodlama yapmak kadar önemlidir.

İster yolun başında bir programcı adayı olun ister programlama konusunda uzman olun metodoloji ve o
metodolojiyi doğru uygulamak çok önemlidir. İyi yazılım, iyi bir analiz ile başlar. Analiz sizin programınızla
neler yapacağınızın ve müşterinin problemlerine nasıl çözüm getireceğinizin bir taslağıdır. Analiz iş
senaryolarınızı ortaya çıkarmanızı ve müşteri isteklerine daha iyi cevap vermenizi saglar. Analiz
Metodolojileri nelerdir? Örneğin Modül Tabanlı Analiz (CBD, Component Based Development), Nesne
Tabanlı Analiz (OOA, Object Oriented Analyse), Unified Modelling Analiz (bunun Türkçe'sine UM Analiz
diyelim, pek iyi olmadı ama!), eXtreme Programming (Yazılım dünyasında XP olarak biliniyor fakat
Windows XP ile karıştırmayın). Bu metodolojileri doğru biçimde projelerinizde uygularsanız verimlilik ve
zamanında yetiştirmek açısından pek sorununuz olacağını zannetmiyorum. Yukarıda bahsettiğim
konuları tek tek açıklayan makaleler de yazacağım.
3.4.7 Düzenli Çalışma
Kendinize bir hedef vermeden bilgisayarın başına oturmayın. Hedefinizi belirleyip ona göre yol
alın. Projelerinize hep bir isim verin ve anlamlı bir isim verilmiş bir dizine kaydedin. Formlarınızın
isimlerini ve başlıklarını muhakkak değiştirin. Bu sayede farklı formları farklı projelerde kullanmak
istediğinizde isim çakışmaları olmaz. İsimlerden formlarınızın ne işe yaradığını kolayca anlayabilirsiniz.
Her yiğidin bir yoğurt yiyişi olduğu gibi yazılım gruplarınında uyulması gereken kuralları vardır. Bir yazılım
firmasında çalışmaya başladığınızda, ilk yapacağınız şey firma standartlarını öğrenmektir. Bu sayede ekip
içi bilgi aliş verişi hızlı ve kesin olur.
3.4.8 Dökümantasyon
Yaptığınız çalışmaları, ufak projeleri kısacası ileride kullanabileceğiniz her kod parçasını yazıya
dökün ve ne işe yaradığını, nasıl calıştığını, amacının ne olduğunu ister kodun içine yorum satırı olarak,
ister bir Word dosyasına yazarak saklayın. Hangisi pratik geliyorsa. Bu tür bir çalışma ileride bir kod
parçasına ihtiyacınız olduğunda kolayca bulmanızı sağlar.
3.4.9 İngilizce Kaynaklar
Yabanci dil bilmek pek çok konuda işimize yaradığı gibi, programlama konusunda da işimize
yarayacaktır. Fakat öyle sular seller gibi bilmeye veya konuşurken aksanlı konuşucam diye ağzımızı
burnumuzu bükmeye gerek yok. Sonuçta bizler Türk'üz ve konuşurken yabancı olduğumuzun
anlaşılmasıda gayet doğal ve gereklidir. Yabancı dil bilgimiz, konumuzdaki yabancı yayınları takip edecek
ve derdimizi anlatabilecek kadar olsa yeter. Bu nasihatlerden sonra gelelim yabancı yayınlara, örütbağı
üzerinde bir arama ile pek çok yayına ulaşabilirsiniz. Bunların dışında Microsoft yayınları ve kitapları,
Wrox yayınevinin kitapları, Visual Studio ile gelen MSDN (Microsoft Developer Network, Microsoft
Geliştirici Ağı) tıkızları çok işinize yarayabilir. Inprise ürünleri ile birlikte gelen yardım dosyalarıda çok
yararlı olabilir. Ek olarak firmaların sitelerinde her zaman deneme sürümlerinin tıkızlarının adresinize
postalanması için gerekli formları bulup doldurabilirsiniz. Ayrıca pek çok teknik dökümanı, gerçek
projeleri, egitimle ilgili yazıları bilgisayarınıza indirebilirsiniz. Firmaların Türkiye temsilciliklerinden birer
bağlantıya sahip olmanızda iyi olur.
3.4.10 Kurslar
Kursların piyasa tarafından tanınmış ve verdikleri sertifikaların dünya çapında geçerli olmasına
dikkat edin. Çalışmalarınızın kurs ile sınırlı kalmaması için, evinizde de bazı projeler geliştiriyor olmanız
gerekir. Türkiye'de çoğu büyük şehirlerde pek çok kurs mevcut. Kurs ile birlikte çevrenizde oluşacak
arkadaş grubu iyi bir yönlendirme ile birlikte iyi projelere imza atabilir. Unutmayın çevrenizdeki grup
ileride iş arkadaşlığına dönüşebilir.
3.4.11 Amatör Ruhu
Hangi işle uğraşıyor olursanız olun, dünyanın en kötü şeyi, ugraştığınız alanda her şeyi bildiğinizi
iddia etmek olacaktır. İşte bu tür adamlardan uzak duracaksınız. Hayat zaten kendi içinde bir okul
bizlerde bu okulun ögrencileriyiz. Her zaman öğrenecek yeni şeyler olacak. Bazen hiç ummadığıniz bir
çıraktan bir şeyler kapabilirsiniz. Yada artık kendinizi programlama hakkında ermiş olarak gördüğünüz
anda bir çırak çıkıp algoritmalarınızın şöyle şöyle yaparsanız daha hızlı çalışacağını söylemesi sizi yerin
dibine sokabilir. Ne yapmak gerekir, çırağı karşınıza alıp teoremleri hakkında konuşursunuz ve sonuçta
gerçekten haklıysa dediklerini uygulayıp dersinizi alırsınız. Daha sonra bu dersi baska çıraklara aktarmak
üzere tabii. Ögrenmekten ve doğru bildiğiniz şeylerin aslında yanlış olduğunu anladığınızda
değiştirmekten çekinmeyin. Yanlışları bulan kişileri tebrik edin ve daha fazla yanlış bulmaları için
yönlendirin. Ancak bu şekilde ilerleme kaydedebiliriz.
3.4.12 Ben Neler Yapıyorum
Gelelim bu kadar bilgiden sonra ben bunları ne kadar uyguluyorum. Dil olarak seçimlerim
VB.NET ve C#. Bunlarla birlikte XML ve SOAP, Web Services gibi teknolojileri öğrenmeye çalışıyorum.
İşletim sistemi olarak, Windows ve Red Hat Linux ortamlarını seçtim. Web Sunucu için Linux üzerinde
Apache Web Server, Windows üzerinde IIS kullanıyorum, bir yandan ASP.NET ile takılırken diğer yandan
Linux üzerinde Java Bean ve EJB nasıl yayınlanır araştırıyorum. İlerde Java dilini de oğrenme planım var.
Veritabanı olarak Linux/IBM DB2 ve Windows/SQL Server kullanmaya çalışıyorum. UML, OO, CBD
metodolojilerinde de calışmalarım var. Araç olarak, Rational, CA, Microsoft, IBM, BEA ürünlerini
kullanıyorum. Tabii ki tek bilgisayar yetmiyor. En az 3 adet lazım, bir tanesi çift işletim sistemli ve hepsi
ağ ile birbirine bağlı. Bilgisayarlardan birini çöpten buldum.
Sizde böyle bir sistemi bir kaç arkadaş birleşip kurabilirsiniz. Birde rahatça girip çikabileceğiniz
bir oda buldunuz mu, iş proje bulmaya kalıyor. Mahallenizdeki esnaf ile hiç bu konuları konuştunuz mu?
Toplumumuzun gelişmesi ve yeni şeyleri ögrenmesi birazda size bağlı. Mahalle esnafına bilgisayardan ve
özel yapıışlmis programların yararlarından bahsettiniz mi? E-posta, internet, işletim sistemi gibi
konularda onları bilgilendirmeyi hiç düşündünüz mü? Biraz da misyonerlik gibi bir göreviniz var aslında.
Etrafınızdaki insanlara bildiklerinizi aktarmayı hiç düşündünüz mü?
3.4.13 Sonuç
Yukarıda anlattığım yöntemler her yazılımcının alet çantasını geliştirmesi için çok güzel
yöntemler. Fakat nasıl evinizde bir tamirata giriştiğinizde alet çantasındaki her aracı kullanmıyorsanız,
yazılımcı olarak alet çantanızı da o şekilde kullanacaksınız. Öğreneceğiniz her bilgi alet çantanızda yerini
alacak ve yeri geldiğinde çıkarıp kullanmaktan çekinmeyeceksiniz. Bu arada aletlerinizde gelişmeler de
olabilir, zaman içerisinde bazıları yok olabilir. Önemli olan sürekli devinim içinde ögrenmeye ve
gelişmeye açık olmaktır.
3.5 Extreme Programlama
Her yazılım geliştirme metodu temelinde kullanılabilir, hatasız ve müşteri gereksinimlerini tam
olarak karşılayan bir ürün üretebilmek için ortaya çıkmıştır. Bir bakıma dinler gibi hepsi temelinde iyiye
ve doğruya yöneltmeye çalışır insanları ve bu yolda uygulanması gereken bir dizi kuraldan bahseder.
Yazılım geliştirme metodlarında sonradan eklenen çeşitli yöntemler ile metod artık takip
edilmesi ve öğrenmesi zorlaşmış bir hal alır ki bu da projelerin uzamasına ve onaylama mekanizmalarının
çok zaman almasına neden olur.
Neyseki din değiştirmek kadar katı olmadığı için kullanılan metodu degiştirebilir veya farklı
metodların çeşitli kısımlarını bir araya toplayarak yeni bir olgu yaratabiliriz.
Yapısı oturmuş bir firmada metod değiştirmek zor olacaktır. Ve heleki yaşı ilerlemiş ve firmada
masa, sandalye gibi demirbaş listesine girmiş elemanlar varsa işiniz daha da zor. Kendi istedikleri olsun
da patrona “en çok ben biliyorum” gibi gözükeyim konusundan başka dertleri yoktur bunların. Birde tabii
adamın dinini değiştirmek istiyorsunuz bir bakıma. Yıllardır takip ettiği ve yazılım geliştirdiği metodu
değiştiriyormuş gibi gelecektir ona. Aslında farkına varsa sadece ufak eklentiler olduğunun, her şey daha
da kolay olacak.
Birden bire yazılım geliştirme metodunu değiştirmek istediğinizde direnişlerle karşılaşabilirsiniz.

Bunun için ufak paketler halinde değişiklikleri sunmalı ve işe yaradığının ispatını diğer çalışanlara
kanıtlamalısınız.
Eski metodun bir kısmını “tamamı ile değiştirmek” yerine (yada en azından bu cümleyi
kullanmak yerine) “değişiklikler ile güncellemek” daha iyi bir yöntem olacaktır. Yapılan işin ismini aynı
bırakın fakat işleyişini değiştirin. Getirmeye çalıştığınız metodun ismini ise kesinlikle kullanmayın. “Ben
burada Extreme Programming metodunu uygulayacağım artık” derseniz baştan kaybedersiniz. Bunun
yerine sebep sonuç yasasını kullanın. Eger sebepler metodu değiştirmeniz için bir sinyal veriyorsa, işleyişi
değiştirip sonuçlarında yapılan kara bakın ve daha iyi bir metod olduğunu herkese kabul ettirin.
Extreme Programming ismi kulağa uzaydan düşme bir isim gibi gelsede içerik olarak uygulanan
metodların günümüzde kullandığımız metodlardan pek farkı yok. Bir miktar da insanın kendi özverisi ile
zaten uyguladığı şeyler. Bu tip mevhumları ögretemezsiniz zaten, insanın kişiliğinden gelen şeylerdir.
Ama görsel olarak uygulayabileceğiniz pek çok XP yöntemi mevcuttur.
Narsistlik yapıp sadece kendini düşünen kişiler olacaktır. Onlara hak da veriyorum çünkü
kendilerini satabilecekleri tek hünerlerini diğerlerine ögretmesini istiyorsunuz. Kişinin aklına “acaba
ilerde beni şutlayacaklar mı?” sorusunu sokar ki bu kişi hiç çalışmasa daha iyi olur. Verdiğimiz şeylerden
daha çok aldığımız şeyler ile ilgilenip daha fazla nasıl geliştirebilirim diye düşünmemiz lazım. İlerleme
ancak bu şekilde olur. Ama zor bir yoldur.
Neyse biz konumuza dönelim. Anlatacağım bir kaç XP metodunu ben deneyip gördüm ki
gerçektende yazılım geliştirme aşamasında işe yarıyor ve hızlı bir biçimde sonuca ulaştırıyor. Aslında eski
metod da hakkıyla uygulandığında sonuca ulaşilabilir fakat insanoğlu yaşayan bir organizma ve bir süre
sonra rutin işlerden sıkılmaya başlıyor, üstelik bir de yapılan iş pek çok kontrol gerektiriyorsa ve “bunu
yapmasak ta olur” gibilerinden suistimale açıksa hiç bir zaman hakkıyla uygulanmıyor. Bizim amacımız
yapılan işi basitleştirmek veya parçalara bölerek yapmak.
3.5.1 Benim Hikayem
Bu bölümde benim başımdan geçen bir durumu aktaracağım. Uzun gelirse buradan sonrasını
okumanıza gerek yok.
Ürün destek bölümüne ilk geçtigim zaman bir başıboşluk sezinledim. Proje bitmis ve ben tek
başıma üründen sorumlu olarak tayin edilmiştim. Bana yardımcı olacak bir eleman verdiler fakat bu
kişinin konu ile yakından uzaktan alakası yoktu. Bırakın olayın işleyişini programcılıktan anlamayan bir
kişi idi.
Büyük problemin farkındaydım fakat proje müdürüm farkında değildi ve bana verilen kişinin kısa
zamanda benimle aynı seviyeye çıkması bekleniyordu. Burada öncelikle kabul edilmesi gereken planların
uzayacağıdır. Proje müdürünü ve bana verilen arkadaşi karşıma alıp bir toplantı yaptım. Ben tüm
bildiğimi aktarsam bile ürün destekte problemlere çözüm bulmak zaman alacaktır bu arkadaş için, çünkü
yeterli alt yapısı yok. Bunu kabul etmeleri 2 saat aldi fakat kabul ettiler. İnsanoğlu bazı tümsekleri
görmezden gelir ya bu da öyle birşey.
Benim esas problemim hem iş akışını hemde programcılık konusunu bana verilen arkadaşa nasıl
anlatmam gerektiği. Problemi parçalayıp çözmek için programcılık konusunu eğitimin dışında tutmaya
karar verdim. Düşünecek olursanız sizinle aynı seviyede çalışan birinin en az sizinki kadar bilgiye sahip
olması gerekir. Bu yüzden arkadaşa bazı kurslar tavsiye ettim, proje müdürü de onaylarsa kursları
ücretsiz alabilecek. Ben, sonuç olarak programcılık öğretmek için burada çalışmıyorum.
3.5.2 Model Duvarı
Öncelikle tüm sistemin işleyiş şemasını büyük kağıtlara çizerek duvara astım. Tüm kutuları
isimlendirip anlattım. Tabii ilk anlatımda ancak %25 oranında bir bilgi hafızada kalır. Daha fazlası için
tekrar gerekir. Şemaları duvara asmam iyi oldu; problem olduğunda hemen ilgili kutuyu gösterip
anlatabiliyorum. Genel şemalar dışında sınıf yapısını ve veritabanı yapısını da duvara astım. Böylece
şemalar arasında bağlantı kurarak anlatabiliyorum. Bir resmini çekip burada göstermek isterdim fakat
yasa gereği göstermiyorum.
Burada kullandığım 3 çeşit model tipi var. Birincisi sistemin işleyişi ile ilgili olan İş Nesneleri
Modeli. Bu modelde hem bizim sistemin iç yapısı hemde diğer sistemlerle olan bağlantıları yer alıyor.
Genel yapıyı kuş bakışı görmek için ideal. İkinci model Sınıf Yapısı. Kendi sistemimiz içinde kullanılan tüm
sınıflar sahaları ve metodları ile burada gösteriliyor. Üçüncü model ise Veritabanı Modeli. Bunda da
veritabanının yapısı ve tablolar arası ilişkiler ile hangi “stored procedure” hangi tabloya erişiyor gibi
bilgiler var.
3.5.3 Sık Sürümler Verebilmek
İkinci olarak tüm projeyi derledim. Daha önceki sürümlerde sadece değişen kısmı paketleyip
kullanıcılara göndermişler. Fakat tüm projenin derlenebiliyor olması gerekir. Visual Source Safe
erişimlerini kapatıp tüm projeleri indirdim ve derleme yaptım. Derleme sırasında hatalı modüller ve eksik
modüller ortaya çıktı bunları temizlemek iki gün aldi. Daha önce NT4 üzerinde derlenmiş ve MTS
nesneleri eski idi, tüm bunları yeni COM+ karşılıkları ile değiştirmem gerekti. Tüm projeleri derledikten
sonra test ekibinden test etmelerini istedim, bu arada buldukları hatalarıda düzelttim. Sonuç olarak
eskisinden daha hızlı çalışan ve tamamı derlenebilen bir ürüne sahip olduk. Artık küçük sürümler halinde
projeyi derleyebiliyorum ve her ay yeni bir sürüm kullanıcılara gönderebilirim.
3.5.4 Vss Organizasyonu
VSS organizasyonu çok kötü yapılmıştı. 45 adet ufak projeden meydana gelen bir istemci
uygulaması, 18 COM+ uygulaması ve 4 adet sürekli çalışan daemon uygulaması var. Fakat derleme
sırasında hangi dll’in hangi projede kullanıldığını anlatan bir belge bulamadım. 45 projenin her birini tek
tek VB ile açarak References kısmından hangi dll veya ocx’lere erişim yapıldığıni yazdım. Daha sonra her
projeyi numaralandırarak bir derleme sırası oluşturdum. Örneğin:
01-ErrorLog
02-DbAccess
03-BRCheck
Bu sırada derleme yapıldığında proje sıfırdan derlenebiliyor. VSS’de de proje isimlerini

değiştirdim. Böylece her bakan bu sıranın ne olduğunu tahmin edebilir.
İlk başta var olan Development, Test, Production gibi VSS dizinlerini de teke indirip hepsini bir
dizin altında topladım. Anlamıyorum neden böyle bir yola başvuruyorlar. VSS zaten eski sürümleri
tutuyor birde 3 farklı dizin açıp her şeyi tekrar ediyorsun. Tamamı ile gereksiz bana göre. Etiketleme diye
bir şey var. Eski sürümden bir dosya istiyorsan “History” kısmından indirebilirsin.
VSS için yaptığım diger bir olay ise Shadow dizinleri. Shadow dizinlerini kullanarak en son
sürümün sabit disk üzerinde bir dizine toplanmasını saglayabilirsiniz. Bunun için srcsafe.ini dosyasına
asağıdaki satırları eklemek gerekiyor. Admin aracından da yapilabilir; Tools-Options menüsünden
Shadow Folder sekmesine gideceksiniz. Köşeli parantez içindeki kısım kopyasını almak istediğiniz VSS
dizini. Benim 1-Builds olarak adlandırdığım dizin 45 ufak projenin exe’lerinin “Share” edildiği dizin. Bir
projenin exe dosyasını sag klik ile taşıyıp başka bir dizin üzerine bıraktığınızda bir menü göreceksiniz.
Burada “Share” seçerseniz, o dosyanın bir kopyası bu dizinde de var olacaktır ve siz projeyi üzerinde
değişiklik yapıp VSS’e geri yolladığınızda bu “Share” edilmiş dosya her iki dizinde de güncellenecektir.
NAnt gibi bir lüksümüz olmadığı için bu yolla projenin exe, dll, ocx gibi çıktılarını bir dizinde bu sekilde
toplayip daha sonra “Shadow” yöntemi ile VSS dışında normal bir dizine atabiliriz.
[$/1-Builds]
Shadow = \\Yoda\Builds
Shadow_SetTime = Current
Shadow_SetTime için 3 adet deger var. bunlar Current, Mod ve Update. Ne zaman projeyi VSS’e
geri yollarsanız bu “Shadow” dizinindeki ilgili dosya da güncellenecektir.
Tahmin edeceğiniz gibi veritabanı da VSS’de mevcut değildi. Tüm veritabanını script olarak alıp
VSS içine yerleştirdim ve her güncelleme için ayrı bir script dizini yarattım. Böylece veritabanında yapılan
değişiklikleri takip etmek kolaylaşti. Ayrıca programın çalışabilmesi için gereken konfigürasyon verisi için
de scriptler hazırlayıp bu dizinde tutuyorum.
VSS ile işim bittiğinde artık güvenilir bir kod kontrol sistemimiz olduğunu söyleyebilirdim.
3.5.5 İstek Ve Hataların Yönetimi
Program için gereken değişiklik ve istekleri takip edecek bir access uygulaması geliştirerek
herkesin kullanmasını sağladım. Bu sayede kullanıcıların ne gibi problemleri oluyor veya istedikleri
değişiklikler var mı kontrol edebildik. Gelen istekleri parçalara ayırarak sık sürümler içinde halletmeye
çalıştık. Kullanıcı isteklerinin hızlı yapıldığını görünce daha fazla değişiklikler istedi bunlarıda projelendirip
yaptık. Hem kullanıcı kendini proje ekibinin bir parçası olarak hissetti hemde bizim firma içindeki yerimiz
sağlamlaştı.
İstek ve Hataların işleyişindeki bazı bürokrasileri ortadan kaldırdım. Bir değişiklik için 15 ayrı
yerden onay almak gerekiyordu. Alınacak onayları 5’e indirip değişikliğin merkezi olarak takip edilmesini
sağlayınca hem değişiklikler çabuk uygulandı hemde sırtında imza atma yükü bulunan kişiler rahatladı.
İmza atmak büyük sorumluluk istiyor, eğer birde attığınız imzanın ne için oldugunu bilmiyorsanız daha da
zor. Onay almak için geçen zaman uzuyor.
3.5.6 Belgeleme
İlk projeyi devraldığımızda belgeleme açısından çok fazla eksik vardı. Bu eksikliği gidermek için
bir UML Case Tool ile tüm projeleri modelledim. Girdi/Çıktı ve parametrelerine varıncaya kadar tüm
fonksiyonları şemalar halinde çizdim. Daha sonra da her fonksiyon için bir açıklama yazdım. Genel
modüller içinde geniş açıklamalar yazdım. Bir kere Case Tool ile bu işi yapınca, gerekli belgeleri kolayca
rapor halinde yaratabiliyorsun. Ayrıca tüm modelleri html sayfaları halinde yayınlayarak herkesin
görmesini sağladım. Iş analistleri modelleri inceleyip yorumda bulunabiliyordu.
Kod içine yerleştirdiğim yorum satırları ile daha iyi okunabilir hale gelmesini sagladım. Ayrıca
her public fonksiyon için “Tools/Procedure Attributes” menüsünden bir açıklama girdim. Bu dll
kütüphanelerinin başka projelerde kullanılması halinde yardımcı oluyor. Object Browser ile bir dll
içindeki fonksiyonları görüntülediğinizde fonksiyonların açıklamaları da geliyor başka bir dökümana
ihtiyacınız kalmıyor.
3.5.7 Xp Ve Benim Yaptıklarım
XP presiplerini benim yaptıklarımla karşılastırdığımızda nasıl örtüşdüğüne bir bakalım.
İletişim – Proje içi iletişim ve kullanıcılarla olan iletişim %70 oranında arttı.
Basitlik – Onaylama mekanizmasını basite indirgeyerek geçen süreyi %300 oranında kısalttım.
Ayrıca VSS üzerindeki çalışmam derleme işlerinin çok kısa zamanda yapılmasına neden oldu.
Geri Besleme – Kullanıcıların kendini ifade edebilecekleri bir ortam hazırlayarak, istek ve
hataların bize doğrudan gelmesini sağladım.
Cesaret – Tüm kodun yeniden derlenmesi ve VSS’in yapısının değiştirilmesi konusunda büyük
risk aldım fakat değdi.
Ağır Başlılık – Tüm bunları yaparken insanları bilgisizliklerinden dolayı aşağılamak yada
suçlamak gibi terbiyesiz girişimlerde bulunmadım.
Eğer sıfırdan baslamış bir proje olsa idi yapilacak çok şey vardı fakat bu proje zaten sonlanmış
bir proje, yapılacaklar da kısıtlı oluyor. XP’nin sadece bir kısmını uygulamak bile pek çok işin hızlı ve tam
anlamıyla yapılmasına yetti.
3.6 Yazılım Uzmanı ve Sağlık
Bir yazılım mühendisinin en önemli aracı sanırım bilgisayar. Ne kadar hızlı olursa olsun genede
daha hızlısını istiyoruz. Bulduğumuz her yazılımı kurduğumuz içinde 6 ayda bir yeniden kurmak ta
heralde dünyanın en zevkli olayı yada en azından bana zevkli geliyor. Benim düşünceme göre sadece bir
adet bilgisayara sahip olmak yeterli!!! Ben böyle diyorum ama bende 4 tane bilgisayar var, yakında
hepsini elden çıkarıp tek bir bilgisayar alacağım. 3 adet dikkat edeceğim husus var.
CPU
Bellek
Sabit Disk
Yatırımın büyük bir bölümünü bu üçü üzerinde yoğunlaştırıp alabileceğimin en iyisini

(büyüğünü) almaya çalışacağım. Nedeni çok basit. Masanın altında elli tane bilgisayar olacağına bir tane
güçlü olacak ve Virtual PC (sanal bilgisayar) ile diğerlerini halledeceğim. Oyun filan nadiren oynadığım
için ekran kartına da ihtiyacım olmayacak on-board beni idare eder.
Gelelim zırt pırt programları kurup kaldırmaya. Bir adet taban sayılabilecek VPC Windows XP
kurup hd dosyasını saklayacağız. Böylece yeni bir tane yaratmak istediğimizde bunu kullanacağız. Kurup
denemek istediğiniz yazılımları VPC üzerine kurup deneyebilir işimiz bitince de VPC'yi tamamen ortadan
kaldırabiliriz. VPC üzerine kurulmuş sistemler ile ana işletim sistemi arasında ağ bağlantısı olduğu için
VPC üzerindeki kaynaklara erişmek te mümkün. Ben Websphere MQ, IIS, SQL Server 2005 gibi ağ
üzerinden erişim gerektiren yazılımları VPC üzerine kuruyorum, ayrıca beta sürüm yazılımlarıda VPC
üzerinde kurup deniyorum.
Diğer dikkat edilmesi gereken konuda monitör. İşimiz yazılım olduğu için günün büyük bir
bölümünü monitör karşısında geçiriyoruz. Tabii gözler haşat oluyor. Ara vermek bir yere kadar koruyor
ama her zaman mümkün olmuyor. Kod yazmaya başlayınca zaman anlamını yitiriyor ve ara vermek şöyle
dursun, yemek dahi aklıma gelmiyor benim. Bu durumda yatırım yapılacak diğer bir parçada monitör.
Eğer monitörünüzde titremeler varsa frekans ayarları ile oynayıp düzeltebilirsiniz. normalde 60Hz
ayarlıdır fakat monitör destekliyorsa yükseltmek sizin yararınıza olacaktır. TFT monitörler de iyi bir
çözüm olabilir. 6 ayda bir göz muayenesinden geçerek durumunuzu değerlendirin, doktora bilgisayar
kullandığınızdan bahsedin ve doktorun önerdiği gözlüğü alın. Unutmayın ki kendinize yaptığınız yatırım
bu sektörden daha uzun seneler ekmek yemenizi sağlayacaktır.
3.7 Ekip Toplantıları
İnsanoğlu sosyal bir varlık. Bulunduğumuz çevredeki insanları etkileyecek kararlar almadan
evvel bir toplantı yapıp enine boyuna tartışırız. Toplantı yapıcı bir olaydır fakat her zaman iyi sonuçlar
doğurmaz. Uzun ve yorucu olabilir. Toplantıya katılanların aktif olarak dinlemesi, öneri ve değerlendirme
yapması ve çözümler sunması beklenir. Ayrıca katılanlar seslerini de duyurmak isterler. Genelde birbiri
ile çelişen fikirler tartışılır.
Eğer alınan kararlar, kararın etkilediği tüm gruplar tarafından duyulmamış ise grup içinde yada
gruplar arasında kopukluklara neden olur. Ekip müdürlerine olan güven kırılır. Toplantıların bir amacı
ekip içindeki bağları güçlendirmek ve ortak bir hedef için çalışıldığını göstermektir. Diğer bir amacıda
verilebilecek en iyi kararı vermektir. Ekip lideri yada müdürü her zaman en iyi kararın ne olduğunu
bilemez ama görevi en iyi kararın ne olduğuna karar vermektir. Bunun içinde kararların tartışıldığı ortamı
hazırlayıp değerlendirmeyi herkesin huzurunda yapar.
İş yaşamımızın büyük bir bölümü toplantılarla geçer. Özellikle proje başlarında analiz yaparken.
Toplantılar pahallıya mal olan olaylardır, sonunda da doğru kararın verilip verilemeyeceği kesin bile
değildir. Toplantının verimini anlamak için kendinize sormanız gereken bir kaç soru var:
 Toplantının başarılı olması için üzerinize düşen her şeyi yaptınız mı?
 Toplantıya katılan diğer iş arkadaşlarınız verimli bir toplantı olduğu konusundan

hemfikirler mi?
 Toplantı sonucunda alınan kararlar toplantı maliyetlerini amorti ediyor mu?
 Aynı sonuçlara toplantı yapmadan da ulaşabilir miydiniz? (E-posta, telefon, gayri resmi
konuşmalar vb.)
Eğer toplantılar verimsiz geçiyorsa muhakkak anlarsınız. Şüpheniz varsa aşağıdaki göstergeler
yardımcı olabilir.
 Başlangıç ve bitiş saatleri planlandığı gibi yürümez.
 Kişiler geç gelir ve erken ayrılır.
 Kişiler toplantıya hazırlanmadan gelir.
 Toplantı girip çıkan kişiler tarafından bölünür yada cep telefonları çalar.
 Kişiler diğerlerinin fikirlerini önemsemez ve başka konular üzerinde çalışır.
 Duygusallaşıp kişisel saldırı yapanlar olabilir.
 Bir kaç kişi birleşip kendi fikirlerini benimsetmeye çalışır yada toplantıda sadece
bir kaç kişi konuşur.
 Öneriler dandik nedenlerden dolayı geri çevrilir. Benim en sevdiğim dandik

nedenler:
o Bu fikre kesinlikle karşı çıkarlar (müşteriyi kastederek)
o Biz onu geçen sene denedik (tuhaf bir sırıtma ile)
o Tamda pazarlama ekibinden duyacağım bir çözüm (konuşan yazılım

ekibinden ise)
o Ben bunu geçen ay patrona söyledim, kabul etmedi. (patron toplantıda

olmayacak) *Benim favorim*
 Birisi konuşmasını bitirip diğeri söz aldığında konuşulanları göz ardı edip tamamı
ile başka bir konuda konuşmak.
 Kesin karara varmadan yada tüm çözümleri dinlemeden toplantının bitmesi.
 Toplantı sonucunda planlanan işlerin paylaştırılmaması ve kişilerin ne yapacağını

bilmemesi. (Bu çok kötü bir durumdur)
 Toplantı sonucunda işler paylaştırılır ve herkesin yapacağı iş belirlenir fakat kimse

görevlerin başarılıp başarılmadığını kontrol etmez.
Verimsiz bir toplantı işiniz için iyi değildir, para ve zaman kaybına neden olur. Yaratacğı stres ve
çelişkilerde cabası. Yönetim ekibine olan güveni kırar ve ekip içinde kopmalara neden olur. Peki
toplantıları nasıl verimli hale getireceğiz.
3.7.1 Tümden toplantılardan vazgeçmek
İyi bir fikir ve en hızlı biçimde kara geçmenize neden olur. Nede olsa toplantı sırasında
harcanacak vakit ve nakit kaybını anında önlemiş oluyorsunuz. Ekip içinde iletişimi biraz öldürür ama
zaten daha önceden de bir iletişim yoktu. Ekip liderinin sorumlulukları biraz artar ve kritik kararları
vermesi beklenir. Ekip lideri bu yükü kaldırabiliyorsa sorun yok. Kararlar hızlı verilir ve uygulamaya
geçilir.
Eğer toplantılara tüm ekibi çağırmak zor oluyorsa bir kaç önerim var
Lider Ekibi: Bu ekip firmanın her bölümünden konusunda uzman kişilerin bir araya gelmesi ile
oluşturulur. Lider ekibinde proje müdürleri yada ekip liderleri olmamalıdır başka bir deyişle yönetim
ekibinden kimse bu ekibe katılmamalıdır. Lider Ekibinin görevi her gün bir araya gelerek bir önceki günün
değerlendirmesini yapmak ve günün problemlerini ve yapılması gerekenleri tartışmaktır. Değişim ve
istekleri yöneten bir ekip yok ise Lider Ekibi bu işide yapabilir.
Ayak üstü koridor görüşmeleri: Hızlı ve kesin bilgi akışı ile yüz ifadeleri ve vücut hareketlerinin
kullanıldığı bir görüşme tipi. Toplantı sırasında maskelerle oturan yada hiç konuşmayan kişilerin fikirlerini
almak için birebir. Bazen yüz ifadelerinden ve vücut dilinden çok daha fazla bilgi almamız mümkün.
Sorular ve beklenen cevaplar kısa olmalı, "evet, hayır, yanlış, doğru" gibi cevaplar ve sonunda kişiye ufak
bir görev vererek bitirme (bir belge yazma yada, ufak bir prototip hazırlama). Görev verdiğiniz kişiye
daha sonra bir e-posta atarak bu görevi verdiğinizi diğerlerinin de bilmesini sağlamayı unutmayın.
Tartışanların ayrı tutulması: Nasıl evlilik müessesesinde fikir çatışmalarından dolayı ayrılıklar
oluyorsa, firma içinde de birbiri ile tartışan elemanları bir süreliğine farklı işlerde meşgul edip,
düşünmelerini sağlamak gerekir. Konu eğer kişisel boyutlara gelmişse çözmek zor (kanser gibi) fakat
önceden sezinleyebilirseniz ve vereceğiniz işlerle konu üzerinde düşünmelerini sağlarsanız çözüm kolay
olabilir. Evet EQ önemli bir olay fakat bir iş için IQ yeterli, çatışmaların kişisel alınmaması ve firma
çıkarlarının dolayısı ile çalışanların çıkarlarının gözetilmesi hatırlatılmalıdır. Çatışan kişilerin kendi fikirleri
üzerine bir rapor hazırlaması ve değerlendirme sonucu iyi olanının seçilmesi işe yarayabilir.
3.7.2 Toplantıların Belli Bir Düzen İçinde Yapılması
Düzensiz toplantıların zaman ve para kaybına neden olduğunu gördük. Bir toplantının çekiciliğini
ve verimliliğini arttırmak için yapmanız gereken bir kaç şey var. Kimse sıkıcı toplantılara katılmak istemez,
katılsa da verimli olmaz.
Öncelikle toplatıyı yönetecek kişi belirlenir. Toplantı başkanı konuyu bilen, kiminle tartışacağını
ve kimlerin fikirlerine başvuracağını bilen kişi olmalıdır. Toplantı başkanı not tutacak kişiyi ve toplantıya
katılacak kişileri belirler. Toplantı sonrasında verilen görevlerin yerine getirilip getirilmediğini de kontrol
eder.
Toplantı başkanının yapacağı işlere bakalım:
Toplantıdan Önce
 Problemi sade bir dille yazılı olarak tanımlar. Problem içinde belli olmayan
yada değişken kısımlar listelenir ve olası problem senaryolarıvarsa ortaya çıkarılır. (bazen
problemin boyutu değişkenlere göre değişebilir ve etkileri farklı olabilir.)
 Yazıcıyı belirler. Yazıcı toplantıda sunulan önerileri ve bu önerilere verilen

cevapların notunu tutar.
 Toplantıya katılacakları belirler. Problem hakkında bilgisi olan ve çözümleri

hayata geçirecek herkes bu toplantıya katılmalıdır.
 Problemin anlaşılması için gerekli taban bilgiyi ortaya çıkarır ve katılanlara

dağıtır. Bazen bu taban bilginin ortaya çıkartılması sırasında çok farklı çözümler
üretilebilir. Probleme yğunlaşmak yerine çevresindeki değişkenlere yoğunlaşmak farklı
bakış açıları ve çözümler verebilir.
 Toplantının zaanını ve yerini tayin eder. Toplantı için gerekli malzemeyide

sağlar (beyaz tahta, projektör, hesap makinesi, ağ bağlantısı, dizüstü bilgisayar vesaire.)
 Diğer katılanları, kimin Toplantı başkanı ve Yazıcısı olduğu hakkında

bilgilendirir. Gerekli belgeleri gönderir ve yer ve zaman konusunda bilgilendirir.
 Toplantının ajandası ve akış şeması hakkında bilgi verir.
Peki katılanların ve Yazıcının görevleri nelerdir?

 Gönderilen belgeleri okumak ve toplantıya getirmek.
 Sunulan belgelerde değişiklik gerekiyorsa Toplantı Başkanını uyarmak.
Toplantı Sırasında
 Her katılan kendini tanıtır ve çalıştığı alanı belirtir.
 İlk adım olarak problemin bir tanımı yapılır ve konunun anlaşılması için belli
miktarda detaya girilir. Tam olarak anlaşılmayan bir konu üzerinde tartışmak hiç kimseye yarar
sağlamaz.
 Tüm katılanların fikirlerinin tek tek dinlenmesi gerekir böylece herkes bir diğerinin
deneyimlerinden yararlanabilir.
 Çözümler ortaya çıktıkça tahtaya yazar ve bir numara verir. Çözümü üreten kişinin
isminin baş harflerinide çözümün yanına yazar.
 Bazı çözümleri birleştirerek farklı bir çözüm yaratır ve birleştirilen çözümleri

üreten kişilere fikirlerini sorar.
 Çözümleri yargılamadan anlamaya çalışır.
 Yeni bir çözüm çıkmayana kadar bu işlem devam eder.
Bu arada Yazıcıda şunları yapar.
 Katılanların bir listesini oluşturur.
 Olası çözümleri listeler.
 Tartışmaların kaydını tutar.
Bir kaç çözüm üretildikten sonra, bu çözümlerin fizibilite çalışmaları yapılır. Hangi çözüm
firmaya en yararlı olandır bulmaya çalışılır. En iyi çözümü bulmak için irdelenmesi gereken konular:
 Önemlilik derecesi
 Çözülebilirlik (günün teknolojisi bunu yapabilir mi?)
 Maliyet Analizi (ne kadara mal olacak)
 Kaynak ve İşgücü var mı?
 Yeterli bilgi firma içinde mevcut mu?
 Bu çözüm başka problemler doğuruyor mu? (en önemlisi bu)
Tüm çözümler liste halinde katılanlara dağıtılır ve 1'den 10'a kadar bir önemlilik derecesi
vermeleri istenir. Sonuçta herkesin verdiği önemlilik dereceleri toplanır ve en yüksek puanı alan
çözümler üzerine yoğunlaşılır. Katılanların bu sonuçları tasdik etmesi ve tekrar düşünmeleri istenir.
Sonuçlar tekrar değerlendirilir.
Bir problemin mutlak bir çözümü olmayabilir. Bir kaç çözümün bir araya gelmesi ile daha şık bir
çözüm elde edilebilir. Yada iki farklı çözüm aynı anda uygulamaya konulabilir fakat bu daha fazla iş
demektir.
En iyi çözüm belirlendikten sonra bir ekip veya bir kişi bu çözümü hayata geçirmek üzere atanır.
Çözümü hayata geçirecek kişinin yaptıklarını takip edecek ve durumu raporlayacak bir kişi de atanır.
Toplantı Sonrasında
Toplantı sırasında tutulan tüm notlar Yazıcı tarafından elektronik ortama aktarılır. Sonuçta karar
verilen çözüm veya çözümler listelenir ve kimin ne iş yapacağı belirlenir. Tüm bu plan toplantıya katılan
herkese gönderilir.
Toplantı başkanı bu planı takip eder ve kişilerle kontak kurarak ilerlemeler hakkında bilgi alır.
3.8 Eski Projeler
Bu günlerde yeni projelere başlamaktansa, eski projeleri adam etmekle yada yeni sistemlere
uydurmakla vakit harcıyoruz. Genelde devir aldığımız projeler zamanın şartlarına göre güzel yazılmış
fakat artan veri yığınları ve eskiyen teknolojiler nedeni ile ya performansları düşmüş yada yeni
sistemlerle konuşamaz duruma gelmiş oluyor.
Bazende firmaların kısır düşünceleri ve günlük politikaları yüzünden, günü kurtarmak amaçlı
alına iki eleman ile eski projeler canlı tutulmaya çalışılıyor. Bazı firmalar, bırakın gelecek seneyi,
önümüzdeki haftayı düşünüp planlamazken, bütün iş yükünü bu iki elemana yükleyip bir şeyler
bekliyorlar. Bu iki eleman sihirbaz mıdır da sihirli deynekleri ile sistemi ayağa kaldırıp, bir o kadar da
hatayı düzeltip programı çalışır hale getirsin.
Diyelim ki böyle bir projeyi Proje Müdürü olarak devir aldınız. İlk yapacaklarınız neler olurdu bir
bakalım.
3.8.1 Proje Hakkında Yeterli Döküman Var Mı?
Benim devir aldığım projelerin hepsinde dökümantasyon eksikliği vardı. Belkide benim istediğim
kalitede dökümana hiç bir zaman erişemeyeceğim ama herkesin hayalleri var değil mi? Kimi zaman
veritabanı tasarımlarına rastlasamda genelde işi anlatan döküman bulmak zor olur. Hele hele birde UML
model filan arıyorsanız işiniz zor. Her zaman firma standartlarını anlatan bir kaç döküman da bulunur
ama bu standartlarda oluşturulmuş bir proje dökümanına ulaşmak her zaman imkan dahilinde olmaz.
Genelde kaynak kodu, firma standartları ve çok şanslı iseniz birde veritabanı tasarım dökümanı
bulabilirsiniz. Projenin ne olduğunu, müşteri gereksinimlerini, senaryoları, iş akışlarını anlatan
dökümanların olmaması sizin için önemli bir riskdir. Programatik hataları kod içinde düzeltseniz bile iş
akışları ile ilgili hataları düzeltemezsiniz.
Bu büyük riski ortadan kaldıramasakta alacağımız bir kaç önlem ileride işimize yarayabilir.
Bunlar:
İşi bilen ve iş akışlarında yardımcı olacak sektörden bir elemana erişim. Böyle birisini bulursanız,
bu kişinin tam zamanlı olarak projede çalışması için istekte bulunun. Bu kişinin görevi projenin iş
akışlarını dökümante etmek olacaktır.
Bir UML modelleme aracı ile mevcut kaynak kodunu kullanarak model oluşturmaya çalışın. Bu
size genel olarak tüm projede kullanılan nesneler ve aralarındaki ilişkiler hakkında bilgi verecektir. Eğer
OO yazılmış bir proje ise işiniz nisbeten kolayç Bazı UML araçları kodu Re-Engineering yaparak koddan
model oluşturabiliyor.
Modelleme sırasında dağınık bir yapı ortaya çıkıyorsa, ufak modüller halinde toparlamaya
çalışın. Böl ve yönet mantığı ile daha kolay anlaşılabilir hale getirebilirsiniz.
Yazacağınız raporda bu riskten geniş biçimde bahsetmeyi unutmayın.
3.8.2 Kaynak Kodu Derlenebiliyor Mu?
Tüm kodu derlemeye çalışın ve bağımlılık şeması çıkartmaya çalışın. Modül bazında derleme
sırasını oluşturmaya çalışın. Kullandığınız UML aracı ile bu derleme sırasını modelleyin. Eksik, kayıp,
gereksiz modüller var mı tesbit edin. Kullanılan üçüncü parti modülleri de tesbit edin. Eğer kod sorunsuz
olarak derlenebiliyorsa bu sizin başlangıç noktanız olacaktır. Yeni bir VSS veritabanı yaratıp tüm kodu
buraya aktarın ama kodun tarihçesini almayın. Eski VSS veritabanını da daha sonra kullanmak üzere
yedekleyin. Yeni yarattığınız VSS sanki yeni açılmış bir proje gibi olacak.
Derlenemeyen kod varsa bunlarda risk oluşturacaktır. Raporunuza bu riskleri de ekleyin.
3.8.3 Bir Müşteri İstekleri Ve Hata Veritabanı Mevcut Mu?
Daha önce kullanılmış bir hata ve istek veritabanı size projenin gidişatı ve şimdi bulunduğu
konum hakkında bilgi verecektir. Bir kaç analiz yapıp iyi ve kötü modülleri yada hataların genelde
nerelerde çıktığını tesbit edebilirsiniz. Bu veritabanını yedekleyip yeni ve temiz bir tane oluşturun. Aynen
VSS gibi sıfırdan başlayacak.
3.8.4 Kaynak Kodu Bir Kod Kontrol Veritabanına Bağlı Mı?
Eğer daha önce VSS gibi bir kod kontrol uygulaması kullanılmış ise, kodun tarihçesinden ne
değişiklikler yapılmış görebilirsiniz. Bu değişiklikleri hata veritabanı ile karşılaştırabilirsiniz. Ama bu eski
kod kontrol veritabanını kullanmayın. Tüm kodu indirip derlendiğine emin olduğunuz kısımları yeni bir
kod kontrol veritabanına aktarın. Böylece başlangıç için elinizde bir temel olmuş olacak.
3.8.5 Kullanan Müşteri Var Mı?
Bu proje müşterilere kurulmuş mu kontrol edin. Eğer kurulmuş ise müşterinin isteklerini göz
önüne alarak bir plan yapın ve bir yapılacak işler listesi çıkarın. Eğer pilot olarak kurulmuş ise bu pilot
uygulamalarını tekrardan çalışır hale getirmek için neler gerekli çıkartın. Müşteri tarafında bağlantı
kuracağınız kişilerin de bir listesini yapın.
3.8.6 Kurulum Programı Var Mı?
Bu yazılımın bir kurulum programı var mı araştırın. Yoksa kurulum için neler gerekiyor araştırın.
Daha sonra piyasadaki kurulum hazırlama programlarını veya mevcut elde varsa yeni sürümlerini
araştırın. Yamaların ve kurulumların müşteriye sorunsuz ulaştırılması ve fazla bilgisayar bilgisi olmayan
müşterilerin rahatça kurabilmesi için mümkün olduğunca basit bir kurulum hazırlamaya çalışın.
3.8.7 Yazılım İçin Kullanılan Araçlar Son Sürümler Mi, Lisansları Tamam Mı?
Kullanılan tüm yazılım araçlarını kontrol edip eksik lisanslı olanlarını ve eski sürümleri tesbit
edin. Sağlayıcı firmalardan kiminle kontak kurulacağını tesbit edin. Eğer eksik lisanslar varsa bu bir risk
teşgil eder. Raporunuza bunları eklemeyi unutmayın.
3.8.8 Yeterli Teknik Alt Yapı Mevcut Mu?
Kullanılan bilgisayarlar, sunucular, sabit disk kapasitesi, ağ ve internet erişimi proje için yeterli
mi araştırın. Projenin derlenmesi, veritabanının oluşturulması gibi işlem gücü ve hafıza isteyen
operasyonlar çok zaman alıyor mu kontrol edin. Yeterli hafıza, sabit disk, işlemci için istekte bulunun ve
risk olarak bunları raporunuza ekleyin.
3.8.9 Projede Kullanılmış Üçüncü Parti Modül Var Mı?
Bu proje dahilinde yazılmamış veya hazır satın alınmış modüller, ActiveX nesneler yada
assembly'ler, aynı firma içinde başka bir projede yazılmış modüllerin hepsi üçüncü parti modüllerdir ve
sorumluluğu başkasına aittir. Fakat genede proje içinde bunları yönetecek bir elemana ihtiyaç vardır. Bu
kişi gerekli firmalar yada kişiler ile bağlantı kuracak, yeni sürümleri takip edecek, yamaları uygulayacak
ve çıkan hataları sağlayıcı firmalara bildirecektir. Bu aşamada böyle bir elemana sahip olmasanız da
üçüncü parti tüm modülleri tesbit edip bir liste haline getirin, sağlayıcı firmalardan kontak kurulacak
kişileride karşılarına yazın. Yukarıda bahsettiğim elemanı ekibinize dahil ettiğinizde yapacağı işler az çok
çıkmış olur.
Projede kullanılabilecek üçüncü parti modül var mı? Özellikle çalışmayanların yerine
kullanılabilecek.
Hazır satılan bir muhasebe modülü, kredi kartı kontrol modülü, portal şablonları vs. gibi
piyasada hazır bulunan modüllerin araştırılması ve bir kar zarar analizi ile projede kullanılıp
kullanılamayacağını araştırın. Hatalı modülleri yeniden yazmak mı daha karlı olur yoksa hazır bulunan bir
modülü entegre etmek mi?
3.8.10 En Fazla Sorun Çıkaran Modüller Hangileridir?
Hata ve istek veritabanından çok sorun çıkartan modülleri bulun. Değiştirilecek yada çok fazla
zaman alacak kısımları ortaya çıkartın. Bu modülleri önem sıralarına göre dizip işe nereden başlamanız
gerektiği konusunda bir plan ortaya çıkartabilirsiniz.
3.8.11 Genelde Sorunlar Basit Programatik Sorunlar Mı Yoksa İş Akışlarında Mı?
Gene hata ve istek veritabanından sorunların programatik sorunlar mı (örneğin sıfıra bölme,
text box'ların yerlerinin değiştirilmesi, veritabanına kayıt sırasında bir sahanın unutulması vs) yoksa iş
akışlarında mı (örneğin bir sipariş alma ve gönderme sırasında geçen olaylar ve kullanılacak
fonksiyonlar)? Programatik sorunları çözmek kolaydır fakat iş akışlarındaki hatalar ancak işi bilen birisi
tarafından bulunabilir ve çözülebilir. Eğer programatik hatalar çoğunlukta ise işiniz nisbeten daha kolay.
3.8.12 Bir Proje Planı Mevcut Mu?
MS Project veya MS Excel gibi bir araçla oluşturulmuş bir proje planı var mı ve var ise gelecekte
yapılacak işler yazılmış mı? Böylece ileride yapılacak işlere buradan da bir kaç madde eklenebilir.
3.8.13 Hızlı Çözülebilecek Hatalar Nelerdir?
Hızlı çözülebilecek hataların tesbitini yapıp bunları yeni mezun programcılara yada stajyerlere
verebilirsiniz. Böylece zamanla hem mevcut koda hemde iş akışına aşikar olacaklardır. Biraz daha sistem
hakkında bilgileri artınca diğer hatalarıda atayabilirsiniz. Onlar için en iyi eğitim bu şekilde olur sanırım.
3.8.14 Patronun İstekleri Nelerdir?
Patronun hedefleri nelerdir, sizden neler bekliyor öğrenmeniz, ileride doğacak yanlış anlamaları
ortadan kaldıracaktır. Sizin yapıp yapamayacağınız işler imkanlar dahilinde ortaya çıkmıştır ve eğer
patron sizden gerçek dışı, doğa üstü bir şey istiyorsa güzel bir dille sizin büyücü olmadığınızı ve geleceği
gösteren kristal topunuzun olmadığını, böyle bir öngörü istiyorsa Medyum Keto yada Memiş'i proje
müdürü olarak almasını tavsiye edin. Yada bir ara yolu düştüğünde Kıbrıs'ta Elmas Hanım'dan da
danışmanlık alabilir. Ama danışmanların pahallıya mal olacağını söylemeyi unutmayın.
Patron, proje müdürü için bir çeşit müşteridir ve mutlu edilmesi gerekir.
3.8.15 Kompleks Modüller Bölünebilir Mi?
Fazla kodlamadan dolayı yada fonksiyon fazlalığından şişmiş modüller bölünüp daha kolay
yönetilebilir parçalar haline getirilebilir. Bu tür imkanlar varsa kesinlikle uygulayın. İleride işleri
programcılara atarkende işinize yarar. Küçük parçalarda hata aramak ve düzeltmek te daha kolay
olacaktır.
3.8.16 Modül Testleri Yapabilmek İçin Test Senaryoları Oluşturmaya Başlayın
Test senaryoları size bir modülün nasıl çalıştığını ve ne tür hata durumları oluşacağını belirtir. Bu
dökümanları hazırlamak uzun sürer. İlk oluşturulan test dökümanları yetersiz olabilir fakat zaman içinde
bu yetersizlikler dökümana eklenerek tam bir test dökümanına kavuşabilirsiniz.
3.8.17 Projenin Yeni Bir Teknoloji İle Yazılması Makul Müdür?
Böyle bir öneriyi patrona götürürken çok dikkatli olmalısınız. Zira tüm yük omuzlarınızda
kalabilir. Fakat zaman zaman yazılımlar o kadar eskirki artık ne yazıldığı dil sağlayıcı firma tarafından
destekleniyordur nede çalıştığı işletim sistemi. Öte yandan bu yazılım yazıldığı sırada hiç kimse bu
yazılımın emekli olacağı zamanı düşünmemiş ve planlara katmamıştır. Her projenin bir hayat süreci
vardır, projeler doğduğu gibi ölürler de. Ama nedense bu ölüm zamanı planlarda pek bulunmaz (en
azından yazılım dünyası için).
Eğer patronda yeni teknolojiye geçmekte gerçekten hevesli ise ve bu geçiş projesine emek,
zaman, para harcayacaksa işiniz biraz daha kolay. Tabii bu durumda yukarıda yazdığım planların çoğu
değişiyor. Sizin için yeni bir proje ve yeni bir başlangıç olacaktır.
3.8.18 Ne Kadar Bütçemiz Var?
Bütçe konuşmaları en sıkıcı konuşmalardır. Manav gibi pazarlık yapma hüneriniz yoksa hiç
girmeyin daha iyi. Ama Proje Müdürü olarak girmek zorundasınız. Bütçe projenin ihtiyacı olan insan
sayısı, hataların sayısı, riskler, temel ihtiyaçlar (yemek, çay, kahve), donanım ihtiyacı, yazılım ihtiyacı,
masa sandalye gibi mobilyalar, ofis kirası, elektrik ve su giderleri gibi daha burada unuttuğum pek çok
değişkene dayalı olarak hesaplanmalıdır. Patronun kafasında eski deneyimlerine dayanarak ve bu
projenin yediği bütçeyi düşünerek zaten bir rakam vardır. Sizin göreviniz patronun beynini bu rakam
bariyerinden kurtarmak ve daha mantıklı bir düşünce sistemine getirmek olmalıdır. Bir mühendis olarak
imkanları, riskleri, ihtiyaçları sıralamak, piyasadan örnekler vermek ve ayakları yere basan gerçekçi bir
plan sonucu ucu açık bir bütçe istemek gerekir. "Ucu Açık" tan kastım tam olarak kapalı bir bütçe yerine
esnek, ekleme çıkartma yapabileceğimiz bir bütçedir.
3.8.19 Na Kadar Zamanımız Var?
"Zaman" her zaman dar olduğumuz bir ihtiyaç. Genelde tam ihtiyacımız olduğu anda biter. Ne
kadar zamanınız olduğunu Patrondan öğrenin ve gerçekçi olup olmadığı konusunda; kendi planlarınız ile
karşılaştırıp bir rapor halinde patrona sunun. Riskler ve tam olarak belli olmayan müşteri istekleri
raporun ana kaynağı olacak ve bu riskleri ortadan kaldırmak için sunacağınız bir kaç yöntem -onaylanırsa-
sizin çözüm yolunuz olacaktır. Zamanınızı iyi kullanmak sizin elinizde, eğer iyi bir planlama yaparsanız ve
kaynakları iyi kullanırsanız her şey mümkün.
3.8.20 Yeni Eleman Alabilir Miyiz?
Eleman alımları eğer onaylanırsa, işinize yarayacak elemanları bulmak size kalıyor. Vereceğiniz
ilanlarda hem kullanılan teknolojiyi hemde işin yapısını belirtin. Projenin boyuna göre alınacak bir kaç
Gereksinim ve Modelleme Uzmanı, Yeni mezun ve usta programcıların karmasından oluşmuş bir yazılım
ekibi, sistem yöneticisi, veritabanı uzmanı ilk aşamada ihtiyacınız olanlar.
3.8.21 Program Kaça Satılacak, Beklenen Kar Nedir?
Programın satışı ve fiyat belirlemelerini yapacak pazarlama ekibi ile sıkı bağlantılar, yazılımın
pazar gücünü arttıracaktır. Pazarlama ekibi üretilen yazılımın tüm artı ve eksilerini bilmeli ve piyasadaki
diğer rakipler ile karşılaştırmalı tablolar hazırlamalıdır. Eğer sizin ürününüzde olmayan fonksiyonlar
varsa, bunları analiz edip genel iş akışı olarak belgeler ve yazılım ekibinden istekte bulunabilir.
Görüyorsunuz pazarlama ekibi bile yazılım ekibine istekte bulunarak projeye katkı sağlayabiliyor. Göz
ardı edilmemesi gereken bir kaynak bence.
3.8.22 Hazır Müşteri Var Mı?
Hazırda bekleyen müşteriler de sizin için bulunmaz bir fırsat. Pilot firma olarak kullanıp ürün
testleri yada kullanıcı kabul testleri yapabilirsiniz. Bu tür müşterileri organize edecek bir elemanda
atamanız gerekebilir.
3.8.23 Programın Desteğini Verecek Ekip Var Mı? Eğitimleri Yeterli Mi?
Destek ekibi genelde yazılım ekibi içinden gelir fakat çok sıkıcı bir iş olduğundan yazılım
ekibinden kimse yapmak istemez. Aslında yanlış da bir uygulamadır çünkü bir yazılım uzmanına
ödediğiniz maaş destek elemanına ödeyeceğiniz maaşdan çok daha fazladır. Yazılım uzmanının hem
destek vermesi hemde program yazması bekleniyorsa; bu da işleri ucuza getirme felsefesinden
doğuyordur ki profesyonelliğin öldüğünün ve batmaya başlayan firmanın göstergesidir. Destek ekibinin
eğitimi çok önemlidir ki müşteri tarafında destek verirken hızlı ve doğru olsunlar.
3.8.24 Medya İle Bağlantıları Sağlayacak Biri Var Mı?
Ürünün tanıtımını yapacak, dergilerde, gazetelerde, televizyonda reklamlarını ve röportajları

yönetecek bir medya uzmanı gereklidir. Böylece ürünün reklamı yapılırç MEdya uzmanının ürün
hakkındaki bilgisi pazarlama uzmanları ile aynı olmalıdır.
3.8.25 Programın Tanıtılacağı Bir Örütbağ Sitesi Var Mı?
Ürününüzü örütbağ üzerinde tanıtacak, müşterilerin aradıklarında bulmasını sağlayacak,

kullanım kılavuzlarının yer aldığı bir site çok işinize yarayabilir. Müşterilerin kullanacağı bir forum, bir e-
posta listesi ve bir hata bildirme formu müşteriyi mutlu edecektir.
3.8.26 Programın Deneme Sürümleri, Öğrenci Sürümleri Olacak Mı?
Ürününüzün yayılması ve mümkün olan en fazla kitleye erişebilmesi için okullara, firmalara
deneme sürümlerinin yada kısıtlı sürümlerinin satılması yada ücretsiz verilmesi düşünülebilir.
Böyle bir projeden genelde beklenen kısa zamanda piyasaya çıkması ve satılmasıdır ki zaten
zarara uğramış bir projeden bir miktar da olsa geriye dönüş olsun. Fakat planlama aşamalarına az zaman
harcandığı ve gerçeklikten uzak olduğu için istenen sonuç elde edilemez. Sonuçta önemli olan planın
gerçeğe yakın olmasıdır.
Öte yandan eminim bütçe kısıtlı olacaktır ve ekstra eleman almak mümkün olmayacaktır. İşinin
ehli, sistem üzerinde biraz bilgisi olan bir kaç yazılım uzmanı tüm planları hızlandırabilirdi oysaki. Ama
tabii firma sahipleri kaz gelecek yerden tavuğu her zaman esirgerler di mi? Proje müdürü olarak bu
bariyerleri kırmak sizin elinizde. Bir mühendis olarak tüm problemleri ve riskleri delilleri ile beraber
ortaya koyup olası çözümleri sunduğunuzda epey bir yol katetmiş olacaksınız. Üst yönetim ekibinin bu
riskleri ve çözümleri hazmetmesi için bir kaç gün zaman verin. Onaylarlarsa projeye başlayabilirsiniz.
3.9 CMMI, ISO, SPICE, IEEE
Eğer bir ekip içinde yazılım geliştiriyorsak her zaman yeni teknolojilere ayak uydurmak, yarım
kalan işleri tamamlamak, müşteri problemleri ile uğraşmak gibi sorunlarla başetmek zorunda kalırız.
Analist Yazılım Uzmanı olarak ta kendimizi geliştirmek ve bilgilerimizi çoğaltmak ile yükümlüyüz.
Gelişme eğer temelleri iyi atılmış ise mümkün olur ve izlenen yola göre, faydaları zaman içinde
ortaya çıkar. Yıllardan beri izlediğiniz yöntemler (bir işe yaramadığını bile bile), okulda öğretilen
metodlar, mühendislik yöntemlerinin yazılım alanında yanlış kullanılması sonucu artık işe yaramaz hale
gelmiş, durağan işleyiş modellerinin değiştirilmesi gerekebilir.
Tabii her değişim bir öğrenme evresi ve eğitim zorunluluğu ile birlikte gelir. Fakat belli bir
yöntemi firma genelinde oturtmak uzun vadede çok daha faydalı olacaktır. Her yiğidin bir yoğurt yiyişi
vardır fakat firmalarında belli bir yoğurt yiyişi olmalıdır. Firmanın sahip olduğu bu "kişilik" ve "kültür"
çalışanlar tarafından benimsenmelidir. Firmalar kendi içlerinde küçük sosyal yapılardır ve her sosyal
yapının haberleşmeye ve paylaşmaya ihtiyacı vardır. Ayrıca her sosyal yapının bir de karşıtı (rakibi) vardır
ki, ayakta kalabilmesi ve gelişebilmesi için bu gereklidir. Yani düşman olmadan ilerleme olmaz.
Firma içindeki yazılım geliştirme kültürü ise bu sosyal yapının bir nevi anayasasıdır. Kurallara
uymak ile yükümlü olan çalışanlar anayasa üzerinde değişiklik yapılması için önergede bulunabilir. Tabii
bu anayasanın da uluslararası yasalara uygun olması gerekir ki firmanın dışarı ile olan ilişkileri (hem
yabancı hemde Türk firmalar) de belli çerçeveler içinde ve anlaşılabilir düzeyde olsun.
Tepeden inme metodlar, aniden değişen kurallar firma çalışanlarını korkutabilir, direnişe veya
bölünmelere neden olur. Bunu hepimiz çok iyi biliyoruz sanırım. Fakat sindirilerek ve belirli politikalar
uygulanarak yapılan değişiklikler daha kalıcı olur. Ayrıca bu değişikliğin, verimi arttırdığı görüldüğün de
kabul edilmesi çok daha hızlı olacaktır. Bir iki dinazor çıkacaktır tabii fakat sebeplerin çok iyi analiz
edilmesi ve yeni sistemin öğretilmesi için zaman harcanması gerekir.
Firmaya yeni kişiler alınırken de firma kültürü ve ahlakı da ortaya konulmalı ve görüşmeler
sırasında adayın bu kurallara aşina olup olmadığı veya öğrenmeye ve uymaya istekli olup olmadığı,
uymazsa sonuçlarının neler olacağı tartışılmalıdır. Bu şekilde aday seçimi aşaması çok daha verimli
olacaktır ve firmanın geleceği garanti altına alınmış olacaktır.
Buraya kadar yazdıklarımı lütfen yavaş yavaş ve tekrar okuyun. Bir yazılım firması hayal edip
kavramları oturtmaya çalışın.
Bu kadar genel konuşmadan sonra, firma kültürünün nasıl oluşturulacağına, anayasanın nasıl
uygulanacağına, dünyada mevcut uluslararası kurallara bir göz atalım.
3.9.1 Müşteri
Bir firmanın varoluş sebebi müşterileridir. Müşterisi olmayan bir firma düşünebiliyor musunuz?
Bu durumda mutlu edilmesi gereken en önemli birim müşteridir. Mutlu müşteri bedava reklam
demektir. Bir yazılım projesinde de en önemli unsur müşteri gereksinimleridir. Şimdi bir düşünelim;
yaptığınız kaç projede gerçekten müşteri ile yüz yüze geldiniz, müşteriyi dinlediniz veya müşteri ile bir
fikir birliğine vardınız yada müşteriyi tam olarak anladığınıza inandınız? E o zaman bu kadar önemli bir
unsuru neden proje dışında tuttunuz? Neden müşteriyi iyice dinlemediniz?
Cevap sanırım çok kısa ve klasik, çünkü düşündüğünüz tek şey sonuçta ortaya çıkacak üründü.
Ürüne odaklandığınız için müşteri ikinci plana itildi. Oysa ki en önemli unsur müşteriler; firmanızın
hayatta olma sebebi.
Ürün odaklı sistemler ile müşteri odaklı sistemlerin en büyük farkı müşteri odaklı sistemlerin
devinimsel olmalarıdır. Yani projenin hayat süreci boyunca müşteri yeni bir şeyler ister sizde bunları
uygulamakla yükümlü olursunuz. Dinamik yapısından dolayı ürün odaklı sisteme göre daha zor gelebilir
fakat işleme modelini bir kere oturttuktan sonra sorun olmayacaktır.
Ürün odaklı sistemlerde ise ürünün ne olacağı, ne yapacağı belirlenmiştir. Belli bir müşteri kitlesi
belirlenmiştir fakat müşterinin üründen haberi yoktur. Eğer tutarsa ne ala, kar yapabilir fakat batabilirde.
Görülüyorki müşteri odaklı bir sistemin hayatta kalabilme şansı daha fazla ve riskleri daha az.
Müşteri üründen haberdar, ayrıca geliştirme aşamasında katkıda bulunduğu için memnun ve mesut.
Demek ki firmamızın işleme modelinde ilk değiştirmemiz gereken şey müşterinin önemini anlamak ve
ürün yerine müşteriye odaklanmak. Böylece ortaya çıkacak ürün müşteri gereksinimlerini daha iyi
karşılayacak ve kendi kendini satacaktır. İşte size mutluluğun resmi. Abidin Dino gibi ressam olmasakta
kendi alanımızda mutluluğun resmini yaptık işte.
3.9.2 Kültür
Firmanın yazılım geliştirme kültürü, işleme modeli ile yakından ilgilidir. Eğer firmanın işleme
modeli genel standartlar içinde ise kalite zaten kendiliğinden gelir. Burada bahsettiğim firma kültürü,
yazılım geliştirme metodolojileri ile (waterfall, agile, XP vs.) karıştırılmamalıdır. yazılım geliştirme metodu
firmanın işleyiş modeli içine entegre olmuş bir parçadır ve işleme modelindeki kontrol mekanizmaları ile
kontrol edilir. Metodolojinin açıkları veya yetmeyen tarafları varsa eklenir veya değiştirilir.
Peki nedir bu işleme modeli?
İşleme modeli bir firmanın yaptığı işi ele alış şeklidir. Aynı sektörde olupta farklı yöntemlerle iş
yapan firmalar vardır. Örneğin kimisi tahsilatı aylık yapar, diğeri peşin çalışır, bir başkası bir al bir bedava
der v.b. gibi. Yazılım firmalarında ise kimisi paldır küldür kod yazmaya girer, kimisi önce analiz belgelerini
yazar, kimisi kalite kontrolü en sona bırakır, kimisi müşteriyi hiç görmek istemez, kimisi de bazı işleri
taşeronlara verir yada Open Source modülleri kullanmaya çalışır. Kontrol ve işleme modelini geliştirmek
gibi konular üzerinde de fazla durulmaz.
Bir firmanın öncelikle bir organizasyon şemasına ihtiyacı vardır. Bu şemalarda yapılan en büyük
yanlış; görevler yerine isimlerin yazılmasıdır. Sadece görevlerin yer aldığı bir şema daha motive edici bir
şema olacaktır. Her görevin ne iş yaptığı ayrıntılı olarak açıklanmalıdır. Böylece çeşitli görevler için
atanan kişiler ne yapacaklarını önceden bileceklerdir. Ayrıca atamaların karar verilmesi için kişinin bir üst
pozisyondan yaptığı işleride rahatça görebiliriz. Problemler için nerelere başvurulacağıda kolayca
görünür.
Konumuz yazılım geliştirme olduğuna göre bu konudaki işleme modellerine bakalım.
Çeşitli standart kuruluşları ve Amerikan ordusu bu konuya el atıp bir standarda oturtmaya
çalıştılar, zamanına göre de oldukça başarılı oldu. İlk başlarda çıkan pek çok standart ürün odaklı idi fakat
bu günlerde artık müşteri odaklılar.
Avrupada ISO (International Standards Organisation) bir standart çıkarınca Amerikada boş
durmayıp IEEE (The Institute of Electrical and Electronics Engineers) ile bazı standartlar çıkardılar fakat
biraz bölük pörçük ve acele ye gelmiş bir standart. Amerika bu işin devlet eli ile olmayacağını anlayınca
Carnegie Mellon - Software Engineering Institue (SEI) ile anlaşıp bu işi üniversite bazında çözmek için
girişimde bulundu ve ortaya CMM (Capability Maturity Model) çıktı.
IEEE 12207 çok güzel bir işleme modeli ortaya koyuyor ve yazılım firmaları yada departmanları
için ideal. Ayrıca 12207'nin nasıl uygulanacağını anlatan 15504 numaralı bir standartları da var. ISO'da da
aynı numaralarla standartlar mevcut. Maalesef link veremiyorum çünkü bunlar paralı satılıyor.
SEI ise bir adım daha ileri gidip hem ISO ve IEEE sentezinde hemde EIA/IS (Electronic Industries
Alliance Interim Standard), IPD-CMM (Integrated Product Development) ve Capability Maturity Model
işleme modellerini aynı potada eritip CMMI (Capability Maturity Model Integrated) modelini ortaya
çıkardılar. Amerikan ordusu tarafından desteklenen bu proje şimdiye kadar çıkan tüm IEEE, ISO ve diğer
standartların katkısı ve eklenen yeni modüllerle oluştu. Hala da geliştirilmeye devam ediyor.
Destek anlaşmaları gereği üretilen her ürünün halka açılması zorunluluğundan dolayı SEI tüm bu
standartları kendi örütbağ sitesinde yayınlıyor. 724 sayfalık CMMI pdf dosyasını indirdiğinizde elinizde
hatırı sayılır bir işleme modeli oluyor ki bunu uygulayabilirseniz ne ala. İlk 93 sayfayı okuyup diğer
bölümleri yeri geldikçe okuyabilirsiniz.
CMMI'ın iki farklı modeli var. Biri "Continues" yani devinimsel diğer ise "Staged" yani merdiven
modeli. (Gene felaket bir çeviri oldu farkındayım :-) ) Merdiven modelinde bir organizasyonun
değerlendirilmesi aşağıdan yukarıya her departman için yapılıyor. Yani size bağlı çalışan tüm
departmanlar belli kriterleri geçmeden CMMI sertifikası alamıyorsunuz. CMMI sertifika sistemi ilk
çıktığında bu model vardı sadece. Genelde insan hayatının söz konusu olduğu sistemlerde bu model
kullanılır.
Öte yandan Devinimsel model ise organizasyon departmanlarını tek tek ele alıp değerlendiriyor
ve CMMI sertifikası veriyor. Yeri gelmişken bu sertifikalardan da bahsedeyim. 5 adet CMMI sertifikası
mevcut, bunlar:
0. Incomplete (Beyaz Kuşak)

1. Performed (Sarı Kuşak)
2. Managed (Turuncu Kuşak)
3. Defined (Mavi Kuşak)
4. Quantitatively Managed (Kahverengi Kuşak)
5. Optimizing (Siyah Kuşak)
Tavsiyem Continues modeli indirip bir göz atmanız ve ilk 93 sayfayı okumanız.
Bir başka modelde SPICE. SPICE size yazılım geliştirme modelinizi tetkik edecek bir sistem
sunuyor. Bu tetkikler sırasında da yapılması gerekenleri anlatıyor. ISO ve IEC standartları göz önüne
alınarak hazırlanmış. Esas dökümanları olmasada "draft" sürümünü indirip bakabilirsiniz.
Gerekli Linkler:
http://www.sei.cmu.edu/publications/documents/02.reports/02tr011.html CMMI Continues Model

http://www.sei.cmu.edu/cmmi/ CMMI Ana Sayfa
http://www.sei.cmu.edu/cmmi/adoption/iso-mapping.html ISO9001:2001 ve CMMI arasındaki benzerlikler
http://www.sqi.gu.edu.au/spice/ SPICE Ana Sayfa
http://www.psmsc.com/ Practical Software Measurement
http://www.sei.cmu.edu/sema/welcome.html Software Engineering Measurement and Analysis
http://www.sei.cmu.edu/publications/documents/96.reports/96.hb.002.html Goal Driven Software
Measurement
3.10 SOA ve Proje Analizi
SOA, Service Oriented Architecture, yani Hizmet Tabanlı Mimari. Yazılım geliştirme sürecinde ilk
başlarda analiz yaparken ortaya çıkan "iş senaryolarının" ayrı birimler olarak ele alınması ve kendi başına
var olabilecek hizmetler olarak tasarlanması olarak yorumlayabiliriz. Her hizmet kendi başına bir iş
halleder. Nesne Yönelimli Analiz metodu olarak ne kullanırsanız kullanın (Shlaer-Mellor, Hatley-Pirbhai,
UML vesaire.) sonuçta elinizde bir kaç katmana yayılmış hizmetler olacaktır. Veritabanından, grafik
arabirime (sunum katmanı) kadar uzanan bu katmanlar birbirleri arasında veri alışverişi yaparak istenilen
operasyonu başarmaya çalışır. SOA mimarisi ile tasarlanmış bir uygulamada bakım ve onarım işleri daha
ucuza mal olur diyebiliriz. Arayüzlere dokunmadıkça ve giriş çıkış veri formatını değiştirmedikçe içeride
her türlü değişikliği yapabiliriz. Ayrıca SOA ile tekrar kullanımı arttırıyoruz ki bu da tekrar eden işlemler
için aynı programın tekrar tekrar yazılmasını ortadan kaldırıyor.
İyi bir SOA tasarımının kalitesi ilk etapta yapılan analizin kalitesine bağlıdır. Benim değinmek
istediğim konu bir Analyst Developer'ın gerekli araçları temin ederek bu analiz aşamasından yüzünün akı
ile çıkmasıdır. Kalitenin anlaşılabilmesi için bazı ölçülere de burada değineceğim.
3.10.1 Metodu Belirleyin
Analiz aşamasında takip edeceğiniz metod size analizin yapılması için gerekli izlenecek yolu
verir. Bu metoda uyduğunuz sürece hata yapma yada bazı adımları atlama olasılığınız en aza inmiş
olacaktır. Metodu kendi isteğinize göre de değiştirebilirsiniz fakat yapılan değişikliklerin verimliliği nasıl
etkilediği test edilmeli ve metoda kattığı artılar gözler önüne serilmelidir. Belli bir metod ile analiz
yapmak ilk etapta yorucu gelebilir (daha önce gelişi güzel analiz yapanlar için), doldurulması gereken
formlar ve yazılması gereken belgeler yük olabilir ama yarın bir şeylere ihtiyacınız olduğunda cevaplar bu
belgelerde ve formlarda saklı olacaktır ayrıca ortaya çıkacak üründe müşteri gereksinimlerini tam olarak
karşılayacak bir ürün olacaktır.
3.10.2 Seçtiğiniz Metoda Uygun Bir Modelleme Aracı Kullanın.
Örneğin Hatley-Pirbhai ile analiz yapmaya karar verdiniz. Elinizdeki uygulamanın Data Flow (Veri
Akışı) şemalarını çizebiliyor olması gerekir. Çizilen şemaların ekip tarafından paylaşılabilmesi ve
yorumların online olarak girilebilmesi gerekir. Böylece ekipten gelecek yorumlar hızlı bir şekilde
modellere yansıtılabilinir. Modellerin sürekli el altında olması gerekir.
3.10.3 Karmaşık Operasyonları Bölün
Normalize her aşamada uygulanabilecek bir yöntem. Karmaşık operasyonlar atomize parçalara
ayrılarak kodlama süresi kısaltılabilir. Ayrıca hata ayıklama da ve testlerde problemlerin kaynağının
doğru olarak bulunmasını kolaylaştırır. Servisleri mümkün olduğunca bölün ve en ufak atomik parçaya
varıncaya kadar katmanlar oluşturmaktan korkmayın. Emin değilseniz diğer ekip elemanları ile tartışarak
en iyi çözüme ulaşmaya çalışın.
3.10.4 Hazır Modülleri Araştırın
Eğer firmanın yapısı ve müşterinin istekleri izin veriyorsa açık kaynak projelerden yararlanmaya
çalışın. Açık kaynak projelerin lisans anlaşmalarını iyi inceleyin ve açık kaynak kullanacağınız projelerin
sahiplerini bu konuda haberdar edin. Projelerin tamamını olmasada bazı parçalarını kullanabilirsiniz.
3.10.5 Veritabanı Ve Grafik Arayüz Değişebilir
Yaptığınız tasarımın hedeflerinden biri de zaman içinde veritabanının ve grafik arayüzün

değişimlerinden etkilenmemesidir. Tasarım tamamı ile modüler olmalı ve sadece iş kurallarını
uyguladığınız katman sizin için önemli olmalıdır. Veritabanı ve Grafik arayüz tümden çöpe atılıp yeniden
geliştirilebilmeli ve iş kurallarını uygulayan katmana kolayca eklenebilmelidir. İşte hizmet tabanlı
mimarilerin önemi burada ortaya çıkıyor.
Bir işi analiz ederken veritabanı tablolarını ve grafik arayüzü düşünüyorsanız, büyük ihtimalle
ortaya çıkacak tasarım da veritabanına ve grafik arayüze sıkı sıkıya bağlı olacaktır. Unutmayın yarın
öbürgün teknoloji ilerler ve veritabanları ile grafik arabirimleri değişebilir (oldu bile, işte Vista ile Avalon
geliyor). Bu aşamada programınızın tamamını mı yazmak daha kolay olur yoksa sadece veritabanı ile
grafik arayüzünü mü değiştirmek kolay olur? Teknoloji ne kadar ilerlese de işin işleyiş kuralları
değişmemiştir. İş gene olduğu gibi gider. Tabii ki özel sektör işleri, devlet birimlerine göre biraz daha
statik yapıdadır. Eğer özel sektöre program yazıyorsanız (örneğin bir hava yoluna bilet satış işlerini
koordine edecek bir program yazıyorsunuz) iş kuralların değişmesi nadirdir. Fakat devlet birimlerine
yazılan programlarda ki iş kuralları genelde değişime uğrar. Yasa değişiklikleri, yeni yasaların gelmesi,
bürokrasi ve işleyiş değişiklikleri iş kurallarının değişmesine neden olur. Buda hizmet katmanınızdaki
hizmetlerin değişmesi demek olacaktır. Bu durum da SOA mimarisi pek elverişli olmaz. O zaman iş
kurallarının parametre haline getirilmesi ve hizmetlerin bu parametreler ile güdümlü olarak çalışması
gerekir. Neyse konuyu dallandırmayalım, devlete program yazmak işlerin temelinden başlanmasını
gerektirir ve analizlerin çok uzun sürmesi de bundandır. Bu paragrafı toparlarsak; bir işi modellerken
sadece işin verdiği tepkileri ve girdi çıktıları modelleyin. Veritabanı ve grafik arayüz en son gelmelidir.
Analist Yazılım Uzmanının yapması gereken hem işi bu şekilde modellemek hemde modellere uygun
sistemi oluşturmaktır.
SOA mimarilerinde koddan müşteri gereksinimlerine yani geriye doğru takip çok kolaydır. Bu tür
bir özellik testlerin yazılmasını da kolaylaştırır ve kaliteyi arttırır. Her servis belli bir işi yapar ve belli iş
kurallarını uygular. Her servisin bir belgesi vardır. Belgenin formatı az çok İş Senaryoları belgesine benzer
fakat biraz daha teknik bir belgedir. Belgede bulunması gerekenleri aşağıda listeledim. Her belgede
olması gereken, içindekiler, değişiklik yönetimi, onay ekibi ve dağıtım listesini geçiyorum.
Servis Tasarım
Alt başlık: Servisin ismi

Bu alt başlıkta kısaca servisin ne yaptığını yazmak gerekir.
Alt Başlık: Tip
Servislerde kendi aralarında katmanlara ayrılabilir. Eğer bir DFD şeması varsa katmanları görmek
kolaylaşır, yada iş ve sistem senaryoları olarak ikiye ayrılmış senaryoları gerçekleyen servisler tiplerine
göre isimlendirilebilir.
İş Kuralları
Bu servisde uygulanan iş kurallarının bir listesi yada iş kurallarının bulunduğu dökümana link
verilebilir.
Servisin Girdileri
Burada servisin işleyeceği verinin yapısı anlatılır. Ne tür bir girdi olacak tablo halinde
yazılmalıdır. Eğer veritabanı şekillenmeye başladı ise verinin tipide belirmeye başlamıştır.
Servisin Çıktıları
Servisten beklenen verinin yapısıda burada yazılır.
Varsayımlar
Eğer servisin çalışması için gerekli varsayımlar varsa burada listelenir. Önceden var olması
gereken koşullar yada çalışmış olması gereken servisler burada listelenir.
Oluşabilecek Hatalar
Servisin oluşturacağı hataların listesi (exception yada bir hata listesi olabilir) burada listelenir.
İleride servisi kullanacak olan programcı (yada bizzat siz) servisin geriye döndüreceği hataları kontrol
etmekle hükümlüdür.
Çağırılan Diğer Servisler
Bu servisden çağırılan diğer servisler burada listelenir ve Servis İçerik belgelerine link verilir.
Tabii her çağırılan servisin bir de geriye döndürdüğü hata durumları var ve bunların kontrol edilmesi
gerekiyor. Eğer bu servisden 100 adet servis çağırıldıysa kontrol edilecek hata listesi bini geçecektir. Bu
durumda oluşan hataların yönetimi için bir sistem oluşturulup her servis de uygulanmalıdır. Hazır hata
kontrol modülleri mevcuttur, yada açık kaynak bu tür projeler de var.
Akış Şeması
Firma genelinde kullanılan metoda göre burada bir şema yer almalı ve servisin yaptığı işi
anlatmalıdır. Servisi kodlarken kullanılacak en önemli kısımlardan biridir. Bu bölümü yazarken kesinlikle
programlama dilinden uzak durmanız gerek, aksi takdirde yanlış yorumlamalara yada iş akışında oluşacak
farklı durumlara sebebiyet verilmiş olunur. Eğer yukarıda belirttiğim gibi modelleri oluşturmak için bir
araç kullanıyorsanız ve modeller iç-örütbağı üzerinden erişilebilir ise, bu servisin ilişkili olduğu modele bir
link te verebilirsiniz. Bakımı daha kolay olur.
Test Senaryoları
Yukarıda bu servisin geriye döndüreceği hata durumlarını yazdınız, şimdide bu hata durumlarını
meydana getirecek durumları listelemeniz gerekiyor. Servis kodlanıp test aşamasına geldiği zaman bu
test senaryolarında bulunan senaryolar kullanılacaktır. Eğer TDD (Test Driven Development - Test
Güdümlü Yazılım Geliştirme (felaket bir çevirim oldu :-)) ) yapıyorsanız kodlamaya bu test modelinden
başlayacaksanız demektir. Testler için kullanılacak veriyide tablolar halinde yazın.
Kullanıldığı Yerler
İlerleyen zamanlarda bu servisin çağırıldığı servisler buraya kaydedilir. Yada link verilebilir. Söz
konusu servis değişikliğe uğradığında buradaki listede bulunan servisler de bu değişiklikten haberdar
edilmelidir. Böylece değişikliklerden kimler etkilenecek sorusunun yanıtını anında alabilirsiniz
başımızdaki saçlar da yerinde daha uzun durur.
Görüldüğü gibi bazı kurallara uyarak yazılım geliştirmek gerçekten de hatırı sayılır bir kaliteye
ulaşmamızı sağlıyor. Ortaya çıkan belgelerin ve modellerin yönetimi, erişimi, kontrolü ve değişimi ne
kadar kolay ve sorunsuz ise yapılan işin kaliteside o kadar artıyor.
3.11 Analist Yazılım Uzmanı
Analist Yazılım Uzmanı (Analyst Developer kısaca Anyazu diyelim (yeni kelime yaratmak değil
amacım; yazı içinde kolaylık olsun diye)) ne iş yapar.
Günlüğümü takip edenler göreceklerdir ki burada yazdığım yazılar genelde belli bir kitleye hitap
eder. Bana gelen linkler de bazı arkadaşların Analist Developer ne iş yapar diye Google'da aradıklarını
gördüm. Kendi kendime ben neden böyle bir yazı yazmadım diye hayıflandım. Nede olsa sitemin
isminden belli bir kitleye hitap ettiğim belli oluyor fakat kitlenin ne yaptığınının sınırlarını çizmemişim.
İşte bu yazımda merak edenler için bir analist yazılım uzmanının neler yapabileceğini irdeliyorum.
Profesyonel bir Anyazu olmak için araştırma, öğrenme ve uygulama şart. Anyazu, yazılım
dünyasında çıkan her türlü yenilik, teknoloji, metodoloji, araç, dil, standart ve sistemleri takip edip
öğrenmek, bu konularda kataloglar oluşturmak, nerelerde kullanılabileceğini belirlemek ve yeni
sürümlerini takip edip, değişikliklerin var olan sistemleri nasıl etkilediğini analiz etmek için sonsuz bir
istek ve çaba içerisinde olmalıdır. “Yeni Başlayanlara” başlıklı yazımda öğütlediğim bazı metodları
uygulamanızı tavsiye ederim. Bir nevi sektörün kalbini dinlemeyi öğrenmek gibi. Gelecekte çıkacak
teknolojileri önceden tahmin edebilme, hangilerinin piyasada daha uzun kalacağını algılama gibi yetilere
de sahip olmalıdır. Tabii burada anlattıklarım belli bir deneyimin sonunda ve bilgi birikimi ile olur.
Örneğin "Düşüncelerim" yazımı okuyun. Sanki Windows Workflow Foundation olayını görmüş gibiyim.
Ama WWF'in benim istediğim konuma gelmesi biraz daha zaman alacak gibi. Aslında WWF ve BizTalk
hemen hemen benim istediğimi yapıyor fakat konumuzu dağıtmayalım.
Öncelikle Analiz olayından başlayalım. Bir sistemi yada müşteri gereksinimlerini analiz etmek ve
bu gereksinimleri yazılım ekibine doğru olarak aktarmak çok önemlidir. Anyazu, nasıl analiz yapılır,
analizler nasıl sıralandırılır, müşteri ile nasıl konuşulur, UML nedir ve nasıl kullanılır, senaryo şemaları
nasıl çizilir bilmelidir. Bu aşamada Anyazunun yapacakları:
Müşteri isteklerini senaryolar halinde belgelendirir. (Senaryo Belgeleri)

Sistemin sınırlarını çizer (Sistem Gereksinimleri Dökümanı)
Harici sistemlerle olan bağlantıları belirler (Harici Arayüz Dökümanı)
Senaryolar arası ilişkileri belirler (Use Case, UML şemaları)
Sistemin hacmini belirler (Function Point Analysis ve COCOMO II)
Tüm üretilen çıktıların müşteri tarafından onaylanmasını sağlar.
Tavsiyem kendinizi sistem analizi ve UML konusunda geliştirin. Ayrıca Agile Modeling, XP gibi
metodlar ile ilgili kitap yada örütbağı üzerinde bulacağınız kaynakları kataloglamaya başlayın. Bazı ufak
tefek metodları iş yerinizde uygulayın. Güzel sonuçlar aldığınızda herkes kullandığınız metodun iyi bir
metod olduğuna kanaat getirecektir. Ayrıca FPA ve COCOMO II konusunda da örütbağı üzerinde
araştırma yapıp nasıl kullanılacaklarını öğrenin.
Müşteri gereksinimleri bir kere müşteri tarafından onaylandıktan sonra tasarıma geçilir. Müşteri
gereksinimlerindeki değişiklikler artık Değişiklik Kontrol Yönetimi ekibinin sorumluluğundadır. Proje yeni
olduğu için müşteri gereksinimleri devinimsel olarak değişime uğrayacaktır. Anyazunun görevi bu
değişikliklerin sistemde ne gibi etkiler doğurduğunun, maliyetinin ne kadar olacağının ve ne kadar
zamanda uygulanabileceğinin analizini yapmaktır. Analiz sonucuna göre Değişiklik Kontrol Yönetimi
değişikliği onaylar yada bir sonraki sürümün kapsamına dahil eder.
Anyazu tasarım aşamasında iş kurallarını tek bir belgede toplar ve senaryo belgelerinden iş
kurallarını çıkartır. Bir UML aracı ile sistemi modellemeye başlar. Projenin yazılacağı dilin nesne yönelimli
olmasına gerek yok, bu modeller her türlü analiz ve tasarım amacı için kullanılabilir. UML aracı deyince
aklımıza Rational Rose (TM), yada MS Visio veya ücretsiz yazılımlardan Argo UML geliyor. Araçlar
üzerinde inceleme yapıp hangisinin ekip için de en verimli kullanılacağını araştırın. Gerekirse COTS bir
ürünün alınması için istekte bulunun.
UML şemalarını hazırlarken öncelikle sistemde yer alacak nesneler tanımlanır. Her nesne bir
sınıf olarak belirlenir. Daha sonra bu sınıflar arasındaki ilişkiler senaryo belgeleri yardımı ile belirlenir. Bu
tür şemalar en iyi "sequence diagram" (sıralı işlem şemaları) ile analiz edilir. Sistemin analizi sırasında
diğer yazılım uzmanlarıda bulunur ve analiz bir toplantı odasında, projektörden yansıtılan UML aracı ile
yapılır. Gerekli nesneler, mesaj alışverişleri, senkron - asenkron işlemler ve ortaya atılan fikirler direk
model üzerinde uygulanır. Böylece toplantı sonrasında kağıt yığınları arasında tekrardan analiz
yapmaktan kurtuluruz. Toplantıya katılan herkes yapılan değişikliklerin onayladığına dair belgeyi imzalar.
Tüm değişiklikler Anyazu tarafından listelenir ve toplantıya katılanlara gönderilir. Model ortaya çıkmaya
başladıkça hangi ekip elemanlarının model üzerinde değişiklik yapma hakkına sahip olacağı da Anyazu
tarafından belirlenir.
Tasarım modelinin Use Case'lerden başlayıp nesnelere kadar takip edilebilmesi gerekir. Model
içinde oluşturulacak linkler ve modelin HTML olarak yayınlanması; sistem hakkında bilgi sahibi olmak
isteyen yada referans vermek isteyen kişiler tarafından yoğun olarak kullanılacaktır. Anyazu bu işi de
yapar ve modelin bozulmadan kalması için diğer yazılım uzmanlarını koordine eder.
Anyazu veritabanı modelini; sistemin analizine dayanarak ortaya çıkarır ve veritabanı uzmanları
ile beraber çalışarak standartlara uygun bir veritabanı geliştirilmesine yardımcı olur. Sistemde
modellenen nesneler ile veritabanındaki tablolar ve sahalar farklı isimlerde olacağı için bir veritabanı
sözlüğü yaratır ve modele bağlar. Bu belgeyi ister tek bir belge halinde ister UML aracı içinde entegre
olarak barındırmakla yükümlüdür. UML aracının bu tür belgeleri otomatik olarak üretmesi ek bir kolaylık
sağlayabilir.
Anyazu, modelleme aşamasında ortaya çıkan pattern'leride belirler. Unutmayın Tasarım

Patternleri model içinde farkediliyorsa uygulamaya girer, yoksa illa pattern uygulayacağız diye model
hazırlamıyoruz. Eğer belirgin şekilde bir pattern görüyorsanız bunları uygulamaktan çekinmeyin fakat illa
bir pattern uygulayacağım diye tasarımın kapsamını da daraltmayın.
Konfigürasyon Yönetimi yazılımı (Subversion, Clearcase, CVS, VSS gibi) üzerinde her Use Case
yada function point için bir dizin yaratır ve yazılım uzmanlarına dağıtılacak işleri belirler. Sürekli
Entegrasyon (CruiseControl, Draco, NAnt, FXCop, NUnit gibi yazılımların Subversion, CVS gibi
konfigürasyon yönetimi yazılımları ile entegre edilmesi) ortamını kurar ve çalışma prensipleri hakkında
eğitimleri verir. İşlerin ataması proje müdürü tarafından yapılır. Bu aşamada Anyazu PM ile beraber
çalışır ve her Use Case'in hacmi, alacağı zaman ve önceliği hakkında bilgi verir. Anyazu padişahın
yanındaki vezir gibidir yani.
Sistem, yazılım uzmanları tarafından kodlanmaya başlandığında; Anyazu kodun sistem

gereksinimlerine göre yazılıp yazılmadığını teftiş eder. Ayrıca standartlara uyulup uyulmadığını da
kontrol eder. Kod içindeki yorumlardan dökümantasyon üretmek (NDoc) ve gerektiğinde bu yorumları
düzeltmek gene Anyazunun görevidir. Tabii burada yazılım uzmanları; nasıl olsa yorumları yazan biri var
diye dökümantasyonu biraz hafife alabilirler fakat yazdıkları kodun ne olduğunu anlatacak yorumları
eklemek görevleridir. Anyazu bu şekilde takılan yazılım uzmanlarını tatlı dille uyarabilir.
Anyazu hata ve istek veritabanlarının kullanımı, bakımı, raporlanması gibi konulara da bakar.
PM veya üst müdürlerin istediği raporları oluşturmakla yükümlüdür. İstenmediği sürece raporlara
herhangi bir yorum eklemez.
Anyazu projenin yada firmanın her kademesindeki kişiler ile doğrudan görüşür ve fikir
belirtebilir, gerektiğinde toplantıları organize eder. Problem yaratan konular varsa analizini yapar ve
çözümü için gerekli ekiplerin bir araya gelmesini sağlar.
Kodda yazar vakit bulursa. Ama kod yazmak ana işleri içerisinde değildir. Yazılan kodun
entegrasyonu ve dış sistemler ile bağlantılarını kontrol eder ve test edilmesi için gerekli ortamı hazırlar.
Gerekli ortam deyince aklınıza bilgisayar kurmak gelmesin o işler için sistem yöneticisi var, daha çok dış
sistemlerin veri alış verişinde kullandığı mekanizmaların kurulumu ve testi (örneğin Websphere MQ yada
MSMQ gibi) işlerini yapar. Kullanılacak üçüncü parti uygulamaları tesbit eder ve entegrasyonu için gerekli
kodu yazar yada analizini yapar.
Ürünün kurulumu, testi gibi işleri koordine eder. Test senaryolarını yada kurulum tıkızlarını
hazırlamaz, sadece yapılacak işleri koordine eder ve sonuçları çıkartır. PM meşgul ise iş paylaştırması
yapar ve sonuçlardan PM'i haberdar eder. İşleri paylaştırmadan önce PM'den onay alır veya iş paylaşımı
listesini PM'e devreder.
Anyazu her işi için onay alır. Onaysız bir iş yapmaz. Onaylar, bir e-posta, imzalı bir belge yada bir
toplantının sonuçlarında yazılı olmasada oluşabilir (toplantıda şahitler olduğu için) fakat ayak üstü
konuşmalar yada çay makinesi başındaki sohbetler onay veya atama olarak kabul edilmez.
PM'e bağlı olduğu için yapacağı her işi önce PM'e bildirir. İstekler daha üst kademelerden direk
Anyazuya gelse bile PM haberdar olmalıdır, böylece Anyazunun ne işle meşgul olduğunu bilir.
Görüyoruz ki Anyazu tüm proje birimlerini birbirine bağlayan bir etken. Arada köprü görevi
gördüğü için, herkesin dilini iyi konuşması gerekiyor. Ayrıca PM için bulunmaz bir kaynak. Sistem bilgisi
ve kullanılan metodoloji bilgisi ile sürekli PM ve diğer proje elemanlarına destekte bulunuyor.
Oluşturduğu dökümantasyon ve modeller sayesinde müşteri gereksinimlerinin tam olarak yazılım
ekibine aktarılmasında büyük bir rol oynuyor. Ayrıca yazılan kodun da gereksinimlere uyup uymadığını
araştırıyor. Bir nevi kalite kontrol görevi de var aslında. Ama bir kalite kontrol uzmanı kadar geniş
konulara bakmıyor yada bir HCI uzmanı kadar herustik inceleme yapmıyor.
Anyazunun bir dizüstü bilgisayarı olması bazı işleri kolaylaştırabilir. Kullanılacak yazılımların beta
yada deneme sürümlerinin testi, sistem entegrasyonlarının denenmesi, gibi proje ile ilgili işler
dizüstünde denenebilir. Ayrıca Anyazu genelde ofis dışında olacağı için (müşteri yanında, eğitimde,
üçüncü parti yazılımları sağlayan firmanın ofisinde, toplantıda vb. gibi) bir dizüstü ve kablosuz örütbağ
erişimi şarttır. Ayrıca firmanın haberleşme kurallarına göre MSN Messenger, Skype, Google Talk, E-posta
gibi mesajlaşma programları kurulu olmalıdır. Anyazunun temel amacı her zaman ulaşılabilir olmak ve
destek vermektir.
Anyazuyu sadece analiz yapmak ve kod yazmak için çalıştırıyorsanız, gerçek verimini
alamıyorsunuz demektir.
Bu kadar işten sonra Anyazu ailesini ve varsa çocuklarını da ihmal etmez. Akşam eve giderken
eşine bir çiçek alır, çocukları ile hoşça vakit geçirir, bilgisayara elini sürmez. Aile ile geçirilen zaman bir
meditasyon gibi bir sonraki güne hazırlanmak için yeterli gücü sağlayacaktır. Anyazu iş yerinde geçen
geyikleri ve tartışmaları eve taşımaz. Çok gerekirse eşinden yardım almak için anlatabilir.
3.12 Nasıl Daha iyi Kod Yazarız
Bu yıl yazılım dünyasındaki sekizinci senem (Commodore 64 ve Amiga dönemlerini

saymıyorum). Zaman içinde yazılım dillerinin daha da somutlaşması (Design Patterns, Best Practices, OO
ve UML vb) bana tasarım ve mimari konularına daha fazla eğilmem için zemin hazırladı. 10 sene önce
evrenkentte yazdığım kodlara şöyle bir bakınca "ben öğretmen olsam buna not vermem" diyorum.
Şimdi yazılım araçlarının daha da gelişmesi, ve bu araçlara erişimin kolaylaşması, açık kaynak yazılımların
çoğalması, tasarım, mimari, güvenlik, yönetim, nesne yönelimli gibi konular hakkında materyalin daha
fazla bulunabilmesi 10 sene önce hayal bile edilemeyecek bir durumdu.
Bu kadar çok kaynak serbest olarak erişilebilir olduğu için performansı düşük, anlaşılması zor,
bakımı ve değiştirmesi imkansız kod yazmak günah olmalı bence. Peki nasıl mükemmelliğe ulaşacağız?
Yazdığımız kodu nasıl daha anlaşılır biçimde üreteceğiz? Dökümantasyonu nasıl daha okunur hale
getireceğiz? Nasıl daha fazla öğrenip uygulayacağız? İşte bu yazımda sizlere birkaç püf noktası vererek iş
kalitenizi arttıracak konulardan bahsetmek istiyorum.
Yazılım geliştirme olayını bir bütün olarak ele aldığımızda kod yazmanın çok küçük bir parçayı
temsil ettiğini görüyoruz. Hataların en fazla yapıldığı ve müşteri isteklerinin programa dönüştürüldüğü
geçiş süreci olduğu için de yanlış anlaşılmalara ve uygulamalara en açık bölüm. Hal böyle olunca buna bir
de yazılımcının yetersiz deneyimini ve yönetimin ilgisizliğini katarsak ortaya kalitenin çok düşük olacağı
bir ürün çıkacaktır. Yazılım uzmanı kullandığı programlama dilini çok iyi biliyor olabilir. Yazılımı yapılan işi
de bilmek en az programlamayı bilmek kadar önemlidir. Örneğin muhasebe kurallarını bilmeden nasıl
muhasebe programı yazacağız? Yada diğer sistemlerin girdi çıktılarını öğrenmeden nasıl entegre bir
sistem yazacağız?
Çoğu zaman program geliştirmek; favori text editörümüzü açıp bir kaç satır kod yazmak,
veritabanına iki üç tablo yerleştirmek ile başlar. Bu bazı firmalarda dahi böyle. Bu tür bir projeye devam
ettiğinizi düşünelim eminim 5 ay sonra ilk yazılan kodun tek satırı dahi kalmaz. Diğer bir konuda yazılan
kodun müşteri istekleri ile örtüşmesi. Örneğin yazdığınız bir fonksiyonun hangi müşteri isteği tarafından
kullanıldığını biliyor musunuz?
3.12.1 Kitap Okuyun
Kullandığınız yazılım dili ile ilgili en az bir referans kitap bulundurmalısınız. Araştırıp en iyisini
veya tavsiye edilenleri alın. Dil ile ilgili kitapların yanında insan ilişkilerini anlatan kitaplar, proje
yönetimini anlatan kitaplar, süreç iyileştirme ile ilgili kitaplar, IEEE, CMMI yada ISO standart kitapları,
UML ve nesne yönelimli tasarım konularını anlatan kitaplar, kullandığınız yazılım araçlarını anlatan
kitaplar, güvenli kod yazmak ile ilgili kitaplar sayılabilir. Burada kitap reklamı yapmayacağım, eğer
ilgileniyorsanız benimle bağlatıya geçip bilgi alabilirsiniz.
Bu kitaplardan öğreneceğiniz yöntemler yazdığınız kodun kalitesini oldukça arttıracaktır.
3.12.2 Listelere Üye Olun
E-posta listeleri bedava destek alabileceğiniz yerlerden bir tanesi. Çoğunlukla üretici firmalar
tarafından da kontrol edilmekte. Bir listeye üye olduğunuzda muhakkak liste kurallarını öğrenin. Örneğin
nasıl üye olacağınızı veya üyelikten çıkacağınız iyi bilin. Benim takıldığım listelere her gün bir kaç kişi
direk listeye gönderdiği UNSUBSCRIBE e-postası ile hem kendini rezil ediyor hemde üyelikten çıkamıyor.
Listede her zaman saygılı olun ve şakayı yeri gelince kullanın. Şaka yaptığınızı belirtmek içinde :-)
imleçlerini kullanın ki herkes şaka yaptığınızı anlasın, aksi takdirde sonu gelmez tartışmalara girersiniz.
Konu dışı bir şey soracaksanız liste kurallarına göre postayı işaretleyin. Örneğin benim üye olduğum bir
listede OT harflerini konu kısmında görünce konu dışı olduğunu anlıyorum. Liste üyeleri e-maıl
programlarında bu başlıklara göre kurallar oluşturabiliyor.
Sorduğunuz sorular cevaplanınca teşekkür edin ve daha sonra bir özet postası atıp problemi
nasıl çözdüğünüzü anlatın ki herkes yararlanabilsin. Listedeki insanlarla fırsat doğarsa tanışmaya çalışın.
Listeye sormadan evvel Google'da arayın.Yüzde 95 ihtimalle sizin karşılaştığınız problem birileri
tarafından zaten çözülmüştür.
3.12.3 Açık Kaynak Araçları Kullanmayı Öğrenin
Eskiden kod yazarken Allah ne verdiyse harala gürele yazıyorduk. Ne bir dökümantasyon ne bir
ünite testi nede kurulum için herhangi bir şey yapıyorduk. Programı edinen kişilerin en az bizim kadar
bildiğini varsayarak, kurulum sırasında problem yaşamayacaklarını düşünürdük. Şimdi o günler geride
kaldı. Artık kod yazarken gerekli açıklama satırlarını XML olarak yazıyoruz. Daha sonra açık kaynak
programlar ile bunları yardım dosyalarına dönüştürmek mümkün. Ünite testleri içinde bir sürü açık
kaynak sistem var. Programı yazmadan önce testini yazıyoruz artık. Sonrada bu testlerden geçmek için
kod yazıyoruz. Sonuçta ortaya çıkan ürün en azından bazı testleri yapılmış olarak çıkıyor. Kodun ne
kadarının ünite testine girdiğini anlayacak araçlar da var. Testleri yapılmamış kısımları hemen görmek
mümkün. Ayrıca bu işleri tamamen otomatize edip sonuçları her derleme işleminde görmekte mümkün.
Belli kurallara uyulup uyulmadığını kontrol edecek araçlar da mevcut. Örneğin herkes member
değişkenler için m kullanmış mı? Bu araçların bugün mevcut olması bizim için bulunmaz bir fırsat. Belli
bir programlama diline yönelik yazmadığım için araç isimlerini vermiyorum fakat .NET ile ilgili araç
isimlerini isterseniz benimle bağlantıya geçiniz.
3.12.4 Sürüm Ve Konfigürasyon Yönetimi Konusunda Bilgilenin
Bir ekip içinde yazılım geliştirmenin sorumluluğu, diğer kişilerin ne yaptığını bilmekten geçer.
İşlerin paylaştırılması, planların yapılması ve çalışmaya başlamak için kendi payınıza düşen kod parçasını
alıp değiştirmek, ünite testlerini yapmak ve en sonunda da diğer kişilerin kullanımına açmak gerekir.
Kullandığınız kod kontrol programının özelliklerini öğrenmek bir yana, proje içinde kullanılan
konfigürasyon yönetimi metodunu öğrenmek te çok önemlidir. Yapılan her işin, üretilen her dökümanın
kısacası zaman içinde değişime uğrayacağını bildiğiniz her türlü materyal kod kontrol sunucularında
tutulmalıdır. Yazdığınız kodun eski sürümüne dönmek yada farklı sürümlerde paralel geliştirme yapmak
ancak bu şekilde mümkün olabilir.
3.12.5 Bir Bilene Sorun
İşte herkesin korktuğu bir olay. Genelde kişiler suçlanmaktan yada küçük düşmekten korktuğu
için soru sormaz. Ama soru sormadan da öğrenme olmuyor. Yazdığınız bir kodun daha iyi nasıl
yazılabileceğini sordunuz mu hiç? Yada bir problemi en iyi hangi yolla çözebileceğinizi öğrenmek için soru
sordunuz mu? Eğer korkularınız varsa yukarıda anlattığım e-posta listeleri sizin için biçilmiş kaftan. Kendi
isminizi kullanmadan soru sorabilirsiniz. Yada patronunuzun ismine GMail'de bir hesap açıp onu kullanın
evet bu bir şaka...
Soru soracağınız kişileri de iyi belirlemeniz lazım. En azından yeterli bilgiye sahip olup
olmadıklarını anlamaya çalışın. Aldığınız bilgiyi vakit geçirmeden uygulayın ve sonuçları tekrar bir bilenle
tartışın.
3.12.6 Seminerlere Katılın
Yeni ürünleri görmek, yeni insanlarla tanışmak, yaptığınız iş hakkında daha da fazla bilgilenmek
ve sıfatınızın daha da fazla tanınması için en mükemmel yol. Peki yazdığınız kodun kalitesini nasıl
arttıracak? Ben genelde hands-on denilen oturup kod yazdığımız seminerleri tercih ediyorum. Hem
uygulama var hem öğrenme. Bu arada da kodu nasıl yazmışlar görme imkanımız oluyor. Eğer birinin
daha iyi bir fikri varsa çıkıp söylüyor.
Ürün tanıtım seminerleri de yararlı eğer kod yazmada kullandığınız araçlar ile ilgiliyse yada
üretkenliği arttıracak araçlar anlatılıyorsa. Bu araçlara erişiminiz olmayabilir fakat en azından böyle bir
teknolojinin varlığından haberdarsınız.
3.12.7 Yeni İnsanlarla Tanışın
İnsan ilişkilerine yukarıdaki paragraflarda değindim. Yeni insanlarla tanışmak önünüze yeni
ufuklar açabilir. Bu kişilerden öğreneceğiniz hiç bilmediğiniz hiç görmediğiniz yada pek önemsemediğiniz
konular problemlerinize farklı bir bakış açısı katabilir. Yada siz onlara bir şeyler katabilirsiniz. Yeni
insanlarla tanışmak benim hayatımda her zaman değişikliklere yol açmıştır. Ayrıca iş konuları dışında
birlikte yapılacak aktiviteler çok değişik iş imkanları açabilir.
3.12.8 Blog Yazın/Okuyun
Deminden beri yaptığım olay... Eğer benim blogumu okuyorsanız ne mutlu bana. Bir iki yorum
da atarsanız çok mutlu olurum. Şaka bir yana öğrendiğim konuları ders notları gibi başkalarına anlatmak
amaçlı yazdığımda daha da pekiştiriyorum. Hatta bazen farklı yollar bile bulmak mümkün oluyor. Ek
olarak iş verenler blogunuzu okuyup ne işler yaptığınızı öğrenebilir ve buna göre size teklifte
bulunabilirler. Blogunuzda belli konulara yönelin ve iş hayatınızda karşılaştığınız konuları yazın.
Tanıdıklarımın bir kaç blogu birden var, bir tanesi kesinlikle işleri ile ilgili konuları yazmak için diğeri ise
sırf geyik olsun diye yazdıkları yada aile fertleri ile resim paylaşmak için kullandıkları blogları.
Kod yazarken çeşitli problemlerin çözümünü genelde bloglarda buluyorum. Bir kaç yazışmadan
sonra kodu alıp kullanabiliyorum. Kimi zaman örnek projeler bile indirmek mümkün. Böylece yazdığım
kodun kalitesi artmış oluyor.
3.12.9 Refactoring Nedir Öğrenin
Refactoring yazılan kodun performansının, bakımının, okunabilirliğinin ve yeniden

kullanılabilirliğinin arttırılması için uygulanan bir dizi metoddan ibarettir.Örneğin tekrar eden rutinleri
ayrı fonksiyonlara ayırmak, ilgili rutinleri bir sınıf altında toplamak, değişken isimlerini değiştirmek,
algoritmaları daha hızlı çalışır hale getirmek vb gibi. Tüm bunları yaparkende zaten çalışan kodu
bozmamak. Sonuçta işin kalitesi artmış oluyor.
3.12.10 İnsan İlişkilerini Sıcak Tutun
Firma içinde olsun, bağlı olduğunuz sektörde olsun; tanıştığınız insanlar ile ilişkilerinizi sıcak
tutmaya çalışın. Bir gün bir probleminiz olduğunda gene onlara soracaksınız ama sadece probleminiz
olduğunda bu kişilerle bağlantı kurarsanız biraz ayıp olur. Ayrıca soru sormayıda öğrenmek gerek.
Örneğin benim blogumda bir kaç tane yorum var, sadece hata aldığı kısmı kopyalayıp yapıştırmış. Ne bir
açıklayıcı not var nede takip ettiği adımları anlatmış. Neyse bende çıkarttım kristal küremi baktım neymiş
hatası. Geriye mesaj atıp 3 vakte kadar çözeceksin dedim :-).
3.12.11 Değişime Ve Yenilenmeye Açık Olun
Değişik metodları ve yeni ürünleri kurmaktan, kullanmaktan çekinmeyin. Değişmeyen ve

yenilenmeyen beyinler bir gün gelir sistem dışı kalırlar. Değişiklik ve yenilik her zaman iyi olmayabilir ama
bunun muhakemesini yapacak olan sizlersiniz.Benim en çok karşılaştığım tipler "gündüz programcıları".
Bunlar sadece yazılım sektörü iyi maaş ödüyor diye sektöre atılmış kişilerdir. Bir iki kurstan sonra hayata
atılıp kendilerini işin ehli gibiymiş gösterip ahkam keserler. Bu kişiler kullandıkları yöntemleri değiştirmek
istemezler çünkü öğrenmek ve uygulamak beraberinde yeni külfetler getirecektir. Zaten bildikleri yoldan
şaşmayıp işlerini zamanında bitirmeye çalışırlar. Mükemmele ulaşmak gibi bir çabaları yoktur.
Refactoring deyince küfür zannederler :-)
Birde "gece programcıları" vardır. Burada anlattıklarımı yüzde 70 yapan kişiler sanırım bu
kategoriye giriyorlar. Gece programcısı araştırıp öğrenmek, yenilikleri denemek için sonsuz bir istek
içindedir. Mükemmelliğe ulaşana kadar her yolu dener. Sistemleri değiştirmekten kaçınmaz.
Sektörün her iki tip insana da ihtiyacı var. Biri iyidir, diğeri kötüdür diye bir yorum yapmayalım.
Projelerde bazen zamanlama ön plandadır, kimi zamanda kalite. Duruma göre bu iki tip yazılım
uzmanının dengeli bir karışımı kaliteli bir ürünü zamanında teslim etmenize sebep olabilir.
3.12.12 Firma Kültürünü Öğrenin
Firma içindeki işleyiş şemasını iyi öğrenin. Firma kurallarını iyi öğrenin. Bazı kurallar yazılı
olmayabilir ve zamanla öğrenilecek kurallardır. Yazılım standartlarını, kullanılan araçları, ve ağ yapısını
öğrenin. Yazdığınız kodun standartlara uyduğundan emin olun.
3.12.13 Kişisel Bilgisayarınıza Yazılım Araçlarını Kurun
Yazılım olayına gönül vermiş iseniz zaten bunu söylemeye gerek yok. Ama ben öyle insanlar ile
çalıştım ki adam sadece firma duvarları arasında yazılım uzmanı olarak geçiyor. Evinde bir bilgisayarı dahi
yok, varsa bile örütbağı amaçlı kullanıyor. Bir kişisel e-posta adresi yok. Seminerlerden, toplantılardan,
etkinliklerden bi haber. Ben bu işi yapmaktan zevk alıyorsam tabii ki evimdeki bilgisayarıma gerekli
araçları yüklerim. Evde de bazı projeler geliştirmek isterim. Amaç daha çok denemek, daha çok yanılmak
ve bilgiyi arttırmak değil mi?
3.12.14 Açık Kaynak Projelere Katılın
Açık kaynak projeler size bir ekip içinde nasıl çalışacağınızı ve ne tür araçları kullanacağınız
hakkında bilgi verir. Katılacağınız bir projeyi eminim Sourceforge yada başka açık kaynak proje
sitelerinde bulabilirsiniz. Sonuçta yazdığınız kod başkaları tarafından kontrol edileceği için değişiklikleri
takip edip en iyi nasıl yazılır öğrenebilirsiniz.
3.12.15 Hayal Kurun
Hayal kurmak beynimizin en üretken işlerinden biridir. Hayal kurarken problemlere yeni
çözümler bulabilir veya yeni projelere başlamak için malzeme toplayabilirsiniz. Ben bir defter alıp buna
aklıma gelen olası projeleri yazıyorum. Gerçi ben projeleri hayata geçirene kadar birileri benden önce
yapıyor ama olsun. Bu yöntemin amacı aslında yeni projeler bulmak değil var olan projelerin belirli
kısımlarının nasıl düzeltilebileceğini araştırmaktır. Örneğin bir projede şöyle bir durumla karşı karşıya
kaldık. Bir dökümanın onaylanması için 3 ayrı kişinin onay vermesi gerekiyordu. 5 yıl önce programı
tasarım edenler veritabanında ki Dokuman tablosunda bu 3 kişi için birer saha tanımlamış. Gel zaman git
zaman, onaylama süreçleri organizasyonun yapısı ile değişmiş fakat yeni sistemi karşılayacak
veritabanında yeteri kadar saha yok. Olayın çözümü basit. Ek bir tablo yaratıp onaylayacak kişileri burada
tutabilir ve her döküman için istendiği kadar çok onaylayacak kişi tanımlanabilir.
3.12.16 Kod Teftişi
Kod teftişi başkasının yazdığı kodun gözden geçirilmesi ve aksaklıkların not edilmesidir. Proje
açık kaynak ise, kodu düzeltmek te işin içine girer. Eğer firma içinde yazılım geliştiriyorsanız, kodun
yazarına bir not gönderip değişmesi gereken yerleri ve nedenlerini bildirebilirsiniz. Kod teftişinin amacı
var olan kodu daha iyi çalışır hale getirmek yada proje standartlarına uydurmaktır. Agile metodları ile
geliştirme yapanlar Pair Programming olayını bilirler. Bu yöntemde iki kişi bilgisayarın karşısına geçer.
Birisi kod yazarken diğeride yazılan koda puan verir. 10'dan başlayan bu puanlamada her hata da 1 puan
düşülür. Kodlama bitince programın aldığı puana bakılır ve 10 puan almak için neler yapılabilir tartışılır.
Gerekli olan düzeltmeler uygulanır.
3.13 Eğer Test Edilmemişse Çalışmıyor Demektir
Belkide çok üzüntülere yol açacak bir başlık ama test edilmemiş bir özelliğin çalışmadığını ve
ürününüze yada firmanıza vereceği zararları bir düşünün. Bugün Sourceforge'dan bir modül indirirken ne
kadar test yapıldığına bakıyorum. Eğer testler eksik ise ekliyorum yada o modülü hiç kullanmıyorum.
Eskiden yazdığımız bir programı test etmek için ihtiyaç duyulan şeylere bir göz atalım
 Test için kullanılacak ağın oluşturulması
 Test kullanıcılarına hesap açılması ve gerekli hakların verilmesi

 Gerekli verinin veritabanlarına yüklenmesi
 Farklı senaryolar için farklı veri oluşturulması
 Tüm programın derlenip test ortamına kurulması
 Test senaryolarının yazılması
 Test sonuçlarının analizi
 Hata ve isteklerin kaydı ve organizasyonu
Bu anlattıklarım bugün dahi yapılıyor ama entegrasyon yada kullanıcı kabul testleri için. Ünite
testleri için bu kadar teferruata girmeye gerek yok. Bugün yazdığımız bir program için test oluşturmaya
kalkarsak bunu NUnit veya VSTS ile rahatça yapabiliyoruz. Ayrıca oluşturulan testler hem yönetmesi
hemde çalıştırması kolay testler oluyor. Kazandığımız zaman ve artan kalite de cabası. Bu durumda
yazılım uzmanı yazdığı kodun testlerini de oluşturacak, testleri çalıştıracak ve diğer testlerin
etkilenmediğini de kontrol edecektir. Bu olay artık bizim (yazılım uzmanlarının) sorumluluğumuzda olan
bir olaydır.
TFS bu olayı bir adım öne alarak şöyle bir özellik eklemiş. Check-out edilen kod ancak ünite
testlerinden geçerse TFS'e geri gönderilebiliyor. Bu kapatılıp açılabilen özellik sayesinde TFS üzerindeki
kodun her zaman ünite testlerinden geçeceğini düşünebiliriz.
Sanıyorum bu tür araçlar arttıkça, süreç iyileştirme için uygulamamız gereken işlemleri günlük
hayatımıza sokmak daha da kolaylaşıyor. Peki bir yazılım firmasında sırf TFS ve iyi bir yazılım süreci
kullandığınızda 3. seviye CMMI sertifikası almanın kolaylaştığını biliyor musunuz?
Bundan bir kaç zaman önce bir grup toplantısında NUnit testlerinin ürün ile birlikte verilmesini
tartışıyorduk. Böylece ürünü alan müşteriler testleri çalıştırarak ürünün kalitesi hakkındaki sorularını
cevaplayabilirlerdi. Müşterinin teknik konulardaki yetersizliğini dikkate almadık. Her zaman konudan
anlayan bir programcıyı bünyelerine katıp yeni bir iş sahası oluşturabilirler. Testleri kendi çalıştıran
müşterinin ürüne olan güveni biraz daha artar hatta tavsiyelerde bulunabilir. Böylece ürün geliştirmek
için harcayacağınız ArGe finansmanını da bilgisayarları güncellemek için kullanabilirsiniz.
Sizce nasıl olmalı? Yazdığınız programlarda ünite testlerini de dahil ediyor musunuz? Bu
sistemleri otomatize ettiniz mi? Yazdığınız programın kaçta kaçı ünite testlerine tabii tutuluyor?
Deneyimlerinizi duymak isterim...
3.14 Gereksinim Yönetimi ve Kalite
100. yazımdan sonra Gürol Beyden aşağıdaki e-postayı aldım. Birilerinin bu tür konulara kafa
yorduğunu görmek sevindirici.
SAYIN GÜRKAN BEY,
Yeni yaşınızı kutlar, nice güzel yaşları sevdiklerinizle geçirmenizi temenni ediyorum.
100.yazınızla ilgili bir sorum olacaktı. Burada bahsi geçen "gereksinim yönetimi", yazılım
kalite güvencesi içerisinde bir parça olarak mı algılanmalı yoksa, yazılım çalışmaları yapan kişilerin
oluşturacakları bir kontrol mekanizması olarak mı algılanması gerekmektedir?
Böyle bir yönetim kavramı veya bunun geliştirilmesi şirketlerin hangi birimi tarafından
uygulanmalıdır? Bir sorumda, önereceğiz bir kitap varmı bunlarla ilgili olarak? Daha önce vermiş
olduğunuz öneriler için de teşekkür ederim.
İYİ ÇALIŞMALAR
SEVGİ VE SAYGILARIMLA
GÜROL GÜRSES
Kutlaman için teşekkür ederim.
Gereksinim Analizi basit olarak müşterinin ihtiyaçlarını analiz ettiğimiz adım diyebiliriz. Projenin
başında müşteri gelir ve problemlerini anlatır sende oturup bunları analiz edersin. Yönetimini ise
Business Analyst yada Analist Yazılım Uzmanı yapar. Üretilen her türlü döküman belli onay
kademelerinden geçeceği ve zaman içinde değişikliğe uğrayacağı için bu şarttır.
Bunun kalite kontrolü içinse üretilen her türlü senaryonun müşteri tarafından onaylanması
gerekir. Böylece ortaya çıkardığımız her gereksinimin müşterinin ihtiyacı olan gereksinimler olduğunu
söyleyebiliriz. Boşuna ürettiğimiz bir şey olmaması gerekir. Gereksinim Yönetimi Yazılım Kalite Güvencesi
içinde bir parça olarak algılanabilir. Örneğin IEEE 829 (Yazılım testi dökümantasyonu) gibi bir standardı
uyguluyorsak birde bunların doğru kullanılıp kullanılmadığını tetkik edecek denetleme mekanizmaları
oluşturmamız gerekir. Bu mekanizmalar Yazılım Kalite Güvencesi kapsamına girer. Yani bir uyguladığımız
metod var birde bu metodun doğru uygulanıp uygulanmadığını test edecek başka bir metod var. Örneğin
çeşitli dökümanlar için belli şablonlar var ve bunlar kullanılarak dökümantasyon oluşturmanız gerekiyor.
Ama tabii zaman içinde ekibin yada kişilerin karşı koyması ile bazılarını değiştirdiniz yada tamamı ile
ortadan kaldırdınız. İşte o zaman metodoloji polisi gelip size hesap sorar.
Yazılım Geliştirme süreci içinde hangi metodu kullanırsak kullanalım, her adımdan sonra bir test
koyarak üretilen materyallerin doğruluğunu ölçebiliriz. Kimi zaman müşteri, kimi zaman test ekipleri
yada genel konuşmak gerekirse projede payı olan herkes bir nevi test yapmalıdır ki sonuçta üretilecek
yazılım hem müşterinin ihtiyaçlarına tam olarak vecap verebilsin hemde yazılım olarak doğru çalışsın.
Örneğin Master of Software Engineering okurken Verification & Validation diye bir ders gördük.
Bu derste V&V programlarını mevcut metodoloji içine nasıl entegre edeceğimizi, Risk yönetimini,
Inspection yöntemlerini ve IEEE 829 kurallarını gördük. TQM konularına da girdik. Sonuçta elde ettiğim
pratik yöntemleri günlük hayatımda kullanıyorum. Okuduğumuz kitaplardan bir tanesi “V&V of Modern
Software Systems” yazarlar SchulmeyerveMacKenzie. Alıp okumanı tavsiye ederim.
Projenin boyutuna ve firmanın finansman yeterliliğine göre bence bir Quality Assurance uzmanı
muhakkak gerekli. Firma içinde kullanılan yazılım geliştirme metodolojisini çok iyi bilmelidirler ki kalite
kontrol aşamalarını entegre edebilsinler. Ayrıca projeya katkısı olan herkes ile doğrudan konuşurlar. Bu
işin outsource (taşeron) edilmesi düşünülemeyecek bir konu. Hem fikirleriniz çalınabilir hemde
taşeronun kalitesinden emin olamayabilirsiniz. QA uzmanı birden fazla projeye de bakıyor olabilir. QA
uzmanını her türlü testleri yapacak kişi olarak görmemek lazım. Örneğin oturup kullanılabilirlik testlerini
yapmaz. bunun için HCI uzmanları vardır. Ama kullanılabilirlik testlerinin sonuçlarını değerlendirmek
kesinlikle işleri arasındadır.
Gereksinim Yönetimi için yazılımlar da mevcuttur. Gartner raporlarından "Agile Requirements

Definition and Management Will Benefit Application Development" raporunda belirtilen yazılımları
aynen listeliyorum.
En çok bilinen/kullanılan gereksinim yönetimi araçları
IBM Rational Requisite Pro (Bunu kullandım fakat Rational SoDA olmadan raporlamak çok
güç)
Borland CaliberRM (Bunun bir de VS Team System eklentisi var, trial indirip kurdum harika
bir şey)
Serana Requirements / Traceability Management
Telelogic DOORS
Daha az bilinen araçlar ise:
Apptero 2004
Axure Software Solutions Rapid Prototyper
Compuware Reconcile (QA Center ve DevPartner ile kullanılıyor)
Goda Software Analyst Pro
iRise Application Simulator
MKS Requirements 2005 (Integrity Manager ile)
Sofea Profesy
SpeeDev RM
SteelTrace Catalyze
TCP Integral Requisite Analyzer
Sistem Mühendisliği üzerine gereksinim yönetimi araçları:
3SL Cradle
UGS Teamcenter
ViewSet Pace
Vitech Core
Maalesef hepsinin linklerini veremiyorum. Google'dan aratabilirsiniz.
Yukarıda bahsettiğim rapordan bir alıntı yapayım. Raporu sitede verecektim fakat lisans olayı
yüzünden dokunmayayım dedim. Gartner avukatları ile uğraşmak istemem . İsteyen olursa raporu
e-posta ile gönderebilirim.
Gereksinimlerin toplanması ve yönetimindeki esneklik, yazılım geliştirme sürecinin ne kadar

disiplinli olduğunu gösterir. Gereksinim toplama ve yönetme işlerini otomatize etmiş yazılım geliştirme
firmaları değişiklik kontrolünü daha iyi destekler, testlerde verimlilik kazanır ve gelecekte ortaya çıkacak
bakım ve değişiklik işlerinin yükünü azaltırlar.
Öte yandan kalite subjektif bir olgudur. Kişiden kişiye değişir. Bir kişinin sevdiğini diğeri
beğenmez. Pirsig ikilemlerinde şöyle laflar geçer:
Eğer bir nesne kaliteli ise neden bilimsel araçlar ile kaliteyi ölçemiyoruz?
Eğer kalite subjektif ise ve sadece gözlemcinin kanısı ise o zaman kalite sadece neyi
beğendiğinize verilecek şık bir sıfattır.
IEEE ise olaya biraz daha açıklık getirmiş:
Bir sistemin, modülün yada sürecin tanımlanmış gereksinimlere yada müşteri veya kullanıcı
ihtiyaç ve beklentilerine uyma derecesidir.
Weinberg ise hataların bulunmadığı durumları kaliteli olarak varsaymıştır.
Umarım anlattıklarım yararlı olur yada daha fazla soru sormanız için zemin hazırlar.
3.15 Diğer Gereksinim Yönetimi Yazısı
Çok fazla yazan bir adam değilim. Bir şeyler yazmak için hele ki sektör ile ilgili olacaksa ilham
gelmesi yada birilerinin beni kızdırması lazım. Ancak o zaman sular seller gibi yazabiliyorum. Tabii birde
yazdıklarımın kalitesi ve doğruluğu mümkün olduğu kadar yüksek olmalı.
Bu doğum günü ve 100. yazı olması vesilesi ile önemli bir şeylerden bahsedeyim.
Yazılım geliştirme alanında gereksinim analizi aşamasını bilirsiniz. Müşterinin ihtiyaçlarını veya
problemlerini analiz ederek bilgisayar ortamında nasıl çözüm bulacağınızı araştırırsınız. Müşterinin
farkında olduğu veya olmadığı tüm gereksinimlerini ortaya çıkarır çeşitli yöntemler ile bunları dosyalar ve
sistemi modellemeye çalışırsınız. Bu gereksinimleri ne kadar iyi yönetirseniz sonuçta ortaya çıkacak
üründe o kadar hatasız olacaktır.
Gereksinim Yönetimi
Gereksinim analizi sırasında ortaya çıkabilecek ürünlere bir bakalım.
Senaryolar
İş akışı diyagramları
İş kuralları
Hedef ve Kapsam belgesi
Data definition diyagramları
Dahili ve harici arayüz gereksinimleri
Çeşitli UML diyagramları

Sistem gereksinimleri spesifikasyonları
Test senaryoları
Prototipler
Sürüm politikası
Değişiklik istek belgesi
Güvenlik politikası
Risk dökümanı
Bu listeyi daha uzatmak mümkün. Bunlar ilk etapta aklıma gelen şeyler. Daha kod yazmaya
geçmeden elimizde bir sürü döküman oluşuyor. Müşteri isteklerini değiştirebilir, yenilerini ekleyebilir
veya bazı gereksiz gördüğü kısımları silebilir. Bu kadar fazla ürünün yönetilmesi kesinlikle mecburidir.
Aksi takdirde ipin ucunu kaçırırsak ve bazı gereksinimleri müşterinin istediği gibi değiştirmezsek bu proje
salıncak hikayesine döner.
Müşteri odaklı bir yazılım firmasının en büyük bilgi kaynağı müşteridir. Çünkü işi bilen ve her
türlü girdi çıktısını tanımlayabilecek tek kişidir. Programı hatasız yazabilmek için müşteriyi sürecin her
türlü aşamasına sokmanız gerekir ve müşterinin ağzından çıkan her türlü bilgi kayıt edilmeli ve iyi
yönetilmelidir.
Bunlar yazılı döküman olduğuna göre rahatça bir kelime işlem programı (Word, wiki, Open
Offıce vs.) ile hazırlayacağınız şablonları kullanarak belli bir biçimde kayıt edilmelerini sağlayabilirsiniz.
Her türlü dökümanın bir şablonu olunca işler biraz daha kolaylaşır.
İkinci aşamada bunların sürüm kontrolünü yapmalısınız. Böylece kim ne değiştirmiş görmek
mümkün olur. Örneğin wiki ortamında kimin ne değiştirdiğini görmek kolay olur yada Subversion gibi bir
program ile sürüm kontrolünü yapabilirsiniz.
Değişikliklerin onaylanması içinde bir iş akışı düzenleyip belgelere uygulanacak değişikliklerin

onaylanmasını sağlayabilirsiniz. Onay ya müşteriden yada bu iş ile ilgili firma içindeki birimden gelecektir.
Değişiklik ancak onaylanırsa (değişiklik istek belgesi bu iş içindir) esas belge içine gömülür.
Son hali onaylanan belgeler üzerinde değişiklik istenirse; bu değişikliğin etkilediği diğer alanlar
çok iyi tanımlanmalıdır. Eğer maliyeti ve zamanı arttıran bir değişiklik ise başka bir sürüme bırakılabilir.
Bu da sürüm politikası belgesinde belirtilmelidir.
Her yazılan fonksiyonun hangi senaryoda nasıl kullanıldığını gösterecek akış şemaları ile koddan
gereksinimlere doğru takibi kolaştıracak UML diyagramları oluşturmalısınız. İlk sürüm verildiğinde
boşuna yazılmış kod var mı yada boşuna üretilmiş bir senaryo var mı analiz edebilirsiniz. Bu size
ürettiğiniz ürünün gereksinimleri ne kadar kapsadığı hakkında bilgi verir.
Evet, toparlamak gerekirse gereksinim yönetimi çok önemli bir konu ve önümüzü görerek kod
yazmak istiyorsak şart. Düşünün petrol yüklü bir tankeri yönetiyorsunuz ve sis içinde yol alıyorsunuz. Bir
yere çarpsanız hem çevre kirliliğine hemde para kaybına neden olacaksınız. Ayrıca kaybedeceğiniz itibar
da cabası. Böyle bir riski almaktansa bir iki radar sistemine yatırım yapmak yada sisin kaybolması için
beklemek en akıllıca iş olur. Gereksinimleri akıllıca yönetirsek üstesinden gelemeyeceğimiz proje yok
değil mi?
3.16 Serbest Yazılım
Açık kaynak yazılım üzerine podcasting yapan IT Conversations sitesinden bir kaç şovu
dinliyordum. Şovların kalitesi çok iyi. Bilindiği gibi sitemde genelde Microsoft teknolojilerine üzerine
yazıyorum fakat yazılım mühendisi olmamın verdiği sorumluluk ile her alandan bir şeyler burada
göreceksiniz. IT Convesations sitesinden dinlediğim Larry Augustin'in "The Next Wave of Open Source :
Applications - Açık Kaynak Dünyasında Bir Sonraki Dalga : Uygulamalar" isimli şovda serbest yazılım
dünyasında önümüzdeki yıllarda karşımıza çıkacak ve mevcut ticari yazılım paketlerinden bahsediliyor.
Serbest yazılım dünyasında işletim sistemi, derleyici gibi altyapıların artık oturduğu bir dönemde ticari
yazılımların üretimine doğru kayılması oldukça normal bir durum.
Yazılım satın alacak bir firma için en önemli unsur bence mevcut sistemlere na kadar entegre
olacağıdır. Burada sistem olarak bahsettiğim mevcut bilgisayar sistemleri yada işin işleyiş modelidir. Satış
sonrası destek, fiyat, kullanılabilirlik daha sonra gelir. Bir firmanın Linux ortamında mevcut olan ticari
yazılımları kullanabilmesi için tabii ki tüm alt yapısının Linux olması ve gerekli desteği ya içerden yada
dışarıdan alıyor olması gerekir. Ne tür alt yapı kullanırsak kullanalım genede bir sistem yönetcisine
ihtiyaç var nasıl olsa değil mi.
Pek çok yazılım -ticari veya serbest yazılım- ihtiyaçlardan doğar. Daha sonra kullanıcıların
gereksinimlerine göre şekillenir. Ticari yazılımlarda gerçek kullanıcı ile yazılım arasında bazı bariyerler
vardır. Her isteyen kurup deneyemez, gerekli eğitim, dökümantasyon serbest olarak mevcut değildir,
çevrede kullanan bilgi alabileceğiniz fazla firma yoktur yada firmalar bu bilgileri açıklamaktan çekinirler.
Bu günümüzde değişmeye başlayan bir model ama aşılması gereken pek çok bariyer daha mevcut.
Serbest yazılım dünyasında ise yukarıda saydığımız bariyerler yok fakat bu seferde fonksiyonellik
açısından bir fazlalık var ve buda kullanılabilirliği azaltan bir faktör. Ayrıca geliştirme platformlarının
çokluğu gene kullanıcının kafasını karıştıran bir etken. Diğer bir etkende açık kaynak yazılımların birlikte
çalışabilmesi için harcanacak zaman ve naktin miktarı.
Bence çeşitli standartlar oluşturulmalı ve verinin bütünlülüğü sağlanmalıdır. Örneğin müşteri

tablosu her yazılımda aynı isimle ve aynı sahalar ile tanımlanmalıdır. Tabii ki böyle bir standardı yazılım
dünyasında oturtmak pek mümkün değil. Her yazılım kendi içinde küçük bir dünya ve kendi kurallarına
göre yönetiliyor. Neyse konuyu dağıtmayalım...
Bir kaç serbest yazılımı birleştirip ortaya çıkaracağınız biri ürünü satabilir ve desteğini
verebilirsiniz. Güzel bir iş modeli ama başlangıç aşamasında biraz zorlanabilirsiniz. Biraz dikkat ve
koyacağınız kurallar ile bunları aşmak mümkün. Nedir bu zorluklar:
Türkçe döküman eksikliği
Entegrasyon
Sürüm kontrolü
Kurulum zorlukları
Marka eksikliği
Fonksiyon fazlalılığı
Müşteri güveni oluşturma
Genelde serbest yazılım projelerinde Türkçe döküman bulmak zordur yada arayüzleri
Türkçeleştirmek gerekir. Sıkı ve temiz bir çalışma gerektirecek bir alan. Özellikle bu alanda üretilen
çıktının çok iyi test edilmesi ve yazım, imla vs. hataların giderilmesi gerekir. Yardım dosyalarının da
Türkçeleştirilmesi ve kullanıcıya sunulması şarttır. Bir diğer konuda eğitim dökümanları ve kullanıcıya
verilecek eğitimlerin şekillendirilmesi.
Entegrasyon pek çok açıdan ele alınabilir. Kullandığınız açık kaynak yazılımların entegrasyonu,
mevcut sistemlerle entegrasyon, işleme modeli ile entegrasyon vb. gibi. Sistemler arası veri alışverişinin
çok iyi analiz edilmesi ve her türlü senaryonun test edilmesi gerekir.
Kullandığınız açık kaynak yazılımlar yeni sürümler verdikçe sizinde bunları uygulamanız
gerekiyor mu araştırmanız lazım. Örneğin bir kere entegrasyon ile ilgili kodu yazdıktan sonra sürümleri
değiştirmek istemeyebilirsiniz (aslında bu olay modüler bir yapıda kod yazmadığınızı gösterir). Kendi
içinizde de bu sürüm kontrolünü Subversion gibi bir programla çözebilirsiniz.
Kurulum için gerekecek programı sizin yazmanız gerekecektir. Bir kaç açık kaynak programı
birleştirdiğiniz için kurulum da size özel olacaktır. Mümkün olduğu kadar kurulum olayını
otomatikleştirmek ve sistemin çalışması için elle müdahale edilecek adımları azaltmanız gerekir. Kurulum
aşaması bir açık kaynak proje için çok önemlidir çünkü kullanıcı ilk kurulum ile başlar ve ilk izlenimler
burada ortaya çıkar. Sistem destek uzmanları için de ne kadar az müdahale edilirse o kadar iyidir.
Gereksiz fonksiyonları kırparak müşteriye tam istediği çözümü vermeliyiz. Zaten fazla fonksiyon
olması sizinde başınızı ağrıtır. Zaman ilerledikçe bu fonksiyonları işleme koyabilir
Bazı potansiyel müşterilerin programı pilot olarak kurup denemelerini sağlayın. Böylece
programın kendi işlerine yaradığını daha net görürler ve açık kaynak yazılımlara karşı şüphelerini
giderebilirler. Bir iki satıştan sonra müşterileri bir araya toplayacak toplantılar düzenleyip fikir
alışverişinde bulunmalarını sağlayabilirsiniz. Sizin hiç ummadığınız bir özelliği farklı şekillerde kullanan
müşteriler çıkabilir.
İşte size mis gibi iş modeli. Yazılacak minimum kod ile bir ürüne sahip olmak ve bunu
pazarlamak ne kadar kolay değil mi? Satış sonrası destek ve eğitim konularınıda hallettiniz mi piyasada
uzun yıllar kalacak bir firma sahibi oldunuz demektir.
3.17 Reusing ve Refactoring
Yazılım dünyasının bu iki önemli konusundan biraz bahsetmek istiyorum. Sıkılmayın sonuna
kadar okuyun. Sizin için yararlı olduğunu göreceksiniz.
Bir yazılım geliştirme sürecini düşünün. Müşteri size gelir derdini anlatır, projeyi almanızı ister,
yasal işlemlerden sonra oturup analiz yapmaya başlarsınız. Öncelikle bir "Hedef ve Kapsam" belgesi
yazmanız ve müşteriye onaylatmanız gerek. Daha sonra senaryo analizlerine ve firmanın müşterisi ile
arasındaki diyaloglarını belgelendirmeye çalışırsınız. Müşterinin aklına sürekli yeni gereksinimler gelir
sizde süreç içinde dökümanları güncelleyerek bunlara karşılık vermeye çalışırsınız.
Her yazılım projesinde kullanılacak genel parçalar, süreçler, modüller ve belgeler vardır. Örneğin
senaryoların belgelendirileceği Word şablonları vardır, çeşitli test verilerinin oluşturulacağı Excel
belgeleri vardır, programlama alt yapısını oluşturacak; kredi kartı sorgulama, güvenlik, rol dağıtımı, ekran
tasarımları, bazı iş akışları, web temaları vardır. Tüm bu malzeme proje daha ortada yokken hazırdır.
Mesela kek yaparken yumurta kullanıyoruz ama oturup yumurtayı yeni baştan üretmiyoruz di mi? Zaten
çok zor olurdu, önce tavuk mu üreticez yoksa yumurta mı?
Öncelikle refactoring olayından başlayalım. Sadece yazılan kod için değil, projenin her
aşamasında kullanılabilecek bir yöntem. Refactoring üretilen parçanın daha kolay anlaşılması, bakımının
kolaylaştırılması, hızlandırılması, gereksiz yerlerinin kırpılması, dökümantasyonunun iyileştirilmesi adına
yapılacak bir dizi işlemdir. Tek düşünmeniz gereken bu parçayı sizden sonra başka projelerde kullanacak
kişilerin yardıma ihitiyacı olmadan (ve size küfür etmeden) rahatça kullanabilmesi ve performansının
düşmemesidir.
Örneğin bir döküman şablonunu ele alalım. Projenin başında senaryoları yazarken Word'ü açıp
Allah ne verdiyse yazıyordunuz. Sonradan farkettiniz ki aslında her senaryo için belli başlıklar var ve
hepsinde ortak kullanılıyor (farklı isimlerde olsa bile). Bir Word şablonu oluşturup herkesin bunu
kullanmasını sağlarsanız, firma içi iletişim 10 kaplan gücünde olacaktır ki Agile programlama yapanlar için
baş kurallardan bir tanesidir.
Yada yazdığınız bir fonksiyonu düşünün. Hani yapmazsınız ama; ilk yazdığınızda çok uzun ve
karmaşık bir algoritma kullanmış olun. Sizden sonra gelen programcılar şöyle diyecektir. "Ağbi NASA'da
rocket science üzerine çalıştım, fezaya 10 tane roket gönderdim, ama böyle karmaşık bir algoritma ne
gördüm nede duydum". Böyle konuşmalar duymak istemiyorsanız yazdığınız fonksiyonu parçalara bölüp
yeniden düzenlemeniz, belki bir kaç pattern kullanmanız, bir arayüzde çeşitli fonksiyonları toplamanız,
algoritmaları hızlandırmanız ve ünite testlerini genişletmeniz gerekir.
Refactoring genelde sürümleri verdikten sonra yapılır. İlk sürümü verip müşteriyi memnun
ettikten sonra oturup daha iyi nasıl yapabilirim diye düşünmek, biraz kafa patlatmak ve ünite testlerini
bozmadan yeniden yapılandırmaya gidebilirsiniz. Böylece ürün daha kolay anlaşılır, bakımı kolay ve yeni
özelliklerin rahatça eklenebileceği bir hal alır ki hem sizin için hemde sizden sonra gelecekler için sağlam
bir alt yapı olur. Bir sonraki projenizi yaparken bu alt yapıları kullanır, üretim zamanını yarıya
indirebilirsiniz.
İşte Reusing bu aşamada devreye giriyor. Tasarım Pattern'leri, hazır modüller, temalar,
şablonlar, program parçaları, fonksiyonlar, testler ve aklınıza gelebilecek daha pek çok şey tekrar
kullanılabilir. Oturup koca bir güvenlik modülünü tekrardan yazmaktansa bir önceki projede yazdığınız
güvenlik modülünü refactoring yaparak yeniden kullanılabilir hale getirmek daha kısa sürecektir.
Kural olarak; yazdığınız bir fonksiyonun tekrar kullanılabileceğini tahmin ediyorsanız, refactoring
yapmanız şarttır. Böylece üretim maliyetlerini azaltmış oluruz. Firmanın büyüklüğü yada projelerin
sayısıda sizin için bir kıstas olmasın. Zaten topu topu iki projemiz var refactoring ile zaman harcamaya
gerek yok diye düşünebilirsiniz. Fakat daha fazla projeler almak, projeleri zamanında teslim etmek,
büyümek ve uzun süreli bir firma olma vizyonumuz varsa bu yöntemleri muhakkak kullanmamız gerekir.
Böylece piyasada adından iyi söz edilen, köklü bir firma olursunuz.
Ben her zaman değişimden ve yenilikten yanayım. 10 senedir kullanılan iş süreçlerini

değiştirmekten kaçınmam. Tabii ki öncesinde bir analiz ve maliyet-fayda analizi yaparım. Bir heykeltıraş
gibi olanı yontmayı veya yeni şeyler ekleyerek geliştirmeyi her zaman düşünürüm. Biraz sanat biraz da
mühendislik ile daha iyisini daha kısa zamanda üretmek için yollar ararım. Örneğin açık kaynak
projelerde sizin kullanabileceğiniz bir sürü modül olabilir. Birileri sizin yaşadığınız problemleri zaten
yaşamış ve çözmüşdür. Hatta o çözümleri refactoring yaparak herkesin kullanabileceği hale bile
getirmiştir. Arayıp bulmak size kalıyor.
Yazılım Uzmanı olarak sizin kariyeriniz için de iyi olan tarafları var. Öncelikle yöntemleri
öğreniyorsunuz, bunları tekrar uygulamak sizin için çocuk oyuncağı olacaktır. Özgeçmişinize refactoring
ve reusing sonucu firmanıza ne kadar yarar sağladığınızı yazabilirsiniz. Örneğin "Falan projede
uyguladığım refactoring ve reusing yöntemleri ile görevlerimi %30 daha az zamanda bitirdim. Projenin
tamamlanma sürecini de %15 hızlandırdım" gibi. Bu tür başarılar yazacağınız ön kapakta çok yararlı olur.
Bold yazılmış kelimelerde dikkati çekmek için iyi bir yöntemdir. Ama lütfen dürüst olmaya özen gösterin.
3.18 Kariyer Olayı
Bilgi Teknolojileri alanında kariyer yapmak isteyen gençlere bir kaç öğüt. Diğer okuduğum
bloglardan ve kendi deneyimlerimden derledim.
Rahatlık kariyerinizi öldürür. Eğer zorlanmadığınız bir alanda uzun zamandır çalışıyorsanız her
üç ayda bir özgeçmişinize yeni bir hüner ekleyebilmeye dikkat edin. Eğer ilk üç ayda yeni bir şey
ekleyemezseniz ikinci üç ayda mutlaka yeni bir şeyler ekleyebilin. Eğer çalıştığınız yerde yeni şeyler
öğrenmeye fırsat yoksa açık kaynak projelere katılabilir ve boş durmadığınızı kanıtlayabilirsiniz. Ben
bazen eğitimlere katılıyorum bazende açık kaynak projelere yardımda bulunuyorum. Yada yeni bir
ürünün kurulum konfigürasyon adımlarını araştırıyorum.
Kariyerinize karar verin. Hedeflerin belirlenmesi bu hedeflere ulaşılabilmesi için atılacak ilk
adımdır. Hangi projeye girersem benim için en iyisi olur, o projeden neler öğreneceğim ve proje sonunda
özgeçmişime neler ekleyebilirim gibi soruları kendinize sorun. Eğer firma içindeki kaymalardan dolayı,
size hiç bir şey katmayacak bir projeye katıldıysanız artık o firmadan ayrılmanın vakti gelmiş demektir.
Genelde bu durumlarda firma sahipleri çeşitli teşvik veya vaatlerle sizi projede tutmaya çalışabilirler
fakat kariyeriniz daha önemlidir. Ben Türkiye’de çalışırken yurt dışında çalışmak aklımın ucundan bile
geçmezdi. Ya tutarsa diye özgeçmişimi gönderdiğim bir firma beni cepten arayınca epey bir şok
olmuştum. 1 ay sonra yeni işimde başladım ve kariyerim için çok iyi oldu.
Taşeron işler hayatın bir gerçeğidir. Kapitalist sistemlerde işler yüksek maliyetli bölgelerden
düşük maliyetli bölgelere doğru kayar. Tabii ki taşeronun kalitesi yönetim açısından kabul edilebilir ise.
Bir firma için kabul edilebilir olan kalite seviyesi diğer bir firma için kabul edilmeyebilir. Eğer işlerin
taşeron firmalara kayacağını sezinlerseniz o işten hemen ayrılın. Yada kendinizin başka bir firmaya
kiralanacağını sezinlediğiniz zaman vakit gelmiş demektir.
İşe girerken imzaladığınız anlaşmalara dikkat edin. Piyasada elinizi kolunuzu bağlayacak
anlaşmaları imzalamaktan çekinin. Sizin özgürlüğünüze saygı duymayan bir firmada nasıl çalışabilirsiniz
ki. Eminim o firma e-postaları ve messenger loglarını da okuyordur.
Hayatınızı tamamı ile iş bulma ajanslarına bağlamayın. İş bulma ajanslarının her zaman iyi
bağlantıları olmayabilir. Sadece özgeçmişleri gönderecekleri birer e-posta adresleri vardır. İş
değiştirmede en büyük yardımcı bence fuar ve toplantılardır. İnsanlarla yüz yüze konuşup iyi izlenimler
bırakma olanağı en çok bu tür organizasyonlarda ortaya çıkar. Ayrıca kişisel bir kart bastırıp kontak
bilgilerinizi dağıtmanız da iyi olur. Ürünleri görüp deneyebileceğiniz, deneme sürümlerini alabileceğiniz
ve bilgiyi ilk ağızdan duyacağınız yegane yer fuarlardır.
E-posta çok ucuz bir yöntem. Kariyer.net gibi sitelerde iş ilanı veren kuruluşlar geriye çok fazla
e-posta alırlar ve sizin e-postanızın okunma şansı yok denecek kadar azdır. Ayrıca iş başvurusu yapan
kişiler iş için gerekli yeteneklere sahip olmasalar dahi özgeçmiş gönderirler. Buda okunacak bir sürü e-
posta anlamına geliyor. İş başvurularında eski yöntemleri denemek iyi sonuç verebilir. Önce
özgeçmişinizi güzel bir kağıda basın ve dosyalayın. Bir ön yazı yazıp neden o firmada çalışmak istediğinizi
anlatın. Takım elbisenizi giyip saçınızı düzeltin ve firmanın yolunu tutun. Böylece insan kaynakları ile
doğrudan görüşmüş ve belkide iyi bir izlenim uyandırmış olursunuz. İşe alınmasanız bile akılda
kalacağınız garantidir. Ben 98 yılında ilk mezun olduğunda gelen ilk Bilişim fuarına gittim. Amaç katılan
firmalar kitapçığını almaktı. Fuarı bile gezmedim. Eve gelip fax programımı açtım ve sanıyorum 75 tane
firmanın fax numarasını tek tek kaydettim. Birde Word’de özgeçmiş hazırlamıştım. Programın Auto-Send
özelliği ile 70 kadar firmaya özgeçmiş gönderdim. Ertesi gün sanırım 20-25 kadar telefon aldım, Hepside
görüşmek istiyordu. Tabii bunları organize etmek için bir ajanda kullanmam gerekti. Aynı semtte olanları
aynı günlere peş peşe koymaya çalışmıştım. Sonuçta bir tanesine girdim ve başladım çalışmaya. O
yıllarda önemli olan para değildi sadece deneyim yapmamın gerektiğini biliyordum bu yüzden maaşı
önemsemedim. 2 sene sonra ise artık ben Bilişim fuarında görevli olarak yer almaktaydım.
Çevre oluşturmak için blog yazmak ve kullanıcı grubu toplantılarına katılmakta çok önemlidir.
Eğer çevrenizde belli bir kullanıcı grubu yoksa bir tane siz başlatabilirsiniz. Çevre oluşturmak için her
türlü fırsatı değerlendirmeye bakın.
Sevdiğiniz işi yapın, para arkasından gelecektir. Piyasada çok insan gördüm sırf programcılık iyi
para veriyor diye programcı olan. Tabii zaman içinde kaybolup gittiler bu kişiler. Programcılık
yapamasanızda IT alanında yapılacak pek çok iş seçeneği var. Örneğin sistem analisti, modelleme
uzmanı, sistem yöneticisi, proje yöneticisi vs. Herhangi birini seçip kariyerinize o yönde şekil vermelisiniz.
Beta ve deneme sürümleri ile yeni şeyler öğrenmeye başlayabilirsiniz. Eğer eski teknolojilerde
bir şeyler yazıyorsanız (ASP, VB6, COBOL vs.) yeni teknolojileri takip edin ve bir sonraki trendin ne
olacağını önceden sezinlemeye çalışın. Böylece yeni teknolojiler piyasaya çıktığında sizde en az diğerleri
kadar bilgili olacaksınız. Tabii bu durum eski firmanızı bırakmanıza neden olabilir ama zaten siz o firmada
eski teknolojileri bilen kişi olarak tanınıyorsunuz ve bu önyargıyı kırmak biraz zor en iyisi ayrılmak ve
yeniden başlamak. Tek dezavantajı yeni teknolojiyi öğrenmek için iş saatleri dışında zaman harcamanız
gerekliliği fakat kariyerinizin bir atlama yapması için sanıyorum bu gerekli. Eski teknolojileri bilmek bir
avantajda olabilir. Eğer sizden başka tamir edecek kimse yoksa kısa kontrat usulü çalışabilirsiniz. Ürünü
tamir eder, ücretinizi tahsil eder ve olaydan çekilirsiniz.
Kariyer için daha söyleyecek çok şeyim var. Başka bir yazıda onlarıda yazacağım.
3.19 İspanyol Teorisi
İspanyol Teorisi: İşkolik yazılım ekibi, üretkenliği daha önce duyulmamış seviyelere getirmek
için, ücretsiz olarak normal saatler dışında çalışabilir.
Bu çalışma aslında bir didinmedir. En sonunda da tüm proje ekibi istifa eder. Peki bunun
maliyeti nedir? Bu tür bir maliyet analizi hiç bir zaman planlara dahil edilmemiştir edilmeyecektir de. De
Marco’nun Peopleware kitabını okurken benim piyasaya ilk atladığım 98 yılı gözümün önüne geldi. Hele
sayfa 18’deki “Reprise” başlıklı hikaye bana B2 Yazılım için OCT Bilişim’de (isimleri değiştirdim) yaptığımız
projeyi hatırlattı. Proje müdürü projeyi 6 ay’da bitireceğimizi söylüyordu (kullandığımız yazılım aracına
güvenerek). Ama tabii buna kimse inanmamıştı. B2 Yazılım’ın müdürü dahi zaten 6 ay içinde analizleri
bile bitiremeyeceğimizi biliyordu. Tabii bize bunu sanırım 7. yada 8. ayda söylemişti. Üstüne birde yazılım
ekibinin kullanılan yazılım aracını fazla bilmediğini eklemeliyim.
Biz tabii ki yeni mezun olmuş ve profesyonel hayata yeni atladığımız için canavar gibi başladık
projeye harıl harıl yazdık. Yeni mezun olduğumuz için söylediklerimize önem veren de yoktu. Nede olsa
tepede birileri bizim yerimize tüm planları yapmış ve 6 ay gibi bir zamanla çıkagelmişti. Bizde acaba 6
ayda olur mu, diyerek harıl harıl yazdık. Proje müdürü İspanyol, çalışanlar ise olaya Fransız kalmıştı.
Geceleri ofiste yattığımız günleri daha dün gibi hatırlıyorum. Bir arkadaşımız sürüm öncesi ofise Pazartesi
girip Perşembe günü çıkmıştı. Proje müdürü ne olursa olsun ilk bir kaç modülün sürümünü vermek
istiyordu çünkü... Verdi de... Ama 6 ay sonunda değil. Bizimde migren ağrılarımız arttı. Spor yapıyordum
düzenli, onu da bırakmak zorunda kaldım. Sağlığım bozuldu.
Sizinde çalıştığınız işyerlerinde bu tür İspanyol proje müdürlerine rastlamanız mümkün. Kısa
dönem taktiği ile yeni yetme bilişimcileri köle gibi çalıştırarak üretkenliği arttıracağını zannedecek bir
garip görüş içerisinde oluyorlar. Kendinizi sakın bu tür proje müdürlerine kaptırmayın. Unutulmayacak
en önemli kural: İnsan bu kadar dar proje planı baskısı altında daha iyi çalışmıyor sadece daha hızlı
çalışıyor. Bu arada ürünün kalitesi ve bizim iş memnuniyeti de bayır aşağı gidiyor tabii ki.
İlk 3 ay sonunda 8 kişilik ekipten kopmalar başladı. Bu projede gelecek görmeyenler başka işler
bulup yollarına devam etti. 1 senenin sonunda kala kala orjinal ekipten iki kişi kaldı. Ben ve Pazartesi
günü girip Perşembe günü çıkan arkadaş. İki de yeni eleman katıldı projeye. Eşim Cumartesi Pazarları
beni görebilmek için ofise yemek getiriyordu. Özel hayat filan kalmamıştı. Bu arada proje el değiştirdi,
ofisi taşıdık, masaları ben monte ettim tekrar. Networkünden, bilgisayarların kurulumuna kadar her şeyi
yaptım. Gene harıl harıl çalışmaya devam. Garip bir zevk alıyordum bu işten.
Tabii bu arada proje neredeyse sonuna gelmişti, fakat test ekibinde yeterli kişi olmayınca
hataların bulunması ve bunların düzeltilmesi gecikiyordu. Maaşlar gecikiyordu. Önce yemek fişlerini
kestiler, yol parası zaten epeyden beri yoktu. Maaşlar da en sonunda ödenmemeye başladı. İki ay maaş
ödenmeyince benimde saksı çalışmaya başladı artık. Sanırım burada esas yanlışı ben yapıyordum. Yeter
artık diyerek sağa sola özgeçmiş göndermeye başladım. Bu proje boyunca aldığım ücret benim için
önemli değildi aslında. Piyasaya yeni atladığım için deneyim ve bilgilerimi genişletmek istiyordum. Tek
yararı benim için bu oldu. Ama tabii bu arada evlendim ve artık bir ev geçindirmeye başladım. Aldığım
ücretin önemi yükseldi. Tüm faturalarımı ödeyebilecek durumda değildim. Allahtan eşim de çalışıyordu.
Pek çok planımızı ertelemek zorunda kaldık.
Ne yazık ki bu filmin sonu Hollywood filmleri gibi güzel bitmedi. Projeyi daha sonraları ayağa
kaldırmak için girişimler oldu. Ben 1 sene sonra tekrar geri döndüm fakat bu seferde benden başka kimse
kalmamıştı. Gene network kurmalar, bilgisayar kurmalar, ofis mobilyası monte etmeler. Bunları yaparken
kendi kendime gülüyordum. Sen kaşındın Gürkan diyerek. Ne yapıp edip bir kişi daha aldım projeye ama
sırf o kişiyi eğitmek 3 ay aldı. 3 ayın sonunda da yüzde yüz üretken olmasını bekleyemezsiniz. Daha çok
eleman gerekiyordu. Bir veritabanı uzmanı, sistem yöneticisi, bir kaç yazılım uzmanı daha... Bu arada ofis
yeni yere taşındığı için evden ofise tam 3 saat yol gidiyordum. Akşam saatinde eve dönmek daha bir
berbat oluyordu (gene 3 saat). Bütün gün yorulan halk otobüste vapurda patlayacak bomba gibi, suratlar
beş karış.
Sonuç hüsran tabii ki. Firmanın kaybı çok büyük oldu. Proje bitmedi. İyi niyet bir yere kadar
fakat ben gene bir iş bulup ayrıldım. Alacaklar gene kaldı. 4 senenin sonunda artık dersimi almış ve
arkama bakmadan ileriyi planlamam gerektiğini anlamıştım. Planımızı yaptık ve uyguladık. Benim bu
projeye verdiğim değer kadar firma bana değer vermiş olsaydı belkide sonuçlar çok daha farklı olabilirdi.
3.20 İş Başvurusu ve Dikkat Edilecekler
Bir iş başvurusunda başarılı olmak için ne gibi özelliklere sahip olmanız gerekir veya işverenler
nelere dikkat eder hiç düşündünüz mü? Joel Spolsky'nin "The Best Software Writing I" kitabından ve
benim deneyimlerimden derlediğim şu maddelere bir göz atın.
Sürekli öğrenme isteğiniz var mı? Yeni çıkan teknolojileri ne kadar takip ediyorsunuz? Yeni bir
şeyler öğrenmek ve bilgilerinizi güncellemek için ne zaman bir araştırma yaptınız? Son 1 sene içinde ne
gibi kurslara yada seminerlere katıldınız? Belli bir öğrenme planınız var mı? Bilişim Teknolojileri alanında
ayakta kalabilmek için en önemli şey sanırım yeniliklere ve öğrenmeye açık olmak. Son aldığınız
kitaplara, kurduğunuz programlara, gezdiğiniz web sitelerine bir göz atın. Blogunuzda yazdığınız yazılara
bir bakın. Yeni bir şeyler var mı? Sürekli öğrenme isteği içinde olduğunuzu gösterecek bir kanıtınız var
mı?
Neleri bilmediğinizi biliyor musunuz? Zayıf olduğunuz konuların bir listesini yapabilir misiniz? Bu
zayıflıklardan konuşurken utanıp sıkılmamayı başarabiliyor musunuz? İnsanoğlu kendi zayıflıklarından
bahsetmeyi pek sevmez. Ama işverene dürüstçe bunlardan bahsetmeniz ve bunları kapatmak için neler
yapacağınızı sıralamanız size bir artı puan kazandırabilir.
Elini taşın altına koyabiliyor musun? Projenin veya ürünün başarılı olması için elinizden geleni
yapacağınıza emin misiniz? Özveri isteyen bazı işleri söylenmeden yapabilir misiniz? Genelde BT
sektöründe çalışmak demek, akşam saatlerini ve hafta sonlarını ziyan etmek anlamına gelir. Hani bu
ecnebiler derya "work smarter not harder" çok çalışmaktan ziyade akıllı çalışmak. Bazı işleri otomatize
ederek bunun önüne geçebilirsiniz. Buna rağmen halen daha özveri isteyen işler olacaktır. Otomatize
edilemeyen işler, yada birisinin başında beklemesi gerekecek işler her zaman olacaktır. Hakikaten bu tür
işler ortaya çıktığında elinizi taşın altına koymaktan çekinmeyin. Ama tabii harcadığınız zamanın ve
emeğin karşılığını da alacağınızdan eminseniz.
Eğitim durumunuz nedir? Bir üniversiteden mi mezunsunuz yoksa alaylı olarak mı BT

sektöründesiniz? Alaylı veya mektepli olmanın hiç bir farkı yok, önemli olan bildiğinizi ispatlamak ve
eğitiminizle bunu ortaya koymak. Gittiğiniz kurslar veya okuduğunuz Bachelor Degree'nin önemi büyük.
Üniversite okumadıysanız bunu iş deneyimleriniz ile ve gittiğiniz kurslar ile kapatmanız mümkün.
Üniversite okuduysanız ve sektöre yeni atlayacaksanız analitik problem çözme ve araştırma geliştirme
konularında iyisiniz demektir. Her iki durumda da firmaya yararlı olacağınızı belirtebilirsiniz.
Proje ekibi içinde nasıl çalışılır biliyor musunuz? Hiç Açık Kaynak bir projeye katıldınız mı?
Birlikte çalışma, kod ortaklığı, Sourceforge, Subversion, CVS vs. gibi kavramlardan haberiniz var mı? Açık
Kaynak projelere katılmak veya zaten başkasının yaptığı bir ürünü başka bir şekilde yapmak "boş iş" gibi
gelebilir. Kaç tane açık kaynak blog uygulaması, kaç tane CRM vs uygulaması olduğu ortada. Tekerleği
yeniden icat ediyor bile olsanız bunun size kazandıracağı deneyimler tartışılmaz. Hem bir ekip içinde nasıl
çalışacağınızı öğreniyorsunuz hemde teknoloji ve kullandığınız araçlar hakkında yeni şeyler
öğreniyorsunuz. Bu öğrendiklerinizi iş görüşmelerinde muhakkak belirtin.
İyi kod deyince aklınıza ne geliyor? Yazdığınız kodun iyi olabilmesi için ne tür özellikler
gerekiyor? İyi kod yazabiliyor musunuz? Performans konusunu hiç düşündünüz mü? Kodlamadan önce
testleri yazmak gibi bir şey daha önce duydunuz mu? Yazdığınız kodda bir standart var mı? FXCop gibi bir
araçla kodunuzu kontrol ettiniz mi? Refactoring hiç yaptınız mı? İyi kod kişiden kişiye, firmadan firmaya
değişir. Kimi zaman performans ön planda iken, kimi zaman sadece o işin yapılması önemlidir. Firmanın
stadartlarını hızlı kavrayıp uygulayabilmek te size bir yarar sağlar. Değişikliklere hızlı ayak uydurabilmek
bu açıdan önemlidir.
Boş zamanlarınızda TV seyretmek yerine kod yazmayı tercih ediyor musunuz? İşiniz aynı
zamanda bir hobi olarak devam ediyor mu? Yaptığınız işten zevk almanız o işin kalitesini yükselten en
önemli etkenlerden biri (bunu birde firma sahiplerine anlatabilsek). Hobiler genelde bir boş zaman
uğraşıdır ve beyni dinlendirmek için yapılır. Ama boş zamanınızda bile kod yazmaya yöneliyorsanız bu
sizin işinizi ne kadar sevdiğinizi gösterir. İşini bu kadar seven birisini çok fazla düşünmeden işe alırdım.
Belge yazmak ile aranız nasıl? Teknik açıdan yetersiz bir kişinin okuyunca anlayabileceği bir
belge üretebilir misiniz? Kodladığınız modüllerin ne yaptığını genel olarak yazabilecek kabiliyetiniz var
mı? Blog yazıyor musunuz? Tamam yazılım uzmanları belge yazmayı pek sevmez, hatta bu işi otomatize
etmek için araçlarda var. Ama kodun içinde yeterli derecede yorum ve açıklama yoksa, o araçlarda pek
bir işe yaramaz. Belge yazabilen bir yazılım uzmanını değerlendirmelerde öncelikli tutardım.
Analiz nasıl yapılır, UML nasıl kullanılır, müşteri ile nasıl konuşulur, müşteri istekleri nasıl
belgelenir ve koda dönüştürülür hiç düşündünüz mü? Bu konularda deneyiminiz var mı? Bir ürünü ortaya
çıkartabilmek için öncelikle müşterinin ne istediğini iyi kavramak gerekir. Yoksa ürün ortaya çıksa bile
müşterinin istediği gibi bir şey olmaz. İnsan ilişkilerinde önemli olan dinlemeyi ve konuşmayı iyi
yapabilmektir. Karşındaki kişinin psikolojisini, değer verdiği şeyleri, espri anlama kabiliyetini kısa
zamanda kavrayıp "nabza göre şerbet" vermelisiniz. Anlaşıldığını anlayan müşterinin size olan güveni
artar. (dönüp bu son cümleyi tekrar okuyoruz). Anlaşıldığını anlayan müşterinin size olan güveni artar.
Bu soruların tümüne evet cevabını vermeniz gerekli değil. Ben bir öngörüşmede bu konuları
sorar ve kişinin ekibe neler katacağını, istediğimiz özelliklere uyup uymadığını bulmaya çalışırdım.
3.21 Yeni İş Kuracaklara Bir Test
Aşağıdaki test http://osc.gigavox.com/ adresinde 25 Nisan 2006 tarihinde yayınlanan, Greg

Gianforte'nin yaptığı bir konuşmasından alınmıştır. Konuşmada kendi deneyimlerine yer veren Greg
daha sonra dinleyicileri test etmek için bu soruları soruyor. Benim çok hoşuma gitti bu sorular ve sizlerin
de yararlanacağınızı tahmin ediyorum. Vezir'de bahsettiğim konular ile hemen hemen örtüşüyor.
Bu podcast'e direk link vermiyorum. Önce soruları kendi deneyimleriniz ile cevaplamanızı
ve sonra podcast'i dinleminizi öneririm. Haftaya cevapları ve benim yorumlarımı burada yayınlayacağım.
İşte sorular
1-Eğer sıfırdan yeni bir iş yada yazılım firması kurmak istiyorsanız ilk yapacağınız iş ne olmalı?
a-Bir iş planı yazmak
b-Bir sürü kişiyi arayıp pazarın sorunlarını/isteklerini öğrenmek
c-Bir prototip üretmek
d-Bir pazarlama uzmanını işe almak
2-Bir fikriniz var, sonraki adım ne olmalı?

a-İş planını uygulamaya koymak
b-Bir ofis kiralamak ve kullanılmış ofis mobilyaları almak
c-Fikriniz için patent başvurusunda bulunmak
d-Fikrinizi 300 müşteriye göndermek ve daha sonra arayıp ne düşündüklerini sormak
3-İyi bir ürünü ortaya çıkaracak tüm özellikleri listelediniz, sonraki adım ne olmalı?
a-Fikrinizi koruyacak bir avukat bulmak
b-Kendinizin satacağı bir prototip üretmek
c-Bir yerlerden para bulmaya çalışmak
d-Bir pazarlama uzmanı bulup ürününüzü satmasını sağlamak
4-Bir müşteri adayı buldunuz, sonraki adım ne olmalı?
a-Beta programına katılmaları için ikna etmek
b-Bir sipariş vermeleri için çalışmak
c-Henüz bir ürününüz olmadığını söylemek
d-İleride ekleyeceğiniz özellikleri anlatmak
5-Ürününüz müşterinin istediği şeyleri yapmıyor, yapılacak en iyi şey:
a-Bu özellikleri eklemeyeceğinizi söylemek
b-Bu istenen eklentiler için müşterinin para ödemesini sağlamak
c-Siparişi alıp 4 hafta içinde ürünü getireceğinizi söylemek
d-İstenen özelliklerin uygulanmasının ne kadar zor olduğunu anlatmak ve mevcut sürümü

alması için çalışmak
6-Sektörün en fazla satan yayın organı ürününüz hakkında bir makale yazacak ve yan sayfada
ki reklam alanını da size satmak istiyor, yapılacak en iyi şey:
a-Reklam alanını almak
b-Reklam giderleri bütçesinin dolduğunu söylemek
c-Yeterli paranızın olmadığını söylemek

d-Cehennemin dibine gitmesini söylemek
7-Bir pazar araştırma firması, firmanız hakkında bilgi ve ayrıntılı finansal döküm istiyor ne
yapardınız?
a-Bilgiyi veririm
b-Nazikçe redederim
c-Muhasebecimize gönderirim
d-Mesajlarını cevaplamam
8-Önemli bir müşteri adayı sizinle görüşmek için 1 hafta sonrasına randevu istiyor. Ama siz
hala evdeki ofisinizden çalışıyorsunuz, ne yaparsınız?
a-Yeni başladığınızı ve ofisinizin olmadığını söyleyin
b-Müşteri gelmeden önce bir ofis kiralayın
c-O hafta seyahatte olacağınızı söyleyin
9-Bu işte tam zamanlı çalışan tek kişi sizsiniz. Müşteri adayı kaç çalışanınız var diye soruyor.
Cevabınız:
a-Ben bu firmanın tek çalışanıyım demek
b-5
c-20
d-50
10-İlk satışınızı yaptınız ve bir miktar kar elde ettiniz, yapacağınız ilk şey?
a-Kendime zam yaparım
b-Daha büyük bir ofise geçerim
c-Bir kutlama partisi yaparım
d-Bir danışmanı işe alırım
3.22 Testin Cevapları
Önceki yazımda Greg Gianforte'nin konuşmasından aldığım testi vermiştim. İşte burada da
Greg'in cevaplarını ve benim bazı yorumlarımı yayınlıyorum.
1-B
Eğer sıfırdan bir firma kuruyorsanız ve hangi sektöre yazılım yapacağınızı da biliyorsanız, tek
işiniz sektörün istediği bir yazılım üretmek. Bunun özelliklerini de en iyi sektör verir. Sektörden kişileri tek
tek arayıp isteklerini dinlemek hatta gerekiyorsa bir kahve yada öğlen yemeği sırasında fikirlerini almanız
bulunmaz bir kaynak olacaktır. Tabii bu tür kişileri bulmak zor olabilir. Kulüplere, barlara, toplum
örgütlerine, derneklere katılmak, toplantılarına gitmek veya örütbağı üzerindeki sosyal toplaşma
sitelerine üye olmak yapabilecekleriniz arasında.
2-D
Amacımız tam bir özellikler listesi hazırlamak ve bu listeyi hazırlarken de müşteri

gereksinimlerini gözden kaçırmamak. 1. soruda hazırladığımız listeyi sanki ortada bir ürün varmış gibi
müşterilere göndererek fikirlerini sorabiliriz. Ortaya tam bir özellikler listesi çıkar ki, ürünü geliştirmeye
hemen başlayabilirsiniz. Bu iki aşamadan sonra oturup ürünü ortaya çıkarmanız lazım. Yada en azından
bir prototip.
3-B
Prototip fikirlerin hayata geçirilmesi ve gizli kalmış isteklerin ortaya çıkması için zemin hazırlar.
Ayrıca bu ürünü sizin satabilmeniz çok daha önemli. Hem işinizi severek ve motive olarak yapacaksınız,
hemde ileride pazarlama uzmanlarına konuyu tam olarak anlatabilmek için öğreniyor olacaksınız. Zaten
firma ilk kurulduğunda finansman açısından çok fazla kaynağınız olmayacağı için bunu kendiniz yapmanız
çok daha iyi olacaktır.
4-B
En önemli olayınız bir sipariş almak olduğuna göre bunun için en fazla çabayı sarfetmelisiniz.
Sipariş almanız demek bir gelir akışı demektir ve buna hakikaten ihitiyacınız var.
5-B ve C
Her iki şıkta oluyor bu soru için. Eğer istekler çabuk uygulanabilir şeyler ise müşteriyi üzmenin
anlamı yok. Bence müşteriden bir hafta isteyip bir rapor çıkarın ve her isteğin kaça mal olacağını ve
süresini belirleyin. Müşteriye bu rapor ile gittiğinizde bu istekleri öncelik sırasına göre dizmesini önerin.
Müşterinin öncelik sırasına göre sizin belirleyeceğiniz miktardaki yeni özelliği ikinci sürümde
gerçekleştireceğinizi teyit edin. Müşteri sıralamayı sizin raporunuzdan önce yapmıyor çünkü fiyatları ve
zamanları gördüğünde daha gerçekçi bir sıralama yapacaktır.
6-B
Bu yayın organı zaten hakkınızda bir makale yazacak, birde yanına reklam koymanın bir anlamı
yok. Zaten finansman olarak dardasınız. Reklam giderleriniz 0YTL olabilir ve reklam giderleri bütçesinin
dolduğunu söylemek hiçte yanlış olmaz diyor Greg.
7-B
Hiç bir araştırma firması sizin kara kaşınız kara gözünüz için hakkınızda araştırma yapmaz. Bak
bu firmada yeni başlamış, aman yardımcı olalım, reklamını yapıp isimlerini duyuralım demez. Büyük
ihtimalle ürününüzü satmaya çalıştığınız bir müşteriniz hakkınızda kredibilite soruşturması yapıyordur ve
araştırma firmasına bu görevi vermiştir. Red edip istene bilgileri doğrudan müşterinize verebilirsiniz.
8-A
Greg bu soru için dürüst olun diyor çünkü eninde sonunda ortaya çıkacak bir yalan. Eğer müşteri
hala sizinle görüşmek istiyorsa listede birinci sırayı almaya hak kazanmış demektir. Aile içinde bir ortam
bile hazırlayabilirsiniz. Böylece müşterinin samimiyeti artar ve güveni yükselir. Samimi olmak daha sonra
ardı arkası kesilmeyen isteklerin gelmesine neden olabilir ama ilk başlarda zaten buna ihtiyacınız var. İş
ve arkadaşlık ilişkilerini birbirine karıştırmayın. Profesyonellik bu ikisini ayırmaya başardığınız zaman
başlıyor.
9-B
Bir önceki soruda dürüst olun diyen Greg bu soru için 5 kişi var demenizi öğütlüyor. Nasıl olsa
müşteri ürünü alıp kurana ve kullanmaya başlayıncaya kadar sizin firmanız büyür.
10-C
Greg parti yapın diyor fakat ben zaten bu kadar zor kazandığım bir geliri parti yaparak çar çur
etmezdim. Öz kaynaklarımı arttırmak için daha güçlü bilgisayarlar, iyi bir bilgisayar sandalyesi veya yeni
programcılar alarak devam ederdim. Kutlama tabii ki gerekli ama aşırıya kaçmadan, mütevazi bir şeyler
yapardım.
3.23 Programlama Öğrencisinin Derdi
Yer Bayburt, Atatürk Üniversitesi 2. sınıfında okuyan ve yazılım uzmanı olmak için çalışan bir
öğrenci var karşımızda. Esas programlama dersi öğretmeni gelemediği için bir lise öğretmenini derse
sokuyorlar. Bu öğretmenin verdiği bir ödev var.
-SourceSafe hakkında bilgi topla ve yaz...
Öğretmene net olarak ne istediğini sorduğunda itiraz yok diyor. Çünkü öğretmen ne istediğini
biliyor. Fakat bu öğrenci nereden başlayacağını bilemiyor çünkü örütbağı üzerinde yeterli bilgi de yok.
Belli ki öğretmen de bu konu hakkında derste konuşmamış.
Hani sürüm yönetimi gibi bu araçlarla yapılan bir iş hakkında sorsan pek çok bilgi mevcut. Fakat
Microsoft Visual Sourcesafe hakkında hakikaten Türkçe kaynak örütbağında yok. Bende bulamadım.
Öğrencimizin de bu araca erişimi yok; kurup, kullanıp ne olduğunu anlayacak mali gücü de!!! MS
Sourcesafe'in ise artık kullanılmayan ve yetersiz bir araç olduğundan ise hiç bahsetmeyeceğim. Halen
daha bir öğretmenin bu konuda ödev vermesi üzücü. Konu Subversion veya CVS olsa, hem örütbağında
ücretsiz mevcut, hemde kurup kullanmak için bir sürü dökümana erişmek olası.
Yazılım Uzmanı olmaya çalışan arkadaşımız bu işten çok sıkılmış ve okul bittikten sonra yazılım
uzmanı olmamaya karar vermiş bile. Zaten finallerden ve ödevlerden şu sıralar kafayı yemiş durumda,
birde üstüne üstlük böyle ne idüğü belirsiz bir ödev veriyorlar.
Sorarım, acaba bu öğretmen Sourcesafe hakkında hiç derste konuştu mu? Sürüm Yönetimi gibi
çok gerekli olduğunu düşündüğüm bir konu derste işlendi mi? Programcılık sadece kod yazmak mıdır?
Bu öğretmen Sourcesafe hakkında bilgi topla ve yaz derken nasıl bir şey istediğini biliyor
muydu? Belki de sürüm yönetimi konusunu kast etti ama sorma şekli yanlış. Belki de sürüm yönetimini
Sourcesafe'den ibaret sanıyor. Team Foundation Server, Subversion, CVS vs. nedir duymamış ömründe.
Bu öğretmen hakikaten bir şeyler öğretmek için mi orada bulunuyor yoksa salla başını al maaşını
tarzında mı takılıyor? Eğer öyleyse gerçekten daha da fazla üzülücem. Zaten bu öğrencimize ve eğitimin
kalitesine çok üzüldüm. Birde bu öğrencimiz gibi aynı sınıfta bu konu ile cebelleşen bir sürü başka
öğrenci var. Allah'ım ölmek istiyorum bu acıya dayanamam.
Valla sizi bilmem ama bu olay beni çok etkiledi. Hakikaten çok üzüldüm. MEGEP projesi
(www.megep.meb.gov.tr) çerçevesinde Tarık Bey'e yardım ediyordum az da olsa. MEGEP ile okullarda
yazılım uzmanı yetiştirmek amaçlı olarak ders programları üretilmişti. Fakat dandik ve Türkiye
bürokrasisine yaraşır bir biçimde sonlandı. Ders müfredatını geliştirmek için çalışan bir sürü gönüllü
kişinin 12 aylık emeği boşa gitti. Yazılan tonla döküman boşa gitti. İşte Tarık Bey'in blogundan bir alıntı:
Ocak 2006 - Aralık 2006 tarihleri arasında MEGEP (www.megep.meb.gov.tr) için tüm zaman ve
emeğimizi harcadık. Ama şimdi tam bir karmaşaya sürüklediler bizi. Ücretimizi 27 saatten 18 saate
düşürüldüğü için istifa dilekçelerimizi verdik. Ama tabi bizi oyalama yöntemi ile verilen görevleri zorla
yaptırma yoluna gidiyorlar.
1- BTT (Bilişim teknolojileri temelleri) dersinin son 5 modülü olan programlama ile ilgili
modüllerim okullarda BASIC dersi imiş gibi gösteriliyor. Bu sebeple yazdığım onca içerik işlenmiyor. 250
sayfalık derleme kaynak boşa gitti.
2- Access modüllerinin ilk 2'si hariç kalanlardan yazdığım 3 modül boşa gitti. istifa ettiğimiz için.
3- Erkek Teknik için hazırladığım http://etogm2.meb.gov.tr Modül takip projesi silindi.

Kullanılamadan boşa giden 2 aylık emek...
Yani son bir yılda yaptığım çalışmaların %90'ı "boş", faydasız hale geldi bir anda. Verilmeyen
"telif" haklarımız da unutulmamalı.
Modül takip projesinin bir yansısı http://www16.brinkster.com/tbagriyanik/modul adresinde de

vardı.
Bu insanlar Türkiye'de bir şeyleri düzeltmek ve daha da iyiye götürmek için neredeyse karın
tokluğuna emek sarfediyorlar. Yaptıkları işi seviyorlar ve gönülden çalışıyorlar. Fakat her zaman olduğu
gibi aptalca bürokrasiler ve bakanlıkların anlaşılması zor kararları yüzünden emekler çöpe gidiyor.
Türkiye'nin ileriye gitmesini istemeyen birilerinin bir oyunu mu yoksa bizim ürettiğimiz dandik kurallar ve
yönetim şekillerinin bir ürünü mü bu olanlar?
Bu kadar nefretle okuyan öğrenci ondan sonra hacker oluyor tabii. Aynen Anakin Skywalker'ın
korkularından dolayı oluşan nefreti ve akabinde de karanlık güçlerin tarafına geçişi gibi. Tema aynı.
Nefretle okuyan öğrenci mezuniyetten sonra kendini hazır hissetmediği için bir işe girmek yerine hacker
oluyor. Kolay yolu tercih ediyor çünkü elinde yeteri kadar bilgi birikimi yok. YAZIK. Ne ülke ekonomisine
bir katkısı nede kendisine bir yararı oluyor.
Üniversite kişilere nasıl araştırma yapacağını ve doğru bilgilere nasıl erişip

analiz edeceğini öğreten bir kurum olmaktan çıkıp, sınavların ve ödevlerin öğrencileri bezdirmek için
kullanıldığı, ödül ve ceza yöntemi ile sözüm ona eğitimin yapıldığı bir yer durumuna dönüşüyor. Türkiye
nasıl bilişim çağında diğer milletlerin yanında yer alacak? Alt yapı olmayınca nasıl üstüne sağlam yapılar
kuracağız? Teknolojoyi bu kadar tüketmeyi seven bir toplumsak neden üretimi için bir şeyler
yapmıyoruz? Neden MEGEP gibi bir proje için çalışan insanların emeklerini bir kalemde çöpe atıyoruz?
Neden Allah'ım neden?????
3.24 Bana Rakibini Söyle
Bir iş kurmak istiyorsunuz fakat çok fazla rakibiniz olacak bir pazarda iş yapacaksınız.
Müşterilerin sizin ürününüzü kullanması için nelerden vazgeçmeleri gerekiyor? Bu soruyu müşteri
tarafından ele alırsak; müşteri sizin ürününüze geçmek için vazgeçmesi gereken özelliklerden
vazgeçebilecek mi?
Sizin ürünün ne özelliği var da müşteriler şimdiye kadar kullandıkları rakip ürünü bırakıp,
tamamen farklı olan sizin ürününüzü kullanmaya başlasın ki? Kara kaş? Kara göz?
Yeni bir pazara adım attığınızda yada çok iyi bildiğiniz bir pazara firma olarak giriş yaptığınızda
müşterinin sizin ürününüzü kullanması için bazı özelliklerden vazgeçmesini beklemek çok yanlış olur.
Müşteri sizin ürününüze geçmek için fedakarlık değil açgözlülük gösterir. Tüketici psikolojisi
zaten buna dayanır. Yani hem rakip üründe olan özellikler hemde sizin ürününüzün ekstra özelliklerinin
toplamı müşteride kullanmak için bir arzu uyandırır.
Piyasa takibi ve rakip firmaların ürün özelliklerinin takibinin önemi bu aşamada ortaya çıkıyor.
Eğer pazarda herkesin yaptığını ve ek olarak bir kaç özellik daha sunabiliyorsanız başarılı olmanız için
yeterli zemin sağladınız demektir.
Geriye dönük uyumluluk ve rakip firmaların ürünleri ile uyumluluk bunlardan ikisi. Diyelim ki
müşteri X ürününü kullanıp bir veritabanı yaratıyor ve Y firmasının veritabanı uygulamasına geçmek
istiyor. Y firmasının veritabanı X ürünü ile tamamı ile uyumlu olmalıdır ki müşteri karar verme
aşamasında rahat davransın ve sancı yaşamasın. Ayrıca Y firmasının ürünü ekstra hizmetler de sunmalı
ve bu hizmetler müşterinin her zaman istediği fakat X ürününden alamadığı hizmetler olmalı.
Bir kere ürünü satıp sunduğunuz hizmetleri olduğu gibi bırakmakta iyi değil. Pazar takibi sürekli
kendini tekrar eden bir analiz sistemi ve rakipleriniz sizi alt etmek için her türlü yolu deneyecektir.
Mevcut müşteri tabanınız rakip firmaların ürünlerinde bulunan özellikleri talep edecekdir. Bu taleplere
cevap verebilmenin tek yolu önceden ürün hizmetlerinin planlanıp (müşteriden gelecek geri beslemeler
ve pazar takibi ile) sürümlere ayrılması ve müşterilere sunulmasıdır.
Firmanızda rakipleri analiz edecek ve müşterilerden gelecek yeni fikirleri değerlendirecek bir
departmanınız var mı? Üründe olacak özelliklere kim karar veriyor? Müşteriyi de projeye dahil edip
fikirlerini soruyor musunuz? Önünüzdeki 10 sürümü planlayacak kadar hizmeti listeleyebiliyor musunuz?
Bu sorulara vereceğiniz cevaplar sizin pazar payınızı ve devamlılığınızı büyük oranda etkileyecektir.
Duraksama Dönemi
Kimi firmalar sadece bakım ücretleri ile ayakta kalmaya çalışır. Firma stratejisi olarak üründe her
hangi bir geliştirmeye gitmezler. Çünkü müşteri tabanları o kadar iyidir ki pazarın neredeyse %50sini
ellerinde tutarlar. Yeni teknolojileri takip etmek yerine ellerinde olanla yetinir ve mevcut müşterilerden
gelen hatalar ile uğraşırlar. Bu aşamaya gelmiş bir firma bence Duraksama Dönemine girmiş demektir.
Eski parlak günleri yakalamak ve daha da büyümek için hem yeni teknolojilerin takibi hemde bunların
üründe uygulanması için planlanması gerekir. Pazarda kalmak için gelişme şart.
Duraksama Dönemindeki bir firmada çalışmak ise pek zevkli bir iş değildir. Genelde müşteri
destek işleri ile uğraşır ve teknolojinin gerisinde kalırsınız. Bildiklerinizi dahi unutursunuz. Kod yazmak
için pek fırsat olmaz. Artık başka maceralara doğru kanat açma vakti gelmiştir. Eğer mutluysanız
diyeceğim yok tabii.
Firma hacminin büyümesi beraberinde kurumsallaşmayı getirir. Profesyonelliğin birinci kuralı

mümkün olduğu kadar işi sektörün önde giden firmaları ile kontrat yöntemi ile yapmanız. Böylece
bütçelendirmeyi daha rahat yapabilirsiniz. Bilgisayarları, ağınızı, sunucularınızı ve kullandığınız yazılım
araçlarını yenilemek amacıyla tedarikçi firmaları iyi seçmeniz sizin için iyi bir referans olur. Müşteriye
güven verir. Veri güvenliği ve politik sebeplerden dolayı dışarıya veremeyeceğiniz işleri ise kendi içinizde
profesyonel olarak çözebilmek, yönetim anlayışının değişmesine neden olacaktır. Daha önceleri tepeden
tek bir kişi tarafından yönetilirken, şimdi yönetimi tabana yayıp firmayı bölümlere ayırmak ve her birimin
kendi içinde kendi kurallarını çıkartmasını sağlamak gerekir. Tabii ki en önemli şey birimler arası
haberleşme olmalıdır.
Sonuç
Bir firmanın pazarda geçireceği evrelere kuş bakışı bakmaya çalıştım. Önümüzdeki engeller ve
püf noktalarından bazılarına değindim. Kurumsallaşma ve hacim büyümesi ile ilgili deneyimlerimi
yazmaya çalıştım. Umarım yararlı olmuştur.
3.25 Yazılım Uzmanlığından Yöneticiliğe
Daha önce yazdığım şu yazıya atılan bir yorum üzerine bu yazıyı yazıyorum. Genel olarak yeni
mezun olmuş ve yazılım uzmanı olarak işe başlamış bir kişinin yöneticiliğe doğru uzanan yolda katetmesi
gereken aşamaları deneyimlerimden yararlanarak yazmaya çalışayım.
Hiç kimse evrenkentten mezun olur olmaz yöneticiliğe soyunmaz yada soyunmamalıdır. Yüksek
lisans dahi yapmış olsanız yöneticilik için gereken vasıflar henüz sizde bulunmaz çünkü yaşadığınız çevre
sizin gibi insanlardan oluşmuş izole bir çevredir (okul ve öğretmenler) ve ilişkiler yüzeyseldir, amaçlar
farklıdır. Proje yönetimi ve insan ilişkileri konusundaki deneyimin azlığı, firma içi kültürlerin bilinmemesi,
stres durumlarında ne yapılacağının bilinmemesi, planların zaman içinde nasıl değiştirileceğinin
bilinmemesi, kalite arttırımı ve testleri konusundaki deneyimin azlığı önümüzdeki engellerden bir kaçıdır.
Yeni mezun olmuş bir yazılım uzmanının yönetici olabilmek için geçireceği evrelere bir bakalım.
3.25.1 Mezuniyet Ve İlk Projeler
Mezuniyetten sonra tek hedefiniz bir firmada çalışmaya başlayarak hünerlerinizi geliştirmektir.
Evrenkentteki hocalarınızdan birer referans mektubu isteyin (ingilizce ve türkçe mümkünse) ve
özgeçmişinize referans olarak yazmak için izin alın. Gireceğiniz firmanın yeni bir projeye başlıyor olması
daha tercih edilen bir durum olmalıdır. Firma seçmek için yeni işe girecek mezunlara yazdığım şu yazıdan
ve kariyerinize karar vermek için şu yazıdan yararlanabilirsiniz. Ücret bu aşamada önemli olmamalı ve
size öğreteceği yetenekler ön planda tutulmalıdır. Unutmayın; okul bitti ama öğrenme süreciniz bitmedi.
En azından 4 yada 5 projede yer alıp gözlemlerinizi sürdürmelisiniz. Bu arada kalın ve çizgisiz bir defter
edinin ve projelerde yaşadığınız olayları, aksayan noktaları, bu aksayan noktaların nasıl çözülebileceğini,
yönetimin davranışlarını, projenin gidişatını, iş arkadaşlarınızın davranışlarını ve aklınıza gelen her türlü
bilgiyi ve deneyimi not edin. Bu defter sizin kara defteriniz olacak ve hiç kimsenin görmemesi gerekiyor.
Her akşam bu deftere yazdığınız notları tekrar tekrar okuyun. Yapılan yanlışlardan yada doğru
yöntemlerden feyz alın. Eski yazdığınız bilgiler yada deneyimler zaman içinde geçerliliğini kaybetmişse
bunları da yenileyin ve nasıl bir değişime uğradığını anlamaya çalışın.
Bu aşamada yönetime veya proje müdürlerine bir öneri veya tavsiyede bulunmayın zira sizi
dinlemezler ve boşuna vakit harcamış olursunuz.
%100 kod yazıp size verilen işleri zamanında bitirmek için elinizden geleni yapın. Zaten tüm
planlar sizin için yapılmıştır ve bitirme zamanları planlanmıştır. Tek işiniz kod yazmak ve zamanında
bitirmektir.
Problem çıkartmak yerine problem çözücü olarak tanınmaya gayret gösterin. Hoşunuza
gitmeyen eylemler ve bir şeyler söylemek istediğiniz durumlar olacaktır ama kendinizi tutun. Problemleri
çözmek proje müdürünün veya yönetimin işidir. Sizin işiniz kod yazmak. Sektörde ilerleyip iyi bir yerlere
gelebilmek sizin hedefiniz ve bu hedef doğrultusunda bu sorunlara katlanıyorsunuz.
Firma kültürünü öğrenin ve uygulayın. Standartları, davranış şekillerini, insan ilişkilerini, üst ast
ilişkilerini ve organizasyon şemasını çok iyi öğrenin. Firma kültürüne ters gelecek davranışlardan kaçının.
Ancak fikriniz sorulduğunda konuşun aksi takdirde ağzınızı açmayın.
Bu devrede okunacak kitaplar tamamı ile yazılım ile ilgili olmalıdır. Kullandığınız yazılım dilini
anlatan, veritabanını anlatan, üst seviye konuları anlatan kitaplar edinmeye ve yeteneklerinizi
geliştirmeye bakın. Code Complete, Writing Secure Code, Agile Modeling her zaman kitaplığınızda
bulunması gereken kitaplardan. Yeni teknolojileri ve ürünleri takip edin, kurun, deneyin. Personal
Software Process, Best Software Writing I, Joel on Software ek olarak okumanız gereken kitaplardan.
Okurken kara defterinize notlar alın ve projede uygulamak için fırsat kollayın.
İngilizce bilmiyorsanız hemen bir kursa giderek öğrenin. Yabancı yayınları, blogları, siteleri,
kitapları takip etmek için bu gerekli. Takip edeceğiniz bloglara bir kaç örnek olarak benim takip ettiğim
blogları vereyim (genelde .NET ve yazılım mühendisliği ile ilgili):
Yabancı bloglara örnekler
 Coding Horror http://www.codinghorror.com/blog/
 Scott Hanselmann http://www.hanselman.com/blog/
 Joel Spolski http://www.joelonsoftware.com/
 Mitch Denny http://notgartner.wordpress.com/
 Scott Watermasysk http://scottwater.com/blog/
 Secret Geek http://secretgeek.net/index.asp
 Seth Godin http://sethgodin.typepad.com/seths_blog/
 The Server Side http://www.theserverside.com/
 Phil Haack http://haacked.com/Default.aspx
Türkçe bloglara örnekler
 Mehmet Doğan http://www.unbf.ca/altiustu/
 Bilgi Güvenliği http://www.bilgiguvenligi.org/
 Ferruh Mavituna http://ferruh.mavituna.com/
 Hüseyin Ünal http://www.huseyinunal.net/

 Tekno Seyir http://www.teknoseyir.com/
Daha pek çok blog bulabilirsiniz ve sizin sektörünüze göre bunları çoğaltmak mümkün.
Aileniz ile yaşadığınızı ve gelirinizin kısıtlı olduğunu varsayarak önemli bir tavsiye vermek
istiyorum. İlk bir kaç maaşınız ile paranın alabileceği en iyi bilgisayarı alın. Evde bilgisayar başında
geçireceğiniz zamanı iyi değerlendirmek için çeşitli yeni teknolojileri veya birbirine zıt teknolojileri
denemeniz ve görmeniz gerekiyor. Firmada imkan bulamadığınız programları yada rakip firmanın
ürünlerini evde kurarak denemek size farklı bakış açıları katacaktır. Bunun için bir plan yapın; örneğin bir
haftayı belli bir programa ayırın ve genel olarak neler yaptığını öğrenmeye çalışın. Nasıl kurulur, kaldırılır,
yönetilir öğrenin.
Maaşınızın bir bölümünü ayrı bir banka hesabında biriktirin. Almak istediğiniz şeyler için
hedefler koyup parayı bu şekilde kullanın. Evin telefon faturasını (internet için en fazla sizin kullandığınızı
varsayarak) veya broadband ödemelerini siz yapmaya başlayın.
Açık Kaynak projelere katılıp kendinizi gösterin. Yada bu tür bir projeyi siz başlatın. Sourceforge,
Codeplex bu tür projeleri bulabileceğiniz yada başlatabileceğiniz tonla siteden ikisi. Genel bir bilgi
açısından yazdığım şu yazıyı okuyabilirsiniz (bitiremediğim bir yazı). Kara defterinizde proje vasıflı fikirler
eminim vardır. Bunları biraz daha pişirip proje olarak yapmaya çalışın. Sağlayacağınız deneyim paha
biçilemez olacaktır. Firma içinde çalışma imkanı bulamadığınız teknolojileri veya dilleri bu şekilde çalışıp
öğrenebilirsiniz. En güzeli firmada geliştirdiğiniz ürünü birde açık kaynak olarak geliştirmek olur :-). Bu
projeleri özgeçmişinize de yazın.
Bir sonraki aşamaya geçmek için bazı göstergeler vardır. Zaman geçtikçe firmadaki kıdeminiz
artar, yeni gelenlere sistemi öğretmeniz istenir, sorun çıktığında size sorarlar veya içinden çıkılması güç
işleri size verirler. Belli modüllerin tüm sorumluluğunu size verirler, müşteriye sunum yaptırırlar,
kurulumlara ve müşteri ziyaretlerine dahi gönderebilirler. Tüm bu saydıklarım bir üst aşamaya geçmeniz
için birer göstergedir. Bir sonraki aşama Kıdemli Yazılım Uzmanlığıdır.
Özetlersek
 Yeni bir projeye başlayan firmaya girin
 Ücret önemli değil
 Kalın çizgisiz bir defter edinin, not tutun
 4 yada 5 projede yer alın (aynı anda değil tabii ki)

 Açık kaynak projelere katılın/başlatın
 Okunacak kitapları edinin ve blogları takip edin
 İngilizce öğrenin (eğer bilmiyorsanız)
 İyi bir bilgisayar alın
 Maaşınızı çar çur etmeyin, planlı harcama yapın
 Bir sonraki aşama için göstergeleri iyi takip edin
Yukarıda anlattıklarım ilk 4 yada 5 yılınızı alacaktır. Bu arada özgeçmişinizi sürekli yenileyin ve
yaptığınız işleri sıralayın. Çalıştığınız firma size yükselme fırsatı vermiyorsa başka bir iş arayışı içine
girebilirsiniz. Eski firmanızla ilişkilerinizi iyi tutmanız size ilerde iyi referans verecekleri garantisini
sağlayabilir. Bu yüzden firmanızdan ayrılırken tüm kapıları kapatmayın ve muhakkak referans mektubu
alın. Referans mektubunda firmaya giriş ve çıkış tarihleri, yaptığınız işin vasfı, görev aldığınız projeler,
başardığınız işler, kullandığınız teknolojiler açık seçik yazmalıdır. Mümkünse hem İngilizce hem de Türkçe
referans mektubu isteyin.
3.25.2 Kıdemli Yazılım Uzmanı
Maaşınıza zam istemeniz doğaldır ama fazla uçmayın. Bir önceki aşamanın sonlarında
öğrendiğiniz insan ilişkileri sizin için bir temel olacaktır. İlişki kurmanız gereken organizasyonlara bir
bakalım.
 Yazılım ekibindeki yeni kişiler
 Pazarlama Ekibi
 Müşteriler
 Yönetim
Herkesin farklı dil konuştuğu, herkesin teknik bilgileri bilmediği bir ortamdasınız. Burada
geliştirmeniz gereken yeteneğiniz dinleme ve anlamadır. Aynı konuyu farklı ağızlardan farklı cümleler
kullanarak duyarsınız. Hem sizin kelime hazneniz genişler hemde kiminle nasıl konuşacağınızı öğrenmeye
başlarsınız. Ürettiğiniz dökümanları başkalarının okumasını sağlayarak ne anladıklarını test edin. Uzun bir
öğrenme devresi ve %70 kod yazımı, %30 insan ilişkilerinin analizi ile geçecek bir dönem. Yapacağınız
işleri anlamak için Anyazu hakkında yazdığım yazıyı bir okuyun.
Stres ve risk yönetimi konusunda da deneyimlerinizi arttırmanız gerekiyor. ISO ve IEEE

standartlarını inceleyerek bu konularda bilgi edinebilirsiniz. CMMI, SPICE, ISO, IEEE hakkında genel
bilgilendirme için yazdığım yazı işinize yarayabilir. Ayrıca zamanınızı iyi kullanabilmek için yaptığınız her
işin ne kadar zaman alacağını planlayıp, iş bittiğinde de plan ile gerçek geçen zamanı karşılaştırmanız ve
dersler çıkarmanız gerek. Böylece ileride size verilen görevler için ürettiğiniz tahmini zaman çizelgeleri
daha gerçekçi hale gelecektir. En azından MS Project nasıl kullanılır öğrenin veya bir kursa giderek temel
proje yönetimi hakkında bilgi edinin. Çalıştığınız firma size bu kursu almak için yardım sağlamıyorsa hafta
sonlarını kullanarak ve cebinizden ödeyerek gitmenizi tavsiye ederim (bir önceki aşamadan biriktirdiğiniz
parayı kullanın). Temel kursu bitirince ileri seviye kursunu da alın ve öğrendiklerinizi harfiyen
uygulamaya çalışın. Bir Yüksek Lisans programına da katılabilirsiniz, eğer yarım zamanlı bir program
bulursanız ve yeterli paraya sahipseniz veya firma sizi destekliyorsa kesinlikle tavsiye ederim.
Project Management Body of Knowledge (PMBoK) isimli kitabı internetten indirin ve okuyun.
Linkteki biraz eski ama işnize yarar. Yada http://www.projectmanagement.net.au sitesine üye olarak son
PMBoK kitabını okuyabilirsiniz. Bu kitap genel proje yönetimi ile ilgili bir yayındır ve içinde yazılım
alanında da kullanılabilecek pek çok bilgi mevcut. Geleneksel proje yönetimi metodları dışında Agile
Project Management with Scrum isimli kitabı öneririm. CMMI hakkında kaynakları bulup okuyun.
Software Engineering Institute'ün sitesinde CMMI hakkında okuyacak pek çok döküman mevcut. En
hoşuma gideni ürün geliştirenler için üretilmiş bu döküman. Okunacak çok fazla materyal olduğu için
okuma saatlerini planlamanızı öneririm. Böylece neyi ne zaman ve ne kadar süre ile okuyacağınızı
bilirsiniz.
Özel hayatınızdan hiç bahsetmedim ama psikolojik ve mental sağlığınız için gerekli bir unsur.
Ailenize, sevdiklerinize veya hobilerinize zaman ayırın. Tabii eskisi kadar zaman ayıramayabilirsiniz, bu
doğal. Ben hem Aikido hem Judo yapıyor, perşembeleri grubumla çalıyor, salıları da tırmanışa
gidiyordum. Bir gün çok fazla hobim olduğuna karar verdim, artık zaten eskisi gibi de zamanım
olmuyordu yapmaya ve Aikido ve Judoyu eledim, Salı tırmanışları kendiliğinden bitti, grubumda iki
haftada bir ancak toplanıyor. Böylece geleceğim ile ilgili işlere (ekmek parası kazandığımız işlere) daha
fazla zaman ayırabildim. Gitar çalmak ve Scuba Dalışı geriye kalan tek hobilerim.
Okunacak kitaplar Peopleware, Mythical Man Month, Team Software Process. İnsan ilişkilerini
anlatan psikoloji kitapları da işinize yarayabilir.
Kara defterinize ilişki kurduğunuz insanları ve özelliklerini not edin. Birileri ile tanıştırıldığınızda
kimin tarafından tanıştırıldığınızı not edin. Sizi en fazla birileri ile tanıştıran kişi “sosyal simsar” dır. Sosyal
simsarlar çevrenizi geliştirmek için çok işinize yarar. Sosyal simsarları iyi belirleyin ve ilişkilerinizi daima
sağlam tutun. Özel günlerde kart göndermek yada bir e-posta atmak ta çok zor değil. Bunun için adres
defterinizi sürekli güncel tutmanız gerekiyor. Ben Outlook kullanıyorum ve tüm kontaklarım burada
kayıtlı.
Çevrenizi geliştirmek için firma dışı seminerlere ve toplantılara katılın, notlar alın, ürün CDlerini
isteyin, firmalardan kontak kuracağınız kişilerin kartlarını almaya çalışın. Çalıştığınız firmadan kartvizit
isteyerek her gittiğiniz yerde dağıtın. Ne kadar fazla insanla tanışırsanız sizin için o kadar iyi çünkü firma
içinde yeteri kadar farklı psikolojide insana rastlayamazsınız. Firma dışı aktiviteler ile ilişkilerinizi
güçlendirin. Kendinize bir grup oluşturup bir mangal partisi, LAN partisi (oyun oynamak için), veya gezi
düzenleyebilirsiniz. İş dışında yapılan aktiviteler size farklı iş imkanları veya fırsatlar sunabilir.
Özgeçmişinizi mümkün olduğu kadar çok firmaya gönderin ve 3 ayda bir de yenisini göndermeyi
unutmayın.
Dış görünüşünüze önem verin. Takım elbise ve gravat ile kod yazmak zordur. Rahat edeceğiniz
ve firma içinde kabul edilebilir bir dış görünüşü benimseyin ve stilinizi oluşturun.
Firmanın yeni alacağı projeleri veya işleri takip edin ve yönetici seviyesinde küçük işler almak
için istekte bulunun. Aldığınız kursları ve planlama ile ilgili yaptığınız işlerdeki başarınızı referans gösterin.
İşleri size vermeseler bile istekli olduğunuzu göstermek için iyi bir fırsattır. Eğer yönetimin size olan
güveni belli bir seviyeye gelmiş ise eninde sonunda bu işleri almaya başlarsınız.
Toplam Kalite Yönetimi konusunda bir kaç kitap edinip okuyun. Ishikawa en iyi TQM
yazarlarından biri ve Japonya'nın kalkınma planlarının arkasındaki isim. Kitaplarından What Is Total
Quality Control? ve Guide to Quality Control tavsiye edeceklerim arasında. Yaptığınız işlerde kaliteyi nasıl
ölçebilir ve nasıl yükseltirsiniz araştırın. Ortaya çıkan sonuçları projede uygulayın ve yararlarını test edin.
Bu yöntemleri kara deftere not edin.
Değişiklik ve İstek yönetimi konularında da bilgilenmeye ve firma içinde bir sistem oluşturmaya
çalışın (eğer yoksa veya yeterli değilse). Kıdemli Yazılım Uzmanı olduğunuz için yapacağınız tavsiyelerin
dinlenme oranı yüksek olacaktır. Yapacağınız tavsiyeleri yazılı ve rakamlara dayalı olarak rapor halinde
verin. Örneğin doğru bir Değişiklik ve İstek yönetimi sistemi ile üretkenliğin %65 artacağını ve isteklerin
eskiye oranla %98 daha iyi yönetileceğini basit hesaplamalar ile gösterin. En sona bir maliyet/yarar
analizi koyun ve firmaya sağlayacağı yararlardan bahsedin. Maliyeti düşüren bir unsur varsa vurgulayarak
belirtin. Raporu aynı anda bir kaç üst düzey yöneticiye gönderin. Yöneticiler bu durumda iki şekilde
davranırlar. Eğer ilerlemeye açık ve alttan gelen tavsiyeleri değerlendirebilecek kadar kendileri ile
barışıksalar raporunuz iyi ellerde demektir. Fakat üstünüzdeki yönetici her şeyin en iyisini ben bilirim
tarzında burnu havada birisiyse farklı bir yöntem izlemek gerekir. Gönderdiğiniz rapora kızmış veya
hakarete uğramış gibi bile düşünebilirler. O zaman fikirler sanki onlarınmış gibi empoze edip sonuçlara
kendilerinin varmasını sağlamanız gerekir. Raporunuz kağıtta yazılı olmaz belki ve başkası sahiplenebilir
ama bu arada sizede bir yöneticilik görevi düşebilir. Hiç bir yöntem işe yaramıyorsa ayrılıp kendi firmanızı
kurun ve o fikirleri hayata geçirmeye bakın. İşte birdenbire CEO oldunuz :-).
Eğer sonu olmayan, vizyonu dar bir firmada olduğunuzu ve ilerleyemeyeceğinizi düşünüyorsanız
yeni bir iş arama zamanı gelmiş demektir. Kıdeminizin ve maaşınızın yükseleceği bir iş aramaya
başlamanızı tavsiye ederim. Kesinlikle aynı maaşa yada aynı kıdeme sahip başka bir işe geçmeyin. Eski
firmanızda kalıp bildiğiniz işe devam etmek sizin için daha iyi olacaktır. Ancak kıdem ve maaş daha
yüksek olduğunda atlama yapın. Zaman alabilir ama büyük düşünmeden hedeflere ulaşılmıyor değil mi?
Vizyonu dar olan firmaya vizyonunu genişletmek için yardımda da bulunabilirsiniz. Genelde ufak
firmalar büyümekten ve büyük projelere girmekten korkarlar. Çünkü yönetimi bir bela olacaktır. Bu tür
bir projeye girmeyi ve yönetici olarak bu işi yapabileceğinizi düşünüyorsanız, geniş kapsamlı bir rapor
hazırlayıp sunabilirsiniz. İlk başlarda diğerleri için ürkütücü olsa da zaman içinde firma tarafından da
benimsenecek fikirler ve projeler ile firmanın vizyonunu genişletebilir ve kendinize yöneticilik pozisyonu
imkanı yaratabilirsiniz.
Yönetici olabilmek için eğitim şart. Bunun için yukarıda bahsettiğim kursları muhakkak alın ve
işyerinde de uygulayın. İnsan ilişkilerini geliştirmek ve dinlemeyi öğrenmek, risk yönetimi ve stres
yönetimi konularında deneyim kazanmak çok önemlidir. Enterprise Risk Management isimli kitabı
tavsiye edebilirim. Baskı altında çalışmak ve stres yönetimi deneyimi, problemleri önceden görebilme
yeteneğinizi geliştirir. Personal Software Process ve Team Software Process kitaplarında anlatılan
araçları uygulamak planlama konusunda gelişmenizi sağlar.
Benim söyleyeceklerim bu kadar. Gerisi size ve yeteneklerinize kalmış. Biraz yüzeysel bir anlatım
oldu ama sanırım temel bazı bilgileri ve yolları göstermeye yeter. Kolay gelsin ve iyi seneler.
3.26 ISVler İçin 25 Kural
ISV de ne yahu diyenler için hemen açıklayayım Independent Software Vendor yani Bağımsız
Yazılım Firması. Genelde küçük fakat çok iyi bir fikir ile yola çıkarak ürüne dönüştürmeyi ve milyonlara
satmayı hedeflemiş bir kişi tarafından en az finansal destek ile kurulan firmalara ecnebilerin verdiği isim.
Leon Bambrick, Secret Geek isimli blogunda kendi ürünleri Time Snapper'ın fikir aşamasından
nasıl ürün aşamasına geldiğini ve bu yolda edindikleri deneyimleri ISV'ler için 25 kural altında açıklıyor.
Ayrıca Scott Hanselman podcast'inde de Leon'a söz veriyor . Leon ilerde bu kuralların açıklamalarını bir
kitap haline getireceğinden de bahsediyor fakat yeni doğan kızına daha fazla vakit ayıracak sanırım.
Benim çok hoşuma gitti bu listede yer alan kurallar ve Vezir'de yazdıklarımla örtüşüyor. Kuralları
ve kendi açıklamalarımı yazayım dedim. Belki birilerinin işine yarar.
1. Bir alan adı alın: Ben Google ve MSN Spaces bloglarımdan sonra alan adı alarak blog
hayatıma devam etmek istedim. Çünkü daha profesyonel ve kayda değer işlere imza atmak istiyordum.
Blogum belki bir ürün değil ama profesyonel düşüncenin bir ürünü. O zaman İngilizce aldım ismi çünkü
ilk başta sadece ingilizce blog yapmayı düşünmüştüm. Ürününüzün ismine uyacak bir alan adı alın.
Google'da bu kelimeleri satın alın ve aramalarda ilk sizin sitenizin çıkmasını sağlayın. Sadece ürün için bir
isim alın ve firma ismini düşünmeyin.
2. İyi bir hosting firması bulun: Kendi sunucularınızı evinizde barındırıyorsanız bir sürü
teknik işle de uğraşacaksınız demektir. Bu harcayacağınız zamanı bir hosting firmasından alacağınız
hizmet ile geri kazanabilirsiniz. Hem daha ucuza gelir hemde müşterileriniz için kaliteli bir hizmet
sağlamış olursunuz.
3. Kullanılabilir bir web sitesi tasarımlayın: Herhalde bu konu hakkında fazla yazmaya gerek
yok. Bir yazılım ürünü alırken önce firmanın sitesinden gerekli bilgileri almaya çalışırsınız. Mehmet
Doğan'ın Altı Üstü Tasarım adlı blogunda yazdığı ipuçlarına dikkat edin.
4. Temel web sitesi içeriği: Sitenizde olması gereken temel bölümler. Ürün hakkında kısa
bilgi, ürünün tüm özelliklerini anlatan yardım bölümü, ekran resimleri, sipariş bölümü, forum ve blog
kısmı vb gibi. Çok fazla karışık bir site yaparsanız müşteriler korkup kaçabilir. Mümkün olduğu kadar sade
yapmaya özen gösterin. Bir İçerik Yönetim Sistemi ile de gidebilirsiniz fakat statik sayfalar ile de gerekli
mesajı vermek ve sade olmak mümkün.
5. Sitenizin trafiğini kontrol edin: Site trafiğini Google Analytics ile ücretsiz kontrol
edebilirsiniz. Böylece siteyi ziyaret eden kişiler hakkında genel bilgi alabilirsiniz.
6. Sitenizde forumlar açın, geri bildirimleri destekleyin: Forumlar müşterilerin birbirlerine

yardım ettiği bir ortamdır. Fakat forumları başıboş bırakmayın ve 24 saat kontrol altında olmasını
sağlayın.
7. SSS listeleri düzenleyin: Sıkça Sorulan Sorular bölümünü güncel tutun ve forumlar ile
besleyin. Böylece belli sorular için hemen cevap bulabilirsiniz.
8. En iyi ekran resimlerini kullanın: Dış görünüş ilk başta müşterileri etkileyecek unsur
olduğu için alacağınız en iyi ekran resimlerini almaya çalışın. Örneğin Vista ile ekran resimlerini
güncelleyin.
9. Alan adı için e-posta düzenleyin: Alan adını aldıktan sonra e-postaları da düzenleyin.
Örneğin admin@alanadı.com, destek@alanadı.com, siparis@alanadı.com vb gibi akılda kalacak e-posta
adreslerini düzenleyin ve sıkça kontrol edin.
10. Online alışveriş hesabı alın: PayPal gibi bir sistem ile online alış veriş hesabı alın. Ürünün
satılmasını kolaylaştırmak ve dünya üzerinde herkesin almasını kolaylaştırmak için atacağınız en önemli
adımlardan bir tanesi.
11. Sitenizden ödeme yapılmasına izin verin: PayPal ödeme sistemini sitenize entegre ederek
sitenizden direk ürünün satılması için bir bölüm yapın.
12. Bir PAD (portable application description) dosyası hazırlayın: Bir XML dosyası ve ürün
hakkında bazı bilgileri tutar ve sitenizin root dizininde bulunması gerekiyor. Bu PAD dosyası indirme
siteleri tarafından kontrol edilir ve yeni sürümleri bu şekilde otomatik olarak dağıtabilirsiniz. PAD
dosyasını üretmek için http://www.padgen.org/ adresindeki aracı kullanabilirsiniz.
13. Genel indirme sitelerine kayıt olun: Ürününüz yeni sürüm çıkardığında otomatik olarak
indirme sitelerinde güncellenmesini sağlayın.
14. Ücretsiz ve profesyonel olarak iki ayrı sürüm çıkarın: Ürünün daha da fazla yayılması için
bir ücretsiz sürüm çıkarın ve profesyonel sürümden tamamen ayrı olarak yayınlayın.
15. Uygun bir son kullanıcı lisans anlaşması düzenleyin (iki tanede olabilir): Örütbağında
bulabileceğiniz pek çok örnek var. Ürününüz için uygun hale getirmek bir avukatın yardımı ile olabilir.
16. Otomatik güncelleme fonksiyonu sunun: Otomatik güncelleme en çok aranan

özelliklerden biridir. Yeni sürümler çıktığında progam otomatik olarak indirilmeli ve güncellenmelidir.
17. Lisans aktivasyonu için bir web servisi kurun: Bu web servisi her lisansın takibini
kolaylaştıracaktır. Yasadışı kullanımın da önüne bir miktar geçebilir.
18. Lisansların yönetileceği bir otomasyon sistemi yapın: Yukarıdaki web servisi ile bir
veritabanında tutulacak lisanslar size müşterileriniz ve kurulu çalışan ürünleriniz hakkında bilgi
toplayabilirsiniz.
19. İyi bir kurulum hazırlayın: Müşterilerin ürün ile ilk karşılaşmaları kurulum ile olmaktadır
ve iyi bir kurulum müşterinin ürün hakkında iyi izlenimlere sahip olmasına neden olur.
20. Assemblileri obfuscate edin: Ürünün kodunu obfuscate ederek Reflector gibi araçlardan
saklayabilirsiniz.
21. İnşa ve sürüm işlemlerini otomatize edin: Ünite testi, inşa, kurulum hazırlama gibi
işlemleri otomatize ederek zamandan kazanabilirsiniz. Cruise Control, Subversion, NUnit gibi ürünlerden
bahsetmeme gerek yok heralde.
22. Zaman ve kaynaklarınızı destek ve geri bildirimler ile ilgilenmek için ayarlayın: Destek
müşterilerin her zaman istediği bir şey ve geri bildirimler de ürününüze fikir olarak katkıda bulunabilir.
Kesinlikle zaman ve kaynak ayırılması gerekir.
23. Cafcaflı, kullanılabilir, yardımcı: Ürün arayüzlerinde kullanılan teknoloji kullanıcıyı

yormamalı, ürünün kullanılabilirliği müşteriye ürün özelliklerini bulup kullanmak açısından yardımcı bir
ürün olmalı.
24. Promasyon stratejinizi planlayın ve işleme koyun: Nasıl reklam vereceğinizi, ve ürünün
nasıl dağıtılacağını planlayın ve işleme koyun.
25. Hepsini tekrar yapın: Tüm bu işlemleri tekrar tekrar gözden geçirin ve bu süreçteki işleri
iyileştirmek için neler yapabilirsiniz kontrol edin ve uygulayın.
3.27 Sürüm Yönetimi
Bu yazımda Sürüm Yönetiminin büyük bir firmada yada devlet organizasyonunda nasıl
yönetileceğini ele alacağım. Sürüm yönetimi bir ürünün evrimsel gelişimi için muhakkak ele alınması ve
profesyonelce yönetilmesi gereken bir konudur. Ürünün ilk analizlerinden itibaren proje ile ilgili ürünler
ortaya çıkmaya başlar ve kod yazılmaya başladıktan sonra yönetim daha da karmaşık hale gelir. Konuyu
iki basamakta ele alacak olursak:
1. Üretilen belgelerin ve yazışmaların takibi
2. Ürünün geçirdiği evrelerin ve dallanmaların takibi

Olarak özetleyebiliriz. Ben üretilen ürünün sürüm yönetimi ile ilgili yazacağım. Büyük bir firmada
yada devlet organizasyonunda yazılan ürünlerin pek çok bağımlılığı vardır. Diğer iç birimlerin yazdığı
modüller, başka devlet organizasyonları ile olan bağlantılar, yabancı devletlerin sistemleri ile olan veri
alışverişi, özel sektör ile olan bağlantılar, üçüncü parti sistemler, kullanılan işletim sistemi ve
bağımlılıkları, donanım bağımlılıkları gibi pek çok sistemin ahenk içinde çalışacağı ve yeni sürüm
verdiğinizde bu bağımlılıkları kırmayacak şekilde sürüm vermeniz gerekir.
Öncelikle sürüm yönetimi konusunda bir birimin gerekliliği söz konusu. Bu birim Test birimleri
ile bağlantılı çalışır ve testlerde onaylanmış olan uygulamaları sahada kullanmak üzere kurmak için
gerekli işleri organize eder. Bu organize sırasında aşağıdaki birimlerden gerekli kişiler belirlenir:
1. Proje Yöneticisi (ürünü geliştiren ekibin proje lideri)
2. Teknik Lider (ürünü geliştiren ekibin teknik lideri)
3. İş Lideri (ürünü kullanacak ekibin lideri)
4. Saha Kurulum Müfettişi (Kurulumun doğru gerçekleştiğini onaylayacak ve ürünü kullanan

kişilerden seçilecek bir kişi. Eğer ürün coğrafik olarak farklı yerlere kurulacaksa her ofisden bir kişi.)
5. Kurulum Sorumlusu (ürünün kuracak olan kişi)
Hiyerarşik bir yapıda işlerin nasıl yürüdüğüne bakalım.
Adım 1. Teknik Lider olarak yapacağınız iş sürüm verme isteğinizi bir "Değişiklik İstek Formu"
düzenleyerek Sürüm Yönetimi ekibine bildirmektir. Sürüm Yönetimi isteğinizi inceleyip istenen tarihte
olup olamayacağına ve diğer etkilenen uygulamaların durumu ile etkilenme derecelerini araştırır.
Sonuçta bir değişiklik numarası verilir ve onaylanır. Bu aşamadan sonra Teknik Lider olarak test ekibinin
bulacağı hataları gidermek ve ürünü, kurulum tarihine kadar hazır etmek ile yükümlüsünüz. Ürünün son
halini paketleyip bir kurulum rehberi ile beraber kararlaştırılan bir ağ dizinine kopyalayacaksınız. Teknik
Lider ayrıca İş Liderini uyararak sürümün yapılacağı tarihi bildirir ve mesai yapacak çalışanların
bilgilendirilmesini sağlar. Sürümün verileceği hafta sonu, uygulama erişilemez olacaktır. Bu aşamadan
sonra artık Teknik Liderin işi bitmiş oluyor.
Adım 2. Sürüm zamanı yaklaştıkça sürümü yönetecek kişi (Sürüm Yönetimi ekibinden bir kişi)
hangi uygulamaların sürüm vereceğini belirler. Test ekibinin onayladığı ve sürüm zamanı belirlenen
uygulamalar listelenir. Test onay belgelerinde Proje Yöneticisi ve Teknik Lider hakkında bilgi vardır.
Ayrıca Değişiklik İsteği Formunda da bu bilgi mevcuttur. Bu bilgi uygulamanın karşısına yazılır. Bu işlem
için MS Project yada bir Excel dosyası kullanılabilir. Örnek olarak bu Excel belgesine bakabilirsiniz.
Sürüm Yöneticisi test onay belgelerini inceler ve testlerden geçememiş uygulamaları geri çevirir.
Değişiklik İstek Formlarını ilgili kişilere geri göndererek sürüm tarihini güncellemesini ister. Testlerden
geçen uygulamalar listede güncellenir.
Adım 3. Sürüm Yöneticisi yapılacak her işi adım adım belirleyebilmek için tüm yetkili kişilerin
katılacağı bir toplantı düzenler. Bu toplantıya sürüm verecek tüm uygulamaların sorumlu kişileri ile
etkilenecek fakat sürüm vermeyecek tüm uygulamaların sorumluları katılır. Sürümün hafta sonuna denk
gelmesi ve kimsenin sistemleri kullanmadığı bir anda yapılması önemlidir. Zaten sistemi kullanan
kullnıcılar önceden uyarılmıştır. Yapılacak işlerin listelendiği belgeye buradan bakabilirsiniz. Bu
toplantılar sürüm tarihi yaklaştıkça sık aralıkta tekrarlanır.
Adım 4. Sürüm yöneticisi görev listesindeki her görevin kimin yapacağını ve kontak telefonlarını
bir liste halinde yayınlar. Herkes bu listeye sahip olmalıdır ve sürüm günü bolca kullanılacaktır. Bizim
burada yaptığımız bir uygulama da bir telekonferans hattı organize etmektir. Herkes bu konferans hattını
arar ve 24 saat hatta kalır. Böylece olan olaylardan herkes haberdar olur. Eğer sürüm başka şehirlerdeki
ofisleri de etkiliyorsa bu tür bir haberleşme işleri çok daha kolaylaştırmaktadır.
Adım 5. Mesai yapacak olan kişiler belirlenir ve görev listesinden ne zaman ofiste olacaklarını
kontrol etmeleri istenir. Ayrıca mesai için izin alınması gerekiyorsa bu izinler önceden alınır. Bina girişi
için özel bir güvenlik durumu söz konusu ise güvenlik birimi bu olaydan haberdar edilir.
Adım 6. Sürüm Yöneticisi, Geriye Dönüş işlemlerini de organize eder. Eğer yeni sürümler sahaya
kurulduktan sonra testler sırasında bir hata çıkarsa sistem eski haline geri döndürülür. Kurulum Yönetimi
ekibi sürüm günü ortaya çıkacak hatalara hazırlıklı olmak için her ürünün mevcut sürümünü hazırda
bulundurur. Sürüm günü çıkan hatalardan dolayı kurulamayan yeni sürüm uygulamaların proje
müdürleri durumdan haberdar edilir. Saha Kurulum Testlerinde çıkan tüm hatalar ekran resimleri ile
beraber kaydedilir ve bir numara verilir. Eğer sürüm günü çözülemeyecek bir hata ile karşılaşılırsa o
sürüm iptal edilir ve eski sürüm kurularak sistemin devamlılığı sağlanır.
Tüm bu adımlar sürüm gününün sancısız geçmesi için tekrar tekrar gözden geçirilir ve mümkün
olduğunca görevler en ayrıntılı biçimde yazılır.
Sürüm günü uzun ve yorucu bir gün olacağından yiyecek ve içecek temini için önceden hazırlık
yapın.
Sürüm günü her işlem başarı ile sonuçlanırsa gelecek 2 hafta için uygulamalar göz altında
tutulur ve çıkacak hatalar gözden geçirilir.
3.28 Firmanızı Korumak
Emre Bey'in attığı bir yorum üzerine bu yazıyı yazıyorum. Emre Bey'in derdi günümüzde çok
yaygın olan veri ve ürün hırsızlığı ile ilgili. Yasaların yetersiz kaldığı yada uygulanmasının mümkün
olmadığı durumlarda (finansal yetersizliklerden dolayı) ürün ve kaynak kodunu korumak için neler
yapabilirsiniz? Yazılım firmanızı ve ürününüzü meraklı yazılım uzmanları ve hırsızlara karşı nasıl
koruyacaksınız? Finansal olarak zaten küçük bir işletmesiniz ve dava açıp avukat masrafları ile uğraşmak
ta istemiyorsunuz. Zaman ve nakit kaybını en aza indirerek ürününüzü ve firmanızın geleceğini korumak
istiyorsunuz.
Teknik açıdan ne yaparsanız yapın elbet bir delik bulunacaktır. Ya sosyal mühendislik yolu ile
yada sistemdeki bir açık yüzünden gözünüzün nuru ürününüz dışarıya sızacaktır. Gene de teknik açıdan
yapılabilecek pek çok şey var. Ne kadar çok kapıyı kapatırsak o kadar sızıntıyı önlemiş oluruz. Öte yandan
yazılımcıların esnekliğini kısıtlamış oluyorsunuz ve bir yazılımıc için pek iyi bir durum değil.
Yapılacak teknik kısıtlamalara bir bakalım. Uyarı: Bu yazılanları uygularsanız firmanızda Darth
Wader olarak adınız çıkabilir.
1- Tüm disket ve CD sürücüleri kaldırın
Firma içinde yazılım amaçlı kullanılan ve yazılımın bulunduğu ağ dizinlerine erişebilecek her
bilgisayarın disket ve CD sürücülerini kaldırın. Böylece bir kapıyı kapamış oluyoruz. Benim şu an çalıştığım
departmanda CD ve disket sürücüleri bilgisayarların üzerinde fakat işletim sisteminden hiç birine erişim
yok. BIOS seviyesinde kapatılmışlar.
Bazı bilgisayar kasaları vidaları sökülüp açıldığında sistem yöneticisine bildiri gönderecek şekilde
tasarım edilmiştir. Bu kasaları kullanırsanız bir miktar daha koruma sağlamış olursunuz.
2- USB portlarını kapatın
USB portlarına takılacak herhangi bir araç kodun dışarıya sızmasına neden olabilir. USB portları
muhakkak kapatılmalıdır. Ayrıca varsa infrared portaları da kapatılmalıdır.
3- BIOS şifrelenmeli
BIOS sistem yöneticisi tarafından bir şifre ile korunmalıdır. Böylece kimse BIOS üzerinden USB
portlarını açamaz yada IDE sürücülerini etkin hale getiremez. Kasaları açıp pilleri çıkartınca pek geçerli bir
koruma olmuyor ama haftalık kontroller ile denetlenebilir.
4- Tek bir sistem yöneticisi
Genel olarak bir yazılım evinde herkes sistem yöneticisi olarak tanımlanır ki herkes istediği her
yere ulaşabilsin. Fakat çok yanlış bir uygulama. Ben kendi bilgisayarlarımda bile sistem yöneticisi olarak iş
yapmıyorum. Biraz daha profesyonel olmak için bir domain kurun ve tek bir sistem yöneticisi atayarak
kullanıcıları yönetin. Verilecek hakları ve erişimleri sıkı denetleyin.
5- Security Policy ayarları
Windows üzerindeki Security Policy ayarları ile kullanıcıların uygulama kurma ve kaldırma
haklarını kapatın. Böylece bir şekilde ağınıza bir uygulama girse dahi kurulumu çok zor olacaktır. Domain
kurarak bu ayarları domain bazında yapın.
6- Hiç kimse lokal admin olmamalı
Eğer COM+ geliştiriyorsanız olabilir tabii ama hiç kimse kullandığı bilgisayarda lokal admin
olarak iş yapmamalı.
7- İnternet bağlantısı olmamalı
İnternet verimliliği düşüren en büyük etkenlerden biri bence. Ben kod yazarken ne Outlook
nede MSN Live Messenger açıktır. Zaten gerek te yok çünkü en son sürüm MSDN kurulu makinemde.
8- Domain kurun ve kullanıcıları iyi yönetin
Her kullanıcıyı admin olarak tanımlamaktansa bir domain kurup kullanıcılara verilecek hakları
belirleyin. İstisnalar olacaksa neden olacağını ve nasıl yönetileceğini de belirleyin.
9- Ağınıza bağlanacak makineleri takip edin
Linux için www.arpalert.org adresinde ArpAlert diye bir ürün mevcut. Bu ürün ile ağınıza bağlı
makinelerin MAC adreslerini bir veritabanında tutuyorsunuz ve kayıtlı olmayan bir makine bağlandığında
size haber veriyor. Günümüz MAC Spoof yöntemleri ile biraz geçersiz bir ürün oluyor ama hiç yoktan
iyidir. Kablosuz ağlar içinde iyi sayılabilecek bir yöntem.
10- Kod deponuzu koruyun

Kod deponuz, hangi ürün olursa olsun kesinlikle kilitli kapılar ardında olmalıdır. Ayrıca
kullanıcıların yaptığı işlemleri takip edip uygunsuz bir işlem gördüğünüzde soruşturma yapın. Örneğin bir
kullanıcı tüm kod deposunu indirmeye kalkarsa arkasında muhakkak bir çapan oğlu vardır. Her gün
sonunda bir yedek alıp güvenli bir şekilde saklayın. Yedeğin bir kopyasını firma dışında bir yerde hatta
farklı bir şehirde tutun.
11- Güvenilir kişiler ile çalışın
Bulması ve anlaması zor bir özellik. Kişilerin güvenilirliği çok değişken de olabilir. Haysiyetli ve
helal süt emmiş yazılım uzmanları ile çalışırsanız riskiniz daha da azalacaktır. Deneme yanılma yolu ile
bulacağınız bu kişiler firmanın kök ekibini oluşturabilir.
12- Log tutun ve logları inceleyin
Herkes log tutar ama bunları inceleyen çok azdır. Kilit işlemler yapılırken muhakkak log tutun ve
bunları gün sonunda inceleyin. Çeşitli otomatik uyarı mekanizmaları kurup yapılan bazı işlemlerden
anında haberdar olmaya bakın.
13- Dışarıya giden postaların kontrolü
Firmanızın sunucularından çıkacak her türlü e-posta incelenmeli ve onaylanmalıdır. Böylece bir
yazılım uzmanı kodları zipleyip e-posta ile göndermeye kalkarsa durdurulabilir.
Kodu çalmak isteyen yazılımcı kodu yazıcıdan basabilir ve bir şekilde kodu dışarıya çıkarabilir.
Teknik açıdan ne kadar kısıtlama getirirseniz getirin bir açık elbet olacaktır. Bu kadar çok kısıtlama yazılım
uzmanlarını da bunaltabilir. Hani bu kadar yazdım ama ben bu tür bir firmada çalışmak istemezdim. Eğer
firma sahibi beni hırsız olarak görüyorsa neden çalışayım ki... Sanırım teknik açıdan yapılacak şey çok
fazla ve takibi ve teftişi için nakit ve vakit harcamanız gerekecek.
Sonuç
Sadakat kişilerin karşılıklı güvenlerinin artması sonucu doğan bir unsurdur. Eğer siz firma sahibi
olarak çalışanlarınızın geleceğini garanti edebilirseniz çalışanlar da size sadık olacaktır. Yapacağınız
satışlar ile firmanıza sağlayacağınız gelir akışları ve akabinde bunun herkesin çabası ile olduğunu
anlatacak toplantılar veya kutlamalar yapabilirsiniz. Böylece çalışanlar kendilerini daha da fazla firmanın
bir parçası olarak görürler. Gelecek vaad etmeyen bir firmada hiç kimse durmak istemez.
Firma kültürünü ve sadakati misyon haline getirseniz dahi birileri mutlaka kodu çalmak için
yeltenecektir. Gizlilik anlaşması bu aşamada imdadımıza yetişebilir. Bu anlaşma kişilerin çalıştıkları ürün
hakkında dışarıda konuşmalarını ve herhangi bir şekilde kaynak kodunun dışarıya sızdırılması halinde
yasal işlemlerin uygulanacağını açık seçik belirten bir anlaşmadır. (bakınız Non-Disclosure Aggrement
yada Confidentiality Aggreement). En iyi çözüm bir gizlilik anlaşması imzalatmak ve güvenilir kişiler ile
çalışmak. Yapılan her işlem için log da tutabilirsiniz. Anlaşmayı imzalayan ve her işlem için log
tutulduğunu bilen yazılım uzmanları kodu çalmaya yeltenmeyecektir (en azından ben öyle umuyorum).
Bu iki anlaşma örneğini yakında blogumda vereceğim.
Bazı anlaşmalarda ayrılan kişilerin rakip firmalarda çalışmasını önleyecek maddeler bulunur.
Örneğin A firmasından ayrılıp aynı tür ürün geliştiren B firmasına geçip çalışmamız engellenmek
istenebilir. Bu hayatımda gördüğüm en rezil uygulama. Zaten yasal bir dayanağı da yok. Ben kendi
bildiğim işleri yapmak ve kariyerimde ilerlemek için tabii ki aynı işi yapan daha büyük bir firmaya
geçicem. Bu kaçınılmaz.
Karşılıklı güven ve sadakatin gelişmesi için sağlanacak ortamın yaratılması ve kişilerin özveri ile
çalıştığı bir firmada bu tür yaptırımlara gerek kalmaması lazım. Uygulanacak her türlü yaptırım, yazılım
uzmanlarının çalışma şartlarını bozar. Kodun kalitesini dahi düşürebilir. Kontrolün dozajını iyi ayarlayıp
çalışanları tiksindirmeden bu işi halletmek gerekiyor. Firmada çalışan herkes istisnasız bu anlaşmaları
imzalamadır. İstisna yapmaya başlarsanız diğer çalışanlar bu durumdan rahatsız olabilir.
Diğer bir yöntem yazılım ve şirket genel ağlarını birbirinden fiziksel olarak ayırmak. Hatta her bir
test seviyesi için birer ağ kurmak iyi olabilir. Örneğin benim çalıştığım departmanda Geliştirme,
Fonksiyon Testleri, Kullanıcı Kabul Testleri, Entegrasyon Testleri, Performans Testleri için birer ağ
mevcut. Bu ağlar birbirinin hemen hemen aynısı. Fakat domain olarak ayrılar. Aralarında fiziksel olarak
bağlantı var fakat firewall bunları denetliyor. Masraflı ama günümüzün Virtual PC imkanlarını düşünecek
olursanız aslında uygulaması o kadar da maliyetli değil. Benim çalıştığım yerde Performans testlerine
kadar olan tüm ağlar ve bilgisayarlar sanal. Yönetimi de çok kolay oluyor. Bir temel "image" hazırlayıp
her kurulumda bunu kullanabilirsiniz.
Kod çalınırsa yada kaçak olarak yerlerde satılmaya başlarsa yapacağınız en mantıklı hareket,
ürünün bir sonraki sürümünde ekleyeceğiniz özellikleri geliştirmektir. Öyle ki müşteriler yerlerde satılan
eski sürüm yerine yeni sürüm için aşersinler. Arayüzlerde yapılacak yenilikler veya sistemde temelden
yapılacak değişiklikler buna neden olabilir. Evet masraflı ama pazarda kalabilmenin ve hırsızlarla
mücadele etmenin başka bir yolu.
3.29 Yazılım ve Kişilik
Code Complete kitabından çok güzel bir bölümü ve benim yorumlarımı yazmak istedim.
 Kişisel karakteriniz yazılım üretmedeki kabiliyetinizi doğrudan etkiler.
Yazılımı üreten insanoğlu olduğuna göre kişisel karakterin yazılım üretme kabiliyetine doğrudan
yansıması kaçınılmazdır. Hayatını nasıl yaşadığın, çevrenle ilişkilerin, ahlaki seviyen, davranış biçimlerin
yaptığın işi doğrudan etkiler. Örneğin evinde dağınık yaşayan bir kişinin yazdığı kod da dağınık olacaktır
vb gibi.
 Bu karakterlerden yazılım alanında en işinize yarayacak olanlar ağırbaşlılık, merak,

entellektüel dürüstlük, yaratıcılık, disiplin ve entellektüel tembelliktir.
Ağırbaşlılık yaptığınız hataları kabullenme ve ders alma etkilenmesini yaratır. Yaptığı hatalardan
ders alan yazılım uzmanı bu hataları tekrar etmiyorsa yaptığı işin kalitesini yükseltmiş demektir. Ayrıca
dışarıdan gelecek yardımları da ağırbaşlılık ile kabul eden kişi gene deneyimini ve yaptığı işin kalitesini
yükseltecektir.
Entellektüel dürüstlük ise yaptığınız işte size gelen yardımlara hakettikleri saygıyı göstermek,
sizinle beraber çalışanlara her zaman saygılı davranmak demektir. Örneğin Ahmet’in size yardım olması
için yazdığı bir fonksiyonun tepesine kendi isminizi yazmanız ayıptır. Ya da blogumdan dümdüz
kopyaladığınız bir yazıyı isim yada link vermeksizin forum sitenizde yayınlamanız ahlaksızlıktır. Yapılan
işin kredisini kimin hakkıysa verin, dünyanın sonu gelmez merak etmeyin. Yada birileri çıkıp ta bunu da
buradan kopyalamışsın dediğinde yerin dibine girip rezil olmak daha iyi gelebilir veya hiç
yakalanmayabilirsiniz de. Hiç yakalanmayacağınızı düşünüyorsanız sizi Allaha havale ediyoruz, yok
yakalansam bile banane diyorsanız size ar damarı nakli öneriyoruz.
Entellektüel tembellik, tembellik yaptığınız anlarda bile bir problemi düşünmek ve farklı
çözümler aramaktır. Yada yaratıcılığınızı kullanarak üreteceğiniz bir iş fikrine çeşitli kullanım alanları
bulmaktır. Dışarıdan tembellik yapıyor gibi görünürsünüz fakat beyniniz tam gücüyle çalışıyordur.
 Süper yazılımcı olmanın Allah vergisi bir yetenek ile ilgisi yoktur. Aksine kendini adamak ve
kişisel gelişme ile ilgisi vardır.
Yazılım ve bilgisayar dünyasının her geçen yıl biraz daha ilerlediğini ve yeni teknolojilerin ve
tekniklerin mantar gibi türediğini düşünürsek, kendimizi geliştirmek için harcayacağımız zamanın
değerini sanırım daha iyi anlayacağız. Düşünün ki iyi bir bilgisayar için yatırım yapıyoruz ama kendimizi
geliştirmek adına bir yatırımda bulunmuyoruz. Kimin belli bir kurs planı var? Önümüzdeki yıl için eğitim
planlarınızı belirlediniz mi? Hangi kitapları alacağınızın veya hangi yeni teknolojileri öğrenmek için
çalışacağınızın planını yaptınız mı? Yoksa önünüze ne pilav koyarlarsa yemek için elde kaşık bekliyor
musunuz?
 İşlenmemiş zeka, deneyim, sağlam karakter ve altıncı his yarar sağladığı kadar zarar da
verebilir.
Eğer at gözlükleri ile doğru bildiğiniz şeylere bağlıysanız ve değiştirmek için gelen yorumları
kulak arkası ediyorsanız bu artık sizin yeni teknolojileri öğrenme ateşinizi söndüğüne işarettir. Yada
bulunduğunuz ortamın monotonloğu ve kemikleşmiş işleme modeli sizi de etkilemiş demektir. Bu
kabuğun dışına çıkmak ve yeni bilgi ve teknikler için arayışa girmek için vakit kaybetmeyin.
Sezgileriniz ile hareket ederken unutmayın ki bir mayın tarlasında yürüyorsunuz. Sezgilerinizi
hemen ilan etmeden evvel, önce bir kodunu yazın sonra ünite testini de yazın ve size kazık atmayacak bir
arkadaşınıza gösterin ve test ettirin. Test edilmiş ve onaylanmış bir düşünce artık bir ürün haline
gelmiştir ve kullanıma hazırdır. Atalarımızın söylediği gibi bazı düşüncelerin pişmesi için üstüne bir gece
uyumak gereklidir.
Çok sağlam karakteriniz esnekliğe izin vermiyorsa sizin için tehlikeli olabilir. Yıllarca o sağlam
karakterdeki doğru zannettiğiniz davranış biçimleri yanlış olabilir yada zaman içerisinde geçerliliğini
kaybetmiş olabilir. Değişime açık olmak her zaman iyidir.
Zeki olabilirsiniz fakat yöntem bilmiyorsanız aklınıza gelen fikirleri hayata geçirmek zor olabilir.
İşlenmemiş zekanın işleneceği yegane yer eğitim kurumudur. (evrenkent, kurs, hayat, çevre, aile,
kitaplar, kaldırım fakültesi vs.) Bilgiye açık ve aç olmak yeterlidir. Öğrenilen yöntemlerin nasıl
kullanılacağı ve teorinin pratiğe nasıl uygulanacağı düşünmeniz gereken tek şeydir. Yani öğrenirken şu
yaklaşımı ele alın “ben bunu nasıl hayatımda/işimde/ailemde kullanırım ki bana faydası olsun”. Bunun
bir sonraki aşaması ise “bu yöntemi çok güzel kullandım, acaba daha iyi ve verimli hale gelmesi için bir
şeyler yapabilir miyim?” sorusunun sorulması ve akabinde süreç iyileştirmeye gidilmesidir.
 Pek çok yazılımcı kendini geliştirmek için aktif olarak yeni bir bilgi yada teknik arayışı içine
girmez. Bunun yerine yaptıkları iş içerisinde tesadüfen buldukları yeni bilgilerle yetinirler. Eğer
zamanınızın küçük bir bölümünü yeni kitaplar veya teknikleri anlatan yayınları okumaya adarsanız bir kaç
ay yada yılda kendinizi sürüden rahatça ayırt edebilirsiniz.
Kendini yazılım uzmanı sanan pek çok kişi var ve senin bunlardan farkını ayırt etmek güç mü
oluyor? Hem işveren hemde kendin için bu ayrımı yapmak güç oluyorsa artık bunun için bir şeyler
yapmanın vakti geldi demektir. Her gün belli bir kısım zamanı yeni bilgi ve teknolojileri öğrenmek için
harcamalısın. Bir günlük tutup bu öğrendiklerinin ve öğrenmek istediklerinin bir seceresini tut. Ayrıca
planlı olması açısından 3 aylık yada 6 aylık planlar yap ve ne öğreneceğini planla. Yılda en az iki kez bir
kursa katıl. Yada bir üniversite ile anlaşıp yılda bir ders al konunla alakalı. Çok geçmeden göreceksin ki
sürüden ayrılmış ve daha yeşil otluklar için yelken açmışsın.
 İyi karakter sahibi olmak doğru alışkanlıkları seçmekten geçer. Alanında mükemmel bir
yazılım uzmanı olmak istiyorsan doğru alışkanlıkları seç gerisi zaten gelecektir.
Yazılım sektöründe kullanılan ve yazılı olmayan standartlar vardır. Bu standartları bulup

çıkarmak ve kendi işinde kullanmak yaptığın işin kalitesini yükseltir. Kalite yükseldikçe sana maaş artışı
yada mevki yükselmesi olarak geri döner (dönmüyorsa firma değiştirmek şarttır). Kendi uyguladığın bu
yöntemlerde süreç iyileştirmesine gidip zamanın gerekliliklerine göre değişimler yapmak daha da
ilerlemeye neden olur. Yaşam tarzın ve hayat standardın yükselmeye devam eder. Yeni öğrendiğin
teknikleri de bir şekilde iş hayatında kullanıp verim alabiliyorsan ne mutlu sana.
Code Complete kitabını her okuduğumda aklımda yeni fikirler beliriyor yada bir problemime
çözüm buluyorum. Bu kitabı her kese tavsiye ederim.
3.30 Yazılım Sürecinde Kalite
Yazılım mühendisliğinin yegane amacı yüksek kalitede bir uygulama üretmek olagelmiştir. Bunu
başarabilmek için test edilip onaylanmış bir metod, yüksek kaliteli uygulama geliştirme araçları ile
birleştirilerek yazılım süreçlerinde kullanılmalıdır. Günümüzde yazılım araçlarının çok ilerlediği bir gerçek;
demek kaliteyi yakalamak için metodu doğru ve yerinde kullanmamız gerekiyor. Ayrıca metoda ne kadar
sadık kalındığı ve tam olarak kullanılıp kullanılmadığı da bir etken olarak karşımıza çıkıyor.
Soru 1: Çalıştığınız yerde hangi metodun kullanıldığını biliyor musunuz?
Projelerin bir harala gürele ile başladığı ve Allah ne verdiyse kod yazmaya girişildiği bir yerde mi
çalışıyorsunuz? Yoksa belli bir düzende müşteri gereksinimlerine bağlı kalınarak, dökümantasyon ve
sürüm yönetiminin kullanıldığı bir ortamınız mı var? Çalıştığınız yerdeki yazılım geliştirme metodunu iyice
öğrenip, işlerin nasıl dağıtıldığını, nasıl test yapıldığını, kod yazarken nelere dikkat edildiğini öğrenin. Belli
bir düzen yok mu? O zaman siz bir düzen getirin. Metodun gerekliliklerini öğrenip uygulayın. Bu
durumda hataların en çok hangi aşamada oluştuğunu bililmsel olarak ortaya koyabilirsiniz.
İstenen kalitenin elde edildiğini anlamak için proje boyunca oluşan hatalara göz atılabilir.
Örneğin Use Case (Senaryo) kullanarak analiz yapıyorsunuz diyelim. Senaryolar bir kez onaylandıktan
sonra gerekecek her türlü değişiklik bir hata demektir. Yada Yazılım Gereksinimleri Tanımlama
belgesinde onaydan sonra oluşacak her değişiklik te hata statüsüne girer. Testler sırasında kodda
yakalanan hatalar da bu durumdadır. Hata projenin her aşamasında ortaya çıkar; sadece kod üzerine
odaklanmayın.
Her senaryo başına kaç hata düştüğünü, testler sırasında 1 saatte ne kadar hata yakalandığını
ölçüp projenin kalitesi hakkında bir fikre sahip olabilirsiniz. Ayrıca Hata Düzeltme Hızı (HDH) her senaryo
için ölçüldüğünde senaryoların boyutları ve içerdikleri zorluk seviyesi ortaya çıkartılabilir. Eğer bir
senaryo için HDH zamanı uzunsa, kompleks bir senaryo ile uğraşıyoruz demektir (yada çok basit olduğu
için analizcilere angarya gibi gelen bir iştir). Proje planında bu senaryo ve bağlı olduğu fonksiyonlar için
daha fazla zaman ayırmanız yada senaryoyu düzeltmesi için analizcileri dürtmek gerekir. Projelerin
kompleks kısımlarını anlamak için maliyet analizi de yapabilirsiniz. Modül yada senaryo başına maliyet
analizi en fazla kullanılan tekniktir.
Proje maliyetlerinin çoğu son iki aşamada ortaya çıkar. Bunlar
1. Ürün müşteride kullanılmaya başlamasından sonra destek aşamasında ve
2. Ürünün farklı müşterilere ve sistemlere uydurulmaya çalışılması sırasında
Bu aşamalarda ortaya çıkacak hatalar da düzeltilmesi en maliyetli ve zor hatalardandır. Zaten

kompleks ve zorlu olan bu iki aşama, ortaya çıkan hatalar ve uzun süren HDH zamanları ile içinden
çıkılmaz bir hal alır. Bu sebepten dolayı zaten çoğu proje yöneticisi bu iki aşamayı proje planlarına dahil
bile etmezler. Böylece kaliteyi yükseltmiş gibi gözükürler ama aslında projenin en önemli kısmını es
geçmişlerdir.
Soru 2: Ürünün doğruluğu hakkında ne biliyorsunuz?
Bir program doğru olarak çalışmalıdır. Peki doğruluğunu nasıl anlayacağız. Şöyle; müşteri
gereksinimlerine göre doğru çalışıyor mu test ederek (basit değil mi? Tabii müşteri ne istediğini
biliyorsa). Bu testler sırasında ortaya çıkan toplam hata rakamı diyelim ki 3000 olsun. Proje başından beri
yazılan kodun da 150,000 satır olduğunu düşünelim. Bu durumda 150,000*X=3000*1000 formülünden
her 1000 satır için 20 hata olduğu ortaya çıkar. Tabii bu hataların hepsi ürün müşteri tarafında
kullanılmaya başladıktan sonra müşteri tarafından girilen hatalardır. Kalite ölçümü için bellli bir zaman
sürecinde bu hatalar toplanır, örneğin 1 sene gibi. Ürün müşteride kullanılmaya başladıktan sonra her
1000 satır için hata seviyesinin %1,5 ile %2 arasında olması gerekir ki ürünü kaliteli bir ürün olarak
farzedebilelim. Eğer hata sayısı üst limitlerde geziyorsa ki örneğimizde öyle, hata sayısını alt limitlere
çekmek için çalışma yapılmalıdır.
Ayrıca modül başına düşen hata sayısı ve modüllerin boyutu göz önüne alınarak, kompleks
fonksiyonlara daha fazla zaman ayrılmasının sağlanması gerekir.
Soru 3: Ürünün ilk sürümünden sonra gelen istekleri ve hataları ne kadar zamanda
düzeltiyorsunuz?
Ürün müşteriye sunulur ama proje bununla bitmez. Bir destek ekibi 7/24 problem çözmek için
didinir durur. Bu aşamada oluşan hata, istek ve entegrasyon problemlerine cevap verme hızı ürünün
kalitesini belirler. Madde halinde sıralarsak:
14. Ürün müşteriye sunulduktan sonra çıkan hataların düzeltme hızı
15. İstenen değişikliklerin analizi, uygulanması, testi ve müşteriye sunulması sırasında geçen
zaman ve
16. Ürünün farklı sistemlere entegre edilmesi veya değişen ana sistemle birlikte ürünün de
buna ayak uydurması için yapılacak değişikliklerin uygulanma hızı.
Genel bir ölçüm birimi olmasa da bu zamanların ölçülüp grafik haline getirilmesi ileride çıkacak
hata, istek ve entegrasyon istekleri için tahmin edilecek zamanların daha gerçekçi olmasını sağlayacaktır.
Projenin boyutuna ve yoğunluğuna, müşteri sayısına ve hizmet veren programcı, testçi, analizci vb gibi
proje sahiplerine bağlı olarak her proje için farklı bir gösterge ortaya çıkması doğaldır.
Soru 4: Ürün ne kadar güvenli?
Ürünün korsan saldırılarına karşı ne kadar güvenli olduğu da bir kalite göstergesidir. Korsan
saldırıları direk programa, veritabanına veya belgelere yapılabilir. Bu üç öğenin kendini koruyabilmesi ve
saldırılardan yara almadan kurtulması ürünün gevenliliğini gösterir. Kod ve Rol seviyesinde güvenlik
mekanizmalarının kurulması, şifreli bilgi alışverişi için ortamın ayarlanması, sistemlere ulaşan kişilerin
izlenmesi ve kayıt edilmesi gerekir. Ürünün çalıştığı sistem yöneticiler tarafından göz altında tutulmalı ve
şüpheli durumlarda otomatik uyarıcı modüller eklenmelidir. Örneğin her isteyen cumhurbaşkanının vergi
kayıtlarını görmemelidir.
Güvenlik tam olarak ölçülecek bir birim değildir ama günde 10 kere saldırıya uğrayan bir
sistemin her seferinde yara almadan kurtulduğunu bilmek müşteri için rahatlatıcı bir unsurdur.
Soru 5: Ürünün kullanılabilirliği hakkında ne biliyorsunuz?
Her yeni yazılım ürünü yada eklenen özellik beraberinde belli bir öğrenme süreci getirir. Bu
öğrenme sürecinin uzunluğu:
1. Kullanıcının entellektüel bilgi seviyesine
2. Ürün ile yararlı bir şeyler yapacak seviyeye gelmek için geçen zamana
3. Yararlı bir şeyler yapacak seviyeye gelmekten tam üretken olacak zamana kadar geçen
süreye bağlıdır.
Kullanılabilirlik tamamı ile müşteriden müşteriye değişecek bir etkendir. Fakat ürünün arayüz
tasarımı, komutlara karşı verdiği cevaplar, tahmin edilebilirliği, hata durumlarında verdiği yanıtlar ve bir
çökme durumunda üzerinde çalıştığı veriyi bozmadan bir önceki haline geri dönebilmesi kullanılabilirliği
arttıran unsurlardır.
Müşteri genelde ürünü hataları ile beraber öğrenir ve bu hatalara karşı defans geliştirir. Yani
program müşteriyi yönetmiş olur fakat verinin bütünlüğü veya sistemin güvenliği tehlike altına girer. Bu
tür durumlara yer vermemek amacı ile kullanılabilirlik testlerinin bağımsız kişiler tarafından yapılması
gerekir.
Yazılım süreçlerinde bu metriklerin yerleştirilmesi ve kullanılması oldukça güç bir iştir. Hele ki
firmada geçmişte herhangi bir metrik tutulmadıysa daha da zor olacaktır. Fakat şunu düşününki eğer
ölçüm yapmazsak ilerlediğimizi anlayamayız. Ben örneğin her body building salonuna gidişimde bir
defter ve bir kalem bulunduruyorum ve kaldırdığım ağırlığı not ediyorum. Örneğin 1 aylık Türkiye
tatilinden sonra eski performansıma kavuşmam bir ay gibi bir zaman aldı. Ağırlıkları yazmasaydım bunu
bilemeyecektim. Öte yandan limitlerini bilmek ve biraz daha sınırları zorlamak için de tuttuğum kayıtları
kullanıyorum. Örneğin uzunca bir süre aynı kiloda biceps yapıyorsam bir daha ki antrenmanda 1 kilo
arttırıyorum ve aldığım tepkilere dikkat ediyorum.
Proje zaman çizelgelerinde bu şekilde kompres yoluna gidilebilir ama mutlaka bir önceki metrik
ölçümler göz önünde bulundurulmalıdır. Yoksa yapılan kompres anlamsız olacaktır. 5 gün sürecek bir işi
2 günde bitirebilmek için yapılan kompres eğer metod olarak önceki metriklere dayanmıyorsa pek bir
anlam ifade etmez.
Sonuç
Bir firma içinde yazılım süreci boyunca her proje için belli metriklerin tutulması gerekir. Bu kayıt
tutma alışkanlığı ileride alınacak projelere ve zaman çizelgeleri için tahmin edilecek sürelere bir ışık tutar.
Proje bazında kaliteyi ölçmek için belli rakamlar almamızı sağlar. Bu metrikler sayesinde elle tutulur bir
kalite anlayışına sahip oluruz ve daha da arttırmak için neler yapmamız gerektiğini daha açık görebiliriz.
Yoksa yazılım sürecimiz bir kör dövüşüne döner ki piyasada uzun süre kalmayı düşünen bir firma için
hiçte iyi bir şey değil. Uzun süreden kastım öyle 15 yada 20 yıl değil. 100 yada 150 sene ortamın
değişikliklerine ayak uydurabilmiş ve ürünü ile sürekli devinim içinde gelişmiş ve kaliteyi de ön planda
tutmuş bir firmadan bahsediyorum.
3.31 Yazılım Uzmanı Olamayacağınızın 10 Kanıtı
Tech Republic’de yazan Justin James 10 maddede neden yazılım uzmanı olamayacağınızı
açıklamış. Bakalım neymiş bu 10 madde.
1: Kendi kendine öğrenmek yerine kursları tercih ediyorsunuz
Yazılım Uzmanı ilk işe başladığında gerekli tüm bilgiyi biliyor olduğu varsayılır. Firmanın belirli bir
eğitim politikası olsa bile gerçekte firmanın yardımı ile alacağınız eğitimler hiç bir zaman gerçekleşmez.
En iyi ihitimalle bir iki kitap almanız için bir ödenek ayrılır. Yönetim ekibinin düşüncesine göre yazılım
uzmanı problem çözmeyi bilen akıllı bir kişidir ve bu yüzden de eğitime ihtiyacı yoktur. Öte yandan kurs
masrafları karşılanan yazılım uzmanının her zaman firmayı terkedip gitme ihtimali olduğu için firmanın
yatırım yapması pek düşünülemez (olsa iyi olurdu tabii ama gerçek hayat bu). Bu durumlar göz önüne
alındığında kendi kendinize öğrenebiliyor olmanız gerekir. Eğer bu disiplin sizde yoksa yazılım uzmanı
olmayı aklınızdan bile geçirmeyin.
2: Normal çalışma saatlerini seviyorsunuz
Yazılım projelerinin geç bitme olayını herkes bilir. Zamanında biten projeler bile projenin hayatı
boyunca çoğu kereler geç kalma durumuna düşmüştür. Eğer 9’dan 5’e bir işte çalışmayı seviyor ve
yazılım projelerinin uzun çalışma saatlerine ve gecelemelerine dayanamayacağınızı düşünüyorsanız
yazılım uzmanı olmayı aklınızdan çıkarın. Patronunuz, ürünün zamanında müşteriye ulaştırılmasını, sizin
oğlunuzun spor müsabakasından yada televizyonda seyretmek istediğiniz programdan daha önemli
tutacaktır.
3: Küçük maaş artışlarını kıdem yükselmesine tercih ediyorsunuz
Teknolojik değişmeleri uygulamayan bir firmada çalışmıyorsanız, şimdi bildiğiniz şeyler seneye
ya geçersiz yada az ödeyen konuma gelecektir. Bugün gözde olan teknolojiler seneye isimleri bile
hatırlanmayan garip teknolojiler olabilir. İşin sırrı hızlı biçimde değişmektir. Yeni teknolojileri hızlı
(herkesden önce) öğrenip konu hakkında otorite olmaya bakın. Hiç yeni bir teknoloji öğrenmeden aynı
koltukta oturup, maaşınıza gelecek zammın hayat standardınıza yeteceğini düşünüyorsanız
yanılıyorsunuz. Ya deneyimlerinizi ilerletip aynı firmada kıdem yükseltmeli yada başka bir firmaya
geçerek aldığınız maaşı yükseltmelisiniz.
4: Ekip çalışmasında insan ilişkileriniz pek iyi değil
Yazılım uzmanları her ne kadar a-sosyal insanlar olarak bilinsede bir araya geldiklerinde
hararetli konuşmalar yaparlar ve kendileri gibi olan insanlarla hemen kaynaşıp sosyalleşirler. Hangi
dükkanda indirim var veya dün akşamki diziden bahsetmedikleri için dışarıdan kulak misafiri olanlara
Fransızca gibi gelir ama aslında çok sosyal insanlardır. Ekip içinde çalışamıyor ve iletişimin düşük
olduğunu düşünüyorsanız yada ekip arkadaşları ile bağlantı kuramıyorsanız; problem genellikle sizdedir.
Aynı deneyimleri yaşamamış kişilerin bağlantı kurmaları beklenemez.
5: Kolayca sinirleniyorsunuz
Yazılım dünyası pek çok engellerle doludur. Belgeler genelde tam değildir, sizden önceki
yazılımcı okunmaz bir kod yazmıştır, proje müdürünün anlaşılmaz kuralları vardır, herkesin uyması
beklenen... liste daha da uzatılabilir. Sonuç olarak kimse sürekli bela okuyan ve ekrana küfür eden birisi
ile aynı çatı altında olmak istemez. Eğer 8 saatlik bir uğraşın sonunda konuyu 10 dakikada
çözebileceğinizi görüp deliriyorsanız bu kariyer sizin için değildir.
6: Ekip elemanlarının fikirlerine kapalı iseniz
Yazılım geliştirmede genelde problemlerin birden fazla çözümü vardır her yiğidin bir yoğurt
yiyişi olduğu gibi. Eğer gelen kritikleri ve diğer çözümleri göz ardı ediyorsanız önemli bir noktayı gözden
kaçırıyor olabilirsiniz. Sektörde yani olan ve deneyimleri sizden az olan birinin yapacağı bir tavsiye size
pek çok şey kazandırabilir. Tabii bu tavsiyeye önem verip uygularsanız.
7: Detay adamı değilsiniz
Programlama olayı komplex bir olaydır ve dikkat ister. Eğer Conan The Barbarian filminden daha
karmaşık bir filmi izlerken kayboluyorsanız yada bir yeni nesil ev kredisi formunu doldururken
zorlanıyorsanız yazılım uzmanlığı büyük ihtimalle sizin için değildir. Bazen unutulan bir virgül, başarı ile
başarısızlık arasındaki çizgiyi çizer. Eğer bu virgülü arayıp bulacak yapıya ve sinir esnekliğine sahip
değilseniz kariyeriniz belli limitler içinde yer alır.
8: Yaptığınız işten onur duymuyorsunuz
Kitaba göre yazılım üretmek ve orta derece ile geçecek bir iş çıkartmak mümkündür. Problem,
kitapların sürekli güncelleniyor olmasıdır. Yazılım geliştirmek bir fabrika işi değildir. Fabrikada işler belirli
bir prosedüre göre gider ve beyin seviyeniz ne olursa olsun prosedürü uyguladıktan sonra iş ortaya çıkar.
Yazılım geliştirme daha çok bilimsel bir iştir ve bağımsız düşünce gerektirir ki bu da yaptığınız işten gurur
duymanızı sağlar. Bir işi yanlış yoldan yapıp üretime geçildiğinde ancak yeteri kadar çalışmasını
sağlayabilirsiniz fakat göz ardı ettiğiniz o hata problem açmıyor gibi görünsede ileride problem açacaktır.
Yazılımcı olarak yaptığınız işin gurur duyulacak bir iş olduğunu düşünmüyorsanız ürettiğiniz ürünün
kalitesi düşük olacaktır ve kariyerinizin sürekliliği ile doğru orantılı olacaktır. Siz ayrıldıktan sonra
arkanızdan konuşulmasını istemiyorsanız (gerçi ağzınla kuş tutsan arkandan konuşacaklardır) haysiyet ve
onurunuzu korumak için yaptığınız işin tam olmasına dikkat edin. En azından sizin içiniz rahat olur.
9: Önce ateş edip sonra soru soran tiplerden misiniz?
Yazılım uzmanı bir parça kod yazmadan önce bir planlama aşaması geçirir ve kod yazmaktan
daha fazla zaman planlamaya ayrılır. Eğer kod yazma aracınızı açıp Allah ne verdiyse kod yazmaya
başlıyorsanız %100 ihtimalle iki ay sonra yazdığınız kod tamamı ile değişecektir. Konu hakkında düşünen,
planlayan yazılım uzmanı ise daha az hata ile daha kısa sürede kod yazacaktır. Çoğu programcıların
neden 10 parmak yazamadığının nedeni de budur; işin zor kısmı ne yazacağını bilmektir. Eğer düşünen
bir insan değilseniz yazılım uzmanlığı sizin için bir kariyer değildir.
10: “Geek” tipini sevmiyorsunuz
Haklı kimi nedenlerden dolayı, mühendis veya teknik kişilerin yakınında olmaktan hoşlanmıyor
olabilirsiniz. Eğer Dilbert gibi bir kişilikten çekiniyorsanız yazılım uzmanlığını düşünmeyin bile. Tabii ki her
yazılım uzmanı böyle değil ama sektörün büyük bir çoğunluğunu oluşturuyor ve aralarında haliniz yaman
olur.
Çalışma hayatım boyunca çok rastladığım bir insan tipi “bir iş fazla para ödüyor” diye o işe
girenler. Daha önce ahçı olan ve iki yazılım kursundan sonra yazılım uzmanı kesilen ve sektörde para
kazanan pek çok kişi tanıyorum. Yaptıkları işlerin kalitesi ise yerlerde sürünüyor. Bir kaçının proje
ortasında işine son verildiğine de şahit oldum. Tamam yazılım sektörü çok ballı bir sektör ama
üzüldüğüm bir konu varsa o da bu kişilerin ürettiği ürünlerin bizim tarafımızdan ileride tamir edilecek
olması. İlla yazılım uzmanı olmaya da gerek yok bence. Yazılım sektörünün daha bir çok dalı var ki bu
dallarda hakikaten adama ihtiyaç var. Örneğin, yazılım tasarımcısı, iş analisti, sistem destek uzmanı, veri
tabanı uzmanlığı, donanım uzmanlığı, test uzmanı vs. liste daha da uzatılabilir. Bu dallarda ki açıklar
genelde yazılım uzmanı tarafından kapatılmaya çalışılıyor yada firmalar yazılım uzmanlarından bunu
bekliyorlar. Yanlış bir uygulama ve tasarımın ve analizin kalitesini düşürüyor.
Siz ne düşünüyorsunuz? Bu liste daha da uzatılabilir mi? Yazılım uzmanı olmanın başka
gereklilikleri var mı? Yorumlarınızı bekliyorum.
3.32 Stres ve Yazılım Sektörü
Türkiye yazılım sektöründe göz ardı ettiğimiz çok önemli bir proplem var. Stres. Kaliteyi,
üretkenliği, devamlılığı ve ikili lişkileri sekteye uğratan bir unsur. Stres beraberinde depresyon ve moral
bozukluğu getiriyor ki buda üzerinde çalışılan işlere doğrudan negatif olarak yansıyor. Ben stres olayını
yazılım sektörü bazında ele alıyorum ama hangi sektörü ele alırsanız alın stresin zararları her zaman
yukarıda söylediğim gibi olacaktır.
Yazılım sektöründe stresin pek çok nedeni var. Proje teslimat zamanları, müşterilerin bastırması,
proje müdürünün gerçeğe dayanmayan istekleri, çalışma ortamının yetersizliği, liderlerin bilinçsiz
davranışları, konu hakkındaki bilgisizlik ve beraberindeki korku hemen aklımıza gelen bir kaç tanesi.
Stres faktörünü algılamak burada proje müdürüne düşüyor çünkü proje ekibini dışarıdan gören
ve objektif olarak değerlendirebicek tek kişi konumunda. Eğer gerçekten ikili ilişkilerde iyi ve insan
psikolojisini algılayabilecek seviyede ve deneyimdeyseniz, projenizde iş dışında nelerin olup bittiğini, ne
tür dış etkenlerin projeyi etkilediğini, performansın ne zaman çıkıp ne zaman alçaldığını görebilirsiniz.
Proje yönetimi sadece MS Project'i çok iyi bilmekle olmuyor yani. Bir lider olduğunuzu, arkanızda sizi
takip edecek bir ekip olduğunu, bu ekibin başarısının sizin başarınıza yansıyacağını, ekibin sürekliliğinin
sizin elinizde olduğunu, alacağınız kararların ekibi etkileyeceğini sürekli hafızanızda tutmanız gerekir.
Ekibin psikolojisi de sizin projeyi nasıl yönettiğinize bağlı olarak değişir. Proje liderinin psikolog olmasına
yada Tibet'te bir manastırda eğitim görmesine de lüzum yok. Çalıştığınız insanların ruhsal durumunu
anlayacak kadar veriyi algılamaya hazır olmak ve bu veriyi analiz edecek kadar ikili ilişkilere önem
vermek yetecektir.
Sektöre yeni girmiş arkadaşlara verdiğim öğütlerden bir tanesi kendilerini bu işe adamaları ve
öğrenme hevesini hiç bir zaman kaybetmemeleridir. Fakat proje müdürleri de bu "kendini adama"
olayını görüp ekibin omuzlarına daha fazla yük bindirmesi kaçınılması gereken bir olaydır. Yeni mezun ve
hevesli bir yazılım sektörü çalışanının daha işin başındayken strese kapılması ve akabinde yaptığı işten
soğuması aslında projeye vurulacak en büyük darbedir. Ne kişiye ne projeye ne de firmaya uzun vadede
bir yararı olmaz. Eski bir kaç yazımda bahsetmiştim, aslında bu olay üniversite zamanında hocaların
davranışları ve verdikleri ödevlere ve öğrencileri yönlendiremeyişlerine kadar dayanıyor. MSN'de sohbet
ettiğim ve daha ikinci sınıfta yazılım olayından soğumuş öğrenciler var. Tabii ki stres daha üniversite
zamanında ortaya çıkınca yazılım sektörü daha da büyük bir darbe almış oluyor.
http://www.analystdeveloper.com/progs/f4357de46951_13AB8/angry.jpgStresi yenmenin
birinci yolu stres hakkında konuşmaktır. Proje müdürü bu tür konuşmalara ortam hazırlamalı ve herkesin
rahatça konuşabileceği, fikirlerini, problemlerini rahatça dökebileceği bir zemin hazırlamalıdır. Bu zemin
hazırlanırken proje ekibinin nelerden hoşlandığı, hobileri, ilgi alanları, değer verdikleri şeyler, nefret
ettikleri şeyler vs göz önünde tutulmalıdır. Unutmayın projeniz ancak ekibinize verdiğiniz değer kadar
değerlidir ve ekibinize gösterdiğiniz saygı kadar saygıyı hakeder.
Bir firmanın sürekliliği çalışanlarına yaptığı yatırım ile doğru orantılıdır. Çalışanların da
sektördeki devamlılığı ve kariyerlerindeki yükselmesi yaptıkları işe verdikleri değer ve çalıştıkları firmaya
duydukları güven ile doğru orantılıdır. Bu formüllerden yola çıkarak uzun süre sektörde kalacak ve
başarılı işlere imza atacak bir organizasyonun kurulması çok kolay görünüyor değil mi? Evet çok zor değil.
Şaşırmayın. Stres faktörünü ortadan kaldırmak için atacağınız her adım, proje ekibi ve firma arasındaki
bağları güçlendirecektir. İnsanlar mutlu olmaya başladıkça verimleri de artacaktır. İşten atılmayacağını
bilerek her türlü problemini dile getirmeye alışan çalışanlar; stresi yaratan unsur ortadan kalkmamış bile
olsa bir rahatlama devresine girer. Bu rahatlama problemlerle boğuşmak için gereken gücü
yenileyecektir.
Stres yaratan faktörlerin açıkça tartışılması problemlere daha farklı çözümler bulmamızı da
sağlayabilir. İş yerinde azalan stres kişinin aile ortamına ve arkadaş ilişkilerine de yansıyacaktır ki
mutluluğun artmasına neden olur. Yatakta, sokakta ve işte performansınız artar. İş yerinde mutlu olup
olmadığınızın en önemli göstergesi, son 1 ay içinde özgeçmişinizi yenileyip yenilemediğinizdir. Çok fazla
stres olan ve çeşitli yollar denenip te sakinleştirilemeyen bir çalışanınız varsa ne yapacaksınız? Bu kişinin
çalışma ortamını tamamen değiştirmek gerekebilir. Örneğin evden çalışması için bir ortam hazırlanabilir.
Eğer ortam değişikliği yeterli gelmiyorsa bir psikologdan yardım alınmalıdır. Psikolog deyince tüyleri
diken diken olan varsa şimdiden söyleyeyim bu deli olduğunuz anlamına gelmiyor. Sadece yarı deli
olduğunuz anlamına geliyor ki zaten yazılım sektöründe yarı deli olmak faydalı bile :-). Şaka bir tarafa
eğer profesyonel yardıma ihtiyacınız varsa bunu ancak en iyi siz bilebilirsiniz. En azından deneme amaçlı
bile olsa bir psikoloğa görünün. Elde edeceğiniz yararlar zararlarından eminim fazla olacaktır.
Bir magazinde okumuştum; bir kişinin sosyal olarak aktif ve zihinsel olarak dingin olabilmesi için
günde en az 8 farklı kişi ile konuşması gerekiyormuş. Bu konuşmaların mahiyeti ne olursa olsun, farklı
insanlarla farklı konularda yapılacak sohbetler beyin cimnastiği olacaktır. Odaklandığınız iş
problemlerinden bir miktar uzaklaşmanızı ve problemlerle yeniden boğuşacak gücü kazanmanızı
sağlayacaktır.
Problemsiz bir hayat geçirmenin yolu yok, önemli olan problemler karşısında nasıl tepki
verdiğimiz ve çözümlere ne kadar hızlı ulaştığımız. Eğer stres karşısında ayakta durabiliyor ve hakkında
konuşabiliyorsak çözüm için gerekli yolun yarısını katetmişiz demektir. Bugün stres yaptığımız olayların
yarın belki de gülüp geçilecek şeyler olduğunu göreceğiz.
Stresden uzak ve mutlu bir hayat dilerim.
3.33 Yurtdışına Yazılım Üretelim
Dün akşam MSN üzerinde Sertaç Bey ile güzel bir sohbet yaptık. Konumuz Türk yazılım
firmalarının dışarıdan iş almaları idi. Sohbet sırasında bir kaç noktaya değindim fakat etraflıca blogda
yazmak iyi olur diye düşündüm. Hem böylece gelecek kollektif yorumlar ile bizim düşünemediğimiz
şeyler de ortaya çıkabilir diye düşünüyorum.
Burada yazdıklarımın hepsini uygulamak zorunda değilsiniz, hatta eksikler bile olabilir. Bu
yüzden yorumlarınızı bekliyorum. Ayrıca aşağıda sayılan işlerden yapabileceğiniz varsa, kontak
bilgilerinizi bana göndermenizi yada yorumlara yazmanızı rica edeceğim. Belki bu işlere girmek isteyen
kişilere profesyonel destek verebiliriz. Daha sonra yorumlardan derleyeceğim bu işleri yapabilecek
kişileri yazıya ekleyeceğim.
Birde zaten dışarıya bu tür yazılım işleri yapıyorsanız ve oturmuş bir sisteminiz varsa lütfen firma
bilgilerini yorumlara ekleyin.
Alt yapı
Firmanın belli bir yeri olması ve alt yapısının sağlam olması gerekiyor ki müşterilere bir güven
verebilsin. Aşağıdaki listede bir kaç yardımcı yöntem listeliyorum.
 Tanıtıcı site
Firmanızı tanıtmak için profesyonel bir tasarımcı ile oturup web sitesi hazırlayın. Bu site sizin
dışarıya açılan kapınız olacaktır. Ayrıca aylık bir ücret ile Google arama sonuçlarında üst sıralarda yer
alabilirsiniz.
 Referanslar
Yaptığınız işleri bir bir sıralayın. Bu işlerden aldığınız referansları ve iyi yorumları sitede yazın.
Eğer mümkünse müşterilerinizin kontak bilgilerini verin ki potansiyel müşteriler direk hakkınızda bilgi
alabilsin.
 Yazılım ortamı ve teknolojiler
Kullandığınız yazılım ortamını, araçlarını, işletim sistemi, veritabanı, bilgisayarların

kapasitelerini, yedekleme stratejinizi, güvenlik önlemlerinizi listeleyin. Size iş vermek isteyen ve sizi hiç
tanımayan bir kuruluşun hakkınızda en fazla bilgiyi alabilmesi için her türlü ayrıntıyı yazın.
 Kod Kontrol
Kod Kontrol için kullanılan ortam en önemli ortamlardan biridir. Örneğin her proje için sanal bir
TRAC makinesi kullanabilirsiniz. Trac subversion, wiki, hata veritabanı, ViewVC yada WebSVN gibi
yazılımlar ile kurulu geliyor. IP ayarlarını yapıp, modem üzerinden port forward ayarlarını yaptıktan sonra
internete açık hale gelir.
 Sürekli Entegrasyon
Kod kontrol sisteminize, değişiklikleri takip edecek ve derleme ile kurulumları yapacak otomatik
bir sistem kurmanız gerek. Zaman dar olduğu için mümkün olduğu kadar işi otomatikleştirmek gerekiyor.
Yazılım uzmanlarının tek işi kod yazmak olmalıdır. Derleme, kurulum gibi işlerle vakit harcamayın. Bu işi
Cruise Control ile yapabilirsiniz. (Bu tavsiyeyi vermekten artık dilimde tüy bitecek.)
 Ünite Testi
Kod yazarken ünite testlerinide ihmal etmeyin. Kodun doğruluğunu ortaya çıkaracak yegane
yöntemlerden biridir. Hatta ünite testlerini müşteri bile yazabilir eğer isterse. Kesinlikle yapılması
gereken bir iş
 İngilizce
Dışarıya iş yapıldığı için doğal olarak herkesin ingilizce bilmesi gerekiyor. Yada projeyi yönetecek
kişinin çok iyi ingilizce bilmesi şart. Eğer analizleri Türkçe'ye çevirecek zaman varsa yazılım uzmanlarının
ingilizce bilmesine gerek yok.
 Bloglar
Web sitenizde, firmada çalışan herkesin bir blogu olmalıdır. Çaycı Emine teyze bile bir blog
sahibi olmalıdır. Blogunda çay ve kahvenin nasıl yapıldığını, üretime nasıl katkıda bulunduğunu, firmanın
kafein ihtiyaçlarının nasıl karşılandığını, beslenmenin nasıl olduğunu yazmalıdır. Birde Kuru Kahveci
Mehmet Efendi ve Mahdumlarından bir reklam koydunuzmu, dışarıya sadece yazılım değil kahve de
satıyor olabiliriz.
 Teslimat
Derlenmiş yazılımın ve kaynak kodunun nasıl teslim edileceği ve test ortamlarının nerede
olacağı konusunda araştırma yapılıp, test amaçlı hosting hizmeti alınabilir. Eğer web tabanlı projeler
yapıyorsanız bu ideal. Windows Forms tabalı yapıyorsanız, müşteri ile anlaşmaya bağlı olarak, kurulum
dosyalarını iletebilir ve müşterinin test etmesini sağlayabilirsiniz. Teslimat zamanlarının iyi belirlenmesi
ve sık aralıklarla yapılması yerinde olur. Örneğin her hafta Cuma günü gibi.
 Evden çalışma
Kurulan bu alt yapı yazılım uzmanlarına evden çalışma imkanı verecektir. Kaynak kodu gizliliği ve
sızmaları önlemek için herkesin bilinçlendirilmesi gerekir. Evden çalışmak herkesin hayali olduğuna göre
de idealdir. Yanlız ücretlendirme konusunda sıkıntı yaşanabilir. Yazılım uzmanlarına hangi bazda ücret
verileceği (saatlik, her satır kod için, çözülen hatalar için vs.) tartışılmalı ve herkesin ulaşabileceği biçimde
duyurulmalıdır. Sizce aşağıdaki işler için yazılım uzmanı ne kadar ücret almalıdır?
o Her satır kod
o Karmaşık GUI tasarım
o Orta derece karmaşık GUI tasarım
o Düşük derece karmaşık GUI tasarım
o Yüksek öncelikli hata giderme
o Orta öncelikli hata giderme
o Düşük öncelikli hata giderme
o 1 saatlik ücret
o Hatanın sebebini arama (hatanın önceliği ile doğru orantılı)
o Bu listeye eklemek istediğiniz başka bir şey var mı?

Diyelimki proje yönetimi için hazırladığınız diyagram bütün alt işleri en ince ayrıntısına kadar
içeriyor. Yukarıda oluşturduğumuz fiyatlandırma politikası ile projenin maliyetini çıkartabilirmiyiz?
Analiz Süreci
Analiz sürecinde müşteri ile sürekli irtibat halinde olmanız gerekiyor. Yada belkide analizler size
hazır halde gelecek. Eğer analizler hazır ise öncelikle bir yerlere imza atmadan projenin maliyetini eldeki
verilere dayanarak kestirmeye çalışmak gerek.
 Metodoloji
Kullandığınız metodolojinin ne olduğunu ve adımlarını listeleyecek, kolayca web üzerinden

gezilebilen bir şablon hazırlayın. Böylece müşteri yazılım süreçlerini görüp ne aşamalardan geçtiğini
görebilir. Metodoloji belkide güven kazanmak için en önemli unsurlardan biridir. RUP, Agile, MSF gibi bir
metodoloji veya kendinizin geliştireceği bir water fall modeli bile olabilir. Yeterki belgelenmiş olsun ve
her adımı tespit edilmiş olsun.
 Prototip
Zaman varsa veya proje planında öngörülmüş ise bir prototip ile müşterinin karşısına
çıkabilirsiniz.Bu prototip size müşteriyi anlamak için daha fazla imkan sunar.
 Belge Sunucusu
Yazılan ve çizilen her türlü belge bir belge sunucusunda tutulmalı ve müşteriye erişim
verilmelidir. Hiç bir yazılı belge kaybolmamalıdır. MErkezi bir çalışma sistemi kurularak kim ne değişiklik
yapmış görülebilmelidir.
Proje Planı
 Riskler
Risksiz bir iş yok ama bunların farkına varmak heleki önceden sezinlemek neredeyse imkansız.
Risk durumlarında yönetim yapmak ise gerçekten bir hüner işi. Bir yazılım projesinde olabilecek belli
başlı riskler var. Bunlar:
o Felaket durumunda operasyonun durması
o Virüs ve dış etkenlerden dolayı aksama
o Yazılım uzmanlarının bırakıp gitmesi
o Müşterinin operasyonu durdurması

o Yeni sürüm yazılım araçlarından dolayı aksama
o Alt işlerin belirlenen zamandan uzun sürmesi
o Kapsam değişikliği
o Donanım değişikliği
o İletişim hatlarının aksaması
Bu risklerin pek çoğu önlenebilecek riskler. İyi bir planlama ile riskler en aza indirilebilir. Proje
gidişatı içinde ortaya çıkan riskler de iyi bir yönetim ve müşteri ile anlaşmalar sonucu giderilebilir.
 Maliyet
Yukarıda değindiğimiz maliyet unsurlarından başka projede kullanılacak lojistik desteğinde bir
maliyeti vardır. Artık Tuvalet kağıtlarından tutunda Emine teyzenin getirdiği çay ve kahveye kadar.
Bunları da proje maliyetlerine eklemek gerekmektedir.
 İşler
Proje planında ortaya çıkan işlerin en ince ayrıntısına kadar ayrılması ve müşteri tarafından
onaylanmasına dikkat edin. İleride ortaya çıkacak sürprizlerden kaçmanın tek yolu budur.
 İşlerin ufak parçalara bölünmesi
İşleri parçalara bölmek için Data Definition Diagram yada fonksiyon bazında bölümleme
yapabilirsiniz. Gereken zamanları tahmin ederken yazılım uzmanlarına danışmayı unutmayın.
 İşlerin Dağıtılması
İşleri dağıtırken herkesin yapabileceği işe göre dağıtım yapın ve fazla yüklemeden kaçının.
Hedeflerin Belirlenmesi
 Günlük Sürümler
Ecnebilerin "Nightly Build" dedikleri bu nane, kodunuzun her akşam kod kontrolden çekilerek
derlenmesini ve ünite testlerinin çalıştırılmasını salık verir. Eğer raporlar başarılı olursa (tüm dünkü ünite
testleri çalışıyor, yeni ünite testleri de %80 çalışıyor gibi), güne güzel başladık demektir. Eğer sabah
gelipte 2 gün önce yazdığınız ünite testinin artık doğrulama yapmadığını görürseniz (ve bunun sorumlusu
siz değilseniz) artık b**ktan bir gün sizi bekliyor demektir.
Şu çok güzel olurdu. Blogunuzun altında bir bölümde o gün kaç tane ünite testinizin geçtiğini ve
kaç tane eklediğinizi gösteren bir panel olsa ve her derleme işleminden sonra güncellense güzel bir
gösterge olurdu. Var mı böyle bir proje yapacak olan?
 Hataların Çözülmesi
Müşterinin girdiği veya dahili olarak bulunan hatalar sınıflandırıldıktan sonra sorumlu kişilere
atanır ve belirlenen süre zarfında çözümlenir. Ne kadar basit değil mi? Değil tabii ki çünkü her zaman
gözden kaçan bir üçüncü faktör (ecnebilerin devil in the details dediği gibi) ortaya çıkıp ya zamanı uzatır
yada hatanın giderilmesi sonucu 4 yeni hata ortaya çıkartır. Bu tür durumlarda verilecek reaksiyon,
analitik problem çözme yeteneği ve sistem bilgisine dayanır. Yapılan işin herkes tarafından bilinmesi
problem çözmeyi kolaylaştırır. İşin başında iç iletişimi sıkı tutarsak bunu sağlayabiliriz. Ben bir modül
yazıyorsam; bunun akış şemasını ve kodun dallandığı durumları belirtmem; kısacası bir teknik tasarım
belgesi hazırlamam gerekir. Diğer bir yazılımcı ise benim kodumu teftiş ederken bu belge ve kaynak kodu
ile teftiş eder. Kod Teftişi önemli bir konudur ve atlanmaması gerekir. Kod teftişini müşteri de yapabilir
isterse.
 Müşteri ile iletişim
Müşterinin size istediği zaman ulaşabilmesi ve isteklerini aktarabilmesi gerekir. Her zaman
erişilebilir olmaya özen gösterin. Müşteri isterse yazılımcılar ile doğrudan görüşebilir. Fakat operasyon
müdürünün bu iletişimlerden haberdar olması gerekir. Çünkü ileride ekibin çıkarlarını koruyacak kişi
O'dur. Eğer bir yazılım uzmanı olarak müşteri tarafından direk arandıysanız bunu bir belge haline
dönüştürüp operasyon müdürüne iletiniz ve hiç bir soruyu yanıtlamayınız. Daha sonra geriye dönüp
cevapları vereceğiniz söyleyin. Müşteri sizi sadakatınızı ölçüyor bile olabilir.
Kod Kontrol ve Müşteri erişimi
 Firma sunucuları
Sunucularınızı öyle bir kurunki müşteri kendi projesine istediği zaman tepeden bakabilsin. Kod
kontrol, hata ve istek veritabanı, belge sunucusu ve test ortamları her zaman müşteriye açık olmalıdır.
Çeşitli raporlama seçenekleri ile müşteriye gidişat hakkında bilgi verilebilir. Sizinde uğraşmanıza gerek
kalmaz bu raporlar için. Yani düşünün sourceforge.net gibi bir sistem fakat kurumsal olarak planlanmış
ve herkese açık değil. Bu arada Sourceforge.net sistemini satın alıp kullanabileceğinizi biliyormuydunuz.
 Subversion veya TFS

Alt yapı için, operasyonun büyüklüğüne göre bu iki üründen birini seçin. Sanal makine
kullanmak ta yönetimi kolaylaştırır.
Şeffaf Yönetim
 Erişilebilirlik
Bu firmanın yönetimi o kadar şeffaf olmalıki müşteriler bir bakışta bunu sezinleyebilsin.
Müdürlerin aktif katılımı, herkesin blogları, forumlar vs herşey göz önünde olmalıdır. Büyük kurumların
şu anda yaptıkları da bu değil mi?
Kullanıcı Kabul
 Testler
Kullanıcı kabul şartlarını iyi gözden geçirmek ve bu şartların yazılım içinde doğrulandığına emin
olmak gerekir. Testler için belirli test senaryoları hazırlamak ve iş akışlarının sonunda meydana gelecek
çıktıların belirtilmesi gerekir.
 Performans
Ürünün performans testlerinin de yapılması gerekir. Genelde otomatik araçlar ile yapılan bu
testler ürünün yük altında nasıl tepki vereceğini ölçmek ve optimum çalışacağı donanım gereksinimlerini
belirlemek için gereklidir.
 Kabul Şartları
Müşterinin öne süreceği kabul şartlarının yeterliliği ve olabilirliği en ince ayrıntısına kadar
araştırılmalıdır. Ayrıca müşterinin istediği bir şart ile sizin o şarttan anladığınız anlam aynı olmayabilir. Bu
tür yanlış anlamaları ortadan kaldırmak için bu şartların enine boyuna müşteri ile konuşulması gerekir.
Teknoloji Desteği
Kullandığınız yazılım ve donanım ile ilgili gerekli desteği almanız gerekir. Ayrıca yedek olarak bir
kaç bilgisayar bulundurmak ta operasyonun devamlılığı için şarttır. Microsoft Programları, CA VIP
programları, Linux desteği, IBM Programları vs gibi bir programa katılıp hem ürünleri ucuza almak hemde
gerektiğinde destek almak için anlaşmalar yapın.
Yazılımcı bulmak
İşin zor yanlarından biri de sanırım yazılım uzmanı bulmak. Ama yazılımcılar da ulaşılamaz
kaynaklar değiller. Nereye bakmak gerektiğini iyi bilmek gerekir. Genelde yazılım sitesi portallarında,
sosyal gruplarda, bloglarda, forumlarda aktif olan kişileri bulup birer özgeçmiş isteyebilirsiniz. Yada
liselerde yazılıma meraklı öğrencileri bu işler için yönlendirebilirsiniz. O yüzden bu bloga yorum
yazarsanız ne iş yapabileceğinizi yazın yada en azında blogunuzun adresini verin.
Müşteri Bulmak
Diğer bir zor işte bu. Fakat yukarıda sayılan işleri yapığınızda müşterinin de sizi bulması
kolaylaşır. Bir video konferans sistemi ayarlayıp müşteri ile yüz yüze konuşmayı sağlamanız gerek. Bir
sigorta şirketi ile anlaşıp projenin batması durumunda teminat gösterecek bir belge edinmeniz de
gerekir. Müşteri zaten bunu isteyecektir. Müşteri ancak size gueteri kadar güvenirse sizinle çalışacaktır;
sizinde imkanlar dahilinde bu teminatları sunmanız gerekir.
Ecnebilerin "outsorcing" dediği olayı biraz irdeledik. Yorumlarınızı ve yapabileceğiniz işleri

bekliyorum. Hatta bir çalışma grubu oluşturup bu tür bir alt yapının kurulması için fikir alışverişinde
bulunabiliriz. Ne dersiniz?
3.34 Bir Başka Gözlem
Paylaşıma açtığım ve bir gün gibi kısa bir sürede yazdığım gitar akorlarını gösteren basit
programa bir sürü yorum geliyordu. Tabii klasik olarak bu yorumlar genelde karalama yorumları idi. Bu
kişilerin eğitim seviyesinin düşük olduğu ve ailelerinden aldıkları terbiye eğitiminin yetersiz kaldığı
bıraktıkları yorumlardan aşikar. Gel gelelim bu olay yeni ressamın hikayesine benziyor. Yani herkes
hataları bulmak ve üstünü kırmızı kalemle çizmek için yarışıyor fakat bu hataları düzeltmeye yeltenmiyor.
Özgür Yazılım ve açık kaynak felsefesini de bu yüzden seviyorum, ağar bir hata varsa otur düzelt ve
yamayı projeye gönder ki herkes yararlansın. Eğer düzeltecek bilgin yoksa hatayı ilgili kişilere iletebilirsin
ama bununda yolları var. Aşağıdaki alıntı o blog girdisine ek olarak yazdığım kısımdır. Millet olarak çok
büyük bir problemimiz var aslında ama bu konulara girmekten nefret ediyorum.
Arkadaşlar Gitar Akor Veritabanı kendi kullanımım için VB6 ile bir günde
yazdığım basit bir program. Açıkcası programın bir tek amacı var, o da akorları
basitçe göstermek. Hani satacağım bir program da olmadığı için ne arayüzüne önem
verdim ne de programın performansına. Ben kullanıyorum ve burada paylaşıma
açtım ki böyle basit bir şeye ihtiyacı olan başkaları da varsa onlar da yararlansın.
Programın ticari bir amacı bulunmadığı için kimseye beğendirmek gibi bir iddiamda
hiç bir zaman olmadı. Bu sebeplerden dolayı mükemmel bir program ve cilalı bir
arayüz olması beklenemez. Benim işimi yeterince gördüğü içinde daha sonra
üzerinde herhangi bir geliştirme yapıp zaman kaybetme gereğide duymadım zaten.
Yeri gelmişken bir gözlemime de burada yer vermek istiyorum bu vasıta ile.
5 senedir İngiltere ve Avustralya'da yazılım uzmanlığı yapıyorum. Bu ülkelerde
tanıdığım ve sektörün ileri gelenleri ile yaptığım sohbetler sırasında birbirlerini
eleştirenler elbette oluyor ancak bu eleştirilerin aktarılma tarzı ile Türkiye'de
insanların eleştirilerini aktarma tarzı çok farklı. Türkiyede sadece yazılım konusunda
değil, her konuda insanlar birbirini kırmak veya sırf karalamak için dandik bir sebep
bulup çıkartmada, sürekli birbirine çelme takma konusunda gereğinden fazla istekli
görünüyor. Sitenin içeriğine ve vermeye çalıştığı mesaja bakmaksızın buldukları
küçük bir ayrıntı ile uğraşıp zaman kaybetmek ve kaybettirmek daha çok biz Türklere
has bir özellik gibi görünüyor.
Diğer ülkelerde bir kişi eğer bir problemi aktarıyorsa yanında 1 veya 2
tanede çözüm önerisi sunar ve cümle sonunda seçimi yine sana bırakmayı da ihmal
etmez. Bu tip insanlar yıkıcı olmak yerine yapıcı olmayı, problem çözmeyi ve konu
hakkında konuşmanın edebini biliyorlar. İşte bizim öğrenmemiz ve hayatımızın her
aşamasında uygulamamız gerekenin de bu davranış tarzı olduğuna inanıyorum.
Aslında bu tarzın eğitim ile de ilgisi var. Yani eğitim derken illaki üniversite veya
yüksek lisans demek istemiyorum. İşlerini iyi bilen, sürekli okuyan, sektörünü takip
eden insanların kendi işleri konusunda ki kültürleri yaptıkları işlere ve sohbetlerine
de yansır doğal olarak. Eminim birbirimize bu tarzda yaklaşırsak ülke olarak şu
ankinden daha hızlı bir şekilde ileriye gidebiliriz.
Milletçe çözmemiz gereken bilinç altımıza işlemiş tabiri caiz ise boktan bir psikoloji. Ama sanırım
bunun çözümü düşündüğüm kadar kolay değil. İlkokul’dan başlayıp eğitim süreci içerisinde, ailede,
yaşanılan çevrede ve girdiğimiz her ortamda uygulanması, düzeltilmeye çalışılması ve tatbik edilmesi
lazım ki bu psikoloji düzelsin. Yani her konu hakkında ahkam kesmenin bir anlamı yok veya en iyisini ben
bilirim demenin de. Kızdığım konu; bu kadar ananevi gelenek görenek, bilmem kaç yıllık tarih ve bilgi
birikimi, bir sürü bu konuya uyacak atasözü var hiç mi feyz almadık bunlardan. Neden yobazlaşıyoruz ve
herkesi herşeyi karalamaya çalışıyoruz. Öte yandan acaba bu kaba yorumları bırakan kişilerin benden
beklentileri çok mu yüksekti de bu basit programı görünce moralleri bozuldu? Yoksa zaten bu kişileri
memnun etmek hayatın her kademesin de zor mudur? Tez konusu olacak bir olgu bu, psikoloji yüksek
lisansı yada doktorası yapan var mı aranızda?
Neyse ben gene bu konuya tekrar parmak basarak değerli zamanımı boşa harcamış oldum. Ama
bazı şeyleri de söyleme ihtiyacı duyuyorum ki belki değişime, ilerlemeye katkım olur (bir umut dediler)
umuyorum. Tabii bu amaç çok ulvi bir amaç ve kaba yorumlar bırakan kişilerin anlama kapasitesinin bir
miktar üstünde ama ne yapalım.
145 UML ve CBD ile yazılım geliştirme
UML İngilizce Unified Modelling Language (Genelleştirilmiş Modelleme Dili) kelimelerinin baş
harflerinden meydana gelir. Modelleme sırasında kullanılacak bir dizi şematik gösterimi teşkil eder.
Genelde Nesne Yönelimli sistemlerin analiz ve modelleme aşamalarında kullanılır. Nesnelerin birbirleri
arasındaki ilişkilerini ve kendi iç yapılarını gösterir. Bir standart olarak Object Management Group (OMG)
tarafından dünyaya yayılmaktadır. Sahibi de OMG’dir. Şu anki en son versiyonu 2.0’dır. Programlama
dilinden ve işletim sisteminden bağımsız bir modelleme dilidir.
CBD İngilizce Component Based Development (Modül (ben PETEK diyorum) Tabanlı Geliştirme)
kelimelerinin baş harflerinden oluşur. Nesne Yönelimli olmayan sistemlerde Hizmet Bazlı Mimari’leri
(Service Oriented Architecture SOA) uygulayabilmek amaçlı geliştirilmiş bir yapıdır. Fakat Nesne
Yönelimli sistemlerde de kullanılabilir. CBD’de her modülün bir arayüzü, bir veritabanı, kendine has
özellikleri ve iş kuralları vardır. Modüller bir araya gelerek daha karmaşık modülleri ortaya çıkartabilirler.
Her modülün girdileri, çıktıları ve hata durumlarında ürettikleri hata mesajları vardır. Genelde IBM
Mainframe sistemi için geliştirilmiş fakat Windows veya Unix bazlı sistemlerde de kullanılmaktadır. CBD
kavram olarak her türlü projeye uygulanabilir.
Öncelikle OO analiz konularından başlayarak bir giriş yapmak istiyorum. Sırası ile UML ve CBD
konularına geçeceğiz. İlk olarak OO analiz sırasında aşama aşama ne tür belgelere ihtiyaç duyuluyor buna
bakalım.
4.1 İş Gereksinimlerini Modelleme Aşaması
Bu aşama “iş problemlerine” çözümler bulunması ve çözümlerin yazılımlar yolu ile hayata
geçirilmesine öncülük eder. İşi analiz edecek olan ekip İş Analisti’dir (Business Analyst). İş analistleri
sektörden aldıkları iş bilgisini yazılımcıya aktarırlar. Bu aktarım sırasında kullanılacak haberleşme dili
UML olmalıdır. Bu sayede aktarılan bilginin anlaşılabilirliği arttırılmış olur. Analizler ilk olarak
Senaryoların ortaya çıkarılması ile başlar. İş analistlerinin üretmesi gereken belgelere bir bakalım. Burada
anlatılan her belgeyi üretmek gerekli değildir, projenin gerekliliklerine göre değiştirilebilir yada yenileri
eklenebilir.
4.1.1 Senaryo Belgesi
Senaryolar analizi yapılan iş ile müşterileri veya bulunduğu piyasanın hareketleri ile aralarında
geçen olaylardır. Olayların tümünün doğrudan işi etkilemesi gerekir. İşin verdiği tepkiler ve sonuçları
burada tanımlanır ve Senaryolar olarak belgelendirilir. Senaryolar ortaya çıkartılırken takip edilecek

UML ve CBD ile yazılım geliştirme 146
metod müşteri yada kullanıcı grubu ile yapılacak aylık toplantılardır. Bu toplantılarda senaryolar gözden
geçirilir, kullanılacak sistemler belirlenir ve senaryolar ortaya çıkartılmaya çalışılır. Kullanıcı grubunun
kadrosu her toplantıda aynı olmalıdır ve değişmemelidir. Proje ekibinde her senaryodan bir analist
sorumlu olmalıdır. Tüm senaryoları yönetecek ve toplantıları organize edecek bir İş Gereksinimleri
Analisti (konusunda uzman ve deneyimli) bulunmalıdır. İGA hem toplantıların planını hem de
konuşulacak konuları ortaya çıkarır ve ekibi bu konulardan haberdar eder. UML ve OO analiz konularında
eğitim verecek düzeyde olması gerekir. Bu belgenin ingilizce ismi Use-Case’dir.
4.1.2 İşleme Modeli Belgesi
Bu arada İş Analisti tek tek senaryoları ele alırken İşleme Modeli’nide ortaya çıkarır. İşleme
Modeli analizi yapılan işin nasıl işlediğini ve senaryoların nasıl birbirleri ile bağlantıda bulunduklarını ve
aralarındaki ilişkileri anlatır. Her senaryonun girdi ve çıktıları göz önüne alınarak Genel İşleme Modeli
oluşturulur. Bu belgenin ingilizce ismi Business Process Model’dir.
4.1.3 İş Kuralları Kütüğü Belgesi
Ortaya çıkan mevcut ve yeni iş kuralları bu belgede numara verilerek kayıt edilir. İş kuralları,
analizin ilk aşamalarında, Senaryo belgeleri içinde ortaya çıkartılırken, belli bir miktarı geçtiklerinde ayrı
bir belgede toplanması gerekir. Bir kaç senaryo aynı iş kurallarına bağlantılı olarak çalışıyor olabilir. Her
senaryo belgesi için aynı iş kuralını tekrar tekrar yazmak yerine bu belgedeki kayıt numarası ile çağırmak
daha mantıklı olur ve zamandan kazandırır. İş kuralları, Değişim ve İstekler Kontrolüne bağlıdır. Bu belge
üzerinde yapılacak değişiklikler çok iyi gözden geçirilmeli ve projenin diğer kısımları üzerindeki etkisi çok
iyi tanımlanmalıdır. Bu belgenin ingilizce ismi Business Rules Register’dır
4.1.4 Sözlük Belgesi
Proje içinde ortaya çıkan deyimlerin ve bilinmeyen kelimelerin bu belgede toplanması gerekir.
Senaryo, İş Modeli yada İş Kuralları Kütüğü içinde sözlükte kayıtlı kelimeler geçiyorsa sözlük belgesine bir
bağlantı verilmelidir. Eğer belli devlet yasalarının kullanımı söz konusu ise onlarda bu belge içinde yer
alır. Projede kullanılacak hesaplama formülleri ve bu formüllerin parametrelerinin nerelerden geldiği de
belirtilir. Sözlük, Değişim ve İstekler Kontrolü’ne bağlı olmayan bir belgedir ve sürekli güncellenebilir.
Buna rağmen her proje ekibi üyesinin değişikliklerden haberdar olması gerekir ve Proje Yöneticisinin
değişikliği onaylaması gerekir. Bu belgenin ingilizce ismi Glossary of Terms’dür

4.1.5 Genel Proje Gereksinimleri Belgesi
Bu belgede proje için gerekli alt yapı anlatılır. Alt yapı hem geliştirme hemde hayata geçtiğinde
çalışacağı ortamı kapsar. Eğer proje sonucu ortaya çıkan ürünün çalışacağı bilgisayar alt yapısında özel
bir gereksinim varsa belirtilmelidir. Kullanılacak yan araçlar (yazıcı, nokta vuruşlu yazıcı, barkod okuyucu,
yazar kasa, tartı aletleri, kontrol sistemleri vb.) ve bunların kullandığı port numaraları ve bağlantı şekilleri
açıkça belirtilmelidir. Ürünün çalışacağı bilgisayarların ekran çözünürlüğü, hafıza miktarı, disk kapasitesi
gibi bilgilerde bulunmalıdır. Kullanılacak üçüncü parti yazılımların tüm ayrıntıları belirtilmelidir. Örneğin
projenin hayata geçebilmesi için bir Web sunucu gerekiyorsa tüm ayrıntıları ile gerekli herşey açıklanmalı
ve desteği istenen teknolojiler tanımlanmalıdır. Örneğin PHP desteği isteniyorsa Web sunucunun bu
desteği verebilmesi veya bir ISAPI dll yardımı ile eklenebilir türden olması gerekir. İşletim sistemleri ve
gerekli parçalarının tanımlanması gerekir. Örneğin projeniz Windows XP service Pack1 ile gelen
winhttp.dll dosyasını kullanıyorsa ürünün kurulduğu test ve kullanım ortamlarında bu öngereksinimin
olmasına dikkat edilmelidir. Satın alınması gereken yazılımların yapması gereken işlerde burada
tanımlanır. Eğer mümkünse firmaların adresleri, telefonları veya örütbağ adresleri ile kontak kurulacak
kişilerin listesi burada yapılır. Yazılan projenin mevcut projeleri etkileyip etkilemediği ve ne gibi
değişikliklere yol açacağı da burada bir çözüme kavuşturulur. Sistemin arayüzleri belirlenerek dış
sistemler ile nasıl haberleşeceği ve giriş/çıkış verilerinin neler olacağı tanımlanarak dış sistemlerin bu
gereksinimleri destekleyip desteklemediği araştırılır. Örneğin eğer yeni sistem, Sistem B ile
konuşamıyorsa hizmet X müşteriye sunulamaz. Bu durumda test ve kullanıcı ortamlarında Sistem B’nin
varlığından ve istediğimiz işi yaptığından emin olmalıyız. Eğer projeniz mevcut sistemler üzerinde
değişiklik gerektiriyorsa bu değişimin içeriği ayrıntılı biçimde tanımlanmalıdır. Ürünün kullanıcı
tarafından ne kadar zamanda öğrenilebileceği ve kolaylıkla hazmedilebilmesi için ne gibi geliştirmelerin
yapılması gerektiği tanımlanmalıdır. Ürünün ağ kaynaklarını ne kadar kullanacağı ve günlük kaç işlemin
gerçekleşeceği ve kaç kullanıcının ürünü kullanacağı bilgileri tanımlanmaya çalışılır. Kullanıcıların
coğrafik olarak nerede olacakları ve ne şekilde ürünü kullanacakları belirtilir. Eğer güvenli bir biçimde
korunması gereken bir veri üzerinde çalışılıyorsa, güvenlik sistemlerinin nasıl kullanılacağı, kullanıcı
hakları ve kısıtlamaları, veri tabanına erişim ve ağ kaynaklarını kullanım hakları belirlenmelidir. Ürünün
lisanlama işleyişi ve lisansların kontrolü belirtilmeli ve bunları kontrol edecek sistemler burada ortaya
çıkartılmalıdır. Kurulum, kullanıcı yardım kılavuzları, ve her türlü kullanıcı belgesi bu belgede
belirtilmelidir.

Görülüyor ki analiz aşamasında, ileride koda dönüşmeyecek her türlü bilgi bu belge içinde
toplanıyor ve tüm bu gereksinimler hem test ekibi için hemde yazılım geliştirme ekibi için bir temel
yardım kaynağı oluyor. Bu belgenin ingilizce ismi Non-Functional Requirements’dır.
4.1.6 İş Nesne Modeli Belgesi
Bir işi analiz ederken ortaya çıkan sınırlardan dışarıya her uzantıda farklı bir sistemin hizmetleri
kullanılır. Analiz edilen iş kendi içinde de belli parçalara ayrılır. Her parçanın (nesne) bir arayüzü ve
haberleşme için kullandığı mesajları vardır. İş Nesne Modeli, tüm iş nesneleri ve dışarıdan heberleşilen
tüm nesneleri gösteren modele denir. Çok genel bir gösterim şeklidir ve veritabanı modeli ile yada sınıf
şemaları ile karıştırılmaması gerekir. Görünüş olarak sınıf şemalarına benzer fakat sınıf isimleri firmanın
bir bölümünü yada başka bir sistemin parçasının adı olur. Büyük sistemi kolayca görmek, dışarıya ne gibi
mesajlar gidiyor ve ne gibi sistemler ile alış veriş içinde olduğumuz belirlemek için idealdir. İş Nesne
Modeline giren her sistem ve/veya parçası yazılı olarak anlatılmalıdır. Bu şemaların bir UML aracı ile
çizilmesi şarttır. Bu belgenin ingilizce ismi Business Object Model’dir.
4.1.7 Tool-Tip Kayıt Kütüğü Belgesi
Tool-Tip’ler her hangi bir ekran nesnesi (text-box, buton, drop-down, liste kutusu) üzerine fare
ile gelindiğinde yada durum barında (status bar) ortaya çıkan kısa yardımlardır. Kullanıcıyı sunulan bilgi,
yada girilecek veri konusunda bilgilendirirler. Tüm Tool-Tip’lerin kayıt edilerek belgelendirilmesi gerekir.
Her Tool-Tip bir numara verilerek kaydedilir. Bu belgenin ingilizce ismi Tool Tips Register’dır.
4.1.8 Mesaj Kayıt Kütüğü Belgesi
İş kurallarına göre kullanıcının girdiği verinin kontrolü ve sonrasında çıkacak mesajları kapsar.
Mesajlar Bilgilendirme, Uyarı, Hata (Informational, Warning, Error) olarak üçe ayrılır ve her hatanın bir
numarası olmalıdır. Örneğin bir programda iş kuralına göre 8 karakterden az şifreye izin verilmiyordur
fakat kullanıcı şifresini tanımlarken 5 karakter girmiştir. Butona bastığında iş kuralına göre girilen şifre
kontrol edilir ve kriterlere uymadığı saptanır, ve kullanıcıya bir hata mesajı ile bilgilendirme yapılır. Bu
mesajda kullanıcıdan en az 8 karakter girmesi istenir. Mesajda ki tamam tuşuna basınca girilen şifre
silinerek boşaltılır ve imleç şifre kutusuna konumlanarak yeni şifre girişi için beklemeye geçer. İşte tüm
bu işlemler öncesi ve sonrasıyla belgelendirilmelidir. Bu belgenin ingilizce ismi Message Register’dır.
4.2 Kullanıcı Arayüzü Gereksinimleri Ve Tasarımı Belgesi
Tüm yukardaki belgeler ilk sürümlerini verdiğinde Kullanıcı Arayüzlerini planlamaya geçebiliriz.
Kullanıcı Grubu toplantılarında İş Senaryolarına göre adım adım gidilerek sunumu ve girişi yapılacak

verinin düzeni ortaya çıkartılır. Ekranlarda neler isteniyor, düzeni nasıl olmalı gibi problemlerin kullanıcı
tarafından önerilmesi ve tartışılması gerekir. Ekran akışları ve standardı şemalar ile belirlenmelidir. Çok
karmaşık sistemlerde mantıksal olarak sistemi bölerek ve her parçaya bir isim vererek işi
kolaylaştırabiliriz. Böylece gelecekte yazacağımız modüllerde ortaya çıkar. Her ekran konrolünün (buton,
text-box, liste kutusu) ismi, açıklaması, yaptığı iş, Tool-Tip numarası ve Mesaj numarası bu belgede yer
almalıdır. Bu belge ilk sürümünü verirken ekran prototipleri geliştirilebilir. Kullanıcı Grubu
Toplantılarında bu prototipler kullanılarak onay alınmaya çalışılır. Bu belgenin ingilizce ismi User
Interface Requirements’dır.
4.3 Sistem Modelleme Aşaması
4.3.1 Uygulama Mimarisi Belgesi
Bu belge uygulama için önemli olan modülleri listeler ve özelliklerini anlatan belgelere
bağlantılar verir. Aşağıdaki gibi bir tablo şeklinde olabilir.
İsim Tip Bağlantı

Hizmetin yada modülün genel Hizmet/Modül Bu hizmet yada modülü anlatan
ismi API belgeye bağlantı.
Uygulama/RDBMS
Diğer
Ayrıca her modülün sistemde hangi mimari katmana oturduğunu da gösterir. Ayrı bir başlık
altında incelenir ve projede üretilen her modülün hangi katmanlarda yer aldığını ve diğer katmanlardaki
modüller ile nasıl haberleştiğini gösterir. Örnek olarak:

v0.4 28/4/2003
DRAFT only
Complaints User
Interface
Boundary Layer • see preliminary dialogue
map for an outline of
proposed web pages /
Complaints screens…
Email
Dashboard • operational
monitoring and
• to receive alerts management
and notifications… information for
complaints (No data access allowed -
only access to solutions or
infrastructure components)
(No user interface allowed - only business and • tied to user interface
control logic, data encapsulated in components) • handles transaction, session / state
Complaints • no business data
• minimal business logic (just calls to lower components)
Security
Solution Layer Orchestration Services
Case
Reporting
• fill in case plan template
Complaints Reference
Process Mgmt Data (codes)
• Allocate complaint Letter
Complaint Details • Send complaint for Client Mgmt
Authorisation
Constructor
• Accept / Reject • Get Client details • draft a letter to
• record/update a complaint complaint • Add New client the client / contact
• get previous complaints Authoring
• search (by type, text, status etc)
• basic statistics (current day only) Generic Case Tool
Generic Process
Management Complaints Op
Mgmt
Reporting
• Create Work item
• Allocate • provide dashboard
• allocate / reallocate
• escalate facilities
• Accept / authorise Audit Trail
• Reject
Enterprise
Business Client Staff Document
Component Registration Management
Case & Work
Layer Provide name and address information Using Staff information available
through SAP services (contact Management
name and phone etc)
(No user interface Event
allowed - minimal • Create Case
• Create Work Item (& connect to case) Notifier
business logic and • Allocate & Re-allocate work
only COMMON • Manage generic case/work status
rules, no control • Close / complete work or case
logic, no Profiles
knowledge of other Outwards
Organisation
components or • provide view of profile
hierarchy (for work allocation Correspondence
direct calls, data
purposes) • Send and archive letter
encapsulated in • maintain organisation hierarchy (until
• maintain profile hierarchy • retrieve and re-edit…
available in SAP…)
components)
• positions within teams
• officers occupying positions
Inwards Client
Channels Relationship
Applications
• manage all inwards
communication from fax,
Management
• record all contact with
Infrastructure
scanning, email etc client
• provide a list of all recent
contacts (regardless of
Layer
channel or purpose…)
Kurulum yapılacak yapıyıda burada belirtebiliriz. Ürünü kuracağımız donanım ve yazılım yapısını
bir şema ile anlatmamız gerekir. Örnek olarak:

Bu şema kurulumun genel bir planını gösterir. Fazla ayrıntı verilmez. Kurulum yapılacak yapının
ağ mimarisi genel olarak tanımlanır.
Ürünün parçalarının hangi platformlara kurulacağı hakkında da bilgi vermek gerekir. Modüllerin
kimi parçaları veritabanı sunucusu üzerinde çalışıyorken, diğer bir parçası istemci tarafında hizmet
veriyor olabilir. Dağınık sistemlerde her modül farklı bir sunucuda çalışıyor olabilir ve aralarındaki
haberleşme için belli kanalları kullanıyor olabilirler. Tüm bu ayrıntıyı da Ağ Kurulumu başlığı altında bu
belgeye dahil edebilirsiniz. Örnek olarak bu şemada bir ürünün parçalarının farklı sistemler üzerine nasıl
kurulacağı ve haberleşeceği belirtilmiştir:
Note that this broad design is likely to change during the detailed design phase of any redevelopment…
As at 30/4/2003
At this stage it is a summary of all the Phase 1 (ie. Within 12-18 months) recommendations…
F/W F/W
All external External Web

clients & agents Server(s) One or several mid-
(via browser) May use Complaints
services
range servers…
ATO Portal Mainframe
internet
Complaints
Orchestration
Client
Registration
Complaints
CRM (CP) Op Reporting
Generic Case
* = could also be Case Reporting Mgmt
replaced by Change
Program capabilities * Generic
* Complaints
Process Mgmt Process Mgmt
Complaint * Case &

Details Work Mgmt
Client Mgmt Staff

Internal Web
Server(s) Organisation
Profiles
Internal user
Complaints UI
COLA (message based
middleware)
Complaints Dashboard
Security Audit Trail

Authoring
Email
Tool (MS
(Outlook) = New or altered
Word)
facility this phase

Eğer standart dışı bir haberleşme protokolü kullanılacaksa bununda belirtilmesi gerekir. Bu
belgenin ingilizce ismi Application Architecture’dır.
4.3.2 Harici Arayüz Gereksinimleri Belgesi
Geliştirdiğimiz sistem ile dış sistemler arasındaki haberleşmeleri ele alan bir belgedir. Giriş/Çıkış
verilerini, mesajları ve verinin düzenini belirler. Dış sistemler senaryo şemalarında AKTÖR olarak
belirirler. Öncelikle kendi ürettiğimiz arayüzü ve bağlantı kuracağımız dış sistemin arayüzünü
tanımlayarak işe başlamamız gerekir. Bağlantı kuracağımız arayüzden hangi hizmetleri kullanacaksak
bunları da ayrıntılı belirtmemiz gerekir. Eğer bağlantı kurmak istediğimiz dış sistemde bizim istediğimiz
hizmetler yok ise bu hizmetleri ayrıntılı biçimde yazarak istememiz gerekir. Bu belgenin ingilizce ismi
External Interface Requirements’dır.
4.3.3 Veritabanı Tasarım Belgesi
Bu belge geliştirilecek ürünün veritabanı hakkında ayrıntılı bilgi içerir. Her tablo ve saha
açıklamaları ile beraber yazılır. Kullanılacak Stored-Procedure ve SQL programcıkları yazılır ve test edilir.
Bir Entity Relationship Şeması ile tablolar arasındaki ilişkiler gösterilir. Veritabanının uygulanacağı
sisteme özel durumlar varsa bunlarda belirtilir. Anahtar sahalar, tabloların büyüme hızı, öngörülen işlem
kapasiteleri ve tahmini kayıt kapasiteleri belirtilmelidir. Belgenin ilk sürümden sonra değişiklik istenirse
tüm kontrol Veritabanı Yöneticilerine bırakılır. Bu belgenin ingilizce ismi Database Design’dır.
4.3.4 Hizmet Modeli Belgesi
Her modülün sunduğu çeşitli hizmetler vardır. Mesela aritmetik modülü isminde bir modülümiz
olsun. Bu modülün sunduğu hizmetler Toplama(), Çıkarma(), Çarpma() ve Bölme() olsun. Siz Muhasebe
modülünü yazarken Aritmetik modülünün sunduğu bu hizmetleri kullanacaksınız, bu hizmetleri oturup
tekrar yazmaya gerek yoktur. Her hizmetin bir giriş verisi ve çıkış verisi ile hata durumlarında üreteceği
mesajları vardır. Hizmetler o modülün arayüzünü oluştururlar ve dış dünya ile bağlantı kuracağı
kapılarıdır. Herhangi bir sistem yada kullanıcı bu hizmetleri kullanarak modül ile haberleşir ve istediği
işleri yaptırmaya çalışır. Bu arada veritabanı ile ilgili işlemleride gerçekleştiriyor olabilir. Aritmetik
modülü, yapılan her işlemin kaydını ve kimin yaptığını veritabanında saklayabilir.
Bir modülün arayüzüne ait tüm hizmetlerin genel olarak anlatıldığı belgeye Hizmet Modeli
denir. Tüm hizmetler bir tablo içinde sıralanır ve kendi operasyon belgelerine bağlantılar verilir. Bu
belgenin ingilizce ismi Service Model’dir.

Component XYZ
interface 1
COMPONENT
interface 2
SPECIFICATION
Figür 1: İki arayüz içine toplanmış hizmetler görünüyor.
4.3.5 Nesne Devamlılığı Belgesi
Bu belge proje içinde varolan nesnelerin ne tür biçimlere dönüştüğünü gösterir. Örneğin bir sınıf
nesnesi bir veritabanı tablosuna yada XML belgesine dönüşebilir. Modelleme sırasında ortaya çıkan sınıf
kütüphaneleri yada modüller ve modüllere ait hizmetler, veritabanı tabloları veya XML belgeleri ile
karşılaştırmalı tablolar halinde üretilmelidir. Bu belgenin ingilizce ismi Object Persistence Document’tir.
4.3.6 Hizmet Operasyon Belgesi
Bir modül arayüzü veya sınıf içerisinde hizmet olarak bulunan fonksiyonların giriş, çıkış ve hata
mesajları ile tüm algoritmasının anlatıldığı belgedir. Çözüm getirilen Senaryolara, gerçeklenen iş
kurallarına bağlantı verilir. Yani tekrar tekrar yazmak yerine iş kuralı yada senaryo belgesinin yeri ve
sayfa numarası belirtilir. Giriş ve çıkış verileri formatları ile beraber verilir. Hata durumlarında üretilecek
mesajlar belirtilir. Bu belgenin ingilizce ismi Service Operation Document’tir.
4.4 Prototipleme Aşaması
Tüm bu belge üretimi devam ederken ekran prototipleri de tasarım edilir ve kullanıcı grubu
toplantılarında onaya sunulur. Toplantılar sonucunda ekranlar değişikliğe uğrayacaktır. Kullanıcının aktif
katılımı ile sunumu yapılacak verinin düzeni belirlenir. Prototipler Visio gibi bir programlama
yapılabileceği gibi yazılım geliştirme için kullanacağınız araç ile de yapılabilir. Hem böylece elinizde
yazılım sürecinde kullanabileceğiniz hazır temalar olmuş olur.
4.5 Örnek Proje ile OO ve UML
Bu bölümde UML ile adım adım bir projenin nasıl uygulanacağını analiz aşamasından başlayarak
test işlemlerine kadar ele alacağız. Örnek firma olarak kullanacağımız firma bir personel taşıma firması.
Bünyesinde barındırdığı minibüs, otobüs gibi araçlar ile personeli evinden işine, işinden evine; belli
güzergahlar içerisinde taşıyan bir yapıya sahip. Ayrıca kişilerin özel olarak araç kiralamak istediği

durumlarda da yardımcı olmakta. Firmamızın ismi AntTur olsun. Bu arada yazılım firmamızın ismide BİG
Yazılım olsun. Üç arkadaşın baş harfleri. Projeye kısa olarak ATOS diyelim (AntTur Otomasyon Sistemi).
AntTur’un sahibi Ahmet Bey bize gelerek, bünyesinde çalışan araçların kayıtlarını tutmak, hangi
firmaların servislerini çektiğini görmek, hangi güzergahlardan gittiğini, ne kadar benzin ve yol masrafı
yaptığını, boşta olan araçların listelerini görmek gibi bir dizi işlemi otomatize etmek istediğini belirtti.
Ayrıca müşteri ile firma arasındaki ilişkileri daha yakın tutmak için düşündüğü bir dizi yeni işlemi de
kullanıma örütbağ üzerinden açmak istediğini belirtti. Bunun için piyasada hazır bir program
bulamadığını ve bu projeyi yapıp yapamayacağımızı sordu. Tabii ki bizde üstesinden gelebileceğimizi
söyleyip bu işi aldık.
BİG Yazılım ve Ahmet Bey arasında geçen ilk toplantıda müşteri istekleri kaba taslak ortaya
çıkmıştı. Yapılacak iş mevcut isteklerin detaylandırılıp, müşteriye düşünmesi için zaman tanımak ve yeni
isteklerin ortaya çıkmasına zemin hazırlamaktır.
BİG Yazılımdan İlker Bey, bu projeye atanmış ve proje yöneticisi olarak görevine başlamıştır.
İlker Bey ilk olarak 2 ayını Ahmet Bey’in ofisinde geçirecek ve personel taşıma işini analiz edecek,
problemlerin ne kadarının bir bilgisayar programı ile çözülebileceğini araştıracaktır. Her hafta sonunda
yönetim kuruluna yada bağlı olduğu birime rapor vererek analizin ne aşamada olduğunu, daha fazla
zamana ihtiyacı olup olmadığını, ortaya çıkan müşteri ihtiyaçlarının bir listesini ve bu ihtiyaçların
çözülebilirlik derecelerini de raporunda belirtecektir. İlker Bey aynı zamanda Sistem Modelleme ve
Analiz konularında firmadaki en yetkili kişidir ve UML ve OO hakkında firma içi eğitimleri yönetmektedir.
İlk raporda yer alacak iş senaryoları “Genel Senaryolar” olacaktır. Bu genel senaryolar
oluşturulacak sistemin yapısını ana hatları ile ortaya koyar. Başka bir deyişle müşteri isteklerinin, analizci
gözü ile nasıl çözüme kavuşturulacağını ortaya koyar.
Analiz aşamasında senaryolar 3 aşamada incelenir ve sırası ile detaylandırılarak oluşturulur.
1. Genel Senaryolar
2. Müşteri Hedefleri
3. Detay Fonksiyonlar
4.5.1 Senaryolar (Use Cases)
Burada UML’in ingilizce kelimelerinden biraz bahsedelim. Bu kitapta bahsettiğim “senaryo”

terimi UML’de adı geçen “Use Case”’dir. Genel Senaryolar dediğimiz ise “Summary” olarak adlandırılır.

Müşteri Hedefleri “User Goal” ve Detay Fonksiyonlar’da “Sub-function” olarak geçer. Bu terimlerin
açıklamalarını ileride göreceğiz. Kavramların hepsini birden aynı anda vermektense yeri geldikçe
örnekler ile açıklamak, konunun anlaşılması için daha iyi olacaktır sanırım.
İlker Bey ilk haftalık çalışmasından sonra müşteri isteklerini hemen hemen ortaya çıkarmış ve
başlıklar halinde belirlemiştir. Sürekli müşteri tarafında işin içerisinde bulunmuş ve işi analiz etmeye
çalışmıştır. Çıkardığı sonuçları Ahmet Bey ile paylaşmış ve gerçekten bu problemlere çözüm arayıp
aramadığını sorgulamıştır. Ahmet Bey çıkartılan her sonuçtan haberdardır. Yavaş yavaş müşteri istekleri
ortaya çıkmış ve bu isteklere bilgisayar ortamında çözüm aranmaya başlanmıştır. İlker Bey burada ortaya
çıkartılan senaryoları daha sonra yazılım ekibine aktaracaktır.
Şimdi İlker Bey’in ilk hafta sonunda Yönetim Kuruluna verdiği rapora bir göz atalım. İlk raporda
yer alacak genel senaryo başlıklarına dikkat ediniz. Bu genel senaryolar yönetim kuruluna konu hakkında
bilgi verecek ve planlama aşamalarında yardımcı olacaktır.Konu: AntTur Taşımacılık Ltd. Şti. Projesi
ATOS.
Başlangıç: 5 Mart 2003
Süreç: İş Analizi ve İsteklerin Modellenmesi
Sayın Yönetim Kurulu üyeleri,
Eylem planım içerisinde müşteri tarafında geçirdiğim zaman zarfında Genel Senaryolar
ortaya çıkartılmış ve müşteri isteklerine bilgisayar ortamında çözüm aramaya çalışılmıştır.
Yazılımdan yapması beklenen
1- Çalışan araçların yönetimi
2- Çalışan şoförlerin yönetimi
3- Servisleri çekilen firmaların yönetimi (“Servis Çekmek” taşımacılık dilinde bir firmanın
personelini evinden işine, işinden evine taşımak anlamında kullanılıyor.)
4- Servislerin güzergahlarının yönetimi
5- Yolcuların yönetimi
6- Aksayan servislere/şoförlere puan yöntemi uygulanması ve bu servislerin neden
aksadığının araştırılması.
7- Firmalardan kontak kurulan kişilerin kayıtlarının tutulması
8- Servis aracı sahiplerine yapılan ödemelerin yönetilmesi
9- Kar zarar analiz raporları
Ant Tur ve Müşterileri arasında olan ilişkiler

 Servis durumlarının örütbağı üzerinden takibi (çalışılan her firmanın yöneticisi servislerin
gelip gelmediğini örütbağı üzerinden kontrol edebilsin)
 Müşterinin isteğine göre servis aracı bulmak
 Şoförlere vardiyalı işler bulmak
 Araç sahiplerini bakım zamanları konusunda uyarmak
 Yeni araçların sisteme girilebilmesi için sorulacak soruların basılması
 Örütbağ üzerinden, araç sahipleri için kayıt olabilme imkânı
 Ekstra işlerin araç sahiplerine bildirilmesi ve onay alınması
Bundan sonraki 2 aylık eylem planım içinde genel senaryolardan detay senaryolara inilecek ve
detay senaryoların yazımına başlanacaktır. Bu arada veritabanıda modellenerek ortaya çıkarılacaktır.
Projenin %10’luk Genel Senaryolar safhası bitmiş ve Ahmet Bey tarafından test edilmiştir.
Saygılarımla
İlker Dağıstanlı
Bu raporda dikkat edilmesi gereken konulara bir bakalım. Öncelikle İlker Bey ve Yönetim kurulu
arasındaki bilgi akışı çok üst seviyede ve detay bilgi barındırmıyor. Böylelikle Yönetim Kurulu üyeleri işin
devam ettiğini ve ana hatları ile konunun ne olduğunu biliyorlar, zaten daha da fazla bilgiye ihtiyaçları
yok. Personel Taşıma işi konusunda ve bu iş içerisinde kullanılan deyimler hakkında da bilgi sahibi
oluyorlar (servis çekme). Projenin “İş Senaryoları Detaylandırma” safhasına geldiğinide görüyorlar.
Bundan sonra Yönetim Kurulu’nun tek ihtiyacı yüzde rakamlarıdır. Proje yüzde kaç bitti, finansmanın
yüzde kaçı harcandı, yazılımcılar yüzde kaç işlerini bitirdi vs gibi.
İlker Bey konumu itibarı ile Ant Tur ile BİG Yazılım arasındaki köprü görevini görür ve bilgi akışını
sağlar. Buradaki iletişim ne kadar akışkan ve güçlü olursa daha sonra ileride çıkacak aksaklıkların çoğu
önlenmiş olur.
Son paragrafta Ahmet Bey’in genel senaryoları test ettiğinden bahsediliyor. Evet Ahmet Bey
çıkartılan bu senaryolardan haberdardır ve hepsini okuyarak doğruluğunu kabul etmiştir. Böylece her
senaryonun büyük sistem içerisindeki güvenliği arttırılmıştır. Yani senaryolardan hepsi gerçekten
müşterinin çözüm aradığı konulardır, boşuna ürettiğimiz bir senaryo yoktur.
Burada eXtreme Programing’den bahsedelim. Bu metodolojide her aşamadan sonra bir test yer
alır. Amaç ürün ortaya çıkartıldığında hiç bir hatanın (veya en az hatanın) olmamasıdır. Testler projede
payı olan herkes tarafından yapılır. Müşteri, sistem analist, proje lideri, yönetim kurulu, programcılar,

test ekibi, destek ekibi vb projeye en ufak bir katkısı olan kişi test işlemlerinde yer almalıdır. Tabii ki her
biri farklı testler yapacak ve ortaya çıkacak ürünün hatasız ve isteklere tam cevap verecek bir ürün
olmasına dikkat edeceklerdir. Ayrıca standartlara uyulup uyulmadığını da test edeceklerdir.
İlker Bey’in bu ilk raporundan sonra yapacağı iş Genel Senaryolar’ı yazmak olacaktır. Bu işlem
gene müşteri tarafında ve belli standartlara göre yapılacaktır.
Bu arada kağıt israfını önlemek ve ağaçları korumak amaçlı olarak, üretilen hiçbir belge
yazıcıdan basılmaz, ve hiç bir yere kağıda basılı biçimde taşınmaz. Zaten kağıda basılmış belgelerin sürüm
kontrolü çok güç olur. Bir toplantıya girdiğinizde her kesin en son sürüm belgelere sahip olması gerekir.
Bu da ancak belgeleri sayısal ortamda tutmak ile mümkün olur. Ahmet Bey’in, Yönetim Kurulunun, İlker
Bey’in ve yazılım uzmanlarının birer bilgisayarı olduğuna göre ve hepside e-mektup kullanabildiğine göre
belgeleri kağıda basmak pek iyi bir uygulama değildir.
Senaryolar yazılırken dikkat edilecek pek çok konu var. Öncelikle senaryoların BİG Yazılım içinde
belli bir biçimi olmalıdır. Oluşturulacak şablon Word belgeleri ile bu problem rahatça çözülür. Ayrıca bu
senaryoların hepsi belli bir dizin altında toplanmalı ve herkesin kolayca ulaşabileceği bir yerde
durmalıdır. Belli zaman aralıklarında yedeğinin alınmasıda gereklidir. Şablonun nasıl doldurulacağı
bilgiside şablon içinde bulunmalıdır.
Projeye verdiğimiz kısa isim gibi (ATOS) senaryolara da bir kısa isim verelim (SN). Her
senaryonun bir ismi ve numarası olmalıdır. Firma içindeki kültür ve bilgi akışı bu koyulan kurallar
sayesinde herkesin anlayabileceği bir seviyeye gelmiş olmaktadır. Eğer firmanız UML ve CBD gibi
kavramları kullanmaya başlayacaksa, öncelikle eğitim için vakit ve nakit harcayıp her çalışanın aynı
seviyede bilgiye sahip olmasına özen gösterin. Firma içindeki iletişimin aynı iletişim kanalları ve
sistemleri kullanılarak yapılması, üretkenliği müsbet biçimde etkiler. Her şeyin belli bir standartta olması
ve herkesin bu standartları bilmesi haberleşmeyi akışkan kılar.
Burada biraz durup önemli bir konudan bahsetmek istiyorum. Firmanızda yeni çalışmaya
başlayacak kişilere ne gibi işlemler uyguluyorsunuz. Firmanızın belli bir düzeni var mı? Firmanızda
kullandığınız her ürünün bir eğitim kitapçığı vb. var mı? Firmanızda uyulması gereken kuralları anlatan bir
dosyanız var mı? İçörütbağınızda projeler ve eğitim ile ilgili yeterli miktarda bilgi mevcut mu? Yeni
kişilere yeterli eğitimi veriyor musunuz? Eğer bu sorulara samimi olarak evet cevabı verebiliyorsanız,
yolun yarısını katetmiş oluyorsunuz. Diğer yarısıda mevcut bilgiyi güncel tutmaktan geçiyor.

Yukarıda bahsettiğimiz 3 çeşit senaryo modelinin ana şablonuna bir göz atalım. Bu senaryo İlker
Bey’in ilk raporunda geçen ilk maddenin yazılmış halidir.

ATOS.SN1 Araç Yönetimi
Senaryo # 1
Use Case Name Araç Yönetimi
Kapsam İş Süreci (Şeffaf-Kutu)
Hedef Seviye Genel Senaryo
Aktör(ler) Son Kullanıcı (birincil)
Hedef Bu senaryoda firma bünyesinde çalışan/çalışmış tüm araçların bilgilerinin tutulması
hedeflenmiştir. Araç üzerinden araç sahibine ve firmaya da ulaşılabilir.
Amaç Firma bünyesinde çalışan pek çok araç vardır. Bunların doğru biçimde yönetilmesi,
yerleştirilmesi, bakımlarının yapılması gibi konuları organize etme gereği ortaya
çıkmıştır. Bu senaryo Araç Yönetiminin Genel Senaryosudur.
Olgunluk Kırmızı
Varsayımlar
Sorular 1- Araç hakkındaki müşteri şikayetlerinin tutulması zorunluluğu var mıdır?
2- Bir firmaya atanmış bir araç ihale zamanı dolmadan değiştirilebilir mi?
Aynı özelliklere sahip araçların birbirinin yerine kullanılması olabilir mi? Araçların
arıza yapmaları halinde gerekli olabilir.
Öndurumlar Bir aracın veritabanında yer alabilmesi için son bakım tarihinin son 6 ay içinde olması
gerekir.
Başarılı bitiş Yok
durumları
Minimum bitiş Yok
durumları
Tetikleyici Araçlar ile ilgili her türlü işlem için bu senaryo dikkate alınır.
Ana İş Akışı
1- Aracın kayıt edilip edilemeyeceği araştırılır (son bakım tarihi 6 aydan geri olmayacak)
2- Aracın tüm bilgileri araç sahibinden talep edilir
3- Araç kaydedilir
4- Son bakım tarihleri 6 ayı geçen araçların sahipleri uyarılır.
5- Firmalara atanacak araçlar kriterlere göre ortaya çıkarılır. (koltuk sayısı + Şoförün oturduğu semt)
6- Araçlar her servis aksattığında puan verilir.
Alternatif İş Akışı
1- Yok
İş kuralları  Araç son bakım tarihi 6 aydan geri olmamalıdır
Notlar 
İlişkili Şemalar
Belge Tarihçesi
Tarih Sürüm Açıklama İsim/Soyisim
6/Mart/2003 0,1 İlk sürüm oluşturuldu İlker Dağıstanlı
10/Mart/2003 0,1 İş akışına 6. madde eklendi İlker Dağıstanlı

Buradaki tasarım sadece bir öneridir ve kendi isteğinize göre şablonu değiştirebilir, gerekliliklere
göre yeni sahalar ekleyebilir ve MS Word şablonlarına “header, footer” ekleyerek firmanızın ismini,
logonuzu, belgenin sürüm bilgilerini, sayfa numaralarını, belgenin bulunduğu dizini, en son üzerinde
çalışan kişi vb. gibi bilgileri de koyabilirsiniz. Hatta bir veritabanı hazırlayıp bu bilgileri tutacak bir
program hazırlamak ta mümkün, önemli olan ne kadar zamanınız ve naktiniz var?
Senaryoda adı geçen alanlara bir bakalım.
4.5.1.1 Senaryo başlığı
Senaryo başlığı proje ismi ve senaryonun kısaltılmış hali ile senaryonun numarasından ve
isminden oluşur. Ek olarak en sona sürüm numarasınıda ekleyebilirsiniz fakat çokta gerekli değildir.Yani:
proje ismi + SN + senaryo numarası + Senaryo ismi + (sürüm no)
Örneğimizde “ATOS.SN1 Araç Yönetimi” senaryo başlığıdır. Proje ismi ve SN1 nokta işareti ile
birbirinden ayrılmıştır.
4.5.1.2 SN#
Senaryonun numarasını tutar. Her senaryoya birden başlayarak bir numara vermek gerekir
4.5.1.3 SN isim
Senaryonun ismi burada belirtilir. Açıklayıcı bir kelimeyi takiben bir fiilden oluşur. Birincil
Aktörün yapmak istediği işi belirtir. Örneğin “Yeni Müşteri Oluşturma”, “Araç Yönetimi” vs.
4.5.1.4 Kapsam
Senaryonun kapsamı belirtilir. Kapsam ileride ortaya çıkacak modüllerin (component) isimleri
olarak düşünülebilir. Örneğimizden anlaşılacağı üzere tasarım aşamasına geçtiğimiz zaman “Araç”
isminde bir modülümüz olacaktır. Kapsamlar, üzerinde tartışılan sistemlerde olabilir (İş Süreci, Sistem,
Alt-Sistem). Bu üç sistem için oluşturulan Senaryo’ları Şeffaf-Kutu (white-box), yada Kara-Kutu (black-
box) olarak tanımlamamızda gerekir. Şeffaf-kutu olan senaryoların girdi ve çıktı’ları ile içinde geçen tüm
işlemler ve veri yapısı tamamen Aktör’ler tarafından bilinir. Öbür taraftan Kara-Kutu senaryolarının
sadece girdileri ve çıktıları bilinir. Bu konuyu Modül-Tabanlı Geliştirme konusunda daha ayrıntılı
anlatacağım. Henüz modüllerimizi kodlayıp, kullanıma sunmadığımız için sadece bu kadar bilmemiz
yeterlidir.

4.5.1.5 Hedef seviye
Hedef Seviye, senaryonun 3 aşamalı senaryolandırma sınıflarından hangisine ait olduğunu

söyler (Genel Senaryolar, Müşteri Hedefleri, Detay Fonksiyonlar). Senaryoları bu şekilde sınıflandırmanın
amacı, analizin belli bir düzen içerisinde olmasını sağlamak içindir. Konu hakkında genel bilgi sahibi
olmak isteyen yönetici ekibi sadece Genel Senaryo sınıfındaki senaryoları okuyarak işin ne olduğunu
kavrayabilirler.
Genel Senaryolar, sistemi tanımlayıcı 3 ana görevi yerine getirir.
1. Büyük sistem içerisinde Müşteri Hedeflerinin nereye oturduğunu gösterir.
2. Müşteri Hedeflerinin hayat döngülerini belirtir.
3. Bir kitabın içindekiler bölümü gibi daha alt seviye senaryoların başlıklarını belirtir
Müşteri Hedefleri ise gerçekte birincil aktörlerin yapmak istedikleri işleri belirtir. Müşteri Hedefi
olan bir senaryo “Aktör bu senaryoyu uyguladıktan sonra sistemden mutlu bir şekilde ayrılacak mı?”
sorusuna “Evet” yanıtını vermeye çalışmaktadır.
Detay Fonksiyonlar, Müşteri Hedeflerinin yerine getirilmesi için atılacak adımları belirler. Detay
fonksiyonları sadece gerçekten ihtiyacınız varsa ekleyin. Örneğin “Sisteme Oturum Aç”, “Ürün bul”,
“Müşteri bul” gibi işlemler birer detay fonksiyondur.
4.5.1.6 Aktörler
Aktör, senaryo ile ilişkili olan veya senaryoyu kullanan kişi veya sistemdir. Unutmayın bir
senaryoyu başka bir sistemde kullanabilir. Her senaryo için en azından bir adet birincil aktör olmalıdır.
Eğer senaryoyu kullanan başka aktörler de varsa onlarıda sıralamak gerekir.
4.5.1.7 Hedef
Senaryonun hedefini belirtir. Sadece, senaryo ile yapılması amaçlanan iş anlatılır. Senaryo NE işe
yarar sorusuna cevap verir. Bir paragraftan fazla olmamalı ve senaryoyu okuyan kişiye genel bir bilgi
vermelidir. Detay bilgi barındırmaz.
4.5.1.8 Amaç
Senaryonun sistemde NEREYE oturduğunu söyler. Bir işi veya sistemi analiz ederken, o sistemi
parçalara bölmek ve küçük parçalar halinde ele almak bize zaman kazandırır. Bu açıdan bakıldığında her

senaryo büyük sistemin bir parçasıdır ve genelde diğer senaryolar ile ilişki içerisindedir. Ayrıca “Amaç”
senaryonun sistem için NEDEN önemli olduğunu da söyler.
4.5.1.9 Olgunluk
Olgunluk senaryonun hangi süreçte olduğunu gösterir. Renkler ile kodlama UML diline oturmuş
bir gösterim biçimidir.
Kırmızı: İş süreci senaryosu tanımlanır fakat henüz detaylandırılmamıştır.
Turuncu: Senaryonun iş akışı şekillenmeye başlar ve sorular bölümünde sorular belirmiştir.

Turuncu seviyesi biraz uzun sürdüğü için Turuncu1 Turuncu2... biçiminde çoğaltılabilir.
Sarı: Senaryo, kontrol mekanizmaları için yayınlanabilir bir hale gelmiştir. Senaryonun
bitirilebilmesi için temel adımlar ortaya çıkarılmış ve alternatif adımlardan önemli olanlar tamamen
genişletilmiştir. Ayrıca senaryonun büyük sistem içerisindeki durumuda güvenli bir hale gelmiştir
(Gerçekten sistemin bu senaryoya olan ihtiyacı ortaya çıkartılmıştır).
Yeşil: Senaryo bir sonraki süreç için hazırdır, fakat henüz onaylanmamıştır. Şablondaki tüm
sahalar doldurulmuş ve Soru kısmında hiç bir soru kalmamıştır.
Mavi: Senaryo onaylanmış ve bitmiştir. Son Gereksinim Modeli’nde yerini alır.
Gümüş: Senaryo başka bir projede yeniden kullanılmıştır. Küçük değişiklikler yapılmış olabilir.
Altın: Senaryo birden fazla başka projede değişiklik yapılmadan kullanılmıştır.
4.5.1.10 Varsayımlar
Senaryonun çalışabilmesi için oluşacak varsayımları burada listeleriz. Her zaman karşımıza
çıkmasada bazı durumlarda gerekli olabilmektedir.
4.5.1.11 Sorular
Senaryonun tamamlanabilmesi için ortaya çıkması gereken konuların sorulduğu bölümdür. Yeşil
konumuna gelmiş bir senaryonun Sorular kısmında hiç bir soru olmaması gerekir.
4.5.1.12 Ön durumlar
Senaryonun işlemeye başlayabilmesi için gerekli ön durumları belirtir. Ön durumlar

gerçeklenmeden senaryo işleme başlayamaz. Numaralı bir liste şeklinde ve hiyerarşik bir yapıda olması
gerekir.

4.5.1.13 Başarılı bitiş durumları
Senaryo bittikten sonra, sistemin alacağı durumdur. Ana iş akışı sonunda yada Alternatif iş
akışları sonucunda oluşacak her türlü başarılı bitiş durumu burada numaralı liste biçiminde not edilir.
4.5.1.14 Minimum bitiş durumu
Minimum bitiş durumları, senaryonun bitiş durumu ne olursa olsun (başarılı yada başarısız) her
zaman doğru olacak durumlardır. Örnek olarak bir senaryo başarılı veya başarısız biçimde sonlanırsa,
senaryonun çalıştırıldığına dair sonuç kütüklerine bir kayıt eklenir. Kütüklere kayıt ekleme işlemi her iki
durumda da geçerlidir.
4.5.1.15 Tetikleyici (seçmeli)
Tetikleyici bu senaryonun işlenmesini başlatan olaydır. Bazen senaryonun ilk adımı tetikleyici
adım olabilir. O zaman burada tekrar etmenin gereği yok. Fakat tetikleyici olaylar birden fazla ise burada
listelemek iyi olur.
4.5.1.16 Ana iş akışı
Senaryonun hedefine ulaşabilmesi için gerekli adımların sıralanması ile oluşturulur. Bu akış
aktör ile sistem arasında geçen konuşmadır. Senaryonun akışı ön koşullardan sonlanma koşullarına
doğru olmalıdır. Her hangi bir hata durumunu barındırmaz. Her türlü ön koşulun ve tahmin edilemez
hataların ortaya çıkmayacağı var sayılır.
Her adım için:
 Bir hedefin başarıldığını gösterin
 Aktörün nasıl tepki verdiğini yakalamaya çalışın, kullanıcı arayüzünü değil.
 Her adım bir aktör ile başlar (Aktör şu işlemi yapar, Sistem şu bilgiyi gönderir)
 Aktörlerin isimleri ile kullanılmasına özen gösterin, çünkü aynı işi yapan birden fazla
aktör olabilir.
4.5.1.17 Alternatif iş akışları
Ana iş akışında belirli durumlara göre sapmalar olabilir veya parametrik yapılarda işlemler
parametrelere göre değişebilir veya senaryodaki problemin başka bir çözüm yolu olabilir. Buna göre
alternatif çözüm yollarını ve hata durumlarındaki senaryonun vereceği yanıtı bu kısımda ele alıyoruz.
Buradaki numaralı listeye bir bakalım.

Diyelimki 3 adımdan oluşan bir ana iş akışınız var. Birinci adım için 2 adet alternatif çözümünüz
olsun. İlk çözümü 1a olarak isimlendireceğiz. İkinciyi de 1b. Alternatif çözümlerin adımlarına 1a1, 1a2 de
diyebiliriz fakat çok fazla karıştırmamak için baştaki adım numarasını düşürüyoruz.
1a. Ana akışın 1. adımına alternatif olabilecek 1. durum
a1. Adım 1
a2. Adım 2
1b. Ana akışın 1. adımına alternatif olabilecek 2. durum
b1. Adım 1
b2. Adım 2
3a. Ana akışın 3. adımına alternatif olabilecek 1. durum
a1. Adım 1
a2. Adım 2
Evet yukarıdan da anlaşıldığı gibi üçüncü adım içinde bir adet alternatif çözümümüz mevcut.
4.5.1.18 İş kuralları
Burada senaryo uygulanırken dikkat edilmesi gereken iş kurallarını listeliyoruz. Listelenen iş

kuralları zaman içerisinde değişebilir. Tüm senaryolar kırmızıdan maviye doğru yol alırken iş kuralları da
kendi içinde değişir ve gelişir. Senaryolar mavi olduktan sonra iş kurallarının tümü tek bir dosyada
toplanır ve senaryolardan çıkartılır. Senaryolar maviden sonra sadece iş kuralı dosyasına bir referans
numarası tutarlar. Genelde iş kuralının numarası referans amaçlı kullanılır.
İş kuralları 2 türlüdür. Birincisi, doğrulanmaması sonucu senaryoyu bitiren kurallar. Bunlar

doğrulanması zorunlu kurallardır. İkincisi, doğrulanmaması sonucu senaryo işlemeye devam eder fakat
aktör bu konuda bilgilendirilir. Bu tür iş kurallarıda seçmeli iş kurallarıdır. İş kuralları tesbit edilirken
seçmeli mi yoksa zorunlu mu olduğu belirtilmelidir.
4.5.1.19 Notlar
Tüm bu sahalardan herhangi birine girmeyen ve senaryoyu ilgilendiren her türlü bilgi bu alana
yazılır.

4.5.1.20 İlişkili diyagramlar
Senaryonun daha iyi anlaşılabilmesi için bir aktivite diyagramı veya veri akışı diyagramı bu alana
eklenebilir. Yeri geldikçe bu diyagramları açıklayacağım.
Senaryo belge şablonlarını tıkızda bulabilirsiniz. Unutmayın farklı projeler veya firmalar için
farklı şablonlar gerekebilir. Gereksinimlerinize göre şablonları değiştirmekten kaçınmayın. Tüm firma
içinde aynı şablonu kullanmak iletişimin hızlı olabilmesi için daha sağlıklıdır. Firmadan firmaya şablon
değişebilir ama firma içindeki projelerde kullanılan senaryo şablonları aynı olmalıdır.
Buraya kadar bir senaryonun nasıl ortaya çıktığını ve geliştirildiğini ele aldık. Şimdi senaryolarda
adı geçen aktör terimini inceleyelim.
4.5.1.21 Aktör
Aktör sistemle senaryolar yolu ile ilişkide bulunan birimdir. Aktör genel bir terimdir ve
senaryolar içinde kullanabilmek için öncelikle bir sıfat kazandırılması gerekir. Örneğin “Son Kullanıcı” bir
aktördür. Senaryoyu kullanacak olan birim bir grup insan da olabilir örneğin “Muhasebe Bölümü”
muhasebe ile ilgili senaryoları kullanacak bir grup insanı simgeler. Aktörler başka bir program veya
sistem de olabilir. Örneğin EFT modülü sizin yazdığınız “Müşteri Bul” senaryosunu kullanmak isteyebilir.
“Müşteri Bul” aynı zamanda “Muhasebe Bölümü” tarafından da kullanılıyor olabilir. Aktöre verdiğimiz
sıfat UML dilinde “stereotype” olarak bilinir ve aktörün UML gösterimi “Cin Ali” şeklindedir. Her UML
nesnesinin bir stereotype’ı vardır. Sırası geldikçe bunları göreceğiz. Aktör eğer bir sistemi temsil ediyorsa
sıfatı sistemin ismi olacaktır.
İngilizce terimleri veriyorum fakat bunları kullanmayın, maalesef UML modelleme

programlarında mecburen kullanacaksınız fakat Türkçe ne demek istediğini çok iyi bilmeniz gerekiyor.
Burada senaryo olarak bahsedilen analiz sistemi “Use-Case” olarak bilinir ve UML modellemede
“Use-Case Diagram” olarak şekillendirilir. Senaryo şemaları, aktör ve senaryolar arasındaki ilişkiler ile
senaryoların kendi aralarındaki ilişkilerini gösterir.
Operator Firma
Figure 2: UML Şemalarında aktörün gösterimi

4.5.1.22 Senaryolar arasındaki ilişki çeşitleri
include: Sistem oluşmaya başladığı zaman bazı senaryolarda tekrar eden işlemler ortaya
çıkabilir. Bu tür tekrar eden işlemleri farklı bir senaryo olarak ayırıp ana senaryoya “include” bağlacı ile
bağlarız.
<<include>>
Puanla
(from Sofor Yonetimi )
<<include>>
Sofor Yonetimi
Odeme Belirle
Figure 3: Include bağlacının UML gösterimi
generalization: Sistemde ortaya çıkan senaryolardan iki tanesi birbirine çok benziyor fakat bir
tanesi biraz daha fazla iş yapıyor ise oluşur. Analiz sırasında sadece bir iş kuralı yüzünden bir senaryoyu
ikiye bölmek gerekebilir. Bu gibi durumlarda sorun çıkaran iş kuralını senaryodan izole edip ayrı bir
senaryo gibi ele alırız ve “generalization” bağlacı ile ana senaryoya bağlarız. Bu olay bize problemi
çözmek için alternatif yollar görmemizi de sağlayabilir.

Firma Yonetimi
(from Firma Yonetimi)
Servis Bilgilerini Listele Guzergah Olustur

(from Servis Yonetimi) (from Servis Yonetimi)
Figure 4: Generalization bağlacının UML gösterimi
extend: Ana senaryoya bağlı bu tip özel senaryolar, ana senaryoya farklı davranışlar
ekleyebilirler. Fakat bu durumda ana senaryo genişleme noktalarını (extension points) belirtmelidir. Ve
bağlantı üzerinde bu genişleme noktalarından hangilerinin kulanıldığı gösterilmelidir.
<<extend>>
Uygun Servis bul
(from Arac Yonetimi)
<<extend>>
Guzergah Olustur
Operator
(from Servis Yonetimi)
(from Aktor)
Servis Degistir
(from Arac Yonetimi)
Figure 5: Extend bağlacının UML gösterimi
4.5.1.23 İş ve sistem senaryoları (business ve system)
Bu iki tür senaryoyu ayırd etmek zaman zaman güç olmaktadır. Genel olarak Sistem Senaryo’ları
yazılım ile olan ilişkileri, İş Senaryo’ları ise bir firmanın müşterisi yada piyasa hareketleri ile olan
ilişkilerini ortaya koyar.

İş senaryolarını analiz sırasında ayırd edebilmek için firmanın müşteri isteklerine nasıl cevap
verebileceğini düşünmeli ve bilgisayar sistemlerini veya veritabanını değil, müşteriye verilecek cevabı
düşünmeniz gerekir.
Düşünün ki bilgisayar diye bir şey henüz icat edilmemiş ve siz müşterinizle karşılıklı oturarak
sohbet ediyor ve isteklerine çözümler bulmaya çalışıyorsunuz. Burada geçen olaylar firma ile müşteri
ilişkileri üzerine kurulu ve senaryolar İş Senaryo’su olarak ortaya çıkıyor. Proje başında yaratılan İş
Senaryoları sistemi anlamak için yararlı olmaktadır. Ayrıca Yönetim Kurulu gibi yazılım alanında olmayan
kişilere proje hakkında yeterli bilgiyi sunar. Sistem senaryolarının doğruluğunu veya alternatif sistem
senaryolarının bulunmasına da yardımcı olur.
Müşteriniz gittikten sonra bilgisayar başına geçip (bu arada bilgisayar icat oldu) müşteri
isteklerini kaydedip, çözümleri yaratıyorsunuz. İşte burada yazılım ile aranızda geçen diyalog içindeki
senaryolar da Sistem Senaryo’ları olmuş oluyor. Sistem senaryoları, planlama, proje maliyet analizi,
modül tanımlama gibi işlemlerde yardımcı olur ve bilgisayar sistemi ile olan bağlantıları gösterir. Her İş
Senaryo’sunu başarabilmek için bir dizi Sistem Senaryo’su gerekir.
4.5.1.24 Senaryo oluşturma sırasında yapılan yanlışlar
Bir işi analiz etmeye kalktığınızda, aklınıza sürekli ekran tasarımları ve veritabanı tabloları
geliyorsa yanlış yapıyorsunuz demektir. İşin analizi o iş ile müşterileri arasında geçen ilişkilerin ortaya
çıkarılması ile başlar. Müşterinin istekleri ve işin verdiği tepkiler kayıt edilir. Tüm müşteri istekleri
olabilecek tüm senaryoları ile ortaya çıkarıldıktan sonra işin bu senaryolara nasıl tepki verdiğini
yakalamanız gerekir. Ancak bu şekilde iş sahibinin isteklerine cevap verebilecek bir program
yazabilirsiniz. Önce işin nasıl döndüğünü anlamanız gerekiyor hemde tüm ayrıntıları ile. Her türlü işlem
yazıya döküldükten sonra, müşteri ile iş arasında geçen bu senaryoları analiz edip bilgisayar ortamında
çözüm arama aşamasına geçilmelidir. Kayıt edilecek veri, sunumu yapılacak veri, ve formatları ortaya
çıkarılır.
Dikkat ederseniz bu aşamaya kadar henüz bir veritabanı oluşturmadık veya tek satır kod
yazmadık. Veritabanının sahaları hemen hemen ortaya çıktı ama tablolar daha belli değil. Sunumu
yapılacak veri belirlendi ama ekran tasarımları daha yapılmadı. Henüz her şey planlama aşamasında ve
daha yapmamız gereken pek çok iş var.

4.5.2 Sınıf Şemaları (Class Diagrams)
UML’in en fazla kullanılan ve doğrudan yazılım ile ilgili olduğu için yazılım mühendislerinin en iyi
bildiği şema tipidir. Class olarak isimlendirilmesinin sebebi belli aynı özelliklere sahip veri ve
fonksiyonların bir çatı altına toplanmasından kaynaklanıyor. Kafanızda bir model oluşturması açısından
bir kaç örnek vereyim.
Bir ilkokul sınıfı düşünün. Boş bir oda, sıralar, karatahta gibi şeyler içinde mevcut. Bu, sınıfı
tanımlayan genel bir anlatım ve ilkokul sınıfının “class” durumunu gösterir. İlk ders ile birlikte öğrenciler
sınıfa doluşur ve öğretmen eğitime başlar. Sınıf artık “class” durumundan “object (nesne)” durumuna
geçmiştir. Öğrenciler sınıfın sahalarıdır (fields). Öğretmen sınıfın bir fonksiyonudur ve öğretme
fonksiyonunu gerçekleştirir. Öğretme fonksiyonu içinde öğrencilerin öğrendikleri bilgiler değişir ve
gelişir. Bu arada ilk ders ile beraber sınıfta bir isim kazanmıştır, örneğin “3. sınıf” ve nesne haline
gelmiştir. Bu sınıfın üç tür durumu var. Bunlar “derste”, “tenefüste” veya “tatilde”. Ayrıca derste ise
hangi derste olduğunu gösterecek bir de göstergesi var, örneğin matematik, hayat bilgisi gibi. Ders günü
sonunda 3. sınıfta ortadan kalkar ve tekrar boş bir oda haline gelir. Yani hafızadan silinir fakat kodu hala
elinizdedir yada şeması.
Boş bir oda hali sınıfın şemasıdır. Öğrencilerin nereye oturacağı öğretmenin nerede duracağı ve
işlenecek derslerin haftalık programının belirtildiği tablo sınıfın planını oluşturur. Öğrenciler sınıfın
alanlarıdır. Yani veriyi tutan değişkenleri. Öğretmen ise sınıfın yegâne fonksiyonudur. Öğretme işi ile
sınıfın alanlarının barındırdığı bilgiyi yeniler veya yeni bilgiler ekler. İlk ders ile birlikte bu şema somut bir
hal kazanır ve işlemeye başlar. İşte bu noktada nesne haline geçer. İlk tenefüs zili çalınca sınıfın durumu
“tenefüste” olur ve öğretme fonksiyonunu yürüten öğretmen sınıfı tenefüse çıkarır ve öğretme işine ara
verir. Son dersten sonra sınıfa son verilir.
Bir gün bir koro çalışması için bir kaç sınıfın tüm öğrencileri toplanarak bir çalışma yapmaya
karar verirler. Tüm koro öğrencilerinin aynı zamanda kendi sınıfları vardır ve bu özel çalışma için bir
araya gelmişlerdir. Sınıflarında öğrendikleri tüm disiplini ve bilgiyi beraberlerinde getirirler ve yeni bir
sınıf oluştururlar. Yani kendi sınıflarında müzik dersinde öğrendikleri tüm bilgi ve deneyimlerini bu yeni
koro sınıfı için kullanırlar, fakat matematik dersindeki bilgileri koro sınıfı için gereksiz olduğundan
kullanmazlar. Kendi sınıflarında öğrendikleri bilgiyi bu koro sınıfına miras olarak getirirler. Burada farklı
sınıfların bir araya gelmesi ile yeni bir sınıf kurulmuş ve farklı bir iş için uğraş vermektedirler.

İlkokul bitipte ortaokul başladığında sınıfların tipleri değişir. Her ders için farklı öğretmeler
gelmeye başlar. Yani bir sınıfın artık birden fazla fonksiyonu vardır. Sınıfın durumları değişmemiştir hala
“tenefüste”, “derste” ve “tatilde” durumları vardır. İlkokuldan gelen bilgiler hala mevcuttur ve yenileri
eklenmektedir. İlkokul bilgileri miras yolu ile gelmiştir fakat sınıfın yeri ve tipi değişmiştir. Her ders için
farklı sınıflara gidiliyordur. Buda çoklu form (polymorphism) oluşturur. Farklı sınıflarda farklı davranışlar
ile öğrenen öğrenci hala bir öğrencidir.
Sınıf (class), nesnenin planıdır. UML gösterimde sınıf aşağıdaki gibi gösterilir. 3 bölümden
oluşur. İlk bölümde sınıfın ismi yer alır. İkinci bölümde sınıfın sahaları ve üçüncü bölümde de sınıfın
fonksiyonları yer alır. Sınıf hafızada yer aldığı zaman artık bir nesne haline gelir.
Firma
FirmaIsmi
IhaleZamani
AracSayisi
IhaleKontrol()
AracArttir()
Figure 6: IBM Rational™ ile sınıf gösterimi

Ihale
Servis Firma 1
1
n 1 1
1 FirmaPersonel
1..n
TicariFirma OzelMusteri
n
n
Arac
1
n
0..1
1..n Kontak
0..n
BakimAriza
Figure 7: AntTur sınıf Şeması
4.5.2.1 Özellikler (properties)
Sınıfın alanlarını temsil eder. Sınıf kendi bünyesinde barındıracağı veriyi bu alanlarda saklar.
Alanlar sınıfa özel (private), herkese açık (public), korumalı (protected), paket (package) olarak dört tip
erişilebilirlik derecesine ayrılırlar. Kullanılan programlama diline göre başka tipleride olabilir. UML
şemalarında aşağıdaki işaretler ile gösterilir.
+ herkese açık
- sınıfa özel
~ paket
# korumalı
UML modelleme programlama dilinden bağımsızdır fakat kullanacağınız dile göre değişikliklere
izin verecek kadar esnektir. Kullandığınız programlama dilinin özelliklerine göre erişilebilirlik derecelerini

ekleyip çıkartabilirsiniz. UML modelleme yazılımları, bir model için dil seçimi yaptığınızda o dilin
özelliklerini kullanmanıza izin verir.
Modelleme sırasında ben yanlızca + ve – işaretlerini kullanıyorum. Diğer işaretler genelde

modelleme sırasında ortaya çıkmıyor. Ancak analizler ilerleyip kodlamaya geçildiğinde iş kuralları ile
birlikte yada ihtiyaca göre belirleniyorlar.
4.5.2.1.1 Alanlar (attributes)
Bir sınıfın özelliğidir. UML gösteriminde tavsiye edilen biçimi:
<tip (+ - ~ #)> <alan ismi>: <veri tipi> <array genişliği> = <ilk değeri> ,<özellik, yazı
ile>}
Bir örnek verecek olursak:
- Soyisim: string*1+ = “Yeniceri” ,readOnly-
İlk olarak (-) işareti ile bu alanın erişilebilirlik derecesini belirtiyoruz. Soyisim: bu alanın ismi yani
sınıfın alana erişmek için kullanacağı belirteçtir. string alanın barındıracağı veri tipini belirtir. *1+ alanın bu
tip veriden kaç tane barındıracağını belirtir. “Yeniceri” alanın ilk tanımlandığında alacağı veridir.
,readOnly- kısmı ek özellikleri tanımlamak için kullanılır. Yeri geldikçe bu özellikleri anlatacağım.
4.5.2.1.2 İlişkiler (associations)
İki sınıf arasındaki ilişkiyi belirlemek amacı ile oluşturulmuş bir alandır. Güncel hayattan bir
örnek verelim. Sülale ve aile ilişkisinde soyisminiz sizin hangi sülaleye mensup olduğunuzu belirtir.
Soyisimleri aynı olan Ahmet, Mehmet, Hüseyin evlenip kendi başlarına bir aile oluşturur. Soyisimleri aynı
olan bu üç kişi sülalenin genetik mirasını barındırırlar ve yeni nesillere bunu aktarırlar. Soyisim burada
ilişki belirten alandır. Soyisim hem ailenin bir alanıdır hemde sülalenin bir alanıdır. UML şemaları
üzerinde çok farklı görünmesine rağmen ilişkiler ve alanlar aslında aynı şeydir.
İlişkilerin UML gösterim biçimi alanlar ile aynıdır. Şemalar da ise iki sınıf arasında ok biçiminde
gösterilir. Okun gittiği yön hedef sınıftır. Hedef sınıf üzerindeki alanlardan bir tanesi, ilişkiyi tanımlamak
açsısından esas sınıf üzerine gelir.

Arac
Servis AracPlaka : String
1 n SonBakimTarihi
ServisNo
KoltukSayisi
AracPlaka : Arac
Model
Notlar
Figure 8: UML şemalarında ilişkinin gösterimi
Yukarıdaki şemada Servis sınıfı üzerindeki AracPlaka sahasının tipine dikat edin. Tip olarak Arac
sınıfı verilmiştir. Yani
1. İlişki Çeşitleri
Yukarıdaki şemada ilişkiyi Türkçeleştirerek okursak ortaya şöyle bir şey çıkar.
Soldan sağa: Her Servis pek çok araca sahip olabilir.
Sağdan sola: Her Araç sadece bir serviste çalışabilir.
Her iki ilişkide de zorunluluk yok. Yani Araçlar ve Servisler kendi başlarına var olabilirler. Bu tür
ilişkilere 1-To-Many yani “Bire Çoklu” ilişkiler denir.
2. Programda nasıl gözükecek
3. İki yönlü ilişkiler (bidirectional)

4.5.2.2 Fonksiyonlar (operations)
4.5.2.3 Genelleme (generalization)
4.5.2.4 Not ve Yorumlar
4.5.2.5 Bağımlılık (dependency)
4.5.2.6 Constraint kuralları
4.5.2.7 Desing by contract
4.5.2.8 Sorumluluklar
4.5.2.9 Statik fonksiyon ve alanlar
4.5.2.10 Aggregation and composition
4.5.2.11 Arayüzler
4.5.3 Sıralı İşlem Şemaları (Sequence Diagrams)
Her yazılım parçası bir kaç sınıftan oluşur. Her sınıfın kendi içinde belli servisleri olabileceği gibi
tüm yazılım parçasının dışarıya sunduğu hizmetler de vardır. Bu tür hizmetler arayüzlerde toplanarak dış
kullanıma açılır ve arayüzler vasıtası ile yazılım parçaları kendi aralarında haberleşir. Bir senaryo
belgesine göre bir işin başarılabilmesi için farklı yazılım parçalarının sunduğu hizmetlerin belli bir sırada
kullanılması gerekliliği vardır. Bu tür isteklere cevap verebilecek şema Sıralı İşlem Şemasıdır. Nesnelerin
hayat süreçlerini görmek için iyi bir yöntemdir.
4.5.3.1 Döngü ve durumsal işlemler
4.5.3.2 Senkron ve asenkron
4.5.3.3 CRC kartları
4.5.4 İşlem Akış Şemaları (Collaboration Diagrams)
4.5.5 Nesne Şemaları (Object Diagrams)
Nesne şemaları bir işlem sırasında nesnelerin durumlarını gösterir. Sınıfın kendisini değil sınıftan
oluşan nesneyi ele alır.
4.5.6 Paket Şemaları (Package Diagrams)
Sınıflar nesne yönelimli sistemlerin temel yapısını oluştururlar. Binlerce sınıftan oluşmuş çok
büyük bir yapıyı ele aldığınızda sınıf şemalarının okunması zor olabilir. Paket şemaları ile sınıfları

mantıksal olarak ayırarak gruplar ve okunmasını kolaylaştırırız. Sadece sınıfları değil tüm UML birimlerini
paketlemek mümkündür. Paketleride başka paketler içinde gruplandırmak mümkündür. Analiz edilen
sistemin karmaşıklığına bağlı olarak paketler çoğaltılabilir. Çözülmesi güç problemleri yada sistemleri
farklı paketlere bölerek ufak ufak çözme yoluna gidebiliriz. Hem yapılacak iş daha net ortaya çıkar hemde
büyük sistemin karmaşıklığı ile uğraşmamız oluruz. Ayrıca çözüme kavuşturduğumuz her ufak yapı taşı
bize bir sonraki adım için motivasyon verecektir.
Paketleri .NET çerçevesi içinde isim alanları (namespace) olarak düşünebiliriz. Bu durumda
paket içinde bulunan her sınıfın özel bir ismi olması zorunluluğu vardır.
Kurumsal bir uygulamayı paket şemaları ile kurgulayabilirsiniz. Sınıf şemalarından daha sade ve
anlaşılabilir olacaktır.
4.5.7 İşlem Durum Şemaları (State Machine Diagrams)
Tek bir nesnenin ömrü boyunca gireceği durumları analiz etmek amaçlı geliştirilmiştir.
4.5.8 Aktivite Şemaları (Activity Diagrams)
Okulda öğrendiğimiz Akış Şemalarına benzer. Tek fark olarak bunda paralel işlemleri şematik
olarak gösterebiliriz.
4.5.9 İletişim Şemaları (Communication Diagrams)
Sıralı işlem şemaları gibi sınıflar arası ilişkileri göstermek amaçlı oluşturulmuştur. Sıralı işlem
şemalarında her işlem belli bir sıra içinde yer alır, fakat iletişim şemalarında sınıfları ve mesajları
istediğiniz yere oturtabilirsiniz. Eski ismi “Collaboration Diagrams”’dır ve İşlem akış şemaları ile
karıştırılmamalıdır.
4.5.10 Modül Şemaları (Component Diagrams)
4.5.11 Zamanlama Şemaları (Timing Diagrams)
4.5.12 Kurulum Ve Yayımlama Şemaları (Deployment Diagrams)
Kurulum ve yayınlama şemaları sistemin hangi parçalarının hangi donanım ve yazılım üzerinde
çalışacağını göstermektedir. Donanım belli bir bilgisayar yada bir kart olabilir, yazılım donanımın
etrafında sistemi yayınlamak amaçlı bir işletim sistemi yada uygulama sunucusu veya web sunucusu
olabilir.

Yazilim Uzmanligi Uzerine

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Yazilim Uzmanligi Uzerine

Uploaded by

Copyright:

Available Formats

Yazılım Uzmanlığı Üzerine

Standartlaşma, Firma Altyapısı, Ekip Oluşturulması, Blogdan Seçmeler ve UML

Yazılım Uzmanlığı Üzerine

Sürüm 0.1 beta

Kitap Kimin İçin Yazıldı

Kitap 4 ana bölümden oluşmaktadır. Bunlar:

2- Proje Ekibinin Oluşturulması

Yazılımı üretecek ekibin yapılanması ve aralarındaki haberleşmenin nasıl olacağı konusunda

4- UML ve CBD ile Yazılım Geliştirme

1.1 Proje Alt Yapısının Hazırlanması

Bir firmanın değeri çalışanlarına verdiği değer ile doğru orantılıdır.

 Bilgisayarların tamamı yetkili bir firmadan alınmalıdır.

 Her kullanıcının kendi bilgisayarı hakkındaki özellikleri bilmesi ve en verimli biçimde

 Önceden plan yapılarak kabloların nerelerden geçeceği tesbit edilir.

1.1.3 İşletim Sistemleri

Sanallaştırma ile maliyetleri bir miktar düşürmek te mümkündür. Eğer sanallaştırma

Bir de yedekleme stratejilerinin çok iyi uygulanması ve sistemlerin, yazılan kodun,

1.1.4 Yazılım Araçları

İşte hayatınızı, ve firmanızın geleceğini belirleyecek en önemli karara geldik. Seçeceğiniz

 Ürününüzü birden fazla İşletim sistemini destekleyecek mi?

Ek yazılımlar, firma içerisinde ve yazılım geliştirme sürecinde işleri kolaylaştıracak, kendi

1.1.6 Dışarıdan Alınmış Modüller

1.1.7 Analiz Yazılımları

Projelerinizin analiz aşamasında harcayacağınız zaman daha çok olacağından, bu bölümde

UML veya OO analiz metodolojilerini kullanacaksanız kullanacağınız yazılım diline ek olarak, bu

1.1.8 Hata Denetleme Ve Atama Yazılımları

 Farklı projeler yaratıp modülleri belirleyebilmelisiniz.

 Farklı projeden modülleri bir diğer projede kullanabilmeli ve o modül için

1.1.9 Dizin Yapısı

1.1.10 Programlar Ve Sorumluları

1.1.11 Ürünün Dağıtımı

1.1.12 Merkezi Çalışma Yöntemleri

1. Belge yönetimi ve sürüm takibi

2. Kod yönetimi ve sürüm takibi

3. Ürününüzün yönetimi ve sürüm takibi

1.2 İş Ortamı Ve Sağlıklı Çalışma

1.2.1 Masalar Ve Bilgisayarlar

Kullanılan monitörlerin yüksekliği ve açısı ayarlanabilir kaideler üzerinde durması sağlanmalıdır.

Genelde bilgisayar ve yazılım firmalarında beyaz floresan kullanılır. Fakat bu floresanların

1.2.5 Proje Ortamının Güvenliği

Haftalık çalışma saatinin %20’si araştırma ve geliştirmeye ayrılabilir. Bu sayede çalışanların

2 Proje Ekibinin Oluşturulması

Şimdi bir proje ekibindeki sorumluluklara göz atalım.

2.1 Sistem Sorumlusu

2.2 Proje Lideri

2.2.1 Görev Süreçlerinin Tayin Edilmesi

GZ = (Eİ + 4NB + EK) / 6

Eİ = En iyi durumda görevin alacağı zaman

NB = Normal bitiş süresi

EK = En kötü durumda görevin alacağı zaman

2.3 Analiz Ekibi

2.4 Tasarım Ekibi

2.5 Yazılım Ekibi

2.6 Müşteri Temsilcisi

2.7 Test Ekibi

Test ekibinin yapacağı testleri bir kaç sınıfa ayırabiliriz. Bunlar:

2.8 Eğitim Ekibi

a- Yazılım ekibinin egitilmesi

b- Pazarlama ekibinin egitilmesi

d- Eğitim odalarının hazırlanması

Eğitim odalarının düzeni ve kullanılacak bilgisayar ve beyaz tahtaların bakımı konularından

e- Ürün eğitimlerinin hazırlanması

2.9 Pazarlama Ekibi

2.10 Kurulum Yönetimi Ekibi